|
Уловка, позволяющая обойти критическое (Emergency) состояние базы данных
Информация в этой статье относится к версиям Microsoft SQL Server 4.2x, 6.0, 6.5, 7.0
В критических ситуациях, база данных может быть представлена Вам, как SUSPECT, из-за завершения неудачей
её восстановления во время старта сервера, причём обычно, это препятствует любому доступу клиентов к данным.
Однако, существует возможность ручного вывода базы данных из состояния SUSPECT в "bypass mode" (также
называемого "emergency mode") и последующего исполнения команды SELECT или запуска программы Bulk Copy (BCP),
позволяющих осуществить копирование данных в другое место, в целях их сохранения. В то время, когда никто
не сможет выполнять никаких легитимных модификаций данных, с помощью этой уловки, можно выполнить DUMP
TRANSACTION WITH NO_LOG. Обратите внимание, что использование этой уловки не поддерживается Микрософт,
и является потенциально опасной операцией. По этим же причинам, если восстановление базы при запуске будет
осуществляться слишком долгое время, Вы не должны прерывать этот процесс, переводить базу данных в bypass mode,
и затем выполнять DUMP TRANSACTION WITH NO_LOG.
Все операции сервера, исполняемые в рамках DUMP TRANSACTION, обычно регистрируются в журнале, так,
что эти операции можно восстановить или отменить. Однако, эти операции, порождённые непосредственно командой
DUMP, также занимают место в transaction log. Если transaction log переполнен, и места недостаточно для нормальной
работы сервера, а также для регистрации операций DUMP TRANSACTION, использование опции WITH NO_LOG
может предоставить Вам возможность произвести усечение transaction log без регистрации каких - либо операций в
журнале.
DUMP TRANSACTION WITH NO_LOG правильно сохраняет транзакции только при относительно нормальных
условиях работы сервера. Сервер сам предпринимает определённые меры для гарантии успешности восстановления,
даже если на сервере произойдёт сбой во время этой операции.
В редких случаях автоматическое восстановление (также называемое, восстановление при запуске - startup recovery)
может закончится неудачей, после чего база данных будет отмечена, как SUSPECT. Восстановление закончится
неудачей по определенной причине. Очень важно обратить внимание на сообщение в errorlog, которое отражает
причину завершения неудачей восстановления, потому что это может помочь локализовать проблему.
Восстановление, это процесс поиска и исправления противоречий в базе данных, который восстанавливает или
отменяет все транзакции, которые были или активны или завершены после времени исполнения последней контрольной
точки. Этот процесс основывается на write-ahead (опережающей записи) природе transaction log (все измененные
страниц записываются вначале в журнал регистрации транзакций, и только потом в базу данных). Восстановление
состоит из чтения каждой записи журнала, сравнения её timestamp с timestamp соответствующей страницы базы
данных, и последующего принятия или отмены этого изменения. Отмена происходит в случае не исполненной транзакции,
а восстановление внесённого изменения в случае исполненной транзакции.
После обнаружения в errorlog нужного сообщения, которое относится к ошибке, повлекшей неудачу процесса
восстановления, попробуйте перевести состояние базы данных в нормальное NORMAL, с помощью простого перезапуска
SQL сервера. Это позволит Вам попробовать выполнить процедуру восстановления второй раз. Вы можете изменить
состояние базы данных посредством хранимой процедуры sp_resetstatus. Эта дополнительная хранимая процедура,
которую Вы можете установить, воспользовавшись сценарием Instsupl.sql в каталоге Mssql\Install. Для получения
дополнительной информации, см. "Resetting the Suspect Status" в документации.
Если восстановление все равно терпит неудачу, обратите внимание на сообщение об ошибках, и войдите в контакт
с вашей службой поддержки. Вы должны также убедится в наличии и работоспособности вашей последней резервной
копии базы данных, потому что она может понадобится для восстановления работоспособности базы. Однако, многие
данные в вашей базе могут быть все еще доступны, хотя их целостность нарушена. Вы можете обращаться к этим
данным, установив предварительно состояние базы данных в bypass или emergency mode. Для этого установите
для базы данных sysdatabases.status в значение: -32768, которое будет применено после выполнения команды "allow updates".
Например, используйте следующую команду:
UPDATE SYSDATABASES SET STATUS=-32768 WHERE NAME='DBNAME'
После исполнения этой инструкции, база данных может быть доступна и станет возможно получить данные с помощью
SELECT или BCP. Вы можете сталкиваться с ошибками при выполнении SELECT или BCP, но в большинстве случаев,
часть данных удаётся спасти.
|
|
