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

减轻Shared Pool负载

Parse一次并执行多次
       在OLTP类型的应用中,最好的方法是只让一个语句被解析一次,然后保持这个cursor的打开状态,在需要的时候重复执行它。这样做的结果是每个语句只被Parse了一次(不管是soft parse还是hard parse)。显然,总会有些语句很少被执行,所以作为一个打开的cursor维护它们是一种浪费。
       请注意一个session最多只能使用参数:open_cursors定义的cursor数,保持cursor打开会增加总体open cursors的数量。
       OCI中开发者能直接控制cursor,在预编译器中,HOLD_CURSOR参数控制cursor是否被保持打开。 

消除 Literal SQL
       如果你有一个现有的应用程序,你可能没法消除所有的literal SQL,但是你还是得设法消除其中一部分会产生问题的语句。从V$SQLAREA视图可能找到适合转为使用绑定变量的语句。下面的查询列出SGA中有大量相似语句的SQL:
SELECT substr(sql_text,1,40) "SQL", 
               count(*) , 
               sum(executions) "TotExecs"
FROM v$sqlarea
WHERE executions < 5
GROUP BY substr(sql_text,1,40)
HAVING count(*) > 30
ORDER BY 2
;

在10g以上的版本可以用下面的语句:

SET pages 10000
SET linesize 250
column FORCE_MATCHING_SIGNATURE format 99999999999999999999999
WITH c AS
(SELECT FORCE_MATCHING_SIGNATURE,
COUNT(*) cnt
FROM v$sqlarea
WHERE FORCE_MATCHING_SIGNATURE!=0
GROUP BY FORCE_MATCHING_SIGNATURE
HAVING COUNT(*) > 20
)
,
sq AS
(SELECT sql_text ,
FORCE_MATCHING_SIGNATURE,
row_number() over (partition BY FORCE_MATCHING_SIGNATURE ORDER BY sql_id DESC) p
FROM v$sqlarea s
WHERE FORCE_MATCHING_SIGNATURE IN
(SELECT FORCE_MATCHING_SIGNATURE
FROM c
)
)
SELECT sq.sql_text ,
sq.FORCE_MATCHING_SIGNATURE,
c.cnt "unshared count"
FROM c,
sq
WHERE sq.FORCE_MATCHING_SIGNATURE=c.FORCE_MATCHING_SIGNATURE
AND sq.p =1
ORDER BY c.cnt DESC;

注意:如果系统中有library cache latch争用的问题,上面的语句会导致争用加剧。

避免Invalidations

       有些命令会将cursor的状态变成成INVALIDATE。这些命令直接修改cursor相关对象的上下文环境。它包括TRUNCATE, 表或索引上的ANALYZE或DBMS_STATS.GATHER_XXX,关联对象的权限变更。相对应的cursor会留在SQLAREA中,但是下次被引用时会被完全reload并重新parse,所以会对数据库的整体性能造成影响。

下面的查询可以帮我们找到Invalidation较多的cursor:

SELECT SUBSTR(sql_text, 1, 40) "SQL",
invalidations
FROM v$sqlarea
ORDER BY invalidations DESC;

时间: 2024-10-25 13:38:41

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

【每日一摩斯】-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)-系列5

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

[转载】&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