В сценарии хранилища данных есть ли какие-либо недостатки при использовании With(NOLOCK)

Question

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

Я понимаю WITH(NOLOCK) может привести к чтению незафиксированных данных, однако я также не хочу создавать какие-либо блокировки, которые могли бы привести к сбою или блокировке процессов ETL.

Во всех случаях, когда мы читаем из хранилища данных, мы читаем из таблиц фактов на дату, которая не изменится (таблицы фактов секционированы по дате), и таблиц измерений, атрибуты которых не будут изменяться для фактов, с которыми они связаны. .

Итак – есть ли недостатки?- возможно, в планах выполнения или в эксплуатации таких SELECT-только запросы, выполняемые параллельно с одними и теми же таблицами.

Answer 1

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

Answer 2

Это то, что вам, вероятно, нужно:

`ALTER DATABASE AdventureWorks     SET READ_COMMITTED_SNAPSHOT ON;

ALTER DATABASE AdventureWorks     SET ALLOW_SNAPSHOT_ISOLATION ON; `

Тогда иди и используй

УСТАНОВИТЕ УРОВЕНЬ УРОВНЯ ИЗОЛЯЦИИ СДЕЛКИ

в ваших запросах. По данным BOL:

Поведение READ COMMITTED зависит от настройки параметра базы данных READ_COMMITTED_SNAPSHOT:

Если для READ_COMMITTED_SNAPSHOT установлено значение OFF (по умолчанию), компонент Database Engine использует общие блокировки для предотвращения изменения строк другими транзакциями, когда текущая транзакция выполняет операцию чтения. Общие блокировки также блокируют оператор от чтения строк, измененных другими транзакциями, пока другая транзакция не будет завершена. Тип общей блокировки определяет, когда она будет снята. Блокировки строк снимаются до обработки следующей строки. Блокировки страниц снимаются при чтении следующей страницы, а блокировки таблиц снимаются по завершении инструкции.

Если для READ_COMMITTED_SNAPSHOT установлено значение ON, компонент Database Engine использует управление версиями строк для представления каждого оператора с согласованным с точки зрения транзакций моментальным снимком данных в том виде, в каком он существовал в начале оператора. Блокировки не используются для защиты данных от обновлений другими транзакциями.

Надеюсь, это поможет. Радж

Answer 3

Рассматривали ли вы создание базы данных SNAPSHOT вашего DW и запустить ваши отчеты от него?

Answer 4

Да.Ваш SQL будет гораздо менее читаемым.Вы неизбежно пропустите некоторые подсказки NOLOCK, поскольку командам SQL SELECT, использующим стратегию NOLOCK, придется размещать их повсюду.

Вы можете получить то же самое, установив уровень изоляции

УСТАНОВИТЬ УРОВЕНЬ ИЗОЛЯЦИИ ТРАНЗАКЦИИ ЧТЕНИЕ НЕЗАВЕРШЕНО

В итоге вы получаете прирост производительности на 10% (извините, мне лень искать эту статью, но она есть)

Я бы сказал, что выигрыш в 10% не стоит снижения читабельности.

Answer 5

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

ALTER DATABASE adventureworks SET read_only

Answer 6

NOLOCK выполняет & # 8216; грязное чтение & # 8217; (неприлично READ UNCOMMITTED делает то же самое, что NOLOCK). Если база данных обновляется во время чтения, существует опасность, что вы получите противоречивые данные обратно. Единственный вариант - либо принять блокировку и, следовательно, блокировку, либо выбрать один из двух новых уровней изоляции, предлагаемых в SQL 2005 и далее обсуждается здесь .