【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列5

Flushing(清空) SHARED POOL

       在使用大量literal SQL的系统中,shared pool随时间推移会产生大量碎片进而导致并发能力的下降。Flushing shared pool能够使得很多小块碎片合并,所以经常能够在一段时间内恢复系统的性能。清空之后可能也会产生短暂的性能下降(补充:因为需要做第一次的硬解析),因为这个操作同时也会把没造成shared
pool碎片的共享SQL也清除了。清空shared pool的命令是:

ALTER SYSTEM FLUSH SHARED_POOL;(补充:不支持SESSION级别的)

注意:如果显式的使用以上命令,即使是用DBMS_SHARED_POOL.KEEP而被保留的那些对象可能也会被释放掉,包括它们占用的内存。如果是隐式的flush(由于shared pool上的内存压力)这个时候“kept"的对象不会被释放。

注意:如果sequence使用了cache选项,冲刷shared pool有可能会使sequence在其范围内产生不连续的记录。

使用DBMS_SHARED_POOL.KEEP('sequence_name','Q')来保持sequence会防止这种不连续的情况发生。

DBMS_SHARED_POOL.PURGE
       也可以不刷新整个shared pool,而只清空其中的单个对象。下面的文档说明了10g和11g中如何清空library cache heap。
Document:751876.1

DBMS_SHARED_POOL.PURGE Is Not Working On 10.2.0.4

使用 V$ 视图 (V$SQL 和 V$SQLAREA)

       注意有一些V$视图需要获取相关的latch来返回查询的数据。用来展示library cache和SQL area的视图就是值得注意的。所以我们建议有选择性的运行那些需要访问这种类型视图的语句。特别需要指出的是,查询V$SQLAREA会在library
cache latch上产生大量的负载,所以一般可以使用对latch访问比较少的v$sql做替代——这是因为V$SQLAREA的输出是基于shared pool中所有语句的GROUP BY操作,而V$SQL没有用GROUP BY操作。

MTS, Shared Server 和 XA

       由于多线程服务器(MTS)的User Global Area (UGA)是存放在shared pool中的,所以会增加shared pool的负载。在Oracle7上的XA session也会产生同样的问题,因为他们的UGA也是在shared pool里面(在Oracle8/8i开始XA session不再把UGA放到shared pool中)。在Oracle8中Large Pool可以被用来减少MTS对shared pool活动的影响——但是,Large Pool中的内存分配仍然会使用"shared
pool latch"。

       使用dedicate connections(专有连接)替代MTS可以使UGA在进程私有内存中分配而不是shared pool。私有内存分配不会使用"shared pool latch",所以在有些情况下从MTS切换到专有连接可以帮助减少竞争。

       在Oracle9i中,MTS被改名为"Shared Server"。但是对于shared pool产生影响的行为从根本上说还是一样的。 

时间: 2024-10-25 22:44:01

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列5的相关文章

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列4

CURSOR_SHARING 参数 (8.1.6 以上)        这个参数需要小心使用.如果它被设为FORCE,那么Oracle会尽可能用系统产生的绑定变量来替换原来SQL中的literals部分.对于很多仅仅是literal不一样的相似的语句,这会让它们共享cursor.这个参数可以在系统级别或者session级别动态设置: ALTER SESSION SET cursor_sharing = FORCE; 或者 ALTER SYSTEM SET cursor_sharing = FOR

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列2

下面来谈一谈系列1中讲到的Literal SQL和Shared SQL的比较. 首先是Literal SQL: 在有完整的统计信息并且SQL语句在predicate(限定条件)中使用具体值时,基于成本的优化器 (CBO)能工作的最好.比较下面 的语句: SELECT distinct cust_ref FROM orders WHERE total_cost < 10000.0; 和 SELECT distinct cust_ref FROM orders WHERE total_cost <

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列3

减轻Shared Pool负载 Parse一次并执行多次        在OLTP类型的应用中,最好的方法是只让一个语句被解析一次,然后保持这个cursor的打开状态,在需要的时候重复执行它.这样做的结果是每个语句只被Parse了一次(不管是soft parse还是hard parse).显然,总会有些语句很少被执行,所以作为一个打开的cursor维护它们是一种浪费.        请注意一个session最多只能使用参数:open_cursors定义的cursor数,保持cursor打开会增加

[转载】&amp;mdash;&amp;mdash;故障排除:Shared Pool优化和Library Cache Latch冲突优化 (文档 ID 1523934.1)

原文链接:https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrlstate=23w4l35u5_4&id=1523934.1用途   提出问题,得到帮助并分享您的心得   排错步骤   什么是shared pool?   专用术语   Literal SQL   Hard Parse(硬解析)   Soft Parse(软解析)   完全相同的语句?   Sharable SQL   语句的版本   Library Cac

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列6

使用SQL 查看Shared Pool问题        这一章节展示了一些可以用来帮助找到shared pool中的潜在问题的SQL语句.这些语句的输出最好spool到一个文件中. 注意:这些语句可能会使latch竞争加剧,我们在上面的"使用 V$ 视图 (V$SQL 和 V$SQLAREA)" above. 查找literal SQL SELECT substr(sql_text,1,40) "SQL",                count(*) ,  

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列1

什么是Shared Pool?        Oracle的实例主要包括共享内存(主要是SGA,还有PGA)和Background Processes,其中SGA中又包括了Shared Pool.Buffer Cache.Redo Log Buffer以及其它一些内存区.        Oracle在SGA的一个特定区域中保留SQL语句.Package是.对象信息以及其它一些内容,这就是Shared Pool.这个共享内存区域是由一个复杂的cache和heap manager 构成的.它需要解决

shared pool latch和library cache latch

shared pool latch和library cache latch    >                                   >                                                                                                                                                                           

【每日一摩斯】-Fundamentals of the Large Pool

以下内容介绍从Oracle 8引入的'Large Pool'. 什么是Large Pool(翻译过来叫"大池")?        大池是SGA中一块类似于shared pool的区域,但是它的使用又有严格的限制,仅有几种类型和大小的内存能够在这个池中分配.        大池的内存不是来自于shared pool,而是直接来自于SGA,因此需要在实例启动时增加共享内存的容量.        大池的大小由LARGE_POOL_SIZE参数决定,可以分配的最小内存chunk由LARGE_P

【每日一摩斯】-RAC and Sequences (853652.1)

序列有四种组合: a. CACHE + NOORDER b. CACHE + ORDER c. NOCACHE + NOORDER d. NOCACHE + ORDER 即使在单例配置下,当有大量的sequence需要产生的时候,性能压力和存储sequence值的行锁定代价相关. NOCACHE与CACHE的性能       当使用cache时,dictionary cache(row cache)仅仅当出现新的水位线时才会更新一次.例如当cache是20,nextval第一次请求时,dicti