我的查詢第二次運行得更快，我該如何阻止？

我運行在Oracle查詢10 select A from B where C = D B具有數百萬條記錄並且對C中沒有索引我的查詢第二次運行得更快，我該如何阻止？

我第一次運行它需要花費約30秒，所述第二時間我運行查詢大約需要1秒。

很明顯，它緩存了一些東西，我希望它能夠阻止它，每當我運行查詢時，我希望它花費30秒 - 就像它第一次運行一樣。

我過度簡化了爲了使問題可讀而出現的問題。

感謝

來源

2011-07-07 LoudNPossiblyWrong

您是否介意解釋爲什麼要讓它持續緩慢運行？ – Aducci

可能回答：性能調優和測試 – MatBailie

如何強制硬解析：http://oracle-randolf.blogspot.com/2009/02/how-to-force-hard-parse.html –

清除緩存以衡量性能是可能的，但非常笨拙。

跟蹤實現調優效果的一個非常好的方法是計算查詢執行過程中讀取塊的數量。一要做到這一點最簡單的方法是用sqlplus與自動跟蹤，就像這樣：

set autotrace traceonly 
<your query>

輸出

... 
Statistics 
---------------------------------------------------------- 
      0 recursive calls 
      0 db block gets 
      1 consistent gets 
      0 physical reads 
      0 redo size 
     363 bytes sent via SQL*Net to client 
     364 bytes received via SQL*Net from client 
      4 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
      1 rows processed

塊的數量看，無論是從高速緩存或從磁盤，是consistent gets。

的另一種方法是與增加統計即，與提示gather_plan_statistics運行查詢，然後在尋找從遊標緩存查詢計劃：

auto autotrace off 
set serveroutput off 
<your query with hint gather_plan_statistics> 
select * from table(dbms_xplan.display_cursor(null,null,'typical allstats'));

塊數讀是buffers列輸出。

--------------------------------------------------------------------------------------------------------------------- 
| Id | Operation  | Name   | Starts | E-Rows | Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | 
--------------------------------------------------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT |    |  3 |  |  1 (100)|   |  3 |00:00:00.01 |  3 | 
| 1 | SORT AGGREGATE |    |  3 |  1 |   |   |  3 |00:00:00.01 |  3 | 
| 2 | INDEX FULL SCAN| ABCDEF   |  3 | 176 |  1 (0)| 00:00:01 | 528 |00:00:00.01 |  3 | 
---------------------------------------------------------------------------------------------------------------------

來源

2011-07-07 14:48:47

有趣，但我創建了一個綜合索引，我在分析函數中使用的列，我想看看這個索引是否有效和有效。我可以使用你描述的效果嗎？ thx – LoudNPossiblyWrong

是的，查詢計劃的每個部分都會顯示相關的成本。如果沒有意外的情況發生，那包括你的複合索引意想不到的事情可能是你的索引不被使用。 –

看到這個question ...

它顯示瞭如何清除數據和執行計劃的緩存，同時也擴展了它是否是一個好主意或沒有。

來源

2011-07-07 14:16:48 MatBailie

-2

它可以幫助你

http://www.mssqltips.com/tip.asp?tip=1360

CHECKPOINT;
GO DBCC DROPCLEANBUFFERS;
GO

來源

2011-07-07 14:36:55

**另一種解決方案** –

EXEC sys.sp_configure N'max服務器內存（MB）'，N'2147483646'重寫GO重新配置（大小由您決定） –

錯誤的數據庫...不會幫助OP Oracle太多了。（看問題上的標籤） – derobert

顯而易見的答案是每個測試用例多次運行查詢並拋出第一個結果。由於涉及各種緩存，它不容易完全複製第一個查詢運行的條件：有些是Oracle緩存（遊標，緩衝區等）;有些是操作系統（磁盤緩存，取決於Oracle配置）;一些是硬件（SAN，RAID，磁盤）。

在每次試用之前重新啓動數據庫服務器可能會非常接近一致條件。

來源

2011-07-07 14:45:16 derobert

第一個結果不是最準確的嗎？ – EvilTeach

其實，第一個結果是不是最不準確的？如果你跑了100次，第一次過30秒，其餘的都是1秒，我認爲 - 就用戶體驗而言 - 這30秒的值非常不準確。 –

我的查詢第二次運行得更快，我該如何阻止？

回答

相關問題