Описание параметров для явного задания блокировок

Параметр	Описание
UPDLOCK	Блокирует изменение значений таблиц, но дает возможность другим пользователям считывать информацию. Это состояние помогает предотвратить задержки, мешающие пользователям просматривать данные таблиц в то время, когда вы обновляете их значения. При задании этого параметра пользователи могут просматривать содержимое базы данных, но не могут обновлять заблокированные строки.
PAGLOCK	Явно задает SOL Server разделяемые блокировки страниц. Этот параметр можно использовать только если вы задаете для таблицы блокировку TABLOCLKX.

Параметр NOLOCK дает возможность считывать в запросе "грязные" (dirty) данные.

Параметр HOLDLOCK: выполнение обычной инструкции SELECT для таблицы на время выборки данных вызывает разделяемую блокировку страницы. Разделяемая блокировка не запрещает другим пользователям обновлять записи или пытаться получить эксклюзивную блокировку страницы данных, с которой в этот момент работает инструкция SELECT. Разделяемая блокировка снимается со страницы данных, как только инструкция SELECT начинает выборку следующей страницы. Если из-за необходимости менять направление просмотра результирующего набора (назад и вперед) вы хотите обеспечить целостность данных на все время жизни инструкции SELECT, используйте команду HOLDLOCK. Эта команда заставит SQL Server сохранять разделяемую блокировку до окончания транзакции.

При задании команды TABLOCK в инструкции SELECT на все время выполнения инструкции блокируется вся таблица (или таблицы), указанная в инструкции. Параметр TABLOCKX вызывает монопольную блокировку таблицы на все время действия транзакции, запрещая всем остальным пользователям доступ к таблице до момента окончания транзакции.

В SQL Server 2000 добавлены следующие уровни блокировки:

• ROWLOCK — предписывает использовать блокировку на уровне строки, вместо страничных и табличных;

• READPAST — вместо перевода процесса в состояние ожидания заблокированные записи пропускаются; применяется только к инструкции SELECT на уровне изоляции read commited.

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

С помощью инструкции DBCC OPFNTRAN, можно получить список открытых транзакций и решить проблему.

В качестве примера рассмотрим следующую ситуацию: разработчик открыл транзакцию, выполнил входящие в нее операции и убедился, что код выполнен правильно. Когда выяснилось, что результаты транзакции в базе данных отсутствуют, разработчик решил перезапустить SQL Server. После перезапуска SQL Server восстановил базу данных, но тем не менее данные снова не изменились.

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

В случае сомнений лучше лишний раз проверить наличие действующих процессов. Кроме этого убедитесь, что проверены открытые (или действующие) блокировки. Вы можете также избежать многих проблем, если установите небольшую систему обработки ошибок и воспользуетесь внутренней переменной SQL Server @@TRANCOUNT, которая при выходе из хранимой процедуры подтверждает, что связанные с ней транзакции завершены успешно.