OCP认证033之自制讲稿—调整共享池

9. 是否共享了Cursor
   /查询V$librarycache,检查SQL AREA的gethitratio
     select gethitratio from v$libararycache where namespace='SQL AREA';
    这个命中率 = gethits/gets, 表示软分析次数与分析次数的比值
    OLTP系统应该>=90%,如果<90%,你可能需要
     --改写你的应用程序中的Statement了，提高效率。但往往你可能无法去调整应用程序的代码，因为你没有。
     --增加共享池的大小
     --调查那些SQL正在执行
       select sql_text, users_excuting,executions, loads from v$sqlarea;
         --users_excuting查询的时候，正在执行的次数
         --excutions  总的执行次数
         --loads      这个数值越低越好
       select * from v$sqltext where sql_text like 'select * from hr.employees where %';

10. 共享游标
   /初始化参数 CURSOR_SHARING,有三个取值：exact, similar, force
     --exact 默认值，2个sql语句必须完全一样才共享缓存中的已分析代码 
     --similar  当2个sql仅只有参数变量值不一样而结构完全一样时,而且执行计划一样就共享
     --force 当2个sql仅只有参数变量值不一样而结构完全一样时也共享，不考虑执行计划的影响，比如
        select * from employees where employee_id=1000;
        select * from employees where employee_id=1234;
11. 准则：库缓存的丢失率(reloads)
    /reload应该小于PINS的1%
     select sum(pins) "executions", sum(reloads) "cache misses",
            sum(reloads)/sum(pins) from v$libararycache;
   /当其>1%时，有两种可能的原因
     --因为没有空间了，曾经分析执行过的代码被赶出去了，对策：增加shared pool大小，当然SGA要有空闲空间
     --共享的代码 invalidated了
      对策：避免在高负荷时修改数据结构和收集数据统计，创建索引等，把这些工作调整到负荷低的时候去做

12. 调整库缓存
   /当gethitratio<90%或丢失率>1%时，就需要优化
   /对于频繁要用的PL/SQL包，触发器，sequence，永久将他们缓存在内存中
   /为常用的SQL定义足够的内存
   /为大内存需求的对象保留空间，这样可以避免碎片(碎片会导致这些内存不可用而浪费)
   /栓住那些常用的对象
   /将大的匿名PL/SQL块改写成小的包函数
    将匿名PL/SQL块改写成存储过程，不管他们是大还是小的匿名块

13. 共享池建议
    可以通过OEM来查看oracle server建议的共享池大小，也可以查询视图
    select shared_pool_size_for_estimate as pool_size, estd_lc_size,estd_lc_time_saved from v$shared_pool_advice;
     shared_pool_size_for_estimate：表示估计的共享池大小,取值范围,当前库缓存大小的50---200%,每个估计值一行
     estd_lc_size: 对应分配的library cache大小，
     estd_lc_time_saved: 估计的能保留的时长
    怎么决定库缓存的大小呢，当estd_ls_size增大时，estd_lc_time不再发生变化时，我们取第一个这样的share_pool_size_for_estimate作为我们的共享池大小。

14. 执行计划
   /oracle server把SQL解析执行过的执行计划缓存在内存中，供下次共享使用，而不必再执行一次硬分析，直接找到相应的内存中的执行计划来执行SQL
   /当SQL在内存中被淘汰，相对应的执行计划也会被请出libarary cache
   /这个特性最主要的好处就是能更好的诊断查询执行效率
   /怎样查询SQL的执行计划
  select operation,object_owner,object_name,cost from v$sql_plan order by hash_value
   /在v$sql视图中有一列hash_value(书上错：不应该是书上说的plan_hash_value)和v$sql_plan的列hash_value相对应
  /hash_value还可以用来比较Cursor SQL TEXT是否相似

15 计算Global Space
   /计算存储对象需要的空间大小，比如包，函数，存储过程
    select sum(sharable_mem) from v$db_object_view
      [where type in ('PACKAGE','PACKAGE BODY','PROCEDURE','FUNCTION')]
   /计算经常执行的SQl需要的空间大小
    select sum(sharable_meme) from v$sql_are where execution>5
   /计算高峰时所有打开游标需要的空间，假如每个用户每个游标的最大允许大小是250B
    select sumI(250*user_opening) from v$sqlarea
    /理想状态下，您的生产环境的library cache应该是这些数字之和，并且加上一定的缓冲大小
   /在测试环境中，你也可以用一个典型用户来计算可能需要需要的平均游标空间,
   select 250*value bytes_per_user from v$sesstat s, v$statname n where s.statistic$=n.statistics#
     and n.name='opened cursors curent' and s.sid=15;

16. 大内存需求(oracle自身运行的大程序段，package等，超过1万byte的程序段)
    /有大的连续内存满足需求
    /在共享池中为他们保留一定的连续空间
    /V$shared_pool_reserved视图中的列说明
     --free_space:    保留空间列表中所有的空闲空间
     --Avg_Free_Size: 保留空间列表空闲内存的平均值
     --Max_Free_Size: 保留空间列表空闲内存的最大值
     --Request_misses：因为没有一个满足需求的连续空闲内存，LRU列表不得不flush对象来满足请求的次数
     --request_failuers: 没有空闲空间导致请求失败的次数
     --last_failures_size:最后一次请求失败需要的内存大小
     --其他
   /初始化参数：shared_pool_size
          shared_pool_reserved_size 一般为share_pool_size的10%, 是shared_pool_size的一部分，不是另外开辟一块内存
          最大值是share_pool_size的50%, 大于50%会报错

17. 调整共享池保留空间
   /诊断工具       V$shared_pool_reserved
     --在一个有足够空闲内存的系统，调整的目标是 request_misses=0
   /通过dbms_shared_pool_pachage.aborted_request_threshold过程来设置一个阀值
    比如有个包在reserver中请求2M空间，reserver会去找一个2M的连续空间出来，一般情况下，如果没有则会请出一些对象以获得这2M内存，但是你可以设置一个阀值比2M小一点，那么不管有没有2M或者以上的空闲内存，就都不会让2M及其以上的对象进来
   /设置初始化参数shared_pool_reserved_size
     ---当shared_pool_reserved_size太小，可以适当增大他的大小
     --当他太大，以下任何一种情况满足应该适当减小shared_pool_reserved_size的值
        /request_miss=0或者保持一个值而不再增大是，可以减小shared_pool_reserved_size到一个适合这个情况的最小值，
         释放出不必要的内存给其他的人用
        /shared_pool_reserved中如果Free_space 大于其50%时 
   /shared_pool_size太小时
    使用V$shared_pool_reserved也可以诊断出shared_pool_size太小，这是request_failuer>0并且持续增大的一个原因，这个时候，如果
    你已经启用了the reserved list,那么减小shared_pool_reserved_size的大小，如果没有，则要增加shared_pool_size的大小。
  
18. 在共享池中栓住大对象
   /调查库缓存中那些大对象没有被栓住, 比如大于1万字节的
    select * from v$db_object_cache where shareable_mem>10000
     and kept='NO' [and type in ('PACKAGE', 'PACKAGE BODY', 'FUNCTION','PROCEDURE')]
   /用什么工具来栓住他们到共享池中，用dbms_shared_pool.keep(package_nem)这个包过程
    现在我们应该知道为什么要栓住这些大对象吧，如果不栓住这些大对象，在加载到库池时极容易引起内存碎片，为了能够获得足够的连续空间，甚至需要将大量的小对象从共享池中赶出去，这样将会导致命中率低，响应用户的时间增加，对不对啊！为了避免这种糟糕的情况发生，我们就有必要以启动instance,就先栓住这些常用的大对象，这样他们可以一直保存在内存中，也不再去和那些小对象去抢空间了。
   /那些对象应该被栓住
    --经常需要的大的存储过程，比如standard包，diutil包以及那些超过定义的阀值的常用的大对象
    --使用频率很高的那些表对应的触发器
    --序列sequence, 缓存起来可以增加响应的速度，（创建sequence有一个cache N从句，可以一次生成多少个值缓存起来）
   /什么时候栓住他们最好
    在前面我已经提到过好几次了，大家想起来了没有。在instance一起来就把他们栓住。
   /凡是被栓住的对象，即使你执行alter system flush shared_pool;时也不会被赶出去，还在里面，是不是很有好处啊？

上一页  [1] [2] [3] 下一页

【责编:Yoyo】