对Oracle软软解析的一点看法

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
简介: 本文将介绍Oracle解析器的一种较为特殊的解析行为,软软解析。


杂谈

 在接触过oracle优化器的特征之后,我们都知道oracle优化器的一个迷人之处,就在于shared pool的设计,说准确点是shared pool中的Library Cache,这种设计的结果就是让执行计划变得可缓存。因此产生了软解析的概念,这就保证了相同SQL在统计信息不发生变化的前提下只用经历一次繁杂的解析过程。而相对比软解析,oracle优化器还有一种更为特殊的行为,即软软解析,发生软软解析过程的SQL将消耗更小的开销,执行更加迅速。

Cursor

 首先了解下oracle中的两种sql cursor,Shared Cursor 和 Session Cursor。
1.Shared cursor。缓存于SGA的shared pool,Oracle的Shared Cursor分为Parent Cursor(父游标)和Child Cursor(子游标),父游标存储SQL的文本,子游标则存储sql的执行计划。
2.Session Cursor。缓存于PGA的private sql区,在执行SQL时创建,一般SQL执行完毕释放。Session cursor和shared cursor的区别就在于,session cursor是session私有的,这其实也是PGA与SGA的区别。

PGA

接下来聊下PGA的组成。
1.PGA=UGA + CGA
2.CGA。即call global area,包含排序区+散列区+位图合并区
3.UGA=user session + cursor state(private sql区)

user session(会话信息区)
 存放用户权限,角色,性能统计等信息。

private sql
 固定部分:绑定信息,数据结构信息,指针。随session的创建而创建,结束而释放
 动态部分:执行sql的中间结果集,如多表联查,排序。随sql的创建而创建,结束而释放

 那么前面说的session cursor对应UGA中private sql区的动态部分,当执行SQL语句的时候创建,主要用于作为SQL中间结果集的缓存区域,但是当一个SQL在同一个会话中连续执行三次以上时,这个cursor会被缓存,当相同SQL再次执行时,直接使用这个打开的游标。

软软解析的意义

首先看下SQL解析的过程,大致可以概括如下。
1.语法、语义及权限检查;
2.查询转换(语句等价转换,又称为逻辑优化);
3.执行递归查询获取统计信息;
4.根据统计信息计算每条执行路径的执行开销
5.选择开销最小的执行路径作为执行计划

 在整个解析过程中,步骤3和4是最其本身的性能开销所在,而软解析正是为了节省这两个步骤而设计的(实际上也省去了步骤2)。
 那么软软解析呢?正如前面所说,当session cursor被缓存时,下一次在同一会话执行同一个SQL的时候就可以直接使用这个打开的游标,这个过程就是软软解析。软软解析相对比软解析,甚至还省去了步骤1和2,并且还减少了打开游标的开销。
 直接使用这个还未关闭的游标,意味着提交这个SQL请求之后,接下来就可以直接去获取执行计划执行该SQL了,而软解析在命中执行计划之前还需要经历SQL hash查找的过程。

可以查询相关视图查看某会话中发生软软解析的情况,如下
rrjx

session cursor cache count
 这个数值指的是当前会话缓存的的这种sql cursor的总数量
 可通过参数设置单个会话最大可缓存cursor的总数量
rrjx2

session cursor cache hits
 在session cursor cache找到的次数。在session中每发生一次软软解析,就代表session cursor cache的一次命中。

结语

 同样是为了节省解析带来的性能开销,软软解析实质上是软解析的一个特例。
 而无论是哪种解析过程,ORACLE在解析和执行目标SQL时,始终会按照如下逻辑生成执行计划。
1.查找PGA的private sql area,若命中,发生软软解析,若不命中进行步骤2;
2.在Library Cache中匹配该SQL的hash值,若命中发生软解析,否则进入步骤3;
3.发生硬解析,将会执行递归查询获取统计信息,并且用来计算执行开销,然后生成执行计划,并将执行计划缓存在Library Cache中。

目录
相关文章
|
SQL Oracle 关系型数据库
问题出在Debezium Oracle Connector的日志解析器上
问题出在Debezium Oracle Connector的日志解析器上
135 2
|
1月前
|
负载均衡 Oracle 网络协议
Oracle中TAF与SCANIP全面解析
通过本文的解析,读者可以清晰地理解Oracle中TAF与SCAN IP的概念、工作原理及其在实际应用中的优势和局限性。TAF通过自动故障转移提升了会话的高可用性,而SCAN则通过简化客户端连接和负载均衡提升了集群的可管理性和扩展性。这两种技术在现代企业数据库架构中扮演着重要角色,能够显著提高系统的稳定性和可用性。
59 6
|
4月前
|
监控 Oracle 关系型数据库
"深度剖析:Oracle SGA大小调整策略——从组件解析到动态优化,打造高效数据库性能"
【8月更文挑战第9天】在Oracle数据库性能优化中,系统全局区(SGA)的大小调整至关重要。SGA作为一组共享内存区域,直接影响数据库处理能力和响应速度。本文通过问答形式介绍SGA调整策略:包括SGA的组成(如数据缓冲区、共享池等),如何根据负载与物理内存确定初始大小,手动调整SGA的方法(如使用`ALTER SYSTEM`命令),以及利用自动内存管理(AMM)特性实现智能调整。调整过程中需注意监控与测试,确保稳定性和性能。
376 2
|
6月前
|
SQL DataWorks Oracle
DataWorks产品使用合集之datax解析oracle增量log日志该如何操作
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
66 0
|
7月前
|
缓存 Oracle 关系型数据库
oracle 软软解析
oracle 软软解析
45 0
|
2月前
|
存储 Oracle 关系型数据库
Oracle数据库的应用场景有哪些?
【10月更文挑战第15天】Oracle数据库的应用场景有哪些?
193 64
|
13天前
|
存储 Oracle 关系型数据库
数据库数据恢复—ORACLE常见故障的数据恢复方案
Oracle数据库常见故障表现: 1、ORACLE数据库无法启动或无法正常工作。 2、ORACLE ASM存储破坏。 3、ORACLE数据文件丢失。 4、ORACLE数据文件部分损坏。 5、ORACLE DUMP文件损坏。
52 11
|
26天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
1月前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
19天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。

推荐镜像

更多