Последствия использования изоляции Serializable и Snapshot одновременно

Question

Есть ли проблемы с использованием изоляции SNAPSHOT для постоянного чтения данных для просмотра без блокировки, блокировки или грязных/фантомных чтений, в то время как отдельный процесс обрабатывает непрерывные входящие данные в сериализуемых транзакциях?

Нам нужны считыватели (гарантированные только для чтения: синхронизация веб-данных, просмотр в режиме реального времени и т. Д.), Чтобы иметь возможность считывать согласованные данные без блокировки или блокировки обновлений. Мы использовали SNAPSHOT для всего, но имели слишком много сбоев согласования, поэтому переключили процесс обновления на SERIALIZABLE.

Я читал, но не совсем ясно, что касается одновременного использования разных уровней изоляции. Я видел lock compatibility matrix и читал различную информацию. Кажется, все в порядке, но я бы очень признателен за мудрое руководство от людей с практическим опытом о любых серьезных подводных камнях.

Существуют ли какие-либо проблемы, связанные с изоляцией моментальных снимков для читателей, в то время как транзакции SERIALIZABLE записываются? Есть ли обстоятельства, что он заблокирует транзакцию SERIALIZABLE? Есть ли преимущество использования SNAPSHOT против READ COMMITTED (с READ_COMMITTED_SNAPSHOT ON)?

Спасибо, любая помощь очень ценится :-)

Answer 1

Считывают выполняются под уровнем изоляции SNAPSHOT прочитать любые измененные данные из хранилища версий. Как таковые, они затрагивают только от записи. Записывает поведение тождественно под всеми уровнями изоляции. Поэтому чтение SNAPSHOT ведет себя одинаково независимо от уровня изоляции совпадающих транзакций.

READ_COMMITTED_SNAPSHOT ON делает READ COMMITTED действующим как SNAPSHOT. По сути, это SNAPSHOT: READ_COMMITTED_SNAPSHOT был предоставлен как быстрый способ переноса приложений на SNAPSHOT без изменений кода. Итак, все сказанное в первом абзаце применяется.