從Oracle 10中的分區事實表中優化SELECT

Question

我有一個事實表，其中包含8百萬行，每月增加100萬行。該表已包含索引。該表由IBM Cognos環境用於生成報告。目前我正在尋找優化表SELECT語句的方法。作爲第一次嘗試，我對錶進行了分區（每個分區具有相同的行分佈），並且該查詢適用於分區，但出於某種原因，我得到的性能相當甚至更差，這很奇怪。每個查詢只有一個分區受到影響。有人可以解釋如何優化這個？

我想到的第二個想法是將事實表作爲Index組織表來實現，但它必須將所有列都作爲主鍵。這是否正常，並會有性能增益？

第三個想法是以包含從星型模式連接的所有列的方式實現事實表。會有性能增益嗎？

編輯：這裏是執行計劃：

我已設法通過3次，以減少的訪問時間的事實表FT_COSTS（成本爲42000，現在是14900）後，我創建包含所述分區條件索引，但在此之前，我的結果比未分區的表格要糟糕。我用這個鏈接來解決我的分區問題Range partition skip check

從我現在看到的主要瓶頸是GROUP BY，它將成本從34000提高到85000，這比兩倍多。有沒有人有關於這個解決方法的想法？

Answer 1

分區修剪可能是一個棘手的問題。

你有解釋你的查詢計劃嗎？它顯示PARTITION RANGE SINGLE？如果沒有，則查詢忽略分區。如果確實如此，那麼你還有其他一些問題。

我的錢是在這些分支的第一個：分區物理重新排序表。這意味着不符合分區策略的執行計劃可能會比對未分區表更糟糕。

要進一步瞭解這一點，我們需要看到一些細節。至少您的表的分區子句和您所說的查詢部分適用於此方法。解釋計劃也會非常有幫助。你給我們提供的細節越多越好：調整是關於細節的，因爲每個案例都是獨特的。

---

「你能不能解釋一下爲什麼 組由具有如此高的成本，以及如何 可以減少？」

GROUP BY手段排序。如果您擁有大量數據，則這可能很昂貴，因爲它需要內存或磁盤寫入以及CPU週期。

至於降低成本，對於我沒有看到的查詢提供建議有點困難。我可以說的是：查詢需要時間，而使用大量數據的查詢需要更長的時間。調優的祕訣在於瞭解給定查詢的合理時間。如果查詢以足夠快的速度運行，成本無關緊要。

Answer 2

GROUP BY實際上GROUP BY是什麼？

解釋計劃指示進入GROUP BY的散列連接中的1,238,320行以及出現在頂層SELECT中的相同數字。這表明優化器實際上並不相信你會在這裏做任何真正的聚合。

Answer 3

通常通過創建一個或多個物化視圖來降低組的成本，通常要求您創建pe計算的聚合。

Answer 4

如果您在執行計劃結束時看到它顯示錶FT_COSTS已完全訪問（表訪問已滿）。因爲它是完全訪問的，所有的連接都是爲了獲得剛剛添加的數據，最後成本看起來很大。我的建議是爲表格設置合適的索引，以便它引用索引而不是整個表格來訪問數據，然後查看性能的劇烈變化！