[Oracle数据库] 深入分析ora-600 2662错误系列一

结论 1,本文主要分析ora-600错误从报错分为数字和函数 2,本文主要分析ora-600的数字报错 3,像ora-600错误大家我特定的操作有关，涉及的ORACLE机制比较复杂，具体说可能和REDO,UNDO等等有关，首先要确认到底是哪块有问题了，这样解决问题才有针对性 4，由3就引申出来，一定要全方位查阅MOS文章，获取ORA-600方面的分析文章，ID175982.1 此文极佳，建议大家精读，把报错区别为不同的模块或层次，这样解决问题就有进一步的思路了 5，由于ORA-600错误多半很复杂，所以需要你对ORACLE原理及机制很熟悉或理解，更具体一些，就是要读懂TRC文件 6，从本文测试可知，ORA-600 2662错误，其TRC文件的重点关注结构有： 报错的进程 报错的SQL --由此可知到底是什么对象出错了，进行针对性分析，比如换个对象会不会不出错，进行对比分析 报错的波函数调用堆栈 --以此信息在MOS进行查找，获取进一步的文档或信息，以进行进一步的分析，当然也可能是BUG library cache dump -- 报错进程的PROCESS STATE DUMP --可以获取报错进程当前在等待什么事件以及历史的等待事件，等待哪个数据文件及数据块，获取进一步的分析线索 UNDO BLOCK相关信息 ---这个暂时作用未知 绑定变量信息 --用此可知报错SQL的具体内容是什么，或者是什么对象，进行进一步的分析 进程的MAP信息 ---此信息作用暂时未知 7，ora-600错误非常复杂，后面的参数有数不清，引申就是一定要对ORACLE的原理有进一步精深的理解，方可诊断ORA-600错误 8，由ora-600 2662可见，涉及到UNDO BLOCK,UNDO SEGMENT HEADER BLOCK,SCN，你要完全搞懂这个报错，一定要把这些数据结构全搞通方可 当然你去查MOS，也会告诉你现成答案，不知我想大家都想知其所以然，所以掌握原理极为重要，道方为根本 9，对了，再补充一个分析，在ALERT报错ORA-600 2662错误前，一般也会有伴随性的其它报错，也可以分析这些报错，即可以进一步理解为何会报600错误  扩展问题 1,进一步学习undo block,undo segment header block,data block以及scn的概念及相互关系 最终达到的目标就是更多了解ORACLE在这些方面的机制是什么，可以快速诊断ORACLE一些怪异的ORA-600报错  分析思路  测试  ---分析600错误时，要通过alert去查看近邻之前有无什么特殊的操作及报错，由下可见600错误是和恢复有关 Errors in file /home/ora10g/admin/asia/bdump/asia_cjq0_27483.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-08176: consistent read failure; rollback data not available Tue Dec 01 01:19:19 EST 2015http://www.kmnk03.com/hxpfk/tf/344.html Errors in file /home/ora10g/admin/asia/bdump/asia_smon_27479.trc: ORA-00600: internal error code, arguments: [2662], [0], [115], [0], [333574], [8388713], [], [] 经查MOS一文：ID175982.1，详细 列举了600错误的分类，共计13个不同的layers 和 modules 可见2662属于2000，即Cache Layer，和数据一致性有关，即和恢复有关，而数据一致性一般和SCN有关，即CHECKPOINT_CHANGE有关 再查阅MOS，找到2662相关的文章，获取各个参数的含义 ORA-600[2662] Block SCN is ahead of Current SCN [ID 28929.1] ORA-00600: internal error code, arguments: [2662], [0], [115], [0], [333574], [8388713], [], [] ORA-600 各个参数的格式和说明如下： ERROR: ORA-600 [2662] [a] [b] [c] [d] [e] ARGUMENTS: Arg [a] Current SCN WRAP Arg [b] Current SCN BASE Arg [c] dependent SCN WRAP Arg [d] dependent SCN BASE Arg [e] Where present this is the DBA wherethe dependent SCN came from http://www.kmnk03.com/hxpfk/tf/345.html 可见2662代表就是数据库哪个层有问题 0代表current scn wrap 115代表current scn base 0代表dependent scn wrap 333574代表depdendent scn base 8388713代表dependent scn是源于哪个数据块即dba,也就是这个参数和前述的2个参数dependent scn base及dependent scn wrap就关联起来了，我理解可能是某个具体数据块 FUNCTION DATA_BLOCK_ADDRESS_BLOCK RETURNS NUMBER Argument Name Type In/Out Default? ------------------------------ ----------------------- ------ -------- DBA NUMBER IN FUNCTION DATA_BLOCK_ADDRESS_FILE RETURNS NUMBER Argument Name Type In/Out Default? ------------------------------ ----------------------- ------ -------- DBA NUMBER IN --获取600错误最后一个参数 8388713的含义，到底是哪个文件，哪个数据块 SQL> select dbms_utility.DATA_BLOCK_ADDRESS_FILE(8388713) file_id,dbms_utility.DATA_BLOCK_ADDRESS_BLOCK(8388713) block_id from dual; http://www.kmnk03.com/hxpfk/tf/346.html FILE_ID BLOCK_ID ---------- ---------- 2 105 可见是和回滚段 有关，也证明我前面的分析，2662就是和数据一致性有关，即数据恢复 SQL> select owner,segment_name,segment_type from dba_extents where file_id=2 and block_id=105; OWNER SEGMENT_NAME SEGMENT_TYPE ------------------------------ --------------------------------------------------------------------------------- ------------------ SYS _SYSSMU7$  --从另一个角度分析可见上述报错涉及的回滚段共计占用66个数据块 SQL> select count(*) from dba_extents where segment_name='_SYSSMU7$' 2 ; COUNT(*) ---------- 66 SQL> select distinct block_id from dba_extents where segment_name='_SYSSMU7$' order by 1; BLOCK_ID ---------- 105 113 249 中间略 37065 37257 38537 39945 66 rows selected. --既然是2号文件的105数据块报错，DUMP这个数据进行分析 Start dump data blocks tsn: 1 file#: 2 minblk 105 maxblk 105 buffer tsn: 1 rdba: 0x00800069 (2/105) scn: 0x0001.00000e73 seq: 0x02 flg: 0x00 tail: 0x0e732602 ---scn frmt: 0x02 chkval: 0x0000 type: 0x26=KTU SMU HEADER BLOCK ---可见是回滚段头块 Hex dump of block: st=0, typ_found=1http://www.kmnk03.com/hxpfk/tx/347.html Extent Control Header ----------------------------------------------------------------- Extent Header:: spare1: 0 spare2: 0 #extents: 66 #blocks: 3647  last map 0x00000000 #maps: 0 offset: 4080  Highwater:: 0x00800158 ext#: 4 blk#: 7 ext size: 8  #blocks in seg. hdr's freelists: 0  #blocks below: 0  mapblk 0x00000000 offset: 4  Unlocked Map Header:: next 0x00000000 #extents: 66 obj#: 0 flag: 0x40000000 ---extent map控制extent分配的情况，对应dba_extents的extents总数 Extent Map ----------------------------------------------------------------- 0x0080006a length: 7  0x00800071 length: 8  0x008000f9 length: 8  0x00800131 length: 8  0x00800151 length: 8  0x00800159 length: 8  0x008001e1 length: 8  0x00800201 length: 8  0x008002c1 length: 8  0x008002e9 length: 8  0x00800329 length: 8  0x00800381 length: 8  0x008003c1 length: 8  0x008003e9 length: 8  0x00800449 length: 8  0x00800461 length: 8  0x00800509 length: 128  0x00800a89 length: 128  0x00801309 length: 128  0x00801709 length: 128  0x00801c89 length: 128  0x00802109 length: 128  0x00802689 length: 128  0x00802e89 length: 128  0x00803109 length: 128  0x00803689 length: 128  0x