OB-v4中视图oceanbase.GV$OB_MEMSTORE中字段FREEZE_CNT为什么一直都为0

[小哲豆腐花]

【 使用环境 】生产环境 & 测试环境
【 OB or 其他组件 】observer
【 使用版本 】4.3.5.2
【问题描述】视图oceanbase.GV$OB_MEMSTORE中字段FREEZE_CNT为什么一直都为0
【复现路径】
集群为1-1-1架构；租户规格为8c19g
1、创建了一个3亿行数据的表
2、进行列类型改动
3、查看视图oceanbase.GV$OB_MEMSTORE发现字段FREEZE_CNT一直都为0

mysql> select * from oceanbase.gv$session_longops\G
*************************** 1. row ***************************
SID: -1
TRACE_ID: YB420ABA3F1A-000640C8A21B533C-0-0
OPNAME: modify column
TARGET: 500014
SVR_IP: 10.186.63.26
SVR_PORT: 2882
START_TIME: 2025-10-11 10:11:48
ELAPSED_SECONDS: 2137
TIME_REMAINING: 0
LAST_UPDATE_TIME: 2025-10-11 10:47:25
MESSAGE: TENANT_ID: 1002, TASK_ID: 14940314, STATUS: REPLICA BUILD, INSERT, PARALLELISM: 2, INSERT_THREAD: 2, ROW_COUNT_INFO:{ ROW_SCANNED: 300000000, ROW_SORTED: 530145428, ROW_INSERTED: 185408772 }, INSERT_PROGRESS_INFO:{ INSERT_TIME_ELAPSED: 385.758s, INSERT_PROGRESS: 36.95%, INSERT_TIME_REMAINING: 658.297s }, SLOWEST_THREAD_INFO:{ THREAD_ID: 22604, INSERTED_ROW_COUNT: 46306700 }
1 row in set (0.07 sec)

mysql> select * from oceanbase.gv$ob_memstore;
±--------------±---------±----------±------------±---------------±-----------±--------------±---------------+
| SVR_IP | SVR_PORT | TENANT_ID | ACTIVE_SPAN | FREEZE_TRIGGER | FREEZE_CNT | MEMSTORE_USED | MEMSTORE_LIMIT |
±--------------±---------±----------±------------±---------------±-----------±--------------±---------------+
| 10.186.63.162 | 2882 | 1002 | 241172480 | 2104543172 | 0 | 241172480 | 9180492550 |
| 10.186.63.26 | 2882 | 1002 | 270532608 | 2104543172 | 0 | 270532608 | 9180492550 |
| 10.186.63.42 | 2882 | 1002 | 180355072 | 2104543172 | 0 | 180355072 | 9180492550 |
±--------------±---------±----------±------------±---------------±-----------±--------------±---------------+
3 rows in set (0.03 sec)

mysql>

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

[论坛小助手]

用户问题: 在 OB-v4 版本 4.3.5.2 中，视图 oceanbase.GV$OB_MEMSTORE 的字段 FREEZE_CNT 始终为 0。在 1-1-1 架构的集群和 8c19g 规格的租户下创建了包含 3 亿行数据的表，并进行了列类型改动操作。
推荐使用 obdiag 工具进行日志采集，以便我们能够更好地理解您的情况并提供解决方案。
日志采集场景: 内存问题
日志采集命令: obdiag gather scene run --scene=observer.memory

请您执行上述命令，将采集到的日志提供给我们以便确认问题所在。另外，为了更准确地诊断问题，请您提供以下信息：

1. 您进行列类型改动操作的具体步骤是什么？
2. 当前集群的配置和状态是否正常？
3. 是否有其他异常日志或告警信息出现？
4. 表的结构（如索引、分区情况等）能否提供？
5. 执行 DDL 操作时是否有充足的内存资源？
6. 您的操作系统和硬件环境如何？

附上敏捷诊断工具 obdiag 使用帮助链接

[辞霜]

查询一下该租户的meta租户1001。

[小哲豆腐花]

mysql> select * from oceanbase.gv$ob_memstore;
±--------------±---------±----------±------------±---------------±-----------±--------------±---------------+
| SVR_IP | SVR_PORT | TENANT_ID | ACTIVE_SPAN | FREEZE_TRIGGER | FREEZE_CNT | MEMSTORE_USED | MEMSTORE_LIMIT |
±--------------±---------±----------±------------±---------------±-----------±--------------±---------------+
| 10.186.63.162 | 2882 | 1 | 144703488 | 290527068 | 0 | 144703488 | 1288490160 |
| 10.186.63.162 | 2882 | 1001 | 83886080 | 185770144 | 0 | 81788928 | 816043760 |
| 10.186.63.162 | 2882 | 1002 | 253755392 | 2104543172 | 0 | 253755392 | 9180492550 |
| 10.186.63.26 | 2882 | 1 | 150994944 | 291046028 | 0 | 150994944 | 1288490160 |
| 10.186.63.26 | 2882 | 1001 | 83886080 | 167759624 | 0 | 83886080 | 816043760 |
| 10.186.63.26 | 2882 | 1002 | 285212672 | 2104543172 | 0 | 285212672 | 9180492550 |
| 10.186.63.42 | 2882 | 1 | 115343360 | 303710048 | 0 | 115343360 | 1288490160 |
| 10.186.63.42 | 2882 | 1001 | 69206016 | 183551744 | 1 | 69206016 | 816043760 |
| 10.186.63.42 | 2882 | 1002 | 239075328 | 2104543172 | 0 | 239075328 | 9180492550 |
±--------------±---------±----------±------------±---------------±-----------±--------------±---------------+
9 rows in set (0.02 sec)

[辞霜]

新环境么，这边测试环境手动触发一次冻结后是正常记录的。

[小哲豆腐花]

手工触发冻结确实记录了。

下午我再测试下3亿表的添加字段，删除字段，看是否会记录