Oracle 表演调谐

嗨，团队，

目前，我们的数据库 (非RAC) 出现了巨大的峰值。此峰值是由于日志文件同步是900会话，此会话的拦截器是日志文件并行写入。

而他们不是日志文件并行写入的拦截器。从顶部查询，我们能够找到一些DMl语句正在发生。
在一个顶部插入语句中，他们也是enq:tx索引争用，我们可以看到。

根据我们的分析，隐藏参数 _ adaptive_log文件同步为false，从awr后台流程详细信息来看，日志文件同步w.r.t日志文件并行写入所花费的时间很低。

从ASH报告这是最重要的等待事件:-

事件 % 事件P1值，P2值，P3值 % 活动参数1参数2参数3
日志文件同步87.87 “4294967295”，“901430137”，“0” 0.14缓冲区 # sync scn未定义
缓冲区繁忙等待4.26 “2946”，“765779”，“1” 0.81文件 # 块 # 类 #
enq: TX-索引竞争2.21 “1415053316”，“5832725”，“8818981” 0.27名称 | 模式usn<<16 | 插槽序列
直接路径读取1.94 “898”，“301442”，“126” 0.01文件编号第一dba块cnt
db文件顺序读取1.28 “71”，“180047”，“1” 0.01文件 # 块


我们没有得到任何关于日志文件同步原因的确凿细节。


从存储端，我们已经检查并发现了一些设备avg。服务时间超过1000。但是存储团队拒绝与存储或服务器端有关的任何问题。


请您对此有所了解，以进行我对RCA的进一步分析。

“日志文件同步” 是等待日志编写器响应的会话。因此，从会话的角度来看，它正在等待提交完成，但它 * 不是 * 对重做日志的实际写入的反映。例如，如果LGWR以某种方式停滞，我可以很容易地让1000会话都在LGWR上等待。

为此，我们查看LGWR本身的事件，看看它正在等待什么。如果您在现代硬件上看到 “日志文件并行写入” 超过几毫秒，则表明存储存在问题。现在，这不一定是一个SAN问题，但从数据库服务器的角度来看，它绝对是一个存储问题，所以它可以是它和存储之间的路径中的任何东西-操作系统，文件系统，网络，光纤，交换机，SAN CPU，SAN缓存等...

"From storage end we have checked and found some of device avg.service time is beyond 1000+" 是令人担忧的原因 * 如果 * 这与LGWR试图写入的位置有关。

如果日志文件并行写入低 * 对于lgwr *，并且当我说低时，我的意思是检查v $ event_histogram，而不仅仅是平均值，这可能会导致日志文件同步。常见原因:

-过载服务器
-提交频率过高