En mi publicación anterior sobre la optimización de las operaciones del registro de transacciones, analicé dos de las causas más comunes de la generación de registros de registro adicionales:el peso muerto de los índices no agrupados no utilizados y las operaciones de división de página (que causan la fragmentación del índice). Suponiendo que haya leído esa publicación, mencioné que hay problemas más sutiles que pueden ser perjudiciales para el rendimiento del registro de transacciones, y los cubriré aquí.
Muchas, muchas pequeñas transacciones
De vez en cuando, SQL Server descargará una parte del registro de transacciones en el disco. Se produce un vaciado de registros cada vez que:
- Se genera un registro de confirmación de transacciones.
- Se genera un registro de anulación de transacción al final de una reversión de transacción.
- Se han generado 60 KB de registros desde el último vaciado de registros.
El vaciado de registro más pequeño posible es un único bloque de registro de 512 bytes. Si todas las transacciones en una carga de trabajo son muy pequeñas (por ejemplo, si se inserta una sola fila de tabla pequeña), se producirán muchos vaciados de registro de tamaño mínimo. Los vaciados de registros se realizan de forma asincrónica, para permitir un rendimiento decente del registro de transacciones, pero hay un límite fijo de 32 E/S de vaciado de registros simultáneos en cualquier momento (aumentado a 112 en SQL Server 2012).
Hay dos posibles efectos que esto puede tener:
- En un subsistema de E/S de rendimiento lento, el volumen de pequeñas escrituras del registro de transacciones podría abrumar al subsistema de E/S, lo que provocaría escrituras de alta latencia y la subsiguiente degradación del rendimiento del registro de transacciones. Esta situación se puede identificar por latencias de escritura altas para el archivo de registro de transacciones en la salida de sys.dm_io_virtual_file_stats (consulte los enlaces de demostración en la parte superior de la publicación anterior)
- En un subsistema de E/S de alto rendimiento, las escrituras pueden completarse extremadamente rápido, pero el límite de 32 E/S de vaciado de registros simultáneos crea un cuello de botella cuando se intenta que los registros sean duraderos en el disco. Esta situación se puede identificar por latencias de escritura bajas y un número casi constante de escrituras de registro de transacciones pendientes cerca de 32 en la salida agregada de sys.dm_io_pending_io_requests (consulte los mismos enlaces de demostración).
En ambos casos, hacer que las transacciones sean más largas (¡lo cual es muy contrario a la intuición!) puede reducir la frecuencia de los vaciados del registro de transacciones y aumentar el rendimiento. Además, en el caso n.º 1, pasar a un subsistema de E/S de mayor rendimiento puede ayudar, pero puede conducir al caso n.º 2. Con el caso n.º 2, si las transacciones no se pueden prolongar, la única alternativa es dividir la carga de trabajo entre varias bases de datos para sortear el límite fijo de 32 operaciones de E/S de vaciado de registro simultáneas o actualizar a SQL Server 2012 o superior.
Crecimiento automático del registro de transacciones
Cada vez que se agrega espacio nuevo al registro de transacciones, debe inicializarse en cero (escribir ceros para sobrescribir el uso anterior de esa parte del disco), sin importar si la función de inicialización instantánea de archivos está habilitada o no. Esto se aplica a la creación, el crecimiento manual y el crecimiento automático del registro de transacciones. Mientras se lleva a cabo la inicialización cero, los registros no se pueden vaciar en el registro, por lo que el crecimiento automático durante una carga de trabajo que cambia los datos puede provocar una caída notable en el rendimiento, especialmente si el tamaño del crecimiento automático está configurado para ser grande ( decir gigabytes, o se deja en el valor predeterminado 10%).
Entonces, si es posible, se debe evitar el crecimiento automático permitiendo que el registro de transacciones se borre para que siempre haya espacio libre que se pueda reutilizar para nuevos registros. La limpieza del registro de transacciones (también conocida como truncamiento del registro de transacciones, que no debe confundirse con la reducción del registro de transacciones) se realiza mediante copias de seguridad del registro de transacciones cuando se usan los modos de recuperación Completo o Registro masivo, y mediante puntos de control cuando se usa el modo de recuperación Simple.
El borrado del registro solo puede ocurrir si nada requiere que se borre el registro en la sección del registro de transacciones. Un problema común que impide el borrado de registros es tener transacciones de ejecución prolongada. Hasta que una transacción se confirme o revierta, se requieren todos los registros desde el comienzo de la transacción en adelante en caso de que la transacción se revierta, incluidos todos los registros de otras transacciones que se intercalan con los de la transacción de ejecución prolongada. Las transacciones de ejecución prolongada pueden deberse a un diseño deficiente, un código que espera la intervención humana o un uso inadecuado de transacciones anidadas, por ejemplo. Todos estos pueden evitarse una vez que se identifican como un problema.
Puede leer más sobre esto aquí y aquí.
Características de alta disponibilidad
Algunas funciones de alta disponibilidad también pueden retrasar la limpieza del registro de transacciones:
- La duplicación de bases de datos y los grupos de disponibilidad cuando se ejecutan de forma asíncrona pueden generar una cola de registros que aún no se han enviado a la copia de la base de datos redundante. Estos registros deben conservarse hasta que se envíen, lo que retrasa la limpieza del registro de transacciones.
- La replicación transaccional (y también la captura de datos modificados) se basa en un trabajo del Agente de registro del registro para escanear periódicamente el registro de transacciones en busca de transacciones que modifiquen una tabla contenida en una publicación de replicación. Si el Log Reader Agent se atrasa por algún motivo, o se hace que se ejecute con poca frecuencia a propósito, todos los registros que no hayan sido escaneados por el trabajo deben conservarse, lo que retrasará la limpieza del registro de transacciones.
Cuando se ejecuta en modo síncrono, la creación de reflejo de la base de datos y los grupos de disponibilidad pueden causar otros problemas con el mecanismo de registro. Usando la creación de reflejo síncrona de la base de datos como ejemplo, cualquier transacción que se confirme en el principal no puede regresar al usuario o la aplicación hasta que todos los registros que generó se hayan enviado con éxito al servidor reflejado, lo que agrega un retraso de confirmación en el principal. Si el tamaño de transacción promedio es largo y el retraso es corto, es posible que esto no se note, pero si la transacción promedio es muy corta y el retraso es bastante largo, esto puede tener un efecto notable en el rendimiento de la carga de trabajo. En ese caso, es necesario cambiar los objetivos de rendimiento de la carga de trabajo, cambiar la tecnología de alta disponibilidad al modo asíncrono o aumentar el ancho de banda y la velocidad de la red entre las bases de datos principal y redundante.
Por cierto, el mismo tipo de problema puede ocurrir si el propio subsistema de E/S se duplica sincrónicamente, con un retraso potencial para todas las escrituras que realiza SQL Server.
Resumen
Como puede ver, el rendimiento del registro de transacciones no se trata solo de que se generen registros de transacciones adicionales, hay muchos factores ambientales que también pueden tener un efecto profundo.
La conclusión es que el estado y el rendimiento del registro de transacciones son de suma importancia para mantener el rendimiento general de la carga de trabajo. En estas dos publicaciones, detallé las principales causas de los problemas de rendimiento del registro de transacciones, por lo que espero que pueda identificar y remediar cualquiera que tenga.
Si desea aprender mucho más sobre las operaciones del registro de transacciones y el ajuste del rendimiento, le recomiendo que consulte mi curso de capacitación en línea de 7,5 horas sobre el registro, la recuperación y el registro de transacciones, disponible a través de Pluralsight.
