了解rman catalog的兼容性

几天前被问到关于rman catalog兼容性的问题,catalog所在数据库版本与目标数据库版本不同会有影响吗?在我概念当中catalog所在数据库的版本并不会影响rman catalog的使用,但catalog schema的版本却有着明确要求,至于具体的兼容关系就不清楚了。

查了下MOS找到文档<RMAN Compatibility Matrix>,这个文档解释地比较清楚,存在3个基本的原则:

  1. RMAN可执行文件的版本需要和target database目标数据库的版本一致(弱一致要求),具体的合法组合如下面列出的表格
  2. RMAN catalog schema版本必须大于等于RMAN可执行文件(强一致要求)
  3. RMAN catalog对target database目标数据库向后兼容,即支持早期版本的目标数据库

具体的可用版本组合:

Target/Auxiliary
Database
RMAN Executable Catalog Database Catalog Schema
8.1.7.4 8.1.7.4 >=8.1.7 8.1.7.4
8.1.7.4 8.1.7.4 >=8.1.7 >=9.0.1.4
9.0.1 9.0.1 >=8.1.7 >= RMAN executable
9.2.0 >=9.0.1.3 and <= Target database >=8.1.7 >= RMAN executable
10.1.0 >=9.0.1.3 and <= Target database >=9.0.1 >= RMAN executable
10.2.0 >=9.0.1.3 and <= target database >=9.0.1 >= RMAN executable
11.1.0 >=9.0.1.3 and <= target database >=10.2.0.3 (note 1) >= RMAN executable
11.2.0 >=9.0.1.3 and <= target database >=9.0.1 >= RMAN executable

从上表中可以看到除去target database为11.1.0时因为Bug 6756872 – RMAN REGISTER OF 11G TARGET INTO 10G CATALOG FAILS WITH ORA-04028,要求catalog所在数据库大于10.2.0.3外,对catalog所在数据库的版本没有一个强要求,一般10gR2都可以满足兼容性。而对于catalog schema的版本则有着明确的高版本要求,究其原因是RMAN使用的DBMS_RCVMAN内置包要求与之版本一致的恢复目录表结构recovery catalog tables,如果达不到这种要求,那么可能出现rman 20299错误:

[maclean@rh2 ~]$ oerr rman 20299
20299, 1, "DBMS_RCVMAN package not compatible with the recovery catalog"
// *Cause:  The version of the recovery catalog tables does not work with this
//          version of the DBMS_RCVMAN package.
// *Action: Check that the recovery catalog packages and schema are installed
//          correctly.  The UPGRADE CATALOG command can be used to upgrade
//          the recovery catalog tables and packages to the most current
//          version.
//

Oracle内部错误:ORA-00600[2608]一例

一套10.2.0.4的单节点数据库在恢复数据文件时出现了ORA-00600: internal error code, arguments: [2608], [1], [0], [690423], [0], [690425], [], []内部错误,其日志如下:

 

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

 

 

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /s01/db_1
System name:    Linux
Node name:      rh2.oracle.com
Release:        2.6.18-194.el5
Version:        #1 SMP Mon Mar 29 22:10:29 EDT 2010
Machine:        x86_64
Instance name: G10R2
Redo thread mounted by this instance: 1
Oracle process number: 15
Unix process pid: 21360, image: oracle@rh2.oracle.com (TNS V1-V3)

*** 2011-04-27 21:20:40.979
*** ACTION NAME:() 2011-04-27 21:20:40.979
*** MODULE NAME:(sqlplus@rh2.oracle.com (TNS V1-V3)) 2011-04-27 21:20:40.979
*** SERVICE NAME:(SYS$USERS) 2011-04-27 21:20:40.979
*** SESSION ID:(159.3) 2011-04-27 21:20:40.979
kwqmnich: current time:: 13: 20: 40
kwqmnich: instance no 0 check_only flag 1
kwqmnich: initialized job cache structure
Recovery target incarnation = 2, activation ID = 0
Influx buffer limit = 52443 (50% x 104887)
Successfully allocated 2 recovery slaves
Using 550 overflow buffers per recovery slave
Start recovery at thread 1 ckpt scn 690423 logseq 1 block 3183
*** 2011-04-27 21:20:46.165
Media Recovery add redo thread 1
*** 2011-04-27 21:20:46.172
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [2608], [1], [0], [690423], [0], [690425], [], []
Current SQL statement for this session:
ALTER DATABASE RECOVER  datafile 9
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7FFF6F1795E0 ? 7FFF6F179640 ?
                                                   7FFF6F179580 ? 000000000 ?
ksfdmp()+21          call     ksedmp()             000000003 ? 000000001 ?
                                                   7FFF6F1795E0 ? 7FFF6F179640 ?
                                                   7FFF6F179580 ? 000000000 ?
kgeriv()+176         call     ksfdmp()             000000003 ? 000000001 ?
                                                   7FFF6F1795E0 ? 7FFF6F179640 ?
                                                   7FFF6F179580 ? 000000000 ?
kgesiv()+119         call     kgeriv()             0068966E0 ? 00A81E650 ?
                                                   000000000 ? 7FFF6F178F08 ?
                                                   7FFF6F179580 ? 000000000 ?
ksesic5()+215        call     kgesiv()             0068966E0 ? 00A81E650 ?
                                                   000000A30 ? 000000005 ?
                                                   7FFF6F17A360 ? 000000000 ?
kcrfro()+6796        call     ksesic5()            000000A30 ? 000000000 ?
                                                   000000001 ? 000000000 ?
                                                   000000000 ? 000000000 ?
kcramr()+7872        call     kcrfro()             2B9DB2D29400 ? 000000000 ?
                                                   000000001 ? 000000000 ?
                                                   000000000 ? 000000000 ?
krddmr()+1290        call     kcramr()             2B9DB2CF70E0 ? 00A7F8280 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
adbdrv()+10248       call     krddmr()             00A7F8280 ? 000000000 ?
                                                   7FFF6F182FC4 ? 000000000 ?
                                                   2B9DB2CF70E0 ?
                                                   A7F828000000001 ?
opiexe()+13505       call     adbdrv()             00A7F8280 ? 000000000 ?
                                                   0A2806BD8 ? 000000000 ?
                                                   2B9DB2CF70E0 ?
                                                   A7F828000000001 ?
opiosq0()+3316       call     opiexe()             000000004 ? 000000000 ?
                                                   7FFF6F184238 ? 000000012 ?
                                                   2B9DB2CF70E0 ?
                                                   A7F828000000001 ?
kpooprx()+315        call     opiosq0()            000000003 ? 00000000E ?
                                                   7FFF6F1843A8 ? 0000000A4 ?
                                                   2B9DB2CF70E0 ?
                                                   A7F828000000001 ?
kpoal8()+799         call     kpooprx()            7FFF6F187554 ? 7FFF6F185530 ?
                                                   000000024 ? 000000001 ?
                                                   000000000 ? A7F828000000001 ?
opiodr()+984         call     kpoal8()             00000005E ? 000000017 ?
                                                   7FFF6F187550 ? 000000001 ?
                                                   000000001 ? A7F828000000001 ?
ttcpip()+1012        call     opiodr()             00000005E ? 000000017 ?
                                                   7FFF6F187550 ? 000000000 ?
                                                   0059C0990 ? A7F828000000001 ?
opitsk()+1322        call     ttcpip()             00689E3B0 ? 000000001 ?
                                                   7FFF6F187550 ? 000000000 ?
                                                   7FFF6F187048 ? 7FFF6F1876B8 ?
opiino()+1026        call     opitsk()             000000003 ? 000000000 ?
                                                   7FFF6F187550 ? 000000001 ?
=========================================================

该ORA-00600[2608]可能由数据文件头中记录的checkpoint scn过小造成,Oracle会将该checkpoint scn与块中的resetlogs scn以及控制文件中记录的日志文件的Low scn相比较,若文件头中的checkpoint scn远小于对比值,那么就会出现ORA-00600[2608]内部错误。

下面我们通过修改数据文件头中kcvfhckp结构中记录的checkpoint scn到一个较小值,来模拟出发ORA-00600[2608]内部错误:

SQL> oradebug setmypid;
Statement processed.

SQL> oradebug dump file_hdrs 8;
Statement processed.

SQL> oradebug tracefile_name;

DATA FILE #11:
  (name #17) /u01/data02.dbf
creation size=6400 block size=8192 status=0x1c head=17 tail=17 dup=1
 tablespace 12, index=12 krfil=11 prev_file=0
 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
 Checkpoint cnt:4 scn: 0x0000.000b01c2 04/27/2011 22:52:31
 Stop scn: 0x0000.000b01c5 04/27/2011 22:52:39
 Creation Checkpointed at scn:  0x0000.000b01a8 04/27/2011 22:52:24
 thread:1 rba:(0xb.e.10)
....................................................
 Hot Backup end marker scn: 0x0000.00000000
 aux_file is NOT DEFINED
 V10 STYLE FILE HEADER:
        Compatibility Vsn = 169870080=0xa200300
        Db ID=2894437650=0xac859d12, Db Name='G10R2'
        Activation ID=0=0x0
        Control Seq=740=0x2e4, File size=6400=0x1900
        File Number=11, Blksiz=8192, File Type=3 DATA
Tablespace #12 - DATA02  rel_fn:11
Creation   at   scn: 0x0000.000b01a8 04/27/2011 22:52:24
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x2cade887 scn: 0x0000.000a88f9 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 prev reset logs count:0x2cadd4e7 scn: 0x0000.000a7f86 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 recovered at 01/01/1988 00:00:00
 status:0x4 root dba:0x00000000 chkpt cnt: 4 ctl cnt:3
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.000b01c2 04/27/2011 22:52:31

/* 可以看到以上11号数据文件头的Checkpoint scn为0x0000.000b01c2 ,
    而resetlogs scn为0x0000.000a88f9                                        */

/* 我们将Checkpoint scn修改为0x0000.000a88f7                      */

[oracle@rh2 u01]$ bbed filename=data02.dbf blocksize=8192 password=blockedit mode=edit

BBED: Release 2.0.0.0.0 - Limited Production on Wed Apr 27 22:55:30 2011

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

************* !!! For Oracle Internal Use only !!! ***************
BBED> set blocksize 8192
        BLOCKSIZE       8192

BBED> set block 2
        BLOCK#          2

BBED> map
 File: data02.dbf (0)
 Block: 2                                     Dba:0x00000000
------------------------------------------------------------
 Data File Header

 struct kcvfh, 676 bytes                    @0       

 ub4 tailchk                                @8188    

BBED> p kcvfh
struct kcvfh, 676 bytes                     @0       
   struct kcvfhbfh, 20 bytes                @0       
      ub1 type_kcbh                         @0        0x0b
      ub1 frmt_kcbh                         @1        0xa2
      ub1 spare1_kcbh                       @2        0x00
      ub1 spare2_kcbh                       @3        0x00
      ub4 rdba_kcbh                         @4        0x02c00001
      ub4 bas_kcbh                          @8        0x00000000
      ub2 wrp_kcbh                          @12       0x0000
      ub1 seq_kcbh                          @14       0x01
      ub1 flg_kcbh                          @15       0x04 (KCBHFCKV)
      ub2 chkval_kcbh                       @16       0xb4a1
      ub2 spare3_kcbh                       @18       0x0000
   struct kcvfhhdr, 76 bytes                @20      
      ub4 kccfhswv                          @20       0x00000000
      ub4 kccfhcvn                          @24       0x0a200300
      ub4 kccfhdbi                          @28       0xac859d12
      text kccfhdbn[0]                      @32      G
      text kccfhdbn[1]                      @33      1
      text kccfhdbn[2]                      @34      0
      text kccfhdbn[3]                      @35      R
      text kccfhdbn[4]                      @36      2
      text kccfhdbn[5]                      @37       
      text kccfhdbn[6]                      @38       
      text kccfhdbn[7]                      @39       
      ub4 kccfhcsq                          @40       0x000002e4
      ub4 kccfhfsz                          @44       0x00001900
      s_blkz kccfhbsz                       @48       0x00
      ub2 kccfhfno                          @52       0x000b
      ub2 kccfhtyp                          @54       0x0003
      ub4 kccfhacid                         @56       0x00000000
      ub4 kccfhcks                          @60       0x00000000
      text kccfhtag[0]                      @64       
      text kccfhtag[1]                      @65       
      text kccfhtag[2]                      @66       
      text kccfhtag[3]                      @67       
      text kccfhtag[4]                      @68       
      text kccfhtag[5]                      @69       
      text kccfhtag[6]                      @70       
      text kccfhtag[7]                      @71       
      text kccfhtag[8]                      @72       
      text kccfhtag[9]                      @73       
      text kccfhtag[10]                     @74       
      text kccfhtag[11]                     @75       
      text kccfhtag[12]                     @76       
      text kccfhtag[13]                     @77       
      text kccfhtag[14]                     @78       
      text kccfhtag[15]                     @79       
      text kccfhtag[16]                     @80       
      text kccfhtag[17]                     @81       
      text kccfhtag[18]                     @82       
      text kccfhtag[19]                     @83       
      text kccfhtag[20]                     @84       
      text kccfhtag[21]                     @85       
      text kccfhtag[22]                     @86       
      text kccfhtag[23]                     @87       
      text kccfhtag[24]                     @88       
      text kccfhtag[25]                     @89       
      text kccfhtag[26]                     @90       
      text kccfhtag[27]                     @91       
      text kccfhtag[28]                     @92       
      text kccfhtag[29]                     @93       
      text kccfhtag[30]                     @94       
      text kccfhtag[31]                     @95       
   ub4 kcvfhrdb                             @96       0x00000000
   struct kcvfhcrs, 8 bytes                 @100     
      ub4 kscnbas                           @100      0x000b01a8
      ub2 kscnwrp                           @104      0x0000
   ub4 kcvfhcrt                             @108      0x2cae0628
   ub4 kcvfhrlc                             @112      0x2cade887
   struct kcvfhrls, 8 bytes                 @116                             resetlogs scn
      ub4 kscnbas                           @116      0x000a88f9
      ub2 kscnwrp                           @120      0x0000
   ub4 kcvfhbti                             @124      0x00000000
   struct kcvfhbsc, 8 bytes                 @128     
      ub4 kscnbas                           @128      0x00000000
      ub2 kscnwrp                           @132      0x0000
   ub2 kcvfhbth                             @136      0x0000
   ub2 kcvfhsta                             @138      0x0004 (KCVFHOFZ)
   struct kcvfhckp, 36 bytes                @484     
      struct kcvcpscn, 8 bytes              @484                               checkpoint scn 
         ub4 kscnbas                        @484      0x000b01c2
         ub2 kscnwrp                        @488      0x0000
      ub4 kcvcptim                          @492      0x2cae062f
      ub2 kcvcpthr                          @496      0x0001
      union u, 12 bytes                     @500     
         struct kcvcprba, 12 bytes          @500     
            ub4 kcrbaseq                    @500      0x0000000b
            ub4 kcrbabno                    @504      0x0000001b
            ub2 kcrbabof                    @508      0x0010
      ub1 kcvcpetb[0]                       @512      0x02
      ub1 kcvcpetb[1]                       @513      0x00
      ub1 kcvcpetb[2]                       @514      0x00
      ub1 kcvcpetb[3]                       @515      0x00
      ub1 kcvcpetb[4]                       @516      0x00
      ub1 kcvcpetb[5]                       @517      0x00
      ub1 kcvcpetb[6]                       @518      0x00
      ub1 kcvcpetb[7]                       @519      0x00
   ub4 kcvfhcpc                             @140      0x00000004
   ub4 kcvfhrts                             @144      0x00000000
   ub4 kcvfhccc                             @148      0x00000003
   struct kcvfhbcp, 36 bytes                @152     
      struct kcvcpscn, 8 bytes              @152     
         ub4 kscnbas                        @152      0x00000000
         ub2 kscnwrp                        @156      0x0000
      ub4 kcvcptim                          @160      0x00000000
      ub2 kcvcpthr                          @164      0x0000
      union u, 12 bytes                     @168     
         struct kcvcprba, 12 bytes          @168     
            ub4 kcrbaseq                    @168      0x00000000
            ub4 kcrbabno                    @172      0x00000000
            ub2 kcrbabof                    @176      0x0000
      ub1 kcvcpetb[0]                       @180      0x00
      ub1 kcvcpetb[1]                       @181      0x00
      ub1 kcvcpetb[2]                       @182      0x00
      ub1 kcvcpetb[3]                       @183      0x00
      ub1 kcvcpetb[4]                       @184      0x00
      ub1 kcvcpetb[5]                       @185      0x00
      ub1 kcvcpetb[6]                       @186      0x00
      ub1 kcvcpetb[7]                       @187      0x00
   ub4 kcvfhbhz                             @312      0x00000000
   struct kcvfhxcd, 16 bytes                @316     
      ub4 space_kcvmxcd[0]                  @316      0x00000000
      ub4 space_kcvmxcd[1]                  @320      0x00000000
      ub4 space_kcvmxcd[2]                  @324      0x00000000
      ub4 space_kcvmxcd[3]                  @328      0x00000000
   word kcvfhtsn                            @332      12
   ub2 kcvfhtln                             @336      0x0006
   text kcvfhtnm[0]                         @338     D
   text kcvfhtnm[1]                         @339     A
   text kcvfhtnm[2]                         @340     T
   text kcvfhtnm[3]                         @341     A
   text kcvfhtnm[4]                         @342     0
   text kcvfhtnm[5]                         @343     2
   text kcvfhtnm[6]                         @344      
   text kcvfhtnm[7]                         @345      
   text kcvfhtnm[8]                         @346      
   text kcvfhtnm[9]                         @347      
   text kcvfhtnm[10]                        @348      
   text kcvfhtnm[11]                        @349      
   text kcvfhtnm[12]                        @350      
   text kcvfhtnm[13]                        @351      
   text kcvfhtnm[14]                        @352      
   text kcvfhtnm[15]                        @353      
   text kcvfhtnm[16]                        @354      
   text kcvfhtnm[17]                        @355      
   text kcvfhtnm[18]                        @356      
   text kcvfhtnm[19]                        @357      
   text kcvfhtnm[20]                        @358      
   text kcvfhtnm[21]                        @359      
   text kcvfhtnm[22]                        @360      
   text kcvfhtnm[23]                        @361      
   text kcvfhtnm[24]                        @362      
   text kcvfhtnm[25]                        @363      
   text kcvfhtnm[26]                        @364      
   text kcvfhtnm[27]                        @365      
   text kcvfhtnm[28]                        @366      
   text kcvfhtnm[29]                        @367      
   ub4 kcvfhrfn                             @368      0x0000000b
   struct kcvfhrfs, 8 bytes                 @372     
      ub4 kscnbas                           @372      0x00000000
      ub2 kscnwrp                           @376      0x0000
   ub4 kcvfhrft                             @380      0x00000000
   struct kcvfhafs, 8 bytes                 @384     
      ub4 kscnbas                           @384      0x00000000
      ub2 kscnwrp                           @388      0x0000
   ub4 kcvfhbbc                             @392      0x00000000
   ub4 kcvfhncb                             @396      0x00000000
   ub4 kcvfhmcb                             @400      0x00000000
   ub4 kcvfhlcb                             @404      0x00000000
   ub4 kcvfhbcs                             @408      0x00000000
   ub2 kcvfhofb                             @412      0x0000
   ub2 kcvfhnfb                             @414      0x0000
   ub4 kcvfhprc                             @416      0x2cadd4e7
   struct kcvfhprs, 8 bytes                 @420     
      ub4 kscnbas                           @420      0x000a7f86
      ub2 kscnwrp                           @424      0x0000
   struct kcvfhprfs, 8 bytes                @428     
      ub4 kscnbas                           @428      0x00000000
      ub2 kscnwrp                           @432      0x0000
   ub4 kcvfhtrt                             @444      0x00000000

BBED> set offset 484
        OFFSET          484

BBED> p                 
pad
---
ub1 pad                                     @484      0xc2

BBED> modify /x f788
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: data02.dbf (0)
 Block: 2                Offsets:  484 to  995           Dba:0x00000000
------------------------------------------------------------------------
 f7880b00 00000000 2f06ae2c 01000000 0b000000 1b000000 1000e880 02000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 0d000d00 0d000100 00000000 00000000 00000000 0200c002 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

BBED> set offset 486
        OFFSET          486

BBED> p
pad
---
ub1 pad                                     @486      0x00

BBED> modify /x 0x0a00
 File: data02.dbf (0)
 Block: 2                Offsets:  486 to  997           Dba:0x00000000
------------------------------------------------------------------------
 0a000000 00002f06 ae2c0100 00000b00 00001b00 00001000 e8800200 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000d00 
 0d000d00 01000000 00000000 00000000 00000200 c0020000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484     
   struct kcvcpscn, 8 bytes                 @484     
      ub4 kscnbas                           @484      0x000a88f7
      ub2 kscnwrp                           @488      0x0000
   ub4 kcvcptim                             @492      0x2cae062f
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500     
      struct kcvcprba, 12 bytes             @500     
         ub4 kcrbaseq                       @500      0x0000000b
         ub4 kcrbabno                       @504      0x0000001b
         ub2 kcrbabof                       @508      0x0010
   ub1 kcvcpetb[0]                          @512      0x02
   ub1 kcvcpetb[1]                          @513      0x00
   ub1 kcvcpetb[2]                          @514      0x00
   ub1 kcvcpetb[3]                          @515      0x00
   ub1 kcvcpetb[4]                          @516      0x00
   ub1 kcvcpetb[5]                          @517      0x00
   ub1 kcvcpetb[6]                          @518      0x00
   ub1 kcvcpetb[7]                          @519      0x00

BBED> sum
Check value for File 0, Block 2:
current = 0xb4a1, required = 0x3d95

BBED> sum apply
Check value for File 0, Block 2:
current = 0x3d95, required = 0x3d95

/* 如我们所期待地出现了ORA-00600[2608]内部错误 */

SQL> recover datafile 11;
ORA-00283: recovery session canceled due to errors
ORA-00600: internal error code, arguments: [2608], [2], [0], [690423], [0],
[721306], [], []

这里的690423也就是16进制的0x000a88f7,是我们之前所修改的checkpoint scn,
而721306等于0xb019a,为当前日志文件的Low scn:
LOG FILE #1:
  (name #5) /flashcard/oradata/G10R2/onlinelog/o1_mf_1_6v34jnkn_.log
  (name #6) /s01/flash_recovery_area/G10R2/onlinelog/o1_mf_1_6v34jnst_.log
 Thread 1 redo log links: forward: 2 backward: 0
 siz: 0x19000 seq: 0x0000000a hws: 0x2 bsz: 512 nab: 0x2 flg: 0x1 dup: 2
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000b0193
 Low scn: 0x0000.000b0196 04/27/2011 22:52:05
 Next scn: 0x0000.000b019a 04/27/2011 22:52:10
LOG FILE #2:
  (name #3) /flashcard/oradata/G10R2/onlinelog/o1_mf_2_6v34jokt_.log
  (name #4) /s01/flash_recovery_area/G10R2/onlinelog/o1_mf_2_6v34jotq_.log
 Thread 1 redo log links: forward: 3 backward: 1
 siz: 0x19000 seq: 0x0000000b hws: 0x1 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 2
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000b0196
 Low scn: 0x0000.000b019a 04/27/2011 22:52:10
 Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
  (name #1) /flashcard/oradata/G10R2/onlinelog/o1_mf_3_6v34jpmp_.log
  (name #2) /s01/flash_recovery_area/G10R2/onlinelog/o1_mf_3_6v34jpyn_.log
 Thread 1 redo log links: forward: 0 backward: 2
 siz: 0x19000 seq: 0x00000009 hws: 0x2 bsz: 512 nab: 0x2 flg: 0x1 dup: 2
 Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.000b0190
 Low scn: 0x0000.000b0193 04/27/2011 22:52:04
 Next scn: 0x0000.000b0196 04/27/2011 22:52:05

记以录之!

使用bbed解决ORA-01189错误

ORA-01189错误常见于使用Create Controlfile命令时发现OFFLINE的数据文件或者备份文件生成于上一次的RESETLOGS之前,一般来说如果是在RESETLOGS前offline的数据文件,可以在CREATE CONTROLFILE命令中省略该offline datafile,在打开数据库后使用rename file命令修复其丢失的数据文件名,之后再将数据文件online;若不是offline datafile所造成的ORA-01189错误,就必须要找出与其他数据文件版本一致的数据文件或其备份才能解决该问题。

设想存在这样一个场景:数据库处于非归档无备份的状态,在周日使用shutdown immediate命令干净地关闭了数据库,到周一发现因为磁盘故障丢失了所有的控制文件,不得不使用Create Controlfile RESETLOGS重建控制文件,而在重建过程中又漏输了某条数据文件的记录,之后又使用alter database open resetlogs重置日志文件并打开数据库,此时发现丢失了一个数据文件,尝试使用针对offline datafile的处理方法将丢失的数据文件重命名(rename),并尝试online该数据文件,毫无疑问我们会遇到ORA-01190 “control file or data file %s is from before the last RESETLOGS”错误,这时虽然我们手上有该”干净”的数据文件,却也没有办法使之online了。

 

 

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

 

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

 

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

 

 

这里我介绍一种使用bbed修改数据文件头的方法来解决该ORA-01189错误:

 

 

[oracle@rh2 controlfile]$ oerr ora 1189
01189, 00000, "file is from a different RESETLOGS than previous files"
// *Cause:  In a CREATE CONTROLFILE command either this file or all previous
//          files were backups from before the last RESETLOGS. This may also
//          occur if this is a file that is offline and has been offline since
//          before the last RESETLOGS.
// *Action: If the file was taken offline normal before the last RESETLOGS,
//          and is still offline, omit it from the CREATE CONTROLFILE command.
//          Rename and online the file after the database is open. Otherwise
//          find the version of the mentioned file consistent with the rest
//          of the datafiles and resubmit the command.

[oracle@rh2 controlfile]$ oerr ora 1190
01190, 00000, "control file or data file %s is from before the last RESETLOGS"
// *Cause: Attempting to use a data file when the log reset information in
//          the file does not match the control file. Either the data file
//          or the control file is a backup that was made before the most
//          recent ALTER DATABASE OPEN RESETLOGS.
// *Action: Restore file from a more recent backup.

/* 在我们的场景中wwli.dbf充当这样一个被"忽视"的数据文件 */

SQL> create tablespace we_will_lost_it datafile '/flashcard/wwli.dbf' size 20M;
Tablespace created.

SQL> create table lost_data tablespace we_will_lost_it as select * from obj$;
Table created.

SQL> alter database backup controlfile to trace ;
Database altered.

SQL> shutdown immediate;

/* 删除所有的控制文件,切勿用于生产环境! */

[oracle@rh2 ~]$ rm /flashcard/oradata/G10R2/controlfile/1.ctl 

[oracle@rh2 ~]$ sqlplus / as sysdba                           

SQL*Plus: Release 10.2.0.4.0 - Production on Wed Apr 27 20:42:31 2011

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.

Connected to an idle instance.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 1224736768 bytes
Fixed Size                  2083560 bytes
Variable Size             318768408 bytes
Database Buffers          889192448 bytes
Redo Buffers               14692352 bytes
ORA-00205: error in identifying control file, check alert log for more info

/* 使用create controlfile resetlogs重建控制文件,这里我们"无意"中丢失了一个数据文件  */

SQL> CREATE CONTROLFILE REUSE DATABASE "G10R2" RESETLOGS  NOARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 (
  9      '/flashcard/oradata/G10R2/onlinelog/o1_mf_1_6v34jnkn_.log',
 10      '/s01/flash_recovery_area/G10R2/onlinelog/o1_mf_1_6v34jnst_.log'
 11    ) SIZE 50M,
 12    GROUP 2 (
 13      '/flashcard/oradata/G10R2/onlinelog/o1_mf_2_6v34jokt_.log',
 14      '/s01/flash_recovery_area/G10R2/onlinelog/o1_mf_2_6v34jotq_.log'
 15    ) SIZE 50M,
 16    GROUP 3 (
 17      '/flashcard/oradata/G10R2/onlinelog/o1_mf_3_6v34jpmp_.log',
 18      '/s01/flash_recovery_area/G10R2/onlinelog/o1_mf_3_6v34jpyn_.log'
 19    ) SIZE 50M
 20  -- STANDBY LOGFILE
 21  DATAFILE
 22    '/flashcard/oradata/G10R2/datafile/o1_mf_system_6v34hhyw_.dbf',
 23    '/flashcard/oradata/G10R2/datafile/o1_mf_undotbs1_6v34hj0l_.dbf',
 24    '/flashcard/oradata/G10R2/datafile/o1_mf_sysaux_6v34hhyx_.dbf',
 25    '/flashcard/oradata/G10R2/datafile/o1_mf_users_6v34hj0p_.dbf',
 26    '/flashcard/oradata/G10R2/datafile/o1_mf_example_6v34jthj_.dbf',
 27    '/flashcard/oradata/G10R2/datafile/o1_mf_test_6vhlm3mv_.dbf',
 28    '/flashcard/oradata/G10R2/datafile/o1_mf_lostfile_6vhtgo7w_.dbf'
 29    -- we lost datafile here!!! '/flashcard/wwli.dbf'
 30  CHARACTER SET UTF8
 31  ;

Control file created.

SQL> recover database using backup controlfile  ;
ORA-00279: change 690423 generated at 04/27/2011 20:40:36 needed for thread 1
ORA-00289: suggestion :
/s01/flash_recovery_area/G10R2/archivelog/2011_04_27/o1_mf_1_1_%u_.arc
ORA-00280: change 690423 for thread 1 is in sequence #1

Specify log: {=suggested | filename | AUTO | CANCEL}
/flashcard/oradata/G10R2/onlinelog/o1_mf_1_6v34jnkn_.log
Log applied.
Media recovery complete.

SQL> alter database open resetlogs;
Database altered.

SQL> select * from v$recover_file;

     FILE# ONLINE  ONLINE_ ERROR                                                                CHANGE# TIME
---------- ------- ------- ----------------------------------------------------------------- ---------- ---------
         9 OFFLINE OFFLINE FILE MISSING                                                               0

SQL> select name from v$datafile where file#=9;

NAME
--------------------------------------------------
/s01/db_1/dbs/MISSING00009

SQL> alter database rename file '/s01/db_1/dbs/MISSING00009' to '/flashcard/wwli.dbf';

Database altered.

SQL> alter database datafile 9 online;
alter database datafile 9 online
*
ERROR at line 1:
ORA-01190: control file or data file 9 is from
before the last RESETLOGS
ORA-01110: data file 9: '/flashcard/wwli.dbf'

/* 此时遭遇了我们之前描述的问题!  */

SQL> oradebug setmypid;
Statement processed.

/* 使用dump file_hdrs命令转储数据文件头,我们转储数据文件头的目的是为了获取resetlogs count,resetlogs scn */

SQL> oradebug dump file_hdrs 8;
Statement processed.

SQL> oradebug tracefile_name;
/s01/admin/G10R2/udump/g10r2_ora_20029.trc

Tablespace #0 - SYSTEM  rel_fn:1
Creation   at   scn: 0x0000.00000005 03/12/2008 00:39:08
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x2cade887 scn: 0x0000.000a88f9 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 prev reset logs count:0x2cadd4e7 scn: 0x0000.000a7f86 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 recovered at 04/27/2011 20:45:34
 status:0x2004 root dba:0x00400179 chkpt cnt: 85 ctl cnt:84
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.000a88fa 04/27/2011 20:46:00

Tablespace #1 - UNDOTBS1  rel_fn:2
Creation   at   scn: 0x0000.00092a47 03/12/2008 01:19:05
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x2cade887 scn: 0x0000.000a88f9 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 prev reset logs count:0x2cadd4e7 scn: 0x0000.000a7f86 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 recovered at 04/27/2011 20:45:34
 status:0x4 root dba:0x00000000 chkpt cnt: 45 ctl cnt:44
begin-hot-backup file size: 0

Tablespace #10 - WE_WILL_LOST_IT  rel_fn:9
Creation   at   scn: 0x0000.000a8849 04/27/2011 20:39:27
Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0
 reset logs count:0x2cadd4e7 scn: 0x0000.000a7f86 reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 prev reset logs count:0x2cadcee3 scn: 0x0000.000a2af7 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000
 recovered at 01/01/1988 00:00:00
 status:0x0 root dba:0x00000000 chkpt cnt: 3 ctl cnt:2
begin-hot-backup file size: 0
Checkpointed at scn:  0x0000.000a88f7 04/27/2011 20:40:36
 thread:1 rba:(0x1.c6f.10)

以上可以看到数据文件1和2的resetlogs count(0x2cade887),scn(000a88f9)都是一样的值,而我们的问题数据文件头中的对应信息则与之不同!

接下来我们使用bbed命令去修改问题数据文件头中的resetlogs count,scn信息,关于bbed的编译和使用可以参考这里。

[oracle@rh2 ~]$ bbed filename=/flashcard/wwli.dbf blocksize=8192 password=blockedit mode=edit

BBED: Release 2.0.0.0.0 - Limited Production on Wed Apr 27 20:59:14 2011

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

************* !!! For Oracle Internal Use only !!! ***************
BBED> set block 1
        BLOCK#          1

BBED> map
 File: /flashcard/wwli.dbf (0)
 Block: 1                                     Dba:0x00000000
------------------------------------------------------------
 Data File Header

 struct kcvfh, 676 bytes                    @0       

 ub4 tailchk                                @8188    

BBED> p kcvfh
struct kcvfh, 676 bytes                     @0
   struct kcvfhbfh, 20 bytes                @0
      ub1 type_kcbh                         @0        0x0b
      ub1 frmt_kcbh                         @1        0xa2                     format 10.2
      ub1 spare1_kcbh                       @2        0x00
      ub1 spare2_kcbh                       @3        0x00
      ub4 rdba_kcbh                         @4        0x02400001           RDBA
      ub4 bas_kcbh                          @8        0x00000000
      ub2 wrp_kcbh                          @12       0x0000
      ub1 seq_kcbh                          @14       0x01
      ub1 flg_kcbh                          @15       0x04 (KCBHFCKV)
      ub2 chkval_kcbh                       @16       0xafa1                checksum
      ub2 spare3_kcbh                       @18       0x0000
   struct kcvfhhdr, 76 bytes                @20
      ub4 kccfhswv                          @20       0x00000000
      ub4 kccfhcvn                          @24       0x0a200300          compatible
      ub4 kccfhdbi                          @28       0xac859d12
      text kccfhdbn[0]                      @32      G                         DB_NAME
      text kccfhdbn[1]                      @33      1
      text kccfhdbn[2]                      @34      0
      text kccfhdbn[3]                      @35      R
      text kccfhdbn[4]                      @36      2
      text kccfhdbn[5]                      @37
      text kccfhdbn[6]                      @38
      text kccfhdbn[7]                      @39
      ub4 kccfhcsq                          @40       0x00000245
      ub4 kccfhfsz                          @44       0x00000a00
      s_blkz kccfhbsz                       @48       0x00
      ub2 kccfhfno                          @52       0x0009                   FILE NUM
      ub2 kccfhtyp                          @54       0x0003                   FILE TYPE
      ub4 kccfhacid                         @56       0x00000000
      ub4 kccfhcks                          @60       0x00000000
      text kccfhtag[0]                      @64
      text kccfhtag[1]                      @65
      text kccfhtag[2]                      @66
      text kccfhtag[3]                      @67
      text kccfhtag[4]                      @68
      text kccfhtag[5]                      @69
      text kccfhtag[6]                      @70
      text kccfhtag[7]                      @71
      text kccfhtag[8]                      @72
      text kccfhtag[9]                      @73
      text kccfhtag[10]                     @74
      text kccfhtag[11]                     @75
      text kccfhtag[12]                     @76
      text kccfhtag[13]                     @77
      text kccfhtag[14]                     @78
      text kccfhtag[15]                     @79
      text kccfhtag[16]                     @80
      text kccfhtag[17]                     @81
      text kccfhtag[18]                     @82
      text kccfhtag[19]                     @83
      text kccfhtag[20]                     @84
      text kccfhtag[21]                     @85
      text kccfhtag[22]                     @86
      text kccfhtag[23]                     @87
      text kccfhtag[24]                     @88
      text kccfhtag[25]                     @89
      text kccfhtag[26]                     @90
      text kccfhtag[27]                     @91
      text kccfhtag[28]                     @92
      text kccfhtag[29]                     @93
      text kccfhtag[30]                     @94
      text kccfhtag[31]                     @95
   ub4 kcvfhrdb                             @96       0x00000000
   struct kcvfhcrs, 8 bytes                 @100                              Creation Checkpointed at scn
      ub4 kscnbas                           @100      0x000a8849
      ub2 kscnwrp                           @104      0x0000
   ub4 kcvfhcrt                             @108      0x2cade6ff           
   ub4 kcvfhrlc                             @112      0x2cadd4e7               resetlogs count
   struct kcvfhrls, 8 bytes                 @116
      ub4 kscnbas                           @116      0x000a7f86              resetlogs scn
      ub2 kscnwrp                           @120      0x0000
   ub4 kcvfhbti                             @124      0x00000000
   struct kcvfhbsc, 8 bytes                 @128
      ub4 kscnbas                           @128      0x00000000
      ub2 kscnwrp                           @132      0x0000
   ub2 kcvfhbth                             @136      0x0000
   ub2 kcvfhsta                             @138      0x0000 (NONE)
   struct kcvfhckp, 36 bytes                @484
      struct kcvcpscn, 8 bytes              @484                                  Checkpoint scn
         ub4 kscnbas                        @484      0x000a88f7
         ub2 kscnwrp                        @488      0x0000
      ub4 kcvcptim                          @492      0x2cade744
      ub2 kcvcpthr                          @496      0x0001
      union u, 12 bytes                     @500
         struct kcvcprba, 12 bytes          @500
            ub4 kcrbaseq                    @500      0x00000001
            ub4 kcrbabno                    @504      0x00000c6f
            ub2 kcrbabof                    @508      0x0010
      ub1 kcvcpetb[0]                       @512      0x02
      ub1 kcvcpetb[1]                       @513      0x00
      ub1 kcvcpetb[2]                       @514      0x00
      ub1 kcvcpetb[3]                       @515      0x00
      ub1 kcvcpetb[4]                       @516      0x00
      ub1 kcvcpetb[5]                       @517      0x00
      ub1 kcvcpetb[6]                       @518      0x00
      ub1 kcvcpetb[7]                       @519      0x00
   ub4 kcvfhcpc                             @140      0x00000003
   ub4 kcvfhrts                             @144      0x00000000
   ub4 kcvfhccc                             @148      0x00000002
   struct kcvfhbcp, 36 bytes                @152
      struct kcvcpscn, 8 bytes              @152
         ub4 kscnbas                        @152      0x00000000
         ub2 kscnwrp                        @156      0x0000
      ub4 kcvcptim                          @160      0x00000000
      ub2 kcvcpthr                          @164      0x0000
      union u, 12 bytes                     @168
         struct kcvcprba, 12 bytes          @168
            ub4 kcrbaseq                    @168      0x00000000
            ub4 kcrbabno                    @172      0x00000000
            ub2 kcrbabof                    @176      0x0000
      ub1 kcvcpetb[0]                       @180      0x00
      ub1 kcvcpetb[1]                       @181      0x00
      ub1 kcvcpetb[2]                       @182      0x00
      ub1 kcvcpetb[3]                       @183      0x00
      ub1 kcvcpetb[4]                       @184      0x00
      ub1 kcvcpetb[5]                       @185      0x00
      ub1 kcvcpetb[6]                       @186      0x00
      ub1 kcvcpetb[7]                       @187      0x00
   ub4 kcvfhbhz                             @312      0x00000000
   struct kcvfhxcd, 16 bytes                @316
      ub4 space_kcvmxcd[0]                  @316      0x00000000
      ub4 space_kcvmxcd[1]                  @320      0x00000000
      ub4 space_kcvmxcd[2]                  @324      0x00000000
      ub4 space_kcvmxcd[3]                  @328      0x00000000
   word kcvfhtsn                            @332      10                         Tablespace#
   ub2 kcvfhtln                             @336      0x000f
   text kcvfhtnm[0]                         @338     W                          TABLESPACE_NAME
   text kcvfhtnm[1]                         @339     E
   text kcvfhtnm[2]                         @340     _
   text kcvfhtnm[3]                         @341     W
   text kcvfhtnm[4]                         @342     I
   text kcvfhtnm[5]                         @343     L
   text kcvfhtnm[6]                         @344     L
   text kcvfhtnm[7]                         @345     _
   text kcvfhtnm[8]                         @346     L
   text kcvfhtnm[9]                         @347     O
   text kcvfhtnm[10]                        @348     S
   text kcvfhtnm[11]                        @349     T
   text kcvfhtnm[12]                        @350     _
   text kcvfhtnm[13]                        @351     I
   text kcvfhtnm[14]                        @352     T
   text kcvfhtnm[15]                        @353
   text kcvfhtnm[16]                        @354
   text kcvfhtnm[17]                        @355
   text kcvfhtnm[18]                        @356
   text kcvfhtnm[19]                        @357
   text kcvfhtnm[20]                        @358
   text kcvfhtnm[21]                        @359
   text kcvfhtnm[22]                        @360
   text kcvfhtnm[23]                        @361
   text kcvfhtnm[24]                        @362
   text kcvfhtnm[25]                        @363
   text kcvfhtnm[26]                        @364
   text kcvfhtnm[27]                        @365
   text kcvfhtnm[28]                        @366
   text kcvfhtnm[29]                        @367
   ub4 kcvfhrfn                             @368      0x00000009
   struct kcvfhrfs, 8 bytes                 @372
      ub4 kscnbas                           @372      0x00000000
      ub2 kscnwrp                           @376      0x0000
   ub4 kcvfhrft                             @380      0x00000000
   struct kcvfhafs, 8 bytes                 @384
      ub4 kscnbas                           @384      0x00000000
      ub2 kscnwrp                           @388      0x0000
   ub4 kcvfhbbc                             @392      0x00000000
   ub4 kcvfhncb                             @396      0x00000000
   ub4 kcvfhmcb                             @400      0x00000000
   ub4 kcvfhlcb                             @404      0x00000000
   ub4 kcvfhbcs                             @408      0x00000000
   ub2 kcvfhofb                             @412      0x0000
   ub2 kcvfhnfb                             @414      0x0000
   ub4 kcvfhprc                             @416      0x2cadcee3     prev reset logs count
   struct kcvfhprs, 8 bytes                 @420                        prev reset scn
      ub4 kscnbas                           @420      0x000a2af7
      ub2 kscnwrp                           @424      0x0000
   struct kcvfhprfs, 8 bytes                @428
      ub4 kscnbas                           @428      0x00000000
      ub2 kscnwrp                           @432      0x0000
   ub4 kcvfhtrt                             @444      0x00000000

/* 以上kcvfh结构是数据文件头的主要信息,其中ub4 kcvfhrlc(offset 112)记录了resetlogs count,
    而 struct kcvfhrls 8 bytes(offset 116)记录了resetlogs scn */

/* 接下来将问题数据文件头上的kcvfhrlc和kcvfhrls信息修改成和1号文件中的一样,
    以欺骗Oracle让其以为该数据文件参与了上一次的RESETLOGS                 */

BBED> set offset 112
        OFFSET          112

/* 在使用bbed modify的时候需要注意所在平台的endian,Linux上使用Little Endian */

BBED> modify /x 87e8
 File: /flashcard/wwli.dbf (0)
 Block: 1                Offsets:  112 to  623           Dba:0x00000000
------------------------------------------------------------------------
 87e8ad2c 867f0a00 00000000 00000000 00000000 00000000 00000000 03000000
 00000000 02000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0a000000
 0f005745 5f57494c 4c5f4c4f 53545f49 54000000 00000000 00000000 00000000
 09000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 e3cead2c f72a0a00 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 f7880a00 00000000 44e7ad2c
 01000160 01000000 6f0c0000 10000000 02000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

BBED> p kcvfhrlc
ub4 kcvfhrlc                                @112      0x2cade887

BBED> set offset 116
        OFFSET          116

BBED> modify /x 0xf988
 File: /flashcard/wwli.dbf (0)
 Block: 1                Offsets:  116 to  627           Dba:0x00000000
------------------------------------------------------------------------
 f9880a00 00000000 00000000 00000000 00000000 00000000 03000000 00000000
 02000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 0a000000 0f005745
 5f57494c 4c5f4c4f 53545f49 54000000 00000000 00000000 00000000 09000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 e3cead2c f72a0a00 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 f7880a00 00000000 44e7ad2c 01000160
 01000000 6f0c0000 10000000 02000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

BBED> p kcvfhrls
struct kcvfhrls, 8 bytes                    @116
   ub4 kscnbas                              @116      0x000a88f9
   ub2 kscnwrp                              @120      0x0000

/* 还需要将kcvfhckp结构中的kcvcpscn也修改成与1号文件一样的resetlogs scn ,
    否则在recover数据文件的时候可能出现
    ORA-00600: internal error code, arguments: [2608], [1], [0], [690423], [0], [690425], [], []错误  */

BBED> set offset 484
        OFFSET          484

BBED> modify /x 0xf9
 File: /flashcard/wwli.dbf (0)
 Block: 1                Offsets:  484 to  995           Dba:0x00000000
------------------------------------------------------------------------
 f9880a00 00000000 44e7ad2c 01000160 01000000 6f0c0000 10000000 02000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 0d000d00 0d000100 00000000 00000000 00000000 02004002 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

 <32 bytes per line>

BBED> p kcvfhckp
struct kcvfhckp, 36 bytes                   @484
   struct kcvcpscn, 8 bytes                 @484
      ub4 kscnbas                           @484      0x000a88f9
      ub2 kscnwrp                           @488      0x0000
   ub4 kcvcptim                             @492      0x2cade744
   ub2 kcvcpthr                             @496      0x0001
   union u, 12 bytes                        @500
      struct kcvcprba, 12 bytes             @500
         ub4 kcrbaseq                       @500      0x00000001
         ub4 kcrbabno                       @504      0x00000c6f
         ub2 kcrbabof                       @508      0x0010
   ub1 kcvcpetb[0]                          @512      0x02
   ub1 kcvcpetb[1]                          @513      0x00
   ub1 kcvcpetb[2]                          @514      0x00
   ub1 kcvcpetb[3]                          @515      0x00
   ub1 kcvcpetb[4]                          @516      0x00
   ub1 kcvcpetb[5]                          @517      0x00
   ub1 kcvcpetb[6]                          @518      0x00
   ub1 kcvcpetb[7]                          @519      0x00

BBED> sum
Check value for File 0, Block 1:
current = 0xb897, required = 0xb899

/* 使用sum apply命令修改该数据块的checksum值  */

BBED> sum apply
Check value for File 0, Block 1:
current = 0xb899, required = 0xb899

SQL>  alter database datafile '/flashcard/wwli.dbf' online;
 alter database datafile '/flashcard/wwli.dbf' online
*
ERROR at line 1:
ORA-01113: file 9 needs media recovery
ORA-01110: data file 9: '/flashcard/wwli.dbf'

/* 完美地recover datafile 9,因为该数据文件中的数据本身就是"干净"的,
    仅仅是datafile header中的resetlogs信息与其他datafile不一致而已  */

SQL> recover datafile 9;
Media recovery complete.

SQL> select * from v$recover_file where file#=9;
no rows selected

SQL> select count(*) from lost_data ;

  COUNT(*)
----------
     51791

/* That's great!

虽然我们也可以利用adjust_scn和设置隐藏参数”_allow_resetlogs_corruption”来尝试解决ORA-01189错误,但使用bbed可以避免用到”_allow_resetlogs_corruption”这个危险参数,且在之后更完美地recover恢复数据文件。

需要注意的是使用bbed修复问题数据文件并不能保证必然都成功,在使用bbed之前必须执行必要的备份,并在专业人士的指导下操作!

在Unix上使用管道压缩exp导出文件

exp导出文件大到文件系统放不下怎么办?

在Unix上一种行之有效的解决方法是创建一个命名管道,因为exp的导出dumpfile的内容是顺序的,可以将其内容重定向到管道并对该管道实施压缩操作,从而实现其直接的导出文件就是压缩过的。下面我们举出一个使用该中管道压缩的例子:

[oracle@vrh1 exp]$ exp system/oracle  file=maclean.dmp tables=maclean.tv

Export: Release 10.2.0.4.0 - Production on Fri Apr 1 17:03:09 2011
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses WE8ISO8859P1 character set (possible charset conversion)
About to export specified tables via Conventional Path ...
Current user changed to MACLEAN
. . exporting table                             TV      19988 rows exported
Export terminated successfully without warnings.

/* 不压缩情况下本例中的dumpfile大小为2MB  */

[oracle@vrh1 exp]$ ls -lh maclean.dmp 
-rw-r--r-- 1 oracle oinstall 2.0M Apr  1 17:03 maclean.dmp

/* 首先使用mknod命令创建命名管道 */

[oracle@vrh1 exp]$ mknod macleanpipe p

/*使用nohup命令在后台执行对macleanpipe管道的内容进行gzip压缩,
   之后重定向到maclean_compress.dmp.gz压缩文件                 */


[oracle@vrh1 exp]$ nohup  gzip maclean_compress.dmp.gz &
[1] 27686


[oracle@vrh1 exp]$ exp system/oracle file=macleanpipe tables=maclean.tv


Export: Release 10.2.0.4.0 - Production on Fri Apr 1 17:13:50 2011
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, Real Application Clusters, OLAP, Data Mining
and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses WE8ISO8859P1 character set (possible charset conversion)
About to export specified tables via Conventional Path ...
Current user changed to MACLEAN
. . exporting table                             TV      19988 rows exported
Export terminated successfully without warnings.


[1]+  Done                    nohup gzip < macleanpipe > maclean_compress.dmp.gz

/* 以上当压缩进程gzip接收到exp输出的EOF文件终结符后,
    该压缩进程会自行结束                 * / 

/* 可以看到这里的压缩比还是很高的 */

[oracle@vrh1 exp]$ ls -lh maclean_compress.dmp.gz 
-rw-r--r-- 1 oracle oinstall 225K Apr  1 17:13 maclean_compress.dmp.gz

/* 使用gzip -d命令解压以上gz文件就可以得到普通的dumpfile用以imp导入 */

[oracle@vrh1 exp]$ gzip -d maclean_compress.dmp.gz 

[oracle@vrh1 exp]$ ls -lh maclean_compress.dmp 
-rw-r--r-- 1 oracle oinstall 2.0M Apr  1 17:13 maclean_compress.dmp

在Oracle 10g中引入了速度更快的DataPump Server-side Expdp/Impdp导入导出工具,与exp不同的是,Expdp导出的dumpfile中信息不遵循某种顺序规则,这导致传统的顺序设备如磁带和管道不支持expdp或impdp;换而言之我们无法使用expdp工具将导出结果直接输出到磁带设备或命名管道中,这也造成上述介绍的管道压缩方法对expdp命令是不适用的。

所幸在Oracle Database 11g中对Expdp的压缩选项添加了all和dataonly选项,虽然目前Datapump压缩的性能仍比gzip压缩要差一些,但2者间的差别几乎可以忽略不计。一般在11g中,Oracle推荐使用DataPump压缩来彻底代替Unix管道压缩。

fast incremental backup failed on standby database

一套Linux上的11.1.0.7的physical standby物理备库在使用fast incremental backup进行高于0级的增量备份时会出现ORA-19648错误,其出错记录如下:

RMAN>  backup incremental level 1 database;

Starting backup at 22-MAR-11
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/standby/oradata/SBDB2/datafile/o1_mf_sysaux_22m6ov92_.dbf
input datafile file number=00003 name=/standby/oradata/SBDB2/datafile/o1_mf_undotbs1_23m6ovap_.dbf
input datafile file number=00006 name=/standby/oradata/SBDB2/datafile/o1_mf_enc_25m6ovba_.dbf
channel ORA_DISK_1: starting piece 1 at 22-MAR-11
channel ORA_DISK_2: starting incremental level 1 datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00001 name=/standby/oradata/SBDB2/datafile/o1_mf_system_21m6ov92_.dbf
input datafile file number=00005 name=/standby/oradata/SBDB2/datafile/o1_mf_example_24m6ovar_.dbf
input datafile file number=00004 name=/standby/oradata/SBDB2/datafile/o1_mf_users_26m6ovba_.dbf
channel ORA_DISK_2: starting piece 1 at 22-MAR-11
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 03/22/2011 20:20:28
ORA-19648: datafile 2: incremental-start SCN equals checkpoint SCN
ORA-19640: datafile checkpoint is SCN 1249353 time 03/09/2011 05:50:27
continuing other job steps, job failed will not be re-run
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_2 channel at 03/22/2011 20:22:33
ORA-19648: datafile 1: incremental-start SCN equals checkpoint SCN
ORA-19640: datafile checkpoint is SCN 1249352 time 03/09/2011 05:50:26

经过分析该ORA-19640->ORA-19648是由11.1.0.7上的Bug引起的,MOS已经确认其为Bug 9288598:

Affects:
Product (Component)	 Oracle Server (Rdbms)
Range of versions believed to be affected	 Versions BELOW 12.1
Versions confirmed as being affected	
11.1.0.7
Platforms affected	 Generic (all / most platforms affected)
Fixed:

This issue is fixed in	
12.1 (Future Release)
11.2.0.2 (Server Patch Set)

An RMAN Backup incremental level 1 can fail with ORA-19648 / ORA-19640 if the standby database is open read only rather than just skipping the datafile.
PROBLEM:
--------
Following error occurring during incremental backup:

Starting backup at 02-DEC-2009 20:37:44
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=154 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: Veritas NetBackup for Oracle - Release 6.5 
(2008052301)
channel ORA_SBT_TAPE_1: starting incremental level 1 datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
input datafile file number=00002 
name=/data/ora_data01/KAHCB4P/KAHCB4P_sysaux_01.dbf
input datafile file number=00001 
name=/data/ora_data01/KAHCB4P/KAHCB4P_system_01.dbf
input datafile file number=00003 
name=/data/ora_data01/KAHCB4P/KAHCB4P_undo_01.dbf
input datafile file number=00004 
name=/data/ora_data01/KAHCB4P/KAHCB4P_users_01.dbf
input datafile file number=00005 
name=/data/ora_data01/KAHCB4P/KAHCB4P_tools_01.dbf
input datafile file number=00006 
name=/data/ora_data01/KAHCB4P/KAHCB4P_backup_test_01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 02-DEC-2009 20:38:01
RMAN-3009: failure of backup command on ORA_SBT_TAPE_1 channel at 12/02/2009 
20:38:02
ORA-19648: datafile 2: incremental-start SCN equals checkpoint SCN
ORA-19640: datafile checkpoint is SCN 3911695 time 11/27/2009 12:36:48
continuing other job steps, job failed will not be re-run
channel ORA_SBT_TAPE_1: starting incremental level 1 datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set

DIAGNOSTIC ANALYSIS:
--------------------
Same problem as Bug 6903819
Requested backport, but this hasn't fixed the problem.
Confirmed that the patch was installed correctly and relinked successfully.

RELEASE NOTES:
]]Backup incremental leve 1 fails with ORA-19648 and ORA-19640 when standby
]]database opened for read only.
*** 02/14/10 02:43 pm *** (ADD: Impact/Symptom->FEATURE UNUSABLE )

REDISCOVERY INFORMATION:
Backup incremental level 1 fails with ORA-19648 and the standby database is
open read-only.
WORKAROUND:
None

可以从上述Note中看到该Bug需要到11.2.0.2中才得到fix,那么在11.1.0.7上我们有什么办法能解决或者绕过该问题吗?
经过测试,我得到2种workaround的方法:
该ORA-19648错误首先可以通过在物理备库(physical standby)上停止介质恢复(MRP)进程的方式来workaround:

SQL>  alter database recover managed standby database cancel;
Database altered.

RMAN> backup incremental level 1 database;

Starting backup at 22-MAR-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=141 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=140 device type=DISK
channel ORA_DISK_1: starting incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/standby/oradata/SBDB2/datafile/o1_mf_sysaux_22m6ov92_.dbf
input datafile file number=00004 name=/standby/oradata/SBDB2/datafile/o1_mf_users_26m6ovba_.dbf
input datafile file number=00006 name=/standby/oradata/SBDB2/datafile/o1_mf_enc_25m6ovba_.dbf
channel ORA_DISK_1: starting piece 1 at 22-MAR-11
channel ORA_DISK_2: starting incremental level 1 datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00001 name=/standby/oradata/SBDB2/datafile/o1_mf_system_21m6ov92_.dbf
input datafile file number=00003 name=/standby/oradata/SBDB2/datafile/o1_mf_undotbs1_23m6ovap_.dbf
input datafile file number=00005 name=/standby/oradata/SBDB2/datafile/o1_mf_example_24m6ovar_.dbf
channel ORA_DISK_2: starting piece 1 at 22-MAR-11
channel ORA_DISK_1: finished piece 1 at 22-MAR-11
piece handle=/standby/backup/2km7suui_1_1.bak tag=TAG20110322T212538 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:33
channel ORA_DISK_2: finished piece 1 at 22-MAR-11
piece handle=/standby/backup/2lm7suv1_1_1.bak tag=TAG20110322T212538 comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:00:27
Finished backup at 22-MAR-11

Starting Control File and SPFILE Autobackup at 22-MAR-11
piece handle=/standby/backup/c-157018592-20110322-01.bak comment=NONE
Finished Control File and SPFILE Autobackup at 22-MAR-11

该ORA-19648错误也可以通过禁用fast incremental backup的块跟踪(block change tracking)特性来绕过问题,当然在可能的情况下我们更推荐使用上面那种方法,因为毕竟还可以利用到fast incremental backup特性:

SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.

SQL> select process,status from v$managed_standby;

PROCESS   STATUS
--------- ------------
ARCH	  CONNECTED
ARCH	  CONNECTED
ARCH	  CONNECTED
ARCH	  CONNECTED
MRP0	  APPLYING_LOG

SQL> select status from v$block_change_tracking;

STATUS
----------
ENABLED


SQL> alter database disable block change tracking;
Database altered.


RMAN>  backup incremental level 2 database;

Starting backup at 22-MAR-11
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: starting incremental level 2 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=/standby/oradata/SBDB2/datafile/o1_mf_sysaux_22m6ov92_.dbf
input datafile file number=00004 name=/standby/oradata/SBDB2/datafile/o1_mf_users_26m6ovba_.dbf
input datafile file number=00006 name=/standby/oradata/SBDB2/datafile/o1_mf_enc_25m6ovba_.dbf
channel ORA_DISK_1: starting piece 1 at 22-MAR-11
channel ORA_DISK_2: starting incremental level 2 datafile backup set
channel ORA_DISK_2: specifying datafile(s) in backup set
input datafile file number=00001 name=/standby/oradata/SBDB2/datafile/o1_mf_system_21m6ov92_.dbf
input datafile file number=00003 name=/standby/oradata/SBDB2/datafile/o1_mf_undotbs1_23m6ovap_.dbf
input datafile file number=00005 name=/standby/oradata/SBDB2/datafile/o1_mf_example_24m6ovar_.dbf
channel ORA_DISK_2: starting piece 1 at 22-MAR-11
channel ORA_DISK_1: finished piece 1 at 22-MAR-11
piece handle=/standby/backup/2nm7sv8d_1_1.bak tag=TAG20110322T213052 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:15
channel ORA_DISK_2: finished piece 1 at 22-MAR-11
piece handle=/standby/backup/2om7sv8s_1_1.bak tag=TAG20110322T213052 comment=NONE
channel ORA_DISK_2: backup set complete, elapsed time: 00:00:15
Finished backup at 22-MAR-11

Starting Control File and SPFILE Autobackup at 22-MAR-11
piece handle=/standby/backup/c-157018592-20110322-02.bak comment=NONE
Finished Control File and SPFILE Autobackup at 22-MAR-11

Fractured block found during backing up datafile

一套AIX上的10.2.0.3系统,在rman备份期间告警日志出现如下记录:

======================= alert log record ============================
Hex dump of (file 35, block 1087687) in trace file /oracle/product/10.2.0/admin/MS/udump/ms_ora_103548.trc
Corrupt block relative dba: 0x08d098c7 (file 35, block 1087687)
Fractured block found during backing up datafile
Data in bad block:
 type: 6 format: 2 rdba: 0x08d098c7
 last change scn: 0x0006.44443e06 seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x6d910601
 check value in block header: 0xc0b0
 computed block checksum: 0x4286
Reread of blocknum=1087687, file=/dev/vx/rdsk/oradgMS/lv_ms_DB31. found valid data

=========== trace information for process 103548 ========================
Corrupt block relative dba: 0x08d098c7 (file 35, block 1087687)
Fractured block found during backing up datafile
Data in bad block:
 type: 6 format: 2 rdba: 0x08d098c7
 last change scn: 0x0006.44443e06 seq: 0x1 flg: 0x06
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0x6d910601
 check value in block header: 0xc0b0
 computed block checksum: 0x4286
Reread of blocknum=1087687, file=/dev/vx/rdsk/oradgMS/lv_ms_DB31. found valid data

可以看到该块的type为6,下面列出了Oracle 9.2中已经存在的各种块类型:

Type Description
1 KTU UNDO HEADER
2 KTU UNDO BLOCK
3 KTT SAVE UNDO HEADER
4 KTT SAVE UNDO BLOCK
5 DATA SEGMENT HEADER
6 trans data
7 Unknown
8 Unknown
9 Unknown
10 DATA SEGMENT FREE LIST BLOCK
11 Unknown
12 DATA SEGMENT HEADER WITH FREE LIST BLOCKS
13 Compatibility segment
14 KTU UNDO HEADER W/UNLIMITED EXTENTS
15 KTT SAVE UNDO HEADER W/UNLIMITED EXTENTS
16 DATA SEGMENT HEADER – UNLIMITED
17 DATA SEGMENT HEADER WITH FREE LIST BLKS – UNLIMITED
18 EXTENT MAP BLOCK
19 Unknown
20 Unknown
21 Unknown
22 DATA SEGMENT FREE LIST BLOCK WITH FREE BLOCK COUNT
23 BITMAPPED DATA SEGMENT HEADER
24 BITMAPPED DATA SEGMENT FREELIST
25 BITMAP INDEX BLOCK
26 BITMAP BLOCK
27 LOB BLOCK
28 KTU BITMAP UNDO HEADER – LIMITED EXTENTS
29 KTFB Bitmapped File Space Header
30 KTFB Bitmapped File Space Bitmap
31 TEMP INDEX BLOCK
32 FIRST LEVEL BITMAP BLOCK
33 SECOND LEVEL BITMAP BLOCK
34 THIRD LEVEL BITMAP BLOCK
35 PAGETABLE SEGMENT HEADER
36 PAGETABLE EXTENT MAP BLOCK
37 EXTENT MAP BLOCK OF SYSTEM MANAGED UNDO SEGMENT
38 KTU SMU HEADER BLOCK
39 Unknown
40 PAGETABLE MANAGED LOB BLOCK
41 Unknown
42 Unknown
43 Unknown
44 Unknown
45 Unknown
46 Unknown
47 Unknown

表和索引的块均可能为type 6的trans data;也就是说rman在备份期间读取到该数据块,并在初次读取时发现该块断裂了(Fractured),但Fractured并不代表块就真的corrupted了;从告警日志看rman在初次读取发现该块Fractured后,又再次读取时发现数据块已经恢复正常(found valid data)。所以上述告警日志并代表所列出的数据块存在讹误,很有可能是该数据块所在数据文件在备份期间发生了剧烈的IO操作,当rman读取到该数据块时可能存储正在对其进行写的操作,所以rman在第一次读取时认为该快断裂了(Fractured);之后rman对该块进行reread发现”断裂”现象已不存在,而”Corrupt block”仅仅是一种假象;针对上述问题可以对表或索引进行进一步的analyze..validate操作以确保不存在坏块。
同时上述”Corrupt block误报”现象极有可能是因为在Rman备份期间个别数据文件的IO过于活跃所致(如频繁的dml操作),建议在磁盘活跃度低的时间段运行rman备份工作。

参考文档:

Fractured Block Messages in Alert.log During RMAN Backup of Datafile
    * fact: Oracle Server - Enterprise Edition 8
    * fact: Oracle Server - Enterprise Edition 9
    * fact: Recovery Manager (RMAN)
    * symptom: Fractured block found during backup up datafile
    * symptom: Reread of blocknum found some corrupt data
    * symptom: Analyze table validate structure cascade returns no errors
    * change: NOTE ROLE: The messages are of the form Reread of blocknum=36256, 
       file=/pdscdata/pdsclive/data1/dispatch_data_large2. dbf. 
found same corrupt data *** Corrupt block relative dba: 0xfc008dc0 (file 63, block 36288) 
Fractured block found during backing up datafile Data in bad block - 
type: 0 format: 0 rdba: 0x00000000 last change scn: 0x0000.00000000 seq: 0x0 flg: 0x00 consistency 
value in tail: 0x53494e53 check value in block header: 0x0, block checksum disabled 
spare1: 0x0, spare2: 0x0, spare3: 0x0
    * cause: RMAN backups of datafile are being performed while the datafile is involved in heavy I/O. 
RMAN reads Oracle blocks from disk. If it finds that the block is fractured, which means it is being actively used, 
it performs a reread of the block. If that fails again then the block is assumed to be corrupt. 
By identifying the object that these blocks belong to by following Handling Oracle Block Corruptions in 
Oracle7/8/8i and performing an analyze .. validate structure cascade on the object involved you can 
confirm that the object is not corrupt. 

fix:
Run the backups when the tablespace has less I/O activity.

TSM配置导致RMAN备份expired

下午协助客户做异机备份恢复测试,平台是AIX 5.3使用tsm备份。在源生产机上备份了数据库和控制文件,准备从磁带库上恢复到测试机时RMAN报找到不备份的控制文件,之后crosscheck了一把:
[Read more…]

图文详解安装NetBackup 6.5备份恢复Oracle 10g rac 数据库(修订)

我们使用Linux平台进行测试,OS版本为Oracle Enterprise Linux 5.5 x86_64:
[root@nas servsoft]# cat /etc/issue
Enterprise Linux Enterprise Linux Server release 5.5 (Carthage)
Kernel \r on an \m

Netbackup 6.0仅支持2.4内核的Linux版本,2.6内核的Linux版本(主流的包括RHEL4,5 Centos等)需要使用NBU,只能安装Netbackup 6.5或以上版本。
现在我们有三台主机: rh1(rac的2号节点),rh2(rac的1号节点),nas(NBU Server)。
首先需要安装的是Netbackup Server端软件,当然你需要用到安装介质,你可以尝试在Veritas的官方网站下载到最新的版本;获取到安装介质后,我们首先要解压它:

[root@nas netbackup]# cp NetBackup_6.5_LinuxRedhat2.6.tar.gz /tmp

[root@nas tmp]# gunzip NetBackup_6.5_LinuxRedhat2.6.tar.gz

[root@nas tmp]# tar -xvf NetBackup_6.5_LinuxRedhat2.6.tar

在进入安装前确认xinetd服务正确运行着:

[root@nas tmp]# service xinetd status

xinetd (pid  2886) is running...

[root@nas NB_65_LinuxR_x86_20070723]# ./install

Do you want to install NetBackup and Media Manager files? [y,n] (y) y

NetBackup and Media Manager are normally installed in /usr/openv.

Is it OK to install in /usr/openv? [y,n] (y) y

Reading NetBackup files from /tmp/NB_65_LinuxR_x86_20070723/linuxR_x86/anb

...................

Enter the full path name to the directory where the

appropriate installics script is located followed by

a  to continue. This script will then install

the package(s).

        OR

Enter q to stop this install and abort.

此时我们需要输入Netbackup ISC(Infrastructure Core Services)软件所在的目录,当然你也可以从Veritas官方网站下载到该软件包,尝试解压:

[root@nas tmp]# cp NetBackup_6.5_ICS_LinuxX86.tar.gz /tmp

[root@nas tmp]# cd /tmp

[root@nas tmp]# gunzip NetBackup_6.5_ICS_LinuxX86.tar.gz

[root@nas tmp]# tar -xvf NetBackup_6.5_ICS_LinuxX86.tar

则此时ISC安装介质位于/tmp/NB_65_ICS_1.4.37.0_LinuxX86下,在原终端窗口中输入该目录

Enter q to stop this install and abort.

/tmp/NB_65_ICS_1.4.37.0_LinuxX86

Installing VRTSpbx...

A NetBackup Server or Enterprise Server license key is needed

for installation to continue.

Enter license key:

继续安装,此时需要输入您所购买的License注册码;如果您没有购买该软件但仍想使用的话,

可以尝试下面一串字符:DEX6-23FJ-T92R-O4O4-O4O4-K777-7777-EPXP-3XO。

Enter license key: DEX6-23FJ-T92R-O4O4-O4O4-K777-7777-EPXP-3XO

DEX6-23FJ-T92R-O4O4-O4O4-K777-7777-EPXP-3XO:

        NetBackup Enterprise Server Base product with all the features enabled

        has been registered.

All additional keys should be added at this time.

Do you want to add additional license keys now? [y,n] (y) n

Use /usr/openv/netbackup/bin/admincmd/get_license_key

to add, delete or list license keys at a later time.

Installing NetBackup Enterprise Server version: 6.5

If this machine will be using a different network interface than the

default (nas), the name of the preferred interface should be used

as the configured server name.  If this machine will be part of a

cluster, the virtual name should be used as the configured server name.

Would you like to use "nas" as the configured

name of the NetBackup server? [y,n] (y) y

Is nas the master server? [y,n] (y) y

Do you have any media servers? [y,n] (n) n

Checking /etc/services for the needed NetBackup and Media Manager services.

Copying original /etc/services file to /etc/services.NBU_062910.14:27:41

Editing /etc/services to update NetBackup and Media Manager services.

/etc/services will be updated to add the following entries for

NetBackup/Media Manager.

bpjobd  13723/tcp       bpjobd

vmd     13701/tcp       vmd

acsd    13702/tcp       acsd

tl8cd   13705/tcp       tl8cd

tldcd   13711/tcp       tldcd

odld    13706/tcp       odld

tl4d    13713/tcp       tl4d

tshd    13715/tcp       tshd

tlmd    13716/tcp       tlmd

tlhcd   13717/tcp       tlhcd

rsmd    13719/tcp       rsmd

...................

好了Netbackup Server端软件已经在NAS主机上安装完成,接下来我们需要进一步配置备份策略。

将/usr/openv/netbackup/bin路径加入到你的用户环境变量PATH中,以方便调用相关执行文件;

并在具有X11 forwarding功能的软件中(譬如Xmanager)中输入jnbSA命令,

您可能遭遇java.lang.UnsatisfiedLinkError: /usr/openv/java/jre/lib/i386/libawt.so: libXp.so的错误,

一般是由于没有安装libXp(i386和x86_64版本的都装一下)包所导致的。

正确安装的话输入jnbSA命令可以看到以下界面:

接着我们需要定义存储单元(Storage Unit),如果你同我一样没有真实的磁带机的话那么我们可以定义普通Disk

类型的存储单元, 选择Netbackup Management->Storage -> Storage Unit,在右边分隔栏右键点击New Storage Unit,

为你的存储单元起一个名字,并输入相关存储目录:

接下来点击NetBackup Management->Policies 选项定义Oracle备份使用到的备份策略,启用Backup Policy Configuration Wizard,并选择Oracle为备份策略类型:

在客户端列表(client list)中加入需要备份2台RAC所在主机,分别为rh1,rh2;硬件与操作系统选择Linux,Redhat2.6

好了,server端的配置完成了,接下来我们安装client端软件,安装前确认你已经获得了相关安装介质,以NBU6.5举例来说你需要有:NetBackup_6.5_CLIENTS2.tar.gz和NetBackup_6.5_UnixOptions.tar.gz 分别为Client端和Oracle Agent软件。

[root@rh2 tmp]# gunzip  NetBackup_6.5_UnixOptions.tar.gz
[root@rh2 tmp]# gunzip  NetBackup_6.5_CLIENTS2.tar.gz
[root@rh2 tmp]# tar -xvf NetBackup_6.5_UnixOptions.tar
[root@rh2 tmp]# tar -xvf NetBackup_6.5_CLIENTS2.tar
[root@rh2 tmp]# cd NB_65_CLIENTS2_20070723/
[root@rh2 NB_65_CLIENTS2_20070723]# ./install

Symantec Installation Script
Copyright 1993 - 2007 Symantec Corporation, All Rights Reserved.

Installing NetBackup Client Software

NOTE:  To install NetBackup Server software, insert the appropriate
NetBackup Server cdrom.

Do you wish to continue? [y,n] (y) y
Do you want to install the NetBackup client software for this client? [y,n] (y) y

This package will install Linux/RedHat2.6 client.

This package will install NetBackup client 6.5.

Enter the name of the NetBackup server : nas

Would you like to use "rh2" as the configured
name of the NetBackup client? [y,n] (y) y
........................
File /usr/openv/tmp/install_trace.10994 contains a trace of this install.
That file can be deleted after you are sure the install was successful.

[root@rh2 tmp]# cd NB_65_UOptions_20070723/
root@rh2 NB_65_UOptions_20070723]# ./install

Symantec Installation Script
Copyright 1993 - 2007 Symantec Corporation, All Rights Reserved.

Installation Options

1 NetBackup Add-On Product Software
2 NetBackup Database Agent Software

q To quit from this script
Choose an option [default: q]: 2

**********

There are two ways to install database agent software.

1.  Remote Installation:  Loads the software on a server with
the intent of pushing database software out to affected clients.

2.  Local Installation:   Loads and installs the software only to this
local machine.

**********

Do you want to do a local installation? [y,n] (n) y

**********

NetBackup Database Agent Installation

Choose the Database Agents you wish to install
one at a time or select Install All Database Agents.

1)  NetBackup for DB2
2)  NetBackup for Informix
3)  NetBackup for Lotus Notes
4)  NetBackup for Oracle
5)  NetBackup for SAP
6)  NetBackup for Sybase

7)  Install All Database Agents

q)  Done Selecting Agents
x)  Exit from this Script

Choose an option: 4

Choose an option: q

You have chosen to install these Database Agents:

NetBackup for Oracle

Is this list correct? [y,n] (y) y

**********

Of the agents selected, the following are supported
on this platform and will be installed:

Oracle

Loading the Database Agent packages into the
/usr/openv/netbackup/dbext directory and installing.

**********

Installing NetBackup for Oracle

Installing NetBackup for Oracle...
..........................
NetBackup for Oracle installation completed.

完成NBU客户端和Netbackup for Oracle Agent安装后,我们还需要对MML介质库文件进行链接,使用dba或oinstall组账户执行/usr/openv/netbackup/bin/oracle_link文件:
[root@rh2 NB_65_UOptions_20070723]# su - maclean
[maclean@rh2 ~]$ cd /usr/openv/netbackup/bin/
[maclean@rh2 bin]$ ./oracle_link
Tue Jun 29 19:22:28 EDT 2010
All Oracle instances should be shutdown before running this script.

Please log into the Unix system as the Oracle owner for running this script

Do you want to continue? (y/n) [n]
[maclean@rh2 bin]$ echo $ORACLE_HOME
/s01/rac10g
[maclean@rh2 bin]$ ./oracle_link
Tue Jun 29 19:22:35 EDT 2010
All Oracle instances should be shutdown before running this script.

Please log into the Unix system as the Oracle owner for running this script

Do you want to continue? (y/n) [n] y

LIBOBK path: /usr/openv/netbackup/bin
ORACLE_HOME: /s01/rac10g
Oracle version: 10.2.0.5.0
Platform type: x86_64
Linking LIBOBK:
ln -s /usr/openv/netbackup/bin/libobk.so64 /s01/rac10g/lib/libobk.so
Done

接下来在rh2主机上进行备份测试:

[maclean@rh2 bin]$ rman target /

Recovery Manager: Release 10.2.0.5.0 - Production on Tue Jun 29 19:26:00 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: RACDB (DBID=720516428)

RMAN> run
2> { allocate channel c1 type sbt parms="ENV=(NB_ORA_SERV=nas,NB_ORA_POLICY=racdb,NB_ORA_CLIENT=rh2)";
3> backup current controlfile;
4> release channel c1;
5> }
RMAN> run
2> { allocate channel c1 type sbt parms="ENV=(NB_ORA_SERV=nas,NB_ORA_POLICY=racdb,NB_ORA_CLIENT=rh2)";
3> backup current controlfile;
4> release channel c1;
5> }

using target database control file instead of recovery catalog
allocated channel: c1
channel c1: sid=136 instance=racdb1 devtype=SBT_TAPE
channel c1: Veritas NetBackup for Oracle - Release 6.5 (2007072323)

Starting backup at 29-JUN-10
channel c1: starting full datafile backupset
channel c1: specifying datafile(s) in backupset
including current control file in backupset
channel c1: starting piece 1 at 29-JUN-10
channel c1: finished piece 1 at 29-JUN-10
piece handle=03lhfi11_1_1 tag=TAG20100629T192729 comment=API Version 2.0,MMS Version 5.0.0.0
channel c1: backup set complete, elapsed time: 00:00:37
Finished backup at 29-JUN-10

released channel: c1

如上所示成功备份了当前控制文件。
RMAN> run
2> {
3> allocate channel c1 type sbt parms="ENV=(NB_ORA_SERV=nas,NB_ORA_POLICY=racdb)";
4> backup archivelog all delete input;
5> release channel c1;
6> }

using target database control file instead of recovery catalog
allocated channel: c1
channel c1: sid=136 instance=racdb1 devtype=SBT_TAPE
channel c1: Veritas NetBackup for Oracle - Release 6.5 (2007072323)

Starting backup at 29-JUN-10
channel c1: starting archive log backupset
channel c1: specifying archive log(s) in backup set
input archive log thread=1 sequence=1 recid=2 stamp=722901460
input archive log thread=1 sequence=2 recid=4 stamp=722901476
input archive log thread=1 sequence=3 recid=5 stamp=722901499
input archive log thread=1 sequence=4 recid=6 stamp=722904852
input archive log thread=2 sequence=1 recid=1 stamp=722901426
input archive log thread=2 sequence=2 recid=3 stamp=722901470
input archive log thread=2 sequence=3 recid=7 stamp=722904852
channel c1: starting piece 1 at 29-JUN-10
channel c1: finished piece 1 at 29-JUN-10
piece handle=06lhfjqr_1_1 tag=TAG20100629T195819 comment=API Version 2.0,MMS Version 5.0.0.0
channel c1: backup set complete, elapsed time: 00:00:46
channel c1: deleting archive log(s)
archive log filename=/arch/1_1_722899663.dbf recid=2 stamp=722901460
archive log filename=/arch/1_2_722899663.dbf recid=4 stamp=722901476
archive log filename=/arch/1_3_722899663.dbf recid=5 stamp=722901499
archive log filename=/arch/1_4_722899663.dbf recid=6 stamp=722904852
archive log filename=/arch/2_1_722899663.dbf recid=1 stamp=722901426
archive log filename=/arch/2_2_722899663.dbf recid=3 stamp=722901470
archive log filename=/arch/2_3_722899663.dbf recid=7 stamp=722904852
Finished backup at 29-JUN-10

Starting Control File and SPFILE Autobackup at 29-JUN-10
piece handle=c-720516428-20100629-01 comment=API Version 2.0,MMS Version 5.0.0.0
Finished Control File and SPFILE Autobackup at 29-JUN-10

released channel: c1

11g Release 2 enhanced Tablespace Point In Time Recovery

11g release 2中引入了针对被dropped掉的表空间的表空间时间点恢复,这是一种十分有用的新特性。TSPITR(TablesSpace Point In Time Recovery)在10g中就能做到自动创建辅助实例以恢复表空间到某个时间点,但在10g中是无法恢复一个已经被drop掉的表空间的。如同10g中一样11g仍旧可以利用全自动的TSPITR恢复被drop的表空间;Oracle会自动创建并启动辅助实例,且仅仅还原那些恢复所需的控制文件,system,sysaux,undo表空间及目标表空间,这些工作都将在用户指定的辅助目的地’Auxiliary Destination’中完成;之后Oracle将进一步使用辅助实例recover目标表空间到指定的时间点,并将其中的数据以Data Pump传输表空间的形式倒回到原数据库当中。
接下来我们要具体测试这一新特性,我们会创建一个示例表空间并在该表空间上产生少量数据,之后我们将对数据库进行备份,drop目标示例表空间,并在RMAN中使用TSPITR的方式将已经被drop掉的表空间恢复回来。在正式drop表空间前我们当然需要留意时间点或者当时的scn号,以保证正常恢复,同时在测试时使用recovery catalog恢复目录,虽然我们同样可以不用。
[Read more…]

rman hang on SQL*Net message from client

有这样一个问题,平台为HP-UX(B.11.31 U ia64),Oracle版本为10.2.0.4 single instance,RMAN自动备份autobackup controlfile时出现hang症状,等待事件为SQL*Net message from client, 这还仅仅是使用最简单的NOCATALOG+ Disk Device的情况,没有MML层面的活动。

针对该问题对RMAN服务进程做了后台TRACE,发现stack call总是hang在_read_sys=>KERNEL内核态函数上,感觉与ORACLE的关系不大,应当是HP-UX C函数调用造成的问题,例如:

10046 trace:

PARSING IN CURSOR #3 len=278 dep=0 uid=0 oct=3 lid=0 tim=9513124502191 hv=3071086789 ad=’bd7447d0′
select sofar, context, start_time from v$session_longops where (start_time > nvl(:1, sysdate-100) or start_time = nvl(:2, sysdate+100)) and sid = :3 and serial# = :4 and opname like ‘RMAN:%’ order by start_time desc, context desc
END OF STMT
PARSE #3:c=0,e=3005,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=9513124502186
WAIT #3: nam=’SQL*Net message to client’ ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=9513124502275
WAIT #3: nam=’SQL*Net message from client’ ela= 234 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=9513124502527
BINDS #3:
kkscoacd
Bind#0
oacdty=12 mxl=07(07) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=64 off=0
kxsbbbfp=9fffffffbf3d73b0 bln=07 avl=00 flg=05
Bind#1
oacdty=12 mxl=07(07) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=0 off=8
kxsbbbfp=9fffffffbf3d73b8 bln=07 avl=00 flg=01
Bind#2
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=0 off=16
kxsbbbfp=9fffffffbf3d73c0 bln=22 avl=03 flg=01
value=1875
Bind#3
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=0 off=40
kxsbbbfp=9fffffffbf3d73d8 bln=22 avl=04 flg=01
value=50006
EXEC #3:c=10000,e=2859,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=9513124505442
FETCH #3:c=0,e=6030,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9513124511493
WAIT #3: nam=’SQL*Net message to client’ ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=9513124511560
WAIT #3: nam=’SQL*Net message from client’ ela= 56 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=9513124511690
BINDS #3:
kkscoacd
Bind#0
oacdty=12 mxl=07(07) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=64 off=0
kxsbbbfp=9fffffffbf3d6360 bln=07 avl=00 flg=05
Bind#1
oacdty=12 mxl=07(07) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=0 off=8
kxsbbbfp=9fffffffbf3d6368 bln=07 avl=00 flg=01
Bind#2
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=0 off=16
kxsbbbfp=9fffffffbf3d6370 bln=22 avl=03 flg=01
value=1875
Bind#3
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=0 off=40
kxsbbbfp=9fffffffbf3d6388 bln=22 avl=04 flg=01
value=50006
EXEC #3:c=0,e=275,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9513124512027
FETCH #3:c=10000,e=5688,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=9513124517733
WAIT #3: nam=’SQL*Net message to client’ ela= 1 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=9513124517765
WAIT #3: nam=’SQL*Net message from client’ ela= 35 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=9513124517853
STAT #3 id=1 cnt=0 pid=0 pos=1 obj=0 op=’SORT ORDER BY (cr=0 pr=0 pw=0 time=11729 us)’
STAT #3 id=2 cnt=0 pid=1 pos=1 obj=0 op=’FIXED TABLE FULL X$KSULOP (cr=0 pr=0 pw=0 time=11697 us)’
WAIT #0: nam=’SQL*Net message to client’ ela= 0 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=9513124517949
WAIT #0: nam=’SQL*Net message from client’ ela= 1629803 driver id=1650815232 #bytes=1 p3=0 obj#=-1 tim=9513126147781
BINDS #2:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=72 off=0
kxsbbbfp=9fffffffbf3d7ef8 bln=22 avl=03 flg=05
value=1782
Bind#1
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=0 off=24
kxsbbbfp=9fffffffbf3d7f10 bln=22 avl=04 flg=01
value=62996
Bind#2
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=0 off=48
kxsbbbfp=9fffffffbf3d7f28 bln=22 avl=02 flg=01
value=2

………….

RMAN DEBUG

DBGRCVMAN: resetAll
DBGRCVMAN: setRAflags kindMask=255 containerMask=15 actionMask=63
DBGRCVMAN: ENTERING setComputeRecoveryActionMasks
DBGRCVMAN: EXITING setComputeRecoveryActionMasks
DBGRCVMAN: allIncarnations is set to FALSE
DBGRCVMAN: reset transclause
DBGRCVMAN: *****BsRecCache Statistics*****
DBGRCVMAN: Cache size=0 hit=0
DBGRCVMAN: rcvRecBackupAge= 0
DBGRCVMAN: thisBackupAge= 0
DBGRCVMAN: ENTERING setRedoLogDeletionPolicy
DBGRCVMAN: setRedoLogDeletionPolicy with policy = TO NONE
DBGRCVMAN: setRedoLogDeletionPolicy with alldest = 0
DBGRCVMAN: ENTERING validateStandbyConfig1
DBGRCVMAN: policy = TO NONE
DBGRCVMAN: alldest = 0
DBGRCVMAN: EXITING validateStandbyConfig1 with target = NULLwith status = 1
DBGRCVMAN: EXITING setRedoLogDeletionPolicy with policy = TO NONE with target = NULL with bind = MANDATORY
DBGMISC: krmknmtr: the parse tree after name translation is: [13:13:53.118]
DBGMISC: EXITED krmknmtr with status Control File and SPFILE Autobackup [13:13:53.118] elapsed time [00:00:00:00.021]
DBGMISC: krmkdps: this_reset_scn=56498483682 [13:13:53.118]
DBGMISC: krmkdps: this_reset_time=02-SEP-09 [13:13:53.119]
DBGMISC: krmkdps: untilSCN= [13:13:53.119]
DBGMISC: krmkdps: untilTime= [13:13:53.119]
DBGMISC: krmkdps: getRA_completedAfter= [13:13:53.119]
DBGMISC: krmkdps: getRA_completedBefore= [13:13:53.119]
DBGMISC: krmkdps: getRA_likePattern= [13:13:53.120]
DBGMISC: krmkdps: getRA_containerMask=15 [13:13:53.120]
DBGMISC: krmkdps: getRA_actionMask=63 [13:13:53.120]
DBGMISC: krmkdps: computeRA_allRecords0 [13:13:53.120]
DBGMISC: krmkdps: computeRA_fullBackups=1 [13:13:53.120]
DBGMISC: krmkdps: allIncarnations=0 [13:13:53.120]
DBGMISC: ENTERED krmkbaut [13:13:53.121]
DBGMISC: Entering krmkgconf [13:13:53.121]

DBGSQL: EXEC SQL AT TARGET select controlfile_type ,controlfile_change# ,controlfile_sequence# ,controlfile_created ,decode(offr.records_used,0,0,((offr.last_recid-offr.records_used)+1)) into :b1,:b2,:b3,:b4,:b5 from v$database ,v$controlfile_record_section offr where offr.type=’OFFLINE RANGE’ [13:13:53.121]
DBGSQL: sqlcode=0 [13:13:53.125]
DBGSQL: :b1 = “CURRENT”
DBGSQL: :b2 = 152792315080
DBGSQL: :b3 = 7538564
DBGSQL: :b4 = “09-AUG-09″
DBGSQL: :b5 = 0
DBGMISC: krmkgconf: Configuration is ENCRYPTION FOR DATABASE [13:13:53.126]

DBGSQL: EXEC SQL AT TARGET declare first boolean ; conf# number ; begin if ( :first > 0 ) then first := TRUE ; else first := FALSE ; end if ; dbms_rcvman . getConfig ( conf# , :name:name_i , :value:value_i , first ) ; end ; [13:13:53.126]
DBGSQL: sqlcode=1403 [13:13:53.127]
DBGMISC: Function kmkgconf created the following tree: [13:13:53.128]
DBGMISC: EXIT
DBGMISC: Exiting krmkgconf [13:13:53.128]
DBGMISC: Configured NoEncrypt at db level [13:13:53.128]
DBGMISC: No Encrypt backup init(60000000) for cfile [13:13:53.128]
DBGMISC: EXITED krmkbaut [13:13:53.128] elapsed time [00:00:00:00.007]
DBGMISC: EXITED krmkomp [13:13:53.128] elapsed time [00:00:00:00.032]
DBGPLSQL: the compiled command tree is: [13:13:53.129] (krmicomp)
DBGPLSQL: 1 CMD type=Control File and SPFILE Autobackup id=1 status=NOT STARTED
DBGPLSQL: 1 STEP id=1 status=NOT STARTED
DBGPLSQL: 1 TEXTNOD = declare
DBGPLSQL: 2 TEXTNOD = ncopies number;
DBGPLSQL: 3 TEXTNOD = copyno number;
DBGPLSQL: 4 TEXTNOD = handle varchar2(512);
DBGPLSQL: 5 TEXTNOD = comment varchar2(80);
DBGPLSQL: 6 TEXTNOD = media varchar2(80);
DBGPLSQL: 7 TEXTNOD = lcfaudate date;
DBGPLSQL: 8 TEXTNOD = lsequence binary_integer;
DBGPLSQL: 9 TEXTNOD = lbautfmt varchar2(512);
DBGPLSQL: 10 TEXTNOD = rsid number;
DBGPLSQL: 11 TEXTNOD = rsts number;
DBGPLSQL: 12 TEXTNOD = p1 binary_integer := 0;
DBGPLSQL: 13 TEXTNOD = p2 binary_integer;
DBGPLSQL: 14 TEXTNOD = p3 binary_integer;
DBGPLSQL: 15 TEXTNOD = p4 binary_integer;
DBGPLSQL: 16 TEXTNOD = p5 binary_integer;
DBGPLSQL: 17 TEXTNOD = t1 varchar2(1025);
DBGPLSQL: 18 TEXTNOD = t2 varchar2(1);
DBGPLSQL: 19 TEXTNOD = t3 varchar2(1);
DBGPLSQL: 20 TEXTNOD = begin
DBGPLSQL: 21 TEXTNOD =
DBGPLSQL: 22 PRMVAL = lsequence := null;
DBGPLSQL: 23 TEXTNOD =
DBGPLSQL: 24 PRMVAL = lcfaudate := null;
DBGPLSQL: 25 TEXTNOD =
DBGPLSQL: 26 PRMVAL = lbautfmt := null;
DBGPLSQL: 27 TEXTNOD =
DBGPLSQL: 28 PRMVAL = rsid := 5708; rsts := 791817232;
DBGPLSQL: 29 TEXTNOD = setBackupParams(FALSE);
DBGPLSQL: 30 TEXTNOD = if (krmicd.getParams(1, p2, p3, p4, p5, t1, t2, t3)) then
DBGPLSQL: 31 TEXTNOD = p1 := 1;
DBGPLSQL: 32 TEXTNOD = end if;
DBGPLSQL: 33 TEXTNOD = sys.dbms_backup_restore.setRmanStatusRowId(rsid=>rsid, rsts=>rsts);
DBGPLSQL: 34 TEXTNOD = sys.dbms_backup_restore.DoAutobackup(ncopies => ncopies,
DBGPLSQL: 35 TEXTNOD = cfaudate => lcfaudate,
DBGPLSQL: 36 TEXTNOD = seq => lsequence,
DBGPLSQL: 37 TEXTNOD = format => lbautfmt,
DBGPLSQL: 38 TEXTNOD = p1 => p1,
DBGPLSQL: 39 TEXTNOD = p2 => p2,
DBGPLSQL: 40 TEXTNOD = p3 => p3,
DBGPLSQL: 41 TEXTNOD = p4 => t1);
DBGPLSQL: 42 TEXTNOD = copyno := 0;
DBGPLSQL: 43 TEXTNOD = loop
DBGPLSQL: 44 TEXTNOD = exit when copyno=ncopies;
DBGPLSQL: 45 TEXTNOD = sys.dbms_backup_restore.backupPieceCrtDupGet(copyno,
DBGPLSQL: 46 TEXTNOD = handle,
DBGPLSQL: 47 TEXTNOD = comment,
DBGPLSQL: 48 TEXTNOD = media);
DBGPLSQL: 49 TEXTNOD = if comment is null then comment := ‘NONE’; end if;
DBGPLSQL: 50 TEXTNOD = krmicd.writeMsg(8503, handle, comment);
DBGPLSQL: 51 TEXTNOD = copyno := copyno + 1;
DBGPLSQL: 52 TEXTNOD = end loop;
DBGPLSQL: 53 TEXTNOD = sys.dbms_backup_restore.setRmanStatusRowId(rsid=>0, rsts=>0);
DBGPLSQL: 54 TEXTNOD = end;
DBGMISC: executing command Control File and SPFILE Autobackup [13:13:53.138]
DBGRPC: krmxpoq: xc=6917529027645961080, action=”0000003 FINISHED66″, col_l=18, ind=0, sid=1475
DBGRPC: krmxr: xc=6917529027645961080 chid=default rpc count=3
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000021 FINISHED129″, col_l=19, ind=0, sid=1870
DBGRPC: krmxr: xc=6917529027645974080 chid=ORA_DISK_1 rpc count=21
DBGRPC: ENTERED krmqgns
DBGRPC: krmqgns: looking for work for channel default (krmqgns)
DBGRPC: krmqgns: commands remaining to be executed: (krmqgns)
DBGRPC: CMD type=Control File and SPFILE Autobackup id=1 status=NOT STARTED
DBGRPC: 1 STEP id=1 status=NOT STARTED
DBGRPC: krmqgns: no work found for channel default (krmqgns)
DBGRPC: (krmqgns)
DBGRPC: EXITED krmqgns with status 1
DBGRPC: ENTERED krmqgns
DBGRPC: krmqgns: looking for work for channel ORA_DISK_1 (krmqgns)
DBGRPC: krmqgns: commands remaining to be executed: (krmqgns)
DBGRPC: CMD type=Control File and SPFILE Autobackup id=1 status=NOT STARTED
DBGRPC: 1 STEP id=1 status=NOT STARTED
DBGRPC: krmqgns: channel ORA_DISK_1 assigned step 1 (krmqgns)
DBGRPC: (krmqgns)
DBGRPC: EXITED krmqgns with status 0
DBGRPC: krmxcic: xc=6917529027645974080 chid=ORA_DISK_1 calling peidcs
DBGRPC: krmxcis: xc=6917529027645974080 chid=ORA_DISK_1 calling pcicmp
DBGRPC: krmxr: xc=6917529027645974080 chid=ORA_DISK_1 calling peicnt
DBGMISC: ENTERED krmzgparms [13:13:53.152]
DBGMISC: Step id = 1; Code = 1 [13:13:53.152] (krmzgparms)
DBGMISC: EXITED krmzgparms with status 0 (FALSE) [13:13:53.152] elapsed time [00:00:00:00.000]
DBGMISC: ENTERED krmzgparms [13:13:53.152]
DBGMISC: Step id = 1; Code = 1 [13:13:53.152] (krmzgparms)
DBGMISC: EXITED krmzgparms with status 0 (FALSE) [13:13:53.152] elapsed time [00:00:00:00.000]
DBGRPC: krmxrpc: xc=6917529027645974080 kpurpc2 rc=0 db=target proc=DBMS_BACKUP_RESTORE.SETRMANSTATUSROWID
DBGRPC: krmxrpc: xc=6917529027645974080 chid=ORA_DISK_1 rpc count(non-blocking)=22
DBGRPC: krmxrpc: xc=6917529027645974080 RPC #22 completed immediately
DBGRPC: krmxrpc: xc=6917529027645974080 kpurpc2 rc=3123 db=target proc=DBMS_BACKUP_RESTORE.DOAUTOBACKUP
DBGRPC: krmxrpc: xc=6917529027645974080 chid=ORA_DISK_1 rpc count=23
DBGRPC: krmxrpc: xc=6917529027645974080 starting longrunning RPC #23 to target: DBMS_BACKUP_RESTORE.DOAUTOBACKUP
DBGRPC: krmxr: xc=6917529027645974080 started long running rpc
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000022 FINISHED129″, col_l=19, ind=0, sid=1870
DBGRPC: krmxr: callback returned TRUE, skipping sleep
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 1 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 2 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 4 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 8 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111″, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds
DBGRPC: krmxpoq: xc=6917529027645974080, action=”0000023 STARTED111”, col_l=18, ind=0, sid=1870
DBGRPC: krmxr: sleeping for 10 seconds

对RMAN相关进程做stack call的追踪

select action from gv$session where sid=1782 and serial#=62996 and inst_id=2

rman.log

-rw-r—– 1 oracle oinstall 56475 Aug 20 13:13 mac_ora_29364.trc
-rw-r—– 1 oracle oinstall 439863 Aug 20 13:13 mac_ora_28147.trc

mac> select spid from v$process where addr in ( select paddr from v$session where module like ‘rman%’);

SPID
————
27957
26914

mac>
mac>
mac> oradebug setospid 27957;
Oracle pid: 275, Unix process pid: 27957, image: oracle@mfs138 (TNS V1-V3)
mac> oradebug short_stack;
ksdxfstk()+48<-ksdxcb()+5776<-sspuser()+640<-<-_read_sys()+48<-_read()+224<-sntpread()+80<-ntprd()+192<-nsprecv()+736<-nsrdr()+272<-nsdo()+12512<-nsbrecv()+80<-nioqrc()+704<-opikndf2()+1216<-opitsk()+1280<-opiino()+1840<-opiodr()+2128<-opidrv()+1088<-sou2o()+336<-opimai_real()+224<-main()+368 oradebug short_stack;
ksdxfstk()+48<-ksdxcb()+5776<-sspuser()+640<-<-_read_sys()+48<-_read()+224<-sntpread()+80<-ntprd()+192<-nsprecv()+736<-nsrdr()+272<-nsdo()+12512<-nsbrecv()+80<-nioqrc()+704<-opikndf2()+1216<-opitsk()+1280<-opiino()+1840<-opiodr()+2128<-opidrv()+1088<-sou2o()+336<-opimai_real()+224<-main()+368 oradebug short_stack;
ksdxfstk()+48<-ksdxcb()+5776<-sspuser()+640<-<-_read_sys()+48<-_read()+224<-sntpread()+80<-ntprd()+192<-nsprecv()+736<-nsrdr()+272<-nsdo()+12512<-nsbrecv()+80<-nioqrc()+704<-opikndf2()+1216<-opitsk()+1280<-opiino()+1840<-opiodr()+2128<-opidrv()+1088<-sou2o()+336<-opimai_real()+224<-main()+368
mac> oradebug setospid 26914
Oracle pid: 463, Unix process pid: 26914, image: oracle@mfs138 (TNS V1-V3)
mac> oradebug short_stack
ksdxfstk()+48<-ksdxcb()+5776<-sspuser()+640<-<-_read_sys()+48<-_read()+224<-sntpread()+80<-ntprd()+192<-nsprecv()+736<-nsrdr()+272<-nsdo()+12512<-nsbrecv()+80<-nioqrc()+704<-opikndf2()+1216<-opitsk()+1280<-opiino()+1840<-opiodr()+2128<-opidrv()+1088<-sou2o()+336<-opimai_real()+224<-main()+368 oradebug short_stack
ksdxfstk()+48<-ksdxcb()+5776<-sspuser()+640<-<-_read_sys()+48<-_read()+224<-sntpread()+80<-ntprd()+192<-nsprecv()+736<-nsrdr()+272<-nsdo()+12512<-nsbrecv()+80<-nioqrc()+704<-opikndf2()+1216<-opitsk()+1280<-opiino()+1840<-opiodr()+2128<-opidrv()+1088<-sou2o()+336<-opimai_real()+224<-main()+368 oradebug short_stack
ksdxfstk()+48<-ksdxcb()+5776<-sspuser()+640<-<-_read_sys()+48<-_read()+224<-sntpread()+80<-ntprd()+192<-nsprecv()+736<-nsrdr()+272<-nsdo()+12512<-nsbrecv()+80<-nioqrc()+704<-opikndf2()+1216<-opitsk()+1280<-opiino()+1840<-opiodr()+2128<-opidrv()+1088<-sou2o()+336<-opimai_real()+224<-main()+368<-main_opd_entry()+80

oradebug dump errorstack 3;
Statement processed.

oradebug tracefile_name
/apps/oracle/admin/mac/udump/mac_ora_26914.trc

pstack 27957
27957: /apps/oracle/product/10.2.0/bin/oracle

——————————– lwpid : 5899967 ——————————-

0: c000000000405690 : _read_sys() + 0x30 (/usr/lib/hpux64/libc.so.1)
1: c000000000419f00 : _read() + 0xe0 (/usr/lib/hpux64/libc.so.1)
2: 40000000020d7ad0 : sntpread() + 0x50 (/apps/oracle/product/10.2.0/bin/oracle)
3: 40000000020d7a20 : ntprd() + 0xc0 (/apps/oracle/product/10.2.0/bin/oracle)
4: 400000000aa3b7c0 : nsprecv() + 0x2e0 (/apps/oracle/product/10.2.0/bin/oracle)
5: 4000000002307bb0 : nsrdr() + 0x110 (/apps/oracle/product/10.2.0/bin/oracle)
6: 4000000002300180 : nsdo() + 0x30e0 (/apps/oracle/product/10.2.0/bin/oracle)
7: 40000000022fcfa0 : nsbrecv() + 0x50 (/apps/oracle/product/10.2.0/bin/oracle)
8: 4000000002aff570 : nioqrc() + 0x2c0 (/apps/oracle/product/10.2.0/bin/oracle)
9: 4000000002bd3c80 : opikndf2() + 0x4c0 (/apps/oracle/product/10.2.0/bin/oracle)
10: 4000000002d9f3f0 : opitsk() + 0x500 (/apps/oracle/product/10.2.0/bin/oracle)
11: 400000000268c3f0 : opiino() + 0x730 (/apps/oracle/product/10.2.0/bin/oracle)
12: 4000000002cd6ec0 : opiodr() + 0x850 (/apps/oracle/product/10.2.0/bin/oracle)
13: 400000000260fd80 : opidrv() + 0x440 (/apps/oracle/product/10.2.0/bin/oracle)
14: 400000000260f390 : sou2o() + 0x150 (/apps/oracle/product/10.2.0/bin/oracle)
15: 40000000025fbfc0 : opimai_real() + 0xe0 (/apps/oracle/product/10.2.0/bin/oracle)
16: 400000000250c880 : main() + 0x170 (/apps/oracle/product/10.2.0/bin/oracle)
17: c000000000032f90 : main_opd_entry() + 0x50 (/usr/lib/hpux64/dld.so)

pstack 26914
26914: /apps/oracle/product/10.2.0/bin/oracle

——————————– lwpid : 5898924 ——————————-

0: c000000000405690 : _read_sys() + 0x30 (/usr/lib/hpux64/libc.so.1)
1: c000000000419f00 : _read() + 0xe0 (/usr/lib/hpux64/libc.so.1)
2: 40000000020d7ad0 : sntpread() + 0x50 (/apps/oracle/product/10.2.0/bin/oracle)
3: 40000000020d7a20 : ntprd() + 0xc0 (/apps/oracle/product/10.2.0/bin/oracle)
4: 400000000aa3b7c0 : nsprecv() + 0x2e0 (/apps/oracle/product/10.2.0/bin/oracle)
5: 4000000002307bb0 : nsrdr() + 0x110 (/apps/oracle/product/10.2.0/bin/oracle)
6: 4000000002300180 : nsdo() + 0x30e0 (/apps/oracle/product/10.2.0/bin/oracle)
7: 40000000022fcfa0 : nsbrecv() + 0x50 (/apps/oracle/product/10.2.0/bin/oracle)
8: 4000000002aff570 : nioqrc() + 0x2c0 (/apps/oracle/product/10.2.0/bin/oracle)
9: 4000000002bd3c80 : opikndf2() + 0x4c0 (/apps/oracle/product/10.2.0/bin/oracle)
10: 4000000002d9f3f0 : opitsk() + 0x500 (/apps/oracle/product/10.2.0/bin/oracle)
11: 400000000268c3f0 : opiino() + 0x730 (/apps/oracle/product/10.2.0/bin/oracle)
12: 4000000002cd6ec0 : opiodr() + 0x850 (/apps/oracle/product/10.2.0/bin/oracle)
13: 400000000260fd80 : opidrv() + 0x440 (/apps/oracle/product/10.2.0/bin/oracle)
14: 400000000260f390 : sou2o() + 0x150 (/apps/oracle/product/10.2.0/bin/oracle)
15: 40000000025fbfc0 : opimai_real() + 0xe0 (/apps/oracle/product/10.2.0/bin/oracle)
16: 400000000250c880 : main() + 0x170 (/apps/oracle/product/10.2.0/bin/oracle)
17: c000000000032f90 : main_opd_entry() + 0x50 (/usr/lib/hpux64/dld.so)

uname -a
HP-UX B.11.31 U ia64 unlimited-user license

Workaround:

没有找到直接解决该问题的方法, (从HP-UX上迁移走似乎是一种不可行的方案),可以通过configure autobackup off绕过该问题,在RMAN备份脚本中加入backup current controlfile可以起来类似的作用。

沪ICP备14014813号-2

沪公网安备 31010802001379号