Блокировки в MS SQL Server 2000
Категория реферата: Рефераты по информатике, программированию
Теги реферата: реферат на тему мыло, контрольная работа 7
Добавил(а) на сайт: Васёна.
Предыдущая страница реферата | 32 33 34 35 36 37 38 39 40 41 42 | Следующая страница реферата
4 – уровень изоляции SERIALIZABLE.
Теперь рассмотрим, каким образом управлять уровнем изоляции транзакций на уровне отдельных команд. Вот синтаксис раздела FROM, который относится к нашей теме (все сказанное ниже относится не только к запросам, но и к командам изменения данных DELETE и UPDATE):
|
FROM { < table_source > } <table_source> ::= table_name [ [ AS ] table_alias ] [ WITH ( < table_hint > [ ,...n ] ) ] < table_hint > ::=
|
Уровни READUNCOMMITTED и READCOMMITTED соответствуют одноименным уровням изоляции транзакций, только пишутся слитно. Блокировки при использовании этих уровней снимаются сразу после выполнения команды. В случае хинтов REPEATABLEREAD и SERIALIZABLE блокировки остаются до конца транзакции. Далее приводится подробное описание всех остальных хинтов.
FASTFIRSTROW – хинт не относится к блокировкам и уровням изоляции. Позволяет быстро выбрать первые строчки результирующего набора.
HOLDLOCK – аналогичен хинту SERIALIZABLE, т.е. устанавливает разделяемую блокировку диапазона индекса (если индекс существует) или простую разделяемую блокировку на страницу или таблицу. Оставлен для обратной совместимости.
NOLOCK – разрешается использовать только с командой SELECT. Аналогичен хинту READUNCOMMITTED, т.е. не накладывает никаких блокировок и игнорирует блокировки других транзакций.
PAGLOCK – пожелание менеджеру блокировок устанавливать блокировки на уровне страниц. Это пожелание выполняется очень редко.
READPAST – разрешается использовать только с командой SELECT. Позволяет выбрать только те строки, на которые не установлена монопольная блокировка. Другими словами, позволяет выбрать все не измененные строки.
ROWLOCK – пожелание менеджеру блокировок устанавливать блокировки на уровне строк. Это пожелание выполняется очень редко.
TABLOCK – позволяет установить на всю таблицу блокировку, тип которой зависит от команды, в которой этот хинт используется. Для команды SELECT будет установлена разделяемая блокировка на всю таблицу до тех пор, пока команда не выполнится, но не до конца транзакции. Действие хинта можно продлить с помощью HOLDLOCK. Например:
|
select * from test with(tablock,holdlock) |
Установит разделяемую блокировку до конца транзакции.
TABLOCKX – устанавливает монопольную блокировку на всю таблицу до конца транзакции даже для команды SELECT.
UPDLOCK – разрешается использовать только с командой SELECT. Позволяет установить блокировку обновления вместо разделяемой блокировки. Действие блокировки продолжается до завершения транзакции.
XLOCK – Действие аналогично хинту UPDLOCK с той лишь разницей, что устанавливается монопольная блокировка на ресурс.
Теперь давайте рассмотрим примеры их использования. Итак, у нас имеется таблица test следующего содержания (таблица 13).
|
i |
n |
|
1 |
alex |
|
2 |
rosa |
|
3 |
dima |
Начнем с монопольных блокировок. В первой сессии выполните команду:
|
update test set n = 'other' where i = 2 |
К тому же результату (наложение монопольной блокировки на строку) привела бы команда
|
select * from test with(xlock) where i = 2 |
Теперь, во второй сессии:
|
select * from test with (nolock) |
Вторая сессия не заблокировалась и выдала три строчки, включая измененную. Если бы мы не указали хинта nolock, сессия заблокировалась бы, так как по умолчанию установлен режим изоляции READ COMMITTED. Этому режиму необходима разделяемая блокировка, но так как монопольная блокировка не совместима ни с какой другой, менеджер блокировок заблокировал бы сессию.
Еще один интересный результат можно получить с помощью следующей команды (во второй сессии):
|
select * from test with (readpast) |
Результаты ее выполнения зависят от того, какую команду мы выполнили в первой сессии. Если выполнялся запрос с хинтом xlock, результирующий набор будет содержать все строки таблицы. Однако если была выполнена команда UPDATE, SQL Server выдаст нам всего две строчки: 1 и 3. Такое поведение, признаться, для меня явилось неожиданностью, так как блокировки, накладываемые этими командами, полностью совпадают. У меня возникло предположение, что сервер каким-то образом помечает действительно измененные строки или вообще не вносит их в файл базы данных. Чтобы получить больше информации по этому поводу, воспользуемся очередной недокументированной возможностью, позволяющей просматривать физическое содержимое данных.
Но сначала я бы хотел рассмотреть содержимое колонки Resources, которую возвращает хранимая процедура sp_lock. Значение это состоит из трех цифр, разделенных двоеточием, первое из которых означает номер файла в базе данных, второе – номер страницы и третье – номер строки. Таким образом, запись 1:31:2 означает вторую строку на странице 31 в первом файле базы данных.
Вот синтаксис команды, с помощью которой можно получить физическое содержимое таблицы:
|
DBCC PAGE (dbid, filenum, pagenum [,print option] [,cache]) |
dbid – идентификатор базы данных; dbname – название базы данных;
filenum – идентификатор файла базы данных;
pagenum – идентификатор страницы
print option – флаги вывода информации. Может принимать значения, приведенные в таблице 14.
|
Значение |
Описание |
|
0 |
Установлен по умолчанию. Выводится только заголовок страницы. |
|
1 |
Выводится заголовок страницы и содержимое каждой строчки. |
|
2 |
Выводится заголовок страницы и полный дамп памяти. |
|
3 |
Относительно новый флаг, который аналогичен флагу 1, с той разницей, что значения форматируются в удобочитаемый вид для каждой колонки. |
cache – флаг, указывающий, выбирать данные из кэша или нет. Если 1 (по умолчанию), данные выбираются из кэша, 0 – с диска.
Откроем новую сессию и выполним следующий набор команд (у меня база, в которой содержится таблица test, имеет идентификатор 8):
|
dbcc traceon (3604) dbcc page(8,1,31,3,1) dbcc traceoff (3604) |
Приведу результат, выводимый данной командой:
|
PAGE: (1:31) ------------ BUFFER: ------- BUF @0x00D88500 --------------- bpage = 0x19548000 bhash = 0x00000000 bpageno = (1:31) bdbid = 8 breferences = 1 bstat = 0xb bspin = 0 bnext = 0x00000000 PAGE HEADER: ------------ Page @0x19548000 ---------------- m_pageId = (1:31) m_headerVersion = 1 m_type = 1 m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x0 m_objId = 1993058136 m_indexId = 0 m_prevPage = (0:0) m_nextPage = (0:0) pminlen = 8 m_slotCnt = 3 m_freeCnt = 8026 m_freeData = 247 m_reservedCnt = 0 m_lsn = (6:181:2) m_xactReserved = 0 m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = 0 Allocation Status ----------------- GAM (1:2) = ALLOCATED SGAM (1:3) = ALLOCATED PFS (1:1) = 0x61 MIXED_EXT ALLOCATED 50_PCT_FULL DIFF (1:6) = CHANGED ML (1:7) = NOT MIN_LOGGED Slot 0 Offset 0x60 ------------------ Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP VARIABLE_COLUMNS 19548060: 00080030 00000001 02000002 15001100 0............... 19548070: 656c6100 78 .alex i = 1 n = alex Slot 1 Offset 0xe1 ------------------ Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP VARIABLE_COLUMNS 195480E1: 00080030 00000002 02000002 16001100 0...............
Предыдущая страница реферата | 32 33 34 35 36 37 38 39 40 41 42 | Следующая страница реферата Поделитесь этой записью или добавьте в закладкиКатегории: |