一．新特性提綱
1.數據庫管理部分
◆數據庫重演(Database Replay)
這一特性可以捕捉整個數據的負載，並且傳遞到一個從備份或者standby數據庫中創建的測試數據庫上，然後重演負責以測試系統調優後的效果。
◆SQL重演(SQL Replay)
和前一特性類似。但是隻是捕捉SQL負載部分，而不是全部負載。
◆計劃管理（Plan Management）
這一特性允許你將某一特定語句的查詢計劃固定下來，無論統計數據變化還是數據庫版本變化都不會改變她的查詢計劃。
◆自動診斷知識庫（Automatic Diagnostic Repository ADR）
當Oracle探測到重要錯誤時，會自動創紀一個事件（incident），並且捕捉到和這一事件相關的信息，同時自動進行數據庫健康檢查並通知DBA。此外，這些信息還可以打包發送給Oracle支持團隊。
◆事件打包服務(Incident Packaging Service)
如果你需要進一步測試或者保留相關信息，這一特性可以將與某一事件相關的信息打包。並且你還可以將打包信息發給oracle支持團隊。
◆基於特性打補丁（Feature Based Patching）
在打補丁包時，這一特性可以使你很容易區分出補丁包中的那些特性是你正在使用而必須打的。企業管理器（EM）使你能訂閱一個基於特性的補丁服務，因此企業管理器可以自動掃描那些你正在使用的特性有補丁可以打。
◆自動SQL優化(Auto SQL Tuning)
10g的自動優化建議器可以將優化建議寫在SQL profile中。而在11g中，你可以讓oracle自動將能3倍於原有性能的profile應用到SQL語句上。性能比較由維護窗口中一個新管理任務來完成。
◆訪問建議器（Access Advisor）
11g的訪問建議器可以給出分區建議，包括對新的間隔分區（interval partitioning）的建議。間隔分區相當於範圍分區（range partitioning）的自動化版本，她可以在必要時自動創建一個相同大小的分區。範圍分區和間隔分區可以同時存在於一張表中，並且範圍分區可以轉換爲間隔分區。
◆自動內存優化（Auto Memory Tuning）
在9i中，引入了自動PGA優化；10g中，又引入了自動SGA優化。到了11g，所有內存可以通過只設定一個參數來實現全表自動優化。你只要告訴oracle有多少內存可用，她就可以自動指定多少內存分配給PGA、多少內存分配給SGA和多少內存分配給操作系統進程。當然也可以設定最大、最小閾值。
◆資源管理器（Resource Manager）
11g的資源管理器不僅可以管理CPU，還可以管理IO。你可以設置特定文件的優先級、文件類型和ASM磁盤組。
◆ADDM
ADDM在10g被引入。11g中，ADDM不僅可以給單個實例建議，還可以對整個RAC（即數據庫級別）給出建議。另外，還可以將一些指示（directive）加入ADDM，使之忽略一些你不關心的信息。
◆AWR 基線（AWR Baselines）
AWR基線得到了擴展。可以爲一些其他使用到的特性自動創建基線。默認會創建周基線。
2.PLSQL部分
◆結果集緩存（Result Set Caching）
這一特性能大大提高很多程序的性能。在一些MIS系統或者OLAP系統中，需要使用到很多"select count(*)"這樣的查詢。在之前，我們如果要提高這樣的查詢的性能，可能需要使用物化視圖或者查詢重寫的技術。在11g，我們就只需要加一個/*+result_cache*/的提示就可以將結果集緩存住，這樣就能大大提高查詢性能。當然，在這種情況下，我們可能還要關心另外一個問題：完整性。因爲在oracle中是通過一致性讀來保證數據的完整性的。而顯然，在這種新特性下，爲提高性能，是從緩存中的結果集中讀取數據，而不會從回滾段中讀取數據的。關於這個問題，答案是完全能保證完整性。因爲結果集是被獨立緩存的，在查詢期間，任何其他DML語句都不會影響結果集中的內容，因而可以保證數據的完整性。
◆對象依賴性改進
在11g之前，如果有函數或者視圖依賴於某張表，一旦這張表發生結構變化，無論是否涉及到函數或視圖所依賴的屬性，都會使函數或視圖變爲invalid。在11g中，對這種情況進行了調整：如果表改變的屬性與相關的函數或視圖無關，則相關對象狀態不會發生變化。
◆正則表達式的改進
在10g中，引入了正則表達式。這一特性大大方便了開發人員。11g，oracle再次對這一特性進行了改進。其中，增加了一個名爲regexp_count的函數。另外，其他的正則表達式函數也得到了改進。
◆新SQL語法 =>
我們在調用某一函數時，可以通過=>來爲特定的函數參數指定數據。而在11g中，這一語法也同樣可以出現在sql語句中了。例如，你可以寫這樣的語句：
|
select f(x=>6) from dual; |
◆對TCP包（utl_tcp、utl_smtp…）支持FGAC(Fine Grained Access Control)安全控制
◆增加了只讀表（read-only table）
在以前，我們是通過觸發器或者約束來實現對錶的只讀控制。11g中不需要這麼麻煩了，可以直接指定表爲只讀表。
◆觸發器執行效率提高了
內部單元內聯（Intra-Unit inlining）
在C語言中，你可以通過內聯函數（inline）或者宏實現使某些小的、被頻繁調用的函數內聯，編譯後，調用內聯函數的部分會編譯成內聯函數的函數體，因而提高函數效率。在11g的plsql中，也同樣可以實現這樣的內聯函數了。
◆設置觸發器順序
可能在一張表上存在多個觸發器。在11g中，你可以指定它們的觸發順序，而不必擔心順序混亂導致數據混亂。
◆混合觸發器（compound trigger）
這是11g中新出現的一種觸發器。她可以讓你在同一觸發器中同時具有申明部分、before過程部分、after each
row過程部分和after過程部分。
◆創建無效觸發器(Disabled Trigger)
11g中，開發人員可以可以閒創建一個invalid觸發器，需要時再編譯她。
◆在非DML語句中使用序列（sequence）
在之前版本，如果要將sequence的值賦給變量，需要通過類似以下語句實現：
|
select seq_x.next_val into v_x from dual; |
在11g中，不需要這麼麻煩了，下面語句就可以實現：
|
v_x := seq_x.next_val; |
◆PLSQL_Warning
11g中，可以通過設置PLSQL_Warning=enable all，如果在"when others"沒有錯誤爆出就發警告信息。
◆PLSQL的可繼承性
可以在oracle對象類型中通過super（和java中類似）關鍵字來實現繼承性。
◆編譯速度提高
因爲不在使用外部C編譯器了，因此編譯速度提高了。
◆改進了DBMS_SQL包
其中的改進之一就是DBMS_SQL可以接收大於32k的CLOB了。另外還能支持用戶自定義類型和bulk操作。
◆增加了continue關鍵字
在PLSQL的循環語句中可以使用continue關鍵字了（功能和其他高級語言中的continue關鍵字相同）。
◆新的PLSQL數據類型——simple_integer
這是一個比pls_integer效率更高的整數數據類型。
3.其他部分
◆增強的壓縮技術
可以最多壓縮2/3的空間。
◆高速推進技術
可以大大提高對文件系統的數據讀取速度。
◆增強了DATA Guard
可以創建standby數據庫的快照，用於測試。結合數據庫重演技術，可以實現模擬生成系統負載的壓力測試。
◆在線應用升級
也就是熱補丁——安裝升級或打補丁不需要重啓數據庫。
◆數據庫修復建議器
可以在錯誤診斷和解決方案實施過程中指導DBA。
◆邏輯對象分區
可以對邏輯對象進行分區，並且可以自動創建分區以方便管理超大數據庫（Very Large Databases VLDBs）。
◆新的高性能的LOB基礎結構
◆新的PHP驅動
二． 詳細介紹
1． 分區
Partition（分區）一直是Oracle數據庫引以爲傲的一項技術，正是分區的存在讓Oracle高效的處理海量數據成爲可能，在Oracle 11g中，分區技術在易用性和可擴展性上再次得到了增強。
1.1. Interval Partitioning
在我曾經的一個項目中，由於數據量的巨大，所以表設計爲每一個小時一個分區，數據庫管理員日常要做的一件重複而無聊的工作就是每隔一天要生成新的24個分區，用以存儲第二天的數據。而在11g中這項工作可以交由Oracle自動完成了，基於Range和List的Interval Partitioning分區類型登場。
CREATE TABLE TB_INTERVAL
PARTITION BY RANGE (time_col)
INTERVAL(NUMTOYMINTERVAL(1, 'month'))
(PARTITION P0 VALUES LESS THAN (TO_DATE('1-1-2010', 'dd-mm-yyyy')));
指定需要Oracle自動創建分區的間隔時間，上面這個例子是1個月，然後至少創建一個基本分區，上面這個例子是在2010-1-1之前的所有數據都在P0分區中，以後每個月的數據都會存放在Oracle自動創建的一個新分區中。
1.2. System Partitioning
系統分區，在這個新的類型中，我們不需要指定任何分區鍵，數據會進入哪個分區完全由應用程序決定，實際上也就是由SQL來決定，終於，我們在Insert語句中可以指定插入哪個分區了。
假設我們創建了下面這張分區表，注意，沒有指定任何分區鍵：
CREATE TABLE systab (c1 integer, c2 integer)
PARTITION BY SYSTEM
(
PARTITION p1 TABLESPACE tbs_1,
PARTITION p2 TABLESPACE tbs_2,
PARTITION p3 TABLESPACE tbs_3,
PARTITION p4 TABLESPACE tbs_4
);
現在由SQL語句來指定插入哪個分區：
-- 數據插入p1分區
INSERT INTO systab PARTITION (p1) VALUES (4,5);
-- 數據插入第2個分區，也就是p2分區
INSERT INTO systab PARTITION (2) VALUES (7,8);
-- 爲了實現綁定變量，用pno變量來代替實際分區號，以避免過度解析
INSERT INTO systab PARTITION (:pno) VALUES (9,10);
由於System Partitioning的特殊性，所以很明顯，這種類型的分區將不支持Partition Split操作，也不支持create table as select操作。
1.3. More Composite Partitioning
在10g中，我們知道複合分區只支持Range-List和Range-Hash，而在在11g中複合分區的類型大大增加，現在Range，List，Interval都可以作爲Top level分區，而Second level則可以是Range，List，Hash，也就是在11g中可以有3*3=9種複合分區，滿足更多的業務需求。
1.4. Virtual Column-Based Partitioning
Virtual Column是11g中的一個新功能，這種列中的數據並不實際存儲於磁盤上（我們可以看成是一個類似Function的列），只有當讀取的時候才實時計算。暫時不討論性能問題，這個功能還是比較有意思的。
可以通過這樣的語句來創建虛擬列。
CREATE TABLE tb_v
(col_1 number(6) not null,
col_2 number not null,
…
col_v as (col_1 *( 1+col_2));
虛擬列雖然沒有實際的存儲空間，但是卻可以跟其他普通列一樣，創建索引，作爲分區鍵，甚至可以收集統計信息。
2． 數據壓縮技術
隨着數據量的不斷海量，CPU的不斷強勁，雙核四核的叫個不停，一種叫做時間換空間的優化技術應該會越來越流行。所以，數據壓縮對於今後的數據庫來說，應該會從核武器變成常規武器。
Oracle11g是正兒八經的要推廣數據壓縮技術了，專門推出了一個叫做Advance Compression的組件，全面支持普通表壓縮，非結構化數據壓縮（SecureFile數據壓縮），Data Pump數據壓縮，以及RMAN備份壓縮，數據壓縮技術從此名正言順的登上歷史舞臺。
在Oracle9i中雖然引入了表壓縮，但是有很大的限制。只能對批量裝載操作（比如直接路徑裝載，CTAS等）涉及的數據進行壓縮，普通的DML操作的數據是無法壓縮的。這應該是對於寫操作的壓縮難題沒有解決，一直遺留到Oracle11g，總算是解決了關係數據壓縮的寫性能問題。Oracle的表壓縮是針對Block級別的數據壓縮，主要技術和Oracle9i差不多，還是在Block中引入symbol表，將block中的重複數據在symbol中用一個項表示。Oracle會對block進行批量壓縮，而不是每次在block中寫入數據時都進行壓縮，通過這種方式，可以儘量降低數據壓縮對於DML操作的性能影響。這樣，在block級別應該會引入一個新的參數，用於控制block中未壓縮的數據量達到某個標準以後進行壓縮操作。
SecureFile也是Oracle11g新推出的一項特性，用於存儲非結構化數據。SecureFile也將支持數據壓縮操作。這樣對於傳統的LOB字段也可以進行壓縮，將極大的減少大型數據庫的存儲空間需求。當然，有得比有失，壓縮和解壓時，對於CPU的要求也將更高。但是，目前CPU的發展速度明顯比IO和存儲空間快速的情況下，壓縮是大有可爲的技術。通過在壓縮率和壓縮效率方面的不斷提升，以後應該爲成爲各個數據庫的標準配置。
除了對數據庫中的數據進行壓縮，Advance Compression Option還將支持備份數據的壓縮。做爲邏輯備份的Data Pump和物理備份的RMAN工具，都將支持該技術。在Oracle10gR2中，Data Pump已經開始支持壓縮源數據，Oracle11g中則可以直接壓縮導出文件，這樣導出的時候就可以極大的減少存儲空間的需求。在以前版本中，利用WinRAR等，經常可以將幾個G的導出文件壓縮到幾十M，Oracle11g的白皮書上說壓縮率可以達到74.67%。同樣的，Oracle也在10g中開始引入RMAN的壓縮技術。但是Oracle11g號稱採用了更先進的ZLIB要所算法，可以比Oracle10g的壓縮算法快上40%，空間需求也將減少20%。
除了上述的數據壓縮技術，Oracle 11g Advanced Compression Option還將引入另外一種壓縮技術。我們知道在Data Guard中，需要將日誌從主庫傳遞到備庫。如果主庫的事務很多，則單位時間內需要傳遞的日誌量將相當可觀。如果能將這些日誌壓縮後在傳遞，然後在備庫解壓後應用，將極大的減少對於網絡帶寬的需求，從而已減少主備庫的時間差。
另外，Oracle的bitmap一直就是壓縮存儲的，10g中的bitmap對於9i就有比較大的改動，通過一些細節的完善，提供更好的性能和更高的穩定性，也是oracle一貫的風格。對於bitmap在Oracle11g中將如何實現，也將是非常值得關注的一個特點。
從Oracle11g開始，將沒有什麼是不可壓縮的。使用更強大的CPU，就可以降低或者延緩對存儲空間無休止的渴求，或許很多大型OLTP和大多數的數據倉庫，都將從數據壓縮技術中收益。
3．統計信息收集
下面圍繞統計信息收集，分別對收集統計信息時可以設置的選項、對合並列收集統計信息，對表達式和函數收集統計信息以及延遲發佈統計信息這四個方面做了闡述。
3.1. 設置收集統計信息時的選項
我們知道，數據庫裏的對象的統計信息（statistics）對於優化器得到正確的執行計劃來說起着至關重要的作用。因此從10g R1開始，只要使用DBCA安裝的數據庫，都會自動創建一個job，該job缺省週一到週五每天晚上10點到第二天早上6點（週末則爲全天）負責收集數據庫所有對象的統計信息。不過，可能存在某些情況，你需要用自己的腳本來收集某些特殊對象的統計信息。但是由於你採用了自動收集統計信息，oracle就會對所有對象使用相同的選項來收集統計信息，這樣你就失去了對某個對象的控制權。當你發現缺省的統計信息收集方式對某個對象不是很合適時，你必須鎖定該對象的統計信息，並使用一個特殊的選項值對該對象來收集統計信息。
比如，某個表的列的數據傾斜（列爲某種值的記錄行數非常多，而某種值的記錄行數又非常少）的非常嚴重，這時如果採用標準的採樣率：
ESTIMATE_PERCCENT=AUTO_SAMPLE_SIZE可能就不適合了。這時你就需要單獨指定該對象的採樣率。我們知道，在11g之前的收集統計信息方面，oracle提供的類似的其他選項還包括：CASCADE、DEGREE、METHOD_OPT、NO_INVALIDATE、GRANULARITY。
到了11g裏，則提供了更大的靈活性，從而使得你可以很簡單的處理上面所說的這種情況。在11g裏，上面說的這些選項可以在不同的級別上分別設置，級別由高到低分別爲：global級別、數據庫級別、schema級別、表級別。其中，低級別的選項覆蓋高級別的選項。
比如，對於上面所舉的例子來說，如果要對你的一個特殊的、列上的值傾斜的很嚴重的表收集統計信息時，你只需要簡單的調用如下的存儲過程來設置該表級別上的的ESTIMATE_PERCCENT=100即可，如下所示：
SQL> exec dbms_stats.set_table_prefs('Schema_name','Table_name',
'ESTIMATE_PERCCENT','100');
這樣設置以後，當數據庫在自動收集統計信息時，對於其他沒有單獨設置採樣率的表來說，採樣率會採用AUTO_SAMPLE_SIZE，而對於你單獨設置的Table_name表，則會使用100的採樣率來收集統計信息。
類似的，如果需要設置global級別上的選項，則調用dbms_stats.set_global_prefs；如果要設置數據庫級別上的選項，則調用dbms_stats.set_database_prefs；如果要設置schema級別上的選項，則調用dbms_stats.set_schema_prefs即可。
同時到了11g裏，除了上面提到的這些選項以外，還添加了另外三種新的選項：PUBLISH、INCREMENTAL、STALE_PERCENT。其中：
1) PUBLISH：收集完統計信息以後是否立即將統計信息發佈到數據字典裏，還是將它們存放在私有區域裏。TRUE表示立即發佈，FALSE表示存放到私有區域裏。
2) STALE_PERCENT：確定某個對象的統計信息過時的上限，如果過時就需要重新收集統計信息，缺省爲10。計算某個表的統計信息是否過時，oracle會計算自從上一次收集該表的統計信息以來，該表中被修改的數據行數佔該表的總行數的百分比。然後用得出的百分比值與該選項配置的值（如果缺省，就是10）進行比較，大於10，則說明該表的統計信息過時了，需要重新收集統計信息；否則就認爲該表的統計信息不過時，不用再次收集。
3) INCREMENTAL：在分區表上收集global的統計信息時（將GRANULARITY設置爲GLOBAL），採用增量方式完成。使用該選項是因爲對於某些分區表來說，比如按照月份進行範圍分區的分區表來說，除了代表當前月的分區裏的數據會經常變化以外，其他分區裏的數據不會變動。因此在收集該分區表上的global的統計信息時，就沒有必要再次掃描那些非當前月的分區了。如果你將INCREMENTAL設置爲TRUE時，則在收集統計信息時，就不會掃描那些非當前月的分區裏的數據，而只會掃描當前月的分區裏的數據。最後將非當前月的分區上已經存在的統計信息加上當前月新算出來的統計信息合併就得出了分區表的global的統計信息。
可以從視圖：DBA_TAB_STAT_PREFS裏看到所有的收集統計信息時的各個選項的值。
3.2. 對合並列收集統計信息
對於where條件裏具有兩個列以上的情況，比如where c1=’A’ and c2=’B’來說，11g以前優化器評估其selectivity時，總是將每個列的selectivity相乘，從而得到整個where條件的selectiviey。但是如果兩個列具有很強的依賴關係，比如汽車製造商與汽車型號這兩個列來說，我們知道每個汽車製造商所生產的汽車型號幾乎都不會重複，也就是說當你發出where 汽車製造商列=’XXX’ and 汽車型號列=’XXX’時，與發出where汽車型號列=’XXX’時返回的記錄行數可能幾乎一樣。這時如果在計算where條件的selectivity時仍然採用將汽車製造商列的selectivity乘以汽車型號列的selectivity時，就會導致總的selectivity過低，從而導致優化器估計返回的記錄行數過少，從而可能導致不正確的執行計劃。
爲了彌補這樣的問題，11g以後可以讓你將多個依賴程度很高列合併成一個組，然後對該組收集統計信息。具體如何實現，則可以看下面的例子。
select dbms_stats.create_extended_stats('Schema_name','Table_name','(C1,C2)') from dual;
通過調用函數dbms_stats.create_extended_stats將兩個或多個列合併，並返回一個虛擬的隱藏列的列名，其名字類似於：SYS_STUW_5RHLX443AN1ZCLPE_GLE4。
然後，我們可以開始對錶收集統計信息，收集完以後，你可以使用ALL|DBA|USER_STAT_EXTIONSIONS視圖來查看列組合的統計信息。
exec dbms_stats.gather_table_stats('Schema_name','Table_name');
如果你要對組合列收集直方圖，則可以如下所示：
exec dbms_stats.gather_table_stats('Schema_name','Table_name',
method_opt=>'for columns (C1,C2) size AUTO');
3.3 對函數以及表達式收集統計信息
如果where條件類似於function_name(table_name.column_name)=’XXX’時，則優化器在估計這樣的where條件的selectivity時，總是會假設其selectivity爲1％，也就是該where條件將返回table_name裏總記錄行數的1％的記錄行數。很明顯的，這種假設肯定是錯誤的，從而可能導致優化器產生了不夠優化的執行計劃。
從11g開始，我們可以對函數或者表達式收集統計信息了。該特性依賴於虛擬列，也就是說你需要先用dbms_stats.create_extended_stats函數爲
function_name(table_name.column_name)創建一個虛擬列，然後對該虛擬列收集統計信息。比如下面的例子。
select dbms_stats.create_extended_stats('Schema_name','Table_name','length(C1)') from dual;
下面則顯示的是對表達式來收集統計信息。
select dbms_stats.create_extended_stats('Schema_name','Table_name','C1*C2') from dual;
然後你可以對錶收集統計信息時，就會爲函數length(C1)對應的虛擬列收集統計信息了。如果你要對該虛擬列收集直方圖，則可以如下所示：
exec dbms_stats.gather_table_stats('Schema_name','Table_name',
method_opt=>'for columns (length(C1)) size AUTO');
3.4 _PRIVATE_STATS裏看到這些私有的統計信息。
爲了測試這些私有統計信息，你可以有兩種方法：
1) 第一種方式使用DBMS_STAT.EXPORT_PRIVATE_STATS存儲過程將私有統計信息轉移到你自己的統計信息表（可以使用存儲過程DBMS_STATS.CREATE_STAT_TABLE來創建你自己的統計信息表）裏。然後可以使用expdp導出你的統計信息表，然後再使用impdp將導出文件導入到測試環境中，再使用DBMS_STAT.IMPORT_TABLE_STATS將其導入到測試環境中進行測試。
2) 第二種方式不導出私有的統計信息，而是直接在產品庫的session級別，將11g引入的新的初始化參數： OPTIMIZER_PRIVATE_STATISTICS設置爲TRUE（缺省情況下該參數爲FALSE）。這時你執行SQL時，優化器就會參考私有統計信息來解析SQL語句並生成執行計劃了。
最後，測試完畢，發現最新的統計信息沒有問題的話，你就可以使用DBMS_STAT.PUBLISH_PRIVATE_STATS在產品庫上將私用統計信息發佈出去，從而讓優化器能夠看到它們。
下面列舉一個例子來簡單說明這個過程。
首先設置表級別的publish選項爲false：
exec dbms_stats.set_table_prefs('Schema_name','Table_name','PUBLISH','false');
然後，收集表的統計信息：
exec dbms_stats.gather_table_stats('Schema_name','Table_name');
第三，設置相關初始化參數：
alter session set optimizer_use_private_statistics = true;
第四，進行測試，運行相關的SQL語句，並檢查產生的執行計劃。
最後，把該表的統計信息發佈出去：
exec dbms_stats.publish_private_stats('Schema_name','Table_name');
4．執行計劃管理
4.1. 執行計劃管理的工作原理
我們知道，SQL語句的性能很大程度上依賴於SQL語句的執行計劃。如果SQL語句的執行計劃發生改變，則SQL的性能很有可能發生大的變化。而SQL執行計劃發生變化的原因有很多種，包括優化器版本的變化、統計信息的變化、優化器相關的各種參數的變化、添加或刪除了索引、添加或刪除了物化視圖、修改了系統設置、以及是否應用了10g引入的SQL profile等。
在11g之前，我們可以使用存儲大綱（stored outline）和SQL Profile來幫助我們固定某條SQL語句的執行計劃，防止由於執行計劃發生變化而導致的性能下降。不過這些技術需要DBA人爲的處理，比如存儲大綱，需要DBA手工創建，而SQL Profile來說，則要DBA手工應用才能生效。
從11g開始，oracle引入了SQL執行計劃管理（SQL Plan Management）這個新特性，從而可以讓系統自動的來控制SQL語句執行計劃的穩定性，進而防止由於執行計劃發生變化而導致的性能下降。
通過啓用該特性，某條語句如果產生了一個新的執行計劃，只有在它的性能比原來的執行計劃好的情況下，纔會被使用。爲了實現執行計劃管理，優化器會爲所有執行次數超過一次的SQL語句維護該SQL語句的每個執行計劃的歷史列表（plan history）。優化器通過維護一個語句執行的日誌條目（statement log）來識別該SQL語句是否爲第二次執行。一旦優化器認出某條SQL語句爲第二次執行，則優化器將該語句所生成的所有不同的執行計劃插入到plan history的相關表裏，而plan history裏包含了優化器能夠用於重新生成執行計劃的所有信息，這些信息包括SQL文本、存儲大綱、綁定變量以及解析環境（比如optimizer_mode之類影響優化器解析SQL語句的參數）等。
當然，11g也支持手工維護SQL語句的plan history，作爲對自動維護plan history的功能補充。但是並不是說plan history裏任何的執行計劃都可以拿來使用。這裏需要先介紹一下所謂的執行計劃基準線（plan baseline）這個概念。plan baseline是plan history的一個子集，plan
baseline裏面的執行計劃是用來比較性能好壞的一個依據。也就是說，憑什麼來判斷是否可以使用一個新產生的執行計劃呢？就是把該新的執行計劃與plan baseline裏的計劃進行比較來判斷。某個SQL語句的執行計劃可以屬於plan history，但是不一定屬於plan baseline。
注意：每個SQL語句都會有它自己的執行計劃歷史以及執行計劃基準線。
那麼某個SQL語句的執行計劃是如何進入執行計劃歷史，乃至執行計劃基準線的呢？
有兩種方法可以將SQL語句的執行計劃納入到執行計劃管理體系中去：
1) 將初始化參數：OPTIMIZER_CAPTURE_PLAN_BASELINES設置爲true，則會自動的捕獲SQL的執行計劃。該參數缺省爲false。設置爲true以後，當某條SQL語句第一次執行時，該SQL語句的plan
history是空的，顯然該SQL語句的plan baseline也是空的。那麼當該SQL第二次再次執行時，優化器會自動將該SQL語句以及相關的執行計劃放入plan history，同時也會放入到plan baseline裏。這就構成了最初的plan baseline，也就是說最初進入plan history的執行計劃會直接自動進入plan baseline裏。那麼當你做了某些修改，比如添加了一個索引等，然後第三次執行該同樣的SQL語句，則會產生另外一個不同的執行計劃，這時新的執行計劃會自動進入plan history，但是不會自動進入plan
baseline。是否使用該新的執行計劃，則要把該新的執行計劃與plan baseline裏現存的第二次執行SQL時的執行計劃進行比較，如果新的執行計劃成本更低，則會使用新的執行計劃，否則使用plan baseline裏的執行計劃。
2) 使用dbms_spm包手工處理，這可以讓你手工管理SQL plan baseline。使用該包，你可以直接將SQL的執行計劃從shared
pool里加載到plan baseline裏，也可以使用dbms_spm包將已經存在的SQL Tuning Set加載到plan baseline裏。同時，dbms_spm可以讓你把plan history裏的執行計劃加入到plan baseline裏。反之，你也可以使用該包將plan baseline裏的執行計劃移出去。
注意，某條SQL語句的plan baseline裏的第一個執行計劃可以像上面說的通過設置初始化參數來自動加入，但是如果你希望在plan baseline裏添加該SQL語句的其他新的執行計劃時，則必須使用dbms_spm包手動完成。
那麼plan baseline裏的執行計劃是如何被使用的呢？
Oracle提供了一個初始化參數：OPTIMIZER_USE_PLAN_BASELINES，該參數缺省爲true，表示要求優化器考慮使用plan baseline裏的執行計劃，如果設置爲false，則不使用執行計劃管理的特性，而又回到了11g之前的狀況。
以下描述基於的前提是plan baseline裏已經存在了一個SQL的執行計劃。
每次優化器解析SQL語句的時候，首先仍然使用11g之前的傳統方式產生一個成本最低的執行計劃，然後看初始化參數：OPTIMIZER_USE_PLAN_BASELINES是否設置爲true，如果爲false，則直接返回所生成的執行計劃。否則如果爲ture，則去plan history裏找是否存在相同的執行計劃，如果找到了，則再去plan baseline裏找是否存在相同的執行計劃，如果也找到了，則直接返回該執行計劃。如果在plan history裏沒找到相同的執行計劃，則將產生的執行計劃加入到plan history裏，然後將執行計劃與plan
baseline裏已經存在的執行計劃進行比較，看哪個執行計劃的成本低就取哪個執行計劃。
如果你爲某個SQL語句保存了存儲大綱，則爲了向下兼容，該語句會使用存儲大綱。另外，即使你通過設置初始化參數：OPTIMIZER_CAPTURE_PLAN_BASELINES爲true來啓動自動捕獲執行計劃到plan baseline裏，對於使用存儲大綱所生成的執行計劃也不會放入plan baseline裏。
SQL語句的plan history以及plan baseline所涉及到的表是存放在SQL
Management Base (SMB)裏的，SMB裏同樣也存放了SQL Profiles。而SMB是數據字典的一部分，存放在SYSAUX表空間裏。SMB所佔用的空間會自動定期的刪除。
4.2. 執行計劃管理的測試
Oracle 11g提供了一個視圖：dba_sql_plan_baselines，可以在該視圖裏查詢某條SQL語句相關的plan history以及plan baseline。我們來看下面的例子。
首先創建一個測試表。
SQL> create table t1(skew number, padding varchar2(100));
SQL> insert into t1 select rownum,object_name from dba_objects;
SQL> commit;
SQL> set autotrace traceonly exp stat;
SQL> select * from t1 where skew=200;
SQL> select * from t1 where skew=200;
儘管執行兩次，但是這時去查詢dba_sql_plan_baselines，試圖找到SQL文本爲select * from t1 where skew=200的記錄時，會發現沒有記錄，因爲optimizer_capture_sql_plan_baselines缺省爲false。我們將該參數設置爲true以後繼續測試。
SQL> alter session set optimizer_capture_sql_plan_baselines=true;
SQL> select * from t1 where skew=200; --全表掃描
SQL> select * from t1 where skew=200; --全表掃描
SQL> select signature,sql_handle,plan_name,origin,enabled,accepted, autopurge
from dba_sql_plan_baselines where sql_text like 'select * from t1 where skew=200';
SIGNATURE SQL_HANDLE PLAN_NAME ORIGIN ENA ACC AUT
---------- ------------------------ ----------------------------- ----------- --- --- ---
1.2376E+19 SYS_SQL_abc0a2c042fa089c SYS_SQL_PLAN_42fa089c844cb98a AUTO-CAPTURE YES YES YES
我們可以看到，文本爲“select * from t1 where skew=200”的SQL語句在plan history裏產生了一個執行計劃。其中，
sql_handle表示SQL語句的句柄；
plan_name則表示該SQL的執行計劃的名字；
origin表示該執行計劃是如何進入plan history的，該列值爲AUTO-CAPTURE則說明是由優化器自動加入的，如果爲MANUAL則說明是由DBA手工加入的；
enabled表示是否被啓用了，YES表示啓用，NO表示禁用。如果某個執行計劃爲禁用，則優化器根本就不會考慮使用該執行計劃；
accepted表示是否接受，也就是是否進入了plan baseline。我們看到這裏的accepted爲YES，說明該SQL的執行計劃進入了plan baseline裏；
autopurge表示該執行計劃是否爲定期自動刪除，YES表示是，NO表示否。
我們繼續測試，在skew上添加一個索引，從而讓原來的SQL不走全表掃描，而改走索引掃描。
SQL> create index idx_t1 on t1(skew);
SQL> exec dbms_stats.gather_table_stats(user,'t1',cascade=>true);
SQL> select * from t1 where skew=200; --索引掃描
SQL> select signature,sql_handle,plan_name,origin,enabled,accepted,fixed,autopurge
from dba_sql_plan_baselines where sql_text like 'select * from t1 where skew=200';
SIGNATURE SQL_HANDLE PLAN_NAME ORIGIN ENA ACC AUT
---------- ------------------------ ----------------------------- ----------- --- --- ---
1.2376E+19 SYS_SQL_abc0a2c042fa089c SYS_SQL_PLAN_42fa089c844cb98a AUTO-CAPTURE YES YES YES
1.2376E+19 SYS_SQL_abc0a2c042fa089c SYS_SQL_PLAN_42fa089cdbd90e8e AUTO-CAPTURE YES NO YES
這時我們可以看到，dba_sql_plan_baselines視圖裏多了一個執行計劃，也就是我們後面那個使用了索引掃描的執行計劃。而該執行計劃的accepted爲NO，說明該計劃並沒有進入plan baseline裏，但是進入了plan history裏。
這時，我們可以通過調用dbms_spm包來手工將走索引的執行計劃加入到plan baseline裏。如下所示，將accepted改爲YES。
SQL> dbms_spm.alter_sql_plan_baseline(
sql_handle => 'SYS_SQL_abc0a2c042fa089c',
plan_name => 'SYS_SQL_PLAN_42fa089c844cb98a',
attribute_name => 'ACCEPTED',
attribute_value => 'YES');
然後再次查詢dba_sql_plan_baselines視圖，可以發現後面的執行計劃的accepted變爲了YES。
SQL> select signature,sql_handle,plan_name,origin,enabled,accepted,fixed,autopurge
from dba_sql_plan_baselines where sql_text like 'select * from t1 where skew=200';
SIGNATURE SQL_HANDLE PLAN_NAME ORIGIN ENA ACC AUT
---------- ------------------------ ----------------------------- ----------- --- --- ---
1.2376E+19 SYS_SQL_abc0a2c042fa089c SYS_SQL_PLAN_42fa089c844cb98a AUTO-CAPTURE YES YES YES
1.2376E+19 SYS_SQL_abc0a2c042fa089c SYS_SQL_PLAN_42fa089cdbd90e8e AUTO-CAPTURE YES YES YES
如果我們要手工刪除plan baseline裏的執行計劃，則可以調用dbms_spm裏的存儲過程來實現。
SQL> var cnt number;
SQL> exec :cnt :=
dbms_spm.purge_sql_plan_baseline('SYS_SQL_abc0a2c042fa089c');
刪除指定SQL語句的執行計劃以後，再去查詢dba_sql_plan_baselines就會發現上面測試SQL語句的執行計劃不存在了。
從上面的描述可以看出，SQL Plan Management特性的主要作用就是通過引入一個SQL plan baseline，從而保證SQL語句執行計劃的穩定，進而保證系統性能的穩定。本質上，它屬於11g之前的存儲大綱的升級版，而且是自動實現的，不需要人工干預。
5．自動內存管理
Auto Memory Management是Oracle10g提出來的一個新特性，在最新的Oracle11g數據庫中又得到了進一步的發展。
通過使用自動內存管理，Oracle數據庫中的PGA和SGA內存之間可以互相轉換，根據當前的工作負載來自動設定Oracle內存區域中的PGA和SGA的大小。這種間接的內存轉換依賴於操作系統的共享內存的釋放機制來獲得內部實例的調優。目前這種技術可以應用於Linux, Solaris, HPUX, AIX 和Windows等操作系統上。
首先我們來回顧下Oracle10g的自動內存管理特性。在Oracle10g的數據庫中，只有SHARED_POOL_SIZE、DB_CACHE_SIZE、LARGE_POOL_SIZE、JAVA_POOL_SIZE、STREAMS_POOL_SIZE五個SGA組件可以被自動調整，其中PGA的最大值由初始化參數PGA_AGGREGATE_TARGET決定，SGA的最大值由初始化參數SGA_TARGET決定。
在Oracle11g數據庫中，使用自動內存管理特性不再需要設定參數PGA_AGGREGATE_TARGET和SGA_TARGET，因爲這兩個參數都已經被修改成自動調優的，除非想指定PGA和SGA的最小值才需要設定這兩個參數。
在Oracle11g數據庫中，則需要設置一個叫做MEMORY_TARGET的初始化參數，這個參數是指整個Oracle實例所能使用的內存大小，包括PGA和SGA的整體大小，在MEMORY_TARGET的內存大小之內，PGA和SGA所用的內存可以根據當前負載情況自動相互轉換。
如果當初始設定的MEMORY_TARGET的內存不夠當前數據庫使用的時候，Oracle11g還提供了另外一個初始化參數MEMORY_MAX_TARGET，當原始設定的內存不夠使用的時候，可以手工來動態 調節MEMORY_TARGET的大小，但是不允許超過MEMORY_MAX_TARGET的值。
下面這張圖簡單明瞭的描述出了Oracle11g數據庫內存大小的設定參數。
此外，Oracle11g數據庫還提供了幾個用於監控自動內存管理的視圖：
V$MEMORY_DYNAMIC_COMPONENTS：描述當前所有內存組件的狀態
V$MEMORY_RESIZE_OPS：循環記錄最後800次的SGA大小調整請求
X$KMGSTFR:循環記錄最後800次的SGA的轉換地址
_MEMORY_MANAGEMENT_TRACING=23:對於所有的內存轉換調整行爲均記錄保存爲跟蹤文件
6． ASM(自動存儲管理)
6.1. ASM Fast Mirror Resync
在10g的ASM中如果因爲某些硬件故障（比如接口線，比如光纖卡，比如電源）導致Diskgroup中的某些磁盤無法正常讀取，這些磁盤將處於offline狀態，在offline之後不久ASM就會把這些磁盤從Diskgroup中刪除，並且嘗試利用冗餘的extent來重新在其它磁盤中構建數據，這是一個比較耗時且耗資源的操作。當我們修復了磁盤，再將它們重新加回磁盤組中，又將是另外一次的數據重整操作。如果我們僅僅是例行的維護硬件，因爲磁盤中的數據並沒有真正的損壞，我們只是將磁盤取出來過一會兒再加回去，那麼這樣的兩次數據重整操作無疑是沒有必要的，在11g中ASM的Fast
Mirror Resync功能允許我們設置磁盤的repair時間，在repair時間內ASM將不會嘗試在磁盤間重新分配extent。
ALTER DISKGROUP dgroup SET ATTRIBUTE 'DISK_REPAIR_TIME'='3H';
上述命令可以設置當磁盤組dgroup中的磁盤失效和重新有效之間的時間在3小時內的話，ASM就不會重新構建extent，當磁盤重新有效之後，ASM需要做的只是將這3小時內更改的extent重新同步到剛纔失效的這些磁盤中就可以了。
6.2. ASM Preferred Mirror Read
我們知道在10g中ASM總是會去讀取Primary extent，這樣做的目的是爲了更好的分散IO，但是在某些環境中，一個ASM磁盤組中的磁盤對於某一個特定的節點來說，有些是Local Disk而有些則是Remote Disk，從Remote Disk中讀取數據效率會低於Local Disk，但是在10g中我們無法要求從哪組磁盤中讀取數據，在11g中新增的ASM_PREFERRED_READ_FAILURE_GROUPS參數幫助我們完成了這個功能。給每個實例設置優先讀取的Failure Group就可以了。
6.3. ASM擴展性的增強
對於外部冗餘（External redundancy），ASM可以最大支持到140PB了，而在10g中這個數字僅僅是35TB。
7．Server Result Cache
Cache始終是提升性能的重要技術, 在Oracle 11g中增加了一種Server Result Cache, MySQL的Query Cache是根據SQL的文本來匹配的, 只有Query的文本一模一樣時纔可以共享,而Oracle的Server Result Cache則只要執行計劃一樣或部份一樣, 並且生命週期一樣, 則就可以共享了. 當下面的表數據改變了, Oracle會自動清除這個Cache, 以確保查詢結果的正確性. 在以讀爲主要的系統中, 宣稱性能可以提升一倍.
這塊內存從SGA中分配, 由RESULT_CACHE_MAX_SIZE控制. Oracle允許你在系統, 會話, 表和語句級(Hint:result_cache)控制是否使用Server Result Cache技術. Oracle提供一個PL/SQL包及相應視圖來管理這個Cache區域.
對於同樣的操作，如果能在多個process或者session間共享結果，對於性能優化自然是非常有幫助的。從oracle7開始提供的share pool，可以讓同樣的SQL可以解析一次，執行多次，有效的減少了多個session執行相同SQL語句時的硬解析，如果應用很好的使用了綁定變量，那麼共享SQL對於系統整體性能的提升是不言而喻的。
那麼，除了能共享SQL和執行計劃，還能共享什麼？直接共享SQL執行後的結果，使得相同或者部分相同的SQL語句甚至只需要執行一次，以後再次執行時就直接得到結果？沒錯，Oracle11g的新特性Server Result Cache就能提供這樣功能。Oracle在白皮書上宣佈，對於讀頻繁的系統，通過該特性，甚至有可能提升系統性能200%，對於大量報表的數據倉庫項目來說，這個特性應該是一個不錯的消息。
Server Result Cache通過在SGA中分配一個緩衝區來保存查詢結果，Oracle引入了一個新的初始化參數來控制這個cache的大小：result_cache_max_size。可以在system、session、table或者語句級別來設置cache的使用。在語句級可以使用一個新的hint來控制是否緩存查詢結果。另外，Oracle還提供了一個新的PL/SQL用來監控和管理Server
Result Cache，比如可以清空整個cache的內容或者清空某個查詢的結果，也可以生成cache的使用報告等。
既然使用了cache，自然會有cache查找和cache數據清除算法的問題。估計查找還會是通過hash算法，這樣還需要引入幾個相關的latch。Cache中的數據，也應該是通過LRU或者類似LRU的算法來管理其生命期。
Server Result Cache不僅僅能緩存整個查詢的結果，也能緩存查詢中某部分操作的結果，比如緩存一次排序的結果，就可以避免再次執行時的排序操作。對於一些比較耗資源的查詢操作，緩存結果應該能很好的提升性能。
通過在服務端和客戶端引入對於查詢結果的緩存機制，Oracle11g或許能極大的提高查詢性能。對於一些讀比較頻繁的系統，比如數據倉庫應用，Oracle11g或者更值得期待。
8．提升性能 Consistent Client Cache
Cache始終是提升性能的重要技術. 除了在前面講的Server Result Cache, Oracle 11g還增加了一種Client Cache. 這是一種在Oracle Client端的緩衝技術, 通過將中間結果或整個表緩衝在客戶端,當客戶端發出查詢請求時, Oracle可以直接在這個緩衝區中返回記錄, 而不需要去和數據庫打交道, 可以大大地着少和服務器端的網絡來回, 降底服務器上的SQL調用, 根據Benchmarks測試, 對於只讀或極少更新的表, 總的消耗時間可以降低500%, 而服務器上的CPU時間可以降低200%.
通過OCI接口，在Client端也可以緩存查詢結果。典型的場景就是我們在應用服務器端緩存查詢結果，這樣在前端執行該查詢時，甚至不需要到數據庫中去執行該查詢。客戶端結果緩存在OCI進程中，可以被該進程中的多個session或者線程共享。
要使用這個Cache功能, 也很簡單, 首先要使用Oracle 11g的OCI客戶端, 如: JDBC-OCI, ODBC, ODB.NET, PHP, Perl等, 無須要去更改現有的程序代碼; 其次需要在數據庫端指定CLIENT_RESULT_CACHE_SIZE參數來指定這一塊Cache的大小, 如果爲0則表示禁用. 當該參數大於0時，該特性被啓用，同樣的，該特性也可以在system、session、table或者語句級來設置。通過在服務端設置參數而不是客戶端設置，可以集中的管理該特性，但是也可以在各個客戶端單獨進行設置，客戶端的設置將覆蓋服務端的設置。
9．如何使用ADRCI
9.1．關於 ADR Command Interpreter (ADRCI)
一個存放數據庫診斷日誌、跟蹤文件的目錄，稱作ADR base，對應初始化參數DIAGNOSTIC_DEST，如果設置了ORACLE_BASE環境變量，DIAGNOSTIC_DEST等於ORACLE_BASE，如果沒有設置ORACLE_BASE，則等與ORACLE_HOME/log。
關於ADRCI:ADRCI Command-Line Utility 命令行工具，使用該工具查看ADR中的日誌和跟蹤信息，查看健康報告；還可以將相關錯誤日誌和信息打包成zip文件，以便提供給oracle support分析。在ADRCI工具中可以執行很多命令，另外可以象sqlplus一樣執行腳本。
9.2．開始使用ADRCI
9.2.1運行ADRCI，$ORACLE_HOME/bin/adrci
代碼:
[root@ractest ~]# su - oracle
[oracle@ractest ~]$ which adrci
~/11g/bin/adrci
[oracle@ractest ~]$ adrci
ADRCI: Release 11.1.0.4.0 - Beta on Thu Jul 12 05:39:29 2007
Copyright (c) 1982, 2006, Oracle. All rights reserved.
ADR base = "/home/oracle"
adrci>>
退出ADRCI，在adrci>>提示符下敲入exit或者quit ， 回車大小寫敏感：在adrci中命令大小寫不敏感
代碼:
adrci>>SHOW tracefile
diag/rdbms/orcl/orcl/trace/orcl_ora_20187.trc
diag/rdbms/orcl/orcl/trace/orcl_fbar_11388.
但使用搜索串的時候是敏感的，比如：
SHOW TRACEFILE %mmon%
9.2.2．如何得到幫助信息：
（1）得到adrci中的命令列
代碼:
adrci>>help
HELP [topic]
Available Topics:
CREATE REPORT
......
（2）也可以使用adrci –help來得到adrci的命令使用和選項。如：
代碼:
[oracle@ractest ~]$ adrci -help
Syntax:
adrci [-help] [script=script_filename]
[exec = "one_command [;one_command;...]"]
Options Description (Default)
-----------------------------------------------------------------
script script file name (None)
help help on the command options (None)
exec exec a set of commands (None)
-----------------------------------------------------------------
（3）如何得到特定命令的幫助信息：
adrci>>HELP SHOW TRACEFILE
Usage: SHOW TRACEFILE [file1 file2 ...] [-rt | -t]
[-i inc1 inc2 ...] [-path path1 path2 ...]
…………….
9.2.3．使用ADRCI進行批處理命令或者腳本
(1) 使用exec選項，用分號將命令隔開
這裏文檔中有個小問題，文檔中寫ADRCI EXEC="COMMAND[; COMMAND]..."，
只能在windows平臺這樣寫，在unix/linux平臺下必須用小寫來執行。
代碼:
adrci>>show homes;show base; echo '20070712'
ADR Homes:
diag/rdbms/orcl/orcl
ADR base is "/home/oracle"
20070712
adrci>>
adrci>>
adrci>>exit
[oracle@ractest ~]$ adrci exec="show homes;echo '20070712';echo '';show base; "
ADR Homes:
diag/rdbms/orcl/orcl
20070712
ADR base is "/home/oracle"
(2) 使用script選項。adrci SCRIPT=adrci_script.txt
代碼:
[oracle@ractest ~]$ cat /tmp/a
show homes;
[oracle@ractest ~]$ adrci script=/tmp/a
[oracle@ractest ~]$ cat /tmp/a
fadsfdsa
[oracle@ractest ~]$ adrci script=/tmp/a
[oracle@ractest ~]$ cat /tmp/a
show trace;
[oracle@ractest ~]$ adrci script=/tmp/a
[oracle@ractest ~]$ cat /tmp/a
SET HOMEPATH /home/oracle/diag/rdbms/orcl/orcl;show trace;
[oracle@ractest ~]$ adrci script=/tmp/a
[oracle@ractest ~]$
9.3．使用ADRCI查看Oracle數據庫後臺報警日誌（alert_sid.log）和跟蹤文件
注意：以下大部分命令都需要用Ctrl+C 來結束，並返回到adrci命令行
1.查看完整alert信息：
adrci>>SHOW ALERT
2. 查看最新alert信息：
adrci>> SHOW ALERT –TAIL
查看最新20條alert信息：
adrci>> SHOW ALERT -TAIL 20
只查看600的錯誤
adrci>>SHOW ALERT -P "MESSAGE_TEXT LIKE '%ORA-600%'"
查看ORA-錯誤信息，注意這裏的參數很好，比較人性化，可以幫助提供錯誤時間
以下該命令的幫助：
代碼:
adrci>>help show alert
Usage: SHOW ALERT [-p <predicate_string>] [-tail [num]] [-v]
[-file <alert_file_name>]
Purpose: Show alert messages.
Options:
[-p <predicate_string>]: The predicate string must be double quoted.
The fields in the predicate are the fields in the alert message's
XML schema. To get the field definitions, use command:
"describe&
3．查看跟蹤文件
常用的有：
(1)列出所有跟蹤文件： SHOW TRACEFILE
(2)模糊查詢跟蹤文件，比如某個進程的，注意這裏區分大小寫 SHOW TRACEFILE
%mmon%
(3)可以指定某個路徑 SHOW TRACEFILE %mmon% -PATH /home/steve/temp
(4)象ls那樣按時間排序 SHOW TRACEFILE -RT
9.4．其他體驗和說明
9.4.1關於在adrci中執行os命令，可以直接在adrci中執行os命令。
所以當發出一個不存在的命令的時候，錯誤信息也就是系統返回的了。
代碼:
adrci>>id
uid=10000(oracle) gid=1001(dba) groups=1001(dba),1002(oinstall)
context=user_u:system_r:unconfined_t
adrci>>host date
DIA-48415: Syntax error found in string [host date] at column [9]
adrci>>host
[oracle@ractest ~]$ exit
exit
adrci>>! -------------這樣不行
/bin/bash: -c: line 0: syntax error near unexpected token `newline'
/bin/bash: -c: line 0: `!'
Additional information: 512
adrci>>! date -------------這就可以
Thu Jul 12 06:20:40 CST 2007
--------------------------------------------------------------------
[oracle@ractest ~]$ ksh
$ adrci
ADRCI: Release 11.1.0.4.0 - Beta on Thu Jul 12 06:28:14 2007
Copyright (c) 1982, 2006, Oracle. All rights reserved.
ADR base = "/home/oracle"
adrci>>abc
/bin/bash: abc: command not found
--------明明在ksh下，卻返回bash的錯誤….
Additional information: 32512
adrci>>ksh
$ abc
ksh: abc: not found
9.4.2.確認了在adrci中使用的alert是log.xml，而非alert_orcl.log
對alert進行置空(> file)，adrci不受影響；
對log.log進行置空，adrci返回的錯誤挺嚇人的：internal error code，
跟00600一個風格啊。。。應該是某些tag找不到，就報這麼狠的錯誤
代碼:
adrci>>show alert
ADR Home = /home/oracle/diag/rdbms/orcl/orcl:
**********************************************************
DIA-48001: internal error code, arguments: [17183],
[0x84B178C], [], [], [], [], [], []
DIA-48154: reached end of file for alert log
DIA-48102: encountered the end-of-file when reading&nb
9.4.3.在adrci中不能使用退格（backspace）怎麼辦
跟sqlplus一樣，有下面幾種選擇：
用del鍵；
使用Ctrl+backspace；
使用Ctrl+u刪除整行（bash下）；
在os命令行下stty erase ^h （可以直接寫到oracle的.profile/.bash_profile下面）
9.4.4.另外adrci一個重要的功能是查看Incident和對Incident打包的功能。
10. RMAN
RMAN除了單純的備份恢復功能，已經被賦予了越來越多的責任，比如創建Standby數據庫，比如跨平臺傳輸表空間中的表空間轉換。Oracle11g的RMAN倒是沒有太多飛躍性的更新。
10.1. 自定義archivelog刪除策略
我們知道在11g之前，只有backupset的刪除策略可以定義，比如保留多長時間的備份或者保留多少份有效備份，而刪除歸檔日誌只有在delete命令中定義刪除全部備份完畢的或者刪除從哪一個時間點到哪一個時間點的。而在11g中我們已經可以通過configure命令來定義歸檔日誌的刪除策略的，比如增加了下面的語法，只有在磁帶上備份了2次的歸檔日誌纔會被delete命令刪除。
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DEVICE TYPE sbt;
當然，僅僅是增加語法那就只能稱爲比較無聊的新功能了，除了configure語法之外，現在在11g中通過APPLIED ON STANDBY關鍵字可以定義只有對於所有的standby站點都已經applied的歸檔日誌纔會被刪除，或者定義所有被成功傳送到standby站點的歸檔日誌就可以被刪除。而以前這些都需要DBA自己撰寫腳本從數據字典中查詢到相關信息然後再通過腳本刪除。
10.2. 直接通過網絡複製數據庫
在11g之前如果要使用duplicate命令來複制一份數據庫，那麼則需要源數據庫，需要在目標機器上的一份有效備份，需要目標數據庫，在11g中這一切被大大簡化。通過FROM ACTIVE DATABASE關鍵字，我們只需要有一個源數據庫，就可以簡單地通過網絡在另外一臺機器上覆制一個相同的數據庫了。Oracle會通過一系列Memory Script在內存中recover並且open目標數據庫。
另外，在11g之前，duplicate數據庫是不會自動複製spfile的，而現在，我們通過下面的語句，就可以讓Oracle在複製過程中自動生成一份spfile，並且其中的初始化參數允許額外定義。
DUPLICATE TARGET DATABASE
TO aux_db
FROM ACTIVE DATABASE
SPFILE PARAMETER_VALUE_CONVERT '/u01', '/u02'
SET SGA_MAX_SIZE = '200M'
SET SGA_TARGET = '125M'
SET LOG_FILE_NAME_CONVERT = '/u01','/u02'
DB_FILE_NAME_CONVERT '/u01','/u02';
在11g中使用duplicate複製一個數據庫的準備步驟只需要目標數據庫（AUXILIARY實例）：
a. 通過一個最簡單的pfile把實例啓動到nomount狀態，這個pfile中只需要包含DB_NAME和REMOTE_LOGIN_PASSWORFILE參數即可
b. password文件必須事先建好，而且SYS密碼需要跟source數據庫中相同，這個通過orapwd可以輕鬆完成
c. 目錄結構需要事先創建好並且具有正確的權限
10.3. 並行備份大文件
現在Oracle數據庫中單個數據文件可以最大到128T，而在以前的版本中RMAN的最小備份單位就是datafile，那麼對於以後可能出現的這種超大數據文件，RMAN備份就幾乎無法操作了。在11g中，通過backup命令中的SECTION SIZE關鍵字，我們可以對數據文件指定section了，每個section都作爲一個獨立單位來處理，每個數據文件可以最多指定256個section。
Section的好處在於，
一可以並行備份多個section，提高備份速度；
二可以分多個時間分別備份一個大文件的多個section，時間上化整爲零，更具有操作性。
10.4. RMAN Catalog管理性增強
IMPORT CATALOG命令允許我們將一個catalog庫中的信息轉儲到另外一個catalog庫，這在以前完全需要手工操作。
推出Virtual Recovery Catalogs概念，這是VPD的實例應用，對於一個集中管理的catalog設置多個用戶的虛擬catalog，每個用戶只能管理自己的數據，安全性的進一步提高。
11. 兩個特性
11.1 歸檔日誌壓縮
其中一個是歸檔日誌壓縮的功能。通過設置初始化參數 log_archive_dest_n 中 compression 選項，可以對歸檔文件進行壓縮生成。對於網絡傳輸比較吃緊的環境，這個功能會很有價值。
11.2 物理 Standby 可以聯機查詢
11g 據說也可以對物理的 Standby 進行聯機查詢，前提條件是激活 Redo Apply 。10g 之前，物理 Standby 都是要麼恢復狀態，要麼 Read Only 狀態。如果能夠邊恢復邊查詢的話，那麼簡直是一個比較完美的 IO 分佈的技術方案了。SharePlex 之類的產品市場會又小不少。
12 Database和SQL重演
Database Replay是指在產品環境的數據庫上捕獲所有負載，並可以將之傳送至Standby數據庫或由備份恢復的測試庫上，在測試環境中重演主庫的環境，這使得升級或者軟件更新可以進行預先的"真實"測試，或者可以通過測試環境完全再現真實環境的負載及運行情況。
在我看來，這是Oracle向後追溯能力的又一增強，在Oracle10g中，我們知道Oracle通過v$session_wait_history視圖，ASH特性等，實現將數據庫的等待事件向後追溯，現在通過Database Replay特性，Oracle可以將整個數據庫的負載捕獲、記錄並實現Replay，也就是整個數據庫的向後追溯能力。
這一特性提供的再現現場能力，極大的豐富了我們發現並解決數據庫問題的手段，將爲數據庫管理帶來更多的方便之處。
當然使用這一特性會帶來一定的性能負擔，Oracle說這一負擔在5%左右。
這一特性的簡化版本就是SQL Replay，即只捕獲SQL負載，通過SQL負載應用再現SQL影響：
Oracle已經有了一系列的Flashback，現在又有了Replay；Flashback可以向後閃回，Replay可以向前推演，Oracle給用戶提供的手段越來越多，期待這一特性在正式版中能夠有完美的展現。
13. Server Connection Pool
在應用服務器這一層, 我們已經使用Connection Pool了, 可以有效地降低服務器上的連接的數量, 不過還是有不足之處的. 當你的訪問量達到一定的規模時, 你會發現一臺或幾臺應用服務器根本就解決不了問題, 在有些世界級的網站中, 應用服務器的數量可能是上千臺的, 當每個應用服務器產生4-5個連接時, 你會發現Oracle服務器端便有了4-5千個物理連接. 象PHP程序, 要求每一個Web Server進程都至少有一個連接. 因此Oracle在11g中引入了Database Resident Connection
Pool的功能, 這樣客戶端就可以不管連接池了, 由Oracle在服務器端進行連接共享控制.
通過增加一個後臺進程CMON(Connection Monitor)來管理連接, 應用發出連接請求時, 實際上是連接到CMON進程, 然後由CMON進程分配一個已經連接好的後臺進程, 當客戶端連接關閉後, 這個後臺進程又交由CMON進程管理. 估計PHP這類的Web程序要有福氣了, 不需要去實現連接池的代碼了.
14 其他地方
14.1, RAC節點通信協議的改進.
11g中的協議比較智能, 可以根據節點的負荷作出動態的調整, 大大減少節點之間的消息傳遞量.
14.2, 邊恢復邊Open的Physical Standby -- Highly Available Reader Farms
這個功能肯定很受大公司的歡迎, 因爲以前的Data Guard不能做到這樣, 當Open時同主庫的延遲會越來越大, 而在11g中則不存在這樣的延遲, 因此可以建幾個這樣的Standby來分擔讀操作, 估計Shareplex或Realsync這樣的軟件市場要受到一定的影響了, 我對Log的研究也變得越來越沒有價值了.
14.3, 面向OLTP的壓縮表
在新的壓縮技術中, Oracle可以去掉了壓縮表的諸多限制, 使之可以適合OLTP的環境. 這樣Oracle可以充分利用閒的CPU的資源(CPU越來越歷害了), 以降低IO的消耗(IO的提高還是很慢).