前滾：

???????? 未完全提交的事務(wù)，即該事務(wù)已經(jīng)被執(zhí)行commit命令了，只是現(xiàn)在該事務(wù)修改所對(duì)應(yīng)的臟數(shù)據(jù)塊中只有一部分被寫到磁盤上的數(shù)據(jù)文件中，還有一部分已經(jīng)被置為提交標(biāo)記的臟塊還在內(nèi)存上，如果此時(shí)數(shù)據(jù)庫實(shí)例崩潰了，則當(dāng)數(shù)據(jù)庫實(shí)例恢復(fù)時(shí)，就需要用前滾（這個(gè)機(jī)制）來完成事務(wù)的完全提交，即將先前那部分已經(jīng)被置為提交標(biāo)記且還在內(nèi)存上的臟塊寫入到磁盤上的數(shù)據(jù)文件中。

回滾：

??????? 未提交的事務(wù)，即該事務(wù)未被執(zhí)行commit命令。但是此時(shí)，該事務(wù)修改的臟塊中也有可能一部分臟塊寫入到數(shù)據(jù)文件中了。如果此時(shí)數(shù)據(jù)庫實(shí)例崩潰了，則當(dāng)數(shù)據(jù)庫實(shí)例恢復(fù)時(shí)，就需要用回滾（這個(gè)機(jī)制）來將先前那部分已經(jīng)寫入到數(shù)據(jù)文件的臟塊從數(shù)據(jù)文件上撤銷掉。

注釋：

?????? 實(shí)例恢復(fù)，就是oracle軟件系統(tǒng)根據(jù)數(shù)據(jù)庫實(shí)例崩潰前最后一次檢查點(diǎn)的那一刻到數(shù)據(jù)庫實(shí)例崩潰那一刻期間所做的所有操作（無論該操作是否有提交的，這些操作可以從重做日志上讀取）對(duì)該數(shù)據(jù)庫實(shí)例對(duì)應(yīng)的數(shù)據(jù)庫（特別是數(shù)據(jù)文件部分做恢復(fù)，當(dāng)然其他配合數(shù)據(jù)文件的文件，如控制文件，日志文件，也會(huì)做相關(guān)的恢復(fù)修改）進(jìn)行前滾，即將該期間的操作重做一遍。之后再將其中未提交的操作進(jìn)行回滾。這里，可能就有人疑問了，為什么前滾時(shí)不只做提交的操作，未提交的操作就不要做就好了嘛？因?yàn)閿?shù)據(jù)庫實(shí)例崩潰前，未被執(zhí)行commit命令的事務(wù)，其所修改的臟塊中也有可能一部分臟塊已經(jīng)寫入到數(shù)據(jù)文件中了，所以需要進(jìn)行回滾操作。

??? 總之，實(shí)例恢復(fù)時(shí)，先做前滾，后做回滾。

??? (疑問)至于為什么不用如下方法就不得而知了？

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

【前滾和回滾交替進(jìn)行？？--------Recovery在SQL Server啟動(dòng)時(shí)也會(huì)發(fā)生，在數(shù)據(jù)庫啟動(dòng)過程中，SQL Server會(huì)檢查事務(wù)日志，看是否存在已提交或未提交的事務(wù)，如果發(fā)現(xiàn)在最后一次檢查點(diǎn)發(fā)生后，還有已提交的事務(wù)，則SQL Server會(huì)對(duì)這些事務(wù)進(jìn)行REDO(ROLL FORWARD)；而如果發(fā)現(xiàn)未提交的事務(wù)，則進(jìn)行UNDO（ROLL BACK）。http://blog.csdn.net/hmzhangfeng/article/details/6338021】

注意： ? 未提交的事務(wù)?? ? 提交的事務(wù)?? 未完全提交的事務(wù)? 完全提交的事務(wù)

????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? 詳見 何明

總結(jié)

以上是生活随笔為你收集整理的前滚和回滚的区别的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。