oracle sequences优化_系统参数设置-Oracle性能优化(精)

一、

SGA 1

、

Shared pool tunning Shared pool

的优化应该放在优先考虑，因为

一个

cache miss

在

shared pool

中发生比在

data buffer

中发生导致的成本更高，

由于

dictionary

数据一般比

library cache

中的数据在内存中保存的时间长，

所以关键是

library cache

的优化。

Gets

：(

parse

)在

namespace

中查找对象的次数；

Pins

：

(

execution

)在

namespace

中读取或执行对象的次数；

Reloads

：

(reparse

在执行阶

段

library cache misses

的次数，导致

sql

需要重新解析。

1

)

检查

v$librarycache

中

sql area

的

gethitratio

是否超过

90

％，如果未超过

90

％，应该检查应用代码，提高

应用代码的效率。

Select gethitratio from v$librarycache where namespace=’sql area’;

2 v$librarycache

中

reloads/pins

的比率应该小于

1

％，如果大于

1

％，应该增加参数

shared_pool_size

的值。

Select sum(pins “executions”,sum(reloads “cache

misses”,sum(reloads/sum(pins from v$librarycache; reloads/pins>1%

有两种可能，一种

是

library cache

空间不足，一种是

sql

中引用的对象不合法。

3

)

shared pool

reserved size

一般是

shared pool size

的

10

％，不能超过

50

％。

V$shared_pool_reserved

中的

request misses

＝

0

或没有持续增长，或者

free_memory

大于

shared pool reserved size

的

50%

，

表明

shared pool reserved size

过大，可以压

缩。

4

)将大的匿名

pl/sql

代码块转换成小的匿名

pl/sql

代码块调用存储过程。

5

)

从

9i

开始，可以将

execution plan

与

sql

语句一起保存在

library cache

中，方便进行

性能诊断。

从

v$sql_plan

中可以看到

execution plans

。

6

)保留大的对象在

shared

pool

中。大的对象是造成内存碎片的主要原因，为了腾出空间许多小对象需要移出

内存，

从而影响了用户的性能。因此需要将一些常用的大的对象保留在

shared

pool

中，下列对象需要保留在

shared pool

中：

a.

经常使用的存储过程；

b.

经常操

作的表上的已编译的触发器

c. Sequence

，因为

Sequence

移出

shared pool

后可能产

生号码丢失。

查找没有保存在

library cache

中的大对象：

Select * from

v$db_object_cache where sharable_mem>10000 and type in

('PACKAGE','PROCEDURE','FUNCTION','PACKAGE BODY' and kept='NO';

将这些

对象保存在

library cache

中：

Execute dbms_shared_pool.keep(‘package_name’;

对应

脚本：

dbmspool.sql 7

查找是否存在过大的匿名

pl/sql

代码块。两种解决方案：

A

．转换成小的匿名块调用存储过程

B

．将其保留在

shared pool

中

查找是否存在过