Введение
История действий, выполненных системой управления базами данных.
В области баз данных в информатике журнал транзакций (также называемый журналом операций, журналом базы данных, бинарным журналом или журналом аудита) представляет собой историю действий, выполненных системой управления базами данных, используемую для гарантии свойств ACID в случае сбоев или аппаратных отказов. Физически журнал представляет собой файл, содержащий перечень изменений в базе данных, хранящийся в надежном формате. Если после запуска обнаруживается, что база данных находится в несогласованном состоянии или была завершена некорректно, система управления базами данных просматривает журналы базы данных для поиска незавершенных транзакций и откатывает изменения, внесенные этими транзакциями. Кроме того, повторно применяются все транзакции, которые уже были зафиксированы, но изменения которых еще не были отражены в базе данных. Все это делается для обеспечения атомарности и надежности транзакций. Этот термин не следует путать с другими, читаемыми человеком журналами, которые обычно предоставляет система управления базами данных. В системах управления базами данных журнал является записью данных, измененных данным процессом.
Типы записей журналов базы данных
Все записи журнала включают в себя общие атрибуты журнала, указанные выше, а также другие атрибуты в зависимости от их типа (который записывается в атрибуте Type, как указано выше). Запись журнала обновления отмечает обновление (изменение) в базе данных. Она включает следующую дополнительную информацию: PageID: ссылка на идентификатор страницы измененной страницы. Длина и смещение: длина в байтах и смещение страницы обычно включаются. Изображения до и после: включает значения байтов страницы до и после изменения. Некоторые базы данных могут вести журналы, включающие одно или оба изображения. Запись журнала компенсации (CLR) отмечает откат конкретного изменения в базе данных. Каждая запись соответствует ровно одной записи журнала обновления (хотя соответствующая запись журнала обновления обычно не хранится в записи журнала компенсации). Она содержит следующую дополнительную информацию: undoNextLSN: это поле содержит LSN следующей записи журнала, которую необходимо отменить для транзакции, записавшей последний журнал обновления. Запись о фиксации отмечает решение о фиксации транзакции. Запись об откате отмечает решение об откате и, следовательно, об откате транзакции. Запись контрольной точки отмечает, что была создана контрольная точка. Они используются для ускорения восстановления. Они записывают информацию, которая избавляет от необходимости просматривать журнал вглубь. Это зависит от алгоритма контрольных точек. Если все измененные страницы сбрасываются на диск при создании контрольной точки (как в PostgreSQL), она может содержать: redoLSN: это ссылка на первую запись журнала, соответствующую измененной странице, то есть первое обновление, которое не было сброшено на диск во время контрольной точки. С этого места начинается повторное применение изменений при восстановлении. undoLSN: это ссылка на самую старую запись журнала самой старой активной транзакции. Это самая старая запись журнала, необходимая для отката всех активных транзакций. Запись о завершении отмечает, что вся работа для данной транзакции выполнена (она была полностью зафиксирована или отменена).
PageID: A reference to the Page ID of the modified page. Length and Offset: Length in bytes and offset of the page are usually included. Before and After Images: Includes the value of the bytes of page before and after the page change. Some databases may have logs which include one or both images. Compensation Log Record (CLR) notes the rollback of a particular change to the database. Each corresponds with exactly one other Update Log Record (although the corresponding update log record is not typically stored in the Compensation Log Record). It includes this extra information:
undoNextLSN: This field contains the LSN of the next log record that is to be undone for transaction that wrote the last Update Log. Commit Record notes a decision to commit a transaction. Abort Record notes a decision to abort and hence roll back a transaction. Checkpoint Record notes that a checkpoint has been made. These are used to speed up recovery. They record information that eliminates the need to read a long way into the log's past. This varies according to checkpoint algorithm. If all dirty pages are flushed while creating the checkpoint (as in PostgreSQL), it might contain:
redoLSN: This is a reference to the first log record that corresponds to a dirty page. i. e. the first update that wasn't flushed at checkpoint time. This is where redo must begin on recovery. undoLSN: This is a reference to the oldest log record of the oldest in progress transaction. This is the oldest log record needed to undo all in progress transactions. Completion Record notes that all work has been done for this particular transaction. (It has been fully committed or aborted)