Резервные копии заключительного фрагмента журнала (SQL Server)Tail-Log Backups (SQL Server). Заключительный фрагмент журнала базы данных не был добавлен

Изменение модели восстановления / Хабр

Примечание от переводчика: числом 101 в американских колледжах обычно обозначается вводный курс, дающий базовые знания о предметной области.

SQLskills запускает новую инициативу по размещению записей с базовыми знаниями, мы назвали ее SQL101. Мы будем писать о вещах, которые, как мы часто видим, делаются неправильно, технологиях, которые используются неверно, и о многих недопониманиях, которые приводят к серьезным проблемам. Если вы хотите найти все записи в этой серии, проверьте ссылку SQLskills.com/help/SQL101 (английский).

Одна из вещей, которая может подстерегать вас при администрировании — это эффект от временного переключения из полной модели восстановления на другую. В этой статье я кратко опишу три модели восстановления и проблемы, которые могут возникнуть при переключении из полной модели в простую и из полной в модель с неполным протоколированием (bulk-logged).

Модели восстановления

Есть три модели восстановления:

• Полная модель восстановления (используется по умолчанию и чаще всего)
  • Все изменения в базе полностью журналируются. Это не означает, что каждое изменение имеет отдельную запись в журнале, поскольку некоторые операции пишутся с меньшим количеством записей в журнале, но тем не менее журналируется полный эффект от операции (например, операция TRUNCATE TABLE — смотрите здесь полное объяснение (английский)).
  • Журнал транзакций не будет очищаться (т.е. его части не станут доступными для переиспользования) до тех пор, как не будет сделана резервная копия журнала транзакций(смотрите здесь полное объяснение (английский)).
  • Все опции восстановления доступны, когда база данных в полной модели восстановления (и была в ней с момента создания последней резервной копии).
• Модель восстановления с неполным протоколированием
  • Некоторые изменения (такие как перестроение индекса или пакетная загрузка, но НЕ стандартные INSERT/UPDATE/DELETE) могут минимально журналироваться, что снижает количество записей в журнале и журнал транзакций не становится слишком большим за время выполнения этих операций. Обратите внимание, что это не изменяет размер последующих резервных копий журнала транзакций. Для получения полных инструкций, как сделать ваши операции минимально журналируемыми, смотрите документ «Data Loading Performance Guide» (английский), который описывает все возможные условия, которые должны быть соблюдены.
  • Журнал транзакций не будет очищаться (т.е. его части не станут доступными для переиспользования) до тех пор, как не будет сделана резервная копия журнала транзакций (абсолютно так же, как и при полной модели восстановления).
  • Используя модель восстановления с неполным протоколированием, вы теряете часть опций по восстановлению (восстановление на момент времени и резервная копия заключительного фрагмента) в обмен на повышение производительности, связанное с минимально журналируемыми операциями.
• Простая модель восстановления
  • Некоторые изменения могут минимально журналироваться (абсолютно так же, как и при модели восстановления с неполным протоколированием).
  • Журнал транзакций не будет очищаться до выполнения операции создания контрольной точки (CHECKPOINT) — обычно она выполняется автоматически.
  • Создание резервных копий журнала транзакций невозможно, поэтому у вас остается самое ограниченное число опций по восстановлению.

Большинство людей использует полную модель восстановления, чтобы иметь возможность создавать резервные копии журнала транзакций и позволить себе все возможные опции восстановления. Главная вещь, которую вы должны помнить, когда ваша база использует полную модель восстановления или модель с неполным протоколированием — вы должны периодически создавать резервные копии журнала транзакций или журнал транзакций будет расти бесконечно.

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

Переключение в простую модель восстановления

Часто я слышу от людей, что они переключаются в простую модель восстановления чтобы избежать роста журнала транзакций при выполнении пакетной загрузки или перестроения индексов, тогда как то, что им действительно нужно — это модель с неполным протоколированием. Также есть устойчивые мифы о том, что какие то регулярные операции *требуют*, чтобы модель восстановления была простой — это просто (ха ха) неправда.

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

Более того, такое переключение ограничивает ваши возможности в случае сбоя, потому что теперь у вас осталась только одна полная резервная копия, из которой вы можете восстановиться — та, которую вы сделали последней. Подумайте об этом — ваши возможные опции для восстановления становятся такими:

• Полная резервная копия после переключения в простую модель восстановления, разностные резервные копии после этой полной (если вы используете разностные резервные копии) и любые резервные копии журнала транзакций с тех пор, как вы переключились обратно из простой модели; или
• Самая последняя полная резервная копия перед переключением в простую модель восстановления плюс последняя разностная копия после переключения назад из простой плюс любые резервные копии журнала транзакций.

Если эта самая последняя полная резервная копия (перед или после переключения в простую модель восстановления) повреждена, вы не можете восстановиться. Вы не можете взять предыдущую полную резервную копию, потому что она позволит вам восстановиться только до момента переключения в простую модель восстановления, но не после. Хорошо, я думаю, вы можете так сделать, но вы потеряете всю работу с момента переключения в простую модель восстановления.

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

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

Переключение в модель восстановления с неполным протоколированием

Переключение к неполному протоколированию в процессе загрузки или обслуживания индексов приемлемо, чтобы избежать роста журнала транзакций. На самом деле, переключение туда и обратно между полной моделью восстановления и моделью с неполным протоколированием никаким образом не влияет на цепь резервных копий журнала транзакций. И такое переключение не влияет на доставку журналов (log shipping) или репликацию, но вы не можете переключаться из полной модели восстановления когда используете зеркалирование базы данных или группы доступности AlwaysOn, поскольку они требуют полной модели восстановления.

Тем не менее, использование модели восстановления с неполным протоколированием может вызвать проблемы для восстановления при сбоях, так что даже если вы хотите использовать такую модель восстановления из-за ее особенностей, вы можете отказаться от ее использования чтобы избежать рисков потери части возможностей по восстановлению.

Проблема 1: резервная копия журнала транзакций, которая содержит минимально журналируемую операцию, не может использоваться в восстановлении на момент времени. Это значит, что время, которое вы указываете в пункте WITH STOPAT в команде по восстановлению не может быть временем, которое принадлежит к такой резервной копии. Вы можете использовать такую резервную копию как часть цепочки восстановления и остановиться на любом времени после нее (если только это время не относится к другой резервной копии, которая также содержит минимально журналируемые операции, конечно), но не во время, принадлежащее этой резервной копии.

Проблема 2: Если вам необходимо выполнить резервную копию заключительного фрагмента, чтобы захватить все записи журнала транзакций, созданные с момента последней запланированной резервной копии журнала транзакций, при этом файлы данных недоступны или повреждены, и записи журнала транзакций, резервную копию которых необходимо сделать, содержат минимально журналируемые операции, то при создании такой резервной копии вы получите ошибку в версиях до SQL Server 2008 R2, и начиная с версии SQL Server 2008 R2 вы получите успешно созданную резервную копию, которая повредит базу данных, если будет восстановлена.

Поэтому, если вы собираетесь использовать модель с неполным протоколированием, чтобы сохранить место в журнале транзакций в момент больших операций, вам необходимо убедиться, что а) нет никакой вероятности, что вы захотите восстановиться на момент времени между последней и следующей за ней резервной копией журнала транзакций; и б) в базе не произойдет никаких изменений, которые вы не сможете повторить в случае, если произойдет сбой и вы не сможете сделать корректную резервную копию заключительного фрагмента.

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

Краткое изложение

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

habr.com

Резервные копии заключительного фрагмента журнала (SQL Server)

• 06/25/2013
• Время чтения: 3 мин

В этой статье

В данном разделе рассматриваются вопросы резервного копирования и восстановления только тех баз данных SQL Server, которые используют модель полного восстановления или модель восстановления с неполным протоколированием.

В резервную копию заключительного фрагмента журнала попадают все записи, резервная копия которых еще не была создана (заключительный фрагмент журнала), что позволяет предотвратить потерю работы и сохранить неповрежденную цепочку журналов. Для восстановления базы данных SQL Server на последний момент времени необходимо предварительно выполнить резервное копирование заключительного фрагмента журнала ее транзакций. Заключительный фрагмент журнала является становится последней рассматриваемой частью резервной копии в плане восстановления базы данных.

Примечание

Не для всех сценариев восстановления требуется резервная копия заключительного фрагмента журнала. Резервная копия заключительного фрагмента журнала не нужна, если точка восстановления содержится в более ранней резервной копии журнала. Кроме того, резервная копия заключительного фрагмента журнала не требуется при перемещении или замещении (перезаписи) базы данных, при котором не нужно восстанавливать ее на определенный момент времени после создания ее последней резервной копии.

В этом разделе:

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

• Резервное копирование заключительного фрагмента журнала с неполными метаданными резервной копии

• Связанные задачи

• См. также

Сценарии, в которых требуется резервная копия заключительного фрагмента журнала.

Рекомендуется формировать резервную копию заключительного фрагмента журнала в следующих сценариях.

• Если база данных находится в режиме «в сети» и следующим действием над базой данных должна быть операция восстановления, то прежде необходимо выполнить резервное копирование заключительного фрагмента журнала. Во избежание ошибок в базе данных, работающей в режиме «в сети», необходимо использовать параметр WITH NORECOVERY инструкции BACKUP Transact-SQL.

• Если база данных, работающая в режиме «вне в сети», не запускается и необходимо восстановить базу данных, то в первую очередь необходимо выполнить резервное копирование заключительного фрагмента журнала. Так как в это время никакие транзакции не выполняются, параметр WITH NORECOVERY использовать не обязательно.

• Если база данных повреждена, попытайтесь получить резервную копию заключительного фрагмента журнала, используя параметр WITH CONTINUE_AFTER_ERROR инструкции BACKUP.

  Резервное копирование заключительного фрагмента журнала поврежденной базы данных может быть успешно выполнено только в том случае, если файлы журнала не повреждены, а база данных находится в режиме, который поддерживает резервное копирование заключительного фрагмента журнала, и не содержит какие-либо изменения с неполным протоколированием. Если резервная копия заключительного фрагмента журнала не может быть создана, то любые транзакции, зафиксированные после создания последней резервной копии журнала, будут потеряны.

В следующей таблице представлена сводка параметров BACKUP NORECOVERY и CONTINUE_AFTER_ERROR.

Параметр BACKUP LOG

Комментарии

NORECOVERY	Если планируется продолжить операцию восстановления базы данных, используйте параметр NORECOVERY. NORECOVERY переводит базу данных в состояние восстановления. Это гарантирует, что после создания резервной копии заключительного фрагмента журнала база данных не изменится. Если параметры NO_TRUNCATE или COPY_ONLY не заданы, то журнал усекается. Важно! Рекомендуется не использовать параметр NO_TRUNCATE, если база данных не повреждена.
CONTINUE_AFTER_ERROR	Параметр CONTINUE_AFTER_ERROR следует указывать только в том случае, если создается резервная копия заключительного фрагмента журнала поврежденной базы данных. Примечание При резервном копировании заключительного фрагмента журнала поврежденной базы данных, некоторые метаданные, захватываемые обычно в резервные копии журналов, могут быть недоступны. Дополнительные сведения см. в подразделе Резервное копирование заключительного фрагмента журнала с неполными метаданными резервной копии ниже в данном разделе.

Резервное копирование заключительного фрагмента журнала с неполными метаданными резервной копии

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

Если резервная копия заключительного фрагмента журнала содержит неполные метаданные, то параметр has_incomplete_metadata в таблице backupset принимает значение 1. Кроме того, выходной аргумент HasIncompleteMetadata инструкции RESTORE HEADERONLY принимает значение 1.

Если метаданные в резервной копии заключительного фрагмента журнала неполные, то в таблице backupfilegroup большая часть сведений о файловых группах того времени в резервной копии заключительного фрагмента журнала будет утеряна. Большинство столбцов таблицы backupfilegroup содержит значение NULL, другие значения имеют следующие столбцы:

• backup_set_id

• filegroup_id

• тип

• type_desc

• is_readonly

Связанные задачи

О создании резервной копии заключительного фрагмента журнала см. в разделе Создание резервной копии журнала транзакций при повреждении базы данных (SQL Server).

О восстановлении резервной копии журнала транзакций см. в разделе Восстановление резервной копии журнала транзакций (SQL Server).

[В начало]

См. также

Отсутствует.

[В начало]

См. также

Справочник

BACKUP (Transact-SQL)

RESTORE (Transact-SQL)

Основные понятия

Резервное копирование и восстановление баз данных SQL Server

Резервные копии только для копирования (SQL Server)

Резервные копии журналов транзакций (SQL Server)

Применение резервных копий журналов транзакций (SQL Server)

msdn.microsoft.com

Help, my database is corrupt. Now what? / Хабр

Поврежденная база данных — это, наверное, один из худших ночных кошмаров большинства администраторов баз данных. Результатом повреждения являются простои, вопли менеджеров и всякие другие неприятные штуки. В этой статье я объясню что нельзя делать с поврежденной базой данных и опишу кое-что из того, что должно быть сделано, некоторые виды повреждений и как их можно исправить.

Как обнаружить, что база данных повреждена

Обычно повреждения превосходно обнаруживаются при попытке доступа к поврежденной странице. Запросы, бэкапы или процедуры реиндексации завершаются ошибками с высокими уровнями серьезности. Вот пара примеров системных сообщений при обнаружении повреждения БД:SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file 'D:\Develop\Databases\Broken1.mdf'.Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816. Основная проблема заключается в том, что если проверки целостности базы данных не производятся на постоянной основе, то повреждение может быть обнаружено спустя часы, дни и даже месяцы, после того, как оно образовалось, в тот момент, когда уже сложно будет что-то исправить. Я не буду описывать ситуацию когда база данных перешла в состояние «suspect» («подозрительная» в русской редакции SQL Server — прим. переводчика). Описание всевозможных причин почему база данных может перейти в «suspect» и множества вариантов исправления этого — тема отдельной статьи, если не книги.

Что делать если база данных все-таки повреждена

1. Не паниковать
2. Не отсоединять (detach) ее
3. Не перезапускать SQL Server
4. Не начинать восстановление сразу
5. Запустить проверку целостности
6. Найти причину

Не паниковать

Самое важное, при обнаружении повреждения БД — это не паниковать. Любые принимаемые решения должны быть тщательно взвешаны, во внимание должны быть приняты все возможные факторы. Чертовски просто ухудшить ситуацию приняв не до конца обдуманное решение.

Не отсоединять базу данных

В большинстве случаев, когда SQL Server обнарживает повреждение базы данных, это означает, что в БД на самом деле есть поврежденные страницы. Попытка убедить SQL Server что это не так, путем отсоединения (detach) и повторного присоединения (attach) БД, бэкапа и последующего восстановления, перезапуска службы SQL Server, либо перезагрузки сервера, не приведет к тому, что ошибка исчезнет. Если база данных повреждена и SQL Server обнаружит это при присоединении, он не сможет присоединить ее. Есть несколько способов заставить его увидеть эту БД, но намного лучше просто не отсоединять ее.

Не перезапускать SQL Server

Точно так же, как при отсоединении-присоединении, перезапуск службы SQL Server не сможет исправить обнаруженные ошибки (если они есть). Перезапуск службы может сделать ситуацию хуже. Если SQL Server обнаружит ошибки во время выполнения фазы восстановления (recovery) БД после перезапуска, он пометит ее как «suspect», что сильно усложнит процесс восстановления БД.

Не начинать восстановление сразу

У вас может возникнуть соблазн просто запустить DBCC CHECKDB с одним из «восстановительных» параметров (обычно допускающими потерю данных) и надеяться, что все станет лучше (по моему опыту — первое что рекомендуют на «непрофильных» форумах по SQL Server — запустить DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS — прим. переводчика). Во многих случаях запуск такого восстановления не рекомендуется. Он не гарантирует исправления всех ошибок и может привести к недопустимой потере данных. Такое восстановление — это последний шаг при исправлении ошибок. Оно должно быть запущено только если у вас уже нет другого выбора, но никак не в первую очередь.

Запустить проверку целостности

Для того чтобы решить как исправить базу данных, мы точно должны знать что именно повреждено. Единственный способ, которым мы можем это выяснить — запустить DBCC CHECKDB с параметром All_ErrorMsgs (в SQL Server 2005 SP3, SQL Server 2008 SP1 и в более старших версиях, этот параметр включен по умолчанию, указывать его не обязательно). Помните, что если вы запустите DBCC CHECKDB без параметра No_InfoMsgs, в выводе этой процедуры будет информация о количестве строк и страниц в каждой таблице, что вряд ли будет вас интересовать при анализе ошибок. DBCC CHECKDB может долго выполняться на больших БД, но необходимо дождаться пока эта процедура не закончит работу. Грамотная стратегия восстановления может быть построена только при наличии информации обо всех проблемах в БД.

Найти причину

После того как ошибки исправлены, работу нельзя считать законченной. Если причина этих ошибок не установлена, они могут возникнуть снова. Обычно, основной причиной ошибок являются проблемы с подсистемой ввода-вывода, но они также могут быть вызваны неправильной работой «низкоуровнего ПО» (вроде антивируса), действиями человека, либо багами самого SQL Server.

Что дальше

Дальнейшие действия по исправлению ошибок целиком и полностью зависят от результатов выполнения CheckDB. Чуть дальше я покажу несколько наиболее часто возникающих ошибок (учтите, что эта статья не претендует на звание полного описания всевозможных ошибок). Описанные ошибки располагаются по возрастанию уровня серьезности — от наименее серьезных к наиболее серьезным. В общем-то, для наиболее серьезных ошибок, находимых CheckDB, есть описание доступных методов их резрешения. Если у вас вдруг обнаружится ошибка не описанная в статье, обратите внимание на последний раздел — «Поиск помощи».

Неверная информация о свободном месте на странице

Msg 2508, Level 16, State 3, Line 1 The In-row data RSVD page count for object «Broken1», index ID 0, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.В SQL Server 2000, количество строк и страниц в таблице или индексе, хранящееся в метаданных, могло не соответствовать действительности (и даже быть отрицательным) и DBCC CHECKDB не видел в этом ничего плохого. В SQL Server 2005, это количество должно быть правильным и CheckDB выдаст предупреждение, если вдруг найдет несоответствие. Это несерьезная прблема и очень легко разрешается. Как говорится в сообщении, нужно всего лишь запустить DBCC UPDATEUSAGE в контексте нужной БД и предупреждение исчезнет. Эта ошибка часто встречается в базах данных обновленных с SQL Server 2000 и не должна появляться в базах данных, созданных в SQL Server 2005/2008.Msg 8914, Level 16, State 1, Line 1 Incorrect PFS free space information for page (1:26839) in object ID 181575685, index ID 1, partition ID 293374720802816, alloc unit ID 76911687695381 (type LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL.Эта ошибка появляется, когда PFS-страница (Page Free Space), которая учитывает насколько заполнены страницы в БД, содержит некорректные значения. Эта ошибка, как и упомянутая ранее, не является серьезной. Алгоритм, по которому определялось насколько заполнены страницы, в SQL Server 2000 не всегда отрабатывал правильно. Для решения этой проблемы нужно запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS и, если это единственная ошибка в БД, никакие данные, на самом деле, не пострадают.

Повреждение только некластерных индексов

Если все ошибки, найденные CheckDB, относятся к индексам с ID = 2 и больше, это означет, что были повреждены только некластерные индексы. Поскольку информация, содержащаяся в некластерных индексах, является «избыточной» (те же самые данные хранятся в куче, либо в кластерном индексе — прим. переводчика), эти повреждения могут быть исправлены без потери каких-либо данных. Если все ошибки, найденные CheckDB, относятся к некластерным индексам, рекомендуемый «уровень восстановления» для DBCC CHECKDB — REPAIR_REBUILD. Примеры таких ошибок (на самом деле ошибок такого типа намного больше):Msg 8941, Level 16, State 1, Line 1 Table error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted [i].offset >= PAGEHEADSIZE) failed. Slot 159, offset 0x1 is invalid.Msg 8942, Level 16, State 1, Line 1 Table error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted[i].offset >= max) failed. Slot 0, offset 0x9f overlaps with the prior row. В этом случае, повреждение может быть полностью исправлено удалением поврежденных некластерных индексов и повторным их созданием. Перестроение индекса (ALTER INDEX REBUILD) в режиме on-line (и иногда в off-line) читает страницы старого индекса для создания нового и, следовательно, завершится с ошибкой. Поэтому, необходимо удалить старые индексы и создать их заново. Именно это сделает DBCC CHECKDB с параметром REPAIR_REBUILD, но база данных при этом должна быть в однопользовательском режиме. Вот почему обычно лучше вручную выполнить эти операции, чтобы с базой данных можно было продолжать работать, пока индексы будут пересоздаваться. Если у вас недостаточно времени на то, чтобы пересоздать нужные индексы и в наличии есть «чистый» (не содержащий в себе ошибок) полный бэкап и бэкапы журнала транзакций с неразорванной цепочкой журналов, вы можете восстановить поврежденные страницы из них.

Повреждение LOB-страниц

Msg 8964, Level 16, State 1, Line 1 Table error: Object ID 181575685, index ID 1, partition ID 72057594145669120, alloc unit ID 72057594087800832 (type LOB data). The off-row data node at page (1:2444050), slot 0, text ID 901891555328 is not referenced.Ошибка говорит о том, что существуют LOB-страницы (Large OBject), на которые не ссылается ни одна страница с данными. Такое может произойти, если ранее был поврежден кластерный индекс (или куча) и его поврежденные страницы были удалены. Если CheckDB говорит только о таких ошибках, то можно запускать DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS — эти страницы будут уничтожены. Поскольку у вас все равно нет страниц с данными, которые ссылаются на эти страницы, бОльшей потери данных уже не будет.

Ошибки, связанные с выходом за пределы допустимого диапазона

Msg 2570, Sev 16, State 3, Line 17 Page (1:1103587), slot 24 in object ID 34, index ID 1, partition ID 281474978938880, alloc unit ID 281474978938880 (type «In-row data»). Column «modified» value is out of range for data type «datetime». Update column to a legal value.Эти ошибки показывают, что в столбце есть значения выходящие за пределы допустимого диапазона. Это может быть значение типа datetime, предполагающее, что с полуночи прошло больше 1440 минут, строка-Unicode, в которой количество байт не делится на 2, или float/real с неверным значением точности. Проверка на эти ошибки не выполняется по умолчанию, для баз данных обновленных с версии SQL Server 2000 или более ранних, если перед этим ни разу не выполнялась команда DBCC CHECKDB со включенным параметром DATA_PURITY. CheckDB не сможет исправить эти ошибки, поскольку неизвестно какие значения поставить взамен неправильных. Исправление таких ошибок не требует особых усилий, но выполняется вручную. Неправильные значения должны быть заменены на что-нибудь приемлимое. Основная проблема — это поиск неверных значений. В этой статье базы знаний есть пошаговая инструкция.

Повреждение кластерного индекса или кучи

Если обнаруживается, что повреждены страницы кучи или листового уровня (leaf pages) кластерного индекса — это означает, что данные на них потеряны. Страницы листового уровня кластерного индекса содержат непосредственно страницы данных и для них избыточность никак не обеспечивается. Если CheckDB сообщает о повреждении страниц листового уровня кластерного индекса, необходимый «уровень восстановления» для DBCC CHECKDB — REPAIR_ALLOW_DATA_LOSS. Примеры таких ошибок:Server: Msg 8976, Level 16, State 1, Line 2 Table error: Object ID 181575685, index ID 1, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data). Page (1:22417) was not seen in the scan although its parent (1:479) and previous (1:715544) refer to it.Server: Msg 8939, Level 16, State 1, Line 2 Table error: Object ID 181575685, index ID 0, page (1:168576). Test (m_freeData >= PAGEHEADSIZE && m_freeData <= (UINT)PAGESIZE — m_slotCnt * sizeof (Slot)) failed. Values are 44 and 8028.Следует помнить, что если ошибки, возвращаемые CheckDB, относятся к index id = 0 или 1, это значит, что повреждены непосредственно данные. Такой тип ошибок исправляется, но исправление заключается в уничтожении строк или целых страниц. Когда CheckDB удаляет данные для исправления ошибки, ограничения, налагаемые внешними ключами, не проверяются и никакие триггеры не срабатывают. Строки или страницы просто удаляются. В результате данные могут оказаться не согласованными, либо может быть нарушена логическая целостность (на LOB-страницы может больше не ссылаться ни одна строка, либо строки некластерного индекса могут указывать «в никуда»). Из-за таких последствий, подобное восстановление, не рекомендуется использовать. Если у вас есть «чистый» бэкап, восстановление из него обычно является более предпочительным, для исправления таких ошибок. Если база данных находится в полной модели восстановления и у вас есть бэкапы журнала транзакций с неразорванной цепочкой журналов (начиная с последнего «чистого» полного бэкапа), вы можете сделать бэкап активной части лога и восстановить базу данных целиком (или только поврежденные страницы), в результате чего данные вообще не будут потеряны. Если бэкапа с неповрежденными данными нет, у вас остается только один вариант — запуск DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Это потребует перевода базы данных в однопользовательский режим на все время выполнения этой процедуры. И хотя у вас нет возможности избежать потери данных, вы можете посмотреть какие данные будут удалены из кластерного индекса. Для этого, посмотрите этот пост Пола Рэнадала.

Повреждение метаданных

Msg 3853, Level 16, State 1, Line 1 Attribute (object_id=181575685) of row (object_id=181575685,column_id=1) in sys.columns does not have a matching row (object_id=181575685) in sys.objects.Подобные ошибки, обычно, возникают в базах данных, обновленных с SQL Server 2000, когда кто-то ковырялся напрямую в системных таблицах. В системных таблицах любой версии SQL Server внешние ключи не используются, поэтому в SQL Server 2000 была возможность удалить строку из sysobjects (например, таблицу) и оставить в таблицах syscolumns и sysindexes строки, ссылающиеся на удаленную строку. В SQL Server 2000 CheckDB не проверял целостность системного каталога и такие проблемы зачастую висели незамеченными. В SQL Server 2005, CheckDB проверяет целостность системного каталога и такие ошибки могут проявиться. Исправление этих ошибок дело не самое легкое. CheckDB не может их исправить, поскольку единственное что можно сделать — это удалить записи из системных таблиц, что, в свою очередь, может вызвать потерю большого количества данных. Если у вас есть бэкап этой БД, сделанный до обновления на SQL Server 2005 и обновление было совсем недавно, вы можете развернуть его на SQL Server 2000, на нем вручную подправить системные таблицы и снова перенести БД на SQL Server 2005. Если у вас нет бэкапа БД на SQL Server 2000 или обновление прошло слишком давно и потеря данных неприемлима, есть два пути. Первый — отредактировать системные таблицы в SQL Server 2005, но следует учитывать, что это довольно сложный и рискованный процесс, поскольку системные таблицы не документированы и гораздо более сложны, чем в ранних версиях. В этом посте можно найти дополнительную информацию. Второй путь — это заскриптовать все объекты БД и экспортировать все данные, после чего создать новую базу данных, восстановить объекты и залить данные. Этот вариант более предпочтителен.

Неисправимые повреждения

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

Повреждение системных таблиц

Msg 7985, Level 16, State 2, Line 1 System table pre-checks: Object ID 4. Could not read and latch page (1:358) with latch type SH. Check statement terminated due to unrepairable error.Msg 8921, Level 16, State 1, Line 1 Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent.CheckDB зависит от нескольких критически важных системных таблиц, для того чтобы получить представление о том, что должно быть в базе данных. Если сами эти таблицы повреждены, то CheckDB не может даже предположить что должно быть в базе данных и с чем сравнить текущее положение дел, не говоря уже о том, чтобы что-то исправить.

Повреждение «карт распределения»

Msg 8946, Level 16, State 12, Line 1 Table error: Allocation page (1:2264640) has invalid PFS_PAGE page header values. Type is 0. Check type, alloc unit ID and page ID on the page.Msg 8998, Level 16, State 2, Line 1 Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 13 pages from (1:2264640) to (1:2272727)В этом случае, одна или несколько страниц определяющих размещение данных в БД (карты распределения — прим. переводчика) повреждены. Эти страницы используются для того чтобы определять какие страницы и экстенты в БД используются, а какие свободны. CheckDB не может исправить такие ошибки, поскольку практически невозможно определить (без этих страниц) какие экстенты используются для размещения данных, а какие нет. Простое удаление такой «карты распределения» невозможно, поскольку удаление любой из них повлечет за собой удаление 4 GB данных.

Поиск помощи

Если вы не уверены в том что вам нужно сделать — обратитесь за помощью. Если вдруг вы получаете сообщение о повреждении БД, которое вам непонятно и которое не описано выше — обратитесь за помощью. Если вы не уверены в том, что выбрали наилучший метод восстановления — обратитесь за помощью. Если у вас есть Senior DBA, обратитесь к нему. Если у вас есть «наставник» — спросите у него. Спросите совета на форумах, но помните, что не все советы полученные на форумах полезны. На самом деле, именно там время от времени публикуются абсолютно неправильные и даже опасные решения. Обратитесь в службу поддержки Microsoft, наконец. Это будет небесплатно, но они действительно знают что можно сделать с поврежденной базой данных и вполне вероятно, что если ваша база данных критична для предприятия, то стоимость простоя во время самостоятельного поиска решения будет намного выше чем стоимость обращения в саппорт.

Заключение

В этой статье я дал несколько примеров того, что можно сделать при обнаружении поврежденной БД и, что даже важнее, того, что делать не надо. Надеюсь, что теперь вы лучше понимаете какие методы можно применять для решения описанных проблем и насколько важно иметь хорошие бэкапы (и правильно выбрать модель восстановления — прим. переводчика).

Примечание: это мой первый перевод, который, к тому же делался не за раз, а в несколько подходов, вечерами, когда появлялось свободное время, поэтому текст целиком, возможно, кому-то покажется несколько несогласованым. Если где-то я был излишне косноязычен и какая-то часть текста вдруг окажется трудной для понимания — с радостью выслушаю все замечания. С уважением, unfilled. P.S. Когда я уже собрался было нажать на кнопочку «Опубликовать», мне на почту свалилась рассылка от SQL Server Central с вот таким вот комиксом.

habr.com

Резервные копии заключительного фрагмента журнала (SQL Server)

• 03/08/2017
• Время чтения: 6 мин
• Соавторы

В этой статье

В данном разделе рассматриваются вопросы резервного копирования и восстановления только тех баз данных SQL ServerSQL Server , которые используют модель полного восстановления или модель восстановления с неполным протоколированием.This topic is relevant only for backup and restore of SQL ServerSQL Server databases that are using the full or bulk-logged recovery models.

В резервную копию заключительного фрагмента журнала попадают все записи, резервная копия которых еще не была создана ( заключительный фрагмент журнала), что позволяет предотвратить потерю работы и сохранить неповрежденную цепочку журналов.A tail-log backup captures any log records that have not yet been backed up (the tail of the log) to prevent work loss and to keep the log chain intact. Для восстановления базы данных SQL ServerSQL Server на последний момент времени необходимо предварительно выполнить резервное копирование заключительного фрагмента журнала ее транзакций.Before you can recover a SQL ServerSQL Server database to its latest point in time, you must back up the tail of its transaction log. Заключительный фрагмент журнала является становится последней рассматриваемой частью резервной копии в плане восстановления базы данных.The tail-log backup will be the last backup of interest in the recovery plan for the database.

Примечание

Не для всех сценариев восстановления требуется резервная копия заключительного фрагмента журнала.Not all restore scenarios require a tail-log backup. Резервная копия заключительного фрагмента журнала не нужна, если точка восстановления содержится в более ранней резервной копии журнала.You do not need a tail-log backup if the recovery point is contained in an earlier log backup. Кроме того, резервная копия заключительного фрагмента журнала не требуется при перемещении или замещении (перезаписи) базы данных, при котором не нужно восстанавливать ее на определенный момент времени после создания ее последней резервной копии.Also, a tail-log backup is unnecessary if you are moving or replacing (overwriting) a database and do not need to restore it to a point of time after its most recent backup.

Сценарии, в которых требуется резервная копия заключительного фрагмента журнала.Scenarios That Require a Tail-Log Backup

Рекомендуется формировать резервную копию заключительного фрагмента журнала в следующих сценариях.We recommend that you take a tail-log backup in the following scenarios:

• Если база данных находится в режиме «в сети» и следующим действием над базой данных должна быть операция восстановления, то прежде необходимо выполнить резервное копирование заключительного фрагмента журнала.If the database is online and you plan to perform a restore operation on the database, begin by backing up the tail of the log. Во избежание ошибок для оперативной базы данных необходимо использоватьTo avoid an error for an online database, you must use the … Параметр WITH NORECOVERY резервного КОПИРОВАНИЯ Transact-SQLTransact-SQL инструкции.WITH NORECOVERY option of the BACKUPTransact-SQLTransact-SQL statement.

• Если база данных, работающая в режиме «вне в сети», не запускается и необходимо восстановить базу данных, то в первую очередь необходимо выполнить резервное копирование заключительного фрагмента журнала.If a database is offline and fails to start and you need to restore the database, first back up the tail of the log. Так как в это время никакие транзакции не выполняются, параметр WITH NORECOVERY использовать не обязательно.Because no transactions can occur at this time, using the WITH NORECOVERY is optional.

• Если база данных повреждена, попытайтесь получить резервную копию заключительного фрагмента журнала, используя параметр WITH CONTINUE_AFTER_ERROR инструкции BACKUP.If a database is damaged, try to take a tail-log backup by using the WITH CONTINUE_AFTER_ERROR option of the BACKUP statement.

  Резервное копирование заключительного фрагмента журнала поврежденной базы данных может быть успешно выполнено только в том случае, если файлы журнала не повреждены, а база данных находится в режиме, который поддерживает резервное копирование заключительного фрагмента журнала, и не содержит какие-либо изменения с неполным протоколированием.On a damaged database backing up the tail of the log can succeed only if the log files are undamaged, the database is in a state that supports tail-log backups, and the database does not contain any bulk-logged changes. Если резервная копия заключительного фрагмента журнала не может быть создана, то любые транзакции, зафиксированные после создания последней резервной копии журнала, будут потеряны.If a tail-log backup cannot be created, any transactions committed after the latest log backup are lost.

  В следующей таблице представлена сводка параметров BACKUP NORECOVERY и CONTINUE_AFTER_ERROR.The following table summarizes the BACKUP NORECOVERY and CONTINUE_AFTER_ERROR options.

Параметр BACKUP LOGBACKUP LOG option КомментарииComments

NORECOVERYNORECOVERY	Если планируется продолжить операцию восстановления базы данных, используйте параметр NORECOVERY.Use NORECOVERY whenever you intend to continue with a restore operation on the database. NORECOVERY переводит базу данных в состояние восстановления.NORECOVERY takes the database into the restoring state. Это гарантирует, что после создания резервной копии заключительного фрагмента журнала база данных не изменится.This guarantees that the database does not change after the tail-log backup. Если параметры NO_TRUNCATE или COPY_ONLY не заданы, то журнал усекается.The log is truncated unless the NO_TRUNCATE option or COPY_ONLY option is also specified. ** Важные * * ** мы рекомендуем не использовать параметр NO_TRUNCATE, если база данных повреждена.** Important **** We recommend that you avoid using NO_TRUNCATE, except when the database is damaged.
CONTINUE_AFTER_ERRORCONTINUE_AFTER_ERROR	Параметр CONTINUE_AFTER_ERROR следует указывать только в том случае, если создается резервная копия заключительного фрагмента журнала поврежденной базы данных.Use CONTINUE_AFTER_ERROR only if you are backing up the tail of a damaged database. Примечание: При использовании резервного копирования заключительного фрагмента журнала поврежденной базы данных, некоторые метаданные, захватываемые обычно в резервные копии журналов могут быть недоступны.Note: When you use back up the tail of the log on a damaged database, some of the metadata ordinarily captured in log backups might be unavailable. Дополнительные сведения см. в подразделе Резервное копирование заключительного фрагмента журнала с неполными метаданными резервной копии ниже в данном разделе.For more information, see Tail-Log Backups That Have Incomplete Backup Metadata, later in this topic.

Резервное копирование заключительного фрагмента журнала захватывает конец журнала даже в тех случаях, когда база данных работает вне сети, повреждена или в ней не хватает файлов данных.Tail log backups capture the tail of the log even if the database is offline, damaged, or missing data files. В результате этого метаданные команд восстановления данных и базы данных msdbмогут быть неполными.This might cause incomplete metadata from the restore information commands and msdb. Однако несмотря на неполноту метаданных, захваченный журнал будет полным и готовым к использованию.However, only the metadata is incomplete; the captured log is complete and usable.

Если резервная копия заключительного фрагмента журнала содержит неполные метаданные, то параметр has_incomplete_metadata в таблице backupset принимает значение 1.If a tail-log backup has incomplete metadata, in the backupset table, has_incomplete_metadata is set to 1. Кроме того, выходной аргумент HasIncompleteMetadataинструкции RESTORE HEADERONLY принимает значение 1.Also, in the output of RESTORE HEADERONLY, HasIncompleteMetadata is set to 1.

Если метаданные в резервной копии заключительного фрагмента журнала неполные, то в таблице backupfilegroup большая часть сведений о файловых группах того времени в резервной копии заключительного фрагмента журнала будет утеряна.If the metadata in a tail-log backup is incomplete, the backupfilegroup table will be missing most of the information about filegroups at the time of the tail-log backup. Большинство столбцов таблицы backupfilegroup содержит значение NULL, другие значения имеют следующие столбцы:Most of the backupfilegroup table columns are NULL; the only meaningful columns are as follows:

Инструкции по созданию резервной копии журнала транзакций см. в разделе Резервное копирование журнала транзакций при повреждении базы данных (SQL Server).To create a tail-log backup, see Back Up the Transaction Log When the Database Is Damaged (SQL Server).

Инструкции по восстановлению резервной копии журнала транзакций см. в разделе Восстановление резервной копии журнала транзакций (SQL Server).To restore a transaction log backup, see Restore a Transaction Log Backup (SQL Server).

См. такжеSee Also

BACKUP (Transact-SQL) BACKUP (Transact-SQL) RESTORE (Transact-SQL) RESTORE (Transact-SQL) Резервное копирование и восстановление баз данных SQL Server Back Up and Restore of SQL Server Databases Резервные копии только для копирования (SQL Server) Copy-Only Backups (SQL Server) Резервные копии журналов транзакций (SQL Server) Transaction Log Backups (SQL Server) Применение резервных копий журналов транзакций (SQL Server)Apply Transaction Log Backups (SQL Server)

msdn.microsoft.com

Восстановление отдельных страниц в базе данных / Хабр

Предисловие

Статья Gail Shaw «Help, my database is corrupt. Now what?», перевод которой я запостил на прошлой неделе, вызвала, вроде бы, определенный интерес, но она, увы, не содержала «практики». Да, там написано как можно спасти данные, но нет никаких примеров. Изначально я хотел сделать еще один перевод все того же автора, но, подумав, решил написать пост «от себя», как бы «по мотивам». Причины, побудившие меня поступить так, я опишу в конце поста, в примечаниях.

Восстановление баз данных в SQL Server

Как уже было сказано в предыдущей статье, в том случае, если повреждены страницы кластерного индекса или кучи, то данные, содержащиеся на этих страницах, потеряны и единственным вариантом для их восстановления является непосредственно восстановление базы данных. SQL Server предоставляет множество возможностей для восстановления баз данных. Во-первых, это восстановление базы данных целиком — оно может занимать довольно много времени (зависит от размера БД и скорости жестких дисков). Во-вторых, восстановление отдельных файловых групп, либо файлов, если ваша БД состоит из нескольких файловых групп (или, соответствено, файлов). В этом случае, есть возможность восстановления только поврежденных частей БД, не затрагивая остальных. Эти два вида восстановления БД используются довольно часто и затрагиваться в дальнейшем не будут. В-третьих, в SQL Server 2005 появилась возможность восстановления отдельных страниц БД — в этом случае из бэкапа будут восстановлены только указанные страницы. Такое восстановление будет особенно актуально, если DBCC CHECKDB найдет несколько поврежденных страниц в какой-нибудь огромной таблице, «лежащей» в здоровенном файле. За счет того, что восстанавливаться будет не весь файл, и даже не вся таблица, а только несколько страниц — время простоя может быть значительно сокращено.

Требования и ограничения

Модель восстановления и доступность резервных копий журнала транзакций

Самое главное, что нужно помнить — для восстановления отдельных страниц, база данных должна использовать полную (full) модель восстановления, либо модель восстановления с неполным протоколированием (bulk-logged). Если ваши базы находятся в простой (simple) модели восстановления — дальше вы можете уже и не читать. Второе требование — ваши полные бэкапы и бэкапы журнала транзакций должны образовывать неразрывную цепочку журналов (log chain). Если вы никогда не выполняете команду BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) и не переключаетесь в простую модель восстановления для того, чтобы уменьшить журнал транзакций, и у вас есть ВСЕ резервные копии журнала транзакций с момента последней полной резервной копии не содержащей поврежденных страниц (включая эту самую полную резервную копию) — за цепочку журналов можно не волноваться. В модели восстановления с неполным протоколированием, теоретически, восстановление отдельных страниц должно работать нормально в том случае, если соблюдаются условия описанные выше, и восстанавливаемые страницы не изменялись операциями, выполняемыми с минимальным протоколированием.

Редакции SQL Server

Восстановление страниц возможно в любой редакции SQL Server, но для редакций Enterprise Edition и Developer Edition возможно восстановление поврежденных страниц on-line, т.е. к базе данных, во время восстановления, можно обращаться (и более того, обращаться можно даже к той таблице, к которой относятся восстанавливаемые в данный момент страницы, если сами эти страницы не будут «затрагиваться» — в противном случае, запрос завершится ошибкой). Для редакций «ниже» Enterprise Edition, восстановление страниц проходит в режиме off-line и база данных, на время восстановления, становится недоступной.

Тип поврежденной страницы

В том случае если повреждены страницы индекса, либо данных, их восстановление возможно в режиме online в редакции Enterprise Edition. Страницы, приндалежащие критически важным системным таблицам могут быть восстановлены, но база данных, при восстановлении, будет недоступна в любой редакции SQL Server. «Карты размещения» не могут быть восстановлены «отдельно». Если повреждены GAM, SGAM, PFS, ML, DIFF-страницы, необходимо восстанавливать базу данных целиком. Единственным исключением являются IAM-страницы. Хотя они и относятся к «картам размещения», но они описывают только одну таблицу, а не всю базу данных, и их восстановление возможно. Загрузочная страница базы данных (9-я страница в 1-м файле БД) и страница заголовка файла (0-я страница в каждом файле) не могут быть восстановлены «отдельно», при их повреждении придется восстанавливать БД целиком.

Собственно, восстановление

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

Портим БД

Для экспериментов я буду использовать базу данных AdventureWorks, которая поставляется вместе с SQL Server. Если вы не устанавливали ее, при желании, можно скачать здесь. Перевожу ее в модель восстановления full:ALTER DATABASE AdventureWorks SET RECOVERY FULLубеждаюсь, что ошибок в ней еще нет:DBCC CHECKDB('AdventureWorks') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITYи создаю полный бэкап:BACKUP DATABASE AdventureWorks TO DISK = 'D:\tmp\aw_backups\aw_full_ok1.bak' В этой базе данных я создаю таблицу crash.CREATE TABLE crash (txt varchar(1000))Поле типа varchar мы и будем портить, для того, чтобы проверить что произойдет, если вдруг SQL Server обнаружит в нем не те данные, которые он сам туда записал. Прежде чем что-то испортить, надо это чем-то заполнить. Я забиваю в созданную таблицу левые данные.SET NOCOUNT ON DECLARE @i INT SET @i = 1 WHILE @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE('a', 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:BACKUP LOG AdventureWorks TO DISK = 'D:\tmp\aw_backups\aw_log_ok1.trn' Теперь немного изменим данные: Итак, все готово. Отсоединяем БД и открываем mdf-файл FAR'ом (или чем вам удобнее), ищем в нем строку «zzzzzzz» и заменяем несколько 'z' на произвольные символы: Теперь, когда БД испорчена, подсоединяем ее. И, да, я помню, что в предыдущей статье было четко сказано, что отсоединять/присоединять БД не стоит. Но в нашем случае это абсолютно «безопасно» — база данных в «suspect» не упадет.

Ищем ошибки

Итак, испорченная БД успешно вернулась в строй. Снова запустим проверку целостности:DBCC CHECKDB('AdventureWorks') WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITYВ результате то, чего мы ждали (обязательно запоминайте номера поврежденных страниц!):

Msg 8928, Level 16, State 1, Line 1 Object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data): Page (1:20455) could not be processed. See other errors for details. Msg 8939, Level 16, State 98, Line 1 Table error: Object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data), page (1:20455). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 29493257 and -4. CHECKDB found 0 allocation errors and 2 consistency errors in table 'crash' (object ID 1883153754). CHECKDB found 0 allocation errors and 2 consistency errors in database 'AdventureWorks'. repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (AdventureWorks).В данном случае повреждены сами данные, находящиеся в куче (index id = 0), поэтому SQL Server эти данные восстановить не сможет. Сейчас у нас есть три варианта:

1. Смириться с потерей данных и выполнить DBCC CHECKDB('AdventureWorks', REPAIR_ALLOW_DATA_LOSS)
2. Сделать бэкап активной части журнала транзакций и восстановить БД целиком — в результате потери данных не будет, но это займет продолжительное время
3. Сделать бэкап активной части журнала транзакций и восстановить только одну(!), поврежденную, страницу

Со вторым вариантом все должно быть понятно, а вот что произойдет если запустить DBCC CHECKDB или как восстанавливаются отдельные страницы — я покажу дальше.

Восстанавливаем поврежденную страницу

В первую очередь нам надо сделать бэкап заключительного фрагмента журнала транзакций (tail backup). При этом, если у вас Enterprise Edition, вы можете не добавлять параметр NORECOVERY, который переведет БД в состояние «restoring», поскольку эта редакция поддерживает on-line восстановление страниц. Более того, если у вас резервные копии журнала транзакций выполняются на регулярной основе, чтобы не нарушать цепочку журналов, в редакции Enterprise Edition, вы можете сделать COPY_ONLY бэкап. Я же иду по пути off-line восстановления и выполняю:BACKUP LOG AdventureWorks TO DISK = 'D:\tmp\aw_backups\aw_log_fail3.trn' WITH NORECOVERY Теперь, можно восстанавливать поврежденную страницу. В первую очередь, используем полный бэкап (aw_full_ok1.bak):RESTORE DATABASE AdventureWorks PAGE = '1:20455' FROM DISK = 'D:\tmp\aw_backups\aw_full_ok1.bak' WITH NORECOVERY В итоге, имеем: Обратите внимание на то, что необходимо использовать опцию NORECOVERY, поскольку нам предстоит еще накатывать на нее бэкапы журнала транзакций.RESTORE LOG AdventureWorks FROM DISK = 'D:\tmp\aw_backups\aw_log_ok1.trn' WITH NORECOVERYиRESTORE LOG AdventureWorks FROM DISK = 'D:\tmp\aw_backups\aw_log_fail3.trn' WITH RECOVERY Вроде бы все прошло успешно, запускаем DBCC CHECKDB и… Восстановление прошло успешно. Обратите внимание, что время простоя сокращается за счет того, что из полного бэкапа мы восстанавливаем не всю БД, а только поврежденные страницы (если бы я восстанавливал бэкап целиком — бэкап восстановился бы за 8,5 секунд, но, чем больше размер БД — тем больше будет разница во времени). Счастливчики с SQL Server Enterprise Edition, использующие on-line восстановление, так же сэкономят время на восстановлении из бэкапов лога, а при off-line восстановлении, увы, журналы будут обрабатываться целиком. Стоит так же добавить, что в SQL Server 2005, 2008, 2008 R2 восстановление отдельной страницы возможно только с помощью T-SQL, в Denali появилась возможность делать это через GUI.

А если все-таки DBCC CHECKDB?

На всякий случай я решил проверить что сделает SQL Server, если я запущу DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Все та же ошибка: Сначала переводим БД в режим SINGLE_USER:ALTER DATABASE AdventureWorks SET SINGLE_USERА затем, запускаем восстановление:DBCC CHECKDB('AdventureWorks', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITYВ итоге:Repair: The page (1:20455) has been deallocated from object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data).Ага, SQL Server удалил «испорченную» страницу. Переводим БД в режим MULTI_USER, чтобы она стала доступной для всех и проверяем что пропало: Учитывая, что размер страницы в SQL Server 8КБ, а для пользовательских данных доступно чуть меньше — то все закономерно, таблица «похудела» на 7 записей (в начале их было 99999). Поскольку на этой таблице не было кластерного индекса, данные могли храниться в произвольном порядке, т.е. мы даже не могли узнать какие данные будут потеряны.

Так почему, все-таки, не перевод?

Итак, почему это все-таки не перевод, а пост «по мотивам». Дело в том, что, в открытом доступе статьи «Page Restore» за авторством Gail Shaw нет. Есть такой раздел в книге SQL Server MVP Deep Dives vol.2, которая продается за довольно-таки ощутимые деньги (но, естественно, легко находится в интернетах) и я не уверен, что публиковать перевод — это эм… правильно что ли. В общем, я прочитал статью, взял на заметку основные моменты, а потом уже сам писал текст и, попутно, проводил эксперимент по восстановлению. Надеюсь, кому-нибудь этот опыт был полезен. И, господа, я искренне надеюсь, что если вы решите повторять этот эксперимент, то будете предельно осторожны (например, не будете эксперементировать с основной БД на production-сервере). Помните, что никакой ответственности за ваши действия я не несу.

habr.com

Устранение неполадок при переполнении журнала транзакций (ошибка SQL Server 9002)

• 03/08/2017
• Время чтения: 6 мин
• Соавторы

В этой статье

В этом разделе описаны возможные действия при переполнении журнала транзакций, а также советы о том, как его избежать.This topic discusses possible responses to a full transaction log and suggests how to avoid it in the future. Когда журнал транзакций переполняется, в компоненте Компонент SQL Server Database EngineSQL Server Database Engine происходит ошибка 9002.When the transaction log becomes full, Компонент SQL Server Database EngineSQL Server Database Engine issues a 9002 error. Журнал может заполниться, когда база данных работает в режиме «в сети» или находится в процессе восстановления.The log can fill when the database is online or in recovery. Если журнал заполняется, когда база данных находится в режиме «в сети», база данных остается в режиме «в сети», но доступной только для чтения, но не для обновления.If the log fills while the database is online, the database remains online but can only be read, not updated. Если журнал заполняется, когда база данных находится в процессе восстановления, компонент Компонент Database EngineDatabase Engine помечает базу данных как RESOURCE PENDING.If the log fills during recovery, the Компонент Database EngineDatabase Engine marks the database as RESOURCE PENDING. В любом случае необходимо вмешательство пользователя, чтобы сделать журнал транзакций доступным.In either case, user action is required to make log space available.

Действия при переполнении журнала транзакцийResponding to a Full Transaction Log

Ответные действия при переполнении журнала транзакций частично зависят от условий, которые вызвали переполнение журнала.The appropriate response to a full transaction log depends partly on what condition or conditions caused the log to fill. Чтобы определить, что препятствует усечению журнала транзакций в конкретном случае, используйте столбцы log_reuse_wait и log_reuse_wait_desc представления каталога sys.database.To discover what is preventing log truncation in a given case, use the log_reuse_wait and log_reuse_wait_desc columns of the sys.database catalog view. Дополнительные сведения см. в разделе sys.databases (Transact-SQL).For more information, see sys.databases (Transact-SQL). Описание причин, которые могут задержать усечение журнала, см. в разделе Журнал транзакций (SQL Server).For descriptions of factors that can delay log truncation, see The Transaction Log (SQL Server).

Важно!

Если база данных была восстановления при возникновении ошибки 9002, после устранения проблемы, восстановить базу данных с помощью инструкции ALTER DATABASE имя_базы_данных SET ONLINE.If the database was in recovery when the 9002 error occurred, after resolving the problem, recover the database by using ALTER DATABASE database_name SET ONLINE.

При переполнении журнала транзакций предусмотрены следующие ответные действия:Alternatives for responding to a full transaction log include:

• создание резервной копии журнала;Backing up the log.

• освобождение места на диске, чтобы журнал мог автоматически расти;Freeing disk space so that the log can automatically grow.

• перемещение файла журнала на диск с достаточным объемом свободного места;Moving the log file to a disk drive with sufficient space.

• увеличение размера файла журнала;Increasing the size of a log file.

• добавление файла журнала на другой диск;Adding a log file on a different disk.

• завершение или уничтожение длительной транзакции.Completing or killing a long-running transaction.

  Эти возможности описаны в следующих разделах.These alternatives are discussed in the following sections. Выберите ответное действие, наиболее подходящее в конкретной ситуации.Choose a response that fits your situation best.

Создание резервной копии журналаBacking up the Log

Для полных моделей восстановления и моделей с неполным протоколированием резервное копирование может предотвратить усечение журнала транзакций, если оно не было сделано недавно.Under the full recovery model or bulk-logged recovery model, if the transaction log has not been backed up recently, backup might be what is preventing log truncation. Если резервная копия журнала создается в первый раз, необходимо сделать вторую резервную копию журнала, чтобы разрешить компоненту Компонент Database EngineDatabase Engine усечение журнала до точки последнего резервного копирования.If the log has never been backed up, you must create two log backups to permit the Компонент Database EngineDatabase Engine to truncate the log to the point of the last backup. Усечение журнала освобождает пространство для новых записей журнала.Truncating the log frees space for new log records. Чтобы избежать повторного переполнения журнала, следует чаще выполнять резервное копирование.To keep the log from filling up again, take log backups frequently.

Создание резервной копии журнала транзакцийTo create a transaction log backup

Освободите место на дискеFreeing Disk Space

Возможно, следует освободить место на диске, где находится файл журнала транзакций для базы данных. Для этого можно удалить или переместить другие файлы.You might be able to free disk space on the disk drive that contains the transaction log file for the database by deleting or moving other files. Освобожденное место на диске позволит системе восстановления автоматически увеличить размер файла журнала.The freed disk space allows the recovery system to enlarge the log file automatically.

Перемещение файла журнала на другой дискMoving the Log File to a Different Disk

Если на текущем диске невозможно освободить достаточное количество места, следует переместить файл на другой диск, где места достаточно.If you cannot free enough disk space on the drive that currently contains the log file, consider moving the file to another drive with sufficient space.

Важно!

Файлы журнала ни в коем случае не следует размещать в файловых системах со сжатием.Log files should never be placed on compressed file systems.

Чтобы переместить файл журналаTo move a log file

Увеличение размера файла журналаIncreasing the Size of a Log File

Если на диске, на котором находится журнал, доступно свободное место, можно увеличить размер файла журнала.If space is available on the log disk, you can increase the size of the log file. Максимальный объем файлов журнала составляет 2 терабайта (ТБ) на файл журнала.The maximum size for log files is two terabytes (TB) per log file.

Чтобы увеличить размер файлаTo increase the file size

Если автоувеличение отключено, база данных находится в режиме «в сети» и на диске достаточно свободного места, выполните одно из следующих действий.If autogrow is disabled, the database is online, and sufficient space is available on the disk, either:

• Вручную увеличьте размер файла для получения одного шага роста размера файла.Manually increase the file size to produce a single growth increment.

• Включить свойство автоматического увеличения при помощи инструкции ALTER DATABASE, чтобы установить отличное от нуля значение шага роста для параметра FILEGROWTH.Turn on autogrow by using the ALTER DATABASE statement to set a non-zero growth increment for the FILEGROWTH option.

Примечание

В любом случае, если достигнут текущий предел размера файла, увеличьте значение MAXSIZE.In either case, if the current size limit has been reached, increase the MAXSIZE value.

Добавление файла журнала на другой дискAdding a Log File on a Different Disk

Добавьте новый файл журнала базы данных на другом диске, где достаточно места, с помощью инструкции ALTER DATABASE <имя_базы_данных> ADD LOG FILE.Add a new log file to the database on a different disk that has sufficient space by using ALTER DATABASE <database_name> ADD LOG FILE.

Чтобы добавить файл журналаTo add a log file

См. такжеSee Also

ALTER DATABASE (Transact-SQL) ALTER DATABASE (Transact-SQL) Управление размером файла журнала транзакций Manage the Size of the Transaction Log File Резервные копии журналов транзакций (SQL Server) Transaction Log Backups (SQL Server) sp_add_log_file_recover_suspect_db (Transact-SQL)sp_add_log_file_recover_suspect_db (Transact-SQL)

msdn.microsoft.com

Аргументы инструкции RESTORE (Transact-SQL)

Эта документация перемещена в архив и не поддерживается.

В этом разделе документированы аргументы, описанные в разделах «Синтаксис» инструкции RESTORE {DATABASE|LOG} и связанного с ней набора вспомогательных инструкций: RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY, RESTORE REWINDONLY и RESTORE VERIFYONLY. Большинство аргументов поддерживается только вложенными наборами этих шести инструкций. Поддержка каждого аргумента указана в его описании.

Применимо для следующих объектов: SQL Server (начиная с SQL Server 2008 до текущей версии).

Синтаксические обозначения в Transact-SQL

Синтаксис см. в следующих разделах:

DATABASE

Поддерживается инструкцией  RESTORE

Указывает целевую базу данных. Если указан список файлов и файловых групп, то восстанавливаются только эти файлы и файловые группы.

Для базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, SQL Server в большинстве случаев требует, чтобы перед восстановлением базы данных была создана резервная копия конца журнала. Восстановление базы данных без создания резервной копии заключительного фрагмента журнала приведет к ошибке, если инструкция RESTORE DATABASE не содержит предложение WITH REPLACE или WITH STOPAT, в котором должно указываться время или транзакция, выполняемая после завершения резервного копирования данных. Дополнительные сведения о резервных копиях заключительного фрагмента журнала см. в разделе Резервные копии заключительного фрагмента журнала (SQL Server).

LOG

Поддерживается инструкцией  RESTORE

Указывает, что резервная копия журналов транзакций должна быть применена к базе данных. Журналы транзакций должны применяться в последовательном порядке. SQL Server проверяет резервные копии журнала транзакций, чтобы гарантировать, что транзакции загружаются в нужную базу данных и в верной последовательности. Для применения нескольких журналов транзакций следует использовать параметр NORECOVERY во всех операциях восстановления, кроме последней.

Примечание

Как правило, последний восстановленный журнал представляет собой резервную копию заключительного фрагмента журнала. Резервная копия tail-log backup является резервной копией заключительного фрагмента журнала, сделанной непосредственно после восстановления базы данных, обычно после отказа базы данных. Создание резервной копии заключительного фрагмента журнала поврежденной базы данных предотвращает потерю работы благодаря сохранению журнала, для которого еще не была создана резервная копия (заключительный фрагмент журнала). Дополнительные сведения см. в разделе Резервные копии заключительного фрагмента журнала (SQL Server).

Дополнительные сведения см. в разделе Применение резервных копий журналов транзакций (SQL Server).

{ database_name | @database_name_var}

Поддерживается инструкцией  RESTORE

База данных, в которую восстанавливается журнал или полная база данных. Если предоставляется как переменная (@database_name_var), это имя может быть указано как строковая константа (@database_name_var = database_name) или как переменная с типом данных символьной строки, за исключением типов данных ntext и text.

<file_or_filegroup_or_page> [ ,...n ]

Поддерживается инструкцией  RESTORE

Указывает имя логического файла или файловой группы или страницы, которая входит в инструкцию RESTORE DATABASE или RESTORE LOG. Можно указать список файлов или файловых групп.

Для базы данных, использующей простую модель восстановления, допускается использовать параметры FILE и FILEGROUP только в случае, если целевые файлы или файловые группы доступны только для чтения или если это восстановление PARTIAL (что в результате приводит к нефункционирующей файловой группе).

Для восстановления одного или нескольких файлов, файловых групп или страниц в базе данных, в которой используется полная модель восстановления или модель восстановления с неполным протоколированием, как правило, необходимо применить журнал транзакций к файлам, содержащим восстановленные файлы; благодаря применению журнала файлы согласуются с остальной базой данных. Из этого правила существуют следующие исключения:

• Если восстанавливаемые файлы были предназначены только для чтения перед последним резервным копированием, то журнал транзакций применять не нужно. Инструкция RESTORE информирует об этой ситуации.

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

FILE = { logical_file_name_in_backup| @logical_file_name_in_backup_var}

Указывает имя файла, который необходимо включить в восстановление базы данных.

FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }

Указывает имя файловой группы, которую необходимо включить в восстановление базы данных.

Примечание. Инструкцию FILEGROUP можно использовать в простой модели восстановления только в том случае, если указанная файловая группа доступна только для чтения и данная операция восстановления — частичная (то есть если используется инструкция WITH PARTIAL). Любые невосстановленные файловые группы, доступные для чтения и записи, отмечаются как несуществующие и впоследствии не могут быть восстановлены в результирующей базе данных.

READ_WRITE_FILEGROUPS

Выбирает все файловые группы, доступные для чтения и записи. Этот параметр особенно полезен, если файловые группы, доступные для чтения и записи, нужно восстановить раньше, чем файловые группы, доступные только для чтения.

PAGE = 'file:page [ ,...n ]'

Указывает список, состоящий из одной или нескольких страниц для операции восстановления страниц (которая поддерживается только для баз данных, использующих полную модель восстановления или модель восстановления с неполным протоколированием). Имеет следующие значения:

PAGE

Указывает список из одного или нескольких файлов и страниц.

file

Идентификатор файла, содержащего определенную страницу для восстановления.

page

Идентификатор страницы, подлежащей восстановлению в файле.

n

Заполнитель, который указывает, что можно задать несколько страниц.

Максимальное число страниц, которое можно восстановить в один файл в последовательности восстановления, — 1 000. Но если файл содержит большое количество поврежденных страниц, лучше восстанавливать не страницы, а весь файл целиком.

Примечание

Восстановленные страницы невозможно восстановить повторно.

Дополнительные сведения о восстановлении страниц см. в разделе Восстановление страниц (SQL Server).

[ ,...n ]

Заполнитель, который указывает, что можно задать в списке несколько файлов, файловых групп и страниц с разделителями-запятыми. Их число не ограничено.

FROM { <backup_device> [ ,...n ]| <снимок_базы_данных> }

Как правило, определяет устройства резервного копирования, с которых восстанавливаются резервные копии. В другом случае в предложении FROM инструкции RESTORE DATABASE можно указать имя моментального снимка базы данных, к которому возвращается база данных; в этом случае не разрешается применять предложение WITH.

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

<backup_device> [ ,...n ]

Указывает логическое или физическое устройство резервного копирования, используемое для операции восстановления.

Поддерживается инструкциями  RESTORE, RESTORE FILELISTONLY, RESTORE HEADERONLY, RESTORE LABELONLY, RESTORE REWINDONLY и RESTORE VERIFYONLY.

<backup_device>::=

Указывает логическое или физическое устройство резервного копирования, используемое для создания резервной копии, следующим образом:

{ logical_backup_device_name | @logical_backup_device_name_var }

Логическое имя устройства или устройств резервного копирования, созданных процедурой sp_addumpdevice, из которых восстанавливается база данных. Должно соответствовать правилам для идентификаторов. Если оно задано как переменная (@logical_backup_device_name_var), то имя устройства резервного копирования может быть задано в виде строковой константы (@logical_backup_device_name_var = logical_backup_device_name) или в виде переменной, имеющей тип данных символьной строки, кроме типов ntext и text.

{DISK | TAPE } = { 'physical_backup_device_name' | @physical_backup_device_name_var }

Разрешает сохранение резервных копий с названного диска или ленточного устройства хранения данных. Необходимо указать фактическое имя типов дисковых и магнитных устройств (например, полный путь и имя файла): DISK = 'Z:\SQLServerBackups\AdventureWorks.bak' или TAPE = '\\. \TAPE0'. Если данное имя приводится в качестве переменной (@physical_backup_device_name_var), то оно может представлять собой строковую константу (@physical_backup_device_name_var = 'physcial_backup_device_name') или переменную типа символьной строки, за исключением типов данных ntext и text.

Используя сетевой сервер с именем UNC (которое должно содержать имя компьютера), укажите тип дискового устройства. Дополнительные сведения об использовании имен UNC см. в разделе Устройства резервного копирования (SQL Server).

Учетная запись, под которой работает SQL Server, должна обладать доступом READ на удаленном компьютере или сетевом сервере, чтобы выполнять операцию RESTORE.

n

Заполнитель, который указывает, что можно задать в списке до 64 устройств резервного копирования с разделителями-запятыми.

Требует ли последовательность восстановления столько же устройств резервного копирования, сколько было использовано для создания набора носителей, которым принадлежат резервные копии, зависит от того, происходит восстановление в режиме «вне сети» или режиме «в сети», следующим образом:

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

• Восстановление в сети требует наличия всех устройств резервного копирования архива. Попытка произвести восстановление с меньшим числом устройств не удается.

Например, рассмотрим случай резервного копирования базы данных на четыре накопителя на магнитной ленте, подключенных к серверу. Для восстановления в сети необходимо иметь четыре накопителя, подключенных к серверу; восстановление вне сети позволяет восстановить резервную копию, если в компьютере менее четырех накопителей.

Примечание

Проводя восстановление из копии с зеркального набора носителей, можно указать по одному зеркалу для каждого семейства носителей. Но в случае ошибок наличие других зеркальных носителей позволяет быстро устранить некоторые проблемы восстановления. Можно заменить поврежденный том носителя соответствующим томом с другого зеркала. Учтите, что при восстановлении вне сети можно использовать меньше устройств, чем семейств носителей, но каждое семейство обрабатывается только один раз.

<database_snapshot>::=

Поддерживается инструкцией  RESTORE DATABASE

DATABASE_SNAPSHOT =database_snapshot_name

Возвращает базу данных к моментальному снимку базы данных, указанному database_snapshot_name. Аргумент DATABASE_SNAPSHOT доступен только для полного восстановления базы данных. При выполнении операции возврата к предшествующему состоянию моментальный снимок базы данных занимает место полной резервной копии базы данных.

Для операции возврата к предшествующему состоянию необходимо, чтобы указанный моментальный снимок базы данных был единственным для базы данных. В ходе операции возврата моментальный снимок базы данных и целевая база данных отмечаются как In restore. Дополнительные сведения см. в подразделе «Замечания» раздела Восстановление базы данных.

Параметры инструкции WITH

Указывает параметры, используемые для операции восстановления предшествующего состояния. Сводку инструкций, в которых используется каждый параметр, см. в секции «Сводка совместимости с параметрами WITH» ниже в данном разделе.

Примечание

Параметры WITH здесь организованы в порядке, описанном в подразделе «Синтаксис» раздела RESTORE {DATABASE|LOG}.

PARTIAL

Поддерживается инструкцией  RESTORE DATABASE

Указывает операцию частичного восстановления, которая восстанавливает первичную файловую группу и любые указанные вторичные файловые группы. Параметр PARTIAL неявно выбирает первичную файловую группу; указывать FILEGROUP = 'PRIMARY' не требуется. Чтобы восстановить вторичную файловую группу, необходимо явно задать ее с помощью параметра FILE или FILEGROUP.

Не разрешается применять параметр PARTIAL в инструкциях RESTORE LOG.

Параметр PARTIAL запускает начальный этап поэтапного восстановления, которое позволяет восстановить оставшиеся файловые группы позднее. Дополнительные сведения см. в разделе Поэтапное восстановление (SQL Server).

[ RECOVERY | NORECOVERY | STANDBY ]

Поддерживается инструкцией  RESTORE

RECOVERY

Настраивает операцию восстановления на откат любых незавершенных транзакций. После процедуры восстановления база данных готова к использованию. Если не указан ни один из параметров NORECOVERY, RECOVERY и STANDBY, RECOVERY является параметром по умолчанию.

Если запланированы последующие операции RESTORE (RESTORE LOG или RESTORE DATABASE из разностного архива), то вместо них следует указать параметры NORECOVERY или STANDBY.

При восстановлении из резервных наборов данных, созданных в более ранних версиях SQL Server, может потребоваться обновление базы данных. Это обновление выполняется автоматически, если указан параметр WITH RECOVERY. Дополнительные сведения см. в разделе Применение резервных копий журналов транзакций (SQL Server).

Примечание

Если предложение FROM опущено, то с предложением WITH должен быть указан параметр NORECOVERY, RECOVERY или STANDBY.

NORECOVERY

Настраивает операцию восстановления на отмену отката любых незавершенных транзакций. Если впоследствии должен применяться другой журнал транзакций, то следует указать параметр NORECOVERY или STANDBY. Если не указан ни один из параметров NORECOVERY, RECOVERY и STANDBY, RECOVERY является параметром по умолчанию. В ходе восстановления вне сети с использованием параметра NORECOVERY база данных непригодна для использования.

Для восстановления резервной копии базы данных и одного или нескольких журналов транзакций или в других случаях, когда необходимо применить несколько инструкций RESTORE (например, при восстановлении полной резервной копии базы данных с последующим разностным восстановлением базы), необходимо указать параметр WITH NORECOVERY для всех инструкций RESTORE, кроме последней. Лучший способ — использовать параметр WITH NORECOVERY во ВСЕХ инструкциях многоэтапной последовательности восстановления до тех пор, пока не будет достигнута желаемая точка восстановления, а затем использовать отдельную инструкцию RESTORE WITH RECOVERY только для восстановления.

При использовании с операцией восстановления файла или файловой группы параметр NORECOVERY принудительно оставляет базу данных в состоянии восстановления после операции восстановления. Это полезно в следующих ситуациях:

• Выполняется скрипт восстановления, и журнал всегда применяется.

• Используется последовательность восстановления файлов, и база данных не предназначена для использования между двумя операциями восстановления.

В некоторых случаях RESTORE WITH NORECOVERY переводит набор данных наката достаточно далеко вперед, чтобы он был совместим с базой данных. В таких случаях откат не производится и данные остаются вне сети, как и предполагается при использовании этого параметра. Однако компонент Компонент Database Engine выдает информационное сообщение о том, что теперь набор данных наката можно восстановить с помощью параметра RECOVERY.

STANDBY =standby_file_name

Указывает резервный файл, с помощью которого можно отменить результаты восстановления. Параметр STANDBY разрешается применять для восстановления вне сети (в том числе частичного восстановления). Параметр не разрешается использовать при восстановлении в сети. При попытке указать параметр STANDBY для восстановления в сети операция восстановления заканчивается неудачей. Инструкцию STANDBY также не разрешается применять, если необходимо обновление базы данных.

Резервный файл используется для сохранения прообраза страниц, измененных во время прохода отмены инструкции RESTORE WITH STANDBY. Благодаря резервному файлу базу данных можно сделать доступной только для чтения между транзакциями и использовать с сервером «горячего» резервирования или в особых ситуациях восстановления, когда полезно проверить базу данных между операциями восстановления журналов транзакций.

msdn.microsoft.com

---

• 
  Заключительный фрагмент журнала базы данных не был добавлен
• 
  Журнал бетонных работ в зимнее время пример заполнения
• 
  Журнал бетонных работ в зимнее время пример заполнения
• 
  Лабораторный журнал по физике для 7 класса ответы
• 
  Лабораторный журнал по физике для 7 класса ответы
• 
  Журнал выдачи дел во временное пользование из архива
• 
  Журнал выдачи дел во временное пользование из архива
• 
  Схема сборки кубика рубика из журнала юный техник
• 
  Схема сборки кубика рубика из журнала юный техник
• 
  Журнал вак современные исследования социальных проблем электронный журнал
• 
  Журнал пентхаус видео смотреть бесплатно в хорошем качестве