資料庫系統性能受到查詢執行的嚴重影響。然而SQL語句的執行計劃可能因統計資訊變化,優化參數變化或方案定義變化等原因而意外改變,Oracle Optimizer優化器往往無法在沒有人工幹預的情況下準确進化執行計劃。在無法保證新的執行計劃總是趨于變得更好的情況下,使用者傾向于通過存儲大綱(stored outline)或鎖定統計資訊來保證執行計劃的問題。然而使用這些方式将不可避免地喪失利用到新的優化器特性以改善SQL語句性能的優勢。在保證目前可被接受執行計劃的前提下,僅允許采用那些更好的,獲益更多的執行計劃才是終極方案。 Oracle Database 11g是在解決這一SQL執行計劃上處于市場領先地位。SQL Plan Management(SPM)提供了一個完全透明且可控的執行計劃進化的架構。在SPM的幫助下優化器自動管理執行計劃并保證隻有已知或已确認的執行計劃才被采用。當一個新的計劃出現時,Oracle将不會采用它,直到确認其與目前的執行計劃有着相當的,或更好的性能。 SQL Plan Management(SPM)保證資料庫運作時性能絕不因為執行計劃的改變而大幅下降。為了確定這一點,僅僅那些已被接受的(accepted or trusted)的執行計劃将被采用;任何計劃的進化都将被追蹤并僅在其被評價為無損于性能或有益于性能後被采納。 SPM主要由三個部分組成: 1.執行計劃基線捕捉 建立SQL執行計劃基線意味着接受(或者說信任)相關SQL語句的執行計劃。SQL計劃基線存儲在曆史計劃中,曆史計劃儲存在SQL Management BASE(SMB)中,SMB位于SYSAUX表空間上。
<a href="http://blog.51cto.com/maclean/1277565#">?</a>
<code>SQL> </code><code>select</code> <code>* </code><code>from</code> <code>v$version;</code>
<code>BANNER</code>
<code>--------------------------------------------------------------------------------</code>
<code>Oracle </code><code>Database</code> <code>11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production</code>
<code>PL/SQL Release 11.2.0.2.0 - Production</code>
<code>CORE 11.2.0.2.0 Production</code>
<code>TNS </code><code>for</code> <code>Linux: Version 11.2.0.2.0 - Production</code>
<code>NLSRTL Version 11.2.0.2.0 - Production</code>
<code>SQL> </code><code>select</code> <code>occupant_name,space_usage_kbytes </code><code>from</code> <code>v$sysaux_occupants </code><code>where</code> <code>occupant_name </code><code>like</code> <code>'%SQL%'</code><code>;</code>
<code>OCCUPANT_NAME SPACE_USAGE_KBYTES</code>
<code>---------------------------------------------------------------- ------------------</code>
<code>SQL_MANAGEMENT_BASE 3776</code>
本文轉自maclean_007 51CTO部落格,原文連結:http://blog.51cto.com/maclean/1277565