昨天写了一篇Oracle AWR的简单分析，今天有6个网友找我分析问题，其中不乏Windows，AIX环境的，同时还有一套ODA和exadata的。其中Exadata的这套环境引起了我的好奇，这里简单记录一下分析思路，供大家参考！
扫了一眼AWR开头部分发现是48core/376g内存，配置还是不错，看主机名就知道是Oracle exadata一体机，问了一下网友反馈说是x8 1/8。
接下来我们直接看Load profile：
从load Profile来看压力似乎还好，但是IO压力似乎看上去略大，每秒14172MB/s;同时我们发现硬解析似乎也不低；针对硬解析的影响，可以看Time model statistics。
我们可以清楚的看到，目前硬解析其实已经产生了一定影响，不过不算大，结合此时top event来看的话。
大家可以清楚的看到cell smart table scan的平均等待时间已经高达21.35ms了，说明全表扫是真的蛮多，同时看cell single block physical read倒是非常正常，avg time还有112us（也就是0.112ms).
据网友反馈此AWR报告期间(早上9-10点),客户应用反馈是整体都很慢;从AWR前面的这些基础信息来看，全表扫 avg time都21ms了，肯定是比较慢了。进一步看IO stats会发现数据确实很夸张。
每秒高达13.5G/s的IO，确实不低。实际上我们要知道的是，这是Oracle exadata offload后下放到存储节点的IO，我们在计算节点是看不到这么高的IO的，这也正是exadata的强悍之处。
| Statistic | Total | per Second | per Trans |
|---|---|---|---|
| cell IO uncompressed bytes | 42.9 TB | 12.3 GB | 342.2 MB |
| cell RDMA reads | 318.0 GB | 91.4 MB | 2.5 MB |
| cell RDMA writes | 293,745 | 82.47 | 2.23 |
| cell blocks helped by commit cache | 5.1 MB | 1.4 KB | 81.92 B |
| cell blocks helped by minscn optimization | 42.9 TB | 12.3 GB | 342.6 MB |
| cell blocks pivoted | 1.6 TB | 479.3 MB | 13.0 MB |
| cell blocks processed by cache layer | 43.0 TB | 12.3 GB | 342.7 MB |
| cell blocks processed by data layer | 42.9 TB | 12.3 GB | 342.2 MB |
| cell blocks processed by txn layer | 43.0 TB | 12.3 GB | 342.6 MB |
| cell blocks returned by data layer | 1.7 TB | 511.8 MB | 13.9 MB |
| cell blocks sent | 96.0 KB | 0 B | 0 B |
| cell chained row pieces fetched | 55,746 | 15.65 | 0.42 |
| cell chained rows processed | 15,490 | 4.35 | 0.12 |
| cell chained rows rejected | 21,446 | 6.02 | 0.16 |
| cell chained rows skipped | 21,446 | 6.02 | 0.16 |
| cell commit cache queries | 53,864 | 15.12 | 0.41 |
| cell flash cache read hits | 45,537,663 | 12,784.58 | 346.46 |
| cell flash cache read hits for controlfile reads | 32.0 KB | 0 B | 0 B |
| cell flash cache read hits for smart IO | 45,532,252 | 12,783.06 | 346.42 |
| cell flash cache read hits for temp IO | 34 | 0.01 | 0.00 |
| cell logical write IO requests | 71,096 | 19.96 | 0.54 |
| cell num bytes in block IO during predicate offload | 1.6 GB | 471.5 KB | 12.8 KB |
| cell num bytes in passthru during predicate offload | 2.3 GB | 667.6 KB | 18.1 KB |
| cell num fast response sessions | 452 | 0.13 | 0.00 |
| cell num fast response sessions continuing to smart scan | 452 | 0.13 | 0.00 |
| cell num smartio automem buffer allocation attempts | 41,935 | 11.77 | 0.32 |
| cell num smartio transient cell failures | 0 | 0.00 | 0.00 |
| cell overwrites in flash cache | 1,417,669 | 398.01 | 10.79 |
| cell partial writes in flash cache | 0 | 0.00 | 0.00 |
| cell physical IO bytes eligible for predicate offload | 47.7 TB | 13.7 GB | 380.7 MB |
| cell physical IO bytes eligible for smart IOs | 47.7 TB | 13.7 GB | 380.7 MB |
| cell physical IO bytes saved by storage index | 4.7 TB | 1.4 GB | 37.7 MB |
| cell physical IO bytes sent directly to DB node to balance CPU | 106.8 GB | 30.7 MB | 851.8 KB |
| cell physical IO interconnect bytes | 820.8 GB | 236.0 MB | 6.4 MB |
| cell physical IO interconnect bytes returned by smart scan | 348.5 GB | 100.2 MB | 2.7 MB |
从上面这段数据我们还可以看出一个信息，通过exadata存储索引获益的IO每秒才1.4G，只有Smart IOs的1/10左右；说明此环境主要因smart scan的谓词过滤等机制发挥左右而非存储索引功能。当然这些并不重要，我们重要的是要看为什么慢。
那么有没有可能就是一体机存储节点IO有问题呢？
我们可以清楚看到，flash 磁盘组的IO相对还算OK，几乎都在3ms以内，然而机械盘的部分磁盘的IO就比较高了，慢的在6～7ms. 而从前面的信息了解到该数据库data磁盘组已经使用了55T（三副本后大约18T），虽然上面跑了几个库。但是我们可以看出，这个容量已经远超flash容量大小了（目前单节点flash+pmem 也就13T左右）；进一步看flash的IO命中率其实也能发现一些蛛丝马迹：
所以这个根本问题在于，不是exadata扛不住，是容量有点不足了呀，需要瘦瘦身或扩容了；要么就是把系统IO降下来。据网友反馈，后面用户把其中一个应用停掉之后，就基本上恢复正常了。
实际上从awr来看，这个系统还有很多小问题，比如内存还是自动调节，因为硬解析较高的缘故，导致shared pool 比buffer cache都还要大了，这显然是个隐患：
还有一些SQL version 问题，以及不知道为什么这套Oracle exadata环境数据库参数大多都是默认值，难道原厂实施也不做任何调整的么。比如连DRM 这种bug居多的特性都不关闭，难道是因为19c中DRM已经足够稳定并万无一失了么。
最后我想说的是，这套硬件设备的价格如果改用国产一体机的话，配置可以更高，实际上我们以前给客户上线#zData一体机(2+3) 全闪价格至少便宜一半以上，尽管没有exadata Smart scan 之类的牛X功能（exadata这些牛叉的功能，避免了应用SQL的烂，是的，再烂都能跑)，但实际上对于99%的用户来说，已经很好用了，毕竟硬件性能弥补了差距。这或许就是很多客户选择国产一体机的原因吧。不是Exadata用不起，而是zdata更具性价比！
最后欢迎大家继续提供Case或者故障分析素材，免费分析。可以继续加我微信或者公众号私信我。
