weblogic The transaction is no longer active
阿新 • • 發佈：2019-01-30
總部有個系統tzjh工作流報流程超時，無法走下去。分析效能問題，按我的風格，先做一個httpwatch的結果，根據結果大致定位。
看到結果後就是一個主請求很慢，定位到是java和SQL的問題，weblogic服務一切良好。找出問題時段的Oracle AWR，可以看到下面的SQL執行了4百多秒。
delete from gg_ru_todo_task_IPMS t
where exists (select 1
from gg_ru_temp_task tmp
where tmp.activity_ins_id = t.activity_ins_id
and tmp.ABORT_FLAG = 1)
看了一下此SQL的執行計劃，完全沒有問題，懷疑是統計資訊有問題，查詢了一下，都是對的。
--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------
| 0 | DELETE STATEMENT | | | | 24 (100)| |
| 1 | DELETE | gg_RU_TODO_TASK_IPMS | | | | |
| 2 | NESTED LOOPS SEMI | | 1 | 165 | 24 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | gg_RU_TODO_TASK_IPMS | 1147 | 145K| 24 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| gg_RU_TEMP_TASK | 1 | 35 | 0 (0)| |
|* 5 | INDEX RANGE SCAN | TEMPTASK_INDEX3 | 1 | | 0 (0)| |
--------------------------------------------------------------------------------------------------------
回頭看了一下資料庫報告，發現這條SQL沒有消耗CPU,IO，根本就是在等待，從top5的等待事件中enq: TX - row lock contention很多可以看出。
這怎麼可能呢？不同的單據刪除的資料是不一樣的啊。
看到結果後就是一個主請求很慢，定位到是java和SQL的問題，weblogic服務一切良好。找出問題時段的Oracle AWR，可以看到下面的SQL執行了4百多秒。
delete from gg_ru_todo_task_IPMS t
where exists (select 1
from gg_ru_temp_task tmp
where tmp.activity_ins_id = t.activity_ins_id
and tmp.ABORT_FLAG = 1)
看了一下此SQL的執行計劃，完全沒有問題，懷疑是統計資訊有問題，查詢了一下，都是對的。
--------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------------
| 0 | DELETE STATEMENT | | | | 24 (100)| |
| 1 | DELETE | gg_RU_TODO_TASK_IPMS | | | | |
| 2 | NESTED LOOPS SEMI | | 1 | 165 | 24 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | gg_RU_TODO_TASK_IPMS | 1147 | 145K| 24 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| gg_RU_TEMP_TASK | 1 | 35 | 0 (0)| |
|* 5 | INDEX RANGE SCAN | TEMPTASK_INDEX3 | 1 | | 0 (0)| |
--------------------------------------------------------------------------------------------------------
回頭看了一下資料庫報告，發現這條SQL沒有消耗CPU,IO，根本就是在等待，從top5的等待事件中enq: TX - row lock contention很多可以看出。
這怎麼可能呢？不同的單據刪除的資料是不一樣的啊。