Oracle的任何一個新版本，總是會帶來很多新特性，今天主要介紹oracle 11g中十個特性，通過這些特性來幫助我們加深對oracle11g版本的理解。

1.Adaptive direct path read - 自適應的直接路徑讀

在Oracle Database 11g中有一個新特性，全表掃描可以通過直接路徑讀的方式來執行（Direct Path Read），這是一個合理的變化，如果全表掃描的大量資料讀取是偶發性的，則直接路徑讀可以避免大量資料對於Buffer Cache的衝擊。可是現實往往是殘酷的：在很多業務系統中，全表掃描是普遍存在的常態，將大表的全表掃描全部轉化為直接路徑讀，反而不如Cache在Buffer Cache中效率高，Direct Path Read反而成為了一個嚴重的負擔。

當然對於小表來說，Oracle允許通過Buffer Cache來進行全表掃描，因為這可能更快，也對效能影響不大。小表受到隱含引數：_small_table_threshold 影響。如果表大於 5 倍的小表限制，則自動會使用DPR替代FTS。如果遇到這個特性的負面影響，可以設定初始化引數： _serial_direct_read 來禁用序列直接路徑讀，其預設值為AUTO，設定為NEVER時禁用 11g 的自動direct path read的特性。該引數可以動態在例項或會話級別修改，而無需重啟例項（可以結合Event 10949設定）。

SQL> alter system set "_serial_direct_read"=auto;
SQL> alter system set "_serial_direct_read"=never;
以下的AWR資訊是典型的DPR症狀，可以看到Direct Path Read在這個報告中處於最佔用DB Time的部分如果結合ASH報告更加一目瞭然，顯示全表掃描的SQL，都在以Direct Path Read的方式執行 Table Access Full：
關於 Log File Sync 等待的優化，在Oracle資料庫中一直是常見問題，LOG FILE的寫出效能一旦出現波動，該等待就可能十分突出。在Oracle 11.2.0.3 版本中，Oracle 將隱含引數 _use_adaptive_log_file_sync 的初始值設定為 TRUE，由此帶來了很多 Log File Sync 等待異常的情況，這個問題雖然由來已久，但是仍然有很多Oracle的使用者並不知情。

當前臺程序提交事務（commit）後，LGWR需要執行日誌寫出操作，而前臺程序因此進入 Log File Sync 等待週期。在以前版本中，LGWR 執行寫入操作完成後，會通知前臺程序，這也就是 Post/Wait 模式；在11gR2 中，為了優化這個過程，前臺程序通知LGWR寫之後，可以通過定時獲取的方式來查詢寫出進度，這被稱為 Poll 的模式，在11.2.0.3中，這個特性被預設開啟。這個引數的含義是：資料庫可以在自適應的在 post/wait 和 polling 模式間選擇和切換。

_use_adaptive_log_file_sync 引數的解釋就是： Adaptively switch between post/wait and polling ，正是由於這個原因，帶來了很多Bug，反而使得 Log File Sync 的等待異常的高，如果你在 11.2.0.3 版本中觀察到這樣的表徵，那就極有可能與此有關。在遇到問題是，通常將 _use_adaptive_log_file_sync 引數設定為 False，迴歸以前的模式，將會有助於問題的解決。

3. Adaptive Cursor Sharing - 自適應遊標共享Oracle資料庫的SQL使用的是共享機制，通過繫結變數可以使Oracle DB 可以為多條SQL 語句共享單個遊標，以減少分析SQL 語句所使用的共享記憶體和CPU資源等。

然而一個執行計劃並不總是適用於所有繫結值，為了儘可能生成準確的執行計劃，Oracle Database 11g 引入了自適應遊標共享的新特性，在執行共享SQL時考慮更多的因素，如果與資源開銷相比，使用多個執行計劃所帶來的收益更重要，則會為使用繫結變數的每條SQL 語句生成多個執行計劃。Adaptive Cursor Sharing 通過自適應遊標共享，可以僅針對使用繫結變數的語句智慧地共享遊標。但是有時候這個特性會使得確定的執行計劃變得不穩定，如果你確定系統中無需額外自適應的分析和變更執行計劃，或者可能被不穩定的執行計劃影響。那麼可能需要調整這個特性的使用。關閉這個特性，可以設定隱含引數：

SQL> alter session set"_optimizer_extended_cursor_sharing_rel"=none;
SQL> alter session set"_optimizer_extended_cursor_sharing"=none;
SQL> alter session set"_optimizer_adaptive_cursor_sharing"=false;
4.Oracle 11g 密碼延遲認證

在 Oracle 11g 中，為了提升安全性，Oracle 引入了『密碼延遲驗證』的新特性。這個特性的作用是，如果使用者輸入了錯誤的密碼嘗試登入，那麼隨著登入錯誤次數的增加，每次登入前驗證的時間也會增加，以此減緩可能對於資料庫重複的口令嘗試***。

但是對於正常的系統，由於口令的更改，可能存在某些被遺漏的客戶端，不斷重複嘗試，從而引起資料庫內部長時間的 Library Cache Lock的等待，這種情形非常常見。

如果遇到這一類問題，可以通過Event 28401關閉這個特性，從而消除此類影響，以下命令將修改設定在引數檔案中：

ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;
出現這類問題非常典型的AWR報告呈現如下，首先在 TOP 5 中，可能看到顯著的 Library Cache Lock 的等待，以下範例來自11.2.0.3.0版本的真實情況：

通過10大oracle特性來理解oracle 11g系統設計
在這類情況下，時間模型 - Time Model 中會顯示如下指標，其中 connection management call elapsed time 佔據了主要的DB Time，這個等待直接表明是在建立資料庫連線時產生的：

通過10大oracle特性來理解oracle 11g系統設計
這類問題，在Oracle的11g中是常見和確定的，在MOS上可以找到相應的記錄：High 'library cache lock' Wait Time Due to Invalid Login Attempts(1309738.1）此外Oracle 11g開啟了密碼大小寫驗證，如果從Oracle 10g升級過來，需要特別的當心這個變化，通過初始化引數SEC_CASE_SENSITIVE_LOGON 可以來控制這個特性。

5. _datafile_write_errors_crash_instance - 檔案寫錯誤終止例項

從Oracle 11.2.0.2版本開始，一個新的隱含引數 - _datafile_write_errors_crash_instance 被引入到資料庫中，通過這個引數名就可以瞭解到其含義：當發生資料檔案寫錯誤時，Crash資料庫例項。

為什麼要引入這個引數呢？這個引數後臺解決的是什麼問題呢？

在歸檔模式下當發生檔案（非SYSTEM檔案）寫錯誤時，Oracle會自動將資料檔案離線，這造成了很多災難，類似的錯誤日誌可能是這樣的：

Fri Jan 13 19:32:21 2018KCF: write/open error block=0xf1fa6 online=1 file=73 /dev/rods_gm05 error=27063 txt: 'IBM AIX RISC System/6000 Error: 22: Invalid argumentAdditional information: -1Additional information: 557056'Automatic datafile offline due to write error onfile 73: /dev/rods_gm05
鑑於很多使用者遇到的困境，Oracle做出了修正，這一修正在MOS上以BUG形式被提交，其內容為：Bug 7691270 Crash the DB in case of write errors (rather than just offline files) 。

在11.2.0.2之前，如果資料庫執行在歸檔模式下，並且寫錯誤發生在非SYSTEM表空間檔案，則資料庫會將發生錯誤的檔案離線，在從11.2.0.2開始，資料庫會Crash例項以替代Offline。注意：在非歸檔模式下或者SYSTEM遭受錯誤時，資料庫會直接崩潰。

為了解決資料檔案損失，離線控制存在的不確定性風險，Oracle引入的 _datafile_write_errors_crash_instance 控制資料庫例項直接崩潰。

如果你不能接受這一選擇，那麼設定引數 _datafile_write_errors_crash_instance 為False。

6. _optimizer_use_feedback - 優化器的基數反饋

Cardinality Feedback - 基數反饋，是Oracle 11.2中引入的新特性，這個新特性利用SQL執行過程中的資訊採集，動態的調整執行計劃，以解決統計資訊陳舊、無直方圖或基於直方圖基數計算不準確等情況。

Oracle希望由此提升執行計劃的準確性，但是在某些情況下，我們可能遇到SQL 第一次執行效能最好，之後再執行其效能變差的情況。

初始化引數 _optimizer_use_feedback 可以控制這個特性的啟用，設定為False關閉了這個特性：

alter system set "_optimizer_use_feedback"=false;

7. deferred_segment_creation - 延遲段建立

在Oracle 11.2中， 當我們建立一個空表或者空分割槽時，為了加快建立速度，Oracle並不會立即分配初始段和空間，實際的表段Table Segement被延遲到第一行資料插入時建立。

該功能通過DEFERRED_SEGMENT_CREATION引數啟用，預設為TRUE。延遲段建立可以節省空間，加快初始化過程，是面向效能和資源的一個優化。

這個新特性帶來的一個問題是，在使用 exp / imp 進行匯出匯入時，不會包含這些空表，可能導致遺漏物件。

如果覺得這個特性是困擾，可以通過修改引數關閉這個特性：

alter system set deferred_segment_creation=flase sscope=spfile;

8. _resource_manager_always_on - 資源管理器

在11g中，Oracle的資源管理器預設被啟用，並且時常發揮作用，並可能引發競爭。

你可能在TOP 5事件中看到類似的情景：

通過10大oracle特性來理解oracle 11g系統設計

有兩個引數配合設定，可以在你不需要資源管理器時徹底關閉這個隱含的控制：

SQL> alter system set "_resource_manager_always_off"=true scope=spfile; SQL> alter system set "_resource_manager_always_on"=false scope=spfile;

9. _gc_policy_time - RAC叢集中的DRM管理

DRM是 Dynamic Resource Management 的簡稱，意思就是動態資源管理。在Oracle RAC中，所有的資料塊（Data block）都有一個例項作為主例項進行管理，叫做Master，Master 負責照看好自己所管轄的data block的狀態，包括鎖定等，並對跨例項訪問進行授權。如果能隨著資料塊的訪問頻繁動態的修改資料塊的master節點，那麼對應GC的grant message則會大量的減少。基於以上考慮，DRM特性應運而生。但是早期的DRM在進行 re-master的過程中長長帶來短時的效能影響，在很多重要環境中，這是不能忍受的
如果希望關閉DRM這個特性，可以結合設定 _gc_policy_time 和 _gc_undo_affinity :alter system set "_gc_policy_time" = 0 scope=spfile;alter system set "_gc_undo_affinity" = false scope=spfile;

10. _cleanup_rollback_entries 、_undo_autotune - UNDO的清理和調整在UNDO的管理中，如何設定保留時間，清理回滾段條目，釋放UNDO空間，在高事務率的資料庫中非常重要_cleanup_rollback_entries - 指定回滾時每次回滾的ENTRIES個數，預設為100，可以設定更高提升回滾速度；

_undo_autotune - 用於自動調整undo retention時間，設定 _undo_autotune=true，則undo_retention不再適用，Oracle會自行決定tuned_undo_retention；

以下設定在需要時對這些特性做出調整：