㈠ 怎麼查找oracle比較慢的session和sql
可以查則喊看v$session_longops視圖來查看當前運行較慢的session。
最好還是生成awr來查看時間段卜盯答內的數型慧據庫運行情況。
㈡ oracle資料庫系統視圖查詢慢
PB連接資料庫右鍵打開一張表的時候要刷新挺多數據的，需要讀取一些系統表，獲取對象數據結構信息，並且生成一個數據窗口展現數據。這個過程消耗時間。
檢查一下如下幾個情況：
1、使用的Oracle驅動是否版本匹配，例如：你使用Oracle8的驅動連接Oracle10的資料庫，從訪問的優化性來將，是有差別的，可能會影響效率；
2、把視圖在PL/SQL工具中進行執行計劃的查詢，檢查其性能是否有問題，例如：索引使用不當等情況；
3、程序編譯之後執行一下看看，性能是否依舊較低？開發模式下，編譯器沒有針對性的優化，可能影響到效率。
從開發階段就開始關注效率，這個是很好的習慣。希望我的回答能對你有幫助。
㈢ oracle 中sql執行超慢幾乎查詢不出來
套這么多層，而羨歷且用到DB LINK表那當然慢了
如果只執行一次最好把DB LINK的表創建一沖槐個中間表過來
再把這幾個中間表聯查速度兄判搜會快多了
㈣ 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的時候，都會比較慢一些，再次執行的時候，由於數據等還在內存內，會速度快很多。
再者，在Oracle中，有共享SQL語句的機制，在第一次解析之後, ORACLE將SQL語句存放在內存中.這塊位於系統全局區域SGA(system global area)的共享池(shared buffer pool)中的內存可以被所有的資料庫用戶共享. 因此,當你執行一個SQL語句(有時被稱為一個游標)時,如果它 和之前的執行過的語句完全相同, ORACLE就能很快獲得已經被解析的語句以及最好的執行路徑. 這樣也會大大的提高效率。
㈥ oracle 查詢的sql語句特別慢，是什麼原因，是or特別慢嗎，用什麼優化，急急急！！！
把查詢計劃的內容發出來，你這一大堆代碼誰能看出來啥啊。看你的代碼這么長，條件那麼多，語句用了函數，很多低效的or,not in等操作，另外還用了group by，order by，左右連接等等，如果表數據量很大的話，你這個語句性能不好是預料中的事情。如果你這條語句無法優化，建議從調整表結構角度考慮
㈦ oracle sql 查詢我使用自已寫的函數查詢很快，加了函數做條件就很慢是為什麼
慢是因為
對於 幾十萬條記錄左右,
你那個 test(a) 函數, 需要執行 很多次， 每行執行一次， 然後判斷 LIKE '%123%'
至於：
select a,b, test(a) c from demo; --只這樣查很快
我估計你使用的是 PLSQL Developer。
查詢的時候， 默認是查詢第一頁， 因此很快。
因為只顯示少部分行。
例如一頁20行的話， 那麼也就執行你那個函數 20次。
㈧ oracleSQL執行緩慢的分析
問題描述
oracle資料庫中一張表的數據已經 億多 而且此表創建了 個獨立的索引 由於業務需要 每天需分兩次向此表中插入 萬條記錄 由於數據量大 每次插入耗時 個小時以上 嚴重影響效率 因此 修改了系統的演算法 將此表中只存儲當天新增記錄 將此表truncate後 第二天執行對此表的update操作時 非常耗時 表中有 億多條數據的時候 此sql語句耗時 秒 表中有 萬條數據的時候 此sql語句耗時幾個小時 咨詢DBA後 得出結論 需重建索引 重建後 秒完成此操作 但第三天問題依然出現 DBA正在查找原因 難道每次truncate表 都需要重建索引？
對於這個問題 DBA也沒有給出合渣段理的解釋 推測主要原因是oracle復雜的查詢優化演算法
最終備者 DBA給出的解決方案
truncate table
drop index
insert data
create index
*** yze table table_name pute statistics;//重仿梁薯新生成統計數據
lishixin/Article/program/Oracle/201311/16938