oracle坏块修复实例

最近几天发现库里有坏块了,环境是11gR2, linux平台的64位的库。以下是我的修复办法,基于dbms_repair做的在线修复,也可以基于备份rman来修复,archivelog,noarchive log可能修复的方式有所不同。 -->首先从alert.log里面发现如下的错误。 DDE: Problem Key 'ORA 1110' was flood controlled (0x1) (no incident) ORA-01110: data file 8: '/dbTS2/oracle/TESTDB2/oradata3/data/TESTDB2_pool_data_03.dbf' Byte offset to file# 8 block# 570051 is 374890496 Incident 1567129 created, dump file: -->从trace文件里有更详细的描述。 /opt/app/oracle/testdb2/admin/TESTDB2/diag/rdbms/TESTDB2/TESTDB2/incident/incdir_1567129/TESTDB2_o ra_5396_i1567129.trc ORA-01578: ORACLE data block corrupted (file # 8, block # 570051) ORA-01110: data file 8: '/dbTS2/oracle/TESTDB2/oradata3/data/TESTDB2_pool_data_03.dbf' Dump continued from file: /opt/app/oracle/testdb2/admin/TESTDB2/diag/rdbms/TESTDB2/TESTDB2/trace/TESTDB2_ora_5396.trc ORA-01578: ORACLE data block corrupted (file # 8, block # 570051) ORA-01110: data file 8: '/dbTS2/oracle/TESTDB2/oradata3/data/TESTDB2_pool_data_03.dbf' ========= Dump for incident 1567129 (ORA 1578) ======== *** 2013-12-11 07:25:21.257 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0) ----- Current SQL Statement for this session (sql_id=7u9gsk798bvrp) ----- SELECT xxxxx FROM APP_CONTROL AC, APP_BILL_PROC BL WHERE APP.DATA_GROUP IS NOT NULL AND BL.PROCESS_ID = APP.NXT_PGM_NAME AND APP.FILE_STATUS IN ('RD', 'IU', 'CN') GROUP BY xxxxxxx -->尝试查看坏块的segment_type,确认一下是Index还是table segment出问题了。查询没有任何结果。 SQL> select segment_name,tablespace_name,segment_type,block_id,file_id,bytes from dba_extents where block_id=570051 and file_id=8; no rows selected -->运行日志中的sql,果断的报错了。 SELECT xxxxx FROM APP_CONTROL AC, APP_BILL_PROC BL WHERE APP.DATA_GROUP IS NOT NULL AND BL.PROCESS_ID = APP.NXT_PGM_NAME AND APP.FILE_STATUS IN ('RD', 'IU', 'CN') GROUP BY xxxxxxx * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 8, block # 570051) ORA-01110: data file 8: '/dbTS2/oracle/TESTDB2/oradata3/data/TESTDB2_pool_data_03.dbf' -->只是从相关的表里select count没有任何问题。 SQL> select count(*)from APP_CONTROL; COUNT(*) ---------- 1613 SQL> select count(*)from APP_BILL_PROC ; COUNT(*) ---------- 103 -->再次验证,还是报错。 SELECT xxxxx FROM APP_CONTROL AC, APP_BILL_PROC BL WHERE APP.DATA_GROUP IS NOT NULL AND BL.PROCESS_ID = APP.NXT_PGM_NAME AND APP.FILE_STATUS IN ('RD', 'IU', 'CN') GROUP BY xxxxxxx * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 8, block # 570051) ORA-01110: data file 8: '/dbTS2/oracle/TESTDB2/oradata3/data/TESTDB2_pool_data_03.dbf' --通过sys来调用dbms_repair来修复。 SQL> BEGIN 2 DBMS_REPAIR.ADMIN_TABLES ( 3 TABLE_NAME => 'REPAIR_TABLE', 4 TABLE_TYPE => dbms_repair.repair_table, 5 ACTION => dbms_repair.create_action, 6 TABLESPACE => '&tablespace_name'); 7 END; 8 / Enter value for tablespace_name: old 6: TABLESPACE => '&tablespace_name'); new 6: TABLESPACE => 'POOL_DATA'); PL/SQL procedure successfully completed. -->以上的步骤会生成一个表repair_table SQL> desc repair_table Name Null? Type ----------------------------------------- -------- ---------------------------- OBJECT_ID NOT NULL NUMBER TABLESPACE_ID NOT NULL NUMBER RELATIVE_FILE_ID NOT NULL NUMBER BLOCK_ID NOT NULL NUMBER CORRUPT_TYPE NOT NULL NUMBER SCHEMA_NAME NOT NULL VARCHAR2(30) OBJECT_NAME NOT NULL VARCHAR2(30) BASEOBJECT_NAME VARCHAR2(30) PARTITION_NAME VARCHAR2(30) CORRUPT_DESCRIPTION VARCHAR2(2000) REPAIR_DESCRIPTION VARCHAR2(200) MARKED_CORRUPT NOT NULL VARCHAR2(10) CHECK_TIMESTAMP NOT NULL DATE FIX_TIMESTAMP DATE REFORMAT_TIMESTAMP DATE -->来定位schema object中的坏块情况 SQL> set serveroutput on DECLARE num_corrupt INT; SQL> 2 BEGIN 3 num_corrupt := 0; 4 DBMS_REPAIR.CHECK_OBJECT ( 5 SCHEMA_NAME => '&schema_name', 6 OBJECT_NAME => '&object_name', 7 REPAIR_TABLE_NAME => 'REPAIR_TABLE', 8 corrupt_count => num_corrupt); 9 DBMS_OUTPUT.PUT_LINE('number corrupt: ' || TO_CHAR (num_corrupt)); 10 END; 11 / Enter value for schema_name: TSTAPPO2 old 5: SCHEMA_NAME => '&schema_name', new 5: SCHEMA_NAME => 'TSTAPPO2', Enter value for object_name: APP_CONTROL old 6: OBJECT_NAME => '&object_name', new 6: OBJECT_NAME => 'APP_CONTROL', number corrupt: 1 PL/SQL procedure successfully completed. -->查询生成的坏块表,里面有相应的记录。指向的坏块确实是日志中指定的。 SQL> select BLOCK_ID, CORRUPT_TYPE, CORRUPT_DESCRIPTION 2 from REPAIR_TABLE; BLOCK_ID CORRUPT_TYPE ---------- ------------ CORRUPT_DESCRIPTION -------------------------------------------------------------------------------- 570051 6148 -->修复坏块 SQL> DECLARE num_fix INT; 2 BEGIN 3 num_fix := 0; 4 DBMS_REPAIR.FIX_CORRUPT_BLOCKS ( 5 SCHEMA_NAME => '&schema_name', 6 OBJECT_NAME=> '&object_name', 7 OBJECT_TYPE => dbms_repair.table_object, 8 REPAIR_TABLE_NAME => 'REPAIR_TABLE', 9 FIX_COUNT=> num_fix); 10 DBMS_OUTPUT.PUT_LINE('num fix: ' || to_char(num_fix)); 11 END; 12 / Enter value for schema_name: TSTAPPO2 old 5: SCHEMA_NAME => '&schema_name', new 5: SCHEMA_NAME => 'TSTAPPO2', Enter value for object_name: APP_CONTROL old 6: OBJECT_NAME=> '&object_name', new 6: OBJECT_NAME=> 'APP_CONTROL', num fix: 0 PL/SQL procedure successfully completed. -->对于坏块的操作都能够skip SQL> BEGIN DBMS_REPAIR.SKIP_CORRUPT_BLOCKS ( 2 3 SCHEMA_NAME => '&schema_name', 4 OBJECT_NAME => '&object_name', 5 OBJECT_TYPE => dbms_repair.table_object, 6 FLAGS => dbms_repair.SKIP_FLAG); 7 END; 8 / Enter value for schema_name: TSTAPPO2 old 3: SCHEMA_NAME => '&schema_name', new 3: SCHEMA_NAME => 'TSTAPPO2', Enter value for object_name: APP_CONTROL old 4: OBJECT_NAME => '&object_name', new 4: OBJECT_NAME => 'APP_CONTROL', PL/SQL procedure successfully completed. -->再次运行以上的sql,尝试。 SQL> l SELECT xxxxx FROM APP_CONTROL AC, APP_BILL_PROC BL WHERE APP.DATA_GROUP IS NOT NULL AND BL.PROCESS_ID = APP.NXT_PGM_NAME AND APP.FILE_STATUS IN ('RD', 'IU', 'CN') GROUP BY xxxxxxx ;

working....

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-03-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏清风

hadoop hive 与 Oracle 互相导入数据

673
来自专栏杨建荣的学习笔记

生产环境sql语句调优实战第五篇(r2笔记41天)

今天在生产环境中发现一条sql语句尽管走了主键索引,但是查询还是很慢。 sql语句类似下面的形式: SELECT /*+ index (bl1_cyc_paye...

3368
来自专栏杨建荣的学习笔记

关于desc的一个奇怪问题及分析(r2第18天)

在平时的工作中,desc这个命令可谓短小精悍,可以很方便的查看表结构和not null的情况。 今天在生产环境中碰到一个有些奇怪的desc问题。 首先是数据迁移...

2665
来自专栏数据和云

高手过招:用SQL解决环环相扣的刑侦推理问题(苏旭辉版本)

本文是继 杨长老 刑侦高考:如何用SQL解决环环相扣的刑侦推理问题 之后,苏旭辉的一个版本,希望大家能够在高手的过招中,看到喜爱、坚持、执着与技艺。

912
来自专栏杨建荣的学习笔记

关于sql_profile中的绑定变量(r4笔记第57天)

使用sql_profile来调优一些紧急的性能sql可以起到立竿见影的效果,如果sql语句本身结构就很清晰,简单,略作修改就能得到调优后的sql语句。 但是如果...

3396
来自专栏数据和云

运维技巧 - 活用临时表隔离冷热数据

编辑手记:Oracle给了我们很多工具,在日常数据库管理中活用这些工具方可发挥最大效能。 作者简介: 张洪涛 富士康 DBA 在数据库监控过程中发现考勤数据...

3455
来自专栏闵开慧

phpmyadmin中导入文件时显示 No database selected

错误 SQL 查询: -- 数据库: `7789_pay` -- -- -------------------------------------...

3856
来自专栏自由而无用的灵魂的碎碎念

oracle 10g 手动创建scott(tiger) schema

转自:http://cnhtm.itpub.net/post/39970/496967

833
来自专栏数据库新发现

Oracle9i新特性-使用DBMS_METADATA包获得对象DDL语句

从Oracle9i开始Oracle提供了一个新的系统包DBMS_METADATA,可以用于提取对象创建的DDL语句。

862
来自专栏数据分析

Database、Table的所有约束

列出Database或Table的所有约束 很多时候我们想使用像 INSERT、UPDATE、DELETE 这样的DML命令。有时候因为某个表被设置约束,导致我...

2654

扫码关注云+社区