Oracle 11g 新特性簡介

Oracle 11g於2007年7月11日美國東部時間11時（北京時間11日22時）正式釋出，11g是甲骨文公司30年來發布的最重要的資料庫版本，根據使用者的需求實現了資訊生命週期管理（Information Lifecycle Management）等多項創新。

 

一．新特性提綱

 

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，我們就只需要加一個的提示就可以將結果集快取住，這樣就能大大提高查詢效能。當然，在這種情況下，我們可能還要關心另外一個問題：完整性。因為在oracle中是透過一致性讀來保證資料的完整性的。而顯然，在這種新特性下，為提高效能，是從快取中的結果集中讀取資料，而不會從回滾段中讀取資料的。關於這個問題，答案是完全能保證完整性。因為結果集是被獨立快取的，在查詢期間，任何其他DML語句都不會影響結果集中的內容，因而可以保證資料的完整性。

◆物件依賴性改進 
在11g之前，如果有函式或者檢視依賴於某張表，一旦這張表發生結構變化，無論是否涉及到函式或檢視所依賴的屬性，都會使函式或檢視變為invalid。在11g中，對這種情況進行了調整：如果表改變的屬性與相關的函式或檢視無關，則相關物件狀態不會發生變化。

◆正規表示式的改進 
在10g中，引入了正規表示式。這一特性大大方便了開發人員。11g，oracle再次對這一特性進行了改進。其中，增加了一個名為regexp_count的函式。另外，其他的正規表示式函式也得到了改進。

◆新SQL語法 => 
我們在呼叫某一函式時，可以透過=>來為特定的函式引數指定資料。而在11g中，這一語法也同樣可以出現在sql語句中了。例如，你可以寫這樣的語句：

◆對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的值賦給變數，需要透過類似以下語句實現：

在11g中，不需要這麼麻煩了，下面語句就可以實現：

◆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 ] [-tail [num]] [-v]

[-file ]

Purpose: Show alert messages.

Options:

[-p ]: 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，並且其中的初始化引數允許額外定義。

在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的提高還是很慢)