如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

ORA-8103是我们Database Consultant 经常要遇到的一个问题，了解ORA-8103的成因非常重要。

【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题

简单来说ORA-8103 的主要成因有2类:

• 数据块的 block type 类型 是 无效的 或者读出来的块类型与Oracle期望的不一致。  例如 Oracle 认为该数据块的类型为data(type=6)，但实际却不是。
• 数据块中的data_object_id 和 数据字典中的data_object_id不匹配

针对ORA-8103问题 我们优先推荐一些措施：

ORA-08103问题的诊断最好是能生成8103错误的ERROR STACK TRACE， 在TRACE中会记录具体引发8103的对象的OBJ和OBJD，这便于我们定位可能存在corruption的对象。

问题在于往往前台进程遇到ORA-08103错误不会在后台生成TRACE文件，这需要我们手动设置8103 触发ERRORSTACK的EVENTS:

ALTER SYSTEM SET EVENTS ‘8103 TRACE NAME ERRORSTACK LEVEL 3’;

解决思路包括：
1. 通过OBJD和DBA定位到具体的表名和块号
2. 有条件的情况下对该表做一个analyze .. validate structure
3. 有条件的情况下对该表所在tablespace做一个 dbms_space_admin.ASSM_TABLESPACE_VERIFY
4. 有条件的情况下move这张表或者相关的分区，尝试绕过该问题
5. 有条件的情况下降该表或分区移动到MSSM表空间上，绕过该问题

execute dbms_space_admin.tablespace_verify(‘&tablespace_name’)
oradebug setmypid
oradebug tracefile_name

execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS)
oradebug setmypid
oradebug tracefile_name

针对不同的 analyze validate structure 后得到的结果 ， 我们可以得到一些初步的结论：

如果执行 flush buffer cache之后再次analyze validate structure不再报ORA-8103错误则说明：

可能是完全正常的现象，之前的ORA-8103正是也因为对象正在被DROP/TRUNCATE而导致SELECT报ORA-8103。一般来说Call Stack会显示进程正尝试访问该段的segment header。 更多信息可以参考BUG 7441661

也可能该问题仅仅发生在buffer cache层，而没有发生在DISK上。通过flush buffer_cache若能解决，则一般是这种情况，往往是Buffer Cache管理的BUG 。

如果执行 flush buffer cache之后再次analyze validate structure再次报ORA-8103错误则说明：

如果dump对应的数据块发现 该块在逻辑上是完整一致的(也可以用bbed/dbv工具验证)， 则有可能是Lost Write，则不是被其他对象重格式化使用了。

这里判断Lost Write的一个重要手段是 对块做recover/blockrecover，如果recover能修复该块，则说明是因为Lost Write引起了本ORA-8103问题，如果不是则说明99%的可能性是BUG引起的。

常见的一种现象是 使用第三方工具在数据库打开的情况下copy 数据库，这些工具的BUG可能导致copy 老的版本的block到目标新库中。

另一种可能是 extent盘区级别的不一致。 同一个数据块/extent 可能 同时属于 2个数据段segment，这导致其中的一个被后者覆盖。 通过recover的方式是无法修复这种场景的， 因为这种逻辑的讹误发生在表空间级别的extent信息上。 可以检查dba_extents/dba_segments/dba_free_space这些视图来确定问题数据块到底是否同时属于多个对象， 或者 一个数据块 同时出现在dba_extents/dba_segments/dba_free_space 三个视图中， 因为 used extent 不该出现在dba_free_space中，而free extent不该在dba_extents，当然要排除recyclebin中对象的影响。 绝大多数情况下这种extent逻辑不一致的现象， 被称作extent overlap ， 通常是Oracle Space Management空间管理层面的BUG。

在对ORA-8103问题的诊断过程中 定位问题的OBJD异常重要。应当说准确地将ORA-8103错误与BUG定位起来是有难度的，因为这往往需要涉及到redo dump以发现到底是哪些opcode造成了后续的objd 或 block type 不一致。在一些BUG中我们发现，由于可能的变量陈旧，造成objd的结构未合理清除， 之后就发现block上的objd是错的了，可能遇到ORA-8103也可能是ORA-1410， 这引起了后续其他的逻辑讹误，以至于很难通过TRACE/REDO LOG DUMP来定位原始问题所在。 这也是为什么虽然在例如版本10.2.0.4上有几个ORA-8103的bug Note， 但这些BUG最终未被close为real software  bug即真的软件BUG ， 大多都是不了了之，因为在用户现场的TRACE和REDO DUMP都未必能真实定位到问题所在，这也是为什么我们要说逻辑讹误的分析和处理原要比物理讹误来的复杂。

Maclean的经验是 在有大量Oracle DB的环境下 一年出个几次的逻辑/物理坏块是很正常的事情， 对于物理讹误 我们只要切实备份即可99%得解决。 而对于逻辑坏块可做的 事情不多， 打最新的补丁 开 db_block_checking、db_block_checksum几件事情而已。

值得一说的是 如果去读一下ORA-8103的一些Bug Note，可以发现使用 LOB、APPEND INSERT、PARALLEL INSERT、exchange partition 、Split partition、advanced compression、HCC 混合列压缩往往是引起ORA-8103的高危操作 ， 但实际我们又不可能放弃上述操作。

目前已知ORA-8103相关的BUG 列表：

对于ORA-8103问题的更多信息可以参考：

MOS文档Note 268302.1 ORA-8103 Diagnostics and Solution 

诊断ORA-08103错误

【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

对于无备份情况下的ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题，可以通过如下PL/SQL 构造ROWID的方式挽救绝大多数非坏块的数据， 一般分成 2种情况 有索引可以用来获取ROWID， 或者 没有索引、索引不可用，必须通过dbms_rowid.ROWID_CREATE来构造ROWID的方式。

对于有索引的情况，可以直接使用MOS上提供的脚本：

REM Create a new table based on the table that is producing errors with no rows:

create table 
as
select *
from   
where  1=2;

REM Create the table to keep track of ROWIDs pointing to affected rows:

create table bad_rows (row_id rowid
                      ,oracle_error_code number);
set serveroutput on

DECLARE
  TYPE RowIDTab IS TABLE OF ROWID INDEX BY BINARY_INTEGER;
  CURSOR c1 IS select /*+ index(tab1) */ rowid
  from  tab1
  where  is NOT NULL;
  r RowIDTab;
  rows NATURAL := 20000;
  bad_rows number := 0 ;
  errors number;
  error_code number;
  myrowid rowid;
BEGIN
  OPEN c1;
  LOOP
   FETCH c1 BULK COLLECT INTO r LIMIT rows;
   EXIT WHEN r.count=0;
   BEGIN
    FORALL i IN r.FIRST..r.LAST SAVE EXCEPTIONS
     insert into 
     select /*+ ROWID(A) */ 
     from  A where rowid = r(i);
   EXCEPTION
   when OTHERS then
    BEGIN
     errors := SQL%BULK_EXCEPTIONS.COUNT;
     FOR err1 IN 1..errors LOOP
      error_code := SQL%BULK_EXCEPTIONS(err1).ERROR_CODE;
      if error_code in (1410, 8103, 1578) then
       myrowid := r(SQL%BULK_EXCEPTIONS(err1).ERROR_INDEX);
       bad_rows := bad_rows + 1;
       insert into bad_rows values(myrowid, error_code);
      else
       raise;
      end if;
     END LOOP;
    END;
   END;
   commit;
  END LOOP;
  commit;
  CLOSE c1;
  dbms_output.put_line('Total Bad Rows: '||bad_rows);
END;
/

对于没有索引或者索引损坏的情况可以使用如下方法：

创建示例数据

create table maclean_tab1 (t1 int,t2 date default sysdate) tablespace users
partition by range(t1) 
(partition p1 values less than (10000),
partition p2 values less than (20000),
partition p3 values less than (30000),
partition p4 values less than (40000),
partition p5 values less than (50000),
partition p6 values less than (60000),
partition p7 values less than (70000),
partition p8 values less than (80000),
partition p9 values less than (90000),
partition p10 values less than (100000),
partition p11 values less than (110000),
partition p12 values less than (120000),
partition p13 values less than (130000),
partition p14 values less than (140000),
partition p15 values less than (150000),
partition p16 values less than (160000))
;

insert into maclean_tab1(t1) select rownum from dual connect by level<160000;

commit;

SQL> select count(*) from maclean_tab1;

  COUNT(*)
----------
    159999

exec dbms_stats.gather_table_stats(USER,'MACLEAN_TAB1');   

SQL> alter system flush buffer_cache;

System altered.

SQL> /

System altered.

随即采样一些块来做 坏块 约涉及到10个块的数据

set linesize 200 pagesize 1400

select dbms_rowid.rowid_block_number(rowid) blkid,
       dbms_rowid.rowid_relative_fno(rowid) rfile
  from maclean_tab1 sample(0.01)
 where rownum <= 200
 group by dbms_rowid.rowid_block_number(rowid),
          dbms_rowid.rowid_relative_fno(rowid)
 order by 1;

     BLKID      RFILE
---------- ----------
    741833          4
    741850          4
    741994          4
    742030          4
    742085          4
    742141          4
    742159          4
    742172          4
    742173          4
    742179          4

 制造坏块

    [oracle@vrh8 udump]$ rman target  /

RMAN> blockrecover datafile 4 block 741833,741850,741994,742030,742085,742141,742159,742172,742173,742179 clear;

Starting blockrecover at 21-APR-13
using channel ORA_DISK_1
Finished blockrecover at 21-APR-13

SQL> select count(*) from maclean_tab1;
select count(*) from maclean_tab1
                     *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 741833)
ORA-01110: data file 4:
'/s01/oradata/G10R25/datafile/o1_mf_users_8nx5srgb_.dbf'

通过blockrecover datafile block clear 构造了一系列坏块且没有备份 ，我们通过下列脚本挽回大部分可用数据

一个实际操作过程



drop table maclean_tab_backup;

create table maclean_tab_backup 
tablespace users 
nologging compress pctfree 0 pctused 99        --可以注释掉的
 as select * from maclean_tab1 where 1=0;

drop table bad_rows;
create table bad_rows (row_id rowid,oracle_error_code varchar2(50))
tablespace users 
nologging compress pctfree 0 pctused 99        --可以注释掉的;

set serveroutput on;
set timing on;

DECLARE
  TYPE RowIDTab IS TABLE OF ROWID INDEX BY BINARY_INTEGER;
  CURSOR Crowid_info IS
    select Do.DATA_OBJECT_ID dataid,
           DE.FILE_ID        fid,
           DE.BLOCK_ID       blkid,
           DE.BLOCKS         blkcnt
      from dba_objects DO, dba_extents DE
     where DO.OBJECT_NAME = 'MACLEAN_TAB1' 
     --and DE.PARTITION_NAME='&PARTITION_NAME'          --若指定分区则取消注释
       and nvl(DO.SUBOBJECT_NAME,'-1') = nvl(DE.PARTITION_NAME,'-1')
       and DO.OBJECT_NAME = DE.SEGMENT_NAME
       and DO.owner = 'SYS'
     order by 1, 2, 3 asc;
  bad_rows   number := 0;
  errors     varchar2(500);
  error_code varchar2(500);
  myrowid    rowid;
BEGIN
  /* Maclean Liu https://www.askmac.cn * Copy Right 2013-4-20 */ 
  execute immediate 'alter session set commit_write=''batch,nowait'' ';
  for i in Crowid_info loop
    for j in 0 .. i.blkcnt - 1 loop
      for z in 0 .. 2000 loop
        begin
          myrowid := dbms_rowid.ROWID_CREATE(1,
                                             i.dataid,
                                             i.fid,
                                             i.blkid + j,
                                             z);
          insert into maclean_tab_backup
            select /*+ ROWID(A) */
             *
              from maclean_tab1 A
             where rowid = myrowid;
        EXCEPTION
          when OTHERS then
            BEGIN
              errors     := SQLERRM;
              error_code := SQLCODE;
              if (error_code like '%1410%' or error_code like '%8103%' or  error_code like '%1578%') then
                bad_rows := bad_rows + 1;
                insert into bad_rows values (myrowid, error_code);
                commit;
              else
                raise;
              end if;
            END;
            commit;
        end;
      end loop;
    end loop;
  end loop;
  dbms_output.put_line('Total Bad Rows: ' || bad_rows);
  commit;
END;
/

Elapsed: 00:01:10.16

SQL> select count(*) from maclean_tab_backup;

  COUNT(*)
----------
    155921

 ===>损失了少量的10个块的数据

原始脚本如下：

步骤1 创建备份表

create table <new table name>
as
select *
from   <original table name>
where  1=2;

步骤2 创建bad_rows表

create table bad_rows (row_id rowid,oracle_error_code varchar2(50));

步骤3 运行下列脚本

DECLARE
  TYPE RowIDTab IS TABLE OF ROWID INDEX BY BINARY_INTEGER;
  CURSOR Crowid_info IS
    select Do.DATA_OBJECT_ID dataid,
           DE.FILE_ID        fid,
           DE.BLOCK_ID       blkid,
           DE.BLOCKS         blkcnt
      from dba_objects DO, dba_extents DE
     where DO.OBJECT_NAME = '&TABNAME' 
     --and DE.PARTITION_NAME='&PARTITION_NAME'          --若指定分区则取消注释
       and nvl(DO.SUBOBJECT_NAME,'-1') = nvl(DE.PARTITION_NAME,'-1')
       and DO.OBJECT_NAME = DE.SEGMENT_NAME
       and DO.owner = '&OWNER'
     order by 1, 2, 3 asc;
  bad_rows   number := 0;
  errors     varchar2(500);
  error_code varchar2(500);
  myrowid    rowid;
BEGIN
  /* Maclean Liu https://www.askmac.cn * Copy Right 2013-4-20 */ 
  execute immediate 'alter session set commit_write=''batch,nowait'' ';
  for i in Crowid_info loop
    for j in 0 .. i.blkcnt - 1 loop
      for z in 0 .. 2000 loop
        begin
          myrowid := dbms_rowid.ROWID_CREATE(1,
                                             i.dataid,
                                             i.fid,
                                             i.blkid + j,
                                             z);
          insert into &backup_table
            select /*+ ROWID(A) */
             *
              from &source_table A
             where rowid = myrowid;
        EXCEPTION
          when OTHERS then
            BEGIN
              errors     := SQLERRM;
              error_code := SQLCODE;
              if (error_code like '%1410%' or error_code like '%8103%' or  error_code like '%1578%') then
                bad_rows := bad_rows + 1;
                insert into bad_rows values (myrowid, error_code);
                commit;
              else
                raise;
              end if;
            END;
            commit;
        end;
      end loop;
    end loop;
  end loop;
  dbms_output.put_line('Total Bad Rows: ' || bad_rows);
  commit;
END;
/

构造ROWID绕过ORA-1578、ORA-8103、ORA-1410脚本下载

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

kccpb_sanity_check_2内核函数kernel function负责监测控制文件的健康性，该ORA-600[kccpb_sanity_check_2]一般在alter database mount阶段发生； 该ORA-600[kccpb_sanity_check_2]发生的原因一般是 控制文件controlfile 块头的seq#号大于控制文件头中的seq#，所以该监测函数认为存在控制文件逻辑不一致。

该kccpb_sanity_check_2函数是从10gR2才引入了，换句话说9i没有这样的控制文件健康性监测，引入该特性的目的是为了检测出写丢失lost write和陈旧读stale read。

该ORA-600[kccpb_sanity_check_2]一般有2个argument代码:

ARGUMENTS:
Arg [a] seq# in control block header.
Arg [b] seq# in the control file header.
Arg [c] maclean

ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [53672], [53643], [0x000000000], [], [], [], []
Current SQL statement for this session:
ALTER DATABASE   MOUNT
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedst+001c          bl       ksedst1              000000000 ? 700000010007FE0 ?
ksedmp+0290          bl       ksedst               104C1FCD0 ?
ksfdmp+02d8          bl       03F34734             
kgerinv+00dc         bl       _ptrgl               
kgeasnmierr+004c     bl       kgerinv              1105312C0 ? 110211598 ?
                                                   000000000 ? 000015018 ?
                                                   000000000 ?
kccpb_sanity_check+  bl       kgeasnmierr          11019B7D0 ? 1104A0040 ?
013c                                               104DFF150 ? 300000003 ?
                                                   000000000 ? 00000D1A8 ?
                                                   000000000 ? 00000D18B ?
kccbmp_get+00f8      bl       kccpb_sanity_check   FFFFFFFFFFFFFFFF ?
                                                   2700000027 ?
kccsed_rbl+008c      bl       kccbmp_get           1100745A0 ? 104E02124 ?
kccocx+08fc          bl       kccsed_rbl           100000068 ?
kccocf+0140          bl       kccocx               FFFFFFFFFFEB7C8 ? 0CBC08BD8 ?
                                                   16D694B2F ? 110231D90 ?
kcfcmb+0ab4          bl       kccocf               000000000 ? 000000000 ?
                                                   000000002 ? 10041C1F4 ?
kcfmdb+0054          bl       kcfcmb               0FFFED160 ? 7000000B9FF038E ?
                                                   000000003 ? 000000000 ?
                                                   000000003 ? 000000000 ?
                                                   000000000 ? 000000000 ?
adbdrv+06c0          bl       kcfmdb               110262390 ? 7000000BCFFA050 ?
                                                   7000000BCFFA470 ? 104F38E08 ?
opiexe+2d34          bl       adbdrv               
opiosq0+1ac8         bl       opiexe               000000001 ? 000000000 ?
                                                   FFFFFFFFFFF9148 ?
kpooprx+016c         bl       opiosq0              300000020 ? 110231D90 ?
                                                   7000000BD1038F8 ?
                                                   A400011019B7D0 ? 000000000 ?
kpoal8+03cc          bl       kpooprx              FFFFFFFFFFFB954 ?
                                                   FFFFFFFFFFFB700 ?
                                                   1600000016 ? 100000001 ?
                                                   000000000 ? A40000000000A4 ?
                                                   000000000 ? 1103ABA18 ?
opiodr+0b2c          bl       _ptrgl               
ttcpip+1020          bl       _ptrgl               
opitsk+117c          bl       01FC6908             
opiino+09d0          bl       opitsk               1EFFFFD920 ? 000000000 ?
opiodr+0b2c          bl       _ptrgl               
opidrv+04a4          bl       opiodr               3C102A89D8 ? 404C72CF0 ?
                                                   FFFFFFFFFFFF8E0 ? 0102A89D0 ?
sou2o+0090           bl       opidrv               3C02A2895C ? 400000020 ?
                                                   FFFFFFFFFFFF8E0 ?
opimai_real+01bc     bl       01FC3174             
main+0098            bl       opimai_real          000000000 ? 000000000 ?
__start+0090         bl       main                 000000000 ? 000000000 ?

    last wait for 'control file sequential read' wait_time=0.000511 sec, seconds since wait started=0
                file#=0, block#=27, blocks=1
                blocking sess=0x0 seq=23
    Dumping Session Wait History
     for 'control file sequential read' count=1 wait_time=0.000511 sec
                file#=0, block#=27, blocks=1
     for 'control file sequential read' count=1 wait_time=0.000957 sec
                file#=0, block#=1, blocks=1
     for 'CSS operation: action' count=1 wait_time=0.036477 sec
                function_id=41, =0, =0
     for 'CSS operation: action' count=1 wait_time=0.000200 sec
                function_id=41, =0, =0
     for 'CSS initialization' count=1 wait_time=0.060291 sec
                =0, =0, =0
     for 'control file sequential read' count=1 wait_time=0.000547 sec
                file#=0, block#=1, blocks=1
     for 'control file sequential read' count=1 wait_time=0.003763 sec
                file#=0, block#=3, blocks=20
     for 'control file heartbeat' count=1 wait_time=3.906271 sec
                =0, =0, =0
     for 'control file sequential read' count=1 wait_time=0.020452 sec
                file#=0, block#=3, blocks=20
     for 'control file sequential read' count=1 wait_time=0.000310 sec
                file#=0, block#=1, blocks=1

上例是一个ORA-600[kccpb_sanity_check_2]的实战案例，虽然出现了该错误，但是由于多路复用了controlfile控制文件，通过修改参数control_files ，发现其中第二个控制文件mount时未报错，可以确信仅有1个控制文件有问题，所以只需要dd 复制一下即可。

针对这个 实例mount阶段的ORA-600[kccpb_sanity_check_2]错误，一般有几种解决方法：

1、如果多路复用了控制文件，则未必所有控制文件都坏了，修改control_files参数一个个试过来，注意当 好的控制文件和坏的控制文件都在参数control_files里时是无法mount成功的

2、从备份中restore健康的控制文件出来

3、若没有备份，则需要手动重建控制文件了

Oracle rman中set newname可能很慢， 对于该问题有几种可能：

1、rman 软件bug ，具体请去MOS查询

2、打开了BACKUP OPTIMIZATION on，show all命令确认下，若是则 CONFIGURE BACKUP OPTIMIZATION OFF; 暂时关掉

3、 set newname 之前不要set until time之类的设置，最好也别allocate channel xx type sbt，可以在set newname之后再设不迟

4 、使用catalog 恢复目录替代controlfile模式往往可以绕过该问题

具体的set newname操作涉及到  sys . dbms_backup_restore . normalizeFileName和 dbms_rcvman . translateDataFile  2个存储过程：

FUNCTION normalizeFileName (fname IN varchar2) RETURN varchar2;

— Normalizes the file name according to the rules of the target
— database and returns the normalized filename.
—
— Input parameters:
— fname
— File name to be normalized.
— Exceptions:
— NAME-TOO-LONG (ora-19704)
— The specified file name is longer than the port-specific
— maximum file name length.

— translateDataFile translates the datafile name/number into
— a datafile number and creation SCN and filename. getDataFile must
— be called to obtain the translation info, just as for the other translate
— functions.
— Unlike the other translation functions, translateDatafile by name is always
— performed relative to current time. If an until setting is in effect,
— and if the filename is ambiguous, then an exception is raised. Ambiguous
— means that the filename refers to different datafile at the until time than
— it does at the current time. This happens only when a filename has been
— reused. When fno and ckpscn are passed, the filename and other info as of
— that scn is returned.

— Input parameters:
— fname
— name of the datafile to be translated.
— The name must be a normalized filename.
— fno
— The datafile number. If the datafile number was not in use at the
— until time, then an exception is raised.
— Exceptions:
— DATAFILE_DOES_NOT_EXIST (ORA-20201)
— the datafile to be translated does not exists
— Check that the recovery catalog is current.

PROCEDURE translateDataFile(
fname IN varchar2);

PROCEDURE translateDatafile(
fno IN number);

PROCEDURE translateDatafile(
fno IN number
,ckpscn IN number);

有这样一种需求，虽然controlfile中的archivelog和其他一些备份信息会被覆盖重用，收到参数control_file_record_keep_time的影响，但是我们没法手动触发这种重用，这导致有时候controlfile中的archivelog 记录过多，可能导致一些备份、恢复过程中的”control file sequential read”等待事件。

已知的一些解决方案，包括：

1. 重建控制文件， 例如 backup controlfile to trace后重建该控制文件，但要求有数据文件均存在

2. 设置control_file_record_keep_time=0 然后等待记录被重用， 太过被动了….

这里再介绍一种手动清除v$ARCHIVED_LOG中不管是DELETED还是available 记录的方法，注意不要在你的产品数据库上这样做：

SQL> select count(*) from v$archived_log;

COUNT(*)
———-
553

SQL> /

COUNT(*)
———-
553
SQL> execute sys.dbms_backup_restore.resetCfileSection( 11);

PL/SQL procedure successfully completed.

SQL> select count(*) from v$archived_log;

COUNT(*)
———-
0

PROCEDURE resetCfileSection(record_type IN binary_integer );

— This procedure attempts to reset the circular controlfile section.
—
— Input parameters:
— record_type
— The circular record type whose controlfile section is to be reset.

execute sys.dbms_backup_restore.resetCfileSection( 11);  ==> 清理v$ARCHIVED_LOG对应的记录

execute sys.dbms_backup_restore.resetCfileSection(28);  ==>清理v$rman_status对应的记录

以上是2个例子，具体的section_id可以这样获得：

1* select rownum-1, type from v$controlfile_record_section
SQL> /

ROWNUM-1 TYPE
———- —————————-
0 DATABASE
1 CKPT PROGRESS
2 REDO THREAD
3 REDO LOG
4 DATAFILE
5 FILENAME
6 TABLESPACE
7 TEMPORARY FILENAME
8 RMAN CONFIGURATION
9 LOG HISTORY
10 OFFLINE RANGE
11 ARCHIVED LOG
12 BACKUP SET
13 BACKUP PIECE
14 BACKUP DATAFILE
15 BACKUP REDOLOG
16 DATAFILE COPY
17 BACKUP CORRUPTION
18 COPY CORRUPTION
19 DELETED OBJECT
20 PROXY COPY
21 BACKUP SPFILE
22 DATABASE INCARNATION
23 FLASHBACK LOG
24 RECOVERY DESTINATION
25 INSTANCE SPACE RESERVATION
26 REMOVABLE RECOVERY FILES
27 RMAN STATUS
28 THREAD INSTANCE NAME MAPPING
29 MTTR
30 DATAFILE HISTORY
31 STANDBY DATABASE MATRIX
32 GUARANTEED RESTORE POINT
33 RESTORE POINT

LOG History占用的控制文件记录数可以查询v$controlfile_record_section获得：

SQL> select * from v$controlfile_record_section where type=’LOG HISTORY’ ;

TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID
—————————- ———– ————- ———— ———– ———- ———-
LOG HISTORY 56 584 563 300 278 570

control file sequential read

Reading from the controlfile. This happens in many cases, e.g. while:

– making a backup of the controlfiles.

– the shared info (between instances) from the controlfile.

– reading other blocks from the controlfiles.

– reading the header block.

Wait time

The wait time is the elapse time of the read.

Parameters

file#

This identifies the controlfile that Oracle7 is reading from and with the following SQL statement one can determine the name of the controlfile:

select *

from x$kcccf

where indx = file#

block#

Blocknumber in the controlfile from where we are starting to read. The blocksize is the as the physical blocksize of the port (normally 512 bytes, some UNIX ports have 1 Kilobytes or 2 Kilobytes).

blocks

The number of blocks that we are trying to read.

Advise

If the wait time is too long (more then average I/O speed), check if the controlfiles are not a disk that is too busy. This could really impact Parallel Server performance as some of the synchronization between instances is done through the controlfiles.

ORACLEデータベース によくあるエラ の解決策

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

前週の金曜日で、RAIDがシャットダウンしたあと、Oracle9 iデータベースが起動できなくなったとお客様からの知らせがあった。この話を続く前に、言っておきたいことがある。このデータベースは我々が担当していない。私たちはこの知らせを受けた前に、このデータベース自身が存在していることですら知らなかった。一部のユーザーがすべてを私たちに担当させたが、一部のユーザーが五分五分であった。けど、私たちに対して、お客様がどのやり方を取っても構わない。これはユーザーそれぞれ異なった選択である。いや、ちょっと話がわき道にそれた。

原因を探して見れば、このデータベースはNOARCHIVELOGモードであったうえに、コールドバックアップもない。一回だけのデータベースをエクスポートしたこともない。しかも、こんなことはいつも金曜日に起こる！

まずは、壊れたオンラインredoログで最初シャットダウンをリカバリしたが、失敗した。そして、お客様が人工的にリカバリしてみたが、状況があまり変わっていない。その上に、シャットダウンした直後、すぐにコールドバックアップを作成していないから。これらの試しがよりひどい損害をもたらしたか私たちも見当がつかない。

ＳＣＮをゆっくり増やしてリカバリしてみた。異なったredoログメンバーも試した。けど、なかなかリカバリできず、ORA-600 [3020]が現れた。

_allow_resetlogs_corruption OPEN RESETLOGS でログファイルを成功にリセットしたが、データベースがまだ起動できず、「一部のオブジェクトが見つけ出せない」とエラ情報を返した。

一言で言えば、システムテーブルスペースが足りないから、データベースを起動出来ない。

このあとでいくつかのアイデアが生み出したが、やはりOracle PRM-DULを使うことが最適だった。PRM-DULはData ExtractionでDatabaseをUnloadingすることと意味している。その機能は起動できなくなったデータベースからデータを抽出する。もちろんこれはデータベース損害次第である。

より詳しい情報は「PRM-DULガイドブック」に参考してください。

もし、あいにくお客様がこのような場合に遭遇したら、www.parnassusdata.com に登録してください。そこで、PRM-DUL体験版をもらえる。あるいは私たちにデータ抽出サビースの申請を出してください。私はもう既にPRM-DULについて詳しいから、一つ目の方法を選んだ。

それを使ったら、数時間だけでデータを収集できた。胡さんより、実演バーションをもらった。

実演バーションで、すべてのテーブルに前の１０行のデータを抽出できた。すべても成功に実行できたと確認できたら、お客様が七日のライセンスをもらった。私は数分だけで抽出コマンドを再び実行したが、なんと、PRM-DULが奇跡的にすべてのテーブルのダンプファイルもリカバリできた。後で必要なのはほかのパソコンにコピするだけ

PRM-DULはすべてのシーケンスもPL / SQLオブジェクトも作成した。いくつのSYSオブジェクトをダンプするだけで、インディクスと制約が抽出できるが、ユーザーが同じデータモデルを持っているから、そこから定義を抽出する方が簡単になる。

お客様はこんな短い時間にこれほど致命的な損害をリカバリできたことに高く評価した。これはすべてもPRM-DULとその開發者、胡さんのおかげだ。胡さん、金曜日に仕事を早めに完成できて、ありがとうございました。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

ORA-08102
oerr ora 8102
08102, 00000, "index key not found, obj# %s, file %s, block %s (%s)"
// *Cause: Internal error: possible inconsistency in index
// *Action: Send trace file to your customer support representative, along
// with information on reproducing the error


ORA-01499
oerr ora 1499
01499, 00000, "table/index cross reference failure - see trace file"
// *Cause:
// *Action:

问题摘要行:

=====================

ORA-8102, ORA-1499 EVEN AFTER DROPPING AND RECREATING INDEX

Problem Description:

====================

ORA-8102 occurs when accessing a table.

08102, 00000, “index key not found, obj# %s, dba %s (%s)”

// *Cause:  Internal error: possible inconsistency in index

// *Action:  Send trace file to your customer support representative, along

//with information on reproducing the error

通过使用OBJ#从错误消息中找出有问题的对象：

select OWNER,OBJECT_NAME, OBJECT_TYPE from DBA_OBJECTS

where OBJECT_ID=<object#_from_error>;

如果返回的对象是一个索引，使用上述查询返回的值，通过以下查询找出与其相关联的表：

SELECT TABLE_NAME FROM DBA_INDEXES

WHERE INDEX_NAME=<object_name> AND OWNER=<owner>;

接着，分析表来确定索引中不一致的类型：

ANALYZE TABLE <owner>.<table_name> VALIDATE STRUCTURE CASCADE;

使用CASCADE子句是很重要的，因为分别验证的表和索引结构不会显示不一致性。

analyze 命令返回ORA-1499

01499, 00000, “table/index cross reference failure – see trace file”

检查在user_dump_dest 中生成的跟踪文件，显示cross reference 失败的类型。在这个情况中，类型是”row not found in index”。

Oracle Support 能帮助你确定哪个索引有丢失行条目。

普通的drop并创建索引的解决方法不适用于这种情况。使用VALIDATE STRUCTURE CASCADE 分析表仍返回ORA-1499，即使在重建了索引之后。

=====================

通过export/import 重建表，然后重建解决问题的索引。

说明：

============

There was a row in the table without a corresponding index entry. The normal

way to resolve this is to drop and recreate the index.  IMPORTANT: Rebuilding

the index will NOT resolve this error as the existing index, which is missing

the row, will be used to rebuild the index.  Dropping and recreating the index

forces Oracle to recreate the index from the table data.  This was most likely

caused by some type of hardware problem as the problem failed to be reproduced

in house. 在表中有一行没有对应的索引条目。解决的正常方法这是drop并重建索引。重要提示：重建该索引将不会解决这个错误，因为现有的丢失行的索引将用于重建索引。drop并重建索引强制Oracle从表数据重建索引。这最有可能是由某种类型的硬件问题引起的，因为问题未能被再现。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

ora-01499

 oerr ora 1499
01499, 00000, "table/index cross reference failure - see trace file"
// *Cause:
// *Action:

适用于：

Oracle Database – Enterprise Edition – 版本 8.1.7.0 到12.1.0.1 [Release 8.1.7 to 12.1]
本文信息适用于任何平台。
Oracle Server Enterprise Edition – 版本: 8.1.7.0 到 11.2.0.2

症状

使用”validate structure cascade”分析表失败，生成ORA-1499 且跟踪文件包含信息 “Table/Index row count mismatch”。示例：

SQL> analyze table test validate structure cascade;
analyze table test validate structure cascade
*
ERROR at line 1:
ORA-01499: table/index cross reference failure – see trace file

The associated trace file contains:

Table/Index row count mismatch
table 6559 : index 10000, 0
Index root = tsn: 6 rdba: 0x01400091

It means: A table scan returned 6559 rows and an index scan returned 10000 rows.

“Index root” is the segment header information for the index:

rdba: 0x01400091 is the Index segment header relative data block address. It is decimal 20971665 which is Rfile#=5 Block#=145 :

SQL> select dbms_utility.data_block_address_file(20971665)  “Rfile#”
2          ,dbms_utility.data_block_address_block(20971665) “Block#”
3 from dual;

Rfile#     Block#
———- ———-
5          145
Running the next query can identify the associated index:

QUERY 1:

SQL> select owner, segment_name, segment_type
2    from  dba_segments
3    where header_file = 5
4      and header_block = 145;

OWNER    SEGMENT_NAME    SEGMENT_TYPE
——– ————— ——————
SCOTT    I_TEST          INDEX

该逻辑不一致问题也能显示为10g+中ORA-600 [kdsgrp1] 或更低版本中的ORA-600 [12700]。

原因

在表和其索引间有逻辑不一致性。这种类型的逻辑不一致性通常是由于表中的High Water Mark (HWM) 的问题，其中全表扫描返回的行可能比索引扫描的少。

不一致性可能由Oracle defect 导致或由于LOST IO引起的OS/硬件问题。

解决方案

The rows retrieved through the index that are not retrieved by a full table scan can be identified by running this query: 通过运行此查询，可以识别由不由全表扫描检索的索引检索的行：

select /*+ INDEX_FFS(<tablename> <indexname identified in 2.1>) */ rowid
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from <tablename>
where <indexed column> is not null
minus
select /*+ FULL(<tablename>)*/ rowid
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from <tablename>;

示例：

select /*+ INDEX_FFS(TEST I_TEST) */ rowid
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from test
where c2 is not null
minus
select /*+ FULL(TEST)*/ rowid
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from test;

全表扫描丢失的值可以使用下一个plsql（SCRIPT 1）的索引存储在另一个表中：

drop table test_copy;

create table test_copy as select * from test where 1=2;

declare
cursor missing_rows is
select /*+ INDEX_FFS(TEST I_TEST) */ rowid rid
from test
where c2 is not null
minus
select /*+ FULL(TEST)*/ rowid rid
from test;
begin
for i in missing_rows loop
insert into TEST_COPY
select /*+ ROWID(TEST) */ * from TEST where rowid = i.rid;
end loop;
end;
/
解决方案

– 当索引的行比表少，重建索引可能解决该问题。

– 当索引的行比表多，重建索引或通过运行dummy 插入到表来提高HWM可能最终修复该逻辑损坏。在这种情况下，逻辑损坏被修复但这些行可能”lost”，可以在应用这些解决方法之前使用以上”SCRIPT 1″来恢复它们。

– 为了避免该不一致性，查看以下已知问题的列表。

如果需要Oracle Support的额外帮助，请提供：

1. analyze 命令生成的跟踪文件。
2. 以上”QUERY 1″ 的结果。
3. 通过dump基表的段头生成的跟踪文件：

select header_file, header_block, tablespace_name
from   dba_segments
where  owner = upper(‘&table_owner’) and segment_name = upper(‘&table_name’);

alter system dump datafile &header_file block &header_block;

This trace file will be used to identify the HWM.

@ Example from a block dump not using ASSM (Automatic Segment Space Management):
@
@ Extent Control Header
@ —————————————————————–
@ Extent Header:: spare1: 0 spare2: 0 #extents: 4 #blocks: 31
@ last map 0x00000000 #maps: 0 offset: 4128
@ Highwater:: 0x014000d6 ext#: 3 blk#: 5 ext size: 8
@
@ So, HWM is located at RDBA 0x014000d6 in extent_id=5 and block#=5 in that extent.

4. 为索引检索的额外行识别extent id’s 的查询结果：

select rid, a.relative_fno, a.block, e.owner, e.segment_name, e.segment_type, e.extent_id, e.blocks
from (select /*+ INDEX_FFS(<table name> <index name>) */ rowid rid
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from <table owner.table name>
where <indexed column> is not null
minus
select /*+ FULL(<table name>)*/ rowid rid
, dbms_rowid.ROWID_RELATIVE_FNO(rowid) relative_fno
, dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block
from <table owner.table name>
) a
, dba_extents e
where a.relative_fno=e.relative_fno
and e.tablespace_name = upper(‘&tablespace_name’)
and v.ts#=&tablespace_number
and (a.block between e.block_id and e.block_id+blocks-1);

注：

– 用适当值替换owner, table name, index name 和indexed column。
– tablespace_name 是以上步骤3中提供的。
– 该查询提供了由索引检索行位于的extent 。
 

已知问题: 

要避免该问题，参考 Note 1499.1 获取已知的Oracle 缺陷。对于由OS/硬件引起的LOST IO，联系第三方供应商。

参考

NOTE:1554054.1 - Quick method to identify table/index mismatch when analyze validate structure cascade takes significant time

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com

适用于：

Oracle Database – Enterprise Edition – 版本 11.1.0.7 到11.2.0.3 [Release 11.1 to 11.2]
本文信息适用于任何平台。

症状

 在一个2节点RAC集群中创建asmlib 磁盘后

– 在第一个节点上磁盘组被成功创建，

– 在第二个节点上尝试mount磁盘组，得到：：ORA-15063: ASM discovered an insufficient number of disks for diskgroup

– 查询v$asm_disk – 显示 header_status: unknown

同样在节点2看到以下错误

SQL> ALTER DISKGROUP ALL MOUNT
NOTE: cache registered group DATA0 number=1 incarn=0x6805c243
NOTE: cache began mount (not first) of group DATA0 number=1 incarn=0x6805c243
NOTE: cache registered group FRA number=2 incarn=0x6805c244
NOTE: cache began mount (not first) of group FRA number=2 incarn=0x6805c244
NOTE:Loaded lib: /opt/oracle/extapi/64/asm/orcl/1/libasm.so
ERROR: kfkOsmIdent:asm_open(): asm_erc:1 msg:Operation not permitted pid:15563
ORA-15186: ASMLIB error function = [kfkOsmIdent:asm_open], Â error = [1], Â mesg = [Operation not permitted]
ERROR: kfkOsmIdent:asm_open(): asm_erc:1 msg:Operation not permitted pid:15563
ORA-15186: ASMLIB error function = [kfkOsmIdent:asm_open], Â error = [1], Â mesg = [Operation not permitted]
ERROR: kfkOsmIdent:asm_open(): asm_erc:1 msg:Operation not permitted pid:15563
ORA-15186: ASMLIB error function = [kfkOsmIdent:asm_open], Â error = [1], Â mesg = [Operation not permitted]
ERROR: kfkOsmIdent:asm_open(): asm_erc:1 msg:Operation not permitted pid:15563
ORA-15186: ASMLIB error function = [kfkOsmIdent:asm_open], Â error = [1], Â mesg = [Operation not permitted]
ERROR: kfkOsmIdent:asm_open(): asm_erc:1 msg:Operation not permitted pid:15563
ORA-15186: ASMLIB error function = [kfkOsmIdent:asm_open], Â error = [1], Â mesg = [Operation not permitted]

原因

在节点1

$ ls -l /dev/oracleasm/disks
total 0
brw-rw—- 1 oracle dba 253, 34 Sep 18 07:34 ASMDB1
brw-rw—- 1 oracle dba 253, 29 Sep 18 07:36 ASMF1
brw-rw—- 1 oracle dba 253, 28 Sep 18 07:37 ASMRD1
brw-rw—- 1 oracle dba 253, 25 Sep 18 07:38 ASMRD2
brw-rw—- 1 oracle dba 253, 33 Sep 18 07:39 ASMT1

在节点2

—->oracle@xxxxxx:/oracle/diag/asm/+asm/+ASM2/trace
$ ls -l /dev/oracleasm/disks
total 0
brw-rw—- 1 oracle dba 65, 161 Sep 18 07:40 ASMDB1
brw-rw—- 1 oracle dba 65, 177 Sep 18 07:40 ASMF1
brw-rw—- 1 oracle dba 65, 193 Sep 18 07:40 ASMRD1
brw-rw—- 1 oracle dba 65, 209 Sep 18 07:40 ASMRD2
brw-rw—- 1 oracle dba 65, 225 Sep 18 07:40 ASMT1

节点2 不在使用多路径设备。

解决方案

确认以下：

1.   两个节点都有相同 /etc/sysconfig/oracleasm  文件且都有以下行

# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER=”dm”

# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE=”sd”

2.  两个节点显示相同symlink ，当发出以下：

# ls -l  /etc/sysconfig/oracleasm
lrwxrwxrwx 1 root root 24 Sep 18 22:10 /etc/sysconfig/oracleasm -> oracleasm-_dev_oracleas

一旦完成，请重新扫描#oracleasm scandisks 并再次验证两个节点上的# ls -l /dev/oracleasm/disks 。

它们应当使用dm 设备而不是单路径。 

参考

NOTE:398622.1 – ORA-15186: ASMLIB error function = [asm_open], error = [1], mesg = [Operation not permitted]