★ FEATURED ARTICLE 1. 曾经的必选项如今成了备选项Oracle的霸权是怎么来的1.1 那个年代里Oracle确实没有对手先交代一下背景免得后文里的批评显得像情绪发泄。我是从Oracle 9i时代入行的后来一路经手10g、11g、12c到现在维护着几套19c生产环境。前阵子一个老同事打电话来聊选型说他们集团新项目的立项书里直接写了数据库优先考虑PostgreSQL和云RDSOracle作为备选。这个表述放在十年前是不可想象的但今天确实成了很多企业的常态。要理解这种变化得先明白Oracle当年的统治地位是怎么立起来的。上世纪九十年代到本世纪前十年严格满足ACID、能撑住高并发商业事务、又能横向扩展的数据库引擎Oracle几乎是唯一解。RAC架构把多个节点变成一个逻辑库这种能力在当时只有Oracle能做到Data Guard的物理备库、逻辑备库方案让企业第一次有了像样的容灾手段PL/SQL把复杂的业务逻辑塞进数据库执行性能也确实比应用层一次次往返调用强。说白了在那个硬件性能捉襟见肘、网络带宽昂贵、中间件技术还不成熟的年代Oracle的集中式设计恰好卡在了最佳位置。再加上它的营销体系、认证体系、合作伙伴生态一起织成了一张巨网。企业采购数据库时说Oracle没人会承担责任出了事全国都有能修的人说选个开源库反而要承担另类的风险。这种路径依赖一直延续到今天所以我看到很多批判Oracle的文章动不动说Oracle是智商税这是不公平的。它今天的地位是几十年真刀真枪打出来的问题在于这套打法和技术底座在今天的语境下越来越显得笨重。1.2 今天的去O声浪不只是价格问题现在网络上关于Oracle的讨论很多随手一搜就能看到一堆真实痛点监听日志膨胀、登录卡顿、等保加固命令繁琐、12c卸载不干净、19c安装折腾、补丁下载要账号、JDK下载还要Oracle账号。这些词条看起来琐碎但拼在一起就是一个整体印象——运维体验太差了。更关键的是这些痛点不是孤立的。开源阵营在同等可靠性下把运维复杂度降了一个数量级云厂商把数据库的容灾、备份、监控全部托管业务团队只要买一个连接串。当客户被问到你们数据库能不能收缩、能不能弹性扩缩容、能不能自助分析时Oracle的交付周期和成本结构往往让人倒吸一口凉气。于是去O就成了一种政治正确。平心而论去O运动里确实有过度唱衰的成分。很多批判文章只盯着Oracle的缺点却绝口不提它在关键业务里仍然稳如老狗。但反过来看Oracle自己也确实在吃过去积累技术红利的存量不少设计在今天的架构语境里已经有点历史的包袱的味道。这也是我写这篇文章的初衷把Oracle放在技术成熟度、成本模型、生态竞争和未来演进四个维度上重新审视一遍不吹不黑只为让正在做选型或者还在维护Oracle系统的人有个清醒的参照系。2. 技术债细数监听、登录、ASM、存储过程里藏着的旧时代2.1 监听日志与SQLPlus登录日常运维的老三样折磨网上搜Oracle运维相关的内容出现频率最高的几个问题一定是监听日志膨胀、SQLPlus登录慢、监听服务无法启动。这三件事我几乎每个月都要帮人排查一次而且根因来来去去就是那么几个。先说监听日志。Oracle 10g、11g时代listener.log是无限增长的监听进程每收到一个客户端连接请求就写一条日志按默认配置这个文件不会自动轮转。我遇到过一个生产库listener.log长到20多GB磁盘直接被打满所有新连接全部失败。这个坑到今天还有人在踩原因很简单很多人搞不清trace directory和alert log目录的区隔也不清楚log_status操作能动态切换监听日志。清理监听日志的正确姿势是lsnrctl set log_status off停掉监听写入然后备份旧的listener.log再开一个空文件最后lsnrctl set log_status on 恢复。这套步骤必须严格按顺序来如果先删文件监听进程的文件句柄还在磁盘空间依然回收不了这跟Linux下删除被进程占用的日志文件是一样的道理。再说SQLPlus登录缓慢。症状很典型sqlplus命令敲下去屏幕要卡几秒甚至几十秒才出来。真正的原因不外乎三类第一客户端在做DNS反向解析服务器端或者网络设备上没有配置反向解析超时重试拖慢了连接第二sqlnet.ora里的SQLNET.AUTHENTICATION_SERVICES和NAMES.DIRECTORY_PATH配置冲突导致解析走了错误路径第三监听器注册信息混乱服务器动态注册和静态注册打架客户端只能靠重试找到可用的服务名。处理思路也不复杂先关掉DNS反解环节——把sqlnet.ora里的NAMES.DIRECTORY_PATH改成tnsnames优先再把SQLNET.AUTHENTICATION_SERVICES明确设成(NONE)避免OS认证和密码认证互相干扰最后用lsnrctl services查看服务的实际注册状态必要时把监听停掉重启一次。还有一个高频操作是等保加固命令。Oracle在等保测评里涉及的加固项很多从密码策略、审计策略、最小权限到日志留存一套做下来至少要执行几十条SQL。麻烦在于不同版本的默认参数还不太一样11g的AUDIT_TRAIL配置和19c的unified audit配置完全两套逻辑抄来的脚本稍不注意就在目标库上报错。我现在的做法是把常用加固命令固化成内部文档每换一个版本先跑一遍全量检查而不是等测评机构来了才临时补。2.2 ASM、DUAL、trunc(sysdate)绕不开的黑话与玄学Oracle的技术体系里充斥着各种黑话。比如热词里就有oracle进入asm命令这其实是很多新手DBA的困惑点。ASM是Oracle的存储管理组件你要进ASM实例不是用sqlplus / as sysdba而是要登录到asmcmd或者用sqlplus / as sysasm。权限设计上sysasm和sysdba是分开的很多人就是在这一步栽跟头。更麻烦的是ASM实例的启动顺序和数据库实例的依赖关系如果不先启动ASM实例就启动库你会看到ORA-12518之类让人头皮发麻的报错。再比如oracle中dual最多存多大这个搜索词乍一看有点好笑但其实是新手对Oracle虚拟表机制的真实困惑。dual就是一个单行单列的虚拟表用来执行select 1 from dual这种不需要真实表参与的SQL。它在物理存储上没有对应的数据文件也不存在最多存多大的问题任何函数计算、常量和伪列引用都能挂在dual下执行。理解了它的设计意图再去查trunc(sysdate)这类日期函数就会顺很多。trunc函数并不是Oracle独有但Oracle里用的场景极其频繁截到天、截到月、截到年可能就改变了整条SQL的谓词条件直接影响索引使用这些细节全是要靠经验积累的。2.3 存储过程与分页写法两代开发范式的碰撞Oracle的存储过程承载了很多传统应用的核心逻辑。PL/SQL的性能确实好批量提交、游标控制、包内变量写出来像一门完整的语言。但它的调试和版本管理是个大问题。数据库里塞了几万个存储过程的系统我见过不少改一个参数要沿着调用链路查半天想重构其中的一段逻辑还得确认没有别的过程在依赖它。这种耦合在云原生的微服务架构里简直是一个反模式。新一代开发者普遍不喜欢把业务逻辑写进数据库再加上Python连接Oracle时还要处理游标、事务边界、隐式转换这些细节整套生态都显得和现代开发流程不太合拍。分页是个更具体的例子。Oracle传统上用ROWNUM做分页写法是三层嵌套select逻辑绕可读性差而且ROWNUM赋值的时机很容易踩坑where rownum 5这种写法永远查不到数据因为ROWNUM是在结果集产生前逐行编号的先过滤后编号编号只从1开始。直到12c加入了OFFSET FETCH FIRST子句分页写法才算向SQL标准靠拢。可偏偏很多存量系统还跑在11g上开发人员就不得不用那套该死的老写法还要面对分页大偏移量时全表扫描的性能问题。2.4 安装与卸载的仪式感12c删不干净、19c装不上Oracle的安装卸载也是经久不衰的吐槽点。12c卸载不干净是家常便饭卸载程序跑完以后注册表里还残留一堆以Oracle开头的键值/etc/oratab里还留着行目录删不干净服务项还在。想彻底清掉得手工遍历注册表核查服务列表再删安装目录有时还得删掉crs配置。这种体验放到今天和云数据库在网页上点几下就完成创建和释放完全不在一个时代。19c安装则是另一类痛点。Linux环境下光是前置准备就有很多讲究内核参数、shm大小、大页配置、磁盘IO调度、ulimit限制。我帮人排过一个ORA-12518最后发现是/dev/shm挂载大小不足process和session一多共享内存段分配失败监听根本分发不了连接。还有一次是装了数据库之后监听服务随机无法启动查了半天发现/etc/hosts里的主机名和实际hostname不一致。这类问题和数据库本身的能力强弱无关但积累起来就在团队里形成了一个印象Oracle很重很脆没点专人经验真伺候不了。3. 成本账本License、补丁与人力成本的三重递进式消耗3.1 按CPU核数计费带来的核数焦虑Oracle的商业授权模式是它今天被诟病最多的地方。核心计费分两种按NUP命名用户数和按CPU核数。关键业务系统普遍走CPU核数授权因为用户数量根本无法准确统计。问题来了Oracle对CPU核数的计算标准非常苛刻物理机和虚拟机还有不同口径超线程开了以后某些授权规则甚至要按物理核和逻辑核的较大值来计算。这导致虚拟化环境里你明明只要4个vCPU但Oracle授权可能要求你按宿主机上所有物理核来买。很多时候企业买的不只是数据库软件还要为RAC、Partitioning、Compression、Advanced Security、Data Guard这样一个个option单独掏钱。这些options每个都是单独授权、单独计费价格比基础版还贵。算下来Oracle的许可证费用动辄几百上千万确实是很多企业IT预算里的核弹级开支。更让人头大的是Oracle的营收模式鼓励持续性绑定。你买了授权每年还要交大约22%的续保费用才能继续获得补丁和技术支持。几年叠加下来续保费用总和都能再买一套新授权了。如果不续保Oracle会停止对你提供补丁这在等保和行业合规审计里非常麻烦等于被绑架。所以很多企业嘴上说要迁移行动上却还在老老实实续费因为这个决策链条太长迁移风险太大。3.2 补丁下载和版本升级一道没有尽头的工序网上有个热词叫jdk下载 oracle账号看起来很荒谬但真实反映了Oracle生态的封闭性连下载一个JDK都需要注册Oracle账号、接受许可协议、登录验证。补丁就更不用说了每个季度一次的CPU补丁要从My Oracle Support上手动下载补丁之间还有依赖关系有的要先打这个再打那个顺序错了就会报opatch冲突。我见过很多运维团队的补丁流程就是下载、打补丁、回滚、再打补丁反复折腾每次都要申请变更窗口。版本升级的成本更是被严重低估。从11g迁到19c不是简单装个新版本然后把库导进去就行。字符集、分区表、优化器统计信息行为、SQL执行计划变化每一样都可能让生产系统在升级后性能骤变。我做过一个项目升级后发现一张日增千万行的大表原来走索引的SQL在19c里改走了全表扫描因为19c的优化器对直方图统计的敏感度比11g高了很多。这种问题只能通过全量回归测试发现周期和成本都不小。3.3 人力账会Oracle的人越来越贵、越来越少和License成本并行的是人力成本。Oracle DBA是一个很窄的工种精通RAC、Data Guard、ASM、调优又熟悉等保合规的老DBA市场上越来越难找。原因很简单这个方向的新人流入越来越少而老一批DBA很多转型去了云架构或SRE。团队里一旦出现人员变动Oracle系统的维护就直接断层。新招进来的运维工程师更熟悉的是Kubernetes、Docker、开源监控系统面对Oracle的告警日志和AWR报告往往无从下手。这带来的连锁反应是企业为Oracle技能支付的人力溢价越来越高但又不得不付因为出了问题时能修复系统的人就那么几个。这个成本在财务上不太好直接量化但每个做过Oracle运维的管理者心里都有数。4. 生态阵地失守的三条战线开源、云厂商、迁移工具链4.1 开源阵营从能用进化到好用过去大家不用开源数据库核心顾虑是可靠性、性能、工具链和管理能力。这些年PostgreSQL和MySQL的进步是实打实的。PostgreSQL的逻辑复制、JSON支持、窗口函数、并行查询在OLAP场景和混合负载场景下已经不输Oracle而且它还是完全免费、没有license合规审计压力的。MySQL虽然在高并发复杂查询上弱一些但配合分布式中间件在互联网海量业务里的表现早就经过了大规模验证。更不要说TiDB、CockroachDB这类原生分布式数据库分库分表后还能做分布式事务这件事已经超出了Oracle本质上是单体架构的能力上限。这些产品带来的不仅是功能对齐更是运维文化的改变开源社区的问题库、公开的源码、丰富的工具生态让问题响应速度比Oracle的官方工单快了不知道多少倍。我经常和团队说Oracle的问题和PostgreSQL的问题最大的差别不是难度而是可检索性和可复现性——开源库踩了坑大概率在GitHub或技术社区有人踩过同样的坑并且已经把解决方案贴出来了。4.2 云厂商的托管整合打法云数据库是另一条战线。以AWS RDS/Aurora、阿里云RDS、腾讯云TDSQL为代表的产品把高可用、备份、监控、扩容这些Oracle至少要配一整套人来维护的能力全部做成了开箱即用的服务。云厂商甚至提供了DMS、DTS这类数据同步工具让业务可以在不需要业务停服太久的情况下完成数据迁移。还有一个现象很有意思Oracle自己也在OCI上推出了自治数据库号称可以自动打补丁、自动调优、自动防护。这等于承认了一个事实——传统Oracle DBA手工运维的模式已经太低效了连Oracle自己都想甩掉这部分成本。从业务角度看云数据库的成本模型更清晰按量付费没有几百万的授权门槛扩容和缩容是分钟级别的。当数据库运维成为一个云服务而不是一个需要长期供养的专家团队时Oracle这种重资产的集中式数据库商业逻辑自然受到了冲击。4.3 开发者生态新工具链在快速绕过Oracle开发者的习惯变化也很能说明问题。现在做数据操作新一代工程师最顺手的是Python连接数据库处理分析类任务甚至会直接选Pandas加数据库很少再有人去写一坨PL/SQL包。Oracle也做了一些顺应趋势的努力比如Python驱动python-oracledb的thin模式不再强制依赖Oracle Client这个变化对开发者确实更友好了。但整体来说Oracle提供的现代化开发体验还是偏少的。尝试Oracle的运维自动化、用CI/CD做数据库变更管理都会发现它的工具链密度远不如开源生态。拿Schema变更来说PostgreSQL有Liquibase、Flyway等一堆工具Oracle用起来兼容性总有些小毛病。更不用说很多新式玩法比如MCP用来连接数据库做自然语言查询热点都在PostgreSQL和云数据库上Oracle的适配和支持总是慢半拍。生态重心一旦偏移存量系统的维护体验只会越来越差。5. 批判之外说句公道话哪些场景Oracle仍然难以被替代5.1 核心交易与强一致场景里它还是定海神针网上很多文章把Oracle说得一文不值但我做过金融、电信、制造等行业的核心系统我必须说一句公道话在最核心的交易场景里Oracle的稳定性和一致性依然是很多开源产品追赶的目标。所谓不敢换不是感情因素而是真实的风险考量。RAC加Data Guard的架构已经跑了十几二十年每一个故障模式都被人研究过大部分问题都有成熟的处理手册。而对很多开源产品来说真正的极端故障场景下的表现还没有经历足够长的考验。尤其在强一致、高并发、要求严格事务隔离的业务里Oracle的多版本并发控制、锁机制、粒度精细的恢复能力骨子里带着一股为关键任务而生的味道。换到开源库不一定是做不到但需要团队做更多的自研和深度定制这个隐性成本往往被免费和开源的表象所掩盖。5.2 存量系统的迁移成本远高于想象还有一层原因是存量包袱。很多老系统里的存储过程有几千个业务逻辑、定时任务、报表计算全在里面。迁移到目标数据库时一类是SQL方言迁移一类是存储过程逻辑重写还有一类是数据一致性核对这三样里面任何一样都是时间黑洞。项目论证时可能觉得工程期是几个月真正开工后才发现光是存量SQL的语法改造和性能调优就够团队忙一年以上。这也是为什么很多企业最后选择双轨运行而不是一步切换先在Oracle旁边跑一套新库同步数据灰度验证再用很长的时间窗口逐步替换。可以确定的是这个过程并不轻松所以骂归骂买归买在相当多行业里还是会继续存在。6. 身处Oracle体系中的公司和工程师我的实际应对方案6.1 先做许可和成本审计再谈动不动刀如果你所在的公司还在用Oracle我的建议是先别急着把迁移列为第一优先级。你可以先做一次彻底的许可盘点现有授权覆盖了哪些功能模块是不是买了用不上的Partitioning或ADG虚拟机环境里实际分配的vCPU和许可要求的差距有多大很多企业付了过高的授权费用仅仅是因为当年签约时多买了一堆以防万一的option。把用不上的option从续保合同里去掉是立竿见影的成本削减。另一个思路是用Oracle的免费版本做边界系统。Oracle XE的免费授权其实能满足很多低负载场景但要注意免费版有资源上限不适合拿来承载主数据库。对我来说更稳妥的路径是把真正核心的交易库保留在Oracle上把报表、数据分析、非核心应用逐步挪到更轻量的开源数据库或云数据库上。这个渐进式策略能控制风险同时让团队积累新技术的经验。6.2 渐进式数据迁移的操作思路做渐进式迁移时我会优先选边缘系统作为试点。比如一个内部运营系统数据量不大业务逻辑不复杂把它整体迁到PostgreSQL或云RDS积累从Oracle到目标库的SQL改造成熟套路。试点跑通后再处理中等复杂度的系统。真正牵动全公司的核心账务系统如果短期无法迁移至少要保证它不再新增基于Oracle特性的业务逻辑。迁移过程中数据同步是核心。我用过Oracle GoldenGate和云厂商的DMS来将增量日志实时同步到目标库先把目标库作为只读副本运行一段时间检验数据一致性和业务兼容性。等到两边数据齐平了再通过切换读流量、写流量、灰度放量的节奏一步步把业务从Oracle上摘下来。这个过程的经验非常宝贵比单纯看一堆去O白皮书有用得多。6.3 工程师个人该怎么选别押上全部身家最后聊点个人层面的东西。我见过不少年轻工程师问现在学Oracle还有前途吗我的答案是学它的底层原理是绝对值得的但别把全部职业赌在单一技术上。Oracle的事务机制、锁体系、优化器逻辑、备份恢复原理这些底子放在任何数据库上都不过时。你理解了undo和redo的工作机制再看PostgreSQL的WAL和MySQL的redo log基本是一通百通。真正的风险不在于Oracle没用而在于你不去拓宽技术面。未来的数据库世界一定是多元的会Oracle、懂PostgreSQL、玩得转云数据库还理解分布式一致性才是真正有竞争力的数据库工程师。我自己的做法是把Oracle维护手册和问题库吃透保证现有系统稳定同时花时间研究开源数据库和云数据库的最佳实践。这样既能在存量系统里输出价值又能在新技术选型时给团队提供可靠的决策依据。说到底技术和商业环境的变迁不会因为谁吐槽几句就停下来提前把自己摆到能看清变化的位置上才是对职业最负责的选择。
阅读完成 · 觉得有帮助？
