oracle查询慢的sql
‘壹’ oracle sql 用什么可以替代or，这样查询特别慢
可以用union，比如select 内容 from user where name='张三' union select 内容 from user where name='李四'，相当于select 内容 from user where name='张三' or name='李四' ，因为union会用到索引，不知道你这个表有没有索引，表的数据多大？
‘贰’ ORACLE 如何查看执行时间较长 较慢的语句
运行慢的sql：
select*
from(selectsa.SQL_TEXT,
sa.SQL_FULLTEXT,
sa.EXECUTIONS"执行次数",
round(sa.ELAPSED_TIME/1000000,2)"总执行时间",
round(sa.ELAPSED_TIME/1000000/sa.EXECUTIONS,2)"平均执行时间",
sa.COMMAND_TYPE,
sa.PARSING_USER_ID"用户ID",
u.username"用户名",
sa.HASH_VALUE
fromv$sqlareasa
leftjoinall_usersu
onsa.PARSING_USER_ID=u.user_id
wheresa.EXECUTIONS>0
orderby(sa.ELAPSED_TIME/sa.EXECUTIONS)desc)
whererownum<=50;
‘叁’ oracle数据库执行sql很慢怎么回事
一条sql突然执行变慢，耗时9秒，应用是不能改的，只能从数据库方面下手解决
步骤思路：
1：查看sql是否走索引
2：查看索引是否失效
3：hint 强制走索引（只是用来查看hint状态下，查询是否更改，应用是不能改的）
4：收集该表所有信息（包括索引）
5：分析该表所有信息（包括索引）
6：再次执行并查看
注意：哪个用户执行较慢，就用哪个用户进行操作，这样才准确
‘肆’ oracle数据库运行sql很卡很慢很顿，看等待事件都是cursor:pin s on x,这是啥
详解cursor: pin S wait on X等待事件
‘cursor: pin * events’等待事件
该类等待事件一般是为了pin相关的子游标
‘Cursor: pin S on X’ 最常见的等待事件， 进程为了共享操作例如执行pin游标而以SHRD S mode申请mutex， 但是未立即获得。原因是该游标被其他进程以EXCL X mode 持有了。
实际该 cursor: pin S wait on X等待事件往往是由于其他因素诱发的。Mutex争用仅仅是问题的症状，但根本原因需要Database Consultant 进一步挖掘。
下面我们列出一些已知的常见案例， 在这些例子中可以看到 我上面提到的 Mutex的争用仅仅是伪争用:
过多的子游标 High Version Counts
过多的子游标版本Version Count可能导致Mutex 争用，一般一个SQL的Version Count不要高于500。
检查High Version Count很简单， 在AWR里就有SQL ordered by High Version Count，也可以写SQL查V$SQL、V$SQLAREA
昂贵的X$、V$视图查询
一些对于V$、X$视图的查询，需要访问X$KGL*之类的fixed table，可能触发Mutex争用。
Mutex持有者得不到CPU
Mutex持有者若得不到足够的CPU片可能一直阻塞他人，直到它拿到需要的CPU。
这种情况可能由于OS操作系统的实际情况或者使用Resource Manager而引起。需要配合AWR中的Host CPU、Instance CPu一起看。
已经被KILLED的SESSION仍持有Mutex
当session正持有Mutex，而其对应的Process被强制KILL掉， 则直到PMON彻底清理掉该Dead Process并释放Mutex，其他session才能不再等待。 诊断该类问题，最好能检查PMON的TRACE。 当然也存在部分BUG会导致PMON清理过程非常慢。
举例来说，bug 9312879描述了一种场景：PMON 需要获得某个Mutex以便清理某个dead process，但是该Mutex又被其他进程持有，则PMON甚至无法开始真正清理并释放Mutex。
如果自己搞不定可以找ASKMACLEAN专业ORACLE优化团队成员帮您搞定!
‘伍’ oracle如何定位效率较低的sql
oracle中看效率低的sql，其实是没有的；
只有看资源消耗高的sql，因为即使这个sql语句效率低，但是运行次数过少，或总体消耗并不算大，还是对系统没有多大妨碍的。
通过awr的各种排序（cpu，elapsed time，buffer），找出高消耗的sql语句，再通过awrsqrpt进行分析，到底问题出在什么地方