盤點 Oracle 11g 中新特性帶來的10大效能影響

---

---

原創 2017-08-02 蓋國強 資料和雲

Oracle的任何一個新版本，總是會帶來大量引人矚目的新特性，但是往往在這些新特性引入之初，首先引起的是一些麻煩，因為對於新技術的不瞭解、因為對於舊環境的不適應，從Oracle產品到技術服務運維，總是要走過一個磨合的長期過程。

請注意：我們並不推薦大家盲目的關閉和摒棄Oracle的新特性，我們建議大家在遇到問題時，做出適合自己的調整。

就此盤點一下 Oracle 11g 中，那些新特性帶來的新煩惱，如果有使用者準備或者剛剛踏入這個新版本，則可以作為借鑑。

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：

請點選此處輸入圖片描述

2. Adaptive Log File Sync - 自適應的Log File Sync

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

請點選此處輸入圖片描述

在這類情況下，時間模型 - 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 可以來控制這個特性。

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 2013

KCF: write/open error block=0xf1fa6 online=1

     file=73 /dev/rods_gm05

     error=27063 txt: 'IBM AIX RISC System/6000 Error: 22: Invalid argument

Additional information: -1

Additional information: 557056'

Automatic datafile offline due to write error on

file 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事件中看到類似的情景：

請點選此處輸入圖片描述

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

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;

---

---

About Me

............................................................................................................................................. ● 本文來自於 蓋國強 資料和雲 ● 本文在itpub（http://blog.itpub.net/26736162/abstract/1/）、部落格園（http://www.cnblogs.com/lhrbest）和個人微信公眾號（xiaomaimiaolhr）上有同步更新 ● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/ ● 本文部落格園地址：http://www.cnblogs.com/lhrbest ● 本文pdf版、個人簡介及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA寶典今日頭條號地址：http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826 ............................................................................................................................................. ● QQ群號：230161599（滿）、618766405 ● 微信群：可加我微信，我拉大家進群，非誠勿擾 ● 聯絡我請加QQ好友（646634621），註明新增緣由 ● 於 2017-08-01 09:00 ~ 2017-08-31 22:00 在魔都完成 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ............................................................................................................................................. ● 小麥苗的微店：https://weidian.com/s/793741433?wfr=c&ifr=shopdetail ● 小麥苗出版的資料庫類叢書：http://blog.itpub.net/26736162/viewspace-2142121/ ............................................................................................................................................. 使用微信客戶端掃描下面的二維碼來關注小麥苗的微信公眾號（xiaomaimiaolhr）及QQ群（DBA寶典），學習最實用的資料庫技術。    小麥苗的微信公眾號      小麥苗的DBA寶典QQ群1     小麥苗的DBA寶典QQ群2        小麥苗的微店 .............................................................................................................................................

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2143222/，如需轉載，請註明出處，否則將追究法律責任。