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

Обновлено 07.10.2026 · 12 мин

Содержание

«Ошибка СУБД» в 1С означает, что платформа отправила запрос в базу данных, а СУБД (MS SQL Server, PostgreSQL или файловый движок 1С) вернула отказ. Сама 1С в этот момент только пересказывает чужую ошибку. Поэтому первое действие всегда одно: прочитать сообщение целиком, до конца, и найти в нём текст от самой СУБД. Именно он показывает причину: нет места на диске, неверный пароль, взаимоблокировка, повреждённый файл.

Дальше по найденной причине выбирают способ устранения. Сбой из-за места на диске решают за 10 минут, взаимоблокировки требуют анализа запросов, а повреждённый файл базы — проверки и восстановления из копии.

Из чего состоит сообщение и почему возникает ошибка СУБД

Полный текст обычно выглядит так:

Ошибка СУБД:
Microsoft SQL Server Native Client 11.0: Журнал транзакций для базы данных "buh" заполнен.
HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1

Разбирайте его по частям:

🔹 Первая строка — от 1С: «Ошибка СУБД». Она ничего не говорит о причине.
🔹 Драйвер — Microsoft SQL Server Native Client, ODBC Driver или ERROR: для PostgreSQL. По нему видно, какая СУБД отказала.
🔹 Текст ошибки — главное. Его и нужно искать в документации СУБД.
🔹 Код — native=9002, native=1205, SQLSTATE=40P01. По коду причину находят быстрее, чем по тексту.

Причины по группам:

Группа	Типичный текст	Что случилось
💾 Место	`заполнен журнал транзакций`, `could not extend file`, `No space left on device`	Кончился диск или раздулся лог транзакций
🔐 Доступ	`Login failed for user`, `password authentication failed`	Неверный логин/пароль или нет прав на базу
🔒 Блокировки	`вызвала взаимоблокировку`, `deadlock detected`	Две транзакции ждут друг друга
🌐 Связь	`TCP Provider`, `could not connect to server`, `Communication link failure`	Сервер СУБД недоступен по сети
🧱 Повреждение	`Файл базы данных поврежден`, `consistency errors`	Сбой диска, аварийное отключение питания
⏱ Ресурсы	`out of memory`, `timeout expired`	Тяжёлый запрос, нехватка памяти

В файловой базе тоже бывает «Ошибка СУБД». Там СУБД — встроенный движок 1С, а самые частые тексты: Файл базы данных поврежден и ошибки доступа к файлу 1Cv8.1CD.

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

Если сообщение пользователь закрыл, а текст не сохранил, его можно найти в трёх местах.

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

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

Установите отбор по уровню Ошибка.
Сузьте интервал до времени сбоя.
Откройте событие: в комментарии будет полный текст ошибки СУБД, а в колонках — пользователь, компьютер и данные (документ или отчёт).

По журналу регистрации видно кто и на чём упал. Если ошибка повторяется на одном документе или отчёте — это подсказка к анализу запроса.

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

Журнал регистрации не показывает текст SQL-запроса и участников взаимоблокировки. Для этого включают технологический журнал: файл 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:\1c_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 — исключения, в том числе ошибки СУБД.
🔸 TDEADLOCK — взаимоблокировки управляемых блокировок 1С.
🔸 TTIMEOUT — превышено время ожидания блокировки.
🔸 TLOCK — сами управляемые блокировки.
🔸 history="24" — хранить 24 часа логов.

Техжурнал быстро растёт. Не добавляйте событие DBMSSQL (все запросы к MS SQL) без фильтра — за час на нагруженной базе набираются гигабайты. Выносите каталог логов на диск, где не лежат файлы базы данных, и выключайте журнал после разбора, удалив или переименовав logcfg.xml.

Платформа подхватывает изменения файла без перезапуска службы, примерно в течение минуты.

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

MS SQL Server — журнал ошибок в SQL Server Management Studio: Management → SQL Server Logs. Взаимоблокировки по умолчанию пишет сеанс расширенных событий system_health.
PostgreSQL — каталог log (или pg_log в старых версиях) внутри каталога данных. Путь задаёт параметр log_directory в postgresql.conf.

Взаимоблокировки (deadlock) и конфликты блокировок

Сообщение при взаимоблокировке на MS SQL:

Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 11.0: Транзакция (идентификатор процесса 87)
вызвала взаимоблокировку ресурсов блокировки с другим процессом и была выбрана
в качестве жертвы взаимоблокировки. Запустите транзакцию повторно.

На PostgreSQL то же самое выглядит как ERROR: deadlock detected.

Механика простая. Транзакция А заблокировала запись 1 и ждёт запись 2. Транзакция Б держит запись 2 и ждёт запись 1. СУБД видит замкнутый круг и отменяет одну из транзакций. Пользователь, чью транзакцию отменили, получает ошибку; второй работает дальше.

Отличайте от другой ошибки: Превышено максимальное время ожидания предоставления блокировки. Это не deadlock, а таймаут управляемой блокировки 1С: документ ждал, пока другой сеанс освободит данные, и не дождался (по умолчанию 20 секунд).

Как разбирать

Включите техжурнал с событиями TDEADLOCK и TTIMEOUT (пример выше).
Дождитесь повторения сбоя.
В событии найдите свойства DeadlockConnectionIntersections или WaitConnections — там номера соединений, которые мешают друг другу, и таблицы (регистры), на которых случился конфликт.
По номерам соединений найдите в том же журнале, какие документы проводились в эту секунду.

Сразу посмотреть, кто кого держит, можно прямо в СУБД:

-- MS SQL Server: кто сейчас заблокирован и кем
SELECT session_id, blocking_session_id, wait_type, wait_time, command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

-- PostgreSQL: сеансы, ждущие блокировку
SELECT pid, state, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE wait_event_type = 'Lock';

Что помогает

✅ Режим управляемых блокировок. В Конфигураторе: свойства корня конфигурации → Режим управления блокировкой данных. У типовых БП 3.0, ЗУП 3.1 и УТ 11 он уже управляемый. В старых самописных конфигурациях автоматический режим — частая причина взаимоблокировок на уровне СУБД.
✅ Разнести тяжёлые операции по времени. Закрытие месяца , перепроведение и массовая загрузка в часы работы пользователей — классический источник конфликтов.
✅ Одинаковый порядок блокировок в доработках. Если два своих обработчика проведения блокируют регистры в разном порядке, deadlock — вопрос времени.
✅ Короткие транзакции. Не вызывайте внешние сервисы и диалоги внутри транзакции.

Единичный deadlock раз в неделю — нормальная жизнь нагруженной базы, достаточно повторить операцию. Десятки в день — сигнал искать конкретный конфликт.

Медленные запросы, нехватка ресурсов и переполнение диска

Здесь ошибки СУБД появляются не из-за логики, а из-за железа и обслуживания.

Журнал транзакций и диск

Ошибка native=9002 («журнал транзакций заполнен») на MS SQL почти всегда значит одно: база в модели восстановления Full, а резервные копии журнала никто не делает. Лог растёт до конца диска.

Проверить размер и заполнение логов:

DBCC SQLPERF(LOGSPACE);

Два правильных решения:

Настроить регулярное резервное копирование журнала транзакций — если нужно восстановление на момент времени.
Перевести базу в модель Simple — если хватает ежедневных полных копий. Это делается в свойствах базы в Management Studio, страница Options → Recovery model.

После этого лог можно сжать командой DBCC SHRINKFILE. Сжимать лог без смены модели или настройки копий бесполезно: через неделю он снова заполнит диск.

Не удаляйте файлы .ldf и .mdf вручную при работающей службе SQL и не отсоединяйте базу «чтобы почистить». Это прямой путь к потере данных.

На PostgreSQL аналог — No space left on device или could not extend file. Проверьте место на разделе с каталогом данных и раздувание каталога pg_wal: обычно оно связано с неработающей архивацией WAL или зависшим слотом репликации.

Тяжёлые запросы и таймауты

Отчёт без отборов за 5 лет или самописная обработка с запросом в цикле могут упереться в память или таймаут. Признаки: ошибка всегда на одном отчёте и только на большом периоде.

🔍 Найдите отчёт или обработку по журналу регистрации.
🔍 Проверьте, воспроизводится ли ошибка на коротком периоде. Если нет — дело в объёме, а не в данных.
🔍 Для доработок включите замер производительности в Конфигураторе (Отладка → Замер производительности) и найдите строку, где запрос выполняется внутри цикла.

Статистика и индексы

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

Действие	MS SQL Server	PostgreSQL	Как часто
Обновление статистики	`sp_updatestats`	`ANALYZE`	ежедневно ночью
Перестроение индексов	план обслуживания `Rebuild Index`	`REINDEX`	еженедельно
Очистка «мёртвых» строк	—	`VACUUM` (обычно autovacuum)	автоматически
Проверка целостности	`DBCC CHECKDB`	`amcheck`	еженедельно

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

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

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

Ошибка СУБД: Login failed for user 'sa'.
Ошибка СУБД: FATAL: password authentication failed for user "postgres"
Ошибка СУБД: Named Pipes Provider: Could not open a connection to SQL Server

Где хранятся параметры подключения

Сервер 1С подключается к СУБД с теми логином и паролем, что указаны в свойствах информационной базы на кластере. Открыть их: консоль администрирования серверов 1С → кластер → Информационные базы → свойства базы. Там поля:

Сервер баз данных — имя или IP сервера СУБД, для именованного экземпляра MS SQL — SERVER\INSTANCE;
Тип СУБД;
База данных — имя базы в СУБД;
Пользователь сервера БД и Пароль.

Если пароль SQL-пользователя сменили в СУБД, его надо обновить и здесь — сама 1С об этом не узнает.

Какие права нужны

🔐 MS SQL Server: пользователю, под которым 1С подключается к базе, нужна роль db_owner в этой базе. Чтобы 1С сама создавала новые базы — серверная роль dbcreator.
🔐 PostgreSQL: пользователь должен быть владельцем базы. Доступ с сервера 1С должен быть разрешён в pg_hba.conf; после правки этого файла конфигурацию перечитывают без остановки (SELECT pg_reload_conf();).
🔐 Файловая база: у пользователя Windows (или у учётной записи службы, если база опубликована на веб-сервере) нужны права на изменение каталога базы, а не только на файл 1Cv8.1CD: рядом создаются служебные файлы.

Сетевые причины

Если текст про TCP Provider или could not connect to server:

Проверьте, запущена ли служба СУБД.
Проверьте доступность порта с сервера 1С: по умолчанию 1433 у MS SQL и 5432 у PostgreSQL. В PowerShell: Test-NetConnection имя_сервера -Port 1433.
Для MS SQL проверьте, что протокол TCP/IP включён в SQL Server Configuration Manager, а для именованного экземпляра работает служба SQL Server Browser.

Повреждение данных: проверка и восстановление

Самый неприятный вариант. Признаки: ошибка на одних и тех же данных, тексты Файл базы данных поврежден, consistency errors, invalid page.

Перед любым восстановлением сделайте копию базы в текущем состоянии — файлами (для файловой базы) или средствами СУБД. Если исправление пойдёт не так, у вас останется исходная точка.

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

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

Для клиент-серверной базы:

Проверьте базу средствами СУБД: DBCC CHECKDB('имя_базы') на MS SQL.
Если ошибки есть — лучший путь восстановление из последней исправной резервной копии СУБД.
Логические ошибки 1С (битые ссылки, неверные итоги) исправляет Тестирование и исправление в Конфигураторе. Режим требует монопольного доступа: пользователи будут отключены, планируйте его на нерабочее время.

Режим REPAIR_ALLOW_DATA_LOSS у DBCC CHECKDB может удалить повреждённые строки вместе с данными. Используйте его только когда исправной копии нет, и после него обязательно прогоните тестирование и исправление в 1С.

Диагностика: выберите симптом

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

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

Регламент обслуживания СУБД для 1С

Ежедневная полная резервная копия базы и проверка, что копия восстанавливается
Контроль свободного места на дисках с данными и логами, порог тревоги 15-20%
Ночное обновление статистики
Еженедельное перестроение индексов и проверка целостности
Модель восстановления выбрана осознанно: Simple или Full с копиями журнала
Пароль пользователя СУБД хранится у администратора и совпадает с настройкой в кластере
Тяжёлые регламентные операции вынесены на нерабочее время

Выполнено: 0 / 7

Что ещё стоит настроить:

📊 Мониторинг места. Простейший скрипт по расписанию, который пишет в почту или мессенджер при заполнении диска выше 80%, предотвращает самую частую аварию.
📊 Еженедельный просмотр журнала регистрации с отбором по ошибкам. Один и тот же текст ошибки СУБД пять раз за неделю — повод разобраться до того, как он станет ежедневным.
📊 Память SQL Server. Ограничьте max server memory, если на том же сервере работает сервер 1С: иначе SQL заберёт почти всю память, и рабочим процессам 1С её не хватит.
📊 Пробное восстановление. Раз в месяц разверните резервную копию на тестовый сервер. Копия, которую никто не проверял, может оказаться пустой ровно в день аварии.

Частые ошибки при устранении сбоя

❌ Перезапуск сервера как первое действие. Перезагрузка обрывает сеансы всех пользователей и часто прячет причину: лог очищается, блокировки снимаются, а через день всё повторяется. Сначала сохраните текст ошибки и посмотрите журнал.
❌ Сжатие журнала транзакций без смены режима. Место вернётся на неделю, потом снова авария.
❌ Лечение по первой строке. «Ошибка СУБД» — не причина. Без текста от драйвера любые действия наугад.
❌ Техжурнал «на всё» без ограничений. Сам по себе может заполнить диск и вызвать новую ошибку СУБД.
❌ Тестирование и исправление в рабочее время. Режим требует монопольного доступа и на большой базе идёт часами.

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

Можно ли просто повторить операцию после ошибки СУБД?

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

Теряются ли данные при ошибке СУБД?

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

Почему ошибка только у одного пользователя?

Обычно она связана с его действием: конкретный отчёт на большом периоде или документ, который конфликтует с чужой операцией. Найдите его события в журнале регистрации с отбором по пользователю.

Что лучше для 1С при частых сбоях — MS SQL или PostgreSQL?

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

Нужно ли обращаться к программисту 1С?

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

Помогла статья?