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

Главная — Статьи — Установка и настройка 1С — Восстановление разрушенной базы 1С Предприятие 8.1

Какими методами восстанавливать разрушенные базы программы 1С:Предприятие 8,1

Зачем нужна эта статья

Есть такая очень правдивая шутка, мол, все администраторы делятся на 2 группы: одни делают бэкапы, а другие будут делать бэкапы. Обычно чем старше человек, тем больше вероятность того, что он принадлежит к первой категории. Впрочем, эта статья как раз и создана для того, чтобы читатель смог перейти в первую категорию

Стандартная документация программ 1С практически не затрагивает тему нештатной работы 1С:Предприятие; часто в этих статьях советуют использовать серверы с разными механизмами резервирования устройств, а также использовать источники бесперебойного питания; ну и, конечно же, иногда делать резервные копии, храня их на флешке, диске или дополнительных винчестерах

Но, как свидетельствует практика, большинство пользователей, и даже администраторов имеют привычку сначала испортить базу, а когда ее восстановить уже нельзя, как впрочем и данные в ней, тогда и кричат о помощи

Методы восстановления данных

Сейчас мы расскажем немного о том, как поступать в случаях, когда резервной копии нет, а база при этом повреждена

1) запишите на бумаге дату и время, когда появились ошибки; это поможет намного быстрее найти и исправить ошибку, когда, например, вы будете просматривать логии. Если не помните точное время, запишите хотя бы приблизительное, или временные рамки, когда, по вашему мнению, могли начаться глюки и ошибки

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

- если возможно, сделайте скриншота экрана, когда на нем высветилась ошибка;

- сделайте пометку, может ли это быть результатом рассинхронизации узлов базы, или нет;

Например, текст ошибки может быть таким:

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

Или на английском:

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) предложите вашему заказчику прислать базы данных с SQL Server’а или dt-файл, или же архивную копию каталога на адрес v8@1c.ru ;

- это обязательно нужно делать сразу, ведь если заказчик откажется, можно предложить ему платную версию ваших работ;

- для передачи данных в 1С нужно предоставить продукт, зарегистрированный в 1С, а также подписку на ИТС в текущем месяце; учтите, что сроки реакции 1С бывают медленные;

5) спросите у заказчика, какие резервные копии у его есть, или какие другие узлы базы; в дальнейшем их можно будет использовать для восстановления

- обязательно обратите внимание на актуальность этих копий – когда они были сделаны;

- для распределенных баз может быть полезен состав информации, которая регистрируется;

- спросите Заказчика о наличии dt-файла

6) определяем то, что вызвало ошибку – это описано во втором пункте;

- обычно источник ошибки – это MS SQL Server, но все равно нужно внимательно читать текст, исследовать ошибки PostgreSQL отдельно от ошибок MS SQL Server;

- бывает, что ответ уже заложен в источнике ошибки;

- стандартная документация программ 1С описывает такую возможную причины:

При запуске 1С:Предприятие начинает проверять, есть ли в информационной базе таблицы следующие элементы: Config, ConfigSave, Files, Params, _YearOffset, 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. Именно такой статус имеют базы, которые находятся в аварийном состоянии. Довольно часто причиной этого являются неполадки с журналом транзакций. Если попробовать подключить базу без журналов, может появиться такое сообщение про ошибку:

Для того чтобы решить такую проблему, можно создать новую базу с таким же именем, и аналогичными по имени и расположению файлами mdf и ldf; пропишите параметр базы autoclose в активное состояние, то есть введите autoclose = true

Тепер нужно подменить файл с расширением mdf. Можно также делать проверку физической целостности базы при помощи команды DBCC CHECKDB

Если сервер был остановлен, то сразу запускаем, не обращая внимания на статус базы, а в Query Analyzer выполняем такое:

Use master
go -- позволяем изменять данные систeмных баз
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)

/*Этот код ищет Журнал транзакций по старому пути. Если база уже находится на другом компьютере, то нужно создать временный пустой Журнал транзакций в той же папке и на том же диске, что и раньше. После восстановление можно его перенести

Если у вас не получилось перевести базу в singleusermode, то проверку целостности может получить сделать через 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](
[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];

- делаем реструктуризацию и реиндексацию

- делаем обновление;

- выполняем ТиС, но с очисткой испорченных ссылок

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

Конечно, гарантий успешности этих мероприятий никто не дает, но уже многим людям данные советы помогли; но самый главный совет – регулярно делайте бэкапы!

Теги материала: база, 1с, бухгалтерия, предприятие, сломалась база, зависла база, повредилась база, не открывается база