Предупреждение

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

Введение

Многие люди, работающие с программами 1С в файловом варианте, рано или поздно сталкиваются с такой проблемой, как неработоспособность файловой базы 1С.

Еще совсем недавно информации о способах восстановления в интернете было крайне мало. Вот, например, одна из самых известных статей на эту тему Методика восстановления разрушенных баз 1С:Предприятие 8 Вячеслава Гилева. Все описанные там способы относятся, в основном, к серверным базам данных. Про файловые базы данных там есть 2 совета: попробовать chdbfl.exe и отослать базу в 1С.

В интернете (в основном на Инфостарте) можно найти и другие статьи по восстановлению файловых баз. Вот, для примера, некоторые из них.

Восстановление файловой версии базы данных *.1CD после ошибки динамического обновления.

Восстановление работоспособности базы 1С 8.1 (файловой)

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

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

Большинство советов в таких статьях напоминают шаманские пляски с шестнадцатеричным редактором, и, как правило, применимы только в узких, специальных случаях.

Но в последнее время дело начало сдвигаться с мертвой точки. Сначала появился проект Дмитрия Воробьева (vde69) restoration-base-1c8 и его статья Как я востанавливал базу 1CD.

А совсем недавно появился цикл статей Андрея Савкина (andrewks)

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

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

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

Восстановление работоспособности файловой базы. 3. Конфигурация

Очень рекомендую ознакомиться с ними. Впервые появился системный подход к процессу восстановления файловых баз 1С. Основой предлагаемых Андреем Савкиным способов лечения является его Компонента для прямого чтения/записи данных из файлов баз данных .1CD.

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

Стандартные средства восстановления

Что же нам предоставляет фирма 1С для восстановления файловых баз? Для этого есть инструмент «Тестирование и исправление» в конфигураторе и утилита «chdbfl.exe». Инструмент «Тестирование и исправление» предназначен для выявления и исправления логических ошибок в данных, но не для проверки физической структуры базы. Да и для того чтобы воспользоваться тестированием и исправлением, необходимо войти в конфигуратор. Но в подавляющем большинстве случаев о том, что есть проблемы с базой, люди узнают только тогда, когда база перестает работать совсем, и зайти ни в конфигуратор, ни в предприятие не получается.

Для проверки и восстановления физической структуры файловых баз 1С предлагает нам только утилиту «chdbfl.exe». Ее интерфейс скромен до аскетичности. Все настройки поведения этой утилиты заключены в одной галке «Исправлять обнаруженные ошибки». К сожалению, утилита «chdbfl.exe» обнаруживает далеко не все ошибки, и более того, иногда делает только хуже. Алгоритм работы утилиты в режиме исправления относительно прост. Она читает все данные из файла базы, которые может прочитать, и записывает их в новый файл базы. По окончании старый файл базы утилита удаляет! Без предупреждения. В результате, все данные, которые потенциально есть в битой файловой базе, бесследно исчезают! Желающие могут провести простой эксперимент. Возьмите копию любой непустой базы (обязательно копию! база будет потеряна!), посмотрите на размер файла базы. Исправьте любым шестнадцатеричным редактором в файле 1Cv8.1CD два байта по адресу 0x4020 на нули.

А теперь выполните проверку файла базы утилитой «chdbfl.exe» с установленным флажком «Исправлять обнаруженные ошибки» и посмотрите на размер базы данных. От всей базы вдруг осталось всего 20 килобайт! А утилита «chdbfl.exe» меж тем сказала «Ошибок не обнаружено». Она просто молча удалила всю базу целиком, в базе не осталось ни одной таблицы.

Конечно, это искусственный пример. Те два байта, которые мы обнулили – это на самом деле количество таблиц в базе. Утилита «chdbfl.exe» попыталась считать данные, обнаружила, что в базе 0 таблиц, и именно столько таблиц перенесла в новый файл базы. Но, если до применения утилиты «chdbfl.exe» были все шансы восстановить базу, ведь на самом деле все данные реально содержались в файле базы, то после применения утилиты восстанавливать просто нечего. Этот пример показывает, как себя ведет утилита «chdbfl.exe» в случае, если не может прочитать какие-то данные. Она их просто удаляет! В реальности, я неоднократно сталкивался со случаями, когда «chdbfl.exe» частично удаляла данные. Не всю базу, конечно.

Еще одна неприятная особенность утилиты «chdbfl.exe» заключается в том, что в результате ее работы база может получиться корректной с точки зрения движка баз данных, но некорректной с точки зрения программ конфигуратора и предприятия. Например, было несколько случаев, как под копирку, когда в базе портился единственный индекс таблицы CONFIG, и «chdbfl.exe», вместо того, чтобы создать индекс заново, просто удаляла индекс в таблице совсем. После такого «исправления» не работали ни конфигуратор, ни предприятие.

Надеюсь, я смог вас убедить никогда не запускать «chdbfl.exe» с флажком «Исправлять обнаруженные ошибки», не сделав предварительно копию базы. Я отнюдь не призываю вообще не пользоваться «chdbfl.exe», но делать это надо с осторожностью!

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

Структура файла базы данных 1CD

Техническое описание внутреннего устройства опубликовано мной в статье Краткое описание формата файлов *.1CD (файловых баз 1Сv8). Однако она достаточно сумбурна, плоха для восприятия, поэтому здесь я попытаюсь описать формат немного более популярно. Чтобы не было путаницы с термином «файл», сразу замечу, что когда я буду иметь в виду файл базы *.1CD, я буду говорить «файл базы», когда же я буду говорить про внутренние файлы, содержащиеся внутри базы, я буду употреблять просто термин «файл».

Страницы

На самом нижнем уровне файл базы данных 1CD состоит из страниц размером 4 килобайт (0x1000).

По сути, весь файл базы состоит из массива четырехкилобайтных страниц. Каждая страница имеет свой номер (индекс). Здесь и далее каждый прямоугольник с красной рамкой обозначает одну страницу.

Файлы

На более высоком уровне находятся файлы. Файл состоит из одной или более страниц. У каждого файла есть ровно одна заголовочная страница, в которой размещается массив номеров страниц размещения. В каждой странице размещения, в свою очередь, находится массив номеров страниц данных. Заголовочная страница и страницы размещения – это служебные страницы, которые нужны только для хранения служебных данных (сигнатура, длина файла, версия) и для нахождения страниц данных. Собственно содержимое файла хранится в страницах данных.

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

Таблицы

Ну, а на самом высоком уровне находятся таблицы. Каждая таблица состоит из нескольких файлов:

• файла описания таблицы DESCR;
• файла записей DATA;
• файла индексов INDEX;
• файла данных неограниченной длины BLOB.

Файл описания таблицы DESCR содержит текстовое описание таблицы – имя таблицы, состав полей и индексов. А также файл DESCR содержит номера файлов DATA, INDEX и BLOB. Таблица адресуется с помощью файла описания таблицы. Структуру файлов таблиц мы в данной статье рассматривать не будем, подробности можно узнать из моей статьи, ссылку на которую я приводил выше. Файл индексов может отсутствовать, если в таблице нет ни одного индекса. Файл данных неограниченной длины тоже может отсутствовать, если в таблице нет ни одного поля с данными неограниченной длины.

Адресация

Повторим еще раз. База состоит из таблиц. Таблицы, в свою очередь, состоят из файлов. И наконец, файлы состоят из страниц. Адресом страницы является ее порядковый номер (индекс) в файле базы. Адресом файла является номер его заголовочной страницы. Адресом таблицы является адрес ее файла описания, а значит, номер заголовочной страницы файла описания. Т.е. о каком бы объекте мы бы не говорили – странице, файле или таблице, адресом объекта всегда является просто номер страницы.

Предопределенные объекты.

Но каким образом найти нужную нам таблицу или файл? Как узнать их адрес? В базе есть предопределенные объекты с адресами 0, 1 и 2. Нулевая страница (страница с адресом 0) располагается в самом начале файла базы. Нулевая страница не принадлежит никакому файлу или таблице. Она содержит сигнатуру базы, версию структуры базы и длину базы в страницах. Предопределенный объект с адресом 1 – это специальный файл, содержащий все свободные страницы базы. Файл свободных страниц не принадлежит никакой таблице. И наконец, предопределенный объект с адресом 2 – это корневой файл. В корневом файле содержатся код локализации, количество таблиц в базе и список адресов всех таблиц. Корневой файл также не принадлежит никакой таблице.

Теперь мы можем ответить на вопрос, каков минимальный объем базы? Если база абсолютно пуста и в ней нет ни одной таблицы, то в файле базы все равно есть предопределенные объекты:

• Нулевая страница;
• Файл свободных страниц. Так как в пустой базе этот файл пустой, то он содержит только заголовочную страницу;
• Корневой файл. В пустой базе этот файл не нулевой длины – в нем содержится код локализации и количество таблиц. Поэтому состоит из трех страниц – заголовочной страницы, одной страницы размещения и одной страницы данных.

Итого 5 страниц по 4 килобайта – 20 килобайт. Именно такой размер мы получили в эксперименте с chdbfl.exe, описанном выше.

Структура информационной базы 1С

Теперь рассмотрим вкратце, что нам надо знать про логическую структуру базы 1С. Определимся сначала с терминологией.

Информационная база 1С (файл 1Cv8.1CD) является файловой базой. Но не всякая файловая база является информационной базой 1С. Например, хранилище конфигураций (файл 1Cv8ddb.1CD), тоже является файловой базой, но не является информационной базой 1С.

Проще говоря, файловая база – это любой файл с расширением 1CD, а информационная база 1С – это частный случай файловой базы (с именем 1Cv8.1CD), в которой содержатся конфигурация и бизнес-данные. Тем не менее, когда говорят, что упала файловая база, практически всегда имеют в виду именно информационную базу.

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

Все таблицы информационной базы делятся на 2 категории – системные таблицы и таблицы данных. Системные таблицы хранят служебную информацию, их состав и структура примерно одинаковы во всех базах (в зависимости от версии платформы 1С). Таблицы данных хранят бизнес-данные. Их состав в разных базах может сильно различаться.

Основа базы – это конфигурация, а конкретно конфигурация базы данных. От нее зависит, сколько в базе будет таблиц данных, какая у них будет структура. Конфигурация базы данных хранится в системной таблице CONFIG.

Основная (разрабатываемая) конфигурация целиком в базе не хранится. В таблице CONFIGSAVE хранятся только отличия основной конфигурации от конфигурации базы данных. В рабочих базах, как правило, таблица CONFIGSAVE пустая (кроме момента обновления конфигурации базы). К основным системным таблицам относятся также таблицы FILES, PARAMS и DBSCHEMA.

Таблицы CONFIG, CONFIGSAVE, FILES и PARAMS имеют идентичную структуру и, по сути, являются хранилищами файлов. Таблица DBSCHEMA всегда имеет одно поле и одну запись, хранящую текстовый файл.

При обновлении конфигурации базы данных происходит реструктуризация - процесс создания или изменения таблиц данных, полей и индексов. Но каким образом 1С создает имена таблиц, полей и индексов? Все объекты конфигурации, хранимые в БД, в процессе реструктуризации получают порядковый номер. Если объект конфигурации существовал до реструктуризации, то он сохраняет свой номер, а новые объекты получают номера по порядку, начиная с некоего хранимого максимального номера. Процесс нумерации новых объектов при реструктуризации немного похож на процесс автоматической нумерации документов, когда хранится последний использованный номер, и каждый следующий документ получает номер на единицу больше. Соответствие объектов конфигурации их порядковым номерам хранится в записи DBNames таблицы PARAMS. Приведу для примера кусочек этой записи из одной из баз:

Каждый объект конфигурации имеет свой внутренний уникальный идентификатор, который и используется в записи DBNames. Также здесь указывается тип хранимого объекта и тот самый порядковый номер объекта. Имя объекта в базе формируется как символ подчеркивания плюс тип и плюс номер. Например, таблицы, которые описаны в приведенном примере, будут иметь имена «_Reference2639», «_Document83» и «_Enum113», а индекс будет иметь имя «_ByField1322». Вообще, по имени типа объекта можно понять, что это – поле, индекс, или таблица. Полями являются типы «Fld», «LineNo», «Turnover», «TurnoverDt», «TurnoverCt». Имена типов индексов начинаются на «By» («ByField», «ByOwnerField», «ByParentField», «ByProperty», «ByPropRecorder», «ByResource», «ByDim», «ByDims», «ByDimension», «ByDimensions», «ByDimRecorder»). Остальные типы являются таблицами. Причем типы «VT» и «ExtDim» являются подчиненными таблицами (табличными частями), и для получения полных имен этих таблиц надо впереди еще добавить имя таблицы объекта владельца, например «_Document199_VT5172».

Дополнительно, в DBNames хранятся строки, относящиеся к некоторым системным таблицам

Уникальный идентификатор в таких строках пустой, т.е. эти таблицы не описаны в конфигурации. Имена таблиц при этом не содержат порядковый номер, т.е. имена соответствующих таблиц «_SYSTEMSETTINGS», «_USERSWORKHISTORY» и т.д.

Таким образом, все системные таблицы можно условно разделить на основные системные таблицы, их имена не начинаются с символа подчеркивания и они не описаны в DBNames, и дополнительные системные таблицы, имена которых начинаются с символа подчеркивания, и они описаны в DBNames. По этому признаку к основным таблицам можно отнести таблицы «IBVERSION» и «V8USERS». Но в реальности эти 2 таблицы не обязательны, и 1С вполне может запуститься без них.

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

Теперь добавим еще один справочник с одним реквизитом, обновим:

А теперь выгрузим конфигурацию, и загрузим ее в новую базу. После обновления в новой базе:

Как видим, номера одних и тех же объектов разные. Все из-за разного порядка обновлений.

Также следует заметить, что в записи DBNames содержатся только нумерованные объекты. Например, там нет полей, соответствующих стандартным реквизитам (Код, Наименование у справочников, Номер у документов и т.д.).

Полная структура всех таблиц данных содержится в единственной записи таблицы DBSCHEMA. Тут описаны все таблицы данных со всеми полями (в том числе, соответствующие стандартным реквизитам) с типами хранения, именно так, как это лежит в базе. Например, если у нас есть реквизит составного поля, то DBNames ему будет соответствовать одна строка, а вот в DBSCHEMA уже будут содержаться все поля, необходимые для хранения всего спектра значений этого реквизита. Но в DBSCHEMA нет привязки к объектам конфигурации.

Стоит еще немного остановиться на хранении реквизитов составного типа. 1С создает отдельное поле для каждого примитивного типа, входящего в составной тип, а также отдельное поле для ссылочных значений. Это общеизвестно, и описано, например, в статье Составные типы — бесплатный сыр мышеловки производительности. Я хочу обратить только внимание, что в поле вида ссылки (имена таких полей заканчиваются всегда на «TREF»), которое существует, если в составном типе возможны несколько видов ссылок, хранится порядковый номер объекта конфигурации, полученный им при реструктуризации. Тот самый номер, который записан в DBNames. И, кстати, этот же номер можно увидеть в представлении битой ссылки. Например, если мы видим « (20:94b81c6f65428d5911e2a8bebc48d793)», то мы сходу можем определить, что это ссылка на объект конфигурации, имеющий номер 20 в DBNames.

Итак, 1С для работы с информационной базой сначала загружает конфигурацию из таблицы CONFIG, затем определяет номера объектов по записи DBNames, после этого из записи в DBSchema получает окончательный состав полей всех таблиц, и только после этого 1С получает возможность работать с таблицами данных информационной базы.

Именно поэтому 1С очень чувствительна к ошибкам в CONFIG, DBNames и DBSchema.

Так что же делать?

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

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

Для того чтобы определить что же не так с базой, еще раз посоветую цикл статей Андрея Савкина (andrewks). В этом цикле достаточно хорошо описаны методы диагностики.  В дополнение к рассмотренным там методам могу посоветовать инструменты на странице «Дополнительно» программы Tool_1CD «Проверка состава таблиц», «Тест формата потока», «Найти дубли таблиц», так как вместе с этой статьей я выложил новую версию Tool_1CD в публикации Tool_1CD. Программа просмотра файлов баз *.1CD (1Сv8.x). Описание этих инструментов смотрите в следующем разделе.

Если вы разберетесь, что не так в базе, то поймете и как это исправить. Но вот с помощью чего это сделать? Вариантов много. Начиная от шестнадцатиричного редактора. Свои инструменты предлагают Андрей Савкин (andrewks) и Дмитрий Воробьев (vde69). Я тоже предлагаю свой инструмент - Tool_1CD.

В Tool_1CD появилась возможность редактирования таблиц. Правда, пока этот функционал находится в стадии альфа-версии, он еще не отлажен. Тем не менее, теперь вы можете попробовать воспользоваться некоторыми советами, которые ранее были применимы только для серверных баз. Например, в некоторых случаях после сбоев при обновлении конфигурации базы данных, может помочь удаление записей-маркеров в таблице CONFIG "commit", "dbStruFinal", "dynamicCommit".

Также, как я уже сказал, в новой версии Tool_1CD я сделал доступной страницу "Дополнительно", содержащую некоторые инструменты, которые могут пригодиться и для диагностики, и для восстановления баз.

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

Описание дополнительных инструментов Tool_1CD

Tool_1CD создавалась как исследовательская программа формата 1CD, без всякого плана, тех. задания и вообще без всякого представления, что в итоге получится. Дополнительные инструменты в Tool_1CD создавались хаотично, по мере возникновения потребности, поэтому не стоит искать в этом наборе инструментов стройность, законченность и т.д.

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

Все дополнительные инструменты располагаются на странице "Дополнительно":

Приведу краткое описание всех элементов управления, расположенных на этой странице.

Поле ввода «Директория импорта/экспорта таблиц»

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

Кнопка «Экспорт текущей таблицы»

По этой кнопке создается каталог с именем текущей таблицы в каталоге импорта/экспорта таблиц. В созданный каталог записываются все 4 файла текущей таблицы (DESCR, DATA, INDEX и BLOB), а также вспомогательный файл root.

Кнопка «Импорт текущей таблицы»

По этой кнопке в директории импорта/экспорта таблиц ищется каталог с именем текущей таблицы. Если каталог найден, у текущей таблицы перезаписываются файлы DATA, INDEX и BLOB файлами из найденного каталога. Файл DESCR при этом остается неизменным! Это позволяет, например, переносить данные из другой базы с такой же конфигурацией, но с другими именами таблиц (другой нумерацией объектов конфигурации). Для этого нужно будет только переименовать каталог с именем выгруженной таблицы, и присвоить ему имя таблицы, в которую мы импортировать данные. Если при этом порядок полей, количество и тип (но не имена!) будут не совпадать, таблица получится битая!

Кнопка «Экспорт таблиц данных»

Нажатие кнопки равносильно действию кнопки "Экспорт текущей таблицы" для всех таблиц базы, кроме системных.

Кнопка «Импорт таблиц данных»

Нажатие кнопки равносильно действию кнопки "Импорт текущей таблицы" для всех таблиц базы, кроме системных.

Кнопка «Импорт и создание таблиц»

При нажатии этой кнопки происходит просмотр всех каталогов в директории импорта/экспорта. Имена каталогов значения не имеют! В каждом каталоге ищется файл DESCR, содержащий описание таблицы. Из файла DESCR читается имя таблицы.

Если такая таблица существует, то в существующей таблице перезаписываются файлы DATA, INDEX и BLOB файлами из каталога, файл DESCR не изменяется!

Если же таблица с таким именем не существует, то создается новая таблица из файлов в каталоге.

Кнопка «Удаление текущей таблицы»

Удаляет текущую таблицу.

Кнопка «Удалить лишние таблицы»

Производит поиск и удаление таблиц, имена которых оканчиваются на "NG", "OG", а также таблицу "DBCHANGES". Все эти таблицы являются временными при реструктуризации базы, и могут остаться в базе, только если произошел сбой при реструктуризации. Внимание! Удалять таблицы, оканчивающиеся на "NG" или "OG" имеет смысл, если существует таблица с таким же именем, но без суффикса "NG" или "OG".

Кнопка «Найти дубли таблиц»

Производит поиск таблиц с одинаковыми именами. Найденные имена выводятся в окно сообщений.

Поле ввода и кнопка «Создание и импорт таблицы»

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

Если такая таблица уже существует в базе, то в существующей таблице перезаписываются файлы DATA, INDEX и BLOB файлами из каталога. Файл DESCR существующей таблицы не изменяется!

Если таблица с таким именем не существует, то создается новая таблица из файлов в каталоге.

Кнопка «Проверка всех индексов»

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

Кнопка «Найти потерянные объекты»

Объект - это внутренний файл, описанный в разделе "Структура базы данных 1CD". При нажатии кнопки «Найти потерянные объекты» происходит просмотр всех страниц файла базы данных и проверка начала каждой страницы на сигнатуру "1CDBOBV8", являющейся признаком начала заголовочной страницы файла. Если найдена сигнатура, делается проверка, принадлежит ли файл одной из таблиц и не является ли этот файл корневым. Если нет, то в окно сообщений выводится сообщение о найденном объекте с указанием адреса. Стоит отметить, что даже в исправных базах часто встречаются такие потерянные объекты, особенно после реструктуризации. Эти файлы были штатно удалены, и сам по себе факт наличия потерянного файла ни о чем не говорит. Но иногда, в редких случаях, эта информация может помочь найти действительно нужную утерянную информацию. Например, если испорчен файл описания таблицы, но сохранились другие файлы таблицы. См. также "Поиск и восстановление потерянных таблиц" и "Найти и сохранить потерянные объекты".

Кнопка «Тест формата потока»

Одна из самых частых ошибок, приводящих к невозможности запуска конфигуратора и/или предприятия - это ошибка формата потока. В терминологии 1С "поток" - это тектсовое представление двоичных объектов, получаемое в процессе сериализации. Это представление необходимо, чтобы сохранять программные объекты в базе, в файлах, для передачи по сети и т.д. Почти вся конфигурация, хранимая в базе или выгруженная в файл - это набор сериализованных объектов конфигурации. Хранилище значения хранит объекты в сериализованном виде. Методы 1С ЗначениеВСтрокуВнутр(), СохранитьЗначениеВФайл() и т.д. сериализуют объект. Все настройки пользователей хранятся как сериализованные данные. Сериализованные потоки используются 1С повсеместно. Если в любом из перечисленных мной мест, или в еще куче не перечисленных текстовое представление портится, возникает "ошибка формата потока". Из-за того, что сериализованные потоки 1С использует буквально везде, такая ошибка возникает очень часто, и при этом 1С даже приблизительно не намекает в каком же месте возникла эта ошибка. Сообщение "Ошибка формата потока" претендует на звание самого бесполезного сообщения об ошибке в мире!

Инструмент "Тест формата потока" пытается проверить формат потока в записях основных системных таблицах: CONFIG, CONFIGSAVE, FILES, PARAMS и DBSCHEMA. Ошибки формата потока именно в этих таблицах могут приводить к невозможности запуска конфигуратора и предприятия. Однако следует понимать, что такая проверка не совсем корректна. Для полностью корректной проверки необходимо разобрать и описать структуру конфигурации и других записей системных таблиц, но это очень кропотливая работа и на данный момент в открытом доступе такого описания нет.

Данный инструмент делает некоторые проверки формата (например, соответствие открывающих "{" и закрывающих "}" скобок), но не все. В некоторых случаях возможны ложные сообщения об ошибках. И наоборот, реальная ошибка может быть не обнаружена. Этот инструмент следует использовать как вспомогательный и вручную перепроверять сообщения об ошибке. Тем не менее, данный инструмент часто позволяет обнаружить реальные проблемы в системных таблицах.

Кнопка «Создать пустой объект в базе»

Создает новый файл (объект) в базе. Длина нового файла равна 0. Файл никому не принадлежит. Иногда это бывает нужно при ручном восстановлении структуры БД. Этот инструмент можно считать устаревшим.

Кнопка «Создать объект из файла»

Создает новый файл (объект) в базе. Содержимое файла копируется из указанного внешнего файла. Файл никому не принадлежит. Иногда это бывает нужно при ручном восстановлении структуры БД. Этот инструмент можно считать устаревшим.

Кнопка «Проверка состава таблиц»

Проверяется существование в базе каждой таблицы данных (но не системных таблиц!), описанной в записи DBNames таблицы PARAMS. Записи про системные таблицы (с идентификатором 00000000-0000-0000-0000-000000000000) пропускаются, так как часто такие таблицы в базе отсутствуют, но это не является ошибкой. Подробнее про DBNames смотри выше в разделе "Структура информационной базы 1С".

Кнопка «Поиск и восстановление потерянных таблиц»

Производится поиск всех таблиц, которые есть в базе, но которые не содержатся в корневом файле. Работает также как и инструмент "Найти потерянные объекты", но при нахождении потерянного файла (объекта) дополнительно проверяется, не является найденный файл файлом описания таблицы (DESCR). Если да, то таблица добавляется в корневой файл.

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

После описанной в разделе "Стандартные средства восстановления" искусственной порчи базы, до применения chdbfl.exe, данным инструментом можно было бы восстановить таблицы обратно.

Кнопка «Найти и сохранить потерянные объекты»