通过这篇简短的文章，我想消除一个与分析 Oracle Exadata 上运行的 AWR 数据库相关的误解。 近10年来，我一直面临这样一个问题：Exadata软件对生产力的贡献是什么？ 或者用新造的词：特定数据库的工作有多“专家”？
在我看来，这个正确的问题常常根据 AWR 统计数据得到错误的回答。 它提出了系统等待方法，该方法将响应时间视为处理器（DB CPU）的操作时间和各个类的等待时间的总和。
随着 Exadata 的出现，与 Exadata 软件运行相关的特定系统期望出现在 AWR 统计数据中。 通常，此类等待的名称以“单元”一词开头（Exadata 存储服务器称为单元），其中最常见的是具有不言自明名称的等待“单元智能表扫描”、“单元多块”物理读”和“单元单块物理读”。
在大多数情况下，此类 Exadata 等待在总响应时间中所占的份额很小，因此它们甚至不属于按总等待时间排列的 Top10 前台事件部分（在这种情况下，您需要在前台等待中查找它们）活动部分）。 我们好不容易从客户那里找到了一个每日AWR的例子，其中Exadata的预期被列入Top10部分，总计约为5%：
活动
等待
总等待时间（秒）
平均等待时间
%数据库时间
等待班
数据库CPU
115.2
70.4
来自 dblink 的 SQL*Net 更多数据
670,196
5471.5
8.16ms
3.3
商业网络
Cell单块物理读
5,661,452
3827.6
676.07us
2.3
用户输入/输出
同步 ASM 重新平衡
4,350,012
3481.3
800.30us
2.1
其他名称
单元多块物理读取
759,885
2252
2.96ms
1.4
用户输入/输出
直接路径读取
374,368
1811.3
4.84ms
1.1
用户输入/输出
来自 dblink 的 SQL*Net 消息
7,983
1725
216.08ms
1.1
商业网络
单元格智能表扫描
1,007,520
1260.7
1.25ms
0.8
用户输入/输出
直接路径读取温度
520,211
808.4
1.55ms
0.5
用户输入/输出
enq: TM - 争用
652
795.8
1220.55ms
0.5
应用领域
从此类 AWR 统计数据中通常可以得出以下结论：
1. Exadata magic对数据库性能的贡献不高——不超过5%，数据库“exadataizes”较差。
2、这样的数据库如果从Exadata转移到经典的“服务器+阵列”架构，那么性能不会有太大变化。 因为即使该阵列比 Exadata 存储系统慢三倍（这对于现代全闪存阵列来说几乎是不可能的），然后将 5% 乘以 15，我们就会将 I/O 等待份额增加到 XNUMX% - 数据库肯定会幸存下来！
这两个结论都是不准确的，而且它们扭曲了对 Exadata 软件背后理念的理解。 Exadata 不仅提供快速 I/O，其工作方式与经典服务器 + 阵列架构有根本不同。 如果数据库操作真正“适配”了，那么SQL逻辑就会转移到存储系统上。 存储服务器借助许多特殊机制（主要是 Exadata 存储索引，但不仅限于此），可以自行查找必要的数据并将数据库发送到服务器。 它们的执行效率非常高，因此典型的 Exadata 等待时间在总响应时间中所占的比例很小。
在 Exadata 之外，这一份额将如何变化？ 这将如何影响整个数据库的性能？ 测试将最好地回答这些问题。 例如，等待 Exadata 外部的“单元智能表扫描”可能会变成繁重的表全扫描，导致 I/O 占用整个响应时间，并且性能急剧下降。 这就是为什么在分析 AWR 时，将 Exadata 预期的总百分比视为其对性能的魔力贡献是错误的，使用该百分比来预测 Exadata 之外的性能更是如此。 要了解数据库的工作有多“精确”，您需要研究“Instance Activity Stats”部分的 AWR 统计数据（有很多具有不言自明的名称的统计数据）并将它们相互比较。
要了解 Exadata 之外的数据库的感受，最好从目标架构上的备份进行数据库克隆，并分析该克隆在负载下的性能。 一般来说，Exadata 所有者有这个机会。
作者： Alexey Struchenko，Jet Infosystems 数据库部门负责人
来源： habr.com