Журнальное протоколирование в SQL Server — до 20 мин.

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

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

Изменения, вносимые в базу данных, сначала вносятся в данные, которые находятся в кэше SQL Server. То, что изменения вносятся сначала в кэш, требуется в первую очередь для повышения производительности, поскольку ожидание при операциях ввода-вывода занимает много времени. Эти изменения записываются в конечном итоге на диск, но этот процесс выполняется в фоновом режиме и не виден пользователю. Поскольку модифицированные страницы хранятся в кэше, то может пройти существенный период времени, прежде чем эти страницы (их еще называют ожидающими, черновыми страницами – dirty pages) будут записаны соответствующим потоком (подпроцессом) SQL Server. Этот поток называют потоком откладываемой записи ("ленивым" потокомЭтот поток использует LRU-список записи страниц, где первой в очереди записи на диск находится наиболее давно обрабатывавшаяся страница и последней является только что обрабатывавшаяся страница. Страница, которая постоянно модифицируется (и, тем самым, все вр емя перемещается в конец этого списка), вообще может быть не записана этим потоком на диск. Подобные вещи могут увеличивать время воспроизведения, поскольку для применения изменений к таким данным потребуется прочитать много журнальных записей. Например, в большой системе с объемом RAM-памяти более 1 Гб и большим числом изменений в базе данных воспроизведение может занять несколько часов. – lazywriter thread).

Кроме потока откладываемой записи, поток контрольной точки а также выполняет запись ожидающих страниц на диск.

Журнал транзакций содержит "историю транзакций", поэтому операции ввода-вывода для журнала транзакций – это в основном операции записи, которые обычно выполняются последовательно. В случае отката транзакций происходит чтение журнала транзакций, что приводит к нарушению последовательного характера операций ввода-вывода. Поскольку откаты происходят довольно редко (так как аварии системы случаются редко и пользователи не слишком часто отменяют транзакции), ввод-вывод для журнала транзакций имеет достаточно устойчивый характер. Вы можете существенно повысить производительность операций ввода-вывода, поместив журнал транзакций на его собственный диск или RAID. В силу исключительной важности журнала транзакций для воспроизведения базы данных вам следует защитить его с помощью дисковой матрицы RAID.

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

Вы можете усекать журнал транзакций без его резервного копирования, задав для параметра trunc. log on chkpt (усечение при создании контрольной точки) значение TRUE в используемой базе данных. Но после этого вы не сможете получать резервную копию журнала транзакций. В результате вы лишитесь возможности воспроизведения базы данных и поэтому данная установка не рекомендуется.

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

Журнал транзакций значительно изменился после версии Microsoft SQL Server 6.5. Журнал транзакций SQL Server 2000 имеет те же характеристики, что и в Microsoft SQL Server 7. Это следующие характеристики.

· Обработка журнала транзакций отличается от обработки обычного файла данных. При записи и чтении не используются 8-килобайтные страницы, как для файлов данных. Теперь формат страниц данных уже не используется для журнала транзакций: запись может выполняться группами любого размера. Таким образом, если потоку записи журнала требуется записать лишь небольшое количество данных, он не будет использовать для этого 8 Кб данных. При частых обновлениях системы поток записи журнала может выполнять запись крупными блоками данных (16 Кб, 32 Кб и т.д.).

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

· Для журнала транзакций теперь можно использовать несколько файлов. Эти файлы также можно сконфигурировать для автоматического роста. Для файлов журнала транзакций не используется расслоение данных (striping); они используются друг за другом. (Расслоение данных описывается в лекции 5.)

· Журнал транзакций можно перемещать на другие системы для его воспроизведения на резервной системе. Это средство называется доставкой журнала транзакций (log shipping) и подробно описывается в следующей лекции.

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

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

· SELECT INTO

· BULK COPY и программа массового копирования (BCP)

· CREATE INDEX

· Определенные текстовые операции

Чтобы активизировать непротоколируемые массовые операции с определенной базой данных, вы должны задать для работы этой базы данных режим воспроизведения BULK_LOGGED. Кроме этого режима, можно также задавать режимы воспроизведения FULL и SIMPLE. Эти режимы задаются с помощью команды ALTER DATABASE.

При использовании режима BULK_LOGGED массовые операции, описанные в следующих разделах (за некоторыми исключениями, которые тоже описываются в следующих разделах), не протоколируются в журнале, а все остальные операции протоколируются. Если выбран режим воспроизведения FULL, то протоколируются все операции. А в случае режима SIMPLE данные можно восстанавливать только из последней резервной копии.

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

Оператор SELECT INTO используется для создания новой таблицы в базе данных. Поскольку оператор SELECT INTO нельзя использовать для выборки данных в существующий объект, его можно использовать только для создания данных, но не для обновления данных. Этот процесс создания можно легко повторить; поэтому операции SELECT INTO вполне подходят для выполнения как непротоколируемые операции.

Чтобы операции BULK COPY и BCP можно было выполнять как непротоколируемые операции, они должны отвечать следующим требованиям.

· Для параметра базы данных select into/bulkcopy должно быть задано значение TRUE.

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

· Целевая таблица не может реплицироваться, поскольку для транзакционной репликации используются записи журнала транзакций.

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

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

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

К текстовым операциям, которые можно выполнять как непротоколируемые операции, относятся WRITETEXT и UPDATETEXT. Чтобы активизировать выполнение этих операций без протоколирования, вам нужно просто использовать описанный выше режим BULK_LOGGED.