tsn: 6 afn: 97 hint: f hash: [0x700000157972b00,0x700000157972b00] lru: [0x70000012ef09348,0x70000012ef091d0] ckptq: [NULL] fileq: [NULL] objq: [0x70000012ef087b0,0x70000014153f8a0] objaq: [0x70000012ef087c0,0x70000014153f890] st: SCURRENT md: NULL fpin: 'ktspfwh13: ktspGetNextL1ForScan' tch: 4 le: 0x700000043fd8780 flags: auto_bmr_tried LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535] Block dump from disk: buffer tsn: 6 rdba: 0x1845b301 (97/373505) scn: 0x0c91.d8604ed8 seq: 0xff flg: 0x04 tail: 0x4ed845ff frmt: 0x02 chkval: 0xcafb type: 0x45=NGLOB: Lob Extent Header Hex dump of block: st=0, typ_found=1 Dump of memory from 0x0000000110AEA800 to 0x0000000110AEC800 110AEA800 45A20000 1845B301 D8604ED8 0C91FF04 [E....E...`N.....] 110AEA810 CAFB0000 B9138F29 9DC40000 05B6CCDA [.......)........] |
大家可以看下这个坏块的type，居然是0×45，说这是一个lob extent header block。开始我还以为这个表存在lob字段，最后desc看了下表结构，根本没有lob字段。可见这个block是写乱了。大家知道处理坏块的方法无法就是10231 event，dbms_repair，以及dbms_rowid来处理。当时试了几种方法均不行。其中10231 event和dbms_repair本质上差不多，都是标记坏块，跳过多块读。而dbms_rowid则是根据坏块获取rowid，然后根据rowid来抢救数据。居然也不行，比较怪。最后我干脆创建一个空间，分配到该文件，然后delete掉数据，然后dd一个空块，修改掉rdba和obj id，然后直接dd替换。后记：后面让同事全库检查，还发现了20来个数据坏块，不过大多是Index，处理相对简单，我就不参与了。