1 consistent backup:
一致性備份乙個資料庫或者資料庫的一部分，那麼這部分的資料檔案及控制檔案必須被checkpointed並且擁有相同的scn(system change number)，oracle 決定是否一致性備份通過檢查資料檔案頭以及這個資料檔案頭的在控制檔案裡的資訊，如果是一致的，則表示為一致性備份。
這裡補充一點知識：
當發生checkpoint時，會把scn寫到四個地方去。 三個地方於control file內，乙個在datafile header。
1.
system checkpoint scn
**********=> (system checkpoint scn in control file)
2.
datafile checkpoint scn
**********=> (datafile checkpoint scn in control file)
3.
stop scn
********************==> (stop scn in control file)
4.
start scn
********************==> (datafile header)
正是因為這些scn，我們才保證了一致性。詳細內容參考：
redolog checkpoint 和scn關係
只有當資料庫正常關閉，既通過normal,immediate,transactional選項關閉資料庫，而後進行的備份才是一致的，如果instance fails或者shutdown abort進行關閉，那麼資料檔案是不一致的，這時當資料庫開啟時是需要instance 恢復，（當然資料庫是read-only database不需要進行instance 恢復）
oracle 通過checkpoint程序使控制檔案和資料檔案擁有一致的scn，當表空間處於唯讀（read-only）或者offline normal tablespace 時，允許使用舊的scns，這時該錶空間中的資料檔案跟其他的資料檔案仍然被認為是一致的，因為在離線後，表空間沒有進行任何新的改變。
當資料庫restore 一致性資料庫全備份後，開啟資料庫將不需要應用redo，因為資料已經是一致的，不需要新的動作使資料檔案變正確。
2 inconsistent backup:
控制檔案儲存資料庫的結構資訊，這些資訊包括用於恢復的檢查點scn資訊。但是控制檔案是乙個非常繁忙的檔案，連續的scn 和檔案管理對於資料庫的生命期來說至關重要，因此rdbms 必須能夠持續的使用控制檔案。
而rman 開始備份每乙個資料檔案時需要得到乙個一致的控制檔案檢視， rman需要知道備份開始時最新的檢查點資訊和檔案資訊。開始備份後，rman 需要這些資訊在備份操作期間保持一致，也就是說rman需要乙個讀取一致的控制檔案檢視。除非rman 在備份持續時間內鎖定控制檔案，否則資料庫會不斷更新控制檔案，所以不可能。 但是，鎖定控制檔案意味著資料庫不能執行檢查點操作和切換日誌，或則不能產生新的歸檔日誌，這些操作是不可能的。
所以就有了快照控制檔案（snapshot controlfile），快照控制檔案是控制檔案的副本。rman 只在備份和同步操作期間使用快照控制檔案。 這些操作開始時，rman 會根據實際控制檔案來重新整理快照控制檔案，這樣會短暫的鎖住控制檔案，隨後，rman 會切換到快照並在備份持續使用這個快照。 這種方式具有讀取一致性，且不妨礙資料庫活動。
3 重做日誌，備份歸檔日誌 和 控制檔案
重做裡面存放的是未歸檔的資訊。 這些資訊對恢復來說非常重要，因為當online backup 和inconsistent closed backup, 總會應用重做日誌進行恢復，所以有時需要為未歸檔的重做日誌進行歸檔，具體方式如下：
當資料庫處於open狀態：alter system archive log current;
當mounted,open or colsed: alter system archive log all;
當mounted,open or colsed歸檔特定組: alter system archive log group integer;
在開啟或非一致性備份關閉的備份後，oracle推薦備份所有在備份期間產生的歸檔日誌，並且在備份完成後備份控制檔案。
我們在來理解一下歸檔日誌的作用：
rman備份是一種物理的備份，它直接去讀取資料塊，因此rman是塊級別的備份。從備份的那個時間點開始rman將鎖定此刻的資料檔案資訊，也就是說只是備份資料檔案到此刻的資訊為之。
但是rman並不鎖定資料檔案的使用，也就是說rman的備份，不是資料庫一致性狀態的備份，由於rman備份是塊級別的，它只備份控制檔案中已經存在的資料塊，同時資料庫還在執行之中，那麼就有可能會出現某些已經提交的操作，但是dbwn還沒有寫入資料檔案，或者已經被rman備份過的資料塊，又重新被修改，等等。
這些資訊rman備份都不會記錄，也是rman無法記錄的。但是記錄這些資訊的是redo file，所以在rman完畢建議馬上執行日誌切換，然後備份歸檔日誌，因為在rman恢復過程中，對於inconsistent backup，rman要靠這些已經歸檔的redo file資訊恢復和保持資料庫的一直狀態。
由此，我們可以可以看出，其實歸檔檔案中真正有用的是從rman備份開始到rman備份結束時刻系統產生的歸檔日誌。同時rman在恢復的時候，restore database完畢後，會依次利用歸檔日誌和聯機日誌進行完全恢復。此時利用的這些歸檔就是從rman備份開始到rman備份結束產生的歸檔日誌。
因此備份歸檔日誌是很必要的，當然聯機日誌也是必須的，這些日誌保證了rman能夠完全的恢復資料庫。
4. 熱備份和rman 在redo 上的區別：
關於熱備份的一些知識見blog：
對oracle 備份與恢復 的補充說明
熱備份下 歸檔增加 的原因：
熱備份的時候redo log會增長較快，歸檔較平時增多，是由於在begin backup之後，如果正在備份（也就是os命令拷貝cp）的資料塊恰好又在被使用者修改(因為是熱備份，使用者可以操作)，那麼可能會產生split block的情況(split block被oracle認為是corrupt block)，也就是說，乙個oracle block可能包含多個os block, os level的拷貝可能正拷貝的是乙個oracle block的一部分(比如header)，而另一部分(比如尾端)被使用者更新，發生變化，這樣導致乙個oracle block內部的不一致(不是consistent version),可能出現乙個資料塊包含了幾個不同版本的作業系統塊,被稱為split block。
注意：這裡split block是oracle block不是os block，是因為乙個oracle block中不同版本的os block才導致產生split oracle block的。
oracle處理split block的方法是將整個當前oracle split block(變更後的)寫入online redo log中,恢復的時候如果發現datafile中某個oracle block中有不同版本(的os block)，就從redo把這個變更後的映象拷貝回來，在這個版本一致的映象上開始恢復。 不是像原來那樣只寫入更新部分到redo log, 所以熱備期間redo log會激增 。
通過以上面的分析，可以看出，如果用熱備份，那麼會產生大量的redo log。 因為熱備份把不一致的內容全部寫入了redo log。
而rman 備份允許不一致備份，那些不一致的資料塊也會直接備份，但是，在這種情況下，必須通過應用歸檔檔案，使資料塊一直之後才能開啟資料庫。 所以rman 不會產生大量的redo，這也是rman的優點之一。
p s：
整理這篇文章是費了很多的腦細胞，因為理論的東西確實不好理解。 現在我把我對這塊的理解整理了一下。 正確與否，還有待時間的考驗。 因為隨著時間的流逝，對oracle的理解也在慢慢的變化。 以後會越來越清楚。 和 杭州恆生 這位朋友的討論的收穫就是加深了對rman 資料塊 這方面的理解。 也算是進步吧。 還是感覺做實驗比較直觀，按照文件一步一步下來，然後結果出來，正確，就大功完成了。 但理論這東西屬於做學問，要花時間去理解，去研究。 費腦細胞啊….
資料庫 併發一致性問題
在併發環境下，事務間的隔離性很難保證，因此會出現併發一致性問題。併發一致性問題主要有四類，即 丟失修改問題，讀髒資料問題，不可重複讀問題，幻影讀問題。丟失修改問題 t1和t2兩個事務都對同一資料進行修改，t1先修改，t2隨後修改，t2的修改覆蓋了t1的修改。讀髒資料問題 t1修改了乙個資料，t2隨後...
快取與資料庫一致性問題
業務場景 抓拍到的人臉需要推送到第三方系統，但不是所有的網點都需要推送資訊。也就是要做到不同的網點可以根據配置來決定是否推送，前端頁面需要有推送配置功能，手動配置後，把配置的推送資訊儲存到資料庫。抓拍到人臉 後，讀取配置的推送資訊，再判斷是否需要推送。由於網點多抓拍的人臉資料量較大，推送資訊配置後不...
資料庫和快取一致性問題
前言 快取一致性是指業務在引入分布式快取系統後，業務對資料的更新除了要更新儲存以外還需要同時更新快取，對兩個系統進行資料更新就要先解決分布式系統中的隔離性和原子性難題。目前大多數業務在引入分布式快取後都是通過犧牲小概率的一致性來保障業務效能，因為要在業務層嚴格保障資料的一致性，代價非常高，業務引入分...