【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
1.全局序列lsn号是怎么产生和分配的？？
- 归档的intterupt是怎么 判断出来的
2 个赞
全局序列LSN号是在事务提交过程中随着clog一起生成的，用于唯一标识事务日志记录，并且确保日志记录的有序性。归档的interrupt可能是由于clog管理过程中遇到的各种异常情况所导致的，具体的情况需要进一步查阅相关技术文档或联系技术支持获取更多信息。
更多信息请查看:
2 个赞
在 OceanBase 数据库 V4.0.0 版本中，一条日志使用日志流内唯一的 LSN (Log Sequence Number) 表示。LSN 是在日志流（Log Stream, LS）内部分配的，每个 LS 内部的日志条目都会被分配一个唯一的 LSN。这个 LSN 可以在内存及磁盘上唯一定位一条日志。对于已经明确提交的日志，在多个副本之间完全一致。
更多信息请查看:
1 个赞
在 OceanBase 数据库中，LSN (Log Sequence Number) 用于表示一条日志在日志流内的唯一位置。LSN 的生成逻辑和流程如下：
- 当事务系统需要记录日志时，Palf（Paxos Backed Append Only Log File System）负责为每条日志分配一个 LSN。
- Palf 通过全局时钟服务获取一个单调递增的时间戳，该时间戳用作 LSN 的一部分，确保每条日志的 LSN 是唯一的并且有序。
- 日志被追加到日志流中时，Palf 会将 LSN 写入日志头信息，从而使得每条日志都有一个唯一的 LSN。
- 日志在多个副本之间同步时，Palf 会确保 LSN 在所有副本中保持一致，从而保证日志的完整性和一致性。
详情请参考:
2 个赞
LSN (Log Sequence Number) 和 SCN (System Change Number) 都是数据库中的重要概念，但在 OceanBase 中它们各自代表不同的含义：
-
LSN (Log Sequence Number):
- LSN 是日志序列号，通常用来标识日志文件中的位置。在 OceanBase 中，
START_LSN和END_LSN字段用于描述数据字典在租户一号日志流中持久化的第一个和最后一个日志的 LSN。 - LSN 通常是一个单调递增的数字，用于追踪事务日志的位置。
- LSN 是日志序列号，通常用来标识日志文件中的位置。在 OceanBase 中，
-
SCN (System Change Number):
- SCN 是系统变更号，用于标记数据库中的事务提交点。在 OceanBase 中，
START_SCN和END_SCN字段用于描述归档日志的开始和结束 SCN。 - SCN 也是单调递增的，用于确保数据的一致性和恢复。
- SCN 是系统变更号，用于标记数据库中的事务提交点。在 OceanBase 中，
总结来说，LSN 主要用于日志文件的管理和定位，而 SCN 用于事务的一致性和恢复。
检索到的文档如下:
1 个赞
SCN (System Change Number) 的生成与时间戳有关，具体可以通过 TIMESTAMP_TO_SCN() 函数将时间戳类型的参数转换为对应的 SCN。此外，SCN 也用于描述日志归档的组织，如 END_SCN 描述 Piece 的结束 SCN。具体生成机制并未在提供的文档中详细描述，但可以推断 SCN 是系统自动生成的一个序号，用来标识数据库中的变化。
详情请参考:
要判断LSN是否丢失，可以通过查询 oceanbase.DBA_OB_LS 视图来获取日志流的状态和同步信息。具体检查以下字段：
-
SYNC_SCN：表示已经同步的日志序列号。如果该值持续增长且没有停滞，通常表明LSN同步正常。 -
STATUS：表示日志流的状态。如果状态为NORMAL，通常表示日志流没有异常。 -
READABLE_SCN：表示可读的日志序列号。如果该值与SYNC_SCN值接近且没有显著差距，通常表明LSN没有丢失。
更多信息请查看:
我这的疑问是：有2个
- 日志归档进程通过什么方式判断出 clog被覆盖了？？
- scn是怎么生成并分配的？ 单调递增有序 1 2 3 4是否这样子的。或者真实是啥
- LSN 是怎么生成并分配的？ 单调递增有序1 2 3 4是否这样子的。或者真实是啥
打卡学习~~
1、请求的 LSN 小于系统当前可读的起始 LSN，说明该位置的日志已被回收/覆盖。
2、 SCN 的生成与分配：
-
生成：基于机器时钟（纳秒级时间戳）
-
分配：由 GTS Leader 通过 函数分配，保证单调递增
-
转换：通过函数 将时间戳转换为 SCN
-
保证：单调递增、全局唯一、基于时间
SCN 本质上是全局单调递增的时间戳，用于标识事务提交顺序和版本。
3、 LSN 的生成与分配：
-
计算方式：LSN = block_id * PALF_BLOCK_SIZE + block_offset
-
分配器：分配器 负责分配
-
原子操作：使用 128 位 CAS 保证并发安全
-
智能聚合：支持日志聚合、padding、跨 block 等
-
边界处理：处理 2M 切分、4KB padding、block 边界等
LSN 本质是日志在日志流中的字节偏移量，通过 block_id 和 block_offset 计算得出，保证单调递增和连续性。
scn 是怎么 保证连续性的？？
是不是只有提交的事务 才会产生 scn ?? rollback的事务z在开始不会分配scn??
事务一开始就分配scn呢？ 还是事务在commit时分配scn???
scn 不能保证连续性 只保证单调递增
scn产生大概是这样的
○ 在事务/语句（取决于隔离级别）开始时从GTS分配时间戳，用于事务/语句级别的快照；
○ 在事务提交时，从GTS分配时间戳，用于事务版本号的一个参考值（记做ref_ts）；
○ 对于事务的prepare/commit日志，在提交日志时，会传入ref_ts。Palf会基于ref_ts生成一个log_ts，满足如下规则：
■ 在同一个日志流上，每一条日志有一个唯一的log_ts；
■ lsn更大的日志有更大的log_ts；
■ log_ts = max (ref_ts, 最大已分配log_ts + 1);
○ Palf分配的log_ts作为事务版本号使用；
1 个赞
666
666