透析SCN

  控制文件

  1.System Checkpoint(v$database :checkpoint_change#)
  2.Datafile Checkpoint(v$datafile :checkpoint_change#)
  3.Stop SCN(#v$datafile :last_change)
   正常 datafile 在 read-write mode 运作下,last_change#一定是null
  数据文件
  1.Start SCN(v$datafile_header :checkpoint_change#)
   无论redo log中的数据是否影响到该数据文件都会跟新SCN

查看当前系统的SCN     

1.1查看系统当前 SCN

1 SQL> select dbms_flashback.get_system_change_number from dual;
2 
3 GET_SYSTEM_CHANGE_NUMBER
4 ------------------------
5                   686706
6 
7 SQL> 

  可以理解,这里返回的 SCN,也是目前 redo log file 最新的 SCN 纪录。因为 commit 后的交易才会有 SCN,而一旦 commit 就会立刻写入 redo log file 中。

1.2查看系统保存的System Checkpoint SCN

1 SQL> select checkpoint_change# from v$database;
2 
3 CHECKPOINT_CHANGE#
4 ------------------
5             686465
6 
7 SQL>

1.3查看Datafile Checkpoint SCN

 1 SQL> select file#,CHECKPOINT_CHANGE# from v$datafile;
 2 
 3      FILE# CHECKPOINT_CHANGE#
 4 ---------- ------------------
 5          1             686465
 6          2             686465
 7          3             686465
 8          4             686465
 9          5             686465
10          6             686465
11          7             686465
12 
13 7 rows selected.
14 
15 SQL> 

1.4查看Start SCN

 1 SQL> select file#,CHECKPOINT_CHANGE# from v$datafile_header;
 2 
 3      FILE# CHECKPOINT_CHANGE#
 4 ---------- ------------------
 5          1             686465
 6          2             686465
 7          3             686465
 8          4             686465
 9          5             686465
10          6             686465
11          7             686465
12 
13 7 rows selected.
14 
15 SQL> 

1.5查看redo log中的SCN

1 SQL> select GROUP#, STATUS, FIRST_CHANGE# from v$log; 
2 
3     GROUP# STATUS           FIRST_CHANGE#
4 ---------- ---------------- -------------
5          1 INACTIVE                653969
6          2 CURRENT                 686464
7          3 INACTIVE                633672
8 SQL>

   GROUP1 中保存的为scn号653969686464的数据(其中数据已经写入数据文件)
   GROUP2 中保存的为scn号686464686706的数据
   GROUP3 中保存的为scn号633672653969的数据(其中数据已经写入数据文件)
   若此时执行 shutdown abort 并重启,执行 crash recovery 时,使用的在线重做日志文件为 group2中的SCN

  为什么储存在 control file 中要分为两个地方(system checkpoint scn, datafile checkpoint scn)。当把一个 tbs 设为 read-only 时,他的 scn 会冻结停止,此时 datafile checkpoint scn 是不会再递增改变的,但是整体的 system checkpoint scn 却仍然会不断递增前进。所以这是为什么需要分别在两个地方储存 SCN。

  当 clean shutdown 时,checkpoint 会进行,并且此时 datafile 的 stop scn 和 start scn 会相同。等我们打开数据库时,oracle 会检查 datafile header 中的 start scn 和存于 control file 中的 datafile 的 scn是否相同,如果相同,接着检查 start scn 和 stop scn 是否相同,如果仍然相同,数据库会正常启动,否则就需要 recovery….等到数据库 open 后,储存在 control file 中的 stop scn 就会恢复为 null 值,此时表示 datafile 是 open 在正常模式下。

2.1干净关闭oracle:

1 SQL> shutdown immediate
2 Database closed.
3 Database dismounted.
4 ORACLE instance shut down.
5 SQL> 

2.2在mount的状态下查看:

 1 SQL> startup mount
 2 ORACLE instance started.
 3 
 4 Total System Global Area  289406976 bytes
 5 Fixed Size                  1279820 bytes
 6 Variable Size              92276916 bytes
 7 Database Buffers          192937984 bytes
 8 Redo Buffers                2912256 bytes
 9 Database mounted.
10 SQL>

2.3查看Start SCN

 1 SQL> select file#,CHECKPOINT_CHANGE# from v$datafile_header;
 2 
 3      FILE# CHECKPOINT_CHANGE#
 4 ---------- ------------------
 5          1             665470
 6          2             665470
 7          3             665470
 8          4             665470
 9          5             665470
10          6             665470
11          7             665470
12 
13 7 rows selected.
14 
15 SQL>

2.4 查看Datafile Checkpoint SCN

 1 SQL> select file#,checkpoint_change# from v$datafile;
 2 
 3      FILE# CHECKPOINT_CHANGE#
 4 ---------- ------------------
 5          1             665470
 6          2             665470
 7          3             665470
 8          4             665470
 9          5             665470
10          6             665470
11          7             665470
12 
13 7 rows selected.
14 
15 SQL> 

  检查start scn和Datafile Checkpoint相同,则继续比较。

2.5 查看Stop SCN

 1 SQL> select file#,last_change# from v$datafile;
 2 
 3      FILE# LAST_CHANGE#
 4 ---------- ------------
 5          1       665470
 6          2       665470
 7          3       665470
 8          4       665470
 9          5       665470
10          6       665470
11          7       665470
12 
13 7 rows selected.
14 
15 SQL> 

  检查start scn和stop scn相同,则数据库可以正常启动,无需recovery

  如果不正常 shutdown(shutdown abort),则 mount 数据库后,会发现 stop scn 并不等于其它位置的scn,而是等于 null。这表示 oracle 在 shutdown 时没有进行 checkpoint,下次启动必须进行 crash recovery。

3.1故障关闭

1 SQL> shutdown abort
2 ORACLE instance shut down.
3 SQL>

3.2启到mount

 1 SQL> startup mount
 2 ORACLE instance started.
 3 
 4 Total System Global Area  289406976 bytes
 5 Fixed Size                  1279820 bytes
 6 Variable Size              92276916 bytes
 7 Database Buffers          192937984 bytes
 8 Redo Buffers                2912256 bytes
 9 Database mounted.
10 SQL> 

3.3查看Start SCN

 1 SQL> select file#,CHECKPOINT_CHANGE# from v$datafile_header;
 2 
 3      FILE# CHECKPOINT_CHANGE#
 4 ---------- ------------------
 5          1             665471
 6          2             665471
 7          3             665471
 8          4             665471
 9          5             665471
10          6             665471
11          7             665471
12 
13 7 rows selected.
14 
15 SQL>

3.4查看Datafile Checkpoint SCN

 1 SQL> select file#,checkpoint_change# from v$datafile;
 2 
 3      FILE# CHECKPOINT_CHANGE#
 4 ---------- ------------------
 5          1             665471
 6          2             665471
 7          3             665471
 8          4             665471
 9          5             665471
10          6             665471
11          7             665471
12 
13 7 rows selected.
14 
15 SQL> 

  检查start scn和Datafile Checkpoint相同,则继续比较。

3.5查看Stop SCN

 1 SQL> select file#,last_change# from v$datafile;
 2 
 3      FILE# LAST_CHANGE#
 4 ---------- ------------
 5          1
 6          2
 7          3
 8          4
 9          5
10          6
11          7
12 
13 7 rows selected.
14 
15 SQL> 

  检查start scn和stop scn不同,需要recovery

原文地址:https://www.cnblogs.com/polestar/p/2877957.html