Sql restore headeronly прервано с ошибкой

Приглашаем разобраться в важных темах – устранения ошибок MS SQL и восстановления базы данных. Получите представление о разных способах устранения проблемы, которые следует использовать при различных обстоятельствах.

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

Специалисты пользуются несколькими способами восстановления баз данных (БД). Наиболее простой и удобный ­– воспользоваться программой (SSMS) SQL Server Management Studio.

Как восстановить

Узнать, где находится SQL Server Management Studio, довольно легко. Microsoft Windows Server 2012 R2 располагается в стандартном перечне программных продуктов. В Microsoft Windows Server 2008 R2 следует зайти в меню Пуск и отыскать Microsoft Windows Server 2012. Там смотреть Microsoft SQL Server Management Studio.

Далее следует ввести тип сервера с именем, а чтобы подтвердить подлинность – информацию, требуемую для прохождения авторизации. Нажать Соединить (Connect).

В левом углу из обозревателя (Object Explorer) раскрыть Базы данных (Server Objects). Из представленного перечня отобрать базу, подлежащую восстановлению либо ту, данные которой будут восстанавливаться. На выбранном файле кликнуть мышкой и в выпавшем перечне выбрать Задачи (Tasks), затем Восстановить (Restore), потом База данных… (Databases …).

Проделанные шаги дадут старт процессу Restore Database, а значит требуемая база данных начнет восстанавливаться. Следует сделать выбор источника для Restore Database.

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

1. Переключить соответствующую кнопку на Устройство (From device).
2. Прописать, откуда восстановится БД.
3. Выбрать инфобазу, в которую произведется загрузка данных (Destination for restore). Ею может выступать любая БД, которая регистрировалась на SQL Server (в том числе и база, с которой создавалась резервная копия).

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

Если требуется провести копирование БД, то во вкладке Файлы (Files) нужно будет прописать путь к файлам выбранной инфобазы.

Настройка дополнительных параметров

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

• Которая опубликована не на сервере, где она создавалась, сохранились настройки репликации, поможет отметка «Сохранить параметры репликации). Он важен, если при резервном копировании была реплицирована БД;
• была проведена перезапись файлов БД с именем, которое указывалось в качестве базы назначения – нужно поставить отметку «Перезаписать существующую базу данных»;
• сузить доступность к базе всем, кто не sysadmin, db_owner, dbcreator – нужно поставить флажок «Ограничение доступа к восстановленной базе данных»;
• старту должен предшествовать перевод БД в режим одного пользователя, а по его завершению вернуть в пользование для множества пользователей – поставить отметку «Закрыть существующие соединения»;
• чтобы провести требуемое резервное копирование завершающего фрагмента журнала транзакций, следует поставить отметку «Создание резервной копии заключительного фрагмента журнала перед восстановлением». Если в окошке Временная шкала резервного копирования (Backup Timeline) для временной точки требуется эта резервная копия, то отметка будет поставлена системой, без возможности снятия;
• чтобы после завершения восстановления каждой резервной копии уточнялась необходимость продолжения процесса – следует поставить отметку «Выдавать приглашение перед восстановлением каждой резервной копии» (Prompt before restoring each backup). Достаточно полезен, т.к. после того, как восстановлено определенное количество резервных копий можно остановить дальнейшую цепочку восстановительных процессов.

Настроив все важные параметры следует нажать ОК. Тем самым запустится процесс. Соответствующее уведомление сообщит об его окончании.

Восстановление базы в новое место

Чтобы перенести базу данных MSSQL Server по другому пути каталога либо сделать ее копию, следует знать, как восстановить БД в новую папку. Полезно знать как ее переименовывать. Для этого можно воспользоваться вышеупомянутой программой SSMS и T-SQL.

Подготовка к восстановлению базы данных

Перед стартом процесса восстановления нужно соблюдать ряд требований:

1. Когда осуществляется процесс восстановления базы, доступ к ней может быть только у системного администратора. Для остальных пользователей доступ должен быть ограничен.
2. Перед восстановлением нужно сделать резервную копию активного журнала транзакций.
3. Чтобы восстановить зашифрованную базу необходим доступ к сертификату либо ассиметричному ключу, который применялся в качестве ее шифратора. Не имея доступа к ним, восстановление зашифрованной БД становится невозможным. Потому, такой сертификат следует хранить, пока может понадобиться резервное копирование.

После того, как база данных версии SQL Server 2005 (9.x) либо более поздней, восстановится, произойдет автоматическое обновление, и она станет доступной.

Если присутствуют полнотекстовые индексы

В том случае, когда в БД SQL Server 2005 (9.x) присутствуют полнотекстовые индексы, в момент ее обновления произойдет импорт, сброс либо перестроение. Результат зависит от того, какое значение проставлено в свойствах сервера upgrade_option.

При обновлении такие индексы станут недоступны, если upgrade_option имеет значения:

• 2 в режиме импорта;
• 0 в режиме перестроения.

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

В том случае, когда выбран процесс Импорт, а доступ к полнотекстовому каталогу отсутствует, то произойдет перестроение одноименных индексов, которые связаны с ним. Для изменения свойств upgrade_option необходимо воспользоваться процедурой sp_fulltext_service.

Соблюдение правил безопасности

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

• запускать выполнение инструкций T-SQL, не предусмотренных системой;
• вызывать ошибки в результате изменения схемы либо самой структуры БД

Если БД получена из источников, не внушающих доверия, то перед началом ее использования необходимо:

• протестировать по инструкции DBCC CHECKDB;
• исследовать исходный и иные коды БД, изучить процедуры.

Инструкции RESTORE

На ход реализации этих инструкций влияет факт существования восстанавливаемой базы. Если база:

• присутствует, то разрешения получают пользователи sysadmin, dbcreator, dbo (владелец БД) по умолчанию;
• отсутствует, то пользователям потребуются разрешения CREATE DATABASE.

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

Пошаговая инструкция восстановления БД в новую папку в SSMS

1. Открыть SSMS и произвести подключение к SQL Server Database Engine.
2. Щелкнуть мышкой по имени сервера, чтобы развернулось его дерево.
3. Кликнуть мышкой на Базы данных, потом – по Восстановить базу данных.
4. В разделе Источник выбрать Общие, чтобы определить соответственное расположение и источник копий, подлежащих восстановлению. Пользователю предлагается выбрать нужный вариант (Базы данных либо Устройства). Особенности:
5. При выборе Базы данных открывается перечень БД, где можно выбрать нужную. В нем представлены лишь те базы, у которых резервные копии создавались по журналу msdb. Стоит отметить, что для БД на целевом сервере, резервные копии которых поступили с иных серверов, подобный журнал будет отсутствовать. В таких ситуациях следует выбирать вариант Устройство. Это позволит руками прописать файл, а в случае необходимости – обозначить устройство для выполнения восстановления.
6. Устройство можно выбрать, воспользовавшись кнопкой обзора (…). В результате появится окошко Выбор устройств резервного копирования. Перейти в окошко Тип носителя резервной копии, в котором из списка выбрать необходимый тип устройства. Если требуется добавить ряд устройств, это можно сделать с помощью кнопки Добавить в окошке Носитель резервной копии. Когда все необходимые устройства добавлены, необходимо вновь перейти на страницу Общие. Для этого следует нажать ОК в списке Носитель резервной копии. Обратившись к списку Источник: Устройство: База данных обозначить название БД, куда будет производиться восстановление. Пользователь может воспользоваться данным списком только при выборе Устройства. Можно выбирать лишь те БД, у которых на отобранном устройстве имеются резервные копии.
7. Название новой базы для проведения восстановления автоматом сформируется в поле База данных в разделе Назначение. При желании оно может быть изменено. Для этого желаемое название вводится в окошке База данных.
8. Далее перейти к Восстановить до. Пользователь может оставить значение До последней выбранной резервной копии (по умолчанию) либо кликнуть по Временной шкале. При выбре второго варианта всплывет соответствующее окошко Временная шкала …. В нем нужно указывать точное время.
9. Необходимые резервные копии для восстановления можно выбрать в соответствующей сетке. В ней отражены все наборы, доступные в выбранном месте. Система сама предложит план восстановления отобранных копий, который будет использован по умолчанию. Он может быть переопределен, если в сетке изменить отобранные элементы.
10. Для указания другого места расположения файлов базы, необходимо выбрать страницу Файлы после чего нажать на Переместить все файлы в папку. Следует указать вновь выбранное место расположения папок файлов данных и журнала.
11. Если возникла необходимость – провести настройку параметров, как было рассказано выше.

Чтобы начать процесс, в котором будет восстанавливаться БД в новую папку с возможностью переименовывать ее, можно воспользоваться инструкциями Transact-SQL.

Как просмотреть отчет

Стандартный отчет «События резервного копирования и восстановления» позволяет получить сведения о том, когда проводилось:

• Резервное копирование определенной БД;
• операции восстановления базы MS SQL из них.

Данный отчет включает данные, касающиеся создания резервных копий:

• время, затраченное на это в среднем (Average Time Taken For Backup Operations);
• операции, которые прошли успешно (Successful Backup Operations);
• ошибки, которые были допущены (Backup Operation Errors);
• удачно прошедших восстановлений баз (Successful Restore Operations).

Чтобы он начал формироваться, следует в Обозревателе объектов выбрать нужную БД и щелкнуть по ней мышкой. Выбрать в меню Отчеты, а затем – Стандартный отчет. После этого кликнуть на События резервного копирования и восстановления.

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

Для восстановления поврежденной БД можно воспользоваться еще одним инструментом.

Как исправить ошибки в MS SQL с помощью Recovery Toolbox for SQL Server

Для восстановления поврежденной базы данных можно обратиться к помощи Recovery Toolbox for SQL Server. Для исправления ошибки (Error), следует воспользоваться пошаговой инструкцией восстановления данных из файла *.mdf, который был поврежден. Для этого необходимо:

1. Скачать Recovery Toolbox for SQL Server.
2. Установить программу следуя инструкциям и запустить ее.
3. Из списка файлов выбрать файл *.mdf, который был поврежден.
4. Осуществить предварительный просмотр тех данных, которые в процессе выполнения программы могут быть подвергнуты извлечению из базы MS SQL сервер, которая подверглась повреждению.
5. Выбрать наиболее приемлемый способ, которым будут экспортироваться данные:
6. сохранением на диск в качестве SQL-скрипта;
7. выполнением SQL-скрипта в самой БД.
8. Произвести выборку информации, требующей восстановления и сохранения.
9. Начать восстановление нажатием Start recovery.

Данная программа создавалась, чтобы облегчить процесс восстановления поврежденных БД. Специально разработанная, оптимизированная для восстановления SQL Server, утилита поможет устранить ошибки и внести правки в разные типы повреждений *.mdf файлов и базы данных MS SQL Server.

Как становится понятно, для исправления ошибок и восстановления БД необходимо уметь пользоваться различными инструментами. Читайте, изучайте материалы по данной теме. Если возникнут вопросы – обязательно задавайте.

Также приглашаем на специальный курс по MS SQL в Otus.

sergey1982

10.11.13 — 12:48

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

МихаилМ

1 — 10.11.13 — 12:56

sergey1982

2 — 10.11.13 — 12:58

Читал. На 2008 сервере я указывал при восстановлении файл базы и лога. А в 2012 он не дает, все поля не активны.

sergey1982

3 — 10.11.13 — 12:59

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

МихаилМ

4 — 10.11.13 — 13:04

shuhard

5 — 10.11.13 — 13:04

(3) так бэкап полный или инкрементный

sergey1982

6 — 10.11.13 — 13:07

бекап полный

sergey1982

7 — 10.11.13 — 13:11

Номера ошибки нет, просто Выбираю базу данных, пустую, которую создал через 1с , дальше выбираю Задачи — Восстановить — база данных. Открывается окно гдн Источник , выбираю устройство и ище местоположения архива, Назначение — пустая база данных. А вот где Таблица с Восстанавливаемыми резервными наборами данных, которая, как я понимаю, определяет что за архив я буду разворачивать, эта таблица не активна, пустая. А когда все хорошо, она паказывает архив

МихаилМ

8 — 10.11.13 — 13:12

sergey1982

9 — 10.11.13 — 13:15

Вначале пишет Чтение заголовка устройств резервного копирования, идет зеленая полоса прогресса, а потом красный крестик Для восстановления не выбран резервный набор данных. Я не понимаю почему ему не нравятся архивы?

sergey1982

10 — 10.11.13 — 13:16

Может установить родной 2008 с которого архивы все делались вместо 2012

МихаилМ

11 — 10.11.13 — 13:20

sergey1982

12 — 10.11.13 — 13:23

секундочку

shuhard

13 — 10.11.13 — 13:23

sergey1982

14 — 10.11.13 — 13:24

sergey1982

15 — 10.11.13 — 13:26

sergey1982

16 — 10.11.13 — 13:27

МихаилМ

17 — 10.11.13 — 13:28

МихаилМ

18 — 10.11.13 — 13:29

sergey1982

19 — 10.11.13 — 13:31

не перейти по ссылке (

shuhard

20 — 10.11.13 — 13:36

(15) напиши ещё сто раз одно и то же

sergey1982

21 — 10.11.13 — 13:38

это мне адресовано?

sergey1982

22 — 10.11.13 — 13:41

короче задница полная, бухи останутся без работы

МихаилМ

23 — 10.11.13 — 13:45

sergey1982

24 — 10.11.13 — 14:28

он не дает мне изменить параметры восстановления !

МихаилМ

25 — 10.11.13 — 14:38

sergey1982

26 — 10.11.13 — 14:40

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

МихаилМ

27 — 10.11.13 — 14:46

sergey1982

28 — 10.11.13 — 14:49

sergey1982

29 — 10.11.13 — 14:50

МимохожийОднако

30 — 10.11.13 — 14:55

Кроме архивов SQL неплохо делать стандартную выгрузку из 1С

sergey1982

31 — 10.11.13 — 14:55

баз много, было бы несколько — запросто

sergey1982

32 — 10.11.13 — 14:55

беда совсем

sergey1982

33 — 10.11.13 — 14:56

Никак не зайти в параметры и не выбрать местоположение базы и журнала.

ilkoder

34 — 10.11.13 — 14:59

Ошибка здесь — Выбираю базу данных, пустую, которую создал через 1с — создай просто пустую базу через sql менеджер — в нее востанови базу, а потом укажи путь к ней для сервера 1с

sergey1982

35 — 10.11.13 — 15:00

МихаилМ

36 — 10.11.13 — 15:02

ilkoder

37 — 10.11.13 — 15:02

Когда создаешь базу через 1с — она уже будет не пустой — в ней будут куча таблиц 1с. если восстанавливать из dt, то да, а если скл — то нужно просто пустая  скл-база

sergey1982

38 — 10.11.13 — 15:03

так в пустую и восстанавливаю данные из архива

МихаилМ

39 — 10.11.13 — 15:03

ilkoder

40 — 10.11.13 — 15:05

(38) — пустую базу как создаешь?

sergey1982

41 — 10.11.13 — 15:05

sergey1982

42 — 10.11.13 — 15:06

Пустую создаю через значок 1с — создание новой базы

sergey1982

43 — 10.11.13 — 15:06

Вы думаете лучше создавать все только скулем?

МихаилМ

44 — 10.11.13 — 15:06

sergey1982

45 — 10.11.13 — 15:06

в свойствах программа пишет просто 2008 без R2

ilkoder

46 — 10.11.13 — 15:07

(43) — конечно

sergey1982

47 — 10.11.13 — 15:07

Михаил, он мне в опции не дает зайти (

sergey1982

48 — 10.11.13 — 15:09

Создал чере скуль — все то же самое

sergey1982

49 — 10.11.13 — 15:10

Михаил, как на Вашем скриншоте, я так всегда и восстанавливал в пустую базу. Но сейчас засада какая-то.

ilkoder

50 — 10.11.13 — 15:12

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

sergey1982

51 — 10.11.13 — 15:14

Как вы поняли, я не мега спец по СКУЛЮ, читаю Уильяма Станека, но прост осейчас надо все мегасрочно к завтра исправить. А что за таблица я не совсем понимаю?

sergey1982

52 — 10.11.13 — 15:15

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

sergey1982

53 — 10.11.13 — 15:20

Кстати вот эти архивные копии я скопировал на свой внешний жесткий диск, а хранились они на рэйде 10 ssd. Может при копировании на другой тип носителя архивная копия и глючит?

я уже нифига не понимаю

From the error message, it says there’s an error when validating the target (c:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDataLabTables.mdf) of your restore operation.

That sounds like:

a) that file already exists (because you’ve already restored it previously) and is in use by SQL Server

or

b) that directory doesn’t exist at all

In your question, you mentioned you created a backup for that table — that’s not how SQL Server backups work. Those backups are always the whole database (or at least one or several filegroups from that database).

My hunch is: you’ve already restored that database previously, and now, upon a second restore, you didn’t check the checkbox «Overwrite existing database» in your restore wizard — thus the existing file cannot be overwritten and the restore fails.

The user that’s running the restore on your remote server obviously doesn’t have access to that directory on the remote server.

C:program files.... is a protected directory — normal (non-admin) users don’t have access to this directory (and its subdirectories).

Easiest solution: try putting your BAK file somewhere else (e.g. C:temp) and restore it from there

From the error message, it says there’s an error when validating the target (c:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLDataLabTables.mdf) of your restore operation.

That sounds like:

a) that file already exists (because you’ve already restored it previously) and is in use by SQL Server

or

b) that directory doesn’t exist at all

In your question, you mentioned you created a backup for that table — that’s not how SQL Server backups work. Those backups are always the whole database (or at least one or several filegroups from that database).

My hunch is: you’ve already restored that database previously, and now, upon a second restore, you didn’t check the checkbox «Overwrite existing database» in your restore wizard — thus the existing file cannot be overwritten and the restore fails.

The user that’s running the restore on your remote server obviously doesn’t have access to that directory on the remote server.

C:program files.... is a protected directory — normal (non-admin) users don’t have access to this directory (and its subdirectories).

Easiest solution: try putting your BAK file somewhere else (e.g. C:temp) and restore it from there

Данный материал является переводом оригинальной статьи «MSSQLTips : Daniel Calbimonte : SQL Server Database Stuck in Restoring State».

Вы обнаружили, что база данных Microsoft SQL Server находится в состоянии восстановления. Как это произошло и как получить обратно доступ к этой базе данных SQL Server?

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

База данных SQL Server в состоянии RESTORING после восстановления

Обычно состояние восстановления возникает, когда вы восстанавливаете базу данных. Здесь мы рассмотрим пример этого.

Создадим файл полной резервной копии (файл *.bak) и файл резервной копии журнала транзакций (файл *.bak), запустив вот такой код T-SQL в SQL Server Management Studio (SSMS):

BACKUP DATABASE [earnings] TO DISK = N'c:sqlearnings.bak' 
WITH NOFORMAT, NOINIT, NAME = N'earnings-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO   BACKUP LOG [earnings] TO DISK = N'C:sqlearnings_LogBackup_2018-06-02_12-42-07.bak' 
WITH NOFORMAT, NOINIT, NAME = N'earnings_LogBackup_2018-06-02_12-42-07', SKIP, NOREWIND, NOUNLOAD, STATS = 10

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

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

RESTORE DATABASE [earnings] 
FROM DISK = N'c:sqlearnings.bak' WITH NORECOVERY, NOUNLOAD, STATS = 10

База данных теперь будет в состоянии восстановления. Если мы забудем восстановить дополнительные резервные копии, база данных застрянет в этом режиме.

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

RESTORE LOG [earnings]
FROM DISK = N'c:sqlearnings_LogBackup_2018-06-02_12-42-07.bak'

База данных SQL Server в состоянии RESTORING после выполнения резервного копирования журнала с помощью NORECOVERY

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

BACKUP DATABASE [earnings] TO DISK = N'c:sqlearnings.bak' 
WITH NOFORMAT, NOINIT,  NAME = N'earnings-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO   
BACKUP LOG [earnings] TO DISK = N'C:sqlearnings_LogBackup_2018-06-02_12-42-07.bak' 
WITH NOFORMAT, NOINIT, NAME = N'earnings_LogBackup_2018-06-02_12-42-07', SKIP, NOREWIND, NOUNLOAD, NORECOVERY, STATS = 10

Это приведет к переходу базы данных в состояние восстановления.

Чтобы исправить это, вы можете восстановить резервные копии базы данных, как показано выше.

Как сделать базу данных SQL Server доступной в состоянии RESTORING без восстановления резервных копий

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

RESTORE DATABASE [earnings] WITH RECOVERY

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

Дополнительные сведения о восстановлении базы данных в состоянии восстановления можно найти в статье «Recovering a SQL Server database that is in the restoring state».

База данных SQL Server в состоянии RESTORING и Database Mirroring

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

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

Дополнительные сведения о зеркальном отображении базы данных можно найти в статье «Configure SQL Server Database Mirroring Using SSMS».

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

Чтобы выполнить автоматическое переключение при отказе, выполните действия описанные в статье: «SQL Docs : Role Switching During a Database Mirroring Session — Manual Failover».

Чтобы «сломать» зеркало, вам нужно будет выбрать базу данных, перейти на страницу зеркального отображения и нажать кнопку удаления зеркального отображения. В следующей статье показано, как это сделать: «SQL Docs : Remove Database Mirroring (SQL Server)». После удаления база данных зеркального отображения вернется в нормальное состояние, и вы сможете создать резервную копию и восстановить базу данных как обычную базу данных.

База данных SQL Server в состоянии RESTORING и Log Shipping

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

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

Ссылка на статью об изменении состояния, чтобы избежать состояния восстановления: «Change the restore mode of a secondary SQL Server database in Log shipping with SSMS».

База данных SQL Server застряла в состоянии RESTORING после перезапуска компьютера

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

Если у вас возникла эта проблема, попробуйте сначала команду:

RESTORE DATABASE [databasename] WITH RECOVERY

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

USE master;
GO   
ALTER DATABASE Database_name
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;

Затем попробуйте снова выполнить восстановление с помощью предыдущей команды восстановления.

После восстановления вы можете перейти в многопользовательский режим с помощью следующей команды T-SQL:

USE master;
GO   
ALTER DATABASE Database_name
SET MULTI_USER;
GO

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

Так же, вам следует просмотреть журнал ошибок и средство просмотра событий Windows, чтобы проверить наличие ошибок.

Заключение

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

When trying to restore SQL Server database from backup, it is common to receive an error message that reads as follows:

Restored failed for Server ‘xxx’ (Microsoft.SqlServer.SmoExtended)

Additional Information: System.Data.SqlClient.SqlError: Exclusive access could not be obtained because the database is in use.

Reasons behind ‘SQL Database Restore Failed, Database in Use’ Error

Below are some reasons that could interfere with the restore process and throw the ‘restore of database failed because the database is in use’ error:

• You are connected to the database you are trying to restore.
• While using SQL Server Management Studio (SSMS) to do a database restore, you have more than one window open in it.
• Other users are connected to the master db.

Now, we will discuss solutions to fix the error.

Tip: SQL Server database can be restored from the backup (.bak) file. But, the database restore operation may fail if the .bak file is corrupt. Use Stellar Toolkit for MS SQL software that comes with an efficient SQL backup extractor tool designed to help database administrators recover SQL database from corrupted backup (.BAK) file. The software supports SQL Server 2019, 2017, 2016, 2014, 2012, & older versions.

Before We Begin

Before proceeding with resolving the error – exclusive access could not be obtained because the database is in use, make sure to meet the following prerequisites:

• SQL Server, of any version, must be installed on your system.
• You will need SQL Server Management Studio (SSMS) installed on your computer.

How to Fix ‘can’t restore SQL database because it is in use’ Problem?

When attempting to restore SQL Server db, make sure there are no active connections. If someone is using the database, the restore operation will fail. To resolve the issue, you will need to disconnect the active users. You can do so, by following any of these methods:

NOTE: Before disconnecting the users, use SQL stored procedure ‘sp_who’ to check all users currently using the db. If you find users performing some important tasks, notify those users before disconnecting them. For detailed information on sp_who, refer to this link. If you don’t want to notify users, skip to method 2.

Method 1 – Close the existing connections to the database

To close existing connections to SQL db, follow these steps:

Step 1: Open SSMS and connect to the db.

Step 2: After connecting to the database, Object Explorer panel will appear on the left side of the SSMS window.

Step 3: In Object Explorer panel, right-click Databases, and then select Restore Database.

Step 4: In Restore Database dialog box, do the following:

• Select one of the databases to restore.
• In the left panel, click Options.

Step 5: In Options page, check the checkbox labeled, ‘close existing connections to destination database’.

Once the SQL Server connections are closed, proceed with the restore operation.

Method 2 –Change from multiple-user mode to single-user mode

Changing the multiple-user mode by default to single user mode will disconnect all the connected users. This option can be used, if you want to disconnect all the users without notifying them.

To force users to go offline (i.e. disconnect) from SQL Server, set the db from multiple-user mode to single-user mode by following these steps:

Step 1: Open SSMS, connect to the database.

Step 2: In Object Explorer window, select New Query. Copy and paste the below T-SQL code snippet into the query window, and then click Execute:

USE master;
GO
ALTER DATABASE AdventureWorks2012
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

Executing the above code will change the database to single-user mode.

Method 3 – Restart the SQL Server Service

You can also disconnect the users by restarting the SQL service. You can restart the service by using SQL Server Configuration Manager, SSMS, services console, or the command line.

NOTE: Use this method as a last resort. That’s because, you may only need to restore a single db, but restarting the server will kill connections to all databases.

Steps to restart the service from SQL Server Configuration Manager are as follows:

Step 1: Browse SQL Server Configuration Manager using any of the following path:

SQL Server 2019              C:WindowsSysWOW64SQLServerManager15.msc

SQL Server 2017              C:WindowsSysWOW64SQLServerManager14.msc

SQL Server 2016              C:WindowsSysWOW64SQLServerManager13.msc

SQL Server 2014              C:WindowsSysWOW64SQLServerManager12.msc

SQL Server 2012              C:WindowsSysWOW64SQLServerManager11.msc

Step 2: In the left pane of SQL Server Configuration Manager window, click SQL Server Services. And in the right pane, right-click SQL Server service, and Stop and Start it.

Step 3: Click OK to exit the SQL Server Configuration Manager.

What if the problem still persists?

If the issue still persists, likely there is a problem with your database or the backup file, used for restoring the database, is corrupt. In that case, use Stellar Toolkit for MS SQL. The software can recover db from a corrupt SQL Server. It can also extract a database – from corrupt backup (.bak) files – that need to be restored.

Stellar Toolkit for MS SQL software can also help you reset lost or forgotten SQL Server Administrator and user passwords. You can read the software review done by MVP from here.

To restore database from corrupt SQL Server backup (.bak) file by using the software, follow these steps:

Step 1: Download, install and launch Stellar Toolkit for MS SQL software.

Step 2: In software’s user interface, select Extract from MS SQL Backup.

Step 3: In Stellar Backup Extractor for MS SQL window, click Select File to choose the .bak file.

NOTE: Choose ‘Search in Folder’ option, if you do not know the file location.

Step 4: After selecting the .bak file, click Scan.

Step 5: The BackupSet window appears with details of all the backups.

Step 6: Choose the .bak file you want to recover from the Backup Type list, and then click Next to proceed with the scanning process.

Step 7: Once scanning is complete, a dialog box appears displaying the number of total records available in the backup file.

Step 8: The software shows a preview of the database records.

Step 9: To save the recovered .bak file, click Save on File menu.

Step 10: In the window that pops-up, choose MSSQL under Save As, and then click Browse to select the location to save the recovered file. Click OK.

Step 11: Choose New Database or Live Database under Saving Options. Next, specify details required in Connect to Server section, and then click Connect.

Step 12: Click OK when the ‘Recovery process successfully completed’ message appears.

The recovered file will get saved in the selected location.

You can watch the complete video from here:

Conclusion

This blog explained how to fix the SQL database restore failed, database in use problem. You can disconnect active users by closing the existing connections or by changing from multiple-user mode to single-user mode. Or, disconnect all the users by restarting the SQL Server service. But, if you still have issues restoring the db, Stellar SQL Database Toolkit can come in handy. It helps resolving the issue by repairing the corrupt SQL db or by recovering the SQL Server backup file.

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

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

Обычно повреждения превосходно обнаруживаются при попытке доступа к поврежденной странице. Запросы, бэкапы или процедуры реиндексации завершаются ошибками с высокими уровнями серьезности.
Вот пара примеров системных сообщений при обнаружении повреждения БД:

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:DevelopDatabasesBroken1.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 с вот таким вот комиксом.