Процедура восстановления поврежденной БД — различия между версиями

Материал из Oktell
Перейти к: навигация, поиск
Строка 34: Строка 34:
 
DBCC REBUILD_LOG('<имя базы>', '<имя нового лога с указанием полного пути>')
 
DBCC REBUILD_LOG('<имя базы>', '<имя нового лога с указанием полного пути>')
 
</pre>
 
</pre>
 
  
 
'''Шаг 6.''' Если все нормально, то там же выполняем
 
'''Шаг 6.''' Если все нормально, то там же выполняем
Строка 50: Строка 49:
 
go
 
go
 
</pre>
 
</pre>
 
  
 
'''Шаг 7.''' Если все в порядке, то
 
'''Шаг 7.''' Если все в порядке, то

Версия 06:28, 4 июня 2014

Наверх

Возникают ситуации, когда целостность данных в БД нарушена, и сам база помечена как Suspect. Когда нарушилась работа сервера баз данных, как следствие нарушается работа коммуникационной платформы Октелл.

Сама проблема выглядит так: при очередном обращении службы к базе данных в логах появляются строчки исключений, в которых говорится о невозможности подключения к базе по причине ее отсутствия. При этом сами файлы базы находятся на месте, а в Managment Studio база помечена как Suspect.

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

Следующая последовательность действий поможет восстановить поврежденную базу.(Проверялось на MS SQL Server 2000, MS SQL Server 2005)


Шаг 1. Запускаем Managment Studio и выполняем скрипт

USE master
GO
sp_configure 'allow updates', 1
reconfigure with override
GO

Шаг 2. Там же выполняем

UPDATE sysdatabases SET status= 32768 WHERE name = '<имя базы>' 

Шаг 3. Перезапускаем SQL Server

Шаг 4. В принципе база должна быть перейти в emergency mode

Шаг 5. Из Management Studio выполняем

DBCC REBUILD_LOG('<имя базы>', '<имя нового лога с указанием полного пути>')

Шаг 6. Если все нормально, то там же выполняем

USE master
GO
sp_dboption '<имя базы>', 'dbo use only', 'false'
GO
sp_dboption '<имя базы>', 'single user', 'true'
GO
USE <имя базы>
GO
DBCC CHECKDB('<имя базы>', REPAIR_ALLOW_DATA_LOSS)
go

Шаг 7. Если все в порядке, то

USE master
GO
sp_dboption '<имя базы>', 'single user', 'false'
GO
sp_configure 'allow updates', 0
GO


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


Для создания резервной копии базы используем скрипт

BACKUP DATABASE <имя базы>
TO DISK='путь к файлу'
WITH INIT, SKIP


Для восстановления базы из резервной копии используйте скрипт

RESTORE DATABASE
<имя базы>
FROM DISK='путь к файлу'
Для снижения вероятности возникновения подобной ситуации процедуру создания резервной копии необходимо проводить периодически.
Сам Oktell умеет автоматически при выполнении процедуры оптимизации БД создавать резервную копию базы.
Автоматическое резервное копирование БД происходит ежедневно в 2.00.