Oracle 数据库 OMS 增量同步的 Store 组件性能优化

本文为您介绍 Oracle 数据库至 OceanBase 数据库 Oracle 租户的增量同步中，Oracle Store 组件的性能优化方案。

适用版本

适用于 OceanBase 迁移服务（OceanBase Migration Service，OMS）V3.x 和 V4.x。

问题描述

Oracle 数据库至 OceanBase 数据库 Oracle 租户的数据迁移项目在进行增量同步时，如果源端 Oracle 数据库的归档量较大，Oracle Store 的增量同步效率会成为性能瓶颈，不满足割接需求。

解决方法

您可以通过在源端 Oracle 数据库和 OMS Store 端分别进行相应的优化来解决该问题。

源端 Oracle 数据库主要考虑以下优化：

• 均衡分摊至 RAC 多节点。

• 降低单归档大小。

• 调大 Oracle 库的 PGA。

• 配多个节点的数据源。

OMS 端主要考虑以下参数的调整：

• 调整参数 deliver2store.logminer.fetch_arch_logs_max_parallelism_per_instance。

• 调整参数 deliver2store.logminer.max_actively_staged_arch_logs_per_instance。

• 调整参数 deliver2store.logminer.staged_arch_logs_in_memory。

• 调整 Oracle Store 的 JVM 内存。

源库归档情况

• 日归档量 > 1TB

  DATE_TIME            REDO_SIZE_GB
  -------------------- ------------
  2022-09-17             517.334862
  2022-09-18             1126.19538
  2022-09-19             1207.42434
  2022-09-20             1196.54113
  2022-09-21               1179.712
  2022-09-22             1219.90292
  2022-09-23             1246.11929
  2022-09-24             1225.69183
  2022-09-25             1162.05082
  

• Oracle RAC 节点写入不均衡

  DATE_TIME               THREAD# REDO_SIZE_GB
  -------------------- ---------- ------------
  2022-09-17                    1   .753798008
  2022-09-17                    2   516.581064
  2022-09-18                    1    10.925766
  2022-09-18                    2   1115.26961
  2022-09-19                    1   11.3072042
  2022-09-19                    2   1196.11714
  2022-09-20                    1   12.5230002
  2022-09-20                    2   1184.01813
  2022-09-21                    1   12.1180973
  2022-09-21                    2    1167.5939
  2022-09-22                    1    13.641417
  2022-09-22                    2   1206.26151
  2022-09-23                    1   14.4278932
  2022-09-23                    2    1231.6914
  2022-09-24                    1   14.3115559
  2022-09-24                    2   1211.38027
  2022-09-25                    1   14.5016565
  2022-09-25                    2   1147.54916
  

• 单个归档偏大

源端 Oracle 数据库的优化项

• 业务写入均衡分摊至 RAC 多节点，确保多个节点的日归档量均衡。

• 降低单归档大小。

  您可以通过以下两种方法降低单归档大小。

  • 调整 Oracle 生产库 redo 自动切换频率参数 archive_lag_target 至 3 分钟。该参数的单位为秒，请设置取值为 180。

    ALTER SYSTEM SET archive_lag_target=180;
    

  • 直接修改 redo log 的大小。

• 调大 Oracle 数据库 PGA 至 64GB，提升 OMS 增量 logminer 效率。

• Oracle 数据库为两节点，分别配置两节点数据源，不同项目通过项目拆分，指向不同 Oracle 数据源，进行负载均衡。​

OMS Store 优化项

• 调整参数 deliver2store.logminer.fetch_arch_logs_max_parallelism_per_instance 的取值为 最大实例日归档量 / 500GB + 1。

  当前日志拉取并发度日归档量为 1.3TB，日志量较大的实例的每天日志量约为 1T / 500GB + 1，业务侧均衡后，可以调整为 3。 ​

• 调整参数 deliver2store.logminer.max_actively_staged_arch_logs_per_instance 的取值为 fetch_arch_logs_max_parallelism_per_instance * 2。

  日志拉取后每个 Oracle 实例对应的归档文件暂存个数，设置为 deliver2store.logminer.max_actively_staged_arch_logs_per_instance 配置的两倍。 ​

• 调整参数 deliver2store.logminer.staged_arch_logs_in_memory 的取值为 true，日志拉取后暂存到内存。 ​

• 调整 Oracle Store 的 JVM 内存为 -Xms56g -Xmx56g -Xmn16g。

  计算方式为 单个归档文件大小 * 日志放大倍数 4 * Oracle 实例数 * 单个实例的归档文件暂存数 + 8GB，即 2GB * 4 * 1 * 6 + 8GB = 56GB。