7、日志切换时的检查点.
当发生日志切换时,也会触发检查点.在数据库并不繁忙的情况下,日志切换的检查点并不急于完成.之所以在日志切换的时候触发一次检查点,是为了保证重做日志文件所对应的脏块都被写进磁盘文件.如果写脏块的速度比较慢,日志文件循环一圈后,又该覆盖此日志文件时,而此日志文件的检查点还没有完成,那么覆盖操作将等待.等待事件名:log file switch(checkpoint incomplete).如果出现该等待事件,解决方法:1,可以增加日志文件组的数量.2,观察下增量检查点的间隔时间.如果是因为增量检查点间隔时间太长,导致积攒的脏块过多.可以把增量检查点参数设置的频繁点.
日志切换检查点除了会触发DBWR写脏块外,CKPT进程还要将切换时的SCN写进数据文件头和控制文件中的数据库信息节,还有数据文件节.另外还要将新的联机重做日志文件中第一条重做记录的RBA写进数据文件头.
日志切换检查点写进数据文件头的SCN,可以通过v$datafile_header视图查看.
日志切换检查点写进控制文件中数据库信息节的SCN,可以通过v$database查看.
日志切换检查点写进控制文件中的数据文件节中的SCN,可以通过v$datafile查看.
先把log_checkpoints_to_alert这个参数设置为真,以便可以在告警日志中看到日志切换检查点的相关信息.
alter system set log_checkpoints_to_alert=true;
实验:验证下当触发了日志切换检查点后, 数据文件头,控制文件中的日志切换检查点信息都是什么:
步骤一:查看当前数据文件头的SCN
SQL> select checkpoint_change#,checkpoint_time,checkpoint_count from v$datafile_header;
CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT
------------------ -------------- ----------------
2372527 03-3月 -08 646
2372527 03-3月 -08 609
2372527 03-3月 -08 646
......
已选择11行。
步骤二:查看当前控制文件中的数据库信息节的日志切换检查点信息
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
2372527
步骤三:查看当前控制文件中的数据文件节中的日志切换检查点信息
SQL> select checkpoint_change#,checkpoint_time,last_change#,last_time,substr(name,1,30) from v$datafile;
CHECKPOINT_CHANGE# CHECKPOINT_TIM LAST_CHANGE# LAST_TIME SUBSTR(NAME,1,30)
------------------ -------------- ------------ -------------- -------------------------------------------
2372527 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
2372527 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
2372527 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
......
已选择11行。
步骤四:查看当前SCN
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
2373997
步骤五:手动触发日志切换检查点
SQL> alter system switch logfile;
系统已更改。
步骤六:查看日志切换后的数据文件头的SCN
SQL> select checkpoint_change#,checkpoint_time,checkpoint_count from v$datafile_header;
CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT
------------------ -------------- ----------------
2372527 03-3月 -08 646
2372527 03-3月 -08 609
2372527 03-3月 -08 646
......
已选择11行。
步骤七:查看日志切换后控制文件中的数据库信息节的日志切换检查点信息
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
2372527
步骤八:查看日志切换后控制文件中的数据文件节中的日志切换检查点信息
SQL> select checkpoint_change#,checkpoint_time,last_change#,last_time,substr(name,1,30) from v$datafile;
CHECKPOINT_CHANGE# CHECKPOINT_TIM LAST_CHANGE# LAST_TIME SUBSTR(NAME,1,30)
------------------ -------------- ------------ -------------- -----------------------------------------------
2372527 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
2372527 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
2372527 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
......
已选择11行。
--由于普通测试机的I/O并不繁忙,看到的数据很有可能是没有发生变化的,这个时候可以查看告警日志.发现
Mon Mar 03 19:50:35 2008
Beginning log switch checkpoint up to RBA [0x2c0.2.10], SCN: 2374009
Thread 1 advanced to log sequence 704
Current log# 9 seq# 704 mem# 0: E:\LOG9A.RDO
此时的日志切换还未完成,数据文件头的日志切换的检查点和控制文件的日志切换检查点还没来的急更新.少等一会就会完成.oracle会根据机器的繁忙程度来决定什么时候完成日志切换的检查点.通常如果机器比较繁忙,oracle趋向于更急切的完成日志切换检查点.
少等一会再次查看告警日志:
Mon Mar 03 19:50:35 2008
Beginning log switch checkpoint up to RBA [0x2c0.2.10], SCN: 2374009
Thread 1 advanced to log sequence 704
Current log# 9 seq# 704 mem# 0: E:\LOG9A.RDO
Mon Mar 03 19:53:58 2008
Completed checkpoint up to RBA [0x2c0.2.10], SCN: 2374009
可以发现除了beginning log switch chenkpoint外,多了一个completed checkpoint.日志切换的检查点到此才真正的完成.由于我的实验环境并不繁忙,oracle拖了3分钟才去真正的完成日志切换检查点.
此时再查看日志切换后的数据文件头的SCN
SQL> select checkpoint_change#,checkpoint_time,checkpoint_count from v$datafile_header;
CHECKPOINT_CHANGE# CHECKPOINT_TIM CHECKPOINT_COUNT
------------------ -------------- ----------------
2374009 03-3月 -08 647
2374009 03-3月 -08 610
2374009 03-3月 -08 647
......
再查看日志切换后控制文件中的数据库信息节的日志切换检查点信息
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
2374009
再查看日志切换后控制文件中的数据文件节中的日志切换检查点信息
SQL> select checkpoint_change#,checkpoint_time,last_change#,last_time,substr(name,1,30) from v$datafile;
CHECKPOINT_CHANGE# CHECKPOINT_TIM LAST_CHANGE# LAST_TIME SUBSTR(NAME,1,30)
------------------ -------------- ------------ -------------- ----------------------------------------------
2374009 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
2374009 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
2374009 03-3月 -08 E:\ORACLE\PRODUCT\10.2.0\ORADA
......
--从结果可以看出日志切换时的SCN是2373997,而视图中所显示的2374009比2373997大了12.这是因为手动查看SCN和手动切换日志这两个命令间有个时间差.(忽略不计).由此可以证明,在日志切换时,CKPT写进数据文件和控制文件中的SCN,是切换命令开始时的SCN.
在日志切换时,被写进数据文件头的并不只有SCN信息,还有RBA信息.这个RBA是新的连机重做日志文件第一条重做记录的RBA.根据告警日志中的信息,此处是RBA [0x2c0.2.10].上面所介绍的几个视图中,没有显示RBA信息.我们可以通过转储查看到这个RBA.
转储命令如下:
SQL> alter session set events 'immediate trace name file_hdrs level 10';
会话已更改。
转储数据文件头的结果:
DATA FILE #1:
(name #7) E:\ORACLE\PRODUCT\10.2.0\ORADATA\ONE10G\SYSTEM01.DBF
...
Checkpointed at scn: 0x0000.00243979 03/03/2008 19:50:35 [这些信息对应v$datafile_header]
thread:1 rba
0x2c0.2.10)
...
--在转储文件中的每个数据文件相关信息中,都可以找到如上两行,这其中检查点SCN和时间戳,我们都已经在视图中看到了.
RBA信息,告警日志中显示的有,上述3个视图中并未显示出来.
转储控制文件的结果:
这是控制文件中 数据库信息节中的日志切换检查点信息:
***************************************************************************
DATABASE ENTRY
***************************************************************************
...
Database checkpoint: Thread=1 scn: 0x0000.00243979[这些信息对应v$database]
...
这是控制文件中的数据文件记录节,可以看到日志切换检查点SCN.
DATA FILE #1:
(name #7) E:\ORACLE\PRODUCT\10.2.0\ORADATA\ONE10G\SYSTEM01.DBF
...
Checkpoint cnt:647 scn: 0x0000.00243979 03/03/2008 19:50:35 [这些信息对应v$datafile]
...
****在控制文件中,只记录日志切换时的SCN,不记录RBA.
oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html