← На главную

Работа с регистрами расчета в режиме совместимости с платформой 8.2 часто сопровождается возникновением таймаутов на стороне СУБД при проведении документов. Давайте вместе разберемся, почему это происходит и как можно минимизировать влияние данных блокировок на производительность системы.

Причины возникновения блокировок

Основная проблема кроется в том, как именно платформа 1С версий 8.2 и ниже взаимодействует с SQL Server при записи данных в регистры расчета. В отличие от современных версий платформы, где алгоритмы оптимизированы, в режиме совместимости 8.2 часто задействуются дополнительные физические таблицы, например, для хранения ФактическийПериодДействия.

При записи данных платформа генерирует специфические SQL-запросы, которые могут приводить к блокировке всей таблицы TABLOCK. Это необходимо для обеспечения транзакционной целостности при выполнении сложных выборок внутри процедур проведения. Когда два документа одновременно пытаются записать данные в один период, возникают конфликты блокировок на системных таблицах или индексах, что приводит к ожиданию и последующему таймауту.

Шаг 1: Анализ через технологический журнал

Первое, что нам необходимо сделать — это локализовать место возникновения конфликта. Для этого настроим технологический журнал. Нас интересуют события DBMSSQL и TLOCK.

1. Настройте фильтр в файле logcfg.xml так, чтобы фиксировались длительные события DBMSSQL (например, превышающие 5-10 секунд).
2. Проанализируйте полученные данные. Вы увидите конкретные SQL-запросы, которые инициирует платформа. Часто они содержат вставки во временные таблицы с использованием WITH(TABLOCK).
3. Обратите внимание на поля, по которым происходят ожидания. Если в запросах часто фигурирует _CalcKindRRef (Вид расчета), значит, проблема может быть связана с недостаточной эффективностью индексов по этому полю или конкуренцией при обращении к перерасчетам.

Шаг 2: Использование RCSI (Read Committed Snapshot Isolation)

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

Чтобы убедиться, что настройка применена, проверьте параметры вашей базы данных через Management Studio:

Убедитесь, что параметры snapshot_isolation_state и is_read_committed_snapshot_on установлены в значение 1 (True).

Шаг 3: Почему ручное изменение индексов — не лучший путь

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

Шаг 4: Анализ ожиданий через ЦУП

Для глубокого понимания ситуации воспользуйтесь инструментом «Центр управления производительностью» (ЦУП). Он позволит:

• Выявить конкретные документы, которые чаще всего конфликтуют друг с другом.
• Посмотреть, на какие именно ресурсы (блокировки СУБД) тратится время ожидания.
• Определить, является ли проблема следствием неоптимального проведения документов или же системной ошибкой платформы.

Рекомендации по устранению проблемы

1. Проверьте настройки блокировок: Убедитесь, что в конфигурации установлен режим Управляемые блокировки для всех объектов, участвующих в проведении.
2. Оптимизируйте проведение: Проанализируйте, нет ли в логике проведения избыточных записей в регистры. Если движения регистра не меняются, платформа может не выполнять запись, но если алгоритм проведения построен так, что записи перезаписываются при каждом проведении, это создает избыточную нагрузку.
3. Переход на режим совместимости 8.3: Если это возможно, попробуйте перевести базу в режим совместимости 8.3 (или отключить совместимость). Платформа 8.3 использует более совершенные механизмы работы с регистрами расчета, которые позволяют избежать использования многих временных таблиц, вызывающих таймауты в 8.2.
4. Мониторинг транзакций: Используйте динамические представления SQL, такие как sys.dm_tran_locks, чтобы в режиме реального времени видеть, какой именно запрос держит блокировку и какой объект является «узким горлышком».

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