摘要：Oracle數據庫11gR1提供一套新工具集—SQL計劃管理（SPM），它讓每個Oracle DBA都可以為任何SQL語句捕獲并保存最有效的執行計劃。本文是本系列中的最后一篇，主要講述如何使用SPM限制現有SQL語句第一次遇到Oracle11g的基本成本的優化器（CBO）時性能突然倒退，同時，也一并介紹一下幾個允許非常細粒度的SQL管理庫（SMB）的管理的SQL計劃管理特色。

本系列前面的文章探討了Oracle數據庫11g新的SQL計劃管理（SPM）特色，它可以用于Oracle10g升級到Oracle11g時捕獲和載入SQL計劃基線，以便在數據庫升級過程中消除SQL語句性能倒退，前面的文章也講述了如何保證新應用程序代碼在部署到生產環境之前，為SQL語句選擇最有效的執行計劃。

本文將講述如何使用SPM：

◆當它們嘗試利用Oracle11g新的優化器特色時，限制SQL語句性能不必要的倒退。
◆通過手工方法捕獲特定SQL語句的SQL計劃基線。
◆控制現有SQL計劃基線的演變。
◆管理SQL計劃管理基線（SMB）的內容，包括如何清除過時的或不希望有的SQL計劃基線。
SPM情景#3：依靠前面的優化器版本使用SQL性能分析器（SPA）

在前面文章中的第一個情景講述了如何使用SPM為SQL語句捕獲SQL計劃基線，該SQL語句的性能在實施Oracle10g升級到Oracle11g的過程中可能倒退。那個情景實際上涉及到在一個現有的Oracle10g數據庫中執行該SQL語句組成的SQL工作負載。解決這個問題的一個可選的方法是在一個現有的Oracle11g數據庫環境中通過控制初始化參數OPTIMIZER_FEATURES_ENABLE的值模擬一個Oracle10g環境。

模擬準備
要說明這個情景，我將利用前面文章中SPM情景#2中SQL調整集STS_SPM_200中捕獲的相同的SQL語句，在我執行任何新的分析之前，我將從SQL管理庫（SMB）中移除早先創建的所有SQL計劃基線，我將使用函數DBMS_SPM.DROP_SQL_PLAN_BASELINE移除那些標記有注釋字符串“SPM_2”的語句（查看列表3.1），然后，我會準備一個新的名叫SPA_SPM_300的SQL性能分析器（SPA）任務，它將分析STS_SPM_200 SQL調整集中的SQL工作負載的性能（查看列表3.2）。

分析SQL工作負載
接下來，我將瞄準SPA任務SPA_SPM_300，評估在Oracle10gR2和Oracle11gR1數據庫環境之間模擬的工作負載性能，首先我會清除我的Oracle11g的庫緩存和數據庫緩存，確保提供一個干凈的性能評估起點。然后，我會設置初始化參數OPTIMIZER_FEATURES_ENABLE的值為10.0.0.0，欺騙優化器相信它是一個Oracle10g數據庫，最后，我會通過執行SPA_SPM_300一次測試分析那個模式下的性能，一旦這個順序完成了，我將設置OPTIMIZER_FEATURES_ENABLE的值為11.1.0.6，然后重復相同的分析，SPA將在Oracle11g環境下評估工作負載，這里用到的代碼在列表3.3中。

比較相關的工作負載性能
一旦這兩個工作負載執行測試完成，我下一個任務是判斷是否有SQL語句因為優化器設置改變而性能倒退了，我使用的代碼在列表3.4中，它們比較兩個工作負載模擬情況，然后生成一個關于哪些SQL語句性能下降了的報告。為了在這里展示SQL性能分析器的靈活性，我避開使用一個相對變化的優化成本作為我的度量值，相反，我選擇基于估計執行時間進行SQL語句比較。

為性能倒退的SQL語句捕獲SQL計劃基線
與分析報告顯示的結果一樣，在模擬從10.2.0.1升級到11.1.0.6時，有兩條SQL語句產生了負面的影響（性能降低了），我將捕獲這些語句的執行計劃到SQL計劃基線中，這將防止CBO使用11g優化器設置運行這些SQL語句，它會因這些語句引起有害的性能，列表3.5中的代碼說明了如何實現這個。