根據開發反饋，最近每天早上7:30應用會報警，應用的日誌顯示數據庫連接池滿了，新的連接被拒絕。
首先，我做了ASH報告（報告區間：7:25 ~ 7:35），從ASH的等待事件發現enq: TX - row lock contention居然高達76.54%，如下所示：
Top User Events
| Event | Event Class | % Event | Avg Active Sessions |
|---|---|---|---|
| enq: TX - row lock contention | Application | 76.54 | 0.81 |
| CPU + Wait for CPU | CPU | 12.76 | 0.14 |
| db file sequential read | User I/O | 7.40 | 0.08 |
下一步就是找這個等待事件主要由哪些SQL引起的：
Top SQL with Top Events
| SQL ID | Planhash | Sampled # of Executions | % Activity | Event | % Event | Top Row Source | % RwSrc | SQL Text |
|---|---|---|---|---|---|---|---|---|
| 4rm17788qwxuy | 1272661853 | 54 | 69.45 | enq: TX - row lock contention | 69.45 | UPDATE | 69.45 | update shift_case set expertId... |
| 1cqbcdr0ufyk6 | 1272661853 | 10 | 5.20 | enq: TX - row lock contention | 5.20 | UPDATE | 5.20 | update shift_case set daySecti... |
| 1anu5c146v8d7 | 1272661853 | 4 | 1.89 | enq: TX - row lock contention | 1.89 | UPDATE | 1.89 | update shift_case set daySecti... |
| gbw4zk8jv0n0u | 2588599834 | 10 | 1.57 | CPU + Wait for CPU | 0.79 | TABLE ACCESS - BY GLOBAL INDEX ROWID | 0.47 | select sc.scId, sc.estId, ct.c... |
| dvmk92c1umc97 | 905317021 | 9 | 1.42 | CPU + Wait for CPU | 1.42 | CONNECT BY - NO FILTERING WITH START-WITH | 0.63 | select h.hospitaluuid id, h.pl... |
| 4rm17788qwxuy | update shift_case set expertId = :1 , shiftDate = :2 , daySection = :3 , rcLimit = :4 , orderingCount = :5 , shareRccount = :6 , clinicTypeUuid = :7 , fee = :8 , isTimeDivision = :9 , state = :10 , isopen=:11 , stateTime = :12 , updateTime = sysdate where scId =:13 |
好了，既然已經定位到問題就好辦了，馬上把應用開發人員找來一問，真相大白：原來該應用需要從外部系統獲取數據，爲了讓內部的數據庫和外部的儘量保持一致，每次查詢外部系統時，會在數據庫裏執行update語句。
解決辦法也簡單：由於每次的Update都會把前一次的update覆蓋（等於前面的update做的都是無用功），所以根本沒必要每次查詢都update，只要最後一次查詢做update就可以了。