前段時間看了下資料庫的基礎知識，稍微整理一下。redo，顧名思義就，重做。以恢復操作為目的，重現操作。
redo記錄transaction logs，分為online和archived。
比如，機器停電，那麼在重起之後需要online redo logs去恢復系統到失敗點。
比如，磁碟壞了，需要用archived redo logs和online redo logs區恢復資料。
undo，意為取消，以撤銷操作為目的，返回上乙個狀態，類似備份。
注意：redo也會記錄undo操作。
比如我們往乙個表中插入一條資料。
如果這張表有索引，那麼表中索引的改變也會作redo和undo。
redo和undo都是寫在記憶體中的，所以一旦系統奔潰，這些檔案將不復存在。所以資料庫中很重要的乙個東西就是日誌。redo log 的資訊就需要先寫到磁碟上，因為它是最原始的操作，能用於場景重現。
曾在講座中聽到，當年oracle獨霸全球時，很大程度上就是得益於mvcc。
mvcc（多版本控制），如果把基於鎖的併發控制機制稱成為悲觀機制，那麼mvcc就算是樂觀機制。
樂觀和悲觀的區別在於，悲觀機制是必須等所有條件完備之後再開始執行。樂觀機制則是先碰運氣往下做，如果不行就回滾。
oracle允許可以由多個使用者對資料庫進行操作，當你執行乙個查詢幾百萬條記錄的操作時，這個過程可能需要幾分鐘。在這個過程中其它使用者對你查詢的資料時行了修改。這裡就要保證你查詢的結果是被修改之前的。
剛才說了，樂觀機制是需要回滾的，所以undo就派上用場了。
當我們執行乙個事務的時候，oracle會分配乙個scn編號，這個編號是遞增的。下乙個事務的編號一定比當前事務的編號大。上圖中執行第乙個事務分配的編號為10023，在這個事務執行的過程中，另一事務對scn 編號為10008和10021的資料塊進行了修改。用來替換的資料塊scn編號為10024 ，而被替換掉的資料塊會被儲存到undo 上面。當第乙個事務執行到被修改過的資料塊時，發現10024比10023大，這個時候就會到undo segment上找比自己scn號小的資料塊進行讀，於是發找到了scn號為10008和10021兩個塊。這樣就有效的保證讀一致性。
執行看上去總是這麼順利，得益於無鎖機制。但是提交時就可能悲劇。因為提交時需要檢查版本衝突，如果失敗則需要重做一次。
mvcc費時的地方在於版本衝突時。所以mvcc適用於讀多於寫的場景。因為衝突只出現於寫的時候。
如果寫操作很多，則會引起頻繁的衝突，使得mvcc花費很多時間在retry。這種情況還不如直接使用鎖。
說到底還是在於retry的代價是否大，如果retry代價小，就適合mvcc這種嘗試性的操作，否則就是用鎖。
redo和undo的區別
redo undo datafile insert一條記錄時,表跟undo的資訊都會放進 redo 中,在commit 或之前,redo 的資訊會放進硬碟上.故障時,redo 便可恢復那些已經commit 了的資料.redo 每次操作都先記錄到redo日誌中，當出現例項故障 像斷電 導致資料未能更新...
redo和undo的區別
redo undo datafile insert一條記錄時,表跟undo的資訊都會放進 redo 中,在commit 或之前,redo 的資訊會放進硬碟上.故障時,redo 便可恢復那些已經commit 了的資料.redo 每次操作都先記錄到redo日誌中，當出現例項故障 像斷電 導致資料未能更新...
redo和undo的區別
redo undo datafile insert一條記錄時,表跟undo的資訊都會放進 redo 中,在commit 或之前,redo 的資訊會放進硬碟上.故障時,redo 便可恢復那些已經commit 了的資料.redo 每次操作都先記錄到redo日誌中，當出現例項故障 像斷電 導致資料未能更新...