ob事务带来的疑问

[AntTech_NHY7X8]

ob服务告警说有长事务，发现以下几个疑问问题

1. 在租户的事务诊断里，事务 Hash没变，但是刷新多次发现会话id在变化，会有2个不同的id,按理说一个事务，不应该是只有一个会话id吗？因没有保留当时的截图，所以截图个空的截图供参考
   
   
2. 通过 事务详情页面，查看已执行 SQL 详情，点进更新的sql进入SQL详情页面，发现SQL 采样的sql原始文本的内容不对，值几乎都是一样的，但是实际上我们的sql的值并不一样
   
   
3. 在已执行 SQL 详情里有个START TRANSACTION命令，这个确定是用户发的请求吗？研发保证说代码里没有启用这个事务指令,所以这里在想请官方确定一下，目前我们也在抓包确认这个问题
   
   

[旭辉]

发下OCP版本和OB版本

第1，2个问题，我再看看
第3个问题 是否设置了全局参数 事物默认不提交？

set global autocommit=0;

[Sunshining]

向大佬学习

[AntTech_NHY7X8]

ocp版本号: 4.3.2-20241012145836
ob版本：4.2.5.5
查看了全局参数autocommit 为默认值1

[旭辉]

类似第3个问题截图中 带start transaction的sql 多吗？

直接在租户中查询gv$ob_sql_audit 能捕捉到这种sql吗？

[AntTech_NHY7X8]

1. 第3个问题截图中 带start transaction的sql 不多，只在出现长事务锁的时候才发现，平时的抓包里也看不到start transaction这个请求的sql query
2. 直接在租户中查询gv$ob_sql_audit没有看到这种sql

[旭辉]

这个事物中包含了多条select，所以变成长事物了，看起来是有业务逻辑在里面的，建议从业务开发层了解下 看看是否合理

[旭辉]

@AntTech_NHY7X8

autocommit

如果代码中没有显示开启事物，看下代码里面是否设置了session级的autocommit=0，不然数据库不会自动执行start transaction的

[AntTech_NHY7X8]

好的，我也通过抓包进一步证实是用户侧开启的事务，辛苦在看下第一个疑问和第二个疑问

[旭辉]

@AntTech_NHY7X8

一个事务，不应该是只有一个会话id吗？

在分布式架构下，由于 SQL 请求可能被路由到不同的 OBServer 节点上执行 ，导致 connection_id() 返回的值不一致

• 每个 OBServer 节点独立维护自己的连接 ID 空间。
• 同一个客户端会话在不同时间执行 SQL 时，如果请求被路由到不同的 OBServer，connection_id() 查询结果就会不同。
• 这并不意味着事务跨多个会话运行，而是因为连接代理（如 ODP）或负载均衡机制将请求分发到了不同的物理节点。

https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000209980

[旭辉]

第二个问题，SlowSQL中SQL采样到的SQL原始文本与实际SQL不相符，这个是OCP的已知问题，在OCP4.3.6BP1修复了，也就是目前最新的社区版OCP修复了