性能在甲骨文

遠程物化視圖我有一個問題reagrding甲骨文的物化視圖...性能在甲骨文

我們有兩個數據庫：

核心數據庫
報告數據庫

的舉報數據庫有：

到核心數據庫的數據庫鏈接
核心數據庫中的表的許多同義詞
許多在這些同義詞上定義的物化視圖。

視圖設置爲每小時刷新一次。

隨着源系統中數據量的增加，我們看到增加CPU以實現視圖。

經過仔細檢查後，看起來刷新進程構建了報表數據庫中的結果集 - 並將單個較小的SQL語句發送到Core數據庫。

其中一些物化視圖非常複雜，並且在表之間有很多連接。這會導致數百萬個針對Core數據庫的小型SQL語句。

我的問題是：這將是最好創建在覈心數據庫中對應的「複雜」的觀點，並在報告數據庫中的物化視圖，一個簡單的「SELECT * FROM CORE.MY_MAT_VIEW」

感謝任何指針，

歡呼聲，埃文

來源

2009-07-16 Evan

假設當你說「複雜」時，你是否可以安全地使用它，就像Oracle在談到複雜的物化視圖時所做的那樣 - 即無法逐步刷新的物化視圖？還是你在更一般的意義上使用「複雜」？ – 2009-07-16 04:31:48

我的意思是一般意義上的複雜 - 就像在許多表中加入的那樣，很多嵌套的表達式，分組等等。我不知道足夠的Oracle知道決定這些是否可以逐步完成的cirteria。順便說一句，進一步閱讀拋出了「driving_site」的提示。我認爲它可能正是我需要的 - 但我認爲它不能在視圖定義中完成（即在DML內）。 – Evan 2009-07-16 05:09:01

，我不會有什麼核心數據庫過於複雜。你會在覈心數據庫上增加更多的負載，並且可能會拖拽更多的數據。

您是否考慮過使用針對這些複製表構建的MV將Core表複製到Reporting環境（簡單複製）中。針對核心的SQL應該更簡單，從核心到報告的數據量應該更小，並且複雜的MV在單個數據庫中進行管理。

來源

2009-07-16 05:18:13

是的。好點子。我認爲這是我們需要做的，但實際上這對我們來說是中期的。特別是因爲交易量不是很大。要複製的增量更改量將遠遠少於定期運送整個結果集。現在，我是在「快速獲勝」之後。希望:-) – Evan 2009-07-16 05:22:20

+1 - 如果你的物化視圖很複雜（我在這種情況下使用複雜的含義來表示昂貴的SQL），這通常是最好的架構。使用簡單的增量式MV將錶轉換爲報表數據庫，只需很少或不進行轉換，然後從這些表中執行報表數據庫中更昂貴的MV刷新。 – dpbradley 2009-07-16 11:58:04

如果您的交易率並不像您說的那麼好，我會考慮降低您的刷新率。許多報告系統使用24小時週轉時間報告服務，用戶通常可以進行調整。通過在1小時到24小時之間使用刷新率，您甚至可以看到顯着的改進。

來源

2010-07-19 20:10:40 user396181

性能在甲骨文

回答

相關問題