【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】4.2.1-10BP
【问题描述】
数据库备份失败，显示错误信息为module: BACKUP_DATA, result: -4184(Server out of disk space)。
查看了下备份期间，有一台副本磁盘被占用接近95%。 备份的时候为什么会占用磁盘空间
根据文档库中的信息，错误码 -4184 表示磁盘空间不足。以下是关于此问题的详细分析和解决方法：
问题分析
-
备份过程占用磁盘空间的原因
在 OceanBase 数据库中，备份操作需要将数据写入到磁盘上的备份文件中。如果磁盘空间不足，备份操作会失败并返回错误码-4184。此外，备份期间可能会生成临时文件或日志文件，进一步占用磁盘空间。 -
磁盘空间不足的风险
根据文档片段 4 的描述，当事务日志（CLOG）空间利用率超过[log_disk_utilization_limit_threshold]（默认为 95%）时，节点会停止写入。这可能导致备份失败或其他业务操作异常。 -
副本磁盘占用接近 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 技术支持人员协助排查。
详情请参考:
磁盘空间满了啊,或者文件指针用尽了
只有备份期间磁盘空间使用率会上涨是吗？集群是什么部署架构的？只有一台observer上涨？
使用obdiag分析下报错时的日志
obdiag analyze log [options]
https://www.oceanbase.com/docs/common-obdiag-cn-1000000001768214
您把您的集群的规划简单介绍下，同时您的备份的配置比如使用nfs 也介绍下
根据文档库中的信息，您可以使用以下方法来查询哪些 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 语句、创建索引或优化执行计划等，以减少资源消耗并避免备份失败的问题。
更多信息请查看:
根据文档库中的信息，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_examined 和 mem_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：
- 使用
rows_examined和mem_used指标筛选扫描行数多或内存使用量大的 SQL。 - 分析执行时间长或 CPU 时间高的 SQL。
- 结合慢查询日志进行排查。
如果需要更精确的资源占用分析，建议结合 OB 数据库的系统视图（如 gv$ob_sql_audit 和 gv$plan_cache_plan_stat）进行深入挖掘。
检索到的文档如下: