obdumper导出报错怎么解决?

【问题描述】obdumper导出报错怎么解决?

6 个赞

OBDumper 是 OceanBase 数据库的官方数据导出工具,导出时报错的原因多种多样。下面按常见报错类型分类整理排查和解决方法:

连接/权限类报错

Access denied for user

报错示例:Access denied for user 'root'@xxxx

排查步骤:

  • 确认用户名和密码:检查 -u-p 参数是否正确,注意大小写和特殊字符。
  • 确认主机名/IP:确保指定的主机与数据库授权的主机一致(如 localhost vs 远程 IP)。
  • 检查用户权限:登录数据库执行 SHOW GRANTS FOR 'user'@'host';,确认用户有 SELECT 权限。必要时重新授权:
GRANT ALL PRIVILEGES ON *.* TO 'user'@'host' WITH GRANT OPTION;
  • 检查租户名和集群名-t(租户)和 -c(集群)参数需与实际环境匹配。

内存不足类报错

No memory or reach tenant memory limit

排查步骤:

  • 执行 free -h 查看机器剩余内存。
  • 查看租户内存占用:
SELECT * FROM GV$OB_TENANT_MEMORY;
  • 如果内存确实不足,可以调整租户内存配额,或清理已删除租户残留的 resource pool(删除租户后 pool 和 unit 不会自动释放,需手动删除)。
  • 也可以通过 --mem 参数调整 OBDumper JVM 内存大小(V4.3.2+ 支持,默认 4G)。

查询超时类报错

ORA-00600: Timeout / maximum query timeout

这是最常见的报错之一,通常是因为大表导出时间超过了默认的查询超时时间。

解决方法:修改 OBDumper 配置文件

进入 conf/session.config.json,调大超时参数:

"set session ob_query_timeout=300000000000",
"set session ob_trx_timeout=180000000000",
"set session net_read_timeout=86400",
"set session net_write_timeout=86400"

同时检查 jdbc_url_options 中的超时设置:

"socketTimeout": 1800000,
"connectTimeout": 1800000

:bulb: 也可以在数据库层面调大超时:

SET GLOBAL connect_timeout = 3600;

SET GLOBAL net_read_timeout = 3000;






但实测中,**修改 `session.config.json` 更可靠**。

表或视图不存在类报错

ORA-00942: table or view ‘__ctas_xxx’ does not exist

这通常是因为数据库中存在以 __ctas_ 开头的临时表(由 CTAS 操作残留),OBDumper 在遍历元数据时尝试访问这些表但无法读取。

解决方法:

  • 这类临时表一般无法直接 DROP,可以尝试清理残留的临时表对象,或等待系统自动回收。
  • 如果是全库导出,可以使用 --table 参数指定具体表名来跳过问题表:
obdumper -h <host> -P 2881 -u <user> -t <tenant> -p <password> \
  --csv --table 'YOUR_TABLE' -f /backup/output/ --skip-check-dir

性能调优建议

如果导出速度慢或资源占用高,可以通过以下参数优化:

参数 说明 默认值
--thread 导出并发线程数 CPU × 2(上限 32)
--page-size 任务分页大小 1000000
--mem JVM 内存大小(V4.3.2+) 4G

通用排查思路

  1. 查看完整日志:OBDumper 的日志默认输出到导出目录下的 logs/ 文件夹,仔细阅读 ERROR 级别的日志。
  2. 单独导出问题表:用 --table 参数逐表导出,定位具体是哪张表报错。
  3. 检查版本兼容性:确保 OBDumper 版本与 OceanBase 数据库版本匹配,建议升级到最新版。
  4. 检查网络连通性:确认导出机器能正常访问数据库的 IP 和端口。
5 个赞

这也太水了, 得上点日志呀。

什么都没有,怎么解决

打卡打卡