ITPub博客

首页 > Linux操作系统 > Linux操作系统 > oracle scn介绍

oracle scn介绍

原创 Linux操作系统 作者:oracle-admin 时间:2011-03-24 11:16:18 0 删除 编辑
上次做了下基于scn恢复delete掉的数据后,觉得应该好好理解下scn的知识,今天在网上找了下相关的介绍,参考了某些博客,在此我通过实验总结一下。

SCN是当Oracle数据库更新后,由DBMS自动维护去累积递增的一个数字。当一笔交易commit 时,LGWR会将log buffer写入redo log file,同时也会将该笔交易的SCN同步写入到redo log file内(wait-until-completed)。因此当你commit transaction时,在交易成功的讯息返回之前,LGWR必须先完整的完成上述行为之后,否则你是看不到提交成功的回应讯息。
那系统是如何产生一个最新的
select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback
  2  .get_system_change_number) from dual;

GET_SYSTEM_CHANGE_NUMBER
------------------------
SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)
---------------------------------------------------------------------------
           117947354
24-MAR-11 11.32.22.000000000 AM

也可以用函数

SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
control中有三种SCN分别为,system SCN、datafile SCN、last SCN,数据文件头中有一种SCN start SCN
system scn从视图v$database中获得,对应checkpoint_change#字段,datafile scn、last scn分别对应视图v$datafile中的checkpoint_change#,last_change#,而 start scn则从v$datafile_header中checkpoint_change#得到。
数据库在正常启动后下,system scn,datafile scn,start scn会相等,而last scn会被置于无穷大,这里为null。
正常关闭后(immediate,noraml,translate),上面四个scn会应执行full checkpoint 而相等。
当 系统在非正常关闭后,如shutdown abort,这个时候last scn依然为无穷大,那么当重新启动实例时,系统首先会比较start scn与system scn,如果一致,那么再比较start scn 与last scan是否一样大,因为是非正常关闭,这里会不一样大,那么就需要例程恢复。
如果打开数据库时发现system scn>datafile scn,那么以为着使用旧的备份数据文件,也就是需要介质恢复
如果是system scn1、正常启动时
SQL> SELECT checkpoint_change# FROM v$database;

CHECKPOINT_CHANGE#
------------------
     117866282

SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
     1        117866282
     2        117866282
     3        117866282
     4        117866282
     5        117866282
     6        117866282
     7        117866282
     8        117866282
     9        117866282
    10        117866282
    11        117866282

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
    12        117866282
    13        117866282
    14        117866282

14 rows selected.

SQL> SELECT file#, checkpoint_change#, last_change# FROM v$datafile;

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
     1        117866282
     2        117866282
     3        117866282
     4        117866282
     5        117866282
     6        117866282
     7        117866282
     8        117866282
     9        117866282
    10        117866282
    11        117866282

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
    12        117866282
    13        117866282
    14        117866282

14 rows selected.
2、正常关闭后,然后在startup mount;
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area  835104768 bytes
Fixed Size            2217952 bytes
Variable Size          624953376 bytes
Database Buffers      201326592 bytes
Redo Buffers            6606848 bytes
Database mounted.
SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
     1        117925094
     2        117925094
     3        117925094
     4        117925094
     5        117925094
     6        117925094
     7        117925094
     8        117925094
     9        117925094
    10        117925094
    11        117925094

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
    12        117925094
    13        117925094
    14        117925094

14 rows selected.

SQL> SELECT checkpoint_change# FROM v$database;

CHECKPOINT_CHANGE#
------------------
     117925094

SQL> SELECT file#, checkpoint_change#, last_change# FROM v$datafile;

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
     1        117925094     117925094
     2        117925094     117925094
     3        117925094     117925094
     4        117925094     117925094
     5        117925094     117925094
     6        117925094     117925094
     7        117925094     117925094
     8        117925094     117925094
     9        117925094     117925094
    10        117925094     117925094
    11        117925094     117925094

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
    12        117925094     117925094
    13        117925094     117925094
    14        117925094     117925094

14 rows selected.
--发现start scn=last scn,证明系统是正常关闭
SQL> alter database open;

Database altered.
3、在正常打开状态下进行事务操作
SQL> CREATE TABLE w(a number);

Table created.

SQL> INSERT INTO w VALUES(1);

1 row created.

SQL> commit;

Commit complete.

SQL> INSERT INTO w VALUES(2);

1 row created.
4、非正常关闭
SQL> shutdown abort;
ORACLE instance shut down.
5、打开到mount状态下,观看scn
SQL> startup mount;
ORACLE instance started.

Total System Global Area  835104768 bytes
Fixed Size            2217952 bytes
Variable Size          624953376 bytes
Database Buffers      201326592 bytes
Redo Buffers            6606848 bytes
Database mounted.
SQL> SELECT file#,checkpoint_change#, last_change# FROM v$datafile;

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
     1        117925097
     2        117925097
     3        117925097
     4        117925097
     5        117925097
     6        117925097
     7        117925097
     8        117925097
     9        117925097
    10        117925097
    11        117925097

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
    12        117925097
    13        117925097
    14        117925097

14 rows selected.

SQL> SELECT checkpoint_change# FROM v$database;

CHECKPOINT_CHANGE#
------------------
     117925097

SQL> SELECT file#,checkpoint_chnge# FROM v$datafile_header;
SELECT file#,checkpoint_chnge# FROM v$datafile_header
             *
ERROR at line 1:
ORA-00904: "CHECKPOINT_CHNGE#": invalid identifier


SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
     1        117925097
     2        117925097
     3        117925097
     4        117925097
     5        117925097
     6        117925097
     7        117925097
     8        117925097
     9        117925097
    10        117925097
    11        117925097

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
    12        117925097
    13        117925097
    14        117925097

14 rows selected.
--这时发现start scn 与last scn不等,last scn为无穷大,需要例程恢复
6、改变数据库状态为open,并查看该阶段运行日志
SQL> ALTER DATABASE open;

Database altered.

SQL> SELECT * FROM w;

     A
----------
     1
--发现没有提交的事务丢失。
查看日志如下:
Thu Mar 24 10:47:24 2011
ALTER DATABASE   MOUNT
Successful mount of redo thread 1, with mount id 1274403260
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Thu Mar 24 10:50:12 2011
ALTER DATABASE open
Beginning crash recovery of 1 threads    --会自动判断是否需要恢复,这里开始例程恢复
 parallel recovery started with 2 processes
Started redo scan
Completed redo scan
 read 162 KB redo, 112 data blocks need recovery
Started redo application at
 Thread 1: logseq 2635, block 491121
Recovery of Online Redo Log: Thread 1 Group 1 Seq 2635 Reading mem 0    --恢复用的在线重做日志
  Mem# 0: /u01/oradata/orcl/redo01a.log
  Mem# 1: /u01/oradata/orcl/redo01b.log
Completed redo application of 0.13MB
Completed crash recovery at                              --恢复完成
 Thread 1: logseq 2635, block 491446, scn 117945330
 112 data blocks read, 112 data blocks written, 162 redo k-bytes read
Thu Mar 24 10:50:13 2011
LGWR: STARTING ARCH PROCESSES
Thu Mar 24 10:50:13 2011
ARC0 started with pid=22, OS id=31059
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Mar 24 10:50:14 2011
ARC1 started with pid=23, OS id=31061
Thread 1 advanced to log sequence 2636 (thread open)
Thu Mar 24 10:50:15 2011
ARC2 started with pid=24, OS id=31063
Thread 1 opened at log sequence 2636
  Current log# 2 seq# 2636 mem# 0: /u01/oradata/orcl/redo02a.log

1.oracle正常运行时,control文件的SCN是个很大的数,与redo log文件、数据文件的SCN不同,正常关闭时,做完checkpoint后,三者的SCN值相同;
Biti:日志文件中scn有起始和结束2个(高低),在current log中高scn同样为无穷大。
2.当一个事务commit成功时,redo log文件中的SCN+1,当该事务所做的修改写入数据文件后,数据文件的SCN+1;
Biti:commit的时候加1,其他很多时候也会加1,只要
3.疑问:
是不是如果一个事务比较大,在事务提交前就发生redo log entries、data buffer的写入,此时断电,则数据文件、redo log文件的SCN没有+1,且相同,但控制文件SCN不同,数据库startup时发生回滚。
Biti:数据文件是由ckpt进程更新文件头的,scn不是加1,而是更新为检查点发生那时的scn,回滚是根据回滚段头的事务表状态来进行的。

4.数据写入数据文件scn不是加1而是ckpt 更新,检查点发生的时候才修改数据文件头的 检查点计数和更新scn
是不是应该这么说?:
当ckpt 更新时发生数据写入,同时修改数据文件头的 检查点计数和更新scn 。当出现其他情况下的数据写入时(如无空闲缓冲等),不发生ckpt ,但SCN会增加。
Biti:这个时候修改的是数据块但不是数据文件头,只有检查点发生的时候才更新数据文件头,也就是说只有ckpt进程更新数据文件头(oracle8以前如果没有ckpt进程就是lgwr更新),dbwr只写数据块。

BTW:看样DBWR只是些数据块,只有CKPT进程才能更新数据文件头;
5.commit的时候加一,其他很多时候也会加1,只要数据库发生了变化都会增加。
很多时候,能否举一些例子
Biti: dml一发生即使没有提交也会增加scn, job进程一样产生scn,只要对数据库中文件发生任何的改变都有可能产生scn,SCN: system change number, not system commit number .也就是系统发生变化时所产生的一个时间点

标志。不是提交的标志,只是因为提交也是系统的变化之一而已。

6.Biti:检查点的发生,跟写日志文件是没有必然联系的

系统检查点scn(v$database(checkpoint_change#))
数据文件检查点(v$datafile(checkpoint_change#))
数据文件终止scn(v$datafile(last_change#))

数据文件中存放的检查点
启动scn (v$datafile_header(checkpoint_change#)

1>系统检查点scn
当一个检查点动作完成之后,Oracle就把系统检查点的SCN存储到控制文件中。
select checkpoint_change# from v$database
2>数据文件检查点scn
当一个检查点动作完成之后,Oracle就把每个数据文件的scn单独存放在控制文件
中。
select name,checkpoint_change# from v$datafile
3>启动scn
Oracle把这个检查点的scn存储在每个数据文件的文件头中,这个值称为启动scn,
因为它用于在数据库实例启动时,检查是否需要执行数据库恢复
select name,checkpoint_change# from v$datafile_header
4>终止scn
每个数据文件的终止scn都存储在控制文件中。
select name,last_change# from v$datafile
在正常的数据库操作过程中,所有正处于联机读写模式下的数据文件的终止scn都为null.
5>在数据库运行期间的scn值
在数据库打开并运行之后,控制文件中的系统检查点、控制文件中的数据文件检查点scn
和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.

在安全关闭数据库的过程中,系统会执行一个检查点动作,这时所有数据文件的终止scn
都会设置成数据文件头中的那个启动scn的值。在数据库重新启动的时候,
Oracle将文件头中的那个启动scn与数据库文件检查点scn进行比较,
如果这两个值相互匹配,oracle接下来还要比较数据文件头中的启动scn和控制文件
中数据文件的终止scn。如果这两个值也一致,就意味着所有数据块多已经提交,所有
对数据库的修改都没有在关闭数据库的过程中丢失,因此这次启动数据库的过程
也不需要任何恢复操作,此时数据库就可以打开了。当所有的数据库都打开之后,
存储在控制文件中的数据文件终止scn的值再次被更改为null,
这表示数据文件已经打开并能够正常使用了。

引用:http://hi.baidu.com/zty598416146/blog/item/48bc8edfba8fa64595ee3764.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23502881/viewspace-690348/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-03-23

  • 博文量
    22
  • 访问量
    105102