好久沒寫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號查找所需的補丁。