Счетчик выбора SQL Server READ_COMMITTED_SNAPSHOT QUESTION

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

Я также изменил базу данных, чтобы использовать READ_COMMITTED_SNAPSHOT изоляцию,

Тем не менее, кажется, что с помощью счетчика выбора (*) где столбец =? на столе вызывает взаимоблокировки или блокировки на столе ..

Верно ли, что выборочный счетчик (*) должен иметь доступ только к промежуточным строкам? Однако, это не так, и я все еще сталкиваюсь с тупиками. Правильная индексация, вероятно, поможет,

Вопрос заключается в следующем: устанавливает ли SQL Server 2008 R2 разделяемую блокировку для таблицы во время выбора счетчика (*), даже если для read_committed_snapshot установлено значение on?

Спасибо

— grassbl8d
источник

Вам нужен точный подсчет (по запросу) или приблизительный подсчет в порядке?

— Джон Зигель

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

— grassbl8d

Моя точка зрения заключалась в том, что если вы можете рассмотреть вопрос об изменении способа подсчета, это может быть способом решения проблемы взаимоблокировки. Но теперь, когда я снова читаю вопрос, если вам нужно использовать WHEREпредложение, метод, о котором я думаю, все равно не сработает.

— Джон Зигель

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

— Аарон Бертран

Ответы:

Будьте осторожны с READ_COMMITTED_SNAPSHOT: если вы установите его, это может вызвать множество тонких ошибок.

Также READ_COMMITTED_SNAPSHOT является уровнем изоляции по умолчанию, который может быть что-то переопределен. Запустите DBCC USEROPTIONS, чтобы определить фактический уровень изоляции, под которым работает ваш выбор.

Я бы явно установил SNAPSHOT УРОВНЯ ИЗОЛЯЦИИ СДЕЛКИ прямо перед вашим выбором. Таким образом, вы будете уверены, что ваш выбор никогда не попадет в тупики, и вы не нарушите никакой другой код, как READ_COMMITTED_SNAPSHOT.

— Аляска
источник

Блокировка с изоляцией моментального снимка не изменяется. Что изменится, так это то, что при изменении страниц под вами эти страницы копируются в базу данных tempdb, так что вы можете читать их из базы данных tempdb, а не из обычной базы данных. (Да, это упрощенная версия происходящего.)

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

Какой уровень изоляции использует ваш запрос?

— mrdenny
источник

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

— grassbl8d

Да, замки все еще принимаются. Вы можете запросить sys.dm_tran_locks, чтобы увидеть принимаемые блокировки. Запустите ваш запрос в одном окне и запросите sys.dm_tran_locks в другом окне, чтобы увидеть, какие блокировки принимаются. Возможно, вы переходите к блокировкам таблиц и вам нужно использовать подсказку для принудительной блокировки страниц или даже строк.

— Мрденни