oracle cursor和绑定变量

Oracle SQL执行与游标管理
本文详细介绍了Oracle数据库中SQL执行的过程,包括SHAREDCURSOR与SESSIONCURSOR的工作原理,解析执行SQL的具体步骤,以及如何通过绑定变量优化SQL执行效率。此外,还探讨了游标共享的不同类型及其在性能调优中的作用。


1、SHARED CURSOR (位于SGA)
     PARENT CURSOR 只对应SQL文本(V$SQLAREA 不同SCHEMA下相同的SQL ,PARENT CURSOR也相同)
     CHILD CURSOR 对应 VERSION COUNT (V$SQL)
     硬解析:至少需要生成 CHILD CURSOR 占用SHARED POOL LATCH LIBRARY CACHE LATCH  OLTP中的万恶之源(尽可能20/S以下) 


2、SESSION CURSOR (位于PGA)
     session_cached_cursors   软软解析


3、解析执行SQL过程:
  PGA - SESSION CURSOR -N- PARENT CURSOR -Y- SESSION CURSOR CHILD CURSOR
                                                                                             -N- SESSION CURSOR SHARED CURSOR (PARENT CHILD)


                                                  -Y- 直接访问 PARENT CURSOR


4、SESSION CURSOR种类:隐式 显式 参考


5、绑定变量 
  OLTP减少硬解析 批量绑定
  可以给表添加COMMENT也是DDL操作,重新硬解析 影响微乎其微
  DBMS_SHARED_POOL.PURGE 可以删除SHARED CURSOR 强制SQL重新硬解析
  绑定变量分级 内存分配 32字节 128字节 2000字节 2000以上(参数长度大于2000按实际分配,小于2000按2000分配)分配变化 计划改变
  绑定变量捕获(只捕获where子句中的) 硬解析每次记录,软解析默认15分钟记录一次 V$SQL_BIND_CAPTURE DBA_HIST_SQL_STAT DBA_HIST_SQLBIND 


6、游标共享
  常规游标共享
  自适用游标共享 (不安全的谓词条件 范围查询 有直方图统计信息的等值查询) 变量数不超过14个才能生效
    V$SQL_CS_STATISTICS V$SQL_CS_SELECTIVITY
    自适用执行流程:
      第一次硬解析SQL,标记CHILD CURSOR 为 BIND SENSITIVE,存储runtime信息 
      第二次执行 软解析 重用CHILD CURSOR的解析树和执行计划
      第三次执行 如果BIND SENSITIVE,并且第二次和第三次执行时的runtime统计信息和第一次统计信息有较大差异时,则第三次重新硬解析,产生新CHILD CURSOR,并标记此CHILD CURSOR为 BIND AWARE
      标记为BIND AWARE的CHILD CURSOR对应的SQL再次执行时根据绑定变量的谓词选择率确定 硬/软/软软解析
          可选择率处于之前硬解析在V$SQL_CS_STATISTICS中记录的范围内则用软/软软解析
          如果硬解析并且产生计划与原有CHILD CURSOR中的计划相同,则除了新生成一个CHILD CURSOR外还会把原相同计划的CHILD CURSOR标记为非共享,并进行CURSOR合并(扩展相同执行计划的选择率V$SQL_CS_SELECTIVITY)


7、SESSION CURSOR生命周期:OPEN PARSE DESCRIBE DEFINE BIND PARALLELIZE EXECUTE FETCH CLOSE


8、应用类型:硬解析 软解析 软软解析 一次解析多次执行(软软解析改进版)
Oracle 数据库中,虽然绑定变量的使用对于性能优化资源管理具有显著优势,但过度使用绑定变量也可能带来一些潜在的问题负面影响。 ### 1. 绑定变量过多可能导致执行计划稳定 当 SQL 语句使用绑定变量时,优化器会基于绑定变量的值生成执行计划。如果绑定变量的值分布差异较大,可能会导致执行计划的稳定性。例如,某些值可能适合使用索引扫描,而另一些值则更适合全表扫描。这种情况下,优化器可能无法为所有绑定变量值生成最优的执行计划,从而影响查询性能。 ### 2. 绑定变量窥视(Bind Peeking)问题 Oracle 在首次解析 SQL 语句时会查看绑定变量的值,并基于这些值生成执行计划。然而,如果后续执行中绑定变量的值发生显著变化,该执行计划可能再适用。这种现象被称为“绑定变量窥视”,可能导致性能下降,特别是在数据分布均匀的情况下。 ### 3. 增加 SQL 调优复杂性 当使用大量绑定变量时,SQL 调优变得更加复杂。由于绑定变量的值在 SQL 执行时才确定,因此难以通过静态分析来预测执行计划。这可能导致调优工具无法准确评估 SQL 性能瓶颈,从而增加调优的难度。 ### 4. 共享池资源竞争 虽然绑定变量有助于减少硬解析,但过多的绑定变量可能导致共享池中 SQL 语句的共享性降低。当多个会话使用同的绑定变量值执行相同的 SQL 时,可能会导致共享池中的执行计划碎片化,增加共享池的管理开销。 ### 5. 绑定变量未正确使用导致性能问题 在某些情况下,开发人员可能错误地使用绑定变量,例如将绑定变量用于本应使用字面量的条件(如分区键)。这可能导致优化器无法正确识别分区键的值,从而无法利用分区裁剪功能,影响查询性能。 ### 6. 绑定变量过多影响可读性维护 在 SQL 语句中使用过多的绑定变量可能会影响 SQL 的可读性维护性。过多的绑定变量使得 SQL 语句难以理解调试,尤其是在复杂的查询中。 ### 7. 绑定变量CURSOR_SHARING 的交互问题 当 CURSOR_SHARING 参数设置为 FORCE 或 SIMILAR 时,Oracle 会自动将 SQL 语句中的字面量替换为绑定变量。然而,这种自动替换可能导致执行计划的变化,进而影响性能。此外,在某些情况下,CURSOR_SHARING 可能无法正确识别某些 SQL 语句的相似性,导致执行计划的一致性。 ### 示例代码:查看绑定变量的使用情况 可以通过查询 `V$SQL` 视图来查看 SQL 语句中绑定变量的使用情况: ```sql SELECT sql_id, sql_text, executions, elapsed_time, force_matching_signature FROM v$sql WHERE force_matching_signature != 0; ``` 该查询可以识别出那些通过绑定变量CURSOR_SHARING 机制共享执行计划的 SQL 语句。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值