Какие риски существуют, если мы включаем моментальный снимок для чтения в sql-сервере?

Я читал здесь, что некоторые дополнительные данные будут храниться в каждой строке, поэтому мы можем увидеть снижение производительности, но какие еще риски существуют?

например. Повлияет ли это на восстановление базы данных? Есть ли что-то еще, что нам нужно сделать, чтобы воспользоваться этим?

Я планирую выполнить эти команды:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

Я полагаю, что это даст нам что-то ближе к оракулу, когда, если одна транзакция обновляет, другие транзакции могут все еще прочитать старые данные. Это верно?

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

Резюме

1. Если у вас есть проблемы с блокировкой, то у вас есть проблема с вашим кодом: это не ядро ​​базы данных
2. Это не волшебная пуля
3. Вы можете добавить больше проблем

нагрузка

Это также увеличит нагрузку на вашу базу данных и процессор . Также см:

• «Влияние на производительность: потенциальная стоимость Read_Committed_Snapshot» (Линчи Ши)

безопасности

Наиболее важно, снимок изоляты не являются безопасными во многих случаях по умолчанию . Прочитайте раздел «Снимок изоляции» (Википедия), чтобы узнать больше об аномалиях при перекосе. Следующий раздел - «Создание сериализуемой изоляции снимков», чтобы обойти это.

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

Также см:

• «Потенциальная опасность уровня изоляции« зафиксированный моментальный снимок » (JimMcLeod, оспаривается в комментариях Алексея Кузнецова)
• Deadlocked !: Объяснение "прочитанный зафиксированный снимок" (Ник Берарди)
• Сериализуемый или уровень изоляции моментальных снимков, проблема мрамора (Крейг Фридман)
• Чтения с участием UDF в READ_COMMITTED_SNAPSHOT могут показаться непоследовательными (Алексей Кузнецов)

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

По моему опыту, дополнительная нагрузка на TEMPDB незначительна, а преимущества управления версиями строк в уменьшении количества заблокированных читателей огромны.

Для справки, управление версиями строк (изоляция моментальных снимков) - это метод, который Oracle десятилетиями использовал для достижения изоляции без блокировки считывателей, а базы данных Oracle, над которыми я работал почти 20 лет, сталкиваются с гораздо меньшими проблемами блокирования, чем SQL Server. Большинство разработчиков SQL не решаются использовать изоляцию моментальных снимков, потому что они проверяли свой код только на тех базах данных, которые используют настройки по умолчанию.

Пара дополнительных пунктов, чтобы добавить к другим ответам:

SET ALLOW_SNAPSHOT_ISOLATION ONвключает только изоляцию моментальных снимков в базе данных. Чтобы воспользоваться этим, вы должны перекодировать и SET TRANSACTION ISOLATION LEVEL SNAPSHOTте транзакции, к которым вы хотите применить. Код вызова должен быть изменен для обработки ошибок конфликта обновления.

После того SET READ_COMMITTED_SNAPSHOT ON, как операторы при прочтении зафиксировали использование контроля версий строк. Обратите внимание, что это версия строк на уровне операторов только для чтения . Для обновлений извлекается «реальная» строка и применяются блокировки обновлений. См. Раздел Сводка поведения в разделе Общие сведения об уровнях изоляции на основе управления версиями строк.

В любом случае, без исчерпывающего тестирования вы, вероятно, внесете в систему совершенно новый набор проблем.

Я полагаю, что это даст нам что-то ближе к оракулу, когда, если одна транзакция обновляет, другие транзакции могут все еще прочитать старые данные. Это верно?

Да, это правильно .

Стоит прочесть ссылки в ответе gbn, и я считаю, что то же самое относится к стандартному стандарту MVCC Oracle и SQL Server в режиме изоляции моментальных снимков. Я хотел бы добавить, что если вы понимаете потенциальные ловушки, преимущества IMO намного перевешивают дополнительные трудности (если говорить с точки зрения Oracle) - и, конечно, некоторые проблемы с блокировками законно исчезают, в этом суть MVCC (также существует класс проблемы с блокировкой, которые не исчезнут из-за проблем с кодом, но я предполагаю, что вы понимаете это).

Мы используем SNAPSHOT ISOLATION во всех наших проектах, в которых используется БД SQL Server. Не более 1205 ошибок SQL, которые вызваны не из-за неправильного кода приложения, а из-за блокировки страниц по умолчанию и поведения блокировки строк.

Влияние на производительность минимально, и к настоящему времени прошло уже 7 лет, сотни миллионов операций были обработаны в разных системах без каких-либо проблем, связанных с SNAPSHOT ISOLATION.

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

Если у вас есть система OLTP, которая по проекту обновляет одну строку на основе данных текущей строки во многих потоках, конечно, SNAPSHOTS в таких случаях неприемлемы.

у нас он был активен, и странный оператор select sql, работающий на 4, когда-либо блокировал всю базу данных, независимо от того, сколько ядер и все. Отключение RCSI исправило это. Я бы включил его, как только вы столкнулись с другими тупиками, не по умолчанию.