SQL-Ex blog

Log Backups, Norecovery и Standby

Мы выполняем резервирование журнала для защиты данных, начиная с последнего полного бэкапа, и при необходимости обеспечения возможности восстановления к определенному моменту времени с точностью до секунды. Магия, лежащая в основе использования norecovery во время восстановления, позволяет нам продолжать применять резервные копии журналов до тех пор, пока мы, наконец, не будем готовы завершить восстановление и начать использовать базу данных. Это работает до тех пор, пока у нас есть полная цепочка журналов и мы восстанавливаемся на той же или более поздней версии SQL Server (с некоторыми ограничениями - для действительно старых версий вам может потребоваться выполнить восстановление к промежуточной версии, сделать бэкап, а затем восстановить на новой версии). Вы могли бы использовать или, по крайней мере, думать об этом как о log shipping, который использует возможность обслуживания сервера аварийного восстановления. Режим Standby является вариацией, позволяющей нам читать из базы данных в течение всего времени, пока не будет завершено финальное восстановление.

Зачем нам может понадобиться видеть объекты, когда мы еще не завершили процесс восстановления?

• Нам было бы удобно иметь подтверждение, что мы действительно применяем восстановление журналов, как ожидалось.


• Мы хотим использовать эту базу данных для подготовки отчетов, зная, что всякий раз, когда мы восстанавливаем очередной бэкап журнала, мы должны будем отключать все другие сессии к этой базе данных. Это компромисс для получения возможности работать с базой в процессе ее восстановления.


• Нам необходимо просматривать таблицы, чтобы увидеть, достаточно ли мы восстановили, типичный сценарий исследования данных или аварийного восстановления типа "Я думаю, что удалил эту таблицу в момент времени Х".

Восстановление с Norecovery - SQL 2019 в SQL 2019

Во простой пример восстановления полного бэкапа и файла журнала при использовании norecovery:

RESTORE DATABASE [Test] FROM DISK = N'C:\Andy\Test.bak' with MOVE N'Test' TO N'C:\Andy\Test.mdf',  MOVE N'Test_log' TO N'C:\Andy\Test_log.ldf',  NORECOVERY

RESTORE LOG [Test] FROM DISK = N'C:\Andy\Test_log.bak' WITH  NORECOVERY

Выполнив навигацию в SSMS после выполнения этих двух операторов, мы можем увидеть, что база данных находится в состоянии “Restoring…”, которое означает, что мы использовали norecovery при восстановлении и что мы не можем заглянуть внутрь базы данных. Мы знаем, что так оно и есть, что это вроде бы правильно, но не можем видеть ни один объект в базе данных. Мы можем продолжить восстановление последующих изменений или можем перевести ее в режим онлайн (и тогда больше не сможем применять изменения в журналах).

Восстановление со Standby - SQL 2019 на SQL 2019

Если мы изменим восстановление на with standby, то получим возможность выполнять запросы к базе данных. Это незначительно изменит наш синтаксис, который работает почти так же, как и базовое восстановление с norecovery, но добавляет резервный файл на диск. Этот файл и есть та магия, которая обрабатывает операции копирования при записи так, чтобы мы могли продолжать применение бэкапов журнала. Вот пример, который использует standby вместо norecovery:

RESTORE DATABASE [TestCopy] FROM  DISK = N'C:\Andy\Test.bak' with MOVE N'Test' TO N'C:\Andy\Test.mdf',  MOVE N'Test_log' TO N'C:\Andy\Test_log.ldf',  standby = 'c:\andy\testcopy_standby.dat'

RESTORE LOG [TestCopy] FROM  DISK = N'C:\Andy\Test_log.bak' WITH  standby = 'C:\andy\testcopy_standby.dat'

Восстановление с Norecovery - SQL 2019 на SQL 2022

Прежние примеры использовали бэкап SQL 2019 и восстанавливали базу данных на тот же экземпляр для простоты демонстрации. Что будет, если я хочу взять те же самые бэкапы и восстановить их на SQL 2022? Вот то же самое восстановление с norecovery:

RESTORE DATABASE [TestCopy] FROM  DISK = N'C:\Andy\Test.bak' with MOVE N'Test' TO 'C:\Andy\Test.mdf',  MOVE N'Test_log' TO N'C:\Andy\Test_log.ldf',  norecovery

RESTORE LOG [TestCopy] FROM DISK = N'C:\Andy\Test_log.bak' WITH norecovery

Как и следовало ожидать, работает отлично.

Восстановление со Standby - SQL 2019 на SQL 2022

Теперь давайте проверим восстановление бэкапов SQL 2019 на SQL 2022 при использовании standby:

RESTORE DATABASE [TestCopy] FROM  DISK = N'C:\Andy\Test.bak' with MOVE N'Test' TO N'C:\Andy\Test.mdf',  MOVE N'Test_log' TO N'C:\Andy\Test_log.ldf',  standby = 'c:\andy\testcopy_standby.dat'

Не работает! Этот момент я пропускал все эти годы.

Режим Standby терпит неудачу, если версии не совпадают (и еще несколько предостережений)

Вот что говорится в документации:



В этом случае необходим апгрейд базы данных, поскольку это совершенно другая версия. Если мы восстанавливаем с norecovery, а затем завершаем восстановление то можем увидеть пачку сообщений о том, что внутри был применен апгрейд:

Полученный урок

Если вы восстанавливаете в режиме standby только для того, чтобы провести некоторое исследование, знание этого ограничения означает предварительный выбор сервера, который имеет ту же самую версию. Если вы рассчитываете на standby для получения доступа на чтение данных за исключением случаев восстановления, это означает, что вы должны координировать любые будущие апгрейды источника или целевого сервера. Если вы можете проапгрейдить оба одновременно, то нет проблем. Если вы не можете сделать это для обоих серверов одновременно, вы должны переместить либо базу данных источника, либо целевую базу данных на другой совместимый по версии сервер. В любом случае это будет менее раздражающим, если вы знаете, что должны сделать, а не выяснять потом, что сервер источника проапгрейдили.

Это мой небольшой полученный урок, и я надеюсь, то он также поможет кому-нибудь еще. Для тех читателей, кто еще не использовал norecovery, standby или log shipping, я настоятельно советую провести часок для их испытания.

Ссылки по теме
1. Восстановление на момент времени в SQL Server
2. Понимание моделей восстановления SQL Server
3. Примеры резервного копирования базы данных SQL Server
4. 5 типов резервных копий в SQL Server