1樓：愛可生雲資料庫
先撤銷之前的操作，再恢復。在mysql中undo和redo的意義分別是：
00 – undo log
undo log 是為了實現事務的原子性，在mysql資料庫innodb儲存引擎中，還用undo log來實現多版本併發控制(簡稱：mvcc)。
- 事務的原子性(atomicity)
事務中的所有操作，要麼全部完成，要麼不做任何操作，不能只做部分操作。如果在執行的過程中發生了錯誤，要回滾(rollback)到事務開始前的狀態，就像這個事務從來沒有執行過。
- 原理
undo log的原理很簡單，為了滿足事務的原子性，在操作任何資料之前，首先將資料備份到乙個地方（這個儲存資料備份的地方稱為undo log）。然後進行資料的修改。如果出現了錯誤或者使用者執行了rollback語句，系統可以利用undo log中的備份將資料恢復到事務開始之前的狀態。
除了可以保證事務的原子性，undo log也可以用來輔助完成事務的持久化。
- 事務的永續性(durability)
事務一旦完成，該事務對資料庫所做的所有修改都會持久的儲存到資料庫中。不能因為錯誤/重啟/宕機而丟失已經commit的資料。為了保證永續性，資料庫系統需要將修改後的資料完全的記錄到持久的儲存上。
- 用undo log實現原子性和持久化的事務的簡化過程
假設有a、b兩個資料，值分別為1,2。
a.事務開始.
b.記錄a=1到undo log的記憶體buffer.
c.在記憶體中修改a=3.
d.記錄b=2到undo log的記憶體buffer.
e.在記憶體中修改b=4.
f.將undo log的buffer寫到磁碟。
g.將記憶體中修改後的資料寫到磁碟。
h.事務提交
這裡有乙個前提條件：『資料都是先讀到記憶體中，然後修改記憶體中的資料，最後將資料寫回磁碟』。以上過程之所以能同時保證原子性和持久化，是因為以下特點：
a. 更新資料前記錄undo log。
b. 為了保證永續性，必須將資料在事務提交前寫到磁碟。只要事務成功提交，資料必然已經持久化。
c. undo log必須先於資料持久化到磁碟。如果在g,h之間系統崩潰，undo log是完整的，可以用來回滾事務。
d. 如果在a-f之間系統崩潰,因為資料沒有持久化到磁碟。所以磁碟上的資料還是保持在事務開始前的狀態。
缺陷：每個事務提交前將資料和undo log寫入磁碟，這樣會導致大量的磁碟io，因此效能很低。如果能夠將資料快取一段時間，就能減少io提高效能。
但是這樣就會喪失事務的永續性。因此引入了另外一種機制來實現持久化，即redo log.
01 – redo log
- 原理
和undo log相反，redo log記錄的是新資料的備份。在事務提交時，只要將redo log持久化即可，不需要將資料持久化。當系統崩潰時，雖然資料沒有持久化，但是redo log已經持久化。
系統可以根據redo log的內容，將所有資料恢復到最新的狀態。
- undo + redo事務的簡化過程
假設有a、b兩個資料，值分別為1,2.
a.事務開始.
b.記錄a=1到undo log的記憶體buffer.
c.記憶體中修改a=3.
d.記錄a=3到redo log的記憶體buffer.
e.記錄b=2到undo log的記憶體buffer.
f..記憶體中修改b=4.
g.記錄b=4到redo log的記憶體buffer.
h.將redo log的記憶體buffer寫入磁碟。
i.事務提交
- undo + redo事務的特點
a. 為了保證永續性，必須在事務提交時將redo log持久化。
b. 資料不需要在事務提交前寫入磁碟，而是快取在記憶體中。
c. redo log 保證事務的永續性。
d. undo log 保證事務的原子性。
e. 有乙個隱含的特點，資料必須要晚於redo log寫入持久儲存。這是因為recovery要依賴redo log.
如果redo log丟失了，系統需要保持事務的資料也沒有被更新。
- io效能
undo + redo的設計主要考慮的是提公升io效能。雖說通過快取資料，減少了寫資料的io. 但是卻引入了新的io，即寫redo log的io。
如果redo log的io效能不好，就不能起到提高效能的目的。為了保證redo log能夠有比較好的io效能，innodb 的 redo log的設計有以下幾個特點：
a. 盡量保持redo log儲存在一段連續的空間上。以順序追加的方式記錄redo log,通過順序io來改善效能。
因此在系統第一次啟動時就會將日誌檔案的空間完全分配，從而保證redo log檔案在儲存上的空間有更好的連續性。
b. 批量寫入日誌。日誌並不是直接寫入檔案，而是先寫入redo log buffer.當需要將日誌重新整理到磁碟時 (如事務提交),才將許多日誌一起寫入磁碟，這樣可以減少io次數。
c. 併發的事務共享redo log的儲存空間，它們的redo log按語句的執行順序，依次交替的記錄在一起，以減少redo log的io次數。例如,redo log中的記錄內容可能是這樣的：
記錄1:
記錄2:
記錄3:
記錄4:
記錄5:
d. 因為c的原因,當乙個事務將redo log寫入磁碟時，也會將其他未提交的事務的日誌寫入磁碟。
e. redo log上只進行順序追加的操作，當乙個事務需要回滾時，它的redo log記錄也不會從redo log中刪除掉。innodb的做法時將回滾操作也記入redo log(具體做法看下一節).
2樓：小罍神
如果你先redo的話，a先變成90，然後再undo，a變回了600，但是實際上答案應該是630。
造成作業系統故障的六大原因是什麼
3樓：匿名使用者
在資料庫執行過程中，可能會出現各種各樣的故障，這些故障可分為以下三類：事務故障、系統故障和介質故障。應該根據故障型別的不同，採取不同的恢復策略。
1，事務故障及其恢復：
事務故障表示由非預期的、不正常的程式結束所造成的故障。
造成程式非正常結束的原因包括輸人資料錯誤、運算溢位、違反儲存保護、並行事務發生死鎖等。
發生事務故障時，被迫中斷的事務可能已對資料庫進行丁修改，為了消除該事務對資料庫的影響，要利用日誌檔案中所記載的資訊，強行回滾（rollback）該事務，將資料庫恢復到修改前的初始狀態。
為此，要檢查日誌檔案中由這些事務所引起的發生變化的記錄，取消這些沒有完成的事務所做的一切改變。
這類恢復操作稱為事務撤銷（undo），具體做法如下。
（1）反向掃瞄日誌檔案，查詢該事務的更新操作。
（2）對該事務的更新操作執行反操作，即對已經插入的新記錄進行刪除操作，對己刪除的記錄進行插入操作，對修改的資料恢復舊值，用舊值代替新值。這樣由後向前逐個掃瞄該事務已做的所有更新操作，並做同樣處理，直到掃瞄到此事務的開始標記，事務故障恢復完畢為止。
因此，乙個事務是乙個工作單位，也是乙個恢復單位。乙個事務越短，越便於對它進行undo操作。如果乙個應用程式執行時間較長，則應該把該應用程式分成多個事務，用明確的commit語句來結束各個事務。
2，系統故障及其恢復系統故障是指系統在執行過程中，由於某種原因，造成系統停止運轉，致使所有正在執行的事務都以非正常方式終止，要求系統重新啟動。引起系統故障的原因可能有硬體錯誤（如cpu故障、作業系統）或dbms**錯誤、突然斷電等。
這時，記憶體中資料庫緩衝區的內容全部丟失，雖然儲存在外部儲存裝置上的資料庫並未破壞，但其內容不可靠了。系統故障發生後，對資料庫的影響有以下兩種情況。
一種情況是一些未完成事務對資料庫的更新已寫入資料庫，這樣在系統重新啟動後，要強行撤銷（undo）所有未完成的事務，清除這些事務對資料庫所做的修改。這些末完成事務在日誌檔案中只有begin translatl0n標記，而無commit標記。
另一種情況是有些已提交的事務對資料庫的更新結果還保留在緩衝區中，尚未寫到磁碟上的物理資料庫中，這也使資料庫處於不一致狀態，因此應將這些事務已提交的結果重新寫入資料庫。這類恢復操作稱為事務的重做（redo）。這種巳提交事務在日誌檔案中既有bgin transcation標記，也有commit標記。
因此，系統故障的恢復要完成兩方面的工作，既要撤銷所有末完成的事務，還要重做所有已提交的事務，這樣才能將資料庫真正恢復到一致的狀態。具體做法如下。
（1）正向掃瞄日誌檔案，查詢尚未提交的事務，將其事務標識記人撤銷佇列。同時查詢已經提交的事務，將其事務標識記入重做佇列。
（2）對撤銷佇列中的各個事務進行撤銷處理。方法同事務故障中所介紹的撤銷方法。
（3）對重做佇列中的各個事務進行重做處理。進行重做處理的方法是正向掃瞄日誌檔案，按照日誌檔案中所登記的操作內容，重新執行操作，使資料庫恢復到最近某個可用狀態。
系統發生故障後，由於無法確定哪些末完成的事務已更新過資料庫，哪些事務的提交結果尚未寫入資料庫，因此系統重新啟動後，就要撤銷所有的末完成的事務，重做所有的已經提交的事務。
但是，在故障發生前已經執行完畢的事務有些是正常結束的，有些是異常結束的。所以無須把它們全部撤銷或重做。
通常採用設立檢查點（checkpoint）的方法來判斷事務是否正常結束。每隔一段時間，比如說5分鐘，系統就產生乙個檢查點，做下面一些事情：a,把仍保留在日誌緩衝區中的內容寫到日誌檔案中；b,在日誌檔案中寫乙個「檢查點記錄」；c,把資料庫緩衝區中的內容寫到資料庫中，即把更新的內容寫到物理資料庫中；d,把日誌檔案中檢查點記錄的位址寫到「重新啟動檔案」中。
每個檢查點記錄包含的資訊有在檢查點時間的所有活動事務一覽表、每個事務最近日誌記錄的位址。
在重新啟動時，恢復管理程式先從「重新啟動檔案」中獲得檢查點記錄的位址，從日誌檔案中找到該檢查點記錄的內容，通過日誌往回找，就能決定哪些事務需要撤銷，恢復到初始的狀態，哪些事務需要重做。為此利用檢查點資訊能做到及時、有效、正確地完成恢復工作。
3，介質故障及其恢復介質故障是指系統在執行過程中，由於輔助儲存器介質受到破壞，使儲存在外存中的資料部分或全部丟失。
這類故障比事務故障和系統故障發生的可能性要小，但這是最嚴重的一種故障，破壞性很大，磁碟上的物理資料和日誌檔案可能被破壞，這需要裝入發生介質故障前最新的後備資料庫副本，然後利用日誌檔案重做該副本後所執行的所有事務。
具體方法如下。
（1）裝入最新的資料庫副本，使資料庫恢復到最近一次轉儲時的可用狀態。
（2）裝入最新的日誌檔案副本，根據日誌檔案中的內容重做已完成的事務。首先掃瞄日誌檔案，找出故障發生時己提交的事務，將其記入重做佇列。然後正向掃瞄日誌檔案，對重做佇列中的各個事務進行重做處理，方法是正向掃瞄日誌檔案，對每個重做事務重新執行登記的操作，即將日誌記錄中「更新後的值」寫入資料庫。
這樣就可以將資料庫恢復至故障前某一時刻的一致狀態了。
廣州本田飛度a t系統故障是什麼意思
心達致通 本田飛度故障常見故障一 發動機油底漏油 我們在對車輛進行正常保養時，發現有一部分廣州本田飛度車的發動機曲軸箱強制通風蓋及油底殼後部存在漏油故障。經對車輛進行仔細檢查，可以確定這輛本田飛度故障原因在於相關密封件的質量未能達到使用要求。在更換新件並進行適當處理後，本田飛度故障問題得到解決。第二...
博世系統故障碼p1014是什麼意思
傲血殘鋒 噴油器出了問題 博世系統為滿足國三排放標準，國內多數卡車及柴油機企業將技術路線定為高壓共軌，目前高壓共軌技術主要被博世 德爾福 電裝等公司掌握，其中博世的高壓共軌系統佔有絕大部分市場份額。技術升級隨之而來的是車輛使用等方面的變化，為了更好地普及國三電控共軌系統的知識。 吳歡最美 更換噴油器...
長安CS75啟動系統故障是什麼原因造成的
回答汽車起動系統故障問題原因是多方面的，原因之一是蓄電池供電系統有問題 如蓄電池電量不足 汽小夥伴電源保險或繼電器損壞 起動機電纜和蓄電池接線柱鬆動或是接線柱氧化。原因之二是起動繼 電器故障問題 如起動繼電器電感線圈短路 起動繼電器電感線圈斷路或搭鐵 起動繼電器動觸點或靜 觸點燒蝕 起動繼電器鐵芯與...