Oracle 日志文件同步和日志文件并行写入等待事件的平均等待时间每天增加

嗨，团队，

首先，感谢您所做的所有出色工作!

我们面临日志文件同步等待事件的问题。粘贴在下面是详细的记录。如果您可以通过分享您的观点来帮助我们，那就太好了。

再次感谢您的帮助!

-

[Issue]

在我们的数据库实例上，“日志文件同步” 和 “日志文件并行写入” 等待事件的平均等待时间每天都在增加。随着等待时间的增加，我们会遇到应用程序缓慢的情况。这些事件的等待时间是在DB启动后 (本身很高) 约20毫秒，在7-8天内，它攀升到250毫秒。等待时间再次返回到DB服务器重新启动后约20毫秒。

我们的理解是，我们面临着重做文件I/O问题，因为 (日志文件同步平均等待时间)/ (日志文件并行写入平均等待时间) 的比率从1.1到1.4

DB托管在Windows服务器上。

[Things Checked]

1.我们分析了以下因素，它们在任何两天之间几乎是相似的:

A.用户提交计数 (~ 43000/小时)，回滚 (~ 4000/小时)，用户调用 (~ 750000/小时)，事务 (13-14/秒)，等待日志文件同步事件 (9000/小时)。
B.重做 (~ 50,000字节/秒) 、逻辑读取 (8000块/秒) 、物理读取 (~ 7块/秒) 、物理写入 (~ 10-15块/秒) 的大小
C.日志文件开关数量: ~ 3个/小时。

2.DB不受CPU限制，并且系统不受负载: 在具有30个CPU和20个内核的计算机上，DB时间约为22分钟，经过60分钟。我们正在使用闪存驱动器来存储重做日志文件。

3.顶部前台事件显示日志文件同步 (约30% DB时间，8,669等待)，DB CPU (约25-40% DB时间)，控制文件顺序读取 (约2-3% DB时间，2,887等待)，缓冲区繁忙等待 (约1-2% DB时间，24,169等待)。

我们已经探索并实施了减少提交/回滚的途径。

[Questions]

1.在得出结论存在重做文件I/O问题之前，我们还可以检查其他内容吗？我们是否需要考虑任何其他指标/数据？我们还缺少其他明显的东西吗？
2.关于平均等待时间不断增加的原因的任何指示都将非常有帮助。
3.在托管重做文件的磁盘上监视I/O是个好主意吗？我们是否有任何实用程序可以帮助我们将磁盘I/O与windows server上运行的进程相关联？
4.您能否详细说明我们如何将上述事件的平均等待时间与磁盘的I/O容量联系起来？

1)

男人 ..。每秒13-15笔交易，每秒50k重做是 * 什么都没有 *。这是我的电脑在普通标准消费者硬盘上的演示。

SQL> create table t ( x char(100));

Table created.

SQL> insert into t values (1);

1 row created.

SQL> commit;

Commit complete.

SQL>
SQL> conn scott/tiger   -- fresh session
Connected.

SQL> select
  2    s.name, st.value
  3  from v$statname s, v$mystat st
  4  where st.statistic# = s.statistic#
  5  and s.name = 'redo size';

NAME                                                    VALUE
-------------------------------------------------- ----------
redo size                                                 668

SQL>
SQL> set timing on
SQL> begin
  2  for i in 1 .. 100000 loop
  3    update t set x = i;
  4    commit write immediate wait;
  5  end loop;
  6  end;
  7  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:15.10
SQL> set timing off
SQL>
SQL> select
  2    s.name, st.value
  3  from v$statname s, v$mystat st
  4  where st.statistic# = s.statistic#
  5  and s.name = 'redo size';

NAME                                                    VALUE
-------------------------------------------------- ----------
redo size                                            85986460

所以我可以做6MB每秒重做时做很多小事务 (~ 6000/秒)

所以你的存储设置肯定有问题。

2)

并非如此，但我的猜测可能是某些操作系统级别的问题，甚至可能是硬件。如今，闪存驱动器中有很多技术可以进行磨损平整和垃圾收集等操作-它 * 可能 * 与此相关，但我只是在这里假设。显而易见的做法是在不同的磁盘上尝试重做日志 (甚至是暂时的)

3) 是的。

Orion是一个模拟Oracle I/O的简单工具。这是一个不错的文章

https://oracle-base.com/articles/misc/measuring-storage-performance-for-oracle-systems

4) 容量和吞吐量是不同的东西，尽管 (大多数) 磁盘技术通常会随着容量的增加而运行得更慢。


简而言之，攻击计划:

-如果可能的话，尝试不同的磁盘，观察差异
-尝试Orion，看看是否可以在此处复制，这意味着它本身不是数据库。