Ремонт информационной базы 1С 8.3: от журналов до восстановления из копии

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

Типичная ситуация: утром бухгалтер открывает базу, а вместо рабочего стола видит Ошибка формата потока или документ не проводится с сообщением о конфликте блокировок. Администратору нужно быстро понять, что сломалось: данные, индексы, кэш, сеансы или сама СУБД. От этого зависит метод восстановления и риск для данных.

Всё описанное относится к платформе 1С:Предприятие 8.3 и не зависит от конфигурации: одинаково работает для Бухгалтерии, ЗУП, УТ и других решений.

Перед ремонтом: зафиксируйте симптом и сделайте копию

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

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

Что сделать до первых действий:

1. 📸 Сохраните точный текст ошибки. Кнопка «Подробно» в окне ошибки показывает полный стек — скопируйте его в файл.
2. 🕒 Запишите время сбоя и кто работал. Это нужно, чтобы найти событие в журналах.
3. 💾 Сделайте копию в том виде, в каком база сейчас:
   • файловая база — скопируйте весь каталог с файлом 1Cv8.1CD при закрытых сеансах;
   • клиент-серверная — полный бэкап средствами СУБД;
   • если Конфигуратор открывается — дополнительно выгрузите .dt через Администрирование → Выгрузить информационную базу.
4. 🔍 Проверьте место на диске сервера и каталоге базы. Нехватка места — частая и скучная причина «поломки».

Диагностика ошибок базы 1С по журналам

Не чините вслепую. Сначала поймите класс проблемы: ошибка данных, блокировки, сбой СУБД или окружение.

Журнал регистрации

Это первое место, куда стоит смотреть. Открыть его можно двумя способами:

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

Поставьте отбор по уровню «Ошибка» и интервалу времени вокруг сбоя. Смотрите колонки «Событие», «Метаданные» и «Данные». Если ошибки привязаны к одному документу или регистру — проблема в конкретных данных. Если ошибки массовые и разнородные — ищите причину в СУБД, кэше или сети.

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

Журнал регистрации не видит, что происходит внутри платформы и СУБД. Для этого включают технологический журнал. Его настраивают файлом logcfg.xml в каталоге conf установленной платформы, например C:\Program Files\1cv8\conf\. На сервере 1С файл кладут на тот компьютер, где работают рабочие процессы.

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" 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>

Здесь history="24" — сколько часов хранить логи. События:

Быстрая сортировка симптомов

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

У платформы два инструмента: утилита для файловых баз и режим тестирования в Конфигураторе. Второй работает для любых баз.

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

Утилита лежит в каталоге bin установленной версии платформы, например C:\Program Files\1cv8\8.3.24.1586\bin\chdbfl.exe. Номер версии в пути будет вашим.

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

Утилита работает на уровне структуры файла, а не логики данных. Поэтому после неё обычно нужен ещё один шаг — тестирование в Конфигураторе.

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

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

Какие проверки за что отвечают:

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

Пакетный запуск по расписанию или ночью

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

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

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

Как снять блокировки и зависшие сеансы в 1С

Сообщение Конфликт блокировок при выполнении транзакции — не повреждение данных. Это две операции, которые не поделили одни записи: например, закрытие месяца и массовое проведение документов одновременно.

Где искать виновника

В клиент-серверном варианте откройте консоль администрирования серверов 1С: Информационные базы → ваша база → Сеансы. Смотрите сеансы с долгим временем вызова и большим объёмом данных. В свойствах сеанса видно пользователя и компьютер.

Через утилиту командной строки rac список сеансов получают так:

rac cluster list
rac session list --cluster=<UUID_кластера> --infobase=<UUID_базы>

Если нужен параметр, которого нет в примере, смотрите rac help session.

Как завершить зависший сеанс

1. Свяжитесь с пользователем и попросите сохранить работу.
2. Если он недоступен, а сеанс держит блокировку, — удалите сеанс в консоли кластера.
3. Через rac — командой rac session terminate с UUID кластера и сеанса.

Если блокировки повторяются

• 📊 Включите в техжурнале TTIMEOUT и TDEADLOCK: в событиях видны обе стороны конфликта и пространства блокировок.
• 🗓 Разведите тяжёлые операции по времени: закрытие месяца, обмены, регламентные задания.
• ⏱ Время ожидания блокировки задаётся в Конфигуратор → Администрирование → Параметры информационной базы. Увеличивать его — временная мера, причину это не убирает.

Ошибки базы данных на уровне СУБД

Если текст ошибки начинается с Ошибка СУБД: и дальше идёт сообщение SQL Server или PostgreSQL, проблема ниже уровня 1С. Тестирование в Конфигураторе тут может не помочь — сначала нужна диагностика самой СУБД.

Частые причины:

• 💽 закончилось место на диске с данными или журналом транзакций;
• 📜 переполнен журнал транзакций SQL Server в модели восстановления Full без резервного копирования журнала;
• 🧱 повреждённые страницы данных после сбоя диска или питания;
• 🔗 разорвано соединение с сервером СУБД;
• 🔐 у пользователя СУБД, под которым работает 1С, отозваны права.

Microsoft SQL Server

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

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

Кто кого блокирует прямо сейчас:

SELECT session_id, blocking_session_id, wait_type, wait_time, command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

PostgreSQL

Активные запросы и блокирующие процессы:

SELECT pid, usename, state, now() - query_start AS duration,
       pg_blocking_pids(pid) AS blocked_by, left(query, 80)
FROM pg_stat_activity
WHERE datname = 'buh'
ORDER BY duration DESC;

Функция pg_blocking_pids доступна начиная с PostgreSQL 9.6. Принудительно завершить процесс можно через pg_terminate_backend(pid), но это тот же обрыв сеанса пользователя, что и в консоли 1С.

Для обслуживания таблиц используют VACUUM ANALYZE — он убирает «мёртвые» строки и обновляет статистику. Запускайте его в спокойное время: на больших базах он заметно нагружает диск.

Восстановление данных из резервных копий 1С

Если проверка показывает массовые повреждения, а исправление удаляет объекты, честнее восстановиться из копии, чем латать.

Порядок действий:

1. Восстановите копию в отдельную базу, а не поверх рабочей.
2. Зарегистрируйте её в кластере 1С или добавьте в список баз как файловую.
3. Проверьте: открывается ли, проходят ли тестирование и ключевые отчёты.
4. Определите, какие данные внесены после копии, и договоритесь с пользователями, кто их повторит.
5. Только после этого подменяйте рабочую базу.

Если ничего не помогло

Бывает, что база не открывается даже в Конфигураторе, а свежей копии нет. Что ещё можно попробовать:

• 🧹 Запустить клиент с ключом /ClearCache или удалить каталоги кэша пользователя. Это безопасно для данных, но перед удалением кэша вручную пользователь должен выйти из 1С.
• 🆕 Создать новую пустую базу, загрузить в неё конфигурацию из файла .cf и перенести данные обработкой выгрузки-загрузки из повреждённой базы, если та хоть частично открывается.
• 🔢 Проверить, совпадает ли версия платформы на клиенте и сервере: номер версии клиента должен быть таким же, как у сервера.
• 🛠 Для файловой базы — проверить диск (chkdsk) и исключить каталог базы из проверки антивирусом.

Если и это не помогло — с копией повреждённой базы обращайтесь к специалисту по восстановлению. Не запускайте повторные «исправления» на единственном экземпляре: каждое из них может удалить ещё часть данных.

Профилактика ошибок базы данных 1С

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

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

• 📈 Для SQL Server настройте план обслуживания: обновление статистики, перестроение индексов, бэкап журнала транзакций, если модель восстановления Full.
• 🐘 Для PostgreSQL не отключайте автоочистку (autovacuum) — без неё таблицы разрастаются, а запросы 1С замедляются.
• 🧾 Ограничьте размер журнала регистрации и регулярно сокращайте его: на больших базах он сам становится источником тормозов.
• 🚦 Держите одинаковую версию платформы на всех клиентах и сервере и обновляйте её по плану, а не по одному компьютеру.

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