先看官方文檔上的一段話：
Consistent Backups
You can use the BACKUP command to make consistent and inconsistent backups of the database. A consistent backup occurs when the database is in a consistent state. A database is in a consistent state after being shut down with the SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands. A consistent shutdown guarantees that all redo has been applied to the datafiles. If you mount the database and make a backup at this point, then you can restore the database backup later and open it without performing media recovery.
Any database backup that is not consistent is an inconsistent backup. A backup made when the database is open is inconsistent, as is a backup made after an instance failure or SHUTDOWN ABORT command. When a database is restored from an inconsistent backup, Oracle Database must perform media recovery before the database can be opened, applying any pending changes from the redo logs.
Note:
RMAN does not permit you to make inconsistent backups when the database is in NOARCHIVELOG mode. If you employ user-managed backup techniques for a NOARCHIVELOG database, then you must not make inconsistent backups of this database.
If the database runs in ARCHIVELOG mode, and you back up the archived redo logs and datafiles, inconsistent backups can be the foundation for a sound backup and recovery strategy. Inconsistent backups offer superior availability because you do not have to shut down the database to make backups that fully protect the database.
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關係
http://blog.csdn.net/tianlesoftware/archive/2010/01/25/5251916.aspx
只有當數據庫正常關閉，既通過normal,immediate,transactional選項關閉數據庫，而後進行的備份纔是一致的，如果instance fails或者shutdown abort進行關閉，那麼數據文件是不一致的，這時當數據庫打開時是需要instance 恢復，（當然數據庫是read-only database不需要進行instance 恢復）
Oracle 通過checkpoint進程使控制文件和數據文件擁有一致的scn，當表空間處於只讀（read-only）或者offline normal tablespace 時，允許使用舊的scns，這時該表空間中的數據文件跟其他的數據文件仍然被認爲是一致的，因爲在脫機後，表空間沒有進行任何新的改變。
當數據庫restore 一致性數據庫全備份後，打開數據庫將不需要應用redo，因爲數據已經是一致的，不需要新的動作使數據文件變正確。
在noarchivelog模式下，一致性全備份是唯一有效的選擇，因爲如果選擇了不一致性備份，那麼恢復需要apply redo，而非歸檔模式下，所需要的redo logs有可能是不存在磁盤上。
2 Inconsistent backup:
非一致性備份是備份中的數據文件和控制文件他們沒有被checkpointed至相同的scn，oracle將不能打開數據庫直到所有的文件頭header
scns是consistent，也就是說，直到在線重做日誌中所有的改變的記錄都應用到磁盤中數據文件中。
這裏是我們討論的重點。 因爲如果數據庫處與open 狀態，那麼數據塊就會被修改，SCN 也會發生相應的變化。 但是RMAN 在備份前是通過快照控制來參考的。這就會造成不一致狀態。
控制文件存儲數據庫的結構信息，這些信息包括用於恢復的檢查點SCN信息。但是控制文件是一個非常繁忙的文件，連續的SCN 和文件管理對於數據庫的生命期來說至關重要，因此RDBMS 必須能夠持續的使用控制文件。
而RMAN 開始備份每一個數據文件時需要得到一個一致的控制文件視圖， RMAN需要知道備份開始時最新的檢查點信息和文件信息。開始備份後，RMAN 需要這些信息在備份操作期間保持一致，也就是說RMAN需要一個讀取一致的控制文件視圖。除非RMAN 在備份持續時間內鎖定控制文件，否則數據庫會不斷更新控制文件，所以不可能。 但是，鎖定控制文件意味着數據庫不能執行檢查點操作和切換日誌，或則不能產生新的歸檔日誌，這些操作是不可能的。
所以就有了快照控制文件（snapshot controlfile），快照控制文件是控制文件的副本。 RMAN 只在備份和同步操作期間使用快照控制文件。 這些操作開始時，RMAN 會根據實際控制文件來刷新快照控制文件，這樣會短暫的鎖住控制文件，隨後，RMAN 會切換到快照並在備份持續使用這個快照。 這種方式具有讀取一致性，且不妨礙數據庫活動。
作爲24*7的系統，唯一的選擇是進行非一致性的備份，這時數據庫必須是歸檔模式，當offline a tablespace進行備份時，那麼這時這個表空間中的數據文件將跟其他表空間是不一致的了，因爲數據庫在進行活動，數據庫中的其他部分會被修改，那麼這是offline和online的數據文件可能會包含不一致的scn。
當數據庫處於歸檔模式下，可以建立一個全備份使用備份在線數據文件在不同的時間，例如，在不同時間分別備份數據庫中所有的表空間及控制文件，我們認爲這種交錯排列的備份是一個全備份。
關閉狀態下，可以進行非一致性備份，當數據庫處於歸檔模式下，如果關閉時使用了shutdown abort，那麼關閉後進行的備份，就是不一致性備份，但這個備份是有效的，因爲可以應用在線和歸檔重做日誌使數據庫在打開的時候處於一致。
而在noarchivelog模式下，進行的非一致性全數據庫備份，僅僅當redo logs包含所有在上次backup以來的改變，這種情況很少也不希望發生。oracle強烈建議別在noarchivelog 模式下進行shutdown abort命令，如果沒有歸檔重做日誌，那麼將是不可能恢復。
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 備份與恢復 的補充說明
http://blog.csdn.net/tianlesoftware/archive/2010/06/04/5647494.aspx
熱備份下 歸檔增加 的原因：
熱備份的時候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 數據塊 這方面的理解。 也算是進步吧。 還是感覺做實驗比較直觀，按照文檔一步一步下來，然後結果出來，正確，就大功完成了。 但理論這東西屬於做學問，要花時間去理解，去研究。 費腦細胞啊….