關於Oracle 調整存在著許多神秘和規則
我是否應該分割這個表?
我應該使用什麼分區scheme?
我應該將OPTIMIZER_INDEX_COST_ADJ和OPTIMIZER_INDEX_CACHING的值設為什麼?
我是否應該定期重建我的索引?
還有許多問題在這個領域的一些德高望重的專家包括Tom Kyte和Jonathan Lewis提出了證明它的方法論問題是構建測試用例和試驗的時間可能稍稍受限
進入SQL Performance Analyzer(SQL性能分析器SPA)這是我最喜歡的g新特性之一SQL Performance Analyzer允許你捕捉一個sql調整工具集可以很多次地回去使用不同選擇來重新執行然後獲得改變後的結果
讓我們快速浏覽一下這個過程
捕捉一個SQL調整工具集這是一個從數據庫控制台進行的一個步驟在我後面的例子裡我告訴它去捕捉用戶FLOWS_在之後的兩分鐘執行的所有SQL然後我運行Application Express builder來生成SQL
運行SQL Performance Analyzer Guided Workflow向導
第一次替換SQL調整工具集
改變一些參數或數據結構
第二次替換SQL調整工具集
比較這兩個調整工具集並存儲結果
查看這個結果
包括改進或退後的SQL
以及改變了的所有SQL計劃
示例
這是一個例子我們來看看改變OPTIMIZER_INDEX_COST_ADJ和OPTIMIZER_INDEX_CACHING 的影響正如我先前所提到的我們要使用的調整工具集是用戶FLOWS_執行的SQL所以這不是測試這個改變對整個數據庫的影響但是你可以捕捉整個數據庫的調整工具集來測試這個影響這裡不會進行向導的所有個步驟因為沒有那麼多要看的我會解釋整個過程包括捕捉SQL調整工具集這只需要分鐘
要從g數據庫控制台裡到SQL Performance Analyzer點擊Performance標簽然後點擊右下角的SQL Performance Analyzer之後再點擊Guided Workflow下面是Guided Workflow 向導的一個截屏
在開始第二步之前運行下面的代碼
圖
在開始第三步之前運行下面的代碼
圖
下面是結果的截屏注意這條SQL語句中條有錯誤這是由於在APEX 中的DML操作所以在這不是問題但是這是一個要注意的地方還要注意有%的改進作用和%的衰退影響
讓我們看一個SQL語句的細節以便我們可以看到在這個語句上的改變詳情
圖
最後下面兩個截屏是從一個改變了的SQL計劃的細節得來的顯示了舊計劃和新計劃
舊的計劃
圖
新的計劃
圖
正如你所看到的新計劃使用了一個索引而舊計劃沒有
過去測試針對一條SQL語句的變更相對簡單但是測試條以上的語句或者是整個數據庫中的每條語句這幾乎是不可能的所以這是數據庫管理員和開發人員之類的人非常歡迎的一個特性作為一個開發人員你可以在你提出請求之前測試任何你希望你的數據庫管理員要做的性能變更作為一個數據庫管理員你可以在對產品做更改之前查看所有潛在的變更所帶來的影響這可以顯著地降低風險
From:http://tw.wingwit.com/Article/program/Oracle/201311/16844.html
