Диагностика информационной базы 1С 8.3: физика, ссылки, итоги и журнал

Проверить базу данных 1С на ошибки можно двумя инструментами: утилитой chdbfl.exe (физическая целостность файла базы) и режимом Администрирование → Тестирование и исправление в Конфигураторе (логика, ссылки, итоги, индексы). Оба требуют, чтобы в базе не было пользователей, и оба запускают только после резервной копии.

Типичная ситуация: в понедельник отчёт по 60-му счёту не бьётся с оборотно-сальдовой ведомостью, в документах вместо контрагента висит <Объект не найден> (123:a1b2...), а утром база упала с Ошибка формата потока. Это разные поломки, и проверять их нужно в правильном порядке: сначала «железо» файла, потом логика данных, потом учётные итоги.

Подготовка базы к проверке и тестированию

Проверка с исправлением меняет данные необратимо. Если программа решит «удалить объекты» с битыми данными, вернуть их можно только из копии.

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

Порядок подготовки:

1. Договоритесь о времени. Все пользователи должны выйти: тестированию и исправлению нужен монопольный доступ. Для базы на 10–20 ГБ закладывайте от часа до нескольких часов.
2. Отключите регламентные задания и обмены, которые могут подключиться к базе в процессе (синхронизация с сайтом, обмен с УТ, загрузка банка).
3. Сделайте копию:
   • 📁 файловая база — скопируйте каталог базы целиком, главное — файл 1Cv8.1CD;
   • 🗄 клиент-серверная — полный бэкап средствами СУБД (MS SQL или PostgreSQL);
   • 📦 дополнительно — выгрузка в .dt через Администрирование → Выгрузить информационную базу в Конфигураторе.
4. Проверьте свободное место. Реиндексация и сжатие создают временные файлы; держите на диске хотя бы двойной объём базы.
5. Запишите версию платформы и путь к базе: они понадобятся для пакетного запуска и для отчёта, если придётся звать специалиста.

Шаг 1. Физическая проверка файловой базы утилитой chdbfl

Для файловой базы начинайте с chdbfl.exe. Она проверяет структуру самого файла 1Cv8.1CD: страницы, заголовки таблиц, индексы. Если файл повреждён физически, логическое тестирование в Конфигураторе может просто упасть.

Где лежит утилита:

C:\Program Files\1cv8\8.3.2x.xxxx\bin\chdbfl.exe

Номер каталога — ваша версия платформы.

Как запустить:

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

Что означает результат:

Шаг 2. Режим «Тестирование и исправление» в Конфигураторе

Это главный инструмент проверки базы данных 1С на логические ошибки. Он одинаково работает для файловых и серверных баз.

Запуск:

1. Откройте базу в режиме Конфигуратор.
2. Выберите Администрирование → Тестирование и исправление....
3. Отметьте проверки и режим, нажмите «Выполнить».

Что отмечать

Режим: только тестирование или с исправлением

• 🔍 «Тестирование» — программа находит и выводит проблемы в окно сообщений, ничего не меняя.
• 🛠 «Тестирование и исправление» — находит и сразу исправляет по выбранным правилам.

Разумная практика — сначала прогнать в режиме «Тестирование», посмотреть список, а потом запустить исправление уже на копии или после свежего бэкапа.

Пакетный запуск без интерфейса

Для ночной проверки или большой базы удобнее командная строка:

"C:\Program Files\1cv8\8.3.2x.xxxx\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /IBCheckAndRepair -ReIndex -LogAndRefsIntegrity -RecalcTotals -TestOnly /Out"D:\Logs\check.txt"

Ключи:

• /F — путь к файловой базе; для серверной — /S"сервер\имя_базы";
• -TestOnly — только тестирование; уберите его, чтобы включить исправление;
• -LogAndRefsIntegrity — логическая и ссылочная целостность вместе (-LogIntegrity — только логическая);
• -BadRefCreate, -BadRefClear, -BadRefNone — что делать с битыми ссылками;
• -BadDataCreate, -BadDataDelete — что делать с частично потерянными объектами;
• /Out — файл, куда пишется результат.

Если сомневаетесь в каком-то ключе для своей версии платформы, сверьтесь со справкой по параметрам командной строки 1cv8.exe, она есть в документации к платформе.

Шаг 3. Ссылочная целостность: битые ссылки и «Объект не найден»

Ссылочная целостность нарушена, когда документ или справочник ссылается на элемент, которого в базе уже нет. Внешне это выглядит как <Объект не найден> (85:b3c1...) в поле контрагента, номенклатуры или договора.

Откуда берутся битые ссылки:

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

При включённой проверке ссылочной целостности Конфигуратор спрашивает, что делать в двух ситуациях.

Ссылки на несуществующие объекты:

Частичная потеря данных объектов: «Создавать объекты», «Удалять объекты» или «Не изменять».

Найти созданные заглушки просто: они появляются в справочниках с наименованием вида «Объект не найден» и номером. Отфильтруйте список по этому слову и разберите каждую.

Шаг 4. Пересчёт итогов и регистров

Если оборотно-сальдовая ведомость не совпадает с карточкой счёта, а остатки на складе в отчёте расходятся с документами, вероятная причина — испорченные итоги регистров. Регистры хранят движения и отдельно — посчитанные итоги, и вторые иногда «отстают».

Варианты пересчёта:

1. В Конфигураторе — флажок «Пересчёт итогов» в окне тестирования. Пересчитываются все регистры, нужен монопольный доступ.
2. В режиме предприятия — в типовых конфигурациях на БСП: Администрирование → Обслуживание, обработка «Управление итогами и агрегатами». Там можно пересчитать итоги и установить период , по который они рассчитаны.

Пересчёт итогов чинит хранение, но не учёт. Если сам документ проведён неверно, итоги посчитаются правильно по неправильным движениям. Для бухгалтерских ошибок в БП 3.0 есть отдельный инструмент: Отчеты → Анализ учета → Экспресс-проверка. Он ищет учётные нарушения (не закрытые счета, пересортицу, нарушения последовательности), а не повреждения базы.

Шаг 5. Файловая и клиент-серверная база: в чём разница проверки

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

Для MS SQL физическую проверку запускают из SQL Server Management Studio:

DBCC CHECKDB ('Buh') WITH NO_INFOMSGS;

Если команда сообщает об ошибках согласованности, восстановление лучше делать из бэкапа СУБД. Режимы с потерей данных (REPAIR_ALLOW_DATA_LOSS) — последняя мера и только на копии.

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

Шаг 6. Журнал регистрации: ищем, откуда взялись ошибки

Исправить повреждение — полдела. Если не найти причину, через месяц всё повторится. Первоисточник — журнал регистрации.

Где открыть:

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

Как искать:

1. Задайте период: от последнего дня, когда база работала нормально, до момента сбоя.
2. В отборе поставьте уровень «Ошибка», при необходимости добавьте «Предупреждение».
3. Отфильтруйте по событию: удаление объектов, изменение данных, ошибки обмена, аварийное завершение сеанса.
4. Найдите «объект не найден» по ссылке: в журнале по событию удаления видно, кто и когда удалил элемент.

На что смотреть:

• 🔌 массовые аварийные завершения сеансов — признак обрывов сети, перезагрузок или «падений» сервера;
• 🔄 ошибки обмена в одно и то же время — проблема в узле обмена или в правилах;
• 🗑 удаление объектов пользователем с полными правами в обход пометки на удаление;
• ⏱ длинные транзакции, прерванные сбоем.

Для файловой базы частая причина повреждений — работа по сети через общую папку при нестабильном соединении или выключение компьютера, на котором лежит база, во время записи. Если в журнале видны аварийные завершения сеансов и база при этом сетевая, задумайтесь о переходе на серверный вариант или веб-публикацию.

Если проверка не помогла

Бывает, что тестирование и исправление проходит, а проблема остаётся или база не открывается совсем. Варианты по нарастанию радикальности:

1. Выгрузить и загрузить .dt. Выгрузка в .dt и загрузка в новую пустую базу пересобирает всё хранилище. Часто лечит то, что не взяло тестирование.
2. Проверить конфигурацию, а не данные. Ошибки вида «Нарушение целостности структуры конфигурации» связаны с метаданными. Здесь поможет Конфигурация → Проверка конфигурации или обновление из исходного файла поставки.
3. Восстановить из резервной копии и дозанести документы, введённые после неё. Это часто быстрее, чем ручная починка сотен заглушек.
4. Отдать базу специалисту с логом тестирования, выгрузкой журнала регистрации и версией платформы.

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