При работе со связкой 1С 7.7 и SQL Server 2005 (особенно в 64-битной редакции на современных операционных системах) администраторы часто сталкиваются с критической проблемой: во время тяжелых операций, таких как массовое перепроведение документов или запуск процедуры _1sp_DBReindex, сервер «зависает». При этом наблюдается специфическая картина: загрузка процессора (CPU) держится на максимально высоком уровне, а активность дисковой подсистемы практически отсутствует. В таком состоянии процесс может находиться часами, не завершаясь самостоятельно.
В этой статье мы подробно разберем, почему возникают такие «зацикливания», как правильно настроить серверную среду и какие регламентные действия помогут вернуть базе стабильность.
Ситуация, когда процессор занят на 100%, а диски «молчат», в контексте SQL Server почти всегда означает, что оптимизатор запросов выбрал крайне неэффективный план выполнения. Процессор бесконечно перебирает строки в оперативной памяти (например, используя алгоритм Nested Loops вместо более быстрого соединения), пытаясь сопоставить данные. Для 1С 7.7, которая генерирует запросы старого типа, это частое явление на новых версиях SQL Server.
Рассмотрим пошагово методы решения этой проблемы.
Одной из самых частых причин «фризов» в 1С 7.7 является попытка SQL Server распараллелить выполнение одного запроса на несколько ядер процессора. Платформа 7.7 не умеет эффективно работать с параллельными планами, что приводит к взаимным блокировкам и деградации производительности.
Проанализируем настройку Max Degree of Parallelism. Нам необходимо принудительно ограничить выполнение каждого отдельного запроса одним потоком. Для этого выполним следующий скрипт в SQL Server Management Studio:
EXEC sys.sp_configure N'show advanced options', N'1';
RECONFIGURE WITH OVERRIDE;
EXEC sys.sp_configure N'max degree of parallelism', N'1';
RECONFIGURE WITH OVERRIDE;
Установка значения 1 гарантирует, что SQL Server не будет пытаться «разрезать» запрос к базе на части. Как показывает практика, это действие в 90% случаев устраняет зависания при проведении документов и индексации.
Если индексы повреждены или статистика распределения данных устарела, оптимизатор будет строить ошибочные планы. Перед тем как пытаться делать глубокую реиндексацию, выполним проверку базы данных командой DBCC CHECKDB. Это позволит выяснить, нет ли в базе логических или физических повреждений страниц.
Затем перейдем к обновлению статистики. Процедура _1sp_DBReindex, встроенная в 1С 7.7, в некоторых случаях на SQL 2005/2008 отрабатывает некорректно, не обновляя статистику должным образом. Мы можем запустить полное обновление статистики вручную для всей базы:
EXEC sp_updatestats;
Для более глубокой проработки конкретных «тяжелых» таблиц (например, таблиц итогов или регистров) рекомендуется использовать команду с полным сканированием:
UPDATE STATISTICS [НазваниеТаблицы] WITH FULLSCAN;
Если ваш сервер SQL Server 2005 развернут на виртуалке Hyper-V под управлением Windows Server 2012 R2, следует обратить внимание на распределение ресурсов. SQL Server 2005 официально не проектировался под современные гипервизоры, поэтому выясним два важных нюанса:
Dynamic Memory для SQL Server — плохая практика. Старые версии SQL могут неверно определять доступный объем памяти при его изменении гипервизором «на лету», что ведет к нехватке ресурсов или утечкам. Установите статический объем оперативной памяти (в вашем случае 12GB будет достаточно).1С 7.7.Разберем ситуацию с системным журналом 1С. Таблица _1syslog может разрастаться до огромных размеров. Если в базе скопились миллионы записей журнала регистрации за несколько лет, любая операция реиндексации будет спотыкаться об эту таблицу. Если история старых событий не критична, очистите журнал средствами 1С или напрямую через SQL (предварительно сделав бэкап).
Также проанализируем состояние TempDB. При выполнении EXEC _1sp_DBReindex активно используется временная база данных. Если она расположена на медленном диске или имеет слишком маленький размер авторасширения, это создаст «бутылочное горлышко».
Рекомендации по TempDB:
TempDB на отдельный быстрый диск (SSD/NVMe).TempDB хотя бы в 2-4 ГБ, чтобы сервер не тратил время на расширение файла во время работы.В ходе обсуждения было замечено, что SQL Server 2008 работает медленнее 2005-го на 50%. Рассмотрим, почему это происходит. В версии 2008 был изменен механизм Parameter Sniffing — сервер кэширует план запроса на основе первого переданного параметра. Для 1С 7.7, где запросы часто строятся динамически, это приводит к тому, что план, эффективный для выборки за один день, применяется к выборке за год, вызывая катастрофическое замедление.
Если вы планируете переход на более новые версии (2012, 2014, 2017), помните, что для работы 1С 7.7 с ними потребуются дополнительные манипуляции:
BkEnd.dll (существуют решения от сообщества, позволяющие 7.7 корректно распознавать версии SQL старше 2005).4199 для исправления работы оптимизатора).sp_dboption), которые были удалены в новых версиях SQL Server.Для решения вашей проблемы мы рекомендуем выполнить действия в следующем порядке:
MAXDOP = 1.Hyper-V (откажитесь от динамической).UPDATE STATISTICS для всей базы.Эти шаги позволят минимизировать влияние устаревших алгоритмов 1С 7.7 на современные механизмы SQL Server и обеспечат стабильную работу системы без «мертвых» зависаний процессора.