应该让有效数据长时驻留在内存结构中,这是oracle性能调整中非常重要的一个课题。

应该 启用自动共享内存管理，把sga_target设置到一非零值，并把statistics_level设置为typical或者all。sga_target应该设置为操作系统内存总数中可以分配给oracle sga使用的内存量。sga_target受sga_max_size约束。sga_max_size定义了本机上oracle系统可以使用的最大sga。一般最大可达操作系统物理内存的70%.

*********sga内存分配原则(从aix角度出发)

1 减少页交换操作

当需要支持其他应用运行时，会按照LRU算法把当前驻留在内存中的数据页Page out到物理磁盘，显然，这会影响系统的运行性能。

所以一般在系统设计时，往往将数据库安装在一台服务器上，独占这台服务器的所有资源，避免页交换的产生。

2 sga 应宿主在物理内存中

分配sga的目的就是为了快速将数据存储在内存中。内存速度比硬盘速度至少快上4个数量级以上。所以如果sga对应的虚拟内存页被交换到换页空间(磁盘)上，那sga也就失去了意义。

3 为用户连接准备充足的内存资源

除了sga外，还需要为在系统上运行的服务器进程(pga)以及其他任务留下足够的内存。

***********db cache问题

db cache总量是有限的，为了有效使用db cache,就必须限定使用db cache的操作总量。从开发的角度出发，就要在开发中尽量减少其编写的SQL语句需要扫描的数据量，降低不必要的数据块扫描。所以应该评估SQL的i/o代价，优化SQL语句以及PL/SQL,函数等对象。

在安装配置oracle时，精确判定db cache的大小是不可能。正常的情况是，给出一个初始值，该值主要依赖于数据库服务器的内存总量以及能分配给oracle的部分。以后，应该经常性地跟踪db cache的使用效率。具体方法是：使用v$db_cache_advice,以db cache使用命中率作为主要评价标准。

db cache的大小和物理I/O的关系是一条反函数，db cache为横线，物理I/O为竖线，随着db cache的变大，物理I/O会变小，当db cache大到某一个最优点以后，此时，物理I/O最小，再加大db cache已经不会再让物理I/O减少。所以，盲目扩大数据库缓存没有必要。

*******分析db cache命中率

db cache命中率是指所需数据在缓存中被真到的概率。如果一条SQL操作访问的数据快能够在db cache中找到，则对应的物理I/O将会被避免。

需要三个统计参数consistent gets from cache一致性读,db block gets from cache 缓存读,physical reads cache物理读。这里提供一个脚本，用来判断db cache命令率:

SQL>select name,value

from v$sysstat

where name in('db block gets from cache','consistent gets from cache','physical reads cache');

命中率：1-(物理读)/(一致性读+缓存读),这个命中率越高越好。但也不能完全掉进命中率的陷阱，不能因为命中率低就去增加db cache,或因为命中率高就去减少db cache。必须站在全局的高度衡量问题。

*********增大数据缓存的工作步骤：

1:db_cache_advice设置为on,并连续工作了一段时间。

2:查询v$db_cache_advice,查看增加数据缓存导致I/O减少的比率，实现以性价比为依据。

3:判断增加数据缓存是否片面(增加以后，减少了操作系统内存使用，导致操作系统上的页交换，则综合结果为负)。

4:使用alter system命令增加数据块缓存尺寸。

SQL>alter system set db_cache_size=??M scope =both;(如果不成功，调整sga_target,sga_max_size)

******优化并不总是加大db_cache_size,在下面情况下需要缩小

1:db_cache总是保持较高的命中率，查询v$db_cache_advice发现缩减db_cache并不会引起显著的物理I/O增加。(反函数关系)

2:操作系统出现频繁的页交换(Page in/Out).

*********shared pool使用问题

从性能上看,应该尽可能实现软解析,减少硬解析。做到这一点需要进行两方面工作：能够重用的SQL和PL/SQL,足够尺寸的shared pool.

**************SQL和PL/SQL的重用：

1:开发SQL,PL/SQL时，要采用相同的编程规范，在程序中尽量避免使用动态SQL,尽量使用绑定变量，尽量采用存储过程，函数或者包，包体。

2:避免在应用高峰时段执行表的DDL操作，因为这会导致依赖于表，索引的SQL必须做硬解析---他们多依赖的对象结构发生了变化。

3:对于序列对象，应该赋予其足够的缓存，这会减少资源锁的使用频率。

******shared pool 尺寸设定

一般而言，如果library cache，dictionary cache命中率低于90%,则考虑增加shared_pool_size的值。但同时要注意shard_pool_size的边际效益。