摘要：可能大多數DBA都覺得資料庫就是資料庫，不同的資料庫可能在企業級特性上，性能上，穩定性上有些差别，其他的也就
可能大多數DBA都覺得資料庫就是資料庫，不同的資料庫可能在企業級特性上，性能上，穩定性上有些差别，其他的也就不去管了。今天老白和大家聊聊單程序架構資料庫與多程序架構資料庫之間的一些差異性的東西。老DBA都了解Oracle資料庫是一種多程序架構的資料庫，所有的服務和前台程序都是獨立的程序，而Mysql是一種單程序多線程架構的資料庫，整個資料庫服務是一個程序，所有的前台與背景會話都是一個線程。我們來看看一些主流的資料庫，Oracle、PostgreSQL、人大金倉是多程序架構的，SQL SERVER、Mysql、Gaussdb 100(Gaussdb 200的基礎是PostgreSQL ,和Pg是一樣架構的）、達夢等是單程序架構的。
前些年一直在争論兩種架構的優缺點，很多人認為Mysql這類單程序架構的資料庫代表了更新的技術，實際上也沒必要糾結技術的新與不新，兩種架構是各有優缺點的。多線程架構，線程之間通訊的效率直接可以通過記憶體，通過線程鎖實作串行化，其開銷是十分小的，這對于大規模并發十分有利。不過這種架構也有其缺陷，線程數量太多，線程排程的開銷将十分大，是以這種架構比較适合大并發，但是每個通路都較短的場景。對于海量并發場景，可能并不能比多程序架構有優勢。另外一點就是，多程序架構每個服務都是獨立的程序，隔離比較好，某個會話出現問題，包括記憶體洩漏等BUG都比較容易解決，而單程序架構下，這種缺陷會被放大。
資料庫管理系統選擇多程序還是單程序架構是和其企業有關系的，單程序下的CURSOR共享會變得高效與簡單，就不需要搞Oracle SHARED POOL這麼複雜的結構了，oracle公司也不怕，在SHARED POOL方面獨步天下的技術保證了就是用多程序架構，性能上也不懼怕任何競争對手，這是Oracle的底蘊。
接下來進入正題，我們來看看單程序多線程架構的資料庫在運維方面需要注意的一點，就是記憶體控制。剛才也提到了，記憶體是這種架構的資料庫的一個十分要命的地方，那麼最嚴重的情況會出現什麼呢？我們選擇大多數非ORACLE資料庫都運作在LINUX上，那麼我們就以LINUX作業系統為例，來介紹一下對單程序架構資料庫具有緻命影響的一個LINUX特性-OOM KILLER。
單程序資料庫在作業系統中看到的就是一個獨立的服務程序
在一個運作這樣資料庫的系統中，記憶體使用率排在前面的往往就是這些資料庫的服務程序。比如上面的高斯100資料庫占用了這個系統的超過50%的記憶體。這種情況有什麼風險呢？
在你的伺服器的實體記憶體十分充裕的情況下，OOM KILLER的風險是不存在的，而當你的實體記憶體存在問題，出現了SWAP使用率較高的問題的時候，這種風險就十分高了。當LINUX作業系統認為實體記憶體将出現OUT OF MEMORY (OOM）的時候，OOM KILLER這個殺手就會被激活了。作業系統必須殺掉一些風險較高的程序，進而確定整個作業系統不會因為OOM而徹底挂掉。
那麼殺手會如何選擇要殺的程序呢？我們來看看每個程序下的OOM相關的檔案：
有三個和oom相關的檔案，oom_score裡存放的是這個程序的oom評分：
我們發現，高斯的服務程序的oom_score高達370分，目前是整個伺服器上最高的。如果這個時候，伺服器的記憶體出現了OOM的風險，那麼LINUX可不會管你是華為的還是甲骨文的，拿SCORE最高的開刀就沒錯了。
從這裡我們可以得到一條經驗，對于單程序架構的資料庫，一定要確定實體記憶體不要出現過度使用，如果無法確定足夠的實體記憶體供給（這種情況在雲環境下很可能經常會遇到），那麼，確定有足夠的SWAP空間，進而避免OOM的出現。
除此之外，我們還有什麼防禦措施嗎？當然有，就是oom_adj/oom_score_adj這兩個參數（oom_adj是早期linux的參數，為保證相容性保留的，新版本都使用oom_score_adj了），通過設定某個程序的這個參數，可以讓這個程序的oom_score保持低位，確定不會被殺手殺掉。
上面的例子裡，我們把高斯的程序的oom_score_adj設定為-1000，這個服務程序的oom_score立馬就變成0了，這樣殺手就找不到它了。