Диагностика информационной базы 1С 8.3: что проверять, чем и в каком порядке

Проверить базу 1С 8.3 на ошибки можно штатно: откройте Конфигуратор, выберите Администрирование → Тестирование и исправление, отметьте реиндексацию, логическую и ссылочную целостность, пересчёт итогов и запустите сначала режим «Только проверка». Для файловой базы с подозрением на физическое повреждение до этого прогоните утилиту chdbfl.exe, для серверной — проверку средствами СУБД.

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

Подготовка к проверке базы: копия, права и монопольный режим

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

Какую копию делать:

• 📁 Файловая база — скопируйте весь каталог базы, главное — файл 1Cv8.1CD. При физическом повреждении это надёжнее выгрузки: .dt из повреждённой базы может не сформироваться.
• 💾 Выгрузка .dt — Конфигуратор → Администрирование → Выгрузить информационную базу. Если выгрузка падает с ошибкой, это уже диагноз: в базе есть повреждённые записи.
• 🗄️ Серверная база — полная резервная копия средствами СУБД (MS SQL Server или PostgreSQL). Её делает администратор сервера БД.

Что нужно для запуска:

1. Пользователь с ролью «Полные права» или правом администрирования.
2. Монопольный режим. Тестирование и исправление не стартует, пока в базе есть другие сеансы.
3. Окно времени. Большая база проверяется часами, на это время работа в ней останавливается.

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

Штатные средства 1С для проверки информационной базы

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

Это главный инструмент. Путь: Конфигуратор → Администрирование → Тестирование и исправление.

Режим выбирается переключателем:

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

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

Проверка конфигурации

Ошибки бывают не только в данных, но и в коде. Конфигуратор → Конфигурация → Проверка конфигурации ищет синтаксические ошибки в модулях, ссылки на несуществующие объекты метаданных, нарушение логической целостности конфигурации. Это полезно после ручных доработок и объединения конфигураций.

Пакетный запуск из командной строки

Тестирование можно запускать без открытия Конфигуратора, например по расписанию:

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

Ключ -TestOnly включает режим «Только проверка». Результат пишется в файл из параметра /Out. Для серверной базы вместо /F указывают /S"сервер\имя_базы".

Проверки внутри типовых конфигураций

В БП 3.0 и других конфигурациях на БСП есть сервисы уровня данных:

• 🧹 Администрирование → Обслуживание → Корректировка данных — поиск и удаление дублей, удаление помеченных объектов.
• 📊 В БП 3.0 Отчёты → Анализ учета → Экспресс-проверка — ищет учётные ошибки: неверные остатки, пропущенные регламентные операции.

Это уже не техническая целостность, а логика учёта. Но частая жалоба «база с ошибками» оказывается именно такой.

Журнал регистрации: где искать следы ошибок

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

Как читать:

1. Установите отбор по уровню «Ошибка».
2. Сузьте период до дня, когда появилась проблема.
3. Сгруппируйте по событию и пользователю — повторяющиеся ошибки сразу видны.
4. Откройте запись: в комментарии будет текст исключения и модуль, где оно возникло.

Что настораживает:

• ❗ Повторяющееся Ошибка формата потока — повреждены кэш или данные.
• ❗ Аварийные завершения сеансов без действий пользователя.
• ❗ Ошибки записи одного и того же документа у разных людей.
• ❗ Массовые удаления, которых никто не делал.

Сам журнал хранится в каталоге 1Cv8Log: у файловой базы — внутри каталога базы, у серверной — в каталоге кластера srvinfo\reg_1541\<GUID базы>\1Cv8Log. Если журнал разросся до гигабайтов, его можно сократить в окне журнала регистрации в Конфигураторе, предварительно сохранив старые записи в файл.

Производительность и «узкие места»: отдельная диагностика

Тормоза — тоже ошибка, но тестирование и исправление её не найдёт. Здесь нужны другие инструменты.

Технологический журнал

Он пишет то, чего нет в журнале регистрации: исключения платформы, ожидания на блокировках, взаимоблокировки, долгие запросы. Включается файлом logcfg.xml в каталоге conf платформы, например C:\Program Files\1cv8\conf\.

Минимальная настройка для сбора исключений:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1C_TechLog\excp" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Параметр history задаёт срок хранения в часах. Для поиска блокировок добавляют события TLOCK, TTIMEOUT и TDEADLOCK.

Консоль кластера и Windows

Для серверного варианта откройте консоль администрирования кластера: в списке сеансов видно, кто держит базу, сколько памяти и времени занимает вызов. Монитор ресурсов Windows покажет, что упирается: процессор, диск или память.

Внешние утилиты для глубокой проверки базы 1С

chdbfl.exe — физическая проверка файловой базы

Утилита лежит в каталоге bin установленной платформы, например C:\Program Files\1cv8\8.3.xx.xxxx\bin\chdbfl.exe. Она проверяет сам файл 1Cv8.1CD на уровне страниц и структур, чего Конфигуратор не делает.

Порядок:

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

Типичный сценарий: база не открывается с сообщением Файл базы данных поврежден. Сначала chdbfl, потом штатное тестирование.

Проверка на стороне СУБД

За физическую целостность серверной базы отвечает СУБД, и проверять её нужно там же:

• 🗄️ MS SQL Server — команда DBCC CHECKDB по базе в SQL Server Management Studio.
• 🐘 PostgreSQL — расширение amcheck или утилита pg_amcheck (PostgreSQL 14 и новее) для проверки индексов и таблиц.

DBCC CHECKDB (N'buh_base') WITH NO_INFOMSGS, ALL_ERRORMSGS;

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

Сторонние инструменты

Есть утилиты сторонних разработчиков, которые читают 1Cv8.1CD напрямую и позволяют вытащить таблицы из базы, которую платформа не открывает. Это инструмент последнего шанса: работайте только с копией файла.

Вирусы и вредоносный код: что проверить в базе и вокруг неё

Антивирус внутри 1С не нужен, но угрозы для базы реальны.

Что проверить:

• 🦠 Файлы базы и копий — шифровальщики чаще всего портят именно .1CD и .dt. Признак: файл не открывается, рядом лежат файлы со странным расширением и запиской.
• 📎 Внешние обработки и отчёты — файлы .epf и .erf выполняют произвольный код. Посмотрите список в Администрирование → Печатные формы, отчеты и обработки: и дополнительные обработки, и расширения.
• 👤 Пользователи — нет ли незнакомых учётных записей с полными правами.
• 🛡️ Защита от опасных действий — в карточке пользователя этот флажок должен быть включён у всех, кроме администраторов. Тогда платформа предупреждает перед выполнением потенциально опасного кода.

Регулярная проверка базы 1С: как предотвратить ошибки

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

Ещё несколько правил:

• 🔌 Источник бесперебойного питания для сервера с файловой базой.
• 🌐 Файловая база по сети — не более нескольких пользователей. Если людей больше, переходите на клиент-серверный вариант или веб-публикацию.
• 💽 Свободное место на диске — с запасом не меньше размера самой базы: проверке и реструктуризации нужны временные файлы.

Когда звать специалиста: признаки серьёзного повреждения

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

• ⛔ тестирование и исправление прерывается с ошибкой или зависает на одном и том же месте;
• ⛔ chdbfl находит десятки и сотни ошибок, а после исправления база всё равно не открывается;
• ⛔ DBCC CHECKDB сообщает об ошибках согласованности;
• ⛔ после исправления исчезли документы или обнулились остатки;
• ⛔ резервной копии нет, а база — единственный экземпляр.

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

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