还不算晕的专栏

因此建议改写SQL，使用绑定变量。对TOP SQL的SQL文本进行分析，这些SQL的文本事实上一致，因未使用绑定变量，只在一些WHERE条件中不同；对TOP SQL的SQL文本进行分析，这些SQL的文本基本一致，只在一些WHERE条件中不同；当前的应急解决方案是针对出现问题的SQL，进行相应的索引创建，从而降低逻辑读(逻辑读会消耗CPU资源)，提高SQL执行效率，缓解当前CPU使用率高的问题。对TOP SQL的SQL文本进行分析，这些SQL的文本事实上一致，因未使用绑定变量，只在一些WHERE条件中不同；

默认情况下创建的表ITL槽数最小为1,pctfree为10，那么如果是这样一种情况，如果表中经常执行update语句，然后块中剩余的10%空间所剩无几，而且业务的并发量还很大，此时就很容易遇到enq: TX - allocate ITL entry等待。每当一个事务需要修改一个数据块时，需要在数据块头部获得一个可用的ITL槽，其中记录了当前事务的id，使用的undo数据块，还有对应的scn，事务是否提交等信息。此处遇到的问题即是ITL上发生的死锁，SQL同时对一个块进行操作时，对I。

某系统的业务表重建后，次日用户反映业务系统缓慢，检查性能数据，发现业务SQL的执行效率下降，深入分析发现是timestamp数据列，未使用到列上的索引；通过对执行计划的分析，可以发现是发生了隐式转换；即使用idtime > systimestamp;时，实际执行的是filter(SYS_EXTRACT_UTC(INTERNAL_FUNCTION("CREATION_DATE"))>TIMESTAMP' 2022-03-14 00:17:35.520486000')；MOS文档上Index o

在之前的一篇BLOG：oracle 12c pdb架构下绑定执行计划问题https://blog.youkuaiyun.com/haibusuanyun/article/details/113343486中提到，PDB环境下绑定执行计划和删除绑定的执行计划，均需要切换到相应的PDB下进行。下面就来看一次实际的PDB环境使用coe_xfr_sql_profile.sql脚本进行绑定执行计划的实战。1.找出问题SQL找出问题SQL，可以说是最关键的一步，方便有很多，可能是通过操作系统 层面top进程OS PID来找

2021/1/27日上午，某客户反映业务系统反映卡顿，通过查询操作系统性能，未有明显异常。通过v$session中查看active状态的会话以及对应等待事件及blocking session，可以发现数据库中存在大量的热块等等，在Oracle数据库的早期版本，热块等待的典型等待事件是buffer busy wait,后来又有了新的等待事件read by other session以及集群等待事件gc buffer busy等，关于read by other session？参考文档：文档 ID 732891

客户发来一个比较长的SQL，说是跑了几小时还没出结果；这是制造业的一个统计型SQL，发来SQL文本一看SQL比较长要翻好几屏，一时半会也梳理不清；按照DBA的思路先尝试查看执行计划，看是否能通过索引或执行计划的改变在不修改SQL(也就不需要了解SQL业务逻辑)情况下优化；从执行计划来看cost 13676,具体的执行步骤在INDEX SKIP SCAN部分消耗比较大；关于索引跳跃扫描inde...

近期比较有空闲时间，记录下之前的一个DRM导致insert插入语句执行时间波动的案例。 某用户反映OLTP系统某业务正常只需要ms级可以完成，偶尔出现需要5-10s左右才能完成，导致后续关联业务执行错误的情况，近期此问题出现频率每天有几次，需要介入调查出现此问题的原因。通过与客户沟通了解到此业务只是简单的插入数据的SQL语句，此业务模块有日志记录完成所需时间，客户通过后续业务模块报错信息...

近期遇到一套windowsX64+Oracle11.2.0.1版本数据库，遇到一条使用了6个绑定变量值的插入sql出现了5000多个sql version,正常情况下此sql在早上8-9点要执行300-500次左右，当应用程序反应慢时，查看此sql version达到5000多；用户前一段时间在应用反应慢时，即通过重启数据库来解决此问题(用户并没有查找原因，单纯的用重启大法来试一次的)，只是近期此...

1. cursor概念介绍cursor游标,是ORACLE数据库中SQL解析和执行的载体，本质上是C语言中的一种结构structure. ORACLE数据库中cursor分类：shared cursor包括：parent cursor、child cursor session cursor包括： 隐式游标implicit cursor、 显式游标explicit cursor、 参考...

SQL Profile就是为某一SQL语句提供除了系统统计信息、对象（表和索引等）统计信息之外的其他信息，比如运行环境、额外的更准确的统计信息，以帮助优化器为SQL语句选择更适合的执行计划。SQL Profiles可以说是Outlines的进化。Outlines能够实现的功能SQL Profiles也完全能够实现，而SQL Profiles具有Outlines不具备的优化，最重要的有二点：

1 SQL ordered by Elapsed Time记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)。Elapsed Time(S): SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和

virtual circuit wait查询 V$SHARED_SERVER SELECT * FROM v$shared_server WHERE circuit 查询 V$CIRCUIT 视图中的状态SELECT waiter, status FROM V$CIRCUIT WHERE waiter 检查等待的Session 正在处理的SQL：SELECT

如果要分析某条SQL的性能问题，通常我们要先看SQL的执行计划，看看SQL的每一步执行是否存在问题。 如果一条SQL平时执行的好好的，却有一天突然性能很差，如果排除了系统资源和阻塞的原因，那么基本可以断定是执行计划出了问题。              看懂执行计划也就成了SQL优化的先决条件。 这里的SQL优化指的是SQL性能问题的定位，定位后就可以解决问题。  一．