在此我们将提到两个可能出现的问题。

首先提到的就是批处理任务，该任务可能没有足够的完整重做空间来完成，或是因为速度快，以致联机重做日志在归档到脱机重做日志mysql 判断记录是否存在方法比较 iis7站长之家即已切换(使用了所有的重做日志，并且开始再次写入第一个重做日志)。联机重做日志只有在归档(启用归档时)后才可以被重写，因此DML 和 DDL 活动必须等待，直到有可用的联机日志。在操作系统级别上，按它们最近的更新日期和时间列出联机重做日志，您可以判断它们切换的是否频繁。还可以用查询 V$LOG_HISTORY 来得到最近的日志交换记录（ 以前是100个，现在增加了 ）。如果增加了联机重做日志的大小，就可以为那些执行大型的 INSERT、UPDATE 和 DELETE 操作的批处理任务提供足够的空间。较好的解决办法是增加联机重做日志的数目，这样就可以在有很频繁的日志切换(很小但却非常多的联机重做日志)时提供足够的空间。

第二个要考虑的问题就是那些要长时间运行的任务，这些任务可能要花大量的时间来切换联机重做日志。当整个任务正好只需用到一个联机重做日志时，这种长时间运行的任务可能非常快。对于联机事务处理(OLTP)类型的环境来说，最好使用较小的重做日志。我的经验是每半个小时(不考虑可以缩短这段时间的一些长时间运行的批处理操作)就切换一次联机重做日志。通过在操作系统级别上监控联机重做日志发生的日期和时间(或查询 v$log_history，也可以查询)，就可以确定增加联机重做日志的大小或数目，从而设置一个优化的切换时间间隔。

下面的查询显示了两个日志切换的间隔时间，这样我们可以方便地判断系统是否存在问题。

1、对于单实例

您可能感兴趣的文章: