數據庫都具有事務日志，用於記錄所有事務以及每個事務對數據庫所做的修改。事務日志是數據庫的重要組件，如果系統出現故障，則可能需要使用事務日志將數據庫恢復到一致狀態。刪除或移動事務日志以前，必須完全了解此操作帶來的后果。
事務日志支持以下操作：
恢復個別的事務。
在 SQL Server 啟動時恢復所有未完成的事務。
將還原的數據庫、文件、文件組或頁前滾至故障點。
支持事務復制
支持備份服務器解決方案。
那時有兩個痛點：1，某個用戶電腦忽然斷電，數據寫入不完整，導致大家都不能用了；2、多個用戶對同一條記錄進行寫操作，或讀與寫不致，或ID增量重號。
現在的數據庫系統（Oracel、DB2、MS sql、Mysql等）都支持多用戶，所有的數據庫系統（包括Exchange），都是把數據先寫到日志中，等某個時機（比如：確認commit）后再寫到數據庫記錄中，日志是數據庫最重要的數據之一，理解日志是相當重要的。為什么要用日志呢？就是要解決Foxfro多用戶的痛點一啊。
日志一般分成Undo與Redo：Undo一般用於事務的取消與回滾，記錄的是數據被修改前的值，Redo一般用於恢復已確認但未寫入數據庫的數據，記錄的是數據修改后的值，例如：數據庫忽然斷電重啟，數據庫啟動時一般要做一致性檢查，會把已寫到Redo的數據但未寫入數據庫的數據重做一遍。
數據庫系統如何來確認哪些數據需要redo或undo呢？那就需要一個檢查點（checkpoint），在系統中一般有一個表或一個控制文件來記錄檢查點，日志是按順序一直寫下去的，檢查點設置后，只需要比對檢查點之后的數據就可以了。
二：undo日志
1.概述
日志是日志記錄的一個序列。在多事務的數據庫系統中，每個事務有若干個操作步驟。每個日志記錄記載有關某個事務已做的某些情況。幾個事務的行為可以是“交錯的”，因此可能是一個事務的某個步驟被執行，並且其效果被記錄到日志中，接着執行另外一個事務的某個步驟並記入日志，接着可能接着做第一事務的下一個步驟，也可能執行另外一個事務的某個步驟。依次類推。事務的交錯執行使日志更復雜，因為僅在事務結束后記載事務的全過程是不夠的。
如果系統崩潰，恢復管理器就被激活，檢查日志以重建數據庫的一致性狀態。恢復時，有些事務的工作將會重做，它們寫到數據庫的新值會重寫一次。而另外一些事務的工作將被撤消，數據庫被恢復，將仿佛這些事務從來沒執行過一樣。
Undo日志是日志類型的一種，這類日志僅僅進行第二類修復。對於要被撤消的事務，因為不能肯定它對數據庫的修改是否已經寫到磁盤中，所以對於該事務的所有更新都將被撤消，數據庫恢復到事務發生以前的狀態。
2.日志記錄
日志只允許以附加的方式寫入數據。日志塊最初在主存中創建，像數據塊一樣也由緩沖區管理，在確當的時刻，日志塊會從緩沖區寫入到磁盤。
關於undo記錄形式有四種：
1) : 這一記錄表示事務T開始
2) : 事務T已經完成。
3) : 事務T不能成功執行。
4) <t, v="" x,="">: 事務T改變了數據庫元素X的值，元素X原來的值為v。
3.undo日志規則
要想讓undo日志能使我們從系統故障中恢復，事務必須遵循兩條規則。
規則1)如果事務T改變了數據庫元素X，那么形如<t, v="" x,="">的日志記錄必須在X的新值寫到磁盤前寫到磁盤
規則 2)如果事務提交，則其COMMIT日志記錄必須在事務改變的所有數據庫元素已寫到磁盤后再寫到磁盤，但應盡快。
簡單概括，undo日志系統順序如下：
1) 指明所改變數據庫元素的日志記錄
2) 改變的數據庫元素自身
3) COMMIT日志記錄。
5.使用undo日志進行數據庫的恢復
現在假設系統故障發生了。有可能給定事務的某些數據庫更新已經寫到磁盤上，而同一事務的另外一些更新尚未到達磁盤。如果這樣，事務的執行就不是原子的，數據庫狀態就可能不一致。這時候，我們就有必要使用日志將數據庫恢復到一致的狀態。
比如，在表2中，如果故障發生在步驟9之后、步驟10之前。數據庫的狀態就是不一致的。
恢復管理的第一個任務就是將事務划分為已經提交事務和未提交事務。如果在日志中，根據undo的規則2，事務T所做的全部改變在此之前已經寫到磁盤上，因此當故障發生時，該事務T不可能導致數據庫的不一致狀態。
然而，假設在日志中，只有記錄，而沒有與之相匹配的記錄。那么就有可能在崩潰前，事務的某些修改已經反應到磁盤上，而另外一些修改可能未發生或者還在緩沖區中。這種情況下，T是一個未完成的事務，因為必須被撤消。也就是說，T所做的任何修改都必須恢復為原來的值。Undo的規則1使該想法可以成為可能，因為在修改數據刷盤之前，日志文件中已經保存了修改數據的原先值。對於<t, v="" x,="">，只需要將X的值恢復為v就行了(我們不必檢查數據庫中X現有值是否為v)。
日志中可能有一些未提交的事務，並且甚至可能有一些未提交的事務修改了X，所以恢復時采用從日志文件尾向前掃描。在掃描過程中記住所有有或記錄的事務T。同時在隨后的掃描中，如果它看見<t, v="" x,="">，則：
1) 如果T的COMMIT記錄已被掃描到，則什么也不做。
2) 否則，將數據庫中元素X的值改為v。在做完這些操作后，為以前未中止且未完成的每個事務T寫入一個日志記錄，然后刷新日志。
對於表2，作如下分析：
1)崩潰在第12步后發生。因為日志記錄已經寫入日志文件。當恢復時，不需要處理T事務。
2)崩潰發生在11步和12步之間。日志中記錄了三條記錄：、<t, 1000="" a,="">以及<t, 500="" b,="">。當恢復管理進行向后掃描時，首先遇到記錄<t, 500="" b,="">，於是它將B在磁盤上的值存為500。接着它遇到記錄<t, 1000="" a,="">，於是它將A在磁盤上的值存為1000。最后記錄被寫到日志中且日志被刷新。
3)崩潰發生在第8步和第11步之間。情況2一樣。
4)崩潰發生在第8步之前。日志系統中只有一條記錄：。記錄被寫到日志中且日志被刷新。(實際上，在實際系統中，可能其他的事務執行FLUSH LOG操作，而將事務T的日志記錄寫入磁盤中，如果是這樣的話，日志中可能已經寫入<t, 1000="" a,="">和<t, 500="" b,="">，對於這種情況，執行情況2的恢復就行。實際上這些細節不影響undo的恢復效用，為了簡單起見，忽視這些情況)。
6.靜態檢查點
正如我們所看到的那樣，恢復時需要檢查整個日志。當采用undo類型的日志時，一旦日志記錄被寫入日志文件，事務T的日志記錄就可以忽視了。但是此時事務T卻不能截斷日志，因為事務是交替執行的，如果這時將日志截斷，可能丟失活動着的事務的日志記錄。
Undo是恢復的一種策略，但是不是唯一的策略。
Undo日志的一個潛在的問題是：在所有修改數據沒有寫到磁盤前，不允許提交該事務。有時，讓修改的數據頁暫時緩沖在主存中，是可以節省磁盤IO的;只要在崩潰的時候有日志用來恢復。
2.redo日志的規則
Redo日志用新值表示數據元素的更新，而undo日志使用的是舊值。Redo日志的<t，x，v>表示：事務T為數據庫元素X寫入新值v。
Redo日志系統的規則只有一條：
規則1：在修改磁盤上任何數據庫元素X之前，要保證所有與X這一修改相關的日志記錄，包括更新記錄<t，x，v>以及記錄，都必須出現在磁盤上。
Redo日志順序如下：
1) 指出被修改元素的日志記錄
2) COMMIT日志記錄
3) 改變的數據元素自身。
4.使用redo日志的恢復
對於redo日志，根據規則1，我們可以知道如果日志沒有，則事務T的修改所做的所有的更新都沒反映到磁盤上，就像事務T從來沒有發生過一樣。
如果發現記錄記錄，卻不敢保證所有的數據庫修改已經反映到磁盤上，這和undo日志是相反的。我們必須將事務T重做一次。
使用redo日志恢復，過程如下：
1) 確定提交事務
2) 從首部開始掃描日志，對遇到的每一<t，x，v>記錄：
(a)：如果T是未提交的事務，則什么也不做。
(b)：如果T是提交的任務，則為磁盤上數據庫元素寫入值v
3)對於每一個未完成的事務T，在日志中寫入一個記錄並刷新日志。
1) 如果故障發生在第9步以后，記錄已被刷新到磁盤。恢復時，遇到記錄<t, a,="" 950="">，為磁盤上的A寫入值950。遇到記錄<t, b,="" 550="">，為磁盤上的B寫入值550。
2) 如果故障發生在第9步之前，如果已經到達磁盤，則恢復過程同情況1。如果未到達磁盤，T被做為未完成事務，磁盤上的A和B不作任何修改，最后將一條寫入日志並刷盤。
在線重做日志與歸檔日志。
ONLINE Redo log
在線重做日志(online redo log )主要用於：Oracle數據庫所在服務器突然掉電、突然重啟或者執行shutdown abort等命令使得在服務器重新啟動之后，Oracle數據庫沒有辦法正常的啟動實例。此時，在線重做日志就派上了用場，Oracle會使用在線重做日志，把數據庫恢復到服務器掉電前的那一個時刻，從而使得數據庫能正常的啟動起來 。
在Oracle數據庫中，默認情況下，至少會有兩個重做日志組，而且每個組里面至少包含了一個重做日志文件。日志組不會自動增加，在一個寫滿之后，會自動去寫下一個。在下一個被寫滿之后會又從第一個開始寫起。
Archive redo log
歸檔日志(archive log)主要用於硬件級別的錯誤：磁盤的壞道導致無法讀寫、寫入的失敗、磁盤受損導致數據庫數據丟失。這就要使用歸檔日志文件，通過歸檔日志文件，把數據庫恢復到歸檔日志所在的時間點上然后再通過在線重做日志文件把數據庫恢復到當前的時間點上。
對於歸檔日志文件，可以理解為在線重做日志文件的備份。即當一個重做日志文件被填滿了之后，歸檔日志文件就會把其備份保留一份。（因為上面說了，在線重做日志文件會自動的覆蓋）所以，歸檔日志文件就是舊的在線日志文件的備份。