分类：
2008-11-01 15:24:21
重做日志文件是Oracle数据库中一种非常重要的日志文件，也是其一个很有特色的功能。重做日志文件会纪录对于数据库的任何操作，如利用DML语句或者DDL语句对数据进行更改，或者数据库管理员对数据库结构进行更改，都会在重做日志中进行记录。
可见，当数据被意外的删除或者修改，我们可以利用重新日志文件进行恢复; 当出现例程失败或者介质失败的情况下，也可以利用日志文件实现例程恢复或者介质恢复。所以说，我们若能够管理好重做日志文件的话，对于保障数据库数据的安全是非常重要的。
一：重做日志文件的结构体系：
Ø 重做日志分为多个组，最少要两个组；每组有一个或多个成员。一般建议同一组中至少有两个成员，且分布在不同的物理磁盘上面。
Ø Redo Log Files以组的形式组织在一起
Ø 每个数据库至少要有2个组
Ø 每个组至少要有2个成员，每个成员的大小和内容都完全相同，冗余保证安全
Ø 在某个时间点上，只有一个组处于online状态（即数据库现在使用的是这个组）
Ø LGWR向当前online组的所有成员同时写入相同的redo log信息
二：相关参数：
Ø DB_CREATE_ONLINE_LOG_DEST_n：指定log file的存储目录
Ø LOG_ARCHIVE_DEST_n：指定归档日志的存储目录
Ø MAXLOGFILES：指定最多的日志组数目，在create database时用到，其最大值和默认值取决于OS
Ø MAXLOGMEMBERS：指定一个组最多有多少成员，在create database时用到
Ø FAST_START_MTTR_TARGET：指定数据库进行崩溃恢复需要的秒数，当为0值时表示自动检查点调整生效。这个参数是一个阀值, 系统会监控这个参数当前的实际值, 达到(或者接近)这个目标值的时候, 系统就会触发ckpt 检查点, 触发dbwr来写数据, 以保持checkpoint queue的长度与这个参数的长度一致.。因为当这个参数的值较小的时候, 这个触发就比较频繁, ckpt进程,dbwr进程比较繁忙, 同时系统的恢复时间相对也就可以控制的比较短.
Ø FAST_START_IO_TARGET：控制了需要被恢复的数据块数目
Ø LOG_CHECKPOINT_TIMEOUT：限制了上一检查点和最近的重做记录之间的秒数，但它对于设置恢复时间限制来说都是不够精确的。
Ø LOG_CHECKPOINT_INTERVAL：设定了恢复过程中将要被读的重做记录的数目
Ø LOG_CHECKPOINT_TO_ALERT：其值为TRUE或FALSE，当为TRUE时，系统发生Log Switch checkpoint时，相关信息被写入alert文件中。
三：工作原理：
Oracle Server记录所有的数据库变化到redo log的缓冲区中，然后由LGWR从缓冲区写入文件。
Ø 以循环方式（cyclic fashion）工作
Ø 日志切换（Log Switch）：当一个日志文件（组）写满时，LGWR将会移到下一个组开始写工作
Ø 日志切换时，发生checkpoint，相关infomation会被写到控制文件，并且会更新数据文件的头部信息
Ø 当所有日志组都被写满时，如果你的数据库是archive模式，则触发archive进程，实行日志归档；如果你的数据库是noarchive模式，则会直接切到下一个日志，覆盖日志内容重新开始新一轮循环。
1. 有事务提交
2. 重做日志缓冲区1/3满
3. 重做缓冲区中有超过
4. 在DBWn写入数据到数据文件前
Ø CHECKPOINT发生时：
1. 数据库的脏块别写入到数据文件
2. CKPT为所有的控制文件和数据文件头部的序列号
Ø 在如下情形，发生CHECKPOINT
1. 每次的log 切换
2. 实例被关闭，用abort参数的除外
3. 设置参数FAST_START_MTTR_TARGET
4. DBA强制要求
5. alter tablespace 发生时候，强制对某些特定的数据文件进行CHECKPOINT
四：相关操作：
Ø 日志切换可以使用命令行强制执行：ALTER SYSTEM SWITCH LOGFILE;
当你的日志组都写完以后，LGWR 试图写第一个log file，如果这时数据库没有完成写出记录在第一个log file 中的dirty 块时（例如第一个检查点未完成），该等待事件出现。
该等待事件通常表示你的DBWR 写出速度太慢或者IO 存在问题。
为解决该问题，你可能需要考虑增加额外的DBWR 或者增加你的日志组或日志文件大小。
1.强制日志切换：ALTER SYSTEM SWITCH LOGFILE
2.强制checkpoint：
设置参数FAST_START_MTTR_TARGET的值
命令：ALTER SYSTEM CHECKPOINT
3.Sizing Log File:
Minimum size : 50KB
Maximum size : depend on the OS
每个组的大小可以不同，但是同个组的每个成员肯定相同
改变大小的方法：create new + remove old
Ø Querying:
V$LOG : 反应日志组的信息
---------------------------------------------------------------
SQL> SELECT * FROM V$LOG;
|
GROUP# |
THREAD# |
SEQUENCE# |
BYTES |
MEMBERS |
ARCHIVED |
STATUS |
FIRST_CHANGE# |
FIRST_TIME |
|
1 |
1 |
2 |
52428800 |
1 |
NO |
INACTIVE |
565180 |
13-5月-07 |
|
2 |
1 |
3 |
52428800 |
1 |
NO |
CURRENT |
578116 |
13-5月-07 |
|
3 |
1 |
1 |
52428800 |
1 |
NO |
INACTIVE |
534907 |
13-5月-07 |
---------------------------------------------------------------
STATUS的值说明：
UNUSED：表示日志从未使用过，即新日志组。
CURRENT：表示当前正在使用该组。
ACTIVE：表示活动日志组，即脏缓存块还没有完全写入数据文件。
CLEARING：表示该日志组是“正在被”（is being）被clear的re-created的，空的内容，在日志组被cleared以后，status就变为UNUSED。
CLEARING_CURRENT：显示that the current log file is being cleard of a closed thread. The log can stay in this stay in this status if there is some failure in the switch ,such as an I/O error writing the new log header.
INACTIVE：表示非活动组，即所有信息都已经归档
Ø V$LOGFILE : 反应日志成员的信息
---------------------------------------------------------------
SQL> SELECT * FROM V$LOGFILE;
|
GROUP# |
STATUS |
TYPE |
MEMBER |
IS_RECOVERY_DEST_FILE |
|
3 |
|
ONLINE |
D:ORACLE_DB_HOMEORADATAORCLREDO03.LOG |
NO |
|
2 |
|
ONLINE |
D:ORACLE_DB_HOMEORADATAORCLREDO02.LOG |
NO |
|
1 |
|
ONLINE |
D:ORACLE_DB_HOMEORADATAORCLREDO01.LOG |
NO |
|
1 |
|
ONLINE |
D:ORACLE_DB_HOMEORADATAORCLREDO01_1.LOG |
NO |
|
2 |
|
ONLINE |
D:ORACLE_DB_HOMEORADATAORCLREDO02_1.LOG |
NO |
|
3 |
|
ONLINE |
D:ORACLE_DB_HOMEORADATAORCLREDO03_1.LOG |
NO |
---------------------------------------------------------------
STATUS值说明：
INVALID：显示该文件处于不可访问状态。
STALE：显示该文件的内容是不完整的（incomplete）。
DELETED：显示该文件将不再使用（is no longer used）。
Blank Space：空的内容表示这个文件现在正在使用（in use）。
五：归档日志（Archive Log）：
Ø 在mount阶段可以改变数据库的归档模式：alter database archivelog/noarchivelog
Ø 两种归档方式：1 手动Manually ； 2 自动Automatically（推荐）
Ø 即使在自动归档方式下，dba也可以通过sql命令强制归档一个日志组
Ø 参数LOG_ARCHIVE_START显示归档方式是自动（TRUE）或手动（FALSE）；TRUE表示ARCn进程当日志写满发生log switch时自动归档写满的日志；FALSE表示需要DBA手工归档要发生log swtich的写满信息的log file。
Ø 当成功归档后，在控制文件中会记录下列信息：the archive log name, log sequence number (of the just be archived log file), high and low SCN number.
六. 管理好Oracle 数据库日志文件的几点经验技巧
Ø 合理确定重做日志文件的存放位置
我们知道，当数据库内部数据丢失或者被意外更改的情况下，数据库管理员可以利用重做日志文件实现数据库数据的恢复工作。当数据库出现意外事故，如硬盘物理损坏、数据丢失时怎么办?
我们第一个就会想到利用数据库重做日志对数据进行恢复。可是当数据库重做日志跟数据库数据文件放在同一个硬盘的话，很明显，当硬盘损坏的时候，数据文件将跟日志文件共赴黄泉。此时，连天皇老子都救不了我们。
所以，此时，我们就有必要把重做日志文件跟数据库数据文件放在两个不同的硬盘上面。此时，任何一个硬盘若发生损坏，我们都可以凭借另外一块硬盘的数据，来挽回损失。如存放数据文件的硬盘损坏时，我们就可以利用存放在另外一块硬盘上的数据重做日志文件进行修复，挽回损失。
鸡蛋不能放在同一个篮子里，故重做日志文件与数据文件也不要放在同一块硬盘上。那时非常危险一个动作。
其实，这个重做日志文件就跟数据库的备份文件类似。我们在对数据库进行备份的时候，都知道需要进行异地备份。可惜的是，很多数据库管理员，在进行Oracle 数据库管理的时候，没有注意到这一点，结果当出现问题的时候，就来不及了。故，对于数据重做日志文件，保存时，要跟数据库备份文件一样，进行异地保存。
Ø 合理设置数据库的归档模式。
因为数据重做日志会纪录数据库所有的修改动作，所以，当数据库频繁修改时，如那些ERP系统需要频繁对数据库进行修改操作，此时，数据库的重做日志文件就会很庞大。为了便于日志文件的管理，Oracle 数据库默认情况下，在安装的时候，会有三个重做日志文件。当第一个重做日志文件达到一定容量时，就会停止写入，而会转向第二个日志文件; 第二个也满时，就会转向第三个。当第三个满时，就会往第一个日志文件中写入。在往这原来的纪录中写入重做日志文件的时候，是否需要对原有的纪录进行备份呢?根据用户需求的不同，就存在这两种处理模式。一种是不需要数据库进行自动备份，这种模式就叫做非归档模式; 而当重做日志改写原有的重做日志文件以前，数据库会自动对原有的日志文件进行备份的话，这种操作模式就叫做归档模式。
现在摆在数据库管理员面前有两个选择。选择归档模式或者非归档模式呢?
这要根据企业对于数据完整性的要求不同而采取不同的操作模式。笔者的建议是，采用归档模式。因为现在硬盘非常的便宜，故我们可以花比较少的代价，换取比较齐全的数据库重做日志文件，个人认为这对于企业来说，是很值得的。
笔者现在的做法是，重做日志文件至少保存一年。也就是说，当一年过后，就可以重写原来的日志文件。这主要是跟企业所处的行业以及对于数据的安全性程度不同而有所区别。如银行就不同，他们可能要求重新日志保留十年甚至更长的时间。要知道，对于他们来说，任何一条记录可能都涉及到很大的资金。
Ø 合理选择日志切换的方法。
日志切换是指停止向某个重做日志文件组写入而向另一个联机的重做日志文件组写入的那一刹那，我们称为日志切换。一般来说，这个日志切换主要有三种处理方式。通常情况下，使到重做日志文件组容量满的时候，会发生日志切换动作。另外，我们还可以以时间的方式指定日志切换的方式，如我们可以以一个星期或者一个月作为切换的单位。第三，有时候我们可能出于数据库维护的需要，如当发现存放数据重做日志的硬盘容量快用光时，我们需要换一块硬盘，此时，就需要在当前时刻，进行日志的切换动作，这我们一般称之为强行日志切换。
归档就是在重做日志文件被覆盖时，将重做日志文件通过复制操作系统文件的方式，保存到其他指定的位置。一般情况下，只有在处于归档日志模式下的数据库中，才会对重做日志文件进行归档动作。
日志切换的模式选择，一般对于数据的安全性没有很大关系，但是，对于我们进行数据重做日志的管理，却会产生很大影响。合理部署重做日志文件的切换方法，对于我们数据库管理员来说，具有非常的现实意义。我们设置的好，可以大大节省我们数据库的管理工作，提高数据库的自动化管理效率。
如笔者现在对于数据重做日志是如此管理的。
根据笔者对于数据库变动的观察，笔者在新建立数据库的时候，设置了六个数据库重做日志文件。然后笔者采用基于时间的方是进行数据日志的切换动作。每两个月进行切换一次。为什么要选择这个时间呢?一方面是出于这个重做日志文件大小的考虑，另一方面，也是出于日后查询与管理的需要。如此的话，一年六个数据重做日志文件，就非常的清楚。
但是，基于时间的策略来对重做日志文件进行切换的话，有一个不好的地方，就是对于重做日志文件的大小很难控制。如可能在应用系统前期部署阶段，如ERP系统前期数据倒入阶段，因为涉及到很多的数据更改动作，所以，这个数据重做日志文件就会非常的大。而到后来项目上线，业务趋于正常的时候，数据重做日志文件大小又会迅速的回落。这就会导致数据重做日志文件大小差异太大，而数据重做日志的多路复用或者归档带来一定的麻烦。笔者的做法是，当ERP系统前期数据更新完毕，项目上线时，先对数据库进行强制数据重做日志切换。对于这个重做日志进行独立的管理。如此的话，后续的重做日志容量大小就会差不多，易于我们管理。
