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....

时间: 2024-10-22 00:02:02

oracle坏块修复实例的相关文章

Oracle坏块问题处理 Oracle坏块修复 Oracle坏块怎么办

Oracle数据库出现坏块现象是指:在Oracle数据库的一个或多个数据块(一个数据块的容量在创建数据库时由db_block_size参数指定,缺省为8K)内出现内容混乱的现象.由于正常的数据块都有固定的合法内容格式,坏块的出现,导致数据库进程无法正常解析数据块的内容,进而使数据库进程报错乃至挂起,并级联导致整个数据库实例出现异常. 一.坏块分类 物理坏块:也可以称为介质坏块,指的是块格式本身是坏的,块内的数据没有任何意义. 逻辑坏块:指的是块内的数据在逻辑是存在问题.比如说索引块的索引值没有按

一道面试题:遇到大规模Oracle坏块该怎么处理?

最近一两个月,一直有场景化运维.场景化大数据分析的声音围绕在耳畔,以Gdevops全球敏捷运维峰会杭州站上新炬网络执行副总裁程永新的"一切没有场景驱动的运维平台建设都是假大空!"最为振聋发聩.我们一直在谈技术,谈原理,谈内核,总以为"懂了"这些的人,就势必能广阔天地大有所为.   技术固然重要,但偏离了业务/应用场景的技术,无法呈现业务价值的技术就非常不重要.   技术也应该是场景驱动的,对于运维技术人员来说,离开场景学习的所谓高深技术,只是浪费时间.所以新同事进入

[20160816]11G dataguard坏块修复.txt

[20160816]11G dataguard坏块修复.txt --11GR2 不仅仅支持在备库在只读的情况下,日志应用(ACTIVE Data Guard),还提供主备库的坏块修复.自己以前也做过相关测试, --我记得上次测试的仅仅是主库数据块损坏,没有测试备库的数据块损坏.补充一些测试: 1.环境: SYS@test> @ ver1 PORT_STRING                    VERSION        BANNER ---------------------------

oracle 坏道 dbf-关于ORACLE坏道的修复

问题描述 关于ORACLE坏道的修复 1.Oracle未开启备份 2.sys.tab表搜索的时候出现file 1 block 14505错误 问题: 1.如何修复 2.如果不能修复,我新建一个库,如何把原先库的dbf文件导入到新库中? 谢谢.

oracle中file 1 block 128 corrupted/坏块恢复—system rollback坏块修复

有个数据库file 1 block 128 坏块导致数据库无法启动报错如下 该数据库版本是11.2.0.1,根据我们的经验该block是system rollback 的segment header,以下为我在正常哭查询结果SQL> select file_id,block_id,blocks from dba_extents where segment_name='SYSTEM'    FILE_ID   BLOCK_ID     BLOCKS---------- ---------- ---

ORACLE坏块(ORA-01578)处理方法

oracle ORACLE的坏块即ORA-01578错,同时还可能伴随ORA-01110错,这种错误对于初学者或是那些没有实践经验的dba来说无疑是很棘手的.我当初就深受其害,写下这篇文章则是希望对大家有所帮助. 一.出问题时的情景 1.  我的一个计费的入库的进程停掉,报的便是ORA-01578错,对应用相关的表tg_bill03做SQL>select from tg_cdr03 where rownum<10;这样是可以的,但做SQL>select count(*) from tg_

使用 DBMS_REPAIR 修复坏块

       对于Oracle数据块物理损坏的情形,在我们有备份的情况下可以直接使用备份来恢复.对于通过备份恢复,Oracel为我们提供了很多种方式,冷备,基于用户管理方式,RMAN方式等等.对于这几种方式我们需要实现基于数据库以及文件级别的恢复.RMAN同时也提供了基于块介质方式的恢复.也就是说我们根本不需要还原数据文件,而是直接从备份文件基于块来提取以实现联机恢复.可参考基于RMAN实现坏块介质恢复(blockrecover) .这是比较理想的情形.如果没有任何备份怎么办?我们可以使用Ora

oracle中RMAN备份和检查逻辑坏块

1. RMAN备份时是默认检查物理坏块. 2. 如果要检查逻辑坏块,可以用如下语句: $ rman target / RMAN> backup check logical validate database; 注上述语句,只是检查,不会备份的. 3. 如果要在备份的同时,进行逻辑坏块检查,可以用: $ rman target / RMAN> backup check logical database; 4.如果发现坏逻辑如何处理,下面补充一篇教程. 利用RMAN检测数据库坏块的脚本 虽然我们也

Oracle中通过RMAN修复坏块

通过dbv和rman blockrecover对Oracle数据库坏块进行修复. (1)rman备份时alert.log报如下错误: Fri Jul  2 12:41:36 2010 Hex dump of (file 12, block 2718618) in trace file /u01/app/oracle/admin/bi/udump/bi_ora_31213.trc Corrupt block relative dba: 0x03297b9a (file 12, block 2718