如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com
本文件将说明在发生块故障时，查看破损块的方法
。
查看破损块、修复以及调查原因的方法请查看以下文件
查看损坏的而数据块
==================
■ 指定对象
1) DBA 可以指定时
- 使用以下SQL语句，通过DBA查看 FILE#, BLOCK#。
SQL> SELECT dbms_utility.data_block_address_file(DBA#) "FILE#", dbms_utility.data_block_address_block(DBA#) "BLOCK#" FROM dual;
Document 1702410.1(KROWN:11887) 从数据块地址中获得文件编号以及块编号的方法
2.通过已查看到的 FILE#,BLOCK# 使用以下SQL语句，指定破损对象。
SQL> SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME FROM DBA_EXTENTS WHERE <FILE#> = FILE_ID AND <BLOCK#> BETWEEN BLOCK_ID AND BLOCK_ID+BLOCKS -1;
2) 已指定FILE#,BLOCK# 时
使用以下SQL语句，指定破损对象。
SQL> SELECT SEGMENT_TYPE,OWNER||'.'||SEGMENT_NAME FROM DBA_EXTENTS WHERE <FILE#> = FILE_ID AND <BLOCK#> BETWEEN BLOCK_ID AND BLOCK_ID+BLOCKS -1;
** 注意 **
SQL语句以及alert日志、从追踪文件中查看到的 FILE#因为是相对文件编号，所以在
dba_data_files.relative_fno 中我们可以查看到多个相对文件
。
Document 1710756.1(KROWN:32555) Oracle8开始，文件编号的注意事项
**********
■ 查看破损
查看指定对象的破损。
1) 执行ANALYZE
SQL> ANALYZE TABLE <TABLE_NAME> VALIDATE STRUCTURE; SQL> ANALYZE TABLE <TABLE_NAME> VALIDATE STRUCTURE CASCADE; SQL> ANALYZE INDEX <INDEX_NAME> VALIDATE STRUCTURE;
* analyze 命令使用缓冲区上的数据。
磁盘上没有破损，仅仅缓存区中破损的例子
但因为检测到了错误，请尽可能重启后执行分析。
2) 执行dbv
$ dbv file=<datafile_path> blocksize=<block_size>
* ASM 的环境中，代替dbv，使用RMAN执行检测
RMAN> BACKUP CHECK LOGICAL VALIDATE DATABASE;
3)获得块的dump信息
SQL> ALTER SYSTEM DUMP DATAFILE 绝对文件号 BLOCK MIN <BLOCK#-10> BLOCK MAX <BLOCK#+10>;
4) 获得物理转储
- HP-UX 的情况 % dd bs=<block_size> if=<datafile_path> skip=<block#-10> count=21 | od -x > dump.txt - Solaris, Linux, AIX 的情况 % dd bs=<block_size> if=<datafile_path> skip=<block#-10> count=21 | od -x -v > dump.txt *前后共计获得21个块。
■ 查看备份
查看获得了怎样的备份。
– 用户管理的online（offline）备份
– 使用RMAN 的online（offline）备份
– exp/imp (或者Datapump) 使用utility的理论备份
– csv 形式中的备份等
搜索DBA_EXTENTS 时的问题
——————————–
指定对象时查看到的DBA_EXTENTS 的 SELECT 的結果在
“no rows selected”时会有。
“no rows selected” 时如下所示。
– EXTENT 已经开放的块（未使用的块）
为了查看dbv 中没有获得 EXTENT 的块，根据情况不同输出Corrupt。
详细内容请查看一下文档。
Document 1720681.1(KROWN:60310) 使用DBV时发生错误
※ 开放EXTENT的块中的破损不需要处理。
– 本地管理表区域的bitmap 块
本地管理表区域的bitmap块因为不是段，由于没有获得extent，所以无法通过查看DBA_EXTENTS。
在数据文件vendor中，64KB变成了bitmap块，虽然块编号较小，但请通过块转储来查看
为了确认到底是上述哪个案例，需要在已获得的文件转储中调查块类型。
查看块类型是 “KTFB Bitmapped File Space Header” (0x1D)或者
“KTFB Bitmapped File Space Bitmap” (0x1E)。
“KTFB Bitmapped File …” 中，对象块，因为是bitmap 块。
此外的块类型都是EXTENT开放的块。
可以从块转储的以下地址中查看。
------------------ buffer tsn: 0 rdba: 0x00400062 (1/98) scn: 0x0000.000fee5a seq: 0x01 flg: 0x06 tail: 0xee5a0601 frmt: 0x02 chkval: 0x5b40 type: 0x06=trans data ^^^^^^^^^^^^^^^^^^^^^ <--- ★ 查看这个类型。 ------------------
没有获得理论转储的案例中，通过binary来查看。
块类型为 0x1D 或者 0x1E 时就是bitmap块。
------------------ CEE1C00 0000A206 00400062 000FEE5A 06010000 CEE1C10 00005B40 00000002 0000000B 000FEE59 CEE1C20 00000000 00020002 00000000 00000000 CEE1C30 00000000 00000000 00000000 00000000 CEE1C40 00000000 00200003 000001EF 00801CE3 CEE1C50 000500BD 00002001 000FEE5A 01800000 CEE1C60 00000000 00A80042 1B5F1BFA 00000000 CEE1C70 00000000 00000000 00000008 00001F60 CEE1C80 1F531F47 1F2D1F3A 1F131F20 1EF91F06 ------------------
* 这是Linux 的输出例。Big endian以及Block in little endian类型储存的位置不同，请大家注意。
Comment