好久沒寫Oracle方面的文章了，最近有幾個(gè)朋友在超過1TB物理內(nèi)存上的數(shù)據(jù)庫系統(tǒng)因?yàn)榕渲玫膯栴}，在高負(fù)載下出現(xiàn)了不穩(wěn)定，宕機(jī)，莫名其妙的報(bào)ORA-4030等問題。自從三十年前第一次在一臺(tái)32MB內(nèi)存的小型機(jī)上安裝Oracle 5.1以來，這些年的硬件進(jìn)步確實(shí)太快了，內(nèi)存也已經(jīng)進(jìn)入了TB時(shí)代。如果在一臺(tái)TB級(jí)內(nèi)存的服務(wù)器上運(yùn)行一套負(fù)載較高，數(shù)據(jù)量達(dá)到幾十TB的數(shù)據(jù)庫的時(shí)候，是不是會(huì)與以前有所不同呢？我也在MOS上查找了一些資料，確實(shí)在超大內(nèi)存環(huán)境下運(yùn)行負(fù)載較高的Oracle數(shù)據(jù)庫系統(tǒng)，在參數(shù)優(yōu)化上還是要做些調(diào)整的，今天早上我就把這些資料匯總一下，提供給有需要的朋友。

首先在操作系統(tǒng)層面設(shè)置大頁，關(guān)閉透明大頁，設(shè)置vm.swappiness以及調(diào)整網(wǎng)絡(luò)參數(shù)，這些都按照Oracle安裝手冊(cè)的要求去做就可以了。在RHEL 7以上，新版本下，如果物理內(nèi)存足夠的情況下，swappiness的設(shè)置不是必須的，不過設(shè)置為0或者小于10的值會(huì)更為穩(wěn)妥一些。

除了上述比較常規(guī)的參數(shù)以外，我今天還要介紹一個(gè)比較陌生的參數(shù)，vm.max_map_count，這個(gè)參數(shù)用于進(jìn)程中映射虛擬內(nèi)存。CENTOS 7的默認(rèn)值是65530。對(duì)于傳統(tǒng)的服務(wù)器來說，這個(gè)值是夠用的，而如果你的系統(tǒng)需要對(duì)一張百GB級(jí)別的表做掃描的時(shí)候，過小的max_map_count可能會(huì)導(dǎo)致在物理內(nèi)存還十分充足的情況下出現(xiàn)ora-4030報(bào)錯(cuò)。Oracle對(duì)于12c的官方建議值是262144，是操作系統(tǒng)默認(rèn)值的4倍。

接下來是一些數(shù)據(jù)庫的參數(shù)，首先是DRM相關(guān)的參數(shù)。在Oracle較低的版本上（比如10g/11g）或者網(wǎng)絡(luò)不是很好的環(huán)境中，直接關(guān)閉DRM可能是更好的選擇。如果網(wǎng)絡(luò)帶寬夠高，延時(shí)夠穩(wěn)定，那么在12C及以后的版本中，甚至在11g中，關(guān)閉DRM并不是必須選項(xiàng)。DRM對(duì)于性能來說是個(gè)雙刃劍，除了一些特殊場(chǎng)景必須關(guān)閉DRM外，實(shí)際上也可以打開DRM以降低GCS的開銷。如果你想要關(guān)閉DRM，可以設(shè)置：_gc_policy_time = 0。如果你沒有關(guān)閉DRM，那么建議設(shè)置_gc_policy_minimum=15000。_gc_policy_minimum參數(shù)是一個(gè)隱藏參數(shù)，用于指定每分鐘數(shù)據(jù)庫對(duì)象至少要被訪問多少次，才考慮修改它的主節(jié)點(diǎn)信息。在某些版本中，該參數(shù)的默認(rèn)值是2400，對(duì)于負(fù)載較高的系統(tǒng)，這個(gè)默認(rèn)值太小了，建議加大。

另外一個(gè)十分重要的集群參數(shù)是_lm_sync_timeout。這個(gè)參數(shù)的默認(rèn)值也是偏小，這會(huì)增加大SGA環(huán)境下，RAC RECONFIGURATION或者DRM引發(fā)的lm同步超時(shí)的幾率。Oracle建議在12.2或者更低版本中將該參數(shù)設(shè)置為1200。

_lm_tickets參數(shù)控制了RAC消息通訊中的tickets數(shù)量，在不同版本的Oracle數(shù)據(jù)庫中，對(duì)于較大型、負(fù)載較高的數(shù)據(jù)庫來說，是不夠的，僅僅為1000。為了確保高負(fù)載的大型數(shù)據(jù)庫在運(yùn)行中不會(huì)因?yàn)閠ickets不足而導(dǎo)致性能問題甚至引發(fā)集群故障，該參數(shù)建議設(shè)置為5000或者更大。

如果你的系統(tǒng)的GCS相關(guān)的等待比較多，并且延時(shí)也比較高，那么很可能你的lm process數(shù)量不足了。在Oracle 12.2及以下的大多數(shù)版本中，gcs_server_processes參數(shù)的默認(rèn)值是不夠的，一般需要設(shè)置為默認(rèn)值的2倍或者略高。不過設(shè)置該參數(shù)的時(shí)候一定要注意，lm processes的數(shù)量至少要比CPU的物理核數(shù)略低一些。

對(duì)于12.2或者更高的數(shù)據(jù)庫版本來說，大家可能不會(huì)意識(shí)到有一個(gè)對(duì)GCS性能影響巨大的PDB參數(shù)TARGET_PDBS，這個(gè)參數(shù)設(shè)置了今后CDB里將會(huì)創(chuàng)建的PDB數(shù)量（不包含種子，根等）。因?yàn)殡S著Oracle數(shù)據(jù)庫的自治能力提升，很多參數(shù)的默認(rèn)值都會(huì)根據(jù)實(shí)際可能的情況做預(yù)留，GCS/GES相關(guān)的閂鎖數(shù)量也是如此。如果你今后會(huì)使用PDB，那么一定要規(guī)劃好大致的PDB數(shù)量（不用百分百精確，但是不能相差太大，如果相差太大，要重新調(diào)整該參數(shù)），并將此參數(shù)設(shè)置好。

最后講到Oracle的SGA/PGA方面的配置了。超大內(nèi)存環(huán)境當(dāng)然與SGA有關(guān)，不過實(shí)際上Oracle對(duì)SGA的管理已經(jīng)十分自動(dòng)化，如果你使用11g，那么，建議還是采用SGA_TARGET和PGA_AGGREGATE_TARGET參數(shù)來控制PGA/SGA。而如果你使用12.2版本，那么無論使用memory_target還是使用sga_target，都沒有太大的問題。唯一需要注意的是，你一定要將SGA的15%分配給SHARED_POOL_SIZE。共享池對(duì)于數(shù)據(jù)庫并發(fā)性能十分關(guān)鍵，如果你的數(shù)據(jù)庫的并發(fā)執(zhí)行很高，不給共享池一個(gè)較大的最低配置，會(huì)導(dǎo)致SGA抖動(dòng)加劇。當(dāng)數(shù)據(jù)庫負(fù)載很高的時(shí)候出現(xiàn)一次共享池的RESIZE，那么可能會(huì)對(duì)數(shù)據(jù)庫的性能造成很大的影響。

最后一點(diǎn)要提醒的是，如果你使用了巨大內(nèi)存，那么一些數(shù)據(jù)庫的比較新的補(bǔ)丁建議都打一下。因?yàn)镺racle的一些初始版本都沒有考慮到這些問題，因此或多或少都存在一些支持上的不足。比如對(duì)于表早期的11.2.0.3, 11.2.0.3.5 數(shù)據(jù)庫 PSU是必須打的。如果你的服務(wù)器內(nèi)存大于4TB，而數(shù)據(jù)庫版本還是比較老的11.2.0.4，BUG 18780342會(huì)倒追在LINUX上無法在4TB內(nèi)存的服務(wù)器上穩(wěn)定運(yùn)行Oracle 11.2.0.4，目前該修復(fù)已經(jīng)包含在一些修復(fù)中，可以去MOS上通過bug號(hào)查找所需的補(bǔ)丁。