oracle 针对checkpoint的概要分析Word文档下载推荐.docx
《oracle 针对checkpoint的概要分析Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《oracle 针对checkpoint的概要分析Word文档下载推荐.docx（13页珍藏版）》请在冰豆网上搜索。
RBA就是重做日志块（redologblock）的地址，相当与数据文件中的ROWID，通过这个地址来定位重做日志块。
RBA由三个部分组成：
日志文件序列号（4字节）
日志文件块编号（4字节）
重做日志记录在日志块中的起始偏移字节数（2字节）
通常使用RBA的形式有：
LRBA
数据缓存（buffercache）中一个脏块第一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为LRBA。
HRBA
数据缓存（buffercache）中一个脏块最近一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为HRBA。
checkpointRBA
当一个checkpoint事件发生的时候，checkpoint进程会记录下当时所写的重做日志块的地址即RBA，此时记录的RBA被称为checkpointRBA。
从上一个checkpointRBA到当前的checkpointRBA之间的日志所保护的buffercache中的脏块接下来将会被写入到数据文件当中去。
BuffercheckpointQueues（BCQ）
Oracle将所有在数据缓存中被修改的脏块按照LRBA顺序的组成一个checkpoint队列，这个队列主要记录了buffercache第一次发生变化的时间顺序，然后有DBWn进程根据checkpoint队列顺序将脏块写入到数据文件中，这样保证了先发生变更的buffer能先被写入到数据文件中。
BCQ的引入是为了支持增量checkpoint的。
ActivecheckpointQueue（ACQ）
ACQ中包含了所有活动的checkpoint请求。
每次有新checkpoint请求是都会在ACQ中增加一条记录，ACQ记录中包含了相应的checkpointRBA。
checkpoint完成以后相应的记录将被移出队列。
完全检查点（normalcheckpoint）
完全检查点工作过程
一个checkpoint操作可以分成三个不同的阶段：
第一阶段，checkpoint进程开始一个checkpoint事件，并记录下checkpointRBA，这个通常是当前的RBA。
第二阶段，checkpoint进程通知DBWn进程将所有checkpointRBA之前的buffercache里面的脏块写入磁盘。
确定脏块都被写入磁盘以后进入到第三阶段，checkpoint进程将checkpoint信息（SCN）写入/更新数据文件和控制文件中。
更新SCN的操作由CKPT进程完成，在Oracle8.0之后CKPT进程默认是被启用的，如果CKPT进程没有启用的话那相应的操作将由LGWR进程完成。
什么时候发生normalcheckpoint
下面这些操作将会触发checkpoint事件：
日志切换，通过ALTERSYSTEMSWITCHLOGFILE。
DBA发出checkpoint命令，通过ALTERSYSTEMcheckpoint。
对数据文件进行热备时，针对该数据文件的checkpoint也会进行，ALTERTABLESPACETS_NAMEBEGINBACKUP/ENDBACKUP。
当运行ALTERTABLESPACE/DATAFILEREADONLY的时候。
SHUTDOWN命令发出时。
特别注意：
日志切换会导致checkpoint事件发生，但是checkpoint发生却不会导致日志切换。
日志切换触发的是normalcheckpoint，而不是大家所说的增量checkpoint，只不过logswitchcheckpoint的优先级非常低，当一个logswitchcheckpoint发生的时候它并不会立即的通知DBWn进程去写数据文件，但是当有其它原因导致checkpoint或者是写入数据文件的RBA超过logswitchcheckpoint的checkpointRBA的时候，这次的logswitchcheckpoint将会被标记成完成状态，同时更新控制文件和数据文件头。
我们随后可以做个实验验证这个说法。
checkpoint和SCN有什么关系?
在Oracle中SCN相当于它的时钟，在现实生活中我们用时钟来记录和衡量我们的时间，而Oracle就是用SCN来记录和衡量整个Oracle系统的更改。
Oracle中checkpoint是在一个特定的“时间点”发生的，衡量这个“时间点”用的就是SCN，因此当一个checkpoint发生时SCN会被写入文件头中以记录这个checkpoint。
增量checkpoint
增量checkpoint工作过程
因为每次完全的checkpoint都需要把buffercache所有的脏块都写入到数据文件中，这样就是产生一个很大的IO消耗，频繁的完全checkpoint操作很对系统的性能有很大的影响，为此Oracle引入的增量checkpoint的概念，buffercache中的脏块将会按照BCQ队列的顺序持续不断的被写入到磁盘当中，同时CKPT进程将会每3秒中检查DBWn的写入进度并将相应的RBA信息记录到控制文件中。
有了增量checkpoint之后在进行实例恢复的时候就不需要再从崩溃前的那个完全checkpoint开始应用重做日志了，只需要从控制文件中记录的RBA开始进行恢复操作，这样能节省恢复的时间。
发生增量checkpoint的先决条件
恢复需求设定（FAST_START_IO_TARGET/FAST_START_MTTR_TARGET）
LOG_checkpoint_INTERVAL参数值
LOG_checkpoint_TIMEOUT参数值
最小的日志文件大小
buffercache中的脏块的数量
增量checkpoint的特点
增量checkpoint是一个持续活动的checkpoint。
没有checkpointRBA，因为这个checkpoint是一直都在进行的，所以不存在normalcheckpoint里面涉及的checkpointRBA的概念。
checkpointadvancedinmemoryonly
增量checkpoint所完成的RBA信息被记录在控制文件中。
增量checkpoint可以减少实例恢复时间。
增量checkpoint相关参数设置
log_checkpoint_interval
设定两次checkpoint之间重做日志块（重做日志块和系统数据块是一样的）数，当重做日志块数量达到设定值的时候将触发checkpoint。
log_checkpoint_timeout
设定两次checkpoint之间的间隔时间，当超时值达到时增量checkpoint将被触发。
Oracle建议不用这个参数来控制，因为事务（transaction）大小不是按时间等量分布的。
将此值设置成0时将禁用此项设置。
fast_start_io_target
因为log_checkpoint_interval主要看的时候重做日志块的数量，并不能反应buffercache中脏数据块的修改，因此Oracle又引入了这个参数来实现当脏数据块达到一定数量的时候触发checkpoint，不过此参数实际上控制的是恢复时所需IO的数量。
fast_start_mttr_target
此参数是在9i中引入用来代替前面的三个参数的，它定义了数据块崩溃后所需要的实例恢复的时间，Oracle在实际上内在的解释成两个参数:
fast_start_io_target和log_checkpoint_interval.如果这两个参数没有显式的指定,计算值将生效.。
fast_start_mttr_target可以设定的最大值是3600，即一个小时。
它的最小值没有设限，但是并不是说可以设置一个任意小的值，这个值会受最小dirtybuffer（最小为1000）的限制，同时还会受初始化时间以及文件打开时间的限制。
在设置此参数的时候要综合考虑系统的IO，容量以及CPU等信息，要在系统性能和故障恢复时间之间做好平衡。
将此参数设置成0时将禁用fast-startcheckpointing，这样能见效系统负载但同时会增加系统的恢复时间。
如果fast_start_io_targetorlog_checkpoint_interval被指定，他们会自动覆盖由fast_start_mttr_target参数计算出来的值。
在10g中，数据库能根据各种系统参数的设置值来自动调整检查点的执行频率，以获得最好的恢复时间以及系统的正常运行影响最小。
通过自动checkpoint调整，Orach能在系统低IO操作的时候将脏块写入到数据文件中，因此即时DBA没有设置checkpoint相关的参数值或是设置了一个不合理的值的时候系统还是能获得一个很合理的系统恢复时间。
10g中的增量checkpoint更能体现它持续活动的特点，在10g中，增量checkpoint不是在某一个特定的条件下触发，而是由数据库根据系统参数设置自动触发。
与完全checkpoint的区别
完全checkpoint会将checkpoint的信息写入到控制文件以及数据文件头中
增量checkpoint只会将RBA信息写入到控制文件中。
查看系统的checkpoint动作
我们可以通过将LOG_checkpointS_TO_ALERT设置成TRUE来打开checkpoint的trace，这样就可以跟踪checkpoint的操作了。
ALTERSYSTEMSETLOG_checkpointS_TO_ALERT=TRUE;
这设置以后系统的checkpoint将会被记录alert_$SID.log文件中。
在V$DATAFILE_HEADER里面也保存了发生完全checkpoint的时候一些相关信息，包括checkpoint发生时间、对应SCN已经checkpoint的次数。
selectfile#NO,status,tablespace_name,name,dbms_flashback.get_system_change_numberCUR_SCN, to_char（resetlogs_time,'
YYYY-MM-DDHH24:
MI:
SS'
）RST_DT,resetlogs_change#RST_SCN,
to_char（checkpoint_time,'
）CKPT_DT,checkpoint_change#CKPT_SCN,checkpoint_countCKPT_CNT
fromv$datafile_header;
/**
NOSTATUSTABLESPACE_NAMECUR_SCNRST_DTRST_SCNCKPT_DTCKPT_SCNCKPT_CNT
----------------------------------------------------------------------
1ONLINESYSTEM5335412008-01-1216:
51:
534460752008-08-0422:
03:
5853235465
2ONLINEUNDOTBS15335412008-01-1216:
5853235428
3ONLINESYSAUX5335412008-01-1216:
4ONLINEUSERS5335412008-01-1216:
5853235464
5ONLINEEXAMPLE5335412008-01-1216:
5853235424
*/
完全检查点
--我们先执行一个
ALTERSYSTEMcheckpoint;
--下面是alert文件中的数据结果
MonAug422:
22:
082008
BeginningglobalcheckpointuptoRBA[0x8.c9d4.10],SCN:
533714
CompletedcheckpointuptoRBA[0x8.c9d4.10],SCN:
--我们能看到完全checkpoint发生的SCN533714
--下面我们再对照下V$DATAFILE_HEADER中的结果
NOSTATUSTABLESPACE_NAMECUR_SCNRST_DTRST_SCNCKPT_DTCKPT_SCNCKPT_CNT
1ONLINESYSTEM5337902008-01-1216:
0853371466
2ONLINEUNDOTBS15337902008-01-1216:
0853371429
3ONLINESYSAUX5337902008-01-1216:
4ONLINEUSERS5337902008-01-1216:
0853371465
5ONLINEEXAMPLE5337902008-01-1216:
0853371425
--看到了么，checkpoint时间和checkpoint的SCN已经被记录到数据文件头中了。
日志切换时的检查点
--我们先做一次日志切换
ALTERSYSTEMSWITCHLOGFILE;
--然后看看alert里面的记录
31:
392008
BeginninglogswitchcheckpointuptoRBA[0x9.2.10],SCN:
534450
Thread1advancedtologsequence9
Currentlog#2seq#9mem#0:
/u/app/oracle/oradata/orcl/redo02.log
MonAug422:
35:
582008
CompletedcheckpointuptoRBA[0x9.2.10],SCN:
--我们能看到checkpoint是在过了一段时间（这里是4分钟）之后才完成的
--接着我们来看下V$DATAFILE_HEADER中的结果
1ONLINESYSTEM5347702008-01-1216:
4453445067
2ONLINEUNDOTBS15347702008-01-1216:
4453445030
3ONLINESYSAUX5347702008-01-1216:
4ONLINEUSERS5347702008-01-1216:
4453445066
5ONLINEEXAMPLE5347702008-01-1216:
4453445026
--在这里我们能发现下V$DATAFILE_HEADER里面记录的SCN和日志切换发生的checkpoint的SCN是一样的，
--这就证明了日志切换是会更新数据文件头的，同时日志切换的checkpoint是一个级别比较低的操作，
--它不会立即完成，这也是出于性能上考虑的。
增量checkpoint查看
--下面是当LOG_checkpoint_TIMEOUT设置为1800s的时候所产生的增量checkpoint记录
SunAug319:
08:
562008
IncrementalcheckpointuptoRBA[0x8.e17.0],currentlogtailatRBA[0x8.1056.0]
SunAug319:
39:
002008
IncrementalcheckpointuptoRBA[0x8.1be0.0],currentlogtailatRBA[0x8.1c6e.0]
SunAug320:
09:
042008
IncrementalcheckpointuptoRBA[0x8.2af5.0],currentlogtailatRBA[0x8.2b6a.0]
072008
IncrementalcheckpointuptoRBA[0x8.3798.0],currentlogtailatRBA[0x8.3851.0]
SunAug321:
102008
IncrementalcheckpointuptoRBA[0x8.47b9.0],currentlogtailatRBA[0x8.48bb.0]
142008
IncrementalcheckpointuptoRBA[0x8.548d.0],currentlogtailatRBA[0x8.5522.0]
MonAug421:
05:
182008
top查看fast_start_mttr_target
通过查看V$INSTANCE_RECOVERY动态性能视图可以查看一些MTTR相关的信息。
SELECTTARGET_MTTR,ESTIMATED_MTTR,CKPT_BLOCK_WRITES,CKPT_BLOCK_WRITESFROMV$INSTANCE_RECOVERY
TARGET_MTTR
用户设置的参数FAST_START_MTTR_TARGET的值.
ESTIMATED_MTTR
根据目前脏块数目和日志块数目,评估的现在进行恢复所需要的时间.
CKPT_BLOCK_WRITES
检查点写完的块数目.
额外的因为检查点引起的数据库写入操作（因为不必要的检查点的产生,设置一个非常小的系统恢复时间将会对性能产生负面影响,为了帮助管理员监测这个参数设置较小时对数据库的影响,这个视图显示了这个列）
相关视图
V$视图
V$DATAFILE_HEADER
查看数据文件的完全checkpoint信息。
V$INSTANCE_RECOVERY
查看fast_start_mttr_target设置以及系统MTTR相关信息。
X$视图
X$BH
用于查看脏块的LRBA和HRBA（ThereisalsoarecoveryRBAwhichisusedtorecordtheprogressofpartialblockrecoverybyPMON.）。
X$TARGETRBA
查看增量checkpointRBA，targetRBA和on-diskRBA。
X$KCCCP
这里面也有增
升级会员 