← На главную

Разберем весьма неприятную и распространенную проблему, с которой сталкиваются администраторы и разработчики при эксплуатации клиент-серверных баз 1С:Предприятие 8.3. В процессе работы (выгрузка на сайт, формирование отчетов, фоновые задания) система аварийно завершает работу и выдает сообщение вида: Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Не удалось найти объект "#tt5", так как он не существует.... Имя объекта может меняться (например, #tt1, #tt2), а также может сопровождаться кодами HRESULT=80040E37 или SQLSTATE=42S02.

Проанализируем ситуацию детально. Ошибка означает, что сервер 1С обратился к временной таблице в базе данных СУБД, но этой таблицы там уже нет. Выясним причины такого поведения и рассмотрим рабочие способы решения проблемы, от самых простых до глубокой настройки SQL-сервера (см. инструкцию по настройке регламентных операций MS SQL Server).

Причина 1: Ошибка конкретных релизов платформы 1С

Посмотрим на историю версий. Данная проблема массово проявлялась на релизах платформы 1С 8.3 (в частности, в ветках 8.3.8 и 8.3.9, например, 8.3.9.2033). Ошибка была официально зарегистрирована разработчиками под кодом 10171074. Она возникает при высокой нагрузке в клиент-серверном варианте, часто при активном использовании поиска по строке в динамических списках или закрытии транзакций.

Что мы можем сделать в этом случае:

1. Обновление платформы: Ошибка официально исправлена в версии платформы 8.3.9.2170 и выше. Рекомендуется запланировать обновление до стабильного актуального релиза.
2. Откат (даунгрейд): Если обновление невозможно, стабильная работа без данной ошибки наблюдалась на версии платформы 8.3.8.2088.

Причина 2: Переполнение или сбои в базе tempdb

Временные таблицы с префиксом #tt физически хранятся в системной базе tempdb в Microsoft SQL Server. Если ресурсы диска исчерпаны или настройки неоптимальны, СУБД может аварийно сбрасывать соединения и удалять временные таблицы.

Рассмотрим шаги по оптимизации tempdb, чтобы исключить узкие места:

1. Изоляция на быстрых накопителях: Разместите файлы базы tempdb на отдельном высокоскоростном диске (SSD или NVMe). Это кардинально снизит задержки при интенсивной работе 1С с временными таблицами.
2. Разделение файлов данных: Разделите основной файл данных tempdb на несколько файлов. Рекомендуется создавать количество файлов, равное числу логических ядер процессора (но обычно не более 8-10 файлов). При этом файл журнала транзакций (transaction log) всегда должен оставаться один!
3. Отключение автоприращения (Auto Grow): В моменты пиковых нагрузок операция автоматического увеличения размера файла базы данных полностью блокирует работу СУБД. Задайте файлам tempdb изначально большой размер (например, 20-50 ГБ или весь доступный объем диска), чтобы исключить динамическое расширение в рабочее время.

Экстренные способы восстановления работы

Если ошибка парализовала работу предприятия прямо сейчас, применим оперативные меры. Выполните следующие действия по порядку:

1. Перезапуск службы SQL Server: Это самое быстрое и эффективное решение. При перезапуске службы MS SQL Server системная база tempdb полностью очищается и пересоздается. Все "зависшие" временные таблицы удалятся.
2. Очистка кэша: Остановите службу сервера 1С:Предприятие. Очистите сеансовые данные и серверный кэш. Также полезно очистить пользовательский кэш на клиентах (папки %userprofile%\appdata\local\1c\), так как локальный кэш иногда сохраняет ссылки на неактуальные структуры данных.
3. Управление фоновыми заданиями: Тяжелые регламентные задания могут провоцировать удаление временных таблиц у обычных пользователей. Попробуйте временно заблокировать выполнение регламентных операций на сервере или перенести их на отдельный рабочий сервер в кластере.

Проблемы в коде 1С: Тяжелые запросы

Иногда платформа 1С забывает "убрать за собой" или теряет контекст из-за специфических конструкций в коде конфигурации (для отладки таких случаев полезна консоль запросов с отладкой временных таблиц). Разберем типичные ошибки разработчиков (для анализа сложных запросов удобно использовать консоль запросов с графом):

Проблема часто эскалируется при использовании в запросах оператора В (&Массив), если в этот массив передаются десятки или сотни тысяч элементов. SQL Server генерирует под это огромные планы запросов (рекомендуется проверка запросов на лишнюю выборку) и сильно нагружает tempdb. Избегайте таких конструкций. Вместо этого помещайте элементы во временную таблицу (через объект МенеджерВременныхТаблиц) и уже с ней делайте внутреннее соединение в основном запросе.

Что делать, если пропала физическая таблица (ошибка Недопустимое имя объекта)

Иногда в тексте ошибки фигурирует не временная таблица (#tt), а физическая, например: Недопустимое имя объекта "dbo._Document425" или Не удалось найти объект "CRM.dbo._RefSInf21797". Это более серьезная ситуация, которая возникает после некорректных обновлений, сбоев с расширениями или при тестировании и исправлении (ТИИ) базы.

Рассмотрим, как это исправить:

1. Выгрузка и загрузка DT: Остановка сервера 1С, выгрузка информационной базы в файл .dt и последующая загрузка в пустую базу SQL пересоздает все структуры таблиц. Во многих случаях это полностью устраняет ошибку ненайденных физических объектов.
2. Восстановление предопределенных данных: Существует известный баг (например, коды 70087249 или 60016376), когда при Тестировании и исправлении платформа ошибочно удаляет пустые физические таблицы предопределенных элементов (справочников). Чтобы вернуть таблицу без отката базы из бэкапа: зайдите в Конфигуратор, добавьте любой фиктивный предопределенный элемент в проблемный справочник и обновите конфигурацию базы данных (клавиша F7). В этот момент платформа принудительно создаст таблицу в SQL заново. После этого фиктивный элемент можно удалить.

Наконец, не забывайте следить за актуальностью самой СУБД. Регулярно устанавливайте последние Service Pack и кумулятивные обновления (CU) для вашей версии Microsoft SQL Server. Ошибки с разрывом транзакций часто исправляются на уровне драйверов OLE DB и Native Client.