enq: SQ - contention等待事件，咱來一步步分析awr報告找到問題所在。
在快照期間數據庫一定發生了什么事情。
第一條便是enq:SQ - contention，占用了大部分的DB Time
然后查找enq:SQ - contention的MOS文檔，很容易就找到其cause：
The most common cause is that one or more sequences are getting used heavily, and the cache size for those sequences may not be adequate for RAC
也就是說是由於sequence設置不合理導致
為了解決這個問題，我們來着重理解一下sequence的cache特性
sequence也就是我們說的序列號，一般來說建立sequence是為了完成所求變量的自增。在sequence中有非常關鍵的屬性cache，cache就是sequence的緩存，當我們建立sequence的時候，就需要指定cache值（當然也有默認值），比如說當sequence從1一直nextval到20，這個時候緩存中的sequence值都取完了，必須重新取緩存值21，內存中的值也就到了21-40。
這個cache的問題有什么意義呢？
如果sequence定義為nocache，也就是不緩存，每次取nextval都會重新計算nextval的值，而不是直接從內存中讀取，從性能上來講這肯定效率較低。
為什么oracle不直接把默認值設置的很大？
首先內存肯定是有限的，為了一個sequence就犧牲數據庫的內存也太不應該了。其次，為了安全。當oracle數據庫宕機的時候，內存中的sequence cache也都找不到了，比如說cache值為10000，nextval已經取到了9999，內存中的cache值仍為1-10000，這個時候數據庫宕機，內存中的數據找不回來了，數據庫重新啟動后業務的sequence重新取值，就得從1開始取，而不是10000。所有cache值設置的太大也不合適
了解了sequence，就能理解mos提供的解決辦法：
1.盡量把非cache noorder的sequence設置成cache noorder
2.如果是cache noorder，且cache值小於100，設置成更大的值（cache默認值為20），mos建議值為10000.
（參考文檔：High "enq: SQ - contention" waits in RAC (文檔 ID 2156730.1)）
馬上查找了數據庫中所有sequence的cache設定，很多用戶都是設置的默認值20或者或者很小的值.
但是sequence有幾百個，全部修改的話動作較大，找到問題sequence修改就足夠了。
所以再繼續看awr
從上面的TOP SQL和對應的SQL Text就可以看出，
在快照時間內，數據庫一定發生了大量的插入操作，在插入操作中使用了大量的sequence，所以將這些sequence做出修改，enq:SQ - contention等待事件就會舒緩許多