dump 验证实例恢复的起点和终点
2013-11-20 22:06
281 查看
什么时候会产生实例恢复呢？当你数据库服务器异常断电，重启数据库就会发生实例恢复。实例恢复是由数据库自动完成的，无须DBA的干涉。当然这里有个前提条件：数据文件、
在线日志文件、控制文件不得有损坏。
我们用实验来分析一下实例恢复的整个过程吧！
1、在关闭数据库前，我们先看一下几个检查点的SCN
--System checkpoint SCN (存在于控制文件)
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
856021
--控制文件中保存的数据库检查点SCN号实际上在所有数据文件头部中最小的检查点SCN
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 856021
2 856021
3 856021
4 856021
5 856021
--控制文件中保存的数据文件检查点SCN:当一个检查点动作完成之后，Oracle就把每个数据文件的scn单独存放在控制文件中
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 856021
2 856021
3 856021
4 856021
5 856021
--每个数据文件的文件头中的检查点SCN
select name,last_change# from v$datafile
STOP SCN(存在于控制文件)
最后一类SCN,End SCN他也是记录在控制文件当中，每一个所记录的数据文件头都有一个对应的End SCN,这个End SCN一定是存在于控制文件当中。这个SCN存在的绝对意义主要是用
来去验证数据库启动过程中是否需要做instance recovery。我们可以通过
那么其实在数据库正常运行的情况下，对于read/write的online 数据文件这个SCN号为#FFFFFF(NULL).
2、此命令可以模拟异常断电
SQL> shutdown abort;
ORACLE instance shut down.
这三个检查点的SCN一致，接下来模拟异常断电，重启机器
3、监控告警日志
Tue Oct 31 17:51:47 2000
Shutting down instance (abort)
License high water mark = 2
Instance terminated by USER, pid = 2350
4、数据库启动到MOUNT状
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
856021
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 856021
2 856021
3 856021
4 856021
5 856021
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 856021
2 856021
3 856021
4 856021
5 856021
SQL> col name format a30
SQL> select name,last_change# from v$datafile;
NAME LAST_CHANGE#
---------------------------------------- ------------
/oradata/june/june/system01.dbf
/oradata/june/june/sysaux01.dbf
/oradata/june/june/undotbs01.dbf
/oradata/june/june/users01.dbf
/oradata/june/june/example01.dbf
发现与异常断电前的检查点的SCN一致，这里一致无须介质恢复。
先不着急open数据库，我们做一些dump
alter session set events 'immediate trace name CONTROLF level 12';
***************************************************************************
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
11/07/2000 12:05:40
DB Name "JUNE"
Database flags = 0x00404000 0x00001000
Controlfile Creation Timestamp 11/07/2000 12:05:41
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.000b8338 Resetlogs Timestamp 11/07/2000 12:05:44
Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 08/13/2009 23:00:48
Redo Version: compatible=0xb200000
#Data files = 5, #Online files = 5
Database checkpoint: Thread=1 scn: 0x0000.000d0fd5 ----转换为10进制是856021
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 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 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
Max log members = 3, Max data members = 1
Arch list: Head=0, Tail=0, Force scn: 0x0000.000cc0ccscn: 0x0000.000b8338
Activation ID: 307689684
Controlfile Checkpointed at scn: 0x0000.000d34a8 11/07/2000 20:29:02
thread:0 rba:(0x0.0.0)
enabled threads: 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 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
234 DATA FILE RECORDS
235 ***************************************************************************
236 (size = 520, compat size = 520, section max = 100, section in-use = 5,
237 last-recid= 64, old-recno = 0, last-recno = 0)
238 (extent = 1, blkno = 11, numrecs = 100)
239 DATA FILE #1:
240 name #7: /oradata/june/june/system01.dbf
241 creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
242 tablespace 0, index=1 krfil=1 prev_file=0
243 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
244 Checkpoint cnt:91 scn: 0x0000.000d0fd5 11/07/2000 15:19:36
245 Stop scn: 0xffff.ffffffff 11/07/2000 15:17:39
Stop scn: 0xffff.ffffffff 11/07/2000 15:17:39
--结束的SCN填无穷大，说明是异常关机的，重启数据库必须做实例恢复
从dump 控制文件查看
***************************************************************************
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:37
low cache rba:(0xa.12a30.0) on disk rba:(0xa.12ab4.0)
on disk scn: 0x0000.000d3522 11/07/2000 20:31:01
resetlogs scn: 0x0000.000b8338 11/07/2000 12:05:44
heartbeat: 413022655 mount id: 307684709
THREAD #2 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #3 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #4 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #5 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #6 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #7 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #8 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
low cache rba:(0xa.12a30.0) on disk rba:(0xa.12ab4.0)
on disk scn: 0x0000.000d3522 11/07/2000 20:31:01
-- low cache rba:(0xa.12a30.0)实例恢复的起点：10号日志，第76336个块，第0个字节
--on disk rba:(0xa.12ab4.0)：实例恢复的终点：10号日志，第76468个块，第0个字节
-- Database checkpoint: Thread=1 scn: 0x0000.000d0fd5 ----转换为10进制是856021 scn恢复起点
--on disk scn: 0x0000.000d3522 11/07/2000 20:31:01 ---865570 scn恢复终点
low cache rba:就是CKPT记录的DBWR写出的进度
on disk rba:就是LGWR的写进度
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
read 66 KB redo, 37 data blocks need recovery
Started redo application at
Thread 1: logseq 10, block 76336
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
Mem# 0: /oradata/june/june/redo01.log
Completed redo application of 0.06MB
Completed crash recovery at
Thread 1: logseq 10, block 76468, scn 885570
37 data blocks read, 37 data blocks written, 66 redo k-bytes read
实例恢复的起点和终点；
checkpoint position 到 end of redo log
10、最后总结一下实例恢复
(1)数据文件、在线日志文件、控制文件不得有损坏
(2)数据库自动恢复，无需DBA干涉
(3)恢复只需在线日志文件，无需归档日志
(4)数据库在open的时候开始实例恢复
实际上我做的这个实例恢实验的还没有写完整， 还有最后一步回滚！这个就留给你们思考！
实例恢复三步：前滚--->打开库---->后滚(也叫回滚)
在线日志文件、控制文件不得有损坏。
我们用实验来分析一下实例恢复的整个过程吧！
1、在关闭数据库前，我们先看一下几个检查点的SCN
--System checkpoint SCN (存在于控制文件)
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
856021
--控制文件中保存的数据库检查点SCN号实际上在所有数据文件头部中最小的检查点SCN
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 856021
2 856021
3 856021
4 856021
5 856021
--控制文件中保存的数据文件检查点SCN:当一个检查点动作完成之后，Oracle就把每个数据文件的scn单独存放在控制文件中
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 856021
2 856021
3 856021
4 856021
5 856021
--每个数据文件的文件头中的检查点SCN
select name,last_change# from v$datafile
STOP SCN(存在于控制文件)
最后一类SCN,End SCN他也是记录在控制文件当中，每一个所记录的数据文件头都有一个对应的End SCN,这个End SCN一定是存在于控制文件当中。这个SCN存在的绝对意义主要是用
来去验证数据库启动过程中是否需要做instance recovery。我们可以通过
那么其实在数据库正常运行的情况下，对于read/write的online 数据文件这个SCN号为#FFFFFF(NULL).
2、此命令可以模拟异常断电
SQL> shutdown abort;
ORACLE instance shut down.
这三个检查点的SCN一致，接下来模拟异常断电，重启机器
3、监控告警日志
Tue Oct 31 17:51:47 2000
Shutting down instance (abort)
License high water mark = 2
Instance terminated by USER, pid = 2350
4、数据库启动到MOUNT状
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
856021
SQL> select file#,checkpoint_change# from v$datafile;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 856021
2 856021
3 856021
4 856021
5 856021
SQL> select file#,checkpoint_change# from v$datafile_header;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 856021
2 856021
3 856021
4 856021
5 856021
SQL> col name format a30
SQL> select name,last_change# from v$datafile;
NAME LAST_CHANGE#
---------------------------------------- ------------
/oradata/june/june/system01.dbf
/oradata/june/june/sysaux01.dbf
/oradata/june/june/undotbs01.dbf
/oradata/june/june/users01.dbf
/oradata/june/june/example01.dbf
发现与异常断电前的检查点的SCN一致，这里一致无须介质恢复。
先不着急open数据库，我们做一些dump
alter session set events 'immediate trace name CONTROLF level 12';
***************************************************************************
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
11/07/2000 12:05:40
DB Name "JUNE"
Database flags = 0x00404000 0x00001000
Controlfile Creation Timestamp 11/07/2000 12:05:41
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.000b8338 Resetlogs Timestamp 11/07/2000 12:05:44
Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 08/13/2009 23:00:48
Redo Version: compatible=0xb200000
#Data files = 5, #Online files = 5
Database checkpoint: Thread=1 scn: 0x0000.000d0fd5 ----转换为10进制是856021
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
enabled threads: 01000000 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 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
Max log members = 3, Max data members = 1
Arch list: Head=0, Tail=0, Force scn: 0x0000.000cc0ccscn: 0x0000.000b8338
Activation ID: 307689684
Controlfile Checkpointed at scn: 0x0000.000d34a8 11/07/2000 20:29:02
thread:0 rba:(0x0.0.0)
enabled threads: 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 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
234 DATA FILE RECORDS
235 ***************************************************************************
236 (size = 520, compat size = 520, section max = 100, section in-use = 5,
237 last-recid= 64, old-recno = 0, last-recno = 0)
238 (extent = 1, blkno = 11, numrecs = 100)
239 DATA FILE #1:
240 name #7: /oradata/june/june/system01.dbf
241 creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
242 tablespace 0, index=1 krfil=1 prev_file=0
243 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
244 Checkpoint cnt:91 scn: 0x0000.000d0fd5 11/07/2000 15:19:36
245 Stop scn: 0xffff.ffffffff 11/07/2000 15:17:39
Stop scn: 0xffff.ffffffff 11/07/2000 15:17:39
--结束的SCN填无穷大，说明是异常关机的，重启数据库必须做实例恢复
从dump 控制文件查看
***************************************************************************
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:37
low cache rba:(0xa.12a30.0) on disk rba:(0xa.12ab4.0)
on disk scn: 0x0000.000d3522 11/07/2000 20:31:01
resetlogs scn: 0x0000.000b8338 11/07/2000 12:05:44
heartbeat: 413022655 mount id: 307684709
THREAD #2 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #3 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #4 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #5 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #6 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #7 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
THREAD #8 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
on disk scn: 0x0000.00000000 01/01/1988 00:00:00
resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
heartbeat: 0 mount id: 0
low cache rba:(0xa.12a30.0) on disk rba:(0xa.12ab4.0)
on disk scn: 0x0000.000d3522 11/07/2000 20:31:01
-- low cache rba:(0xa.12a30.0)实例恢复的起点：10号日志，第76336个块，第0个字节
--on disk rba:(0xa.12ab4.0)：实例恢复的终点：10号日志，第76468个块，第0个字节
-- Database checkpoint: Thread=1 scn: 0x0000.000d0fd5 ----转换为10进制是856021 scn恢复起点
--on disk scn: 0x0000.000d3522 11/07/2000 20:31:01 ---865570 scn恢复终点
low cache rba:就是CKPT记录的DBWR写出的进度
on disk rba:就是LGWR的写进度
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
read 66 KB redo, 37 data blocks need recovery
Started redo application at
Thread 1: logseq 10, block 76336
Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
Mem# 0: /oradata/june/june/redo01.log
Completed redo application of 0.06MB
Completed crash recovery at
Thread 1: logseq 10, block 76468, scn 885570
37 data blocks read, 37 data blocks written, 66 redo k-bytes read
实例恢复的起点和终点；
checkpoint position 到 end of redo log
10、最后总结一下实例恢复
(1)数据文件、在线日志文件、控制文件不得有损坏
(2)数据库自动恢复，无需DBA干涉
(3)恢复只需在线日志文件，无需归档日志
(4)数据库在open的时候开始实例恢复
实际上我做的这个实例恢实验的还没有写完整， 还有最后一步回滚！这个就留给你们思考！
实例恢复三步：前滚--->打开库---->后滚(也叫回滚)
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- dump 验证实例恢复的起点和终点
- 用event 10013验证实例恢复的终点不是On-Disk RBA？
- oracle 实例恢复前滚与前滚的起点与终点
- 用event 10013验证实例恢复的终点？
- 用event 10013验证实例恢复的终点
- 用event 10013验证实例恢复的终点
- ORACLE实例恢复过程详细分析--使用dump、BBED等多种工具结合分析
- ORACLE实例恢复过程详细分析--使用dump、BBED等多种工具结合分析
- ORACLE实例恢复过程详细分析--使用dump、BBED等多种工具结合分析
- 崩溃恢复的起点和终点 崔老师
- postgresql pg_dump,pg_restore实例详解
- php生成验证码与验证码验证完整实例
- Struts2自定义拦截器实例—登陆权限验证
- Oracle实例恢复的原理
- 迷宫问题1-在给定的迷宫中判断是否存在一条路径从起点到终点
- Struts2实现生成动态验证码并验证实例代码
- jQuery使用$.ajax进行即时验证实例详解
- 以申购单为实例，讲解Jquery动态删减行,新增行添加鼠标事件，子窗口与父窗口传值，自动计算金额，及输入值的验证，前台数据批量提交到后台action
- Asp.Mvc 2.0用户客户端验证实例讲解（3）
- Oracle 实例恢复