«Ошибка СУБД» в 1С:Предприятии 8.3: разбор по тексту сообщения

Ошибка СУБД в 1С означает, что платформа отправила запрос в базу данных, а СУБД его отклонила или не смогла выполнить. Причина почти всегда написана в самом сообщении после двоеточия: код ошибки SQL Server (native=1205, native=9002), текст PostgreSQL (ERROR: deadlock detected) или фраза файловой базы Файл базы данных поврежден. Сначала читайте этот хвост, а не первую строку.

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

Как 1С работает с базой данных и где рождается ошибка

У 1С:Предприятия 8.3 два варианта хранения данных, и ошибки у них разные.

• 📁 Файловая база. Один файл 1Cv8.1CD, встроенный движок платформы. Ошибки СУБД здесь — это чаще всего повреждение файла, нехватка места на диске или доступ к файлу из нескольких мест по сети с неустойчивым соединением.
• 🖥 Клиент-серверная база . Клиент подключается к агенту сервера 1С (порт 1540), тот передаёт его менеджеру кластера (1541) и рабочему процессу. Рабочий процесс rphost и есть клиент СУБД: он строит SQL-запрос и отправляет его в Microsoft SQL Server, PostgreSQL, IBM Db2 или Oracle.

Получается цепочка: пользователь → сервер 1С → СУБД. Сообщение «Ошибка СУБД» показывает, что сбой случился на последнем звене. Сервер 1С в этот момент работает, лицензия в порядке, но база ответила отказом.

Типовой вид сообщения для SQL Server:

Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Transaction (Process ID 87) was deadlocked
on lock resources with another process and has been chosen as the deadlock victim.
HRESULT=80004005, SQLSrvr: SQLSTATE=40001, state=..., native=1205, line=1

Самая полезная часть — native=. Это номер ошибки SQL Server, по нему причина находится однозначно. У PostgreSQL вместо номера — английская фраза после ERROR:.

Причины ошибок СУБД: таблица по тексту сообщения

Ниже — частые сочетания, которые встречаются в рабочих базах. Ищите в своём сообщении ключевую фразу или код.

Где искать подробности: журнал регистрации, техжурнал и логи SQL

Окно с ошибкой пользователь закрывает, и текст теряется. Поэтому первым делом найдите полное сообщение в логах.

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

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

1. Поставьте отбор по уровню «Ошибка» и по интервалу времени, когда был сбой.
2. Найдите событие с текстом «Ошибка СУБД».
3. Откройте запись: там полный текст, имя пользователя, компьютер и объект метаданных, на котором упала операция.

Объект метаданных часто подсказывает причину сам: если все сбои на проведении одного документа, ищите блокировки по его регистрам.

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

Журнал регистрации пишет итог, а технологический журнал — что происходило внутри сервера 1С. Его включают файлом logcfg.xml, который кладут в каталог conf установки платформы на сервере 1С (например, C:\Program Files\1cv8\conf\). Платформа подхватывает файл без перезапуска, обычно в течение минуты.

Минимальная настройка для разбора ошибок СУБД и блокировок:

<?xml version="1.0" encoding="UTF-8"?>
<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>
    <event><eq property="name" value="TLOCK"/></event>
    <property name="all"/>
  </log>
</config>

• 🔴 EXCP — исключения, в том числе ошибки СУБД с полным текстом.
• 🔒 TLOCK, TTIMEOUT, TDEADLOCK — управляемые блокировки 1С: кто ждал, кого и сколько.
• history="24" — хранить файлы 24 часа, чтобы журнал не забил диск.

После разбора удалите или переименуйте logcfg.xml, иначе журнал будет писаться постоянно.

Логи самой СУБД

• SQL Server. Журнал ошибок смотрят в SQL Server Management Studio: Management → SQL Server Logs. Для взаимоблокировок удобна встроенная сессия Extended Events system_health — в ней сохраняются графы deadlock.
• PostgreSQL. Логи лежат в каталоге log внутри каталога данных (на Linux путь зависит от сборки). Для разбора блокировок включите log_lock_waits = on: в лог попадут ожидания дольше deadlock_timeout.

Блокировки и взаимоблокировки (Deadlock)

Блокировки — самая частая причина ошибок СУБД в рабочих клиент-серверных базах с десятками пользователей.

Как отличить таймаут от взаимоблокировки

• ⏳ Таймаут. Транзакция A держит данные долго, транзакция B ждёт и сдаётся. В 1С при управляемых блокировках это сообщение «Превышено максимальное время ожидания предоставления блокировки» — оно идёт от самой платформы. На стороне SQL Server — native=1222.
• 🔁 Взаимоблокировка. A держит запись 1 и хочет запись 2, B держит запись 2 и хочет запись 1. Ждать бесполезно, СУБД или 1С выбирает «жертву» и откатывает её транзакцию.

Разовая взаимоблокировка в загруженной базе — нормальное событие. Пользователь повторил проведение, документ провёлся. Разбирать нужно, когда это повторяется каждый день на одних и тех же операциях.

Что делать при частых блокировках

1. По журналу регистрации определите, какие документы или обработки участвуют в конфликте.
2. Включите технологический журнал с TLOCK и TDEADLOCK и дождитесь повтора.
3. В событии TDEADLOCK смотрите свойство DeadlockConnectionIntersections: там указаны оба соединения и пространства блокировок, за которые они спорили.
4. Проверьте режим управления блокировками в свойствах конфигурации. Современные типовые работают в управляемом режиме; на старых доработанных базах встречается автоматический — с ним SQL Server блокирует больше, чем нужно.
5. Найдите длинные транзакции: групповое перепроведение, закрытие месяца, обмены, регламентные задания в рабочее время.

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

Посмотреть, кто держит блокировку прямо сейчас

В SQL Server ожидания видны в системном представлении:

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

blocking_session_id — это сеанс-виновник. Соответствие сеанса SQL и сеанса 1С ищут в консоли кластера: у сеанса 1С есть свойство с номером соединения с СУБД.

Повреждение данных и ошибки целостности

Если ошибка СУБД возникает на одном и том же объекте при любом обращении, даже при простом открытии списка, данные могут быть повреждены физически или логически.

Перед любой проверкой и исправлением сделайте полную резервную копию базы — выгрузку .dt или копию средствами СУБД. Исправление удаляет и пересоздаёт данные, откатить его без копии нельзя.

Файловая база

1. Попросите всех выйти из базы и скопируйте каталог базы целиком.
2. Запустите утилиту chdbfl.exe из каталога bin установленной платформы.
3. Укажите путь к 1Cv8.1CD, поставьте флажок исправления ошибок и запустите проверку.
4. После утилиты откройте Конфигуратор и выполните Администрирование → Тестирование и исправление.

Утилита работает только с файловой базой и требует, чтобы база была закрыта.

Клиент-серверная база

Порядок проверки — от уровня СУБД к уровню 1С:

1. Физическая целостность в SQL Server. Выполните DBCC CHECKDB для базы. Команда без параметров ремонта только сообщает об ошибках и ничего не меняет.

DBCC CHECKDB ('ИмяБазы') WITH NO_INFOMSGS;

2. Если CHECKDB нашёл ошибки — восстанавливайтесь из последней исправной резервной копии. Режим REPAIR_ALLOW_DATA_LOSS удаляет повреждённые страницы вместе с данными; это крайняя мера и только на копии базы.
3. Логическая целостность 1С. В Конфигураторе: Администрирование → Тестирование и исправление. Требуется монопольный доступ, поэтому выполняйте вне рабочего времени.

В окне тестирования для начала достаточно трёх флажков:

• ✅ проверка логической целостности информационной базы;
• ✅ проверка ссылочной целостности;
• ✅ реструктуризация таблиц информационной базы — включайте, если ошибка появилась при обновлении конфигурации.

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

Дубли при реструктуризации

Ошибка с duplicate key или CREATE UNIQUE INDEX при обновлении значит, что в таблице есть записи, нарушающие уникальность нового индекса. Чаще всего так бывает после сбоя записи или загрузки данных в обход платформы. «Тестирование и исправление» с реструктуризацией обычно устраняет такие дубли. Если нет — их ищут запросом в СУБД по полям индекса, но правка таблиц напрямую — работа для администратора, а не для пользователя.

Обслуживание СУБД, чтобы ошибки не возвращались

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

Microsoft SQL Server

Ещё три настройки, которые закрывают типичные сбои:

1. Ограничение памяти. Задайте max server memory в свойствах сервера, оставив операционной системе и серверу 1С часть оперативной памяти. Без ограничения SQL Server забирает почти всю память, и рабочие процессы 1С начинают падать.
2. Модель восстановления. Если резервные копии журнала не делаются, переведите базу в модель «Простая». Тогда журнал очищается сам, но восстановить базу можно только на момент полной копии.
3. Место на дисках. Следите за дисками с данными, журналом и tempdb. Ограничение роста файла базы, забытое с тестовой установки, — частая причина ошибки 1105.

PostgreSQL

Для 1С используют сборки PostgreSQL с доработками под платформу (от фирмы 1С или Postgres Professional). Ванильный PostgreSQL без патчей с 1С не работает как положено.

• 🧹 VACUUM и ANALYZE. Автоочистка (autovacuum) должна быть включена. Для больших баз дополнительно запускают vacuumdb --analyze по расписанию ночью.
• 🔢 max_locks_per_transaction. Значение по умолчанию мало для 1С. Его повышают, например, до 256 и выше, если в логе встречается out of shared memory.
• 💾 shared_buffers. Ориентир — около четверти оперативной памяти сервера, если на нём не работают другие тяжёлые службы.
• 📈 Мониторинг места. PostgreSQL при заполненном диске может остановиться целиком, а не только отказать одному запросу.

Общие правила для обоих вариантов

• 🛡 Добавьте каталоги данных СУБД и файловые базы в исключения антивируса. Сканирование файла в момент записи даёт и обрывы, и повреждения.
• 🔌 Сервер СУБД держите на ИБП. Внезапное отключение питания — основной источник повреждённых файлов 1Cv8.1CD.
• 🌐 Файловую базу не открывайте через VPN или Wi-Fi с нескольких мест одновременно. При десятке пользователей и регулярных сбоях пора переходить на клиент-серверный вариант.

Если ошибка осталась: что собрать для администратора

Когда своими силами причину найти не удалось, соберите пакет данных. С ним специалист разберётся за час, а не за день.

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