整合环境引发Exadata性能问题

个人简介:石云华,Exadata中国用户组联合创始人,2019年被ORACLE官方授予ACE称号。毕业后一直从事Oracle数据库第三方运维服务工作,拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司,oracle数据库专家组成员,Exadata部门负责人。个人著作有《Exadata实施运维指南》,另外一本《Oracle Exadata性能优化》即将面世。

案例概要:

我们的一个客户在1/4配置的Exadata X2-2上运行着一套Oracle数据库,这套数据库上面运行着两套业务系统,按照最初的规划,A业务系统平时运行在节点1上,而B业务系统平时运行在节点2上。

有一天,在运维的微信群里,A业务系统的运维人员喊着”数据库现在是不是有问题啊,平均1分钟就能跑完的SQL语句,现在2、3分钟才出来结果,感觉今天业务系统整体都比平时慢。”这时,B业务系统的运维人员也在群里回复着”没有啊,我们感觉还是比较正常,与平时没什么区别。”看到这些聊天记录,作为一个数据库运维人员肯定是坐不住了,最起码要搞清楚到底是怎么回事,这个锅不能动不动让数据库来背啊。

案例分析及处理:

数据库出现性能问题,首先需要提取当前的AWR报告。节点1中AWR报告关于数据库负载和数据库等待事件的信息如图10.22所示。


图10.22 节点1中AWR报告关于数据库负载和数据库等待事件的信息

节点2中AWR报告关于数据库负载和数据库等待事件的信息如图10.23所示。


图10.23 节点2中AWR报告关于数据库负载和数据库等待事件的信息

从AWR报告中的等待事件可以看出,当前数据库全部是User I/0类型的等待,高达几百毫秒,说明当前的IO性能非常糟糕。从节点2的AWR报告中的数据库负载Physical reads可以看出每秒钟访问190892个物理数据块,折算成IO吞吐量大约为1.5GB,这样的物理IO吞吐量对于传统架构而言,这个系统早就挂掉了。

既然看出节点2上的物理IO过高,那就看看这些物理IO是谁访问的,我们继续查看AWR报告中SQL语句访问物理IO的信息,具体如图10.24所示。


图10.24 节点2中AWR报告关于SQL语句访问物理IO的信息

可以看出SQL_ID为1z32jd030pcnf的这条SQL语句访问了334,550,485个物理IO,也即大约2.5TB的数据量,一条SQL语句占用了将近50%的物理IO。

至此,我们找到了性能问题的罪魁祸首,赶紧通知B业务系统的运维人员,找到该SQL语句对应的业务模块,停止该业务模块后,一切恢复正常。

临时恢复业务后,我们需要看看这条SQL语句为何会访问如此多的物理IO,通过awrsqrpt.sql脚本获取SQL_ID为1z32jd030pcnf的SQL语句的执行计划,具体信息如图10.25所示。

图10.25 语句执行计划

未经允许不得转载:Oracle一体机用户组 » 整合环境引发Exadata性能问题

相关推荐