Восстановление файловой базы данных. Первый случай

Структура файла базы данных 1CD
Я начну с небольшого обзора ….
Страницы
Если рассматривать структуру файловой базы данных целиком, то файл 1CD состоит из страниц
(блоков). Размер одного такого блока равен 4 килобайта (это статичный размер для всех
страниц/блоков). Именно поэтому размер файла базы 1CD всегда кратен 4 килобайтам.
Файлы
На более высоком уровне – из страниц состоят файлы (имеются в виду внутренние служебные
файлы). Здесь изображена структура одного файла. Каждый красненький прямоугольничек на
этом рисунке – это одна четырехкилобайтная страница.
Каждый такой внутренний файл базы состоит из одной или более страниц:



ровно одной заголовочной страницы, которая содержит служебные данные (сигнатуру,
длину файла и версию), а также массив номеров служебных страниц размещения
страниц размещения, которые, в свою очередь, содержат массив номеров страниц
данных.
страниц данных, в которых содержатся сами реальные данные файла.
Страницы, принадлежащие одному файлу, совсем не обязаны следовать друг за другом, они
могут быть разбросаны по всей базе. Если файл имеют нулевую длину, то у него есть только
заголовочная страница. Если же файл содержит хотя бы 1 байт данных (имеет длину 1), у файла
уже есть три страницы – заголовочная, одна страница размещения и одна страница данных, в
которой и записан это байт.
Таблицы
На самом верхнем уровне – из файлов состоят таблицы. Каждая таблица – это совокупность
четырех файлов максимум.




Один из этих файлов – это файл описания таблицы DESCR. Он содержит текстовое
описание таблицы (имя таблицы, состав полей и индексов). Также в нем указаны (в
качестве объявления вида {“Files”, <НомерФайлаЗаписей>,< НомерФайлаBlob>,<
НомерФайлаИндексов>}) номера трех оставшихся файлов:
файла записей (DATA),
файла индексов (INDEX)
и файла данных неограниченной длины (BLOB).
Файл индексов и файл BLOB могут отсутствовать, если в таблице нет ни одного индекса и если нет
ни одного поля с данными неограниченной длины. Структура непосредственно файла записей
DATA представляет собой просто обычный массив записей.
Я не буду сейчас здесь подробно все расписывать – в моей статье есть вся подробная информация
о структуре данных. Это был просто короткий обзор, чтобы можно было бы иметь какое-то
наглядное представление. Основная мысль этого обзора была в том, что файловая база 1С
достаточно просто устроена, но в ее восстановлении это нам сейчас не поможет.
Восстановление файловой базы данных.
Первый случай – разрушение при обновлении
Сегодня я вам покажу две базы. Это реальные две базы, которые мне буквально на днях
прислали. Ко мне обращаются иногда. Я восстанавливаю базы. После этого я их стираю. Я их не
храню. Но сегодня я вам покажу те две последние базы, которые еще не успел стереть.
 Это значит – что в случае чего к вам можно обращаться, если у меня есть битая
база?
 Можно, в случае, если база не открывается.
Вообще, давайте выясним, что такое «битые базы»?
Битая база в моем понимании – это такая база, которая не открывается ни в
конфигураторе, ни в предприятии. Точнее, в предприятии она может открываться.
Основная проблема «битой» базы для меня в том, что она не открывается в
конфигураторе, соответственно с ней дальше ничего нельзя сделать. Ее нельзя обновить,
отредактировать, нельзя выгрузить. Если она открывается в предприятии, есть еще шанс
выгрузки/загрузки XML.
Мы не рассматриваем те случаи, когда база не открывается из-за проблем с кэшем. Или,
когда она не открывается из-за проблем по сети или проблем прав доступа к папке. Это
все не битые базы, естественно.
 А если база загружается в конфигураторе, но выгрузка/загрузка dt в ней не удается?
Или конфигурацию выгрузить/загрузить нельзя?
 Это, как правило, тоже битые базы. Чаще всего такие базы даже в режиме конфигуратора
не открываются. Бывает еще такой случай, что база открывается в конфигураторе только
потому, что сохранен кэш. Поскольку 1С сохраняет локально кэш конфигурации в файл, то,
когда она открывает конфигурацию – там реально читается не весь файл базы данных,
какие-то данные читаются из кэша. И там, в кэше – действительно могут быть еще
нормальные данные. А в самой базе – уже будут битые данные. Соответственно, если эту
базу перенести на другой компьютер, туда, где нет этого кэша, она перестанет
открываться.
В любом случае то, что не проходит выгрузка/загрузка, означает, что база битая.
Чтобы точно убедиться, что база в порядке, вы можете в тестировании/исправлении
сделать реструктуризацию базы.
Если реструктуризация полностью проходит, значит база в порядке. Если в базе есть
проблемы, полную реструктуризацию она не пройдет.
Сегодня я покажу новые возможности своей программы Tool_1CD. В ней сейчас многое
изменилось. В частности, добавилось редактирование. Я ее планирую выложить на Инфостарт, но
описание еще не совсем готово.
Я открываю программой Tool_1CD одну из битых баз. И первое, что я хочу сейчас проверить – это
целостность таблицы CONFIG (таблицы конфигурации базы данных).
И здесь мы можем видеть, что в файле CONFIG есть битые записи – записи, у которых поле
FILENAME пустое, а значение поля DATASIZE (размер файла) равно нулю.
Вообще, если в таблице CONFIG существуют файлы с нулевой длиной, то это уже означает, что
конфигурация битая однозначно. Файлов с нулевой длиной там быть не может.
Есть один случай – это признак динамического обновления. Там появляется файл
dynamically_updated – он с нулевой длиной. Но это тоже нехорошо.
Здесь мы видим файлы с расширением .new – это означает, что база упала в момент обновления.
В момент обновления конфигураций новый файл сначала пишется с расширением .new, потом
старые удаляются, а потом вот эти файлы с расширением .new переименовываются (без
расширения .new, соответственно).
Точно также можно посмотреть CONFIGSAVE. Мы видим, что здесь тоже какие-то проблемы – тут
тоже есть файлы нулевой длины.
То есть, мы здесь делаем вывод, что в данном случае конфигурация абсолютно битая. Ее надо
восстанавливать.
В 1С мы встречаемся с различными понятиями о том, какая бывает конфигурация: в 1С бывает
конфигурация поставщика, конфигурация базы данных и основная конфигурация.
1. Конфигурация поставщика – это содержимое поля BLOB одной из записей таблицы
CONFIG. Таких записей может быть несколько – столько, сколько конфигураций
поставщика есть в базе.
2. Конфигурация базы данных – это текущая рабочая конфигурация, на основе которой
созданы все таблицы базы данных. Если проводить аналогии с таблицами базы данных, то
конфигурация базы данных хранится в таблице CONFIG.
3. Основная конфигурация – это та конфигурация, которая разрабатывается. Этой
конфигурации соответствует таблица CONFIGSAVE. Но только в таблице CONFIGSAVE
хранится не сама основная конфигурация, а только ее отличия. Если у вас основная
конфигурация совпадает с конфигурацией базы данных, то CONFIGSAVE будет просто
пустой. Это нормальная ситуация. Обычно в рабочих базах таблица CONFIGSAVE
совершенно пустая. Как только вы начинаете что-то менять, то, что вы поменяли,
записывается в CONFIGSAVE.
Соответственно, в CONFIGSAVE хранятся только отличия. И если мы делаем операцию
«Вернуться к конфигурации базы данных», то мы просто очищаем таблицу CONFIGSAVE.
Для того чтобы восстановить потерянные данные нашей информационной базы у нас должен
быть какой-то источник для восстановления. Мы ведь не можем восстановить информацию,
которая потеряна совсем, восстановить «из ничего», «из воздуха». В данном случае у нас,
например, конфигурация битая. И нам надо, соответственно, эту конфигурацию откуда-то взять.
Мы не будем восстанавливать эту конфигурацию, которая у нас есть. Это очень неблагодарное
дело. И, боюсь, бесполезное. Тут несколько тысяч файлов, среди которых много битых записей, и
я мы вряд ли сможем ее целиком восстановить, – просто не получится ничего из этого вытянуть.
Однако, как правило, конфигурации у нас типовые. Поэтому надо просто взять конфигурацию
типовую с сайта 1С, например, или из других источников.
Для начала, нам надо сначала определить версию типовой конфигурации, которая соответствует
той, которая у нас поломалась. Так как ни в режиме Предприятие, ни в режиме Конфигуратора
база у нас не открывается, соответственно, мы идем в таблицы и ищем версию типовой
конфигурации там.
Как можно посмотреть текущую версию конфигурации?
Возможно, нам удается найти в файлах таблицы CONFIG файл root (правда у нас здесь root.new
получается). В общем, в файле root или root.new всегда указан UUID того файла, в котором описан
корень конфигурации (главный файл конфигурации).
В общем – тот UUID, который мы увидим в файле root – тут он выглядит как e0666db2-45d6-49b4a200-061c6ba7d569.
Потом мы попытаемся найти этот файл. Если он цел, то нам повезло. Мы нашли корневой файл
всей конфигурации.
Здесь записано название конфигурации (мы видим, что это «Бухгалтерия 2.0.»), и, если сюда, чуть
дальше промотать, то здесь будет вот это – версия конфигурации. Это версия текущая – то, что
сейчас используется.
Так, как падение произошло в момент обновления (это очень частый случай, когда именно в
момент обновления база падает), то, соответственно, есть версия конфигурации, с которой мы
обновлялись и есть версия конфигурации, на которую мы обновлялись. И, сказать заранее, в
каком состоянии таблицы сейчас находятся невозможно. А версию конфигурации нам сейчас надо
установить именно ту, в которой сейчас уже таблицы. Если таблицы не успели обновиться, то,
соответственно, надо установить конфигурацию до обновления. Если таблицы уже успели
обновиться и, то структура уже поменялась. И, соответственно, нам надо установить уже новую
версию. И поэтому, вторым шагом мы сейчас должны проверить, какая версия конфигурации у нас
сейчас находится в режиме «Предприятия».
То есть, первым шагом мы проверили версию конфигурации в таблице CONFIG – там у нас сейчас
записан номер версии 2.0.46.8. А вторым шагом мы проверяем константу, которая содержит
версию конфигурации. Если мы обновляем типовые конфигурации, то всегда в таблицах, в
которых хранятся константы, мы можем найти такую константу.
Раньше таблица констант была одна. Там было много полей. Сейчас 1С сделала раздельное
хранение констант – для каждой константы свою таблицу.
То есть, мы просто пробегаемся по этим константам и ищем таблицу константы, в которую
записан номер версии. Ее сразу характерно видно. Тут указана версия 2.0.45.5. Это означает, что
версия, «с которой мы обновляемся» – это версия 2.0.45.5.
Потом, соответственно, нам надо взять обе конфигурации. Я их, конечно же, уже принес. Вот они.
Но в реальной жизни мы сначала определяем, а потом ищем эти конфигурации. Теперь для того,
чтобы понять, какая же конфигурация из них правильная и соответствует, нам надо будет создать
две новые пустые базы. В каждую из этих новых пустых баз мы сейчас загрузим соответствующую
конфигурацию.
 А как мы можем посмотреть конфигурацию поставщика?
 Конфигурация поставщика – она хранится внутри. Это просто как один большой файл в
таблице CONFIG. То есть, когда мы выгружаем конфигурацию, даже если эта конфигурация
у нас изменена – конфигурация поставщика все равно там.
Что фактически происходит? В этой конфигурации у нас конфигурации поставщика нету –
потому что мы ее не снимали с поддержки. Но, если мы включаем режим изменения, то
текущая конфигурация (CONFIG) – она сохраняется в файл, который записывается туда же,
в таблицу CONFIG. Он как бы дублирует ее.
Потом эта таблица CONFIG может изменяться, обновляться, еще что-то. Но этот файл
поставщика – он остается неизменным (пока мы не обновим конфигурацию поставщика).
Именно поэтому, как только вы включаете режим изменения конфигурации, у вас cf файл,
который вы выгружаете, просто вдруг становится в два раза больше объемом. Потому что
там становится сразу две конфигурации. До тех пор, пока не включен режим изменения
конфигурации там конфигурация одна. Зачем ее дублировать в этом случае – она же
ничем не отличается от первоначальной.
 В платформе 8.3 там такое же строение базы данных или что-то другое совсем?
 Я внимательно не смотрел, но сами структуры файловых почти ничем не отличаются.
Вообще, начиная с версии 8.0 никакой разницы практически не было. Вся внутренняя
структура файловых баз – она абсолютно идентична во всех версиях, начиная с 8.1.
Единственная разница в том, что происходит реструктуризация – формат индексов
меняется. Даже не собственно сам формат индексов, а меняется версия библиотеки,
которую 1С использует – это IBM-овская библиотека ICU. Просто при выпуске новой
редакции базы более новую версию библиотеки подключают, а новая версия генерирует
уже другие индексы. Поэтому вся конвертация, когда мы переходим, например, с 8.2.13 на
8.2.14 – это просто переиндексация. Они просто делают переиндексацию базы, и в
заголовочном файле меняется, соответственно, номер версии. Ничего более.
Например, до тех пор, пока платформа 8.2 была бетой, формат ее базы был 8.1. Как только
они выпустили 8.2, соответственно, формат базы поменялся на 8.2. Я так думаю, когда уже
будет финальная 8.3 выпущена, в нее тоже, скорее всего, будут внедрены новые версии
библиотеки, и внутри поставят метку 8.3.
 Вот еще вопрос: в 18 релизе 8.2 было анонсировано, что оптимизирована работа с
файловой базой данных. За счет чего это может быть сделано в плане внутренней
структуры базы?
 Структура, как я уже говорил, не изменилась. То есть, заявленная оптимизация была
выполнена на уровне внутренней работы платформы 1С. Вы же понимаете, что падения в
большинстве случаев происходят по вине самой 1С. Обычно это случается в момент
обновления, если, например, отключился свет, а источника бесперебойного питания нету.
Или обновляют по сети. А сеть, соответственно, может тоже иметь свои перебои.
 У нас такая ситуация – очень много точек и падения баз при превышении объема
базы более 2-х гигабайт участились (на 1000 баз где-то 50 падений в месяц). Кэш
чистится при старте каждый день.
 Это кстати тоже плохо. Конечно, когда кэш битый, его чистка, безусловно, необходимая
вещь. Но чистить его просто так каждый день – это необоснованно нагружать саму базу.
Ведь кэш он и существует для того, чтобы разгрузить, как говориться, дать работать
другим. Если база у вас обновляется – тогда да. Можно посоветовать автоматически
чистить кэш, но только при обновлении. Например, вы обновили конфигурацию только что
– почистите сразу кэш, включая кэш пользовательский, чтобы у них действительно, 100%
запустилось в новой версии. Если конфигурация не обновлялась, не нужно чистить кэш.
 Ну а в чем разница запуска без чистки кэша? Я так понимаю, что просто будет
первый запуск быстрее и все. Дальнейшая работа будет аналогичной. Это
единственный плюс этого кэша, как я понимаю.
 Ну, в принципе, да. Все зависит от объема баз и от скорости соединения. У нас есть
ситуация, когда по 4-гигабитному каналу работают напрямую, и без кэша запуск минут 10
занимает.
 Нет. У нас все локально. И падения у нас почему-то происходят именно при
превышении размера базы (когда она становится больше гигабайта)
 Честно говоря, я не знаю причин, чтобы падение базы происходило «до гигабайта» или
«после гигабайта». Файловая база может быть и 30 гигабайт. Существует только
ограничение на размер таблицы – ее размер может быть максимум 4 гигабайта. Это
абсолютно не зависит от операционной системы, на которой установлена платформа. Это
ограничение внутреннего формата таблицы файловой базы данных.
 Получается, что как только внутренний объем одной таблицы в базе превысит 4 Гб,
с базой же уже в этом случае ничего нельзя будет сделать - нельзя будет ее
выгрузить даже в SQL. Как поступить тогда?
 На самом деле размер таблицы файловой базы данных просто не может превысить 4 Гб.
База просто в какой-то момент не запишет часть данных. При этом выгрузить в SQL-то вы
ее сможете. Другое дело, что в этот момент там данные уже будут какие-то
несогласованные. Но это естественно. Если внутренний файл превышает 4 Гб, кроме как
перехода на SQL – никакого другого выбора нет.
Теперь, для того, чтобы понять, какая же конфигурация реально наша, мы открываем обе базы в
Tool_1CD.
Первый признак – это количество таблиц. Как правило, 1С, когда меняет релиз, добавляет какието новые объекты. И конфигурации можно сравнить уже по количеству таблиц, которые созданы.
Сами названия таблиц будут другие. А вот количество их в любом случае будет то же самое (у
одной и той же конфигурации количество таблиц будет одно и то же).
Смотрим, сколько таблиц у нас в битой базе – 1752. А в базе, в которую мы развернули пустую
конфигурацию версии 2.0.45.5 – у нас 1744 таблицы.
 А если мы восстанавливаем измененную конфигурацию? В которую мы уже добавили
свои объекты?
 Дело в том, что если у вас нет конфигурации той, которая была – у вас не получится
восстановить базу, накатив на нее типовую конфигурацию.
Это возможно только в том случае, если у вас есть только такие изменения, которые не
затрагивают структуру базы данных. В любом случае для восстановления вам нужно иметь
конфигурацию вашу, измененную.
Итак, мы видим, что количество таблиц здесь не совпадает. Значит, смотрим уже в конфигурацию
2.0.46.8. И вот, здесь мы видим уже как раз 1752 таблицы. То есть, ровно столько же, сколько и в
битой базе.
Отсюда мы уже можем сделать вывод, что нужная нам конфигурация – это конфигурация 2.0.46.8.
То есть, в битой базе таблицы уже реструктуризировались.
 А вот интересно – ведь объекты при обновлении иногда не только добавляются, но
еще и удаляются. Ведь неизвестно, в какой момент происходит падение? Может
быть, сначала было добавление новых таблиц для объектов, а потом база упала, и
при этом удаления таблиц не произошло?
 В момент реструктуризации 1С делает новые таблицы – они с расширением "NG" или
"OG". А потом, когда она сделала все новые, она удаляет старые таблицы. И при этом она
удаляет те таблицы, которые просто удалены. И также удаляет те таблицы, из которых она
данные переносила, которые изменились. Потому что, даже если мы просто изменяем
таблицу (например, добавляем какой-то реквизит в какой-то справочник), то в момент
реструктуризации 1С создает новую таблицу с новым составом полей, и, после этого, из
старой таблицы копирует все данные в новую. То есть, у вас на тот момент существует две
таблицы одновременно. И, только после того, как она скопировала все данные в новую (в
которой появилось дополнительное поле для добавленного реквизита), она уже удаляет
старую.
 А если база рухнула на этапе самой реструктуризации базы?
 На самом деле, в этом случае, вы, просматривая в битой базе список таблиц, увидите там
таблицы с суффиксами "NG" или "OG". NG – это новые таблицы (New Generation), OG,
видимо – это старые таблицы (Old Generation). Здесь, в этой базе, все таблицы чистенькие.
 А, ведь например, бывает такое, что в одном релизе – была одна таблица добавлена
и одна удалена? Ведь тогда же одинаковое количество таблиц и в том и другом
релизе получается? Как в этом случае определить номер релиза? Получается, что
количество таблиц – это неоднозначный признак.
 Из моей практики (я восстановил уже более 100 баз) – такого не бывает. Правда, если
говорить честно, четверть из этих 100 баз восстановить не удалось. То есть, далеко не
всегда это удается, на самом деле.
Но я такого не встречал, чтобы прямо количество таблиц и в том и в другом релизе
совпало. В любом случае, вы же в момент восстановления делаете копию. Это я сейчас
делаю без всяких копий, без ничего.
А если вы получили битую базу, вы сначала должны сохранить ее в том, первоначальном
виде. Потом попытаться что-то с ней сделать. Никто не запрещает вам попробовать одну
конфигурацию накатить (допустим, действительно, у вас и в том и в другом релизе совпало
количество таблиц), и, если она потом упала, другую конфигурацию попробовать.
В общем, мы остановились на том, что мы выяснили, какая нам нужна конфигурация. Открываем в
Tool_1CD информационную базу с полноценной конфигурацией этого релиза. Переходим на
закладку «Дополнительно». Вы эту закладку еще не видели. Эта закладка появилась в новой
версии. Здесь есть некоторые инструменты, которые помогают в восстановлении таблиц.
Это инструменты, которые я создавал в течение всего последнего года. Здесь нет какого-то
законченного набора, никакой цельной структуры. Это просто такой хаотичный набор того, что
мне понадобилось в тот или иной момент при восстановлении информационных баз. Тут далеко
не все актуально может быть.
Итак:
1. Я открываю в Tool_1CD информационную базу с полноценной конфигурацией нужного
нам релиза.
2. На закладке «Дополнительно» в качестве директории импорта/экспорта выбираю путь
экспорта (заранее создаю для этого папку «Экспорт»)
3. Встаю в списке таблиц (который слева) на таблицу CONFIG и нажимаю «Экспорт текущей
таблицы».
4. И для таблицы CONFIGSAVE тоже делаю экспорт таблицы.
Таким образом – я просто-напросто эти две таблицы в заранее созданную папочку «Экспорт»
выгрузил. Вот они. Сюда сохранились все те файлы таблиц, о которых я вам говорил (файлы root,
descr, data, index, blob).
Теперь нам надо в нашей битой базе сделать импорт таблиц CONFIG и CONFIGSAVE.
1. Я открываю в Tool_1CD битую базу.
2. На закладке «Дополнительно» в качестве директории импорта/экспорта выбираю нашу
папку «Экспорт»
3. Встаю в списке таблиц (который слева) на таблицу CONFIG и нажимаю «Импорт текущей
таблицы».
4. И для таблицы CONFIGSAVE тоже делаю импорт таблицы.
Таким образом, мы заменяем битые таблицы на аналогичные им полноценные таблицы.
Сразу после того, как мы импортировали файлы в нашу битую базу, мы заходим в конфигуратор и,
первое, что мы делаем – это тестирование и исправление с галочкой «Реструктуризация таблиц
информационной базы».
 А все остальные пункты, тестирования и исправления - какая их может быть роль в
восстановлении? Есть там что-нибудь еще интересное?
 С точки зрения восстановления – не очень. Их потом, естественно, тоже надо сделать.
Более того, особо важно будет сделать сжатие, потому что после реструктуризации объем
базы вырастет в два раза. Вообще сам процесс реструктуризации базы данных – это
создание новой таблицы и перегрузка данных из старой таблицы в новую. И при обычном
обновлении реструктуризация затрагивает только те таблицы, которые изменились. А при
ее запуске через ТиИ реструктуризация будет в любом случае затрагивать все таблицы. То
есть, она в любом случае создает новую таблицу, копирует данные из старой таблицы в
новую, потом старую таблицу удаляет. При этом читается вся база целиком. Именно
поэтому это и есть очень хорошая проверка того, что здесь все в порядке. Если что-то гдето не так, то она может на любой таблице заткнуться и жестко упасть с ошибкой.
 А вот удаление удаленных строчек – это реструктуризация? Сама
реструктуризация удаленные строчки удаляет?
 Удаление удаленных строчек – это сжатие. Да, в новой таблице после реструктуризации
самих удаленных строчек не будет. Но файл после реструктуризации так и останется
большого объема. Само удаление таблиц – это просто помечение внутри файла 1СD, что
эти страницы, которые занимала эта таблица, стали свободными. А сам файл – все равно
будет большой. Если рассматривать просто отдельно таблицу, то там да, там этих записей
не будет.
 Перед ремонтом базы мы должны сделать копию всей папки файловой базы данных?
 На самом деле, файл базы данных – это просто файл 1CD. Конечно, этот файл желательно
скопировать перед любыми манипуляциями. То есть, то, что я вам сейчас показываю – я
просто знаю, что это у меня получится, потому что я уже это делал. В реальности, когда я
восстанавливаю базу данных, фактически после каждого шага я, на всякий случай, делаю
бекапы.
 У нас, например, была такая ситуация: когда еще конфигуратор открывался – мы
запустили chdbfl.exe, и он, конечно, что-то отремонтировал, но при этом он удалил
данные, удалил проводки.
 Работу cdbfl я вам сейчас покажу как раз.
Итак, вот у нас сейчас все прошло. И я уже не буду сейчас делать уже оставшиеся пункты
«Тестирования и исправления». Могу просто сейчас нашу информационную базу в режиме
«Предприятие» запустить. Она уже замечательно запускается. Здесь все хорошо. Проходит
обновление.
Эксперимент с cdbfl.exe
Во второй базе, которую мы будем восстанавливать, нам придется работать с помощью
шестнадцатеричного редактора, потому что не бывает средств на все случаи жизни. Потому что
Tool_1CD – она тоже не универсальна. Например, если начало файла затерто вирусом, как
произошло в этом конкретном случае, Tool_1CD даже не откроет эту базу. Конечно, Tool_1CD
очень многое может сделать, но далеко не всегда это помогает. Приходится иногда
шестнадцатеричным редактором все равно лезть.
Теперь, прежде чем показать вторую базу для восстановления, я хочу вам показать один
искусственный пример, связанный как раз с работой утилиты chdbfl.exe.
Я сейчас возьму вот нашу первую базу, которую мы только что восстановили, которая хорошая. И
открою ее шестнадцатеричным редактором.
Перехожу к специальному адресу 4020. И делаю простую вещь – стираю два байта. В моей
практике были «битые» базы, когда реально какой-то один бит менялся и этот бит приходился на
файл DBSCHEMA и база после этого переставала запускаться.
То есть, после того, как я этот бит нашел – совершенно случайно – его поменял – и база
запустилась в полном порядке.
Я про то, что бывают какие-то сбойные обстоятельства – представьте, на дисках какие-то сбои,
еще что-то происходит.
Сейчас я здесь – в этой – абсолютно рабочей базе всего-то каких-то два байта исправил. 4020 – это
адрес, содержащий количество таблиц. И теперь я покажу, что теперь – после того, как я два байта
исправил – это ведь вроде как небольшой сбой – база размером 356 МБ. Там все данные вроде
как есть. Понятно, что этими двумя байтами я ничего не затер.
Теперь открываем наш chdbfl.exe и в нем мы указываем сейчас эту базу, в которой я сейчас стер
два байта и поставим вот эту галочку «Исправлять обнаруженные ошибки».
Утилита написала «Ошибок не обнаружено». А теперь посмотрите на размер базы. От 356 Мб
осталось 20 кб.
Так вот, chdbfl.exe – она работает по принципу, в чем-то похожему на «сжатие таблиц». Она, если
мы поставили галочку «Исправлять обнаруженные ошибки», всегда создает новый файл и
пытается туда записать все, что смогла прочитать.
Если в базе есть какие-то сбои, и cdbfl что-то не прочитала, то получается, что эти данные она
просто потеряла. Потому что эта утилита совершенно без предупреждений удаляет старый файл
базы. То есть, до того, как мы chdbfl применили, эти данные еще можно было как-то восстановить,
а после ее применения – их в базе уже нет. Поэтому, если у вас битая база, прежде чем применять
chdbfl, всегда делайте копию. Вот у вас случился сбой – сделайте копию, положите куда-то этот
битый файл изначальный. До каких-либо других телодвижений.
Очень часто мне присылают файл после chdbfl, а с базой уже после него ничего сделать нельзя.
Chdbfl – что сделала, то сделала. Восстановить то, что она удалила, мне просто неоткуда. Это как
предупреждение.
 То есть, она может потереть какой-нибудь регистр, потому что он поломался? И
это даже сразу не заметишь?
 Да. Были такие случаи, причем несколько, примерно в одно время – почему-то портился
индекс у таблицы CONFIG. Chdbfl при этом просто-напросто индекс удаляла. Из описания
таблицы его удаляла и удаляла сам индекс. Сама таблица CONFIG после этого была
абсолютно нормальная – с помощью Tool_1CD ее можно было смотреть абсолютно
спокойно, но индекса в ней просто не было (там есть единственный индекс по имени
файла). При этом и конфигуратор и предприятие – напрочь отказывались работать. Они
предполагали, что этот индекс существует.
Chdbfl – это утилита, которая пытается восстановить данные на уровне файловой базы как
таковой.
Вот в чем отличие файловой базы от информационной базы?

Файловая база – это просто некое хранилище. Например, хранилище конфигурации – это
тоже файловая база. Хотя там нет таблицы CONFIG, там нет таблицы CONFIGSAVE, USERS и
прочего. Там свои таблицы. Но это тоже файловая база.

А в информационной базе 1С обязательно есть системные таблицы CONFIG, CONFIGSAVE,
PARAMS, FILES, DBSCHEMA и V8USERS. И, соответственно, и конфигуратор, и предприятие –
они предполагают, что там эти таблицы есть, что у них определенная структура,
определенные индексы… Если что-то не так, они просто не работают.
А chdbfl – она про это ничего не знает. Ни про информационную базу, ни про таблицы CONFIG, ни
про еще что-то. Она просто пытается что-то сделать так, как ей кажется правильным. Она, конечно,
не удаляет таблицы и не очищает их содержимое. Просто, точно так же, как и сжатие, она создает
новый файл и пишет туда все, что смогла прочитать из старого файла, а потом старый файл
удаляет. При этом удаляет без предупреждения все, что не прочитала. То есть, все, что она не
прочитала – это все исчезло.
А как вы думаете, почему в базе осталось 20кб? Даже если база абсолютно пуста и в ней нет ни
одной таблицы, то в файле базы все равно есть предопределенные объекты:

Нулевая страница (содержит сигнатуру базы, версию структуры базы и длину базы в
страницах)

Файл свободных страниц. Так как в пустой базе этот файл пустой, то он содержит только
заголовочную страницу;

Корневой файл. В пустой базе этот файл не нулевой длины – в нем содержится код
локализации и количество таблиц. Поэтому состоит из трех страниц – заголовочной
страницы, одной страницы размещения и одной страницы данных.
Итого 5 страниц по 4 килобайта – 20 килобайт. Именно такой размер мы получили в нашем
эксперименте с chdbfl.exe.
Восстановление файловой базы данных.
Второй случай – начало файла зашифровано вирусом
Вот я вам сейчас покажу этот второй файл. Пытаюсь его с помощью Tool_1CD – не открывает,
вылезает ошибка «Невозможно установить связь с объектом». Открываем этот файл
шестнадцатеричным редактором. И видим – что на самом деле произошло? Клиент поймал вирусвымогатель, который шифрует файлы, потом выдает табличку, что «Ваши файлы зашифрованы.
Перечислите столько-то туда-то и т.д». При этом клиент перечислил деньги, злоумышленники
прислали программу расшифровки, которая расшифровала, как мы видим, первые меньше ста
байт. А дальше, тут видно – оно пошло зашифрованное.
Присылают точно такие же базы – они просто зашифрованные. Как правило, шифруется какой-то
определенный участок файла – может быть его первый мегабайт.
Как мы сейчас будем чинить эту базу?
Мы сейчас возьмем ту базу, которую мы только что получили путем работы chdbfl – в которой
всего 20 кб. Ее можно даже в Tool_1CD открыть. Она открывается нормально. С точки зрения
файловых баз это абсолютно валидная, хорошая база, только в ней нет ни одной таблицы.
Можно сказать, что это пустышка-заготовка любой файловой базы.
 Если создать чистую базу – будет такая же?
 Нет, в том-то и дело, что если мы создадим в 1С чистую базу, там уже будет таблица
CONFIG, CONFIGSAVE и пр. Это будет с точки зрения информационной базы чистая база.
А наша пустышка – это чистая база с точки зрения файловой базы. Другим способом,
кроме как работой chdbfl ее, получается, получить невозможно. Но, тем не менее, эта
пустая база нам сейчас, как раз, поможет.
Открываю еще раз наш зашифрованный файл базы в шестнадцатеричном редакторе. Конечно, это
уже от шестнадцатеричного редактора зависит, как заменить один кусочек файла на другой. Но в
моем любимом Hiew это делается так – надо отметить блок байт (клавиша "*") в объеме 20
килобайт, а затем выполнить команду Getblk (Ctrl-F2)
Здесь я пишу путь к моей базе-пустышке. Нажимаю несколько раз Enter.
Теперь эти 20 килобайт я просто заменил – сюда вставил кусок из этой нашей пустой базы.
Если теперь ее попытаться открыть в Tool_1CD – она откроется.
Единственное, что у нас сейчас неправильно – это длина файла в блоках не соответствует. То есть,
нам в шестнадцатеричном редакторе надо будет поправить в одном месте в заголовке.
Заголовок здесь очень простой. В самом начале – первые восемь байт – это индекс сигнатуры –
1CDBMSV8.
Потом четыре байта идут – это версия базы. У нас тут идут 08 02 0E – это означает 8.2.14. А вот
следующие четыре байта – это длина в четырехкилобайтных страницах.
Чтобы ее определить – надо в конец файла пойти, встать на самый последний символ (символ
окончания файла) и определить таким образом его адрес (31749000). Три нуля мы отбрасываем и
записываем то, что осталось (3 17 49) – это будет, по сути, количество блоков. Именно это число
мы и должны прописать в это значение заголовка.
Кто с шестнадцатеричным редактором работал, тот знает, что для того, чтобы записать число
3 17 49 – его нужно в таком виде записать: 49 17 03 – сначала младшие байты, потом средние,
потом старшие. Фиксируем эти изменения. Пробуем, что у нас получилось. Открываем
измененную шестнадцатеричным редактором базу в Tool_1CD.
Ну вот, открылось без ошибок. Но, естественно, таблиц тут как бы нет – потому что мы записали
сюда данные пустой базы. Теперь – в моей программе Tool_1CD на закладке «Дополнительно»
есть такая кнопочка – которая так и называется – «Поиск и восстановление потерянных таблиц».
Что она делает, на самом деле? Она просматривает весь файл базы данных и ищет сигнатуры
начала внутренних файлов – у каждого внутреннего файла вначале одна и та же сигнатура –
1CDBOBV8. Она ищет все такие файлы, пытается прочитать, не является ли этот файл описанием
таблицы. Если он является описанием таблицы, то она его добавляет в корневой файл таблицы.
В результате этого в нашей базе появились все таблицы. Правда пока что отсутствует таблица
CONFIG, потому что она была первой, и она как раз затерта была этим вирусом.
Ну а дальше уже – дело техники. Слава богу, у клиента оказался бэкап двухмесячной давности, в
котором была точно такая же конфигурация, то есть, таблицу CONFIG я все-таки мог откуда-то
восстановить. Я сейчас уже не буду опять показывать одно и то же – я создаю базу новую,
загружаю в нее эту конфигурацию. Потом из этой конфигурации, как я уже показывал, выгружаю
таблицу CONFIG. А потом в битой базе эту таблицу загружаю. Единственное отличие в том, что в
предыдущем случае я делал импорт. Там я вставал на существующую таблицу. А здесь, поскольку
у нас существующая таблица CONFIG отсутствует, я делаю загрузку таблицы другой кнопочкой – я
выбираю каталог и нажимаю «Создание и импорт таблицы».
Суть этого действия та же самая. Она просто создает таблицу, которую мы загружаем.
 Скажите – а вот эти 3 17 49 – размер страницы – вы где его искали?
 Вот смотрите – я вошел в редактор и перешел в самый конец. Последний адрес, который в
этом файле есть это 31749000. Вы можете преобразовать этот адрес через обычный
калькулятор Windows. Открываем калькулятор, делаем вид «Программист». Вот смотрите
– размер файла нашей базы – 829722624 байт. Переводим эту величину к
шестнадцатеричному виду – получаем 31749000. Без трех нулей это и будет 3 17 49.
 И вот этот вот размер пишется в файл базы по какому адресу?
 Последние четыре байта первой строки. По смещению C в самом начале. Первые восемь
байт первой строки – это сигнатура базы, потом четыре байта – это версия базы. А уже по
смещению C (смещение 12) – длина файловой базы в страницах
 А как вы эти значения редактируете?
 Это уже от шестнадцатеричного редактора зависит. Здесь у меня Hiew. В нем нажал F3 и
можно уже все, что угодно отредактировать. А вообще в каждом редакторе это по-своему
редактируется.
 А я прослушал – а как вы пустую файловую базу создали?
 Берете любую базу. В шестнадцатеричном редакторе находите в ней адрес 4020 и меняете
два байта по этому адресу на нули. Это на самом деле количество таблиц мы обнуляем. И
после этого запускаете chdbfl.exe с установленной галочкой «Исправлять обнаруженные
ошибки», и утилита chdbfl просто удаляет все таблицы.
 А на Инфостарте статья об этом есть?
 Нет, пока нет. Но я, кстати, готовлю эту статью. Там будет этот момент про chdbfl описан. Я
просто, честно говоря, не успел ее выпустить до конференции.
 В версии 8.1 появилась возможность изменения конфигурации во время работы
пользователей (динамическое обновление). Несколько раз у меня такое обновление
заканчивалось ошибкой формата потока. При такой ситуации что надо сделать?
Скопировать CONFIG из бэкапа?
 Не существует универсальных решений, во-первых. То, что я показал – это просто такое
типовое и не самое сложное. Конечно, когда вирус зашифровал начало – это может быть
для кого-то сложно. Но вообще это достаточно распространенная проблема и ее можно
решить при удачном стечении обстоятельств.
При динамическом обновлении в таблице CONFIG появляется специальная метка
DBCHANGE. А в таблице CONFIG появляется запись с именем dynamically_updated. Она
нулевой длины. Но если у вас при этом ошибка формата потока, то все, что я могу
посоветовать, это попробовать из Tool_1CD сначала выгрузить конфигурацию. Утилита
Tool_1CD пытается обходить эти динамические обновления и игнорирует эти файлы.
Может быть, если конкретно в них ошибка, это поможет. И, может быть, конфигурация
получится рабочей.
То есть, вы открываете вашу проблемную базу в Tool_1CD и выбираете утилиту «Сохранить
конфигурацию базы данных». Он сохраняет конфигурацию в файл cf. Пытается, по крайней
мере, сохранить. Бывает такое, что он внутри конфигурации битый, а сохраняется
нормальный. Если при сохранении все эти битые файлы он обошел.
Вы попытаетесь загрузить эту конфигурацию в чистую базу и, если она запустилась в
чистой базе, то все хорошо. Тогда вы можете таблицу CONFIG из этой чистой базы просто
перенести в вашу проблемную базу.
 Но ведь мы же уже знаем, что динамические записи всегда существуют поверх
реальных (тех, которые были до динамического обновления). Можно даже
отсортировать файлы в таблице по дате последней модификации и эти
динамические записи просто удалить и все.
 Новая версия удаляет файлы в таблице. Но пользоваться этим все равно неудобно в
данном случае, потому что Tool_1CD не сортирует файлы по дате. То есть подобный
сценарий возможен только для скульных баз. Но, если воспользоваться утилитой
«Сохранить конфигурацию базы данных», она автоматически обходит эти проблемные
файлы.
 А 1С чинит базы?
 Ну да, конечно же. Другое дело, что это занимает 2-3 недели в лучше случае и, насколько я
знаю, у них тоже далеко не всегда получается починить. Я не знаю, с помощью чего они
там чинят. Должны же у них быть какие-то инструменты для этого. Они же это не
выкладывают, и никаким образом не говорят.
Новые возможности Tool_1CD
В новой версии Tool_1CD появилось редактирование.
Можно выделить запись в таблице и вызвать ее на редактирование. Что-нибудь изменить в ней,
записать ее в таком виде. Можно удалить запись. Можно добавить запись. При нажатии кнопочки
«Записать изменения» - Tool_1CD реально эти изменения в базу запишет. Честно говоря, все это
пока находится в стадии альфа.
 А можно ли здесь в таблице найти ссылку нужную?
 Нет. Сейчас прямо нету такого. Хотя, в принципе, сделать, наверное, можно этот
функционал. Вы напишите в публикации на Инфостарте в комментариях это пожелание.
Может быть, сделаю.
 А вы для SQL подобное не планируете?
 А зачем? Там же есть Management Studio.
 У меня такая ситуация была: я делал апдейт, и у меня, так получилось, зависла
ссылка. И в самой базе и в конфигураторе. То есть, получая какой-то справочник по
типу – яполучал другой тип данных. То есть, если я писал Справочники.
Номенклатура.Создать(), то получал справочник на элемент выше всегда. Как будто
там внутренний какой-то нумератор сбился. Это как-то можно исправить?
 Я, честно говоря, с таким не сталкивался. Я думаю, тут может быть проблема следующая. В
таблице PARAMS – есть такая запись DBNames. Это, кстати, очень узкое место. И я думаю,
что если оно портится, действительно может «поехать» нумерация внутри базы.
В DBNames указано соответствие внутренних идентификаторов объектов базы и тех
таблиц, в которых данные этих объектов хранятся.
То есть – вот этот тип соответствует вот этой таблице. Причем нумерация, которая здесь
используется – она сквозная. И вот эти самые номера она потом использует в качестве
типов. Когда у нас, допустим, реквизит составного типа – там есть собственно GUID для
ссылки. А для определения типа этого реквизита в таблице объекта есть отдельное поле с
суффиксом TREF – тип ссылки. И в этом поле хранятся, как раз, вот эти числа. То есть,
соответственно, если вот здесь какой-то справочник Reference50 – то и в таблицах мы тоже
обязательно найдем таблицу Reference50. То есть, это все – те же самые номера. И это –
тот же самый номер, когда нам база пишет «Объект не найден
20:94b81c6f65428d5911e2a8bebc48d793» - то, что идет до двоеточия – это опять же, тот
самый номер. Это номер типа. И, я так понимаю, что-то у вас произошло, что вот эти
номера типов – они сбились.
 А вы не сталкивались с такой проблемой – у меня в конфигурации регламентные
отчеты дописаны, поэтому я обновление делаю сначала на тестовой базе, которая
на XP находится, а потом перетаскиваю это на сервак 64-бит. То есть, я обновляю
конфигурацию на XP и все отлично. Конфигурация открывается. Я выгружаю ее.
Потом пытаюсь загрузить в рабочую – и мне при загрузке конфигурации
вываливается «Ошибка формата потока». Я сидел, вычислял, на что он ругается –
вычислил, что это регламентный отчет «Прибыль». Я попытался перетащить
файловую базу на сервак. Получилось. Без проблем открыл ее в конфигураторе, и
нашел, что не открывается форма конкретно этого отчета. То есть, форму
пытаешься открыть, и он пишет «Ошибка формата потока». Но эта же форма на
XP открывается нормально. Что это за прикол?
 Вот это я не могу сказать. Здесь, например, на страничке «Дополнительно», есть такая
утилита, как «Тест формата потока» - я для себя делал. Она пытается открыть все файлы
конфигурации. И если в каком-то файле увидит такую ошибку, он просто напишет –
ошибка в таком-то файле, ошибка в таком-то файле и т.п. Можно хотя бы попытаться
посмотреть, что это такое, почему там ошибка.
Эта кнопка «Тест формата потока» - проверяет таблички CONFIG, CONFIGSAVE, PARAMS,
FILES и DBSCHEMA, то есть все пять основных таблиц. Например, если в таблице DBSCHEMA
такая ошибка – то просто ничего работать не будет.
Что такое ошибка формата потока? 1С почти все хранит в своем внутреннем формате
сериализации – вот этот вот, с фигурными скобочками. Все внутренние файлы. Там,
соответственно этих скобочек должно быть – сколько открытых, столько и закрытых. В этих
скобочках выводятся данные – либо строка, либо число, ну там, мало ли – GUID
определенного формата – и все это через запятую. Это такой текстовый поток
сериализации. И вот если в этом потоке какой-то баг – скобочка незакрытая, запятая
лишняя, еще что-нибудь – вот это и есть «Ошибка формата потока». Это ошибка этого
внутреннего формата сериализации. Этот формат настолько повсеместно в 1С
применяется, что все в него засериализованы все ваши настройки, все таблицы, да и вся
сама конфигурация. Поэтому эта ошибка может возникать по любому поводу, когда что-то
где-то собьется. Не только в момент обновления. Но особенно часто такое, почему-то
происходит при обновлении конфигурации, при реструктуризации регламентных отчетов,
конкретно их форм.