Вот несколько направлений, которые я бы исследовал. Не делайте все это (некоторые из них являются разными методами для достижения одной и той же цели), но стоит рассмотреть:
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
(с помощью любого из вышеперечисленных методов) вам необходимо исследовать любые изменения, которые могли быть потеряны, если бы они были сделаны после только что восстановленной резервной копии:
- Изменения в безопасности
- Новые базы данных (файлы все еще будут на диске, просто прикрепите их)
- Настройки для всего сервера
Не существует волшебного способа найти их, вам придется вернуться к документации вашей собственной компании для таких изменений, если они у вас есть.