⑴ 資料庫大神來看，事務回滾靠的是undo,還是redo
回滾事務是undo哦，把這兩個概念大致說一下額。
redo（重做信息）是Oracle在在線（或歸檔）重做日誌文件中記錄的信息，萬一出現失敗時可以利用這些數據來「重放」（或重做）事務。 Oracle會使用歸檔重做日誌以及在線重做日誌將該驅動器上的數據備份恢復到適當的時間點。歸檔重做日誌文件實際上老的在線重做日誌文件的副本。undo（撤銷信息）是Oracle在undo段中記錄的信息，用於取消或回滾事務。 具體的機制lz可以耐心去了解一下，對你幫助很大。有問題再追問吧，望採納。
⑵ redo和undo的區別是什麼
undo一般用於事務的取消與回滾，記錄的是數據修改前的值；
redo一般用於恢復已確認但未寫入資料庫的數據，記錄的是數據修改後的值。
⑶ rac redo和undo為什麼二個實例不能共享，而需要分開
多實例的資料庫中，每個實例擁有一組獨立的在線日誌記錄，也就是我們常說的REDO
THREAD。每個實例獨立生成在線日誌信息，並且擁有獨立的LGWR進程用於寫入在線日誌文
件。但是在RAC資料庫環境中，在線日誌文件也必須是所有節點都能夠共同訪問的。原因也是
一樣的，當進行實例恢復的時候，由於相關的數據被寫在多個在線日誌文件中，因此必須用到所
有的REDO LOG THREAD中的在線日誌文件，才能夠完成恢復。當我們在資料庫上增加一個新
的實例的時候，必須為這個實例創建一組新的在線日誌記錄，同時激活這個REDO LOG
THREAD。反過來，要從資料庫中刪除一個實例的時候，我們必須關閉這個THREAD，否則無
論這個實例是否被使用，資料庫恢復的時候，仍然會需要使用這個THREAD的日誌。在這種情
況下關閉某個THREAD後重新做一次全庫備份，會少很多麻煩事。如果你真的碰到了這種情況，
而那個實例的在線日誌文件還沒刪除，那麼可以找找資料庫恢復所需要的CHANGE#是否在在線
日誌中存在，如果存在，你也可以直接恢復這個在線日誌來解決這個問題。
在使用UNDO自動管理的模式下，每個實例都需要使用獨立的UNDO表空間，這些表空間
的數據文件也必須存放在所有實例都能夠訪問的共享存儲上，其原因我們在前面已經多次提到，
不再重復了。
在多實例資料庫環境中，臨時表空間是可以多個實例共享的，不過能夠共享的僅僅是臨時表
空間，臨時段是不能共享的。在一個臨時表空間上，每個實例必須擁有自己獨立的臨時段。當臨
時表空間滿的時候，如果其他實例的臨時段有空閑空間，那麼這個實例可以從其他實例的臨時段
中偷取一個EXTENT，用於擴展自己的臨時段。
⑷ ORACLE中，資料庫的redo與undo分別是什麼呀，兩者是什麼關系呢
redo 是記錄日誌用的。
undo是記錄數據的備份用的。
簡單舉個例子說明（實際過程比這要復雜的多）：
1、當你發出一條update語句後，oracle先將更改前後信息寫進redo（當滿足一定條件後由日誌寫進程寫入日誌文件）
2、然後將更新前得數據鏡像到undo中。
3、用戶rollback後，oracle 將undo中的數據覆蓋回去
用戶commit後，oracle可以根據redo 的信息進行數據恢復。（當然也可以利用undo進行flashback）
簡單的講就是這樣，慢慢理解吧。
⑸ 在資料庫中，REDO操作和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: <trx1, insert …>
記錄2: <trx2, update …>
記錄3: <trx1, delete …>
記錄4: <trx3, update …>
記錄5: <trx2, insert …>
D. 因為C的原因,當一個事務將Redo Log寫入磁碟時，也會將其他未提交的事務的日誌寫入磁碟。
E. Redo Log上只進行順序追加的操作，當一個事務需要回滾時，它的Redo Log記錄也不會從Redo Log中刪除掉。InnoDB的做法時將回滾操作也記入Redo Log(具體做法看下一節).
⑹ 資料庫篇：mysql日誌類型之 redo、undo、binlog
可以說mysql的多數特性都是圍繞日誌文件實現，而其中最重要的有以下三種
innodb 為了提高磁碟I/O讀寫性能，存在一個 buffer pool 的內存空間，數據頁讀入會緩存到 buffer pool，事務的提交則實時更新到 buffer pool，而不實時同步到磁碟（innodb 是按 16KB 一頁同步的，一事務可涉及多個數據頁，實時同步會造成浪費，隨機I/O）。事務暫存在內存，則存在一致性問題，為了解決系統崩潰，保證事務的持久性，我們只需把事務對應的 redo 日誌持久化到磁碟即可（redo 日誌佔用空間小，順序寫入磁碟，順序I/O）
sql 語句在執行的時候，可能會修改多個頁面，還會更新聚簇索引和二級索引的頁面，過程產生的redo會被分割成多個不可分割的組（Mini-Transaction）。MTR怎麼理解呢？如一條 insert 語句可能會使得頁分裂，新建葉子節點，原先頁的數據需要復制到新數據頁里，然後將新記錄插入，再添加一個目錄項指向新建的頁子。這對應多條 redo 日誌，它們需要在原子性的 MTR 內完成
MTR 產生的 redo 日誌先會被復制到一個 log buffer 里(類似 buffer pool)。而同步到磁碟的時機如下：
事務需要保證原子性，也是說事務中的操作要麼全部完成，要麼什麼也不做。如果事務執行到一半，出錯了怎麼辦-回滾。但是怎麼回滾呢，靠 undo 日誌。undo 日誌就是我們執行sql的逆操作
binlog有三種格式：Statement、Row以及Mixed。
redolog 中的事務如果經歷了二階段提交中的prepare階段，則會打上 prepare 標識，如果經歷commit階段，則會打上commit標識（此時redolog和binlog均已落盤）。崩潰恢復邏輯如下：