Действия при ошибках восстановления SQL Server, вызванных повреждением резервных копий
Ошибки восстановления возникают при повреждении носителя резервной копии. Ошибки восстановления могут быть сформированы операционной системой или выявлены при подсчете контрольных сумм. В любом из этих случаев есть три варианта действий:
исправить ошибку и перезапустить операцию восстановления;
продолжить восстановление, несмотря на ошибки, и восстановить базу данных после его завершения;
отменить операцию восстановления и воспользоваться другим планом восстановления, в котором поврежденная резервная копия не участвует.
Примечание |
---|
Набор носителей или резервный набор данных должен содержать минимальные правильные данные, чтобы интерпретироваться как формат Microsoft Tape Format. Иначе инструкция RESTORE прекращает работу и сообщает, что резервная копия имеет недопустимый формат. |
Исправление ошибки и перезапуск восстановления
Ошибки могут быть исправлены разными способами:
если ошибка возникла на ленточном накопителе, можно почистить или заменить считыватель;
для дисковых устройств можно проверить устройство на ошибки и заменить поврежденный файл;
если набор носителей участвует в зеркальном отображении, можно заменить поврежденный носитель соответствующим носителем с зеркального сервера.
Продолжение после обнаружения ошибки
Внимание! |
---|
Определение параметра WITH CONTINUE_AFTER_ERROR инструкции RESTORE дает возможность восстановить базу данных. Однако существует множество видов повреждений, которые могут не позволить восстановить базу данных. Рекомендуется использовать параметр CONTINUE_AFTER_ERROR только в том случае, когда все остальные методы не дали результата. |
Параметр CONTINUE_AFTER_ERROR позволяет продолжить операцию восстановления после обнаружения ошибки, чтобы восстановить все, что можно. Происходит накат и появляется возможность использования последовательных резервных копий журнала транзакций. Если при накате обнаружена ошибка, препятствующая достижению заданного момента времени, это отражается в журнале. Если это возможно, то в точке восстановления база данных переводится в оперативный режим. Но если восстановление не может быть завершено, то база данных остается в автономном режиме.
Размеры потерь данных зависят от произошедшей ошибки. Например, неверная контрольная сумма на странице вызывает вопросы только к этой странице. Чтение и обработка данных при этом продолжается. В то же время, ошибка ввода-вывода, о которой сообщает ленточный накопитель, может привести к прекращению операции чтения, и тогда восстановление с оставшейся части ленты не производится.
Если продолжать восстановление после ошибок, страницы, которые не прошли проверку, сохраняются на диске и отражаются в таблице suspect_pages и в журнале ошибок.
Рекомендации: после использования при восстановлении данных параметра WITH CONTINUE_AFTER_ERROR изучите описания ошибок в журналах ошибок. Также следует сохранить и проанализировать все сообщения, которые выдает инструкция RESTORE.
Продолжение работы, несмотря на ошибки
Базовый синтаксис RESTORE:
RESTORE DATABASE database_name FROM устройство_резервного_копирования WITH CONTINUE_AFTER_ERROR, [ NORECOVERY ]
Управление базой данных в автономном режиме
По окончании последовательности восстановления с пропуском ошибок, может появиться возможность восстановить базу данных с помощью инструкции DBCC CHECKDB. Чтобы гарантировать наибольшую согласованность, после восстановления с параметром RESTORE CONTINUE_AFTER_ERROR рекомендуется выполнять инструкцию DBCC CHECKDB с параметром WITH TABLOCK. Дополнительные сведения см. в разделе DBCC CHECKDB (Transact-SQL). Доступны все параметры восстановления. Для определения минимального необходимого уровня восстановления запустите инструкцию DBCC CHECKDB, не указывая параметры восстановления. Но имейте в виду, что в особо тяжелых случаях данных для восстановления может оказаться недостаточно.
Для получения ограниченного доступа к данным «как есть» можно с помощью параметра EMERGENCY команды ALTER DATABASE переключить базу данных в аварийный режим.