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

Question

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

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

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

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

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

Answer 1

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

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