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