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

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

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

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

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

В качестве примера рассмотрим, что происходит, если обновляется одна строка таблицы. Допустим, имеется некоторая таблица SimpleTable содержащая столбец c1 с целочисленными данными и столбец c2 с символьными данными. В таблице имеется 10 000 строк, и пользователь отправляет запрос на обновление следующим образом:

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE '%Paul%';

При получении запроса на обновление данных выполняются следующие операции:

• Страницы данных из SimpleTable считываются с диска в память (буферный кэш), после чего можно выполнить поиск соответствующих запросу строк. Оказывается, что на трех страницах данных имеется пять строк, соответствующих предикату предложения WHERE.
• Эти три страницы и пять строк данных блокируются для выполнения обновлений.
• Изменения вносятся в пять записей данных на трех страницах данных, находящихся в памяти.
• Изменения записываются также в записи журнала транзакций на диске.
• При возникновении контрольной точки данные три страницы будут сохранены на диске.

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

· В терминах производительности, если бы страница данных вытеснялась на диск при каждом ее обновлении, число операций ввода/вывода в активно используемой системе могло бы превысить возможности подсистемы ввода/вывода. Сбрасывание на диск «грязных» страниц (те, которые были изменены с момента их считывания с диска) с некоторой периодичностью, требует гораздо меньше ресурсов, чем запись на диск страниц незамедлительно после внесения в них изменений.

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

Восстановление представляет собой процесс воспроизведения в базе данных изменений, описанных в записях журнала, или возврат базы данных к состоянию до этих изменений. Воспроизведение изменений данных по записям журнала называется фазой REDO (или наката) восстановления. Обращение изменений записей журнала называется фазой UNDO (или отката) восстановления. Другими словами, процедура восстановления обеспечиваете для транзакции и всех соответствующих записей журнала либо полное воспроизведение, либо полную отмену.

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

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

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

• Для записи журнала из зафиксированной транзакции, в которой страница базы данных имеет номер транзакции не меньший, чем номер транзакции записи журнала, не требуется никаких действий. Результаты воздействия записи журнала уже записаны в страницу на диске.
• Для записи журнала из зафиксированной транзакции, в которой страница базы данных имеет номер транзакции, меньший, чем номер транзакции записи журнала, необходимо выполнить накат записи журнала, чтобы обеспечить сохранение результатов транзакции.
• Для записи журнала из незафиксированной транзакции, в которой страница базы данных имеет номер транзакции, не меньший, чем номер транзакции записи журнала, необходимо выполнить откат записи журнала, чтобы результаты транзакции не были сохранены.
• Для записи журнала из незафиксированной транзакции, в которой страница базы данных имеет номер транзакции, меньший, чем номер транзакции записи журнала, не требуется никаких действий. Результаты воздействия записи журнала не были сохранены на странице на диске, и в таком случае ничего делать не требуется.

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

Ранее упоминалось, что одним из достоинств применения контрольных точкек является сокращение времени, занимаемого процедурой восстановления после сбоя. Периодическое сбрасывание на диск всех «грязных» страниц сокращает число страниц, измененных зафиксированными транзакциями, но изображений которых еще нет на диске. Это, в свою очередь, сокращает число страниц, к которым требуется применять операцию REDO во время восстановления после сбоя.