Форум 1С
Программистам, бухгалтерам, администраторам, пользователям
Задай вопрос - получи решение проблемы
28 мар 2024, 12:17

Восстановление испорченной базы данных 1С [chdbfl.exe] [chdbfl]

Автор MuI_I_Ika, 25 ноя 2012, 20:16

0 Пользователей и 2 гостей просматривают эту тему.

MuI_I_Ika

Бонусный урок по восстановлению испорченных файловых баз данных с использованием утилиты chdbfl.exe



Сегодня рассмотрим один из способов восстановления испорченной базы данных. А именно использование для восстановления утилиты chdbfl.exe.

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

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

Утилита находится в установочной папке программы 1С и подпапке bin. В данном случае это: C:\Program Files\1cv82\8.2.15.289\bin. Открываем файл chdbfl.exe.

Для старта исправления нам нужно выбрать файл базы данных. Это 1cv8.cd. Он находится в каталоге базы данных. Выбираем файл отмечаем галку производить исправление и нажимаем кнопку «Выполнить».

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

greenLiss

Шутишь ? :D Эта утилита для не значительных исправлений и обычно не помогает.
Вот нормальная статья по восстановлению испорченной базы: http://infostart.ru/public/155427/

Опыт по восстановлению файловой версии базы после неудачной реструктуризации таблиц

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

Вступление

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

Реструктуризация

При повторном запуске программа выдавала сообщение

Незавершенная операция

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

Восстановление базы


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

Краткое описание формата файлов *.1CD (файловых баз 1Сv8)

Восстанавливаем убитую базу 1C

Шаг №1. Делаем резервную копию испорченной базы

Коллега awa, упомянул в одном из сообщении, что штатная утилита 1С chdbfl.exe - чуть реже чем всегда бесполезна для исправления подобных проблем. Данная утилита проверяет только физическую целостность таблиц. Восстановление структур необходимых для запуска БД для нее непосильная задача. Более того, в некоторых случаях она портит испорченную базу на столько, что ее невозможно восстановить. В любом случае при запуске данной утилиты всегда делайте резервную копию базы.

Шаг №2. Делаем выгрузку конфигурации при помощи утилиты Tool_1CD

Утилита находится здесь: //infostart.ru/public/19633/

Помимо просмотра списка таблиц, там есть важная для нас функция выгрузки конфигурации. Запускаем утилиту, открываем базу. База открылась без сообщений об ошибок, это хороший знак!

Выгрузка конфигурации

Шаг №3. Анализируем структуру файла испорченной базы

Итак, как вам известно CD файл - это по сути хранилище файлов-таблиц. Открываем Hex редактор (например опенсорсный http://en.wikipedia.org/wiki/HxD), переходим по ссылке 0x4000. Тут находится таблица смещений основных таблиц базы данных и конфигурации.

Лирическое отступление

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


Итак взглянем на таблицу из HEX редактора:

Основная таблица смещений

На этой картинке в левой части показан HEX редактор в правой части список таблиц из утилиты Tool_1CD. Их порядок совпадает с тем как они идут в файле CD. Здесь мы видим, что таблица CONFIG начинается с адреса 0x5000 и оканчивается на 0x31F0FFF, где следом начинается таблица CONFIGSAVE по адресу 0x31F1000 (для тех кто никогда не программировал на ассемблере скажу, что в машинных кодах числа пишутся с права на лево - пережиток царского режима). Строго говоря, 0x5000 расположен заголовок таблицы CONFIG, который ссылается еще на один заголовок, а потом уже следует сама таблица (см. описание формата файлов по ссылке выше). Разумно предположить, что если 1С ругается на конфигурацию, стало быть именно эту таблицу нам надо исправить, для этого надо выцепить таблицу CONFIG из сохраненной конфигурации (или если она не сохраняется, взять конфигурацию максимально близкой к испорченной) и подставить ее по адресу 0x5000, но при этом таблица не должна выходить за пределы 0x31F0FFF.

Upd 10/10/2012

Важное замечание awa:

1С обращается к таблицам по имени, и ей не важно, какая таблица находится в списке первой, какая второй и т.д. Просто при создании новой базы 1С создает нужные таблицы друг за другом в том порядке, в каком это создание написали программисты 1С. Поэтому всегда и получается, что CONFIG идет первой, CONFIGSAVE второй и т.д. Но если бы первой таблицей была бы какая-нибудь _REFERENCE152, а CONFIG была бы семнадцатой в списке, 1С спокойно бы работала с такой базой.

Шаг №4а. Загружаем в пустую конфигурацию выгруженную конфигурацию (извините за каламбур)

Загрузили. Записали. Смотрим в HEX-редакторе

Структура в другой платформе

Так-с, что-то не то, какая-то новая таблица добавилась. Отсюда вывод: Восстановление нужно делать на том же релизе платформы, что и испорченная база.

Шаг №5б. Загружаем в пустую конфигурацию выгруженную конфигурацию той же самой версии платформы

Смотрим результат:

Рабочая конфигурация

Да-а, результат тоже не очень. Таблица CONFIG заканчивается по адресу 0x10FFF, судя по всему она не реструктуризирована. Ладно попробуем скопировать рабочую таблицу Tool_1CD в нерабочую базу. Выделяем блок в рабочей базе и копируем с замещением по адресу 0x5000 в испорченную базу:

Выделение блока

Открываем Tool_1CD, открываем испорченную базу, но увы Tool_1CD виснет при попытке посмотреть таблицу CONFIG. После нескольких не правильных шагов, мне пришла идея: а что если 1С структурирует таблицы при загрузке базы? Тогда остается сделать выгрузку и загрузку базы с рабочей конфигурацией.

Шаг №5в. Загружаем в пустую конфигурацию выгруженную конфигурацию той же самой версии платформы, делаем выгрузку и загрузку базы (не конфигурации!).

Посмотрим как сейчас выглядят смещения:

После выгрузки/загрузки

Уже лучше. Теперь CONFIGSAVE расположена по адресу 0x31FC000, что больше чем 0x31F1000. Как же скопировать больший блок таблицы CONFIG в рабочей базе на меньший блок в испорченной базе? Ответ прост: надо удалить метаданные в рабочей конфигурации, не влияющие на ее структуру: общие модули, картинки, отчеты, обработки и т.п. Нам важно запустить испорченную базу, конфигурацию мы потом восстановим.

Шаг 6. Итерация по удалению метаданных конфигурации, не влияющие на ее структуру, выгрузка и загрузка базы.

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

Удаление метаданных

Наконец-то: CONFIGSAVE начинается с 0x313B0000<0x31F1000. Теперь выделяем блок 0x5000-x313AFFF в рабочей базе и в адрес 0x5000 в испорченной базы копируем с замещением

Копируем блок

Записываем. Открываем 1С. Отклично, все заработало.

Upd 10/10/2012

Важное замечание awa

Как правило по смещению 0x4000, содержатся ссылки на файлы описания таблиц. А уже в файлах описания таблиц содержатся ссылки на таблицы записей, индексов и BLOB. В общем случае, если таблица CONFIG "начинается" с адреса 0x5000, а таблица CONFIGSAVE с адреса 0x31f1000 и нет никакой гарантии, что на промежутке от 0x5000 до 0x31f1000 не содержится ни одного блока, относящегося к любой другой таблице, помимо CONFIG. В большинстве случаев таблица CONFIG не фрагментирована, объясняется это, думаю, тем, что такое расположение файлов одной таблицы друг за другом, так, что вся таблица как бы находится в файле 1CD одним непрерывным куском, образуется в результате применения сжатия базы данных при тестировании и исправлении или при применении утилиты chdbfl.exe.

База загрузилась

Осталось только загрузить в базу рабочую конфигурацию, чтобы восстановить рабочую базу. Все, База восстановлена.

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



MuI_I_Ika

Некритичные ошибки она исправляет. Для критичных всегда должен быть бекап.

greenLiss

ну да - ну да, бекап :ooifh:
Обычно такие базы приходят именно когда фирмой никто не занимается, и естественно никто даже батник для бекапов не удосужился написать :)

П.С. Устал читать про бекапы, везде пишут одно и тоже... Все такие умные :nhsrm: . Я думаю, если есть конкретная задача, нужно решать именно её, а не рассуждать, что должно было бы быть...

Рейтинг@Mail.ru

Поиск