一聚教程网:一个值得你收藏的教程网站

热门教程

oralce数据库恢复过程详解

时间:2022-06-29 09:46:33 编辑:袖梨 来源:一聚教程网

某客户的数据库出现崩溃,无法正常启动,经过我的远程紧急救援恢复之后,恢复正常,如下是简单的处理过程,供参考!

在open数据库时,发现无法打开,报错如下:


SMON: enabling cache recovery
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.1d2be1e6):
select ctime, mtime, stime from obj$ where obj# = :1
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_20559.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7_3286610060$" too small
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_20559.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7_3286610060$" too small
Error 704 happened during db open, shutting down database
USER (ospid: 20559): terminating the instance due to error 704
Instance terminated by USER, pid = 20559
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (20559) as a result of ORA-1092
Mon Sep 28 21:03:41 2015
ORA-1092 : opitsk aborting process
 
对于上述错误,其实是比较常见的,大致上可以理解为Oracle在open 时需要进行一致性读的处理,却发现回滚段内容已经被覆盖,进而报错ora-01555,导致无法open。我们也可以发现,报错的SQL预计是Oracle 递归SQL,这是数据库在open时必须执行的SQL,很明显,该SQL无法执行成功,那么也就导致数据库无法正常打开。
处理思路很简单,首先我们要做的事情是通过10046 trace跟踪确认数据库在执行该SQL时访问了那些block,进而报错的?
通过oracle 10046 trace得到如下的内容:


=====================
PARSING IN CURSOR #4 len=70 dep=1 uid=0 oct=3 lid=0 tim=1443431294544569 hv=3377894161 ad='122f55f28' sqlid='32d4jrb4pd4sj'
select charsetid, charsetform from col$  where obj# = :1 and col# = :2
END OF STMT
PARSE #4:c=1000,e=226,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1443431294544569
=====================
PARSING IN CURSOR #5 len=52 dep=1 uid=0 oct=3 lid=0 tim=1443431294545488 hv=429618617 ad='121b18860' sqlid='4krwuz0ctqxdt'
select ctime, mtime, stime from obj$ where obj# = :1
END OF STMT
PARSE #5:c=0,e=217,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1443431294545488
BINDS #5:
 Bind#0
  oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
  oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp=7f1daaac1700  bln=22  avl=02  flg=05
  value=20
EXEC #5:c=0,e=421,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=1218588913,tim=1443431294545986
WAIT #5: nam='db file sequential read' ela= 9 file#=1 block#=337 blocks=1 obj#=36 tim=1443431294546059
WAIT #5: nam='db file sequential read' ela= 6 file#=1 block#=338 blocks=1 obj#=36 tim=1443431294546117
WAIT #5: nam='db file sequential read' ela= 6 file#=1 block#=241 blocks=1 obj#=18 tim=1443431294546166
=====================
PARSING IN CURSOR #6 len=142 dep=2 uid=0 oct=3 lid=0 tim=1443431294546497 hv=361892850 ad='123eebc48' sqlid='7bd391hat42zk'
select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1
END OF STMT
PARSE #6:c=0,e=292,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,plh=0,tim=1443431294546496
BINDS #6:
 Bind#0
  oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
  oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp=7f1daaa2ebb8  bln=22  avl=02  flg=05
  value=10
EXEC #6:c=0,e=473,p=0,cr=0,cu=0,mis=1,r=0,dep=2,og=3,plh=906473769,tim=1443431294547061
WAIT #6: nam='db file sequential read' ela= 9 file#=1 block#=321 blocks=1 obj#=34 tim=1443431294547113
WAIT #6: nam='db file sequential read' ela= 7 file#=1 block#=225 blocks=1 obj#=15 tim=1443431294547169
FETCH #6:c=0,e=116,p=2,cr=2,cu=0,mis=0,r=1,dep=2,og=3,plh=906473769,tim=1443431294547196
STAT #6 id=1 cnt=1 pid=0 pos=1 obj=15 op='TABLE ACCESS BY INDEX ROWID UNDO$ (cr=2 pr=2 pw=0 time=0 us)'
STAT #6 id=2 cnt=1 pid=1 pos=1 obj=34 op='INDEX UNIQUE SCAN I_UNDO1 (cr=1 pr=1 pw=0 time=0 us)'
CLOSE #6:c=0,e=5,dep=2,type=0,tim=1443431294547246
WAIT #5: nam='db file sequential read' ela= 11 file#=3 block#=7344 blocks=1 obj#=0 tim=1443431294547284
=====================
PARSING IN CURSOR #6 len=142 dep=2 uid=0 oct=3 lid=0 tim=1443431294547411 hv=361892850 ad='123eebc48' sqlid='7bd391hat42zk'
select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1
END OF STMT
PARSE #6:c=0,e=22,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=3,plh=906473769,tim=1443431294547411
BINDS #6:
 Bind#0
  oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
  oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp=7f1daaa2ebb8  bln=22  avl=02  flg=05
  value=7
EXEC #6:c=0,e=47,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=3,plh=906473769,tim=1443431294547514
FETCH #6:c=0,e=95,p=0,cr=2,cu=0,mis=0,r=1,dep=2,og=3,plh=906473769,tim=1443431294547630
STAT #6 id=1 cnt=1 pid=0 pos=1 obj=15 op='TABLE ACCESS BY INDEX ROWID UNDO$ (cr=2 pr=0 pw=0 time=0 us)'
STAT #6 id=2 cnt=1 pid=1 pos=1 obj=34 op='INDEX UNIQUE SCAN I_UNDO1 (cr=1 pr=0 pw=0 time=0 us)'
CLOSE #6:c=0,e=4,dep=2,type=0,tim=1443431294547678
WAIT #5: nam='db file sequential read' ela= 8 file#=3 block#=552 blocks=1 obj#=0 tim=1443431294547710
FETCH #5:c=1999,e=1938,p=7,cr=9,cu=0,mis=0,r=0,dep=1,og=4,plh=1218588913,tim=1443431294547945
STAT #5 id=1 cnt=0 pid=0 pos=1 obj=18 op='TABLE ACCESS BY INDEX ROWID OBJ$ (cr=0 pr=0 pw=0 time=0 us)'
STAT #5 id=2 cnt=1 pid=1 pos=1 obj=36 op='INDEX RANGE SCAN I_OBJ1 (cr=2 pr=2 pw=0 time=0 us)'
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7_3286610060$" too small
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7_3286610060$" too small
 
 
根据我们常见的处理思路,将上述访问的block中的事务状态改成8000之后,发现仍然报错。我们仔细来对比下block中的scn与报错的scn信息,发现了其中的关系,如下:

BBED> p ktbbh
struct ktbbh, 48 bytes                      @20
。。。。。
   struct ktbbhitl[0], 24 bytes             @44
      struct ktbitxid, 8 bytes              @44
         ub2 kxidusn                        @44       0x000a
         ub2 kxidslt                        @46       0x0019
         ub4 kxidsqn                        @48       0x00071d47
      struct ktbituba, 8 bytes              @52
         ub4 kubadba                        @52       0x00c01cb0
         ub2 kubaseq                        @56       0x2c95
         ub1 kubarec                        @58       0x15
      ub2 ktbitflg                          @60       0x8000 (KTBFCOM)
      union _ktbitun, 2 bytes               @62
         b2 _ktbitfsc                       @62       0
         ub2 _ktbitwrp                      @62       0x0000
      ub4 ktbitbas                          @64       0x1d2be6ea
 
 
将上述的scn bas值转换为10 进制后为:489416426,我们再来查询下数据库文件头的scn:

SQL> select file#,checkpoint_change# from v$datafile_header;
 
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1          489415139
         2          489415139
         3          489415139
         4          489415139

我们不难发现,报错的block中的scn比数据文件头的scn要大,其次也比前面报错的的scn:1d2be1e6 (转换后为 489415142)要大一些。这说明什么?
当数据库处于running的情况之下,Oracle 不知道下一个时间点事务什么时间结束,因此也不知道下一个时间点的scn是多少,所以其对应的scn 往往要比当前的大一些。当数据库crash后,加上undo损坏,那么很容易出现这样的情况。
所以,我们这要做的事情,很简单,将上述scn 修改得比报错的scn小一些(或者等于),则可以解决该错误。


SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [2662], [0], [489415146], [0],
[489416426], [4194545], [], [], [], [], [], []
Process ID: 22192
Session ID: 66 Serial number: 1

修改之后,再次启动数据库,发现报错发生了变化,查看此时的alert log,发现信息如下:


Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /data/oradata/orcl/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Sep 28 21:17:17 2015
SMON: enabling cache recovery
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_22192.trc  (incident=128561):
ORA-00600: internal error code, arguments: [2662], [0], [489415146], [0], [489416426], [4194545], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_128561/orcl_ora_22192_i128561.trc
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_22192.trc:
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [2662], [0], [489415146], [0], [489416426], [4194545], [], [], [], [], [], []
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_22192.trc:
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [2662], [0], [489415146], [0], [489416426], [4194545], [], [], [], [], [], []
Error 704 happened during db open, shutting down database
USER (ospid: 22192): terminating the instance due to error 704
Instance terminated by USER, pid = 22192
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (22192) as a result of ORA-1092

很明显,这是scn的问题,要处理也很简单,通过推进scn即可解决掉。通过推进scn之后,发现打开数据库时,还是报错了,但是错误再一次发生了改变:


*********************************************************************
Database Characterset is ZHS16GBK
No Resource Manager plan active
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1144] [PC:0x2297740, kgegpa()+40] [flags: 0x0, count: 1]
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1144] [PC:0x229596B, kgebse()+279] [flags: 0x2, count: 2]
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1144] [PC:0x229596B, kgebse()+279] [flags: 0x2, count: 2]
Mon Sep 28 21:25:01 2015
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_p000_23736.trc  (incident=132169):
ORA-00600: internal error code, arguments: [6006], [1], [], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_132169/orcl_p000_23736_i132169.trc
Mon Sep 28 21:25:03 2015
PMON (ospid: 23582): terminating the instance due to error 397
Instance terminated by PMON, pid = 23582

这次过程处理起来就很简单了,通过屏蔽undo就可以很容易解决掉。其次在后续的恢复过程中,还遇到了如下的一些错误:


Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j004_27644.trc  (incident=137080):
ORA-00600: internal error code, arguments: [4097], [9], [7], [63399], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_137080/orcl_j004_27644_i137080.trc
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j004_27644.trc  (incident=137081):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [4097], [9], [7], [63399], [], [], [], [], [], [], [], []
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_137081/orcl_j004_27644_i137081.trc
Mon Sep 28 22:00:10 2015
Trace dumping is performing id=[cdmp_20150928220010]
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j004_27644.trc  (incident=137082):
ORA-00600: internal error code, arguments: [4097], [9], [7], [63399], [], [], [], [], [], [], [], []
ORA-06512: at "SYS.DBMS_STATS", line 26392
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_137082/orcl_j004_27644_i137082.trc
Trace dumping is performing id=[cdmp_20150928220011]

这部分错误处理起来都相对简单的多。【4097】也是回滚段的问题,在处理undo时,可以一并处理之。我博客之前就写了该错误的处理案例,这里不再累述。这种恢复场景,最后打开数据库后一般还会有如下的错误:


Mon Sep 28 22:10:57 2015
Sweep [inc][141951]: completed
Sweep [inc2][141951]: completed
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_29255.trc  (incident=141952):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Trace dumping is performing id=[cdmp_20150928221057]
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_29255.trc  (incident=141953):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_29255.trc  (incident=141954):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_29255.trc  (incident=142843):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_29255.trc  (incident=142844):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_29255.trc  (incident=142845):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_29255.trc  (incident=142846):
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Mon Sep 28 22:11:00 2015

最后这个错误处理起来十分简单,通过重建index即可解决上述错误,对于大量的 日志,建议直接grep,然后重建相关index即可。


[root@db2 ~]# cat /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_132169/orcl_p000_23736_i132169.trc |grep obj:
        dbwrid: 0 obj: 5777 objn: 5777 tsn: 1 afn: 2 hint: f
 seg/obj: 0x1691  csc: 0x00.1d2be90f  itc: 2  flg: E  typ: 2 - INDEX
  dbwrid: 0 obj: 37 objn: 37 tsn: 0 afn: 1 hint: f
 。。。。。
 seg/obj: 0x1692  csc: 0x00.1d2be8f1  itc: 2  flg: E  typ: 1 - DATA
  dbwrid: 1 obj: 36 objn: 36 tsn: 0 afn: 1 hint: f
 seg/obj: 0x24  csc: 0x00.1ca4ab69  itc: 1  flg: -  typ: 2 - INDEX
  dbwrid: 0 obj: 36 objn: 36 tsn: 0 afn: 1 hint: f
 seg/obj: 0x24  csc: 0x00.16f03  itc: 2  flg: -  typ: 2 - INDEX
  dbwrid: 0 obj: 5777 objn: 5777 tsn: 1 afn: 2 hint: f
 seg/obj: 0x1691  csc: 0x00.1d2be90f  itc: 2  flg: E  typ: 2 - INDEX
  dbwrid: 1 obj: 5777 objn: 5777 tsn: 1 afn: 2 hint: f
 seg/obj: 0x1691  csc: 0x00.1d2baac0  itc: 1  flg: E  typ: 2 - INDEX

最后通过mos的脚本来check 数据字典是否存在异常,这样就可以确保数据库起码可以正常运行。如下是检测结果:


SQL> exec hcheck.full
H.Check Version 9i+/hc3.50
---------------------------------------
Catalog Version 11.2.0.1.0 (1102000100)
---------------------------------------
 
                                   Catalog       Fixed
Procedure Name                     Version    Vs Release      Run
------------------------------ ... ---------- -- ----------   ---
.- SynLastDDLTim               ... 1102000100 >  1001000200 : n/a
.- LobNotInObj                 ... 1102000100 >  1000000200 : n/a
.- MissingOIDOnObjCol          ... 1102000100 <=  *All Rel* : Ok
.- SourceNotInObj              ... 1102000100 >  1002000100 : n/a
.- IndIndparMismatch           ... 1102000100 <= 1102000100 : Ok
.- InvCorrAudit                ... 1102000100 <= 1102000100 : Ok
.- OversizedFiles              ... 1102000100 <=  *All Rel* : Ok
.- TinyFiles                   ... 1102000100 >   900010000 : n/a
.- PoorDefaultStorage          ... 1102000100 <=  *All Rel* : Ok
.- PoorStorage                 ... 1102000100 <=  *All Rel* : Ok
.- MissTabSubPart              ... 1102000100 >   900010000 : n/a
.- PartSubPartMismatch         ... 1102000100 <= 1102000100 : Ok
.- TabPartCountMismatch        ... 1102000100 <=  *All Rel* : Ok
.- OrphanedTabComPart          ... 1102000100 >   900010000 : n/a
.- ZeroTabSubPart              ... 1102000100 >   902000100 : n/a
.- MissingSum$                 ... 1102000100 <=  *All Rel* : Ok
.- MissingDir$                 ... 1102000100 <=  *All Rel* : Ok
.- DuplicateDataobj            ... 1102000100 <=  *All Rel* : Ok
.- ObjSynMissing               ... 1102000100 <=  *All Rel* : Ok
.- ObjSeqMissing               ... 1102000100 <=  *All Rel* : Ok
.- OrphanedUndo                ... 1102000100 <=  *All Rel* : Ok
.- OrphanedIndex               ... 1102000100 <=  *All Rel* : Ok
.- OrphanedIndexPartition      ... 1102000100 <=  *All Rel* : Ok
.- OrphanedIndexSubPartition   ... 1102000100 <=  *All Rel* : Ok
.- OrphanedTable               ... 1102000100 <=  *All Rel* : Ok
.- OrphanedTablePartition      ... 1102000100 <=  *All Rel* : Ok
.- OrphanedTableSubPartition   ... 1102000100 <=  *All Rel* : Ok
.- MissingPartCol              ... 1102000100 <=  *All Rel* : Ok
.- OrphanedSeg$                ... 1102000100 <=  *All Rel* : Ok
.- OrphanedIndPartObj#         ... 1102000100 >  1101000600 : n/a
.- DuplicateBlockUse           ... 1102000100 <=  *All Rel* : Ok
.- HighObjectIds               ... 1102000100 >   801060000 : n/a
.- PQsequence                  ... 1102000100 >   800060000 : n/a
.- TruncatedCluster            ... 1102000100 >   801070000 : n/a
.- FetUet                      ... 1102000100 <=  *All Rel* : Ok
.- Uet0Check                   ... 1102000100 <=  *All Rel* : Ok
.- ExtentlessSeg               ... 1102000100 <=  *All Rel* : Ok
.- SeglessUET                  ... 1102000100 <=  *All Rel* : Ok
.- BadInd$                     ... 1102000100 <=  *All Rel* : Ok
.- BadTab$                     ... 1102000100 <=  *All Rel* : Ok
.- BadIcolDepCnt               ... 1102000100 >  1101000700 : n/a
.- WarnIcolDep                 ... 1102000100 >  1101000700 : n/a
.- OnlineRebuild$              ... 1102000100 <=  *All Rel* : Ok
.- DropForceType               ... 1102000100 >  1001000200 : n/a
.- TrgAfterUpgrade             ... 1102000100 <=  *All Rel* : Ok
.- FailedInitJVMRun            ... 1102000100 <=  *All Rel* : Ok
.- TypeReusedAfterDrop         ... 1102000100 >   900010000 : n/a
.- Idgen1$TTS                  ... 1102000100 >   900010000 : n/a
.- DroppedFuncIdx              ... 1102000100 >   902000100 : n/a
.- BadOwner                    ... 1102000100 >   900010000 : n/a
.- UpgCheckc0801070            ... 1102000100 <=  *All Rel* : Ok
.- BadPublicObjects            ... 1102000100 <=  *All Rel* : Ok
.- BadSegFreelist              ... 1102000100 <=  *All Rel* : Ok
.- BadCol#                     ... 1102000100 >  1001000200 : n/a
.- BadDepends                  ... 1102000100 <=  *All Rel* : Ok
.- CheckDual                   ... 1102000100 <=  *All Rel* : Ok
.- ObjectNames                 ... 1102000100 <=  *All Rel* : Ok
.- BadCboHiLo                  ... 1102000100 <=  *All Rel* : Ok
.- ChkIotTs                    ... 1102000100 <=  *All Rel* : Ok
.- NoSegmentIndex              ... 1102000100 <=  *All Rel* : Ok
.- BadNextObject               ... 1102000100 <=  *All Rel* : Ok
.- OrphanIndopt                ... 1102000100 >   902000800 : n/a
.- UpgFlgBitTmp                ... 1102000100 >  1001000100 : n/a
.- RenCharView                 ... 1102000100 >  1001000100 : n/a
.- Upg9iTab$                   ... 1102000100 >   902000400 : n/a
.- Upg9iTsInd                  ... 1102000100 >   902000500 : n/a
.- Upg10gInd$                  ... 1102000100 >  1002000000 : n/a
.- DroppedROTS                 ... 1102000100 <=  *All Rel* : Ok
.- ChrLenSmtcs                 ... 1102000100 >  1101000600 : n/a
.- FilBlkZero                  ... 1102000100 <=  *All Rel* : Ok
.- DbmsSchemaCopy              ... 1102000100 <=  *All Rel* : Ok
 
Found 0 potential problem(s) and 0 warning(s)
 
PL/SQL procedure successfully completed.
我们可以发现,至少通过Oracle mos的脚本检查之后,没有数据字典有问题。

热门栏目