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

Я прочитав тут, що деякі додаткові дані будуть зберігатися в рядку, щоб ми могли побачити зниження продуктивності, але які існують інші ризики?

напр. Чи вплине це на відновлення бази даних? Чи потрібно ще щось зробити, щоб скористатися цим?

Я планую виконати ці команди:

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

Я вважаю, що це дасть нам щось ближче до Oracle, коли, якщо одна транзакція оновлюється, інші транзакції все ще можуть читати старі дані. Це правильно?

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

Підсумок

1. Якщо у вас проблеми з блокуванням, у вас є проблема з вашим кодом: це не двигун бази даних
2. Це не чарівна куля
3. Ви можете додати більше проблем

Навантаження

Це також збільшить навантаження на ваш tempdb та процесор . Також дивіться:

• "Вплив на продуктивність: Потенційна вартість Read_Committed_Snapshot" (Лінчі Ши)

Безпека

Найголовніше, що ізоляція знімків у багатьох випадках не є безпечною за замовчуванням . Прочитайте "Ізольованість знімків" (Вікіпедія) для отримання додаткових відомостей про аномалії перекосу. Наступний розділ - "Зробити серійний знімок знімків", щоб обійти це.

Таким чином, загалом, ізоляція знімків ставить перед проблемою певну проблему збереження нетривіальних обмежень перед користувачем, який може не оцінити ні потенційні підводні камені, ні можливі рішення. Перевагою цієї передачі є краща ефективність.

Також дивіться:

• "Потенційні небезпеки рівня читання знімків, здійснених під час читання" (JimMcLeod, спір у коментарях Олексія Кузнецова)
• Тупик !: "Почитав зроблений знімок" Пояснив (Нік Берарді)
• Серіалізабельність та рівень ізоляції знімків, проблема з мармуром (Крейг Фрідман)
• Читання, що стосуються 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, заяви при читанні скористаються версією версій. Зверніть увагу, це версія версії рядка на рівні заяви лише для читання . Для оновлень вилучається "справжній" рядок і застосовуються блокування оновлень. Див. Розділ «Підсумок поведінки» в розділі « Розуміння рівнів ізоляції на основі рядків»

Будь-який маршрут, без вичерпного тестування, ви, ймовірно, внесете абсолютно новий набір проблем у систему.

Я вважаю, що це дасть нам щось ближче до Oracle, коли, якщо одна транзакція оновлюється, інші транзакції все ще можуть читати старі дані. Це правильно?

Так, це правильно .

Варто прочитати посилання у відповіді gbn, і я вважаю, що те саме стосується і MVCC за замовчуванням Oracle, як і для SQL Server у режимі Snapshot Isolation. Я додам, що якщо ви розумієте потенційні підводні камені, переваги ІМО набагато перевищують додаткові труднощі (якщо говорити з точки зору Oracle) - і, звичайно, деякі проблеми з блокуванням законно відходять, це суть MVCC (є також клас MVCC проблеми з блокуванням, які не усунуться через проблеми з кодом, але я припускаю, що ви це розумієте).

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

Вплив на продуктивність мінімальний, і поки минуло 7 років, сотні мільйонів операцій були оброблені в різних системах, без проблем щодо ІЗОЛЯЦІЇ SNAPSHOT.

Ситуації, коли декілька різних потоків оновлюють критичну інформацію про бізнес в одному ряду паралельно, є надзвичайно винятковими, а шанси, що ІЗОЛЯЦІЯ СНАПШОТИ стане причиною будь-якої проблеми невідповідності, дуже близькі до нуля.

Якщо у вас є система OLTP, то, оновлюючи дизайн одного рядка на основі даних поточних рядків у багатьох потоках, звичайно, SNAPSHOTS неприйнятні в таких випадках.

у нас це було активним, і дивна заявка для вибору sql під керуванням 4 колись блокувала весь db незалежно від кількості ядер і всього. Вимкнення RCSI вимкнено. Я б увімкнув це колись перед іншими тупиками, а не за замовчуванням.