Сегодня я хочу поговорить о табличной подсказке READPAST, которая появилась впервые в SQL Server 2005. Эта подсказка указывает, что компонент Database Engine не считывает строки и страницы, заблокированные другими транзакциями. Если указан аргумент READPAST, то блокировки уровня строк будут пропускаться. Компонент Database Engine будет пропускать строки вместо блокировки текущей транзакции до тех пор, пока блокировки не будут сняты.

Например, предположим, что в таблице T1 есть один целочисленный столбец со значениями 1, 2, 3, 4, 5. Если транзакция A изменит значение 3 на 8, но еще не будет зафиксирована, то инструкция SELECT * FROM T1 (READPAST) возвратит значения 1, 2, 4, 5. Параметр READPAST главным образом используется для устранения конфликта блокировок при реализации рабочей очереди, использующей таблицу SQL Server. Средство чтения очереди, использующее аргумент READPAST, пропускает прошлые записи очереди, заблокированные другими транзакциями, до следующей доступной записи очереди, не дожидаясь, пока другие транзакции снимут свои блокировки.

Аргумент READPAST можно задать для любой таблицы, к которой обращается инструкция UPDATE или DELETE, и к любой таблице, на которую ссылается предложение FROM. Если аргумент READPAST задан в инструкции UPDATE, он применяется только при считывании данных для идентификации подлежащих обновлению записей вне зависимости от того, где он указан в инструкции. Аргумент READPAST для таблиц из предложения INTO инструкции INSERT задать нельзя. Операции чтения, в которых используется аргумент READPAST, не блокируются. Операции обновления или удаления, использующие аргумент READPAST, могут блокироваться либо при считывании внешних ключей или индексированных представлений, либо при изменении вторичных индексов.

Аргумент READPAST можно указывать только в транзакциях, выполняемых на уровнях изоляции READ COMMITTED или REPEATABLE READ. При указании подсказки READPAST в транзакциях, выполняемых с уровнем изоляции SNAPSHOT, она должна использоваться в сочетании с другими табличными подсказками, требующими блокировки, например UPDLOCK или HOLDLOCK.

Табличная подсказка READPAST не может быть указана, если параметр базы данных READ_COMMITTED_SNAPSHOT установлен в ON и выполняется одно из следующих условий.

• Уровень изоляции транзакций сеанса имеет значение READ COMMITTED.
• В запросе также указана табличная подсказка READCOMMITTED.

Чтобы в этих случаях указать подсказку READPAST, удалите табличную подсказку READCOMMITTED (если существует) и включите в запрос табличную подсказку READCOMMITTEDLOCK.


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

Но так ли всё на самом деле? Или возможны исключения? Об этом чуть ниже.

[Ещё]

12 апреля 2012 состоялась первая беспрецедентная нон-стоп конференция 24 Hours of PASS. Russian Edition.

В рамках этого мероприятия я рассказывал про недокументированные возможности SQL Server. И, как и обещал, выкладываю свою презентацию и скрипты к ней.

24HoursofPASS_a.knyazev.pdf (368,31 kb)

24PASS_DEMO.zip (7,29 kb)

Другие доклады:

• Конференция "24 Hours of PASS. Russian Edition"
• http://www.techdays.ru/videos/24%20HOP

[Ещё]

http://en.wikipedia.org/wiki/Microsoft_SQL_Server

[Ещё]

В текущих версиях SQL Server ( SQL Server 2008R2 и ниже ) операция добавления нового столбца NOT NULL с DEFAULT-значением может занять значительное время, если таблица имеет большой размер. Для небольших таблиц эта операция допустима, но, когда объём данных в таблице велик, то мы получаем блокировку Sch-M для таблицы на длительное время, т.к. при этой операции происходит построчное заполнение нового столбца значением по умолчанию.

В SQL Server 2012 ситуация кардинально изменилась, теперь при добавлении в таблицу нового NOT NULL столбца с DEFAULT-значением мы не производим физического изменения данных построчно, а лишь изменяем таблицу на уровне метаданных, поэтому операция практически мгновенна.

[Ещё]

- Процедура стала работать медленнее, чем обычно?
- Запрос выполняется быстро, а процедура, в которой подобный запрос, работает очень долго?
- У процедуры неоптимальный план запроса?

Если ответ "Да" хоть на один из вопросов, то эта статья для вас. Я расскажу и покажу, как можно повлиять на работу процедуры и быть уверенным, что в кэше окажется ожидаемый план запроса (а значит никаких больше сюрпризов) для вашей процедуры.

Тема не нова, но если вы это читаете, то моё время потрачено не зря.

[Ещё]

В одной из предыдущих заметок в своём блоге я писал о ряде сюрпризов, к которым нужно быть готовым при использовании "грязного чтения" (уровень изоляции READ UNCOMMITTED) - http://www.t-sql.ru/post/nolock.aspx.

А именно:

• "Фантомные" записи, которых нет в БД
• Чтение не всех записей из таблицы
• Чтение одной и той же записи несколько раз

Сегодня я покажу ещё один неприятный момент - это чтение промежуточного состояния изменяемой строки, т.е. при изменении записи в одной атомарной операции:

update MyTable 
set a = b
  , b = a

В другой транзакции с уровнем изоляции READ UNCOMMITTED можно прочитать запись, когда значение поля a уже равно b, а поле b ещё не изменено.
[Ещё]

Ещё один вопрос, который регулярно появляется на тематических форумах: "Как получить максимум из нескольких колонок одной таблицы?".
Любую задачу можно решить несколькими способами, эта не исключение. Я попытался собрать несколько вариантов для решения этого вопроса в этой заметке для разных версий SQL Server.
Кроме того, проведу небольшие замеры производительности всех рассмотренных примеров.

Буду рад, если вы предложите ещё несколько вариантов решения этой задачи и с удовольствием дополню эту статью позже.


[Ещё]

Собственно проблема озвучена в тебе этого поста. Если у вас на рабочей станции при двойном клике по файлам с расширением *.sql загружается новый экземпляр SSMS (SQL Server Management Studio), вместо того, чтобы открыть файл в новой вкладке уже открытой студии, то эта заметка для вас.

[Ещё]

[Ещё]