---
title: 如何排查位点统计卡住-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 如何排查位点统计卡住相关的常见问题和使用技巧，帮助您快速解决 如何排查位点统计卡住的难题。
---
切换语言

- 简体中文
- English

划线反馈

# 如何排查位点统计卡住

更新时间：2025-06-23 06:56

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

## SYNC_SCN 卡住

`REPLAYABLE_SCN` 是 `SYNC_SCN` 与 `READABLE_SCN` 计算的结果，所以如果位点卡住，只会是 `SYNC_SCN` 或者 `READABLE_SCN` 卡住，`REPLAYABLE_SCN` 是受害者，所以这里的卡住，属于 `SYNC_SCN` 和 `READABLE_SCN` 卡住的问题。

若 `SYNC_SCN` 卡住，按照以下步骤排查：

1. 在系统租户下确定 `SYNC_SCN` 是否停止变化，执行如下查询。

   ```shell
   select * from oceanbase.__all_virtual_tenant_info where tenant_id = xxxx;

   ```

   如果 `SYNC_SCN` 一段时间内没有发生变化，则需要看 `RECOVERY_UNTIL_SCN`，如果 `SYNC_SCN` 已经大于等于 `RECOVERY_UNTIL_SCN`，则 `SYNC_SCN` 没有发生变化是预期内的。
 2. 如果未达到到 `RECOVERY_UNTIL_SCN`，则需要进一步排查是哪个日志流的 `SYNC_SCN` 不推进了。

   在系统租户下执行如下查询语句。

   ```shell
   select * from oceanbase.__all_virtual_ls_recovery_stat where tenant_id = xxxx;

   ```

   每个日志流的同步位点的汇报都由本日志流选举的 leader 进行。所以在确定某个日志流不推进了，需要在是 leader 的机器上找日志。
 3. 在去排查日志之前，在系统租户下执行如下命令，查询是否由于没拉日志导致的没有汇报。 在系统租户下执行查询语句。

   ```shell
   select * from oceanbase.__all_virtual_log_stat where tenant_id = xxx and ls_id = yyy;

   ```

   如果 leader 副本的 `END_SCN` 和 `SYNC_SCN` 是相等。那就是没有拉日志导致的。
 4. 如果没有拉日志，可以在系统租户下查看日志流的恢复状态是不是到了拉日志的状态，执行如下查询语句。

   ```shell
   select * from oceanbase.__all_virtual_ls_meta_table where tenant_id = xxx and ls_id = yyy;

   ```

   看 leader 副本的 `is_restore` 状态。如果是备库的话，请联系 OceanBase 技术支持团队协助排查。

### 系统日志流

系统日志流需要去 `Txxx_RecLSSer` 下找日志。 关键日志，要去找 `thread_idx= 1` 线程日志。如果这个线程有报错，可以联系 OceanBase 技术支持团队协助排查。

```sql
 LOG_INFO("[LS_RECOVERY] finish one round"

```

示例命令如下：

```sql
fgrep "T1004_RecLSSer" rootservice.log | grep "finish one round" | grep "thread_idx=1" | vim -

```

这个线程池内有两个线程，只有 `thread_idx= 1` 是用来汇报同步位点的，所以要据此信息找到对应报错线程的日志。

### 普通日志流

普通日志流需要找 `Txxx_TeRec` 找日志。

示例命令如下：

```sql
fgrep "T1004_TeRec" rootservice.log | grep "id:1003" | vim -

```

如果这个线程有报错，请联系 OceanBase 技术支持团队协助排查。

## READABLE_SCN 卡住

`READABLE_SCN` 可读点不同于 `SYNC_SCN`，可读点统计的是多数派副本的最小的可读点。

例如一个日志流 3 个副本，leader 副本的可读点是 10 点，follower 副本 1 的位点是 11 点，follower 副本 2 的位点是 9 点，最后统计出来的可读点就是 10 点。

和 `SYNC_SCN` 一样，`READABLE_SCN` 可读点的汇报是和 `SYNC_SCN` 在同一个线程中的。

若 `READABLE_SCN` 卡住，按照以下步骤排查:

1. 在系统租户下确定 `READABLE_SCN` 是否停止变化，执行如下查询语句。

   ```

   如果 `READABLE_SCN` 在一段时间内没有发生变化，则需要看 `SYNC_SCN`，如果 `READABLE_SCN` 已经等于 `SYNC_SCN`，则 `READABLE_SCN` 没有发生变化是在预期内的。
 2. 如果未达到到 `SYNC_SCN`，则需要进一步排查是哪个日志流的 `READABLE_SCN` 不推进了。

   ```

   每个日志流的同步位点的汇报都由本日志流的选举的 leader 进行。所以在确定某个日志流不推进了，需要去 leader 的机器上找日志。

   确定落后的日志流及其 `WEAK_READ_TIMESTAMP`。
 3. 如果多数派的 `WEAK_READ_TIMESTAMP` 落后，执行如下查询语句，检查回放是否卡住。

   ```shell
   select * from oceanbase.__all_virtual_ls_info where tenant_id = xxxx and ls_id = yyy;//WEAK_READ_TIMESTAMP

   ```

   如果经过上面的查询多数派的 `WEAK_READ_TIMESTAMP` 是落后的，那大概率就是回放卡住了。如果回放卡住了，需要去回放卡住的副本上去找相应的日志。
 4. 确认是否有待回放的任务，执行如下查询语句。

   ```shell
   select * from oceanbase.__all_virtual_replay_stat where tenant_id = xxxx and ls_id = yyy

   ```

   如果可读点的汇报确实卡住了，请按照 `SYNC_SCN` 卡住排查位点的方法，分系统日志流和普通日志流分别去不同的线程中找相应的日志，并联系 OceanBase 技术支持团队协助排查。

Previous

[如何排查网络备库同步卡住](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000832367)

Next

[备库 OBServer 日志报错：OB_SIZE_OVERFLOW，-4019](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000933518) ![有帮助](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) 咨询热线