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

Надпись «Ошибка СУБД» в 1С 8.3 скрывает исходную причину. Платформа лишь пересказывает ответ SQL Server или PostgreSQL. Точный текст ищите в журнале СУБД за ту же минуту.

Не перезапускайте службы и не запускайте «Тестирование и исправление» наугад. Сначала запишите время сбоя, имя базы и действие пользователя. Если 1С не соединяется с СУБД, начните с проверки сервера баз данных. Соединение работает — открывайте журнал СУБД.

Свяжите сообщение из окна 1С с исходной записью SQL Server или PostgreSQL. Она покажет, где искать сбой: в соединении, ресурсах сервера, временной таблице или повреждённых данных.

Где найти журнал SQL Server

Microsoft описывает два способа чтения журнала SQL Server: через SQL Server Management Studio и напрямую из файла. Файл пригодится, когда экземпляр не запускается или SSMS недоступна.

В Windows журнал по умолчанию лежит здесь:

<drive>:\Program Files\Microsoft SQL Server\MSSQL.<n>\MSSQL\LOG\ERRORLOG

В Linux Microsoft указывает другой каталог:

/var/opt/mssql/log

Точный путь зависит от имени экземпляра и параметров установки. Текущий файл называется ERRORLOG, расширения у него нет.

Даже при нестандартной установке текущий журнал SQL Server сохраняет имя ERRORLOG.

При каждом запуске экземпляра SQL Server создаёт новый журнал. Предыдущий файл получает имя ERRORLOG.1, следующий по возрасту — ERRORLOG.2. По документации Microsoft, SQL Server обычно хранит шесть предыдущих журналов.

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

Администратор также может сменить журнал без перезапуска командой sp_cycle_errorlog. Свежий ERRORLOG ещё не доказывает, что экземпляр недавно останавливался.

Как определить расположение журнала PostgreSQL

У PostgreSQL нет единого пути для всех установок. Каталог задают параметры кластера. Запросите их текущие значения:

SHOW logging_collector;
SHOW data_directory;
SHOW log_directory;
SHOW log_filename;

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

Относительный путь из log_directory отсчитывайте от data_directory. Абсолютный используйте без изменений. Такой порядок приводит справочник PGLens по журналам PostgreSQL.

Команды SHOW читают настройки нужного кластера, поэтому они точнее типового пути из инструкции.

При logging_collector = off PostgreSQL отправляет сообщения в стандартный поток ошибок. В системе с systemd откройте журнал службы:

journalctl -u postgresql

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

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

Как связать сообщение 1С с записью СУБД

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

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

Для диагностики нужен полный текст СУБД. Заголовок «Ошибка СУБД» не отличает нехватку ресурсов от повреждения данных.

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

«Недопустимое имя объекта #tt…» относится к временной таблице

SQL Server может вернуть такое сообщение:

Microsoft OLE DB Driver for SQL Server:
Invalid object name '#tt60'
HRESULT=80040E37
SQLSTATE=42S02
native error 208

Такой формат встречается в обсуждении на форуме Infostart. В приведённых там случаях временные таблицы получают префикс #tt, а хранит их системная база tempdb.

Один пример не даёт универсальной расшифровки ошибки 1С. Среди предоставленных материалов нет документа Microsoft или 1С, который связывает весь набор HRESULT, SQLSTATE и native error с одним сценарием платформы.

Сохраните полную запись SQL Server. Проверьте соседние ошибки tempdb, разрыв соединения перед сбоем и повторяемость на той же операции.

Если сообщение появляется только в одном отчёте или обработке, воспроизведите сбой на копии базы. Передайте разработчику время, текст SQL Server и действие пользователя. Одного имени #tt60 мало: при следующем запуске временная таблица может называться иначе.

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

Код PostgreSQL 53200 нельзя расшифровывать по стороннему блогу

Поиск по фразе «ошибка СУБД 53200» часто приводит к версии о нехватке памяти. В предоставленных материалах такую расшифровку даёт только блог Philip McClarence. Официальной таблицы кодов PostgreSQL среди материалов нет.

Не меняйте work_mem, shared_buffers и лимиты службы только из-за числа 53200. Сначала сохраните полный текст записи, узнайте версию PostgreSQL и прочитайте соседние сообщения. Затем найдите код в официальном приложении PostgreSQL «Error Codes» именно для этой версии.

Даже класс ошибки не указывает процесс, который исчерпал ресурс. Ответ ищите в полном сообщении PostgreSQL и событиях операционной системы за тот же момент.

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

Сообщение о повреждении требует отдельного сценария

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

Для клиент-серверной базы сначала снимите резервную копию средствами SQL Server или PostgreSQL. Разверните её отдельно: на другой машине, в другом экземпляре либо под другим именем.

Не восстанавливайте копию поверх рабочей базы. Вы сотрёте изменения, которые появились после её создания.

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

Сбой начался после обновления — сохраните текущее состояние и найдите этап, на котором прервалось обновление. Не запускайте реструктуризацию на боевой базе повторно. Сначала воспроизведите и разберите ошибку на отдельной копии.

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

При сообщении «1С SQL: ошибка СУБД» соблюдайте порядок:

1. Запишите время, имя базы и операцию пользователя.
2. Сохраните полный текст окна 1С.
3. Определите СУБД: SQL Server или PostgreSQL.
4. Откройте журнал СУБД и найдите запись за ту же минуту.
5. Сохраните код, полный текст и соседние строки.
6. При сообщении о повреждении сначала снимите резервную копию.
7. Выберите сценарий по исходному сообщению СУБД.

Сервер недоступен — проверяйте службу, порт и сеть. Видите #tt… — изучайте временную таблицу и tempdb. При признаках повреждения прекратите исправления до создания копии.

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

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

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

Если рабочей копии нет, не пересоздавайте дисковый массив и не перезапускайте сервер по кругу. Материалы можно передать в аварийную помощь по 1С и SQL. Сколько данных доступно для возврата, станет понятно после проверки копии и носителей.

Чтобы не повторилось

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

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