Реферат: Версионность в Yukon
После ее выполнения сервер не сразу переключает базу в версионный режим, а переводит механизм поддержки версионности (snapshot isolation framework) в состояние PENDING_ON, поскольку в этот момент в базе могут быть активные транзакции. После завершения всех активных транзакций над базой производятся все необходимые изменения, механизм версионности для нее переводится в состояние ON, и появляется возможность выполнять версионные запросы. Обратное действие осуществляется также в два этапа, сначала БД переводится в состояние PENDING_OFF, а потом уже отключается механизм поддержки версионности.
Проверить состояние всех баз на сервере можно с помощью вот такого запроса:
| SELECT name, snapshot_isolation_framework FROM sys.databases |
Здесь «snapshot_isolation_framework» можетприниматьследующиезначения: 0 – OFF,1 – ON, 2 – PENDING_OFF, 3 – PENDING_ON.
Механизм поддержки версионности отвечает за сохранение копий данных, выборку нужных версий при версионных запросах, автоматическое определение конфликтов при изменениях и выполняет остальную рутинную работу по поддержке версионности. Он является не отдельной службой или модулем, а относительно простым набором алгоритмов, которые включаются в работу при переводе базы в соответствующее состояние.
Физически механизм версионности в Yukon отслеживает изменение данных отдельно для каждой записи. Для этого к записи добавляется кусочек длиной в 14 байт, в котором хранится идентификатор транзакции, изменившей эту запись, и ссылка на предыдущую зафиксированную версию. Таким образом, все версии одной записи образуют связный список, и серверу в случае необходимости не составляет никакого труда спуститься по цепочке ссылок к нужным данным.
|
ПРИМЕЧАНИЕ В том случае, если на странице данных не хватает места под дополнительные 14 байт на каждую запись, то во время перевода базы в «версионное» состояние данные будут автоматически перераспределены по страницам. |
Все версии записи собираются в специальном хранилище (version store heaps), которое расположено в tempdb. При любом изменении записи предыдущая версия копируется в это хранилище.
Благодаря особенностям tempdb и отсутствию журналирования для хранилища версий при обслуживании и чтении копий данных, нагрузка на операции ввода/вывода обещает быть минимальной.
Те устаревшие копии данных, которые уже точно не будут нужны ни одной транзакции, удаляются из tempdb автоматически. При этом отслеживается старейшая заинтересованная транзакция. Поэтому исключается вероятность того, что сервер в какой-то момент не найдет нужную версию. Удаление производит специальный механизм, который учитывает текущую нагрузку, через количество активных версионных транзакций, и процент свободного места в tempdb.
Для оценки предполагаемого размера хранилища версий предлагается следующая формула: Size (KB) = частота обновления версий (Version generation rate) Kb/sec. * время выполнения самой длинной транзакции (the longest transaction time) sec.
Как это работает
Здесь опять-таки проще всего разобрать по очереди все уровни изоляции предлагаемые Yukon снизу вверх.
Read uncommitted
В чистом версионнике, как уже говорилось, read uncommitted обычно не предусмотрен, да и не нужен. В Yukon при запросах к БД с включенной поддержкой версионности такой фокус тоже провернуть не получится. Даже при явном указании соответствующих подсказок оптимизатору в запросе, возвращается предыдущая зафиксированная версия, а не грязные данные транзакции, заблокировавшей запись от изменений.
Read committed
С read committed всенесколькосложнее. После включения поддержки версионности все запросы на чтение при этом уровне изоляции автоматически начинают работать как версионные. То есть если транзакция при чтении натыкается на заблокированную запись, то она читает предыдущую версию этой записи из tempdb.
|
ПРИМЕЧАНИЕ На самом деле в alpha-версии Yukon для поддержки версионности при read committed необходимо включить специальный трейс-флаг (3970). Но Microsoft торжественно клянется, что в финальном продукте все будет происходить автоматически. |
Можно провести простенький эксперимент. Пусть есть небольшая табличка tst в БД с поддержкой версионности, например, AdventureWork, созданная с помощью вот такого скрипта:
|
CREATE TABLE tst(x int, y int) GO INSERT INTO tst(x, y) VALUES(1, 5) INSERT INTO tst(x, y) VALUES(2, 4) INSERT INTO tst(x, y) VALUES(3, 3) INSERT INTO tst(x, y) VALUES(4, 2) INSERT INTO tst(x, y) VALUES(5, 1) |
Сначала откроем новое подключение, откроем read committed-транзакцию и сделаем выборку, транзакцию при этом закрывать не будем.
|
SET TRANSACTION ISOLATION LEVEL READ COMMITTED BEGIN TRAN К-во Просмотров: 345
Бесплатно скачать Реферат: Версионность в Yukon
|