Oracle QQ群讨论系统性能Tuning话题总结（1）

最新推荐文章于 2022-10-26 09:24:45 发布

转载最新推荐文章于 2022-10-26 09:24:45 发布 · 57 阅读

本文分享了一位专家在处理数据库服务器CPU及IO高负载问题时的实战经验。通过详细的步骤介绍，包括使用TOPAS工具监控、分析RAC节点日志、检查存储与网络状况等，揭示了在面对复杂数据库性能问题时的诊断与解决方法。

以下是群中牛牛爱你如初老大的一些谈话总结。有一些概念性的东西我会在回复中写出来。供大家参考。

应用跟我的反映98%就是慢 , 一般会按照下面步骤进行

1、打开TOPAS (AIX)，查询IO CPU情况

2、检查应用服务器的情况

一般时候到这里就会出现2中情况 , 数据库服务器CPU很高或者IO很高

3、查询RAC节点的日志和OS的日志确认不存在OS或者数据库本身出现了问题 , 比如FSP卡出现问题或者内存模块出现问题等等都要先排除

4、检查存储日志

如果检查OS以后发现CPU与IO都不高，前台还反映慢，那就开始考虑网络了

5、然后开始着手查数据库本身与应用的问题了，一般我都会通过排名前几的进程去查在后台执行什么动作，由于像我们这些系统执行频度很高，所以语句的切换是非常快的，大部分时间都是花在这里。

记得有回，我们的一个节点CPU利用率很高，但是经过对大量语句的分析，每条语句的执行都不会超过0.1S , 而且这些语句都是一闪而过, 这个时候我会特别注意这些语句执行的频度, 最后发现有个语句每秒执行接近100次 , 你想想即使这个语句每次执行0。01S，那么一秒种也需要用掉你大量的CPU .

如何查询每秒执行接近100次, 到v$sqlarea里去查, 如果绑定过的 , 里面会记录一个执行次数 , 你可在2个时间点执行相减下就可以算出来了, 对绑定不好的情况，情况就更复杂了 .

比如前天我们这里出现的问题, DBA跟我反映说从上午9：40开始，主服务器的CPU一直攀身从20%一直差不多到80% , 这种情况是属于比较紧急时刻了, 但是经过对大量语句排查后没有发现任何异常 , 然后我检查了下v$session_wait , 发现里面有少量的LATCH FREE等等 , 我再看看v$sqlarea，发现前天晚上执行的一些大量的非绑定语句存在 , 这个问题就跟10G的内存自动管理就有点关系了 , 我一直不很推崇10G的对于SHARED POOL自动管理的能力 , 我曾经做过测试，在10G下和9I下做压力测试，在相同情形下，都不进行变量的绑定, 9I的效率到后期差不多是10G的30倍 , 10G对于SHARED POOL自动管理是存在缺陷的, 比如他在什么时候停止申请新内存等等应该是没控制好的 , 没控制好直接导致SHARED POOL的进出队列管理也存在了缺陷 ,也就是当SHARED POOL内存用了到达一定程度的时候，那么ORACLE本身对这片内存区的管理尤其是在变量绑定不好的时候 , 那代价是极其高的 . 不过这个问题我从没看到过有人在论坛上提过 , 这个时候有个小巧的解决办法, 我一般都那么处理, 果也是相当不错的 , 一般这个时候我会把SHARED POOL给清空(alter system flush shared pool ) , 我们前2天的问题我把内存清掉以后 , CPU马上下到20% . flush之后，应用语句绑定好，虽然所有请求都需要hard phase一次，但是基本没有大的影响。

接着谈谈FLUSH的作用？举个例子吧，例子好理解些，举个排队的例子，如果一个队伍里总共就2个人，只要一个管理员就可以管得好好的，但是如果一个队伍有2万个人，那需要多少管理员去管理才能管理好这个队伍呢？实际上就是一个PIN的动作，因为变量没绑好，很多PARSE的时候都要去PIN这个OBJECT，所以会出现LATCH FREE等带， LATCH可以理解为是一个内存保护锁，一块内存区的数据一个时刻只能被某一个进程读取占用，实际上在内存区不够的时候也会出现这种等待时间了