OMS 查询数据字典缓慢导致 JDBCWriter 进程检查点推进缓慢

本文为您介绍 OceanBase 迁移服务（OceanBase Migration Service，OMS）查询数据字典缓慢导致 JDBCWriter 或 Incr-Sync 进程检查点推进缓慢的原因和解决方法。

适用版本

适用于 OMS V3.x 和 V4.x。

问题描述

OMS 的 JDBCWriter 进程检查点推进非常缓慢，通过查询 OCP 的 SQL 诊断功能排查相应时间点租户的性能，发现下述语句耗时较长：

SELECT TABLE_OWNER,TABLE_NAME,PARTITION_NAME,SUBPARTITION_NAME FROM DBA_TAB_SUBPARTITIONS WHERE ((TABLE_OWNER=? AND TABLE_NAME=?))

问题原因

OMS 的 JDBCWriter 组件同样需要查询 OceanBase 数据库的数据字典信息，当这种语句查询缓慢时，会拖慢总体的性能。

解决方法

1. 登录 OMS 的 Docker 容器。

   docker exec-it oms bash 
   

2. 检索 connector 文件，定位缓慢语句。文件名称示例 (您可以在 OMS 控制台查看组件的名称）：/u01/ds/run/xxx.xxx.xxx.1-9000:p_4vxxxxtz7c0_dest-000-0:0000000004/logs/connector.log ​ 排查过程中发现以下类型的 SQL 语句执行的时间间隔较久，可能存在执行性能问题。

   [2023-07-06 08:50:42.250] [INFO] [sinkTask-81] [partition relation sql: SELECT TABLE_OWNER,TABLE_NAME,PARTITION_NAME,SUBPARTITION_NAME FROM DBA_TAB_SUBPARTITIONS WHERE ((TABLE_OWNER='NGCRM_XX' AND TABLE_NAME='CM_SUBS_RESOURCE'))]
   [2023-07-06 08:50:46.028] [INFO] [sinkTask-10] [partition relation sql: SELECT TABLE_OWNER,TABLE_NAME,PARTITION_NAME,SUBPARTITION_NAME FROM DBA_TAB_SUBPARTITIONS WHERE ((TABLE_OWNER='XXIB' AND TABLE_NAME='IB_CB_VOICERESDET'))]
   [2023-07-06 08:50:51.136] [INFO] [sinkTask-30] [partition relation sql: SELECT TABLE_OWNER,TABLE_NAME,PARTITION_NAME,SUBPARTITION_NAME FROM DBA_TAB_SUBPARTITIONS WHERE ((TABLE_OWNER='NGCRM_XX' AND TABLE_NAME='CS_REC_CUSTOMER'))]
   

   您可以通过 shell 脚本定位该类语句，示例如下：

   cat connector.log|grep "FROM DBA_TAB_SUBPARTITIONS WHERE"|grep "relation sql"|awk -F"relation sql:" '{print $2}'|sed 's/\]/;/g'|sort|uniq
   

   在 OCP 中通过 SQL 诊断也确认了该类 SQL 执行存在性能问题。

3. 对问题 SQL 语句进行路径调优。例如，绑定一个更好的执行计划（登录 OMS 的用户进行操作）。

   obclient -hxxx.xxx.xxx.2 -P2883 -uxx@xx#xx -p
   
   CREATE OUTLINE OLT_OMS_FOR_DBA_TAB_SUBPARTITIONS_OMS ON '2C3D03CFDADxxxx8705A' USING HINT 
   /*+ USE_HASH(@"SEL$1" ("SYS.TP"@"SEL$1" ))
   PQ_DISTRIBUTE(@"SEL$1" ("SYS.TP"@"SEL$1" ) LOCAL LOCAL)
   LEADING(@"SEL$1" (("SYS.S_PART"@"SEL$1" (("SYS.DB"@"SEL$1" "SYS.TB"@"SEL$1" )"SYS.P_PART"@"SEL$1" ))"SYS.PI"@"SEL$1" ))
   USE_HASH(@"SEL$1" ("SYS.PI"@"SEL$1" ))
   PQ_DISTRIBUTE(@"SEL$1" ("SYS.PI"@"SEL$1" ) LOCAL LOCAL)
   USE_HASH(@"SEL$1" ("SYS.DB"@"SEL$1" "SYS.TB"@"SEL$1" "SYS.P_PART"@"SEL$1" ))
   FULL(@"SEL$1" "SYS.S_PART"@"SEL$1")
   USE_HASH(@"SEL$1" ("SYS.P_PART"@"SEL$1" ))
   USE_HASH(@"SEL$1" ("SYS.TB"@"SEL$1" ))
   FULL(@"SEL$1" "SYS.DB"@"SEL$1")
   FULL(@"SEL$1" "SYS.TB"@"SEL$1")
   FULL(@"SEL$1" "SYS.P_PART"@"SEL$1")
   FULL(@"SEL$1" "SYS.PI"@"SEL$1")
   FULL(@"SEL$1" "SYS.TP"@"SEL$1")
   */; 
   

4. 重启 OMS 的 JDBCWriter 组件，并观察 OCP 的 SQL 诊断信息。

5. 登录 SYS 租户，验证 SQL 绑定的效果。

   select sql_id,hit_count,executions,avg_exe_usec,slowest_exe_usec,plan_id,type,last_active_time from gv$plan_cache_plan_stat where    sql_id='2C3D03CFDxxxx8705A' order by last_active_time;