azure sql database CPU troubleshooting
描述
最新我们一个稳定运行快一年的项目突然出现CPU方面的性能问题，该项目使用的azure sql database P2 500DTU,运维同事监控到CPU使用非常高，客户反馈系统运行也比较卡。看到CPU高我们的第一感觉一般就是数据库缺少索引、执行计划重编译过度。该项目稳定运行快一年了，按道理不会突然出现这种现象，可能与客户有业务变动有关，具体要与项目经理沟通了解才清楚。
数据库环境
Microsoft SQL Azure (RTM) - 12.0.2000.8
Mar 30 2017 01:30:03
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
处理过程
接到故障报警之后，我们马上查看了当前的sys.dm_db_resource_stats 查看到当前的CPU占比情况，发现当前的CPU占比并不高而且数据库链接也比较少，当前情况是很正常的，估计是我们错过事故现场。azure sql database 的性能调优跟我们平常使用的sql server 可能会有些不同，相对来说会有比较多的限制，我们通常情况是使用DMVs来处理比较多一些。像这种CPU情况我们先查看top 20 的sys.dm_exec_query_stats 的 total_worker_time 相同sql_handle 的情况，大概也能定位到问题点。这次CPU性能问题，我们更想体验一下query store 优势，看能否快速解决我们当前的情况，前提是我们已提前配置好了query_store，使用SSMSv17链接azure sql database 查看该库的属性。
如图
首先我们先查看前几个资源使用查询
我们一目了然就知道哪些语句是有问题，我们可以选择个人认为性能比较好的执行计划强制使用，这个选择可以快速让DBA做出决策；
我们当时遇到的问题是客户最近新增了一个数据对接接口，我们直接点中性能比较差的执行计划就可以看到具体的执行代码，恰好需更新的表上缺少索引造成本次事故，，新增缺少索引对比效果如下：
修改前的CPU情况
新增缺少索引后CPU情况
查看资源情况如下：
再通过我们的实施工程师的验证以及客户的反馈，本次故障已解决。
总结
1.提前管控好客户业务功能变动带来的影响；
2.提前部署好相关监控能为后续的快速问题处理提供指引；
