oralce数据库恢复过程详解

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

在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的脚本检查之后,没有数据字典有问题。

时间: 2024-11-05 12:19:14

oralce数据库恢复过程详解的相关文章

CentOS下DB2数据库安装过程详解_DB2

最近因为工作需要在学习DB2数据库,本教程讲解DB2数据库在inux下的安装步骤. 安装前请查看DB2版本和许可证说明来增加了解,先弄明白改安装什么版本,这里我用的是最新的Express-C版本,这个版本是提供给个人学习用的版本. 管理客户端从v9.7版本之后就不再带有控制中心了,而是使用 Data Studio Client. Linux版本: Linux版本下的DB2数据库采用的官方免费版本,操作系统用的CentOS6.2. 安装过程: 1.下载:db2_v101_linuxia32_exp

mysql的XA事务恢复过程详解_Mysql

mysql数据库开机报错: InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 100224 12:24:20 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace

DBA_Oracle Startup / Shutdown启动和关闭过程详解(概念)(对数据库进行各种维护操作)_oracle

一.摘要 Oracle数据库的完整启动过程是分步骤完成的,包含以下3个步骤: 启动实例-->加载数据库-->打开数据库 因为Oracle数据库启动过程中不同的阶段可以对数据库进行不同的维护操作,对应我们不同的需求,所以就需不同的模式启动数据库. 1. Oracle启动需要经历四个状态:SHUTDOWN .NOMOUNT .MOUNT .OPEN 2. Oracle关闭的四种方式:Normal, Immediate, Transactional, Abort 3. 启动和关闭过程详解   二.数

SQL语句执行过程详解

SQL语句执行过程详解一条sql,plsql的执行到底是怎样执行的呢?一.SQL语句执行原理:第一步:客户端把语句发给服务器端执行当我们在客户端执行 select 语句时,客户端会把这条 SQL 语句发送给服务器端,让服务器端的进程来处理这语句.也就是说,Oracle 客户端是不会做任何的操作,他的主要任务就是把客户端产生的一些 SQL 语句发送给服务器端.虽然在客户端也有一个数据库进程,但是,这个进程的作用跟服务器上的进程作用事不相同的.服务器上的数据库进程才会对SQL 语句进行相关的处理.不

新浪微博OAuth认证和储存的主要过程详解

 本文给大家介绍的是参考Twitter的认证过程实现的新浪微博OAuth认证和储存的主要过程详解     网上很多关于OAuth的文章,但是包括sina本身都都没有详细的的介绍,包括验证过程和验证后数据的储存,所以参考了Twitter的认证过程写下一些详细的注释代码. 在我们开始前,我们先建立一张数据库来保存用户信息,下面是一个基本的 Mysql 的例子: ? 1 2 3 4 5 6 7 8 9 CREATE TABLE `oauth_users` ( `id` INT(10) UNSIGNED

yum安装CDH5.5 hive、impala的过程详解_Linux

一.安装hive 组件安排如下: 172.16.57.75 bd-ops-test-75 mysql-server 172.16.57.77 bd-ops-test-77 Hiveserver2 HiveMetaStore 1.安装hive 在77上安装hive: # yum install hive hive-metastore hive-server2 hive-jdbc hive-hbase -y 在其他节点上可以安装客户端: # yum install hive hive-server2

Android 定时任务过程详解_Android

在Android开发中,通过以下三种方法定时执行任务: 一.采用Handler与线程的sleep(long)方法(不建议使用,java的实现方式) 二.采用Handler的postDelayed(Runnable, long)方法(最简单的android实现) 三.采用Handler与timer及TimerTask结合的方法(比较多的任务时建议使用) android里有时需要定时循环执行某段代码,或者需要在某个时间点执行某段代码,这个需求大家第一时间会想到Timer对象,没错,不过我们还有更好的

Android 定时任务过程详解

在Android开发中,通过以下三种方法定时执行任务: 一.采用Handler与线程的sleep(long)方法(不建议使用,java的实现方式) 二.采用Handler的postDelayed(Runnable, long)方法(最简单的android实现) 三.采用Handler与timer及TimerTask结合的方法(比较多的任务时建议使用) android里有时需要定时循环执行某段代码,或者需要在某个时间点执行某段代码,这个需求大家第一时间会想到Timer对象,没错,不过我们还有更好的

Win 2000系统引导过程详解(2)

过程|详解 表一则列出了在系统引导的不同阶段所引用的文件. 表一 在这里,我们暂不讨论Windows 2000操作系统的内部工作机制,以下通过图文结合的方式,简要给大家说明在这五个阶段,操作系统都在干些什么,那些程序发挥了作用. 第一步,预引导阶段,过程如图二所示,首先包括了系统加电自检,这个过程完成硬件设备的枚举和配置.其次计算机BIOS确定引导设备的位置,加载并运行Master Boot Record(MBR)主引导区内容(如lilo等).然后扫描分区表,定位活动分区,并将活动分区上的引导扇