图片 5

详解Oracle中的隐含参数_disable_logging_oracle_脚本之家

注意:Oracle的隐含参数只应该在测试环境或者在Oracle
Support的支持下使用。

Oracle通过Redo来实现快速提交,一方面是因为Redo Log
File可以连续、顺序地快速写出,另一个方面也和Redo记录的精简内容有关。

 原创 

从Oracle的系统表中,我们知道Oracle存在一个隐含参数_disable_logging可以用于禁用日志生成,这个参数显然只能用于测试目的,禁止日志生成必然导致事务的不可恢复性,而且会导致日志文件损坏。

两个概念:

   
 检查点的主要目的是以对数据库的日常操作影响最小的方式刷新脏块。脏块不断的产生,如何将脏块刷新到磁盘中去呢?在8i之前,Oracle定期的锁住所有的修改操作,刷新Buffer cache中的所有脏块,这种刷新脏块的方式被称为完全检查点,这极大的影响了效率,从9i之后只有当关闭数据库时才会发生完全检查点。

SQL> select ksppinm,ksppdesc from x$ksppi where ksppinm like '%logging';KSPPINM KSPPDESC-------------------- ------------------------------_disable_logging Disable logging

改变向量(Change
Vector)

     从8i开始,Oracle增加了增量检查点的概念,增量检查点的主要宗旨就是定期的刷新一部分脏块。将脏块一次刷新完是不合理的,因为脏块不断产生,没有穷尽。像完全检查点那样停止用户所有的修改操作,将脏块刷新完再继续,这绝对会极大的影响性能。所有增量检查点的一次刷新部分块是脏块问题的最好解决办法。那么,每次刷新时,都刷新那些块呢?根据统计研究,根据块变脏的顺序,每次刷新那些最早脏的块,这种方式最为合理。为了实现这一点,Oracle在Buffer cache中又建立了一个链表,就是检查点队列。每个块在它变脏时,会被链接到检查点队列的末尾。就好像排队一样,9:00来的人站在第一位,9:05来的人排第二位,以后每来一个人都站在队伍的末尾,这个队伍就是按来到的时间顺序排列的一个队列。检查点队列就是这样,块在变脏时会被链到末尾。因此检查点队列是按块变脏的时间顺序,将块排成了一个队列。

因为特殊的需要,对这个参数进行了一点简单测试:

改变向量表示对数据库内某一个数据块所做的一次变更。改变向量中包含了变更的数据块的版本号、事务操作代码、变更从属数据块的地址(DBA)以及更新后的数据。例如:一个update事务包含一系列的改变向量,对于数据块的修改是一个向量,对于回滚段的修改又是一个向量。

图片 1

1.设置参数

重做记录(Redo
Record)

   
 如上图,检查点队列中的每一节点,都指向一个脏块。检查点队列每个节点中的信息其实非常少,就是记录对应块在Buffer cache中的地址,脏块对应的重做记录在日志文件中的位置,另外还有前一个节点、后一个节点的地址。检查点队列还有LRU、脏LRU,这些都是双向链表。双向链表就是在节点中记录前、后两个节点的地址。

[oracle@jumper bdump]$ sqlplus "/ as sysdba"SQL*Plus: Release 9.2.0.4.0 - Production on Wed Oct 19 11:01:19 2005Copyright  1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - ProductionWith the Partitioning optionJServer Release 9.2.0.4.0 - ProductionSQL> alter system set "_disable_logging"=true scope=both;System altered.

重做记录通常由一组改变向量组成,是一个改变向量的集合,代表一个数据库的变更(INSERT、UPDATE、DELETE等操作),构成数据库变更的最小恢复单位。例如:一个Update的重做记录包括相应的回滚段的改变向量和相应的数据块的改变向量等。

   
 检查点队列头部的块是最早变脏的,因此,Oracle会定期唤醒DBWn从检查点队列头开始,沿着检查点队列的顺序,刷新脏块。在刷新脏块的同时,仍可以不断的有新的脏块被链接到检查点队列的尾部。这个定期唤醒DBWn刷新脏块的操作,Oracle就称为增量检查点。

2.事务测试

 

图片 2

SQL> create table t as select * from dba_users;Table created.SQL> select count---------- 12SQL> shutdown abort;ORACLE instance shut down.SQL> startupORACLE instance started.Total System Global Area 97588504 bytesFixed Size 451864 bytesVariable Size 33554432 bytesDatabase Buffers 62914560 bytesRedo Buffers 667648 bytesDatabase mounted.Database opened.SQL> select count from t;select count from t *ERROR at line 1:ORA-00942: table or view does not exist

假定发出一个更新语句:

     
如上图,1、2、3号节点所指向的脏块已经被刷新为干净块。同时,又有两个块变脏,它们被链接到了检查点队列的末尾,它们是9号、10号节点。

由于未产生相应日志,数据库crash或shutdown
abort之后,上一次成功完成的检查点之后变化的数据将无法恢复。

Update emp set
sal=4000 where empno=7788;

   
 检查点队列的头,又被称为检查点位置,Checkpoint postion,这些名称我们不必从字面上去理解。总之,检查点位置就是检查点队列头。检查点队列头节点(也就是检查点位置)的信息,Oracle会频繁的将它记录到控制文件中,而且会很频繁的记录。一般是每隔三秒,有一个专门的进程CKPT,会将检查点位置记录进控制文件。

3.观察alert文件

这个语句的执行如下所示:

图片 3

从日志中我们可以看到在instance
recovery中,没有数据被恢复,只有成功完成的上次检查点之前数据可以被获取,之后数据都将丢失。

  1. 检查empno=7788记录在Buffer
    Cache中是否存在,如果不存在则读取道Buffer
    Cache中;

  2. 在回滚段表空间的相应回滚段事务表上分配事务槽,这个操作需要记录Redo信息;

  3. 从回滚段读入或者在Buffer
    Cache中创建sal=3000的前镜像,这需要产生Redo信息并记入Redo Log
    Buffer;

  4. 修改sal=4000,这是update的数据变更,需要记入Redo Log
    Buffer;

  5. 当用户提交时,会在Redo Log
    Buffer记录提交信息,并在回滚段标记该事务为非激活。

   
 如上图,当前的检查点位置是检查点队列的1号节点。又一个三秒到了,CKPT进程启动,将新的检查点位置记入控制文件:

Wed Oct 19 20:38:38 2005Beginning crash recovery of 1 threadsWed Oct 19 20:38:38 2005Started first pass scanWed Oct 19 20:38:39 2005Completed first pass scan 0 redo blocks read, 0 data blocks need recoveryWed Oct 19 20:38:39 2005Started recovery at Thread 1: logseq 2, block 201, scn 0.897632464Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0 Mem# 0 errs 0: /opt/oracle/oradata/conner/redo01.logWed Oct 19 20:38:39 2005Completed redo applicationWed Oct 19 20:38:39 2005Ended recovery at Thread 1: logseq 2, block 201, scn 0.897652465 0 data blocks read, 0 data blocks written, 0 redo blocks readCrash recovery completed successfully

对于数据块的修改,如果执行写出,那么通常需要写出8KB的Block,而对于Redo日志来说,重做信息却相当精简,Oracle只需要记录那些重构事务必须的信息(如事务号、文件号、块号、行号、字段等)即可,这个数据量大大减少。

 图片 4

总结

 

   
 新的检查点位置是4号节点,它对应当前变脏时间最早的脏块。1、2、3号节点已经从检查点队列中摘除了。因为它们对应的脏块已经不脏了。一般来说,控制文件中的检查点位置之后的块都是脏块。但是有时也例外,因检查点位置每三秒才会更新一次,就像上图,1、2、3号节点对应的脏块已经被刷新过了,但是由于三秒间隔没到,检查点位置还是指向1号节点。只有当三秒到后,检查点位置才会被更新到4号节点上。

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流。

产生多少Redo

   
 关于检查点队列、检查点位置我们先说到这里,在全面的介绍什么是增量检查点之前,我们先说一下检查点队列的一个重要作用。

在SQL*Plus中使用autotrace功能

     让我们先来总结一下用户修改块时,Oracle内部都发生了什么:

当在SQL*Plus中启用autotrace跟踪后,在执行了特定的DML语句时,Oracle会显示该语句的统计信息,其中,Redo
size一栏表示的就是该操作产生的Redo的数量:

   
 1.如果块不在Buffer cache,将块读入Buffer cache

SQL> set
autotrace trace stat

   
 2.先生成重做记录,并记入日志缓存,在用户提交时写到日志文件中

SQL> insert
into test

     3.在Buffer cache中修改块

 2 select empno,ename
from scott.emp;

   
 4.在Buffer cache中设置块的脏标志位,标志块变成脏块,同时在检查点队列末尾增加一个新节点,记录这个新脏块的信息,信息包括:脏块在Buffer cache中的位置,在步骤2时生成的与此脏块对应的重做记录位置。

已创建12行。

   
 5.用户提交后,将相应的重做记录从重做缓存写入日志文件。

Statistics

   
 我现在将日志补充到上面的图中:


图片 5

       189 recursive
calls

 

         2 db block
gets

     
就像上图,检查点队列的每个节点,都保存有脏块的地址和脏块对应的重做记录的编号。脏块在Buffer cache中的位置是随机的,用户不一定修改那个块。但重做记录是顺序生成的,就和检查点队列的排列顺序一样。因为,它们都是当块被修改而变脏时产生的。块A先被修改,块A的重做记录就排在前面,块B后被修改,块B对应的重做记录会被排在块A对应的重做记录的后面。和它们在检查点中的顺序是一样。每当数据库因异外而当机,比如异常死机、断电等等,Buffer cache中有许多脏块没来的及写到磁盘上。以图为例,比如说现在断电了,现在磁盘上还有7个脏块,它们里面有用户修改过的数据,Oracle已经将反馈信息“你的修改完成”发送给用户,用户也以为他们的修改完成了,将为一直保存到数据库中。但是,断然的断电,令这几个脏块中的数据丢失了,它们没来得及写到磁盘上。

        37 consistent
gets

  
  Oracle如何解决这个问题呢?很简单,当数据库重新启动时,Oracle只需从控制文件中读出检查点位置,检查点位置中记录有重做记录编号,根据此编号,Oracle可以很快的定位到日志文件中的重做记录n,它读出重做记录n中的重做数据,将用户的修改操作重现到数据库。接着,Oracle读取重做记录n+1中的重做数据,重现用户修改,这个过程将沿着日志流的顺序,一直进行下去,直挡最后一条重做记录,在上图的例子中,最后一条重做记录是第n+6条。这个过程完成后,用户所有的修改又都被重现了,一点都不会丢失。只要你的日志文件是完整,日志流是完整的,就一点信息都不会丢失。

         4 physical
reads

   
 有人可能会有一个问题,重做记录在生成后,也是先被送进重做缓存,再由重做缓存写往日志文件。这样的机制下,一定会有某些重做记录在没来的及写到日志文件中时,数据库突然当机,而造成这些重做记录丢失。这样,这些重做记录所对应的脏块,将得不到恢复。用户还是会丢失一些数据。

       564 redo
size

   
 这种情况的确会发生,但丢失的都是没用的信息。为什么这么说的。Oracle会在用户每次发出提交命令时,将事务所修改脏块对应的重做记录写进日志文件,只有当这个操作完成时,用户才会收到“提交完成”,这样的信息,对于一个完整的事务,当用户看到提交完成后,也就意味着所对应的重做记录一定被写到了日志文件中,即使发生异常死机,它也是绝对可以恢复。而当用户没有提交,或没来得及提交,数据库就崩溃了,那么事务就是不完整的,这个事务必须被回滚,它根本用不着恢复。对于这样不完整的事务,它对应的重做记录有可能丢失,但这无所谓了,因为不完整的事务根本不需要恢复。也就是说,只有用户的事务提交了,用户的修改一定不会丢失。不过这还有一个前提,就是日志文件千万不能损坏,DBA所要做的就是要保证日志文件不能损坏。DBA可以使用RAID1这样的磁盘镜像技术,或者多元备份日志文件,等等,这个我们在前面章节中已经讲过了的。

       778 bytes sent
via SQL*Net to client

   
 我们上面所讲到的这种恢复,是自动进行的,并且不需要DBA参与,它被称之为实例恢复。

       823 bytes
received via SQL*Net from client

   
 检查点队列与增量检查点的作用我们已经说的差不多了,它们的主要目的就是让DBWn沿检查点队列的顺序刷新脏块。还有,就是实例恢复。

         4 SQL*Net
roundtrips to/from client

 

         1 sorts
(memory)

   
 下面我们来讨论一下增量检查点的设置。

         0 sorts
(disk)

 

        12 rows processed

   
 这里所说的检查点设置,主要指增量检查点频繁的设置。注意增量检查点只是一个名词,不必按字面的意义去理解它。增量检查点发生时,Oracle会唤醒DBWn沿着检查点队列写脏块,这就是增量检查点。那么到底多长时间一次发生一次增量检查点呢?这个增量检查点的频率是非常重要的,它基本上控制着DBWn多长时间去刷新一次脏块。DBWn活动的太频繁,会影响数据库的整体性能,如果DBWn活动太不频繁,又会使脏块挤压太多,这同样也会影响性能。而且,如果出现异常崩溃,需要实例恢复,脏块越多,实例恢复越慢。。在9i之前DBA主要靠间隔时间等方式来设置增量检查点的频率,比如可以让Oracle每10分钟发生一次增量检查点。如果这个数字设置不合适,对数据库性能的影响是很大的。而且有可能造成实例恢复时间过长。在9i之后,特别是到了10g中,检查点已经相当的智能化了,很少会成为I/O问题的原凶。9i中设置fast_start_mttr_target参数为你所期望的实例恢复时间,系统将自动控制增量检查点的频率。比如,你希望实例恢复可以在5分钟内完成,你可以将此参数设置为300,也就是300称。

 

   
 如果此参数设置的值超出了硬件实际的限制,比如你将它设置为60,你期望无论在任何情况下,数据库都可以在1分钟内完成实例恢复,但根据数据库的脏块生成速度、存储设备的写性能,1分钟内根本无法完成实例恢复。这时候Oracle会自动设置合适的fast_start_mttr_target参数值,我们可以在参数文件中看到修正后的参数值,也可以在V$instance_recovery视图中的Target_mttr列中看到实际的值。例如:

通过v$mystat查询:

     (举个例子)

Oracle通过v$mystat视图记录当前session的统计信息,也可以从该视图中查询得到session的Redo生成情况:

   
 我们不能将这个值设置的太小,因为实例恢复必竞只是偶然现象。如果为了让实例恢复尽快完成,而设置fast_start_mttr_target为很小的值,那么DBWn将活动的很频繁,这会造成性能问题的。
为了避免用户设置不合理的增量检查点频率,在10G中,如果将fast_start_mttr_target设置为0,Oracle将根据产生脏块的速度、存贮硬件的性能自动调节检查点的频率,尽量使检查点频率不成为I/O问题的原凶。

SQL> col
name for a30

   
 检查点的主要任务就是催促DBWn刷新脏块,如果DBWn刷新脏块时的等待事件太多,就说明脏块太多、存储设备的写速度太慢,或者就是增量检查点的频率太高了,或太低了。DBWn写脏块的等待事件是Db file parallel write。如果你的增量检查点频率很低,你发现了此事件,在排除了存储设备写性能的问题后,你应该将增量检查点频率设置的高一些。反之,如果你的增量检查点频率本身很高,出现了Db file parallel write事件,这说明检查点频率太高了。

SQL> select
a.name,b.value

   
 除它之外,还有一个和DBWn、增量检查眯有关的等待事件,它是Write complete waits事件,当前台进程要修改DBWn正要成批写的块中的若干个块时,就会有此等待事件,这个事件是前台进程再等待DBWn写完成。这个等待事太多,说明了存储设备写性能有问题,或者增量检查点太频率了。

 2 from v$statname
a,v$mystat b

 

 3 where
a.statistic#=b.statistic# and a.name=’redo size’;

   
 我们可以V$instance_recovery中看到有关检查点的很多信息:

 

 

NAME                               VALUE

   
 Estimated_mttr列如果太大,说明检查点不够频繁,同时也说明脏块产生的太多。同时在V$sysstat资料视图中,还有两个资料background checkpoints started、background checkpoints completed,前面的一个是后台进程检查点开始次数,后一个是后台进程检查点完成次数。后台进程检查点的意义,其实就是增量检查点。只有增量检查点是由后台进程触发的。如果你用Alter system checkpoing命令让系统完成完全检查点,这叫做前台检查点与增量检查点无关,是不会被记入这两个资料了。如果这两个值经常相差一些,比如检查点的开始次数比完成次数大的不至1,这说明有太多次检查点开始,但没有及时完成。这说明检查点太频繁或检查点完成的太慢。


   
 (举例,大量的产生脏块、日志文件比较小5MB,日志文件频率的切换而触发检查点,同时查看一下等待事件)


   
 检查点的问题大多数情况下其实都是DBWn写I/O的问题, DBWn写脏块的等待事件是Db file parallel write,还有Write complete waits等待事件,是当前台进程要修改DBWn正要成批写的块中的若干个块时,就会有此等待事件,这个事件是前台进程再等待DBWn写完成。这个等待事太多,也说明了DBWn有问题。

redo size                              5000

     注意,对于数据文件的I/O问题,除了等待事件外,我们还可以用上几节讲过了V$filestat视图帮助确定问题。)

 

SQL> insert
into test

 2 select empno,ename
from scott.emp;

已创建12行。

 

SQL> select
a.name,b.value

 2 from v$statname
a,v$mystat b

 3 where
a.statistic#=b.statistic# and a.name=’redo size’;

 

NAME                               VALUE



redo size                              5564

 

SQL> select
5564-5000 from dual;

 

 5564-5000


      564

 

通过v$sysstat查询:

对于数据库全局redo的生成量,可以通过v$sysstat视图来查询得到:

SQL> col
value for 999999999999

SQL> select
name,value from v$sysstat

 2 where name=’redo
size’;

 

NAME                                  VALUE



redo size                          11471552

 

从v$sysstat视图中得到的是自数据库实例启动以来累计日志生成量,可以根据实例启动时间来大致估算每天数据库的日志生成量:

SQL>
select

 2 (select
value/1024/1024/1024 from v$sysstat where name=’redo
size’)/