塊分裂

塊分裂原理          

      執行begin bacckup之後，oracle會把将要備份的資料檔案都标記為hot-backup-in-progress，鎖定所要備份的datafile header的scn，例如此時scn=100,同時redolog中會記住這個scn，其他資料檔案正常使用，scn會繼續增長。之後再備份所要備份的資料檔案過程中，資料檔案是允許寫入和checkpoint，而且可能不止一次checkpoint，而這個過程中的所有操作和checkpoint也會正常記錄到redolog與archivelog中。

       假如oracle系統資料檔案最小存儲單元是資料塊，比如8192bytes，而作業系統的最小存儲單元os塊為固定的512bytes，這樣問題就産生了。

       在oracle執行begin backup之後進行copy操作，這個copy操作底層屬于作業系統的指令，每次隻能copy一個os block，假如oracle資料塊的block機關為8192bytes，那麼這個oracle block就由16個os block組成，這裡為了友善了解，我們把他們标記為1-16個os block。copy指令對于資料塊的拷貝時沒有順序的，也就是說第一次可能copy 1号block，而第二次可能就會copy 16号block。而在這個copy過程中，對于oracle熱備份機制來說對oracle整個的block是允許讀寫的，這樣就會産生如下的問題，例如：執行begin backup,oracle鎖定datafile header的scn，假設此時oracle block中存儲的資料是10，敲copy進行複制，系統就會将這個oracle block中的16個os block一個一個地拷貝到備份目錄，假如拷貝到第五個os block時候，如果資料寫入，例如需要将這個資料塊中的資料update為20，oracle就會調用dbwr程序對這個資料塊進行資料修改，同樣dbwr程序也是不順序地将資料寫入這16個os block，是以他就有可能從已經拷貝完的哪五個os塊中開始寫資料，也有可能從剩下的11個os block中開始寫資料。如果從剩下的11個os block中開始寫入的話，就會帶來一個嚴重的後果，熱備份copy正在進行，而剩下的11個block其中的幾個有可能資料已經改變，這樣copy出來的備份檔案肯定會不一緻，copy出來的備份檔案對于這個oracle block來說前5個block是原來存儲資料10的資訊，而後來copy的11個block就有可能存儲的是update之後的資料20的資訊，這樣是絕對不允許的。

（自己的了解：

        塊分裂：資料庫1個塊相當于作業系統16個塊，在轉儲時，資料檔案改變，導緻16個系統塊中前5個的scn為2000，後11個scn為2001，也就是說前後不一緻，對應的資料庫塊，既不是更新前的資料，也不是更新後的資料。

 解決方法：

         将update之前的鏡像對os塊進行覆寫，在用日志對其恢複。）

         是以，oracle做了這樣的一個機制，在copy過程中如果需要有資料update，dbwr程序告訴oracle我要update，這時候oracle就會通知備份系統，先把所要寫入的那個Oracle black完全鏡像到redo中，redo記錄的是整個資料塊的鏡像，而不是一條資訊。之後dbwr在開始向這個oracle block中的16個os block随機寫入資料。這樣，在資料恢複的時候，oracle檢查是從被鎖定的那個scn時刻起開始恢複，如果檢查到那個時間點上的某個oracle block出現上述所說的那種"損壞的block‘，他就會将redo中的鏡像在完全copy到這個oracle block，這樣，這個資料塊就是begin backup的那個時間點時候的完整的資料庫了，之後redo就可以從這個scn進行向後的恢複工作。