Отложенные транзакции (SQL Server)Deferred Transactions (SQL Server)

ОБЛАСТЬ ПРИМЕНЕНИЯ: даSQL Server нетБаза данных SQL Azure нетAzure Synapse Analytics (хранилище данных SQL) нетParallel Data Warehouse APPLIES TO: yesSQL Server noAzure SQL Database noAzure Synapse Analytics (SQL DW) noParallel Data Warehouse

В SQL ServerSQL Server Enterprise поврежденная транзакция может быть отложена, если данные, которые требуются для отката (отмены), находятся в режиме "вне сети" во время запуска базы данных.In SQL ServerSQL Server Enterprise, a corrupted transaction can become deferred if data required by rollback (undo) is offline during database startup. Отложенная транзакция представляет собой транзакцию, которая не фиксируется по завершении стадии наката и которая вызывает ошибку, препятствующую ее откату.A deferred transaction is a transaction that is uncommitted when the roll forward phase finishes and that has encountered an error that prevents it from being rolled back. Поскольку нельзя выполнить откат этой транзакции, она откладывается.Because the transaction cannot be rolled back, it is deferred.

Примечание

Поврежденные транзакции откладываются только в выпуске SQL ServerSQL Server Enterprise.Corrupted transactions are deferred only in SQL ServerSQL Server Enterprise. В других выпусках SQL ServerSQL Serverповрежденная транзакция вызывает сбой запуска.In other editions of SQL ServerSQL Server, a corrupted transaction causes startup to fail.

Обычно отложенная транзакция встречается, когда во время наката в базе данных происходит ошибка ввода-вывода, которая не позволяет считать нужную для транзакции страницу.Generally, a deferred transaction occurs because, while the database was being rolled forward, an I/O error prevented reading a page that was required by the transaction. Еще одной причиной возникновения отложенных транзакций может стать ошибка на файловом уровне.However, an error at the file level can also cause deferred transactions. Отложенная транзакция может возникнуть,если последовательность частичного восстановления останавливается из-за необходимости отката, а требуемые для этого данные находятся в режиме «вне сети».A deferred transaction can also occur when a partial restore sequence stops at a point at which transaction rollback is necessary and a transaction requires data that is offline.

Пользовательские транзакции, для которых выполняется откат и в которых возникает ошибка ввода-вывода, вызывают переключение всей базы данных в режим «вне сети».User transactions that are rolling back and hit an I/O error cause the whole database to go offline. При повторном переводе базы данных в режим «в сети» повтор заново запрашивает все имевшиеся ранее блокировки и производит попытку произвести откат всех незавершенных транзакций.When the database is brought back online, the redo reacquires all the locks it had and tries to roll back all the uncommitted transactions. Все измененные транзакцией данные остаются соответствующим образом заблокированными до тех пор, пока не завершится откат транзакции.All data modified by a transaction remains appropriately locked until the transaction can roll back. Транзакции, для которых невозможно выполнить откат, снимают блокировки после устранения повреждения и перезапуска базы данных либо после восстановления «в сети», когда отложенные транзакции разрешаются в режиме «в сети» базы данных.Transactions that cannot be rolled back will give up their locks when the corruption is fixed and the database restarted or, after an online restore, when the deferred transactions are resolved while the database remains online. До этого момента отложенная транзакция удерживает блокировки, предотвращающие определенные операции над базой данных в целом.Until that point, a deferred transaction can hold locks that prevent certain operations on the database as a whole. Например, если отложенная транзакция содержит инструкцию CREATE TABLE, ни один пользователь не сможет создать таблицу до тех пор, пока отложенная транзакция не будет разрешена.For example, if a deferred transaction contains a CREATE TABLE instruction, no user can create a table until the deferred transaction has been resolved.

Отложенные транзакции могут также возникать, когда поэтапное восстановление восстанавливает базу данных до точки, в которой одна или несколько активных транзакций затрагивают еще не восстановленную файловую группу, находящуюся в режиме «вне сети».Deferred transaction can also occur because a piecemeal restore recovers a database to a point at which one or more active transactions are affecting a filegroup that has not yet been restored and is offline. Поскольку нельзя выполнить откат этих транзакций, они откладываются.Because the transactions cannot be rolled back, they become deferred.

В следующей таблице перечисляются действия, ведущие к тому, что база данных начинает восстановление и формирование результата при возникновении проблемы с вводом-выводом.The following table lists the actions that cause a database to perform recovery and the outcome if an I/O problem occurs.

ДействиеAction Разрешение (если возникает проблема ввода-вывода или нужные данные находятся в режиме «вне сети»)Resolution (if I/O problems occur or required data is offline)
Запуск сервераServer start Отложенная транзакцияDeferred transaction
ВосстановитьRestore Отложенная транзакцияDeferred transaction
AttachAttach Присоединение завершается с ошибкойAttach fails
Автоматический перезапускAutorestart Отложенная транзакцияDeferred transaction
Создание базы данных или моментального снимка базы данныхCreate database or database snapshot Создание завершается с ошибкойCreation fails
Повтор при зеркальном отображении базы данныхRedo on database mirroring Отложенная транзакцияDeferred transaction
Файловая группа находится в режиме «вне сети»Filegroup is offline Отложенная транзакцияDeferred transaction

Вывод транзакции из состояния DEFERREDMoving a Transaction Out of the DEFERRED State

Важно!

Отложенная транзакция удерживает журнал транзакций активным.Deferred transactions keep the transaction log active. Файл виртуального журнала, содержащий все отложенные транзакции, нельзя усекать, пока эти транзакции не выйдут из отложенного состояния.A virtual log file that contains any deferred transactions cannot be truncated until those transactions are moved out of the deferred state. Дополнительные сведения об усечении журнала см. в разделе Создание резервной копии журнала транзакций (SQL Server).For more information about log truncation, see The Transaction Log (SQL Server).

Для вывода транзакции из отложенного состояния база данных должна запуститься без ошибок ввода-вывода.To move the transaction out of the deferred state, the database must start cleanly without any I/O errors. При наличии отложенных транзакций необходимо восстановить работу источника ошибок ввода-вывода.If deferred transactions exist, you must fix the source of the I/O errors. Ниже приводятся доступные решения, перечисленные в том порядке, в каком они обычно применяются.The available solutions, listed in the order in which they are typically tried, are as follows:

  • Перезапуск базы данных.Restart the database. Если проблема временная, база данных должна запускаться без отложенных транзакций.If the problem was transient, the database should start without deferred transactions.

  • Если транзакции были отложены из-за того, что файловая группа была в режиме «вне сети», вновь переведите файловую группу в режим «в сети».If the transactions were deferred because a filegroup was offline, bring the filegroup back online.

    Для возвращения файловой группы из режима «вне сети» в режим «в сети» воспользуйтесь следующей инструкцией Transact-SQLTransact-SQL :To bring an offline filegroup back online, use the following Transact-SQLTransact-SQL statement:

    RESTORE DATABASE database_name FILEGROUP=<filegroup_name>  
    
  • восстановить базу данных.Restore the database. После восстановления «в сети» разрешаются отложенные транзакции.After an online restore, any deferred transactions are resolved.

    В полной модели восстановления или модели с неполным протоколированием восстановление страницы в режиме «в сети» может решить проблему (там, где это поддерживается), если причиной возникновения отложенных транзакций являются лишь несколько поврежденных страниц.Under the full or bulk-logged recovery model, if the deferred transactions were caused by only a few corrupted pages, an online page restore might resolve the errors (where supported).

  • Если файловая группа, состояние «вне сети» которой является причиной отложенных транзакций, больше не требуется, отключите эту файловую группу.If you are no longer require a filegroup whose offline status is causing deferred transactions, make the offline filegroup defunct. Транзакции, отложенные из-за того, что файловая группа находилась в режиме «вне сети», выходят из отложенного состояния после того, как эта файловая группа перестанет функционировать.Transactions that were deferred because the filegroup was offline are moved out of the deferred state after the filegroup becomes defunct.

    Важно!

    Восстановление уничтоженной файловой группы невозможно.A defunct filegroup can never be recovered.

    Дополнительные сведения см. в статье Удаление уничтоженных файловых групп (SQL Server).For more information, see Remove Defunct Filegroups (SQL Server).

  • Если транзакции отложены из-за повреждения страницы, а резервная копия базы данных отсутствует, для восстановления базы данных воспользуйтесь следующей процедурой.If transactions were deferred because of a bad page and if a good backup of the database does not exist, use the following process to repair the database:

    • Вначале переведите базу данных в аварийный режим, выполнив следующую инструкцию Transact-SQLTransact-SQL :First put the database into emergency mode by executing the following Transact-SQLTransact-SQL statement:

      ALTER DATABASE <database_name> SET EMERGENCY  
      

      Сведения об аварийном режиме см. в разделе Database States.For information about emergency mode, see Database States.

    • Затем восстановите базу данных, используя параметр DBCC REPAIR_ALLOW_DATA_LOSS в одной из следующих инструкций DBCC: DBCC CHECKDB, DBCC CHECKALLOCили DBCC CHECKTABLE.Then, repair the database by using the DBCC REPAIR_ALLOW_DATA_LOSS option in one of the following DBCC statements: DBCC CHECKDB, DBCC CHECKALLOC, or DBCC CHECKTABLE.

      При возникновении страницы с поврежденными данными DBCC освобождает эту страницу и исправляет связанные с ней ошибки.When DBCC encounters the bad page, DBCC deallocates it and repairs any related errors. Такой подход дает возможность возвратить базу данных в режиме «в сети» в физически согласованное состояние.This approach enables the database to be brought back online in a physically consistent state. Но при этом могут быть также потеряны дополнительные данные, поэтому этот подход должен применяться только в исключительных случаях.However, additional data might also be lost; therefore, this approach should be used as a last resort.

См. также:See Also

Обзор процессов восстановления (SQL Server) Restore and Recovery Overview (SQL Server)
Удаление уничтоженных файловых групп (SQL Server) Remove Defunct Filegroups (SQL Server)
Восстановления файлов (модель полного восстановления) File Restores (Full Recovery Model)
Восстановление файлов (простая модель восстановления) File Restores (Simple Recovery Model)
Восстановление страниц (SQL Server) Restore Pages (SQL Server)
Поэтапное восстановление (SQL Server) Piecemeal Restores (SQL Server)
ALTER DATABASE (Transact-SQL) ALTER DATABASE (Transact-SQL)
RESTORE (Transact-SQL)RESTORE (Transact-SQL)