【问题描述】obdumper导出报错怎么解决?
6 个赞
OBDumper 是 OceanBase 数据库的官方数据导出工具,导出时报错的原因多种多样。下面按常见报错类型分类整理排查和解决方法:
连接/权限类报错
Access denied for user
报错示例:Access denied for user 'root'@xxxx
排查步骤:
-
确认用户名和密码:检查
-u和-p参数是否正确,注意大小写和特殊字符。 -
确认主机名/IP:确保指定的主机与数据库授权的主机一致(如
localhostvs 远程 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
也可以在数据库层面调大超时:
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 |
通用排查思路
-
查看完整日志:OBDumper 的日志默认输出到导出目录下的
logs/文件夹,仔细阅读 ERROR 级别的日志。 -
单独导出问题表:用
--table参数逐表导出,定位具体是哪张表报错。 - 检查版本兼容性:确保 OBDumper 版本与 OceanBase 数据库版本匹配,建议升级到最新版。
- 检查网络连通性:确认导出机器能正常访问数据库的 IP 和端口。
5 个赞
这也太水了, 得上点日志呀。
什么都没有,怎么解决
打卡打卡