Почему тормозит 1С 7.7 на SQL 2008 R2 и как восстановить производительность базы данных

Работа связки 1С 7.7 и MS SQL Server 2008 R2 часто сопровождается внезапными «тупняками»: операции, занимавшие секунды, начинают длиться минутами, а процесс sqlserver.exe потребляет 100% мощности одного или нескольких ядер процессора. В этой статье мы подробно разберем, почему возникают такие задержки, как правильно настроить регламентные задания и что нужно изменить в настройках сервера для стабильной работы.

Анализируем причину: проблема планов запросов и статистики

Основная причина резкого замедления работы — выбор SQL-сервером неоптимального плана выполнения запроса. Это часто связано с тем, что статистика распределения данных устаревает или обновляется некорректно в режиме совместимости 80 (SQL 2000). Проанализируем ситуацию: когда вы нажимаете кнопку «Найти» в журнале или проводите документ, 1С формирует запрос, который в нормальном состоянии использует индекс. Однако из-за неверной статистики сервер может решить, что быстрее будет просканировать всю таблицу целиком (Index Scan вместо Index Seek).

Рассмотрим порядок действий для исправления ситуации:

1. Обновление статистики с полным сканированием. Стандартное автоматическое обновление может использовать слишком малую выборку данных.
2. Очистка процедурного кэша. После обновления статистики старые «плохие» планы запросов могут оставаться в памяти. Нужно их принудительно сбросить.
3. Переход в нативный режим совместимости. Работа в режиме 80 на сервере 2008 R2 заставляет оптимизатор использовать устаревшие алгоритмы.

Переход на режим совместимости 100 (SQL 2008)

Многие администраторы боятся повышать уровень совместимости базы (Compatibility Level) до 100, опасаясь краха 1С. Действительно, при простом переключении 1С может закрываться с ошибкой. Выясним причину: чаще всего это происходит из-за использования старых версий внешних компонент, таких как vk_hook1c.dll.

Разберем шаги по безопасному переходу:

1. Отключите или обновите компоненты, перехватывающие обращения к базе (например, vk_hook).
2. Убедитесь, что используете «секретный релиз» или патченную BkEnd.dll (версии 1.0.0.7 и выше), которая корректно работает с современными версиями SQL.
3. В SQL Server Management Studio выполните команду повышения уровня совместимости:
   Скопировать код

   
   ALTER DATABASE [ВашаБаза] SET COMPATIBILITY_LEVEL = 100;
   GO
   

4. После этого обязательно зайдите в Конфигуратор и выполните любое изменение (например, добавьте и удалите реквизит), чтобы обновился файл .dds.

Оптимизация регламентных заданий SQL

Посмотрим на типичную ошибку: выполнение реиндексации и обновления статистики в одном задании без очистки кэша. Проанализируем правильный регламент, который должен выполняться ежедневно в часы минимальной нагрузки:

1. Реорганизация или перестроение индексов (Rebuild Index).
2. Обновление статистики с параметром FULLSCAN.
3. Очистка кэша планов выполнения (FREEPROCCACHE).

Для автоматизации этого процесса создадим T-SQL шаг в плане обслуживания:

-- Обновление статистики для всей базы с полным сканированием
EXEC sp_updatestats;
-- Или более жесткий вариант для конкретных таблиц:
UPDATE STATISTICS [RG9898] WITH FULLSCAN;
GO
-- Очистка кэша планов, чтобы SQL построил их заново на основе свежей статистики
DBCC FREEPROCCACHE;
GO

Использование сжатия данных (Data Compression)

Если ваша база данных разрослась до значительных размеров, а дисковая подсистема показывает низкую скорость (как в случае с 27-28 МБ/сек на LDF-массиве), стоит включить сжатие страниц. Это доступно в редакции Enterprise. Сжатие позволяет SQL-серверу хранить больше данных в оперативной памяти и тратить меньше времени на ввод-вывод.

Разберем пример кода для массового включения сжатия всех таблиц и индексов базы:

-- Сжатие всех таблиц
EXEC sp_MSforeachtable 'ALTER TABLE ? REBUILD WITH (DATA_COMPRESSION = PAGE)';
-- Сжатие всех индексов
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)';

Важно: этот процесс может занять несколько часов и требует монопольного доступа к таблицам, поэтому выполняйте его только в технологическое окно.

Настройка TempDB и серверных параметров

Проанализируем монитор ресурсов: если вы видите высокую активность FETCH_API_CURSOR, это значит, что 1С активно использует курсоры через TempDB. Чтобы ускорить этот процесс, выполним следующие настройки:

1. Разделение TempDB. Создайте несколько файлов данных для TempDB (по числу ядер процессора, но не более 8). Установите им одинаковый начальный размер и фиксированный шаг прироста.
2. Максимальная степень параллелизма (MAXDOP). Для 1С 7.7 рекомендуется установить MAXDOP = 1, чтобы один тяжелый запрос не парализовал работу всего сервера.
3. Память. Ограничьте Max Server Memory так, чтобы операционной системе оставалось минимум 4 ГБ, иначе SQL Server может вытеснить системный кэш, что приведет к тормозам самой ОС.

Работа с блокировками и транзакциями

При переходе на новые версии SQL часто встает вопрос загрузки ядра на 100% при ожидании блокировки таблицы. Выясним причину: в штатном режиме 1С 7.7 использует «активное ожидание». Если вы отказались от компонент типа vk_hook, используйте программные методы минимизации блокировок:

• Проанализируйте запросы ВыбратьПодчиненныеДокументы. В SQL 2008 они могут работать медленно, если не указан жесткий период (начальная и конечная даты).
• Проверьте регистры накопления. Если в них включен «отбор движений» по измерениям, которые имеют низкую селективность (мало уникальных значений), это может путать оптимизатор.
• Сокращайте время нахождения внутри транзакции. Все расчеты делайте ДО вызова метода Записать() или начала транзакции.

Соблюдение этих рекомендаций позволит стабилизировать работу 1С 7.7 на современном оборудовании и избежать еженедельных перезагрузок сервера.