Malaga SQL PASS

Para empezar puedo contarte que PASS es una organización independiente sin ánimo de lucro creada por y para la comunidad. Con un grupo de mas de 100K miembros que va en aumento, PASS da soporte a los profesionales que usan la plataforma de datos de Microsoft a nivel global.

PASS se esfuerza por cumplir su misión mediante:

  • Facilitar el intercambio de información y networking a través de los grupos locales y virtuales, eventos online y regionales, y conferencias internacionales.
  • Proporcionar contenido técnico de alto nivel y actualizado para un aprendizaje en profundidad y desarrollo profesional.

PASS fue cofundado por CA Technologies y Microsoft en 1999 para promover y educar usuarios de SQL Server en todo el mundo. Desde su fundación PASS se ha expandido globalmente para acoger a cualquier profesional usando las tecnologías de datos de Microsoft.

Si necesitas más información:

Email: info@sqlpass.org

Telf: 1.604.899.6009 (International)

Mail: Professional Association for SQL Server
203 North LaSalle, Suite 2100
Chicago IL 60601 USA

 

Ser miembro de PASS es gratis

PASS pertenece a cada uno de sus miembros. El sitio web de PASS te proporciona un link virtual a todos los miembros de PASS, pero también te puedes beneficiar a nivel local uniéndote a un Grupo PASS y encontrándote en persona con otros profesionales del área.

Además, PASS organiza eventos globales como el Summit anual, el mayor evento para profesionales de Microsoft SQL Server en el mundo, o el PASS Business Analytics Conference. Y también los eventos SQLSaturday.

En España tenemos el PASS Spanish Group, con sede en Madrid, y desde Diciembre de 2016: el Grupo Malaga SQL Server. Somos el segundo grupo creado en España, de lo que estamos muy orgullosos! 🙂

También están los Grupos PASS virtuales, hay docenas y ofrecen conocimiento muy especializado:

  • Application Development
  • Big Data
  • Business Analytics
  • Business Intelligence
  • Cloud
  • Data Architecture
  • Data Science
  • Database Administration
  • DBA Fundamentals
  • Excel Business Intelligence
  • Varios grupos específicos por idiomas: Español, italiano, francés,…
  • Sanidad / Healthcare
  • High Availability & Disaster Recovery
  • Hybrid
  • Infrastructure VC
  • Performance
  • PowerShell
  • Professional Development
  • Saturday Night SQL
  • Security
  • Virtualization
  • Women in Technology
  • etc

PASS está activamente comprometido para añadir nuevos beneficios a sus miembros. Te puedes registrar siguiendo este enlace, y podrás ver la lista completa de beneficios. Si todavía no estás seguro, échale un vistazo a su web y mira todo lo que ofrecen. Una vez registrado, puedes unirte a todos los grupos, chapters, que quieras. Recomendamos los virtuales que te interesen y tu PASS chapter más cercano.

Lo mejor, un montón de recursos gratis e impulsar tu carrera 😉

Anuncios

Un asunto pendiente de MS SQL Server Developer

Para este artículo empezaremos comentando como es un entorno común de trabajo, que de encaje al ciclo de desarrollo de SW elegido en vuestra empresa. Luego veremos que nos ofrece MS SQL Server. Y al final os comento mi opinión.

Si nos paramos a pensar como son los entornos de trabajo de una empresa de desarrollo, muchos de vosotros encajaréis en en lo siguiente:

  • 1 Entorno de desarrollo: Volumen de datos reducido, esquema igual que producción + nuevos cambios. AKA Desarrollo,
  • [0..N] Entornos de pruebas de integración: Volumen de datos reducido, esquema igual al de producción. AKA Integración.
  • [0..M] Entornos de pruebas de carga: Volumen de datos similar a Producción, esquema clon de producción, configuración (servidor e instancia) igual a producción. AKA Load Test
  • [1..P] Entornos de producción: entorno final del producto/aplicación. AKA Producción.

Por [0..N], nos referimos a cero o más. [1..M]: Al menos uno, etc. Basta decir la importancia que tiene la consistencia entre entornos es crucial para que el ciclo de desarrollo del SW funcione correctamente.

Ejemplo 1: la definición de una tabla o el código de un procedimiento almacenado en Desarrollo debe ser igual al del resto de los entornos antes de un nuevo cambio.

Ejemplo 2: La configuración del entorno de Load Test debe ser un clon al de Producción, en todos los sentidos: Esquema de BD, configuración de la instancia de SQL Server, configuración del servidor, etc. De lo contrario las pruebas realizadas aquí no tendrán valor o muy poco, ya que no nos servirá para predecir el comportamiento de Producción en situaciones de alta carga de trabajo.

Ahora que hemos planteado el escenario, veamos que nos ofrece SQL Server para cada entorno, resumido en dos líneas:

  • Entornos de no Producción: MSSQL Developer.
  • Entornos de Producción: MSSQL Standard o Enterprise.

Standard tiene muchas características/opciones y Enterprise las tiene todas. Por citar un ejemplo: El motor de SQL Server en Enterprise, para una consulta X, usará automáticamente una vista indexada, en caso de que exista y ayude a generar un mejor plan de ejecución y por tanto optimize el rendimiento de la consulta. En Standard no es así. Por eso la diferencia de costes de licencias entre una y otra. Aquí puedes ver todas las diferencias entre las ediciones, hay un buen número.

Pos su parte la edición MSSQL Developer funciona con todas las opciones de Enterprise, seguramente con algún matiz pero ahora no entraremos en eso. Lo cual está muy bien para ver qué es lo que ofrece el MSSQL, probar y tratar de convencer a tus jefes de lo bueno que es Enterprise para que lo compren.

Pero… ¿Qué pasa si el entorno de Producción tiene que ser Standard, sí o sí? Developer edition no tiene hasta la fecha ninguna opción para configurarlo como otra edición diferente. WTF!!??

¡Sí amigos! Esto es lo que hay por ahora… pero se puede hacer algo para que lo cambien. Para ello existe un ticket de Connect abierto, si te interesa como a mí ¡Vota!

Hasta el próximo post!

 

Empezando con QUERY STORE

Esta es una nueva de las nuevas características en la versión 2016, de la que se está hablando mucho en los círculos de SQL Server ¿Está lista para ser usada? ¿O es una de esas características a las que hay que dejar evolucionar hasta que pasen unas versiones más? ¿Hay unas buenas prácticas ya? Yo te recomiendo ante todo que lo pruebes por ti mismo, aunque también puedes leer un blog y ver qué dicen… ¡Ahí vamos!

Lo que ofrece Query Store

Nos ofrece la creación de forma automática un registro perdurable de consultas, planes de ejecución y estadísticas. Esta funcionalidad se activa a nivel de base de datos, no de instancia. Lo cual veo positivamente, porque lo hace más adaptable. Habrá instancias donde te interese tenerlo activado para todas las BBDD de usuario y otras en las que sólo para algunas.

Si habéis hecho alguna vez consultas a las vistas dinámicas del sistema sys.dm_exec_query_stats o sys.dm_exec_procedure_stats para medir el rendimiento de alguna consulta o procedimiento, incluso combinadolo con la función sys.dm_exec_query_plan, posiblemente habréis pensado “Qué pena que toda esta información no sea persistente y se pierda con un reinicio del servidor o servicio de SQL…”

Bueno… ¡Es justo lo que hace Query Store! Y varias cosas más como veremos en este y futuros artículos.

Configurando Query Store

Query Store, en adelante QS, tiene una configuración por defecto que puede cambiarse a conveniencia. Recomiendo leer detenidamente todas estas opciones de configuración en la msdn, las detallo todas a continuación y comento algunas de ellas:

  • OPERATION_MODE: Puede ser READ_WRITE, que permite la recopilación y consulta de datos por parte de Query Store. También puede ser READ_ONLY, o sólo consulta, y dejan de actualizarse las estadísticas, los planes, etc.
  • CLEANUP_POLICY: Se usa junto a la keyword STALE_QUERY_THRESHOLD_DAYS y sirve para especificar cuanto tiempo queremos retener los datos recopilados, por defecto son 367 días.

Si la principal utilidad de QS es analizar el rendimiento de la base de datos, y dar un mejor soporte al troubleshooting, guardar los metadatos de todo un año o incluso varios meses parece muy exagerado. Para este propósito de resolver/investigar un problema de rendimiento, pondría un valor de una semana como mucho. Con un valor bajo, mantenemos a ralla el tamaño máximo que pueda necesitar QS.

  • DATA_FLUSH_INTERVAL_SECONDS: Para indicar con qué frecuencia quieres que los datos recopilados se graben en disco, se hagan persistentes. El valor por defecto son 900 seg (15 min).

Hay que tener en cuenta que en caso de un apagón se perderá todo lo que QS tenga en memoria, si este valor es alto entonces potencialmente puedes perder todos esos datos de los últimos N-1 minutos, donde N es el valor configurado. Por otro lado, si este valor es muy bajo, QS estará grabando cada pocos segundos en disco. Es algo que hay que ponderar y que dependerá de la memoria disponible y el rendimiento del almacenamiento.

  • MAX_STORAGE_SIZE_MB: Para indicar el tamaño máximo de almacenamiento asignado a QS. Por defecto son 100 MB. Si Query Store alcanza su tamaño máximo asignado, automáticamente su OPERATION_MODE pasa a READ_ONLY.

Este valor dependerá de la carga de trabajo, workload, que tenga la base de datos. Un buen valor será aquél que no cause frecuentes llenados del QS.

  • INTERVAL_LENGTH_MINUTES: Intervalo de tiempo para agregar datos. Valores permitidos: 1, 5, 10, 15, 30, 60 y 1440. Por defecto es cada hora.

Este valor es muy importante, ya que afecta al espacio que QS necesitará. Si se agregan datos cada pocos minutos, hará falta más espacio.

  • SIZE_BASED_CLEANUP_MODE: Hace que QS haga un mantenimiento automático cuando se acerque al MAX_STORAGE_SIZE_MB. Valores permitidos: OFF y AUTO, cuando llega al 90% de la capacidad, elimina las más antiguas y menos costosas hasta llegar al 80%.

Esta es una opción muy importante para evitar que el QS se llene, se ponga en modo READ_ONLY y por tanto deje de recopilar datos y sernos útil. El citado cleanup no debería ocurrir más de una vez cada N días, si no podrías estar perdiendo información útil en caso de querer investigar un problema en las últimas 24 horas por ejemplo.

  • QUERY_CAPTURE_MODE: Indica el modo actual de captura de datos de ejecución. Valores posibles:

ALL, captura todas las consultas. Es el valor por defecto.:

AUTO, recopila todas las consultas relevantes. Se basa en número de ejecuciones y consumo de recursos.:

NONE deja de capturar nuevas consultas, pero continúa recopilando datos para las que existían.:

La opción AUTO sin duda ayudará a mantener el tamaño de QS a raya.:

  • MAX_PLANS_PER_QUERY: Indica el número máximo de planes de ejecución que se pueden guardar para cada consulta. Por defecto es 200.

El valor por defecto es realmente alto. Personalmente lo reduciría en función de STALE_QUERY_THRESHOLD_DAYS. Si vamos a retener información para una semana, MAX_PLANS_PER_QUERY podría ser por ejemplo 7, para el caso extremo de una query que cambie su plan de ejecución cada día.

Eso es todo por ahora, espero que como introducción os haya sido útil. En un próximo artículo mucho más práctico sobre Query Store, comprobaremos algunos ejemplos de configuraciones, monitorización y consumo de recursos.