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

Восстановление работоспособности разрушенной файловой базы. Этап 1. Обследование, определение проблемных мест.

Продолжение. Предыдущие этапы:

0. Введение


Этап 1. Обследование, определение проблемных мест.

Итак, перед нами «мёртвая» файловая база. Задача, которая стоит перед нами на текущий момент — всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго «ныряют» в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: «База не подлежит ремонту». Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.

1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой «Исправлять обнаруженные ошибки».

Утилита chdbfl.exe

Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто «выкидываем». Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, «Поврежден заголовок файла базы данных» чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). «Повреждено содержимое внутреннего файла » означает, что в корневом объекте существуют «битые записи», с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.

2. Технологический журнал (ТЖ) 1С:Предприятие. Прекрасная возможность узнать, на каком месте «спотыкается» платформа, если она «зависает», «падает», или выдаёт загадочное сообщение «Ошибка формата потока» (причём сама ошибка может быть где угодно, в любом из файлов системных таблиц). Закрываем все сеансы 1С, чтобы они нам не мешались, и настраиваем запись ТЖ. Для этого идём в папку «bin», где лежат исполняемые файлы текущей плафтормы «1cv8*.exe», находим там вложенную папку «conf», и создаём там файл настройки записи ТЖ «logcfg.xml» примерно следующего содержания (исходный текст файла настройки есть в прикреплённом архиве):

Пример файла настройки ТЖ
Вместо «C:1cv8logs» можно указать любую существующую папку, куда будут писаться логи, но лучше создать новую, пустую, чтобы не было проблем с записью логов.
(Подробнее про настройку ТЖ можно почитать, например, здесь: http://help1c.com/faq/view/464.html )
Далее, запускаем нашу проблемную базу в режиме конфигуратора, дожидаемся вывода окошка с ошибкой, или краха приложения, и сразу же идём изучать содержимое записанного лога (он будет в файле «1cv8_PIDМеткаДаты.log»). На следующие события и ошибки не обращаем внимания (их наличие является нормальным):
Exception=NetDataExchangeException,Descr=’server_addr=any:port_num descr=Ошибка сетевого доступа к серверу…
Exception=DatabaseException8,Descr=»Отсутствует файл базы данных ‘ПутьКБазе/1Cv8tmp.1CD'»
Файл не обнаружен ‘SprScndInfo’
и некоторые другие.
Собственно, мы даже можем не увидеть там нужного нам сообщения об ошибке, но зато мы увидим, при работе с каким объектом (таблицей или внутренным файлом таблицы) происходит ошибка.

Пример файла ТЖ

1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS — таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA — схема (структура) БД
_USERSWORKHISTORY — история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS — хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS — содержит файлы с параметрами БД
FILES — содержит прочие системные (служебные) файлы
CONFIG — содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE — содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME — имя файла
CREATION/MODIFIED — дата создания/изменения
ATTRIBUTES — атрибуты
DATASIZE — размер файла
BINARYDATA — содержимое файла (двоичные данные)

В случае полного отсутствия какой-либо системной таблицы (не путать с наличием пустой таблицы) 1С при старте базы выдаст сообщение «База данных полностью разрушена».

Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла «ibparams.inf» из таблицы PARAMS.

Итак, анализируем файл лога. Например, если происходит «Ошибка формата потока», а в конце файла лога мы видим примерно следующее:
41:29.3460-1,DBV8DBEng,2,process=1cv8,Usr=Админ,Trans=0,Func=restoreObject,tableName=DBChanges
41:29.3900-439,DBV8DBEng,2,process=1cv8,Usr=Админ,Trans=0,Func=restoreObject,tableName=DBSchema
41:29.3901-443,SDBL,1,process=1cv8,Usr=Админ,Trans=0,Sdbl=GET NGENERATIONS
41:29.4060-19207,SESN,1,process=1cv8,Func=Attach,IB=ПутьКБазе,Nmb=2,ID=GUID
41:29.4061-19210,SESN,1,process=1cv8,Func=Finish,IB=ПутьКБазе,Nmb=2,ID=GUID
то можно заключить, что ошибка формата потока возникла при работе с содержимым таблицы «DBSchema», следовательно, содержимое этой таблицы нужно будет изучить поподробнее.
Ещё, если в наличии есть какой-нибудь старый бэкап, можно применить такой приём: записать ТЖ при его старте, и сравнить его с ТЖ при старте проблемной базы, чтобы понять, какими сообщениями об исключениях можно пренебречь, а также, какие этапы при старте проблемной базы проходят нормально, а до каких дело не доходит.
По окончании данной процедуры файл «logcfg.xml» можно переименовать, чтобы не засорять ненужными логами диск.

3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).

Просмотр содержимого таблиц в Tool_1CD
При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями «OG» — их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями «.new» — их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.

4. Открываем базу при помощи компоненты 1CDLib. Информация из п. 3 в полной мере относится и к этому пункту, меняется только методика работы с файлом базы — посредством скриптов, использующих функции компоненты, с последующим анализом лог-файла и извлечённых данных.
Вашему вниманию представлены два скрипта (являющихся внешними обработками для режима управляемого приложения 1С:Предприятие 8.2, их можно запустить, например, из созданной пустой базы), с помощью которых можно произвести полуавтоматическое обследование проблемной базы:
Обработка «SaveAllTables.epf» позволяет сохранить данные всех таблиц в виде структуры вложенных папок и файлов в папке «Objects» (создаётся там же, где находится файл базы), и далее их можно изучать при помощи обычного файлового менеджера. Также, после сохранения всех таблиц, полезно изучить содержимое лога «logdb1cd.log» — туда выводятся сообщения об ошибках, которые произошли при извлечении таблиц. Если сообщения об ошибках в нём отсутствуют, то можно сказать, что физических ошибок в структуре хранения таблиц в файле базы нет, и проблемы уже либо в отсутствии каких-то таблиц, либо в их некорректном содержимом.
Обработка «ViewRecords.epf» позволяет просматривать записи таблиц и сохранять в файлы BLOB-данные (файлы создаются в папках с именами соответствующих таблиц), предназначена, в первую очередь, для полуавтоматического анализа содержимого системных таблиц (хотя с помощью неё можно просмотреть и другие таблицы). В случае ошибок при извлечении BLOB-данных, или при их распаковке (если содержимым BLOB-поля являются запакованные по алгоритму Deflate данные), выводятся соответствующие сообщения.

Просмотр содержимого таблиц в ViewRecords.epf

 

5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался — закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.

Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:

Система restoration-base-1c8 - основное окно

а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:

Система restoration-base-1c8 - редактирование содержимого блока

Просмотр записей таблиц, к сожалению, не реализован.


 

На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе «лечения». Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.

28 Comments

  1. ula1c

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

    Reply
  2. support

    Ба! Андрюша, ты ли это?

    Reply
  3. andrewks

    (2) support, имя моё. а кто имеется в виду? 🙂

    Reply
  4. ivan_83

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

    Reply
  5. andrewks

    (4) ivan_83, с таким сообщением об ошибке ещё не сталкивался, но, скорее всего, проблема типовая, раз при обновлении, просто сообщений у 1с много разных. Вы обследуйте проблемную базу по приведённой методике, расскажите, какие ошибки выявили, постараюсь что-нибудь посоветовать

    Reply
  6. ivan_83

    (5) проблема типовая и известная. Для SQL-ных баз решается просто — в таблице PARAMS достаточно удалить записи *.si, которые создаются заново при открытии базы. В файловой базе удалить записи из таблицы сложнее (особенно без достаточных знаний и навыка работы с HEX-редактором). База не открывалась ни в режиме предприятия ни в конфигураторе, был лишь файл базы 1Cv8.1CD. Обновлял не я и, как выяснилось, копии до обновления не было (как и копии базы в принципе).

    Reply
  7. andrewks

    (6) ivan_83,

    В файловой базе удалить записи из таблицы сложнее (особенно без достаточных знаний и навыка работы с HEX-редактором)

    см. http://infostart.ru/public/166557/

    Reply
  8. ivan_83

    (7) пробовал использовать эту обработку. Она может удалить таблицу целиком, но не конкретные записи из неё.

    Reply
  9. andrewks

    (8) ivan_83, она может удалять и конкретные записи. может, Вы качали давно, старую версию? посмотрите историю версий на странице публикации, и файл с описанием методов, там всё подробно расписано

    Reply
  10. MRAK

    Спасибо, хорошая работа!

    Reply
  11. ivan_83

    (9) действительно у меня была старая версия, что не позволяло делать отбор по FILENAME. Теперь работает.

    Reply
  12. awa

    Отличная статья!

    Позволю себе прокомментировать замеченные неточности:

    CONFIG — содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида ., хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что конфигурация полностью совпадает с типовой) .

    Здесь, видимо имелось ввиду «в файлах с названиями вида <GUID>.<GUID>».

    Отсутствие же таких файлов говорит либо об отсутствии конфигурации поставщика вообще (самописная конфигурация или типовая конфигурация со снятой поддержкой), либо, что в типовой конфигурации не включен режим изменения.

    CONFIGSAVE — содержит файлы основой конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что конфигурация полностью на поддержке.

    На самом деле, отсутствие записей в CONFIGSAVE означает, что основная конфигурация и конфигурация БД совпадают. Если же, конфигурация полностью на поддержке, то в момент загрузки обновлений в CONFIGSAVE все равно могут быть записи, и в данном случае это означает, что версии основной конфигурации и конфигурации БД различаются.

    Reply
  13. andrewks

    (12) awa,

    Здесь, видимо имелось ввиду «в файлах с названиями вида <GUID>.<GUID>».

    да, так и писал, но у местного редактора проблемы с угловыми скобками — он их жрёт как тэги, причём, даже если они встречаются в блоке с кодом.

    спасибо за поправки, учту их при обновлении статьи.

    Reply
  14. andrewks

    (12) awa, ещё раз перечитал свои

    CONFIGSAVE — содержит файлы основой конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что конфигурация полностью на поддержке.

    это писал не я! я не мог такого написать! )))

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

    Reply
  15. flash2k

    Хорошая статья.

    Сохранил, пригодится.

    Reply
  16. margo2007

    Клиент 1 час назад позвонил:

    «Ошибка записи в таблицу x100x» и 1С перезапускается.

    Это, видимо, тот самый случай, когда можно использовать Ваши наработки?

    Reply
  17. andrewks

    (16) margo2007, очень может быть. а может, и нет. для этого и было написано Введение

    Reply
  18. kenza

    (4) ivan_83, Тоже недавно столкнулся с такой проблемой. Ошибка возникла при сохранении конфигурации после редактирования. В саму базу войти не мог, благо в конфигуратор войти получилось. Восстановление базы тоже завершалось ошибкой, решил проблему только восстановлением старой конфигурации (до редактирования). А вообще проблема видимо типичная для 8.2.

    Reply
  19. zels

    Столкнулся с интересной битой базой (релиз платформы 8.2.18.82, БП2.0 типовая), при обновлении был сбой питания.

    1. При попытке перейти в конец журнала банковских выписок программа виснет намертво.

    2. Тестирование в конфигураторе сообщает, что файл поврежден.

    3. При тестирование утилитой chdbfl.exe тоже виснет (одно ядро процессора загружается 100%)

    При этом каталог с логами пуст (хотя создал logcfg, как здесь написано)

    Открыл файл утилитой Tools_1CD (0.2.3), на «тест формата потока» тоже виснет.

    При нажатии «Найти конфигурацию поставщика» вылетает по ошибке «Write of addess 0000000»

    (а версия 0.2.1 сообщает, что конфигурации поставщика не найдены).

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

    Reply
  20. andrewks

    (19) zels, написал в личку

    Reply
  21. margo2007

    (19)Буквально на днях АБСОЛЮТНО так-же было.

    В «Тестирование и исправление» сначала только реструктуризацию запустила, а потом все остальное уже пошло… Вылечилось.

    Reply
  22. zels

    (21) margo2007, при реструктруризации выскакивает сообщение, что файл поврежден и все заканчивается.

    Reply
  23. zels

    Огромное спасибо andrewks: оказалось, что с галочкой «исправлять ошибки» программа chdbfl заканчивает работу (и что-то там исправляет), а без галочки тупо зацикливается…

    Reply
  24. Светлый ум

    Отсутствует таблица dbschema, какими средствами её можно скомпилировать?

    Reply
  25. Serge_ASB

    Добрый день.

    Скажите, почему не подключается компонента в версии (0.2.3)?

    Под WIndows 10 (x64) и иногда под Windows 7 (32 — начальная).

    При повторном открытии не доремонтированной базы и попытке обновления данных долго-долго удаляет старые данные… на этом и виснет.

    P.S. 1C 8.3.4.465, 8.2.19.68

    Reply
  26. zels

    (24) Константин, удалось восстновить DBSCHEMA? Если «да», то каким образом?

    Reply
  27. Светлый ум

    Павел Фомин

    https://infostart.ru/profile/442433/

    собрал мне из базы то что осталось — но кроме справочников ничего не выжило… у меня «Тулзом_СД» не получилось, хоть и с подменой таблиц из донора разобрался.

    — Павел был не против сотрудничать за почасовую оплату, напишите ему… думаю возьмется

    Reply
  28. protexprotex

    Хорошая статья. Еще бы был бы рассмотрен вопрос про крах базы при динамическом обновлении.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *