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                                                 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9240380/viewspace-757732/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9240380/viewspace-757732/