系统改变号(SCN)的详解

oracle026

---

SCN 系统改变号，是通过某些函数把时间产生某个数；确保数据文件的一致性，比较先后，新旧；
为什么使用时间产生数字，因为在比较时间的比较慢，而用数字就相对的块点，就像shared pool 比较sql的
使用算出的hash值进行比较。

select dbms_flashback.get_system_change_number,
SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) from dual;

//获取当前时间的SCN的值，dual是一张临时表类似于MYSQL的temp表的用处。
1153633     22-12月-14 03.04.02.000000000 上午



控制文件中有三个SCN：开始SCN 结束SCN  和文件SCN 

文件SCN是针对于每个数据文件产生的文件SCN号
文件SCN是针对于每个数据文件产生的结束SCN号

在每个数据文件前有一个开始SCN

在数据库正常的时候结束SCN时NULL的 ，而文件的开始SCN、文件SCN、和系统SCN号是相同的
当数据库关闭的时候，系统、文件、结束、开始都是一样的，
当非正常关闭，结束SCN为空，由于没有及时保存信息；当下一次数据开启的时候。就会
检查到数据时非正常关闭，就会做数据实例的恢复工作：需要redo log部分日志、控制文件LRBA、HRBA、ON DISK RBA

当我们把数据文件换了旧的文件，当系统检测到了旧文件的开始SCN和和结束SCN不一样就需要进行数据恢复做：
跑日志：把SCN跑成新的
提升SCN

查看几个SCN：
select checkpoint_change# from v$database;  //系统SCN，存在于每个控制文件
     1148314
select name,checkpoint_change# from v$datafile;//文件SCN，存在于每个控制文件
/u01/app/oracle/oradata/jiagulun/system01.dbf     1148314
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf     1148314
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf     1148314
/u01/app/oracle/oradata/jiagulun/users01.dbf     1148314
/u01/app/oracle/oradata/jiagulun/example01.dbf     1148314

select name,last_change# from v$datafile;//结束SCN，存在于每个控制文件
/u01/app/oracle/oradata/jiagulun/system01.dbf    
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf    
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf    
/u01/app/oracle/oradata/jiagulun/users01.dbf    
/u01/app/oracle/oradata/jiagulun/example01.dbf    

select name ,checkpoint_change# from v$datafile_header//文件头SCN，存在于每个数据文件的头部
/u01/app/oracle/oradata/jiagulun/system01.dbf     1148314
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf     1148314
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf     1148314
/u01/app/oracle/oradata/jiagulun/users01.dbf     1148314
/u01/app/oracle/oradata/jiagulun/example01.dbf     1148314

redo日志文件有一个first SCN 和一个next SCN
first、next 是这个文件中日志记录的范围
每个日志的条目都有一个SCN；可以把frist SCN号当做这个文件第一条记录的SCN号，把next SCN号当做下一个文件日志中记录的开始SCN号
select * from v$log；
名称            空值 类型          
------------- -- ------------
GROUP#           NUMBER   //日志组
THREAD#          NUMBER      
SEQUENCE#        NUMBER   //唯一标识   
BYTES            NUMBER      
BLOCKSIZE        NUMBER      
MEMBERS          NUMBER      
ARCHIVED         VARCHAR2(3) 
STATUS           VARCHAR2(16) //状态：active，inactive，current
FIRST_CHANGE#    NUMBER   //first SCN，而下一个日志的开始就是上一个日志的next SCN （在10g的时候是这么认为的） 
FIRST_TIME       DATE        
NEXT_CHANGE#     NUMBER  //next SCN（10g不一样）    
NEXT_TIME        DATE   

1     1     10     52428800     512     1     NO     INACTIVE     1108520     21-12月-14     1148313     22-12月-14
2     1     11     52428800     512     1     NO     CURRENT     1148313     22-12月-14     281474976710655    
3     1     9     52428800     512     1     NO     INACTIVE     1087024     21-12月-14     1108520     21-12月-14


做一个实验：
     1. select * from v$log;

1     1     10     52428800     512     1     NO     INACTIVE     1108520     21-12月-14     1148313     22-12月-14
2     1     11     52428800     512     1     NO     ACTIVE     1148313     22-12月-14     1156305     22-12月-14
3     1     12     52428800     512     1     NO     CURRENT     1156305     22-12月-14     281474976710655    
    
     2. alter system switch logfile;
     3. alter system switch logfile;
     4. select * from v$log;

1     1     13     52428800     512     1     NO     ACTIVE     1157154     22-12月-14     1157173     22-12月-14
2     1     14     52428800     512     1     NO     CURRENT     1157173     22-12月-14     281474976710655    
3     1     12     52428800     512     1     NO     ACTIVE     1156305     22-12月-14     1157154     22-12月-14    
     5. select name , last_change# from v$datafile;
              
/u01/app/oracle/oradata/jiagulun/system01.dbf     1157173
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf     1157173
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf     1157173
/u01/app/oracle/oradata/jiagulun/users01.dbf     1157173
/u01/app/oracle/oradata/jiagulun/example01.dbf     1157173

会发现数据文件中、数据文件头的SCN没有变化，而日志中的SCN的值发生了变化。由于在控制文件中、数据文件头的SCN的主要目的是控制
数据文件的一致性

active表示日志文件中对应脏缓冲区还未写入数据库，不能被覆盖，也就说明需要进行实例恢复。
再做个试验：
     1. alter system flush buffer_cache;//冲刷缓冲区数据
     2. select name , checkpoint__change# from v$datafile;

/u01/app/oracle/oradata/jiagulun/system01.dbf     1157173
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf     1157173
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf     1157173
/u01/app/oracle/oradata/jiagulun/users01.dbf     1157173
/u01/app/oracle/oradata/jiagulun/example01.dbf     1157173

     3. select * from v$log;
1     1     13     52428800     512     1     NO     INACTIVE     1157154     22-12月-14     1157173     22-12月-14
2     1     14     52428800     512     1     NO     CURRENT          1157173     22-12月-14     281474976710655    
3     1     12     52428800     512     1     NO     INACTIVE     1156305     22-12月-14     1157154     22-12月-14

上面的数据你会发现当把buffer cache中数据flush掉以后，控制文件、数据文件中的SCN都没有变化，只有日志文件中的状态变了
是由于原本缓冲区的脏数据被清空了，那么它所对应的日志可以变成可以覆盖的了，也就是inactive了
而且在文件头部、控制文件中的SCN的值是记录着日志文件中的ACTIVIE/CURRENT的SCN的值等于最老的redo log中的active的日志

其实控制文件中的SCN是用来定位哪个文件跑日志，而在控制文件中的LRBA是确定从哪里开始跑日志


注意：增量检查点并不会去更新数据文件头，以及控制文件中数据库SCN以及数据文件条目的SCN信息，而只是每3秒由CKPT进程去               更新控制文件中的low cache rba信息，也就是检查点的位置。
     那么他们是在什么时候会进行更新呢？
          结束SCN时在数据库正常关闭的时候进行更新
          其他的SCN是在日志文件的状态从active变成inactive的时候才进行更新的，上面的测试可以证明

fast_start_mttr_target：这个参数是用来设置实例在恢复的时间，因为在个值将会影响DBWR的写数据库频率，
               把恢复的时间缩短，说明脏数据少了，那是因为写的频率大。