Oracle 重做日志和控制文件I/O争用。

嗨，汤姆，

您能向我解释一下Oracle数据库需要多久从控制文件中读取一次吗？并且将控制文件放置在与重做日志相同的磁盘/磁盘组上会导致I/O争用吗？

问题上下文:

我们有一个3节点RAC群集，托管29个繁忙的生产数据库。我们在所有数据库上随机遇到高等待尖峰，这似乎是从 “日志文件同步” 的根。重做日志在2个ASM diskgroups (REDO1和REDO2) 之间多路复用。我们还复用位于同一ASM diskgroups上的控制文件。

奇怪的是，我始终能够看到从REDO1读取数千kb/s，而REDO2始终几乎没有。我的理解是，除非需要恢复，否则不会从重做日志中读取任何内容。

这使我指向控制文件-我知道只有v $ controlfile的第一个controlfile条目是由Oracle “读取” 的，这将是有意义的，因为该条目在所有29个数据库上都是REDO1。29个数据库系统的controlfile “读取” 请求是否会累积价值数千kb/s的I/O？

我担心将controlfile放置在与重做日志相同的diskgroups上会导致I/O争用，从而导致等待日志文件同步。除了读取I/O之外，controlfile还会在每个事务上盖章，因此也会遇到大量的写入I/O。我已经在许多系统上看到了这个文件布局 (重做和控制文件在一起)，但没有多达29个数据库。

非常感谢。

My understanding is that nothing reads from the redo logs, unless recovery is required. 
复制

好吧，归档程序会，如果您有备用数据库，那么我们将继续从主数据库到备用数据库进行重做。AWR报告可以按文件类型向您显示I/O分布，因此您可以使用它来确认其重做还是控制文件。但是让我们假设后者。

这里仍然有很多 * 潜在 * 的原因需要关注。

首先，“日志文件同步” 是您等待LGWR回复您的时间，但这可能是 (或可能不是) LGWR I/O的同义词。您应该检查日志文件同步到日志文件并行写入的比例，看看有多少时间是真正基于等待LGWR I/O。

例如，粉碎一台计算机以100% CPU，您将所有会话都停留在日志文件同步上，因为LGWR无法查看CPU，因此每个人都在等待。所以CPU是一个很好的起点。

你在做直接模式操作吗？直接路径加载或nologing操作导致controlfile操作。有时，即使在没有知识的情况下，这些也可能发生，例如，如果您有使用 “w同” 子句的SQL，我们可能会动态创建并加载全局临时表来支持这一点。

备份活动可能会导致大量的controlfile操作-因为RMAN正在通过controlfile跟踪其许多进度和结果。

你有备用数据库吗？再次-用于协调那里的活动的controlfile。

同样，您有多少个 “正在播放” 的archivelogs。那里的元数据将存储在controlfile中-检查V $ CONTROLFILE_RECORD_SECTION中archivelog信息的大小。大 = 痛苦

按照类似的思路，任何中断归档 (例如磁盘已满) 通常都会导致LGWR/ARCn等丢失情节，并在尝试/重试等时对控制文件进行弹道攻击。

因此，这应该给您一些东西-如果所有其他方法都失败了，可能是时候与支持人员取得联系了。