OceanBase 数据库中怎么查看临时文件的磁盘空间占用

OceanBase 数据库在执行 SQL 以及 DDL 操作时，比如 SQL 执行时排序产生了较大的中间结果集，或者建立索引过程中对大量数据进行排序，都可能要把内存中的结果集临时存放在磁盘上。本文讲述如何查看临时文件的空间使用情况，以及怎么定位是什么操作导致的临时空间使用。

适用版本

OceanBase 数据库 V2.x、V3.x 版本。

查看临时文件的磁盘占用

数据盘占用比例大，但是和实际数据大小不符合，可能是临时文件占用磁盘空间导致数据盘使用量上升。可以使用如下步骤进行分析处理。 ​

1. 查看系统磁盘空间的使用情况。

   如果 __all_virtual_disk_stat 表中使用空间 total-free 非常大，比 __all_virtual_meta_table 中的 sum(required_size) 明显大，先排除正在合并，以及转储占用的空间。​

2. 通过系统表 __all_virtual_macro_block_marker_status 来查看临时空间的使用情况。

   • data_count 为数据文件占用的宏块数量。
   • hold_count 为临时文件占用的宏块数量​。

3. 通过 observer 日志中的 backtrace 信息查看是什么操作在使用临时文件。

   1. 在 observer.log 日志中搜索 succeed to open a tmp file 关键字，获取相关日志的 lbt 堆栈信息。如果是 V3.x 之前的版本，日志中搜索 succeed to open macro file，表示打开和使用了临时文件。
   2. 使用 addr2line 转换堆栈信息，查看是哪个模块在做 temp file 的相关操作。

      addr2line -pCfe /home/admin/oceanbase/bin/observer <lbt 信息>
      

   3. 多次重复以上过程，确认到底是创建索引还是执行 SQL 使用了大量的临时文件。​

4. 定位使用临时文件的 SQL 语句。

   SQL 执行过程中对大量数据进行排序、hash 等操作，无法全部在内存中完成，此时会进行落盘动作。可以通过系统视图和虚拟表来查询是哪个 SQL 使用了较大的临时文件空间。

   • gv$sql_workarea：SQL 执行的历史信息，包含 workarea 以及 temp file 的使用信息。
   • __all_virtual_sql_workarea_active：当前正在执行的 SQL 的 workarea 和 temp file 使用信息。

   字段名称	描述
   con_id	租户 ID
   sql_id	SQL 语句的 SQL 唯一标示
   operation_type	workarea 操作符类型，例如 Sort、Hash Join、Group by 等
   operation_id	计划树中识别操作符的唯一标示
   max_tempseg_size	workarea 使用时最大的临时磁盘空间，单位：bytes；如果是 NULL，则表示未使用临时空间
   last_tempseg_size	workarea 上次执行时使用的临时磁盘空间；如果是 NULL，表示未使用临时空间

5. 在 observer.log 中搜索 dump dtl interm result cost 关键字，查看中间结果集的落盘操作的统计信息。该日志是后台定时十秒打印一次的，如果没有临时文件生成的话不会打印该日志。

   grep "dump dtl interm result cost" observer.log
   

   [2022-06-09 09:11:27.269825] INFO  [SQL.DTL] ob_dtl_interm_result_manager.cpp:33 [37947][4][Y0-0000000000000000] [lt=5] [dc=1] dump dtl interm result cost(us)(dump_cost=1836728752, ret=0, interm count=4573153, dump count=2582591)
   [2022-06-09 09:55:03.390245] INFO  [SQL.DTL] ob_dtl_interm_result_manager.cpp:33 [37947][4][Y0-0000000000000000] [lt=3] [dc=0] dump dtl interm result cost(us)(dump_cost=2604775667, ret=0, interm count=8350963, dump count=2582592)
   

   日志解读：

   • dump_cost：临时文件 dump 的耗时，单位 us。
   • interm count：实时有多少个中间结果。
   • dump count：dump 的中间结果数（当前示例的 dump count 不正确，是累加值）。 ​

6. 根据排查的结果，采取相应的措施来应对临时文件占用过大的问题。

   • 如果是大查询导致，要么减少并发度，要么进行相应的 SQL 调优。如果应急，可以杀掉对应大查询的 session 来解决。
   • 如果是索引创建导致，需要等待索引创建结束后。 ​