redo重做日志文件是Oracle数据库的非常重要的组成部分。当日志文件发生切换时（Log Switch），会触发一个检查点，那么日志文件的大小就和检查点的触发频率相关。更为频繁的检查点可以缩短数据库的恢复时间，但是过于频繁的检查点却会带来性能负担。所以如何合理地设置日志文件的大小也是数据库优化的一个重要内容。而且，如果日志文件意外损失或丢失，那么就会丢失数据，所以更大的日志文件可能意味着更多的数据损失风险。所以数据库的任何一个调整都需要慎重。
即使是Oracle公司，在对于日志的设置上，也是在不断调整，在大小、切换、恢复时间、数据损失等问题上，Oracle也在试图找到一个平衡点。一般来说，在实际生产环境中，把Log Switch的时间控制在半小时左右即可；对于通常的操作系统来说，日志文件的最大大小为2GB，在非常繁忙的业务系统中，由于受限于日志大小，调整、优化都只是一个选择而已。
Oracle版本
缺省的redo log file大小(单位：MB)
8i
1
9iR2
100
10gR1
10
10gR2
50
11g
50
以通用的Oracle10.2.0.4版本为例，Oracle建库的时候自动创建3个日志文件组，每个日志文件组包含一个日志文件，初始大小50M，在实际运行过程中可能切换频繁导致性能下降，这时候可以增大其大小，方法如下：加入新的大的日志文件，然后删掉旧的小的日志文件。例如，现有三个日志组，每个组内有一个成员，每个成员的大小为50MB，现在要把此三个日志组的成员大小都改为100MB，下面我将演示一下操作过程。
1.查看现有日志组及其文件大小；
点击(此处)折叠或打开
-
SQL>
-
SQL> select group#,sequence#,status,bytes/1024/1024 from v$log;
-
-
GROUP# SEQUENCE# STATUS BYTES/1024/1024
-
---------- ---------- ---------------- ---------------
-
1 7 INACTIVE 50
-
2 8 INACTIVE 50
-
3 9 CURRENT 50
-
- SQL>
点击(此处)折叠或打开
-
SQL>
-
SQL> alter database add logfile group 4(\'/u01/app/oracle/oradata/HOEGH/redo04.log\') size 100M;
-
-
Database altered.
-
-
SQL> alter database add logfile group 5(\'/u01/app/oracle/oradata/HOEGH/redo05.log\') size 100M;
-
-
Database altered.
-
- SQL>
点击(此处)折叠或打开
-
SQL>
-
SQL> alter system checkpoint;
-
-
System altered.
-
-
SQL> alter system switch logfile;
-
-
System altered.
-
-
SQL> alter system checkpoint;
-
-
System altered.
-
-
SQL> alter system switch logfile;
-
-
System altered.
-
- SQL>
点击(此处)折叠或打开
-
SQL>
-
SQL> alter database drop logfile group 1;
-
-
Database altered.
-
-
SQL> alter database drop logfile group 2;
-
-
Database altered.
-
-
SQL> alter database drop logfile group 3;
-
-
Database altered.
-
- SQL>
点击(此处)折叠或打开
-
SQL>
-
SQL> alter database add logfile group 1(\'/u01/app/oracle/oradata/HOEGH/redo01.log\') size 100M;
-
-
Database altered.
-
-
SQL> alter database add logfile group 2(\'/u01/app/oracle/oradata/HOEGH/redo02.log\') size 100M;
-
-
Database altered.
-
-
SQL> alter database add logfile group 3(\'/u01/app/oracle/oradata/HOEGH/redo03.log\') size 100M;
-
-
Database altered.
-
- SQL>
点击(此处)折叠或打开
-
SQL>
-
SQL> alter system checkpoint;
-
-
System altered.
-
-
SQL> alter system switch logfile;
-
-
System altered.
-
-
SQL> alter system checkpoint;
-
-
System altered.
-
-
SQL> alter system switch logfile;
-
-
System altered.
-
-
SQL> alter system checkpoint;
-
-
System altered.
-
-
SQL> alter system switch logfile;
-
-
System altered.
-
- SQL>
点击(此处)折叠或打开
-
SQL>
-
SQL> alter database drop logfile group 4;
-
-
Database altered.
-
-
SQL> alter database drop logfile group 5;
-
- Database altered.
点击(此处)折叠或打开
-
SQL> alter database backup controlfile to trace resetlogs;
-
-
Database altered.
-
- SQL>
点击(此处)折叠或打开
-
SQL>
-
SQL> select group#,sequence#,status,bytes/1024/1024 from v$log;
-
-
GROUP# SEQUENCE# STATUS BYTES/1024/1024
-
---------- ---------- ---------------- ---------------
-
1 12 INACTIVE 100
-
2 13 INACTIVE 100
-
3 14 CURRENT 100
-
- SQL>
另外，介绍一下重做日志的状态，最常见的状态有以下几种：CURRENT,ACTIVE,INACTIVE,UNUSED。
CURRENT
CURRENT指的是当前日志，该日志文件是活动的，当前正在被使用的，在进行崩溃恢复时，Current的日志文件是必须的。
ACTIVE
ACTIVE的日志是活动的非当前日志，该日志可能已经完成归档也可能没有归档，活动的日志文件在Crash恢复时会被用到。
ACTIVE状态意味着，检查点尚未完成，如果日志文件循环使用再次到达该文件，数据库将处于等待的停顿状态。
引起Checkpoint incomplete可能有以下多种原因：
l 日志文件过小，切换过于频繁；
l 日志组太少，不能满足正常事务量的需要；
l 日志文件所在磁盘I/O存在瓶颈，导致写出缓慢，阻塞数据库正常运行；
l 由于数据文件磁盘I/O瓶颈，DBWR写出过于缓慢；
l 由于事务量巨大，DBWR负荷过高，不堪重负。
针对不同的原因，可以从不同角度着手解决问题：
l 适当增加日志文件大小；
l 适当增加日志组数；
l 使用更快速磁盘存储日志文件（如采用更高速转速磁盘；使用RAID10而不是RAID5等方式）；
l 改善磁盘I/O性能；
INACTIVE
INACTIVE的日志是非活动日志，该日志在实例恢复时不再需要，但是在介质恢复时可能会用到。INACTIVE状态的日志可能没有被归档。如果数据库启动在归档模式，在未完成归档之前，日志文件也不允许被覆盖，这时候活动进程会处于log file switch（archiving needed）等待之中。
UNUSED
UNUSED是指该日志从未被写入，这类日志可能是刚被添加到数据库或者在RESETLOGS之后被重置。被使用之后，该状态会被改变。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30162081/viewspace-1587281/ ，如需转载，请注明出处，否则将追究法律责任。
