MSSQL_41305 1С:Предприятие и СУБД

MSSQL Error 41305: Repeatable read validation failure in In-Memory OLTP — Решение

Обновлено: 25.08.2026 · Официальная документация ↗

Ошибка при выполнении транзакции: Error: 41305, Severity: 16, State: 1. The current transaction failed to commit due to a repeatable read validation failure.
Транзакция успешно читала данные, но на этапе COMMIT была прервана ядром SQL Server.
Сбои в финансовых модулях и модулях взаиморасчетов 1С, использующих строгую изоляцию.

1. Принцип работы фазы валидации REPEATABLE READ в Hekaton

При использовании уровня изоляции REPEATABLE READ движок In-Memory OLTP в момент выполнения COMMIT выполняет проверку: не была ли обновлена или удалена любая из ранее прочитанных строк другой параллельной транзакцией. Если хотя бы одна строка изменилась, валидация проваливается с ошибкой 41305.

2. Анализ транзакций с высоким риском сбоя валидации

-- Мониторинг провалов валидации транзакций XTP
SELECT 
    transaction_id,
    state_desc,
    commit_status_desc,
    validation_failures
FROM sys.dm_db_xtp_transactions
WHERE validation_failures > 0;

3. Переход на уровень изоляции SNAPSHOT

Уровень SNAPSHOT гарантирует целостность прочитанных данных на момент старта транзакции и не требует совпадения версий на момент фиксации:

-- Замена хинта REPEATABLEREAD на SNAPSHOT в запросе
SELECT ID, Balance 
FROM dbo.AccountBalances_InMemory WITH (SNAPSHOT) 
WHERE AccountID = @AccountID;

4. Минимизация интервала между чтением и фиксацией

Перенесите все тяжелые расчеты бизнес-логики 1С ДО открытия транзакции модификации In-Memory данных, чтобы сократить окно уязвимости для параллельных коммитов.

💡 Практика специалистов: В 99% сценариев интеграции 1С с In-Memory OLTP использование REPEATABLE READ избыточно. Используйте уровень изоляции SNAPSHOT в сочетании с нативно скомпилированными процедурами.

Частые вопросы (FAQ)

Чем уровень SNAPSHOT отличается от REPEATABLE READ в In-Memory OLTP?

При SNAPSHOT транзакция всегда видит согласованный снимок на начало своего старта и успешно коммитится, если сама не меняла те же строки. REPEATABLE READ требует, чтобы прочитанные строки оставались неизменными в таблице до момента COMMIT.

Почему ошибка 41305 возникает только в момент COMMIT, а не при выполнении SELECT?

В неблокирующей архитектуре Hekaton валидация прочитанных диапазонов и строк откладывается до финальной фазы двухфазной фиксации транзакции.

Можно ли использовать скомпилированные модули (Natively Compiled Stored Procedures) для избежания 41305?

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

Как включить автоматическое повышение изоляции до SNAPSHOT на уровне базы?

Выполните: ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;