原文：
自从Oracle 10g引入自动化管理内存参数特性以来，之前极度困扰DBA的sga pga参数设置问题似乎逐渐被人淡忘。 是的，理论上只要分配系统的80%左右的内存给DB，剩下的留给OS及其它应用，这是个非常不错的实践原则，也被实践所认可。 但是，计算机世界经常告诉我们的启示就是，这种自动化的智能性在某些极限的场景下常常为人误用。。。
IOT优化项目中，之前的测试环境：
32G物理内存，分给PGA 1.5G，sga_max_size=sga_target=18.8G。
从理论上讲， SGA应该是32 * 80% * 80% = 20.48G; PGA应该是32 * 80% * 20% = 5.12G
也就是说对于常见的OLTP应用，该系统的SGA值设置基本合理，PGA应该适度调大。
在测试期间发现，200个并发做select/insert操作时(读写比9:1) TPS稳定，server side表现尚且合理。
如果提高到500个并发时TPS会骤降， server side 挂掉， load 会在一分钟内达到200以上！
对于一个4CPU，32G内存的box来说，结果只能说极其的惨不忍睹。 于是在重现场景时实时监测一下系统资源，发现load骤升时cpu/io资源均表现合理，而memory达到瓶颈，需要tuning。
于是在DBA的帮助下，将PGA调大到4G，sga_max_size降为16G，sga_target降为12G，重新跑测试，一切正常。
结论1：不要迷信公式，掌握原理后，根据现象及产生的深度原因来tuning，才能正中要害
结论2：对于内网测试环境，由于测试场景众多，建议最好不要将sga_max_size和sga_target设为同一值， 生产系统自当别论：）