oracle SGA PGA UGA 内存
1.2.3 各个参数的设置那么SGA中的各个参数具体应该按照什么样的原则来设置呢，下面进行讨论：
log_buffer
对于日志缓冲区的大小设置，通常我觉得没有过多的建议，因为参考LGWR写的触发条件之后，我们会发现通常超过3M意义不是很大。作为一个正式系统，可能考虑先设置这部分为log_buffer=1—3M 大小，然后针对具体情况再调整。
large_pool_size
对
于大缓冲池的设置，假如不使用MTS，建议在20—30M 足够了。这部分主要用来保存并行查询时候的一些信息，还有就是RMAN
在备份的时候可能会使用到。如果设置了MTS，则由于UGA部分要移入这里，则需要具体根据session最大数量和 sort_ares_size
等相关会话内存参数的设置来综合考虑这部分大小的设置，一般可以考虑为 session * (sort_area_size +
2M)。这里要提醒一点，不是必须使用MTS，我们都不主张使用MTS，尤其同时在线用户数小于500的情况下。
java_pool_size
假如数据库没有使用JAVA，我们通常认为保留10—20M大小足够了。事实上可以更少，甚至最少只需要32k，但具体跟安装数据库的时候的组件相关(比如http server)。
shared_pool_size
这
是迄今为止最具有争议的一部分内存设置。按照很多文档的描述，这部分内容应该几乎和数据缓冲区差不多大小。但实际上情况却不是这样的。首先我们要考究一个
问题，那就是这部分内存的作用，它是为了缓存已经被解析过的SQL，而使其能被重用，不再解析。这样做的原因是因为，对于一个新的SQL
（shared_pool
里面不存在已经解析的可用的相同的SQL），数据库将执行硬解析，这是一个很消耗资源的过程。而若已经存在，则进行的仅仅是软分析（在共享池中寻找相同
SQL），这样消耗的资源大大减少。所以我们期望能多共享一些SQL，并且如果该参数设置不够大，经常会出现ora-04031错误，表示为了解析新的
SQL，没有可用的足够大的连续空闲空间，这样自然我们期望该参数能大一些。但是该参数的增大，却也有负面的影响，因为需要维护共享的结构，内存的增大也
会使得SQL 的老化的代价更高，带来大量的管理的开销，所有这些可能会导致CPU 的严重问题。
页:
[1]