记得19年底我刚刚来我现在服务的客户这时，还是每个业务管自己的数据库，整个中心维护了超过30套数据库，其中包括了RAC和单实例，几乎没有容灾。
那时候我接手了前任DBA搭好的一套4节点Oracle 12.2 RAC环境以及2个月内完成10套数据库以上的迁移和搞定ADG的任务。回想起来丧心病狂的。
在这套库有一体机替换之前，最多的时候承载了32个PDB，其中生产约20个，完成这一系列操作我们究竟实现了些什么：
约30套数据库变成了一套，节约服务器至少30台，维护压力、维保成本、整体能耗显著下降
原来需要大量的网络链路、网络资源以及存储链路资源极大减少
原来一个生产业务需要一个数据库维护人员（专业或非专业），现在仅需一个高级DBA即可完成集中管理
所有承载业务统一离线备份与异地实时灾备
等等等等
上面这些对于客户和业务厂商来说都是一大进步和简化，用较少的资源完成更多的需求。后面Exadata一体机来了，除了灾备环境以外，生产库已经完全脱离除网络环境以外的外部硬件依赖，同时提供了强劲的数据库能力。
国产化趋势的来临，无论是集中式还是分布式，都出现一个问题，又要将合一了的数据库拆回到一个业务一套数据库（不管是不是所谓的多租户环境）。服务器用量回去了，甚至比原来还要多得多；管理压力上去了，尤其是分布式，服务器和组件数量都上去了；能耗。。。节能减排感觉有活回去了；最后就是性能和稳定性还不一定好。
本来技术的进步是可以带来架构、维护的简化的，结果现在看来大多数情况可能会越来越复杂，为啥？这个我们还是得正视差距。我不抵触国产，也不抵触分布式，也不是O吹，但是如此内卷...还需努力啊...
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31466763/viewspace-2998146/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- 胖头鱼的技术专栏-479 如何高效地将喂给 AI 的数据搬过去（20261015）
- 胖头鱼的技术专栏-478 Agent 成了新用户，数据库要接住它的下一步（20261014）
- 胖头鱼的技术专栏-477 26ai新特性实战：表达式分区（20261013）
- 胖头鱼的技术专栏-476 26ai新特性实战：聚合过滤（20261012）
- 胖头鱼的技术专栏-475 蹭到最后，就没人摆摊了（20261010）
- 胖头鱼的技术专栏-474 从能跑到能上线：PG SplitJSON 0.2.0 和 0.1.0 差在哪
- 胖头鱼的技术专栏-473 26ai新特性实战：日历函数（20261004）
- 胖头鱼的技术专栏-473 改JSON的一个字段不再重写整篇：我给PostgreSQL 18写了个扩展
- 胖头鱼的技术专栏-472 26ai新特性实战：无 FROM 子句的 SELECT 语句（20261003）
- 胖头鱼的技术专栏-471 数据库优化的三层楼——为什么多数人总在第二层打转
