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的错误日志的信息要时常看看。