База 1С выдаёт ошибки или не открывается: от журнала до DBCC CHECKDB

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

Диагностика всегда идёт по одной схеме: текст ошибки → журнал → проверка структуры → проверка данных. Схема одинакова для файлового и клиент-серверного варианта 1С:Предприятия 8.3.

1. Диагностика ошибок базы 1С: текст сообщения и журнал регистрации

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

Дальше — журнал регистрации. В пользовательском режиме БП 3.0, ЗУП 3.1 и УТ 11 он открывается через Администрирование → Обслуживание → Журнал регистрации. В Конфигураторе — Администрирование → Журнал регистрации.

Что смотреть в журнале:

• 🔴 уровень «Ошибка» — включите отбор по важности, чтобы не листать тысячи информационных строк;
• 👤 пользователя и компьютер — ошибка у одного человека и у всех лечится по-разному;
• 🕐 время первого появления — совпадает ли оно с обновлением, отключением света, установкой новой платформы;
• 📄 поле «Данные» — ссылка на документ или элемент справочника, на котором упало.

Физически журнал лежит в подкаталоге 1Cv8Log рядом с базой (для файловой) или в каталоге кластера на сервере. В новых версиях это один файл 1Cv8.lgd, в старом формате — набор файлов .lgp и .lgf. Если сам журнал не открывается или «пустой», это тоже симптом: файл мог повредиться при сбое.

Как классифицировать ошибку

💡 Если ошибка возникает только на одном рабочем месте, а у остальных база работает, база почти наверняка цела. Начните с очистки локального кэша (раздел 6), а не с исправления базы.

2. Технологический журнал: когда журнала регистрации мало

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

Он включается файлом logcfg.xml в каталоге conf установленной платформы (например, C:\Program Files\1cv8\conf\). На сервере файл кладут на машине, где работает служба сервера 1С. Минимальная настройка для поиска ошибок и блокировок:

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

Что здесь важно:

1. location — каталог для логов на диске с запасом места. Не системный диск.
2. history="24" — хранить логи 24 часа. Платформа сама удаляет старые.
3. EXCP — исключения, в том числе аварийные завершения процессов.
4. TDEADLOCK и TTIMEOUT — взаимоблокировки и таймауты управляемых блокировок.

Платформа подхватывает изменение файла сама, перезапуск службы не нужен. Логи появятся в подкаталогах с именами процессов (rphost_..., 1cv8_...), файлы называются по часам.

3. Проверка и исправление базы 1С встроенными средствами

У платформы два инструмента. Они не заменяют друг друга: chdbfl.exe чинит физическую структуру файла базы, а «Тестирование и исправление» проверяет логику и ссылки внутри данных.

Утилита chdbfl.exe — только для файловой базы

Утилита лежит в каталоге bin установленной платформы: C:\Program Files\1cv8\8.3.xx.xxxx\bin\chdbfl.exe. Её запускают, когда база не открывается вовсе или выдаёт Файл базы данных поврежден.

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

На базе в 10–20 ГБ проверка идёт от нескольких минут до часа. Утилита работает с файлом напрямую, поэтому прерывать её нельзя.

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

Режим открывается через Конфигуратор → Администрирование → Тестирование и исправление. Нужен монопольный доступ: все сеансы, включая фоновые задания, должны быть завершены.

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

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

Запуск из командной строки

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

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

Для серверной базы вместо /F используют /S"сервер\имябазы". Ключ -TestOnly включает режим только проверки, -ReIndex — реиндексацию. Протокол пишется в файл из /Out.

4. Как исправить ошибки базы 1С на уровне СУБД

В клиент-серверном варианте данные хранит СУБД. Если она повреждена, «Тестирование и исправление» либо упадёт, либо выдаст ошибку СУБД с её собственным кодом. Тогда проверка идёт средствами самой СУБД.

Microsoft SQL Server

Проверка целостности:

DBCC CHECKDB ('Buh') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Пустой результат — база цела. Если есть ошибки, в конце вывода SQL Server подскажет минимальный уровень исправления.

• 🟢 REPAIR_REBUILD — перестраивает индексы, данные не теряет.
• 🔴 REPAIR_ALLOW_DATA_LOSS — удаляет повреждённые страницы вместе с данными.

Исправление требует однопользовательского режима:

ALTER DATABASE Buh SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('Buh', REPAIR_REBUILD);
ALTER DATABASE Buh SET MULTI_USER;

Если SQL Server требует REPAIR_ALLOW_DATA_LOSS, лучше сначала восстановиться из последнего целого бэкапа. После REPAIR_ALLOW_DATA_LOSS обязательно прогоните в Конфигураторе тестирование с проверкой ссылочной целостности и пересчётом итогов: СУБД удалила строки, ничего не зная о связях объектов 1С.

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

PostgreSQL

Аналога DBCC CHECKDB в PostgreSQL нет. Используют несколько приёмов:

1. Расширение amcheck и функцию bt_index_check — проверка индексов.
2. REINDEX DATABASE — перестроение всех индексов, если проверка нашла ошибки.
3. Пробный pg_dump в /dev/null или во временный файл: он читает все таблицы и падает на повреждённой строке. Так находят битую таблицу.

pg_dump -U postgres -d buh -f /tmp/test.dump

Если дамп прошёл без ошибок, данные читаются целиком — проблема не в физическом повреждении.

5. Блокировки и взаимоблокировки в базе 1С

Конфликты блокировок часто принимают за «ошибки базы», хотя данные целы. Симптомы: пользователь проводит документ, ждёт около 20 секунд и получает сообщение о конфликте блокировок или превышении времени ожидания. Взаимоблокировка — когда два сеанса ждут друг друга, и платформа отменяет транзакцию одного из них.

Что делать сразу

1. Откройте консоль кластера серверов 1С, найдите базу и посмотрите список сеансов.
2. Найдите сеанс с давно открытой транзакцией — обычно это фоновое задание, обмен или зависший отчёт.
3. Завершите его, только убедившись, что это не проведение важной обработки.

Как найти причину

• 🔍 Включите в техжурнале события TDEADLOCK и TTIMEOUT (раздел 2). В них видно, какие пространства блокировок и какие сеансы конфликтовали.
• 🔍 Проверьте режим блокировок в свойствах конфигурации: «Режим управления блокировкой данных». У актуальных типовых — «Управляемый». Автоматический режим на серверной базе блокирует таблицы крупнее и чаще даёт конфликты.
• 🔍 Сопоставьте время конфликтов с расписанием регламентных заданий и обменов.

Типовые причины, которые решаются без программиста:

Если конфликты дают собственные доработки (код с длинными транзакциями, запросы внутри цикла), это работа для разработчика: исправление делается в коде, а не в базе.

6. Восстановление базы 1С после сбоя питания и аварии

Внезапное отключение особенно опасно для файловой базы: запись в 1Cv8.1CD обрывается на середине. Серверная база на MS SQL или PostgreSQL обычно поднимается сама — СУБД откатывает незавершённые транзакции по своему журналу.

Кэш сервера 1С

Если после аварии серверная база ведёт себя странно, а СУБД проверку проходит, причиной может быть сеансовый кэш сервера. Он хранится в каталоге кластера, папки snccntx... внутри srvinfo\reg_1541.

Порядок: остановить службу «Агент сервера 1С:Предприятия», удалить папки snccntx..., запустить службу.

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

Восстановитесь из резервной копии и перенесите в неё документы, введённые после бэкапа. Для серверной базы на MS SQL в полной модели восстановления можно откатиться на момент перед сбоем по журналу транзакций — если бэкапы журнала делались.

Выгрузка в .dt из повреждённой базы иногда проходит, когда сама база работает с ошибками. Загрузка такого файла в новую пустую базу пересобирает таблицы с нуля. Это не панацея: если повреждены данные, выгрузка упадёт на них.

7. Профилактика: как не доводить базу 1С до лечения

Большинство описанных выше аварий предсказуемы. Регламент на одну страницу снимает почти все.

Несколько наблюдений из практики:

• 💾 Файловая база по сети. Файловую базу в общей папке открывают десятки людей по Wi-Fi — и потом удивляются повреждениям. При 5–10 одновременных пользователях и выше думайте о клиент-серверном варианте или публикации на веб-сервере.
• 🧱 Антивирус. Сканирование 1Cv8.1CD на лету замедляет работу и в момент записи может мешать платформе. Исключение для каталога базы ставят в первую очередь.
• 🔄 Обновления. Обновляйте конфигурацию только после свежего бэкапа. Прерванное обновление структуры — частая причина неработающей базы.
• 📊 Мониторинг диска. Уведомление при заполнении диска на 85% дешевле, чем ночь восстановления.

Проверку «Тестирование и исправление» не нужно гонять по расписанию «на всякий случай». Её запускают по симптомам. Плановой должна быть проверка бэкапов и регламент СУБД.

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