Oracle服务器的Execute to Parse

本文涉及的产品
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: 有台Oracle数据库服务器,发现内存占用得比较厉害,生成awr报告,发现有个指标有点异常Instance Efficiency Percentages (Target 100%)Buffer Nowait %:100.

有台Oracle数据库服务器,发现内存占用得比较厉害,生成awr报告,发现有个指标有点异常

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 100.04 In-memory Sort %: 100.00
Library Hit %: 98.33 Soft Parse %: 98.96
Execute to Parse %: -13.40 Latch Hit %: 99.95
Parse CPU to Parse Elapsd %: 98.77 % Non-Parse CPU: 72.78

里面的Execute to Parse 居然出现负数。找到某大师给出的该参数计算公式如下:

Execute to Parse  =  round(100*(1-:prse/:exe),2)                    
 
prse = select value from v$sysstat where name = 'parse count (total)';
exe = select value from v$sysstat where name = 'execute count';

也就是说,这个参数的值,主要是体现 SQL的 解析次数与执行次数的比率。而且这里的解析包括硬解析和软解析、软软解析。

SQL的执行包括几个步骤:打开、解析、绑定、执行、抓取、关闭。

解析的时候确定执行计划,硬解析就是重新生成执行,软解析是在共享池中找到了执行计划,软软解析是让查找执行计划的过程更短、更快。但无论软解析、还是软软解析,都有解析这个操作。

要改善解析与执行的比率关系,就需要增加无解析的次数,无解析就是不再解析,为SQL绑定不同的变量,然后执行。这样做的前提就是:1、Session不能断开;2、Session执行过解析过的SQL不要关闭;满足这两点就可以实现无解析。

下面,就介绍一个和这个有密切关系的参数:session_cached_cursors

session_cached_cursors,就是说的是一个session可以缓存多少个cursor,让后续相同的SQL语句不再打开游标,从而避免软解析的过程来提高性能。(绑定变量是解决硬解析的问题),软解析同硬解析一样,比较消耗资源.所以这个参数非常重要。

oracle有一个概念,那就是session cursor cache,中文描述就是有一块内存区域,用来存储关闭了的cursor。当一个cursor关闭之后,oracle会检查这个cursor的request次数是否超过3次,如果超过了三次,就会放入session cursor cache,这样在下次parse的时候,就可以从session cursor cache中找到这个statement, session cursor cache的管理也是使用LRU。

session_cached_cursors这个参数是控制session cursor cache的大小的。session_cached_cursors定义了session cursor cache中存储的cursor的个数。这个值越大,则会消耗的内存越多。

另外检查这个参数是否设置的合理,可以从两个statistic来检查。
select name,value from v$sysstat where name like '%cursor%';
select name,value from v$sysstat where name like '%parse%';
session cursor cache hits 和parse count(total) 就是总的parse次数中,在session cursor cache中找到的次数,所占比例越高,性能越好。如果比例比较低,并且有剩余内存的话,可以考虑加大该参数。

到这里,我们就明白了,基于上面的情况,我们应该调整哪个参数,才能真正解决问题。

alter system set session_cached_cursors=100 scope=spfile;

修改后要重启数据库方能生效。

目录
相关文章
|
17天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
1月前
|
存储 Oracle 关系型数据库
oracle服务器存储过程中调用http
通过配置权限、创建和调用存储过程,您可以在Oracle数据库中使用UTL_HTTP包发起HTTP请求。这使得Oracle存储过程可以与外部HTTP服务进行交互,从而实现更复杂的数据处理和集成。在实际应用中,根据具体需求调整请求类型和错误处理逻辑,以确保系统的稳定性和可靠性。
63 0
|
3月前
|
存储 Oracle 关系型数据库
Oracle同一台服务器创建多个数据库
【8月更文挑战第30天】在 Oracle 中,可在同一服务器上创建多个数据库。首先确保已安装 Oracle 软件并具有足够资源,然后使用 DBCA 工具按步骤创建,包括选择模板、配置存储及字符集等。重复此过程可创建多个数据库,需确保名称、SID 和存储位置唯一。创建后,可通过 Oracle Enterprise Manager 进行管理,注意服务器资源分配与规划。
175 10
|
7月前
|
Oracle Java 关系型数据库
【服务器】python通过JDBC连接到位于Linux远程服务器上的Oracle数据库
【服务器】python通过JDBC连接到位于Linux远程服务器上的Oracle数据库
101 6
|
7月前
|
运维 Oracle 关系型数据库
Oracle服务器参数文件:数据王国的“调控大师”
【4月更文挑战第19天】Oracle服务器参数文件,数据库的“调控大师”,掌控着内存管理、进程调度等关键设置。通过参数调整如SGA_MAX_SIZE和PROCESSES,实现性能优化和故障防控。虽然挑战重重,但成功的性能调优带来无尽成就感。它在备份恢复中也扮演重要角色,保障数据一致性与可用性。成为真正的“调控大师”,为数据王国效力!
|
2月前
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
192 64
|
12天前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
48 11
|
25天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
1月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
1月前
|
SQL Oracle 关系型数据库
Oracle数据库优化方法
【10月更文挑战第25天】Oracle数据库优化方法
49 7

推荐镜像

更多
下一篇
DataWorks