数据库备份失败,提示 module: BACKUP_DATA, result: -4184(Server out of disk space)

【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】4.2.1-10BP
【问题描述】
数据库备份失败,显示错误信息为module: BACKUP_DATA, result: -4184(Server out of disk space)。

查看了下备份期间,有一台副本磁盘被占用接近95%。 备份的时候为什么会占用磁盘空间

@论坛小助手

根据文档库中的信息,错误码 -4184 表示磁盘空间不足。以下是关于此问题的详细分析和解决方法:

问题分析

  1. 备份过程占用磁盘空间的原因
    在 OceanBase 数据库中,备份操作需要将数据写入到磁盘上的备份文件中。如果磁盘空间不足,备份操作会失败并返回错误码 -4184。此外,备份期间可能会生成临时文件或日志文件,进一步占用磁盘空间。

  2. 磁盘空间不足的风险
    根据文档片段 4 的描述,当事务日志(CLOG)空间利用率超过 [log_disk_utilization_limit_threshold](默认为 95%)时,节点会停止写入。这可能导致备份失败或其他业务操作异常。

  3. 副本磁盘占用接近 95% 的影响
    如果某台副本的磁盘占用接近 95%,可能已经触发了磁盘空间限制,导致备份无法继续。


解决方法

1. 检查磁盘空间

  • 确认所有 OBServer 节点的磁盘空间是否充足。
  • 使用以下命令检查磁盘使用情况:
    df -h
    
  • 特别关注备份目录所在磁盘的空间使用率。

2. 增加磁盘空间

  • 如果磁盘空间不足,可以通过以下方式增加磁盘容量:
    • 添加新的磁盘分区。
    • 扩展现有磁盘分区。
  • 参考文档片段 1 的建议,增加服务器以扩容。

3. 清理不必要的文件

  • 删除旧的备份文件或日志文件,释放磁盘空间。
  • 备份目录路径通常位于 /home/admin/oceanbase/backup 或类似路径,请根据实际环境确认。

4. 调整磁盘分配策略

  • 根据文档片段 4 的建议,推荐分别挂载三块磁盘用于系统日志、事务日志和数据文件。如果无法实现物理分离,可以对磁盘进行逻辑分区。
  • 开启日志限流功能,控制系统日志所能占用的磁盘 I/O 带宽上限:
    alter system set syslog_io_bandwidth_limit='10M';
    
  • 开启回收系统日志功能并设置最大文件数量:
    alter system set enable_syslog_recycle = true;
    alter system set max_syslog_file_count = 1000;
    

5. 优化备份策略

  • 减少单次备份的数据量,避免一次性占用过多磁盘空间。
  • 调整备份时间窗口,避开业务高峰期。

总结

备份失败的原因是磁盘空间不足,建议按照上述步骤逐一排查和解决问题。如果问题仍未解决,可以参考文档片段 6 提供的日志路径,进一步定位问题原因,并联系 OceanBase 技术支持人员协助排查。

详情请参考:

  1. 4000 ~ 4499
  2. 9000 ~ 9499
  3. OceanBase 数据库性能的影响因素
  4. 数据备份失败
  5. 4500 ~ 4999
  6. 0001 ~ 3999

磁盘空间满了啊,或者文件指针用尽了

只有备份期间磁盘空间使用率会上涨是吗?集群是什么部署架构的?只有一台observer上涨?

使用obdiag分析下报错时的日志

obdiag analyze log [options]

https://www.oceanbase.com/docs/common-obdiag-cn-1000000001768214

您把您的集群的规划简单介绍下,同时您的备份的配置比如使用nfs 也介绍下

image
监控检查到存在大sql查询,占用了磁盘。导致备份失败。
如何查询哪些sql查询时占用了比较大的内存和磁盘
@论坛小助手

根据文档库中的信息,您可以使用以下方法来查询哪些 SQL 查询占用了较大的内存和磁盘资源:

查询大 SQL 查询的方法

利用 gv$ob_processlist 查找慢查询
根据文档片段 5 的描述,可以使用 gv$ob_processlist 视图来查找慢查询。执行以下 SQL 查询以获取占用较多资源的 SQL 请求:

SELECT * 
FROM gv$ob_processlist 
WHERE state = 'executing' 
ORDER BY time DESC;

此查询将返回正在执行的 SQL 请求,并按照执行时间降序排列。重点关注执行时间较长的 SQL 请求。

利用 gv$ob_sql_audit 查找资源消耗大的 SQL
根据文档片段 4 的描述,可以使用 gv$ob_sql_audit 视图来分析 SQL 执行计划的获取耗时。执行以下 SQL 查询以获取资源消耗较大的 SQL 请求:

SELECT sql_id, get_plan_time, execute_time, rows_examined, mem_used 
FROM gv$ob_sql_audit 
ORDER BY get_plan_time DESC, execute_time DESC, rows_examined DESC, mem_used DESC;

此查询将返回按获取执行计划耗时、执行时间、扫描行数和内存使用量降序排列的 SQL 请求列表。重点关注这些指标较高的 SQL 请求。

利用 gv$plan_cache_plan_stat 分析执行计划
根据文档片段 5 的描述,可以使用 gv$plan_cache_plan_stat 视图来分析执行计划的性能。执行以下 SQL 查询以获取性能较差的执行计划:

SELECT sql_id, plan_id, avg_exe_time, avg_cpu_time, avg_mem_used, avg_rows_examined 
FROM gv$plan_cache_plan_stat 
ORDER BY avg_exe_time DESC, avg_cpu_time DESC, avg_mem_used DESC, avg_rows_examined DESC;

此查询将返回按平均执行时间、CPU 时间、内存使用量和扫描行数降序排列的执行计划列表。重点关注这些指标较高的执行计划。

利用 gv$plan_cache_plan_explain 获取执行计划详情
根据文档片段 5 的描述,可以使用 gv$plan_cache_plan_explain 视图来获取执行计划的详细信息。执行以下 SQL 查询以获取特定 SQL 请求的执行计划:

SELECT * 
FROM gv$plan_cache_plan_explain 
WHERE sql_id = '<目标_sql_id>' AND plan_id = <目标_plan_id>;

<目标_sql_id><目标_plan_id> 替换为从上一步查询中获得的值。此查询将返回目标 SQL 请求的执行计划详细信息,帮助您了解其资源消耗情况。

结合 SQL Diagnoser 工具进行诊断
根据文档片段 8 的描述,可以使用 SQL Diagnoser 工具对业务集群中的可疑 SQL 进行诊断。该工具能够提供索引优化建议和 SQL 改写建议,帮助您进一步优化资源消耗较大的 SQL 请求。

总结
通过以上方法,您可以查询到占用较大内存和磁盘资源的 SQL 请求。根据查询结果,您可以采取相应的优化措施,例如调整 SQL 语句、创建索引或优化执行计划等,以减少资源消耗并避免备份失败的问题。

更多信息请查看:

  1. 工作线程
  2. JOIN 表使用建议
  3. SQL 调优典型场景和案例
  4. SQL 性能问题的典型场景和排查思路
  5. 定位和分析慢查询(一)
  6. 通过 SQL Diagnoser 工具进行 SQL 性能诊断和分析
  7. SQL 查询导致的异常

@论坛小助手 ocp中的sql诊断有没有指标能筛选出占用内存和磁盘大的sql

根据文档库中的信息,OCP 的 SQL 诊断功能确实提供了多种维度的筛选和分析能力,但直接针对内存和磁盘占用的指标需要进一步明确。以下是详细解答:

1. OCP 中的 SQL 诊断功能

依据文档片段 2 和文档片段 4 的描述,OCP 提供了以下几种 SQL 诊断类型:

  • TopSQL:根据响应时间排序,展示总响应时间最长的 SQL。
  • SlowSQL:提取执行耗时超过一定阈值(默认 100ms)的 SQL。
  • 可疑 SQL:识别性能异常的 SQL,例如执行计划变化、性能下降等。
  • ParallelSQL:针对使用并行调度机制执行的 SQL。

虽然 OCP 的 SQL 诊断功能没有直接以“内存”或“磁盘”为筛选指标,但可以通过其他间接指标来推测哪些 SQL 占用了较多资源。


2. 间接筛选占用内存和磁盘大的 SQL

(1)通过 rows_examinedmem_used 筛选

  • 在文档片段 4 中提到,gv$ob_sql_audit 视图可以提供 SQL 的资源消耗信息,包括:

    • rows_examined:扫描的行数。
    • mem_used:内存使用量。

    您可以在 OCP 的 SQL 诊断页面中,结合这些指标进行高级搜索。如果 OCP 支持自定义 SQL 查询,可以直接运行以下语句:

    SELECT sql_id, rows_examined, mem_used 
    FROM gv$ob_sql_audit 
    ORDER BY rows_examined DESC, mem_used DESC;
    

    这将返回扫描行数最多和内存使用量最大的 SQL。

(2)通过执行时间 (execute_time) 和 CPU 时间 (avg_cpu_time) 筛选

  • 执行时间较长的 SQL 往往会占用更多资源,包括内存和磁盘 I/O。
  • 文档片段 5 提到,gv$plan_cache_plan_stat 视图可以提供 SQL 的平均执行时间和 CPU 时间:
    SELECT sql_id, avg_exe_time, avg_cpu_time, avg_mem_used 
    FROM gv$plan_cache_plan_stat 
    ORDER BY avg_exe_time DESC, avg_cpu_time DESC;
    

(3)通过慢查询日志分析

  • 慢查询日志通常记录了执行时间较长的 SQL,而这些 SQL 很可能也占用了较多的内存和磁盘资源。
  • 在 OCP 的 SQL 诊断页面中,可以筛选出 SlowSQL,并进一步分析其执行计划。

3. OCP 社区版的功能限制

需要注意的是,根据文档片段 2 的说明:

目前社区版 OCP 暂不支持可疑 SQL 诊断功能。

因此,如果您使用的是社区版 OCP,可能无法直接利用可疑 SQL 功能来快速定位性能异常的 SQL。不过,您仍然可以通过 TopSQL 和 SlowSQL 功能,结合上述间接指标进行分析。


4. 总结

虽然 OCP 的 SQL 诊断功能没有直接提供“内存”和“磁盘”占用的筛选指标,但可以通过以下方式间接筛选出占用资源较大的 SQL:

  1. 使用 rows_examinedmem_used 指标筛选扫描行数多或内存使用量大的 SQL。
  2. 分析执行时间长或 CPU 时间高的 SQL。
  3. 结合慢查询日志进行排查。

如果需要更精确的资源占用分析,建议结合 OB 数据库的系统视图(如 gv$ob_sql_auditgv$plan_cache_plan_stat)进行深入挖掘。

检索到的文档如下:

  1. 诊断分析
  2. 租户性能诊断
  3. OCP V3.1.2
  4. SQL 诊断概述
  5. SQL 性能诊断相关参数配置
  6. SQL 诊断
  7. odp_sql_query_slow 慢查询 SQL 次数超限
  8. 诊断事务