Параметры для установки подсказки NOLOCK в запросах к набору данных

7

Немного контекста.
Сначала мы писали отчеты «прямо вверх», без каких-либо подсказок по блокировке в запросах. При больших отчетах это иногда вызывает проблемы с блокировкой. В первом мы исправить это с помощью WITH (NOLOCK)подсказки для таблиц в запросе.

Потому что (а) это довольно навязчивое, и (б) легко забыть намек на один из столов, мы перешли к настройкам второго подхода TRANSACTION ISOLATION LEVELк READ UNCOMMITTED(это хорошо) в верхней части запроса каждого набора данных.

Как вы можете догадаться, все еще легко забыть подсказку для одного из наборов данных. Так что это приводит к вопросу:

Вопрос: Какие есть варианты отправки NOLOCKподсказок вместе с запросами к отчету?

PS. Я понимаю, что это в некоторой степени проблема XY (со многими другими моими опциями для X, такими как оптимизация запроса, не ведение отчетов в оперативной базе данных и т. Д.), Но, тем не менее, попытался сделать этот вопрос правильным для себя. ,

Опции:
Вот опции, упомянутые выше, с добавленными опциями, о которых мне интересно, будут ли они работать:

  1. Установить WITH (NOLOCK)подсказку для каждой таблицы. (навязчиво, очень легко забыть)
  2. Установите уровень изоляции READ UNCOMMITTEDдля всего запроса. (все еще легко забыть)
  3. Можно ли указать это на уровне отчета ? Например, убедитесь, что все запросы к набору данных для одного отчета будут выполняться без блокировки.
  4. Можно ли указать это на каком-то другом уровне SSRS ? Например, возможно установить это для определенной папки отчетов или с помощью расширения?
  5. Можно ли указать это на уровне источника данных / строки подключения ? Например, все ли соответствующие отчеты используют определенный «источник данных без блокировки»?
  6. Относительно предыдущего варианта: возможно, можно указать подсказку по умолчанию для конкретного «no-lock-sql-user» (который используется в соединении)?
  7. ???

Какие варианты являются жизнеспособными? Есть ли варианты, которые я пропустил?

sql-server locking ssrs Йерун
источник
Проблема с переходом на nolocks везде или с изменением изоляции для чтения незафиксированных данных по всем направлениям - это проблема качества данных. Вы не просто получаете грязное чтение, но потенциально можете вернуть одни и те же данные дважды или вообще пропустить данные. Может быть, лучше взглянуть на свой дизайн и посмотреть, не пора ли для отдельной базы данных отчетов. Смотрите этот вопрос
Майк Уолш
@MikeWalsh Согласен. Это то, к чему я также попытался рассказать немного о проблеме XY. Тем не менее, знание, где и когда есть возможность использовать подсказки блокировки, может быть полезным, если использовать его с осторожностью.
Йерун

Ответы:

5

Быстрые ответы:

  1. Работает, как вы заметили.
  2. Работает, как вы заметили.
  3. Это не похоже на работу. Я не видел опцию без присмотра, и всякий раз, когда задают этот вопрос, ответ всегда возвращается к установке уровня изоляции в хранимой процедуре .
  4. Я бы не поверил в это. SSRS находится на более высоком уровне абстракции, чем ядро ​​базы данных, поэтому в некотором смысле его не волнует, каков уровень изоляции - в конце концов, вы можете использовать не-RDBMS-решения в своих отчетах.
  5. Это не работает. Вы не можете установить уровень изоляции в строке подключения .
  6. Это может сработать. Вы можете создать триггер входа в систему .

Есть несколько вариантов, которые являются жизнеспособными, если отчеты оптимизированы и все еще вызывают проблемы:

  1. Используйте Always On, если у вас SQL 2012. После этого вы можете иметь реплику только для чтения, которую могут использовать ваши отчеты SSRS.
  2. Используйте replication: снимок, если вам не нужно в режиме реального времени, и транзакционный, если вам нужно, чтобы он был близок к реальному времени.
  3. Если у вас нет бюджета на Always On или терпения, чтобы справиться с репликацией, сделайте репликацию по дешевке: создайте удобную для отчетов схему (т. Е. Денормализуйте таблицы и поместите их в формат, облегчающий запуск отчетов). ) и использовать SSIS для подачи этой схемы отчета. Это работает лучше, если ваши конечные пользователи могут жить со «старыми» данными (например, обновляя почасово или каждые 5 минут). Недостатком является то, что вы будете проектировать модель данных дважды: один раз для модели OLTP и один раз для модели псевдохранилищ. Плюс в том, что если вы когда-нибудь будете двигаться в направлении централизованного хранилища данных, это очень полезное упражнение.
Кевин Физель
источник
6

Рассматривали ли вы READ_COMMITTED_SNAPSHOTверсионирование строк для базы данных?

У Ким Трипп есть хорошая статья об этом на http://msdn.microsoft.com/en-us/library/ms345124%28v=sql.90%29.aspx

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

Макс Вернон
источник