摘要：Oracle數據庫11gR1新的SQL計劃管理工具給每個Oracle DBA都有能力捕獲并保存最有效的SQL語句執行計劃。本文—該系列文章的第二篇—解釋在升級一個現存的Oracle10gR2數據庫到Oracle11g時如何使用SQL計劃管理，與部署新應用程序代碼一樣，有效地限制SQL語句性能異常回退。

本系列的前一篇提供了Oracle數據庫11g新的SQL計劃管理（SPM）特色的入門介紹，包括一些如何使用SPM工具幫助過濾執行計劃以識別并隔離最佳的計劃以提升SQL語句性能的簡單例子。

因為我已經解釋并說明了SQL計劃管理的基本架構，現在我將注意力集中到討論兩種每個Oracle DBA都會遇到的情況：升級現有的Oracle數據庫到一個更新的版本，部署新的應用程序代碼到現有的數據庫。前面的文章已經說明了如何使用Oracle11g的新DBMS_SPM包捕獲新的SQL計劃基線，我將利用這兩種情況來說明Oracle11g企業管理器數據庫控制的SQL計劃控制規則來捕獲新的SQL計劃基線候選者，以及管理現有的SQL計劃基線。

SPM情景#1：升級一個現有的數據庫

在我看來，升級一個現有的數據庫有新的版本即使對一個經驗豐富的Oracle DBA而言也是相當痛苦的事情，因為很難精確地判斷升級后哪個語句性能降低了。在Oracle11g之前的環境中，我已經找到了限制這個不確定性最好的方法，就是在我的QA服務器上構造一個與生產環境完全一致的副本，捕獲充足的應用程序最關鍵的SQL語句工作負載，并捕獲這些語句的執行計劃。一旦我啟動升級開關升級QA數據庫和環境到新的數據庫版本，我要為這些語句重新生成執行計劃并比較結果以發現性能倒退的語句。

通過這種野獸般的測試方法我得以相當順利的從舊版本升級到Oracle11g，我也希望有更可靠的方法精確地判斷升級對現有SQL語句性能的影響，我已經在早先的關于SQL性能分析器的文章中論述過了，因此現在隔離任何性能倒退的SQL語句非常簡單，甚至對內部相對較小的升級也很簡單（如從11.1.0.5.0升級到11.1.0.6.0）。一旦使用SQL性能分析器識別出所有性能倒退的SQL語句，在我執行升級操作之前，我將拿起SQL計劃管理的強大工具捕獲那些語句到SQL調整集（STS）中。

從STS捕獲語句的SQL文本、綁定變量、執行計劃和執行統計后，我將保留它們直到數據庫版本升級完畢，到那時我將轉換這些語句執行計劃成為SQL計劃基線，當這些語句對于升級后的數據庫第一次執行時，無論如何，基于成本的優化器（CBO）都將檢測SQL計劃基線是否仍然可用，如果CBO判斷SQL計劃基線提供了一個更有效的執行計劃，它將用該基線計劃替換原有的計劃，最終結果是一個可能很嚴重的SQL計劃倒退是可以完全避免的。

收集SQL工作負載
要說明這個概念，我將首先在Oracle10gR2上創建一個SQL工作負載。我將在銷售歷史方案（SH）的多個表中使用5個查詢，查詢SQL（SPM_2_1.SQL），用來模擬一個在數據倉庫應用程序中的SQL工作負載，在我開始工作負載前，我將初始化列表2.1中的代碼，它使用DBMS_SQLTUNE.CAPTURE_CURSOR_CACHE_SQLSET來捕獲工作負載的SQL語句到一個名叫STS_SPM_200的SQL調整集中。

打包并導出SQL調整集
一旦我將SQL工作負載捕獲到一個SQL調整集中，我準備將它轉移到Oracle11gR1數據庫中，列表2.2展示了如何做：

◆創建中間表作為SQL調整集STS_SPM_200的容器
◆通過存儲過程DBMS_SQLTUNE.PACK_STGTAB_SQLSET轉移SQL調整集到中間表
◆通過數據泵導出工具導出中間表數據到一個名叫DumpStagingTable.dmp的導出文件

轉移SQL調整集
在我拷貝了數據泵導出文件到我的Oracle11g數據庫的默認數據泵目錄后，我將使用Oracle數據泵導入工具和適當的參數導入中間表到目標Oracle11gR1數據庫，然后，我會使用存儲過程DBMS_SQLTUNE.UNPACK_STGTAB_SQLSET打開存儲在中間表中的SQL工作負載。列表2.3展示了轉移過程的詳細情況。