Сообщение «Ошибка СУБД» в 1С: найти причину и вернуть базу в строй

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

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

Как расшифровать текст ошибки за две минуты

Сообщение обычно состоит из трёх частей. Разберите их по порядку.

1. Источник. Строка вроде Microsoft SQL Server Native Client или ERROR: ... SQLSTATE показывает, чья это ошибка.
2. Код или фраза СУБД. Например, Cannot open database, deadlocked, No space left on device, could not connect to server.
3. Контекст 1С. Документ, регистр, процедура: что делал пользователь в момент сбоя.

Сохраните сообщение целиком. В окне ошибки есть кнопка подробностей, её текст можно скопировать. Скриншот без текста мало полезен, поиск по нему не сработает.

Что означают самые частые формулировки

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

Начните с самого дешёвого и безопасного: логи. Менять настройки пока рано.

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

Откройте Администрирование → Журнал регистрации (в Бухгалтерии 3.0 и ЗУП 3.1 пункт находится в разделе администрирования, при отсутствии пункта найдите его поиском по форме). Отберите события уровня «Ошибка» за время сбоя. Обратите внимание на пользователя, компьютер и событие, которое упало.

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

Журнал самой СУБД

• 🗂 MS SQL Server: журнал ошибок SQL Server открывается в среде SSMS в разделе управления. Ищите записи с ошибками ввода-вывода, переполнения журнала и сообщения о восстановлении базы.
• 🐘 PostgreSQL: текстовые файлы в каталоге логов (параметр log_directory). Ищите строки ERROR, FATAL, PANIC.
• 🖥 Журнал событий Windows или journalctl в Linux: отказы дисков, нехватка памяти, перезапуск служб.

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

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

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

Сбои соединения с сервером СУБД

Ошибка про соединение, сетевой адаптер или недоступность сервера бывает по четырём причинам. Проверяйте в таком порядке.

1. Служба остановилась. Проверьте services.msc или systemctl status postgresql. После обновления Windows службы нередко не поднимаются сами.
2. Порт закрыт. MS SQL по умолчанию слушает 1433, PostgreSQL слушает 5432. С сервера 1С проверьте доступность командой Test-NetConnection сервер -Port 1433 в PowerShell.
3. Не тот адрес. В консоли кластера у информационной базы указано имя сервера БД. После переезда или смены IP оно устаревает.
4. Учётная запись. Пароль пользователя СУБД истёк или сменён, а в параметрах базы остался старый.

Для PostgreSQL отдельно проверьте файл pg_hba.conf: разрешён ли адрес сервера 1С и каким методом проверяется пароль. После правки нужна перезагрузка конфигурации, не всего сервера.

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

Самая частая «внезапная» причина в MS SQL: переполнен журнал транзакций (ошибка 9002, The transaction log for database is full). База в этот момент работает только на чтение, проведение документов падает.

Почему он переполняется

• Модель восстановления Full, а резервных копий журнала никто не делает. Журнал растёт, пока не упрётся в диск.
• Очень долгая открытая транзакция: например, групповая обработка на сотни тысяч объектов.
• Диск с журналом занят чем-то другим.

Что делать

1. Освободите место на диске с журналом: удалите лишнее, перенесите старые копии.
2. Сделайте резервную копию журнала транзакций. Это штатно освобождает место внутри файла.
3. Если резервные копии журнала вам не нужны (тестовая база, ночное копирование полной копией достаточно), переведите модель в Simple.
4. Только после этого при необходимости уменьшайте файл. Постоянно «ужимать» журнал вредно: он снова вырастет и будет фрагментироваться.

В PostgreSQL аналог проблемы: разросся каталог журнала предзаписи (pg_wal). Причины те же: нет места, застрявший слот репликации, не работает архивация WAL. Смотрите состояние слотов запросом к pg_replication_slots.

Восстановление целостности базы данных

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

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

1. Остановите работу пользователей. Закройте сеансы в консоли кластера, запретите новые подключения.
2. Сделайте копию того, что есть. Остановите службу СУБД и скопируйте файлы базы целиком или снимите образ диска. Даже повреждённая копия пригодится, если лечение сделает хуже.
3. Проверьте оборудование. Ошибки диска и памяти в журнале ОС значат, что лечить базу бесполезно, пока не заменено железо.
4. Запустите проверку. В MS SQL: DBCC CHECKDB с выводом ошибок. В PostgreSQL: проверка контрольных сумм (если включены) и pg_dump в никуда для проверки читаемости таблиц.
5. Решите, что восстанавливать. Если повреждён только индекс, его пересоздают. Если повреждены данные, быстрее и надёжнее поднять последнюю полную копию плюс копии журнала.

Проверка на стороне 1С

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

Для файловых баз есть отдельная утилита chdbfl, но к клиент-серверной базе её применять нельзя.

Блокировки и взаимоблокировки

Фраза deadlocked в тексте или deadlock detected в PostgreSQL означает, что две транзакции ждут друг друга. Платформа обычно показывает пользователю ошибку блокировки, а СУБД одну из сторон отменяет.

Что обычно стоит за этим:

• ⏱ длинная транзакция при проведении, внутри которой много запросов к разным регистрам;
• 🔁 параллельные регламентные задания, обновляющие одни и те же данные;
• 🔒 управляемые блокировки в коде, которые берутся в разном порядке в разных процедурах;
• 🧾 закрытие месяца одновременно с массовым вводом документов.

Для поиска: включите в технологическом журнале события TDEADLOCK, TLOCK, TTIMEOUT. Они покажут, кто кого ждал. Типичные меры: сократить транзакцию, вынести тяжёлые расчёты за её пределы, развести задания по времени. Эти правки делает разработчик, не администратор.

Настройка параметров СУБД под нагрузку

Если ошибки связаны с нехваткой памяти или медленной работой, а не с повреждениями, проверьте настройки. Цифры ниже ориентировочные: подбираются под сервер и число пользователей.

Конкретные значения для 1С рекомендуют производитель платформы и сообщество, они зависят от версии СУБД. Проверьте текущие рекомендации для вашей связки.

Обслуживание, без которого база «пухнет»

1. Обновление статистики по таблицам, ежедневно или еженедельно, в нерабочее время.
2. Перестроение или реорганизация индексов по степени фрагментации.
3. В PostgreSQL: VACUUM и ANALYZE, автоочистка должна быть включена и успевать за нагрузкой.

Если после массового удаления или загрузки документов база стала тормозить, начните именно с статистики. Это часто решает вопрос без всякой «оптимизации».

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

Пройдите по короткому списку: это экономит часы.

• 🔍 Воспроизводится ли ошибка на копии базы на другом сервере? Если нет, дело в среде, а не в данных.
• 🧩 Меняли ли что-то перед первым сбоем: обновление платформы , СУБД, антивируса, драйверов, прав?
• 📉 Совпадает ли ошибка по времени со стартом резервного копирования или регламентных заданий?
• 🧪 Не пора ли обновить платформу 1С до последнего исправленного релиза вашей ветки и совместимую версию СУБД? Список поддерживаемых версий СУБД указан в документации платформы.

Как не получить ошибку СУБД снова

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

1. Резервные копии: полная копия раз в сутки и копии журнала каждые 15-60 минут для базы, где потеря часа работы критична. Периодически проверяйте, что копия реально восстанавливается.
2. Мониторинг места: оповещение при остатке менее 20% на дисках с данными, журналом, tempdb и WAL.
3. Мониторинг ошибок: разбор журнала регистрации и логов СУБД хотя бы раз в неделю.
4. Отдельные диски: данные, журналы и временная база не должны делить один том с системой.
5. Обновления по плану: сначала на копии базы, затем в рабочую.
6. Регламентные задания: обслуживание индексов и статистики по расписанию вне рабочих часов.

Типичные ошибки администраторов

• Сжатие базы и журнала по расписанию каждую ночь: файл постоянно растёт заново и фрагментируется.
• Перезапуск службы СУБД «на всякий случай» посреди транзакций: получают восстановление базы на старте и долгий простой.
• Антивирус сканирует каталог данных и файлы журналов: возникают таймауты и ошибки ввода-вывода. Добавьте каталоги в исключения.
• Работа с базой без копии перед исправлением. Отката потом нет.
• Правка настроек по статье пятилетней давности без проверки версии СУБД.

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