OceanBase snapshot_gc_ts 是什么,如何查询?17认证网

正规官方授权
更专业・更权威

OceanBase snapshot_gc_ts 是什么,如何查询?

作者:范计杰
墨天轮数据库管理服务团队技术顾问
从事Oracle数据库技术服务10余年,近3年开始转型国产、开源数据库运维(OCEANBASE、PostgreSQL等),先后管理维护金融、能源、运营商以及政企事业单位等客户的核心数据库,擅长数据库故障诊断、性能调优、异常恢复、运维自动化、高级技术咨询等。
snapshot_gc_ts 是 OceanBase 数据库中用于控制 快照垃圾回收(Snapshot Garbage Collection) 的一个关键时间戳,主要用于通知存储层可以安全清理的历史多版本数据的边界。
一、snapshot_gc_ts 的作用
定义与用途:
snapshot_gc_ts 表示系统允许清理所有早于该时间戳的多版本快照。
OBS(OceanBase Storage)在进行 compaction 时,会依据此时间戳判断哪些历史版本的数据可以被回收,从而减少磁盘空间占用。
如果该值长时间不推进,会导致大量历史版本堆积,引发频繁转储(minor freeze)、磁盘压力增大和查询性能下降。
存储位置:
该值存储在内部系统表 __all_core_table 中,table_name = ‘__all_global_stat’ 的记录中包含 snapshot_gc_ts 字段。
正常行为:
正常情况下,snapshot_gc_ts 应随系统运行持续向前推进,通常与当前时间相差不大(如小于 1 小时)。
若超过半小时未推进,系统会打印 WARN 日志;若超过 1 小时未推进,则打印 ERROR 日志,需引起关注。
特殊场景说明:
在备库(Standby)环境中,当副本尚未完全同步时,snapshot_gc_ts 可能暂停推进,这是正常现象,无需报警。
主要应关注 cluster_type = PRIMARY 的集群实例中的 snapshot_gc_ts 状态。
二、如何查询 snapshot_gc_ts
目前 OceanBase 没有直接暴露 snapshot_gc_ts 的视图(如 GV$OB_PARAMETERS 或 CDB_OB_*),但可以通过以下方式间接查看或诊断:
方法一:通过日志查看 snapshot_gc_ts 值
在 observer.log 中搜索关键字 snapshot_gc,可找到类似如下错误日志:
cat observer.log|grep snapshot_gcupdate min reserved snapshot(reserved_snapshot=1766457233558465000, duration=1800, snapshot_gc_ts_=1766459033558465000)[2025-12-23 11:04:01.185127] INFO  [STORAGE] try_update_reserved_snapshot (ob_tenant_freeze_info_mgr.cpp:1048) [8537][T1006_FreInfoRe][T1006][Y0-0000000000000000-0-0] [lt=20] success to update min reserved snapshot(reserved_snapshot=1766457238647468000, duration=1800, snapshot_gc_ts_=1766459038647468000)[2025-12-23 11:04:01.337493] INFO  [STORAGE] update_info (ob_tenant_freeze_info_mgr.cpp:768) [2946][T1034_FreInfoRe][T1034][Y0-0000000000000000-0-0] [lt=32] ObTenantFreezeInfoMgr success to update infos(snapshot_gc_ts=1766459032094536000, min_major_snapshot=1, cur_idx=0, info_list_[0]=[{freeze_version:1, schema_version:1, cluster_version:17180001539}, {freeze_version:1762884000833342000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1762970400632840000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763056805032438000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763143200519952000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763229601764965000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763316001688470000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763402401380153000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763488800450500000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763575200646841000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763661602419946001, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763748002770156000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763834403563879000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763920803688002000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764007203865985000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764093604095798000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764180003830704000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764266403826206000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764352804478602000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764439204381599000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764525604452978000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764612000179628000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764698404700482001, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764957604055095000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765044002649289000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765130400316474000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765216802629872000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765303204907400000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765389602915981000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765476000404827000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765562403094084000, schema_version:1765526007759472, cluster_version:17180001539}, {freeze_version:1765648805063896000, schema_version:1765526007759472, cluster_version:17180001539}], info_list_[1]=[{freeze_version:1, schema_version:1, cluster_version:17180001539}, {freeze_version:1762884000833342000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1762970400632840000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763056805032438000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763143200519952000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763229601764965000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763316001688470000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763402401380153000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763488800450500000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763575200646841000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763661602419946001, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763748002770156000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763834403563879000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1763920803688002000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764007203865985000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764093604095798000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764180003830704000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764266403826206000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764352804478602000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764439204381599000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764525604452978000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764612000179628000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764698404700482001, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1764957604055095000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765044002649289000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765130400316474000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765216802629872000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765303204907400000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765389602915981000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765476000404827000, schema_version:1761640183844552, cluster_version:17180001539}, {freeze_version:1765562403094084000, schema_version:1765526007759472, cluster_version:17180001539}, {freeze_version:1765648805063896000, schema_version:1765526007759472, cluster_version:17180001539}], snapshots_[0]=[], snapshots_[1]=[])[2025-12-23 11:04:01.947240] INFO  [STORAGE] try_update_reserved_snapshot (ob_tenant_freeze_info_mgr.cpp:1048) [8325][T1005_FreInfoRe][T1005][Y0-0000000000000000-0-0] [lt=114] success to update min reserved snapshot(reserved_snapshot=1766457238656277000, duration=1800, snapshot_gc_ts_=1766459038656277000)[2025-12-23 11:04:02.149283] INFO  [STORAGE] try_update_reserved_snapshot (ob_tenant_freeze_info_mgr.cpp:1048) [10359][T1031_FreInfoRe][T1031][Y0-0000000000000000-0-0] [lt=37] success to update min reserved snapshot(reserved_snapshot=1766457231549344000, duration=1800, snapshot_gc_ts_=1766459031549344000)[2025-12-23 11:04:02.529033] INFO  [STORAGE] try_update_reserved_snapshot (ob_tenant_freeze_info_mgr.cpp:1048) [8014][T1002_FreInfoRe][T1002][Y0-0000000000000000-0-0] [lt=35] success to update min reserved snapshot(reserved_snapshot=1766457239213472000, duration=1800, snapshot_gc_ts_=1766459039213472000)[2025-12-23 11:04:02.827740] INFO  [STORAGE] try_update_reserved_snapshot (ob_tenant_freeze_info_mgr.cpp:1048) [2946][T1034_FreInfoRe][T1034][Y0-0000000000000000-0-0] [lt=102] success to update min reserved snapshot(reserved_snapshot=1766457232094536000, duration=1800, snapshot_gc_ts_=1766459032094536000)[2025-12-23 11:04:02.947597] INFO  [STORAGE] try_update_reserved_snapshot (ob_tenant_freeze_info_mgr.cpp:1048) [9587][T1016_FreInfoRe][T1016][Y0-0000000000000000-0-0] [lt=35] success to update min reserved snapshot(reserved_snapshot=1766457237226009001, duration=1800, snapshot_gc_ts_=1766459037226009001)[2025-12-23 11:04:03.454147] INFO  [STORAGE] try_update_reserved_snapshot (ob_tenant_freeze_info_mgr.cpp:1048) [549][T1038_FreInfoRe][T1038][Y0-0000000000000000-0-0] [lt=59] success to update min reserved snapshot(reserved_snapshot=1766457242125238000, duration=1800, snapshot_gc_ts_=1766459042125238000)[2025-12-23 11:04:03.458653] INFO  [STORAGE] try_update_reserved_snapshot (ob_tenant_freeze_info_mgr.cpp:1048) [3137][T1033_FreInfoRe][T1033][Y0-0000000000000000-0-0] [lt=34] success to update min reserved snapshot(reserved_snapshot=1766457237310202000, duration=1800, snapshot_gc_ts_=1766459037310202000)  obclient(root@sys)[oceanbase]>  select scn_to_timestamp(1766459037310202000); +---------------------------------------+ | scn_to_timestamp(1766459037310202000) | +---------------------------------------+ | 2025-12-23 11:03:57.310202            | +---------------------------------------+ 1 row in set (0.002 sec)
这表明当前的 snapshot_gc_ts 时间戳及其延迟情况。
方法二:检查系统表(需权限且谨慎操作)
虽然 __all_core_table 是内部核心表,一般不建议直接查询,但在技术支持指导下,可通过以下 SQL 查询:
— 注意:此表为内部表,仅限管理员或技术支持使用
obclient(root@sys)[oceanbase]> desc __all_core_table;+--------------+----------------+------+------+----------------------+--------------------------------+ | Field        | Type           | Null | Key  | Default              | Extra                          |+--------------+----------------+------+------+----------------------+--------------------------------+| gmt_create   | timestamp(6)   | YES  |      | CURRENT_TIMESTAMP(6|                                || gmt_modified | timestamp(6)   | YES  |      | CURRENT_TIMESTAMP(6| ONUPDATE CURRENT_TIMESTAMP(6|| table_name   | varchar(128)   | NO   | PRI  | NULL                 |                                || row_id       | bigint(20)     | NO   | PRI  | NULL                 |                                || column_name  | varchar(128)   | NO   | PRI  | NULL                 |                                || column_value | varchar(65536| YES  |      | NULL                 |                                |+--------------+----------------+------+------+----------------------+--------------------------------+6 rows inset (0.023 sec)obclient(root@sys)[oceanbase]> SELECT * FROM __all_core_table -> WHERE table_name = '__all_global_stat'AND column_name = 'snapshot_gc_ts';Empty set (0.020 sec)SELECT * FROM __all_core_table WHERE table_name = '__all_global_stat';+----------------------------+----------------------------+-------------------+--------+-------------------------+---------------------+| gmt_create                 | gmt_modified               | table_name        | row_id | column_name             | column_value        |+----------------------------+----------------------------+-------------------+--------+-------------------------+---------------------+| 2025-07-0120:37:25.396818 | 2025-07-0120:38:34.302356 | __all_global_stat |      1 | baseline_schema_version | 1751373514259360    || 2025-07-0120:37:25.396818 | 2025-07-0120:37:27.871192 | __all_global_stat |      1 | core_schema_version     | 1751373447795256    || 2025-07-0120:37:25.396818 | 2025-07-0120:37:25.396818 | __all_global_stat |      1 | current_data_version    | 17180001539         || 2025-07-0120:37:25.396818 | 2025-12-1914:55:19.565381 | __all_global_stat |      1 | ddl_epoch               | 16                  || 2025-07-0120:37:25.396818 | 2025-07-0120:37:25.396818 | __all_global_stat |      1 | gc_schema_version       | 0                   || 2025-07-0120:37:25.396818 | 2025-12-2222:55:25.475389 | __all_global_stat |      1 | rootservice_epoch       | 81                  || 2025-07-0120:37:25.396818 | 2025-12-2311:01:52.046140 | __all_global_stat |      1 | snapshot_gc_scn         | 1766458912046140000 || 2025-07-0120:37:25.396818 | 2025-07-0120:37:25.396818 | __all_global_stat |      1 | target_data_version     | 17180001539         |+----------------------------+----------------------------+-------------------+--------+-------------------------+---------------------+8 rows inset (0.006 sec)  obclient(root@sys)[oceanbase]> select scn_to_timestamp(1766458912046140000);+---------------------------------------+| scn_to_timestamp(1766458912046140000|+---------------------------------------+| 2025-12-2311:01:52.046140            |+---------------------------------------+1 row inset (0.002 sec)《《《《
⚠️ 警告:直接访问系统表可能影响稳定性,请仅在 OceanBase 技术支持指导下执行。
三、常见问题及处理
问题
描述
处理建议
snapshot_gc_ts 长时间不推进
可能由于日志归档异常、LS GC 卡住等原因导致
检查 ob_garbage_collector.cpp 相关日志,排查归档位点、checkpoint 等是否阻塞
备库 snapshot_gc_ts 不动
副本未完成拷贝前属正常现象
不需要干预,等待同步完成即可
手动触发 RS 切主
可尝试恢复卡住的状态
使用命令: ALTER TENANT sys SET primary_zone = ‘xxx’;
参考:日志归档异常导致日志流 GC 卡住的原因和解决办法
[root@observer1 log]# cat observer.log|grep ob_garbage_collector|tail -20[2025-12-23 13:42:04.183275] INFO  [CLOG] gc_check_ls_status_ (ob_garbage_collector.cpp:1646) [8360][T1005_GCCollect][T1005][Y0-0000000000000000-0-0] [lt=13] gc_candidates push_back success(ret=0, candidate={ls_id_:{id:1}, ls_status_:1, gc_reason_:0})[2025-12-23 13:42:04.183312] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1668) [8360][T1005_GCCollect][T1005][Y0-0000000000000000-0-0] [lt=30] ls status is normal, skip(id={id:1}, gc_candidates=[{ls_id_:{id:1}, ls_status_:1, gc_reason_:0}])[2025-12-23 13:42:04.183331] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1723) [8360][T1005_GCCollect][T1005][Y0-0000000000000000-0-0] [lt=17] execute_gc cost time(ret=0, time_us=20)[2025-12-23 13:42:04.444390] INFO  [CLOG] run1 (ob_garbage_collector.cpp:1358) [7832][T1001_GCCollect][T1001][Y0-0000000000000000-0-0] [lt=6] Garbage Collector is running(seq_=481176, gc_interval=10000000)[2025-12-23 13:42:04.444488] INFO  [CLOG] construct_server_ls_map_for_member_list_ (ob_garbage_collector.cpp:1493) [7832][T1001_GCCollect][T1001][Y0-0000000000000000-0-0] [lt=45self is leader, skip it(ls->get_ls_id()={id:1})[2025-12-23 13:42:04.444527] INFO  [CLOG] gc_check_member_list_ (ob_garbage_collector.cpp:1451) [7832][T1001_GCCollect][T1001][Y0-0000000000000000-0-0] [lt=26] gc_check_member_list_ cost time(ret=0, time_us=91)[2025-12-23 13:42:04.444560] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1723) [7832][T1001_GCCollect][T1001][Y0-0000000000000000-0-0] [lt=27] execute_gc cost time(ret=0, time_us=1)[2025-12-23 13:42:04.449549] INFO  [CLOG] gc_check_ls_status_ (ob_garbage_collector.cpp:1646) [7832][T1001_GCCollect][T1001][Y0-0000000000000000-0-0] [lt=9] gc_candidates push_back success(ret=0, candidate={ls_id_:{id:1}, ls_status_:1, gc_reason_:0})[2025-12-23 13:42:04.449613] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1668) [7832][T1001_GCCollect][T1001][Y0-0000000000000000-0-0] [lt=51] ls status is normal, skip(id={id:1}, gc_candidates=[{ls_id_:{id:1}, ls_status_:1, gc_reason_:0}])[2025-12-23 13:42:04.449653] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1723) [7832][T1001_GCCollect][T1001][Y0-0000000000000000-0-0] [lt=37] execute_gc cost time(ret=0, time_us=41)[2025-12-23 13:42:04.809998] INFO  [CLOG] run1 (ob_garbage_collector.cpp:1358) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=6] Garbage Collector is running(seq_=480944, gc_interval=10000000)[2025-12-23 13:42:04.810054] INFO  [CLOG] construct_server_ls_map_for_member_list_ (ob_garbage_collector.cpp:1493) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=31self is leader, skip it(ls->get_ls_id()={id:1})[2025-12-23 13:42:04.810080] INFO  [CLOG] construct_server_ls_map_for_member_list_ (ob_garbage_collector.cpp:1493) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=21self is leader, skip it(ls->get_ls_id()={id:1001})[2025-12-23 13:42:04.810109] INFO  [CLOG] gc_check_member_list_ (ob_garbage_collector.cpp:1451) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=18] gc_check_member_list_ cost time(ret=0, time_us=79)[2025-12-23 13:42:04.810139] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1723) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=23] execute_gc cost time(ret=0, time_us=0)[2025-12-23 13:42:04.813078] INFO  [CLOG] gc_check_ls_status_ (ob_garbage_collector.cpp:1646) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=10] gc_candidates push_back success(ret=0, candidate={ls_id_:{id:1}, ls_status_:1, gc_reason_:0})[2025-12-23 13:42:04.815622] INFO  [CLOG] gc_check_ls_status_ (ob_garbage_collector.cpp:1646) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=42] gc_candidates push_back success(ret=0, candidate={ls_id_:{id:1001}, ls_status_:1, gc_reason_:0})[2025-12-23 13:42:04.815679] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1668) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=49] ls status is normal, skip(id={id:1}, gc_candidates=[{ls_id_:{id:1}, ls_status_:1, gc_reason_:0}, {ls_id_:{id:1001}, ls_status_:1, gc_reason_:0}])[2025-12-23 13:42:04.815701] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1668) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=20] ls status is normal, skip(id={id:1001}, gc_candidates=[{ls_id_:{id:1}, ls_status_:1, gc_reason_:0}, {ls_id_:{id:1001}, ls_status_:1, gc_reason_:0}])[2025-12-23 13:42:04.815714] INFO  [CLOG] execute_gc_ (ob_garbage_collector.cpp:1723) [9666][T1016_GCCollect][T1016][Y0-0000000000000000-0-0] [lt=12] execute_gc cost time(ret=0, time_us=37) [root@observer1 log]
 四、相关参考视图(辅助诊断)
虽然不能直接查 snapshot_gc_ts,但以下视图可用于辅助分析快照状态:
该视图从 V4.3.0 版本开始引入。
 GV$OB_LS_SNAPSHOTS:展示日志流级别的快照信息(从 V4.3.0 引入)
字段包括:TENANT_ID, LS_ID, SNAPSHOT_ID, SVR_IP 等
可用于查看各日志流上的快照分布情况 https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000003978816)
总 结
snapshot_gc_ts 是决定多版本清理边界的关键时间戳,对系统稳定性和性能至关重要。
它存储在内部表 __all_core_table 中,无法通过标准视图直接查询。
推荐通过日志监控其变化,结合 GV$OB_LS_SNAPSHOTS 视图进行综合诊断。
若发现长时间停滞,请及时联系 OceanBase 技术支持介入分析。

想了解更多干货,可通过下方扫码关注

可扫码添加上智启元官方客服微信👇

未经允许不得转载:17认证网 » OceanBase snapshot_gc_ts 是什么,如何查询?
分享到:0

评论已关闭。

400-663-6632
咨询老师
咨询老师
咨询老师