【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1.8
【问题描述】
执行以下导入操作，执行到半小时会报错
insert /*+ append direct(false,0,'full') enable_parallel_dml parallel(24) */ into lineitem1 select * from lineitem order by l_orderkey asc limit 300000000;
Fri Oct 25 17:21:49 CST 2024
ERROR 6002 (HY000) at line 1: Transaction context does not exist
real 29m33.858s
user 0m0.009s
sys 0m0.002s
Fri Oct 25 17:51:23 CST 2024
1、–根据时间和执行语句查询诊断信息
select query_sql,svr_ip,TRACE_ID,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE,FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),’%Y-%m-%d %H:%i:%S’) from GV$OB_SQL_AUDIT
WHERE tenant_id=1002 and REQUEST_TIME>=‘2024-04-05 14:34:00’ and lower(query_sql) like ‘%insert /*+ append direct(false,0,‘full’) enable_parallel_dml parallel(24) */ into lineitem1 select * from lineitem order by l_orderkey asc limit 300000000%’ order by elapsed_time desc
limit 10;
2、应该是有行锁冲突 可以用obdiag诊断锁冲突
-- 查看当前的事务超时时间
SHOW VARIABLES LIKE 'ob_trx_timeout';
SHOW VARIABLES LIKE 'ob_trx_idle_timeout';
-- 修改事务超时时间
SET GLOBAL ob_trx_timeout = 1800000000; -- 30分钟
SET GLOBAL ob_trx_idle_timeout = 1800000000; -- 30分钟
EXPLAIN SELECT * FROM lineitem ORDER BY l_orderkey ASC LIMIT 300000000;
分批插入数据：
如果数据量非常大，可以考虑分批插入数据，以减少单个事务的执行时间。
-- 分批插入数据
INSERT /*+ append direct(false,0,'full') enable_parallel_dml parallel(24) */ INTO lineitem1 SELECT * FROM lineitem WHERE l_orderkey BETWEEN 1 AND 100000000;
INSERT /*+ append direct(false,0,'full') enable_parallel_dml parallel(24) */ INTO lineitem1 SELECT * FROM lineitem WHERE l_orderkey BETWEEN 100000001 AND 200000000;
INSERT /*+ append direct(false,0,'full') enable_parallel_dml parallel(24) */ INTO lineitem1 SELECT * FROM lineitem WHERE l_orderkey BETWEEN 200000001 AND 300000000;
检查系统资源：
确保系统资源（如 CPU、内存、磁盘 I/O）充足，避免因资源不足导致事务超时。
使用 top、iostat 等命令监控系统资源使用情况。
日志分析：
继续使用 obdiag 工具进行日志分析，以获取更多详细的错误信息。
obdiag rca run --scene=transaction_other_error
obdiag gather scene run --scene=observer.sql_err --env "{db_connect='-h127.0.0.1 -P2881 -utest@test -p****** -Dtest', trace_id='YB420A0AA020-0006255A3FFD4350-0-0'}"
检索对应observer 日志，可以发现有6005错误，failed to lock write_memtable 相关信息，可确定为行级锁冲突导致的sql变慢。
1、根据trace_id=YB420A0AA020-000625996C1DA4FF-0-0 查询一下 看看这个语句执行的时间
select query_sql,svr_ip,TRACE_ID,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE,FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),’%Y-%m-%d %H:%i:%S’) from GV$OB_SQL_AUDIT
WHERE tenant_id=1002 and REQUEST_TIME>=‘2024-10-29 00:00:00’ and TRACE_ID=‘YB420A0AA020-000625996C1DA4FF-0-0’ order by elapsed_time desc
limit 10;
