От chdbfl до технологического журнала: диагностика базы 1С

Проверку базы делят на два уровня. Физическую целостность файловой базы (1Cv8.1CD) проверяет утилита chdbfl.exe из каталога платформы. Логические ошибки — битые ссылки, неверные итоги, рассыпавшиеся индексы — ищет Конфигуратор, пункт Администрирование → Тестирование и исправление.

Для серверной (клиент-серверной) базы chdbfl.exe не применяется — там за физическую целостность отвечает СУБД, а логику так же проверяет тестирование из Конфигуратора. Ниже — семь приёмов: от штатного тестирования до технологического журнала, с точными путями и порядком действий.

Тестирование и исправление через Конфигуратор

Главный штатный инструмент. Запустите базу в режиме Конфигуратора, затем откройте Администрирование → Тестирование и исправление информационной базы.

В окне доступны проверки, их можно комбинировать:

• 🔧 Реиндексация таблиц — пересобирает индексы, самая безопасная операция.
• 🔗 Проверка логической целостности — ищет нарушения в структуре данных.
• 🔎 Проверка ссылочной целостности — находит «битые» ссылки на удалённые объекты.
• 🧮 Пересчёт итогов — выравнивает регистры накопления и бухгалтерии.
• 📦 Сжатие таблиц — убирает пустое место после удалений (файловый режим).
• 🏗 Реструктуризация таблиц — перестраивает физическую структуру.

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

Для проверки ссылочной целостности задаётся реакция на найденную ошибку: создавать объекты по ссылкам, очищать ссылки или не изменять. На боевой базе безопаснее сначала посмотреть, что программа предлагает изменить.

Чем отличаются проверки по тяжести:

• Реиндексация и проверка целостности данные не портят, их можно гонять относительно спокойно.
• Пересчёт итогов переписывает рассчитанные остатки регистров — после него сверьте отчёты.
• Реструктуризация перестраивает физические таблицы под текущую структуру метаданных. Это самая долгая и ресурсоёмкая операция: на крупной базе она идёт часами и требует свободного места на диске под временные таблицы. Запускайте её отдельно, не вперемешку с остальными флагами.

Монопольный доступ нужен именно для режима с исправлением, реструктуризации и пересчёта итогов. Если база занята, Конфигуратор сообщит, какие сеансы её держат. Для серверной базы завершить зависшие сеансы можно из консоли администрирования кластера.

Проверка файловой базы утилитой chdbfl.exe

chdbfl.exe проверяет и чинит физическую структуру файла 1Cv8.1CD. Это нижний уровень — то, с чем Конфигуратор уже не справится, если повреждён сам файл.

Где взять утилиту: каталог установки платформы, подпапка bin. Типичный путь — C:\Program Files\1cv8\<номер версии>\bin\chdbfl.exe.

Порядок работы:

1. Закройте все сеансы с базой — и Предприятие, и Конфигуратор. Файл должен быть свободен.
2. Сделайте копию файла 1Cv8.1CD вручную (обычное копирование в проводнике).
3. Запустите chdbfl.exe.
4. Укажите путь к файлу 1Cv8.1CD проверяемой базы.
5. Первый прогон — без галочки «Исправлять обнаруженные ошибки». Посмотрите отчёт.
6. Если ошибки есть — повторите с установленной галочкой.

Утилита восстанавливает структуру, но при тяжёлых повреждениях может удалить сбойные таблицы. Поэтому резервная копия файла перед запуском обязательна: если chdbfl.exe сделает хуже, вы вернётесь к исходнику.

Частая причина обращения к chdbfl.exe — аварийное выключение компьютера или обрыв сети во время записи в файловую базу на сетевой шаре. Если после проверки база открылась, но часть документов пропала, не считайте это «починкой»: утилита убрала повреждённые страницы вместе с данными. Сверьте остатки с последней копией и при расхождении восстанавливайтесь из неё.

Что искать в журнале регистрации

Журнал регистрации — это история событий базы: кто вошёл, что провёл, где платформа споткнулась. Нештатные закрытия, ошибки блокировок и исключения оседают именно здесь.

Открыть можно двумя путями:

• в Конфигураторе — Администрирование → Журнал регистрации;
• в режиме Предприятия пользователь с правами администратора открывает журнал из раздела администрирования.

Что настроить сразу — отбор по важности события. Поставьте фильтр на уровень «Ошибка», чтобы не тонуть в рутине входов-выходов. Дополнительно отбирайте по дате (сузьте до окна сбоя) и по пользователю.

На что смотреть в тексте события:

• 📄 текст исключения — часто прямо называет документ и реквизит;
• 🔐 сообщения о конфликте блокировок — признак проблем с производительностью под нагрузкой;
• 🚪 аварийные завершения сеанса — повод проверить сеть и стабильность сервера.

В современной платформе журнал хранится в файле 1Cv8.lgd (формат SQLite) в каталоге базы. Если журнал разросся до гигабайтов, его можно проредить через настройку Администрирование → Настройка журнала регистрации — там задаётся период хранения и минимальная важность записываемых событий.

Журнал отвечает на вопрос «что именно произошло перед сбоем». Если Предприятие закрылось с ошибкой, а воспроизвести её не удаётся, первым делом открывают журнал за минуту до падения: там обычно виден и пользователь, и операция, и текст исключения. Это быстрее, чем гадать по жалобам.

Оценка производительности базы

Если база «не сломана, но тормозит», ищут не ошибки, а узкие места. Проверка производительности — отдельная задача.

Базовые шаги:

1. Замер по APDEX. В типовых конфигурациях есть подсистема оценки производительности: Администрирование → Оценка производительности (включается флагом). Она копит время ключевых операций и считает индекс APDEX — от 0 до 1, где ближе к 1 лучше. Ориентиры по индексу привычны любому администратору: около 0,9 и выше — отлично, 0,7–0,85 — приемлемо, ниже 0,5 — пользователи уже жалуются. Смотрите не средний балл по базе, а конкретные тяжёлые операции: именно они тянут оценку вниз.
2. Журнал регистрации под нагрузкой. Всплеск конфликтов блокировок в часы пик указывает на избыточные блокировки или тяжёлые проведения. Полезно сопоставить время конфликта из журнала с тем, какой документ в этот момент проводился — так находят «тяжёлый» объект.
3. Размер базы и регистров. Разросшиеся регистры сведений и накопления замедляют проведение. Пересчёт итогов и свёртка старых периодов помогают. Отдельно проверьте, не накопились ли помеченные на удаление объекты — их удаление через Администрирование → Удаление помеченных объектов разгружает базу.

Для файловой базы отдельный фактор — сеть и диск: файловая база на сетевой шаре по медленному каналу будет тормозить независимо от «чистоты» данных. Серверный вариант диагностируют глубже технологическим журналом и центром управления производительностью (см. ниже).

Восстановление из резервной копии

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

Файловая база. В Конфигураторе — Администрирование → Загрузить информационную базу, укажите файл .dt. Операция полностью затирает текущую базу содержимым копии, поэтому доступ — монопольный. Парный пункт Выгрузить информационную базу создаёт такой .dt заранее.

Серверная база. Восстановление идёт средствами СУБД из её бэкапа (например, из .bak в MS SQL Server), а не загрузкой .dt. Выгрузка в .dt для серверной базы тоже возможна, но как разовый снимок, а не штатная резервная копия продуктивной системы.

Отдельно стоит проверять сами копии. Резервная копия, которую ни разу не разворачивали, — это предположение, а не гарантия. Раз в период разверните свежий .dt или бэкап в тестовую базу и убедитесь, что она открывается и данные на месте. Так вы узнаете о непригодной копии заранее, а не в момент аварии.

Проверка на вирусы и повреждение файлов

База 1С — обычные файлы на диске, и шифровальщики их не щадят. Признаки заражения: файлы 1Cv8.1CD или резервные .dt переименованы, получили чужое расширение или не открываются.

Что сделать:

• 🛡 Проверьте каталог базы и каталог резервных копий антивирусом с актуальными базами.
• 🧱 Исключите каталог рабочей базы и временные файлы 1С из постоянного сканирования «на лету» — агрессивный антивирус иногда блокирует файлы базы и имитирует повреждение.
• 💾 Храните резервные копии на отдельном носителе или в сетевом хранилище, а не рядом с базой: шифровальщик достаёт всё, до чего дотянется из одной папки.

Если файл базы повреждён не вирусом, а сбоем диска или аварийным выключением, вернитесь к разделам про chdbfl.exe (файловый режим) и восстановление из копии.

Инструменты для глубокой диагностики

Когда штатного тестирования мало, подключают профессиональные средства. Они нужны в основном на серверных базах под нагрузкой, где проблема не в одной «битой» ссылке, а в поведении системы в целом: долгие запросы, блокировки, очереди к СУБД.

• Технологический журнал. Настраивается файлом logcfg.xml в каталоге conf платформы. Пишет детальную трассировку событий: долгие запросы, исключения, таймауты блокировок, обращения к СУБД. Тяжёлый инструмент — включайте точечно, по нужным событиям и на короткое время, иначе он быстро забьёт диск логами на десятки гигабайт. После разбора не забудьте вернуть пустой logcfg.xml.
• Центр управления производительностью (ЦУП) из состава КИП (Корпоративный инструментальный пакет) — собирает замеры, строит отчёты по APDEX и показывает самые дорогие операции.
• Консоль кластера и rac. Для серверной базы состояние сеансов и соединений смотрят через консоль администрирования или утилиту rac. Безопасные команды — rac cluster list, rac session list. Параметры, в которых не уверены, уточняйте по rac help.
• Средства СУБД. Для MS SQL — проверка целостности DBCC CHECKDB, анализ фрагментации индексов и актуальности статистики. Часть «тормозов 1С» лечится именно на уровне СУБД.

Частые вопросы