Основная база данных повреждена, экземпляр не запускается - каковы мои варианты?

Помогите! Моя основная база данных повреждена, я даже не могу вывести экземпляр SQL в онлайн! Какие есть варианты для восстановления моего сервера?

У меня есть резервная копия master, но страница MSDN «Восстановление базы данных master» просит меня запустить экземпляр в однопользовательском режиме, чего я не могу сделать!

(Примечание: я оставляю этот вопрос не уточненным в отношении версии SQL, чтобы он был более широко применимым. Есть некоторые похожие вопросы о DBA.SE, но ни один из них не связан с невозможностью запуска сервера.)

Вот несколько направлений, которые я бы исследовал. Не делайте все это (некоторые из них являются разными методами для достижения одной и той же цели), но стоит рассмотреть:

1. Изучите журнал ошибок SQL напрямую

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

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

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

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

Если другое приложение всегда захватывает однопользовательское соединение, прежде чем вы сможете, сначала отключите агент SQL, чтобы он не запускался. Во-вторых, посмотрите идеи по этому вопросу, чтобы использовать -m"Application Name"параметр для указания имени приложения.

3. Восстановите masterдругой экземпляр и скопируйте его файлы.

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

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

• Конечно, восстановите под другим именем ( master_please_god_let_this_work), WITH MOVEчтобы не перезаписывать masterна хорошем сервере.
• Восстановление WITH NORECOVERY. Не уверен, что это необходимо, но я почувствовал себя лучше, потому что знал, что другой сервер не собирается ничего менять в восстановленном мастере.
• Установите его в автономный режим: ALTER DATABASE [master_please_god_let_this_work] SET OFFLINE
• Скопируйте восстановленные файлы MDF и LDF с хорошего сервера на мертвый сервер
• Переименование master.mdfи mastlog.ldfфайлов по мере необходимости заменить плохой мастер - файлы с восстановленными версиями
• Скрестите пальцы и запустите пример
• Необязательно: выполните новое восстановление мастера на обновленном сервере. Не уверен, что это необходимо, так как мы были очень осторожны, чтобы не измениться master.

4. Перестройте системные базы данных.

Если у вас нет другого экземпляра, работающего с той же версией, или если вам неудобно использовать недокументированную процедуру, перечисленную в # 3, или если у вас нет резервных копий master( почему у вас нет резервных копий ?? ), Вы можете восстановить системные базы данных SQL с исходного установочного диска :

Setup.exe /ACTION=REBUILDDATABASE /...

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

5. Восстановите все базы данных USER в новый (или существующий) экземпляр SQL

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

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

CREATE DATABASE foo 
ON (FILENAME = 'D:\data\foo.mdf'),
   (FILENAME = 'D:\data\foo_log.ldf')
FOR ATTACH;

6. Повторно внесите любые изменения в master

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

• Изменения в безопасности
• Новые базы данных (файлы все еще будут на диске, просто прикрепите их)
• Настройки для всего сервера

Не существует волшебного способа найти их, вам придется вернуться к документации вашей собственной компании для таких изменений, если они у вас есть.

Я просто хотел добавить возможную проблему и решение, с которым только что столкнулся - у меня была похожая ситуация во время сбоя накопительного обновления (SQL2016 CU12) и сообщений в средстве просмотра событий и в журнале ошибок, где говорилось: «Невозможно восстановить основную базу данных. SQL Server не удается запустить. Восстановить мастер из полной резервной копии, отремонтировать его или перестроить. ", однако в конечном итоге я обнаружил, что если я просто перезапустить исполняемый файл CU, он обнаружит статус обновления как" Не полностью установлен "и позволил мне просто запустить обновите снова, после чего оно успешно завершено, и основная база данных и все остальные будут открыты без проблем.