SQL Server 主庫DML操做慢故障處理過程

  從某個時間開始，Cat監控到的數據發現，正式環境的Insert 表很慢，數據庫用了AlwasON高可用(1個備庫作了實時同步），特別是天天早上9:00--11:00,作活動的時候，下單的insert須要1秒，有些有3秒的，並且是大量出現

不少簡單的insert也有。從8月份就一直就有問題，嚴重影響業務 ，當時還記錄了：  https://www.cnblogs.com/zping/p/9510485.html

本身還特地問了同行，有沒有遇到這樣的狀況，結果說是同步改爲異步。

 

  查看數據庫監控SQL：

 

大量HADR_SYNC_COMMIT這樣的等待事件， 網上找到的解決辦法：https://www.sqlshack.com/sql-server-wait-type-hadr-sync-commit/

    1，AlwasON環境下，從實時同步改爲異步

    2，提示網絡帶寬

    3，將大的事務改爲小事務

    4，減小索引和修改的數據量

    5，拆分數據庫

 這些解決辦法 1，第一改爲異步，業務部門不一樣意，由於有些業務是讀的這個庫，須要實時同步，

                       2，直接網絡帶寬，局域網的帶寬限制沒有用完

                       3，將大的事務改爲小事務，業務上沒有具體的操做性

                       4，減小索引，後來的確刪除了4個以爲不過重要的索引，可是還沒變化

                       5，拆分庫，就是把表拆到其餘庫裏

   這5個辦法，當前面4個辦法沒多大操做空間，最後只能拆分出表，讓程序去修改。根據監控，有4個表拆出來後，這4個表的寫入是好了，可是下單仍是慢。後來講只有把下單的表獨立出來就會好

也想找其餘緣由，也諮詢了其餘的同行，有沒有出現HADR_SYNC_COMMIT的解決辦法，結果他們沒出現這樣的問題。

  對應比較官方的建議，我一直沒有懷疑， 並且後來還懷疑是否： 1，Cat數據不許   2，網絡是否不穩定  3，接的數據庫insert方法有性能問題等待

  懷疑這個懷疑那個引發的性能問題。

  由於主庫一直有監控他的性能差的sql，一旦出現性能sql，就會立馬修改。主庫不會有什麼性能問題。對比了一下2017年8月份的監控數據，發現當時HADR_SYNC_COMMIT 的等待事件不多，

沒有如今這麼頻繁。

  是由於數據量增加的緣由？

     和去年的訂單表數據對比，數據量增加了50%左右，有個表達到了8千萬條數據，是數據量增加的緣由？

 若是是數據量增加的緣由，那爲什麼是在作活動的高峯纔出現問題。

 後來查詢備庫的錯誤日誌，大量發現下列錯誤：

  

 網上查：https://blogs.msdn.microsoft.com/joaol/2008/11/20/sql-server-checkpoint-problems/

  是 checkpoint problem問題，這裏的提交是0.18MB的速度， 這麼慢。是硬盤慢，用CrystalDiskMark 6.0 工具測試了一下硬盤性能，沒有特別的問題，也讓人看了服務器的硬盤，都沒有問題

  這個文章也介紹：  https://www.sqlservercentral.com/Forums/Topic1363610-2799-1.aspx

    To resolve this issue, you have several options:
     1. dirty fewer pages (drop extra indexes, use compression, tune queries, etc). Fewer dirty pages means less work each checkpoint.
     2. reduce IO load overall (Add memory to reduce reads/sec, move busy tempdb to different drive, tune queries, etc)
    3. increase IO write capacity (extra spindles in SAN, add SSD's, switch from Raid-5 to Raid-10, etc)
    4. smooth out checkpoint's IO load (set a really high recovery interval and perform manual checkpoints. Don't go here until you've got a really good handle on the perfmon counters above and can prove that this helps.)

上面的解決辦法：  就是減小IO，提示硬盤的IO能力，換成SSD的。 但根據實用的沒有。由於也不可能備庫換服務器。

    沒辦法查了一下備庫的監控的SQL：

    

   大量的： IO_COMPLETION，PAGEIOLATCH_SH，PAGEIOLATCH_EX，其中PAGEIOLATCH_SH的事件出現最多，

    PAGEIOLATCH_SH： 常常發生在用戶正想要去訪問一個數據頁面，而同時SQL Server卻要把這個頁面從磁盤讀往內存。

    PAGEIOLATCH_EX：常常發生在用戶對數據頁面作了修改。SQL Server要向磁盤迴寫的時候，意味着寫的速度跟不上。

    IO_COMPLETION： 這種等待類型表示數據文件中的各類同步讀和寫操做，這些操做與表無關，而且從事務日誌中讀取。

    pageiolatch是爲了數據的異步訪問。好比說咱們想讀取一個page，可是它不內存中，那麼sql server會首先在內存中爲這個page空出一塊空間，而且加上ex_latch，而後在這個page真正從disk讀取到內存當中以前，其餘線程不能對這片內存進行操做。由於異步操做，因此這個線程會去訪問這個page，此時申請sh_latch，可是與以前的ex_latch，最終致使本身被本身阻塞了。這就是pageiolatch_sh。

   這一切說明，備庫的IO性能有問題。

   是什麼致使備庫的IO性能異常？

      特地查了備庫的查詢的SQL，有大量的查詢慢的SQL，很耗CPU的：

    

    這些SQL有些查詢特別大的表，很耗CPU，直覺告訴我，這些sql有問題，後來發現這些sql也是從8點左右開始查詢，是爲了監控業務數據的，諮詢了一下，能夠停掉，還有一些有性能的sql優化了一下，有些查詢若是

不讀這個實時備庫，就遷移到異步讀庫。修改了一圈後，有問題的SQL少了不少。 今天早上9；00開始的活動搶購，insert慢的問題沒有出現，本身都以爲難以想象，困擾咱們近1年的DML操做慢的問題解決了。

 

 總結：

    1，太教條，就依據等待事件的解決辦法。

    2，只關注主庫的性能差SQL，未監控實時備庫的性能差的SQL，實時備庫有時會拖主庫的後腿

    3，SQL Server的錯誤日誌的信息要時常看看。