一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题
【背景】
有一套运行在Oracle 11g RAC双节点内存分别为512GB、96颗CPU的医院系统，数据量大概3T，有10多张亿以上的分区表，并且是核心表，节假日业务高峰期间偶尔会出现卡顿现象，如果迁移到TiDB选哪个版本比较合适？相应的物理硬件如何规划？
从Oracle 11g RAC迁移到TiDB，硬件规划上建议先做POC验证。512GB/96C的配置对应TiDB集群建议：3台TiDB（32C/128GB）+3台TiKV（32C/256GB，NVMe SSD）+3台PD（8C/16GB），存储用NVMe，网络万兆以上。版本选7.5 LTS，稳定且分区表、并行DDL都成熟。
同等双节点堆配置迁过来，不一定更快。医院核心表更适合 TiDB 8.5 LTS，硬件按 TiKV 多节点、存算分离来规划，不要两台 RAC 对等替换。先做 SQL 评估和热点改造，分区表按主键/业务键重新分布，高峰压测后再切。
TiDB 推荐最新的LTS，建议针对性的做一些POC，具体的配置可参考官方提供的参数要求。
硬件只是小问题，主要还是软件侧吧
同样的两台机器，应该不会有Oracle快的。。
Tls版本了，性能需要根据也需要去poc了，节点肯定比之前多
建议选TiDB v8.5.x LTS版本比较稳妥，硬件上可以直接按照经典的3+3+3架构规划，也就是3台TiDB计算节点配32核128G内存，3台TiKV存储节点配32核256G内存并一定要上NVMe SSD，另外3台PD调度节点配8核16G内存就够了，考虑到你3T的数据量以及10多张上亿的大分区表，核心是要把分区键设计好确保业务SQL能走分区裁剪避免全表扫描，针对节假日高峰期出现的卡顿现象，强烈建议先拿这些核心SQL在测试环境做个POC实测，确认性能没问题后再敲定最终买多少硬件。
Oracle11g RAC 医院 HIS 核心系统迁移 TiDB 方案
现状：Oracle 11gRAC 双节点，512G/96C、96G/96C；总数据 3TB，十余张亿级分区核心表；节假日高峰偶发卡顿；医院核心交易系统，7×24 不可中断。
痛点来源：Oracle 单实例 CPU / 内存上限、热点分区争用、大表索引维护、RAC 节点间 GC 等待、高峰期 Buffer Cache 争用。
一、版本选型（生产核心业务）
首选：TiDB v8.1 LTS（企业版 / 平凯数据库）
- LTS 长期支持，Bug 修复周期长，适合医院核心，不选 DMR 短期版本；
- 相比 7.5LTS：分区表、大 DDL、内存管控、热点调度、Oracle 兼容、执行计划稳定性大幅增强；修复大量大分区表元数据、统计信息、内存泄漏问题；
- 全局排序、批量 DDL 优化、实例级 Plan Cache，对亿级分区表、节假日突发高峰更友好；
- DM 迁移工具对 Oracle11g 适配完善，支持 Range 分区迁移、增量同步、数据一致性校验；
- 不选 8.4/8.5 短期 DMR 版本，迭代快，医疗核心不建议追新；不选 7.5（虽为 LTS，但亿级多分区表场景内存与调度短板）。
重要提醒：医院核心业务强烈建议企业版（平凯数据库），提供 Oracle 迁移适配包、7×24 支持、SQL 诊断、热点调度增强、灾备工具；社区版无官方技术保障，核心系统风险高CSDN博…。
迁移约束：Oracle Range 分区表迁移到 TiDB 依然使用 Range 分区；TiDB 不支持 Oracle 的 Interval 自动分区，迁移后需业务层或脚本维护分区；序列、存储过程、触发器需要改造。
二、集群整体架构规划
业务特征：OLTP 为主（门诊、住院、收费），节假日突发尖峰；同时存在大量历史明细查询、报表统计，建议标准 HTAP 架构：
- TiDB：SQL 计算层，无状态，可随时扩容，前端用 TiProxy 做连接管理、负载均衡、连接池收敛
- PD：元数据与调度，3 副本强一致
- TiKV：事务存储层（3 副本，NVMe SSD），承载全部 3TB 业务数据
- TiFlash：列存分析副本，承担报表、DRG 统计、历史明细查询，隔离分析负载，避免报表把 OLTP 拖垮（解决原 Oracle 高峰期卡顿一大根源）
- DM：Oracle→TiDB 迁移同步组件；监控 Prometheus+Grafana；BR 备份
3TB 原始 Oracle 数据，TiDB 3 副本，开启压缩，TiKV 实际存储占用约 4‑5TB；TiFlash 额外一份列存副本，预留 5‑6TB 空间。
服务器硬件规划（物理机，不建议虚拟机，医疗核心）
网络硬性要求：**双万兆光口绑定，集群内部万兆，绝对不能千兆；TiKV 节点 CPU 必须支持 AVX2 指令集（TiFlash 依赖）**TiDB。
1）TiKV 节点（存储，共 5 台；3TB、多张亿级分区表，节假日尖峰）
TiKV 是性能瓶颈，单实例建议 16C‑24C/64‑128G，一台机器最多跑 2 个 TiKV 实例，不要多实例堆砌，避免磁盘 IO 争抢。
表格
| 配置项 | 参数 |
|---|---|
| CPU | 2×24 核（48 逻辑核），Intel Xeon |
| 内存 | 128GB |
| 磁盘 | NVMe SSD 3.84TB ×2（RAID0，给 TiKV 数据盘；独立 SSD 放 Raft 日志盘） |
| 网卡 | 双万兆光口 bond |
| 数量 | 5 台 TiKV（3 副本，冗余 2 台用于节假日弹性、热点负载分摊；后期业务上涨可继续横向加 TiKV） |
为什么 5 台 TiKV：10 + 张亿级 Range 分区表，极易出现热点 Region，更多 TiKV 节点有利于 PD 打散热点分区；节假日尖峰写入、查询压力大，3 台 TiKV 会出现 CPU 打满无冗余。
2）TiDB SQL 计算节点（4 台，无状态，可弹性扩缩）
应用连接全部走 TiProxy，TiDB 节点不直接暴露应用。
表格
| 配置项 | 参数 |
|---|---|
| CPU | 2×16 核（32 逻辑核） |
| 内存 | 64GB |
| 磁盘 | 1.6TB SSD（放日志，不需要高速盘） |
| 网卡 | 双万兆 bond |
| 数量 | 4 台 TiDB；2 台承担业务 OLTP，1 台专供 DM 迁移，1 台专供后台报表；高峰不够可临时再加 TiDB 节点，无需迁移数据 |
3）PD 集群（3 台，元数据，轻负载，必须 3 副本）
表格
| 配置项 | 参数 |
|---|---|
| CPU | 2×8 核（16 逻辑核） |
| 内存 | 32GB |
| 磁盘 | 1.6TB SSD（PD 对 IO 延迟敏感） |
| 网卡 | 双万兆 bond |
| 数量 | 3 台 PD，独立部署，不和 TiKV 混部 |
4）TiFlash 列存节点（2 台，HTAP，承担报表 / 历史查询，隔离 OLTP）
原 Oracle 高峰期卡顿很大一部分是大表报表查询挤占交易资源，TiFlash 把分析负载剥离出去，交易不受影响。
表格
| 配置项 | 参数 |
|---|---|
| CPU | 2×24 核（48 逻辑核） |
| 内存 | 128GB |
| 磁盘 | NVMe SSD 3.84TB ×2 |
| 网卡 | 双万兆 bond |
| 数量 | 2 台 TiFlash |
5）辅助组件服务器（1 台）
部署 TiProxy、DM‑master/DM‑worker、监控 Prometheus/Grafana、BR 备份调度机
- CPU：16 核，内存 32G，SSD 1.6TB，万兆网卡。
总物理服务器数量：5 (TiKV)+4 (TiDB)+3 (PD)+2 (TiFlash)+1 (辅助)=15 台物理服务器。
如果预算紧张可适度压缩：TiKV 最少不低于 4 台；TiDB 最少 3 台；TiFlash 最少 2 台；PD 必须 3 台，不可降低副本数。不建议组件混部，医疗核心故障隔离优先。
三、针对你的业务场景关键风险点与优化要点（多张亿级分区表、节假日尖峰卡顿）
1）分区表迁移与热点优化（重中之重）
- Oracle Range 分区原样迁移 TiDB Range 分区；关闭 TiDB 自动分区，脚本定时预创建未来分区，避免运行时 DDL 卡顿。
- 亿级表主键：若自增时间序列主键，开启
SHARD_ROW_ID_BITS打散 rowid，解决单 Region 写入热点；v8.1 支持全局变量默认控制，不需要每张表设置TiDB。 - 开启 PD 的分区亲和调度（partition‑level affinity），尽量把同一个分区的多个 region 打散到不同 TiKV 节点，避免单台机器扛一个大热点分区的全部流量TiDB。
- 统计信息定时更新，亿级分区表禁止全表 analyze，使用
ANALYZE PARTITION xxx，防止统计信息任务打满集群。
2）解决 “节假日高峰偶发卡顿”
- TiFlash 同步所有核心大表的列存副本，所有报表、DRG、历史明细查询强制走 TiFlash，不跑 TiKV OLTP 链路；
- TiDB 开启实例级 Plan Cache，抑制尖峰大量硬解析；
- 设置 TiKV 内存、线程池、compaction 限流，高峰期后台 Compaction 不抢占业务 IO；
- 节假日来临前，可临时在线扩容 TiDB/TiKV 节点，过完高峰缩容，无需停机、无需迁移数据，这是对比 Oracle RAC 最大优势。
3）迁移风险点 Oracle11gRAC → TiDB
- Oracle Interval 分区：TiDB 不支持，业务脚本预生成分区；
- 存储过程、函数、触发器、自定义类型：必须改写为应用层逻辑；
- Oracle RAC 的 sequence 与 TiDB auto‑increment 行为差异，需要验证主键冲突风险；
- DM 做全量 + 增量迁移，迁移完成必须做全量数据一致性校验；割接前搭建 Oracle 回退链路；
- 医院系统大量复杂多表 join，迁移前做完整业务压测，捕获差 SQL，绑定执行计划。
四、备份与高可用、灾备建议
- 使用 BR 做快照备份，定期全量 + 增量备份；禁止逻辑备份 mysqldump；
- 生产 3 副本，尽量跨 2‑3 个机架部署 TiKV 节点，机架级故障容忍；
- 可搭建异步灾备集群（TiCDC 同步），满足医院等保要求。
五、与原 Oracle RAC 简单对比
表格
| 维度 | Oracle11g RAC | TiDB v8.1 LTS |
|---|---|---|
| 横向扩展 | 受单节点内存 CPU 上限，扩展成本极高 | TiKV/TiDB 横向线性扩容，节假日临时扩容 |
| 亿级分区表 | RAC GC、buffer cache 争用，高峰偶发卡顿 | 分区打散，TiFlash 隔离报表负载 |
| 报表与交易混跑 | 互相争抢资源，高峰期业务卡顿 | HTAP，交易、分析物理隔离 |
| 运维 | RAC 维护复杂，打补丁停机风险高 | 在线升级，滚动更新，业务无感知 |
| 许可成本 | Oracle license 高昂 | 平凯企业版订阅模式，降低授权成本 |
六、如果硬件预算不足的折中方案
- TiKV 降到 4 台；TiDB 降到 3 台；TiFlash 保留 2 台（TiFlash 不能去掉，否则报表查询会冲击交易，高峰期卡顿问题不能解决）；
- 不建议 TiKV 一台机器跑 3 个及以上实例，IO 隔离失效，尖峰抖动会很严重。
如果你需要，我可以输出一份：
1）TiDB v8.1 针对医院 HIS 亿级分区表关键参数配置模板（tidb.toml/tikv.toml/pd.toml）；
2）Oracle11gRAC 迁移 TiDB 的割接与回退方案要点。
1 个赞
现有环境为两台小型机，单台配置96颗CPU、512GB内存（总计192颗CPU）。每逢节假日业务高峰，系统仍偶发卡顿，表明即使小型机架构也难以满足峰值负载需求。当前数据量约3TB，若I/O层面无瓶颈，则性能症结应集中在并发处理能力上。数据库选用Oracle 11g，据此推断系统上线时间大概率早于2020年。
综合上述因素，本次换代需支撑未来5~8年的业务发展。建议至少采购48台x86服务器（通常为双路配置），总CPU颗数为96颗。原因是：结合近六年芯片技术演进，以及海光、鲲鹏等国产处理器的单核性能表现，可按旧有算力与新算力约1:2的比例进行替换。相比原有2台小型机的192颗CPU，新方案以48台服务器承载96颗CPU，在采购成本大幅下降的同时，性能亦可得到有效保障。
数据副本这块，可以考虑配置为5副本，副本多一点盘也够（现在单盘3.84TB），但是可以保障绝对的安全性。
可以参考这个架构，把TP和AP业务做分离，TiKV的数量适当缩减（图里的TiKV承接了Oracle 30T数据）：
全闪NVME加25G网络吧，成本增加不会太多，但是性能提升明显
谢谢！
原存储是固态，两节点是物理的；迁移的话只能到虚拟机上，存储是NVMe性能较前好很多，稳定性和高峰并发可能要重点关注和测试下
谢谢！你说的很有道理，SQL性能评估、热点改造、分区表和模拟高峰压测确实需要重点测试下
谢谢！POC肯定是必须的
谢谢你的详细建议
谢谢你的建议，可能会采用虚拟化没有预算采购那么多服务器