oracle动态性能表之shared_pool相关

1）v$shared_pool_advice
这张动态性视图是oracle根据当前系统的负荷进行分析，而得出的推荐值，相关字段如下：

 SHARED_POOL_SIZE_FOR_ESTIMATE  NUMBER  共享池的估计值

 SHARED_POOL_SIZE_FACTOR  NUMBER  当前共享池大小的倍数

 ESTD_LC_SIZE  NUMBER  估计librarycache的大小值
 ESTD_LC_MEMORY_OBJECTS  NUMBER  估计在当前指定的共享池中库缓存对象的数量

 ESTD_LC_TIME_SAVED  NUMBER  考虑在当前指定共享池的大小中找到库缓存对象，所节省的时间（秒）
 ESTD_LC_TIME_SAVED_FACTOR  NUMBER  考虑在当前共享池的大小的前提下，估计节省解析时间的倍数
 ESTD_LC_LOAD_TIME  NUMBER  估计在当前指定共享池的大小前提下，解析所消逝的时间（秒）
 ESTD_LC_LOAD_TIME_FACTOR  NUMBER  考虑在当前指定共享池大小的前提下，估计读取时间的倍数
 ESTD_LC_MEMORY_OBJECT_HITS  NUMBER  估计在当前指共享池大小下库缓存对象被命中的次数

 所以根据：

SELECT shared_pool_size_for_estimate, estd_lc_size, estd_lc_memory_objects,estd_lc_time_saved, estd_lc_time_saved_factor,estd_lc_memory_object_hits FROM v$shared_pool_advice;

我们便能很快得到oracle根据当前负荷给出的shared_pool推荐值，依据查询结果的命中次数趋于平缓时，oracle的推荐值。

 

2）V$LIBRARYCACHE

这张视图主要包括和librarycache的性能和活动的统计信息，根据这张视图我们可以轻易得到当前librarycache的各项指标信息，字段说明如下：

 NAMESPACE  VARCHAR2(15)  Library cache namespace
 GETS  NUMBER  请求获取的次数
 GETHITS  NUMBER  请求获取对象命中的次数
 GETHITRATIO  NUMBER  GETHITS 与GETS比值，即对象共享的命中率
 PINS  NUMBER  对象请求执行的次数
 PINHITS  NUMBER  对象请求执行命中的次数

 PINHITRATIO  NUMBER  PINHITS 与PINS比值，即对象执行的命中率
 RELOADS  NUMBER  对象被librarycache通过LRU算法清除后，又被重新解析放入librarycache中的次数

 INVALIDATIONS  NUMBER  请求执行对象时，发现对象被修改了（一般指DDL，dbms_stats,analyze等操），
                                           要 求 重新读取，而导致对象无效的次数
 DLM_LOCK_REQUESTS  NUMBER  Number of GET requests lock instance locks
 DLM_PIN_REQUESTS  NUMBER  Number of PIN requests lock instance locks
 DLM_PIN_RELEASES  NUMBER  Number of release requests PIN instance locks
 DLM_INVALIDATION_REQUESTS  NUMBER  Number of GET requests for invalidation instance locks
 DLM_INVALIDATIONS  NUMBER  Number of invalidation pings received from other instances

 

对于namespace，oracle官方建议只看前4项的值。
可以通过下面语句判断当前librarycache是不是太小了，如果reload-to-pin的值大于0.1，说明太小，应该增大shared_pool_size（因为不能直接设置librarycache大小，只能通过增加shared_pool_size来增加它）
    select sum(pins) "Executions",
        sum(reloads) "Cache Misses",
        sum(reloads) / sum(pins) " reload-to-pins"
    from v$librarycache;

另外如果GETHITRATIO  值小于95%的话，就说明shared_pool共享池SQL共享率比较低，需要检查一下SQL和共享池的大小。

3）v$sql
    存储的是具体的SQL 和执行计划相关信息，实际上，v$sqlarea 可以看做 v$sql 根据 sqltext 等做了 group by 之后的信息，v$sql   join  to  v$sql_plan  就代表了具体的sql的执行计划,通过下面3个字段做连接
 ADDRESS                                                  RAW(4)
 HASH_VALUE                                            NUMBER
 CHILD_NUMBER                                        NUMBER
举例：
select a.OPERATION,a.OPTIONS,a.OBJECT_name,a.COST,a.BYTES,a.IO_COST
  from v$sql_plan a where a.HASH_VALUE='3464022363' and a.ADDRESS=hextoraw('66726E58')
 and a.CHILD_NUMBER=0;
关于v$sql表示字段信息，参见下面v$sqlarea视图

4）v$sqlarea
     存储的SQL 和一些相关的信息，比如累计的执行次数，逻辑读，物理读等统计信息，通过这个动态性能视图，可以查看SQL的执行情况，找出最消耗资源的SQL。相关重要字段信息说明如下：
     HASH_VALUE：SQL语句的Hash值。
     ADDRESS：SQL语句在SGA中的地址
     PARSING_USER_ID：为语句解析第一条CURSOR的用户
     VERSION_COUNT：语句cursor的数量
     KEPT_VERSIONS：
     SHARABLE_MEMORY：cursor使用的共享内存总数
     PERSISTENT_MEMORY：cursor使用的常驻内存总数
     RUNTIME_MEMORY：cursor使用的运行时内存总数。
     SQL_TEXT：SQL语句的文本（最大只能保存该语句的前1000个字符）。
     MODULE,ACTION：使用了DBMS_APPLICATION_INFO时session解析第一条cursor时的信息
     SORTS: 语句的排序数
     CPU_TIME: 语句被解析和执行的CPU时间
     sorts       所有的子游标排序的次数
     executions     所有的子游标执行的总次数
     invalidations  所有的子游标无效的次数

     parse_calls     所有的子游标解析的次数

     disk_reads     所有的子游标磁盘读的量

     buffer_gets    所有的子游标缓冲区读的量(内存读)

     rows_processed   所有的子游标处理的行数综合

例如查询消耗资源最多的SQL语句：

 SELECT hash_value, executions, buffer_gets, disk_reads, parse_calls
 FROM V$SQLAREA
 WHERE buffer_gets > 10000000 OR disk_reads > 1000000
 ORDER BY buffer_gets + 100 * disk_reads DESC;

5）v$sqltext
    存储的是完整的SQL。

相关参数设置：
shared_pool_size
open_cursors   含义就是这个Session中能够打开游标的最大数
session_cached_cursors  设置session_cached_cursors减少软解析的次数
cursor_space_for_time
cursor_sharing                 取值：exact,similar,force
shared_pool_reserved_size

更新系统级的session_cached_cursors初始值
1)create pfile from spfile
2)shutdown abort
3)编辑INIT，在最后添加：session_cached_cursors=20