通過(guò)10大oracle特性來(lái)理解oracle 11g系統(tǒng)設(shè)計(jì)

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

在Oracle Database 11g中有一個(gè)新特性，全表掃描可以通過(guò)直接路徑讀的方式來(lái)執(zhí)行（Direct Path Read），這是一個(gè)合理的變化，如果全表掃描的大量數(shù)據(jù)讀取是偶發(fā)性的，則直接路徑讀可以避免大量數(shù)據(jù)對(duì)于Buffer Cache的沖擊。

可是現(xiàn)實(shí)往往是殘酷的：在很多業(yè)務(wù)系統(tǒng)中，全表掃描是普遍存在的常態(tài)，將大表的全表掃描全部轉(zhuǎn)化為直接路徑讀，反而不如Cache在Buffer Cache中效率高，Direct Path Read反而成為了一個(gè)嚴(yán)重的負(fù)擔(dān)。

當(dāng)然對(duì)于小表來(lái)說(shuō)，Oracle允許通過(guò)Buffer Cache來(lái)進(jìn)行全表掃描，因?yàn)檫@可能更快，也對(duì)性能影響不大。小表受到隱含參數(shù)：_small_table_threshold 影響。如果表大于 5 倍的小表限制，則自動(dòng)會(huì)使用DPR替代FTS。

如果遇到這個(gè)特性的負(fù)面影響，可以設(shè)置初始化參數(shù)： _serial_direct_read 來(lái)禁用串行直接路徑讀，其默認(rèn)值為AUTO，設(shè)置為NEVER時(shí)禁用 11g 的自動(dòng)direct path read的特性。該參數(shù)可以動(dòng)態(tài)在實(shí)例或會(huì)話級(jí)別修改，而無(wú)需重啟實(shí)例（可以結(jié)合Event 10949設(shè)置）。

SQL> alter system set "_serial_direct_read"=auto;

SQL> alter system set "_serial_direct_read"=never;

以下的AWR信息是典型的DPR癥狀，可以看到Direct Path Read在這個(gè)報(bào)告中處于最占用DB Time的部分：

如果結(jié)合ASH報(bào)告更加一目了然，顯示全表掃描的SQL，都在以Direct Path Read的方式執(zhí)行 Table Access Full：

關(guān)于 Log File Sync 等待的優(yōu)化，在Oracle數(shù)據(jù)庫(kù)中一直是常見(jiàn)問(wèn)題，LOG FILE的寫(xiě)出性能一旦出現(xiàn)波動(dòng)，該等待就可能十分突出。

在Oracle 11.2.0.3 版本中，Oracle 將隱含參數(shù)

_use_adaptive_log_file_sync 的初始值設(shè)置為 TRUE，由此帶來(lái)了很多 Log File Sync 等待異常的情況，這個(gè)問(wèn)題雖然由來(lái)已久，但是仍然有很多Oracle的用戶并不知情。

當(dāng)前臺(tái)進(jìn)程提交事務(wù)（commit）后，LGWR需要執(zhí)行日志寫(xiě)出操作，而前臺(tái)進(jìn)程因此進(jìn)入 Log File Sync 等待周期。

在以前版本中，LGWR 執(zhí)行寫(xiě)入操作完成后，會(huì)通知前臺(tái)進(jìn)程，這也就是 Post/Wait 模式；在11gR2 中，為了優(yōu)化這個(gè)過(guò)程，前臺(tái)進(jìn)程通知LGWR寫(xiě)之后，可以通過(guò)定時(shí)獲取的方式來(lái)查詢寫(xiě)出進(jìn)度，這被稱為 Poll 的模式，在11.2.0.3中，這個(gè)特性被默認(rèn)開(kāi)啟。這個(gè)參數(shù)的含義是：數(shù)據(jù)庫(kù)可以在自適應(yīng)的在 post/wait 和 polling 模式間選擇和切換。

_use_adaptive_log_file_sync 參數(shù)的解釋就是： Adaptively switch between post/wait and polling ，正是由于這個(gè)原因，帶來(lái)了很多Bug，反而使得 Log File Sync 的等待異常的高，如果你在 11.2.0.3 版本中觀察到這樣的表征，那就極有可能與此有關(guān)。

在遇到問(wèn)題是，通常將

_use_adaptive_log_file_sync 參數(shù)設(shè)置為 False，回歸以前的模式，將會(huì)有助于問(wèn)題的解決。

Oracle數(shù)據(jù)庫(kù)的SQL使用的是共享機(jī)制，通過(guò)綁定變量可以使Oracle DB 可以為多條SQL 語(yǔ)句共享單個(gè)游標(biāo)，以減少分析SQL 語(yǔ)句所使用的共享內(nèi)存和CPU資源等。

然而一個(gè)執(zhí)行計(jì)劃并不總是適用于所有綁定值，為了盡可能生成準(zhǔn)確的執(zhí)行計(jì)劃，Oracle Database 11g 引入了自適應(yīng)游標(biāo)共享的新特性，在執(zhí)行共享SQL時(shí)考慮更多的因素，如果與資源開(kāi)銷相比，使用多個(gè)執(zhí)行計(jì)劃所帶來(lái)的收益更重要，則會(huì)為使用綁定變量的每條SQL 語(yǔ)句生成多個(gè)執(zhí)行計(jì)劃。

Adaptive Cursor Sharing 通過(guò)自適應(yīng)游標(biāo)共享，可以僅針對(duì)使用綁定變量的語(yǔ)句智能地共享游標(biāo)。但是有時(shí)候這個(gè)特性會(huì)使得確定的執(zhí)行計(jì)劃變得不穩(wěn)定，如果你確定系統(tǒng)中無(wú)需額外自適應(yīng)的分析和變更執(zhí)行計(jì)劃，或者可能被不穩(wěn)定的執(zhí)行計(jì)劃影響。那么可能需要調(diào)整這個(gè)特性的使用。

關(guān)閉這個(gè)特性，可以設(shè)置隱含參數(shù)：

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 引入了『密碼延遲驗(yàn)證』的新特性。這個(gè)特性的作用是，如果用戶輸入了錯(cuò)誤的密碼嘗試登錄，那么隨著登錄錯(cuò)誤次數(shù)的增加，每次登錄前驗(yàn)證的時(shí)間也會(huì)增加，以此減緩可能對(duì)于數(shù)據(jù)庫(kù)重復(fù)的口令嘗試攻擊。

但是對(duì)于正常的系統(tǒng)，由于口令的更改，可能存在某些被遺漏的客戶端，不斷重復(fù)嘗試，從而引起數(shù)據(jù)庫(kù)內(nèi)部長(zhǎng)時(shí)間的 Library Cache Lock的等待，這種情形非常常見(jiàn)。

如果遇到這一類問(wèn)題，可以通過(guò)Event 28401關(guān)閉這個(gè)特性，從而消除此類影響，以下命令將修改設(shè)置在參數(shù)文件中：

ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;

出現(xiàn)這類問(wèn)題非常典型的AWR報(bào)告呈現(xiàn)如下，首先在 TOP 5 中，可能看到顯著的 Library Cache Lock 的等待，以下范例來(lái)自11.2.0.3.0版本的真實(shí)情況：

在這類情況下，時(shí)間模型 - Time Model 中會(huì)顯示如下指標(biāo)，其中 connection management call elapsed time 占據(jù)了主要的DB Time，這個(gè)等待直接表明是在建立數(shù)據(jù)庫(kù)連接時(shí)產(chǎn)生的：

這類問(wèn)題，在Oracle的11g中是常見(jiàn)和確定的，在MOS上可以找到相應(yīng)的記錄：High 'library cache lock' Wait Time Due to Invalid Login Attempts(1309738.1）此外Oracle 11g開(kāi)啟了密碼大小寫(xiě)驗(yàn)證，如果從Oracle 10g升級(jí)過(guò)來(lái)，需要特別的當(dāng)心這個(gè)變化，通過(guò)初始化參數(shù)SEC_CASE_SENSITIVE_LOGON 可以來(lái)控制這個(gè)特性。

從Oracle 11.2.0.2版本開(kāi)始，一個(gè)新的隱含參數(shù) -

_datafile_write_errors_crash_instance 被引入到數(shù)據(jù)庫(kù)中，通過(guò)這個(gè)參數(shù)名就可以了解到其含義：當(dāng)發(fā)生數(shù)據(jù)文件寫(xiě)錯(cuò)誤時(shí)，Crash數(shù)據(jù)庫(kù)實(shí)例。

為什么要引入這個(gè)參數(shù)呢？這個(gè)參數(shù)后臺(tái)解決的是什么問(wèn)題呢？

在歸檔模式下當(dāng)發(fā)生文件（非SYSTEM文件）寫(xiě)錯(cuò)誤時(shí)，Oracle會(huì)自動(dòng)將數(shù)據(jù)文件離線，這造成了很多災(zāi)難，類似的錯(cuò)誤日志可能是這樣的：

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形式被提交，其內(nèi)容為：Bug 7691270 Crash the DB in case of write errors (rather than just offline files) 。

在11.2.0.2之前，如果數(shù)據(jù)庫(kù)運(yùn)行在歸檔模式下，并且寫(xiě)錯(cuò)誤發(fā)生在非SYSTEM表空間文件，則數(shù)據(jù)庫(kù)會(huì)將發(fā)生錯(cuò)誤的文件離線，在從11.2.0.2開(kāi)始，數(shù)據(jù)庫(kù)會(huì)Crash實(shí)例以替代Offline。注意：在非歸檔模式下或者SYSTEM遭受錯(cuò)誤時(shí)，數(shù)據(jù)庫(kù)會(huì)直接崩潰。

為了解決數(shù)據(jù)文件損失，離線控制存在的不確定性風(fēng)險(xiǎn)，Oracle引入的

_datafile_write_errors_crash_instance 控制數(shù)據(jù)庫(kù)實(shí)例直接崩潰。

如果你不能接受這一選擇，那么設(shè)置參數(shù)

_datafile_write_errors_crash_instance 為False。

Cardinality Feedback - 基數(shù)反饋，是Oracle 11.2中引入的新特性，這個(gè)新特性利用SQL執(zhí)行過(guò)程中的信息采集，動(dòng)態(tài)的調(diào)整執(zhí)行計(jì)劃，以解決統(tǒng)計(jì)信息陳舊、無(wú)直方圖或基于直方圖基數(shù)計(jì)算不準(zhǔn)確等情況。

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

初始化參數(shù) _optimizer_use_feedback 可以控制這個(gè)特性的啟用，設(shè)置為False關(guān)閉了這個(gè)特性：

alter system set "_optimizer_use_feedback"=false;

在Oracle 11.2中， 當(dāng)我們創(chuàng)建一個(gè)空表或者空分區(qū)時(shí)，為了加快創(chuàng)建速度，Oracle并不會(huì)立即分配初始段和空間，實(shí)際的表段Table Segement被延遲到第一行數(shù)據(jù)插入時(shí)創(chuàng)建。

該功能通過(guò)DEFERRED_SEGMENT_CREATION參數(shù)啟用，默認(rèn)為T(mén)RUE。延遲段創(chuàng)建可以節(jié)省空間，加快初始化過(guò)程，是面向性能和資源的一個(gè)優(yōu)化。

這個(gè)新特性帶來(lái)的一個(gè)問(wèn)題是，在使用 exp / imp 進(jìn)行導(dǎo)出導(dǎo)入時(shí)，不會(huì)包含這些空表，可能導(dǎo)致遺漏對(duì)象。

如果覺(jué)得這個(gè)特性是困擾，可以通過(guò)修改參數(shù)關(guān)閉這個(gè)特性：

alter system set deferred_segment_creation=flase sscope=spfile;

在11g中，Oracle的資源管理器缺省被啟用，并且時(shí)常發(fā)揮作用，并可能引發(fā)競(jìng)爭(zhēng)。

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

有兩個(gè)參數(shù)配合設(shè)置，可以在你不需要資源管理器時(shí)徹底關(guān)閉這個(gè)隱含的控制：

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 的簡(jiǎn)稱，意思就是動(dòng)態(tài)資源管理。在Oracle RAC中，所有的數(shù)據(jù)塊（Data block）都有一個(gè)實(shí)例作為主實(shí)例進(jìn)行管理，叫做Master，Master 負(fù)責(zé)照看好自己所管轄的data block的狀態(tài)，包括鎖定等，并對(duì)跨實(shí)例訪問(wèn)進(jìn)行授權(quán)。

如果能隨著數(shù)據(jù)塊的訪問(wèn)頻繁動(dòng)態(tài)的修改數(shù)據(jù)塊的master節(jié)點(diǎn)，那么對(duì)應(yīng)GC的grant message則會(huì)大量的減少。基于以上考慮，DRM特性應(yīng)運(yùn)而生。但是早期的DRM在進(jìn)行 re-master的過(guò)程中長(zhǎng)長(zhǎng)帶來(lái)短時(shí)的性能影響，在很多重要環(huán)境中，這是不能忍受的。

如果希望關(guān)閉DRM這個(gè)特性，可以結(jié)合設(shè)置 _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的清理和調(diào)整

在UNDO的管理中，如何設(shè)置保留時(shí)間，清理回滾段條目，釋放UNDO空間，在高事務(wù)率的數(shù)據(jù)庫(kù)中非常重要。

_cleanup_rollback_entries - 指定回滾時(shí)每次回滾的ENTRIES個(gè)數(shù)，默認(rèn)為100，可以設(shè)置更高提升回滾速度；

_undo_autotune - 用于自動(dòng)調(diào)整undo retention時(shí)間，設(shè)置 _undo_autotune=true，則undo_retention不再適用，Oracle會(huì)自行決定tuned_undo_retention；

以下設(shè)置在需要時(shí)對(duì)這些特性做出調(diào)整：

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

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

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

后面會(huì)分享更多關(guān)于DBA內(nèi)容，感興趣的朋友可以關(guān)注下~