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

Question

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

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

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

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

Answer 1

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

`ALTER DATABASE AdventureWorks SET READ_COMMITTED_SNAPSHOT ON;

ALTER DATABASE AdventureWorks SET ALLOW_SNAPSHOT_ISOLATION ON; `

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

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

ALTER DATABASE adventureworks SET read_only

Answer 5

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

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

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

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

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

Answer 6

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