| dbpprop:abstract
|
- In the field of databases in computer science, a transaction log (also database log or binary log) is a history of actions executed by a database management system to guarantee ACID properties over crashes or hardware failures. Physically, a log is a file of updates done to the database, stored in stable storage. If, after a start, the database is found in an inconsistent state or not been shut down properly, the database management system reviews the database logs for uncommitted transactions and rolls back the changes made by these transactions. Additionally, all transactions that are already committed but whose changes were not yet materialized in the database are re-applied. Both are done to ensure atomicity and durability of transactions. This term is not to be confused with other, human-readable logs that a database management system usually provides.
- 計算機科学のデータベースの分野において、トランザクションログ (または データベースログ, バイナリログ とも呼ばれる) とは、クラッシュやハードウェア故障があったとしてもデータベース管理システムのACID特性を保障するための操作履歴を指す。ログは電源が途絶えてもデータを保持できる補助記憶装置上のファイルに出力される場合が多い。 データベースが起動後に、整合性の無い状態であるか、正常に終了されていないことを検知すると、データベース管理システムはトランザクションログを読み取り、以下の操作を行う。どちらも原子性と永続性を保障するために必要である。 完了していない または ロールバックされたトランザクションが行った操作を取り消す。 コミットしているが、データベースには反映されていない操作を再実行する。 トランザクションログの目的は、データログとは異なる。一般にデータログは操作履歴を人間が読みやすい (human-readable) 表現で記録するために用いられる。そのため、データベース管理システムによってはトランザクションログとデータログの両方を提供している場合も多い。
- Журнализация изменений -- функция СУБД, которая сохраняет информацию, необходимую для восстановления базы данных в предыдущее консистентное состояние в случае логических или физических отказов. В простейшем случае журнализация изменений заключается в последовательной записи во внешнюю память всех изменений, выполняемых в базе данных. Записывается следующая информация: порядковый номер, тип и время изменения; идентификатор транзакции; объект, подвергшийся изменению (номер хранимого файла и номер блока данных в нём, номер строки внутри блока); предыдущее состояние объекта и новое состояние объекта. Формируемая таким образом информация называется журнал изменений базы данных. Журнал содержит отметки начала и завершения транзакции, и отметки принятия контрольной точки (см. ниже). В СУБД с отложенной записью блоки данных внешней памяти снабжаются отметкой порядкового номера последнего изменения, которое было выполнено над этим блоком данных. В случае сбоя системы эта отметка позволяет узнать какая версия блока данных успела достичь внешней памяти. СУБД с отложенной записью периодически выполняет контрольные точки. Во время выполнения этого процесса все незаписанные данные переносятся на внешнюю память, а в журнал пишется отметка принятия контрольной точки. После этого содержимое журнала, записанное до контрольной точки может быть удалено. Журнал изменений может не записываться непосредственно во внешнюю память, а аккумулироваться в оперативной. В случае подтверждения транзакции СУБД дожидается записи оставшейся части журнала на внешнюю память. Таким образом гарантируется, что все данные, внесённые после сигнала подверждения, будут перенесены во внешнюю память, не дожидаясь переписи всех измененных блоков из дискового кэша. СУБД дожидается записи оставшейся части журнала так же при выполнении контрольной точки. В случае логического отказа или сигнала отката одной транзакции журнал сканируется в обратном направлении, и все записи отменяемой транзакции извлекаются из журнала вплоть до отметки начала транзакции. Согласно извлеченной информации выполняются действия, отменяющие действия транзакции, а в журнал записываются компенсирующие записи. Этот процесс называется откат (rollback). В случае физического отказа, если ни журнал, ни сама база данных не повреждена, то выполняется процесс прогонки (rollforward). Журнал сканируется в прямом направлении, начиная от предыдущей контрольной точки. Все записи извлекаются из журнала вплоть до конца журнала. Извлеченная из журнала информация вносится в блоки данных внешней памяти, у которых отметка номера изменений меньше, чем записанная в журнале. Если в процессе прогонки снова возникает сбой, то сканирование журнала вновь начнется сначала, но фактически восстановление продолжиться с той точки, откуда оно прервалось.
|
![[RDF Data]](/statics/sw-cube.png)
