Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1853136
  • 博文数量: 334
  • 博客积分: 11301
  • 博客等级: 上将
  • 技术积分: 3452
  • 用 户 组: 普通用户
  • 注册时间: 2006-10-18 10:19
个人简介

路虽弥,不行不至;事虽少,不做不成。

文章分类

全部博文(334)

文章存档

2013年(4)

2012年(19)

2011年(27)

2010年(71)

2009年(45)

2008年(15)

2007年(84)

2006年(69)

分类: Oracle

2007-05-09 13:10:47

Redologs Mechanism
 

How redo logs work
. Redo logs are used in a cyclic fashion
. When a redo log file is full,LGWR will move to the next log group
  -this is called a log switch
       
alter system switch logfile;       <---forcing log switch
 
  -checkpoint operation also occurs
    
alter system checkpoint;
       
       >FAST_START_MTTR_TARGET            1
       >FAST_START_TO_TARGET               2
       >LOG_CHECKPOINT_TIMEOUT            3
     
     注意:若使用1,则2,3就要disable;
 
  -information is written to the control file
 
 
Adding online redo log groups and redo log members
 
  alter database add logfile group 5
             ('$ORACLE_HOME/oradata/u01/log5a.log  REUSE',
              '$ORACLE_HOME/oradata/u02/log5b.log  REUSE',
              '$ORACLE_HOME/oradata/u03/log5c.log  REUSE') size 3m;
 
 
  alter database add logfile member
              '$ORACLE_HOME/oradata/u04/log5d.log' REUSE to group 5
 
  说明:注意比较上面两例中REUSE中的用法
 
 
Dropping  online redo log groups and redo log members
 
  alter database drop logfile group 5;
 
  alter database drop logfile member
                   '$ORACLE_HOME/oradata/u04/log5d.log'
 
说明:
   1.当前日志组或日志成员(状态为current)不能删除,如果删除,只有先切换,再删除;
   2.这里指的删除是逻辑删除,物理文件还是存在的,可重新使用
 
Renaming(relocating) online redo log files
 
  alter database rename file '$ORACLE_HOME/oradata/u04/log5d.log'
                          to '$ORACLE_HOME/oradata/u04/log5E.log'
 
  alter database rename file '$ORACLE_HOME/oradata/u04/log5d.log'
                          to '$ORACLE_HOME/oradata/u03/log5d.log'
 
说明:前提条件是DATABASE是在mount状态,而非open状态
 
 
Archived(automatic) redo log files
  .setup parameter
     log_archive_start=TRUE (initialization)  --要编辑pfile
     log_archive_format=%t_%s.arc
     log_archive_dest_1='$ORACLE_HOME/oradata/u01'
     log_archive_dest_2='$ORACLE_HOME/oradata/u02'
        
alter system set log_archive_format=%t_%s.arc;
alter system set log_archive_dest_1='$ORACLE_HOME/oradata/u01' scope=spfile;
alter system set log_archive_dest_2='$ORACLE_HOME/oradata/u02' scope=spfile;
 
  .archivelog database (in mount)
   
alter database archivelog;
 
  .open database     
 
alter database open;
 
  

 
3. Parameters related to incremental checkpointing
Note: Log file switches will always override checkpoints caused by following paarameters.
  • FAST_START_MTTR_TARGET
    Since Oracle 9i FAST_START_MTTR_TARGET parameter is the preferred method
    of tuning incremental checkpoint target. FAST_START_MTTR_TARGET enables you
    to specify the number of seconds the database takes to perform crash recovery
    of a single instance. Based on internal statistics, incremental checkpoint
    automatically adjusts the checkpoint target to meet the requirement of
    FAST_START_MTTR_TARGET.
    V$INSTANCE_RECOVERY.ESTIMATED_MTTR shows the current estimated mean time to
    recover (MTTR) in seconds. This value is shown even if FAST_START_MTTR_TARGET
    is not specified.
    V$INSTANCE_RECOVERY.TARGET_MTTR shows the effective MTTR target in seconds
    enforced by the system.
    V$MTTR_TARGET_ADVICE shows the number of I/Os resulted by the current workload
    under the current MTTR setting and the estimated number of I/Os that would be
    resulted by the current workload under other MTTR settings. This view helps
    the user to assess the trade-off between runtime performance and setting
    FAST_START_MTTR_TARGET to achieve better recovery time.

  • LOG_CHECKPOINT_INTERVAL
    LOG_CHECKPOINT_INTERVAL parameter specifies the maximum number of redo blocks
    the incremental checkpoint target should lag the current log tail.
    If FAST_START_MTTR_TARGET is specified, LOG_CHECKPOINT_INTERVAL should not
    be set or set to 0.
    On most Unix systems the operating system block size is 512 bytes.
    This means that setting LOG_CHECKPOINT_INTERVAL to a value of 10,000 would
    mean the incremental checkpoint target should not lag the current log tail
    by more than 5,120,000 (5M) bytes. .  If the size of your redo log is 20M, you are taking 4
    checkpoints for each log.

    LOG_CHECKPOINT_INTERVAL influences when a checkpoint occurs, which means
    careful attention should be given to the setting of this parameter, keeping it
    updated as the size of the redo log files is changed.  The checkpoint
    frequency is one of the factors which impacts the time required for the
    database to recover from an unexpected failure.  Longer intervals between
    checkpoints mean that if the system crashes, more time will be needed for the
    database to recover.  Shorter checkpoint intervals mean that the database will
    recover more quickly, at the expense of increased resource utilization during
    the checkpoint operation.

    This parameter also impacts the time required to complete a database recovery
    operation during the roll forward phase of recovery.  The actual recovery time
    is dependent upon this time, and other factors, such as the type of failure
    (instance or system crash, media failure, etc.), and the number of archived
    redo logs which need to be applied.


  • LOG_CHECKPOINT_TIMEOUT
    The LOG_CHECKPOINT_TIMEOUT parameter specifies the maximum number of seconds
    the incremental checkpoint target should lag the current log tail.
    In another word, it specifies how long a dirty buffer in buffer cache can
    remain dirty.

    Checkpoint frequency impacts the time required for the
    database to recover from an unexpected failure.  Longer intervals between
    checkpoints mean that more time will be required during database recovery.

    Oracle recommends using LOG_CHECKPOINT_INTERVAL to control the checkpoint
    interval rather than LOG_CHECKPOINT_TIMEOUT, which will initiate a checkpoint
    every "n" seconds, regardless of the transaction frequency.  This can cause
    unnecessary checkpoints in cases where transaction volumes vary.  Unnecessary
    checkpoints must be avoided whenever possible for optimal performance.

    It is a misconception that setting LOG_CHECKPOINT_TIMEOUT to a given
    value will initiate a log switch at that interval, enabling a recovery
    window used for a stand-by database configuration.   Log switches cause a checkpoint,but a checkpoint does not cause a log switch.  The only way to cause a log switch is manually with
    ALTER SYSTEM SWITCH LOGFILE or resizing the redo logs to cause
    more frequent switches.  This is controlled by operating system
    blocks, not a timed interval.
    Sizing of the online redo logs is critical for performance and recovery.
    See additional sections below on redo logs and checkpoints.


  • LOG_CHECKPOINTS_TO_ALERT
    LOG_CHECKPOINTS_TO_ALERT lets you log your checkpoints to the alert file.
    Doing so is useful for determining whether checkpoints are occurring at
    the desired frequency.
    Prior to Oracle9i this parameter was STATIC.
    Oracle generally advises this be set to TRUE as the overhead is
    negligible but the information in the alert log may be useful.
 
 
 
 
阅读(926) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~