​昨天一个微信群里在讨论一个数据库连接数​的计算公式，截图看不太清楚。我来描述一下。说是PG提供了一个连接数计算公式：连接数=核心数*2+有效磁盘数量。其中核心数不应该包含超线程数量，而是物理核的数量。这是一个十分典型的极限测试估算连接数的公式，主要目的是规避CPU方面存在的瓶颈。这种设置思路往往不会使用在普通的生产系统上，因为不管是OLTP系统还是OLAP系统，作为数据库服务器来说，会话会有大量的工作会产生在IO上，包括网络IO和磁盘IO，真正使用CPU的比例实际上并不高。对于OLTP系统来说大量的CPU使用都是小于一个时间片（大部分UNIX系统都是一个厘秒）的，很少会把一个时间片用满，因为

​昨天一个微信群里在讨论一个数据库连接数​的计算公式，截图看不太清楚。我来描述一下。说是PG提供了一个连接数计算公式：连接数=核心数*2+有效磁盘数量。其中核心数不应该包含超线程数量，而是物理核的数量。这是一个十分典型的极限测试估算连接数的公式，主要目的是规避CPU方面存在的瓶颈。这种设置思路往往不会使用在普通的生产系统上，因为不管是OLTP系统还是OLAP系统，作为数据库服务器来说，会话会有大量的工作会产生在IO上，包括网络IO和磁盘IO，真正使用CPU的比例实际上并不高。对于OLTP系统来说大量的CPU使用都是小于一个时间片（大部分UNIX系统都是一个厘秒）的，很少会把一个时间片用满，因为

​二十年前搞Oracle运维的时候，被折腾得最厉害的是共享池的问题，ORA-4031绝对是DBA必须面对的，也是最束手无措的错误。很多DBA面试官也会问大量的共享池诊断与优化的问题，虽然他自己对很多问题的了解也不过如此。今早的这篇文章的主体结构是昨天下班前写出来的，今早做了一些补充就发出来了。因为昨天上午我一直在做D-SMART这个部分的优化设计，这篇文章实际上是我这一天工作的一些总结。Oracle10G以后有了SGA动态分配的能力，而且服务器的内存也从MB级别进入到了VLM的级别，共享池和ORA-4031的问题也就见得少了。在D-SMART里，针对ORA-4031的监控功能比较少，只提供了一

​二十年前搞Oracle运维的时候，被折腾得最厉害的是共享池的问题，ORA-4031绝对是DBA必须面对的，也是最束手无措的错误。很多DBA面试官也会问大量的共享池诊断与优化的问题，虽然他自己对很多问题的了解也不过如此。今早的这篇文章的主体结构是昨天下班前写出来的，今早做了一些补充就发出来了。因为昨天上午我一直在做D-SMART这个部分的优化设计，这篇文章实际上是我这一天工作的一些总结。Oracle10G以后有了SGA动态分配的能力，而且服务器的内存也从MB级别进入到了VLM的级别，共享池和ORA-4031的问题也就见得少了。在D-SMART里，针对ORA-4031的监控功能比较少，只提供了一

​数据库，作为基础软件产品，其研发资源及成熟应用，需要较大投入和较长周期。开源作为一种新的软件开发协作模式，可大大加速这一过程。从上世纪九十年代，以MySQL和PostgreSQL为代表的开源数据库兴起；到近些年来国内数据库也纷纷走向开源道路。的确，开源能为企业及产品带来很大的收益，如加快研发周期、加速产品成熟、促进生态建设等。当然，出于商业化诉求，企业也纷纷摸索在开源条件下的商业模式，大部分企业在开源的同时也提供了商业版本。作为最终用户，是选择社区开源版本还是商业闭源版本，是个值得思考的问题。本文收集数据库领域几家代表性企业开源(社区)版本与商业(企业)版本产品功能及差异，并对这一差异背后的

​数据库，作为基础软件产品，其研发资源及成熟应用，需要较大投入和较长周期。开源作为一种新的软件开发协作模式，可大大加速这一过程。从上世纪九十年代，以MySQL和PostgreSQL为代表的开源数据库兴起；到近些年来国内数据库也纷纷走向开源道路。的确，开源能为企业及产品带来很大的收益，如加快研发周期、加速产品成熟、促进生态建设等。当然，出于商业化诉求，企业也纷纷摸索在开源条件下的商业模式，大部分企业在开源的同时也提供了商业版本。作为最终用户，是选择社区开源版本还是商业闭源版本，是个值得思考的问题。本文收集数据库领域几家代表性企业开源(社区)版本与商业(企业)版本产品功能及差异，并对这一差异背后的