oracle执行慢的sql
由于经常执行sql语句，如果一条一条执行效率低下。
oarclecmd.commandtext
=
sqlstr;
oraclecmd.executenonquery();
sqlstr
可以写成如下所示语句
begin
sql1;
sql2;
......
sqln;
end;
//注意此处的分号很重要
然后同样调用executenonquery()方法，可以一次执行多条sql语句。
2. 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;
3. oracle 一句sql 执行速度特别慢，请指导如何改写，谢谢
selectf.channel_name,c.name,c.rule_detail,count(1)monthly,rank()over(orderbycount(1)desc)rank
fromcljy.sys_cljyc,channel_paylog_dayfwhereSUBSTR(f.recv_time,1,6)=
to_char(sysdate,'yyyymm')andc.namelike'%经典%'and
exists(selectcount(1)fromcljy.sys_pay_prize_targetj,nt_staff_channelgwherej.device_number=f.serial_numberandg.depart_id=f.recv_depart_id)--andrownum<2
groupbyf.channel_name,c.name,c.rule_detail
先把andrownum<2注释去掉能执行成功的话就没错，老感觉这个语句死循环了。。。测完再回复我，给你看
4. oracle 如何确定procere中慢的sql
在存储过程中写日志表，每个sql 执行前后都写入开始执行时间和执行结束时间。
执行完过程，你看下日志表就知道了
5. 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优化团队成员帮您搞定!
6. oracle如何定位效率较低的sql
oracle中看效率低的sql，其实是没有的；
只有看资源消耗高的sql，因为即使这个sql语句效率低，但是运行次数过少，或总体消耗并不算大，还是对系统没有多大妨碍的。
通过awr的各种排序（cpu，elapsed time，buffer），找出高消耗的sql语句，再通过awrsqrpt进行分析，到底问题出在什么地方
7. oracle 这条sql语句速度慢的原因
看下执行计划走索引没有，如果没走索引看看索引是不是失效了
从语句看，只要tb_id上有索引并且可用，应该就没问题
如果都正常，索引也在执行计划中使用了，就需要考虑将全局索引改成分区索引，确实数据量大的，可以考虑数据表建子分区
另外看下CPU使用率、内存使用情况、IO争用情况，还有存储是不是有告警
8. oracle 怎样查看哪些sql语句执行慢
登录OEM，点击”性能“，往下拉，看到一个叫”SQL监视“的栏目，点击进去就可以了
9. 执行一下Oracle SQL时，慢如蜗牛，如何优化
至少可以改成这个样子：
--------------------------------------------------------
select b.reach_item_no as 小区编号,
c.reach_item_name as 小区名称,
substr(b.floor_no, 1, 2) as 楼栋,
count(1) as 应抄数,
sum(decode(d.mp_item_no, null, 0, 1)) as 实抄数,
to_char(round((sum(decode(d.mp_item_no, null, 0, 1)) / count(1)) * 100)) as 抄收率,
'20090701' as 抄收日期
from meter_running a,
customer_files b,
reach_item_location c,
raw_day_e d
where a.customer_no = b.customer_no
and b.reach_item_no = c.reach_item_no
and d.mp_item_no(+) = a.mp_item_no
and d.data_dt(+) = '20090701'
group by substr(b.floor_no, 1, 2), b.reach_item_no, c.reach_item_name,
order by 1, 3
--------------------------------------------------------
如果执行还慢，那么就要看索引是否建了，统计信息是否收集，分配的pga是否够大。这种关联使用hash join应该效率更高，如果分配的pga太小，走nl，估计会比较慢。