超大記憶體環境下的Oracle RAC引數設定建議

好久沒寫Oracle方面的文章了，最近有幾個朋友在超過1TB實體記憶體上的資料庫系統因為配置的問題，在高負載下出現了不穩定，當機，莫名其妙的報ORA-4030等問題。自從三十年前第一次在一臺32MB記憶體的小型機上安裝Oracle 5.1以來，這些年的硬體進步確實太快了，記憶體也已經進入了TB時代。如果在一臺TB級記憶體的伺服器上執行一套負載較高，資料量達到幾十TB的資料庫的時候，是不是會與以前有所不同呢?我也在MOS上查詢了一些資料，確實在超大記憶體環境下執行負載較高的Oracle資料庫系統，在引數最佳化上還是要做些調整的，今天早上我就把這些資料彙總一下，提供給有需要的朋友。

首先在作業系統層面設定大頁，關閉透明大頁，設定vm.swappiness以及調整網路引數，這些都按照Oracle安裝手冊的要求去做就可以了。在RHEL 7以上，新版本下，如果實體記憶體足夠的情況下，swappiness的設定不是必須的，不過設定為0或者小於10的值會更為穩妥一些。

除了上述比較常規的引數以外，我今天還要介紹一個比較陌生的引數，vm.max_map_count，這個引數用於程式中對映虛擬記憶體。CENTOS 7的預設值是65530。對於傳統的伺服器來說，這個值是夠用的，而如果你的系統需要對一張百GB級別的表做掃描的時候，過小的max_map_count可能會導致在實體記憶體還十分充足的情況下出現ora-4030報錯。Oracle對於12c的官方建議值是262144，是作業系統預設值的4倍。

接下來是一些資料庫的引數，首先是DRM相關的引數。在Oracle較低的版本上(比如10g/11g)或者網路不是很好的環境中，直接關閉DRM可能是更好的選擇。如果網路頻寬夠高，延時夠穩定，那麼在12C及以後的版本中，甚至在11g中，關閉DRM並不是必須選項。DRM對於效能來說是個雙刃劍，除了一些特殊場景必須關閉DRM外，實際上也可以開啟DRM以降低GCS的開銷。如果你想要關閉DRM，可以設定：_gc_policy_time = 0。如果你沒有關閉DRM，那麼建議設定_gc_policy_minimum=15000。_gc_policy_minimum引數是一個隱藏引數，用於指定每分鐘資料庫物件至少要被訪問多少次，才考慮修改它的主節點資訊。在某些版本中，該引數的預設值是2400，對於負載較高的系統，這個預設值太小了，建議加大。

另外一個十分重要的叢集引數是_lm_sync_timeout。這個引數的預設值也是偏小，這會增加大SGA環境下，RAC RECONFIGURATION或者DRM引發的lm同步超時的機率。Oracle建議在12.2或者更低版本中將該引數設定為1200。

_lm_tickets引數控制了RAC訊息通訊中的tickets數量，在不同版本的Oracle資料庫中，對於較大型、負載較高的資料庫來說，是不夠的，僅僅為1000。為了確保高負載的大型資料庫在執行中不會因為tickets不足而導致效能問題甚至引發叢集故障，該引數建議設定為5000或者更大。

如果你的系統的GCS相關的等待比較多，並且延時也比較高，那麼很可能你的lm process數量不足了。在Oracle 12.2及以下的大多數版本中，gcs_server_processes引數的預設值是不夠的，一般需要設定為預設值的2倍或者略高。不過設定該引數的時候一定要注意，lm processes的數量至少要比CPU的物理核數略低一些。

對於12.2或者更高的資料庫版本來說，大家可能不會意識到有一個對GCS效能影響巨大的PDB引數TARGET_PDBS，這個引數設定了今後CDB裡將會建立的PDB數量(不包含種子，根等)。因為隨著Oracle資料庫的自治能力提升，很多引數的預設值都會根據實際可能的情況做預留，GCS/GES相關的閂鎖數量也是如此。如果你今後會使用PDB，那麼一定要規劃好大致的PDB數量(不用百分百精確，但是不能相差太大，如果相差太大，要重新調整該引數)，並將此引數設定好。

最後講到Oracle的SGA/PGA方面的配置了。超大記憶體環境當然與SGA有關，不過實際上Oracle對SGA的管理已經十分自動化，如果你使用11g，那麼，建議還是採用SGA_TARGET和PGA_AGGREGATE_TARGET引數來控制PGA/SGA。而如果你使用12.2版本，那麼無論使用memory_target還是使用sga_target，都沒有太大的問題。唯一需要注意的是，你一定要將SGA的15%分配給SHARED_POOL_SIZE。共享池對於資料庫併發效能十分關鍵，如果你的資料庫的併發執行很高，不給共享池一個較大的最低配置，會導致SGA抖動加劇。當資料庫負載很高的時候出現一次共享池的RESIZE，那麼可能會對資料庫的效能造成很大的影響。

最後一點要提醒的是，如果你使用了巨大記憶體，那麼一些資料庫的比較新的補丁建議都打一下。因為Oracle的一些初始版本都沒有考慮到這些問題，因此或多或少都存在一些支援上的不足。比如對於表早期的11.2.0.3, 11.2.0.3.5 資料庫 PSU是必須打的。如果你的伺服器記憶體大於4TB，而資料庫版本還是比較老的11.2.0.4，BUG 18780342會倒追在LINUX上無法在4TB記憶體的伺服器上穩定執行Oracle 11.2.0.4，目前該修復已經包含在一些修復中，可以去MOS上透過bug號查詢所需的補丁。