При работе с крупными прикладными решениями, такими как 1С:ERP Управление предприятием, специалисты часто сталкиваются с ситуацией, когда стандартная процедура обновления через Конфигуратор прерывается критической ошибкой СУБД. Сообщение Microsoft SQL Server Native Client 10.0: Внутренняя ошибка: был достигнут предел размера стека на сервере (код ошибки 8631) может поставить в тупик даже опытного администратора. Подобные кейсы нередко встречаются, когда проводится сложное обновление нетиповой конфигурации 1С:ERP УХ. В этой статье мы подробно разберем, почему возникает эта проблема, и проанализируем последовательность шагов для её гарантированного решения.
Ошибка 8631 в Microsoft SQL Server напрямую указывает на то, что оптимизатор запросов СУБД не смог построить план выполнения из-за чрезмерно сложного или глубоко вложенного запроса. В контексте 1С это происходит в тот момент, когда платформа пытается сопоставить изменения в метаданных (выполнить diff) и внести их в таблицу Config базы данных.
Проанализируем ситуацию: конфигурация ERP содержит десятки тысяч объектов. При попытке динамического обновления («обновления на лету») система генерирует гигантские SQL-запросы для проверки целостности и актуальности структуры. Если при этом используются устаревшие драйверы или серверный кэш заполнен некорректными данными, SQL Server просто «захлебывается», так как выделенный объем памяти под стек выполнения потока (обычно 2 МБ) исчерпывается.
Первое, что мы должны сделать, — это признать, что динамическое обновление для таких систем, как ERP, является крайне рискованной операцией. Рассмотрим подробнее, почему это так. При «демональном» обновлении платформа пытается подменить версию конфигурации без остановки сеансов пользователей. В этот момент в таблицах базы данных создается сложная иерархия временных записей. Для обеспечения безопасности процесса на высоконагруженных системах лучше применять методику «Обновление через копию», которая позволяет минимизировать время простоя основной базы.
Если вы получили ошибку стека, выполните следующие действия:
F7) с предварительной остановкой службы rphost или блокировкой соединений.Обратим внимание на текст ошибки в сообщении автора: Microsoft SQL Server Native Client 10.0. Этот драйвер соответствует SQL Server 2008 и давно устарел. Современные версии 1С:Предприятие 8.3 гораздо эффективнее работают с более новыми компонентами доступа к данным.
Выясним причину важности драйвера: старые версии Native Client имеют жесткие лимиты на работу с памятью и не всегда корректно транслируют сложные планы запросов, генерируемые платформой. Мы рекомендуем:
Native Client 11.0 или выше.Часто проблема кроется в «битом» кэше метаданных, который рабочий процесс rphost передает на сторону SQL Server. Рассмотрим, как правильно выполнить очистку, чтобы не повредить настройки кластера. В некоторых случаях, если система продолжает работать нестабильно после очистки, имеет смысл провести комплексный замер производительности контура 1С и поиск узких мест для выявления проблем в технологическом журнале.
C:\Program Files\1cv8\srvinfo).snccntxt и временные файлы внутри папок с идентификаторами баз (например, reg_1541). Внимание: не удаляйте файлы лицензий (.lic) и файлы конфигурации кластера (1cv8wsrv.lst).temp.Проанализируем ситуацию с точки зрения ресурсов СУБД. Ошибка стека часто возникает из-за попытки SQL Server распараллелить очень сложный запрос. Мы можем временно ограничить аппетиты сервера, чтобы он выполнил задачу в один поток, что значительно снизит нагрузку на стек.
Для этого выполните в среде SQL Server Management Studio (SSMS) следующий скрипт:
EXEC sys.sp_configure N'show advanced options', N'1';
RECONFIGURE;
EXEC sys.sp_configure N'max degree of parallelism', N'1';
RECONFIGURE;
Установка MAXDOP в значение 1 заставит сервер обрабатывать запрос последовательно. После успешного обновления конфигурации не забудьте вернуть это значение к исходному (обычно это 0 или количество ядер в одной NUMA-ноде), чтобы не снижать общую производительность системы.
Если конфигуратор «завис» и не позволяет совершить никаких действий, проанализируем состояние таблицы ConfigSave. В этой таблице хранятся изменения, которые еще не были приняты основной конфигурацией базы данных. Попробуем очистить её вручную (обязательно сделайте бэкап перед этой операцией!):
-- Проверка наличия «зависших» данных
SELECT * FROM ConfigSave;
-- Очистка таблицы, если обновление заблокировано
DELETE FROM ConfigSave;
После удаления записей из ConfigSave, платформа «забудет» о неудачной попытке динамического обновления, и вы сможете запустить процесс заново в нормальном режиме через F7. Если вы столкнулись с большим количеством изменений в объектах на поддержке, вам может пригодиться инструмент для группового изменения режима поддержки по подсистеме, чтобы избежать лишней рутины.
Чтобы исключить влияние старых планов запросов на процесс обновления, выполним принудительную очистку памяти SQL Server. Также стоит учитывать, что ошибки при обновлении могут быть вызваны некорректными запросами в самом коде. В этом случае полезно выполнить поиск «битых» запросов после обновления релиза, чтобы исключить обращения к несуществующим метаданным. Рассмотрим применение команды FREEPROCCACHE:
-- Очистка кэша планов запросов
DBCC FREEPROCCACHE;
-- Обновление статистики для всех таблиц базы данных
EXEC sp_updatestats;
Это заставит оптимизатор SQL Server пересчитать распределение данных и построить новый, возможно, менее глубокий план выполнения запроса, который впишется в текущие лимиты стека.
Мы проанализировали комплексную проблему и выяснили, что ошибка 8631 при обновлении 1С:ERP — это следствие совокупности факторов: огромного объема метаданных, использования динамического обновления и устаревших компонентов доступа к SQL. Для поддержания стабильности системы мы рекомендуем на регулярной основе проводить анализ конфигураций на наличие ошибок, связанных с вызовами экспортных процедур и функций.
Соблюдение регламента (использование MSOLEDBSQL, отказ от динамических обновлений на крупных базах и регулярная очистка кэша) позволит вам навсегда забыть об этой ошибке. Помните, что перед любыми манипуляциями с таблицами Config или ConfigSave создание резервной копии базы данных является обязательным условием успешной работы.