文件名称：Oracle 性能调整（真正由ORACLE甲骨文出品）
文件大小：482KB
文件格式：PDF
更新时间：2011-07-04 20:14:24
ORACLE 性能调整 甲骨文
Oracle 性能调整 （真正由ORACLE甲骨文出品）
如何开始调整？
– 解决性能问题的步骤
分析症状
确定问题范围
参数调整or
结构调整or
应用调整
性能监控
Shared Pool
– SHARED_POOL_SIZE 控制共享SQL缓冲存储区和数据字
典缓冲存储区的大小
– 字典缓冲存储区存储关于数据对象的信息
– 监控V$ROWCACHE，若命中率< 95%,考虑增加
SHARED_POOL_SIZE
– 监控V$LIBRARYCACHE 来确定多重加载的数量
– 若命中率< 75%，确定需要多重加载的对象
– V$SQLAREA, 检索可能的候选共享SQL
– 建议使用存储过程和变量
– 使用DBMS_SHARED_POOL把大的或常用的PL/SQL,
cursors, sequences, triggers, packages and procedures
预装入SGA
如果在应用SQL编程中不使用捆绑变量，很容易引起
shared_pool 和library cache 的latch 竞争.
这种latch等待时间可以通过优化SQL来减少.
Oracle 8i Release 2 (8.1.6)可以做直接常量和捆绑变量的
自动转换，Oracle9i又进一步扩充了该功能…
CURSOR_SHARING=FORCE
(Default is EXACT; 8iR2)
如果通过监测v$sqlarea发现有因为没有使用捆绑变量所引起
的性能问题:
50M的shared pool可以工作正常
50M的shared pool，当x$ksmsp中的记录数超过200,000条
时就可能会引起性能问题.
200M的shared pool，当x$ksmsp中的记录数超过580,000条
时，性能会无法忍受.
– 每个查询会耗用2%CPU
– 大量的I/O
所以:
– 170 meg = 5038 SQL Areas = 131319 x$ksmsp records
Keep the Shared_pool_size at 100M or lower (50M if possible).
If v$sqlarea looks like this:
select empno from rich778 where empno =451572
select empno from rich778 where empno =451573
select empno from rich778 where empno =451574
select empno from rich778 where empno =451575
select empno from rich778 where empno =451576
Use cursor_sharing=force (sqlarea goes to this):
select empno from rich778 where empno =:SYS_B_0
Oracle9i Enterprise Edition Release 9.0.1.0.0 - Production
(SIMILAR takes into account the statistics as well…)
SQL> alter session set cursor_sharing=SIMILAR;
System altered.
Oracle8i Enterprise Edition Release 8.1.7.0.0 – Production
SQL> alter session set cursor_sharing=SIMILAR;
ERROR: ORA-00096: invalid value SIMILAR for parameter
cursor_sharing, must be from among EXACT, FORCE