调整日志机制 :调整日志缓存

调整日志缓存
·    日志缓存的管理机制可以类似理解成一个漏斗，日志数据不断地从漏斗上方加入，然后偶尔打开漏斗下方的开关将加入的数据清空，这个开关就是LGWR进程，为了日志缓存有空间容纳不断加进来的日志数据，LGWR在下面列出的任何一个条件下都会执行写出日志缓存的操作：
?nbsp;   应用程序发出Commit命令时；
?nbsp;   三秒间隔已到时；
?nbsp;   日志缓存三分之一满时；
?nbsp;   日志缓存达到1M时；
?nbsp;   数据库检查点发生时；
·    测量日志缓存的性能 通过服务器进程放置日志条到日志缓存时发生等待的次数和时间来测量；
?nbsp;   Select Name, Value
From V$sysstat
Where Name In ('redo entries', 'redo buffer allocation retries',
    'redo log space requests');
  redo entries 服务器进程放进日志缓存的日志条的总数量；
redo buffer allocation retries 服务器放置日志条时必须等待然后再重试的次数；
redo log space requests LGWR进程写出日志缓存时等待日志切换的次数；

  Select Retries.Value / Entries.Value "Redo log Buffer Retry Ratio"
   From V$sysstat Entries, V$sysstat Retries
  Where Entries.Name = 'redo entries'
   And Retries.Name = 'redo buffer allocation retries'
  这个查询用于计算日志缓存重试率，这个比率应该小于百分之一；
?nbsp;   Select s.Username, Sw.Wait_Time, Sw.Seconds_In_Wait, Sw.State
From V$session_Wait Sw, V$session s
Where Sw.Sid = s.Sid And Sw.Event Like '%log buffer space%';
这个查询用来显示哪些会话的LGWR正在进行写等待；
State有四个取值：WAITING(会话正在等待),WAITED UNKNOWN TIME(等待时间未知),WAITED SHORT TIME(等待时间小于百分之一秒),WAITED KNOWN TIME(等待时间已知，为wait_time栏位所示的时间);
?nbsp;   Statspack中有两个地方存有与日志缓存性能相关的数据：
实例命中率（Instance Efficiency Percentages）中的Redo NoWait%，这个值与日志缓存重试率之和等于1；
实例活动统计（Instance Activity Stats）中的redo entries, redo buffer allocation retries, redo log space requests；

·    改进日志缓存的性能
改进日志缓存的性能就是减少或者消除服务器进程读取日志缓存及放置日志条到日志缓存时发生的等待，可以从下面两个方面入手：
?nbsp;   增大日志缓存
ü    日志缓存由初始参数LOG_BUFFER指定，最小值是64K，默认值是greatest(512k , 128k * CPU数);
ü    当你指定的日志缓存小于最小值时，会以默认值来生效；
ü    日志缓存的最大值由操作系统来指定，考虑到LGWR写出日志缓存的特点，大于3M的日志缓存已没有多大实际意义；
?nbsp;   减少日志的产生：UNRECOVERABLE，NOLOGGING
ü    UNRECOVERABLE 这个关键字用在下面的语法中：create table table_a as select * from table_b unrecoverable; 在表创建的过程可以尽可能少地产生日志，但对该表的后续DML操作没有影响，也不能用于分区表，索引组织表，含有大对象的表的创建，这个关键字的功能已被nologging取代；
ü    NOLOGGING是表的一个属性，可以在表创建时指定，也可以在表创建以后用alter命令进行更改，这个属性可以从许多字典表（DBA_TABLESPACES， DBA_TABLES， DBA_INDEXES，DBA_LOBS等）的logging字段查到；
ü    启用该属性，可以在表创建，表上的索引创建及重建时产生较少的日志（DDL）；
ü    启用该属性，针对表上的数据插入，在以下两种情形下可以产生较少的日志（DML）：用SQL*Loader进行Direct Path Loads ，用append提示进行的Direct Load Inserts；
ü    启用该属性后，用direct path方法装入的数据将会在媒体恢复的过程中丢失，如果这些数据装载发生在最近一次备份操作之后的话。


第七章 调整日志机制 3.调整检查点


调整检查点
·    检查点事件代表在那个时刻数据库处于一致的状态，检查点之所以重要，是因为在实例失败后，只有发生在最后一个检查点之后事务需要恢复；有两种类型的检查点：增量检查点和完全检查点；
·    增量检查点是从ORACLE 8开始引入的，之前的版本只存在完全检查点，这个时候，所有的脏数据都要写回磁盘，巨大的I/O对系统性带来很大影响，而且在写出所有脏块的过程中会锁定数据缓存，写出完成之前再不能够产生新的脏块；和增量检查点相关的一个新的结构是检查点队列，这个队列中存放了所有按low RBA(第一次对此块修改对应的Redo Block Address)排序的脏块，每三秒，增量检查点去更新控制文件，记录当前检查点队列的最小的low RBA以及on-disk RBA(LGWR进程已经写入到日志文件的最后的日志位置)等信息，实例恢复的时候将从控制文件的low RBA开始，而不是从数据文件的Checkpoint SCN开始；
·    完全检查点发生时，会执行下面的动作：
?nbsp;   通知DBWn进程将所有的脏块写回磁盘；
?nbsp;   DBWn在写出脏块时如果发现对应的日志还在日志缓冲区，就触发LGWR写出日志条；
?nbsp;   检查点进程更新控制文件和数据文件头；
·    检查点的触发条件有下面一些：
?nbsp;   实例关闭（ABORT方式除外）；
?nbsp;   日志切换；
?nbsp;   用户触发：Alter System Checkpoint; Alter Tablespace … Begin Backup;
?nbsp;   初始参数FAST_START_MTTR_TARGET指定的值已超过（增量检查点）；
?nbsp;   日志文件长度的90%（增量检查点）；
?nbsp;   每三秒（增量检查点）；
·    完全检查点发生时，必须等到要求DBWn完成的任务完成后，检查点才能结束，增量检查点（FAST_START_MTTR_TARGET以及日志文件长度的90%）也会去建议DBWn应该尽快完成的任务，但不会强制触发DBWn，更不会等待其完成（看 ... 5023372后的理解）；
·    监控检查点的活动很重要，因为太多的检查点会增加不必要的I/O，太少的检查点会使数据库在实例恢复时经历过长的时间；
·    测量检查点性能有下面一些方法：
?nbsp;   Select n.Name, Se.Total_Waits, Se.Average_Wait
From V$system_Event Se, V$event_Name n
Where n.Name = Se.Event(+)
  And n.Name In
    ('checkpoint completed', 'log file switch (checkpoint incomplete)');

checkpoint completed等待检查点的完成;
log file switch (checkpoint incomplete) 如果紧接着的一个日志切换检查点发生，前面日志切换检查点尚未完成，这时，前面的检查点会终止，后面的检查点得从头再来，导致更多的I/O操作却不能缩短实例恢复的时间；
?nbsp;   Select *
From V$sysstat
Where Name In
    ('background checkpoints started', 'background checkpoints completed')；

  background checkpoints started 自实例启动以来开始过的检查点；
  background checkpoints completed自实例启动以来已经成功完成的检查点；
  这两个值的差异值或者差异值减一等于未完成的日志切换检查点；
?nbsp;   Statspack中与检查点性能相关的数据有：实例活动统计（Instance Activity Stats）的background checkpoints started 和background checkpoints completed；
?nbsp;   当出现日志切换检查点未完成事件时，报警日志文件中会有记录，大致的描述如下：Thread x cannot allocate new log, sequence y Checkpoint not complete;
?nbsp;   初始参数LOG_CHECKPOINTS_TO_ALERT置为TRUE时，每一个检查点的性息都可以在报警日志文件中找到；
·    调整检查点性能有下面两种方法（加大日志文件，调整初始参数）：
?nbsp;   每个日志切换时会发生完全检查点，加大日志文件可以使检查点的间隔更大些，以减少检查点未完成这个事件发生频率；
?nbsp;   增大日志文件方法是，先增加新的更大日志文件组，再删除小的日志文件组；
?nbsp;   为了在实例恢复性能以及检查点活动负担间达到平衡，调整日志文件大小，使日志切换的发生间隔在20到30分钟之间为宜；
?nbsp;   在9i中，ORACLE建议只需调整FAST_START_MTTR_TARGET这个参数，含义是实例失败时的平均恢复时间（秒），取值范围为0~3600，这个参数可以用Alter System语句动态改变，为零时取消这个功能，这个参数通常是用另两个参数来实现的：FAST_START_IO_TARGET（实例失败时的平均赃块数）, LOG_CHECKPOINT_INTERVAL（实例失败时的平均日志OS块数）；
?nbsp;   设置上面的参数后，可以用V$INSTANCE_RECOVERY这个视图观察效果：TARGET_MTTR（平均恢复时间，通常等于上面参数指定的值，如果因为服务器资源的限制可能稍大于上面的参数值） ESTIMATED_MTTR（评估的当前时刻实例失败后的恢复用时）；