感兴趣的还是记得去看原帖子，笔记有删减，原作者微信公众号： 
1、关于SCN的一些基本概念和知识点
SCN，即为system commit number（也有人说是system change number),它是一个递增的数字，可以理解为一个递增非连续的sequence，
最大值为0xffff.ffffffff（转换10进制是281474976710655)。
对于单实例：scn值是存放于SGA中的，是通过system commit number latch来保护的，要获得scn，就需要先得到这个latch。
对于RAC环境： scn是通过排队机制(enqueue)来实现各节点之间的顺序增长的。其中的算法有2种，就是大家所熟知的lamport和commit广播。
可以通过参数 max_commit_propagation_delay 来控制2种算法的切换，该值默认是700（厘秒），
lamport算法；如果该值小于100（厘秒），oracle会使用commit广播算法。
关于scn增速：
在2012年第1季度cpu推出后，引发了不少关于scn 的问题，其中引发了网上关于scn 相关bug的讨论。当scn增长出现异常，可以导致scn耗尽的情况：
在11.2.0.2版本之前，scn 的最大增长频率是16k,
在11.2.0.2版本开始，为32k，有如下参数进行控制：_max_reasonable_scn_rate
11.2.0.4和19c显示一样：
NAME VALUE D S S M A DESCRIPTION
---------------------------------------- -------------------- - - - - - ----------------------------------------------------------------------
_max_reasonable_scn_rate 32768 Y N N N N Max reasonable SCN rate
2、SCN的分类有哪些？ 在oracle中存在很多种scn，但是只有如下几种，是我们比较关注的：
Commit scn/cleanout scn --主要存在于data block中
database scn/on disk scn/thread scn/datafile checkpoint scn/start scn --存在于controlfile和datafile中
offline scn/online scn
resetlogs scn
stop scn
low/high scn
下面我们通过实验来展示，描述上述几种scn，便于大家加深理解。
2.1 Commit scn/cleanout scn
create table t1(a number);
insert into t1 values(1);
insert into t1 values(2);
insert into t1 values(3);
commit;
select dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid) blk# from t1;
FILE# BLK#
---------- ----------
4 179
4 179
4 179
--dump block
sqlplus / as sysdba
alter system checkpoint;--让脏数据落盘，要不dump的数据不准确
oradebug setmypid
alter system dump datafile 4 block 179;
oradebug tracefile_name
---此时的dump trace如下
Start dump data blocks tsn: 4 file#:4 minblk 179 maxblk 179
........
buffer tsn: 4 rdba: 0x010000b3 (4/179)
scn: 0x0000.0011983a seq: 0x01 flg: 0x06 tail: 0x983a0601 --scn: 0x0000.0011983a 是block scn，转换成10进制是 1153082
frmt: 0x02 chkval: 0x2c1d type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00002AAAADD26A00 to 0x00002AAAADD28A00
.......... --cleanout scn 和事务有关系，Oracle更新数据块时,会产生一个Cleanout SCN
seg/obj: 0x1553f csc: 0x00.119839 itc: 2 flg: E typ: 1 - DATA --csc: 0x00.119839，这个是cleanout scn，最后一次 full cleanout时的scn，转换成10进制是1153081
brn: 0 bdba: 0x10000b0 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc --Scn/Fsc 表示commit scn或者 fast commit scn，和事务一一对应：1153082
0x01 0x000a.01f.00000294 0x00c00116.0073.37 --U- 3 fsc 0x0000.0011983a
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
/*************修改第二条数据后再次dump block查看变化********************/
update t1 where a=4 where a=2;
commit;
alter system checkpoint;
................................
Itl Xid Uba Flag Lck Scn/Fsc --这里有2条记录
0x01 0x000a.01f.00000294 0x00c00116.0073.37 C--- 0 scn 0x0000.0011983a
0x02 0x0001.00b.00000294 0x00c0206f.0086.0d --U- 1 fsc 0x0000.0011a0cf
Flag：事务标志位含义：
C--- = transaction has been committed and locks cleaned out
-B-- = this undo record contains the undo for this ITL entry
--U- = transaction committed (maybe long ago); SCN is an upper bound
---T = transaction was still active at block cleanout SCN的分类有哪些？
--备注：
1、cleanout分为2钟，一种是fast commit cleanout,另一种是delayed block cleanout；
2、COMMIT或者rollback时，如果块仍在块缓冲区中，Oracle会执行一个很快的清理，这叫做 快速块清除(FAST BLOCK CLEANOUT);
反之，modified block已经被写回磁盘，当发生commit时oracle并不会把block重新读入做cleanout，这样成本太高，而是把cleanout留到下一次对此块的dml时来完成-延迟清理
3、如果该事务没有涉及延时块清除，那么显示的FSC。 如果是延时块清除（delayed block cleanout），那么显示的就是SCN。
2.2 database checkpoint scn/on disk scn/thread scn/datafile checkpoint scn --存在于controlfile和datafile中
所谓检查点scn(checkpoint scn)，也就是指在检查点发生的时候，产生的scn值，该值是相当重要的，在我们进行文件头修复等数据库恢复时，起着至关重要的作用
select file#,STATUS,CHECKPOINT_CHANGE#,ONLINE_CHANGE# from v$datafile;
FILE# STATUS CHECKPOINT_CHANGE# ONLINE_CHANGE#
---------- -------------- ------------------ --------------
1 SYSTEM 1155938 925702
2 ONLINE 1155938 925702
3 ONLINE 1155938 925702
4 ONLINE 1155938 925702
select file#,STATUS,CHECKPOINT_CHANGE#,CHECKPOINT_COUNT from v$datafile_header order by 1;
FILE# STATUS CHECKPOINT_CHANGE# CHECKPOINT_COUNT
---------- -------------- ------------------ ----------------
1 ONLINE 1155938 140
2 ONLINE 1155938 140
3 ONLINE 1155938 61
4 ONLINE 1155938 139
--v$datafile的checkpoint信息是来自controlfile
--v$datafile_header的checkpoint 信息是来自数据库文件头
我们首先来dump controlfile和datafile header的信息，进行观察
oradebug setmypid
alter session set events 'immediate trace name CONTROLF level 4';
alter session set events 'immediate trace name FILE_HDRS level 3';
oradebug close_trace
oradebug tracefile_name
此时的控制文件dump 信息如下所示：
DATA FILE #1:
name #7: /oradata/orcl/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:140 scn: 0x0000.0011a362 09/02/2024 12:16:25 --1155938
Stop scn: 0xffff.ffffffff 08/29/2024 18:21:01
Creation Checkpointed at scn: 0x0000.00000007 08/24/2013 11:37:33
thread:0 rba:(0x0.0.0)
这里重点解释一下几个关键点：
Checkpoint cnt: 表示checkpoint count值
scn: 0x0000.0011a362 这就是存于datafile 头部的checkpoint scn. 也被称为start scn
Stop scn: 0xffff.ffffffff 在数据库open的情况下，该值是被置于无穷大的，因为数据库不知道最后的值是什么，而当你正常停库时，该值会等于database checkpoint scn和datafile checkpoint scn.
2.3 offline scn/online scn
当表空间或数据文件被offline时，其对应的数据文件的scn会写入一个值,被称为offline scn：
select file#,checkpoint_change# from v$datafile where ts#=6;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
5 1168392
select file#,checkpoint_change# from v$datafile_header where ts#=6;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
5 1168392
alter tablespace test offline;
此时我们分别使用前面的命令dump控制文件和数据文件头，这里省略dump命令，trace内容如下：
--controlfile
DATA FILE #5:
name #9: /oradata/orcl/test01.dbf
creation size=12800 block size=8192 status=0x80 head=9 tail=9 dup=1
tablespace 6, index=6 krfil=5 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:13 scn: 0x0000.0011d538 09/02/2024 17:32:19 --0011d538 十进制是1168696
Stop scn: 0x0000.0011d538 09/02/2024 17:32:19 --stop scn =checkpoint scn
Creation Checkpointed at scn: 0x0000.0011ce7f 09/02/2024 17:03:33
thread:1 rba:(0x18.73eb.10)
......
Offline scn: 0x0000.0011d32e prev_range: 1 --当数据文件offline的时候 ，offline scn 并不等于stop scn
Online Checkpointed at scn: 0x0000.0011d341 09/02/2024 17:29:12 --online scn 这个值是历史的，如果online这个值会被更新
--datafile HEADER
DATA FILE #5:
name #9: /oradata/orcl/test01.dbf
creation size=12800 block size=8192 status=0x80 head=9 tail=9 dup=1
tablespace 6, index=6 krfil=5 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:13 scn: 0x0000.0011d538 09/02/2024 17:32:19
Stop scn: 0x0000.0011d538 09/02/2024 17:32:19
Creation Checkpointed at scn: 0x0000.0011ce7f 09/02/2024 17:03:33
thread:1 rba:(0x18.73eb.10)
.............
Offline scn: 0x0000.0011d32e prev_range: 1
Online Checkpointed at scn: 0x0000.0011d341 09/02/2024 17:29:12
thread:1 rba:(0x18.75d5.10)
Stop scn = Checkpoint scn
此时我们切换一次日志，再次观察checkpoint的变化情况：
alter system switch logfile;
select file#,STATUS,CHECKPOINT_CHANGE#,ONLINE_CHANGE# from v$datafile;
FILE# STATUS CHECKPOINT_CHANGE# ONLINE_CHANGE#
---------- -------------- ------------------ --------------
1 SYSTEM 1168392 925702
2 ONLINE 1168392 925702
3 ONLINE 1168392 925702
4 ONLINE 1168392 925702
5 OFFLINE 1168696 1168193
select file#,STATUS,CHECKPOINT_CHANGE#,CHECKPOINT_COUNT from v$datafile_header order by 1;
FILE# STATUS CHECKPOINT_CHANGE# CHECKPOINT_COUNT
---------- -------------- ------------------ ----------------
1 ONLINE 1168392 146
2 ONLINE 1168392 146
3 ONLINE 1168392 67
4 ONLINE 1168392 145
5 OFFLINE 0 0
我们可以看到一旦文件被offline之后，查询v$datafile_header就看不到该文件检查点信息了，但是实际上文件头上的信息仍然存在。我们来试试能否正常online文件。
alter tablespace test online;
--control trc
DATA FILE #5:
name #9: /oradata/orcl/test01.dbf
creation size=12800 block size=8192 status=0xe head=9 tail=9 dup=1
tablespace 6, index=6 krfil=5 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:14 scn: 0x0000.0011d5f1 09/02/2024 17:40:34
Stop scn: 0xffff.ffffffff 09/02/2024 17:32:19 --stop scn 变成无穷大
Creation Checkpointed at scn: 0x0000.0011ce7f 09/02/2024 17:03:33
thread:1 rba:(0x18.73eb.10)
........
Offline scn: 0x0000.0011d538 prev_range: 2 --offline scn 是历史上一次的scn
Online Checkpointed at scn: 0x0000.0011d5f1 09/02/2024 17:40:34 --online checkpoin scn 更新成了checkpoint scn
thread:1 rba:(0x19.5.10)
从上面的小实验，我们可以得出如下结论：
1. archivelog模式下,当表空间offline时，其对应数据文件头stop scn会更新，
offline scn不等于stop scn.
2. 当online后，对应的数据文件头的online scn等于datafile checkpoint scn值。
3. 当online后，controlfile中关于该表空对应的datafile和对应的数据文件头的stop scn都会重新被置于最大值，即为无穷大.
2.4 resetlogs scn
什么是resetlogs scn呢？顾名思义，就是当我们以open resetlogs方式打开数据库时对应的scn值。我们在进行数据库恢复时，经常遇到这个，
可能需要通过bbed来修改文件头的resetlogs scn。那什么时候会遇到呢？
比如当你空间文件丢失或者损坏时，重建控制文件时遗留了数据文件，并resetlogs操作过数据库（即使open resetlogs失败），
那么你也会发现，此时你数据库的数据文件的resetlogs scn会不一致。要想进行恢复，就必须要去修改文件头resetlog scn
--来观察resetlog scn：
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
08/29/2024 10:19:44
DB Name "ORCL"
Database flags = 0x00404001 0x00001200
Controlfile Creation Timestamp 08/29/2024 10:19:44
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.000e2006 Resetlogs Timestamp 08/29/2024 10:19:46 --Resetlogs scn
Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 08/24/2013 11:37:30 --Prior resetlogs scn 是上一次resetlogs的scn
Redo Version: compatible=0xb200400
#Data files = 5, #Online files = 4
Database checkpoint: Thread=1 scn: 0x0000.0011d77a
Threads: #Enabled=1, #Open=1, Head=1, Tail=1
同样，我们如果去观察数据库文件头的话，也能看到resetlogs scn等结构，这里我用bbed来查看更方便（注意这些结构都存在于数据文件头），如下：
BBED> info all;
File# Name Size(blks)
----- ---- ----------
1 /oradata/orcl/system01.dbf 94720
2 /oradata/orcl/sysaux01.dbf 66560
3 /oradata/orcl/undotbs01.dbf 8960
4 /oradata/orcl/users01.dbf 640
5 /oradata/orcl/test01.dbf 12800
BBED> set file 2 block 1
FILE# 2
BLOCK# 1
BBED> p kcvfhrls
struct kcvfhrls, 8 bytes @116
ub4 kscnbas @116 0x000e2006 -- 对应上面trc的 Resetlogs scn: 0x0000.000e2006
ub2 kscnwrp @120 0x0000
BBED> p kcvfhprs
struct kcvfhprs, 8 bytes @420
ub4 kscnbas @420 0x00000001 --对应上面的 Prior resetlogs scn: 0x0000.00000001
ub2 kscnwrp @424 0x0000
BBED>
至少在如下几种情况下，我们可以利用到resetlogs scn.
1) 修复controlfile和datafile header时
2) 当我们resetlogs 后失败会，该值会更新，如果需要重新恢复到原始状态，需要进行修复。
2.5 Stop scn
首先一个问题，什么是stop scn？stop scn 值在什么地方？它有什么作用 ？s
答： stop scn,顾名思义是指数据库或数据文件在某个时刻处于停止状态时的scn值,当处于run状态时，该值是被设置为无穷大的。
shutdown immediate;
startup mount;
select file#,name,last_change# from v$datafile order by 1;
FILE# NAME LAST_CHANGE#
---------- -------------------------------------------------- ------------
1 /oradata/orcl/system01.dbf 1170472
2 /oradata/orcl/sysaux01.dbf 1170472
3 /oradata/orcl/undotbs01.dbf 1170472
4 /oradata/orcl/users01.dbf 1170472
5 /oradata/orcl/test01.dbf 1170472
DATA FILE #1:
name #7: /oradata/orcl/system01.dbf
creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
tablespace 0, index=1 krfil=1 prev_file=0
unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
Checkpoint cnt:149 scn: 0x0000.0011dc28 09/02/2024 18:14:22 --0011dc28 十进制 1170472
Stop scn: 0x0000.0011dc28 09/02/2024 18:14:22 --Checkpoint scn = stop scn
Creation Checkpointed at scn: 0x0000.00000007 08/24/2013 11:37:33
thread:0 rba:(0x0.0.0)
enabled threads: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
Offline scn: 0x0000.000e2005 prev_range: 0
Online Checkpointed at scn: 0x0000.000e2006 08/29/2024 10:19:46
thread:1 rba:(0x1.2.0)
我们发现此时database checkpoint scn和stop scn是相同的
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
08/29/2024 10:19:44
DB Name "ORCL"
Database flags = 0x00404001 0x00001000
Controlfile Creation Timestamp 08/29/2024 10:19:44
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.000e2006 Resetlogs Timestamp 08/29/2024 10:19:46
Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp 08/24/2013 11:37:30
Redo Version: compatible=0xb200400
#Data files = 5, #Online files = 5
Database checkpoint: Thread=1 scn: 0x0000.0011dc28 --控制文件 scn
Threads: #Enabled=1, #Open=0, Head=0, Tail=0
对于正常停库的情况下，stop scn值是等于datafile checkpoint scn值的。数据库启动时，Oracle将数据文件头中的stop scn与datafile checkpoint scn比较，
如果这两个值匹配，Oracle接下来再比较数据文件头中的SCN和控制文件中数据文件的stop scn，如果这个值也匹配，就意味着所有数据块已经提交，
因此数据库不需要进行恢复，此时数据库直接打开。
如果stop scn为null，那么就需要进行实例恢复。如果stop scn小于datafile checkpoint scn或database checkpoint scn，
2.6 high scn/low scn
oracle的redo log日志文件中，其实也存在着一种scn，那就是high scn/low scn。我们首先通过试图来查询了解一下：
select recid,sequence#,first_change#,next_change# from v$log_history;
RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 1 925702 925968
2 2 925968 928868
3 3 928868 941331
.....................................
23 23 1152366 1154604
24 24 1154604 1168865
25 25 1168865 1169270
那么什么是low scn呢？什么是high scn？如果用上面的查询来解释，那么就可以简单的理解为：
first_change#就是low scn,而next_change#值就是high scn.
简单的讲，redo log scn，是指redo log在进行切换时刻对应的scn值,而scn又对应着时间，在进行实例恢复时，是需要通过该值来确认需要应用哪些archivelog或redo log的.
oradebug setmypid
ALTER SESSION SET EVENTS 'immediate trace name loghist level 1';
oradebug tracefile_name
oradebug close_trace
--trc
Oradebug command 'setmypid' console output: <none>
DUMP OF LOG HISTORY: 25 history records
Earliest record:
RECID #1 Recno 1 Record timestamp 08/29/24 10:19:52 Thread=1 Seq#=1 Link-Recid=0 kccic-Recid=2
Low scn: 0x0000.000e2006 08/29/24 10:19:46 Next scn: 0x0000.000e2110 --Low scn: 0x0000.000e2006=925702 Next scn: 0x0000.000e2110=925968
Latest record:
RECID #25 Recno 25 Record timestamp 09/02/24 17:47:20 Thread=1 Seq#=25 Link-Recid=24 kccic-Recid=2
Low scn: 0x0000.0011d5e1 09/02/24 17:39:53 Next scn: 0x0000.0011d776 --Low scn: 0x0000.0011d5e1=1168865 Next scn: 0x0000.0011d776= 1169270
从上面的log history dump可以看到，有2条record记录，分别是最早和最新.
这些信息其实在controlfile中也是存在的，下面我们来dump controlfile来寻找下low scn等信息：
--查询redo log信息
select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARCHIV STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- ------ -------------------------------- ------------- ------------------- ------------ -------------------
1 1 25 52428800 512 1 YES INACTIVE 1168865 2024-09-02 17:39:53 1169270 2024-09-02 17:47:20
2 1 26 52428800 512 1 NO CURRENT 1169270 2024-09-02 17:47:20 2.8147E+14
3 1 24 52428800 512 1 YES INACTIVE 1154604 2024-09-02 11:39:28 1168865 2024-09-02 17:39:53
SQL> select member from v$logfile;
MEMBER
------------------------------
/oradata/orcl/redo03.log
/oradata/orcl/redo02.log
/oradata/orcl/redo01.log
oradebug setmypid
alter session set events 'immediate trace name CONTROLF level 4';
oradebug close_trace
oradebug tracefile_name
--log file trc：
***************************************************************************
LOG FILE RECORDS
***************************************************************************
(size = 72, compat size = 72, section max = 16, section in-use = 3,
last-recid= 3, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 10, numrecs = 16)
LOG FILE #1:
name #3: /oradata/orcl/redo01.log
Thread 1 redo log links: forward: 2 backward: 0
siz: 0x19000 seq: 0x00000019 hws: 0x3 bsz: 512 nab: 0x16a flg: 0x1 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.00119e2c --1154604
Low scn: 0x0000.0011d5e1 09/02/2024 17:39:53 --1168865
Next scn: 0x0000.0011d776 09/02/2024 17:47:20 --1169270
LOG FILE #2:
name #2: /oradata/orcl/redo02.log
Thread 1 redo log links: forward: 3 backward: 1
siz: 0x19000 seq: 0x0000001a hws: 0x4 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.0011d5e1
Low scn: 0x0000.0011d776 09/02/2024 17:47:20 --1169270
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
LOG FILE #3:
name #1: /oradata/orcl/redo03.log
Thread 1 redo log links: forward: 0 backward: 2
siz: 0x19000 seq: 0x00000018 hws: 0x9 bsz: 512 nab: 0x7787 flg: 0x1 dup: 1 -seq: 0x00000018=24
Archive links: fwrd: 0 back: 0 Prev scn: 0x0000.0011956e
Low scn: 0x0000.00119e2c 09/02/2024 11:39:28 --1154604
Next scn: 0x0000.0011d5e1 09/02/2024 17:39:53 --1168865
上面的内容较多，这里重点将说明其中几点：
Prev scn: 0x0000.00119e2c --前一个日志的FIRST_CHANGE#
Low scn: 0x0000.0011d5e1 --这里的low scn对应上面的next change值.(因为我这里是查看的current log信息,前面是dump的redo log history)
Next scn: 0x0000.0011d776 --注意这里next scn其实有点类似datafile的stop scn，对于current log来讲，总是被置于无穷大的.
从上面的dump 信息，我们可以得到如下几个小结论：
1) 对于非current redo，low scn就是上一组redo的最后scn，同时也是next组redo log的起始scn。
2）如果next scn为无穷大，那么就可以判断出，该组redo是处于current 模式。
3）redo log被删除，仍然可以从controlfile中看到，不过其状态是deleted。
4) 另外，我们还可以看到每组redo log的大小，对应的sequence等等.
--补充：
Oracle从 12c开始扩展了scn，也称为extend scn或者Big scn。简单的讲，就是将scn结构的低位进一步扩展了。
后面在讲文件头结构时我们会进一步讲解。 我们知道scn的结构是：kscnwrp.kscnbas，前面wrp是低位，bas值是高位。
所谓big scn就是进一步扩展了低位，增加了 wrp2 .这里给大家看看19c的的数据文件头检查点就知道了：
--11.2.0.4 bbed 查看 scn：
BBED> set dba 1,1
DBA 0x00400001 (4194305 1,1)
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x0011dc2b --对应 scn:1170475
ub2 kscnwrp @488 0x0000
ub4 kcvcptim @492 0x4641aed1
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x0000001a
ub4 kcrbabno @504 0x00000aa2
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
--19.3 bbed查看 scn
BBED> set dba 1,1
DBA 0x00400001 (4194305 1,1)
BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x00356b2a
ub2 kscnwrp @488 0x8000 --这个对比11g变了
ub4 kcvcptim @492 0x46405b12
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000014
ub4 kcrbabno @504 0x00000002
ub2 kcrbabof @508 0x0010
ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
--SCN扩展之后，变得更大了，以前担心的SCN 增长过快的问题，大家再也不需要担心了（ 高位1，就表示2的32次方，扩展4位，大家可以脑补一下最大值是多少了)
--11g 数据库查看数据文件scn：
SQL> select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
-------------------------------------------------- ------------------
/oradata/orcl/system01.dbf 1170475
/oradata/orcl/sysaux01.dbf 1170475
/oradata/orcl/undotbs01.dbf 1170475
/oradata/orcl/users01.dbf 1170475
/oradata/orcl/test01.dbf 1170475
复制最后修改时间：2024-10-10 12:31:56
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
评论
相关阅读
Oracle RAC 一键安装翻车？手把手教你如何排错！
Lucifer三思而后行
563次阅读
2025-04-15 17:24:06
【纯干货】Oracle 19C RU 19.27 发布，如何快速升级和安装？
Lucifer三思而后行
493次阅读
2025-04-18 14:18:38
Oracle SQL 执行计划分析与优化指南
Digital Observer
463次阅读
2025-04-01 11:08:44
XTTS跨版本迁移升级方案（11g to 19c RAC for Linux）
zwtian
455次阅读
2025-04-08 09:12:48
墨天轮个人数说知识点合集
JiekeXu
454次阅读
2025-04-01 15:56:03
【ORACLE】记录一些ORACLE的merge into语句的BUG
DarkAthena
442次阅读
2025-04-22 00:20:37
Oracle数据库一键巡检并生成HTML结果，免费脚本速来下载!
陈举超
430次阅读
2025-04-20 10:07:02
【ORACLE】你以为的真的是你以为的么?--ORA-38104: Columns referenced in the ON Clause cannot be updated
DarkAthena
417次阅读
2025-04-22 00:13:51
Oracle 19c RAC更换IP实战，运维必看！
szrsu
401次阅读
2025-04-08 23:57:08
【活动】分享你的压箱底干货文档，三篇解锁进阶奖励！
墨天轮编辑部
374次阅读
2025-04-17 17:02:24
