sql >> Base de Datos >  >> RDS >> Database

Supervisión del registro de transacciones

Durante el último año, escribí varias veces en mi blog SQLPerformance.com sobre problemas de rendimiento del registro de transacciones (ver aquí) y prometí hablar sobre el monitoreo del registro de transacciones, lo cual haré en esta publicación. Voy a presentar algunas de las métricas que puede rastrear, por qué debería importarle y algún consejo para tratar el problema indicado.

DMV

La forma más fácil de monitorear las latencias de E/S del registro de transacciones es usar sys.dm_io_virtual_file_stats DMV. Deberá realizar algunos cálculos matemáticos para obtener resultados útiles y puede obtener un código de ejemplo en el script VirtualFileStats.sql en este archivo zip de demostración. Realmente desea ver latencias de escritura de menos de 5 ms para el registro de transacciones.

A principios de noviembre, publiqué en un blog los resultados de una encuesta que mostraba las latencias de los archivos de datos tempdb y del registro de transacciones para más de 25 000 bases de datos en todo el mundo (ver aquí), con el 80 % de las bases de datos alcanzando la marca de 5 ms o menos para la latencia de escritura del registro de transacciones.

Si su latencia de escritura es superior a 5 ms, puede:

  • Trabaje para reducir la cantidad de registros que se generan y/o la cantidad de descargas de registros que se producen a partir de pequeñas transacciones, como describí en publicaciones anteriores.
  • Siga algunos de los pasos de solución de problemas que describo en la publicación de blog de la encuesta anterior.
  • Pase a un subsistema de E/S más rápido, recordando que si decide usar un SSD, necesita usar dos en una configuración RAID-1.

Otra cosa que puede hacer es observar para asegurarse de no alcanzar el límite estricto de 32 E/S de escritura pendientes para el registro de transacciones de cada base de datos en 2008 R2 y antes (aumentado a 2012 desde SQL Server 2012 en adelante). Puede intentar hacer esto observando el Disco físico/Promedio. Longitud de la cola de escritura en disco, pero eso es para un volumen completo, no por archivo, por lo que si hay algo más en el volumen además del archivo de registro que le interesa, eso no le dará un número válido. Una mejor manera es agregar los resultados de sys.dm_io_pending_io_requests DMV, que enumera todas las E/S pendientes. Aquí hay un código para hacer eso:

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Puede modificar esto fácilmente para mostrar solo los resultados de los archivos de registro (filtro en type_desc ='LOG' ) y solo por el ID de la base de datos que le interesa.

Si descubre que está alcanzando el límite de 32 para una base de datos en particular, puede:

  • Reduzca la cantidad de vaciados de registros reduciendo la cantidad de transacciones pequeñas y prestando atención a cosas como divisiones de página e índices no utilizados/duplicados que se modifican durante las operaciones de modificación de datos. Puede leer más sobre cómo optimizar los vaciados de registros en esta publicación de blog.
  • Intente usar un subsistema de E/S más rápido
  • Actualice a SQL Server 2012 o superior, donde el límite es 112
  • Prueba la delayed durability feature DMV que se agregó en SQL Server 2014
  • Como último recurso, divida la carga de trabajo entre varias bases de datos o servidores

Si está interesado en ver cuánto registro de transacciones generan sus transacciones, puede usar sys.dm_tran_database_transactions DMV, en un código similar al siguiente:

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Es posible que se sorprenda mucho de la cantidad de registros que se generan, especialmente en tempdb para el código que utiliza objetos temporales. Y, por supuesto, el registro de transacciones de tempdb puede ser un cuello de botella al igual que una base de datos de usuarios.

Contadores del monitor de rendimiento

Los contadores de rendimiento relacionados con el registro están todos en el objeto de rendimiento Bases de datos. Estos son algunos de los principales para ver (ya sea con el propio Monitor de rendimiento, o usando las alertas del Agente SQL, o usando el DMV sys.dm_os_performance_counters, o en su herramienta de monitoreo de terceros favorita):

    Crecimientos de troncos

    No querrá ver que este contador aumente, ya que eso indica que algo está sucediendo en la base de datos que está causando que se genere más registro de transacciones que el espacio actual. Implica que el registro de transacciones no se puede borrar, por lo que debe investigar la causa consultando el campo log_reuse_wait_desc de sys.databases y tomar las medidas necesarias (consulte el tema de Books Online Factors That Can Delay Log Truncation para obtener más detalles). Un código de ejemplo sería:

    SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

    Cada vez que se produce un crecimiento del registro, la parte recién asignada del registro de transacciones debe ponerse a cero, además de que se agregan más archivos de registro virtuales, los cuales pueden causar problemas, como mencioné anteriormente en el blog.

    Retrocesos de registro

    A menos que usted sea la persona que realiza la operación de reducción para volver a controlar un registro de transacciones fuera de control, no desea que este contador aumente. Si alguien simplemente reduce el registro de transacciones sin una buena razón, es probable que vuelva a crecer, causando problemas como escribí anteriormente en el blog.

    Porcentaje de registro utilizado

    Debe monitorear este contador y preocuparse si el valor supera el 90 %, ya que eso indica que un crecimiento del registro puede ser inminente y el registro de transacciones no puede borrarse correctamente, como mencioné anteriormente.

    Registro de esperas de vaciado/seg

    Desea que este valor permanezca igual o disminuya. Si aumenta, significa que tiene un cuello de botella en el subsistema de E/S o un cuello de botella dentro del mecanismo de vaciado de registros porque está vaciando muchas porciones pequeñas de registros. Un aumento aquí también puede correlacionarse con alcanzar las 32 E/S pendientes para el registro. Vea la discusión de sys.dm_io_pending_io_requests arriba para más detalles.

    Bytes de registro vaciados/seg y vaciados de registro/seg

    Estos dos contadores le permiten calcular el tamaño medio de vaciado de troncos, dividiendo el primer contador por el segundo. El resultado será un valor entre 512 y 61440 (los tamaños mínimo y máximo de un vaciado de registros, respectivamente). Es más probable que un valor más bajo se correlacione con el aumento de las esperas/seg. de vaciado de registro. Nuevamente, vea la discusión de sys.dm_io_pending_io_requests arriba para más detalles.

Eventos extendidos

Para los más avanzados entre ustedes, hay algunos eventos extendidos que pueden usar para ver lo que sucede con el registro. Le recomiendo que comience usando la plantilla de seguimiento de E/S del archivo de registro de la base de datos en SQL Server 2012 SSMS. Puede llegar a esto yendo al Explorador de objetos y luego a su instancia -> Administración -> Eventos extendidos y haciendo clic con el botón derecho en Sesiones para seleccionar Asistente para nueva sesión. En la ventana que aparece, escriba un nombre de sesión y seleccione la plantilla de seguimiento del menú desplegable. Luego presione Ctrl+Shift+N y la sesión se programará en una ventana de consulta. Desafortunadamente, los detalles de todo lo que hay más allá del alcance de esta publicación, pero la descripción de la plantilla es bastante explicativa:

Esta plantilla supervisa la E/S de los archivos de registro de la base de datos en un servidor mediante el seguimiento de la E/S asíncrona, los vaciados de registros de la base de datos, las escrituras de archivos, las reversiones de spinlock de tipo LOGFLUSHQ y las esperas de tipo WRITELOG. Esta plantilla recopila datos de dos maneras:los datos sin procesar se recopilan en un búfer de anillo y la información de retroceso de spinlock se agrega en función del búfer de entrada (sql_text). La sesión se filtra para un solo archivo de registro por base de datos; si tiene varios archivos de registro, puede modificar el filtro para los eventos file_write_completed y file_write para incluir más que solo file_id =2.

También hay un nuevo evento extendido en SQL Server 2012 llamado transaction_log que se puede usar para realizar todo tipo de análisis interesantes de qué registros de registro se están generando. Ese es definitivamente un tema que trataré en una publicación futura.

Resumen

Dada toda la información anterior, debería poder crear un sistema de monitoreo de registro de transacciones bastante bueno. El estado del registro de transacciones es de suma importancia para garantizar que su carga de trabajo funcione como debería y espero que las cuatro publicaciones de esta serie (más todos los demás enlaces) lo hayan ayudado a mejorar el rendimiento general de su entorno de SQL Server.