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

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

在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，回歸以前的模式，將會有助于問題的解決。

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;

在 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版本的真實情況：

在這類情況下，時間模型 - Time Model 中會顯示如下指標，其中 connection management call elapsed time 占據了主要的DB Time，這個等待直接表明是在建立數據庫連接時產生的：

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

從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。

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

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

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

alter system set "_optimizer_use_feedback"=false;

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

該功能通過DEFERRED_SEGMENT_CREATION參數啟用，默認為TRUE。延遲段創建可以節省空間，加快初始化過程，是面向性能和資源的一個優化。

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

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

alter system set deferred_segment_creation=flase sscope=spfile;

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

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

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

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；

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

alter system set "_undo_autotune" = false scope=spfile;

alter system set "_cleanup_rollback_entries" = 1000 scope=spfile;

篇幅有限，今天主要講一下oracle11g的這些新特性，幫助大家更好的理解oracle為什么要這樣設計。

后面會分享更多關于DBA內容，感興趣的朋友可以關注下~