Ситуация с повреждением базы данных 1С 7.7 после аппаратного сбоя диска является одной из самых сложных в практике системного администратора. Часто стандартные средства, такие как Тестирование и исправление или удаление индексных файлов *.cdx, не приносят желаемого результата. Рассмотрим подробно причины возникновения «пустоты» в журналах, причины зависания пересчета итогов и методику восстановления данных при их «исчезновении» во время миграции на SQL-сервер.
Проанализируем ситуацию, когда база данных после восстановления файлов с упавшего диска вроде бы открывается, но ведет себя непредсказуемо. Если при просмотре журнала документов за большой период в начале списка отображается «пустая область», а попытка пересчета итогов в Конфигураторе приводит к бесконечному зависанию, это явный признак физического разрушения структуры файлов .dbf.
Разберем, почему это происходит. В 1С 7.7 за хранение основной информации о документах отвечает файл 1SJOURN.DBF. В нем содержатся даты, номера, типы документов и ссылки на конкретные таблицы заголовков. «Пустота» в журнале часто означает наличие записей с некорректными датами (например, 00.00.0000 или даты из «будущего» тысячелетия). Программа пытается отсортировать эти записи, но из-за нарушения структуры заголовка DBF-файла или мусора в полях ссылок алгоритм отображения дает сбой.
Зависание на этапе Пересчета регистров объясняется тем, что система пытается последовательно обработать каждую запись в хронологическом порядке. Натыкаясь на «битую» дату или нарушенную цепочку ссылок, механизм расчета итогов входит в бесконечный цикл или ожидает ответа от поврежденного сектора данных, который система не может корректно интерпретировать.
Рассмотрим крайне интересный симптом: в DBF-версии документы (например, Реализация) видны в списках, но после выполнения штатной процедуры Выгрузка данных (создание файла .dat) и последующей Загрузки данных в SQL-базу, эти документы полностью отсутствуют. Выясним причину этого явления.
Процесс выгрузки в файл 1СV77.DAT работает по следующему алгоритму:
Если заголовок файла DH* (заголовки документов) или DT* (табличные части) содержит информацию о 1000 записей, а фактически из-за сбоя данные обрываются на 500-й, штатный механизм выгрузки может просто проигнорировать «хвост» или вовсе пропустить таблицу, если встретит критическую ошибку структуры. Более того, SQL-сервер гораздо строже относится к типам данных. Если в поле даты в DBF-файле записан «мусор», SQL-сервер отвергнет такую запись при импорте, и в результирующей таблице документа будет пусто.
Проанализируем связь таблиц. Документ в 1С 7.7 состоит минимум из трех составляющих:
1SJOURN.DBF (общие сведения).DHxxxx.DBF (шапка конкретного документа).DTxxxx.DBF (строки документа).
Если связь между 1SJOURN и DH разорвана (например, в журнале ссылка есть, а в таблице DH соответствующий ID отсутствует или поврежден), при выгрузке 1С посчитает такой документ несуществующим.
Посмотрим, какие действия необходимо предпринять для реанимации базы данных, когда стандартные методы бессильны.
Прежде всего, нам необходимо убедиться в целостности заголовков таблиц. Для этого следует использовать специализированные утилиты для ремонта DBF-файлов (например, DBF Recovery или аналогичные редакторы). Важно проверить, чтобы количество записей в заголовке (Header) соответствовало фактическому размеру файла.
Рассмотрим ситуацию вручную. Если база небольшая, можно попробовать открыть файл 1SJOURN.DBF с помощью программ типа FoxPro или любого продвинутого DBF-вьюера. Проанализируем колонку DATE. Если мы находим значения, выходящие за разумные пределы, их нужно исправить вручную или пометить такие записи на удаление. Помним, что 1С 7.7 критично относится к целостности индексов, поэтому после любых ручных правок в DBF файлы .cdx должны быть удалены.
В нашем случае пользователь заметил, что в файле 1СV77.DAT отсутствуют данные по реализации. Это подтверждает, что проблема локализована в файлах DH и DT, относящихся к реализации. Нам нужно найти их идентификаторы. Посмотрим в файл 1CV7.DD (или .DDS для SQL), чтобы узнать, какие именно файлы соответствуют документу Реализация. Например, если реализации соответствует DH254 и DT254, именно эти файлы нужно подвергнуть самому тщательному лечению.
Если повреждения структуры настолько велики, что штатная выгрузка работает некорректно, проанализируем альтернативный метод — перенос данных через внешние обработки.
Этот метод хорош тем, что при программном чтении объекта Документ, если он совсем «битый», система просто выдаст ошибку на конкретном объекте, но позволит прочитать все остальные, в отличие от штатной выгрузки, которая может «потерять» всю таблицу целиком.
Если нам удалось восстановить заголовки и данные появились в интерфейсе, но итоги все еще не считаются, воспользуемся советом опытных специалистов: Сервис -> Обработка документов -> Провести. Разберем правильную последовательность:
Это позволит системе заново сформировать записи в таблицах движений регистров (файлы RG* и RA*), которые могли быть повреждены.
При работе с 1SJOURN обратите внимание на поле CLOSED. Оно отвечает за состояние проведения документа. В битой базе может возникнуть ситуация, когда документ числится проведенным в журнале, но его движений в регистрах нет. В таком случае поможет только перепроведение. Также проверьте поле ISMARK — если там содержатся символы, отличные от «пусто» или «*», 1С может вести себя неадекватно при попытке формирования любого отчета или пересчета итогов.
Важное предостережение: Перед любыми манипуляциями с таблицами напрямую через DBF-редакторы обязательно делайте резервную копию того, что удалось восстановить с диска. Любая ошибка в структуре заголовка при ручном редактировании может окончательно «добить» базу.
Выяснив причины «исчезновения» данных и зависания системы, мы понимаем, что ключ к решению лежит в плоскости восстановления физической целостности отдельных таблиц и связей между ними. Только после того, как все DBF-файлы будут приведены в соответствие со стандартами формата и логикой 1С 7.7, можно приступать к миграции на SQL или полноценной работе в файловом режиме.