重做日志包含可能尚未写入数据文件的事务的详细信息。 重做日志的主要目的在于系统或数据库发生故障时恢复数据库。
重做日志配置
提交事务时，必须出现重做日志文件的物理写入。 必须完成写入，提交调用才能将控制返回给用户。 因此，重做日志写入可以提供更新密集型应用程序吞吐量的限制。
如果日志位于专用设备上且设备不存在争用，则优化重做日志 I/O。 如果达到上述目标，则发布提交时磁头已处于正确的位置，并且等待时间减少到最低（磁盘无需查找）。
由于日志写入是按顺序进行的并且仅由归档进程执行，分段优势就不明显了。 由于 LGWR 只写入这些设备，RAID 5 导致的性能降级很可能是非常明显的，即使该卷专用于重做日志（由于归档进程进程存在争用）。
为了预防在介质故障时发生数据丢失，必须镜像重做日志。 Oracle 提供软件镜像功能（重做日志多路复用），尽管硬件镜像 (RAID 1) 很可能更有效。
由于重做日志的切换生成数据库检查点，并且由于未完成检查点前无法重用日志，因此大量的大日志可产生更好的吞吐量。 通过增加日志的数量，可以降低完成检查点前需要重用日志的概率。 通过增加日志的大小，可以减少必须出现的检查点数量。
重做日志的优化尺寸取决于您的事务比率。 您应设置日志大小，以免切换发生速度过快。 由于通常情况下您会分配重做日志的专用设备，因此有较大的磁盘容量可供日志使用。 通常最简单的办法是，刚开始就过度配置日志的大小和数量。 常见的日志大小为 64 至 256 MB。 配置 10 到 20 个重做日志也是比较常见的情况。
优化存档
存档日志是在线重做日志的副本。 它们可用于将数据库恢复到故障点，或还原备份后的另一个时间点。 如果需要进行在线备份，还需要记录存档。
填写重做日志文件后，Oracle 移动到下一个日志文件。 归档进程 (ARCH) 将最近填写的日志复制到备用位置。 如果归档进程从和当前写入日志相同的物理设备上读取日志，则日志编写器的随后写入都会中断。 如果日志编写器落后太多，数据库可能停止运行（因为存档前无法重用日志文件）。
因此，需要优化归档进程的性能。 可以通过在超过两台设备上交替使用重做日志，最大程度减少归档进程和日志编写器之间的争用。 然后，重做日志写进程可以写入一台设备，而归档进程从另一台设备读取。 由于归档进程写入的速度必须至少和日志编写器一样快，因此存档目标应为一台专用设备，或 RAID 0+1（镜像和条带化）配置中的一组专用磁盘。
日志文件等待事件
正如 Oracle 会话必须等待数据库文件 I/O 一样，它们还必须等待日志文件 I/O。 COMMIT 语句导致写入重做日志时，出现上述等待。 发布 COMMIT 的会话等待日志文件同步事件。 日志编写器发布 I/O 请求时，等待日志文件并行写入事件。
在状况良好的数据库中，等待事件是不可避免的，通常占非空闲等待总时间的 10-20%。
日志文件并行写入的平均等待时间是重要的衡量指标， 它指明了归档进程刷新恢复缓冲区的速度。 它是衡量重做日志设备效率的有效指标。 如果数值低于百分之一秒，则表示良好；如果数值高达百分之五秒，则不正常。 如果数值超过此范围，则表示重做日志设备存在争用。
联系客服
