SQL 2000 – Восстановление поврежденного лога транзакций

Вспомнился недавний «головняк» когда мне очень повезло с SQL 2000.

В двух словах как было дело.
слово №1 – был сервер на котором крутилось приложение которое никому не нужно было довольно много времени.
слово №2 – на этом сервере был, вернее уже есть в полном здравии SQL 2000, и была жутко попорченная ОСь…

В один прекрасный день приложение вместе с SQL сервером «приказало долго жить», и вспомнили о его существовании наверно месяца через три после его кончины.

Симптомы.
SQL не стартует, ни на какие действия не реагирует.
при попытке запуститься с ключом -m грязно ругается на поврежденную БД master и оставляет наедине с тяжелыми размышлениями о том где документация по этому проекту, почему эти «нехорошие люди» не потрудились настроить бэкапы и пр.
Бэкап кстати в последний раз был два года назад.

Вывод.
1. все плохо…
2. придется думать как это восстановить.
3. придется восстанавливать.

По памяти напишу как было дело…

все существующие файлы БД были скопированы на сторонний носитель, после чего была поправлена операционка (пересборка WMI, переустановка Windows Installer и что то еще по мелочам).

Когда возникла полная уверенность в том что «ОС жив и будет жить» началось таинство оживления…

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

Для тех кто следует фразе – «админы делятся на тех кто делает бэкапы и нет» я могу сказать что отношусь к первым, но в моей практике часто попадались случаи когда приходилось поднимать результаты установок методом next-next-finish и потом перелопачивать все допущенные ошибки.

Именно об этом и пойдет речь.

Итак.
Имеем
1. неработоспособный сервер
2. судя по логам живая БД на нем осталась только tempdb

На всякий случай скопировал все существующие файлы БД
идем в дистрибутив и ищем там утилиту rebuildm.exe, запускаем, производим ребилд системных баз.

Стало немногим легче – сервер живой

Далее.

1. Создаем БД с нужным названием (например test1).
2. останавливаем MSSQL
3. Удаляем файл данных и журнала у новой БД (test1.MDF и test1.LDF)
4. переименовываем файл данных от восстанавливаемой БД в test1.MDF
5. запускаем MSSQL
6. в списке баз видим что БД test1 находится в режиме Suspect
7. Открываем QA и выполняем

8. Делаем рестарт MSSQL
9. После рестарта видим что состояние БД поменялось на Recovery
10. Выполняем ребилд лога

11. выполняем сброс состояния БД test1

12. После проверки БД снимаем ограничение на доступ.

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

Сопоставить пользовательские аккаунты с тем что лежало в базе при помощи вот этого не получилось и пришлось повторять процедуру восстановления лога для БД master, после того как под новым именем она заработала ей сделал CHECKDB, который как ни странно показал что данные целы.

Далее остановка SQL сервера, подмена БД master на восстановленную, старт….
Все ожило

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

Print PDF