查詢成本與執行速度+並行度

Question

我們的IT部門最近受到我們IT部門的譴責（運行良好），因爲我們的查詢具有破壞數據庫穩定性和/或崩潰的實際可能性，因此運行查詢的成本非常高。我們都不是DBA的;只是研究人員對數據庫編寫和執行查詢，我可能是唯一一個在譴責之前查看解釋計劃的人。

我們被告知，超過100的查詢成本應該非常少見，並且不應該運行超過1000的成本查詢。我遇到的問題是成本似乎與執行時間沒有關係，而且我在優化查詢時失去了生產力。

作爲一個例子，我有一個查詢在5秒鐘內執行，費用爲10844.我重寫了查詢以使用包含我需要的大部分信息的視圖，並將成本降至109，但檢索相同結果的新查詢需要40秒才能運行。我發現了一個問題，在這裏與一個可能的解釋：

Measuring Query Performance : "Execution Plan Query Cost" vs "Time Taken"

這個問題使我並行提示。我在成本10884查詢中嘗試使用/*+ no_parallel*/，但成本沒有變化，執行時間也沒有變化，所以我不確定並行性是更快執行時間還是更高成本的解釋。然後，我嘗試使用/*+ parallel(n)*/提示，並發現n的值越高，查詢的成本就越低。在成本10844查詢的情況下，我發現/*+ parallel(140)*/將成本降至97，執行時間僅略有增加。

這似乎是一個理想的「欺騙」，以滿足我們的IT部門提出的要求，但後來我讀了這一點：

http://www.oracle.com/technetwork/articles/datawarehouse/twp-parallel-execution-fundamentals-133639.pdf

本文包含了這樣一句話：

並行執行可以使單個操作能夠利用所有系統資源。

所以，我的問題是：

我是否實際使用/*+ parallel(n)*/暗示具有非常高的並行度將服務器上的資源較爲緊張，即使我降低了成本？

假設沒有並行性，執行速度是比成本更好的資源使用衡量標準嗎？

Answer 1

你的DBA給你的規則沒有多大意義。擔心爲查詢報告的成本很少有成效。首先，您不能直接比較兩個不同查詢的成本 - 一個成本高達數百萬的查詢可能運行速度非常快，並且消耗的系統資源非常少，另一個成本高達數百的查詢可能會運行數小時，並將服務器屈膝。其次，成本是一個估計。如果優化器對成本進行了準確估計，這強烈暗示它已經提出了最佳查詢計劃，這意味着您不太可能在使用較少資源時修改查詢以返回相同結果。如果優化器對成本進行了不準確的估計，這強烈暗示它提出了一個糟糕的查詢計劃，在這種情況下，報告的成本與您想出的任何有用的指標都沒有關係。大多數情況下，您試圖優化的查詢是優化程序生成不正確查詢計劃的查詢，因爲它錯誤地估計了各個步驟的成本。

通過使用可能或不可能實際更改查詢計劃的提示來欺騙優化器（例如，取決於如何配置並行性）不太可能解決問題 - 這更有可能導致優化器的估計不太準確，並且更有可能選擇的查詢計劃消耗的資源遠遠超過需求。例如，具有高度並行性的parallel提示將告訴Oracle大幅降低全表掃描的成本，這使得優化器可能會選擇通過索引掃描進行選擇。這很少是你的數據庫管理員希望看到的東西。

如果你正在尋找的，告訴你一個查詢計劃是否合理單一指標，我會用邏輯I/O量。邏輯I/O與實際查詢性能以及查詢消耗的資源量相關性很好。查看執行時間可能會有問題，因爲它根據什麼數據發生緩存而變化很大（這就是爲什麼查詢在第二次執行時運行得更快），而邏輯I/O不會根據什麼數據在緩存中。它還可以讓您根據查詢處理更改所需的行數擴展您的期望。例如，如果您正在編寫一個需要彙總100萬行數據的查詢，則該查詢所消耗的資源要遠遠多於需要從表中返回100行數據而不匯聚的查詢。如果您正在查看邏輯I/O，您可以輕鬆地將您的期望擴展到問題的大小，以確定查詢的實際效率。

在基督教安託尼尼的「Troubleshooting Oracle Performance」（頁450），例如，他給了大拇指，這是非常合理的

• 5邏輯的規則，每時返回/聚合讀取一行可能是非常好的
• 10邏輯每時返回/聚集行讀取是可能足夠
• 20+邏輯每行被返回/聚集可能是低效的，並且需要被調諧

讀取

具有不同數據模型的不同系統可能需要稍微調整桶，但這些可能是很好的起點。

我的猜測是，如果你是研究人員不屬於開發商，你可能運行需要聚合或獲取比較大的數據集，至少相較於那些應用程序開發人員通常編寫查詢。如果您正在掃描一百萬行數據以生成一些聚合結果，那麼與查詢讀取或寫入少量行的應用程序開發人員相比，您的查詢自然會消耗更多的資源。您可能正在編寫從每行邏輯I/O角度看同樣有效的查詢，您可能正在查看更多行。

如果您正在運行鍼對現場製作數據庫查詢，你很可能是在它有道理，開始分離工作負載的情況。大多數組織都達到了針對實時數據庫運行報表查詢開始爲生產系統創建問題的程度。解決這類問題的一個常見解決方案是創建一個單獨的報告數據庫，該數據庫從生產系統提供（通過夜間快照或正在進行的複製過程），報告查詢可以在不影響生產應用程序的情況下運行。另一個常見的解決方案是使用諸如Oracle資源管理器之類的東西來限制一組用戶（在這種情況下是報表開發人員）可用的資源量，以便將對較高優先級用戶（在這種情況下爲生產用戶系統）。