Transacciones diferidas (SQL Server)

En SQL Server Enterprise, una transacción dañada se puede aplazar si los datos requeridos por la reversión (deshacer) están sin conexión durante el inicio de la base de datos. Una transacción diferida es una transacción que no se confirma cuando finaliza la fase de avance y que ha encontrado un error que impide que sea revertida. Dado que la transacción no se puede revertir, se aplaza.

Por lo general, se produce una transacción diferida porque, mientras se estaba implementando la base de datos, un error de E/S impedía leer una página requerida por la transacción. Sin embargo, un error en el nivel de archivo también puede provocar transacciones diferidas. Una transacción diferida también puede producirse cuando una secuencia de restauración parcial se detiene en un punto en el que es necesaria la reversión de transacciones y una transacción requiere datos que están sin conexión.

Las transacciones de usuario que se revierten y alcanzan un error de E/S provocan que toda la base de datos se desconecte. Cuando la base de datos vuelve a estar disponible, la recuperación reacquire 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 pueda revertirse. Las transacciones que no se pueden revertir liberarán sus bloqueos cuando se corrija la corrupción y se reinicie la base de datos o, después de una restauración en línea, cuando las transacciones diferidas se resuelvan mientras la base de datos permanece en línea. Hasta ese momento, una transacción diferida puede contener bloqueos que impiden ciertas operaciones en la base de datos en su conjunto. Por ejemplo, si una transacción diferida contiene una instrucción CREATE TABLE, ningún usuario puede crear una tabla hasta que se haya resuelto la transacción diferida.

También se puede producir una transacción diferida porque una restauración por etapas recupera una base de datos en un punto en el que una o varias transacciones activas afectan a un grupo de archivos que aún no se ha restaurado y está sin conexión. Dado que las transacciones no se pueden revertir, se aplazan.

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

Mover una transacción fuera del estado DIFERIDO

Para sacar la transacción del estado diferido, la base de datos debe iniciarse limpiamente sin errores de E/S. Si existen transacciones diferidas, debe corregir el origen de los errores de E/S. Las soluciones disponibles, enumeradas en el orden en que normalmente se prueban, son las siguientes:

• Reinicie la base de datos. Si el problema era transitorio, la base de datos debería iniciarse sin transacciones diferidas.

• Si las transacciones se aplazaron porque un grupo de archivos estaba sin conexión, vuelva a poner el grupo de archivos en línea.

  Para volver a conectar un grupo de archivos sin conexión, use 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 las transacciones diferidas.

  En el modelo de recuperación completo o optimizado para cargas masivas de registros, si las transacciones diferidas fueron causadas por solo algunas páginas dañadas, una restauración de página en línea podría resolver los errores (donde se admite).

• Si ya no necesita un grupo de archivos cuyo estado sin conexión está causando transacciones diferidas, desuse el grupo de archivos sin conexión. Las transacciones aplazadas porque el grupo de archivos estaba sin conexión se mueven fuera del estado diferido después de que el grupo de archivos deje de estar inactivo.

  Importante

  Nunca se puede recuperar un grupo de archivos inactivo.

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

• Si las transacciones se aplazaron debido a una página incorrecta y si no existe una buena copia de seguridad de la base de datos, use el siguiente proceso para reparar la base de datos:

  • En primer lugar, coloque 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 sobre el modo de emergencia, consulte Estados de base de datos.

  • A continuación, repare la base de datos mediante la opción DBCC REPAIR_ALLOW_DATA_LOSS en una de las siguientes instrucciones DBCC: DBCC CHECKDB, DBCC CHECKALLOC o DBCC CHECKTABLE.

    Cuando DBCC encuentra la página dañada, DBCC la desasigna y repara cualquier error relacionado. Este enfoque permite que la base de datos se vuelva a poner en línea en un estado físicamente coherente. Sin embargo, es posible que también se pierdan datos adicionales; por lo tanto, este enfoque debe usarse como último recurso.

Véase 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)