Oracle XStream 技术揭秘：高吞吐 OLTP 场景下的 CDC 影响评估 ｜ 技术实践
点击查看原文>
2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！
要点速览
Snowflake Openflow Connector for Oracle 是 Snowflake 全新的原生解决方案，可将运营数据直接流式传输到 Snowflake，无需复杂的第三方中间件。然而，数据库管理员（DBA）有时会担心，启用这类变更数据捕获（CDC）管道会破坏其生产环境的稳定性。
为了验证大规模场景下的性能和稳定性，我们使用真实的 TPC-C 工作负载对该连接器进行了压力测试（以 XStream 模式运行），该负载可持续保持约 37,000 笔复杂事务/秒。
结果如何？
Redo 影响：线性增长，而非指数级增长（日志量约增加 47%）；
CPU 开销：几乎可以忽略，约为 3%（主要由日志 I/O 驱动，而不是 XStream 进程本身）；
吞吐量：除非你的数据库已经在磁盘写入方面受到 I/O 限制，否则对事务延迟没有影响。
稳定性与新鲜度之间的冲突
对于 Oracle DBA 来说，使用 CDC 有时听起来像是一种威胁。
你的职责非常明确：保护生产 OLTP 系统。你最不愿看到的情况，是某个外部进程激进地争抢 CPU、导致缓冲区缓存抖动，或阻塞日志写入器（LGWR）。当数据工程师请求启用 XStream Out，以便将数据实时摄取到 Snowflake 时，“不行”可能会成为你的默认回答。
我们理解这种怀疑。在 Snowflake，我们将关键任务型 OLTP 源数据库视为至关重要。我们知道，如果作为记录系统的运营系统宕机，下游分析也就无关紧要了。
然而，AI 对近实时数据的需求不会消失。为了弥合数据工程对数据新鲜度的需求与 DBA 对稳定性的需求之间的差距，我们不再猜测，而是开始测量。
我们针对 Oracle XStream Out 运行了高强度工作负载，以确定它在 AWS 中运行的高吞吐量、中等规模系统上的确切“成本”。以下是数据、我们发现的摩擦点，以及能够确保生产环境安全的架构模式。
测试设置：对生产现实进行压力测试
我们不想测试一个基础的 “Hello World” 场景。我们希望在一个配置适中的数据库上模拟一个真实、嘈杂的企业工作负载，以了解压力点在哪里。
环境：
数据库：AWS RDS Oracle 19c Enterprise Edition（db.m6in.16xlarge）；
计算：64 个 vCPU，256 GB RAM；
存储：io2 Block Express（200,000 预置 IOPS），用于处理写入密集型工作负载。
工作负载：
工具：HammerDB TPC-C（用于 OLTP 压力测试的行业标准，包含插入、更新和删除操作的混合负载）；
规模：100 个仓库，100 个并发虚拟用户；
吞吐量：持续约 37,000 TPS（每秒事务数）；
时长：每个场景持续运行 60 分钟。
测试场景：
我们将基线场景（无 CDC）与三种配置进行了比较：
补充日志（仅主键）；
补充日志（ALL 列）；
启用完整 XStream Capture。
我们用于本次测试的环境是有意设置成“中端”和中等规模的配置。运行在 AWS RDS 服务上为我们的 Openflow Connector 测试提供了一些便利；不过众所周知，在高度虚拟化的基础设施（例如 AWS RDS）中运行数据库，对于高性能工作负载而言并不是最优选择。这也是为什么 AWS 目前正在其数据中心内广泛推出对 Oracle Exadata 和 Autonomous Database 服务的直接支持。
使用 Oracle Exadata，客户通常可以实现超过 100 万 TPS，而 Exadata X11M 能够以惊人的 31 TB/秒扫描数据，并以超过 100 万 IOPS 的速度写入数据。在这些更企业级的系统上运行 XStream 的 DBA，可以预期获得比我们下面展示的结果更好的性能和更优的结果。
结果：来自 AWR 报告的证据
“Redo 爆炸”神话被打破
Oracle AI Database 和 XStream 并不强制要求启用完整补充日志（LOG DATA (ALL)），但对于 Snowflake Openflow Connector 而言，这会极大简化以完全一致性管理数据的过程，因此我们要求开启该功能。DBA 最常见的担忧是，为 ALL 列启用补充日志会产生 5 倍或 10 倍的日志量。
数据：Redo 使用量并没有出现指数级爆炸；它是线性增长的。该数据来自 HammerDB TPC-C 测试中典型的插入、更新和删除操作混合负载。
基线 Redo：每笔事务约 6.79 KB；
启用 ‘ALL’ 列日志后：每笔事务约 10.96 KB。
这代表日志生成量约增加 47%（约 1.5 倍）。虽然这一增长显著，但它是可确定的。它并不是 FUD（恐惧、不确定性和怀疑）讨论中经常提到的那种难以管理的 500% 激增。此外，在当今监管日益严格的世界中，对于任何受 GDPR、HIPAA 或 SOX 合规政策约束的行业来说，拥有完整、可审计、详细的数据“前镜像”历史记录，都是一个非常好的做法。
容量估算公式：
预计 Redo 量 = 当前量 * 1.5
CPU 开销可以忽略不计
XStream 本身极其轻量。观察到的总 CPU 开销仅约为 3%（使用率从约 33% 上升到约 36%）。
洞察：这一 CPU 增长的大部分来自数据库引擎写入额外的 Redo 内容（补充日志）。实际的 XStream Capture 后台进程几乎没有增加任何计算负载。
吞吐量与 “log sync” 瓶颈
我们的测试将数据库推至约 37,000 TPS。在这一速度下，当 XStream 完全启用时，我们观察到总事务吞吐量下降了 8–9%。
为什么？这一下降与增加的日志量触及存储限制直接相关，而不是因为 XStream 锁定了数据库资源。
基线约束：即使在启用 CDC 之前，我们的测试也已经受 I/O 限制。（这并不罕见，因为与更优的裸金属主机相比，RDS 基础设施的 IOPS 性能通常较差。）我们的 AWR 报告显示，数据库将约 74% 的 DB 时间花在提交和回滚上（具体为 log_file_sync）；
好消息：尽管负载很重，每次同步的实际延迟仍然非常优秀，低于 2ms（平均 1.75ms）。磁盘子系统速度很快，只是被数据量压垮了；
CDC 影响：启用 XStream 要求向这条已经饱和的通道写入 47% 更多的数据（补充日志）；
结果：写入频率本身使日志写入器达到饱和，导致吞吐量下降约 9%。
战略要点：CDC 的成本主要体现在 I/O，而不是 CPU。如果你的生产数据库已经让 Log Writer（磁盘 I/O）达到饱和，启用补充日志会加剧这一瓶颈。然而，如果你有 I/O 余量，对事务吞吐量的影响将会很小。
DBA 最佳实践
基于这些数据，以下是安全启用 Snowflake Oracle Connector 的检查清单：
检查你的 I/O 余量（至关重要）
在启用 CDC 之前，检查当前的 log_file_sync 等待情况。
如果你已经经常看到超过 5–10ms 的等待，请先解决存储 I/O 瓶颈；
CDC 增加的是数据量，而不是延迟——但如果通道已满，数据量就会变成延迟。
调整日志大小
传统的 500MB Redo Log 文件将不再够用。
建议：将 Online Redo Log 大小增加到 4GB–8GB；
原因：随着 Redo 量增加 47%，小日志会导致频繁的日志切换（检查点），从而暂停数据库。
“安全阀”：配置 STREAMS_POOL_SIZE
不要让 Oracle AI 源数据库通过 Shared Pool 自动管理这一部分。你必须隔离 XStream 内存。
建议：分配一个专用的 STREAMS_POOL_SIZE（我们建议从 2.5 GB 开始）；
原因：这相当于一个断路器。如果复制管道变慢，或事务量激增，该池会被填满。当它填满时，XStream 会暂停。它不会占用你的缓冲区缓存。它不会导致实例崩溃。它只会产生延迟。这会优先保障 OLTP 稳定性，而不是复制延迟。
精准日志，而不是“全局开启”
在我们的场景中，我们记录了所有内容，以证明这一点。在生产环境中，你绝不应该运行 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS。
建议：仅对正在复制的特定表启用补充日志。Snowflake Openflow Connector for Oracle 要求记录 ALL 列，以完整重构负载内容，但这应当精确应用于范围内的表，而不是整个数据库；
命令：ALTER TABLE schema.table ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS。
请注意，这也可能是你重新审视业务需求和义务的好时机，因为对于关键任务数据表而言，可能还存在其他与合规相关的原因，需要启用额外的补充日志。
信任但要验证：监控脉搏
你无法管理无法测量的东西。使用以下特定视图，确保 XStream 保持健康，并遵守其资源边界：
V$XSTREAM_CAPTURE：检查 STATE（应为 CAPTURING CHANGES）和 LATENCY_SECONDS。这是你的主要延迟指标；
V$STREAMS_POOL_STATISTICS：监控 TOTAL_MEMORY_ALLOCATED。如果它达到你的 STREAMS_POOL_SIZE 上限，你就知道安全阀正在发挥作用（也能知道复制为何可能暂停）；
V$XSTREAM_OUTBOUND_SERVER：确认连接器已连接，且状态为 SENDING CHANGES。
“零接触选项”：下游捕获（适用于极大规模）
如果你的生产数据库 CPU 长期运行在 80% 以上，或生成很高的 Redo 量（例如每天 1TB 到 20TB+），在主库上运行任何额外进程可能并不适合你。
建议：使用 Downstream Capture 模式；
方式：将你的 Redo Logs 发送到一个辅助的、被动的 Oracle 实例（下游挖掘数据库）。XStream 在那里运行；
结果：生产源库上没有任何 CPU 或内存占用。对生产环境的唯一影响，是传输日志所需的网络带宽；
附带收益：你的下游挖掘数据库只需根据 redo logs 进行规模配置，通常比主数据库小得多；并且该挖掘数据库可以运行最新的 Oracle AI Database 26ai 版本，从而为你的 CDC 客户端提供额外的性能和功能优势；
请注意，在下游捕获模式下，仍然需要按照原始/生产源数据库（应用用户所连接的数据库）的核心数来计算/覆盖许可和定价。
结论
许多数据工程团队希望借助 Snowflake 获得洞察速度。许多运营团队希望借助 Oracle 获得稳定性和原始性能。这些目标并不互相排斥。
本文讨论的场景表明，XStream 是一项成熟、高效的技术。在一个中等规模的 AWS RDS 实例上，XStream 能够处理 37k TPS，且 CPU 开销仅为可以忽略的 3%。相关风险——尤其是 I/O 和日志量方面——是可确定且可管理的。对于使用更优基础设施来运行 Oracle AI 数据库的客户，例如 Exadata，使用基于 XStream 的 CDC 客户端（如 Snowflake Openflow）可以预期获得更好的整体结果。
我们构建 Snowflake Openflow Connector for Oracle，是为了利用这些原生内部机制，并优先考虑架构透明性和运营稳定性。
点击链接立即报名注册：Ascent - Snowflake Platform Training - China，更多 Snowflake 精彩活动请关注专区。
本文来源：InfoQ