几个scn和恢复的细节

最新推荐文章于 2021-04-15 22:49:36 发布

cuiheji0772

最新推荐文章于 2021-04-15 22:49:36 发布

阅读量85

点赞数

前些天在看电视剧《无懈可击之高手如林》，终于速度看完了，该静下心来看看oracle了，不然年底估计完成不了俺的4本book的阅读了，这些天陆陆续续接触了rman备份的原理，其中肯定不免得接触了oracle中的scn，查阅资料当然主要是eygle的两本书的说法和itpub上网友整理的一些scn的资料。

当一个checkpoint发生时有哪些scn了

1 发生检查点，记录系统的检查点scn。

Select name,checkpoint_change# from v$datafile

2 发生检查点对数据文件的checkpoint scn更新，也就是数据文件checkpoint scn，存储在控制文件中

Select name，checkpoint_change# from v$datafile

3 数据文件头部又存储了启动的checkpoint scn

Select name，checkpoint_change# from v$datafile_header

4 数据文件的stop scn，同时存储在控制文件和数据文件头部中

Select name,last_change# from v$datafile

数据文件头部视图v$datafile_header不存在stop scn的信息，但是通过转储数据文件头部信息是可以看出stop scn的

5 还有日志文件中low scn和next scn，也就是此日志文件记录的在某一区域的scn的redo log。

关于上述的scn，有点多，有点繁琐，理解起来并不舒服，个人结合资料：

系统检查点scn的发生alter system checkpoint肯定会对所有的数据文件的checkpoint scn同步，数据文件也发生checkpoint，然后数据文件头部启动checkpoint scn也会同步更新，一般都是相同的，除非是数据文件或者控制文件一个被替换了，因为控制文件中记录的数据文件checkpoint scn就是数据文件头部启动checkpoint scn，每次发生检查点都会让他们同步更新。

在这里根据eygel的深入浅出记载，个人的测试也如下：

首先当前数据库是open状态

1 首先转储控制文件

Alter session set events ‘immediate trace name controlf level 8’

内容如下：

DATA FILE #1:

(name #19) D:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBF

creation size=0 block size=8192 status=0xe head=19 tail=19 dup=1

tablespace 0, index=1 krfil=1 prev_file=0

unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

Checkpoint cnt:1179 scn: 0x0000.583aac2d 08/16/2011 11:11:04

Stop scn: 0xffff.ffffffff 08/16/2011 00:32:14

Creation Checkpointed at scn: 0x0000.00000009 03/14/2008 18:46:45

thread:0 rba:(0x0.0.0)

DATA FILE #2:

Checkpoint cnt ：956 scn ：0x0000.583a99b7

转储控制文件，可以查看具体有checkpoint cnt和checkpoint scn，checkpoint cnt也就是发生检查点的计数。每发生一次checkpoint时，checkpoint cnt就会增加1，此时checkpoint cnt 和scn注意查看了。

2 让数据文件1出于热备份状态

Alter tablespace system begin backup

Alter session set events ‘immiedate trace name controlf level 8’

内容如下：

DATA FILE #1:

(name #19) D:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBF

creation size=0 block size=8192 status=0xe head=19 tail=19 dup=1

tablespace 0, index=1 krfil=1 prev_file=0

unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

Checkpoint cnt:1180 scn: 0x0000.583ab466 08/16/2011 12:14:35

Stop scn: 0xffff.ffffffff 08/16/2011 00:32:14

DATA FILE #2

Checkpoint cnt:956 scn ：0x0000.583a99b7

此时表空间热备时，会发生表空间一次检查点。此时checkpoint cnt会自增1，数据文件checkpoint scn也会更新，但是系统的checkpoint scn并没有改变。系统完全checkpoint会更新数据文件和控制文件的checkpoint scn，但是单个表空间的checkpoint，并没有带来整个系统的checkpoint scn的变化。

3 我们显示的调用一次完全检查点

Alter system checkpoint

Alter session set events ‘immiedate trace name controlf level 8’

内容如下：

DATA FILE #1:

(name #19) D:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBF

creation size=0 block size=8192 status=0xe head=19 tail=19 dup=1

tablespace 0, index=1 krfil=1 prev_file=0

unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

Checkpoint cnt:1181 scn: 0x0000.583ab466 08/16/2011 12:14:35

Stop scn: 0xffff.ffffffff 08/16/2011 00:32:14

Creation Checkpointed at scn: 0x0000.00000009 03/14/2008 18:46:45

DATA FILE #2:

Checkpoint cnt:957 scn:0x0000.583ab49d

此时查看数据文件的检查点信息发现Select name,checkpoint_change# from v$datafile和v$datafile_header 此时相应的各数据文件的cnt都会增加，别的表空间数据文件都会随着系统的checkpoint同步checkpoint scn。但是system表空间的checkpoint scn没有变化，只是cnt增加1，因为出于热备期间，数据文件头部的checkpoint scn会被冻结。

4 结束热备份状态

Alter tablesapce users end backup

结束热备状态，此时此时又发生了一次检查点，数据文件头部信息checkpoint scn的冻结被取消并同步。

但是这个检查点是数据文件的检查点事件，观察数据文件2此时的cnt和scn都没有变化。

内容如下：

DATA FILE #1:

(name #19) D:ORACLEPRODUCT10.2.0ORADATATESTSYSTEM01.DBF

creation size=0 block size=8192 status=0xe head=19 tail=19 dup=1

tablespace 0, index=1 krfil=1 prev_file=0

unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

Checkpoint cnt:1182 scn: 0x0000.583ab49d 08/16/2011 12:16:23

Stop scn: 0xffff.ffffffff 08/16/2011 00:32:14

Creation Checkpointed at scn: 0x0000.00000009 03/14/2008 18:46:45

thread:0 rba:(0x0.0.0)

DATA FILE #2：

Checkpoint cnt ：957 scn:：0x0000.583ab49d

啰嗦了这么多，控制文件和日志文件中还记录的low scn和next scn，也就是此日志文件记录的在scn的某一段内的redo log的信息，

Alter session set events ‘immediate trace name controlf level 8’

内容如下：

LOG FILE #1:

WAIT #4: nam='control file sequential read' ela= 301 file#=0 block#=30 blocks=1 obj#=43 tim=13193545386

(name #8) D:ORACLEPRODUCT10.2.0ORADATATESTREDO01.LOG

Thread 1 redo log links: forward: 2 backward: 0

siz: 0x19000 seq: 0x0000000f hws: 0x5 bsz: 512 nab: 0xf044 flg: 0x1 dup: 1

Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.583975fc

Low scn: 0x0000.583a2aa8 08/15/2011 22:50:57

Next scn: 0x0000.583a99b6 08/16/2011 09:26:20

LOG FILE #2:

(name #7) D:ORACLEPRODUCT10.2.0ORADATATESTREDO02.LOG

Thread 1 redo log links: forward: 3 backward: 1

siz: 0x19000 seq: 0x00000010 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1

Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.583a2aa8

Low scn: 0x0000.583a99b6 08/16/2011 09:26:20

Next scn: 0xffff.ffffffff 01/01/1988 00:00:00

此时log file #2是当前联机日志文件，因为next scn未知。

Scn和恢复

Scn是oracle内部的时间机制，checkpoint scn主要是为了实例恢复的时间的减少，

数据库在从mount到open状态时

1首先查看控制文件记录的各数据文件的ckeckpoint cnt和各数据文件的checkpoint cnt是否一致。

2 再次查看控制文件记录的各数据文件头的开始checkpoint scn和控制文件结束checkpoint scn是否一致，因为在数据库正常shutdown时，数据库会发生一次正常检查点，控制文件中的各数据文件stop scn和数据文件头部开始scn一致。如果上述两个条件达不到，则需要进行数据库恢复。

回忆数据库的nomount mount open三个状态，nomount需要spfile，Mount需要controlfile，open需要数据文件和控制文件。

涉及到scn的是controfile和redo log ，datafile。

前段时间一致不是很理解恢复的细节，看过一段时间的os备份恢复和rman恢复，有点想法了。

open状态时：

alter tablespace system begin backup

正常关闭数据库。

Shutdown immediate

系统进行checkoint

Startup

由于在热备份状态system数据文件头部scn 被冻结，当重新启动数据库尝试到open状态时，无法成功，由于stop scn并没有同步成数据文件头部启动scn，此时无法打开数据库，只能到mount状态，需要介质恢复datafile 1.

recover datafile 1

利用controlfile和redo log或者archive log来通过scn机制恢复datafile 1的启动scn和stop scn同控制文件原先记录的达到一致。