物理机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)
DB CPU和DB time很高。同时有OEM,是集成类的EBS产品还是融合中间件产品?
如果没有业务负载的话,可以看下后台的定时任务之类的。
还有就是topSQL的信息我看没有。
方便的话,提供下完整的AWR报告和ASH。
对数据库并不算太熟,不过以前帮朋友处理MYSQLCPU占用资源过高时遇到过一点情况。就是SQL语句不够优化导致其中某条语句执行时CPU占用过高。看了你的日志。
这部分里。前面的几个语句每个执行的时间都比较长,可以找DBA看一下这些语句具体是干什么的,是怎样的一个执行逻辑
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语句,从应用端查原因。
收起根据您提供的信息,可以初步判断这个问题可能是由于资源竞争引起的。具体来说,可能是由于虚拟化层(powerVM)中的资源分配不合理,导致数据库实例无法获得足够的CPU和内存资源,从而导致DBTime和DB CPU等待时间非常高,活动会话数异常。
为了解决这个问题,您可以采取以下措施:
总之,解决这个问题需要综合考虑虚拟化层和数据库实例两个方面的因素,找出瓶颈所在,采取相应的措施来优化性能。