Arquitectura física del registro de transacciones

El registro de transacciones se utiliza para garantizar la integridad de los datos de la base de datos y para la recuperación de datos. Los temas contenidos en esta sección proporcionan información acerca de la arquitectura física del registro de transacciones. Comprender la arquitectura física puede mejorar la eficacia en la administración de registros de transacciones.

El registro de transacciones de una base de datos está asignado a uno o varios archivos físicos. Conceptualmente, el archivo de registro es una cadena de entradas de registro. Físicamente, la secuencia de entradas del registro se almacena de forma eficaz en el conjunto de archivos físicos que implementa el registro de transacciones.

SQL Server Database Engine (Motor de base de datos de SQL Server) segmenta cada archivo de registro físico internamente en una serie de archivos de registro virtuales. Los archivos de registro virtuales no tienen un tamaño fijo y no hay un número fijo de archivos de registro virtuales para un archivo de registro físico. Motor de base de datos elige dinámicamente el tamaño de los archivos de registro virtuales al crear o ampliar los archivos de registro. Motor de base de datos intenta mantener un número reducido de archivos virtuales. El tamaño de los archivos virtuales después de ampliar un archivo de registro equivale a la suma del tamaño del registro existente y el tamaño del nuevo incremento del archivo. El tamaño o número de archivos de registro virtuales no lo pueden configurar ni establecer los administradores.

Los archivos de registro virtuales sólo afectan al rendimiento del sistema cuando se definen con valores pequeños para size y growth_increment. Si dichos archivos de registro crecen hasta un tamaño grande debido a muchos incrementos pequeños, tendrán una gran cantidad de archivos de registro virtuales. Esto puede retrasar el inicio de la base de datos, así como las operaciones de copias de seguridad y restauración del registro. Se recomienda que los archivos de registro se definan con un valor de size cercano al tamaño final necesario y que, además, tengan un valor de growth_increment relativamente alto.

El registro de transacciones es un archivo de registro circular. Considere, por ejemplo, una base de datos con un archivo de registro físico dividido en cuatro archivos de registros virtuales. Cuando se crea la base de datos, el archivo de registro lógico empieza en el principio del archivo de registro físico. Las nuevas entradas del registro se agregan al final del registro lógico y se expanden hacia el final del archivo físico. El truncamiento del registro libera los registros virtuales cuyas entradas son anteriores al número de secuencia de registro de recuperación mínimo (MinLSN). El MinLSN es el número de secuencia de registro de la entrada del registro más antigua necesaria para una reversión correcta de toda la base de datos. El registro de transacciones de ejemplo sería similar al de la siguiente ilustración.

Cuando el final del registro lógico llega al final del archivo de registro físico, las nuevas entradas del registro se escriben al principio del archivo de registro físico.

El ciclo se repite indefinidamente, siempre que el final del registro lógico no alcance el inicio del registro lógico. Si las entradas antiguas se truncan con la frecuencia suficiente para disponer siempre de espacio para todas las nuevas entradas de registro que se van a crear hasta el próximo punto de comprobación, el registro no se llena nunca. Sin embargo, si el final del registro lógico llega al principio del registro lógico, se produce una de estas dos situaciones:

• Si el registro tiene habilitada la opción FILEGROWTH y hay espacio disponible en el disco, el archivo se amplía en la cantidad especificada en growth_increment y las nuevas entradas del registro se escriben en la extensión. Para obtener más información acerca de la opción FILEGROWTH, vea ALTER DATABASE (Transact-SQL).

• Si la opción FILEGROWTH no está habilitada o el disco que almacena el archivo de registro tiene menos espacio disponible que la cantidad especificada en growth_increment, se genera el error 9002.

Si el registro contiene varios archivos de registro físicos, el registro lógico pasará por todos los archivos de registro físicos antes de volver a empezar por el principio del primer archivo de registro físico.