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

Материал из Oktell
Перейти к: навигация, поиск
 
(не показано 6 промежуточных версии этого же участника)
Строка 1: Строка 1:
[[Прочее|Наверх]]
+
[[Решение проблем|Наверх]]
  
Возникают ситуации, когда целостность данных в БД нарушена, и сам база помечена как ''Suspect''. Когда нарушилась работа сервера баз данных, как следствие нарушается работа коммуникационной платформы Октелл.
+
Возникают ситуации, когда целостность данных в БД нарушена, и сам база помечена как ''Suspect''. Когда нарушилась работа сервера баз данных, как следствие нарушается работа коммуникационной платформы Oktell.
 
+
 
+
Сама проблема выглядит так: при очередном обращении службы к базе данных в логах появляются строчки исключений, в которых говорится о невозможности подключения к базе по причине ее отсутствия. При этом сами файлы базы находятся на месте, а в ''Managment Studio'' база помечена как ''Suspect''.
+
  
 +
Сама проблема выглядит так: при очередном обращении службы к базе данных в логах появляются строчки исключений, в которых говорится о невозможности подключения к базе по причине ее отсутствия. При этом сами файлы базы находятся на месте, а в ''SQL Server Managment Studio'' база помечена как ''Suspect''.
  
 
В частности такое происходит при появлении некоторых нарушений в целостности данных. Может быть поврежден и сам файл базы. Без проведения специальных мероприятий базу невозможно ни скопировать, ни переподключить, ни бэкапить.
 
В частности такое происходит при появлении некоторых нарушений в целостности данных. Может быть поврежден и сам файл базы. Без проведения специальных мероприятий базу невозможно ни скопировать, ни переподключить, ни бэкапить.
Строка 11: Строка 9:
 
Следующая последовательность действий поможет восстановить поврежденную базу.(Проверялось на MS SQL Server 2000, MS SQL Server 2005)
 
Следующая последовательность действий поможет восстановить поврежденную базу.(Проверялось на MS SQL Server 2000, MS SQL Server 2005)
  
*1. Запускаем Managment Studio и выполняем скрипт
+
 
 +
'''Шаг 1.''' Запускаем SQL Server Management Studio и выполняем скрипт
  
 
<pre>
 
<pre>
Строка 21: Строка 20:
 
</pre>
 
</pre>
  
 
+
'''Шаг 2.''' Там же выполняем
*2. Там же выполняем
+
 
<pre>
 
<pre>
 
UPDATE sysdatabases SET status= 32768 WHERE name = '<имя базы>'  
 
UPDATE sysdatabases SET status= 32768 WHERE name = '<имя базы>'  
 
</pre>
 
</pre>
  
 +
'''Шаг 3.''' Перезапускаем SQL Server
  
*3. Перезапускаем SQL Server
+
'''Шаг 4.''' В принципе база должна быть перейти в ''emergency mode''
  
 
+
'''Шаг 5.''' Из SQL Server Management Studio выполняем
*4. В принципе база должна быть перейти в ''emergency mode''
+
 
+
 
+
*5. Из Management Studio выполняем
+
  
 
<pre>
 
<pre>
Строка 40: Строка 35:
 
</pre>
 
</pre>
  
*6. Если все нормально, то там же выполняем
+
'''Шаг 6.''' Если все нормально, то там же выполняем
  
 
<pre>
 
<pre>
Строка 55: Строка 50:
 
</pre>
 
</pre>
  
 
+
'''Шаг 7.''' Если все в порядке, то
*7. Если все в порядке, то
+
  
 
<pre>
 
<pre>
Строка 91: Строка 85:
 
:'' Сам Oktell умеет автоматически при выполнении процедуры оптимизации БД создавать резервную копию базы.''
 
:'' Сам Oktell умеет автоматически при выполнении процедуры оптимизации БД создавать резервную копию базы.''
 
:'' Автоматическое резервное копирование БД происходит ежедневно в 2.00.''
 
:'' Автоматическое резервное копирование БД происходит ежедневно в 2.00.''
 +
 +
<span style="color:red">ВНИМАНИЕ: Проверьте что у вас создаются резервные копии баз данных в папке ''\Oktell\Server\Backup'' (по умолчанию)

Текущая версия на 07:03, 4 августа 2014

Наверх

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

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

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

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


Шаг 1. Запускаем SQL Server Management 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. Из SQL Server 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.

ВНИМАНИЕ: Проверьте что у вас создаются резервные копии баз данных в папке \Oktell\Server\Backup (по умолчанию)