一个Oracle DBA的角度来看PostgreSQL的运维与优化 _Oracle

PG数据库目前已经成为最热门的开源数据库之一，特别是因为其开源协议十分适合商业化，因此大量的商用数据库，包括大量的国产数据库也都基于PG的开源代码进行研发。作为一个曾经的Oracle DBA，如果在现阶段要转型的话，学习一下PG数据库的运维，也算是未雨绸缪了。我搞了差不多30年Oracle数据库，不过我估计在我退休前的这几年里，Oracle方面的活会有所减少，而开源和国产数据库方面的运维优化需求会大大增加。于是从2017年开始，我和我团队的小伙伴们就开始对PG数据库进行系统的学习了。Oracle DBA转而学习PG数据库，实际上还是比较容易的，因为大型关系型数据库的基本概念是相通的，而且PG数据库因为没有了共享池和全局共享CURSOR这个超级复杂的机制，也要简单得多。

文章插图
如果按照上面的维度把Oracle数据库与PG数据库的运维做个比对。PG是开源数据库，无原厂支持，第三方服务水平较低，代码BUG可通过阅读源码定位，需要通过社区修复。在这里，第三方服务厂商就可以为客户提供很多服务，比如数据库的安装和初步调优，以及定期的补丁与安全漏洞检查，打补丁升级，解决日常遇到的BUG等。与拥有原厂标准化补丁和服务的Oracle相比，PG数据库这方面相对较弱，需要第三方服务来加以支持。
【一个Oracle DBA的角度来看PostgreSQL的运维与优化】对于运维监控与优化而言，PG数据库提供了同样丰富的监控接口和指标体系，不过部分监控接口需要安装插件，包括一些十分重要的监控采集内容，比如TOP SQL，都需要安装插件来实现。PG的第三方服务商应该帮助用户提供这方面的安装部署服务。
另外一方面，PG数据库和操作系统结合得十分紧密，运维工作与OS关联紧密，相对简单，没有复杂的共享池，运维关注点较为集中。在我个人的感觉里，PG数据库的运维更像是Oracle 9i时代的数据库运维。
与Oracle数据库不同的是，PG数据库的大版本升级对运维细节影响较大，甚至很多运维细节都是颠覆性的。因此需要PG的运维人员不断地更新版本信息，否则很容易出现认知错误。
最后一方面，PG开源的第三方工具和第三方生态产品较多，而且这些工具与Oracle的第三方工具、生态产品不同，如果不能很好地掌握这些工具和生态产品，会对PG数据库的运维产生比较大的影响。如果你去运维Oracle数据库，那么只要把Oracle自身玩好就行了，Oracle数据库自身构成了一个十分完善的体系，周边工具与Oracle RDBMS之间是紧密集成，而且从底层是贯通的。而PG数据库则不同，PG社区仅仅提供了一个RDBMS和一些必要的外围工具，剩下的应用所需要的功能都是其他的开源项目提供的。因此PG周边的生态工具数量庞大，功能也存在差异，与PG数据库的集成也是应用级的，没有在RDBMS底层进行打通。最大的问题是用户在选择这些产品的时候也比较随意，你去服务的不同客户可能会选择不同的高可用解决方案，选用不同的读写分离集群方案，使用不同的第三方插件来解决一些数据库的功能问题。因此作为PG数据库的DBA或者运维服务人员，你需要全面地掌握这些第三方生态工具，才能够真正把PG数据库的运维服务做好。

文章插图
在PG数据库的运维中，从一个ORACLE DBA的角度，我也总结了一些日常运维与优化的工作内容。因为今天下午我还要赶到东莞去参加华为的鲲鹏昇腾开发者峰会，所以今早的事情比较多，我就不展开介绍了，如果大家有兴趣，明后天我会把上面这个片子详细地介绍一下。大家有兴趣的话，就在下面留言吧。
关于留言，我简单说几句，因为怕麻烦，我没有开启留言讨论的公众浏览功能，因此你们给我的留言我都是可以看见的，不过其他朋友可能看不见。年纪大了，只想静静地写点东西，没有精力去就某些观点争论与辩论，大家请包涵。