MS SQL Server под 1С:Предприятием 8.3: что происходит внутри базы и как ускорить её работу

В клиент-серверном варианте 1С SQL Server только хранит данные и выполняет запросы. Бизнес-логику он не исполняет. Запрос на языке 1С переводит в SQL рабочий процесс сервера 1С (rphost), а пользователь с СУБД напрямую вообще не общается. Поэтому работа SQL Server в 1С ускоряется двумя путями: настройкой самой СУБД (память, параллелизм, tempdb, статистика) и правкой запросов в конфигурации.

Частое заблуждение — «база тормозит, значит, нужен сервер мощнее». На практике медленную 1С на SQL чаще лечат регламентом обслуживания и одним-двумя параметрами СУБД, чем покупкой железа.

Кто за что отвечает: клиент, кластер 1С и СУБД

Цепочка в клиент-серверном режиме выглядит так.

1. 💻 Клиент 1С (тонкий клиент или веб-клиент) показывает формы и отправляет вызовы на сервер.
2. 🧭 Агент сервера 1С (ragent, порт 1540) принимает подключение и передаёт его менеджеру кластера (rmngr, порт 1541).
3. ⚙️ Рабочий процесс (rphost) исполняет серверный код конфигурации, строит SQL-текст и отправляет его в СУБД.
4. 🗄️ SQL Server (по умолчанию порт 1433) выполняет запрос и возвращает строки рабочему процессу.

Отсюда практические выводы:

• 🔌 Сеть между сервером 1С и SQL Server должна быть быстрой и стабильной: каждый вызов — это десятки обращений к СУБД. Лучший вариант — оба сервиса на одной машине или в одной стойке.
• 🔐 Права на SQL выдают учётной записи, которую 1С указывает в параметрах информационной базы, а не пользователям 1С.
• 🧮 Лицензии 1С и SQL Server — разные вещи. Клиентские лицензии 1С не покрывают лицензирование СУБД.

Как база 1С появляется в SQL Server

Базу создают в консоли администрирования кластера: новая информационная база, тип СУБД MSSQLServer, имя сервера баз данных, имя базы, логин и пароль пользователя СУБД. Галка «Создать базу данных в случае её отсутствия» поручает создание самой 1С.

Для создания логину нужна серверная роль dbcreator. После этого его достаточно оставить владельцем только своей базы (db_owner). Давать sysadmin для повседневной работы незачем.

Как 1С раскладывает данные по таблицам SQL Server

Откройте базу 1С в SQL Server Management Studio — и увидите сотни таблиц с именами вроде _Reference25, _Document117, _AccumRg2045. Это не мусор, а схема, которую платформа генерирует по метаданным конфигурации.

Поля тоже обезличены: _Fld1234, _IDRRef, _Date_Time, _Posted. Служебные таблицы без подчёркивания (Config, Params, Files, DBSchema) хранят саму конфигурацию и параметры базы.

Как узнать, какая таблица за что отвечает

Соответствие имён метаданным выдаёт встроенная функция ПолучитьСтруктуруХраненияБазыДанных(). Её запускают из обработки или консоли кода:

Структура = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
Для Каждого Строка Из Структура Цикл
    Сообщить(Строка.Метаданные + " = " + Строка.ИмяТаблицы);
КонецЦикла;

Второй параметр Истина возвращает имена в терминах СУБД. Без этого не прочитать ни план запроса, ни отчёт о блокировках: в них только _AccumRg2045.

Индексы

Платформа сама создаёт кластерный индекс и индексы по ссылке, коду, наименованию, дате и измерениям регистров. Свойство реквизита «Индексировать» в конфигураторе добавляет ещё один. Индексы, созданные вручную в SQL, пропадут при следующей реструктуризации базы, так что такой «тюнинг» живёт до первого обновления.

Что происходит с запросом 1С на стороне СУБД

Текст на языке запросов 1С рабочий процесс транслирует в T-SQL. Несколько моментов, которые видны в профайлере и объясняют поведение базы:

• 📦 Временные таблицы (ПОМЕСТИТЬ ВТ_…) превращаются в таблицы #tt в tempdb. Отсюда нагрузка на tempdb в тяжёлых отчётах.
• 🔗 Разыменование через точку (Документ.Контрагент.ИНН) даёт дополнительные соединения. Цепочка через составной тип — по соединению на каждый возможный тип.
• 📊 Виртуальные таблицы Остатки и ОстаткиИОбороты читают таблицы итогов _AccumRgT. Если итоги не пересчитаны или отключены, СУБД перебирает движения целиком.
• 🔒 Управляемые блокировки 1С ставит в своём менеджере блокировок, а СУБД работает в режиме версионирования строк (READ_COMMITTED_SNAPSHOT). Поэтому чтение не ждёт записи, как в старом автоматическом режиме.

Как писать запросы, которые SQL выполняет быстро

1. Ставьте условия в параметры виртуальной таблицы, а не в ГДЕ после неё. Иначе СУБД сначала посчитает остатки по всем организациям, а потом отфильтрует.
2. Не соединяйте с подзапросами — выносите их во временные таблицы и индексируйте по полю соединения (ИНДЕКСИРОВАТЬ ПО).
3. Не используйте ИЛИ в условиях соединения: оптимизатор часто уходит в полный просмотр. Помогает разбиение на два запроса с ОБЪЕДИНИТЬ ВСЕ.
4. Отбирайте по полям, на которых есть индекс, и в порядке этого индекса.
5. Не обращайтесь к базе в цикле: один запрос на 1 000 строк быстрее тысячи запросов по одной.

План выполнения конкретного запроса 1С снимают в технологическом журнале (событие DBMSSQL со свойством planSQLText) или в SQL Server Profiler / Extended Events, отфильтровав по имени базы.

Типичные проблемы производительности и что с ними делать

Ещё две частые причины, которые не видны в SQL:

• 🧾 Отключённые или не пересчитанные итоги регистров. Проверяются в режиме 1С:Предприятие: Все функции → Стандартные → Управление итогами (пункт «Все функции» включается в параметрах программы).
• 🐢 Отладка на рабочем сервере. Включённая отладка на кластере заметно замедляет рабочие процессы.

Настройка SQL Server под нагрузку 1С

Параметры ниже меняют на уровне экземпляра. Это общие для всех баз 1С рекомендации, а не «серебряная пуля»: после каждого изменения смотрите на поведение под реальной нагрузкой.

Команды для MAXDOP и памяти (пример для сервера с 64 ГБ, где 1С стоит на той же машине):

EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 1; RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 40960; RECONFIGURE;

Здесь 40 ГБ отдано SQL Server, 24 ГБ — ОС и рабочим процессам 1С. Если 1С живёт на отдельном сервере, SQL можно отдать около 56 ГБ.

Диски: файлы данных, журнал транзакций и tempdb лучше разнести по разным томам на SSD. Журнал пишется последовательно и особенно чувствителен к задержкам записи.

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

Без обслуживания база деградирует даже на мощном железе. Минимальный план в SQL Server Agent:

Очистка кэша планов выполняется командой DBCC FREEPROCCACHE. Сразу после неё запросы на несколько минут станут медленнее, пока планы не скомпилируются заново, поэтому её ставят в ночное окно.

Мониторинг и диагностика: где искать причину

Разбирайте проблему сверху вниз — от ощущения пользователя до конкретного запроса.

1. Консоль кластера 1С. Список сеансов и соединений показывает, какой сеанс занят, сколько времени он в вызове СУБД и чья блокировка его держит.
2. Монитор активности SSMS. Вкладки процессов, ожиданий и дорогих запросов дают картину «здесь и сейчас».
3. Динамические представления SQL Server. Текущие ожидания и блокировки видны в sys.dm_exec_requests, накопленная статистика ожиданий — в sys.dm_os_wait_stats.
4. Технологический журнал 1С. Файл logcfg.xml в каталоге conf платформы включает сбор событий. Для СУБД нужны DBMSSQL с длительностью выше порога, для блокировок — TLOCK, TTIMEOUT, TDEADLOCK.
5. Query Store (SQL Server 2016 и новее) хранит историю планов и показывает, когда запрос «переключился» на плохой план.

Пример быстрого запроса: кто сейчас кого блокирует.

SELECT r.session_id, r.blocking_session_id, r.wait_type,
       r.wait_time, DB_NAME(r.database_id) AS db, t.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0;

Номер сеанса SQL из этого запроса сопоставляют с соединением 1С в консоли кластера: там видно имя пользователя 1С и что он делает.

Резервное копирование и восстановление базы 1С на SQL

Выгрузка .dt из конфигуратора — не замена резервной копии. Она требует монопольного доступа, на больших базах идёт часами и не даёт восстановиться на момент времени. Основной инструмент — бэкап средствами SQL Server.

BACKUP DATABASE [buh] TO DISK = N'D:\Backup\buh_full.bak'
WITH COMPRESSION, CHECKSUM, INIT;

Для модели FULL бэкап журнала по расписанию обязателен — иначе файл .ldf будет расти до заполнения диска.

Восстановление

1. Восстановите копию в новую базу SQL с другим именем, а не поверх рабочей, — пока не убедитесь, что копия нужная.
2. В консоли кластера зарегистрируйте информационную базу, указав это имя базы SQL.
3. Если это копия для тестов, сразу включите в её параметрах блокировку регламентных заданий. Иначе тестовая копия начнёт выгружать данные в банк, ЭДО и узлы обмена от имени рабочей.
4. Проверьте вход и ключевые отчёты, затем переключайте пользователей.

Копии храните не на том же сервере, что и SQL, и регулярно проверяйте их пробным восстановлением: непроверенный бэкап — это надежда, а не копия.

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