dsi401_block structure之(二)

dsi401_block structure之(二)

什麼是壞損壞
1,oracle讀寫塊(buffer or disk)，肯定會進行一致性檢查
2,一致性檢查內容：
     1,block version --refer to block dump
     2,cache中的dba和block buffer中的dba比較
     3,是否開啟db_block_checking and db_block_checksum
3,如何檢查上述內容呢
     1,基於塊頭的scnbase + seq    
     2,基於塊尾的scnbase + seq
     3,block type
     小結：所在block dump有個block header,block tail(想想tail的構成)
4,塊損壞的一些示例：
   ora-600(4519):cache layer block type is correct
  
5,block corrupation型別:
    1,介質損壞：
    　　　表現：scn=0
    2,邏輯或軟體損壞;
          表現：scn=xxx
                seq=ub1maxval
                注：xxx即最高或最大scn作的變化
                    這樣會導致重構整個資料塊
    3,兩種損壞型別型別的後果:
        1,media corruption:
           從磁碟讀取後此塊完全無用
        2,soft corrupt :
           發現塊不一致性了標記下此塊
          
6,ora-1578
      1,表明是硬體問題
      2,如果多時出現且引數相同,可能這個資料塊物理損壞了
      3,如多次出現但引數不同,可能硬體出故障了
        　檢查下：1,memory
                  2,io子系統的控制器是否正常
                如果可以得到出故障資料塊的編號
                  1,dd　dump
                  2,如果執行多次dd報錯,就要檢查下io子系統或者控制器是否出故障了
                 
                 

7,ora-600
      1,表現：ora-[600] [kcbzpb-1],[d],[kind],[chk],[],[]
      2,各引數含義：
            1,d --block number
              kind --損壞型別
              chk ---checksum flag
              kcbzpb-1 --內部錯誤，要參考source code
      3,此報錯發生於資料塊在記憶體中損壞
         即儲存在記憶體時破壞了塊頭和塊尾，這是它產生的唯一方法
        
8,處理壞塊途徑
   1,檢查alert或trace file
   2,使用診斷工具確定損壞型別
   3,dump確認到底出了什麼問題
   4,執行多次與損壞塊相關的業務，是否一直出現
   5,如必要恢復壞塊
  
   如發現一個壞塊，可能出現了多外壞塊，用dbverify檢查出錯的資料檔案
  
   用dd和od -x分析壞塊的產生原因
  
   對壞塊相關的redo log進行dump,確認何時資料塊的損壞開始時間
  
   如出現壞塊，修復硬體後，必須進行介質恢復
  
與壞塊相關的硬體故障型別：
　　1,io硬體或韌體
    2,os io或緩衝
    3,memory or paging
    4,disk
   
dbverify工具
  1,只能驗證data file,而非redo file
  2,檢查資料塊一致性
  3,dbv會對出問題的連續重2次，第2次才會標記為壞塊；如2次匹配，則標記為influx block
  4,influx block為split block;
  5,split block即：dbv首次讀取一個塊，爾後dbwr又寫入了一個此塊的新版本；導致
  　資料塊部分為老，部人為新;因此塊頭和尾不匹配
  6,所以可能還是會出現壞塊在hwm之上
  7,logical corruption:即驗證block header and block tail is match
 
analyze command
  1,logical block check
  2,不會標記它為soft corrupt,僅報告他們
  3,驗證表和索引
  4,analyze table x validate structure cascade;--cascade option
    analyze index x validte structure;
    analyze cluster xx validate structure;
    多次執行analyze
    analyze table x partition (p1) validate structure into invalid_rows;
  5,對於assm方式，hwm之下的unformatted block不會包括(refer to dsi 402 for detail)
 
診斷事件
  1,event='10231 trace name context forever,level 10';--based full table span,skip corrupt block
  2,event='10233 trace name context forever,level 10';--base index range scan ,skip corrupt block
  3,event 10232:dump corrupted block in a trace file
  4,event 10210 :force logical block checking,只要塊變化
  5,event 10211: 基於index block的10210
  6,event 10212:基於cluster block的10210
 
  7,10210,10211,10212的工作內容如下：
     1,free slot list結構
     2,資料塊內的row位置
     3,重疊的row position
     4,itl的lock count
     5,這些事件很費資源，不用馬上關閉
    
flash freeze
    1,oracle9i新特性,可以配置產生某個錯誤時觸發一個動作
    2,可以進一步分析問題的原因
    3,event='600 flashfreeze after 1 times on error ksuwaitsysevent_1'
      --發生上述錯誤一次觸發flash freeze
     
    4,--如果pmon產生1301 error
      event='600 flashfreeze on error 1301,proc=pmon'
    5,--如果發生事件10295,凍結所有的後臺程式oracle
      event='10295 flashfreeze,proc=bgs,instance=single'
      --不支援rac    
                        
                        
db_block_checking
   1,with it replace above    event from 10210 to   10212

dbms_repair package

bbed