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，咱們就只須要加一個/*+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 ] [-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，而且其中的初始化參數容許額外定義。 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的提升仍是很慢).