Wow - так много информации о том, почему следует избегать обоих вариантов.
В NOLOCK или НЕ в NOLOCK, вот вопрос
http://www.jimmcleod.net/blog/index.php/2009/08/27/the-potential-dangers-of-the-read-committed-snapshot-isolation-level/
Некоторые говорят, что нужно идти вперед и использовать фиксацию чтения и использовать подсказки блокировки.Другие говорят, что вы должны избегать намеков на блокировку.
Включение чтения-фиксации может привести к очень неожиданному поведению, я думаю, что многие типичные приложения в том, как системы переносят базовый код транзакции.
Итак, проблема остается для нас.В производственной системе мы видим много блокирующих запросов после миграции Sybase.Время транзакции чрезвычайно важно для нас - некоторые блокируют на 10+ секунд - повсюду.
Если кто-то хочет избежать техник - я хотел бы понять некоторые внутренние механизмы того, что здесь происходит.Может ли эта проблема всегда быть решена с помощью более подходящих / правильных индексов или же переключение индексов в запросах по-прежнему вызывает блокировки (например, обновление может использовать один некластеризованный индекс для поиска и кластеризованный индекс для блокировки строк)
Допустим, мы делаем следующее:
Выбор * из Customer Where CreatedDate> '6/30/2011'
CreatedDate имеет индекс, но, очевидно, не является ключом.
Мы наблюдаем подобные случаи, приводящие к тому, что блоки (не тупики, а долгие ожидания) для таких операторов, как (это просто демонстрационный код для демонстрации похожего сценария)
Обновление набора клиентов OrderReviewed = 1 Где CreatedDate Between '6/24/ 2011 'и' 7/2/2011 '
Некоторые говорят, что Выберите * из клиента с (nolock), где CreatedDate>' 6/30/2011 '
Это путь, однакоТак как Клиент может быть удален, разделен на страницы и т. д., вы можете страдать от множества проблем.
Мы не можем включить READ_COMMITTED_SNAPSHOT сейчас для потенциального воздействия приложения.
У нас есть индекс CreatedDate - так что ... что еще можно сделать?
Я ищу здесь совет специалиста - с хорошей технической информацией - а не что-то вроде 'turn profilerна «или« посмотрим, что блокирует », поскольку мы знаем, что блокирует , но не внутренние причины того, почему или лучший способ ее решения.