從一個Oracle DBA的角度來談談PG資料庫的最佳化

P G 資料庫目前已經成為最熱門的開源資料庫之一，特別是因為其開源協議十分適合商業化，因此大量的商用資料庫，包括大量的國產資料庫也都基於 P G 的開源代買進行研發。作為一個曾經的 Oracle  DBA ，如果在現階段要轉型的話，學習一下 P G 資料庫的運維，也算是未雨綢繆了。我搞了差不多 30年Oracle資料庫，不過我估計在我退休前的這幾年裡，Oracle方面的活會有所減少，而開源和國產資料庫方面的運維最佳化需求會大大增加。於是從2017年開始，我和我團隊的小夥伴們就開始對P G 資料庫進行系統的學習了。 Oracle  DBA 轉而學習 P G 資料庫，實際上還是比較容易的，因為大型關係型資料庫的基本概念是相通的，而且 P G 資料庫因為沒有了共享池和全域性共享 C URSOR 這個超級複雜的機制，也要簡單的多。

 

如果按照上面的維度把 Oracle資料庫與P G 資料庫的運維做個比對。 P G 是開源資料庫，無原廠支援，第三方服務水平較低，，程式碼 BUG可透過閱讀原始碼定位，需要透過社群修復。在這裡，第三方服務廠商就可以為客戶提供很多服務，比如資料庫的安裝和初步調優，以及定期的補丁與安全漏洞檢查，打補丁升級，解決日常遇到的B UG 等。與擁有原廠標準化補丁和服務的 Oracle相比，P G 資料庫這方面相對較弱，需要第三方服務來加以支援。

對於運維監控與最佳化而言， P G 資料庫提供了同樣豐富的監控介面和指標體系，不過部分監控介面需要安裝外掛，包括一些十分重要的監控採集內容，比如 T OP SQL ，都需要安裝外掛來實現。 P G 的第三方服務上應該幫助使用者提供這方面的安裝服務。

另外一方面， P G 資料庫和作業系統結合的十分緊密，運維工作與 OS關聯緊密，相對簡單，沒有複雜的共享池，運維關注點較為集中。在我個人的感覺離，P G 資料庫的運維更像是 Oracle 9i時代的資料庫運維。

與 Oracle資料庫不同的是，P G 資料庫的大版本升級對運維細節影響較大，甚至很多運維細節都是顛覆性的。因此需要 PG 的運維人員不斷的更新版本資訊，否則很容易出現認知錯誤。

最後一方面， P G 開源的第三方工具和第三方生態產品較多，而且這些工具與 Oracle的第三方工具、生態產品不同，如果不能很好的掌握這些工具和生態產品，會對P G 資料庫的運維產生比較大的影響。如果你去運維 Oracle資料庫，那麼只要把Oracle自身玩好就行了，Oracle資料庫自身構成了一個十分完善的體系，周邊工具與Oracle  RDBMS 之間是緊密整合，而且從底層是貫通的。而 P G 資料庫則不同， P G 社群僅僅提供了一個 R DBMS 和一些必要的外圍工具，剩下的應用所需要的功能都是其他的開源專案提供的。因此 PG 周邊的生態工具數量龐大，功能也存在差異，與 P G 資料庫的整合也是應用級的，沒有在 R DBMS 底層進行打通。最大的問題是使用者在選擇這些產品的時候也比較隨意，你去服務的不同客戶可能會選擇不同的高可用解決方案，選用不同的讀寫分離叢集方案，使用不同的第三方外掛來解決一些資料庫的功能問題。因此作為 P G 資料庫的 D BA 或者運維服務人員，你需要全面的掌握這些第三方生態工具，才能夠真正的把 P G 資料庫的運維服務做好。

 

在 P G 資料庫的運維中，從一個 O RACLE   DBA 的角度，我也總結了一些日常運維與最佳化的工作內容。因為今天下午我還要趕到東莞去參加華為的鯤鵬昇騰開發者峰會，所以今早的事情比較多，我就不展開介紹了，如果大家有興趣，明後天我會把上面這個片子詳細的介紹一下。大家有興趣的話，就在下面留言吧。

關於留言，我簡單說幾句，因為怕麻煩，我沒有開啟留言討論的公眾瀏覽功能，因此你們給我的留言我都是可以看見的，不過其他朋友可能看不見。年紀大了，只想靜靜的寫點東西，沒有精力去就某些觀點爭論與辯論，大家請包涵。