Ir al contenido principal

Notas del SQL Saturday Barcelona (#338): Conocimiento compartido

Volvemos de Barcelona con la sensación de haber sido partícipes de una experiencia enriquecedora: el primer SQL Saturday celebrado en España ha sido todo un éxito.

La encomiable labor organizativa del grupo PASS España -encabezados por Rubén Pertusa-, la generosidad a la hora de compartir su conocimiento de los expertos venidos de diversos países para realizar sus excelentes ponencias y el entusiasmo de todos los profesionales registrados, allí reunidos durante más de 10 horas de sesiones, con un gran afán por compartir y aprender han hecho del SQL Saturday Barcelona un evento del que salimos con un bagaje positivo y muchas ganas de repetir.

Como bien expuso Fernando G. Guerrero, CEO de SolidQ -uno de los sponsors del evento-, "la curiosidad es lo que nos mueve". El apetito por aprender, las ganas de compartir experiencias y conocer a quienes también las viven son el motor de los SQL Saturday. Nada más acertado que el lema de "Share what you know, learn what you don't" (Comparte lo que sabes, aprende lo que no).
Nuestro sábado dio comienzo poco después de las ocho y media de la mañana. Tras el pertinente registro, llegaba la presentación del evento.

La primera sensación fue de sorpresa, pues el número de profesionales inscrito, dispuestos a sacrificar su tiempo libre para no perderse la cita -a centenares de kilómetros de su hogar, en muchos casos-, era elevado.

Tras la bienvenida en uno de los salones de actos del IQS (lugar donde se desarrollaría la jornada), comenzaban las sesiones. Distribuidas entre tres salas, las rutas a elegir eran claras: Business Intelligence, Big Data o DBA (y developers, añadiríamos).

Escogimos, por supuesto, la que más se ajustaba a nuestro perfil, la tercera de ellas. Comenzamos la mañana aprendiendo muchas cosas nuevas sobre SQL Server 2014, de la mano de Enrique Catalá.
No entraremos en detalles técnicos, puesto que no es el propósito de esta entrada en la bitácora, pero las Transacciones de Durabilidad Diferida enseguida captaron nuestra atención. Ya había merecido la pena el esfuerzo realizado por estar presente.

La segunda sesión, también en manos de Enrique, nos dejó con ganas de más. El tiempo destinado a explicar los planes de ejecución -que nos explican qué hace el motor de bases de datos para devolvernos lo que le pedimos- fue a todas luces escaso. Es un tema que da para muchas horas, y que conviene conocer a la perfección. Por cierto, Enrique sólo lo mencionó de pasada porque se quedó sin tiempo para más: si has de verte las caras con planes de ejecución, no dudes en usar SQL Sentry Plan Explorer.

Llegó el tiempo para el primer descanso. Un café y la primera oportunidad para conversar con compañeros de fatigas. Allí conocimos a Eduardo Burillo, alicantino él, con el que fue un placer compartir inquietudes.

Dos sesiones más antes de comer: En la primera, Sergey Olontsev nos habló de una utopía en "Cómo sacar provecho de In-Memory OLTP (Hekaton) en nuestras aplicaciones". Imposible. No se puede. Parece que el afán por competir con otras soluciones para Big Data ha provocado el parto prematuro de Hekaton. SQL Server 2014 salió mucho antes de que esta tecnología estuviese madura. Si es que algún día lo está. Habrá que estar pendientes de su evolución en próximas ediciones. Por ahora solamente alguna aplicación de nuevo cuño y con finalidad muy específica podría sacarle partido sin sufrir alguna se sus casi infinitas restricciones. Eso, y el rayo de luz final que supuso conocer la existencia de una alternativa en memoria a las tablas temporales y variables tipo tabla.

Llegaba el turno después para Davide Mauro, hablándonos de un tema en el que somos más bien profanos: "Cómo elegir el hardware adecuado para SQL Server". Apuntamos algunas cosas interesantes, como las herramientas TPC (Transaction Processing Performance Council) para banco de pruebas. Las usaremos.

Tras la hora de la comida, aún restaban tres sesiones más. Descubrimos el potencial de Power BI, de la mano Rodney Landrum como antesala a otra de las sesiones más interesantes del día, de la mano del divertido alemán Uwe Ricken. Su charla sobre lo que ocurre en las entrañas de SQL Server -esto es, a nivel de páginas de datos- cada vez que modificamos datos mediante instrucciones INSERT, UPDATE y DELETE fue realmente reveladora. No hubo tiempo para completarla, pero nos sumergió de lleno en lo que ocurre cuando ejecutamos dichas sentencias.

Finalizamos el día con la sesión más relajada del sábado. Alberto López Grande nos propuso una reflexión, desarrollada en un agradable debate colectivo, sobre el día a día del DBA, centrada en el desafío que supone mantener los servidores en las versiones más recientes para entornos productivos.

Las interesantes intervenciones de los allí presentes reflejó a la perfección el propósito y espíritu de los SQL Saturday: participar, compartir, debatir. En resumen, aprender. SQL Saturdays que, esperamos, se instauren y se conviertan en costumbre, no sólo en Barcelona, sino en cualquier ciudad donde los profesionales que trabajamos con SQL Server queramos seguir compartiendo conocimiento.

Comentarios

  1. Un placer también por mi parte. Buen resumen de la sala #3 del SQL Saturday 338 en Barcelona.
    Eduardo Burillo

    ResponderEliminar

Publicar un comentario

Entradas populares de este blog

Aprendiendo a usar LEFT OUTER JOIN

En esta entrada pretendemos explicar los diferentes resultados obtenidos por distintas construcciones de consultas que, aparentemente, deberían producir el mismo conjunto de resultados. Así, veremos las diferencias entre filtrar los resultados de una query en la unión (Join) mediante condiciones ON y mediante cláusulas WHERE.

Variantes del SELECT COUNT con DISTINCT

Seguramente, muchos de vosotros habréis usado en innumerables ocasiones la función de T-SQL COUNT , que no hace sino devolver un número de registros: de una tabla, de un conjunto de resultados, etc... En una de sus aplicaciones, combinado con el DISTINCT -uno de los dos argumentos que admite- COUNT nos devuelve el número de valores únicos no nulos de la tabla o conjunto de resultados que estemos consultando. Pero ¡ojo! Cuidado con la sintaxis , o podemos obtener el valor equivocado sin darnos cuenta. No es lo mismo: SELECT COUNT (DISTINCT NombreCampo) FROM NombreTabla que: SELECT COUNT(*), DISTINCT NombreCampo FROM NombreTabla

Script para obtener el tamaño de todas las tablas de la base de datos

En algunas ocasiones podemos vernos con la necesidad de conocer qué tablas de nuestra base de datos están ocupando más espacio en disco. Por ejemplo, si disponemos de SQL Server Express , cuyas bases de datos están limitadas a 4GB o 10GB, según la versión que estemos usando -4, hasta 2005; 10, a partir de 2008-, aparte de usar las opciones de comprimir la base de datos, poner el log en el modo simple de recuperación o ajustar las políticas de crecimiento automático de nuestros ficheros, podemos necesitar averiguar qué tablas crecen más para tomar las decisiones oportunas.