Зачем это надо
Все админы делятся на две категории:
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 = '<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
Тут и сказочки конец, а кто слушал – будет делать бэкапы :)
Платные услуги, контакты в 1С-Рарус
Офис на улице Бутырский Вал (ст. м. «Савёловская»)
г. Москва, ул. Бутырский Вал, д. 68
Телефоны: (495) 250-6383, 250-6393, 223-0404
Схема проезда к московскому офису на улице Бутырский Вал.
Вы также можете пообщаться со мной на курсах >>>
Если у Вас есть предложения как улучшить этот материал или поделиться своим опытом, напишите мне: gilev_slava @ mail.ru
Перейти к другим материалам сайта
