問題背景：
客戶反饋系統突然很慢，查詢awr報告
1 658whw2n7xkd2 BEGIN SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_02', 'SYS'); END;
數據庫在取數據塊時為了保護內存的數據結構而加了latch(一種鎖，很短暫），當SQL邏輯讀過高，在並發的情況下大家都要去取相同的數據庫而產生的等待，
出現這兩個等待事件，基本上是由於大量的邏輯讀競爭造成，那么直接去查邏輯讀或物理讀模塊就可以看到問題所在。既然是並發情況下競爭去讀取同一塊，那邊在AWR上看肯定是長時間無返回的語句
發現此sql占用了大量的read：
1 BEGIN SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_02', 'SYS'); END;
當時沒搞明白，這語句塊代表啥意思，百度搜了一下是用EXPDP在備份數據，客戶確認確實有定時備份任務，建議用戶調整備份時間
數據泵expdp需要全表掃，要把數據塊都讀到內存中，進行導出，當進入內存后，expdp獲得了數據塊的latch，但是這時候有個sql進來了，
要訪問的數據塊expdp正在訪問，SQL也要獲得latch，雖然latch很快，但是此時訪問的特別多，問題的嚴重性就出來了，
其實這個latch爭用嚴重的時候並不是用戶反饋慢這么簡單，有的會直接使CPU使用率達到97%以上，或者直接導致session數據達到最大值，
新的session無法創連等！因此數據泵的導出最好放在業務低峰期間，並且要留有足夠的運行時間，因隨着數據庫的數據量的增加，
原有一個小時備份結束的可能某一天需要幾個小時才能完成，放在早上五點顯然沒有給運行留下太多時間，因此必須調整了刪除這樣的備份任務。
關於latch:cache buffers chains和wait list latch free的原理，buffer cache中block的header被放置到hash chains上，
而hash chains又是放在hash bucket中，多個hash bucket被一個cache buffers chains latch保護。當多個session並發訪問同一個數據塊上的數據，
每個session都要首先獲得cache buffers chains latch，這樣將造成cache buffers chains latch的爭用。