現場反饋:查詢一張幾千條數據的表，一直卡住，然後重啓了數據庫，還是這樣。
1.獲取了數據庫報告，發現排在第一位的是cursor:pin s on x等待事件。
Top 10 Foreground Events by Total Wait Time
Event Waits Total Wait Time (sec) Wait Avg(ms) % DB time Wait Class
cursor: pin S wait on X 220 16K 72891 83.3 Concurrency
SQL*Net message from dblink 1,231 1114 905 5.8 Network
DB CPU 948.6 4.9
db file sequential read 166,701 859.5 5 4.5 User I/O
log file sync 23,317 192.5 8 1.0 Commit
db file parallel read 857 163.4 191 .8 User I/O
2.先要明白這個等待事件的意思：
cursor:pin s on x
A session waits for this event when it is requesting a shared mutex pin and another session is holding an exclusive mutex pin on the same cursor objec（注意在10G之後library cache pin 被mutex取代）
說當一個會話請求共享mutex pin的時候，另一個會話正好在同一個遊標對象上持有排他pin，通常發生在解析SQL的時候。
3.由於現在的問題是可以重現的，所以問題很好解決。
a.先開一個窗口1
–記錄下當前窗口的實例號和sid
select inst_id,sid from gv$mystat where rownum=1;
–查詢會被堵塞的表
select * from table_name
b.再開一個窗口2，查找誰堵塞的上面窗口的會話，s.INST_ID= and s.sid=填窗口1查出來的信息
select s.BLOCKING_INSTANCE,s.BLOCKING_SESSION from gv$session s where s.INST_ID= and s.sid=
現在查出來的 s.BLOCKING_INSTANCE,s.BLOCKING_SESSION就是製造堵塞的會話，
不過要想查出始作俑者，需要再次查找這個製造堵塞者還有沒有s.BLOCKING_INSTANCE,s.BLOCKING_SESSION，如果沒有，則說明它就是堵塞的源頭；如果有，還需要往上查。
c.先不要急着kill session，需要通過gv$session裏面的信息找到功能是什麼觸發的。因爲如果不找到觸發的原因，kill session只是治標的辦法，問題還是會出。幸運的是，本次操作是開發執行腳本，dblink查詢導致的問題。
d.kill session,如果kill不了就需要從操作系統上kill 線程。
4.如果問題不能重現，還想找到問題，怎麼辦？需要查詢dba_hist_active_sess_history，這張表是每10s，數據庫會收集一輪會話的信息。
select *
from dba_hist_active_sess_history
where event =‘cursor: pin S wait on X’
and sample_time between
to_date(‘2019-09-24 00:00:00’, ‘yyyy-MM-dd HH24:mi:ss’) and
to_date(‘2019-09-24 12:00:00’, ‘yyyy-MM-dd HH24:mi:ss’);
查詢字段中有P2，是堵塞這的sid，也有BLOCKING_INSTANCE,BLOCKING_SESSION，應該可以找到問題。