Оптимистичный параллелизм требует больше ресурсов и стоит дороже при возникновении конфликта.
Два сеанса могут читать и изменять значения, и конфликт возникает только тогда, когда они пытаются применить свои изменения одновременно. Это означает, что в случае одновременного обновления оба значения должны храниться где-то (что, конечно, требует ресурсов).
Кроме того, при возникновении конфликта обычно необходимо откатить всю транзакцию или повторно установить курсор, что тоже дорого.
Модель пессимистического параллелизма использует блокировку, что снижает уровень параллелизма, но повышает производительность.
В случае двух одновременных задач для второй задачи может быть дешевле дождаться освобождения блокировки, чем тратить CPU время и диск I/O на две одновременные работы, а затем еще больше на откат менее удачливого работать и переделывать.
Скажем, у вас есть такой запрос:
UPDATE mytable
SET myvalue = very_complex_function(@range)
WHERE rangeid = @range
, с very_complex_function чтением некоторых данных из самого mytable. Другими словами, этот запрос преобразует подмножество mytable с общим значением range.
Теперь, когда две функции работают в одном диапазоне, может быть два сценария:
Пессимистично: первый запрос блокируется, второй запрос ждет его. Первый запрос завершается за 10 секунд, второй тоже. Итого: 20 секунд.
Оптимистично: оба запроса работают независимо (на одном входе). Это делит CPU время между ними плюс некоторые накладные расходы на переключение. Они должны где-то хранить свои промежуточные данные, поэтому данные хранятся дважды (что подразумевает дважды I/O или память). Допустим, оба завершены почти одновременно, за 15 секунд.
Но когда пришло время зафиксировать работу, второй запрос будет конфликтовать и должен будет откатить свои изменения (скажем, это займет те же самые 15 секунд). Затем необходимо снова перечитать данные и снова выполнить работу с новым набором данных (10 секунд).
В результате оба запроса завершаются позже, чем с пессимистической блокировкой: 15 и 40 секунд против 10 и 20.
Когда в SQL Server2005 + понадобятся пессимистичные уровни / подсказки изоляции TX +, если позднее предусмотрена встроенная оптимистическая (или снимок или версия) изоляция параллелизма?
Оптимистичные уровни изоляции, ну, в общем, оптимистичные. Вам не следует использовать их, когда вы ожидаете высокой конкуренции за ваши данные.
Кстати, оптимистическая изоляция (для запросов на чтение) была доступна и в SQL Server 2000.