El registro de transacciones

Se aplica a:SQL Server

Todas las bases de datos de SQL Server tienen un registro de transacciones que registra 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. Si se produce un error del sistema, necesita este registro para devolver la base de datos a un estado coherente.

Advertencia

No elimine ni mueva este registro nunca, a menos que tenga pleno conocimiento de las consecuencias de hacerlo.

Para obtener información sobre la arquitectura física y lógica del registro de transacciones, consulte la guía de administración y arquitectura del registro de transacciones de SQL Server.

Sugerencia

Los puntos de control crean puntos correctos conocidos desde los que empezar a aplicar registros de transacciones durante la recuperación de la base de datos. Para obtener más información, consulte Puntos de comprobación de base de datos (SQL Server).

Operaciones compatibles con el registro de transacciones

El registro de transacciones permite las siguientes operaciones:

  • Recuperación de transacciones individuales.
  • Recuperación de todas las transacciones incompletas cuando se inicia SQL Server.
  • Puesta al día de una base de datos, un archivo, un grupo de archivos o una página restaurados hasta el momento exacto del error.
  • Compatibilidad con la replicación transaccional.
  • Compatibilidad con soluciones de alta disponibilidad y recuperación ante desastres: grupos de disponibilidad Always On, duplicación de base de datos y envío de registros.

Recuperación de transacciones individuales

Si una aplicación emite una instrucción ROLLBACK o si el motor de base de datos detecta un error, como la pérdida de comunicación con un cliente, se usan los registros para revertir todas las modificaciones efectuadas por una transacción incompleta.

Recuperación de todas las transacciones incompletas cuando se inicia SQL Server

Si un servidor produce errores, las bases de datos pueden quedar en un estado en que algunas modificaciones no han llegado a escribirse desde la caché del búfer a los archivos de datos; estos pueden contener modificaciones como resultado de transacciones incompletas. Cuando se inicia una instancia de SQL Server, se ejecuta la recuperación de todas las bases de datos. Todas las modificaciones del registro que no se hayan podido escribir en los archivos de datos se ponen al día. Las transacciones incompletas que se encuentren en el registro de transacciones se revierten para asegurar la integridad de la base de datos. Para obtener más información, vea Información general sobre restauración y recuperación (SQL Server).

Puesta al día de una base de datos, un archivo, un grupo de archivos o una página restaurados hasta el momento exacto del error

Después de una pérdida de hardware o un error de disco que afecten a los archivos de base de datos, ésta se puede restaurar al punto del error. En primer lugar, restaure la última copia de seguridad completa de base de datos y la última copia de seguridad diferencial de base de datos y, después, restaure la secuencia de copias de seguridad del registro de transacciones al punto del error.

Según restaura cada copia de seguridad del registro, el motor de base de datos vuelve a aplicar todas las modificaciones incluidas en el registro para poner al día todas las transacciones. Cuando se restaura la última copia de seguridad, el motor de base de datos usa la información del registro para revertir todas las transacciones no completadas hasta ese momento. Para obtener más información, vea Información general sobre restauración y recuperación (SQL Server).

Permitir la replicación transaccional

El Agente Lector de registros 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 del registro de transacciones en la base de datos de distribución. Para obtener más información, consulte Funcionamiento de la replicación transaccional.

Permitir las soluciones de alta disponibilidad y recuperación ante desastres

Las soluciones de servidor de reserva, los grupos de disponibilidad Always On, la duplicación de la base de datos y el envío de registros dependen en gran medida del registro de transacciones.

En un escenario de grupos de disponibilidad de Always On, cada actualización de una base de datos en la réplica principal se reproduce inmediatamente en las copias independientes de la base de datos de todas las réplicas secundarias. La réplica principal envía inmediatamente cada registro del log a las réplicas secundarias, que aplican los registros del log recibidos a las bases de datos de disponibilidad, haciendo avanzar continuamente el log. Para obtener más información, consulte Instancias de clúster de conmutación por error de Always On (SQL Server).

En un escenario de trasvase de registros, el servidor principal envía las copias de seguridad del registro de transacciones de la base de datos principal a uno o varios destinos. Los servidores secundarios restauran las copias de seguridad del registro en su base de datos secundaria local. Para más información, vea Acerca del trasvase de registros (SQL Server).

En un escenario de creación de reflejo de la base de datos, las actualizaciones de una base de datos (la principal) se reproducen inmediatamente en una copia completa e independiente de la base de datos (la base de datos reflejada). La instancia de servidor principal envía de forma inmediata los registros a la instancia del servidor reflejado, que los aplica a la base de datos reflejada, poniéndola al día de forma continua. Para obtener más información, vea Reflejo de la base de datos (SQL Server).

Características del registro de transacciones

Características del registro de transacciones del motor de base de datos de SQL Server:

  • El registro de transacciones se implementa como un archivo o un grupo de archivos separado en la base de datos. La caché de registros se administra independientemente de la caché del búfer para las páginas de datos. Esta separación da como resultado código sencillo, rápido y sólido dentro del motor de base de datos de SQL Server. Para obtener más información, consulte Arquitectura física del registro de transacciones.

  • El formato de los registros del log y de las páginas no está restringido a seguir el formato de las páginas de datos.

  • El registro de transacciones se puede implementar en varios archivos. Puede configurar los archivos para que se expandan automáticamente estableciendo el valor FILEGROWTH para el archivo de registro. Esta configuración reduce la posibilidad de quedarse sin espacio en el registro de transacciones, al mismo tiempo reduciendo la sobrecarga administrativa. Para obtener más información, vea ALTER DATABASE (Transact-SQL) opciones de archivo y grupo de archivos.

  • El mecanismo para volver a utilizar el espacio de los archivos de registro es rápido y tiene un efecto mínimo en el rendimiento de las transacciones.

Para obtener información sobre la arquitectura física y lógica del registro de transacciones, consulte la guía de administración y arquitectura del registro de transacciones de SQL Server.

Truncamiento del registro de transacciones

El truncamiento del registro libera el espacio en el archivo de registro para que lo pueda reutilizar el registro de transacciones. Debe truncar el registro de transacciones periódicamente para evitar que ocupe todo el espacio asignado. Varios factores pueden retrasar el truncamiento del registro, por lo que es importante supervisar su tamaño. Algunas operaciones se pueden registrar mínimamente para reducir su efecto en el tamaño del registro de transacciones.

El truncamiento del registro elimina los archivos de registro virtuales inactivos (VLFs) del registro de transacciones lógico de una base de datos de SQL Server, lo que libera espacio en el registro lógico para reutilizarlo el registro de transacciones físico. Si un registro de transacciones no se trunca nunca, acabará ocupando todo el espacio en disco asignado a los archivos de registro físicos.

Para evitar quedarse sin espacio, a menos que el truncamiento del registro se retrase por algún motivo, el truncamiento se produce automáticamente después de los eventos siguientes:

  • En el modelo de recuperación simple, después de un punto de control.

  • En el modelo de recuperación completa o en el modelo de recuperación optimizado para operaciones de carga masiva, si se ha realizado un punto de comprobación desde la copia de seguridad anterior, el truncamiento se realiza después de una copia de seguridad del registro (a menos que sea una copia de seguridad del registro de solo copia).

  • Cuando se crea por primera vez una base de datos que usa el modelo de recuperación completa, el registro de transacciones se reutiliza según sea necesario (similar a una base de datos mediante el modelo de recuperación simple), hasta el momento en que se crea una copia de seguridad completa de la base de datos.

Para obtener más información, consulte Factores que pueden retrasar el truncamiento del registro más adelante en este artículo.

El truncamiento del registro no reduce el tamaño del archivo de registro físico. Para reducir el tamaño físico de un archivo de registro, debe reducir el archivo de registro. Para obtener información sobre cómo reducir el tamaño de un archivo de registro físico, vea Administrar el tamaño del archivo de registro de transacciones. Sin embargo, tenga en cuenta factores que pueden retrasar el truncamiento del registro. Si el espacio de almacenamiento es necesario de nuevo después de una reducción del registro, el registro de transacciones volverá a crecer y, al hacerlo, introducirá una sobrecarga de rendimiento durante las operaciones de crecimiento del registro.

Factores que pueden retrasar el truncamiento del registro de transacciones

Cuando los registros de registro permanecen activos durante mucho tiempo, se retrasa el truncamiento del registro de transacciones y el registro de transacciones puede rellenarse, como se describe anteriormente en este artículo.

Importante

Para obtener información sobre cómo responder a un registro de transacciones completo, consulte Solución de problemas de un registro de transacciones completo (error 9002 de SQL Server).

El truncamiento del registro se puede retrasar por varias razones. Para obtener información sobre lo que impide el truncamiento del registro, consulte las columnas log_reuse_wait y log_reuse_wait_desc en la vista de catálogo de la base de datos del sistema. En la tabla siguiente se describen los valores de estas columnas.

valor de log_reuse_wait valor de log_reuse_wait_desc Descripción
0 NOTHING Actualmente hay uno o varios archivos de registro virtual (VLFs) reutilizables.
1 CHECKPOINT No se ha producido ningún punto de control desde el último truncamiento del registro o el encabezado del registro aún no se ha movido más allá de un archivo de registro virtual (VLF). (Todos los modelos de recuperación).

Este escenario es una razón rutinaria para retrasar el truncamiento del registro. Para obtener más información, consulte Puntos de comprobación de base de datos (SQL Server).
2 LOG_BACKUP Se requiere una copia de seguridad del registro antes de poder truncar el registro de transacciones. (Solo modelos de recuperación completos o por operaciones masivas).

Cuando se completa la siguiente copia de seguridad de registros, es posible que se pueda reutilizar parte del espacio de registro.
3 ACTIVE_BACKUP_OR_RESTORE Hay una copia de seguridad de datos o una restauración en curso. (Todos los modelos de recuperación).

Si la copia de seguridad de una base de datos impide el truncamiento del registro, la cancelación de la operación de copia de seguridad podría ayudar a solucionar el problema inmediato.
4 ACTIVE_TRANSACTION Una transacción está activa (todos los modelos de recuperación):

Podría existir una transacción de larga duración en el inicio de la copia de seguridad del registro. En este caso, para liberar espacio se podría requerir otra copia de seguridad del registro. Las transacciones de ejecución prolongada impiden el truncamiento del registro en todos los modelos de recuperación, incluido el modelo de recuperación simple, en el que, por lo general, el registro de transacciones se trunca en cada punto de comprobación automático.

Una transacción está diferida. Una transacción diferida es efectivamente una transacción activa cuya reversión se bloquea debido a algún recurso no disponible. Para obtener información sobre las causas de las transacciones diferidas y cómo sacarlas del estado diferido, vea Transacciones diferidas (SQL Server).

Las transacciones de larga ejecución también podrían llenar el registro de transacciones de tempdb. Las transacciones de usuario usan implícitamente tempdb para objetos internos, como tablas de trabajo para la ordenación, archivos de trabajo para operaciones hash, tablas de trabajo de cursores y el control de versiones de filas. Aunque la transacción de usuario solo incluya lectura de datos (consultas SELECT), pueden crearse y utilizarse objetos internos dentro de la transacción de usuario. Después, se puede completar el registro de transacciones tempdb.
5 DATABASE_MIRRORING La duplicación de la base de datos está en pausa o, en el modo de alto rendimiento, la base de datos reflejada está muy retrasada con respecto a la base de datos principal. (Solo modelo de recuperación completa).

Para obtener más información, vea Reflejo de la base de datos (SQL Server).
6 REPLICATION Durante las replicaciones transaccionales, las transacciones pertinentes para las publicaciones no se han entregado aún a la base de datos de distribución. (Solo modelo de recuperación completa).

Para obtener información sobre la replicación transaccional, consulte Replicación de SQL Server.
7 DATABASE_SNAPSHOT_CREATION Se crea una instantánea de base de datos. (Todos los modelos de recuperación).

Este es un motivo habitual, por lo general breve, para retrasar el truncamiento del registro.
8 LOG_SCAN Se está realizando un análisis del registro. (Todos los modelos de recuperación).

Este es un motivo habitual, por lo general breve, para retrasar el truncamiento del registro.
9 AVAILABILITY_REPLICA Una réplica secundaria de un grupo de disponibilidad está aplicando entradas del registro de transacciones de esta base de datos a una base de datos secundaria correspondiente. (Solo modelo de recuperación completa).

Para obtener más información, consulte ¿Qué es un grupo de disponibilidad Always On?.
10 - Para uso interno.
11 - Para uso interno.
12 - Para uso interno.
13 OLDEST_PAGE Si una base de datos está configurada para usar puntos de comprobación indirectos, la página más antigua de la base de datos podría ser anterior al número de secuencia de registro (LSN) del punto de comprobación. En este caso, la página más antigua puede retrasar el truncamiento del registro. (Todos los modelos de recuperación).

Para obtener información sobre los puntos de control indirectos, consulte: Puntos de control de base de datos (SQL Server).
14 OTHER_TRANSIENT No se utiliza este valor actualmente.
16 XTP_CHECKPOINT Es necesario realizar un punto de comprobación OLTP en memoria. En el caso de las tablas optimizadas para memoria, se toma un punto de control automático cuando el archivo de registro de transacciones supera los 1,5 GB desde el último punto de control. (Incluye tablas optimizadas para memoria y basadas en disco).

Para obtener más información, consulte Operación de punto de control para tablas optimizadas para memoriay Registro y proceso de punto de comprobación para tablas optimizadas para memoria.

Operaciones que se pueden registrar mínimamente

El registro mínimo implica registrar solo la información necesaria para recuperar la transacción sin admitir la recuperación a un momento dado. En este artículo se identifican las operaciones que se registran mínimamente en el modelo de recuperación optimizado para cargas masivas de registros (y también en el modelo de recuperación simple, excepto cuando se ejecuta una copia de seguridad).

Las tablas optimizadas para memoria no admiten el registro mínimo.

Con el modelo de recuperacióncompleta, todas las operaciones masivas se registran completamente. Sin embargo, puede minimizar el registro para un conjunto de operaciones masivas cambiando temporalmente la base de datos al modelo de recuperación de registro masivo para las operaciones masivas. El registro mínimo resulta más eficaz que el registro completo y reduce la posibilidad de que una operación masiva a gran escala termine por ocupar todo el espacio del registro de transacciones durante una transacción masiva. Sin embargo, si la base de datos se daña o se pierde cuando el registro mínimo está en vigor, no se puede recuperar la base de datos hasta el momento en que se produjo el error.

Las siguientes operaciones, que quedan registradas por completo en el modelo de recuperación completa, se registran mínimamente en el modelo de recuperación simple y en el modelo de recuperación con registro masivo:

  • Operaciones de importación masiva (bcp, BULK INSERTy INSERT). Para obtener más información sobre cuándo se registra mínimamente una importación masiva en una tabla, vea Prerrequisitos para registro mínimo en importación en masa.

    Cuando la replicación transaccional está habilitada, las operaciones BULK INSERT se registran por completo incluso con el modelo de recuperación de registros masiva.

  • Operaciones de la cláusula SELECT - INTO.

    Cuando la replicación transaccional está habilitada, las operaciones SELECT INTO se registran por completo incluso con el modelo de recuperación de registro masivo.

  • Actualizaciones parciales de tipos de datos de valores grandes mediante la cláusula .WRITE de la instrucción UPDATE al insertar o agregar nuevos datos. El registro mínimo no se utiliza cuando se actualizan los datos existentes. Para obtener más información sobre los tipos de datos de valores grandes, consulte:Tipos de datos.

  • Las instrucciones WRITETEXT y UPDATETEXT al insertar o agregar datos nuevos en columnas de tipo de datos text, ntext y image. El registro mínimo no se utiliza cuando se actualizan los datos existentes.

    Advertencia

    Las sentencias WRITETEXT y UPDATETEXT están obsoletas. Evite usarlos en nuevas aplicaciones.

  • Si la base de datos está configurada con el modelo de recuperación simple o por medio de registros masivos, algunas operaciones DDL de índices se registran de forma mínima, tanto si la operación se ejecuta sin conexión como en línea. Las operaciones de índice mínimamente registradas son:

    • CREATE INDEX operaciones (incluidas las vistas indexadas).

    • ALTER INDEX RECOMPILACIÓN o DBCC DBREINDEX operación de recompilación.

      Las operaciones de compilación de índices usan un registro mínimo, pero pueden retrasarse cuando hay una copia de seguridad que se ejecuta simultáneamente. Este retraso se debe a los requisitos de sincronización de las páginas del grupo de búfer con registro mínimo cuando se usa el modelo de recuperación simple o de registro masivo.

      Advertencia

      La DBCC DBREINDEX instrucción está en desuso. Evite usarlo en nuevas aplicaciones.

    • DROP INDEX nueva recompilación del montón (si procede). La desasignación de páginas de índice durante una DROP INDEX operación siempre se registra por completo.

Tarea Artículo
Administrar el registro de transacciones Administrar el tamaño del archivo de registro de transacciones

Solución de problemas de un registro de transacciones completo (error 9002 de SQL Server)
Realizar copia de seguridad de un registro de transacciones (modelo de recuperación completo únicamente) Copia de seguridad de un registro de transacciones

Copia de seguridad del registro de transacciones cuando la base de datos está dañada (SQL Server)
Restaurar registros de transacciones (modelo de recuperación completa únicamente) Restauración de una copia de seguridad del registro de transacciones (SQL Server)

Contenido relacionado

  • Last updated on