Oracle重做日志文件管理技巧

重做日志文件是Oracle数据库中一种非常重要的日志文件，也是其一个很有特色的功能。重做日志文件会纪录对于数据库的任何操作，如利用DML语句或者DDL语句对数据进行更改，或者数据库管理员对数据库结构进行更改，都会在重做日志中进行记录。

　　可见，当数据被意外的删除或者修改，我们可以利用重新日志文件进行恢复; 当出现例程失败或者介质失败的情况下，也可以利用日志文件实现例程恢复或者介质恢复。所以说，我们若能够管理好重做日志文件的话，对于保障数据库数据的安全是非常重要的。

　　下面笔者谈谈管理好Oracle 数据库日志文件的几点经验技巧，或许，能够给大家在重做日志文件的管理中带来一些启示。

　　一、 合理确定重做日志文件的存放位置

　　我们知道，当数据库内部数据丢失或者被意外更改的情况下，数据库管理员可以利用重做日志文件实现数据库数据的恢复工作。当数据库出现意外事故，如硬盘物理损坏、数据丢失时怎么办?

　　我们第一个就会想到利用数据库重做日志对数据进行恢复。可是当数据库重做日志跟数据库数据文件放在同一个硬盘的话，很明显，当硬盘损坏的时候，数据文件将跟日志文件共赴黄泉。此时，连天皇老子都救不了我们。

　　所以，此时，我们就有必要把重做日志文件跟数据库数据文件放在两个不同的硬盘上面。此时，任何一个硬盘若发生损坏，我们都可以凭借另外一块硬盘的数据，来挽回损失。如存放数据文件的硬盘损坏时，我们就可以利用存放在另外一块硬盘上的数据重做日志文件进行修复，挽回损失。

　　鸡蛋不能放在同一个篮子里，故重做日志文件与数据文件也不要放在同一块硬盘上。那时非常危险一个动作。

　　其实，这个重做日志文件就跟数据库的备份文件类似。我们在对数据库进行备份的时候，都知道需要进行异地备份。可惜的是，很多数据库管理员，在进行Oracle 数据库管理的时候，没有注意到这一点，结果当出现问题的时候，就来不及了。故，对于数据重做日志文件，保存时，要跟数据库备份文件一样，进行异地保存。

　　二、 合理设置数据库的归档模式

　　因为数据重做日志会纪录数据库所有的修改动作，所以，当数据库频繁修改时，如那些ERP系统需要频繁对数据库进行修改操作，此时，数据库的重做日志文件就会很庞大。为了便于日志文件的管理，Oracle 数据库默认情况下，在安装的时候，会有三个重做日志文件。当第一个重做日志文件达到一定容量时，就会停止写入，而会转向第二个日志文件; 第二个也满时，就会转向第三个。当第三个满时，就会往第一个日志文件中写入。在往这原来的纪录中写入重做日志文件的时候，是否需要对原有的纪录进行备份呢?根据用户需求的不同，就存在这两种处理模式。一种是不需要数据库进行自动备份，这种模式就叫做非归档模式; 而当重做日志改写原有的重做日志文件以前，数据库会自动对原有的日志文件进行备份的话，这种操作模式就叫做归档模式。

　　现在摆在数据库管理员面前有两个选择。选择归档模式或者非归档模式呢?

　　这要根据企业对于数据完整性的要求不同而采取不同的操作模式。笔者的建议是，采用归档模式。因为现在硬盘非常的便宜，故我们可以花比较少的代价，换取比较齐全的数据库重做日志文件，个人认为这对于企业来说，是很值得的。、

　　笔者现在的做法是，重做日志文件至少保存一年。也就是说，当一年过后，就可以重写原来的日志文件。这主要是跟企业所处的行业以及对于数据的安全性程度不同而有所区别。如银行就不同，他们可能要求重新日志保留十年甚至更长的时间。要知道，对于他们来说，任何一条记录可能都涉及到很大的资金。

三、 合理选择日志切换的方法

　　日志切换是指停止向某个重做日志文件组写入而向另一个联机的重做日志文件组写入的那一刹那，我们称为日志切换。一般来说，这个日志切换主要有三种处理方式。通常情况下，使到重做日志文件组容量满的时候，会发生日志切换动作。另外，我们还可以以时间的方式指定日志切换的方式，如我们可以以一个星期或者一个月作为切换的单位。第三，有时候我们可能出于数据库维护的需要，如当发现存放数据重做日志的硬盘容量快用光时，我们需要换一块硬盘，此时，就需要在当前时刻，进行日志的切换动作，这我们一般称之为强行日志切换。

　　归档就是在重做日志文件被覆盖时，将重做日志文件通过复制操作系统文件的方式，保存到其他指定的位置。一般情况下，只有在处于归档日志模式下的数据库中，才会对重做日志文件进行归档动作。

　　日志切换的模式选择，一般对于数据的安全性没有很大关系，但是，对于我们进行数据重做日志的管理，却会产生很大影响。合理部署重做日志文件的切换方法，对于我们数据库管理员来说，具有非常的现实意义。我们设置的好，可以大大节省我们数据库的管理工作，提高数据库的自动化管理效率。

　　如笔者现在对于数据重做日志是如此管理的。

　　根据笔者对于数据库变动的观察，笔者在新建立数据库的时候，设置了六个数据库重做日志文件。然后笔者采用基于时间的方是进行数据日志的切换动作。每两个月进行切换一次。为什么要选择这个时间呢?一方面是出于这个重做日志文件大小的考虑，另一方面，也是出于日后查询与管理的需要。如此的话，一年六个数据重做日志文件，就非常的清楚。

　　但是，基于时间的策略来对重做日志文件进行切换的话，有一个不好的地方，就是对于重做日志文件的大小很难控制。如可能在应用系统前期部署阶段，如ERP系统前期数据倒入阶段，因为涉及到很多的数据更改动作，所以，这个数据重做日志文件就会非常的大。而到后来项目上线，业务趋于正常的时候，数据重做日志文件大小又会迅速的回落。这就会导致数据重做日志文件大小差异太大，而数据重做日志的多路复用或者归档带来一定的麻烦。笔者的做法是，当ERP系统前期数据更新完毕，项目上线时，先对数据库进行强制数据重做日志切换。对于这个重做日志进行独立的管理。如此的话，后续的重做日志容量大小就会差不多，易于我们管理。

　　四、 来自官方的建议

　　下面两条是来自Oracle数据库官方的对于重做日志管理的建议。由于笔者所涉及到的数据库还没有复杂到这种程度，所以对于这两个建议还没有直观的印象。各位读者若觉得有必要的话，也可以参考一下。

　　一是如果采用了归档模式的话，应该将重做日志成员放置到不同的硬盘中去。以消除LGWR和ARCH后台进程对重做日志成员的争夺。也就是说，如有忧多组多路复用重做日志成员，则可以将每个成员都放置在不同的硬盘上，并且将其归档重做日志文件也放在另外的硬盘上。这个笔者还没有测试过，到底其可以提高多少数据库的性能。这么处理的目的，笔者想，大概为了减少填写成员与读取成员、归档成员之间的冲突。具体效果如何，就待大家去测试了。

　　二是不应该将数据日志文件存放在非常活跃的数据或索性表空间的硬盘上。这会降低数据库正常读取的效率。这个从理论上是可以理解的，但是在实际应用中，会取得多大的成效，因为笔者没有亲身感受过，也就不得而知了。