Планы обмена. Управляемый режим блокировок

(1) Вы абсолютно правы! Спасибо за замечание. Поправил.

(3) Да, есть такое дело. Честно говоря, устал бороться с этим явлением =(

(5) Прошу прощения, но Вы бы не могли уточнить, что конкретно имеется ввиду? Например, я понял вопрос так: есть 100 входящих сообщений обмена для центральной базы. Вероятно это РИБ. Если каждое сообщение имеет по 1 объекту, то я не вижу в этом вообще никакой проблемы ... Дайте, пожалуйста, цифры.

(5) Если отвечать на Ваш вопрос глобально, то, при условии, что были исчерпаны все варианты оптимизации планов обмена, нужно использовать альтернативные варианты. Например, можно использовать свою реализацию регистрации изменений. Это как минимум. Некоторые размышления по этому поводу я зафиксировал здесь. Есть и другие публикации по этому поводу. Ссылки на них можно найти в моём профиле.

В ближайшее время я планирую сделать ещё пару публикаций на тему того как можно оптимизировать работу планов обмена. Если проблемы серьёзные и требуется частная консультация, то я готов оказать посильную помощь. Пишите в личку.

(9) Тут не так много мест где будут отличия. Пожалуй это все те места, где выполняется команда SELECT. Если Вы хорошо понимаете разницу между READ COMMITED (автоматический режим) и READ COMMITED SNAPSHOT (управляемый режим), то без труда поймёте где и какая разница возникает.

Если отвечать упрощённо, то разница между этими двумя режимами такова, что:
1. При чтении данных:
в первом случае мы получаем версию записи после её изменения в другой транзакции. При этом мы ждём её завершения (нас блокируют - мы ждём, чтобы прочитать). А в случае со snapshot, мы получаем версию записи, которая была до начала второй транзакции. При этом мы ничего не ждём и допускаем "грязное чтение".
2. В процессе чтения данных:
в первом случае мы блокируем транзакции, которые желают изменить данные, которые мы читаем (мы блокируем - нас ждут, чтобы изменить). А в случае со snapshot мы никого не блокируем.

Некоторые могут подумать, что в первом случае прочитанные нами данные блокируются до конца транзакции, но это не так. Уточняю: речь идёт о первом случае (автоматический режим блокировок), когда опция read_commited_snapshot на уровне базы данных имеет значение OFF (выключено).
Это зависит от режима изоляции транзакции. В случае с планами обмена используется режим изоляции транзакции SQL Server по умолчанию, а он чаще всего равен READ COMMITED, то есть данные блокируются только на время их чтения.
То есть одна запись блокируется пока она читается в выборку, затем блокировка снимается, делается попытка получить разрешение на чтение следующей записи, устанавливается блокировка чтения и читается следующая запись. И так до тех пор, пока все, попавшие в условие отбора, записи не будут прочитаны.

(18) Можно легко предположить что будет. При управляемых блокировках SEL ECT будет выполняться как READ COMMITTED SNAPSHOT, так как BEGIN TRANSACTION вызывается без параметров, а следовательно с уровнем изоляции транзакции используемой SQL Server по умолчанию. По умолчанию это READ COMMITTED. Так как 1С включает на своих базах данных параметр read_committed_snapshot равным значению 1 (включено), то имеем в итоге READ COMMITTED SNAPSHOT.

Таким образом если вынести UPDATE и SELECT в разные транзакции, то от этого ничего не изменится. Если выполнить UPDATE без явного объявления транзакции BEGIN TRANSACTION, то в любом случае эта команда будет выполняться в неявной транзакции с уровнем изоляции по умолчанию.
Короче говоря, таким образом можно уменьшить время выполнения транзакции и удержания эксклюзивных блокировок, установленных командой UPDATE, на время выполнения SELECT. В некоторых случаях это может облегчить жизнь, но не думаю, что это принципиально менят ситуацию с блокировками на таблицах изменений планов обмена.

(21) Косвенно пишу об этом в своей статье "Анализ блокировок СУБД: таблица изменений плана обмена 1С", пункт 4 "Анализ технологического журнала 1С":

Для решения проблем блокировок мой совет: не используйте механизм планов обмена =)