Что делать, когда 1С выдаёт «Ошибка СУБД»: разбор по типу сбоя

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

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

Как прочитать ошибку СУБД и найти её в логах

Первый шаг — получить полный текст. Пользователь обычно присылает скриншот с обрезанной строкой, а нужна вся цепочка.

Где взять полный текст

• 📋 Окно ошибки. Нажмите «Подробно» в сообщении: там стек вызовов и полный ответ СУБД с кодом.
• 📒 Журнал регистрации. В БП 3.0, ЗУП 3.1 и УТ 11: Администрирование → Обслуживание → Журнал регистрации. В Конфигураторе: Администрирование → Журнал регистрации. Отберите события с уровнем «Ошибка» за время сбоя.
• 🖥️ Журнал СУБД. У MS SQL Server — журнал ошибок в SQL Server Management Studio (раздел Management → SQL Server Logs). У PostgreSQL — файлы в каталоге log (или pg_log в старых сборках) внутри каталога данных.
• 🪟 Журнал Windows. «Просмотр событий → Журналы Windows → Приложение»: туда пишут и служба агента сервера 1С, и SQL Server.

Как опознать тип СУБД по тексту

Если в тексте есть HRESULT=80004005 — это общий код OLE DB «неопознанная ошибка». Сам по себе он ничего не значит, смотрите строку перед ним.

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

Когда ошибка плавающая и журнал регистрации молчит, включите технологический журнал сервера 1С. Для этого в каталоге conf установленной платформы создают файл logcfg.xml. Пример, который собирает исключения (в них попадают и ошибки СУБД) и события блокировок:

<?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="TLOCK"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <property name="all"/>
  </log>
</config>

Когда нужно увидеть сами запросы к базе, добавляют события DBMSSQL (для MS SQL) или DBPOSTGRS (для PostgreSQL), обязательно с отбором по длительности — без отбора лог переполнится за минуты. Сервер 1С подхватывает изменения файла сам, перезапуск службы не нужен.

Обрывы соединения и сетевые сбои между 1С и сервером СУБД

Эта группа ошибок СУБД появляется, когда сервер 1С и сервер базы данных стоят на разных машинах или когда служба СУБД перезапустилась посреди работы.

Типичные тексты

• 🔌 TCP Provider: An existing connection was forcibly closed by the remote host (в русской локали — «Удаленный хост принудительно разорвал существующее подключение »).
• 🔌 Communication link failure — у MS SQL.
• 🔌 server closed the connection unexpectedly или could not connect to server: Connection refused — у PostgreSQL.

Что проверить по порядку

1. Работает ли служба СУБД. Откройте services.msc и найдите SQL Server (MSSQLSERVER) или службу PostgreSQL. Если она перезапускалась, причину ищите в журнале СУБД.
2. Доступен ли порт с сервера 1С. Для MS SQL по умолчанию это 1433, для PostgreSQL — 5432. Проверка из PowerShell на сервере 1С:

Test-NetConnection -ComputerName sql-server -Port 1433

3. Не режет ли соединения антивирус или межсетевой экран. Особенно после обновления сигнатур или политик.
4. Не закрывает ли простаивающие соединения сетевое оборудование или VPN между серверами. Обрывы «раз в N минут простоя» — характерный признак.
5. Правильно ли указан сервер СУБД в свойствах базы. Откройте консоль администрирования серверов 1С, найдите базу в кластере и посмотрите поля «Сервер баз данных», «Тип СУБД», «Пользователь сервера БД».

Ошибка входа в СУБД

Сообщения Login failed for user (MS SQL) или password authentication failed for user (PostgreSQL) значат, что сервер 1С не может авторизоваться в СУБД. Обычно пароль пользователя СУБД сменили, а в свойствах базы на кластере остался старый. Исправьте пароль в карточке базы в консоли кластера.

Блокировки и взаимоблокировки: как устранить ошибку СУБД при конфликте транзакций

Здесь две разные ситуации, и их часто путают.

Таймаут управляемой блокировки 1С

Текст: Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки. Это не ошибка СУБД в строгом смысле — это менеджер блокировок 1С. Одна транзакция держит данные, другая ждёт и отваливается по таймауту.

Что делать:

1. Выяснить, кто держит блокировку. Технологический журнал с событиями TLOCK и TTIMEOUT покажет, какой сеанс ждал и какой мешал.
2. Посмотреть, что делает «виновник». Обычно это долгое групповое перепроведение, закрытие месяца или обработка, которая пишет тысячи документов в одной транзакции.
3. Развести тяжёлые операции по времени. Закрытие месяца и массовое перепроведение — вне рабочего дня.
4. Если блокировки из доработок — передать программисту: транзакции нужно укоротить, блокировку ставить как можно позже и только на нужные данные.

Взаимоблокировка (deadlock) в СУБД

Тексты:

• MS SQL: Transaction (Process ID 57) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
• PostgreSQL: ERROR: deadlock detected.

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

Как разобрать:

1. Включите событие TDEADLOCK в технологическом журнале — оно появится при взаимоблокировке на управляемых блокировках 1С.
2. В MS SQL граф взаимоблокировки видно в стандартном сеансе Extended Events system_health. В PostgreSQL подробности пишутся в журнал сервера рядом с сообщением deadlock detected.
3. Найдите два объекта, которые пишутся в разном порядке. Типичный пример — две обработки обновляют одни и те же регистры, но одна сначала остатки, потом обороты, а другая наоборот.

Повреждение данных: исправляем ошибку СУБД в базе 1С

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

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

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

Признак — тексты вроде Файл базы данных поврежден или ошибки при чтении конкретной таблицы.

1. Попросите всех выйти из базы и закройте 1С на всех компьютерах.
2. Скопируйте файл 1Cv8.1CD в отдельную папку.
3. Запустите утилиту chdbfl.exe из каталога bin установленной платформы, например C:\Program Files\1cv8\8.3.xx.xxxx\bin\chdbfl.exe.
4. Укажите путь к 1Cv8.1CD, поставьте флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить».
5. После утилиты откройте Конфигуратор и выполните Администрирование → Тестирование и исправление.

chdbfl.exe чинит физическую структуру файла. Логику данных — битые ссылки, итоги — она не проверяет, для этого нужен второй шаг.

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

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

Порядок выбора флажков от безопасного к тяжёлому:

1. «Реиндексация таблиц информационной базы» — быстро и почти всегда полезно.
2. «Проверка логической целостности информационной базы».
3. «Проверка ссылочной целостности информационной базы». Для битых ссылок выберите «Создавать объекты» — так документы не потеряют реквизиты.
4. «Пересчет итогов».
5. «Сжатие таблиц информационной базы» — для файловой базы.
6. «Реструктуризация таблиц информационной базы» — самый долгий шаг, только если остальные не помогли.

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

Серверная база

У MS SQL физическую целостность проверяет сама СУБД:

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

Если команда нашла ошибки, не запускайте восстановление с потерей данных наугад. Сначала поднимите копию базы из последнего бэкапа на тестовом сервере и сравните. Параметр REPAIR_ALLOW_DATA_LOSS удаляет испорченные страницы — это крайняя мера.

У PostgreSQL при подозрении на повреждённые индексы выполняют REINDEX для таблицы или базы. После этого запускают тестирование и исправление из Конфигуратора.

Ошибки СУБД после обновления платформы или сервера

Вторая большая группа ошибок СУБД возникает сразу после обновлений: платформы 1С, самой СУБД или Windows.

Несовместимая версия СУБД

Каждый релиз платформы поддерживает определённый список версий СУБД. Если поставить слишком новую СУБД под старую платформу или наоборот, база может не создаваться или не открываться. Сверьте версию СУБД со списком поддерживаемых для вашей сборки платформы до обновления, а не после.

PostgreSQL без доработок для 1С

Для 1С нужна сборка PostgreSQL с патчами под платформу: дистрибутив от фирмы 1С или Postgres Pro. Ванильная сборка с сайта сообщества с базами 1С не работает корректно, ошибки начинаются уже при создании базы или загрузке .dt.

Обновление платформы на части серверов

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

Сбой при обновлении конфигурации

Если обновление конфигурации прервалось во время изменения структуры базы, при входе возможна ошибка СУБД про отсутствующую таблицу или поле, например Invalid object name у MS SQL. Действия:

1. Не пытайтесь «дообновить» поверх.
2. Восстановите базу из копии, сделанной перед обновлением.
3. Повторите обновление в монопольном режиме, когда никто не работает.

Если копии нет — в Конфигураторе выполните тестирование и исправление с флажком реструктуризации таблиц. Иногда это восстанавливает соответствие структуры, но гарантии нет.

Нехватка места на диске и переполненный журнал транзакций

Эта причина ошибок СУБД не попадает в большинство инструкций, хотя встречается постоянно.

• 💾 MS SQL: The transaction log for database '...' is full due to 'LOG_BACKUP'. База в модели восстановления Full, а резервные копии журнала не делаются — журнал растёт до конца диска.
• 💾 PostgreSQL: could not extend file ... No space left on device.
• 💾 Файловая база: сбой записи на диск, когда на томе с 1Cv8.1CD не осталось места.

Как исправить:

1. Освободите место на диске. Первым делом — старые технологические журналы, старые копии .dt, временные файлы.
2. Для MS SQL решите, нужна ли модель Full. Если вы делаете только полные ночные копии и восстановление на конкретную минуту не требуется — переведите базу в модель Simple. Если Full нужна — настройте регулярные бэкапы журнала транзакций.
3. Проверьте, где лежит tempdb у MS SQL. Тяжёлые отчёты 1С активно её используют; на системном диске она может забить его целиком.

Профилактика: как не допустить ошибки СУБД в 1С

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

Регламент для MS SQL

• 🔄 Резервные копии — полная ежедневно, журнал транзакций по расписанию при модели Full. Раз в месяц пробное восстановление на тестовый сервер.
• 📊 Обновление статистики — ежедневно ночью. Устаревшая статистика даёт медленные планы запросов и, как следствие, долгие транзакции и таймауты блокировок.
• 🧱 Обслуживание индексов — еженедельно: реорганизация при умеренной фрагментации, перестроение при сильной.
• 🔍 DBCC CHECKDB — еженедельно, в окно без нагрузки.
• 🧠 Ограничение памяти SQL Server (max server memory), если на той же машине работает сервер 1С: иначе SQL заберёт почти всю память, и рабочим процессам 1С её не хватит.

Регламент для PostgreSQL

• 🧹 Следите, чтобы работал autovacuum, и запускайте VACUUM ANALYZE после массовых операций: закрытия года, свёртки базы, загрузки больших объёмов.
• ⚙️ Настройте shared_buffers, work_mem и effective_cache_size под объём памяти сервера, а не оставляйте значения по умолчанию.
• 📦 Делайте копии через pg_dump или средствами вашего решения резервного копирования и проверяйте их восстановлением.

Для файловых баз

• 🛑 Не копируйте 1Cv8.1CD при открытой базе — копия может оказаться битой.
• 🛡️ Исключите каталог базы из проверки антивирусом.
• 🔋 Поставьте ИБП на компьютер или сервер, где лежит файл базы.
• 📈 Если с базой одновременно работает больше 5–10 человек и ошибки блокировок стали регулярными — пора переходить на клиент-серверный вариант.

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