---
title: OceanBase 数据库中怎么查看临时文件的磁盘空间占用-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于OceanBase 数据库中怎么查看临时文件的磁盘空间占用相关的常见问题和使用技巧，帮助您快速解决OceanBase 数据库中怎么查看临时文件的磁盘空间占用的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

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

更新时间：2026-06-16 09:21

适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x 内容类型：How-to  

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 的相关操作。

        ```shell
        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` 关键字，查看中间结果集的落盘操作的统计信息。该日志是后台定时十秒打印一次的，如果没有临时文件生成的话不会打印该日志。

   ```shell
   grep "dump dtl interm result cost" observer.log

   ```

   ```shell
   [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 来解决。
      - 如果是索引创建导致，需要等待索引创建结束后。 ​

上一篇

[如何查看表和索引的大小和磁盘空间使用](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000209900)

下一篇

[slog 介绍](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207769) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线