Oracle 查詢 prod 和 staging 環境之間的不同性能
所以我有這 2 個 Oracle 12c 數據庫 R2、prod 和 staging 環境，它們都完美地對齊並在相同的硬體上執行。相同的 select 語句在暫存時大約需要 400 毫秒，而不會少於 4 秒。
我們的專家 DBA 離開了公司，留下我和我相對薄弱的技能來調查這個問題。我不知道如何繼續，儘管我看到每個解釋計劃（第一個是刺激，第二個是分期）關於基數的一些主要差異。
我真的不知道從哪裡開始只確定問題的根源。我重建了查詢中涉及的索引，但沒有任何效果。後來我放棄了它並再次創建它，沒有任何改進。
編輯：
根據建議，我收集了樣本 = 100% 的統計數據，沒有任何改進。儘管出於某種原因，prod 和 staging 之間唯一不同的參數是 sga_max_size 值，該值在 staging 中要高得多。儘管解釋計劃仍然不同，但在 prod 中對齊它幫助我重新獲得了相似的響應時間（查詢執行時間為 500 毫秒）。
我會將其標記為已解決，因為主要性能問題現已消失
安德魯在對您的問題的評論中所說的同上。
DBMS_STATS.GATHER_TABLE_STATS它可能有助於通過參數以100% 收集表和索引的統計資訊，estimate_percent=>100以確保擷取數據中的任何邊緣情況。我不記得 Oracle 12c 在建構索引時是否會收集完整的統計資訊，但無論哪種方式，如果索引中的數據有偏差，那麼首先要嘗試以 100% 收集統計資訊。預設情況下，Oracle 在收集統計資訊時對要查看多少表進行有根據的猜測，以便在執行時確定計劃。
請參閱該 PL/SQL 函式的文件。
另一件事可能是一個問題，但不太可能是您的症狀的問題，即使兩台伺服器具有“相同的硬體”，在網路、磁碟等方面也可能存在很大差異，Oracle 做出了錯誤的估計對於那些碎片。查看DBMS_STATS.GATHER_SYSTEM_STATS和範例；我發現“相同”伺服器的實際性能存在很大差異。
根據建議，我收集了樣本 = 100% 的統計數據，沒有任何改進。儘管出於某種原因，prod 和 staging 之間唯一不同的參數是 sga_max_size 值，該值在 staging 中要高得多。即使解釋計劃仍然不同，在 prod 中對齊它也幫助我重新獲得了相似的響應時間（查詢執行時間為 500 毫秒）。