Oracle重做日志文件管理技巧

核心提示： 归档就是在重做日志文件被覆盖时，将重做日志文件通过复制操作系统文件的方式，Oracle重做日志文件管理技巧(3)，保存到其他指定的位置，一般情况下，会取得多大的成效，因为笔者没有亲身感受过，只有在处于归档日志模式下的数据库中，才会对重做日志文件进行归档动作

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

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

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

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

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

四、 来自官方的建议

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

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

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