- 1) Проверьте основу: что именно вы хотите ускорить
- 2) Настройка sql-сервера: базовые параметры, которые дают эффект
- 3) Настройка файлов базы: где лежит данные и журнал
- 4) Maintenance plan: что делать каждый день и каждую неделю
- 5) Бэкапы: full и differential, плюс дисциплина журнала
- 6) Статистика: без неё sql оптимизатор часто выбирает плохой план
- 7) tempdb и нагрузка: частая причина “неочевидных” тормозов
- 8) Проверьте подключение 1С и протокол
- 9) Типичные ошибки при настройке MS SQL под 1С
- 10) Мини-чеклист перед запуском пользователей
- Вывод
1С в клиент-серверном варианте использует MS SQL Server как хранилище и как место, где выполняются ресурсоемкие операции. Чтобы база работала быстро и стабильно, настройка нужна не “в целом”, а под вашу нагрузку, размер и режим обслуживания.
Ниже - практический план настройки. Он опирается на общие рекомендации по индексации и обслуживанию базы в MS SQL Server, а также на регламентные подходы, которые описывает 1С.
Источники:
- 1С: рекомендации по регламентным операциям в MS SQL Server (ITS.1c.ru) https://its.1c.ru/db/metod8dev/content/5904/hdoc
- Microsoft: реорганизация и перестроение индексов https://docs.microsoft.com/ru-ru/sql/relational-databases/indexes/reorganize-and-rebuild-indexes
- Microsoft: статистика в SQL Server https://docs.microsoft.com/ru-ru/sql/relational-databases/statistics/statistics
1) Проверьте основу: что именно вы хотите ускорить
Типовые проблемы при работе 1С с sql обычно выглядят так:
- замедляется открытие и проведение документов
- отчеты выполняются дольше
- подбор и другие интерактивные операции “тормозят”
- растут задержки при пиковой нагрузке
У большинства таких симптомов общий корень - состояние базы и настройка окружения: диски, память, индексы, статистика, tempdb, режим восстановления и регулярное обслуживание.
2) Настройка sql-сервера: базовые параметры, которые дают эффект
2.1 Отключите лишние компоненты, если они не используются
Отключайте службы и функции, которые не применяются в вашей схеме (например, Full-Text Search), чтобы не расходовать ресурсы. У 1С обычно есть свой механизм поиска по текстам, поэтому отдельный full-text часто не нужен.
На практике оставляют только нужное ядро:
- SQL Server (sqlservr.exe)
- SQL Server Agent (SQLAGENT.exe) - нужен для регламентных заданий
- SQL Writer (sqlwriter.exe) - зависит от сценариев бэкапа/интеграций
2.2 Память SQL Server: не отдавайте “всё без ограничений”
Установите ограничение max server memory, чтобы sql заранее знал, сколько памяти может потреблять, и не конкурировал с процессами 1С и операционной системой.
Подход простой:
- вычтите память под ОС
- вычтите запас под процессы rphost, если 1С и sql на одном сервере
- остальное - в max server memory
Если вы не уверены в формуле - начните с консервативного лимита, а дальше корректируйте по фактическим метрикам (память, очередь диска, время ответов).
2.3 Потоки и приоритет
Для стабильной работы под нагрузкой настройте:
- Maximum worker threads: обычно ставят значение около 2048
- Boost priority: включают, если sql и 1С критичны для отклика (зависит от политики вашей инфраструктуры)
3) Настройка файлов базы: где лежит данные и журнал
Правильное размещение файлов влияет на скорость чтения/записи и на стабильность под нагрузкой.
Рекомендации:
- файл данных и файл журнала по возможности размещайте на разных физических дисках
- задайте автоувеличение (чтобы база не упиралась в “недостаточно места”)
- начальный размер делайте не меньше ожидаемого после разворачивания
Если база была в .dt и вы “распечатываете” её в sql, файл обычно увеличивается. Поэтому первичный размер нужно задавать с запасом, иначе автоувеличение будет происходить слишком часто и даст паузы.
4) Maintenance plan: что делать каждый день и каждую неделю
Для 1С 1С рекомендует выполнять обслуживание на уровне СУБД и подтверждает, что такие действия должны быть регулярными и запускаться в технологические окна. Базовый набор:
- проверка целостности
- работа с индексами
- обновление статистики
4.1 Схема обслуживания (практичный шаблон)
| Что делать | Как это делается в MS SQL | Периодичность | Когда запускать |
|---|---|---|---|
| Проверка целостности | Проверка целостности базы (maintenance task) | 1 раз в неделю | в технологическом окне, минимальная нагрузка |
| Реорганизация индексов | Reorganize index | 1 раз в сутки | в технологическом окне |
| Обновление статистики | Update statistics | 1 раз в сутки | в технологическом окне |
Эти операции помогают поддерживать оптимальные планы выполнения запросов. Microsoft отдельно объясняет принципы реорганизации/перестроения индексов и условия, когда что выбирать: https://docs.microsoft.com/ru-ru/sql/relational-databases/indexes/reorganize-and-rebuild-indexes
4.2 Как понять, что пора перестраивать индексы
Индексы фрагментируются со временем. В MS SQL Server есть два режима:
- reorganization: “подлечить” фрагментацию без существенного простоя
- rebuild: перестроить индекс, если фрагментация высокая
Microsoft описывает различия и рекомендует применять rebuild при значительном уровне фрагментации: https://docs.microsoft.com/ru-ru/sql/relational-databases/indexes/reorganize-and-rebuild-indexes
Практический ориентир, который часто используют на проде:
- если фрагментация невысокая - делайте reorganization
- если фрагментация высокая - делайте rebuild один раз и дальше возвращайтесь к reorganization
4.3 Проверка индексов по фрагментации - простой запрос
Можно собрать фрагментацию через sys.dm_db_index_physical_stats (логика - как в примерах сообщества и админов). Примерная форма:
- получить avg_fragmentation_in_percent для индексов
- отсортировать по убыванию
После этого вы решаете: реорганизовать или перестроить.
5) Бэкапы: full и differential, плюс дисциплина журнала
Настройте:
- Full backup: раз в сутки
- Differential: раз в 1-2 часа (или по вашему RPO/RTO)
Регулярность важна, потому что восстановление “как можно точнее по времени” напрямую зависит от частоты differential и от корректного цепочного хранения.
Также важно не делать лишние операции shrink. Они почти всегда ухудшают производительность, потому что после shrink файлы снова растут и вызывают лишнюю активность дисковой подсистемы. Это отдельно подчеркивается в практических материалах по эксплуатации 1С на SQL.
6) Статистика: без неё sql оптимизатор часто выбирает плохой план
Для 1С статистика влияет на скорость запросов. 1С активно нагружает таблицы и запросы, а устаревшая статистика снижает качество оптимизации.
Microsoft описывает, что такое статистика и как она используется оптимизатором:
https://docs.microsoft.com/ru-ru/sql/relational-databases/statistics/statistics
Практическая настройка для 1С:
- обновляйте статистику регулярно (часто - раз в сутки)
- запускайте обновление в технологическое окно, чтобы не добавлять нагрузку в часы работы
7) tempdb и нагрузка: частая причина “неочевидных” тормозов
Для 1С tempdb критичен, потому что многие операции используют временные структуры. Если tempdb узкое место, даже хорошо настроенная индексная стратегия не спасет.
Что сделать:
- держать tempdb на быстрых дисках
- выделить несколько файлов tempdb, чтобы снизить контеншн
Точное число файлов зависит от версии sql и количества ядер, поэтому это лучше подбирать под метрики сервера.
8) Проверьте подключение 1С и протокол
Если sql и сервер 1С на одной машине, применяют shared memory (на новых версиях платформы это корректнее, чем named pipes). Если на разных машинах, обычно используют TCP/IP.
Проверку соединения можно сделать по текущим параметрам сессий в sql (например, net_transport). Но ключевой принцип такой:
- выбирайте протокол, который соответствует топологии (одна машина или разные)
- обеспечьте стабильную сеть и пропускную способность
9) Типичные ошибки при настройке MS SQL под 1С
1) Нет обслуживания индексов и статистики
Индексы фрагментируются, статистика устаревает. Результат - запросы выполняются медленнее.
2) Неконтролируемый рост файлов и частые автоувеличения
Если начальные размеры заданы неверно, база постоянно упирается в лимиты. Это дает паузы на операциях роста.
3) Частый shrink ради “освобождения места”
Shrink ухудшает производительность. После него файлы обычно снова растут, а диску приходится работать интенсивнее.
4) Отключили нужные регламентные задания
Если Maintenance plan не отрабатывает по расписанию, через время начнет деградировать скорость работы.
5) Неподходящая модель восстановления без учёта журнала
Цепочка бэкапов и размер журнала зависят от модели восстановления. Ошибки здесь часто проявляются как внезапный рост LDF.
10) Мини-чеклист перед запуском пользователей
- [ ] max server memory задан с учетом ОС и процессов rphost (если 1С и sql на одном сервере)
- [ ] файлы базы и журнала разнесены по дискам, где это возможно
- [ ] задано автоувеличение файлов без частых “шагов”
- [ ] maintenance plan настроен: проверка целостности, реорганизация индексов, обновление статистики
- [ ] full и differential бэкапы настроены по расписанию и проверены по журналу выполнения
- [ ] обновление статистики выполняется регулярно и не в пиковые часы
- [ ] tempdb на быстрых дисках и с разумным числом файлов
- [ ] протокол подключения соответствует топологии (shared memory для одной машины, TCP/IP для разных)
Вывод
Правильная настройка MS SQL Server для работы с 1С строится на трёх вещах: стабильные параметры sql-сервера, корректная структура файлов и регулярное обслуживание базы - индексы и статистика. Это подтверждают рекомендации 1С на портале ITS и документация Microsoft по индексации и статистике.
Ссылки:
- 1С (регламентные операции на уровне СУБД): https://its.1c.ru/db/metod8dev/content/5904/hdoc
- Microsoft (reorganize/rebuild индексов): 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