Transacciones diferidas

En SQL Server 2005 Enterprise Edition, una transacción dañada puede ser diferida si los datos necesarios para la reversión se encuentran sin conexión durante el inicio 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.

[!NOTA] Las transacciones dañadas son diferidas únicamente en SQL Server 2005 Enterprise Edition. En otras versiones de SQL Server, una transacción dañada hace que se produzca un error de inicio.

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 desconecte. Cuando la base de datos se conecta 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 con conexión, cuando las transacciones diferidas se resuelven mientras la base de datos está con conexión. 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.

Eliminar el estado DEFERRED de una transacción

Importante:
Las transacciones diferidas hacen que el registro de transacciones esté activo. Un archivo de registro virtual que contenga transacciones diferidas no se puede truncar hasta que dichas transacciones salen del estado diferido. Para obtener más información acerca del truncamiento del registro, vea Truncamiento del registro de transacciones.

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 conectarlo.
  Para volver a conectar 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 con conexión, se resuelven todas las transacciones diferidas.
  En el modelo de recuperación completa o por medio de registros de operaciones masivas, si las transacciones diferidas se deben a unas pocas páginas dañadas, es posible que una restauración de las páginas con conexión 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 obtener más información, vea Grupos de archivos inactivos.

• 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:

  • Ponga la base de datos en modo de emergencia mediante la ejecución de la siguiente instrucción Transact-SQL:

    ALTER DATABASE <database_name> SET EMERGENCY
    

    Para obtener información acerca del modo de emergencia, vea Estados de base de datos.

  • A continuación, repare la base de datos mediante la opción DBCC REPAIR_ALLOW_DATA_LOSS de una de las siguientes instrucciones DBCC: DBCC CHECKDB, DBCC CHECKALLOC o DBCC CHECKTABLE.
    Cuando encuentre la página dañada, DBCC la desasignará y reparará cualquier error relacionado. Este enfoque permite volver a poner a base de datos en conexión 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.

Vea también

Conceptos

Descripción de cómo funcionan la restauración y la recuperación de copias de seguridad en SQL Server
Grupos de archivos inactivos
Realizar restauraciones de archivos (modelo de recuperación completa)
Realizar restauraciones de archivos (modelo de recuperación simple)
Realizar restauraciones de páginas
Realizar restauraciones por etapas

Otros recursos

ALTER DATABASE (Transact-SQL)
RESTORE (Transact-SQL)

Ayuda e información

Obtener ayuda sobre SQL Server 2005