什么原因会导致AWR报告中DB Time显示异常？
物理机P720，操作系统，powerVM下的aix7.1
数据库oracle11g 11.2.0.4，双机RAC。
数据库对应的应用程序：未承载任何应用，无业务负载。
在查看60分钟的AWR报告时，发现DB Time非常高，能够达到11.72亿分钟；DB CPU等待时间能够达到703.28亿秒。另外，在OEM中的性能页签，平均活动会话数，显示也异常，能达到2200万个。
请问这是 powerVM 虚拟化的原因，还是oracle rac的bug，还是什么其他原因？如何解决呢？请各位高手赐教。
附件：
awr_report_58752_58753.zip (61.17 KB)
ashrpt_2_0731_1655.zip (6.13 KB)
5同行回答
DB CPU和DB time很高。同时有OEM，是集成类的EBS产品还是融合中间件产品？
如果没有业务负载的话，可以看下后台的定时任务之类的。
还有就是topSQL的信息我看没有。
方便的话，提供下完整的AWR报告和ASH。
对数据库并不算太熟，不过以前帮朋友处理MYSQLCPU占用资源过高时遇到过一点情况。就是SQL语句不够优化导致其中某条语句执行时CPU占用过高。看了你的日志。
这部分里。前面的几个语句每个执行的时间都比较长，可以找DBA看一下这些语句具体是干什么的，是怎样的一个执行逻辑
SQL 按 CPU 时间排序
- 为 PL/SQL 代码报告的资源包括代码调用的所有 SQL 语句使用的资源。
- %Total - CPU 时间占总 DB CPU 的百分比
- %CPU - CPU 时间占已用时间的百分比
- %IO - 用户 I/O 时间占已用时间的百分比
- 捕获的 SQL 占总 CPU 时间的 0.0%：17,582,052,979
- 捕获的 PL/SQL 占总 CPU 时间的 0.0%：17,582,052,979
| CPU 时间（秒） | 处决 | 每个 Exec 的 CPU | ％全部的 | 经过的时间（秒） | ％中央处理器 | %IO | SQL ID | SQL模块 | SQL文本 |
|---|---|---|---|---|---|---|---|---|---|
| 5.17 | 0 | 0.00 | 9.59 | 53.91 | 0.00 | 6pw8uk8k0dv0q | 实时连接 | 选择inst_id、begin_time、我... | |
| 5.09 | 0 | 0.00 | 9.28 | 54.89 | 0.00 | 3jvj0zbkak9h6 | 实时连接 | 选择inst_id、begin_time、va... | |
| 5.09 | 0 | 0.00 | 9.54 | 53.34 | 0.00 | f1y8kbhh6v9sv | 实时连接 | 选择inst_id、begin_time、我... | |
| 3.43 | 0 | 0.00 | 6.38 | 53.78 | 0.00 | 1uyp1pq4w60h7 | 实时连接 | 选择 wc.inst_id、wc.begin_ti... | |
| 1.07 | 1 | 1.07 | 0.00 | 1.83 | 58.52 | 0.00 | 邦斯Q950SNHF | 插入到wrh$_sga_target_ad... | |
| 0.63 | 12 | 0.05 | 0.00 | 1.04 | 60.29 | 0.00 | 4xxfmvn2m75q4 | emagent_SQL_oracle_database | / OracleOEM / 选择 * from ... |
| 0.45 | 12 | 0.04 | 0.00 | 0.98 | 45.45 | 0.00 | 0v6s91manuhz8 | emagent_SQL_rac_database | / OracleOEM / SELECT 阻塞... |
| 0.44 | 120 | 0.00 | 0.00 | 0.75 | 58.89 | 0.00 | 2b064ybzkwf1y | OEM系统池 | 开始 EMD_NOTIFICATION.QUEUE_R... |
| 0.36 | 19 | 0.02 | 0.00 | 1.06 | 33.68 | 1.12 | 6gvch1xu9ca3g | 声明作业 BINARY_INTEGER := ... | |
| 0.21 | 505 | 0.00 | 0.00 | 0.49 | 42.06 | 6.69 | 4vs91dcv7u1p6 | emagent_SQL_oracle_database | 插入 sys.aud$( 会话... |
另外判断的思路可以参考一下这个https://www.modb.pro/db/583886
目前看我觉得问题还是在ORACLE方面。看看有没有sql执行计划在后台执行了一些有问题的语句导致
根据AWR报告及平均活动会话数达到2200万个可知，大量的活动会话导致了大量cpu等待，从而DB CPU值过大。重点应该是查什么原因导致存在2200万个活动会话，建议直接查询视图v$active_session_history，追查这些会话是由什么程序发起，在处理什么SQL语句，从应用端查原因。
收起ChatGPT 回答
根据您提供的信息，可以初步判断这个问题可能是由于资源竞争引起的。具体来说，可能是由于虚拟化层（powerVM）中的资源分配不合理，导致数据库实例无法获得足够的CPU和内存资源，从而导致DBTime和DB CPU等待时间非常高，活动会话数异常。
为了解决这个问题，您可以采取以下措施：
- 检查虚拟化层中的资源分配是否合理，是否存在资源竞争。可以使用powerVM的监控工具来查看CPU、内存、网络等资源的使用情况，找出瓶颈所在。
- 调整虚拟化层中的资源分配，确保数据库实例能够获得足够的CPU和内存资源。可以根据实际情况增加虚拟CPU的数量，或者增加虚拟机的内存大小。
- 检查数据库实例中是否存在性能问题。可以使用AWR报告和OEM的性能页签来查看数据库实例的性能指标，找出性能瓶颈所在。如果存在性能问题，可以采取相应的优化措施，例如优化SQL语句、调整数据库参数等。
- 如果以上措施无法解决问题，可以考虑升级数据库版本或者虚拟化层版本，以获得更好的性能和稳定性。
总之，解决这个问题需要综合考虑虚拟化层和数据库实例两个方面的因素，找出瓶颈所在，采取相应的措施来优化性能。