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

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;

 

在白求恩智能診斷平臺上（https://bethune.enmotech.com），對於DRM特性的檢測結果以下：

 

 

不少的新特性，因爲DBA對其原理不夠了解，使用不當每每會帶來不少的性能影響。在白求恩平臺上，針對新特性的部分會詳細檢查。幫助DBA快速找出系統中存在的一些隱患。

 

白求恩，從架構到細節，全方位診斷系統安全與健康，比你更瞭解你的數據庫。如今登陸當即體驗：https://bethune.enmotech.com

 

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;

 

 

---

 

系統的性能永遠是DBA最關注的問題，Bethune可以幫助你快速檢測出數據庫當前的或者潛在的性能隱患，更好地防範。然而，在真正遇到問題的時候，面對龐大負責的性能體系，該如何找到正確的方法優化系統性能呢？

恩墨學院推出性能優化案例視頻課程，由侯院長親自教授，以數據庫經常使用性能優化技術進行講解，包括鎖等待、索引優化和列計算等技術；經過本課程的學習，你將初步具有性能優化診斷與處理的能力，在後續實戰中也會對數據庫的性能優化更加專業和熟練

 

---原地址：雲和恩墨

https://mp.weixin.qq.com/s?__biz=MjM5MDAxOTk2MQ==&mid=2650275500&idx=1&sn=84bc12fea2b88a92162117ab95a52954&chksm=be4866ba893fefac19fd7abb984057be31f506b7f4ad524c9715da6ca067b0df4a6304c38048&mpshare=1&scene=1&srcid=0328SaZWZS6ZF01t0EG3pJJX&key=87a1c8d6f03747dcdcea7c5ef4a6e82edfeaa72112fb442bbd22c5d2cd18c0351fa79dfda34a436b36ce1008e4af68f57d0647a1f62956943f0d81a5715581ff8206c6f95c2c5c06d4e7788733e91dfe&ascene=1&uin=MjAwNDE1MDc0NA%3D%3D&devicetype=Windows+7&version=62060720&lang=zh_CN&pass_ticket=3LdaI16Fu%2Fe6RSsLkprVYko4ubpussxBDzxNm94S7wDPoJklIV5Lji3msP7v3wLp