Как настроить SQL Server для работы с 1С

Связка «1С:Предприятие + Microsoft SQL Server» — стандарт для средних и крупных внедрений, где файловый режим уже не справляется с нагрузкой. Однако SQL Server «из коробки» настроен под универсальные сценарии, а 1С предъявляет специфические требования: активная работа с tempdb, интенсивные блокировки, специфические параметры базы. Без корректной настройки пользователи получают медленные проведения документов, блокировки и ошибки превышения времени ожидания.

Ниже описан практический порядок настройки: от подготовки сервера до проверки результата. Инструкция подходит для SQL Server 2016 и новее в связке с платформой 1С 8.3. Все действия выполняются администратором с правами sysadmin на экземпляре SQL Server и доступом к консоли управления сервером 1С.

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

Выбор выпуска SQL Server и подготовка сервера

1С официально работает с редакциями Standard и Enterprise. Express-выпуск формально запускается, но ограничение на размер базы (около 10 ГБ) и объём памяти делает его пригодным только для крошечных внедрений и тестов. Для рабочей базы с десятками пользователей берите Standard; Enterprise нужен, когда требуются онлайн-перестроение индексов, сжатие данных или Always On.

Сервер приложений 1С и SQL Server можно размещать на одной машине только в небольших установках. Оптимальная схема — два отдельных сервера (физических или виртуальных), связанных сетью не медленнее 1 Гбит/с. Дисковая подсистема критична: файлы данных и журнал транзакций размещайте на разных физических дисках или RAID-массивах, tempdb — на самом быстром доступном массиве, в идеале SSD/NVMe.

Установите актуальное накопительное обновление (CU) для вашей версии SQL Server — в них исправляются ошибки планировщика и оптимизатора, напрямую влияющие на производительность 1С. Русскую или английскую локаль сервера выбирайте любую, но collation экземпляра для русскоязычных баз 1С должен быть Cyrillic_General_CI_AS — его задают при установке, изменить потом можно только пересозданием системных баз.

Настройка памяти и параметров экземпляра

По умолчанию SQL Server считает, что может занять всю память сервера (max server memory = 2147483647 МБ). На выделенном сервере это приводит к нехватке памяти у операционной системы и свопингу. Задайте ограничение: оставьте ОС минимум 4–8 ГБ, а если на той же машине работает сервер 1С — выделите под него ещё отдельный объём в зависимости от числа сеансов.

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 24576;
RECONFIGURE;

Значение 24576 МБ — пример для сервера с 32 ГБ ОЗУ; подставьте свою цифру. Параметр max degree of parallelism для 1С обычно устанавливают равным числу физических ядер одного процессора, но не более 8, а cost threshold for parallelism поднимают со стандартных 5 до 50 и выше — это отсекает распараллеливание мелких запросов, которое на типовых базах 1С даёт обратный эффект.

Параметр optimize for ad hoc workloads полезно включить: типовые конфигурации генерируют много одноразовых запросов, и кэш планов без этой настройки раздувается мусорными планами. Также убедитесь, что учётная запись службы SQL Server имеет привилегию «Lock pages in memory» (на серверных ОС) и «Perform volume maintenance tasks» — последняя ускоряет мгновенную инициализацию файлов данных при росте базы.

1. 1
   Определите общий объём ОЗУ сервера и потребности ОС и других служб
2. 2
   Задайте max server memory через SSMS: Свойства сервера → Память
3. 3
   Включите show advanced options и настройте max degree of parallelism и cost threshold for parallelism
4. 4
   Включите optimize for ad hoc workloads
5. 5
   Выдайте службе SQL Server привилегии Lock pages in memory и Perform volume maintenance tasks через secpol.msc, перезапустите службу

Настройка tempdb — критичный шаг для 1С

1С интенсивно использует временные таблицы: менеджеры временных таблиц, виртуальные таблицы регистров, группировки больших выборок. Поэтому tempdb становится узким местом раньше всего остального. Правило из практики: создайте несколько файлов данных tempdb равного размера — ориентир от 4 до 8 файлов, число не должно превышать количество логических процессоров (при более чем 8 ядрах начинайте с 8 и увеличивайте только при видимой конкуренции за страницы PFS/SGAM).

Все файлы tempdb должны быть одинакового размера с одинаковым приращением — иначе пропорциональное распределение работает неравномерно. Начальный размер задайте с запасом (например, по 1–2 ГБ на файл для средней базы), чтобы избежать частых автоприращений в часы пик. Разместите tempdb на быстром диске отдельно от файлов рабочих баз.

ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, SIZE = 2048MB, FILEGROWTH = 512MB);
ALTER DATABASE tempdb ADD FILE (NAME = tempdb2, FILENAME = 'D:\SQLData\tempdb2.ndf', SIZE = 2048MB, FILEGROWTH = 512MB);

Начиная с SQL Server 2016 многие рекомендуемые ранее флаги трассировки для tempdb (1117, 1118) включены по умолчанию и отдельной настройки не требуют. После изменения состава файлов перезапустите службу SQL Server — tempdb пересоздаётся при каждом старте.

Создание базы и параметры уровня базы данных

Базу для 1С создавайте не вручную в SSMS, а через консоль кластера серверов 1С или конфигуратор — платформа сама задаст обязательные параметры. Если база создаётся скриптом, проверьте обязательные настройки: параметр базы «Смещение дат» (date offset) 2000, включённые AUTO_CREATE_STATISTICS и AUTO_UPDATE_STATISTICS, и желательно AUTO_UPDATE_STATISTICS_ASYNC — он позволяет не ждать пересчёта статистики внутри пользовательского запроса.

Модель восстановления выбирайте осознанно. Простая (Simple) подходит большинству баз 1С: журнал транзакций не растёт бесконтрольно, обслуживание минимально, но восстановление возможно только на момент последней резервной копии. Полная (Full) нужна, когда требуется восстановление на произвольный момент времени — но тогда обязателен регламентный бэкап журнала, иначе файл журнала вырастет до заполнения диска.

Отдельно проверьте режим управления блокировками в свойствах информационной базы (конфигуратор → Администрирование → Параметры информационной базы). Современные конфигурации рассчитаны на управляемый режим; автоматический режим на нагруженной базе приводит к эскалациям блокировок уровня таблицы и массовым взаимоблокировкам.

Учётные записи, права и сеть

Службу SQL Server запускайте под выделенной учётной записью (gMSA или доменной), а не под SYSTEM — это и безопаснее, и упрощает доступ к сетевым ресурсам для бэкапов. Учётной записи сервера 1С (под которой работает агент) нужны права на создание баз в экземпляре: роль dbcreator и processadmin, либо права, выдаваемые при создании базы через консоль кластера.

Аутентификацию включайте смешанную (SQL Server and Windows Authentication), если планируете подключение по логину/паролю SQL, или оставьте Windows-аутентификацию — она предпочтительнее в домене. В свойствах информационной базы 1С указывается пользователь, от имени которого платформа подключается к SQL Server; этому пользователю достаточно роли db_owner на конкретную базу, давать sysadmin не нужно.

По сети: убедитесь, что включён протокол TCP/IP в SQL Server Configuration Manager, порт 1433 (или ваш статический порт) открыт в брандмауэре, а между сервером 1С и SQL Server нет фильтрующих устройств с агрессивными таймаутами простоя — обрыв «молчащих» соединений проявляется в 1С как внезапные разрывы сеансов.

Регламентное обслуживание и мониторинг

Без регулярного обслуживания даже правильно настроенный сервер деградирует за месяцы. Минимальный набор регламентных заданий: еженедельная перестройка или реорганизация индексов (в зависимости от степени фрагментации), ежедневное обновление статистики с полным сканированием для ключевых таблиц, ежедневный полный бэкап и, при полной модели восстановления, бэкап журнала каждые 15–60 минут.

Окно обслуживания планируйте на время минимальной нагрузки. Перестройка индексов на редакции Standard — офлайн-операция, во время неё таблицы блокируются; на больших базах это может занять часы, поэтому перестраивайте выборочно, по фактической фрагментации (sys.dm_db_index_physical_stats), а не всю базу подряд.

Для диагностики проблем используйте технологический журнал 1С (события TLOCK, TTIMEOUT, TDEADLOCK) в связке с динамическими представлениями SQL Server: sys.dm_os_wait_stats покажет преобладающие ожидания, sys.dm_exec_query_stats — самые тяжёлые запросы. Доминирование ожиданий PAGEIOLATCH указывает на диски или нехватку памяти, LCK_* — на проблемы блокировок, PAGELATCH на tempdb — на нехватку файлов tempdb.

Контрольные точки

Как проверить результат

Использование памяти сервером

Норма

SQL Server занимает заданный max server memory, у ОС остаётся свободной не менее нескольких ГБ

Тревожный признак

Доступная память ОС стремится к нулю, растёт файл подкачки

Размер журнала транзакций

Норма

При простой модели — стабильный небольшой размер; при полной — контролируемый рост между бэкапами журнала

Тревожный признак

LDF-файл растёт непрерывно и занимает десятки гигабайт

Блокировки в часы пик

Норма

Единичные кратковременные ожидания, нет жалоб пользователей

Тревожный признак

Цепочки блокировок, ошибки превышения времени ожидания в 1С

Файлы tempdb

Норма

Несколько файлов равного размера, равномерно заполненных

Тревожный признак

Один файл или сильный перекос размеров

Проверка производительности после настройки

После применения настроек дайте системе поработать под реальной нагрузкой минимум несколько дней — синтетические тесты сразу после перезапуска малоинформативны из-за холодного кэша. Базовый ориентир — эталонный тест Гилёва или аналогичная прикладная проверка, но важнее прикладные метрики: время проведения типового документа, скорость формирования ключевых отчётов, отсутствие таймаутов в технологическом журнале.

Сравнивайте метрики «до» и «после» в одинаковые периоды нагрузки — утро понедельника и тихий вечер пятницы не сопоставимы. Если после настройки узкое место осталось, дальнейший анализ обычно уходит в плоскость конкретных запросов и индексов под вашу конфигурацию — это уже работа с планами запросов и, возможно, доработка кода, а не параметров сервера.

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

Можно ли ставить SQL Server и сервер 1С на одну машину?

Можно для небольших внедрений с десятком-двумя пользователями, но тогда обязательно жёстко ограничьте max server memory, оставив память серверу 1С и ОС. При росте нагрузки разнесение на два сервера даёт более предсказуемую производительность и упрощает диагностику.

Какую модель восстановления выбрать для базы 1С?

Если допустима потеря данных за период с последнего бэкапа (обычно до суток) — простую (Simple): она проще в обслуживании и не требует управления журналом. Если нужно восстановление на произвольный момент времени — полную (Full), но только вместе с регулярными бэкапами журнала транзакций.

Сколько файлов tempdb нужно создать?

Практический ориентир — от 4 до 8 файлов равного размера, но не больше числа логических процессоров сервера. Увеличивать сверх 8 имеет смысл только если мониторинг ожиданий (PAGELATCH на страницах PFS/SGAM) показывает сохраняющуюся конкуренцию.

Нужно ли включать READ_COMMITTED_SNAPSHOT для базы 1С?

Это зависит от режима блокировок информационной базы. Для управляемого режима блокировок включение READ_COMMITTED_SNAPSHOT — распространённая практика, снижающая конфликты чтения и записи. Для автоматического режима платформа сама использует другую схему, и изменение параметра эффекта не даст.

Чем опасен включённый Auto shrink?

Автосжатие периодически перемещает страницы данных, сильно фрагментируя индексы, и создаёт всплески дисковой нагрузки в произвольные моменты, включая часы пик. Освобождённое место всё равно понадобится базе снова, поэтому shrink не решает проблему роста — контролируйте размер через архивацию и регламентную очистку данных.

Как понять, что проблема в SQL Server, а не в коде конфигурации?

Смотрите ожидания сервера через sys.dm_os_wait_stats и технологический журнал 1С одновременно. Если доминируют ожидания диска, памяти или tempdb и тяжёлые запросы — типовые (проведение, виртуальные таблицы), проблема в инфраструктуре. Если конкретные запросы с плохими планами при исправном сервере — вероятнее доработки конфигурации или нехватка подходящих индексов.