Перевод исторически сложившихся систем на базе 1С 7.7 (например, конфигурации «Торговля и Склад») с файлового режима (DBF) на SQL Server — это ответственный шаг, который часто сопровождается неожиданным падением производительности. Ситуация, когда база в терминальном режиме на 40+ пользователей начинает «тормозить» при групповом проведении или загрузке процессора, требует комплексного подхода: от системного администрирования до глубокого рефакторинга кода. В данной статье мы разберем по шагам, как заставить 1С 7.7 «взлететь» на SQL-движке.
Проанализируем типичную ситуацию: 1С и SQL Server установлены на одном сервере. Без должной настройки SQL Server по умолчанию попытается занять всю доступную оперативную память под свой кэш (Buffer Pool), что приведет к дефициту ресурсов для терминальных сессий пользователей. Рассмотрим необходимые настройки:
MaxDOP крайне рекомендуется установить в значение 1. Движок 7-й версии генерирует запросы, которые плохо распараллеливаются, что часто приводит к взаимным блокировкам (deadlocks) и замедлению простых операций с регистрами.Shared Memory. Это исключает сетевые задержки при передаче данных внутри одной машины.Выясним причину, почему в режиме DBF документы могут проводиться быстрее, чем на SQL. Основная проблема кроется в объектной модели 1С 7.7. Когда мы используем стандартные методы работы с регистрами в цикле, 1С генерирует огромное количество мелких запросов к SQL-серверу. Разберем на примере метода ВыгрузитьИтоги.
Рассмотрим неоптимальный код, который часто встречается в типовых конфигурациях:
ТаблНоменклатуры.ВыбратьСтроки();
Пока ТаблНоменклатуры.ПолучитьСтроку()=1 Цикл
Номенклатура = ТаблНоменклатуры.Номенклатура;
// Ошибка: Вызов метода внутри цикла по каждой строке документа
ВремПартии.ВыгрузитьИтоги(ТаблИтогов, 1, 1);
// Обработка данных...
КонецЦикла;
Под SQL такой подход работает крайне медленно, так как каждый вызов ВыгрузитьИтоги инициирует отдельное обращение к базе данных. Проанализируем, как сделать правильно. Нам нужно минимизировать количество обращений к серверу БД:
// Правильно: сначала подготавливаем список всей номенклатуры документа
СписокТоваров = СоздатьОбъект("СписокЗначений");
ТаблНоменклатуры.Выгрузить(СписокТоваров, , , "Номенклатура");
// Устанавливаем фильтр по всему списку сразу
ВремПартии.УстановитьФильтр(СписокТоваров);
// Делаем ОДИН вызов ВыгрузитьИтоги для получения всех остатков разом
ВремПартии.ВыгрузитьИтоги(ОбщаяТаблИтогов, 1, 1);
// Далее работаем уже с локальной таблицей значений в памяти
ТаблНоменклатуры.ВыбратьСтроки();
Пока ТаблНоменклатуры.ПолучитьСтроку()=1 Цикл
// Ищем данные в ОбщаяТаблИтогов вместо запроса к базе
КонецЦикла;
Такая переработка кода в модулях проведения (особенно в процедуре глСписаниеПартий) дает прирост скорости в десятки раз.
SQL-версия 1С 7.7 чувствительна к состоянию таблиц итогов. Если в регистрах накоплено много записей с нулевыми остатками, но ненулевыми суммами (так называемые «копейки»), производительность резко падает. SQL-серверу приходится перебирать тысячи «пустых» записей для расчета актуальных остатков.
Рекомендации по обслуживанию:
tempdb на самый быстрый доступный SSD-диск. 1С 7.7 активно использует временные таблицы, и скорость tempdb напрямую влияет на скорость проведения документов.Если система «тормозит», важно точно определить место затыка. В терминальном режиме на Windows Server 2008/2012 отладчик 1С 7.7 может вести себя некорректно (терять фокус или «замирать»).
Проанализируем полезный лайфхак от опытных администраторов: если отладчик не возвращает управление или ведет себя странно, попробуйте убить процесс dwm.exe (Desktop Window Manager) в диспетчере задач. Часто это приходится делать дважды, чтобы графическая оболочка перестала конфликтовать со старым интерфейсом отладчика 7.7. Это позволит вам комфортно использовать Замер производительности.
При использовании замера производительности обязательно снимите галочку «для вызовов процедур и функций». Это позволит увидеть реальное время выполнения встроенных методов, таких как Провести() или ВыгрузитьИтоги(), которые являются основными потребителями времени в SQL-версии.
Если стандартными средствами добиться нужной скорости не удается (база превышает 50–100 ГБ, активных пользователей больше 50), единственным выходом остается использование прямых запросов. С помощью внешней компоненты 1С++ программист может писать запросы на чистом T-SQL.
Вместо того чтобы ждать, пока объект Запрос в 1С проанализирует метаданные и сформирует тяжелый SQL-код, мы можем напрямую обратиться к таблицам RG* (итоги) и RA* (движения). Это позволяет формировать отчеты, которые раньше строились минутами, за доли секунды. Также через прямые запросы можно оптимизировать тяжелые регламентные операции и очистку таблицы регистрации изменений (1SUPDTS) при работе с распределенными базами данных (УРБД).
Резюме: Переход 1С 7.7 на SQL — это не просто «нажатие кнопки». Это процесс, требующий настройки лимитов памяти сервера, пересмотра логики циклов в проведении документов и регулярного обслуживания базы данных. При соблюдении этих правил система способна стабильно работать даже с очень большими объемами данных.