Guía de arquitectura y administración

de registros de transacciones de SQL

Server
 04/01/2018
 Tiempo de lectura: 23 minutos

SE APLICA A:  SQL Server  Azure SQL Database  Azure SQL Data
Warehouse  Almacenamiento de datos paralelos

Todas las bases de datos de SQL Server tienen un registro de transacciones que

graba todas las transacciones y las modificaciones que cada transacción realiza
en la base de datos. El registro de transacciones es un componente esencial de
la base de datos y, si se produce un error del sistema, podría ser necesario para
volver a poner la base de datos en un estado coherente. Esta guía proporciona
información acerca de la arquitectura física y lógica del registro de
transacciones. Comprender la arquitectura puede mejorar la eficacia en la
administración de registros de transacciones.

Arquitectura lógica del registro de transacciones

El registro de transacciones de SQL Server funciona desde el punto de vista
lógico como si fuese una cadena de entradas de registro. Cada entrada del
registro está identificada por un número de flujo de registro (LSN, Log
Sequence Number). Las nuevas entradas del registro se escriben al final lógico
del registro con un LSN mayor que el de las entradas anteriores. Las entradas
del registro se almacenan en la secuencia en la que se crean. Cada entrada del
registro contiene el Id. de la transacción a la que pertenece. Por cada
transacción, las entradas del registro asociadas a dicha transacción se vinculan
individualmente en una cadena con punteros hacia atrás, para acelerar así la
reversión de la transacción.

Los registros de modificaciones de datos registran la operación lógica llevada a

cabo o las imágenes anterior y posterior de los datos modificados. La imagen
anterior es una copia de los datos antes de llevar a cabo la operación; la imagen
posterior es una copia de los datos después de haber realizado la operación.

Los pasos para recuperar una operación dependen del tipo de registro:

 Registro de la operación lógica

o Para poner al día la operación lógica, se vuelve a ejecutar la
operación.
 o Para revertir la operación lógica, se ejecuta la operación lógica
inversa.
 Registro de las imágenes anterior y posterior
o Para poner al día la operación, se aplica la imagen posterior.
o Para revertir la operación, se aplica la imagen anterior.

En el registro de transacciones se registran muchos tipos de operaciones. Entre

las operaciones se incluyen:

 El inicio y el final de cada transacción.

 Todas las modificaciones de los datos (inserción, actualización y
eliminación). Esto incluye las modificaciones de las tablas, incluidas las
tablas del sistema, hechas por procedimientos almacenados del sistema o
por instrucciones del lenguaje de definición de datos (DDL).
 Las asignaciones o cancelaciones de asignación de páginas y extensiones.
 La creación o eliminación de una tabla o un índice.

También se registran las operaciones de reversión. Cada transacción reserva

espacio en el registro de transacciones para asegurarse de que existe suficiente
espacio de registro para admitir una reversión provocada por una instrucción de
reversión explícita o cuando se produce un error. La cantidad de espacio
reservado depende de las operaciones realizadas en la transacción, pero
normalmente equivale a la cantidad de espacio empleado para registrar cada
operación. Este espacio reservado se libera cuando se completa la transacción.

La sección del archivo de registro a partir de la primera entrada de registro que

debe estar presente para una reversión correcta en toda la base de datos hasta
la última entrada de registro escrita se denomina parte activa del registro
o registro activo. Esta es la sección del registro necesaria para una recuperación
completa de la base de datos. No se puede truncar ninguna parte del registro
activo. El número de secuencia de registro (LSN) de este primer registro se
denomina Número de secuencia de registro de recuperación mínimo
(MinLSN) .

Arquitectura física del registro 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. Cada base de datos debe tener al menos un archivo
de registro.
Motor de base de datos de SQL Server segmenta cada archivo de registro físico
internamente en una serie de archivos de registro virtuales (VLF). 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.

 Nota

La creación de archivos de registro virtual (VLF) sigue este método:

 Si el siguiente crecimiento es inferior a 1/8 del tamaño físico actual del

registro, cree 1 VLF que cubra el tamaño del crecimiento (a partir de SQL
Server 2014 (12.x)).
 Si el siguiente crecimiento es superior a 1/8 del tamaño actual del
registro, use el método para versiones anteriores a 2014:
o Si el crecimiento es inferior a 64 MB, cree 4 VLF que cubran el
tamaño del crecimiento (p. ej., en el caso de un crecimiento de 1 MB,
cree 4 VLF de 256 KB).
o Si el crecimiento oscila entre 64 MB y 1 GB, cree 8 VLF que cubran
el tamaño del crecimiento (p. ej., en el caso de un crecimiento de 512
MB, cree 8 VLF de 64 MB).
o Si el crecimiento es superior a 1 GB, cree 16 VLF que cubran el
tamaño del crecimiento (p. ej., en el caso de un crecimiento de 8 GB,
cree 16 VLF de 512 MB).

Si los archivos de registro crecen hasta un tamaño grande en muchos

incrementos pequeños, tendrán numerosos 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. Por el contrario, si los
archivos de registro están establecidos en un tamaño grande con pocos o solo
un incremento, tendrán muy pocos archivos de registro virtuales muy
grandes. Para obtener más información sobre la estimación correcta de la
configuración de tamaño requerido y crecimiento automático de un registro
de transacción, consulte la sección Recomendaciones de Administrar el tamaño
del archivo de registro de transacciones.

Se recomienda que los archivos de registro se definan con un valor size cercano

al tamaño final necesario, con los incrementos requeridos para conseguir la
distribución de VLF óptima, y que tengan también un valor
de growth_increment relativamente alto. Vea la siguiente sugerencia para
determinar la distribución de VLF óptima para el tamaño del registro de
transacciones actual.

 El valor size, establecido por el argumento SIZE de ALTER DATABASE, es el

tamaño inicial del archivo de registro.
 El valor growth_increment (también conocido como el valor de
crecimiento automático), establecido por el argumento FILEGROWTH de ALTER
DATABASE, es la cantidad de espacio que se agrega al archivo cada vez que
se necesita más espacio.

Para obtener más información sobre los argumentos FILEGROWTH y SIZE de ALTER

DATABASE, vea Opciones File y Filegroup de ALTER DATABASE (Transact-SQL).

 Sugerencia

Para determinar la distribución óptima de VLF para el tamaño de registro de

transacciones actual de todas las bases de datos en una instancia determinada,
así como los incrementos de tamaño necesarios para conseguir el tamaño
requerido, consulte este script.

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
VLF. 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 flujo de registro de recuperación mínimo
(MinLSN). MinLSN es el número de flujo 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
el parámetro growth_increment y las nuevas entradas del registro se
escriben en la extensión. Para obtener más información sobre la
opción FILEGROWTH, vea Opciones File y Filegroup de 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. Para obtener
más información, consulte Solucionar problemas de un registro de
transacciones lleno.

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.

 Importante

Para obtener más información sobre la administración de tamaño del registro

de transacciones, vea Administrar el tamaño del archivo de registro de
transacciones.

Truncamiento del registro

El truncamiento del registro es esencial para evitar que se llene. El truncamiento

del registro elimina los archivos de registro virtuales inactivos del registro de
transacciones lógico de una base de datos de SQL Server , liberando espacio en
el registro lógico para que lo reutilice el registro de transacciones físico. Si no se
truncara nunca un registro de transacciones, acabaría ocupando todo el espacio
de disco asignado a sus archivo de registro físicos. Sin embargo, para que se
pueda truncar el registro, se debe realizar primero una operación de punto de
comprobación. Un punto de comprobación escribe en el disco las páginas
modificadas en memoria actuales (denominadas páginas desfasadas) y la
información del registro de transacciones de la memoria. Cuando se lleva a
cabo el punto de comprobación, la parte inactiva del registro de transacciones
se marca como reutilizable. A partir de ese momento, se puede liberar la parte
inactiva mediante el truncamiento del registro. Para obtener más información
sobre los puntos de comprobación, consulte Puntos de comprobación de base
de datos (SQL Server).

En la siguiente ilustración se muestra un registro de transacciones antes y

después del truncamiento. En la primera ilustración se muestra un registro de
transacciones que no se ha truncado nunca. El registro lógico tiene actualmente
cuatro archivos de registro virtuales en uso. El registro lógico comienza al
principio del primer archivo de registro virtual y finaliza en el registro virtual
4. El registro de MinLSN está en el registro virtual 3. Los registros virtuales 1 y 2
solo contienen entradas de registro inactivas. Estas entradas pueden
truncarse. El registro virtual 5 no se utiliza aún y no forma parte del registro
lógico actual.

En la segunda ilustración se muestra el registro después del truncamiento. Se

han liberado los registros virtuales 1 y 2 para su reutilización. El registro lógico
comienza ahora al principio del registro virtual 3. El registro virtual 5 no se
utiliza aún y no forma parte del registro lógico actual.

El truncamiento del registro se produce automáticamente después de los

eventos siguientes, excepto cuando se retrasa por alguna razón:

 En el modelo de recuperación simple, después de un punto de

comprobación.
 Bajo el modelo de recuperación completa o el modelo de recuperación
optimizado para cargas masivas de registros, después de una copia de
 seguridad del registro, si un punto de comprobación ha producirse desde
la copia de seguridad anterior.

El truncamiento del registro se puede retrasar por diferentes factores. En caso

de un retraso largo en el truncamiento del registro, el registro de transacciones
se puede llenar. Para obtener información, vea Factores que pueden ralentizar el
truncamiento del registro y Solucionar problemas de un registro de
transacciones lleno (Error 9002 de SQL Server).

Registro de transacciones de escritura anticipada

En esta sección se describe el rol que desempeña el registro de transacciones de
escritura anticipada en la grabación de modificaciones de datos en disco. SQL
Server usa un algoritmo de registro de escritura previa (WAL), lo cual garantiza
que no se escriba ninguna modificación de datos en el disco antes de escribir en
él la entrada de registro asociada. Así se mantienen las propiedades ACID para
una transacción.

Para entender cómo funciona el registro de escritura anticipada, es importante

saber cómo se escriben los datos modificados en el disco. SQL Server mantiene
una caché del búfer que lee las páginas de datos cuando estos deben
recuperarse. Cuando se modifica una página en la caché del búfer, no se vuelve
a escribir inmediatamente en el disco; en su lugar, la página se marca
como desfasada. Una página de datos puede tener más de una escritura lógica
antes de que se escriba físicamente en el disco. Para cada escritura lógica, se
inserta una entrada del registro de transacciones en la caché del registro que
registra la modificación. Las entradas del registro se tienen que escribir en el
disco antes de que la página desfasada asociada se quite de la caché del búfer y
se escriba en el disco. El proceso de punto de comprobación examina
periódicamente la caché del búfer en busca de búferes con páginas de una base
de datos especificada y escribe todas las páginas desfasadas en el disco. Los
puntos de comprobación permiten ahorrar tiempo en una recuperación
posterior al crear un punto en el que se garantiza que todas las páginas
desfasadas se hayan escrito en el disco.

A la escritura en el disco de una página de datos modificada desde la caché del

búfer se le llama vaciar la página. SQL Server tiene una lógica que evita que una
página desfasada se vacíe antes de que se escriba la entrada del registro
asociada. Las entradas de registro se escriben en el disco cuando se vacían los
búferes de registro. Esto ocurre siempre que se confirma una transacción o se
llenan los búferes de registro.

Copias de seguridad de registros de transacciones

En esta sección se presentan conceptos acerca de cómo realizar copias de
seguridad y restaurar (aplicar) registros de transacciones. En los modelos de
recuperación completa y de recuperación optimizada para cargas masivas de
registros, es necesario realizar copias de seguridad periódicas de los registros
de transacciones (copias de seguridad de registros) para recuperar datos. Puede
realizar una copia de seguridad del registro mientras se está ejecutando
cualquier copia de seguridad completa. Para obtener más información sobre
modelos de recuperación, consulte Realizar copias de seguridad y restaurar
bases de datos de SQL Server.

Antes de crear la primera copia de seguridad de registros, debe crear una copia
de seguridad completa, como una copia de seguridad de la base de datos o la
primera de un conjunto completo de copias de seguridad de archivos. La
restauración de una base de datos utilizando únicamente copias de seguridad
de archivos puede llegar a ser un proceso complejo. Por lo tanto, es
recomendable que comience con una copia de seguridad de la base de datos
completa si es posible. Posteriormente, será necesario realizar copias de
seguridad del registro de transacciones con regularidad. De esta forma, no solo
se minimiza el riesgo de pérdida de trabajo, sino que también se permite el
truncamiento del registro de transacciones. Normalmente, el registro de
transacciones se trunca tras cada copia de seguridad de registros convencional.

 Importante

Es aconsejable realizar copias de seguridad de registros suficientemente

regulares para ajustarse a los requisitos de su empresa, específicamente a la
tolerancia a la pérdida de trabajo que un almacenamiento de registro dañada
podría provocar. La frecuencia adecuada para realizar copias de seguridad de
registros varía en función de la tolerancia al riesgo de pérdida de trabajo y, por
otra parte, de la cantidad de copias de seguridad de registros que puede
almacenar, administrar y, potencialmente, restaurar. Tenga en cuenta
los RTO y RPO necesarios al implementar la estrategia de recuperación,
específicamente el ritmo de realización de copias de seguridad de registros. Una
copia de seguridad de registros cada 15 ó 30 minutos puede ser suficiente. Si su
empresa necesita minimizar el riesgo de pérdida de trabajo, piense en la
posibilidad de realizar copias de seguridad de registros más frecuentemente. La
existencia de copias de seguridad más frecuentes de los registros tiene la
ventaja añadida de aumentar la frecuencia de truncamiento del registro, lo que
genera archivos de registro menores.

 Importante

Para limitar el número de copias de seguridad del registro que necesita

restaurar, es esencial que realice una copia de seguridad de sus datos
periódicamente. Por ejemplo, podría programar una copia de seguridad
completa de la base de datos cada semana y copias de seguridad diferenciales
de la base de datos a diario.
Una vez más, tenga en cuenta los RTO y RPO necesarios al implementar la
estrategia de recuperación, específicamente el ritmo de realización de copias de
seguridad de base de datos completas y diferenciales.

Para obtener más información sobre las copias de seguridad del registro de
transacciones, vea Copias de seguridad del registro de transacciones (SQL
Server).

La cadena de registros

Una secuencia continua de copias de seguridad de registros se

denomina cadena de registros. Una cadena de registros empieza con una copia
de seguridad completa de la base de datos. Normalmente, una cadena de
registro nueva solo empieza cuando se realiza la primera copia de seguridad de
la base de datos o después de que se cambie del modelo de recuperación
simple al modelo de recuperación completa o al modelo de recuperación
optimizado para cargas masivas de registros. A menos que se elija sobrescribir
los conjuntos de copia de seguridad existentes al crear una copia de seguridad
completa de la base de datos, la cadena de registros existente permanece
intacta. Con la cadena de registros intacta, se puede restaurar la base de datos a
partir de cualquier copia de seguridad completa de la base de datos del
conjunto de medios, seguida de todas las copias de seguridad de los registros
subsiguientes hasta el punto de recuperación. El punto de recuperación puede
ser el final de la última copia de seguridad de registros o un punto de
recuperación concreto de cualquiera de las copias de seguridad de
registros. Para obtener más información, consulte Copias de seguridad de
registros de transacciones (SQL Server).

Para restaurar una base de datos al momento del error, es preciso que la cadena
de registros esté intacta. De esta forma, es necesario que una secuencia
ininterrumpida de las copias de seguridad del registro de transacciones se
extienda hasta el momento del error. El lugar en el que esta secuencia de
registros debe comenzar depende del tipo de copias de seguridad de datos que
esté restaurando: de base de datos, parcial o de archivos. En las copias de
seguridad de base de datos o parciales, la secuencia de copias de seguridad de
registros debe extenderse desde el final de la copia de seguridad de base de
datos o parcial. En un conjunto de copia de seguridad de archivos, la secuencia
de copias de seguridad de registros debe comenzar desde el principio del
conjunto completo de copias de seguridad de archivos. Para obtener más
información, vea Aplicar copias de seguridad del registro de transacciones (SQL
Server).
Restaurar copias de seguridad de registros

Al restaurar una copia de seguridad de registros se ponen al día los cambios

que se registraron en el registro de transacciones para volver a crear el estado
exacto de la base de datos en el momento en que se inició la operación de
copia de seguridad de registros. Al restaurar una base de datos, será necesario
restaurar las copias de seguridad de registros creadas tras la copia de seguridad
de la base de datos completa que esté restaurando o al principio de la primera
copia de seguridad de archivos que esté restaurando. Normalmente, se debe
restaurar una serie de copias de seguridad de registros hasta llegar al punto de
recuperación después de haber restaurado la copia de seguridad de los datos o
la copia de seguridad diferencial más recientes. A continuación, se realiza la
recuperación de la base de datos. De esta manera, todas las transacciones que
estaban incompletas cuando comenzó la recuperación se revertirán y la base de
datos se conectará. Una vez recuperada la base de datos, ya no es posible
restaurar más copias de seguridad. Para obtener más información,
consulte Aplicar copias de seguridad del registro de transacciones (SQL Server).

Puntos de comprobación y la parte activa del

registro
Los puntos de comprobación vacían las páginas de datos desfasadas en la
memoria caché del búfer de la base de datos actual en el disco. De este modo,
se minimiza la parte activa del registro que se debe procesar durante una
recuperación completa de una base de datos. Durante una recuperación
completa, se llevan a cabo los siguientes tipos de acciones:

 Se ponen al día los registros de modificaciones que no se vaciaron en el

disco antes de detenerse el sistema.
 Se revierten todas las modificaciones asociadas a transacciones
incompletas, como las transacciones para las que no hay entradas
COMMIT o ROLLBACK en el registro.
Funcionamiento de los puntos de comprobación

Un punto de comprobación realiza los procesos siguientes en la base de datos:

 Escribe en el archivo de registro una entrada que marca el inicio del

punto de comprobación.
 Guarda información registrada para el punto de comprobación en una
cadena de entradas de registro de puntos de comprobación.

Una parte de la información registrada en el punto de comprobación es el

número de flujo de registro (LSN) de la primera entrada del registro que
 debe estar presente para una reversión correcta de toda la base de
datos. Este LSN se denomina LSN de recuperación mínimo (MinLSN). El
MinLSN es el mínimo de:

o El LSN del inicio del punto de comprobación

o El LSN del inicio de la transacción activa más antigua
o El LSN del inicio de la transacción de replicación más antigua que
aún no se ha entregado a la base de datos de distribución

Los registros del punto de comprobación también contienen una lista de

las transacciones activas que han modificado la base de datos.

 Si la base de datos utiliza el modelo de recuperación simple, marca para

su reutilización el espacio que se encuentra antes del MinLSN.
 Escribe en el disco todas las páginas de datos y de registro desfasadas.
 Escribe en el archivo de registro un registro que marca el final del punto
de comprobación.
 Escribe el LSN del inicio de esta cadena en la página de arranque de la
base de datos.

Actividades que provocan un punto de comprobación

Los puntos de comprobación pueden darse en las situaciones siguientes:

 Se ejecuta explícitamente una instrucción CHECKPOINT. Se produce un

punto de comprobación en la base de datos actual para la conexión.
 Se realiza una operación registrada al mínimo en la base de datos; por
ejemplo, se realiza una operación de copia masiva en una base de datos
que utiliza el modelo de recuperación optimizado para cargas masivas de
registros.
 Se han agregado o eliminado archivos de base de datos mediante ALTER
DATABASE.
 Se detiene una instancia de SQL Server mediante una instrucción
SHUTDOWN o deteniendo el servicio SQL Server (MSSQLSERVER). Las dos
acciones insertan un punto de comprobación en cada base de datos de la
instancia de SQL Server.
 Una instancia de SQL Server genera periódicamente puntos de
comprobación de manera automática en cada base de datos para reducir
el tiempo que tardará la instancia en recuperar la base de datos.
 Se realiza una copia de seguridad de la base de datos.
 Se realiza una actividad que requiere cerrar la base de datos. Por
ejemplo, el valor de AUTO_CLOSE es ON y se ha cerrado la última
conexión de usuario a la base de datos, o bien se realiza una modificación
de una opción de la base de datos que requiere reiniciarla.
Puntos de comprobación automáticos

El motor de base de datos de SQL Server genera puntos de comprobación

automáticos. El intervalo entre puntos de comprobación automáticos se basa en
el espacio del registro utilizado y en el tiempo transcurrido desde el último
punto de comprobación. El intervalo de tiempo entre los puntos de
comprobación automáticos puede ser muy variable y largo si se realizan pocas
modificaciones en la base de datos. Los puntos de comprobación automáticos
también se pueden producir con frecuencia si se modifican muchos datos.

El intervalo entre puntos de comprobación automáticos para todas las bases de

datos de una instancia de servidor se calcula a partir de la opción de
configuración del servidor recovery interval . Esta opción especifica el máximo
de tiempo que el motor de base de datos debe usar para recuperar una base de
datos al reiniciar el sistema. El motor de base de datos calcula cuántas entradas
de registro puede procesar en el intervalo de recuperación durante una
operación de recuperación.

El intervalo entre los puntos de comprobación automáticos depende también

del modelo de recuperación:

 Si la base de datos usa el modelo de recuperación completa o el modelo

de recuperación optimizado para cargas masivas de registros, se generará
un punto de comprobación automático cuando el número de entradas del
registro alcance el número que el motor de base de datos estima que
puede procesar durante el tiempo especificado en la opción de intervalo
de recuperación.
 Si la base de datos utiliza el modelo de recuperación simple, se generará
un punto de comprobación automático cuando el número de registros
alcance el menor de estos dos valores:
o El registro está ocupado en un 70 por ciento.
o El número de entradas de registro alcanza el número que el motor
de base de datos calcula que puede procesar en el periodo especificado
en la opción de intervalo de recuperación.

Para más información sobre la configuración del intervalo de recuperación,

consulte Establecer la opción de configuración del servidor Intervalo de
recuperación.

 Sugerencia

La opción de configuración avanzada -k de SQL Server permite a un

administrador de base de datos limitar el comportamiento de E/S de los puntos
de comprobación según el rendimiento de E/S para algunos tipos de puntos de
comprobación. La opción de configuración -k es válida para los puntos de
comprobación y para cualquier punto de comprobación sin limitar.

Los puntos de comprobación automáticos truncan la parte no utilizada del

registro de transacciones si la base de datos utiliza el modelo de recuperación
simple. No obstante, el registro no se trunca mediante puntos de comprobación
automáticos si la base de datos utiliza el modelo de recuperación completa o el
modelo optimizado para cargas masivas de registros. Para obtener más
información, consulte El registro de transacciones.

Ahora la instrucción CHECKPOINT ofrece un argumento checkpoint_duration

opcional que especifica en segundos el tiempo necesario para que finalicen los
puntos de comprobación. Para obtener más información,
consulte CHECKPOINT.

registro activo

La parte del archivo de registro desde el MinLSN hasta el último registro escrito
se denomina parte activa del registro o registro activo. Se trata de la sección del
registro necesaria para una recuperación completa de la base de datos. No se
puede truncar ninguna parte del registro activo. Los truncamientos del registro
se deben realizar en las partes del registro anteriores al MinLSN.

En la ilustración siguiente se muestra una versión simplificada del final de un

registro de transacciones con dos transacciones activas. Los registros de punto
de comprobación se han compactado en un solo registro.

LSN 148 es la última entrada del registro de transacciones. En el momento en

que se procesó el registro del punto de comprobación en LSN 147, Tran 1 se
había confirmado y Tran 2 era la única transacción activa. Esto hace que la
primera entrada del registro para Tran 2 sea la entrada de transacción activa
más antigua del registro en el momento del último punto de
comprobación. Esto convierte al registro de inicio del registro de transacciones
para Tran 2, LSN 142, en el MinLSN.

Transacciones de larga ejecución

El registro activo debe incluir cada una de las partes de todas las transacciones
no confirmadas. Una aplicación que inicia una transacción y no la confirma o la
revierte impide que el motor de base de datos avance hacia el valor de
MinLSN. Esto puede causar dos tipos de problemas:

 Si se cierra el sistema después de que la transacción haya realizado un

gran número de modificaciones no confirmadas, la fase de recuperación
del siguiente reinicio puede durar bastante más que el tiempo
especificado en la opción recovery interval .
 Puede que el tamaño del registro aumente de forma considerable,
porque no se puede truncar pasado el MinLSN. Esto ocurre incluso si la
base de datos utiliza el modelo de recuperación simple, donde el registro
de transacciones se suele truncar en cada punto de comprobación
automático.
Transacciones de replicación

El Agente de registro del LOG supervisa el registro de transacciones de cada

base de datos configurada para la replicación transaccional y copia las
transacciones marcadas para la replicación desde el registro de transacciones a
la base de datos de distribución. El registro activo debe contener todas las
transacciones marcadas para la replicación, pero que aún no se han entregado a
la base de datos de distribución. Si estas transacciones no se replican
puntualmente, pueden evitar el truncamiento del registro. Para obtener más
información, consulte Replicación transaccional.
Controlar la durabilidad de las
transacciones
 15/09/2016
 Tiempo de lectura: 10 minutos

SE APLICA A:  SQL Server  Azure SQL Database  Azure SQL Data
Warehouse  Almacenamiento de datos paralelos

Las confirmaciones de transacciones deSQL Server pueden ser totalmente

durables (el valor predeterminado de SQL Server ) o durables diferidas
(conocidas también como confirmaciones diferidas).

Las confirmaciones de transacciones totalmente durables son sincrónicas y

notifican una instrucción COMMIT como correcta para devolver el control al
cliente únicamente tras escribir en disco los registros de la transacción. Las
confirmaciones de transacciones durables diferidas son asincrónicas y notifican
una instrucción COMMIT como correcta antes de escribir en disco los registros
de la transacción. Para que una transacción sea durable, es necesario escribir las
entradas del registro de transacciones en el disco. Las transacciones durables
diferidas pasan a ser durables cuando las entradas del registro de transacciones
se vacían en el disco.

Este tema contiene información detallada sobre las transacciones durables

diferidas.

Durabilidad total frente a durabilidad diferida de

transacciones
Tanto la durabilidad total como la durabilidad diferida de transacciones tienen
sus ventajas y desventajas. Una aplicación puede tener una combinación de
transacciones totalmente durables y durables diferidas. Debe considerar
detenidamente las necesidades de la empresa y cómo encaja cada una de ellas
en esas necesidades.

Durabilidad total de transacciones

Las transacciones totalmente durables escriben el registro de transacciones en

el disco antes de devolver el control al cliente. Debe utilizar transacciones
totalmente durables cuando:
  El sistema no puede tolerar la pérdida de datos.
Vea la sección ¿Cuándo puedo perder datos? para obtener información
sobre cuándo puede perder algunos de los datos.
 El cuello de botella no se debe a la latencia de escritura en el registro de
transacciones.

La durabilidad diferida de transacciones reduce la latencia debida a operaciones

de E/S de registro al conservar los registros de transacciones en memoria y
escribir por lotes en el registro de transacciones, lo que requiere menos
operaciones de E/S. Las transacciones de perdurabilidad diferida reduce
potencialmente la contención de las E/S del registro, de forma que se reducen
las esperas en el sistema.

Garantías de la durabilidad total de transacciones

 Una vez que la transacción se confirma correctamente, los cambios que

realiza la transacción son visibles para las demás transacciones del
sistema. Para obtener más información sobre los niveles de aislamiento de
transacciones, vea SET TRANSACTION ISOLATION LEVEL (Transact-
SQL) o Transactions with Memory-Optimized Tables (Transacciones con
tablas con optimización para memoria).
 La durabilidad se garantiza en el momento de la confirmación. Las
entradas de registro correspondientes se guardan en el disco antes de que
la transacción se confirme correctamente y se devuelva el control al
cliente.

Durabilidad diferida de transacciones

La durabilidad diferida de las transacciones se realiza mediante escrituras

asincrónicas de registro en el disco. Las entradas del registro de transacciones
se conservan en un búfer y se escriben en el disco cuando el búfer se llena o
cuando se produce un evento de vaciado del búfer. La durabilidad diferida de
las transacciones reduce tanto la latencia como la contención en el sistema
porque:

 El procesamiento de confirmación de transacciones no espera a que

finalicen las E/S del registro y a devolver el control al cliente.
 Resulta menos probable que las transacciones simultáneas compitan por
E/S del registro; en su lugar, el búfer de registro puede vaciarse en el disco
en fragmentos mayores, lo cual reduce la contención y aumenta el
rendimiento.

 Nota
 Es posible que siga habiendo contención de E/S si hay un alto grado de
simultaneidad, especialmente si el búfer de registro se llena más
rápidamente que se vacía.

Cuándo utilizar durabilidad diferida de transacciones

He aquí algunos casos en los que puede ser beneficioso usar la durabilidad
diferida de transacciones:

Puede tolerar alguna pérdida de datos.

Si puede tolerar cierta pérdida de datos, por ejemplo cuando los registros
individuales no son críticos siempre y cuando tenga la mayoría de los datos,
puede resultar útil usar la durabilidad diferida. Si no puede tolerar la pérdida de
datos, no utilice la durabilidad diferida de transacciones.

Experimenta cuellos de botella en la escritura de registros de

transacciones.
Si los problemas de rendimiento se deben a la latencia en la escritura de
registros de transacciones, seguramente la aplicación se beneficiará de utilizar la
durabilidad diferida de transacciones.

Las cargas de trabajo conllevan un alto índice de contención.

Si el sistema tiene cargas de trabajo con un alto índice de contención, se
perderá mucho tiempo esperando a que se liberen los bloqueos. La durabilidad
diferida de transacciones reduce el tiempo de confirmación y, por tanto, libera
los bloqueos con mayor rapidez, lo que redunda en un mayor rendimiento.

Garantías de la durabilidad diferida de transacciones

 Una vez que la transacción se confirma correctamente, los cambios que

realiza la transacción son visibles para las demás transacciones del sistema.
 La durabilidad de las transacciones solo se garantiza después de vaciar
en el disco el registro de transacciones en memoria. El registro de
transacciones en memoria se vacía en el disco cuando:
o Una transacción totalmente durable de la misma base de datos
efectúa un cambio en la base de datos y se confirma correctamente.
o El usuario ejecuta el procedimiento almacenado del
sistema sp_flush_log correctamente.

Si una transacción totalmente durable o sp_flush_log se confirma

correctamente, se garantiza que todas las transacciones de durabilidad
diferida que se hubieran confirmado anteriormente sean durables.
 o SQL Server intenta vaciar el registro en el disco en función de la
generación de registros y del tiempo, incluso si la durabilidad de todas
las transacciones es diferida. Esto suele realizarse correctamente si el
dispositivo de E/S está al día. Sin embargo, SQL Server no proporciona
garantías de durabilidad sólidas que no sean las transacciones durables
y sp_flush_log.

Cómo controlar la durabilidad de las

transacciones
Control de nivel de base de datos

Como administrador de la base de datos (DBA), con la instrucción siguiente

puede controlar si los usuarios pueden usar transacciones de durabilidad
diferida en una base de datos. Debe establecer la configuración de durabilidad
diferida con ALTER DATABASE.

SQLCopiar
ALTER DATABASE ... SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }

DISABLED
[valor predeterminado] Con esta configuración, todas las transacciones que se
confirman en la base de datos son totalmente durables, independientemente
del nivel de confirmación (DELAYED_DURABILITY= [ON | OFF]). No hay
necesidad de modificar y recompilar el procedimiento almacenado. De esta
forma, puede asegurarse de que la durabilidad diferida nunca ponga datos en
peligro.

ALLOWED
Con esta configuración, la durabilidad de cada transacción se determina en el
nivel de transacción: DELAYED_DURABILITY = { OFF | ON }. Vea Control de nivel
de bloque ATOMIC: procedimientos almacenados compilados de forma
nativa y Control de nivel COMMIT: Transact-SQL para obtener más información.

FORCED
Con esta configuración, cada transacción que se confirma en la base de datos es
durable diferida. Independientemente de que la transacción especifique que es
totalmente durable (DELAYED_DURABILITY = OFF) o no haga especificación
alguna, la transacción es durable diferida. Esta configuración resulta útil cuando
la durabilidad diferida es adecuada para una base de datos y no desea cambiar
ningún código de aplicación.

Control de nivel de bloque ATOMIC: procedimientos almacenados

compilados de forma nativa
El código siguiente va en el interior del bloque ATOMIC.

SQLCopiar
DELAYED_DURABILITY = { OFF | ON }

OFF
[valor predeterminado] La transacción es totalmente durable, salvo que la
opción de base de datos DELAYED_DURABLITY = FORCED esté activa, en cuyo
caso la instrucción COMMIT será asíncrona y por tanto durable
diferida. Consulte Database level control para obtener más información.

ON
La transacción es durable diferida, salvo que la opción de base de datos
DELAYED_DURABLITY = DISABLED esté activa, en cuyo caso la instrucción
COMMIT será síncrona y por tanto totalmente durable. Consulte Database level
control para obtener más información.

Código de ejemplo

SQLCopiar
CREATE PROCEDURE <procedureName> ...
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS BEGIN ATOMIC WITH
(
DELAYED_DURABILITY = ON,
TRANSACTION ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = N'English'
...
)
END
Tabla 1: Durabilidad en bloques ATOMIC
Opción de durabilidad de Transacción en proceso (totalmente durable o durable
bloque ATOMIC Ninguna transacción existente diferida)

DELAYED_DURABILITY El bloque ATOMIC inicia una nueva El bloque ATOMIC crea un punto de retorno en la transacción
= OFF transacción totalmente durable. existente y después inicia la nueva transacción.

DELAYED_DURABILITY El bloque ATOMIC inicia una nueva El bloque ATOMIC crea un punto de retorno en la transacción
= ON transacción durable diferida. existente y después inicia la nueva transacción.
Control de nivel COMMIT -Transact-SQL

La sintaxis de COMMIT se ha ampliado para que pueda forzar la durabilidad

diferida de transacciones. Si DELAYED_DURABILITY es DISABLED o FORCED en el
nivel de base de datos (vea más arriba), esta opción de COMMIT se omite.

SQLCopiar
COMMIT [ { TRAN | TRANSACTION } ] [ transaction_name |
@tran_name_variable ] ] [ WITH ( DELAYED_DURABILITY = { OFF | ON } ) ]

OFF
[valor predeterminado] La instrucción COMMIT de la transacción es totalmente
durable, salvo que la opción de base de datos DELAYED_DURABLITY = FORCED
esté activa, en cuyo caso la instrucción COMMIT será asincrónica y por tanto
durable diferida. Consulte Database level control para obtener más información.

ON
La instrucción COMMIT de la transacción es durable diferida, salvo que la
opción de base de datos DELAYED_DURABLITY = DISABLED esté activa, en cuyo
caso la instrucción COMMIT será sincrónica y por tanto totalmente
durable. Consulte Database level control para obtener más información.

Resumen de opciones y sus interacciones

En esta tabla se resumen las interacciones entre las configuraciones de

durabilidad diferida de nivel de base de datos y las configuraciones de nivel de
confirmación. Las configuraciones de nivel de base de datos siempre tienen
prioridad sobre las configuraciones de nivel de confirmación.
Valor
COMMIT/Valor de DELAYED_DURAB DELAYED_DURAB DELAYED_DURAB
base de datos ILITY = DISABLED ILITY = ALLOWED ILITY = FORCED

DELAYED_DURAB La transacción es La transacción es La transacción es de

ILITY = totalmente durable. totalmente durable. durabilidad diferida.
OFF Transacciones de
nivel de base de datos.

DELAYED_DURAB La transacción es La transacción es de La transacción es de

ILITY = totalmente durable. durabilidad diferida. durabilidad diferida.
ON Transacciones de
nivel de base de datos.

DELAYED_DURAB La transacción es La transacción es La transacción es

ILITY = totalmente durable. totalmente durable. totalmente durable.
OFF Transacciones
entre bases de datos o
distribuidas.

DELAYED_DURAB La transacción es La transacción es La transacción es

ILITY = totalmente durable. totalmente durable. totalmente durable.
ON Transacciones
entre bases de datos o
Valor
COMMIT/Valor de DELAYED_DURAB DELAYED_DURAB DELAYED_DURAB
base de datos ILITY = DISABLED ILITY = ALLOWED ILITY = FORCED

distribuidas.
Cómo forzar un vaciado del registro de
transacciones
Existen dos formas de forzar el vaciado en el disco del registro de transacciones.

 Ejecutar todas las transacciones totalmente durables que modifican la

misma base de datos. De esta forma se fuerza un vaciado en disco de las
entradas de registro de todas las transacciones de durabilidad diferida
confirmadas previamente.
 Ejecutar el procedimiento almacenado del sistema sp_flush_log. Este
procedimiento fuerza un vaciado en disco de las entradas de registro de
todas las transacciones de durabilidad diferida confirmadas
previamente. Para obtener más información, vea sys.sp_flush_log
(Transact-SQL).

Durabilidad diferida y otras características de SQL

Server
Seguimiento de cambios y captura de datos modificados
Todas las transacciones con seguimiento de cambios son totalmente
durables. Las transacciones tienen la propiedad de seguimiento de cambios si
realizan operaciones de escritura en tablas que se han habilitado para
seguimiento de cambios. No se admite el uso de durabilidad diferida para bases
de datos que usan captura de datos modificados (CDC).

Recuperación tras bloqueo

Se garantiza la coherencia, pero es posible que se pierdan algunas
modificaciones de las transacciones de durabilidad diferida que se habían
confirmado.

Transacciones entre bases de datos y DTC

Si una transacción es entre bases de datos o distribuida, es totalmente durable,
independientemente de cualquier configuración de confirmación de base de
datos o de transacción.

Grupos de disponibilidad AlwaysOn y creación de reflejo

Las transacciones de durabilidad diferida no garantizan la durabilidad del
primario ni de los secundarios. Tampoco garantizan ningún conocimiento sobre
la transacción en el secundario. Después de COMMIT, se devuelve el control al
cliente antes de que se reciba algún reconocimiento desde un elemento
secundario sincrónico. La replicación de réplicas secundarias continuará
produciéndose mientras tenga lugar el vacío en el disco del primario.

Agrupación en clústeres de conmutación por error

Es posible que se pierdan algunas escrituras de transacciones durables diferidas.

Replicación de transacciones
Las transacciones durables diferidas no son compatibles con la replicación
transaccional.

Trasvase de registros
Solo las transacciones que se han convertido en durables se incluyen en el
registro que se trasvasa.

Copia de seguridad de registros

Solo las transacciones que se han convertido en durables se incluyen en la copia
de seguridad.

¿Cuándo puedo perder datos?

Si implementa la durabilidad diferida en alguna de las tablas, verá que ciertas
condiciones pueden provocar la pérdida de datos. Si no puede tolerar una
pérdida de datos, no debería usar la durabilidad diferida en las tablas.

Catástrofes

En caso de catástrofe, como un bloqueo del servidor, perderá los datos de todas
las transacciones confirmadas que no se hayan guardado en el disco. Las
transacciones de durabilidad diferida se guardan en el disco siempre que se
ejecute una transacción totalmente durable respecto a una tabla (optimizada
para memoria durable o basada en disco) en la base de datos o cuando se llama
a sp_flush_log . Si está usando transacciones de durabilidad diferida, conviene
crear una tabla pequeña en la base de datos que podrá actualizar regularmente
o llamar de forma periódica a sp_flush_log para guardar todas las transacciones
confirmadas pendientes. El registro de transacciones también se vacía cada vez
que se llena, pero es difícil de predecir e imposible de controlar.

Cierre y reinicio deSQL Server

En lo que respecta a la durabilidad diferida, no hay ninguna diferencia entre el

cierre inesperado y el cierre/reinicio planeado de SQL Server. Al igual que en las
catástrofes, debe prever una pérdida de datos. En un cierre/reinicio planeado,
algunas transacciones que no se han escrito en el disco podrían, en primer
lugar, guardarse en el disco, pero no debería contar con ello. Tenga previsto sin
embargo que en un cierre/reinicio, bien se haya planeado o no, se pierden
datos al igual que en las catástrofes.
Administrar el tamaño del archivo de
registro de transacciones
 04/01/2018
 Tiempo de lectura: 6 minutos

SE APLICA A:  SQL Server  Azure SQL Database  Azure SQL Data
Warehouse  Almacenamiento de datos paralelos

En este tema se incluye información sobre cómo supervisar el tamaño de un

registro de transacciones de SQL Server, reducir el registro de transacciones,
agregar o ampliar un archivo de registro de transacciones, optimizar la tasa de
crecimiento del registro de transacciones tempdb y controlar el crecimiento de
un archivo de registro de transacciones.

Supervisión del uso del espacio del registro

Supervise el uso del espacio del registro
mediante sys.dm_db_log_space_usage. Este DMV devuelve información sobre la
cantidad de espacio del registro actualmente en uso e indica cuándo es
necesario el truncamiento del registro de transacciones.

Para obtener información sobre el tamaño actual del archivo de registro, su

tamaño máximo y la opción de crecimiento automático de este archivo, también
puede usar las columnas size, max_size y growth de ese archivo de registro
en sys.database_files.

 Importante

Evite la sobrecarga del disco del registro. Asegúrese de que el almacenamiento

del registro puede soportar la IOPS y los requisitos de latencia baja para la
carga de transacciones.

Reducir el tamaño del archivo de registro

Para reducir el tamaño físico de un archivo de registro físico, debe reducir el
archivo de registro. Esto es útil si sabe que un archivo de registro de
transacciones contiene espacio que no se ha utilizado. Puede reducir un archivo
de registro siempre que la base de datos esté en línea y haya al menos
un archivo de registro virtual (VLF) libre. En algunos casos, no será posible
reducir el registro hasta el siguiente truncamiento del registro.

 Nota
Los factores que mantienen activos los VLF por un periodo prolongado de
tiempo, como puede ser una transacción de ejecución prolongada, pueden
restringir la reducción del registro o incluso impedirla completamente. Para
obtener información, vea Factores que pueden ralentizar el truncamiento del
registro.

Con la reducción de un archivo de registro se quitan uno o varios VLF que no

contienen ninguna parte del registro lógico (es decir, los VLF inactivos). Cuando
se reduce un archivo de registro de transacciones, se quitan VLF inactivos del
final del archivo de registro para reducirlo aproximadamente al tamaño de
destino.

 Importante

Antes de reducir el registro de transacciones, tenga en cuenta los Factores que

pueden ralentizar el truncamiento del registro. Si se requiere el espacio de
almacenamiento de nuevo después de reducir un registro, el registro de
transacciones volverá a crecer y esto implicará una sobrecarga de rendimiento
durante las operaciones de ampliación de registro. Para obtener más
información, vea Recomendaciones en este tema.

Reducir un archivo de registro (sin reducir los archivos de base de datos)

 DBCC SHRINKFILE (Transact-SQL)

 Reducir un archivo

Supervisar los eventos de reducción de un archivo de registro

 Log File Auto Shrink Event Class.

Supervisar el espacio del registro

 sys.dm_db_log_space_usage (Transact-SQL)
 sys.database_files (Transact-SQL) (Vea las
columnas size, max_size y growth de los archivos de registro).

Agregar o ampliar un archivo de registro

Puede obtener espacio al ampliar el archivo de registro existente (si el espacio
en disco lo permite) o al agregar un archivo de registro a la base de datos,
normalmente en otro disco. Un archivo de registro de transacciones es
suficiente, a menos que se esté agotando el espacio del registro y que el
espacio en disco también se esté agotando en el volumen que contiene el
archivo de registro.
  Para agregar un archivo de registro a la base de datos, use la cláusula ADD
LOG FILE de la instrucción ALTER DATABASE. El hecho de agregar un archivo
de registro permite que crezca el existente.
 Para aumentar el archivo de registro, use la cláusula MODIFY FILE de la
instrucción ALTER DATABASE, especificando la sintaxis de SIZE y MAXSIZE. Para
obtener más información, vea Opciones File y Filegroup de ALTER
DATABASE (Transact-SQL).

Para obtener más información, vea Recomendaciones en este tema.

Optimizar el tamaño del registro de transacciones

tempdb
Al reiniciar una instancia del servidor se devuelve el tamaño del registro de
transacciones de la base de datos tempdb a su tamaño original, antes del
crecimiento automático. Esto puede reducir el rendimiento del registro de
transacciones de tempdb .

Para evitar esta sobrecarga, aumente el tamaño del registro de transacciones

de tempdb después de iniciar o reiniciar la instancia de servidor. Para obtener
más información, consulte tempdb Database.

Controlar el crecimiento de un archivo de registro

de transacciones
Use la instrucción Opciones File y Filegroup de ALTER DATABASE (Transact-
SQL) para administrar el crecimiento de un archivo de registro de
transacciones. Observe lo siguiente:

 Para cambiar el tamaño del archivo actual en unidades de KB, MB, GB y

TB, use la opción SIZE.
 Para cambiar el incremento de crecimiento, use la opción FILEGROWTH. El
valor 0 indica que el aumento automático se establece en OFF y no se
permite ningún espacio adicional.
 Para controlar el máximo el tamaño de un archivo de registro en
unidades de KB, MB, GB y TB, o establecer el crecimiento en UNLIMITED,
use la opción MAXSIZE.

Para obtener más información, vea Recomendaciones en este tema.

Recomendaciones
Estas son algunas recomendaciones generales referentes a los archivos de
registro de transacciones:

 El incremento de crecimiento automático del registro de transacciones,

según lo establecido por la opción FILEGROWTH, debe ser lo suficientemente
grande como para anticiparse a las necesidades de las transacciones de la
carga de trabajo. El incremento del crecimiento de un archivo de registro
debe ser lo suficientemente grande para evitar una expansión
frecuente. Un buen punto de referencia para ajustar correctamente el
tamaño de un registro de transacciones es supervisar la cantidad de
registro ocupada durante:
o El tiempo necesario para ejecutar una copia de seguridad
completa, porque no se pueden realizar copias de seguridad del
registro hasta que termine.
o El tiempo necesario para las operaciones de mantenimiento de
índice más grandes.
o El tiempo necesario para ejecutar el lote más grande de una base
de datos.
 Al establecer crecimiento automático para archivos de datos y de
registro mediante la opción FILEGROWTH, es recomendable establecerlo
en tamaño en lugar de en porcentaje. De esta forma, se permite un mejor
control en la proporción de crecimiento, ya que los porcentajes son una
unidad de medida sin límite de crecimiento.
o Tenga en cuenta que los registros de transacciones no pueden
aprovechar la inicialización instantánea de archivos, por lo que los
tiempos de crecimiento de registro extendido son especialmente
importantes.
o Como práctica recomendada, no establezca el valor de la
opción FILEGROWTH por encima de 1024 MB para registros de
transacciones. Los valores predeterminados de la opción FILEGROWTH son
los siguientes:
Versión Valores predeterminados

A partir de SQL Server 2016 (13.x) Datos: 64 MB. Archivos de registro:

64 MB.

A partir de SQL Server 2005 (9.x) Datos: 1 MB. Archivos de registro:

10 %.

Antes de SQL Server 2005 (9.x) Datos: 10 %. Archivos de registro:

10 %.
 Un aumento de crecimiento pequeño puede generar
demasiados VLF pequeños y puede reducir el rendimiento. Para
determinar la distribución óptima de VLF para el tamaño de registro de
transacciones actual de todas las bases de datos en una instancia
determinada, así como los incrementos de tamaño necesarios para
conseguir el tamaño requerido, consulte este script.
 Un aumento de crecimiento grande puede generar
demasiados VLF pequeños y grandes, y también puede afectar al
rendimiento. Para determinar la distribución óptima de VLF para el tamaño
de registro de transacciones actual de todas las bases de datos en una
instancia determinada, así como los incrementos de tamaño necesarios
para conseguir el tamaño requerido, consulte este script.
 Incluso con el crecimiento automático habilitado, puede recibir un
mensaje de que el registro de transacciones está lleno, si no puede crecer
lo suficientemente rápido para satisfacer las necesidades de la
consulta. Para obtener más información sobre cómo cambiar el aumento
del crecimiento, vea Opciones File y Filegroup de ALTER DATABASE
(Transact-SQL).
 Aunque tenga varios archivos de registro en una base de datos, el
rendimiento no mejorará, ya que los archivos de registro de transacciones
no usan el relleno proporcional, como los archivos de datos de un mismo
grupo de archivos.
 Puede configurar los archivos de registro para que se reduzcan
automáticamente. Esto no se recomienda y la propiedad de base de
datos auto_shrink está establecida en FALSE de manera
predeterminada. Si auto_shrink está establecida en TRUE, el proceso de
reducción automática solo reduce el tamaño de un archivo cuando más
del 25 % de su espacio está sin usar.
o El tamaño del archivo se reduce hasta un tamaño en el que solo el
25% del archivo corresponde al espacio sin utilizar o hasta el tamaño
original del archivo (el que sea mayor).
o Para obtener información sobre cómo cambiar la configuración de
la propiedad auto_shrink, vea Ver o cambiar las propiedades de una
base de datos y Opciones de ALTER DATABASE SET (Transact-SQL).