1.1.4.7. 共享池的重要视图
最后,我们再介绍关于共享池的一些重要视图
· v$shared_pool_advice
这个视图与Oracle的另外一个优化建议器——共享池建议器——相关。我们可以根据这个视图里面oracle所做的预测数据来调整共享池大小。它的预测范围是从当前值的10%到200%之间。视图的结构如下
字段 | 数据类型 | 描述 |
SHARED_POOL_SIZE_FOR_ESTIMATE | NUMBER | 估算的共享池大小(M为单位) |
SHARED_POOL_SIZE_FACTOR | NUMBER | 估算的共享池大小与当前大小比 |
ESTD_LC_SIZE | NUMBER | 估算共享池中用于库缓存的大小(M为单位) |
ESTD_LC_MEMORY_OBJECTS | NUMBER | 估算共享池中库缓存的内存对象数 |
ESTD_LC_TIME_SAVED | NUMBER | 估算将可以节省的解析时间。这些节省的时间来自于请求处理一个对象时,重新将它载入共享池的时间消耗和直接从库缓存中读取的时间消耗的差值。 |
ESTD_LC_TIME_SAVED_FACTOR | NUMBER | 估算的节省的解析时间与当前节省解析时间的比。 |
ESTD_LC_MEMORY_OBJECT_HITS | NUMBER | 估算的可以直接从共享池中命中库缓存的内存对象的命中次数。 |
关于如何根据建议器采用合理的共享池大小的方法,和前面提到的缓冲区建议器的使用方法类似,不再赘述。
· V$SHARED_POOL_RESERVED
前面提到了这个视图。这个视图存放了共享池保留区的统计信息。可以根据这些信息来调整保留区。视图结构如下:
Column | Datatype | Description |
以下字段只有当参数SHARED_POOL_RESERVED_SIZE设置了才有效。 | ||
FREE_SPACE | NUMBER | 保留区的空闲空间数。 |
AVG_FREE_SIZE | NUMBER | 保留区的空闲空间平均数。 |
FREE_COUNT | NUMBER | 保留区的空闲内存块数 |
MAX_FREE_SIZE | NUMBER | 最大的保留区空闲空间数。 |
USED_SPACE | NUMBER | 保留区使用空间数。 |
AVG_USED_SIZE | NUMBER | 保留区使用空间平均数。 |
USED_COUNT | NUMBER | 保留区使用内存块数。 |
MAX_USED_SIZE | NUMBER | 最大保留区使用空间数 |
REQUESTS | NUMBER | 请求再保留区查找空闲内存块的次数。 |
REQUEST_MISSES | NUMBER | 无法满足查找保留区空闲内存块请求,需要从LRU列表中清出对象的次数。 |
LAST_MISS_SIZE | NUMBER | 请求的内存大小,这次请求是最后一次需要从LRU列表清出对象来满足的请求。 |
MAX_MISS_SIZE | NUMBER | 所有需要从LRU列表清出对象来满足的请求中的内存最大大小 |
以下字段无论参数SHARED_POOL_RESERVED_SIZE是否设置了都有效。 | ||
REQUEST_FAILURES | NUMBER | 没有内存能满足的请求次数(导致4031错误的请求) |
LAST_FAILURE_SIZE | NUMBER | 没有内存能满足的请求所需的内存大小(导致4031错误的请求) |
ABORTED_REQUEST_THRESHOLD | NUMBER | 不清出对象的情况下,导致4031错误的最小请求大小。 |
ABORTED_REQUESTS | NUMBER | 不清出对象的情况下,导致4031错误的请求次数。。 |
LAST_ABORTED_SIZE | NUMBER | 不清出对象的情况下,最后一次导致4031错误的请求大小。 |
我们可以根据后面4个字段值来决定如何设置保留区的大小以避免4031错误的发生。
· v$db_object_cache
这一视图显示了所有被缓存在library cache中的对象,包括表、索引、簇、同义词、PL/SQL存储过程和包以及触发器。
字段 | 数据类型 | 说明 |
OWNER | VARCHAR2(64) | 对象所有者 |
NAME | VARCHAR2(1000) | 对象名称 |
DB_LINK | VARCHAR2(64) | 如果对象存在db link的话,db link的名称 |
NAMESPACE | VARCHAR2(28) | 库缓存的对象命名空间,包括: TABLE/PROCEDURE, BODY, TRIGGER, INDEX, CLUSTER, OBJECT, CURSOR, INVALID NAMESPACE, JAVA SHARED DATA, PUB_SUB, RSRC CONSUMER GROUP |
TYPE | VARCHAR2(28) | 对象类型,包括:INDEX, TABLE, CLUSTER, VIEW, SET, SYNONYM, SEQUENCE, PROCEDURE, FUNCTION, PACKAGE, PACKAGE BODY, TRIGGER, CLASS, OBJECT, USER, DBLINK, CURSOR, JAVA CLASS, JAVA SHARED DATA, NON-EXISTENT, NOT LOADED, PUB_SUB, REPLICATION OBJECT GROUP, TYPE |
SHARABLE_MEM | NUMBER | 对象消耗的共享池中的共享内存 |
LOADS | NUMBER | 对象被载入次数。即使对象被置为无效了,这个数字还是会增长。 |
EXECUTIONS | NUMBER | 对象执行次数,但本视图中没有被使用。可以参考视图v$sqlarea中执行次数。 |
LOCKS | NUMBER | 当前锁住这个对象的用户数(如正在调用、执行对象)。 |
PINS | NUMBER | 当前pin住这个对象的用户数(如正在编译、解析对象)。 |
KEPT | VARCHAR2(3) | 对象是否被保持,即调用了DBMS_SHARED_POOL.KEEP来永久将对象pin在内存中。 (YES | NO) |
CHILD_LATCH | NUMBER | 正在保护该对象的子latch的数量。 |
· v$sql、v$sqlarea 、v$sqltext
这三个视图都可以用于查询共享池中已经解析过的SQL语句及其相关信息。
V$SQL中列出了共享SQL区中所有语句的信息,它不包含GROUP BY字句,并且为每一条SQL语句中单独存放一条记录;
V$SQLAREA中一条记录显示了一条共享SQL区中的统计信息。它提供了有在内存中、解析过的和准备运行的SQL语句的统计信息;
V$SQLTEXT包含了库缓存中所有共享游标对应的SQL语句。它将SQL语句分片显示。
下面介绍一下我常用的V$SQLAREA的结构:
字段 | 数据类型 | 说明 |
SQL_TEXT | VARCHAR2(1000) | 游标中SQL语句的前1000个字符。 |
SHARABLE_MEM | NUMBER | 被游标占用的共享内存大小。如果存在多个子游标,则包含所有子游标占用的共享内存大小。 |
PERSISTENT_MEM | NUMBER | 用于一个打开这条语句的游标的生命过程中的固定内存大小。如果存在多个子游标,则包含所有子游标生命过程中的固定内存大小。 |
RUNTIME_MEM | NUMBER | 一个打开这条语句的游标的执行过程中的固定内存大小。如果存在多个子游标,则包含所有子游标执行过程中的固定内存大小。 |
SORTS | NUMBER | 所有子游标执行语句所导致的排序次数。 |
VERSION_COUNT | NUMBER | 缓存中关联这条语句的子游标数。 |
LOADED_VERSIONS | NUMBER | 缓存中载入了这条语句上下文堆(KGL heap 6)的子游标数。 |
OPEN_VERSIONS | NUMBER | 打开语句的子游标数。 |
USERS_OPENING | NUMBER | 打开这些子游标的用户数。 |
FETCHES | NUMBER | SQL语句的fetch数。 |
EXECUTIONS | NUMBER | 所有子游标的执行这条语句次数。 |
USERS_EXECUTING | NUMBER | 通过子游标执行这条语句的用户数。 |
LOADS | NUMBER | 语句被载入和重载入的次数 |
FIRST_LOAD_TIME | VARCHAR2(19) | 语句被第一次载入的时间戳。 |
INVALIDATIONS | NUMBER | 所以子游标的非法次数。 |
PARSE_CALLS | NUMBER | 所有子游标对这条语句的解析调用次数。 |
DISK_READS | NUMBER | 所有子游标运行这条语句导致的读磁盘次数。 |
BUFFER_GETS | NUMBER | 所有子游标运行这条语句导致的读内存次数。 |
ROWS_PROCESSED | NUMBER | 这条语句处理的总记录行数。 |
COMMAND_TYPE | NUMBER | Oracle命令类型代号。 |
OPTIMIZER_MODE | VARCHAR2(10) | 执行这条的优化器模型。 |
PARSING_USER_ID | NUMBER | 第一次解析这条语句的用户的ID。 |
PARSING_SCHEMA_ID | NUMBER | 第一次解析这条语句所用的schema的ID。 |
KEPT_VERSIONS | NUMBER | 所有被DBMS_SHARED_POOL包标识为保持(Keep)状态的子游标数。 |
ADDRESS | RAW(4 | 8) | 指向语句的地址 |
HASH_VALUE | NUMBER | 这条语句在library cache中hash值。 |
MODULE | VARCHAR2(64) | 在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_MODULE设置的模块名称。 |
MODULE_HASH | NUMBER | 模块的Hash值 |
ACTION | VARCHAR2(64) | 在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_ACTION设置的动作名称。 |
ACTION_HASH | NUMBER | 动作的Hash值 |
SERIALIZABLE_ABORTS | NUMBER | 所有子游标的事务无法序列化的次数,这会导致ORA-08177错误。 |
IS_OBSOLETE | VARCHAR2(1) | 游标是否被废除(Y或N)。当子游标数太多了时可能会发生。 |
CHILD_LATCH | NUMBER | 为了包含此游标的子latch数。 |
查看当前会话所执行的语句以及会话相关信息:
SQL> select a.sid||'.'||a.SERIAL#, a.username, a.TERMINAL, a.program, s.sql_text
2 from v$session a, v$sqlarea s
3 where a.sql_address = s.address(+)
4 and a.sql_hash_value = s.hash_value(+)
5 order by a.username, a.sid;
... ...
SQL>
· v$sql_plan
视图V$SQL_PLAN包含了library cache中所有游标的执行计划。通过结合v$sqlarea可以查出library cache中所有语句的查询计划。先从v$sqlarea中得到语句的地址,然后在由v$sql_plan查出它的查询计划:
SQL> select lpad(' ', 2*(level-1))||operation "Operation",
2 options "Options",
3 decode(to_char(id), '0', 'Cost='||nvl(to_char(position), 'n/a'), object_name) "Object Name",
4 substr(optimizer, 1, 6) "Optimizer"
5 from v$sql_plan a
6 start with address = 'C0000000FCCDEDA0'
7 and id = 0
8 connect by prior id = a.parent_id
9 and prior a.address = a.address
10 and prior a.hash_value = a.hash_value;
Operation Options Object Name Optimizer
------------------- -------------------- -------------------- ---------
SELECT STATEMENT Cost=0 CHOOSE
NESTED LOOPS
INDEX RANGE SCAN CSS_BL_CNTR_IDX1 ANALYZ
INDEX RANGE SCAN CSS_BKG_BL_ASSN_UQ1 ANALYZ
SQL>
· v$librarycache
这个视图包含了关于library cache的性能统计信息,对于共享池的性能调优很有帮助。它是按照命名空间分组统计的,结构如下:
字段 | 数据类型 | 说明 |
NAMESPACE | VARCHAR2(15) | library cache的命名空间 |
GETS | NUMBER | 请求GET该命名空间中对象的次数。 |
GETHITS | NUMBER | 请求GET并在内存中找到了对象句柄的次数(锁定命中)。 |
GETHITRATIO | NUMBER | 请求GET的命中率。 |
PINS | NUMBER | 请求pin住该命名中对象的次数。 |
PINHITS | NUMBER | 库对象的所有元数据在内存中被找到的次数(pin命中)。 |
PINHITRATIO | NUMBER | Pin命中率。 |
RELOADS | NUMBER | Pin请求需要从磁盘中载入对象的次数。 |
INVALIDATIONS | NUMBER | 命名空间中的非法对象(由于依赖的对象被修改所导致)数。 |
DLM_LOCK_REQUESTS | NUMBER | GET请求导致的实例锁的数量。 |
DLM_PIN_REQUESTS | NUMBER | PIN请求导致的实例锁的数量. |
DLM_PIN_RELEASES | NUMBER | 请求释放PIN锁的次数。 |
DLM_INVALIDATION_REQUESTS | NUMBER | GET请求非法实例锁的次数。 |
DLM_INVALIDATIONS | NUMBER | 从其他实例那的得到的非法pin数。 |
其中PIN的命中率(或未命中率)是我们系统调优的一个重要依据:
SQL> select sum(pins) "hits",
2 sum(reloads) "misses",
3 sum(pins)/(sum(pins)+sum(reloads)) "Hits Ratio"
4 from v$librarycache;
hits misses Hits Ratio
---------- ---------- ----------
84962803 288 0.99999661
SQL>
SQL> select sum(pins) "hits",
2 sum(reloads) "misses",
3 ((sum(reloads)/sum(pins))*100) "Reload%"
4 from v$librarycache;
hits misses Reload%
---------- ---------- ----------
84963808 288 0.00033896
SQL>
当命中率小于99%或未命中率大于1%时,说明系统中硬解析过多,要做系统优化(增加Shared Pool、使用绑定变量、修改cursor_sharing等措施,性能优化不是本文重点,不再赘述)。
· v$library_cache_memory
这个视图显示了各个命名空间中的库缓存内存对象的内存分配情况。一个内存对象是为了高效管理而组织在一起的一组内部内存。一个库对象可能包含多个内存对象。
字段 | 数据类型 | 说明 |
LC_NAMESPACE | VARCHAR2(15) | Library cache命名空间 |
LC_INUSE_MEMORY_OBJECTS | NUMBER | 属于命名空间并正被在共享池使用的内存对象数。 |
LC_INUSE_MEMORY_SIZE | NUMBER | 正在使用的内存对象的大小总(M未单位)。 |
LC_FREEABLE_MEMORY_OBJECTS | NUMBER | 共享池中空闲的内存对象数。 |
LC_FREEABLE_MEMORY_SIZE | NUMBER | 空闲内存对象的大小总和(M为单位)。 |
· v$sgastat
这个视图前面介绍过,是关于SGA使用情况的统计。其中,关于Shared Pool有详细的统计数据。1.1.5. 重做日志缓存(Redo Log Buffer)
Redo Log Buffer是SGA中一段保存数据库修改信息的缓存。这些信息被存储在重做条目(Redo Entry)中.重做条目中包含了由于INSERT、UPDATE、DELETE、CREATE、ALTER或DROP所做的修改操作而需要对数据库重新组织或重做的必须信息。在必要时,重做条目还可以用于数据库恢复。
重做条目是Oracle数据库进程从用户内存中拷贝到Redo Log Buffer中去的。重做条目在内存中是连续相连的。后台进程LGWR负责将Redo Log Buffer中的信息写入到磁盘上活动的重做日志文件(Redo Log File)或文件组中去的。
参数LOG_BUFFER决定了Redo Log Buffer的大小。它的默认值是512K(一般这个大小都是足够的),最大可以到4G。当系统中存在很多的大事务或者事务数量非常多时,可能会导致日志文件IO增加,降低性能。这时就可以考虑增加LOG_BUFFER。
但是,Redo Log Buffer的实际大小并不是LOB_BUFFER的设定大小。为了保护Redo Log Buffer,oracle为它增加了保护页(一般为11K):
SQL> select * from v$sgastat where name = 'log_buffer';
POOL NAME BYTES
------------ -------------------------- ----------
log_buffer 7139328
1 row selected.
SQL> show parameter log_buffer
NAME TYPE VALUE
------------------------------------ ----------- -------------------
log_buffer integer 7028736
SQL>
1.1.6. 大池(large pool)
大池是SGA中的一块可选内存池,根据需要时配置。在以下情况下需要配置大池:
o 用于共享服务(Shared Server MTS方式中)的会话内存和Oracle分布式事务处理的Oracle XA接口
o 使用并行查询(Parallel Query Option PQO)时
o IO服务进程
o Oracle备份和恢复操作(启用了RMAN时)
通过从大池中分配会话内存给共享服务、Oracle XA或并行查询,oracle可以使用共享池主要来缓存共享SQL,以防止由于共享SQL缓存收缩导致的性能消耗。此外,为Oracle备份和恢复操作、IO服务进程和并行查询分配的内存一般都是几百K,这么大的内存段从大池比从共享池更容易分配得到(所以叫“大”池嘛^_^)。
参数LARGE_POOL_SIZE设置大池的大小。大池是属于SGA的可变区(Variable Area)的,它不属于共享池。对于大池的访问,是受到large memory latch保护的。大池中只有两种内存段:空闲(free)和可空闲(freeable)内存段(关于不同类型内存段我们在后面介绍)。它没有可重建(recreatable)内存段,因此也不用LRU链表来管理(这和其他内存区的管理不同)。大池最大大小为4G。
为了防止大池中产生碎片,隐含参数_LARGE_POOL_MIN_ALLOC设置了大池中内存段的最小大小,默认值是16K(同样,不建议修改隐含参数)。
此外,large pool是没有LRU链表的。
1.1.7. Java池(Java Pool)
Java池也是SGA中的一块可选内存区,它也属于SGA中的可变区。
Java池的内存是用于存储所有会话中特定Java代码和JVM中数据。Java池的使用方式依赖与Oracle服务的运行模式。
Java池的大小由参数JAVA_POOL_SIZE设置。Java Pool最大可到1G。
在Oracle 10g以后,提供了一个新的建议器——Java池建议器——来辅助DBA调整Java池大小。建议器的统计数据可以通过视图V$JAVA_POOL_ADVICE来查询。如何借助建议器调整Java池的方法和使用Buffer Cache建议器类似,可以参考Buffer Cache中关于建议器部分。
1.1.8. 流池(Streams Pool)
流池是Oracle 10g中新增加的。是为了增加对流(流复制是Oracle 9iR2中引入的一个非常吸引人的特性,支持异构数据库之间的复制。10g中得到了完善)的支持。
流池也是可选内存区,属于SGA中的可变区。它的大小可以通过参数STREAMS_POOL_SIZE来指定。如果没有被指定,oracle会在第一次使用流时自动创建。如果设置了SGA_TARGET参数,Oracle会从SGA中分配内存给流池;如果没有指定SGA_TARGET,则从buffer cache中转换一部分内存过来给流池。转换的大小是共享池大小的10%。
Oracle同样为流池提供了一个建议器——流池建议器。建议器的统计数据可以通过视图V$STREAMS_POOL_ADVICE查询。使用方法参看Buffer Cache中关于优化器部分。
转载自:http://www.hellodba.com/reader.php?ID=104&lang=CN