MS SQL Server под базы 1С 8.3: параметры, которые реально влияют на скорость

Чтобы SQL Server быстро работал с 1С, на уровне экземпляра достаточно трёх вещей: ограничить max server memory, поставить max degree of parallelism = 1 и включить мгновенную инициализацию файлов. Для каждой базы нужны три настройки: прирост файлов в мегабайтах (не в процентах), осознанно выбранная модель восстановления и ежедневное обновление статистики. Остальное — тонкая доводка.

Частое заблуждение — что SQL Server «съедает всю память, и это надо лечить перезагрузкой». Это не утечка. SQL Server так и задуман: он держит данные в кэше и сам ничего не отдаёт. Если не задать ему потолок, страдает сервер 1С на той же машине, а не сам SQL. Все советы относятся к платформе 1С:Предприятие 8.3 в клиент-серверном варианте и поддерживаемым версиям MS SQL Server.

Подготовка сервера перед установкой SQL Server для 1С

Самые дорогие ошибки делают ещё до первой базы. Потом их исправляют переустановкой или долгими переносами.

Что решить заранее:

• 💽 Диски. Файлы данных, журналы транзакций и tempdb лучше развести по разным томам. Минимум — отдельный SSD/NVMe под tempdb и журналы. Системный диск под базы не используйте.
• 🔤 Сортировка (collation) экземпляра. Для русскоязычных баз ставьте Cyrillic_General_CI_AS. Выбрать её нужно при установке: на готовом экземпляре сменить сортировку системных баз сложно.
• 👤 Учётная запись службы. Отдельная доменная или виртуальная учётная запись, а не администратор домена.
• ⚡ Схема электропитания Windows — «Высокая производительность». На схеме «Сбалансированная» процессор сбрасывает частоту, и короткие запросы 1С заметно замедляются.
• 🧮 Размер блока тома под файлы баз — 64 КБ при форматировании NTFS. Это штатная рекомендация для SQL Server.

Мгновенная инициализация файлов

Без неё каждый прирост файла данных обнуляется. При приросте в 1 ГБ база «замирает» на секунды. Включается правом Windows:

1. Откройте secpol.msc → Локальные политики → Назначение прав пользователя.
2. Найдите право «Выполнение задач по обслуживанию томов» (Perform volume maintenance tasks).
3. Добавьте учётную запись службы SQL Server.
4. Перезапустите службу SQL Server в нерабочее время.

Начиная с SQL Server 2016 это право можно выдать прямо в мастере установки — галочка на шаге выбора учётных записей служб.

Память и параллелизм экземпляра SQL Server

Ограничение памяти: max server memory

Оставьте операционной системе 4–6 ГБ. Если на той же машине работает сервер 1С, вычтите и его потребление: рабочие процессы rphost легко занимают 8–16 ГБ на средней базе.

Это ориентиры. Точное значение подбирают по счётчику свободной памяти ОС: в часы нагрузки свободными должны оставаться хотя бы 2–4 ГБ.

Параллелизм: MAXDOP

Запросы 1С короткие и многочисленные. Параллельные планы на такой нагрузке чаще вредят: одна выборка занимает все ядра, остальные пользователи ждут. Для баз 1С ставят max degree of parallelism = 1.

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
-- 40 ГБ для SQL Server, если рядом стоит сервер 1С на машине с 64 ГБ
EXEC sp_configure 'max server memory (MB)', 40960;
EXEC sp_configure 'max degree of parallelism', 1;
RECONFIGURE;

Оба параметра применяются сразу, без перезапуска службы.

💡 Если на экземпляре, кроме 1С, крутятся отчётные базы или хранилище, MAXDOP можно задать на уровне базы: ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 1; (SQL Server 2016 и новее). Тогда базы 1С получают единицу, а аналитика — параллелизм.

Блокировка страниц в памяти

Право «Блокировка страниц в памяти» (Lock pages in memory) для учётной записи службы не даёт Windows выталкивать буферный кэш SQL в файл подкачки. Выдаётся в том же secpol.msc. Включайте только вместе с ограничением max server memory. Без потолка SQL Server может забрать память так, что ОС начнёт задыхаться.

Параметры базы 1С: файлы, журнал, tempdb

Базу создаёт сама платформа — из консоли кластера или при добавлении информационной базы с флагом «Создать базу данных в случае её отсутствия». Параметры файлов при этом берутся из системной базы model. Удобно один раз настроить model, и новые базы 1С получат правильные значения автоматически.

Модель восстановления

Модель FULL без настроенного резервного копирования журнала — главная причина распухших .ldf размером в сотни гигабайт.

Прирост файлов

Процентный прирост на большой базе даёт непредсказуемые паузы. Ставьте фиксированные значения: данные — 512–1024 МБ, журнал — 256–512 МБ. Логические имена файлов посмотрите запросом, они совпадают не всегда:

USE [buh];
SELECT name, type_desc, size/128 AS size_mb, growth, is_percent_growth
FROM sys.database_files;

ALTER DATABASE [buh] MODIFY FILE (NAME = N'buh', FILEGROWTH = 1024MB);
ALTER DATABASE [buh] MODIFY FILE (NAME = N'buh_log', FILEGROWTH = 512MB);

Параметры AUTO_SHRINK и AUTO_CLOSE должны быть выключены. Автосжатие дробит индексы, а потом файл всё равно растёт заново.

tempdb

1С активно пользуется временными таблицами. Узкое место tempdb проявляется ожиданиями на страницах распределения. Правило: число файлов данных tempdb равно числу ядер, но не больше 8; все файлы одного размера и с одинаковым приростом. Начиная с SQL Server 2016 мастер установки предлагает это сам. На старых экземплярах файлы добавляют вручную через свойства tempdb в Management Studio.

Обслуживание индексов и статистики баз 1С

Платформа создаёт индексы сама по структуре конфигурации. Добавлять свои индексы в таблицы базы 1С нельзя: при обновлении конфигурации платформа их удалит или запнётся о них. Ваша задача — держать существующие индексы и статистику в порядке.

Статистика — каждый день

Устаревшая статистика — частая причина ситуации «вчера отчёт строился минуту, сегодня час». Оптимизатор выбирает план по неверной оценке числа строк.

• AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS — включены (так по умолчанию).
• Ежедневно ночью — задача «Обновление статистики» в плане обслуживания или команда sp_updatestats.
• Раз в неделю — обновление с полным сканированием (FULLSCAN) для крупных таблиц регистров.

USE [buh];
EXEC sp_updatestats;

После обновления статистики часть администраторов очищает кэш планов (DBCC FREEPROCCACHE), чтобы запросы сразу перекомпилировались. Команда без параметров чистит кэш всего экземпляра, поэтому запускайте её только ночью: первые минуты после очистки всё будет работать медленнее.

Индексы — раз в неделю

Ориентир по фрагментации: до 5–10% — не трогать, 10–30% — REORGANIZE, больше 30% — REBUILD. Маленькие индексы (до 1000 страниц) не обслуживают: на них фрагментация ни на что не влияет.

USE [buh];
SELECT OBJECT_NAME(s.object_id) AS table_name, i.name AS index_name,
       s.avg_fragmentation_in_percent, s.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') AS s
JOIN sys.indexes AS i ON i.object_id = s.object_id AND i.index_id = s.index_id
WHERE s.avg_fragmentation_in_percent > 30 AND s.page_count > 1000
ORDER BY s.avg_fragmentation_in_percent DESC;

Порядок ночных заданий: резервная копия → индексы → статистика. Если перестроение индекса уже выполнено через REBUILD, статистика этого индекса обновлена полным сканированием, и sp_updatestats её не испортит.

Блокировки и изоляция транзакций в связке 1С и SQL Server

Как будут ставиться блокировки, определяет свойство конфигурации «Режим управления блокировкой данных»: Автоматический, Управляемый или Автоматический и управляемый. Типовые конфигурации актуальных версий (БП 3.0, ЗУП 3.1, УТ 11, ERP) работают в управляемом режиме.

Что это значит на практике:

• 🔒 Управляемый режим. Логические блокировки ставит менеджер блокировок 1С. На стороне SQL Server платформа 8.3 использует для базы режим READ_COMMITTED_SNAPSHOT: чтение не ждёт записи, версии строк хранятся в tempdb. Это ещё одна причина держать tempdb на быстром диске.
• 🔐 Автоматический режим. Блокировки ставит сам SQL Server, уровни изоляции жёстче. Здесь чаще возникают ожидания и взаимоблокировки на уровне СУБД.

Проверить, что база работает в нужном режиме:

SELECT name, recovery_model_desc, is_read_committed_snapshot_on
FROM sys.databases
WHERE name = N'buh';

Режим READ_COMMITTED_SNAPSHOT не включайте и не выключайте руками на рабочей базе 1С: платформа управляет им сама.

Эскалация блокировок

Когда одна транзакция набирает около 5000 блокировок строк на объекте, SQL Server пытается заменить их одной блокировкой таблицы. При больших проведениях (закрытие месяца , перепроведение) это парализует работу остальных. Включать флаг трассировки 1224, который ограничивает эскалацию, стоит только после того, как мониторинг подтвердил, что проблема именно в ней.

Типичное сообщение пользователю при конфликте управляемых блокировок: Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки. Это таймаут менеджера блокировок 1С, а не SQL Server. Искать причину нужно в технологическом журнале 1С (см. раздел про мониторинг).

Сеть и протоколы между сервером 1С и SQL Server

Сервер 1С обращается к SQL Server на каждый запрос. Задержка сети умножается на тысячи обращений при проведении документа, поэтому сеть здесь важнее, чем между пользователем и сервером 1С.

1. Откройте SQL Server Configuration Manager → Сетевая конфигурация SQL Server → протоколы экземпляра.
2. Включите TCP/IP. Named Pipes для 1С не нужен — выключите.
3. Shared Memory оставьте включённым: если сервер 1С и SQL Server стоят на одной машине, соединение идёт через общую память, без сетевого стека.
4. Для экземпляра по умолчанию порт — 1433. Для именованного экземпляра задайте статический порт в свойствах TCP/IP → IP-адреса → IPAll, иначе он будет меняться при перезапуске.
5. Откройте выбранный порт в брандмауэре Windows только для адреса сервера 1С.
6. Перезапустите службу SQL Server (в нерабочее время — сеансы оборвутся).

Требования к самой сети:

• 🌐 Сервер 1С и SQL Server в одном сегменте, без маршрутизаторов и VPN между ними.
• 📶 Канал 10 Гбит/с, если серверы разнесены. Время отклика ping между ними — доли миллисекунды.
• 🧱 Антивирус: исключите из проверки каталоги с файлами .mdf, .ldf, .ndf и процесс sqlservr.exe. Проверка файлов баз на лету — частая скрытая причина тормозов.

Мониторинг производительности и диагностика

Настроить и забыть не получится. Нагрузка растёт, данные копятся, и раз в квартал стоит заглядывать в цифры.

Что смотреть на стороне SQL Server

Кто кого сейчас блокирует:

SELECT session_id, blocking_session_id, wait_type, wait_time, command,
       DB_NAME(database_id) AS db
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Взаимоблокировки SQL Server пишет в стандартный сеанс расширенных событий system_health (событие xml_deadlock_report). Его можно открыть в Management Studio: Управление → Расширенные события → Сеансы.

Что смотреть на стороне 1С

Технологический журнал включается файлом logcfg.xml в каталоге conf платформы на сервере 1С. Для разбора блокировок достаточно событий TLOCK, TTIMEOUT и TDEADLOCK:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog" history="24">
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="all"/>
  </log>
</config>

💡 Журнал с property name="all" быстро растёт. Ставьте его на отдельный диск, собирайте за конкретный период проблемы и отключайте после разбора.

Частые ошибки настройки SQL Server под 1С

• ❌ Сжатие базы по расписанию. DBCC SHRINKDATABASE в плане обслуживания фрагментирует индексы и на следующий день съедает выигрыш. Сжимают только разово, после удаления большого объёма данных.
• ❌ Express Edition под рабочую базу. У Express ограничение 10 ГБ на базу и урезанный буферный кэш. Для учебной базы годится, для бухгалтерии на 20 пользователей — нет.
• ❌ Свои индексы в таблицах 1С. Их снесёт ближайшее обновление конфигурации . Нужен индекс — включите свойство «Индексировать» у реквизита в конфигураторе.
• ❌ NOLOCK и правка данных запросами в обход платформы. Прямые UPDATE в таблицах 1С ломают целостность итогов регистров, и потом базу приходится долго тестировать и исправлять.
• ❌ Один диск на всё. Данные, журнал, tempdb и резервные копии на одном томе дают очереди к диску в часы закрытия месяца.

Частые вопросы