Transacciones diferidas (SQL Server)

Se aplica a: SQL Server

En SQL Server Enterprise, una transacción dañada puede ser aplazada si los datos necesarios para la reversión se encuentran sin conexión durante el startup de la base de datos. Una transacción diferida es aquella que está sin confirmar cuando termina la fase de puesta al día y que se encuentra con un error que impide que se revierta. Si la transacción no se puede revertir, se convierte en una transacción diferida.

Normalmente, las transacciones diferidas se producen porque, cuando la base de datos se estaba poniendo al día, un error de E/S impidió que se leyera una página necesaria para la transacción. Sin embargo, un error en el nivel de archivo también puede provocar transacciones diferidas. También puede producirse una transacción diferida cuando una secuencia de restauración parcial se detiene en un punto donde se requiere la reversión de transacciones y una transacción necesita datos que se encuentran sin conexión.

Las transacciones de usuario que se están revirtiendo y se encuentran un error de E/S hacen que toda la base de datos se quede sin conexión. Cuando la base de datos está en línea de nuevo, la acción de rehacer vuelve a adquirir todos los bloqueos que tenía e intenta revertir todas las transacciones no confirmadas. Todos los datos modificados por una transacción permanecen adecuadamente bloqueados hasta que la transacción se puede revertir. Las transacciones que no pueden revertirse renuncian a sus bloqueos cuando los daños se arreglan y la base de datos se reinicia o, después de una restauración en línea, cuando las transacciones diferidas se resuelven mientras la base de datos está en línea. Hasta ese momento, una transacción diferida puede mantener los bloqueos que impiden ciertas operaciones en la base de datos en su totalidad. Por ejemplo, si una transacción diferida contiene una instrucción CREATE TABLE, ningún usuario puede crear una tabla hasta que la transacción diferida se haya resuelto.

Las transacciones diferidas pueden producirse también porque una restauración por etapas recupera una base de datos a un punto en que una o varias transacciones activas afectan a un grupo de archivos que todavía no se ha restaurado y sigue estando sin conexión. Como las transacciones no se pueden revertir, se convierten en transacciones diferidas.

En la siguiente tabla se enumeran las acciones que hacen que una base de datos lleve a cabo la recuperación y el resultado si se produce un problema de E/S.

Requisitos y limitaciones

• La base de datos debe usar el modelo de recuperación FULL o BULK-LOGGED.
• Se debe haber completado al menos una copia de seguridad del registro de transacciones y de la base de datos para la base de datos.
• Las transacciones aplazadas no se aplican a los errores detectados durante la reversión de una transacción cuando la base de datos está en línea (por ejemplo, error en tiempo de ejecución).
• Las transacciones no se pueden diferir por errores de recuperación mientras se adjunta una base de datos.
• Algunas transacciones, como las transacciones del sistema (por ejemplo, la asignación de páginas) no se pueden aplazar

Eliminar el estado DEFERRED de una transacción

Para hacer que la transacción salga del estado diferido, la base de datos debe iniciarse correctamente, sin ningún error de E/S. Si existen transacciones diferidas, debe corregir el origen de los errores de E/S. Las soluciones disponibles, que aparecen en la lista en el orden en que se suelen aplicar, son las siguientes:

• Reinicie la base de datos. Si el problema fue transitorio, la base de datos se iniciará sin transacciones diferidas.

• Si las transacciones se aplazaron debido a que el grupo de archivos estaba sin conexión, vuelva a ponerlo en línea.

  Para volver poner en línea un grupo de archivos sin conexión utilice la siguiente instrucción Transact-SQL:

  RESTORE DATABASE database_name FILEGROUP=<filegroup_name>  
  

• Restaure la base de datos. Después de una restauración en línea, se resuelven todas las transacciones diferidas.

  En el modelo de recuperación completa o el modelo de recuperación optimizado para cargas masivas de registros, si las transacciones diferidas se deben a unas pocas páginas dañadas, es posible que una restauración de las páginas en línea resuelva los errores (donde se admita).

• Si ya no necesita un grupo de archivos cuyo estado sin conexión crea transacciones diferidas, haga que el grupo de archivos sin conexión pase a estar inactivo. Las transacciones que estaban diferidas porque el grupo de archivos estaba sin conexión salen del estado diferido una vez que el grupo de archivos queda inactivo.

  Importante

  Un grupo de archivos inactivo no puede recuperarse.

  Para más información, vea Quitar grupos de archivos inactivos (SQL Server).

• Si las transacciones estaban diferidas a causa de de una página dañada y no se dispone de buena copia de seguridad correcta de la base de datos, siga este procedimiento para reparar la base de datos:

  • Primero ponga la base de datos en modo de emergencia ejecutando la siguiente instrucción Transact-SQL:

    ALTER DATABASE <database_name> SET EMERGENCY  
    

    Para obtener información acerca del modo de emergencia, vea Database States.

  • Después, repare la base de datos mediante la opción DBCC REPAIR_ALLOW_DATA_LOSS de una de las siguientes instrucciones DBCC: DBCC CHECKDB, DBCC CHECKALLOCo DBCC CHECKTABLE.

    Cuando encuentre la página dañada, DBCC la desasignará y reparará cualquier error relacionado. Este enfoque permite volver a poner en línea la base de datos en un estado físicamente coherente. Sin embargo, también podrían perderse otros datos, por lo que este enfoque debe ser el último recurso.

Consulte también

Información general sobre restauración y recuperación (SQL Server)
Quitar grupos de archivos inactivos (SQL Server)
Restauraciones de archivos (modelo de recuperación completa)
Restauraciones de archivos (modelo de recuperación simple)
Restaurar páginas (SQL Server)
Restauraciones por etapas (SQL Server)
ALTER DATABASE (Transact-SQL)
RESTORE (Transact-SQL)