划线反馈

实时进度视图 GV$SESSION_LONGOPS 使用示例

更新时间：2026-05-21 09:16

适用版本：V4.1.x、V4.2.x内容类型：TechNote

当对大表 (如 30 亿行的表) 进行 DDL 等操作 (如创建索引、添加主键) 会比较慢，甚至长达数小时，此时我们可以通过视图 GV$SESSION_LONGOPS 观察 DDL 等操作的实时进度。

本文以三个实际场景为例，展示视图 GV$SESSION_LONGOPS 的部分进度内容。

详细说明

测试环境: OceanBase V4.3.3.1 MySQL 租户（64 CPU 256 GB 内存）。

场景一删除大表的 OMS 列

当通过 OMS 迁移无主键大表时，在正向切换阶段会删除 OMS 添加的列，有可能会因表太大导致删除 OMS 列失败，如下。

正向切换步骤执行失败：删除列失败的表 xxx。

此时可以通过手动指定并行删除 OMS 列，相关 SQL 如下。

SET _force_parallel_ddl_dop = 32;
ALTER TABLE `test`.`test` DROP COLUMN `OMS_OBJECT_NUMBER`, DROP COLUMN `OMS_RELATIVE_FNO`, DROP COLUMN `OMS_BLOCK_NUMBER`, DROP COLUMN `OMS_ROW_NUMBER`;

在 MySQL 用户租户 oceanbase 数据库查询 gv$session_longops 可知进度如下，从 PARALLELISM: 32 可知并行度为 32。

MySQL [oceanbase]> SELECT * FROM gv$session_longops\G
*************************** 1. row ***************************
             SID: -1
        TRACE_ID: YB42AC1405B2-000627D8F649686A-0-0
          OPNAME: table redefinition
          TARGET: 1190645
          SVR_IP: 10.10.20.20
        SVR_PORT: 2882
      START_TIME: 2024-12-24 15:44:27
 ELAPSED_SECONDS: 49
  TIME_REMAINING: 0
LAST_UPDATE_TIME: 2024-12-24 15:45:16
         MESSAGE: TENANT_ID: 1010, TASK_ID: 185222008, STATUS: REPLICA BUILD, PARALLELISM: 32, ROW_SCANNED: 175941661, ROW_SORTED: 0, ROW_INSERTED_TMP_FILE: 0, ROW_INSERTED: 0 out of 16890399456 column group rows
1 row in set (0.459 sec)

注：OceanBase 数据库 V4.2.1 BP4 版本开始，Oracle 模式租户支持快速删除列。

场景二行存表转列存表

当需要优化大表相关的 SQL 聚合计算性能时，可以通过如下 SQL 将行存表转为列存表。

SET _force_parallel_ddl_dop = 32;
ALTER TABLE test.test ADD COLUMN GROUP(each column);

在 MySQL 用户租户 oceanbase 数据库查询 gv$session_longops 可知进度如下，从 PARALLELISM: 32 可知并行度为 32。

MySQL [oceanbase]> SELECT * FROM gv$session_longops\G
*************************** 1. row ***************************
             SID: -1
        TRACE_ID: YB42AC1405B2-000627D4B5C31339-0-0
          OPNAME: alter column group
          TARGET: 1185114
          SVR_IP: 10.10.20.20
        SVR_PORT: 2882
      START_TIME: 2024-12-19 19:34:03
 ELAPSED_SECONDS: 1738
  TIME_REMAINING: 0
LAST_UPDATE_TIME: 2024-12-19 20:03:01
         MESSAGE: TENANT_ID: 1010, TASK_ID: 148512420, STATUS: REPLICA BUILD, PARALLELISM: 32, ROW_SCANNED: 40053000, ROW_SORTED: 80106000, ROW_INSERTED_TMP_FILE: 28379000, ROW_INSERTED: 2088192100 out of 3003975000 column group rows
1 row in set (0.34 sec)

场景三旁路导入

当需要备份大表表数据，或需要通过子查询批量插入的方式将行存表转为列存表时，可以通过如下 SQL 实现。

SET ob_query_timeout=360000000000;
SET ob_trx_timeout=360000000000;
SET ob_trx_idle_timeout=360000000000;
SET autocommit=ON;
INSERT /*+ DIRECT(true, 0, 'full') enable_parallel_dml parallel(32) */ INTO test2 SELECT * FROM test;

注：当参数 ob_trx_timeout 设置相对较小时，有可能报错如下。

ERROR 4012 (25000) at line 2 in file: 'test.sql': Transaction timeout occurred, please rollback the transaction, set the variable ob_trx_timeout to a larger value and then restart the transaction

在 MySQL 用户租户 oceanbase 数据库查询 gv$session_longops 可知进度如下，从 PARALLELISM: 32 可知并行度为 32。

可以通过查询结果中的 STATUS 和 LOAD_STATUS 等查看当前阶段。

如下 STATUS 为 REPENDING，LOAD_STATUS 为 loading。

MySQL [oceanbase]> SELECT * FROM gv$session_longops\G
*************************** 1. row ***************************
             SID: -1
        TRACE_ID: YB42AC1405B2-000627E7CC996F57-0-0
          OPNAME: direct load insert
          TARGET: 1191262
          SVR_IP: 10.10.20.20
        SVR_PORT: 2882
      START_TIME: 2024-12-24 20:18:48
 ELAPSED_SECONDS: 339
  TIME_REMAINING: 0
LAST_UPDATE_TIME: 2024-12-24 20:24:27
         MESSAGE: TENANT_ID: 1010, TASK_ID: 185741795, STATUS: REPENDING, TABLE_ID: 1189456, BATCH_SIZE: 100, PARALLEL: 32, MAX_ALLOWED_ERROR_ROWS: 0, DETECTED_ERROR_ROWS: 0, PROCESSED_ROWS: 0, LOAD_STATUS: loading
1 row in set (0.006 sec)

如下 STATUS 为 REPENDING，LOAD_STATUS 为 merging。

MySQL [oceanbase]> SELECT * FROM gv$session_longops\G
*************************** 1. row ***************************
             SID: -1
        TRACE_ID: YB42AC1405B2-000627E807D38302-0-0
          OPNAME: direct load insert
          TARGET: 1191946
          SVR_IP: 10.10.20.20
        SVR_PORT: 2882
      START_TIME: 2024-12-25 16:59:43
 ELAPSED_SECONDS: 5570
  TIME_REMAINING: 0
LAST_UPDATE_TIME: 2024-12-25 18:32:32
         MESSAGE: TENANT_ID: 1010, TASK_ID: 189087504, STATUS: REPENDING, TABLE_ID: 1189456, BATCH_SIZE: 100, PARALLEL: 32, MAX_ALLOWED_ERROR_ROWS: 0, DETECTED_ERROR_ROWS: 0, PROCESSED_ROWS: 0, LOAD_STATUS: merging
1 row in set (0.007 sec)

如下 STATUS 为 COPY DEPENDENT OBJECTS，并有 CHILD TASK create index 处于 VALIDATE CHECKSUM 阶段。

MySQL [oceanbase]> SELECT * FROM gv$session_longops\G
*************************** 1. row ***************************
             SID: -1
        TRACE_ID: YB42AC1405B2-000627E807D38302-0-0
          OPNAME: direct load insert
          TARGET: 1191946
          SVR_IP: 10.10.20.20
        SVR_PORT: 2882
      START_TIME: 2024-12-25 16:59:43
 ELAPSED_SECONDS: 9596
  TIME_REMAINING: 0
LAST_UPDATE_TIME: 2024-12-25 19:39:38
         MESSAGE: TENANT_ID: 1010, TASK_ID: 189087504, STATUS: COPY DEPENDENT OBJECTS, CHILD TASK IDS: [ 189623783 ]
*************************** 2. row ***************************
             SID: -1
        TRACE_ID: Y100B42AC1405B2-000627E807D38302-0-0
          OPNAME: create index
          TARGET: 1192003
          SVR_IP: 10.10.20.20
        SVR_PORT: 2882
      START_TIME: 2024-12-25 19:01:19
 ELAPSED_SECONDS: 2300
  TIME_REMAINING: 0
LAST_UPDATE_TIME: 2024-12-25 19:39:38
         MESSAGE: TENANT_ID: 1010, TASK_ID: 189623783, STATUS: VALIDATE CHECKSUM
2 rows in set (0.006 sec)