PG数据库的很多企业级运维功能还不完备，这对于从ORACLE等企业级数据库转型过来的DBA感受到不适。因为PG的运维中还是有很多小地方需要注意的，对于大型的企业级系统来说，如果忽视了这些问题，可能会引发运维问题。

一年前，我也写过一篇文章《PG离企业核心应用数据库还有多远》，里面提的都是PG目前缺乏的企业级应用特性，讲的都是大问题，需要内核慢慢去解决的。今天我们讨论一些小的方面，这些方面的问题大多数是可以通过DBA日常运维来弥补的。对于企业关键的核心业务系统，如果这些方面不谨慎运维，很容易引发大型故障，需要DBA十分重视。另外很多国产数据库也基于PG内核，作为国产数据库厂商，应该在数据库中开发一些内置功能，自动对这些问题进行管理，减轻DBA的运维负担。

有些Oracle DBA和我吐槽说PG的运维就像运维Oracle 9i甚至更早的8i很多东西都是手动或半自动的，要想让PG上的应用稳定运行，需要做更多的常态化的手工运维工作。

确实如此，Oracle的很多自动化运维作业都已经足够强大和足够智能，因此很多琐碎的重复性工作不太需要DBA介入了。而运维PG数据库则不能如此，如果你运维的PG数据库很大，并且是负载很高的关键业务系统的，那么你需要做很多额外的工作。

首先是Vacuum ANALYZE，这是两项工作，不过为了节约开销，在目前的大多数PG数据库中都会同时完成。在Oracle 中，表分析大多数情况下不需要手工操作，系统自动分析已经足够准确了。在PG可能不行，大家还记得Oracle 8i、9i时代我们如何做表分析吗?自动分析往往是不靠谱的，经常会因为表和索引的统计信息不准确而导致业务系统出现故障，因此一些关键表的分析都是手工进行的。在运维PG的时候也是如此，对于一些分布不均匀，数据量极大，负载极高的表，有时候需要个性化定制其 VACUUM ANALYZE的策略，甚至手工做这方面工作。

除此之外，我们还需要经常检查VACUUM的结果，防止VACUUM过程中因为SKIP了某些PAGE而造成的冻结问题。对于关键业务系统的DBA，这些额外的付出可以让你避免很多问题。其中特别常见的是，数据量没有改变的情况下，随着VACUUM残留越积越多，一条相同的SQL的执行效率会越来越慢。

如果大家对这个问题感兴趣，可以参考一下我几年前写过的一篇文章《PG AUTOVACUUM的优化小技巧》，这篇文章里有详细的介绍。

其次是监控和管理索引，特别是失效索引。PG数据库支持各种各样的索引种类，但是对索引的管理是最宽松的。在PG数据库的核心业务表上，乱建索引是很常见的事情，这会带来一系列的问题。因此定期分析与管理索引十分重要，否则会引发一些性能问题。另外PG失效索引的管理则更为要紧，在很多情况下，PG的索引都会失效，甚至早期版本中因为这方面的代码不严谨，创建中遇到某些问题失败的索引还是会残留下来。因此定期检查核心表的索引，以及清理或者重建失效索引也应成为日常工作的一部分。

第三是孤儿文件问题。孤儿文件会导致某些目录下存在很多垃圾，既占用空间，也影响文件系统的性能。对于此问题，我去年年底时候写过一篇文章，大家有兴趣可以去阅读一下。

第四是WORK_MEM相关参数的调整问题。PG的工作缓存管理与Oracle 8i或者之前的版本类似，无法自动管理，WORK_MEM相关参数设置完全依赖DBA手工工作，这些参数设置过大，可能会导致高并发时内存问题，设置过小，可能会导致排序等工作性能不佳，需要小心设置，并且随着业务数据的变化，也需要不断进行调整。DBA切不可在建库时设好就不管了，而是需要收集这方面的性能问题，从而做出更为精细的调整。

第五是OS层面的监控问题。Oracle DBA平时是不太管OS层面的事情的，当数据库出现了某些问题的时候才会去关注。PG DBA则不能如此，必须时时关注OS层面的一些关键变化，从而发现PG数据库可能存在的问题，并进行及时处置，才能避免运维事故。特别要关注的是CPU/内存/IO/网络等层面的资源使用情况和性能情况以及文件系统使用率的变化情况。对于核心业务系统来说，这些变化必须定期记录，经常性进行比对，才能从中发现隐患，避免重大的运维事故。

今天时间关系，我就先谈这五点，实际上，这五点是目前PG社区版本做得不到位的自动化维护作业引发的，DBA是在做补位工作。对于基于PG内核开发的国产数据库而言，这些方面完全是可以去做加强的。如果数据库自身的运维作业能够自动补上这方面的运维能力，那么DBA就省心多了。