如果您的查詢效率低下,並且您添加了一個索引以幫助提高性能,那麼查詢應該「立即」開始使用索引嗎?應該立即創建一個索引來更新Oracle的查詢計劃嗎?
或者您是否需要清除Oracle「緩存」(v $ sql我相信)runningalter system flush shared_pool;
?
如果您的查詢效率低下,並且您添加了一個索引以幫助提高性能,那麼查詢應該「立即」開始使用索引嗎?應該立即創建一個索引來更新Oracle的查詢計劃嗎?
或者您是否需要清除Oracle「緩存」(v $ sql我相信)runningalter system flush shared_pool;
?
由於DBA喜歡回答,「這取決於」。
這取決於Oracle是否認爲索引將有助於性能。如果Oracle認爲索引不是查詢的最佳選擇,那麼Oracle不會使用它。
這取決於您是否使用準備好的語句。準備好的語句在其生命週期中不會被重新編譯,因此如果正在運行的應用程序使用您正在嘗試修復的準備好的語句,則需要重新啓動該應用程序。
刷新共享池將迫使Oracle重新分析並重新優化所有語句(一個硬解析),因此如果Oracle認爲索引將有助於性能,則刷新共享池將會有訣竅。然而,它也可能在現場生產系統中產生深遠的影響 - 導致「解析風暴」,因爲每個使用中的陳述都必須進行重新設計和重新優化 - 而且只能作爲最後的手段進行。
你應該收集統計數據。您可以計算或估計統計數據。用法示例
計算
BEGIN
SYS.DBMS_STATS.GATHER_TABLE_STATS (
OwnName => 'ENROLLMENT'
,TabName => 'STUDENTS'
,Estimate_Percent => 0
,Degree => 4
,Cascade => TRUE
,No_Invalidate => FALSE);
END;
/
注意級聯參數告訴甲骨文還收集表上的所有索引的統計也是如此。
估計
BEGIN
SYS.DBMS_STATS.GATHER_TABLE_STATS (
OwnName => 'ENROLLMENT'
,TabName => 'STUDENTS'
,Estimate_Percent => DBMS_STATS.AUTO_SAMPLE_SIZE
,Degree => 4
,Cascade => TRUE
,No_Invalidate => FALSE);
END;
/
Thx,這確實有效。收集統計數據意味着什麼?爲什麼需要在我的情況下這樣做? – 2010-07-22 18:13:29
+1給Brian,我今天剛剛遇到這個!很生氣,我的真棒新索引沒有被使用:/ Ran統計表和索引,它的工作。 Marcus,Table和Index Statistics幫助優化器模型執行查詢的最佳方式。通常一個作業在晚上運行以更新統計信息(10g,11g),但您希望儘快重新收集,以便Optimizer立即獲得相關信息。有一整本書專門討論這個問題,所以我不會在這裏的500個角色中全部涵蓋。喬納森劉易斯的「基於成本的Oracle基礎知識」可能是開始深入報道的最佳選擇。 – 2010-07-22 19:53:29
這可能是改變查詢性能的原因是它使遊標無效,而不是因爲新的索引對優化器是「不可見的」。表上的統計數據不應該改變,並且對新索引進行統計將主要影響表中其他索引的選擇。 – dpbradley 2010-07-22 20:21:03
Shared pool不用於高速緩存數據。
Oracle Server有兩個性能測量,邏輯讀取和物理讀取。物理讀取是磁盤讀取性能的度量。邏輯讀取是從存儲器讀取數據的度量。
在任何讀取方法(索引,全表掃描或其他)中,塊中的行必須檢索到緩衝區緩存中。這是物理閱讀的行爲。
如果使用索引提高SQL性能,則邏輯讀取是從緩存返回結果,這是邏輯讀取的改進。
因此,總之,沒有必要。
是的,共享池不會緩存數據;但在這種情況下,問題在於查詢計劃正在被緩存,並且該共享池中的*爲*。 – 2010-07-23 00:39:24
爲什麼重新啓動應用程序會導致重新編寫準備好的語句(並且要更新解釋計劃)? – 2010-07-22 16:28:14
由於preparedStatement是Oracle中的遊標,Oracle知道您的應用程序正在保持該遊標直到您關閉preparedStatement或會話結束。通過終止應用程序結束會話通常是唯一的控制方法。一旦你沒有拿着那個遊標(重新啓動應用程序後),Oracle會注意到新的索引已經使共享池中的語句無效,並重新解析/重新優化語句。請參閱第3頁的流程圖:http://www.oracle.com/technology/books/pdfs/jdbc_ch5。pdf – 2010-07-22 16:46:14
*在錯誤的地方發表評論* – 2010-07-22 17:24:59