歸納熱備份機制

熱備期間最大的特點就是產生了比平常更多的日誌檔案，為什麼會這樣？在恢復的時候有什麼用呢？

熱備期間日誌檔案記錄的是修改的row所在的整個block的image，而不僅僅是修改的row的資訊。
這樣做的目的是為了儘量避免熱備份的資料檔案中因為包含SPLIT BLOCK ，而不能用於恢復的可能性。
為了理解這段話，還要提一下SPLIT BLOCK的概念.

我們都知道，oracle 的block 是由多個OS blocks組成。比如，某個Unix 檔案系統使用 512bytes
的blocksize，而oracle 使用8k 的db_block_size. 當熱備份資料檔案的時候，我們使用檔案
系統的命令工具copy 拷貝檔案，並且使用檔案系統的blocksize 讀取資料檔案。

假設這種情況：當我們拷貝資料檔案的同時，資料庫正好向資料檔案寫資料。這就使得拷貝的檔案中
包含這樣的database block，它的一部分OS block 來自於資料庫向資料檔案(這個db block)寫操作之前，
另一部分來自於寫操作之後。這個database block就是一個SPLIT BLOCK.

所以，通過在日誌中記錄整個變化的db block 的image，可以保證在恢復的過程中，任何在熱備的資料檔案中出現的
SPLIT BLOCK可以通過日誌檔案中的full image of the block 覆蓋掉得以解決。以保證將來恢復的成功。

我的問題：

我一直對為什麼begin backup後要鎖定這個資料檔案的checkpoint scn 不太明確？

我的理解和猜測：

熱備過程中使用統一的checkpoint scn ，可以在日至檔案中很方便的找到哪些日誌是hot backup時產生的日誌，這個過程中的有可能產生SPLIT BLOCK ，需要在恢復時特別注意。而不需要影響到其他的block。

大家有什麼意見？

凍結的checkpoint  scn , 使得備份出來的檔案可以從該scn（實際上對應了日誌檔案的RBA）開始恢復，這樣保證所有的block都能得到完好的恢復（當然包括split  block）。另：檔案被拷貝的時候，並不能確保檔案頭是最先被完整地拷貝成功的。


BTW: 檔案置於熱備份狀態之後，當buffer第一次被修改的時候產生整個塊的before image。注意是buffer而不是block。 也就是說，當buffer被寫入檔案再讀進來，再發生變化的時候將重新產生 block 的 before image。 這是由block中一個標誌位所控制的。

對於同一個block依次發生如下情景

file  block  ---server  process  read  from  file--- into  sga  buffer
buffer  ----  server  process modify  the buffer  --- generate  redo  (whole   block   before  image)
buffer  ---- server  process modify  the  buffer  agin  --- no  redo   for  block  before  image
sga buffer  --- dbwr write the  buffer  to  file  ----  file

file  block  ---server  process  read  from  file--- into  sga  buffer
buffer  ----  server  process modify  the buffer  --- genarate  redo  (whole   block   before  image)
……
……

在熱備過程中雖然資料檔案檔案頭中checkpoint scn更新被凍結,但資料檔案塊還是會被更新,導致在使用OS命令備份資料檔案時,備份的資料檔案會產生split現象,即在拷貝某個資料塊的過程中資料塊被更新,因此oracle就必須將資料塊的past image寫入日誌檔案中以用於重建SPLIT的資料塊.從而導致了日誌檔案的增大.past image的寫入受init.ora引數log_blocks_during_backup控制,預設值是true,表示須寫入日誌檔案

RMAN的熱備就取消了 alter tablespace... begin backup; 命令，不必鎖定資料檔案；而且不會產生多餘的日誌檔案。

這是因為：
RMAN採取了類似於 sql 查詢時的一致性讀的原理進行熱備的，所以不必要在日誌中產生整個快的image；並且將開始熱備時的scn 記錄在rman 目錄或者控制檔案中，不必要凍結資料檔案頭。

我的問題：
RMAN採取的一致性讀是什麼範圍的？
整個資料檔案？不應該，這樣跨越的範圍太大，對回滾段的要求太高；
還有，既然RMAN採取 oracle server process 讀取資料塊，我覺得本身就不會產生split block 的情況。

rman 使用了 large_pool_size 進行緩衝，寫出之前要再檢查 block 的一致性，如果是split  block 則重新讀取該塊，直到一致為止
實際上一致指的是block

rman 讀的時候不是讀整個塊嗎？ 如果是使用的 server process 讀的話，應該是讀整個block呀，為什麼還有split block的情況？

rman 讀的時候依然可能這個塊在發生變化，server  process 讀難道就能避免嗎？  如果正常情況的查詢，dbwr 在寫入檔案的時刻，server  process 在 data  buffer 中就可以得到自然不會去檔案中讀了 。而只要去檔案中讀，都可能出現不一致的情況，檔案有人在讀有人在修改都可能這樣的，因為讀寫並不阻塞，更沒有鎖定  oracle 的 block

rman 在把資料塊寫出去之前，會校驗塊的

如果是普通使用者的查詢，多個程式對於同一個塊的訪問，在8i中是序列的，在9i 中也只有 READ & READ 才可以，READ&write 也是序列的。  所以  server  process 讀資料的時候肯定不會有 正在發生變化的塊

其實也就是無所謂校驗split block了？
因為當RMAN在寫出一個block的時候，這個block一定是一致的
那麼是不是可以這樣認為，RMAN和老方式熱備區別只是在於，前者是oracle用後臺process在寫出資料檔案，而後者是作業系統的命令在copy資料檔案。
因為RMAN是oracle在幫你作copy block，所以無需記錄整個block image

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10697500/viewspace-401648/，如需轉載，請註明出處，否則將追究法律責任。