在事务1中执行update tableA 操作并且未提交，接着在事务2中执行truncate tableA操作，执行会卡住。但奇怪的是，在视图__all_virtual_lock_wait_stat和GV$ob_locks均查不到truncate tableA被锁的信息。
麻烦提供一下详细操作截图
版本是多少？ob默认是自动提交的，是否有进行过修改为手动提交。也可能是数据量大导致truncate超时
你好，参数autocommit值还是ON，并且表中只有1条记录，排除是因为数据量导致的truncate超时。我后面在会话1执行了commit操作后，会话2的truncate马上执行完成，所以应该就是锁导致的。版本号是5.7.25-OceanBase_CE-v4.2.5.7。
1）设置trace信息
SET ob_enable_show_trace=‘ON’;
2）执行sql。
3）获取上个命令的trace
select last_trace_id();
4）获取trace对应的节点
select query_sql,svr_ip from gv$ob_sql_audit where trace_id=‘第三步获取的trace信息’；
5）取对应的svr_ip节点 过滤日志
grep “第三步获取的trace信息” observer.log*
grep “第三步获取的trace信息” rootservice.log*
提供一下truncate语句的日志信息
锁等待只发生在 DML 与 DML 冲突时，例如两个 UPDATE 修改同一行。这是事务层行锁管理器负责的。
truncate是DDL scheduler 统一调度。
DML vs DML 冲突: 事务层 → 行锁管理器 → 产生 lock wait 日志
DDL vs DML 冲突: DDL scheduler 层 → 检测到有活跃事务 → 返回 OB_EAGAIN
那也就是，要排查DDL是否被锁，只能通过某个表是否持有锁来判断。无法直接查询DDL获取锁失败的记录对吗。
确认有表锁， – 查看当前表锁持有情况（租户内执行）
SELECT * FROM oceanbase.DBA_OB_TABLE_LOCK_WAITERS;