可以用 obdiag gather all 先收集下常规信息发出来，了解更多信息才有排查方向。还有原始点的办法就是去搜这条SQL的trace日志，也能知道是啥原因。
obdiag可以参考下面这个文档
https://www.oceanbase.com/docs/common-obdiag-cn-1000000002023146
1 个赞
根据SQL的内容，过滤一下observer的日志，找到trace_id,看下drop 动作为啥超时了
1 个赞
补充下细节，dml语句正常，即增删改查表里的数据都是ok的，但是执行ddl都会卡住。
有好几个日志文件，在哪个里面找？用select last_trace_id()搜出来最后一个执行的trace_id在几个日志中没有找到相关内容。
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*
6）提供日志信息。
select * from gv$ob_sql_audit where query_sql like ‘%drop table sys_aksk%’\G
单引号不是英文的，自己修改一下
是不是可以看一下详细的执行过程或者执行计划什么的吧
DROP 看执行计划没有什么用，我怀疑4012是发送RPC消息到某个节点超时了，先检查下所有节点是否正常吧，具体原因得看observer日志
sys 租户下面执行 select * from oceanbase.dba_ob_servers;看下所有节点的状态
日志还得再等下，现在还在卡着，还没报超时的错误，日志里还没查到多少trace id相关的内容。
有点不太对啊，为啥我用这条命令查出来的trace有3条。
发下查询内容，或者截图
