Методика восстановления разрушенных баз 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».

  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

и в случае отсутствия какой-нибудь из них выдается сообщение «информационная база разрушена».

— другой варинт описывает сотрудник 1С: Такое сообщение об ошибке может быть выдано в случае, если отсутствует или содержит искаженные данные таблица 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] — выполняем реструктуризацию и реиндексацию — выполняем обновление — выполняем ТиС с очисткой битых ссылок

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

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

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

gilev.ru