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

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

Методика

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

  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».

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

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

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

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

При старте 1С:Предприятие проверяет наличие в информационной базе таблиц: - 1) Config - 2) ConfigSave - 3) Files - 4) Params - 5) _YearOffset - 6) DBSchema

В случае отсутствия какой-нибудь из них выдается сообщение “информационная база разрушена”.
Такое сообщение об ошибке может быть выдано в случае, если отсутствует или содержит искаженные данные таблица DBSchema при условии, что имеются таблицы DBChanges и DBSchemaOG, или нет ни таблицы DBSchema, ни таблицы DBSchemaOG.

  1. Поищите в Интернете решения для вашего случая.

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 = ‘<db_name>’ –- для 2000

alter database <db_name> 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 ‘<db_name>’, ‘dbo use only’, ‘true’
 GO
 sp_dboption ‘<db_name>’, ‘single_user’, ‘false’ –- для 2000

alter database <db_name> 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](
 [FileName] [nvarchar](128) NOT NULL,
 [Creation] [datetime] NOT NULL,
 [Modified] [datetime] NOT NULL,
 [Attributes] [smallint] NOT NULL,
 [DataSize] [int] NOT NULL,
 [BinaryData] [image] NOT NULL,
 PRIMARY KEY CLUSTERED
 (
 [FileName] ASC
 )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
 ) 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] — выполняем реструктуризацию и реиндексацию — выполняем обновление — выполняем ТиС с очисткой битых ссылок

Источник gilev.ru