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進行分析，到底問題出在什麼地方