Восстановление работоспособности файловой базы 1С (*.1CD) Печать
22.09.14 15:53

Восстановление работоспособности файловой базы.

 

Ошибка 1C: DBMS:error database file corrupted

Восстановление работоспособности разрушенной файловой базы. Этап 0. Введение в проблематику.

Этап 0. Введение в проблематику.

С упрямой периодичностью на форумах по 1С появляются крики души "Помогите! Упала файловая база, бэкапов нет, что делать?". Лично я всегда при этом вспоминаю известную шутку "Админы делятся на два типа — тех, кто делает бэкапы, и тех, кто будет их делать". Но, отбросив шутки в сторону, постараемся серьёзно рассмотреть данную проблему, ведь ситуации бывают разные. Например, бэкапы делались на диск, на котором закончилось место, или бэкапы делались через выгрузку, и все такие выгрузки за последнее время оказались неработоспособны. К слову сказать, даже админы, считающие себя "бывалыми", прокалываются на подобных мелочах.

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

  1. Помимо настроенных автоматических ежедневных бэкапов, обязательно сделайте дополнительный бэкап перед такими критическими операциями, как обновление конфигурации, ТиИ, проверка базу с помощью chdbfl.exe и т.п.
  2. Делайте бэкап архивированием (копированием) файла 1Cv8.1CD, либо комбинируйте копирование с выгрузкой в .dt. Ни в коем случае не ограничивайте бэкап только выгрузкой в .dt, ведь наличие некоторых ошибок в файле 1Cv8.1CD может привести к тому, что в выгрузке будет отсутствовать часть информации, либо выгрузку вообще невозможно будет загрузить. И если с 1Cv8.1CD можно "поколдовать" и попытаться выудить нужные данные, то в случае полностью отсутствующих данных уже ничего не сделаешь.
  3. Процедуру создания бэкапа выполняйте в такой период, когда с базой не работают пользователи.
  4. Периодически проверяйте наличие свободного места на устройстве, куда настроено автоматическое создание бэкапов.
  5. Старайтесь размещать бэкапы не на том же компьютере, где расположена сама база, а на других компьютерах/хранилищах в локальной сети (например, если на компьютере испортится жёсткий диск, или проникнет вирус-шифровальщик, получим порушенные и базу, и бэкапы). Старайтесь также периодически размещать бэкапы на дополнительных (альтернативных) источниках, например, в облачном хранилище (dropbox, yandex disk и т.п.), или на флэшке.


Но что же делать, если самое страшное уже произошло, и база разрушилась, а рабочих бэкапов нет, или они очень старые?
Сразу оговорюсь, что не очень сложные случаи (например, когда база в режиме Предприятия работает нормально, а войти невозможно только в Конфигуратор, или наоборот, или проблема возникает только под определёнными пользователями) рассматривать не буду, т.к. в Интернете есть масса советов по решению подобных проблем - от очистки кэша и "перезаливки" конфигурации, до обновления версии платформы и выгрузки всех данных в чистую базу. Буду рассматривать самые сложные случаи, когда в базу невозможно зайти ни в режиме Предприятия, ни в режиме Конфигуратора ни под одним из пользователей. Симптомы при этом могут быть разные: 1С "зависает" при попытке войти в базу, либо выдаёт сообщения типа "Ошибка формата потока", "База данных полностью разрушена", "Файл базы данных поврежден", "При обновлении данных, после последней реструктуризации, произошла критическая ошибка", "Обнаружена незавершенная операция сохранения конфигурации", либо "падает" с сообщением об ошибке приложения от операционной системы.

Пример окошка с критической ошибкой


Первоначальные действия для диагностирования таких случаев должны быть такими:

  1. Обязательно делаем самый первоначальный бэкап нашей проблемной базы (до любых манипуляций с ней) копированием/архивированием файла 1Cv8.1CD, и убираем его в надёжное место, дабы случайно не повредить.
  2. Пробуем войти в базу под другими пользователями.
  3. Полностью очищаем кэш 1С (это можно сделать, например, простым удалением базы из списка, и добавлением её в список вновь, либо использовать утилиты типа http://infostart.ru/public/90572/ , либо удалить вручную http://help1c.com/faq/view/1267.html ).
  4. Пробуем перенести файл базы на другой компьютер, и войти в базу там.
  5. Прибегаем к помощи утилиты chdbfl.exe из поставки 1С:Предприятие, с установленной галкой "Исправлять обнаруженные ошибки".  Пример отказа chdbfl.exe реанимировать базу
  6. Ещё можно попробовать открыть базу на более свежих релизах 1С, например, если работали на 8.2.15, то можно попробовать на 8.2.17.


Если все попытки ни к чему не привели, и мы можем констатировать факт, что база "мёртвая", то остаётся выбрать правильный вариант дальнейших действий. Вариант первый, банальный - отдать базу на ремонт специалисту - рассматривать не будем, здесь проблема из технической плоскости уходит в переговорно-финансовую. Вариант второй, нудный, длительный, и с сомнительным исходом - переслать базу в 1С, и ждать результата - тоже рассматривать не будем, хотите им воспользоваться - пожалуйста, но сильно надеяться на быстрое и положительное решение я бы не стал. Вариант третий - попробовать починить базу своими силами - как раз и является нашей темой.

Итак, Вы решили починить базу своими руками, и окунуться в самые дебри загадочного содержимого файла 1Cv8.1CD. Какие же полезные статьи и инструменты мы имеем на текущий день?

  1. Перво-наперво советую ознакомиться со статьёй http://infostart.ru/public/19734/ , содержащей описание формата файловой базы данных .1CD. Крайне настоятельно рекомендую прочитать, осмыслить, и отложить в памяти. Ведь без ясного представления устройства базы заниматься её ремонтом весьма проблематично.
  2. Ещё есть официальная информация о предназначении некоторых таблиц БД от 1С: http://1c-dn.com/library/data_structure_in_1c_enterprise_8/?SECTION_CODE=data_structure_in_1c_enterprise_8&print=Y (к сожалению, только анголязычная).
  3. Неофициальная информация о таблицах и полях: http://main.1c-ei.ru/Home/help/objectdb/dbschema (русскоязычная и более развёрнутая)
  4. Далее, есть прекрасная утилита Tool_1CD http://infostart.ru/public/19633/ , позволяющая визуально просмотреть и извлечь данные из файла .1CD в xml-файлы, а также сохранить конфигурацию БД, основную конфигурацию и конфигурацию поставщика. Если из рухнувшей базы нужно спасти только конфигурацию - то самым лёгким и простым вариантом является именно она. Выгруженные в xml-файлы данные частично можно подгрузить в другую базу при помощи разработки http://infostart.ru/public/143704/ , однако поддерживается только определённый перечень объектов.
  5. Система восстановления баз 1С restoration-base-1c8: http://code.google.com/p/restoration-base-1c8/downloads/list . Является конфигурацией для 1С, позволяющей загрузить и редактировать в ручном режиме содержимое файловой базы. Загрузка базы происходит очень долго, следует запастить терпением. Считывает блоки, не опираясь на данные корневого объекта, поэтому, если имеем базу с полностью разрушенным корневым объектом, то может быть весьма полезна. Описание примера применения: http://infostart.ru/public/158034/
  6. Компонента 1CDLib для прямого чтения/записи данных из файлов баз данных .1CD http://infostart.ru/public/166557/ - единственный имеющийся на текущий день инструмент, позволяющий не только читать данные из файловой базы, но и записывать (если не рассматривать низкоуровневый доступ типа hex-редакторов, естественно). Данная компонента позволяет применять к файловым базам многие имеющиеся на просторах Интернета советы по ремонту клиент-серверных баз (MS SQL, PostgreSQL и т.д.), например: http://www.gilev.ru/1c/81/restore/ , http://infostart.ru/public/116123/ . Поскольку является внешней компонентой для 1С, позволяет в 90% случаев ремонтировать базы при помощи написания определённого кода (скрипта) на языке 1С после проведения процедуры обследования, не прибегая к hex-редактору. Пример скрипта по переносу таблиц
  7. Hex-редактор HxD http://mh-nexus.de/en/hxd/ (на случай, если что-то надо посмотреть или подправить непосредственно и в ручном режиме). В принципе, можно использовать любой, но мне понравился этот.


Хочу заметить, что в следующих статьях цикла будет предполагаться, что читатели ознакомились хотя бы поверхностно с перечисленными статьями и утилитами, и на этом этап введения предлагаю считать законченным. Прошу высказывать свои мнения, замечания и дополнения в комментариях.
В следующей статье рассмотрим подробно этап обследования сбойной базы и выявления проблемных мест.


Следующие этапы:

1. Обследование

См. также

источник: http://infostart.ru/public/174806/

{jcomments on}

Последнее обновление 22.09.14 16:21