All in？跑步入場？清倉？為了這些動作，Ta們在......
國慶節前的幾天A股大漲，很多資深股民紛紛狂曬朋友圈，“All in！”、“跑步入場”、“再漲30%，我就回本了”、“ 牛回，速歸，記住不要賣掉電動車！”、“3點收盤太早啦，強烈要求國慶節加班”。老股民解套在望，新股民躍躍欲試。交易量和用戶活躍度都在急劇增加，證券公司的系統性能成為了保障交易順利進行的關鍵。終于，大家期待的證券公司“加班”，真的來啦！
國慶假期期間，為了保障高并發下的系統穩定運行，中亦科技配合一些證券公司客戶加班進行了壓力測試，其中一個客戶遇到了意想不到的瓶頸，可能導致系統運行緩慢，影響交易。我們今天就一起來看看這個“新鮮”的案例！
某證券客戶對系統進行性能壓測，結果系統運行緩慢，大量會話積壓，無法達到交易目標。這一問題亟需優化處理，以確保在股市熱潮中系統能夠穩定運行。
收集問題時段AWR報告，可以看到系統的等待事件如下：
從系統的負載來看，系統中硬解析的并發量不算大，每秒161.7多左右的：
因主要在解析階段，在AWR報告中就并不進一步觀察SQL語句執行階段的問題。AWR報告顯示，系統異常等待主要是`latch:row cache objects`的等待，即出現在row cache層面的爭用。在AWR報告中，對于row cache部分的統計如下：
可以看到在dc_tablespaces和 dc_users 層面出現大量訪問請求。壓測階段通過對系統做hanganalyze，可以看到如下相關信息：
分析阻塞鏈上的各會話的short stack，可以看到：
在short stack中，可以看到此時進程處于硬解析的過程中，為了計算hash join的成本，需要用ktatminextsz函數從row cache中查找臨時表空間的最小擴展的大小，作為計算因子。我們知道要想訪問row cache，首先要拿到shared pool里的latch: row cache object，以得到相應row cache的地址。當有大量進程需要訪問dc_tablespace這個row cache object時，首先會在latch: row cache object發生爭用。由于這個爭用引發的等待，硬解析時間會變長，從而引發cursor: pin S wait on X的等待。
1、減少CBO對hash join的路徑嘗試。（顯然可能性不大）
2、減少硬解析。(每秒161次不算過分)
3、提高獲取臨時表空間最小擴展的性能。（查下有沒有相應的bug或者enhance）
針對該現象，先核查相關MOS文檔，可以查到對應的文檔，描述類似情況：對應的文檔號為2189126.1：
產生該問題的原因為bug引發：
可以看到，根據bug 13902396 的描述，產生大量對于dc_users和dc_tablespaces的row cache訪問是因為，在調用ktatminextsz函數時，高頻的訪問數據字典獲取”minimum extent
size for the users temporary tablespace”這個信息，事實上通過該bug的修復，在于直接設定返回一個值，而不再去數據字典中查找，避免出現latch爭用；從實際情況來看，臨時表空間的最小擴展基本是個固定的值，通過設備事件直接返回這個值，是可行的，幾乎不會存在什么隱患。我們只需要從ts$中查出這個最小擴展的大小，然通過event設置一下，就可以繞過對latch: row cache object及dc_tablespace、dc_user的訪問。在修復該bug后，還需要設置事件來進行優化處理。
四、最終選擇
經過綜合分析，我們最終選擇了第三個方案——提高獲取臨時表空間最小擴展的性能。具體實施步驟如下：
針對客戶數據庫版本（11.2.0.4版本），為客戶打上補丁13902396，修復了高頻訪問數據字典的問題。
通過設置事件45053，繞過對`latch: row cache object`及`dc_tablespace`、`dc_user`的訪問，直接返回臨時表空間的最小擴展大小。
通過這一方案，系統性能得到了顯著提升，解決了硬解析導致的性能瓶頸問題。在股市熱潮中，證券公司的系統性能至關重要。技術優化不僅是提升系統性能的關鍵，更是抓住市場機遇的重要保障。希望這篇文章能為大家提供有價值的參考。如果大家有相關的技術問題，歡迎留言聯系我們。
