MySQL 租户存在多个同名 user 时，将导致 dbms_scheduler 无法工作

问题现象

以设置 [pquery|mysql] 统计信息定时任务报错 4016，MySQL 租户允许建重复用户名，dbms_scheduler 调度获取用户的时候拿到了多个，预期只有一个，示例如下。

导致统计信息任务执行失败，报错 error code 为 4016。

关键诊断信息

触发条件

MySQL 租户下创建多个同名 user。

事后诊断

如问题现象所属，在 __all_tenant_scheduler_job_run_detail 表里看到了 JOB 执行失败的记录，并且错误码为 4016。

根据 trace_id + 错误码排查，可以发现报错源于 JOB 执行前的 init_env 步骤。

这个步骤会根据 JOB 的 powner 字段（也就是创建 JOB 的 user），检查 schema 中是否存在合法的 user。

如下这个 issue，这里的 powner 是 "root"，但 schema 中发现了两个名为 "root"的 user。

问题原因

因为此租户为 MySQL 租户，而 MySQL 模式下本身就允许同名 user 的存在，只要保证 user_name 和 host_name 不全相同就可以。这种情况下，遇到有多个 user_name 的情况，这个 user 下的 JOB 就会执行失败。

dbms_scheduler 开发之初是为了兼容 Oracle 的行为，Oracle 是明确规定 user name 不可重复的。后来因为统计信息收集模块要用 dbms_scheduler 做定时任务调度，而且这个任务调度覆盖了所有租户，因此 dbms_scheduler 又新增了 mysql mode 的支持。 但是代码的实现上仍然没有考虑到 mysql 模式 user name 可能重复的问题，具体的： __all_tenant_scheduler_job 表中记录的 powner 字段即为每个 job 所属的 user。这个字段是在创建之初，通过内部接口获取到的。

其中 Oracle 模式直接获取的 session_user：

而 mysql 模式截取的是 current_user() 字段的前半部分，去掉了后面的 host：

而在 job 执行前，会根据内部表中 job 的 powner 字段在 schema 中检查对应的 user name，并且要求仅有一个，否则会报错。

这就导致了 mysql 模式下，如果这个 job 所属的用户名对应了多个用户，job 就会运行失败。

问题的风险及影响

• 统计信息收集 JOB 执行失败。

• 物化视图刷新 JOB 执行失败。

• 外部创建的 JOB 执行失败。

影响租户

影响 OceanBase 数据库中的 MySQL 租户，对于 SYS 租户和 Oracle 租户无影响。

影响版本

OceanBase 数据库企业版 V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之后版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本。

解决方法

升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）。

规避方式

1. 对于内部 JOB，包括统计信息收集和物化视图更新，其 powner 均采用 root 用户。因此只要保证不再创建同为 root 名字的用户即可。

2. 如果环境已经存在同名用户而导致 JOB 执行失败，可以删除同名用户或者修改用户名。

3. 如果用户不可删除或更改。

   • 对于统计信息收集任务，手动调用 call dbms_stats。

     GATHER_DATABASE_STATS_JOB_PROC(14400000000);（如果时间落在周末，14400000000 改为 72000000000）

   • 对于物化视图刷新任务，手动执行 call dbms_mview.refresh(mv_name, refresh_mode);。

   • 对于物化视图日志的 purge 任务，手动执行 call dbms_mview.purge_log(table_name);。

   • 对于外部 JOB，只能手动执行 job_action 的 SQL 字段。