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

Немного контекста.
Сначала мы писали отчеты «прямо вверх», без каких-либо подсказок по блокировке в запросах. При больших отчетах это иногда вызывает проблемы с блокировкой. В первом мы исправить это с помощью 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. ???

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

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

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

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

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

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

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

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