---
title: 悬挂事务恢复后排查-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于悬挂事务恢复后排查相关的常见问题和使用技巧，帮助您快速解决悬挂事务恢复后排查的难题。
---
切换语言

- 简体中文
- English

划线反馈

# 悬挂事务恢复后排查

更新时间：2026-06-12 03:56

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

## 适用版本

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

## 问题描述

OCP 告警有悬挂事务。对应告警 OBServer 主机的 `observer.log` 日志有如下内容 `fill redo log cost too much time`。

```shell
[2022-12-05 03:40:11.080962] WARN  [STORAGE.TRANS] fill_redo_log_ (ob_trans_part_ctx.cpp:4511) [30185][2324][YB42030E3213-0005DB7EA46E6824] [lt=15] [dc=0] fill redo log cost too much time(trans_id={hash:12782221063265577272, inc:2817982292, addr:"3.xx.xx.xx:2882", t:1670182807179936}, self={tid:1101710651082337, partition_id:21, part_cnt:0}, timeguard=time guard 'fill_redo_log' cost too much time, used=27616, time_dist: 4,27255,332)  

```

## 问题原因

日志中有事务打印了 Redo Log 填充不及时的内容，这说明有事务 commit 后备机同步很慢。告警恢复后，事务已经跑完。根据日志中的 `tid`，去 `gv$table` 中定位表，检查 TopSQL 记录。

![Alt text](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/transaction-management/image%20%2814%29.png)

TopSQL 这一时间端的慢 SQL 中的表与事务 tid 中的表吻合。查看 SQL 是一个 update 很大的表，导致事务规模太大。

## 解决方法

拆分事务，规避 Redo Log 太大的情况。

Previous

[2.x 版本下大事务导致事务悬挂、无法结束，以及 Clog 不同步的故障](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000322509)

Next

[应用报错：Transaction resolution unknown](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000322510) ![有帮助](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) 咨询热线
