Как работает уровень изоляции RCSI в 1С на MS SQL Server и как подготовить tempdb

При администрировании высоконагруженных и объемных баз 1С (от 1 ТБ и выше) на СУБД Microsoft SQL Server часто возникает вопрос оптимизации параллельной работы пользователей. Классическая проблема ожиданий на блокировках, когда читатели ждут писателей (ожидания типа LCK_M_S), может существенно замедлять работу формируемых отчетов и проведение документов. Разберем, как именно функционирует версионный режим READ_COMMITTED_SNAPSHOT (RCSI), в каких случаях платформа 1С включает его самостоятельно и как предотвратить проблемы с переполнением tempdb.

Автоматическое использование RCSI платформой 1С:Предприятие

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

В современных конфигурациях используется управляемый режим блокировок. Начиная с версии платформы 8.3.1 (при режиме совместимости с версией 8.2.16 и выше), платформа 1С:Предприятие при работе с Microsoft SQL Server 2005 и выше автоматически использует уровень изоляции транзакций READ_COMMITTED_SNAPSHOT. При чтении данных вне транзакций применяется согласованное чтение.

Таким образом, логические блокировки платформа накладывает самостоятельно через собственный менеджер блокировок, а на уровне СУБД читатели больше не блокируются пишущими транзакциями.

Проверка текущего состояния базы данных в MS SQL Server

Чтобы точно узнать, включен ли режим версионирования строк в конкретной базе данных, выполним диагностический T-SQL запрос к системному представлению sys.databases:

SELECT 
    name, 
    is_read_committed_snapshot_on, 
    snapshot_isolation_state_desc
FROM sys.databases 
WHERE name = DB_NAME();

Значение 1 в поле is_read_committed_snapshot_on подтверждает, что для текущей базы данных активирован механизм RCSI.

Поведение хранилища версий (Version Store) и риски переполнения tempdb

При активном RCSI каждая операция модификации данных сохраняет предыдущие версии строк в системной базе данных tempdb (в хранилище Version Store). Это создает определенные риски при высокой интенсивности изменений:

1. Зависание очистки версий из-за долгоживущих транзакций. Процесс Version Store Cleanup не может удалить ни одну версию строки, созданную после старта самой старой активной транзакции на сервере. Если регламентное задание, отчет или фоновый процесс удерживают открытую транзакцию часами, версионник в tempdb непрерывно растет, что может приводить к ошибке переполнения диска (ошибка 9002).
2. Оверхед на уровне строк. При изменении строки к ней добавляется 14-байтный указатель на цепочку версий. При плотном заполнении страниц данных это может вызывать повышенное количество расщеплений страниц (page splits) и увеличивать фрагментацию индексов.

Практические рекомендации по настройке tempdb и дисковой подсистемы

Для надежной работы 1С с версионным режимом на больших объемах данных настроим окружение базы данных:

1. Конфигурация файлов tempdb. Создадим несколько файлов данных одинакового начального размера с одинаковым фиксированным шагом авторасширения в мегабайтах (а не в процентах). Оптимальное количество файлов — по одному на логическое ядро (до 8 файлов).
2. Выделение дискового пространства. Разместим файлы tempdb на отдельном высокоскоростном NVMe-накопителе. Для баз объемом в несколько терабайт с активным параллельным перепроведением документов под tempdb рекомендуется резервировать от 15–20% объема рабочей базы.
3. Настройка Fill Factor. Для снижения частоты расщепления страниц при массовых обновлениях рекомендуется задать коэффициент заполнения индексов (FILLFACTOR) на уровне 85–90% для наиболее активных таблиц.
4. Использование Accelerated Database Recovery (ADR). Начиная с MS SQL Server 2019 доступен механизм ADR, который переносит хранилище версий (Persisted Version Store) из tempdb непосредственно в саму базу данных. Это изолирует нагрузку и предотвращает падение всего экземпляра из-за разрастания системного tempdb.

Мониторинг версионника через динамические представления (DMV)

Для оперативного контроля состояния хранилища версий и поиска зависших транзакций выполним анализ следующих представлений СУБД:

1. Контроль занятого объема в tempdb: используем представление sys.dm_db_file_space_usage (столбец version_store_reserved_page_count).
2. Поиск самой старой активной транзакции: представление sys.dm_tran_active_snapshot_database_transactions позволяет вычислить сессию с минимальным номером transaction_sequence_num, блокирующую автоматическую очистку.
3. Анализ наиболее активных генераторов версий: представление sys.dm_tran_top_version_generators наглядно показывает таблицы базы 1С, которые генерируют максимальный поток версий.