首先我要說明：本文主要目的是幫助初級和中級水平的Oracle專業人士了解Oracle系統及更好地優化它。後面的章節裡也介紹了不少專家主題，但首要的任務卻是協助那些被性能問題折磨得很沮喪的專業人士，他們正尋求著改善數據庫性能的簡單訣竅。本文的目標很單純：提供一個裝滿此類訣竅的彈藥庫，在各種不同的情況下您都可以運用它來使系統快起來。
如果您希望僅讀一章就能得到優化數據庫的方法或者一攬子方案，那麼我提供具有如此特點的兩章給那些沒有時間通讀本書的讀者。頭一個是介紹Statspack和AWR的第14章(Statspack是免費的，但AWR的功能更強)：這是兩個好得令人難以置信的工具，包含了大多數專家所最常用的腳本，專家們在使用V$視圖和X$表優化系統時調用這些腳本(第12和13章中介紹了V$視圖和X$表)。第14章花了我很長時間才寫成，時間主要花在了更新闩(Latch)等內容和互斥(Mutex)的新內容上。另一個包羅萬象的優化章節乃是介紹企業管理器(Enterprise Manager，包括數據庫控制器和網格控制器)的第5章。企業管理器提供了圖形化的方法來優化您的系統，包括許多用於RAC系統和大規模網格控制的特性。企業管理器為您提供了極佳的、以單一界面來查看和優化多個系統的能力。
簡言之，本文講的是Oracle 11gR1和R2中一些令人感興趣的新特性。許多新的和改善了的特性都包含在這個版本中。Oracle 11g的目標不僅僅是創造一個更健壯的數據庫管理系統，同時還要簡化安裝和管理的工作，以提高可用性。這種趨勢從Oracle 9i就已經開始，在10g裡得到延續，在11g中進一步延續下去。Oracle的戰略方向就是提供一個完全集成的功能集合，來取代數據庫管理員們用以管理他們環境的第三方軟件。本文並不會對本章中列出的所有新特性作詳細介紹(因為有些特性與優化並無直接的關系，而且本書的篇幅也有限制)。盡管如此，為了使讀者對11gR2有個整體印象，我想還是需要這麼一章來介紹一些好的特性，而不管它們是否與優化有關。
本章中所涉及的新功能包括：
● 輪到Exadata出場了！
● 高級壓縮
● 自動診斷信息庫(Automatic Diagnostic Repository，ADR)
● 自動共享內存管理(Automatic Shared Memory Management，ASMM)的改進
● ASM(Automatic StorageManagement，自動存儲管理)的改進
● 自動SQL優化
● 數據衛士(Data Guard)的增強
● 數據泵的增強(壓縮、加密、傳統模式)
● 增強了的統計信息
● 閃回數據存檔
● 健康情況監控
● 事件打包服務(IncidentPackaging Service，IPS)
● 不可視索引(invisible index)
● 分區新特性(區間分區、REF分區、系統分區、虛擬列分區、分區顧問)
● 只讀表
● RAC One Node和RAC Patching
● 真正應用測試(Real Application Testing)
● SQL性能分析器(SQL Performance Analyzer，SPA)
● 結果集緩存(ResultCache)
● RMAN的新特性
● 安全文件(SecureFiles)
● 流(XStream In、XStream Out、高級壓縮支持)的增強
● 臨時表空間的收縮
● 透明數據加密(Transparent Data Encryption，TDE)的改進
● 11g新的後台進程
● 11g版本特性對照表
伴隨著Sun 的被收購，一場范式轉換的革命發生在數據庫市場、硬件界和整個IT行業。雖然這場范式轉變才剛剛開始，然而早期的波動預示著重大轉變已經到來，未來的十年中還會有更大的轉變。這裡列出Exadata的一些要點，若想了解更多的細節，則可參閱Exadata那一章(第11章)。Exadata是結合了數據庫威力的硬件，它利用了Oracle加在硬件層面的特性，而其他硬件供應商無法輕易地、或者根本不可能復制這些特性。第11章中的一些主題將詳細討論 Exadata的主要優點：
● 閃存(Flash Cache)
閃存是由比普通磁盤快約20-50倍(取決於不同的磁盤)的固態硬盤組成(信息存儲於芯片上，滿配的機架上可達5TB的容量)。閃存緩存熱數據(經常需要訪問的數據)，這是數據訪問的最後一步(它首先返回數據給用戶，然後根據用戶的設置為下一次的訪問緩存這些數據)。
注意
閃存(硬件/芯片)不同於數據庫閃存。您可以在Oracle Database 11g和Oracle RAC 11g中使用數據庫閃存。如果數據庫運行在Solaris或者Oracle Linux操作系統上，那麼您可以在線添加可選的數據庫閃存。這是一個基於文件擴展的常駐SGA緩沖區的高速緩存(類似於交換區)，為數據塊提供二級緩存。當數據庫被換出SGA時該文件被使用。如果希望了解更多信息，請參閱初始化參數DB_FLASH_CACHE_SIZE。
● 存儲索引(Storage Index)
存儲索引利用最小值/最大值使查詢運行得更快。使用存儲索引通常可以達到10倍的性能提升。它們主要維護數據(比如metadata)的摘要信息。內存結構駐留在存儲單元(cell)層面上。對於一個存儲單元而言，存儲索引最多可以儲存8個查詢表列的最小值/最大值。因此，存儲索引指示數據是如何存儲在存儲單元上的(就像分區的最小值/最大值)。查詢一個表時，數據庫會檢查存儲索引以確定為獲得所需要的數據都要訪問哪些存儲單元。Oracle根據不同列上的最小值/最大值搜索數據，在不匹配的情況下就消除在存儲單元上的I/O，該過程對用戶100%透明。它是在硬件層面上進行的，通常來說每1MB的磁盤就有一個索引條目。Oracle在內部自動完成這項工作而無需任何設置。存儲索引還可以為分布極為不均的數據提供巨大的好處。存儲索引提供了對高選擇性值的快速訪問，而對選擇性不高的值則通過常規的Exadata卸載來處理。
● 智能掃描(Smart Scan)
智能掃描是Oracle在內部硬件層面執行的。通常來說，可以節省10倍的開銷。Oracle基於WHERE子句(謂詞)進行過濾，過濾條件包括行、列或連接(Join)。智能掃描無需設置，Oracle在內部自動完成這項工作。
● 混合列壓縮(HybridColumnar Compression，HCC)
混合列壓縮，也被稱為Exadata混合列壓縮(EHCC)，是指數據由列行混合的格式組成，然後進行壓縮，性能可以提高10到30倍。表是由壓縮單位(Compression Unit，CU)組織起來的，其中包含約1000行數據(行的多少取決於這些行的數據量)。壓縮單元跨越多個數據塊。混合列壓縮對於批量加載數據來說非常有好處，但它不是為OLTP或單塊讀操作而構建的。它主要用於數據倉庫和被查詢的數據，而不是頻繁更新的數據。相比於Gzip/Bzip2，混合列壓縮通常是其兩倍的壓縮比和10倍的訪問效率。
● 企業管理器網格控制器
Oracle企業管理器網格控制器有個專門的Exadata插件，通過這個插件，您可以很容易地管理和查看Oracle提供給Exadata的許多特性。它還可以確保一切都正常和高效地工作(這部分在第5章以及第11章有介紹)
● 在企業管理器中模擬Exadata
可以在實施Exadata之前，讓您在當前運行的系統上模擬Exadata並檢查它可以帶來的好處。這個特性是SQL性能分析器的一部分，SQL性能分析器是Oracle真正應用測試(Real Application Test，RAT)的一個組件。這個選件需要額外購買。
● I/O資源管理器
Oracle最新的I/O資源管理(IORM)工具可以讓Exadata管理多個工作負載，並為每個真正必需的數據庫、用戶或任務設置資源。IORM給您通過一台機器輕松管理許多系統的能力。
● 安全性
帶修改跟蹤文件的安全加密備份要快得多了，存儲節點還對其提供了解密的硬件加速：Exadata利用CPU在硬件層面加速AES-NI的解密過程，所以即便在使用TDE表空間或列的加密時，您也可以加密和解密(加密的數據在使用智能掃描前解密)。
● 工具
Cellcli是一個查詢硬件層面的命令行接口，可用於監控單個存儲單元上各種各樣的健康指標；DCLI用於查詢多個存儲單元上的信息，ADR命令行解釋工具(ADRCI Command Interpreter)用於診斷。
許多最佳實踐將有助於您充分利用Exadata。我先從一個必須做的和不能做的清單開始，然後列出一些最佳實踐！請注意，這些可能隨時更改(檢查Oracle的官方文檔以獲取最新的信息)。
● 必須安裝Bundle Patch 5(參考MOS文獻：888828.1以獲取最新的補丁)。
● 必須使用ASM(自動存儲管理)；ASM為Exadata提供文件系統和卷管理器。
● 數據中心必須配備符合要求的制冷系統！這是非常重要的(我建議做一些這方面的研究)。
● 必須在支起的地板之上鋪三層打了洞(冷卻的原因)的瓷磚來承載整個機架(必須能承受2219磅/964公斤)，前後端之間的通風量要在1560CFM和2200 CFM[1]之間，不這樣做就可能會熱到要融掉！所有這一切都可能會改變，所以請檢查最新的規格需求。
● 必須有合格的電力保障。
● 必須安裝Oracle Linux 5.3(x86_64)和Oracle Database 11.2(目前推薦)。
● 必須使用RMAN進行備份。
● 考慮使用StorageTek SL500磁帶備份(評價很不錯，但價格偏貴)。
● 不要添加任何外來的硬件……不支持！
● 不要更改BIOS/驅動……不支持！
下面是一些其他的最佳實踐：
● 使用4MB大小的ASM分配單元(Allocation Unit，AU)(目前推薦)。
● 創建Celldisk和Griddisks時使用“CREATE ALL”。
● 使用DCLI一次性在所有存儲服務器上執行命令(有用而且節省時間)。
● 使用IORM管理資源。
● 安裝之前確定您的快速恢復區(Fast Recovery Area，FRA)和MAA需求。
● 數據庫使用11.2.0.1以上版本(11.2.1.3.1)和ASM的11.2.0.1以上版本(目前最低要求)。
● 必須兼容11.2.0.1以上版本(目前最低要求)。
● 使用32GB大小的日志文件。
● 使用本地管理表空間(Locally Managed Tablespace，LMT)和4MB的統一大小區(Extent)。
● 使用數據泵移動數據(通常使用這個工具，您也可以有很多其他選擇)。
● 使用默認的初始化參數啟動，根據您的工作負載在需要的時候再調整。
本書寫作的時候，下面提到的數據庫機器已經就位，截止2011年6月Oracle已經賣出了第1 000台Exadata機器。現在的Exadata機器提供了150萬閃存IOPS(每秒的I/O)。您讀到這段文字的時候，這個數字一定又刷新了。正如加速了軟件世界那樣，Oracle正在加快它們的硬件世界。如果Oracle繼續這種加速的話，廣受歡迎的電影“鋼鐵俠”中的世界可能並不像想象的那麼遙遠。在影片中，鋼鐵俠甚至“訪問Oracle網格”。不知您注意到了沒有，拉裡·埃利森也出現在電影中。軟硬一體的工程正在改變游戲規則！
第2版(X2-2)Exadata機器由Oracle公司(Sun)獨家制造，它包括：
● 8台計算服務器(型號4170 M2)
? 8台服務器×2 CPU/服務器×6核/CPU=96核
? 8台服務器×4個磁盤/服務器×300GB(1萬轉/分鐘)/磁盤(服務器端總共9.6TB的SAS存儲空間)
● 8台計算服務器×96GB內存/服務器=768GB內存
● 3台InfiniBand交換機(40 Gb /秒)×36端口/交換機=108端口
● 14台存儲服務器，共有168個CPU核和閃存：
? 96GB閃存卡×4=384GB閃存/存儲服務器
? 14台存儲服務器×384GB/存儲服務器=5.376TB閃存
? 12磁盤/存儲服務器×14存儲服務器=168磁盤
? 168磁盤×600GB/SAS盤=101TB SAS存儲空間(15 000轉/分鐘)或
? 168磁盤×2TB/SATA盤=336TB SATA存儲空間(7 200轉/分鐘)
● 數據加載速率12TB每小時
第2版(X2-8)Exadata機器由Oracle公司(Sun)獨家制造，它包括：
● 兩台計算服務器(2.26GHz的Intel 7560 CPU和總共約5TB的SAS存儲空間)：
? 兩台服務器×8 CPU/服務器×8核/CPU=128核
? 兩台服務器×8個磁盤/服務器×300GB(1萬轉/分鐘)/磁盤(服務器端總共4.8TB的SAS存儲空間)
● 兩台計算服務器×1TB內存/服務器=2TB內存
● 3台InfiniBand交換機(40 Gb /秒)×36端口/交換機=108端口
● 14台存儲服務器，共有168 個CPU核和閃存：
? 96GB閃存卡×4=384GB閃存/存儲服務器
? 14台存儲服務器×384GB/存儲服務器=5.376TB閃存
? 12磁盤/存儲服務器×14存儲服務器=168磁盤
? 168磁盤×600GB/SAS盤=101TB的SAS存儲空間(15 000轉/分鐘)或
? 168磁盤×2TB/SATA盤=336TB的SATA存儲空間(7 200轉/分鐘)
在2011年7月，Oracle增加了Exadata存儲擴展櫃，它通過InfiniBand與X2-2和X2-8相連接，使其存儲容量得到擴充。它具有額外的18台存儲服務器與216個CPU核；6.75TB閃存(約190萬IOPS的閃存)；216塊具有2TB容量的7200轉/分鐘SAS磁盤(432TB的原始磁盤空間，大約194TB鏡像的非壓縮可用容量)。使用這個作為磁盤備份，讓您可以獲得大概27TB/小時的速度。同時發布的還有Exalytics商務智能機，專為小企業設計的Oracle Data Appliance和擁有全新T4處理器(第11章中討論)的SPARC SuperCluster。硬件世界的范式轉變才剛剛開始！
以下是一些關於ExalogicElastic Cloud的簡要信息，這是面向互聯網上的應用程序(也包括一些其他中間件軟件)並使之運行更快的機器(亞馬遜、Facebook、谷歌、Twitter、雅虎、蘋果、Salesforce.com、eBay和其他一些電子商務玩家如果還沒有買的話，他們都應該買一兩台！)。
一台ExalogicElastic Cloud(X2-2)包括了(處理每秒100萬次的HTTP請求)：
● EL X2-2 30台計算服務器，360個CPU核，2.9TB的內存，4TB的SSD讀緩存，40TB的SAS硬盤。將使融合應用程序快到冒煙！
● 100萬HTTP/每秒，我聽說兩台這樣的設備就可以支撐整個Facebook，雖然Facebook有超過5億的用戶(參考最近關於Exalogic的廣告)。
這裡總結了Exadata速度快的原因： 快速的硬件、充足的CPU、快速的閃存、數據庫服務器和存儲上大量的內存、壓縮(性能提高10到70倍)、分區剪裁(PartitionPruning，性能提高10到100倍)、存儲索引(性能提高5到10倍)、智能掃描(性能提高4到10倍)以及其他沒有涵蓋的特性(請參閱Oracle文檔以獲得更多信息)。Exadata是可以將1TB的搜索轉成500MB甚至50MB搜索的最好方式。我相信，Exadata是超劃算的買賣，它將推動所有主流的硬件廠商加速硬件創新。它真是快到要爆了！
Oracle 11g中引入了名為“高級壓縮”的新特性，向不同的組織機構承諾數據庫表將占用更少的空間，相當於數據庫變小了。較小的數據庫占用較少的磁盤空間，也相當於較低的數據庫磁盤存儲的成本。隨著數據庫的規模以驚人的速度持續增長，能增加單位GB的存儲容量確實非常令人振奮。除此之外，也有潛在的性能優勢來自於大量的讀操作，比如全表掃描。Oracle只需要更少的物理塊讀操作就可以完成全表掃描；利用壓縮的數據塊使得更多的數據可以存儲在SGA中，這同樣可以潛在地節省高速緩沖區內存。
Oracle在8i版本中首次引入了對索引鍵的壓縮，然後在9i版本中加入了壓縮表。Oracle 9i的表壓縮是受限的，因為壓縮只能通過創建操作實現，比如CREATE TABLE AS SELECT，也就是直接加載或以追加方式插入。這種壓縮適合初始數據加載，但隨著時間的推移，表需要重新組織然後重新壓縮，這就需要維護和停機時間來維持壓縮。隨著數據庫表高可用性壓力的增加，壓縮不再適合正常的OLTP系統，因為大多數數據不是直接加載。Oracle引進的高級壓縮改變了這一切，允許數據在更新和插入表的時候保持壓縮，比如下面的CREATE TABLE所示：
create table emp_compressed
(EMPNO NUMBER(4),
ENAME VARCHAR2(10),
JOB VARCHAR2(9),
MGR NUMBER(4),
HIREDATE DATE,
SAL NUMBER(7,2),
COMM NUMBER(7,2),
DEPTNO NUMBER(2))
COMPRESS FOR OLTP;
請注意以下高級壓縮設置：
● NOCOMPRESS：表或分區不會被壓縮。這是默認動作。
● COMPRESS：適用於數據倉庫。只在直接路徑插入時啟用壓縮。
● COMPRESS FOR DIRECT_LOADOPERATIONS：同COMPRESS效果一樣。
● COMPRESS FOR ALL OPERATIONS：適合OLTP系統。所有操作，包括常規的DML語句都啟用壓縮。兼容參數COMPATIBLE需要設置為11.1.0或更高。
● COMPRESS FOR OLTP：適合OLTP系統。所有操作，包括常規的DML語句都啟用壓縮。兼容參數COMPATIBLE需要設置為11.1.0或更高。在11.2中已取代COMPRESS FOR ALL OPERATIONS 語法，但COMPRESS FOR ALL OPERATIONS語法仍然存在而且有效。
Oracle 11g中引入了自動診斷信息庫(ADR)，它提供了一個統一而且一致的機制來存儲、格式化並定位所有的數據庫診斷信息(易於使用的文件結構)。ADR關聯各種組件(比如Oracle RAC、Oracle Clusterware、OCI、Net、進程等)的錯誤，並自動為嚴重的錯誤生成事故和提供事故管理功能。ADR可以顯著減少解決事故和問題的時間。
通常在使用傳統的初始化參數的時候，比如BACKGROUND_DUMP_DEST、CORE_DUMP_ DEST和USER_DUMP_DEST等，如果想讓清理文件的過程自動進行，就必須使用自定義過程去手動清理。用ADR和ADR的命令行界面(ADRCI)，您可以設置控制這些文件保存時間的策略：
adrci> set control (SHORTP_POLICY =360 )
adrci> set control(LONGP_POLICY = 4380 )
如表1-1中所示，使用ADR時，傳統的CORE_DUMP_DEST、BACKGROUND_DUMP_DEST和USER_DUMP_DEST位置改變為DIAGNOSTIC_DEST。因此，如果指定了參數DIAGNOSTIC_DEST，由原來的參數設置的位置將被忽略。
表1-1 使用ADR時的位置變化
原 始 位 置
新 位 置
CORE_DUMP_DEST
DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/cdump
BACKGROUND_DUMP_DEST
(Alert Log text)
(Alert Log XML)
DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/trace
DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/alert
BACKGROUND_DUMP_DEST
DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/trace
USER_DUMP_DEST
DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/< INSTANCENAME >/trace
如下是ADR文件位置的縮略列表：
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/trace
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/alert
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/cdump
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/incident
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/hm
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/incpkg
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/ir
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/lck
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/metadata
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/sweep
● DIAGNOSTIC_DEST/diag/rdbms/<DBNAME>/<INSTANCENAME>/stage
● ** 默認情況下，DIAGNOSTIC_DEST 的位置是 $ORACLE_HOME/log
然而，如果在環境變量中設置了ORACLE_BASE，那麼DIAGNOSTIC_DEST就會被設置為$ORACLE_BASE。請參考第4章以獲得關於這個主題的更多信息和如何設置初始化參數。
Oracle 9i實現了用PGA管理SORT_AREA_SIZE、HASH_AREA_SIZE、位圖合並區和創建位圖區域。Oracle 10g邁出了走向自動內存管理的第一步，那就是通過SGA內存管理來管理共享池(Shared Pool)、大型池(Large Pool)、Java 池和緩沖區緩存(Buffer Cache)。Oracle11g進一步改進了自動共享內存管理，使得可以自動管理SGA和PGA。為了使用自動內存管理(Automatic Memory Management，AMM)來管理SGA和PGA，Oracle公司推出了兩個新的數據庫參數：MEMORY_TARGET和MEMORY_MAX_TARGET。
那麼Oracle是如何處理之前的自動內存管理參數的呢？當設置了MEMORY_TARGET之後，SGA_TARGET和PGA_AGGREGATE_TARGET只會被用來表示最低內存設置。為了允許Oracle管理內存有最大的靈活性，您可以設置SGA_TARGET和PGA_AGGREGATE_TARGET為0(不建議使用，我建議給它們設置最小值)。
下面是一些重要注意事項：
● Linux Huge Pages和MEMORY_TARGET參數是不兼容的。更多細節可參見MOS文獻749851.1以了解進一步的細節。
● MEMORY_TARGET的值要小於操作系統共享內存文件系統(/dev/shm)。在Oracle Linux系統中，數據庫啟動時，/dev/shm的空閒空間必須大於MEMORY_TARGET的設置，否則會得到“ORA-00845：MEMORY_TARGETnot support on this system”的錯誤。
● 如果LOCK_SGA數據庫初始化參數設置為true，您就不能使用參數MEMORY_TARGET來啟用自動內存管理。
請參考第4章以獲取關於這個主題的更多信息和如何設置初始化參數。
Oracle 11g大大改善了Oracle ASM的可擴展性、可用性、性能和文件管理功能。Oracle 11g中ASM的改進包括減少了數據庫的啟動時間和內存要求、允許支持更大ASM的文件和提供了在ASM上實現幾百TB級或PB級(1PB=1000TB)數據庫的能力。為了提高可擴展性，ASM增加了支持超大規模數據文件大小的能力。Oracle數據庫限制單一的數據文件大小是128TB(當DB_BLOCK_SIZE = 32K時)，這遠遠小於新的ASM文件大小限制。
以下是新的ASM限制：
● 在Exadata環境下支持最大40 EB存儲(不在Exadata環境下最大是20 PB)。
● 在Exadata環境下每個ASM磁盤最大4PB(不在Exadata環境下最大是2TB)。
● 最大支持每個磁盤組100萬個文件。
● 最大支持一萬個ASM磁盤。
● 每個ASM實例最大支持63個磁盤組。
● 當設置AU_SIZE=1M和COMPATIBLE.RDBMS=> 11.1時磁盤組支持的最大文件大小：
? 外部冗余：140PB
? 正常冗余：23PB
? 高冗余：15PB
注意
當使用大文件(bigfile)表空間時，Oracle數據庫的最大大小是65533(數據文件的最大數量)×128TB(64位操作系統上數據文件的最大大小) = 8EB(如果是小文件(small file)表空間，最大數據庫大小則是8PB)。64位操作系統支持的最大內存尋址空間是16EB(大約18後面有18個0的字節)。這樣將來您就可以使這8EB的數據庫常駐內存，另外還有8EB的空閒內存！
其他關於大小的注意事項包括：
● 可變大小的區(Extent)：可以支持更大的ASM文件，為超大規模數據庫(VLDB)減少SGA內存的需求，並提高文件創建和打開的性能。
● 分配單元(AU)：可以分配給文件的磁盤最小單位，分配單元的大小可以是1MB、2MB、4MB、8MB、16MB、32MB和64MB；默認是1MB大小。
● 條帶化：粗的條帶大小為1個分配單元(AU)，細的條帶大小為128KB。
● 較大的分配單位：為了支持較大的連續讀和寫，較大的分配單元(AU)可以帶來顯著的性能提升。
● 區大小：在11.1中，ASM的文件可以從1MB的區大小開始。假設用1MB大小的分配單元的話，然後隨著ASM文件的增長，根據預定的區數逐步增加8倍到8MB和64MB。在11.2中，文件的擴展大小是變化的，具體如下：
? 在前20 000(0到19 999)個區時，區大小始終等於磁盤組的分配單元(AU)大小。
? 在接下來的20 000(20 000到39 999)個區時，區大小等於4倍的分配單元(AU)大小。
? 在接下來的20 000和更大(40000+)的區范圍時，區大小等於16倍的分配單元(AU)大小。
● MAXIO緩沖區大小：增加MAXIO緩沖區大小到4MB並且創建擁有4MB分配單元(AU)大小的磁盤組有益於大量連續讀I/O的性能提升。
在Oracle 11g中，當使用Oracle ASM來管理冗余時，一台主機上的ASM實例可以配置為從“首選鏡像”上讀取副本；默認是從主組中讀取。當ASM的FailGroup位於不同位置的時候，這為Oracle RAC環境提供了極大的好處。假如ASM的FailGroup和主組位於不同的位置，RAC實例可以配置為從本地的鏡像副本讀取數據，而不是從遠程的主組讀取，從而消除了潛在的網絡延遲。ASM的首選鏡像讀取通過每個ASM實例的控制初始化參數ASM_PREFERRED_READ_ FAILURE_GROUPS來控制。例如，您有兩個站點分別叫做site1和site2，ASM磁盤組DATA1有兩個FailGroup分別命名為SITE1和SITE2(請在使用之前閱讀相應的Oracle文檔)：
對於site1：
ASM_PREFERRED_READ_FAILURE_GROUP=DATA1.SITE1
對於site2：
ASM_PREFERRED_READ_FAILURE_GROUP=DATA1.SITE2
為了提高可用性，Oracle 11g在Oracle RAC環境下的ASM實例具備了滾動升級的能力，這是通過把ASM實例打開到“滾動遷移”模式來完成的。滾動遷移模式允許ASM實例暫時在多版本的ASM環境下工作。建議在開始ASM滾動升級前，先完成在集群上所有Oracle軟件的安裝以使滾動升級的時間最短，因為大多數的ASM操作在ASM實例滾動升級過程中都是不允許的(請在使用之前全面閱讀相應的Oracle文檔)。
開始滾動升級：
ALTER SYSTEM START ROLLING MIGRATION TO <ver_number>;
如果在滾動升級中遇到問題，就停止升級或降級：
ALTER SYSTEM STOP ROLLING MIGRATION;
Oracle 11g改進了ASM重新平衡操作的性能，從而顯著降低了磁盤由於各種瞬時故障而導致脫機的時間，這些故障的原因包括電纜松動、停電、總線適配器或磁盤控制器故障等。ASM將在停運期間跟蹤被修改的盤區。一旦暫時的故障被修復，並且如果磁盤上的內容未被修改過，ASM就可以迅速重新同步停電期間沒來得及修改的ASM鏡像盤區。這使得磁盤可以重新聯機並同步的操作比以前快幾小時甚至幾天。
新的DISK_REPAIR_TIME屬性允許定義一個時間窗口，在該時間窗內可以進行故障維修或同步的操作，鏡像磁盤也可以在該時間窗內重新上線。DISK_REPAIR_TIME默認為3.6小時，但針對磁盤組可以通過ALTERDISKGROUP命令進行修改(請在使用前閱讀相應的Oracle文檔)：
ALTER DISKGROUP <DiskGroupName> SETATTRIBUTE 'DISK_REPAIR_TIME'= '24H';
您可以通過下面的命令重新聯機全部的磁盤組(可以把ALL替換成DISK <diskname>來針對單獨的磁盤組)，並開始重新同步的過程：
ALTER DISKGROUP DISK ONLINE ALL;
注意
Oracle11g允許磁盤組被掛載在限制模式下，從而消除多個ASM實例之間在重新平衡操作時所需要的鎖定和解鎖消息。這大大提高了RAC環境下重新平衡操作的性能。這裡是一系列您可能會用到命令的示例：
ALTER DISKGROUP <diskgroup> DISMOUNT ；
ALTER DISGROUP <diskgroup> MOUNT RESTRICTED ；
執行維護活動(重新平衡/添加/刪除/聯機/脫機磁盤等)：
ALTER DISKGROUP <diskgroup> DISMOUNT ；
ALTER DISKGROUP <diskgroup> MOUNT ；
CREATE DISKGROUP DATA1 NORMAL REDUNDANCY DISK '/dev/raw/raw1', '/dev/raw/raw2' ATTRIBUTE 'compatibile.asm'='11.1' ; ALTER DISKGROUP DATA1 SET ATTRIBUTE 'compatible.rdbms'='11.1' ; select group_number GN, name, compatibility COMPAT, database_compatibility DCOMPAT from v$asm_diskgroup; GN NAME COMPAT DCOMPAT -- ---- ---------- ---------- 1 DG1 11.1.0.0.0 11.1.0.0.0 2 DG2 10.1.0.0.0 10.1.0.0.0
為了更好地管理ASM磁盤組，Oracle 11g在ASMCMD工具裡增加了很多新的命令，下面列出了其中一部分：
● CP：在ASM磁盤組和操作系統文件系統之間復制文件。
ASMCD> cp +ASM1/system.dbf/backups/orcl/system.dbf
● MD_BACKUP：備份磁盤組元數據。
ASMCMD> md_backup –b/backups/orcl/asmbackupfile.md -g ASM1
● MD_RESTORE：恢復磁盤組元數據。
ASMCMD> md_restore –b/backups/orcl/asmbackupfile.md –tfull –g ASM1
● LSDSK：列出磁盤信息。
ASMCMD> lsdsk
● REMAP：在指定的那些數據塊上進行壞塊的重映射。
ASMCMD> remap <diskgroup name> <disk name> <blockrange>
● SYSASMprivileges：為ASM指定新的角色，比如SYSDBA。
SQL> GRANT SYSASM TO<username> ；
SQL> CONNECT<username> AS SYSASM ；
Oracle 11g引入了自動SQL優化。這本書的許多章節都詳細涵蓋了這個主題，因此本節只作概述。Oracle11g根據AWR(AutomaticWorkload Repository，自動負載信息庫)的統計信息針對產生較大性能影響的SQL語句運行SQL 優化顧問(SQL Tuning Advisor)。AWR的統計信息用來生成一個SQL語句列表並根據它們過去一周對系統性能的影響進行排序，這個SQL列表會自動排除所有被斷定為不太容易優化的SQL語句，比如並行查詢、DML、DDL和任何由並發問題引起的性能問題。SQL優化顧問生成優化SQL的建議，這類建議中可能有SQL配置文件(Profile)(利用統計信息)。當建議使用SQL配置文件的時候，這些配置文件會進行性能測試，如果測試結果顯示至少有三倍的改進，並且SQL優化任務參數ACCEPT_SQL_PROFILES設置為true，這個建議就會被接受；如果ACCEPT_SQL_PROFILES被設置為false，這個建議會被報告。您也可以針對任何查詢單獨執行這些步驟。
通過調用dbms_auto_task_admin程序包的enable和disable過程就可以控制自動SQL優化任務的執行。當啟用時，SQL 優化顧問就在定義好的維護時間窗口裡運行，默認的維護時間窗口參考下面的表1-2。
表1-2 Oracle 11g默認維護窗口
窗 口 名 稱
描 述
MONDAY_WINDOW
星期一晚上10點開始到第二天臨晨2點
TUESDAY_WINDOW
星期二晚上10點開始到第二天臨晨2點
WEDNESDAY_WINDOW
星期三晚上10點開始到第二天臨晨2點
THURSDAY_WINDOW
星期四晚上10點開始到第二天臨晨2點
FRIDAY_WINDOW
星期五晚上10點開始到第二天臨晨2點
SATURDAY_WINDOW
星期六晚上10點開始並持續20小時
SUNDAY_WINDOW
星期日晚上10點開始並持續20小時
啟用和禁用自動SQL優化：
exec dbms_auto_task_admin.enable(client_name => 'sql tuning advisor',operation => NULL, window_name => NULL); exec dbms_auto_task_admin.disable(client_name => 'sql tuning advisor', operation => NULL,window_name => NULL);
配置自動SQL優化：
exec dbms_sqltune.set_tuning_task_parameter (task_name => 'SYS_AUTO_SQL_TUNING_TASK', parameter => 'ACCEPT_SQL_PROFILES', value => 'TRUE');
以下是控制自動SQL優化任務的dbms_sqltune選項：
● INTERRUPT_TUNING_TASK：中斷正在執行的任務，得到中間結果並正常退出。
● RESUME_TUNING_TASK：恢復先前被中斷的任務。
● CANCEL_TUNING_TASK：取消正在執行的任務，清除任務的所有結果。
● RESET_TUNING_TASK：重置正在執行的任務，清除任務的所有結果並返回到其初始狀態。
● DROP_TUNING_TASK：刪除一個任務，清除所有與該任務相關的結果。
第5章將展示如何在企業管理器中通過簡單的“點擊運行”來使用自動SQL優化功能。
Oracle 11g中改進了Oracle數據衛士的一些特性，以提高其能力和可用性。以下各節詳細介紹了這些改進。
通過Oracle 11g的新特性快照備用，您現在可以暫時打開一個物理備用數據庫，用於做讀/寫活動，比如報表和負載測試。以讀/寫方式打開的物理備用數據庫仍然接收從主數據庫發來的重做數據，因此它持續地對主要故障提供保護，同時可使自身被用於其他的活動。因為可以服務於企業的其他用途，維護成本核算，物理備用數據庫的價值就得到了提升。請記住，快照備用數據庫從主數據庫接收和歸檔重做數據，但並不在備用數據庫上應用，直到快照備用數據庫轉換回物理備用數據庫。
Oracle 11g也提升了主數據庫和備用數據庫之間角色轉換的速度。
活動數據衛士是Oracle Database 11g版本中為物理備用數據庫引入的一個可選功能。這一可選功能需要支付Oracle公司額外的授權費用；因此，在您的環境中實施這個功能之前，您必須獲得許可。此功能允許物理備用數據庫在只讀模式的同時應用重做日志以保證物理備用數據庫持續跟主數據庫保持一致。主數據庫和物理備用數據庫都必須把數據庫兼容初始化參數設置為11.0(也就是11g兼容模式)。請注意Oracle活動數據衛士需要單獨的許可並且只能用於Oracle數據庫企業版。您可以通過Oracle數據庫企業版的活動數據衛士選件來購買它。它也包含在Oracle GoldenGate產品中。
在11gR2中，通過查詢V$STANDBY_EVENT_HISTOGRAM視圖可得到延遲的歷史，Oracle 以此改進了活動數據衛士(見示例查詢)：
select * from v$standby_event_histogram where name = 'APPLY LAG';
此外，11gR2增加了一個數據庫初始化參數，用來設置備用數據庫可以在滯後多久後，在它上面的查詢活動就需要被控制。在活動數據衛士啟用的時候，對於物理備用數據庫上非管理員用戶執行的查詢，您可以使用STANDBY_MAX_DATA_DELAY參數來指定特定會話的應用可以允許的滯後，這個參數以秒為單位。這個功能允許查詢安全地把對主數據庫的資源消耗卸載到物理備用數據庫上，因為在查詢執行之前就可以知道備用數據庫是否已經過時到不可接受。STANDBY_MAX_DATA_DELAY默認值是NONE，這意味著無論是否存在應用滯後，在物理備用數據庫上發出的查詢都將被執行。其他有效的值是一個大於 0的整型值(表示容忍的滯後秒數)。值為0表示對物理備用數據庫發出的所有查詢都將返回和對主數據庫查詢相同的結果，而值大於0表示對物理備用數據庫發出的查詢只有在應用滯後小於或等於STANDBY_MAX_DATA_DELAY (否則就會返回ORA-3172錯誤，表示應用滯後太久)時才被執行。下面列出幾個有用的查詢。
要檢查物理備用數據庫的狀態，以確保該數據庫的角色是物理備用數據庫並且打開模式是只讀，可以運行下面的查詢來確認。需要注意的是11gR2將顯示打開模式為“read only with apply”。
select db_unique_name, database_role, open_mode from v$database; DB_UNIQUE_NAME DATABASE_ROLE OPEN_MODE ------------------------------ ---------------- ---------- TESTSB PHYSICAL STANDBY READ ONLY
要檢查物理備用數據庫滯後主數據庫的時間，可以運行下面的語句：
SELECT name, value, unit, time_computed, to_char(sysdate, 'DD-MON-YY HH24:MI:ss') FROM V$DATAGUARD_STATS WHERE name like 'apply lag'; NAME VALUE UNIT TIME_COMPUTED TO_CHAR(SYSDATE,'D ---------------------------------------------------------------- apply lag +00 00:00:00 day(2) to second(0) interval 20-MAY-2009 19:04:17 20-MAY-09 19:04:44
Oracle 11g增加的一個擴展功能是物理備用數據庫可以跟主數據庫位於不同的操作系統。Oracle11g現在允許Linux跟Windows的組合，同樣也支持Solaris/IBM AIX的組合(參考bug 12702521以查看11.2.0.2版本中額外的限制)。而其他平台的組合在10g時就已經支持，所以這是第一次完整地支持異構操作系統。
注意
如果要查詢所支持平台/操作系統組合的完整列表，請參閱MOS文獻413484.1。如果要查看更多的限制和細節，請參考MOS文獻395982.1和414043.1。
Oracle Database11gR1引入了高級壓縮，但是高級壓縮不能用於流或邏輯備用數據庫的對象。在11gR2中，高級壓縮可以支持流和邏輯備用數據庫了。
Oracle 11g中的透明數據加密支持邏輯備用數據庫。SQL Apply也支持使用透明數據加密，這進一步增強了邏輯備用數據庫的功能和利用率。
Oracle 10g的數據泵可以通過設置參數COMPRESSION為METADATA_ONLY來壓縮數據泵導出來的元數據(這可以使產生的Dump文件的大小最大縮小15%)。在11g中，數據泵不僅可以壓縮數據泵的元數據，還可以壓縮數據庫中的數據。壓縮通過為元數據、列數據或整個Dump文件集指定不同COMPRESSION參數值來實現，有效的參數值包括ALL、METADATA_ONLY、DATA_ONLY和NONE。
Oracle 11g的數據泵可以加密Dump文件，可以對Dump文件中的元數據和數據庫數據進行加密。Oracle 11g的數據泵增加了新的參數以控制加密：
● ENCRYPTION：設置Dump文件或Dump文件集的加密；有效值是ALL、DATA_ONLY、METADATA_ONLY、ENCRYPTED_COLUMNS_ONLY或NONE。
● ENCRYPTION_ALGORITHM：設置Dump文件或Dump文件集的加密算法；有效值是AES128、AES192和AES256。
● ENCRYPTION_MODE：為Dump文件或Dump文件集生成加密密鑰的方法；有效值是DUAL、PASSWORD和TRANSPARENT。
我強烈建議在您的系統中考慮多層次的加密。您應該制定一個全面的安全計劃，包括在每一個需要的層次加密(特別是加密您的備份)。安全性的話題超出了本書的范圍，但應該是需要優先考慮的！
在11gR2中，數據泵有個傳統模式。該傳統模式兼容由原來的導出和導入工具創建的腳本和參數文件，使用原來的導出和導入工具的用戶和進程可以借助新的數據泵導出和導入工具繼續工作，而無需改變和/或更新。此增強功能簡化了用戶遷移到新的數據泵工具的過程。
Oracle 11g在以下幾個方面改善了統計信息：增強的I/O統計信息、分區對象的統計信息收集、待定統計信息、多列統計信息和表達式統計信息。
Oracle 11g從消費組(Consumer Group)、數據庫文件和數據庫功能三個方面收集所有I/O調用的統計信息。當資源管理器啟用時，作為啟動的資源計劃的一部分，每個針對消費組的I/O統計信息就會被收集起來。這些統計數據可以通過視圖V$IOSTAT_CONSUMER_GROUP來查看。數據庫文件的統計信息在這些文件被訪問的時候就已經被收集了。這些統計信息表明了大和小的讀和寫的請求、服務時間和小的讀延遲。
它們可以通過字典視圖V$IOSTAT_FILE來查看。數據庫功能的I/O統計信息基於數據庫的功能，比如LGWR、DBWR進程，並指示了大和小的讀和寫的請求、等待數量和等待時間。它們通過字典視圖V$IOSTAT_FUNCTION來查看。
Oracle 11g可以配置針對分區對象的增強統計信息收集，僅收集有寫活動的分區，從而去除了沒有改變的分區對象上的統計信息收集。這提高了針對大的分區對象統計信息收集的速度，因為有些分區只包含靜態數據。
Oracle 11g有一個新的特性，稱為待定統計信息。這個特性可以使新收集的統計數據保持在掛起狀態，直到決定發布它們為止。默認條件下，統計信息在收集操作完成的時候自動發布。待定統計信息是通過dbms_stats程序包和OPTIMIZER_USE_PENDING_STATISTICS這個數據庫初始化參數來控制的。
查看待定統計信息設置：
SQL> SELECT dbms_stats.GET_PREFS('PUBLISH')PUBLISH FROM DUAL;
設置自動發布全局待定統計信息(默認)：
SQL> exec dbms_stats.SET_GLOBAL_PREFS('PUBLISH', 'TRUE');
設置不自動發布全局待定統計信息：
SQL> exec dbms_stats.SET_GLOBAL_PREFS('PUBLISH', 'FALSE') ;
待定統計信息的一個很大特性是未發布的統計信息可以通過設置初始化參數OPTIMIZER_USE_PENDING_STATISTICS在發布之前進行測試。此參數可以在系統級別或會話級別進行設置，當在會話級別使用時，優化器統計信息可以在發布之前在會話級別進行測試：
SQL> alter session setOPTIMIZER_USE_PENDING_STATISTICS=TRUE;
Oracle 11g中引入了多列統計信息，當單表的多個列在一條SQL語句的WHERE子句中使用時，多列統計信息是一個強大的特性。優化器確定兩列之間的關系，把它們被當作一個列組。例如，在某個特定季節出售的物品(冬季大衣和泳衣)和季節(冬天和夏天)之間有一個關系。Oracle11g會自動根據對工作負載的分析來收集多列統計信息，和收集直方圖的方法類似，但也可以使用dbms_stats程序包手動創建：
exec dbms_stats.gather_table_stats('SCOTT', 'EMP', method_opt => 'for columns
(job,deptno)');
可以使用視圖DBA_STAT_EXTENSIONS、ALL_STAT_EXTENSIONS或USER_STAT_EXTENSIONS來查詢設置。
Oracle 11g的表達式統計信息幫助基於成本的優化器，基於列的選擇性得知在列上應用函數的影響。優化器可以在列上使用函數時做出更好的決策，因為它能夠更好地預測返回的行數。
exec dbms_stats.gather_table_stats('SCOTT', 'EMP', method_opt => 'for columns
(upper(ename))');
可以使用視圖DBA_STAT_EXTENSIONS、ALL__STAT_EXTENSIONS或USER_STAT_ EXTENSIONS來查詢設置。
閃回數據歸檔是Oracle Database 11g強大的新特性之一。它可以用安全有效的方式透明地跟蹤在數據庫中存儲的所有數據，並且沒有保留期限的限制。這個特性很容易配置，而且擁有高效的存儲以及性能。閃回數據歸檔不依賴於UNDO，通過“AS OF”閃回SQL語句來查看之前在某個時間點的數據，防止意外的數據更新和刪除(例如用戶的錯誤操作)或惡意的數據破壞(例如黑客入侵)。
閃回數據歸檔需要閃回數據歸檔表空間來存放，它通過新的閃回數據歸檔後台進程來收集數據。這個進程把閃回數據歸檔內容寫入閃回數據歸檔表空間。閃回數據歸檔針對每張表進行設置，啟用了閃回數據歸檔的表不可以做某些修改，比如使用了UPGRADE TABLE子句的ALTER TABLE語句、移動或交換分區/子分區和刪除表。雖然這聽起來可能是很不錯的保護功能，但是閃回數據歸檔不記錄做更改的人，因此它不會協助追查操作。追查操作是一個需要額外付費的新特性——Oracle全面回憶(TotalRecall)——的一部分。
以下是閃回數據存檔的例子(使用前請參閱Oracle文檔)。
創建一個閃回數據表空間，叫做fbda1：
create tablespace fbda1 datafile'c:\oracle\oradata\db\fbda1.dbf' size 500M;
創建一個閃回數據存檔：
create flashback archive default dbda1 tablespacefbda1 retention 1 year;
創建一個使用閃回數據存檔的表：
create table a (n number) flashback archive;
更改一個表以啟用閃回數據存檔：
alter table xyz flashback archive;
更改一個表以禁用閃回數據存檔：
alter table xyz no flashback archive;
使用AS OF閃回語句查詢一個表：
select * from a as of timestampto_timestamp('19-SEP-2008 11:59:32','dd-mon-yyyy
hh24:mi:ss') wheretable_name = 'EMP';
Oracle 11g中引入了免費的數據庫健康監控器，通過dbms_hm程序包來完成。健康監控器可以手動運行並檢查下列項目：
● DB結構完整性檢查
● 數據塊完整性檢查
● 重做日志完整性檢查
● UNDO段完整性檢查
● 事務完整性檢查
● 數據字典完整性檢查
使用dbms_hm程序包執行健康檢查：
SQL> exec dbms_hm.run_check ('Dictionary Integrity Check', 'HM_TEST') ;
PL/SQL procedure successfully completed.
使用dbms_hm程序包的get_run_report函數可以獲取健康檢查報告，使用PL/SQL函數通過返回CLOB對象來提取報告。下面這個例子演示了如何通過SQL Plus，使用PL/SQL腳本提取報告到文件中。
執行生成報告的例子：
$ sqlplus sysorcl11g as sysdba
SQL*Plus: Release 11.1.0.6.0 - Production on Thu Oct 2 09:08:55 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SET LONG 100000
SET LONGCHUNKSIZE 1000
SET PAGESIZE 1000
SET LINESIZE 512
select DBMS_HM.GET_RUN_REPORT('HM_TEST')
from dual;
下面是一個報告的例子：
Basic Run Information Run Name : HM_TEST Run Id : 966 Check Name : Dictionary Integrity Check Mode : MANUAL Status : COMPLETED Start Time : 2008-10-02 08:59:50.734000 -04:00 End Time : 2008-10-02 08:59:57.296000 -04:00 Error Encountered : 0 Source Incident Id : 0 Number of Incidents Created : 0 Input Parameters for the Run TABLE_NAME=ALL_CORE_TABLES CHECK_MASK=ALL Run Findings And Recommendations Finding Finding Name : Dictionary Inconsistency Finding ID : 967 Type : FAILURE Status : OPEN Priority : CRITICAL Message : SQL dictionary health check: dependency$.dobj# fk 126 on object DEPENDENCY$ failed Message : Damaged rowid is AAAABnAABAAAO2GAB3 - description: No further damage description available Finding Finding Name : Dictionary Inconsistency Finding ID : 970 Type : FAILURE Status : OPEN Priority : CRITICAL Message : SQL dictionary health check: dependency$.dobj# fk 126 on object DEPENDENCY$ failed Message : Damaged rowid is AAAABnAABAAAQtpABQ - description: No further damage description available
