公司用戶反饋一系統在14:00~15:00（2016-08-16）這個時間段反應比較慢，於是生成了這個時間段的AWR報告， 如上所示，通過Elapsed Time和DB Time對比分析，可以看出在這段時間內伺服器並不繁忙。分析Top 5 Timed Events，我們可以看到前五的等待事件 可以看... ...
公司用戶反饋一系統在14:00~15:00（2016-08-16）這個時間段反應比較慢，於是生成了這個時間段的AWR報告，
如上所示，通過Elapsed Time和DB Time對比分析，可以看出在這段時間內伺服器並不繁忙。分析Top 5 Timed Events，我們可以看到前五的等待事件
可以看到等待事件enq: TX - row lock contention占了所有等待事件17.3%的比例，猜測有可能是鎖等待（enqueue等待）引起的阻塞導致，但是這個還不能下定論，因為畢竟CPU Time和db file sequential read等待事件所占的比例要大。於是我就使用awrddrpt.sql生成了15號與16號同一時段的AWR對比報告。
如上所示，16號14:00-15:00的DB Time反而比15號的DB Time小，從Top 5 Timed Events來看， 15號沒有enq: TX - row lock contention等待事件，那麼很有可能是這個引起的，那麼我接下來看看16號14:00-15:00時間段的AWR報告的Wait Events，如下所示，enq: TX - row lock contention的Total Waits Tims(s)為1022秒，Avg Waits(ms)為2848毫秒，說明鎖等待（enqueue等待）還是蠻嚴重的。
那麼我們去檢查Segments by Row Lock Waits，看看是那些對象產生了等待事件““enq: TX - row lock contention”，如下所示，主要是表INV_NEXT_NO，以及索引IDX_INV_SRN_HD_N1
另外在bdump的trace文件中發現在14:30左右出現了TNS-12535 & TNS-1260錯誤，那麼我就來生成14:25:00~14:35:00這個時間段的ASH報告來分析一下
Client Address = (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.xxx.xxx)(PORT=44913))
*** 2016-08-16 14:32:36.012
NS Primary Error: TNS-12535: TNS:operation timed out
NS Secondary Error: TNS-12606: TNS: Application timeout occurred
kmduicxd: 0x7f381c4bc770, kmduiflg: 1, circuit: 0x3778688f0
(circuit) dispatcher process id = (0x37f799ef8, 1) parent process id = (17, 1) serial # = 416connection context = 0x7f381c4bc770
user session = ((nil)), flag = (100c0), queue = (9)
current buffer = (0), status = (4, 0)
Client Address = (ADDRESS=(PROTOCOL=tcp)(HOST=192.168.xxx.xx)(PORT=60069))
*** 2016-08-16 14:32:58.679
NS Primary Error: TNS-12535: TNS:operation timed out
NS Secondary Error: TNS-12606: TNS: Application timeout occurred
kmduicxd: 0x7f381c4bd960, kmduiflg: 1, circuit: 0x377942fd0
(circuit) dispatcher process id = (0x37f799ef8, 1) parent process id = (17, 1) serial # = 798connection context = 0x7f381c4bd960
user session = ((nil)), flag = (100c0), queue = (9)
current buffer = (0), status = (4, 0)
可以看出主要是因為下麵語句造成的
SELECT NEXT_NO FROM INV_NEXT_NO WHERE PREFIX_CODE = :B1 FOR UPDATE
select next_no from inv_next_no where prefix_code = 'SRN-YMG-201608-' for update
想必你一看到FOR UPDATE語句，心裡就已經知道了七七八八了,當兩個會話或多個會話同時更新某一行時,就會出現enq: TX - row lock contention等待事件,如果其中一個會話遲遲不提交事務或是由於網路等其其它故障出現,那麼其它會話就會一直等待這個資源,併發高的情況下,就會出現大量阻塞。這個還真是因為不合理的設計所造成的。因為系統要生成唯一併且連續的單號（首碼+數字），為了獲取唯一併且連續的單號，所以使用SELECT FOR UPDATE這種設計來實現，沒有使用SEQUENCE（因為SEQUENCE可能會跳號，造成單號不連續），也不能使用其它方式了。如果能修改生成單號的業務邏輯，這個問題就好解決了。
