SGA设置过大造成的系统性能问题

SGA设置过多造成的系统性能问题
2010-2-3
深圳

中午，突然接到Manager的电话，说SAP测试环境有性能问题，需要我紧急接入电话会议。这个环境平时不是我管理的，可能是老大没有找到人，临时把我call上了。
没有办法，顶着头皮上啊。
在电话会议上，一群人在说个不停。Manager把帐号信息发给我，我登录到系统中，查看下系统资源使用情况，发现物理内存使用了90%，IO有些大，有几个DISK处于100%的繁忙，CPU比较闲。他们说现在不是Performance的问题，而是在SAP前端系统没有响应。
查看了等待事件，锁，ALERT的日志，都没有特殊的情况。在等待事件中，发现还是有些IO有关的事件。
除了我的检查外，用户还建议去看下SQLNET等日志文件，查看下是否SAP不能连接到数据库。
看了文件，没有任何发现，还看下相关的SQLNET的参数配置，也是正常的。
除此之外，没有发现有价值的线索。
对于陌生的系统，我习惯性的看下系统的配置。我在他们一筹莫展的时候去查看系统配置，问题就暴露出来了。
查看了系统配置了32G的内存，那SGA分配了多少，最高不能超过25G啊。
去查看SGA的参数，不看还好，一看吓一跳。分配了32G的内存给sga_max_size.
这是谁做的好事啊.没有一点Oracle的概念啊.Oracle的推荐是分配80%的内存给SGA+PGA。好家伙，全部都给了SGA，那PGA还怎么跑啊。
和Manager说了后，他们讨论后给出建议：给Lpar分配14G的内存（这是Ibm的P570，做了LPAR，可以做到动态调整内存），或者调小SGA的size；
@￥#@￥#￥#@！@#一番讨论后，最后决定给Lpar分配14G的内存。
在观察30分钟，系统恢复正常。
后来得知，他们这个PFILE文件是从生产库中拷贝过来的，没有修改就直接使用在测试环境中了。而生产环境的内存是64GB。DBA在做时候没有考虑到环境的差异性，才导致这次危机。
问题找到了，危机解除了。可认为这种情况不应该发生啊。
俗话说，阳光底下无新鲜事啊，类似的问题很多DBA们都遇到，但是这种问题“屡禁不止”。对于DBA来说，细心、多问个为什么、多思考下问题才能尽可能减少出错的几率。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/40239/viewspace-628422/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/40239/viewspace-628422/