前滾：

         未完全提交的事務，即該事務已經被執行commit命令了，只是現在該事務修改所對應的髒資料塊中只有一部分被寫到磁碟上的資料檔案中，還有一部分已經被置為提交標記的髒塊還在記憶體上，如果此時資料庫例項崩潰了，則當資料庫例項恢復時，就需要用前滾（這個機制）來完成事務的完全提交，即將先前那部分已經被置為提交標記且還在記憶體上的髒塊寫入到磁碟上的資料檔案中。

回滾：

        未提交的事務，即該事務未被執行commit命令。但是此時，該事務修改的髒塊中也有可能一部分髒塊寫入到資料檔案中了。如果此時資料庫例項崩潰了，則當資料庫例項恢復時，就需要用回滾（這個機制）來將先前那部分已經寫入到資料檔案的髒塊從資料檔案上撤銷掉。

註釋：

       例項恢復，就是oracle軟體系統根據資料庫例項崩潰前最後一次檢查點的那一刻到資料庫例項崩潰那一刻期間所做的所有操作（無論該操作是否有提交的，這些操作可以從重做日誌上讀取）對該資料庫例項對應的資料庫（特別是資料檔案部分做恢復，當然其他配合資料檔案的檔案，如控制檔案，日誌檔案，也會做相關的恢復修改）進行前滾，即將該期間的操作重做一遍。之後再將其中未提交的操作進行回滾。這裡，可能就有人疑問了，為什麼前滾時不只做提交的操作，未提交的操作就不要做就好了嘛？因為資料庫例項崩潰前，未被執行commit命令的事務，其所修改的髒塊中也有可能一部分髒塊已經寫入到資料檔案中了，所以需要進行回滾操作

    總之，例項恢復時，先做前滾，後做回滾。

    (疑問)至於為什麼不用如下方法就不得而知了？

    該方法具體為,前滾時只做提交的操作，不做未提交的操作，到回滾操作階段時，再去回滾那些（記錄在重做日誌裡的）未提交的操作。

【前滾和回滾交替進行？？--------Recovery在SQL Server啟動時也會發生，在資料庫啟動過程中，SQL Server會檢查事務日誌，看是否存在已提交或未提交的事務，如果發現在最後一次檢查點發生後，還有已提交的事務，則SQL Server會對這些事務進行REDO(ROLL FORWARD)；而如果發現未提交的事務，則進行UNDO（ROLL BACK

注意：   未提交的事務     提交的事務   未完全提交的事務  完全提交的事務

                                                                                                                                                      詳見 何明