База данных может войти в состояние SUSPECT по многим причинам: неисправность оборудования, "битый" LOG или MDF файл, заполнено дисковое пространство, ограничения по линии файловой системы FAT32 и т.д.
Если обратиться в BOL, то там можно узнать, что состояние SUSPECT означает повреждение файла (находится в подозрительном состоянии) и он может быть восстановлен или удален. Также отмечается, что базу данных можно восстановить из резервной копии.
Со словом "удален" все понятно. Попробуем восстановить базу данных. Для простоты будем рассматривать случай, когда повреждена пользовательская база данных.
1. Останавливаем MS SQL SERVER;
2. Копируем файлы mdf и ldf аварийной базы данных в безопасное место;
3. Стартуем сервер и удаляем аварийную базу данных. В этом пункте в некоторых случаях, когда невозможно удалить базу данных, придется подкорректировать системную таблицу sysdatabases;
4. Создаем новую базу данных с таким же именем и местоположением как и аварийная база данных;
5. Останавливаем сервер и подменяем mdf файл;
6. Стартуем сервер. В данный момент состояние аварийной базы данных для нас не актуально.
7. Из QA выполняем скрипт, который позволит нам редактировать системные таблицы
Use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
8. Там же выполняем скрипт, который выводит номер статуса аварийной базы данных, например, 536870912 - полнотекстовые функции включены и т.д.
select status from sysdatabases where name = ''
и запоминаем/записываем значение на случай неудачи перестройки лога
9. Там же выполняем скрипт, который переводит базу данных в аварийный режим
update sysdatabases set status= 32768 where name = ''
10. Перезапускаем MS SQL SERVER;
11. База данных должна находиться в emergency mode, но уже не в состоянии SUSPECT
12. Из QA выполняем скрипт, который создает новый лог к аварийной базе данных
DBCC REBUILD_LOG('', '<имя нового лога с указанием полного пути>')
SQL Server скажет - Warning: The log for database '' has been rebuilt.
13. Выполняем следующий скрипт - переводи базу данных в однопользовательский режим:
Use master
go
sp_dboption '', 'single user', 'true'
go
USE
GO
DBCC CHECKDB('', REPAIR_ALLOW_DATA_LOSS)
go
1. Если Вам не удалось перевести базу в single user mode, то для проверки целостности данных можно попробовать dbo only mode
sp_dboption '', 'dbo use only', 'true'
2. Если все прошло успешно, то
sp_dboption '', 'single user', 'false'
go
Use master
go
sp_configure 'allow updates', 0
go
ПРИМЕЧАНИЕ.
1. Если в состояние SUSPECT вошла, например, база данных TEMPDB, то необходимо воспользоваться рекомендациями {
http://support.microsoft.com/kb/q288809/} 2. Можно интересную информацию получить по ссылке {
http://support.microsoft.com/default.aspx/kb/328354} 3. Резервное копирование и восстановление баз данных {
http://www.sql.ru/articles/Publications.shtml#fix}
Оригинал статьи утянут отсюда:
http://alexs07.livejournal.com