Oracle数据库中几种常见的SCN

shenzhang

　　控制文件中的SCN
　　数据文件头的SCN
　　数据块中的SCN
　　日志文件头中的SCN
　　事务SCN
　　内存中的SCN
　　一 控制文件中的SCN
　　1.1 数据库SCN
　　数据库SCN表示最近一次全量checkpoint操作时的SCN
　　SQL> select checkpoint_change# from v$database;
　　CHECKPOINT_CHANGE#   
　　------------------   
　　1744125   
　　dump控制文件语法
　　alter session set events 'immediate trace name controlf level n';
　　1 文件头信息
　　2 level 1+数据库信息+检查点信息
　　3 level 2+可重用节信息
　　10 level 3
　　dump控制文件获取到的数据库SCN为0x00000000001a9cfd，转换为十进制为1744125
　　*** 2017-02-15T10:59:12.367312+08:00   
　　DUMP OF CONTROL FILES, Seq # 1522 = 0x5f2   
　　V10 STYLE FILE HEADER:   
　　Compatibility Vsn = 203423744=0xc200000   

　　Db>
　　Activation>
　　Control Seq=1522=0x5f2, File>　　File Number=0, Blksiz=16384, File Type=1 CONTROL   
　　***************************************************************************   
　　DATABASE ENTRY   
　　***************************************************************************   

　　(size = 316, compat>　　last-recid= 0, old-recno = 0, last-recno = 0)   
　　(extent = 1, blkno = 1, numrecs = 1)   
　　02/14/2017 10:28:13   
　　DB Name "ORCL"   
　　Database flags = 0x00404000 0x00001000 0x00000080   
　　Controlfile Creation Timestamp  02/14/2017 10:28:13   
　　Incmplt recovery scn: 0x0000000000000000   
　　Resetlogs scn: 0x0000000000157e2e Resetlogs Timestamp  02/14/2017 10:28:15   
　　Prior resetlogs scn: 0x0000000000000001 Prior resetlogs Timestamp  01/26/2017 13:52:29   
　　Redo Version: compatible=0xc200000   
　　#Data files = 4, #Online files = 4   
　　Database checkpoint: Thread=1 scn: 0x00000000001a9cfd   
　　Threads: #Enabled=1, #Open=1, Head=1, Tail=1   
　　1.2 数据文件SCN
　　通过 V$DATAFILE查询保存在控制文件中的数据文件SCN
  

• 数据文件头SCN
  

　　v$datafile.checkpoint_change#
　　SQL> select checkpoint_change# from v$datafile;
　　CHECKPOINT_CHANGE#   
　　------------------   
　　1744125   
　　1744125   
　　1744125   
　　1744125   
  

• STOP SCN
  

　　数据库打开或异常关闭，该值为空或无穷大0xffffffffffffffff
　　SQL> select last_change# from v$datafile;
　　LAST_CHANGE#   
　　------------
　　SQL>   
  

• CREATION SCN
  

　　数据文件创建时的SCN
　　SQL> select creation_change# from v$datafile;
　　CREATION_CHANGE#   
　　----------------   
　　7   
　　4665   
　　1406609   
　　29999   
　　从dump的控制文件中获取到数据文件的SCN。一下为1号数据文件在控制文件中的SCN
　　***************************************************************************   
　　DATA FILE RECORDS   
　　***************************************************************************   

　　(size = 520, compat>　　last-recid= 18, old-recno = 0, last-recno = 0)   
　　(extent = 1, blkno = 11, numrecs = 100)   
　　DATA FILE #1:     
　　name #6: /oradata/ORCL/datafile/o1_mf_system_db4tp1o9_.dbf   

　　creation>　　pdb_id 0, tablespace 0, index=2 krfil=1 prev_file_in_ts=0 prev_file_in_pdb=0   
　　unrecoverable scn: 0x0000000000000000 01/01/1988 00:00:00   
　　Checkpoint cnt:61 scn: 0x00000000001a9cfd 02/15/2017 10:20:16     
　　Stop scn: 0xffffffffffffffff 02/15/2017 10:17:27      
　　Creation Checkpointed at scn:  0x0000000000000007 01/26/2017 13:52:40      
　　thread:0 rba:(0x0.0.0)   
　　1.3 CHECKPOINT PROGRESS RECORDS中的SCN
　　CHECKPOINT PROGRESS RECORDS中的on disk scn表示当前系统最新rba对应的scn，有ckpt进程每3秒更新一次。
　　如果数据库异常宕机，那么crash recovery时，服务器进程至少要应用到该scn为止
　　dump控制文件后能获得CHECKPOINT PROGRESS RECORDS中的SCN，如下所示
　　***************************************************************************   
　　CHECKPOINT PROGRESS RECORDS   
　　***************************************************************************   

　　(size = 8180, compat>　　last-recid= 0, old-recno = 0, last-recno = 0)   
　　(extent = 1, blkno = 2, numrecs = 11)   
　　THREAD #1 - status:0x2 flags:0x0 dirty:6   
　　low cache rba:(0x4.853.0) on disk rba:(0x4.86b.0)   
　　on disk scn: 0x00000000001aa3f5 02/15/2017 10:58:28     
　　resetlogs scn: 0x0000000000157e2e 02/14/2017 10:28:15   

　　heartbeat: 936031722 mount>　　二 数据文件头中的SCN
　　v$datafile_header
  

• creation_change#
  

　　数据文件创建时的SCN
　　SQL> select file#,creation_change# from v$datafile_header;
　　FILE# CREATION_CHANGE#   
　　---------- ----------------   
　　1          7   
　　3           4665   
　　4        1406609   
　　7          29999   
  

• checkpoint_change#
  

　　表示数据文件头当前的SCN
　　SQL> select file#,checkpoint_change# from v$datafile_header;
　　FILE# CHECKPOINT_CHANGE#   
　　---------- ------------------   
　　1          1744125   
　　3          1744125   
　　4          1744125   
　　7          1744125   
  

• resetlogs_change#
  

　　表示数据库以resetlogs方式打开时的SCN 在dump的控制文件中也能看到Resetlogs scn: 0x0000000000157e2e
　　SQL> select file#,resetlogs_change# from v$datafile_header;
　　FILE# RESETLOGS_CHANGE#   
　　---------- -----------------   
　　1         1408558   
　　3         1408558   
　　4         1408558   
　　7         1408558   
  

• change#
  

　　表示数据文件冻结时的SCN。在做数据文件在线热备时，常用begin backup命令将数据文件头冻结，表明chang#这个点开始对数据文件进行备份
　　SQL> select file#,change# from v$backup;
　　FILE#    CHANGE#   
　　---------- ----------   
　　1        0   
　　3        0   
　　4        0   
　　7        0

　　SQL>>
　　Database>　　SQL> select file#,change# from v$backup;
　　FILE#    CHANGE#   
　　---------- ----------   
　　1    1957900   
　　3    1957900   
　　4    1957900   
　　7    1957900   
　　以上SCN可以通过dump数据文件头来进行观察 0x00000000001de00c转换为十进制就是1957900
　　SQL> oradebug setmypid   
　　Statement processed.   
　　SQL> oradebug tracefile_name   
　　/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_24591.trc   
　　SQL> alter session set events 'immediate trace name file_hdrs level 3';

　　Session>　　V10 STYLE FILE HEADER:   
　　Compatibility Vsn = 203423744=0xc200000   

　　Db>
　　Activation>
　　Control Seq=1740=0x6cc, File>　　File Number=1, Blksiz=8192, File Type=3 DATA   

　　Tablespace #0 - SYSTEM >　　Creation   at   scn: 0x0000000000000007 01/26/2017 13:52:40   
　　Backup taken at scn: 0x00000000001de00c 02/15/2017 13:56:00 thread:1     
　　reset logs count:0x37c90b3f scn: 0x0000000000157e2e   
　　prev reset logs count:0x37b02e9d scn: 0x0000000000000001   
　　recovered at 02/15/2017 13:53:24   
　　status:0x2001 root dba:0x00400208 chkpt cnt: 70 ctl cnt:69   

　　begin-hot-backup file>　　Checkpointed at scn:  0x00000000001de00c 02/15/2017 13:56:00   
　　三 数据块中的SCN
  

• 数据块变化时的SCN
  

　　很多操作会引起数据块改变，如业务数据的变化、块清理等。
　　SQL> oradebug setmypid   
　　Statement processed.   
　　SQL> oradebug tracefile_name   
　　/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_29430.trc   
　　SQL> alter system dump datafile 1 block 16;

　　System>　　SQL> !more /oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_29430.trc   
　　Start dump data blocks tsn: 0 file#:1 minblk 16 maxblk 16   
　　Block dump from cache:   
　　Dump of buffer cache at level 4 for pdb=0 tsn=0 rdba=4194320   
　　Block dump from disk:   
　　buffer tsn: 0 rdba: 0x00400010 (1/16)   
　　scn: 0xa seq: 0x01 flg: 0x04 tail: 0x000a1e01   
　　frmt: 0x02 chkval: 0x80ab type: 0x1e=KTFB Bitmapped File Space Bitmap   
　　Hex dump of block: st=0, typ_found=1
　　……
  

• 数据块事务槽中的SCN
  

  

• 数据块中数据行的SCN
  

　　可以通过伪列ORA_ROWSCN查看数据行改变时的SCN

　　SQL> select>
　　>　　---------- ----------   
　　1    1960725   
　　2    1960725   
　　3    1960725
　　四 日志文件头中的SCN
  

• FISRT_CHANGE#
  

　　表示该在线日子文件被重用时的SCN
  

• NEXT_CHANGE#
  

　　表示该日志文件重用结束时的SCN
  

• RESETLOGS_CHANGE#
  

　　表示数据库已RESETLOGS方式打开时的SCN。通常和数据文件头的RESETLOGS_CHANGE#相同。
　　SQL> select first_change#,next_change#,resetlogs_change# from v$log_history  where sequence#=5;
　　FIRST_CHANGE# NEXT_CHANGE# RESETLOGS_CHANGE#   
　　------------- ------------ -----------------   
　　1856486       1956862         1408558   
　　dump日志文件头获取上述SCN,
　　0x00000000001c53e6十进制1856486，0x00000000001ddbfe十进制1956862，0x0000000000157e2e十进制1408558

　　SQL>>
　　Session>　　LOG FILE #2:   
　　name #2: /oradata/ORCL/onlinelog/o1_mf_2_db4tt00w_.log   
　　Thread 1 redo log links: forward: 3 backward: 1   
　　siz: 0x64000 seq: 0x00000005 hws: 0x6 bsz: 512 nab: 0x478 flg: 0x1 dup: 1   
　　Archive links: fwrd: 0 back: 0 Prev scn: 0x00000000001a9cfc   
　　Low scn: 0x00000000001c53e6 02/15/2017 13:52:08   
　　Next scn: 0x00000000001ddbfe 02/15/2017 13:53:25   
　　FILE HEADER:   
　　Compatibility Vsn = 203423744=0xc200000   

　　Db>
　　Activation>
　　Control Seq=1735=0x6c7, File>　　File Number=2, Blksiz=512, File Type=2 LOG   

　　Format>　　redo log key is 30c0dccb5d4341b7f1be4b600b3604e7   
　　redo log key flag is 5   
　　descrip:"T 0001, S 0000000005, SCN 0x00000000001c53e6-0x00000000001ddbfe"   
　　thread: 1 nab: 0x478 seq: 0x00000005 hws: 0x6 eot: 0 dis: 0   
　　reset logs count: 0x37c90b3f     
　　Reset Logs scn: 0x0000000000157e2e   
　　Low scn: 0x00000000001c53e6 02/15/2017 13:52:08   
　　Next scn: 0x00000000001ddbfe 02/15/2017 13:53:25   
　　Enabled scn: 0x0000000000157e2e 02/14/2017 10:28:15   
　　Thread closed scn: 0x00000000001ddbfc 02/15/2017 13:52:30   
　　Disk cksum: 0x6c0a Calc cksum: 0x0   
　　Terminal Recovery Stop scn: 0x0000000000000000   
　　Terminal Recovery Stamp  01/01/1988 00:00:00   
　　Most recent redo scn: 0x0000000000000000   
　　Largest LWN: 0 blocks   
　　Real Next scn: 0x00000000001c555c   
　　Previous Resetlogs scn: 0x0000000000000001   
　　Miscellaneous flags: 0x800000   
　　Miscellanous second flags: 0x0   
　　Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000000000000000   
　　Zero blocks: 8   
　　Enabled redo threads: 1     
　　五 事务开始时的SCN

　　SQL> update aa set>　　1 row updated.
　　SELECT xidusn, start_scnb, start_scnw   
　　FROM v$transaction   
　　WHERE ses_addr = (SELECT saddr   
　　FROM v$session   
　　WHERE sid = (SELECT sid   
　　FROM v$mystat   
　　7                                    WHERE ROWNUM = 1));
　　XIDUSN START_SCNB START_SCNW   
　　---------- ---------- ----------   
　　1    1960725           0
　　SQL> select name from v$rollname where usn=10;
　　NAME   
　　------------------------------   
　　_SYSSMU10_2925533193$

　　SQL>>
　　System>　　六 数据库的CURRENT SCN
　　SQL> ORADEBUG DUMPvar SGA kcsgscn   
　　kcslf kcsgscn_ [0600113B8, 0600113E8) = 001DF7C8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 60049740 00000000   
　　SQL> select current_scn from v$database;
　　CURRENT_SCN   
　　-----------   
　　1963968
　　SQL> select dbms_flashback.get_system_change_number from dual;
　　GET_SYSTEM_CHANGE_NUMBER   
　　------------------------   
　　1964014