MS SQL параллелизм, избыточные блокировки

Question

У меня есть база данных на MS SQL 2000, которая поражает сотни пользователей одновременно. Существуют интенсивные отчеты, использующие службы отчетов 2005, попавшие в одну и ту же базу данных.

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

Существует ли глобальный способ минимизации блокировок, чтобы транзакция продолжала выполняться.

Answer 1

В отчетах можно использовать WITH(NOLOCK).

Другие возможности - запуск отчетов из реплики базы данных, доступной только для чтения, или запуск версии базы данных хранилища данных, оптимизированной для нужд отчетности.

Answer 2

Поскольку вы уже используете подсказки NOLOCK и уровень изоляции READ UNCOMMITTED для своих отчетов, расследование должно быть обращено к входящим транзакционным запросам. Это может стать глубоким. Возможно, приложения слишком долго держат транзакции открытыми. Также может быть так, что у вас есть много табличных или диапазонов сканирования в некотором другом объеме запроса, и они могут содержать общие блокировки для длительных транзакций. Эти общие блокировки блокируют ваших писателей.

Вам нужно начать смотреть на sp_lock, посмотреть, какие блокировки выдаются, посмотреть, какие блокировки пытаются получить заблокированные запросы, а затем изучить запросы, блокирующие запросчики.

Это поможет вам, если вы не знакомы с блокировкой SQL Server: Общие сведения о блокировке SQL Server 2000

Также, возможно, вы могли бы описать вашу дисковую подсистему. Может быть меньше.

Answer 3

Используйте оптимистическую блокировку, если обновления происходят не часто и база данных в основном используется для отчетов.

SQL Server имеет довольно пессимистическую блокировку по умолчанию.

Просмотр Советы по таблице SQL Server может помочь вам начать работу.

Answer 4

Спасибо всем за вашу поддержку. Чтобы смягчить проблему, мы каждый час создавали новую базу данных с процедурой отправки журналов, чтобы синхронизировать ее с реальной. Отчеты, которые не нуждаются в данных в реальном времени, указывают на эту базу данных, и те, которым нужны данные в реальном времени, где они ограничены, поэтому только несколько человек могут получить к ним доступ. Недостатки метода в том, что данные будут синхронизированы до одного часа, и нам нужно создать новый сервер только для этой цели. Кроме того, при запуске процедуры loggshipping каждое соединение прерывается на очень короткий период времени, но это может быть проблемой для действительно длинных процедур или отчетов. После этого я проверю запросы из отчетов, чтобы понять, что можно оптимизировать. Спасибо, и я порекомендую сайт всему ИТ-отделу.