我有一個報表引擎，在Oracle 11上執行PreparedStatements，這是一個高度優先的任務。有沒有辦法解決共享池中的Oracle查詢
我看到的是，第一個查詢調用通常比之後的同一個查詢執行得多得多（查詢具有不同的參數並返回不同的數據）。
我想這是由於第一次查詢調用Oracle完成的硬解析。
我想知道，有沒有一種方式暗示Oracle，這個查詢是高度優先的查詢哪些會經常執行，哪些性能是關鍵的，所以它應該保留在共享池中，不管是什麼？
我知道我可以修復Oracle 11中的執行計劃，但我不想修復它，我希望Oracle仍然能夠更改它，因爲系統更改，我只想要排除查詢硬解析。
Anton， 如果您的查詢使用綁定變量，它將被重新使用。遊標將被緩存，只要它被重用，遊標將保留在遊標緩存中。確保它使用綁定變量。這增加了重用性和可擴展性。
如果您不信任rdbms，則可以使用dbms_shared_pool.keep將其掛住。 請參閱http://psoug.org/reference/dbms_shared_pool.html
您需要找到光標才能這樣做。 通常還有一個問題需要解決。
它確實使用綁定變量。但是如果緩存過載，它會被保留下來。正如我所看到的那樣，問題在於緩存在當天移除此查詢，之後再次解析它。 – mavarazy 2011-02-04 09:47:04
在這種情況下，shared_pool太小或應用程序的其他部分激發了太多不可共享的sql。通常情況下，rdbms會嘗試重新使用和緩存它所能做的所有事情，而不是刪除它認爲有價值的東西。 – 2011-02-04 09:58:13
是的，這是原來的問題。我想知道，我可以提示Oracle不要從shared_pool中刪除這個查詢。換句話說，將其設置爲共享池中最「有價值」的查詢，關於可用性等。 – mavarazy 2011-02-04 11:11:49
也許你應該改變你的「我想......」變成了「我測試，並已確定......」 :)
查詢性能可能比僅僅解析更加受到影響;當它執行時，它必須從磁盤獲取塊到緩衝區緩存中 - 後續執行很可能利用了在內存中找到的塊，因此速度更快。
編輯：回答你的直接問題 - 解決方法可能是定期運行一個作業，解析查詢但不執行它。您甚至可以使用它來確定解析或提取是否是問題的發生位置。
您可以嘗試使用dbms_shared_pool.keep
釘扎到共享池，但你已經老化了問題第一
你使用綁定變量我首先要確保？ – 2011-02-04 09:36:30