sga&uga&pga

1. SGA的设置

Fixed Size
oracle 的不同平台和不同版本下可能不一样，但对于确定环境是一个固定的值，里面存储了SGA 各部分组件的信息，可以看作引导建立SGA的区域。

Variable Size
包含了shared_pool_size、java_pool_size、 large_pool_size 等内存设置

Database Buffers
指
数据缓冲区，在8i
中包含db_block_buffer*db_block_size、buffer_pool_keep、 buffer_pool_recycle
三部分内存。在9i 中包含db_cache_size、db_keep_cache_size、db_recycle_cache_size、
db_nk_cache_size。

Redo Buffers
指日志缓冲区，log_buffer。在这里要额外说明一点的是，对
于 v$parameter、v$sgastat、v$sga查询值可能不一样。v$ parameter
里面的值，是指用户在初始化参数文件里面设置的值，v$sgastat是oracle
实际分配的日志缓冲区大小（因为缓冲区的分配值实际上是离散的，也不是以block 为最小单位进行分配的），v$sga
里面查询的值，是在oracle 分配了日志缓冲区后，为了保护日志缓冲区，设置了一些保护页，通常我们会发现保护页大小是8k(不同环境可能不一样)。

1.2 SGA的大小设置
1.2.1 设置参数前的准备
在设置SGA的内存参数之前，我们首先要问自己几个问题
一：物理内存多大
二：操作系统估计需要使用多少内存
三：数据库是使用文件系统还是裸设备
四：有多少并发连接
五：应用是OLTP 类型还是OLAP 类型
关
于文件系统和裸设备的问题，这往往容易被我们所忽略。操作系统对于文件系统，使用了大量的 buffer
来缓存操作系统块。这样当数据库获取数据块的时候，虽然SGA
中没有命中，但却实际上可能是从操作系统的文件缓存中获取的。而假如数据库和操作系统支持异步IO，则实际上当数据库写进程DBWR写磁盘时，操作系统在
文件缓存中标记该块为延迟写，等到真正地写入磁盘之后，操作系统才通知DBWR写磁盘完成。对于这部分文件缓存，所需要的内存可能比较大，作为保守的估
计，我们应该考虑在 0.2——0.3 倍内存大小。但是如果我们使用的是裸设备，则不考虑这部分缓存的问题。这样的情况下SGA就有调大的机会。
关
于数据库有多少并发连接，这实际上关系到PGA 的大小（MTS 下还有large_pool_size）。事实上这个问题应该说还跟OLTP
类型或者OLAP 类型相关。对于OLTP类型oracle 倾向于可使用MTS,对于OLAP 类型使用独立模式，同时OLAP
还可能涉及到大量的排序操作的查询，这些都影响到我们内存的使用。那么所有的问题综合起来，实际上主要反映在UGA的大小上。UGA主要包含以下部分内存
设置
SQL> show parameters area_size

NAME TYPE VALUE
------------------------------------ ------- --------
bitmap_merge_area_size integer 1048576
create_bitmap_area_size integer 8388608
hash_area_size integer 131072
sort_area_size integer 65536
在
这个基础上，我们假设数据库存在并发执行server process 为100 个，根据上面我们4 个参数在oracle8.1.7
下的默认值，我们来计算独立模式下PGA 的大致大小。由于会话并不会经常使用create_bitmap_area_size
、bitmap_merge_area_size，所以我们通常不对四个参数求和。在考虑到除这四个参数外会话所保存的变量、堆栈等信息，我们估计为
2M，则200 个进程最大可能使用200M 的PGA。

1.2.2 一个经验公式
OS 使用内存+SGA+并发执行进程数*(sort_area_size+hash_ara_size+2M) < 0.7*总内存

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 的严重问题。

在一个充分使用绑定变量的比较大的系统
中，shared_pool_size 的开销通常应该维持在300M 以内。除非系统使用了大量的存储过程、函数、包，比如oracle erp
这样的应用，可能会达到500M甚至更高。于是我们假定一个1G内存的系统，可能考虑设置该参数为100M，2G 的系统考虑设置为150M,8G
的系统可以考虑设置为200—300M。
对于一个没有充分使用或者没有使用绑定变量系统，这可能给我们带来一个严重的问题。所谓没有使用bind var 的SQL，我们称为Literal SQL。也就是比如这样的两句SQL我们认为是不同的SQL,需要进行2 次硬解析：
select * from EMP where name = ‘TOM’;
select * from EMP where name = ‘JERRY’;
假
如把 ’TOM’ 和 ’JERRY’ 换做变量V，那就是使用了bind var，我们可以认为是同样的SQL 从而能很好地共享。共享SQL
本来就是 shared_pool_size 这部分内存存在的本意，oracle的目的也在于此，而我们不使用bind var
就是违背了oracle
的初衷，这样将给我们的系统带来严重的问题。当然，如果通过在操作系统监控，没有发现严重的cpu问题，我们如果发现该共享池命中率不高可以适当的增加
shred_pool_size。但是通常我们不主张这部分内存超过800M（特殊情况下可以更大）。
事实上，可能的话我们甚至要想办法避免软分析，这在不同的程序语言中实现方式有差异。我们也可能通过设置session_cached_cursors 参数来获得帮助（这将增大PGA）
关于使用绑定变量的话题，在下面的应用优化中继续讨论。

Data buffer
现
在我们来谈数据缓冲区，在确定了SGA
的大小并分配完了前面部分的内存后，其余的，都分配给这部分内存。通常，在允许的情况下，我们都尝试使得这部分内存更大。这部分内存的作用主要是缓存
DB BLOCK，减少甚至避免从磁盘上获取数据，在8i中通常是由db_block_buffers*db_block_size
来决定大小的。如果我们设置了buffer_pool_keep 和buffer_pool_recycle，则应该加上后面这两部分内存的大小。

可以看出，设置SGA时基本上应该掌握的原则是：
data buffer 一般可以尽可能的大
shared_pool_size 应该适度
log buffer 在 1MB 以内就可以了

假定 oracle是 32 bit ,服务器RAM大于2G ，注意你的PGA的情况，,则建议
shared_pool_size + data buffer +large_pool_size + java_pool_size < 1.6G

在32bit的数据库下，通常oracle只能使用不超过1.7G的内存。
trace session的方式是一种自下而上的方法，从sql入手；而statspack是自顶向下的方法.

在
Oracle 9i 中，optimizer_mode 参数有四种取值，决定了四种优化模式： rule, choose, all_rows, 和
first_rows，其中 rule 和 choose 两种模式表示目前已经过时的基于规则的优化器模式（rule-based
optimizer，简称RBO），所以我们在此着重讨论后两种CBO模式