cloud

Jun

2024

Cambiar propietario Jobs SQL

Cambiar el propietario de nuestros Jobs de SQL Server a priori es una tarea manual que debemos hacer uno a uno. Este es un proceso común cuando un usuario propietario de varios jobs abandona la compañía o cambia de rol y sus trabajos deben ser asignados a otra persona. Sin embargo, con un poco de conocimiento sobre las tablas y procedimientos de sistema de la MSDB y con código T-SQL dinámico vamos a poder automatizar el proceso.

Para cambiar automáticamente el propietario de todos los jobs de un usuario a otro usaremos el siguiente script. Como has podido ver en el video lo que hace es generar dinámicamente los procedimientos sp_update_job y sp_update_schedule con los parámetros necesarios para cada uno de los jobs y programaciones y el nuevo propietario. Para ello hace uso de las tablas de la base de datos msdb sysjobs, sysjobsschedules y sysschedules cruzando estas con la vista syslogins de master donde encontraremos los logins. De esta manera podemos localizar fácilmente los jobs que pertenecían al antiguo usuario y que debemos cambiar el propietario.

SELECT
	'GO
	EXEC msdb.dbo.sp_update_job @job_id=N'''+convert(varchar(36),J.job_id)+''', 
		@owner_login_name=N''sa''
	GO'
	,'GO
	EXEC msdb.dbo.sp_update_schedule @schedule_id=N'''+convert(varchar(36),s.schedule_id)+''', 
		@owner_login_name==N''sa''
	GO'
	,j.job_id
	,j.name job_name
	,j.enabled job_enabled
	,s.name schedule_name
	,s.schedule_id
	,s.schedule_uid
	,s.enabled schedule_enabled
FROM
	msdb.dbo.sysjobs j
	FULL JOIN msdb.dbo.sysjobschedules js on j.job_id = js.job_id
	FULL JOIN msdb.dbo.sysschedules s on js.schedule_id = s.schedule_id
	INNER JOIN sys.syslogins l on j.owner_sid = l.sid
WHERE
	l.name LIKE 'usuario antiguo'
ORDER BY j.name

Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si quieres ver más videos como este puedes encontrarlos todos aquí. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Jun

2024

ROWGUIDCOL

Hoy os vengo a hablar de una característica de SQL Server y las bases de datos de SQL en Azure que normalmente no se usa pero que es muy importante. La opción ROWGUIDCOL cuando estamos definiendo el tipo de datos de nuestras tablas.

ATENCIÓN este artículo es de nivel avanzado, no sufras si no entiendes nada ahora mismo. Te recomiendo investigar sobre los nuevos conceptos que te encuentres y no sepas de que van. Yo voy a intentar enlazarte con anteriores artículos relacionados o documentación extra siempre que sea posible.

¿Qué es ROWGUIDCOL y por qué es importante?

ROWGUIDCOL es una propiedad que vamos a poner a nuestras columnas GUID (identificadores globales). Aunque se puede poner en columnas con otros tipos de datos lo normal es usarlo en campos de tipo Uniqueidentifier. Es especialmente útil en entornos con distintas bases de datos pues nos va a permitir que la clave sea única entre todas las bases de datos.

NEWSECUENTIALID

Si además acompañamos la propiedad ROWGUIDCOL con un valor por defecto NEWSECUENTIALID() en lugar del tradicional NEWID() vamos a conseguir un mejor resultado. La diferencia entre estas dos funciones es que mientras NEWID genera un GUID aleatorio NEWSECUENTIALID va a generar un GUID mayor que cualquier otro generado desde el último reinicio del servidor. También está preparado para trabajar correctamente en entornos de clúster por lo que si tienes un balanceo en tu AlwaysOn va a tener en cuenta los valores generados anteriormente en el otro nodo.

NEWSECUENTIALID es mejor en términos de rendimiento ya que no tiene que generar la aleatoriedad de NEWID y, por tanto, consume menos recursos de páginas en la caché. Además usar NEWSECUENTIALID nos va a ayudar a llenar completamente las páginas de datos e índices y a permitir un FILLFACTOR del 100%. Por contra, el hecho de generar identificadores globales mayores puede ser un riesgo de seguridad. Si la privacidad es clave en tus sistemas seguramente prefieras un GUID totalmente aleatorio y que no se pueda estimar cual es el próximo valor.

Usos Prácticos de ROWGUIDCOL

Como ya hemos visto, la propiedad ROWGUIDCOL puede sernos útil en escenarios donde necesitamos una clave primaria que sea única en todas las bases de datos, no sólo en una base de datos individual. Por ejemplo, estamos desarrollando una aplicación que necesita sincronizar datos entre varias bases de datos, usaremos ROWGUIDCOL para asegurar que cada fila tiene un identificador único en todas las bases de datos.

ROWGUIDCOL en la replicación

Además de lo que ya hemos visto, ROWGUIDCOL es extremadamente útil en escenarios de replicación. En la replicación, a menudo es necesario tener una forma de identificar de manera única cada fila en una tabla. ROWGUIDCOL proporciona una forma fácil de hacer esto sin tener que generar manualmente valores únicos.

Si tenemos una replicación de mezcla (Merge Replication) SQL Server usará el campo marcado como ROWGUIDCOL para identificar las filas. Esto puede sernos un inconveniente ya que no podremos luego usar nosotros ese campo para filtros en la replicación. También es importante que sepas que si configuras una replicación de mezcla sobre una tabla con una columna ROWGUIDCOL SQL asignará automáticamente el valor de NEWSECUENTIALID() como por defecto para esta columna.

Conclusión

El tema de los identificadores únicos para nuestros datos da mucho juego, hoy hemos profundizado en uno de sus aspectos más complejos en SQL Server pero siempre se puede ir un poco más allá. Si te has quedado con ganas de más te recomiendo este artículo del blog de Microsoft en el que se explica cómo se ordenan estos uniqueidentifier hexadecimales.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Jun

2024

Reducir el tamaño de bases de datos SQL

En esta ocasión vengo a explicaros como puedes hacer para reducir el espacio que ocupan nuestras bases de datos liberando el espacio libre que hay en los ficheros. Para ello, tendremos que hacer un Shrink de los ficheros de base de datos. Tendrás que hacerlo tanto en el ficheros de datos como en el de log (o en el que sepamos que existe un problema).

Evita siempre que puedas la operación de reducir de ficheros, sobre todo en los ficheros de datos, ya que consume muchos recursos del servidor y además va a empeorar el rendimiento de nuestra base de datos. Si no queda más remedio o si has eliminado tanta información que merezca la pena hacerlo, ten la precaución de programarlo fuera de horas de trabajo y de reconstruir los índices fragmentados una vez termines.

En los ficheros de log, como en los de TempDB no vas a tener los problemas de fragmentación pero si de consumo de recursos por lo que aunque no tengamos que ser tan estrictos si debemos intervenir con la debida precaución.

Puedes encontrar los script que he usado en el video aquí. Espero que te haya gustado el video, si es así por favor, deja tu me gusta y suscríbete al canal que nos ayuda mucho. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram al que te puede unir. En este grupo estamos creando una comunidad de usuarios y administradores de SQL Server donde cualquiera pueda preguntar sus dudas y compartir sus casos prácticos para que todos seamos mejores profesionales. ¡Hasta la próxima!

Jun

2024

Migrar de Azure SQL DB a Azure Managed Instance

Te pongo en situación, tu empresa decidió hace tiempo empezar a desplegar servicios en la nube de azure. En una fase inicial del proyecto se decidió usar bases de datos de Azure SQL sin servidor, la gama de entrada a SQL en Azure. Ha pasado el tiempo y se ha descubierto que el proyecto no puede continuar debido a las limitaciones de esta solución SAAS. Hay que migrar las bases de datos.

¿Por qué migrar y donde?

Como ya te he adelantado en la descripción, el problema es que necesitas alguna de las características de SQL Server que no incluyen las bases de datos de Azure SQL. Sin embargo, sí que sigues convencido de que la mejor opción es un producto SaaS administrado en la nube, con un tiempo de disponibilidad del 99,99%, con actualizaciones automáticas, seguridad de datos avanzada y análisis de registros SQL de Azure. Básicamente no tener que administrar una máquina local o virtual IaaS.

Parece que la solución es clara, necesitas una instancia administrada de SQL en Azure. Las características de Azure MI que no tienen las bases de datos de Azure SQL son:

Consultas entre bases de datos
Usar las bases de datos como publicadoras en replicación.
Copias de seguridad y restauraciones a petición por T-SQL.
Compatibilidad con .NET SQL CLR
Activadores de ámbito de servidor o triggers de inicio de sesión
Captura de datos modificados (CDC)
Acceso a Resource Governor.
Agente de SQL.
Y más…

¿Cómo no migrar?

En este punto te piden a ti, DBA, llevar a cabo esta migración. Parece una tarea sencilla, ¿verdad? Pues vamos a ver que de eso nada. Como acabamos de ver en el apartado anterior, una de las limitaciones de las bases de datos de Azure SQL es que no permiten copias de seguridad por T-SQL. Aunque si tienen copias de seguridad automáticas por parte de Azure, estas solo se pueden restaurar como otra base de datos de Azure SQL, no las vas a poder llevar a una instancia.

Tampoco vas a poder usar una base de datos de Azure SQL como origen de datos en Azure Data Migration Service (DMS) ni en Data Migration Assistant (DMA). Y esto no es todo, tampoco admiten DB Mirroring, AlwaysOn, Log Shipping o Replicación. Estás perdido, solo te queda implementar una solución de copia de datos manual con T-SQL, SSIS o Azure Data Factory lo que te va a suponer mucho esfuerzo y una sobrecarga de trabajo difícil de asumir. Pero, no te preocupes, yo te voy a contar cómo hacerlo de manera fácil.

¿Qué opciones tienes?

Visto lo visto, partiendo de las premisas anteriores lo primero que tienes que asumir es que esto va a ser un proceso manual. Podrías automatizarlo con las alternativas que hemos mencionado antes de T-SQL, SSIS o Data Factory pero eso no es lo que buscas. Necesitas una solución simple, mover los datos y ya está. Para eso tenemos dos opciones o usar el asistente de Import/Export con SSIS en SSMS o usar el asistente para importar/exportar aplicaciones de capa de datos, también en SSMS.

Asume que durante la migración vas a tener un tiempo de inactividad total de las bases de datos. Realmente vas a poder seguir leyendo la base de datos Azure SQL de origen pero si haces cambios es posible que luego no los veas replicados en la Azure MI.

Ahora bien, puedes reducir el tiempo de inactividad migrando las tablas por partes siempre que tu aplicación lo permita. Si tienes unos datos “frios”, una especie de diccionarios con pocos o ningún cambio puedes migrar esas primero sin parar la aplicación para luego reducir el tiempo al migrar solo el resto de tablas.

Migrar con el asistente de import/export de SSIS en SSMS

Este asistente, lo puedes ejecutar desde SSMS y genera un paquete de SSIS básico para la copia de datos. OJO, solo para la copia de datos. Si las tablas no existen si que las va a crear pero no va a crear ningún otro objeto, ni siquiera los índices. No, ni los índices clustered ni las PK ni nada. Por supuesto tampoco va a crear vistas, triggers, funciones, procedimientos, etc…

Paso 1

Como este asistente solo copia datos lo primero que tienes que hacer es crear en tu instancia administrada de Azure la base de datos con todos los objetos de la base de datos. Sin embargo, en este punto no te recomiendo crear ni los triggers ni las Foreign Keys para evitar problemas con la copia de datos. Para generar los script de creación de objetos puedes usar el asistente que incluye el propio SSMS.

Paso 2

Ahora que ya tienes toda la estructura de tu base de datos creada en Azure MI puedes usar el asistente de importación y exportación para copiar los datos. No vamos a profundizar en este punto porque ya lo hemos explicado en este artículo y en este vídeo. Solo vas a tener que elegir el origen y el destino correctos.

Paso 3

Ahora que ya tienes todos los datos copiados es el momento de crear los triggers y las FK que antes hemos dejado pendientes. También debes validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.

Migrar con el asistente de import/export de aplicaciones de capa de datos en SSMS

Este asistente, lo puedes ejecutar desde SSMS y genera un archivo bacpac que luego vas a poder importar sobre la base de datos de tu instancia administrada usando el mismo asistente. Es muy parecido a una copia de seguridad tradicional aunque no es exactamente lo mismo. Vas a ver que los pasos son muy simples.

Paso 1

A diferencia del anterior, este asistente no solo copia datos sino que te va a migrar también los objetos. Además, para importarlo, solo vas a poder hacerlo sobre una base de datos nueva así que en este paso vas a exportar directamente los datos de origen en formato bacpac desde tu SSMS. Haz clic derecho sobre la base de datos, ve al menú tareas y ahí a la opción Exportar aplicación de capa de datos…

Paso 2

Es el momento de restaurar en el destino. Conectate con SSMS a tu instancia administrada de Azure y con clic derecho sobre “bases de datos” ve a restaurar aplicación de capa de datos. Sigue los pasos del asistente para importar tu archivo bacpac.

Paso 3

Ahora que ya tienes todos los datos copiados es el momento de validar que todo está correcto y ya estaría listo para trabajar en el nuevo entorno.

Otras opciones

Existe un tercer método simple que no te había comentado hasta ahora pero que también te puede servir para migrar tus datos. Es bastante más sencillo que los anteriores pero su uso queda limitado a bases de datos realmente pequeñas. Esta tercera opción consiste en generar los scripts de base de datos igual que has hecho en el primer paso de la primera solución que te he enseñado pero, en las opciones avanzadas, seleccionar también que genere los script para migrar los datos. De esta manera te generará los scripts con un insert por cada registro de cada tabla que tengas. Como ves te va a mover los datos pero es del todo ineficiente y solo es para bases de datos con pocas tablas y muy pocos registros.

Conclusión

Has visto las formas sencillas de migrar tus datos de una base de datos de Azure SQL a una instancia administrada de Azure. Con estos métodos vas a poder salir airoso de esta difícil tarea. Ahora ya si te quieres complicar te recomiendo crear un paquete SSIS que copie los datos con un bucle por cada una de las bases de datos en tu servidor de bases de datos de Azure SQL y lo que se te ocurra. A mi es la solución que más me gusta pero, cierto es, que solo merece la pena si las que tienes que migrar son muchas bases de datos.

Jun

2024

Tipos de dato Fecha y Hora

Uno de los retos más importantes que vamos a enfrentar cuando trabajamos con datos es la gestión de las fechas y horas. Al igual que nos pasaba con los datos numéricos, elegir el tipo de datos de fecha y/o hora correcto es de vital importancia y no debe ser ignorado. En SQL Server, tenemos a nuestra disposición varios tipos de datos para manejar la fecha y la hora. Pero, ¿sabemos realmente cuándo y cómo utilizar cada uno de ellos? En este artículo, vamos a profundizar en este tema pues no es solo tarea del diseñador de la base de datos sino que, como DBAs tendremos que asesorar al usuario para evitar incidencias con las conversiones de datos en un futuro.

Tipos de Datos de Fecha y Hora

Tanto SQL Server como Azure SQL ofrecen varios tipos de datos para trabajar con fechas y horas: datetime, smalldatetime, date, time, datetime2 y datetimeoffset. Cada uno de ellos tiene unas particularidades y responde a unas necesidades concretas que deberemos conocer para una elección correcta del tipo de dato llegado el momento.

Datetime y SmallDatetime (fecha y hora)

Datetime y SmallDatetime son los tipos de datos más antiguos y existen desde las primeras versiones de SQL Server. Nos van a permitir manejar las fechas y las horas sin demasiada complicación aunque por contra perderemos detalle comparado con otros tipos más modernos. En concreto, Datetime tiene una precisión de hasta 3 milisegundos, mientras que SmallDatetime tiene una precisión de hasta un minuto.

Date y Time (solo fecha y solo hora)

Con la llegada al mercado de SQL Server 2008 se introdujeron los tipos de datos Date y Time. Estos tipos de datos nos permiten almacenar únicamente la fecha o la hora, respectivamente respondiendo así a una necesidad hasta entonces sin cubrir.

Datetime2 (fecha y hora)

Datetime2 es una evolución del tipo de datos datetime que tiene una mayor precisión y un rango de fechas más amplio. Puede tener una precisión de hasta 100 nanosegundos lo que lo convierte en compatible con los estándares ANSI e ISO 8601. Es el tipo de datos que yo te recomendaría usar si estás diseñando una nueva base de datos desde el principio y no te quieres complicar en exceso.

Datetimeoffset (fecha, hora y zona horaria)

Por último, Datetimeoffset es el tipo de datos de fecha y hora más completo que ofrecen SQL Server y Azure SQL. Es similar a datetime2, pero incluye información sobre la zona horaria. Es útil cuando se trabaja con diferentes zonas horarias pero, si no es nuestro caso, este extra de información solo va a conllevar más consumo de espacio y, por tanto, de recursos a la hora de trabajar.

Ejemplos

Veamos todos estos tipos de datos en un ejemplo para que se entienda mejor:

Datetime vs Datetime2: Conversiones entre tipos de datos

Como ya hemos visto, Datetime2 es especialmente interesante debido a su gran precisión y rango. Esto, que a priori es una ventaja, puede llevarnos a errores cuando convertimos a Datetime2 desde Datetime. Si os fijáis en la captura del apartado anterior yo he usado la función SYSDATETIME() que devuelve un resultado Datetime2 y no GETDATE() que devuelve Datetime. Veamos el mismo ejemplo con la función GETDATE()

Como veis, al convertir un valor Datetime a Datetime2 no se rellena con 0 la precisión faltante sino que, en este caso, se ha rellenado con un 3 periódico. Si volvéis a leer ahora lo que os he contado de Datetime veréis que os he dicho que la precisión es de hasta 3 milisegundos y en ningún momento os he dicho que tenga una precisión de milisegundos. Es decir, la precisión es de uno entre 300 fracciones de segundo y no de 1/1000 segundos.

Al convertir ese valor Datetime a Datetime2 no tenemos información para completar ese extra de precisión. Además, es imposible representar en un número en base 10 el valor 1/300 por eso vemos ese 333 de manera infinita en los decimales.

Estilos de fecha y hora

Además de los tipos de datos, un aspecto clave en la representación de las fechas almacenadas en la base de datos es el estilo. Por defecto, se muestra en formato Año, Mes y Dia seguido de la hora en Horas, Minutos, Segundos y Milisegundos. Sin embargo, podremos actuar sobre este comportamiento y elegir el estilo que deseemos con unos valores a la hora de convertir los datos de fecha a texto para su representación.

Podéis encontrar todos los estilos disponibles en esta documentación oficial.

Conclusión

Manejar correctamente los tipos de datos de fecha y hora en SQL Server o Azure SQL es esencial para mantener la integridad de los datos y realizar cálculos precisos. Aunque puede parecer un tema sencillo al principio es más complejo cuando empiezas a trabajar con ello y a profundizar. Sin embargo, como todo, con un poco de práctica y estudio, se puede dominar. Espero que este artículo te haya ayudado en el dominio de los tipos de datos de fecha en SQL Server y Azure SQL. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

May

2024

Localizando advertencias en los planes de ejecución

Hace aproximadamente un año, Jose Manuel Jurado publicó este artículo en el blog de Microsoft. La verdad es que cuando lo vi me resultó curioso pero no le di mayor importancia, será porque no estaba yo tan enamorado como ahora de las bondades de query store. El caso es que parece que el artículo se me quedó grabado aunque nunca había vuelto a él ni lo había puesto en práctica. Y digo esto porque esta semana, hablando con mis compañeros de trabajo sobre los eventos extendidos y explicándoles cómo xEvents ampliaba con creces las características de SQL Server Profiler, les comenté que podrías crear una sesión que solo capture eventos que desencadenen cierto error.

Esto no es nuevo para vosotros, ya lo vimos aquí. Entonces se me encendió la bombilla y volvió a mi el artículo de José Manuel, ¿y si capturamos con eventos extendidos las consultas con advertencias en sus planes de ejecución?

Por qué xEvents para localizar advertencias

Como os he dicho, la idea de esta solución es una mezcla de curiosidad y mini-reto personal. Sin embargo, se me ocurre que puede ser una solución ideal para varios escenarios gracias a la capacidad de eventos extendidos de activar y desactivar la captura de datos a nuestra voluntad. Esto lo hace ideal para capturar eventos contenidos en el tiempo que nosotros hayamos localizado un problema. Tampoco vamos a necesitar en estos casos el historial de planes de ejecución como nos ofrece Query Store.

Capturando advertencias de conversión con eventos extendidos

Como algunos ya sabéis, un error de conversión de datos puede generar dos tipos de problema: errores de cardinalidad o errores en el plan de búsqueda. Es común que sean ambos pero, vamos a partir de la misma premisa del escenario original y vamos a capturar solo los warning de conversión del tipo “seek plan” o errores en el plan de búsqueda. Además vamos a añadir un par de filtros extra como limitar la captura a sesiones con un session ID mayor de 50 para evitar procesos de usuario y a limitarlo a las bases de datos con un ID mayor que 4 para evitar las bases de datos internas de SQL.

CREATE EVENT SESSION [Convert Warnings] ON SERVER 
ADD EVENT sqlserver.plan_affecting_convert(
ACTION(sqlserver.database_name,sqlserver.is_system,sqlserver.sql_text,sqlserver.username)
    WHERE ([package0].[greater_than_uint64]([sqlserver].[session_id],(50)) AND [package0].[equal_uint64]([convert_issue],'Seek Plan') AND [sqlserver].[database_id]>(4)))
ADD TARGET package0.event_file(SET filename=N'Convert Warnings')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)
GO

Y aquí lo podéis ver en funcionamiento:

¿Y el resto de advertencias?

Ahora que hemos visto que mi idea original es viable, ¿por qué quedarnos aquí? Ya vimos en el post sobre planes de ejecución que existen más tipos de advertencias en los planes de ejecución. ¿Y si hacemos una sesión que capture todos esos tipos de alertas? Pues sí mis queridos lectores, claro que os voy a enseñar esto también, ya sabéis que no soy yo de conformarme con poco. Tras indagar un poco en todas las posibles advertencias de planes de ejecución que podemos capturar con xEvents he creado esta sesión que vamos a repasar ahora juntos:

CREATE EVENT SESSION [WARNINGS] ON SERVER 
ADD EVENT sqlserver.hash_warning(
    ACTION(sqlserver.sql_text,sqlserver.username)
    WHERE (([sqlserver].[session_id]>(50)) AND ([sqlserver].[database_id]>(4)))),
ADD EVENT sqlserver.missing_column_statistics(
    ACTION(sqlserver.sql_text,sqlserver.username)
    WHERE (([sqlserver].[session_id]>(50)) AND ([sqlserver].[database_id]>(4)))),
ADD EVENT sqlserver.missing_join_predicate(
    ACTION(sqlserver.sql_text,sqlserver.username)
    WHERE (([sqlserver].[session_id]>(50)) AND ([sqlserver].[database_id]>(4)))),
ADD EVENT sqlserver.plan_affecting_convert(
    ACTION(sqlserver.sql_text,sqlserver.username)
    WHERE (([sqlserver].[session_id]>(50)) AND ([sqlserver].[database_id]>(4)))),
ADD EVENT sqlserver.sort_warning(
    ACTION(sqlserver.sql_text,sqlserver.username)
    WHERE (([sqlserver].[session_id]>(50)) AND ([sqlserver].[database_id]>(4)))),
ADD EVENT sqlserver.unmatched_filtered_indexes(
    ACTION(sqlserver.sql_text,sqlserver.username)
    WHERE (([sqlserver].[session_id]>(50)) AND ([sqlserver].[database_id]>(4))))
ADD TARGET package0.event_file(SET filename=N'WARNINGS')
WITH (STARTUP_STATE=ON)
GO

Aquí podemos ver varios eventos todos ellos relacionados con advertencias en los planes de ejecución entre los que encontramos:

Hash_warning: Este tipo de advertencia nos indica que la operación hash ha usado más memoria de la disponible y ha tenido que escribir datos en el disco.
Missing_column_statistics: Veremos esta advertencia cuando una consulta accede a una columna que no tiene estadísticas disponibles que podrían haber sido útiles para la optimización de consultas.
Missing_join_predicate: Se produce cuando una consulta ejecutada no tiene un predicado de combinación.
Plan_affecting_convert: Este es el caso que hemos visto en el escenario anterior, hay un error de conversión afectando al plan de ejecución.
Sort_Warning: Indica que la operación de ordenación ha usado más memoria de la disponible y ha tenido que escribir datos en el disco.
Unmatched_filtered_indexes: Este error es causado cuando SQL Server no puede hacer uso de un índice filtrado debido a que la consulta está parametrizada. Y si, esta es una de las limitaciones de SQL Server que más quebraderos de cabeza nos pueden dar.

Además, para cada uno de los eventos se han aplicado los mismos filtros de session ID y Database ID del escenario anterior.

Conclusión

Ya sea con query store como hizo Jose Manuel o con eventos extendidos como hemos visto aquí localizar las consultas con advertencias en sus planes de ejecución para luego arreglar el problema nos ayudará a mejorar el rendimiento de nuestro servidor y a no malgastar recursos. No cometas el error que cometí yo y no esperes un año para ponerte a buscar proactivamente este tipo de problemas. Y si se te ocurre otra forma de conseguir lo mismo dejalo en los comentarios o ponte en contacto conmigo para que te publique un artículo sobre el tema, yo estaré encantado de hacerlo. Somos una comunidad y el objetivo es compartir el conocimiento.

cloud

La SQLCon llega a España

NO TE PIERDAS NADA

Colabora con nosotros

Entradas recientes

Etiquetas

Comentarios recientes