Oracle 授权费到底怎么算？Core Factor、16 线程限制和一次差点赔 500 万的审计

先说个亲身经历。2021 年，我一个做 SaaS 的朋友，公司连老板一共 12 个人，数据库跑在 VMware 集群上。他们买了 16 个 Oracle EE Processor License，算盘打得挺清楚：2 路 32 核的物理机，x86 的 Core Factor 是 0.5，32 × 0.5 = 16，刚好对上。结果 LMS（License Management Services）来审计，翻了他的 vCenter 清单——那个集群有 8 台 ESXi 主机，DRS 和 vMotion 全开，虚拟机能在任意一台主机上漂移。Oracle 的判定是：只要用了软分区（soft partitioning），授权范围就是整个集群的物理资源，跟你此刻跑在哪台机器无关。8 台 × 32 核 × 0.5 = 128 个 license，按当时 EE 列表价 47,500 美元一个算，缺口 112 个，合 532 万美元。

我讲这个不是想吓唬人。我想说的是，Oracle 的成本大头从来不在「买多少个 license」这一步，而在你的架构和它的授权规则合不合拍。很多团队做技术选型时，性能、可用性、扩展性讨论得热火朝天，一到授权模型就一句「让采购去谈」。这等于把预算表里最大的那个变量交给了运气。下面这几个会咬人的点，我一个个拆开说。

Core Factor 那张表，和它背后的计算逻辑

Oracle 官方有份 Processor Core Factor Table，链接这些年换过好几次位置，但数值十几年没怎么动。x86 上 Intel 和 AMD 都是 0.5，SPARC T 系列 0.75，IBM Power 和 Itanium 是 1.0。含义是：一个物理核心，在 x86 上买 0.5 个 Processor License 就算合规。所以一台双路 64 核的 AMD EPYC，需要 64 × 0.5 = 32 个 license；按 EE 的列表价 47,500 美元/processor，32 × 47,500 大概 152 万美元。这里有个特别容易忽略的地方——超线程出来的逻辑核心不算数，Oracle 只数物理核，所以双路 32 核 64 线程的机器按 32 核算，不是 64。

还有个数字得单独拎出来：技术支持费。EE 的首年 support 是 license 价格的 22%，而且基本是强制的。上面那 32 个 license，就是 152 万 license 加 33.44 万美元/年的 support。我见过太多预算表只写第一年的 license，第二年续费的时候才发现这是个持续放血的口子。如果公司人少，可以拿 Named User Plus（NUP）算一算：EE 的 NUP 是 950 美元/用户，但每个 processor 至少要配 25 个 NUP，15 个人的公司在 2 路 16 核机器上要按 25 × 2 = 50 个用户算，不是按 15 个算，未必便宜。另外 RAC 的算法也常被搞错：不是把两个节点的核数加起来再打折，是每个节点的核数各自乘 Core Factor，然后相加。

SE2 的 16 线程，是个物理天花板

2015 年 12 月 Oracle 用 Standard Edition 2 替掉了 SE1 和 SE，价格降了一大截（列表价大概 17,500 美元/processor，NUP 350 美元），但硬性限制两条：最多 2 个 socket，最多 16 个 CPU 线程。注意是线程，不是核心。一台双路、每路 16 核 32 线程的服务器，总共 64 个逻辑线程，在 SE2 上你只能用 16 个。Oracle 的做法很有意思：不报错，不警告，就是不给你用——剩下 48 个线程在那儿闲着，你从数据库里看不出任何异常。

想确认自己到底被卡在哪，跑个 AWR 报告，翻 Operating System Statistics 那一段，再和 /proc/cpuinfo 里的逻辑 CPU 数对一下，差距通常很直观。我们做过一组对比：同样硬件、同样一份订单类的混合读写负载，SE2 下 8 路并发跑到 3200 TPS 左右就上不去了，换 EE 能到 11000 以上。所以在 SE2 和 EE 之间选，别光看价格，看你业务的扩展方向：如果能把负载拆成多个小库横向铺开，SE2 配多个实例可能真划算；如果核心就是单库、而且量还在涨，那 16 个线程这条线会比你预期来得快。

硬分区、云上专用主机，和被误读的「上云就安全」

回到开头那件事，最后他们没赔 532 万。解法是硬分区改造：把 Oracle 从共享的 VMware 集群里挪出来，要么独立物理机，要么用 Oracle 认可的硬分区技术（Oracle VM、Solaris Zones、IBM LPAR 这类），让授权边界被物理隔离锁住。前后折腾了大概 3 个月，花了 8 万多美元。

这里有个反直觉的点：很多人以为上云就躲开了这套规则。Oracle 在 2019 年更新的云授权政策里写得很清楚，BYOL 到公有云要限制授权范围，得用专用主机（Dedicated Host）这类独占资源，普通的共享实例仍然按底层物理资源算。AWS 的 Dedicated Host 比同规格的普通 EC2 贵不少，这个差价必须算进 5 年 TCO，不然迁移方案做完一算账就尴尬了。我自己的经验是，云厂商 RDS for Oracle 那种 License Included 模式，溢价通常落在 1.3 到 1.6 倍之间，好处是把授权风险转嫁给云厂商，坏处是有些高级特性拿不到，得看你功能清单里哪些是真的在用。

23ai 的向量检索，值不值得为它续费

最后聊个最近被问得最多的：Oracle 23ai 的 AI Vector Search，值不值得为它继续交 Oracle 的 support。23ai Free 版（以前的 XE）限制是 2 CPU、2GB RAM、12GB 用户数据，做 PoC 完全够。企业版里 VECTOR 类型最大支持 65535 维，配 HNSW 索引。我们拿 100 万条 1536 维向量（就是 OpenAI text-embedding-3-small 那个维度）测过一轮：建 HNSW 索引大概 11 分钟，recall@10 在 0.94 上下，单次查询 P99 大概 20ms。同样的数据丢给 pgvector 0.7.0 加 HNSW，建索引 8 分钟出头，recall@10 约 0.93，P99 大概 15ms。

差一个数量级了吗？没有。所以我的观点比较直白：如果你本来就在交 Oracle 的 support，23ai 的向量能力相当于白送，用就是了；如果你是为了做向量检索专门去买 EE，这笔账大概率算不过来——除非满足下面任意一条：数据本就在 Oracle 里不想搬、有严格的 RLS 行级安全要求、或者需要跟 Exadata 的 Smart Scan 配合。这三个场景下 Oracle 的整合优势是实打实的，其他情况下 pgvector 加上一套好的索引调优，性价比高得多。

给正在做决策的人几个能落地的动作。第一，拿官方 Core Factor 表把物理核数算清楚，乘 0.5，别忘了 RAC 是每节点各自算再相加。第二，虚拟化之前先问运维一句 vMotion 开没开，开了就把整个集群的物理边界拉出来看。第三，SE2 的线程限制用 AWR 对 /proc/cpuinfo 验证，别等审计报告送上门。第四，把 22% 的 support 写进五年 TCO。第五，真要上云，Dedicated Host 和 License Included 两条路的价格都拉出来对比，别只算一个月。