При активной работе пользователей в базах данных на платформе 1С:Предприятие под управлением Microsoft SQL Server периодически возникает аварийное завершение операций с системным сообщением: Ошибка СУБД: Microsoft SQL Server Native Client: Недопустимое имя объекта "#tt4". HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02. Номер временной таблицы в имени может варьироваться (например, #tt1, #tt4, #tt12), однако суть проблемы остается неизменной. Разберем природу этого сбоя и рассмотрим пошаговые методы его гарантированного устранения.
Выясним причину возникновения ошибки
Префикс #tt присваивается временным таблицам, которые платформа 1С автоматически создает в системной базе данных tempdb СУБД. Эти таблицы используются для промежуточных вычислений сложных запросов, работы динамических списков, передачи коллекций значений в условия отбора и полнотекстового поиска.
Ошибка сигнализирует о том, что процесс СУБД попытался обратиться к таблице, которой больше не существует в контексте текущей сессии, либо произошла рассинхронизация пула соединений кластера 1С и сеансов SQL Server. Проанализируем основные факторы, вызывающие этот сбой:
Зарегистрированная ошибка платформы: в некоторых релизах ветки 8.3 (в частности, в сборках 8.3.9 начиная с 8.3.9.1818, а также в ранних версиях 8.3.7) присутствовала внутренняя ошибка платформы (код 50010160), связанная с некорректным повторным использованием соединений из пула и преждевременной очисткой временных таблиц.
Особенности прикладного кода: массовое использование в запросах условий вида ГДЕ Поле В (&Массив) с передачей сотен или тысяч элементов заставляет платформу создавать неявные временные таблицы. При разрыве контекста эти объекты теряются.
Проблемы производительности tempdb: нехватка дискового пространства, задержки автоматического роста файлов базы данных (autogrow) или конкуренция за страницы распределения памяти (SGAM/PFS) при единственном файле данных tempdb.
Сетевой протокол Shared Memory: работа сервера 1С и MS SQL Server на одной физической машине через протокол разделяемой памяти иногда приводит к сбоям адресации пула сеансов.
Способ 1. Обновление или откат версии платформы 1С
Если сбой вызван багом в механизме пула соединений платформы, наиболее надежным решением является смена версии технологической платформы. Рассмотрим варианты действий:
Обновление до стабильного релиза: перейдем на релиз, в котором ошибка официально исправлена. В ветке 8.3.9 проблема была устранена в сборке 8.3.9.2170. Если используется более новая версия платформы (например, ветки 8.3.14, 8.3.20 и выше), необходимо установить актуальный стабильный релиз из соответствующей ветки.
Откат на стабильную ветку: если оперативное обновление конфигурации до актуальных требований платформы невозможно, выполним даунгрейд на предшествующую стабильную версию (например, возврат с проблемных сборок 8.3.9 на проверенную 8.3.8).
Способ 2. Очистка кэша и временных файлов
Нередко сбой провоцируется накоплением поврежденных метаданных во временных каталогах операционной системы и сеансов сервера. Выполним полную очистку кэша по следующим шагам:
Остановим службу Агент сервера 1С:Предприятия через консоль services.msc.
Очистим содержимое каталогов временных файлов операционной системы Windows на сервере приложений: C:\Windows\Temp и папку Temp в профиле пользователя, от имени которого запускается служба 1С (обычно C:\Users\USR1CV8\AppData\Local\Temp).
Удалим сеансовые кэши кластера в каталоге данных srvinfo (за исключением конфигурационных файлов кластера 1cv8wsrv.lst и файлов реестра).
Запустим службу сервера 1С и проверим стабильность работы.
Способ 3. Оптимизация системной базы tempdb на MS SQL Server
Рассмотрим комплекс настроек Microsoft SQL Server, предотвращающий блокировки и сбои при создании таблиц с префиксом #tt:
Разделение на несколько файлов данных: создадим в базе tempdb несколько файлов данных (.mdf и .ndf) одинакового размера. Количество файлов рекомендуется выбирать равным количеству физических процессорных ядер сервера, но не более 8 файлов. Это распределяет нагрузку на страницы памяти и устраняет взаимные блокировки.
Фиксированный начальный размер: зададим файлам достаточный начальный размер (например, от 10–20 Гб на каждый файл) с фиксированным шагом приращения (например, 512 Мб), исключив процентное авторасширение. Это защитит транзакции 1С от падений по таймауту во время расширения дискового файла.
Использование быстрого диска: перенесем файлы базы tempdb и ее журнала транзакций на высокоскоростной NVMe-накопитель.
Способ 4. Корректировка сетевых протоколов SQL Server
Разберем сетевую настройку, если сервер 1С и СУБД развернуты на одной операционной системе. По умолчанию клиент СУБД использует соединение Shared Memory, что в редких случаях рассинхронизирует потоки пула.
Откроем оснастку SQL Server Configuration Manager.
Перейдем в раздел SQL Server Network Configuration -> Protocols for [Имя_Экземпляра].
Отключим протокол Shared Memory, оставив включенным только TCP/IP.
В свойствах кластера 1С при указании имени сервера СУБД пропишем обращение через явный сетевой адрес (например, 127.0.0.1 или сетевое имя сервера).
Перезапустим службу SQL Server для применения изменений.
Способ 5. Оптимизация запросов и настроек кластера 1С
Если проблема возникает в конкретных документах или динамических списках конфигурации (например, в УТ 11 при контекстном поиске по строке), применим обходные программные и административные решения:
Настройка перезапуска рабочих процессов: в консоли администрирования кластера серверов 1С для рабочего сервера настроим интервал перезапуска процессов rphost (например, раз в сутки в нерабочее время) и лимит объема памяти на процесс. Это автоматически освобождает зависшие системные соединения пула.
Оптимизация передачи массивов в запросы: в проблемных алгоритмах заменим передачу огромных списков значений в условие В (&Массив) на предварительную запись данных в явную временную таблицу с ее обязательным ручным удалением в конце выполнения пакета:
// Пример корректного освобождения ресурсов временной таблицы
Уничтожить ВременнаяТаблицаДанных;
Ограничение глобального поиска: в журналах документов с миллионным объемом записей отключим полнотекстовый поиск в динамических списках, настроив для пользователей стандартные отборы по полям индексов (дата, контрагент, организация).