Содержание:

Если 1С работает медленно, чаще всего проблема не в “самом sql”, а в том, что сервер поставили и оставили как есть. 1С любит, когда база обслуживается регулярно, память и диски настроены под нагрузку, а обслуживание выполняется по расписанию.

Ниже - практичная схема настройки sql-сервера для клиент-серверного режима 1С: от базовых параметров до регламентных задач.

Что нужно учесть в первую очередь

Перед тонкой настройкой важно понимать вводные:

  • Режим работы: 1С с СУБД - это когда 1С обращается к базе через sql, а тяжелые операции выполняет sql-сервер.
  • Где стоят 1С и sql: на одной машине или на разных влияет протоколы соединения и настройки.
  • Нагрузка: количество пользователей, размер базы, частота регламентных операций и фоновых задач (загрузки/выгрузки, отчеты).

Если sql и 1С на разных машинах, обычно лучше разделять нагрузку и не пытаться “выжать все” из одной виртуалки. И да, виртуализация часто усложняет предсказуемость производительности.

Базовые настройки sql-сервера в SSMS

1) Обновите управление через SSMS и зайдите под админом

Управлять sql удобнее через SQL Server Management Studio (SSMS): в интерфейсе настраиваются службы, база, параметры сервера и планы обслуживания.

2) Отключите то, что не нужно 1С

В первую очередь проверьте и отключите неиспользуемые компоненты sql, которые создают лишние процессы/нагрузку. Часто лишним бывает FullText Search, а также другие службы, если их не используют.

Минимально полезные для большинства сценариев:
- SQL Server (sqlservr.exe)
- SQL Server Agent (SQLAGENT.exe)
- SQL Writer (sqlwriter.exe)

3) Ограничьте память sql (и объясните ему рамки)

Типовая логика такая: OS нужно немного памяти, а остальное - под sql и рабочие процессы 1С (rphost), если они живут на том же сервере.

Условная схема расчета из практики:
- от общей RAM отнять 4 ГБ (или меньше/по вашей ОС),
- затем под каждый rphost отдать 1.5 ГБ,
- оставшееся - для sql.

Если sql и 1С на одном сервере, то sql должен заранее “знать”, сколько он может держать в RAM. Иначе он будет пытаться забрать больше, чем сервер реально может отдать, и начнет упираться в память и диск.

4) Выставьте потоки и приоритет

Практический ориентир:
- Maximum worker threads - целиться в 2048 (на практике это часто дает стабильную работу под 1С),
- Boost priority - включить, чтобы sql получил более высокий приоритет исполнения.

Эти параметры не “магия”, но они убирают лишнюю задержку в обработке запросов под нагрузкой.

Настройка базы данных: файлы, рост, диски

1) Размер первичных файлов и автоувеличение

Если вы переносите 1С из dt или пока примерно знаете размер, важно сразу задать файлы так, чтобы база не росла рывками.

Рекомендации по автоувеличению (ориентир):
- для данных: автоувеличение примерно 200 МБ
- для лога: автоувеличение примерно 50 МБ

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

2) Данные и лог - по разным дискам

По возможности размещайте:
- данные базы и
- лог транзакций
на разных физических дисках.

Так меньше конкуренция за IO, а 1С меньше страдает от очередей на диске.

3) Ограничьте лог до разумного размера

Для рабочих сценариев часто достаточно, чтобы лог был ограничен в диапазоне примерно 2-4 ГБ (дальше - по модели восстановления и вашему бэкап-плану).

tempdb: мелочь, которая убивает скорость

Если tempdb работает “как попало”, у sql появляются паузы, и 1С это чувствует в отчетах, подборе и тяжелых запросах.

Что обычно делают:
- tempdb размещают на быстром диске (отдельный диск, если есть возможность),
- увеличивают количество файлов tempdb так, чтобы оно хорошо распределяло нагрузку (часто ориентир - 1 файл на ядро, но не более разумного лимита).

Точное число подбирают по железу, но сама идея - убрать “один общий узкий проход”.

Настройка соединений 1С <-> sql (важно для производительности)

Если 1С-сервер и sql на одной машине:
- обычно используют Shared Memory (в зависимости от версий платформы это актуально начиная с определенных релизов).

Если на разных машинах:
- используют TCP/IP.

Проверка транспорта обычно делается запросом к динамическим представлениям sql (в SSMS можно посмотреть, какой net_transport используется текущими соединениями).

Регламентные задания: то, без чего база начинает “тормозить”

Со временем появляются:
- замедления открытия документов,
- подвисания подбора,
- долгие отчеты.

Обычно это следствие того, что индексы фрагментируются, статистика устаревает, а обслуживание отсутствует или выполняется вручную “когда вспомнили”.

Maintenance Plan: что делать раз в неделю/день

Базовая логика из практики для базы 1С:
- Проверка целостности - примерно раз в неделю
- Дефрагментация индексов (реорганизация) и
- обновление статистики - обычно делают ежедневно
- Полное перестроение индексов (если фрагментация высокая) - реже, по ситуации (например, по расписанию отдельно или по порогу)

Обычно в SSMS это настраивается через:
Управление -> Планы обслуживания -> Мастер планов обслуживания

Порог по фрагментации индексов: когда реорганизовать, а когда перестраивать

Практичный ориентир:
- фрагментация 5-30% - делайте реорганизацию,
- фрагментация выше 30% - нужно полное перестроение.

Есть полезный запрос, который возвращает среднюю фрагментацию по индексам через sys.dm_db_index_physical_stats. Для базы 1С его удобно запускать в окно запроса SSMS, чтобы принять решение без гаданий.

Времена и технологическое окно

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

Но ежедневные операции обычно можно делать так, чтобы пользователи продолжали работать (реорганизация индексов обычно менее болезненна, чем восстановление/перестроение).

Бэкапы: как настроить full и differential

Для восстановления и стабильности важно, чтобы bэкапы выполнялись по расписанию.

Типовая схема:
- Full: раз в сутки
- Differential: раз в 1-2 часа

Идея: full дает основу, differential - быстрые точки восстановления чаще, чем full.

С точки зрения практики, full/backups через SQL Server Agent обычно выполняются T-SQL скриптами BACKUP DATABASE ... TO DISK ....

Про shrink и лог

Есть практики “сжимать лог” (DBCC SHRINKFILE для файла логов). Но это может быть спорно: если вы делаете это без понимания модели восстановления и частоты бэкапов, можно получить лишнюю нагрузку и рост/перерост файла обратно.

Если вы решаете, использовать ли shrink, делайте это осознанно и привязывайте к вашей модели восстановления и фактической стратегии бэкапов.

Сжатие базы (когда оно оправдано)

Сжатие базы часто не нужно постоянно. Обычно его имеет смысл включать:
- после существенных изменений в базе,
- после восстановления из дампа,
- после реструктуризации/сверток.

В остальное время сжатие может ухудшить читаемость IO-профиля и добавит лишние операции.

Антивирус и файловая нагрузка

Одна из частых “скрытых” проблем производительности: антивирус сканирует файлы базы и резко тормозит sql.

Что делают:
- исключают каталог(и), где лежат файлы базы данных и ldf/mdf,
- следят, чтобы антивирус не вмешивался в постоянную работу sql.

Короткий чек-лист, который обычно закрывает 80% проблем

Область Что сделать Ориентир
Компоненты sql Отключить неиспользуемые службы FullText Search, если 1С использует собственный поиск
Память Ограничить RAM sql чтобы sql заранее “знал” лимит (особенно если sql и 1С на одном сервере)
Потоки Настроить worker threads целиться в 2048
Файлы базы Задать первичный размер первичный файл >= ожидаемому после разворачивания dt
Автоувеличение Установить разумные шаги ~200 МБ данные, ~50 МБ лог
Диски Разнести данные/лог на разные физические диски, если возможно
tempdb Разместить на быстром диске и раздать файлы чтобы не было узкого места
Индексы Реорганизация/перестроение по фрагментации <30% реорганизация, >30% перестроение
Статистика Обновлять регулярно обычно раз в сутки
Бэкапы Full + Differential по расписанию full раз в сутки, diff каждый 1-2 часа
Антивирус Исключить каталоги базы чтобы файлы sql не сканировались постоянно

Что делать, если “настроили, а через время снова стало медленно”

Это почти всегда значит одно из трех:
- обслуживание не выполняется стабильно (план обслуживания выключен/падает/не в технологическое окно),
- статистика и индексы уходят в плохое состояние (нет регламента или он слишком редкий),
- диски или tempdb стали узким местом (например, вырос объем базы, добавились пользователи, изменился режим работы).

В реальности путь простой: проверяете журнал плана обслуживания, смотрите фрагментацию и актуальность статистики, оцениваете IO и tempdb - и поправляете расписание/пороги под текущую нагрузку.

Принципиальная база: что именно делает 1С “вместе” с sql

Важно понимать, что 1С сама по себе не “ускоряет” работу базы. Она опирается на то, как sql хранит данные, строит планы запросов и обслуживает индексы/статистику. Поэтому правильно настроенный sql - это не один раз “выставить галочки”, а поддерживать стабильное состояние базы: индексы, статистика, бэкапы, диски и отсутствие фоновых конфликтов (например, антивирус).

Полезные официальные источники

  • Документация Microsoft по реорганизации и перестроению индексов: https://docs.microsoft.com/ru-ru/sql/relational-databases/indexes/reorganize-and-rebuild-indexes
  • Документация Microsoft по статистике: https://docs.microsoft.com/ru-ru/sql/relational-databases/statistics/statistics
  • Рекомендации 1С по администрированию СУБД (ИТС): https://its.1c.ru/db/metod8dev/