Методика восстановления разрушенных баз 1С:Предприятие 8**

Зачем это надо

Все админы делятся на две категории: 1) те, которые делают бэкапы 2) те, которые будут делать бэкапы.

Как 2я категория становиться 1й категорией :).

В стандартной документации 1С не сказано про нештатную работу 1С:Предприятия. Во многих статьях рекомендуется использовать сервера с различными механизмами резервирования устройств, использовать источники бесперебойного питания и ДЕЛАТЬ РЕЗЕРВНЫЕ КОПИИ, храня их на отдельном носителе (от данных).

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

Методика

Ниже обобщил свой опыт помощи в таких случаях.

\1. Зафиксируйте время возникновения ошибки на бумаге. (Это в дальнейшем поможет локализовать место изучения различных логов)

\2. Запишите точный текст ошибки (а также номера релизов СУБД, 1С:Предприятие, конфигурации) — если есть возможность сделать скриншот, сделайте — пометьте, может ли быть это результатом рассинхронизации узлов базы

Вот некоторые возможные варианты текста ошибки: Ошибка SDBL: Разрушена структура базы данных 1С:Предприятия. (pos=0)

Произошла неизвестная ошибка на сервере 1С предприятие (80010108)

Server: Msg 945, Level 14, State 2, Line 1 Database ‘ db_zup’ cannot be opened because some of the files could not be activated. Server: Msg 1813, Level 16, State 2, Line 1 Could not open new database ‘db_zup’. CREATE DATABASE is aborted.

В MS SQL Server база данных может оказаться со статусом «Suspect».

\3. По горячим следам постарайтесь восстановить последовательность действий, приведшую к возникновению данной ошибки — если будете вносить любые изменения в этот момент, сначало сделайте бэкап!

\4. Предложите заказчику для расследования прислать на v8@1c.ru backup базы данных SQL сервера или dt-файл или архивную копию каталога для файлового варианта. — это важно сделать сразу, так как это позволит в случаи отказа заказчиком предложить ему ПЛАТНЫЙ вариант Ваших работ — для передачи в 1С надо предоставить зарегистрированный в 1С продукт и подписку на ИТС текущего месяца, сроки реакции в 1С не всегда быстрые

\5. Поинтересуйтесь, какие резервные копии и другие узлы базы есть у Заказчика, чтобы можно было использовать для восстановления — нас будет интересовать актуальность копии (возраст копии) — для распределенных баз это может быть состав регистрируемой информации — наличие dt-файла

\6. Определите источник ошибки по 2 пункту. — здесь чаще всего источником ошибки бывает MS SQL Server, однако надо внимательно прочитать текст, отдельно исследовать ошибки для PostgreSQL, так в последнем случае работа платформы отлажена конечно меньше

— часто в источнике ошибки уже заложен ответ

— в стандартной документации описан следующая возможная причина: При старте 1С:Предприятие проверяет наличие в информационной базе таблицы \1. Config \2. ConfigSave \3. Files \4. Params \5. _YearOffset \6. DBSchema и в случае отсутствия какой-нибудь из них выдается сообщение «информационная база разрушена».

— другой варинт описывает сотрудник 1С: Такое сообщение об ошибке может быть выдано в случае, если отсутствует или содержит искаженные данные таблица DBSchema при условии, что имеются таблицы DBChanges и DBSchemaOG, или нет ни таблицы DBSchema, ни таблицы DBSchemaOG.

\7. Поищите в Интернете и на этом форуме, и в этой статье решения для вашего случая 7.1 При разрушении базы в файловом варианте в каталоге C:\Program Files\1cv81\bin есть утилита chdbfl.exe. Воспользуйтесь этой утилитой или попробуйте конвертировать в клиент-серверный вариант (если это возможно). 7.2 Для варианта с СУБД PostgreSQL попробуйте использовать команду pg_resetxlog, предварительно сделав резервную копию каталога DATA. Возможно PostgreSQL запустится, но часть данных может быть потеряна. 7.3 При обменах. В режиме предприятия сделать базу не подчиненной. Выгрузить из центральной конфигурации, загрузить ее в переферийную базу. Сделать переферийную базу опять подчиненной. Загрузить изменения конфигурации, которые были при обмене выгружены из центральной. 7.4 База со статусом «Suspect». Такой статус присваивается базе в случаи аварийного состояния. Часто такой причиной является неисправность Журнала транзакций (transaction log). Попытка подключить базу без логов ожидается примерно такое сообщение об ошибке: Server: Msg 945, Level 14, State 2, Line 1 Database ‘ db_zup’ cannot be opened because some of the files could not be activated. Server: Msg 1813, Level 16, State 2, Line 1 Could not open new database ‘db_zup’. CREATE DATABASE is aborted.

Решить эту ситуацию можно созданием новой базы с таким же именем и такими же по именам и расположению .mdf и .ldf файлами, укажите параметр базы autoclose = true, чтобы можно было не останавливать сервер целиком. Теперь подменяем файл .mdf . Можно также использовать проверку физической целостности базы командой DBCC CHECKDB. Если останавливали сервер, Стартуем, не обращаем внимания на статус базы и в Query Analyzer выполняем:

Use master go — разрешаем изменения в системных базах sp_configure ‘allow updates’, 1 –- для 2000 reconfigure with override –- для 2000 go –- запоминаем значение select status from sysdatabases where name = ‘имя базы’ –- для 2000 go –-изменяем статус нашей базы update sysdatabases set status= 32768 where name = ‘’ –- для 2000

alter database set emergency –- для 2005 go

После рестарта SQL Server (в командной строке):

Net stop mssqlserver Net start mssqlserver

база должна быть видна (в emergency mode).

Создадим новый Журнал транзакций и выполним полное тестирование DBCC REBUILD_LOG(‘имя_базы’, ‘<имя нового лога с указанием полного пути>’) GO Use master GO sp_dboption ‘имя_базы’, ‘single_user’, ‘true’ –- для 2000

ALTER DATABASE <Имя БД> SET SINGLE_USER –- для 2005 GO USE имя_базы GO DBCC CHECKDB(‘имя_базы’, REPAIR_ALLOW_DATA_LOSS)

/ищет лог по старому пути. И если база уже перенесена на другую машину, то надо на время создать пустой лог в той же директории и на том же диске, что и был раньше. После восстановления его можно перенести (детач-аттач с новыми путями)/ — Если Вам не удалось перевести базу в single user mode, — то для проверки целостности данных можно попробовать dbo only mode — для этого уберите «—» в строке ниже — sp_dboption ‘’, ‘dbo use only’, ‘true’ GO sp_dboption ‘’, ‘single_user’, ‘false’ –- для 2000

alter database set multi_user –- для 2005 GO USE master GO — запрещаем изменения в системных базах sp_configure ‘allow updates’, 0 –- для 2000 GO

7.5 Вариант отката к конфигурации базы данных. Ошибка устраняется открытием конфигуратора данных ключами запуска /RollbackCfg. 7.6 Проверенное лекарство для тяжелых случаем, когда не запускается конфигуратор или не открывается конфигуруция (только для СУБД MS SQL Server 2005):

USE [db_buh] GO DROP TABLE [dbo].[ConfigSave] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].ConfigSave ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO INSERT INTO ConfigSave SELECT * FROM Config GO где [db_buh] — имя базы

7.7 Смертельный номер, когда «убита» конфигурация, но она типовая или близко к типовой и известен ее номер. — создаем чистую конфигурацию из типовой — используем скрипт из 7.6, но вместо SELECT * FROM Config пишем SELECT * FROM [база_источник]dbo.Config — выполняем снова этот скрипт но уже не для [dbo].[ConfigSave], адл [dbo].[Config] — выполняем реструктуризацию и реиндексацию — выполняем обновление — выполняем ТиС с очисткой битых ссылок

Работает ли это?

Пример, когда пункт 7.7 помог «в особо тяжелом» случаи в http://partners.v8.1c.ru/forum/thread…398#595398 Тут и сказочки конец, а кто слушал – будет делать бэкапы 🙂

См. также методику https://infostart.ru/public/391766/

http://www.gilev.ru/restoreib/