Комментарии
(5) Прошу прощения, но Вы бы не могли уточнить, что конкретно имеется ввиду? Например, я понял вопрос так: есть 100 входящих сообщений обмена для центральной базы. Вероятно это РИБ. Если каждое сообщение имеет по 1 объекту, то я не вижу в этом вообще никакой проблемы ... Дайте, пожалуйста, цифры.
(5) Если отвечать на Ваш вопрос глобально, то, при условии, что были исчерпаны все варианты оптимизации планов обмена, нужно использовать альтернативные варианты. Например, можно использовать свою реализацию регистрации изменений. Это как минимум. Некоторые размышления по этому поводу я зафиксировал . Есть и другие публикации по этому поводу. Ссылки на них можно найти в моём профиле.
В ближайшее время я планирую сделать ещё пару публикаций на тему того как можно оптимизировать работу планов обмена. Если проблемы серьёзные и требуется частная консультация, то я готов оказать посильную помощь. Пишите в личку.
В ближайшее время я планирую сделать ещё пару публикаций на тему того как можно оптимизировать работу планов обмена. Если проблемы серьёзные и требуется частная консультация, то я готов оказать посильную помощь. Пишите в личку.
(9) Тут не так много мест где будут отличия. Пожалуй это все те места, где выполняется команда SELECT. Если Вы хорошо понимаете разницу между READ COMMITED (автоматический режим) и READ COMMITED SNAPSHOT (управляемый режим), то без труда поймёте где и какая разница возникает.
Если отвечать упрощённо, то разница между этими двумя режимами такова, что:
1. При чтении данных:
в первом случае мы получаем версию записи после её изменения в другой транзакции. При этом мы ждём её завершения (нас блокируют - мы ждём, чтобы прочитать). А в случае со snapshot, мы получаем версию записи, которая была до начала второй транзакции. При этом мы ничего не ждём и допускаем "грязное чтение".
2. В процессе чтения данных:
в первом случае мы блокируем транзакции, которые желают изменить данные, которые мы читаем (мы блокируем - нас ждут, чтобы изменить). А в случае со snapshot мы никого не блокируем.
Некоторые могут подумать, что в первом случае прочитанные нами данные блокируются до конца транзакции, но это не так. Уточняю: речь идёт о первом случае (автоматический режим блокировок), когда опция read_commited_snapshot на уровне базы данных имеет значение OFF (выключено).
Это зависит от режима изоляции транзакции. В случае с планами обмена используется режим изоляции транзакции SQL Server по умолчанию, а он чаще всего равен READ COMMITED, то есть данные блокируются только на время их чтения.
То есть одна запись блокируется пока она читается в выборку, затем блокировка снимается, делается попытка получить разрешение на чтение следующей записи, устанавливается блокировка чтения и читается следующая запись. И так до тех пор, пока все, попавшие в условие отбора, записи не будут прочитаны.
Если отвечать упрощённо, то разница между этими двумя режимами такова, что:
1. При чтении данных:
в первом случае мы получаем версию записи после её изменения в другой транзакции. При этом мы ждём её завершения (нас блокируют - мы ждём, чтобы прочитать). А в случае со snapshot, мы получаем версию записи, которая была до начала второй транзакции. При этом мы ничего не ждём и допускаем "грязное чтение".
2. В процессе чтения данных:
в первом случае мы блокируем транзакции, которые желают изменить данные, которые мы читаем (мы блокируем - нас ждут, чтобы изменить). А в случае со snapshot мы никого не блокируем.
Некоторые могут подумать, что в первом случае прочитанные нами данные блокируются до конца транзакции, но это не так. Уточняю: речь идёт о первом случае (автоматический режим блокировок), когда опция read_commited_snapshot на уровне базы данных имеет значение OFF (выключено).
Это зависит от режима изоляции транзакции. В случае с планами обмена используется режим изоляции транзакции SQL Server по умолчанию, а он чаще всего равен READ COMMITED, то есть данные блокируются только на время их чтения.
То есть одна запись блокируется пока она читается в выборку, затем блокировка снимается, делается попытка получить разрешение на чтение следующей записи, устанавливается блокировка чтения и читается следующая запись. И так до тех пор, пока все, попавшие в условие отбора, записи не будут прочитаны.
(13) Коротко отвечу всё же:
READ COMMITTED - это уровень изоляции транзакций, как правило, используемый SQL Server.
read_committed_snapshot - это опция уровня базы данных, которая может изменять поведение уровня изоляции READ COMMITTED, принятое по умолчанию. По умолчанию read_committed_snapshot = OFF. Однако при включении управляемого режима блокировок 1С переключает это значение в положение ON. Это меняет поведение уровня изоляции транзакций READ COMMITTED принятое по умолчанию.
READ COMMITTED - это уровень изоляции транзакций, как правило, используемый SQL Server.
read_committed_snapshot - это опция уровня базы данных, которая может изменять поведение уровня изоляции READ COMMITTED, принятое по умолчанию. По умолчанию read_committed_snapshot = OFF. Однако при включении управляемого режима блокировок 1С переключает это значение в положение ON. Это меняет поведение уровня изоляции транзакций READ COMMITTED принятое по умолчанию.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|