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，估計會比較慢。