Главная » Microsoft SQL Server, Базы данных » Архитектура журнала транзакций

0

Структура SQL Server удовлетворяет требованиям АСШ в основном за счет использования последовательного журнала транзакций, гарантирующего живучесть всех транзакций.

Последовательность работы с журналом транзакций

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

Начальное состояние базы данных

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

Некоторые страницы данных, вероятнее всего, уже кэшированы в память. Дополнительные страницы данных и индексов копируются в память по мере необходимости. Итак, приступаем к описанию последовательности действий в транзакции.

1.              База данных находится в целостном состоянии.

Команда модификации данных

Транзакция инициируется отправленным запросом, пакетом или хранимой процедурой, как показано на рис. 51.5.

2.              Программный код выполняет команду BEGIN TRANSACTION. Даже если инструкция DML является обособленной, т.е. не вложена в оболочку инструкций, BEGIN TRANSACTION и COMMIT TRANSACTION, она все равно обрабатывается как транзакция.

3.              В программном коде выполняется одна инструкция DML (INSERT, UPDATE или DELETE) или их последовательность.

Чтобы проиллюстрировать работу журнала транзакций, в следующем коде инициируется транзакция, после чего выполняются две команды обновления:

USE OBXKites;

BEGIN TRANSACTION;

UPDATE Product

SET ProductDescription = ‘Transaction Log Test A’,

DiscontinueDate = ’12/31/2003′

WHERE Code = ‘1001’;

UPDATE Product

SET ProductDescription = ‘Transaction Log Test B1, DiscontinueDate = ‘4/1/2003′

WHERE Code = 4002′;

Рис. 51.5. Инструкции SQL DML обрабатываются в памяти как часть транзакции

Обратите внимание на то, что транзакция не была подтверждена.

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

В следующем разделе мы продолжим нашу хронологическую экскурсию по транзакции.

Выполнение записи в журнал транзакций

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

5.              Изменения в данных записываются в журнал транзакций.

6.              Все записи DML подтверждаются в журнале транзакций. Это является фактической гарантией того, что эти записи в журнале транзакций действительно существуют.

Рис. 51.6. Команда COMMIT TRANSACTION запускает следующую вставку в журнап транзакций

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

Подтверждение транзакции

После того как последовательность задач будет выполнена, инструкция COMMIT TRANSACTION закрывает транзакцию, и следующая транзакция получает возможность записи в журнал (см. рис. 51.6).

7.              Следующий код закрывает транзакцию:

COMMIT TRANSACTION

Чтобы увидеть процесс отправки транзакции в журнал, обратитесь к ролику Transaction на сайте книги.

8.              Запись COMMIT вставляется в журнал транзакций.

9.              Запись COMMIT подтверждается в журнале транзакций (рис. 51.7).

Рис. 51.7. Просмотр подтвержденных транзакций в журнале с помощью сторонней программы ApexSQL Log

10.          В фоновом режиме, когда встречается контрольная точка (внутреннее событие SQL Server), процесс lazy writer записывает все черновые (модифицированные) страницы данных в файл данных. Этот процесс пытается найти последовательные страницы, чтобы ускорить запись. Несмотря на то что я упоминаю это действие под десятым номером, оно может произойти практически в любой момент транзакции. SQL Server получает от операционной системы Windows сообщение о завершении записи.

Рис. 51.8. Одним из последних действий является запись изменений в файл данных

После успешного сохранения транзакции в журнале транзакций последняя дисковая операция записывает изменения в файл данных (рис. 51.8).

Обновление файла данных

11.          В завершение фоновой операции записи SQL Server помечает самую последнюю открытую транзакцию в журнале. Теперь все подтвержденные транзакции, записанные в файл данных, подтверждены также и в журнале. С помощью команды DBCC Ореп- Тгап можно увидеть самую последнюю открытую транзакцию.

Завершение транзакции

Итак, описанная последовательность действий прошла полный цикл, и база данных вернулась в целостное состояние.

12.          База данных вернулась в целостное состояние.

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

Откат в журнале транзакций

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

Восстановление журнала транзакций

Основным достоинством журнала транзакций является то, что он поддерживает свойство атомарности транзакций в случае системного сбоя.

Если SQL Server перестает функционировать, журнал транзакций автоматически проверяется, как только сервер снова включается в работу. Все происходит так, как описано ниже.

?               Если в журнале содержатся какие-либо операции DML, которые не были подтверждены, они откатываются.

Для тестирования этого свойства нужно набраться храбрости. Начните транзакцию и до ее окончания выключите питание сервера. Обычное закрытие анализатора запросов не заменит этого, поскольку он запросит разрешение на завершение ожидающих транзакций и в случае получения отрицательного ответа от пользователя откатит их. Если остановить SQL Sever обычным образом, то перед фактическим остановом он завершит все ожидающие задачи. Поэтому, чтобы увидеть воочию процесс восстановления журнала транзакций, вам придется отключить компьютер от сети.

Если следовать описанной выше последовательности действий, то сервер следует отключить непосредственно перед п. 7. В этом случае записи в журнале транзакций будут идентичны показанным позднее на рис. 51.10. SQL Server плавно восстановится после сбоя и откатит все незавершенные транзакции.

?               Если в журнале транзакций существуют записи об операциях DML, которые подтверждены, но не отмечены как записанные в файл данных, они будут записаны в файл данных при восстановлении. Эту функцию практически невозможно продемонстрировать.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии