重建控制文件后,各文件(datafile、control file、redo log)中scn的关系
2016-07-20 03:42
525 查看
很久之前看了一个论坛上的帖子,谈论到到本文的主题,但是我觉得帖子上说的不足以让人信服。今天想起来了,就自己动手做做实验。
实验方法:
0:backup control file to trace
1:update一张表2000条记录,commit
2:shutdown abort
3:startup nomount
4:重建控制文件
5:dump 控制文件头,数据文件头,redo文件
6:recover database
7:dump 控制文件头,数据文件头,redo文件
8:open 数据库
下面列出部分实验过程中的数据:
第5步dump文件结果(片段):
controlfile :
Controlfile Creation Timestamp 07/20/2016 02:06:03
Database checkpoint: Thread=1 scn: 0x0000.00fbb8cc --与current的redo日志的低scn一致
Controlfile Checkpointed at scn: 0x0000.00000000
控制文件记录的checkpoint process部分:
THREAD #1 - 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: 917640505 mount id: 898487178
控制文件记录的数据文件部分:
Checkpoint cnt:615 scn: 0x0000.00fbb8cd 07/20/2016 02:01:49
Stop scn: 0xffff.ffffffff 07/20/2016 02:06:03
datafile:
status:0x4 root dba:0x00000000 chkpt cnt: 615 ctl cnt:614
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.00fbb8cd 07/20/2016 02:01:49
redofile:
LOG FILE #3:
name #1: /home/oracle/app/oracle/oradata/orcl2/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x00000138 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0xa dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00fb6971
Low scn: 0x0000.00fbb8cc 07/20/2016 02:01:49
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
第7步dump文件结果(片段):
控制文件没有变化
datafile:
Checkpoint cnt:614 scn: 0x0000.00fc0810 07/20/2016 02:04:14
Stop scn: 0x0000.00fc0810 07/20/2016 02:04:14
这里可以看到数据文件scn已经恢复到一致,这里贴一段alert日志,可以看到recover database使用了redo03文件。
Wed Jul 20 02:56:20 2016
ALTER DATABASE RECOVER database
Media Recovery Start
started logmerger process
Parallel Media Recovery started with 4 slaves
Wed Jul 20 02:56:20 2016
Recovery of Online Redo Log: Thread 1 Group 3 Seq 312 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl2/redo03.log
Media Recovery Complete (orcl2)
Completed: ALTER DATABASE RECOVER database
最后一步open后的dump信息:
database open
controlfile :
Database checkpoint: Thread=1 scn: 0x0000.00fc0813
Controlfile Checkpointed at scn: 0x0000.00fc084c 07/20/2016 03:33:09
datafile:
Checkpoint cnt:617 scn: 0x0000.00fc0813 07/20/2016 03:33:08
Stop scn: 0xffff.ffffffff 07/20/2016 02:04:14
可以看到控制文件的数据库检查点与数据文件检查点一致。控制文件检查点略大,原因是因为增量检查点只更新控制文件检查点。
那么可以认为:重建控制文件后,控制文件的检查点来自于redo文件。因为recover过程中使用redo文件恢复数据文件使其一致。这是noresetlogs的情况。resetlogs的情况后续再实验。
实验方法:
0:backup control file to trace
1:update一张表2000条记录,commit
2:shutdown abort
3:startup nomount
4:重建控制文件
5:dump 控制文件头,数据文件头,redo文件
6:recover database
7:dump 控制文件头,数据文件头,redo文件
8:open 数据库
下面列出部分实验过程中的数据:
第5步dump文件结果(片段):
controlfile :
Controlfile Creation Timestamp 07/20/2016 02:06:03
Database checkpoint: Thread=1 scn: 0x0000.00fbb8cc --与current的redo日志的低scn一致
Controlfile Checkpointed at scn: 0x0000.00000000
控制文件记录的checkpoint process部分:
THREAD #1 - 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: 917640505 mount id: 898487178
控制文件记录的数据文件部分:
Checkpoint cnt:615 scn: 0x0000.00fbb8cd 07/20/2016 02:01:49
Stop scn: 0xffff.ffffffff 07/20/2016 02:06:03
datafile:
status:0x4 root dba:0x00000000 chkpt cnt: 615 ctl cnt:614
begin-hot-backup file size: 0
Checkpointed at scn: 0x0000.00fbb8cd 07/20/2016 02:01:49
redofile:
LOG FILE #3:
name #1: /home/oracle/app/oracle/oradata/orcl2/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x00000138 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0xa dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00fb6971
Low scn: 0x0000.00fbb8cc 07/20/2016 02:01:49
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
第7步dump文件结果(片段):
控制文件没有变化
datafile:
Checkpoint cnt:614 scn: 0x0000.00fc0810 07/20/2016 02:04:14
Stop scn: 0x0000.00fc0810 07/20/2016 02:04:14
这里可以看到数据文件scn已经恢复到一致,这里贴一段alert日志,可以看到recover database使用了redo03文件。
Wed Jul 20 02:56:20 2016
ALTER DATABASE RECOVER database
Media Recovery Start
started logmerger process
Parallel Media Recovery started with 4 slaves
Wed Jul 20 02:56:20 2016
Recovery of Online Redo Log: Thread 1 Group 3 Seq 312 Reading mem 0
Mem# 0: /home/oracle/app/oracle/oradata/orcl2/redo03.log
Media Recovery Complete (orcl2)
Completed: ALTER DATABASE RECOVER database
最后一步open后的dump信息:
database open
controlfile :
Database checkpoint: Thread=1 scn: 0x0000.00fc0813
Controlfile Checkpointed at scn: 0x0000.00fc084c 07/20/2016 03:33:09
datafile:
Checkpoint cnt:617 scn: 0x0000.00fc0813 07/20/2016 03:33:08
Stop scn: 0xffff.ffffffff 07/20/2016 02:04:14
可以看到控制文件的数据库检查点与数据文件检查点一致。控制文件检查点略大,原因是因为增量检查点只更新控制文件检查点。
那么可以认为:重建控制文件后,控制文件的检查点来自于redo文件。因为recover过程中使用redo文件恢复数据文件使其一致。这是noresetlogs的情况。resetlogs的情况后续再实验。
相关文章推荐
- 基于 Red Hat 的发行版 Oracle Linux 正式发布Oracle Linux 7.1
- Oracle Containers for J2EE远程安全漏洞(CVE-2014-0413)
- Oracle 10g R2不能使用EM的问题
- 表空间操作
- PreparedStatement中in子句的处理
- VMware下RedHat4.8_64位安装Oracle 10g RAC--简略脚本
- oracle sql日期比较
- 基于 Red Hat 的发行版 Oracle Linux 正式发布Oracle Linux 7.1
- OS block size和Oracle block size,查找OS Blocksize的方法
- oracle中创建数据库和表空间的几点总结
- 数据库自动备份脚本
- oracle的nvl函数的使用介绍
- 解决oracle用户连接失败的解决方法
- oracle的一些tips技巧
- Oracle 下的开发日积月累
- Oracle存储过程之数据库中获取数据实例
- Windows下ORACLE 10g完全卸载的方法分析
- Oracle 函数大全[字符串函数,数学函数,日期函数]第1/4页
- ORACLE LATERAL-SQL-INJECTION 个人见解