济南网站建设优化公司网络舆情监测系统
说明
SQL Server数据库近两天异常卡顿，严重影响程序使用。
评估过程
一、获取当前性能情况
使用SQL server运维工具箱获取巡检报告
人为补充运维工具箱没获取到的内容
二、分析
1、CPU使用率超高
该图可详见巡检报告，近7天以来CPU的使用率都超高，故去看巡检报告第六大项的第一项，TOP慢语句，如下图：
由上图可见，该系统中的慢语句还是比较多的，尤其上图中的红框显示，执行次数竟然达到5000多次，由于巡检报告展示原因，这里只显示SQL标识，现在查询消耗较大的程序语句（查询语句见附录），如下图：
这里为了我们这份报告的直观性，我这里将慢语句及其对应的SQL语句都查询出来了，可见，大于1s的语句竟然超过1万行，这明显降低了服务器的性能。
同时，我们观察篮框所示语句，可以清楚的看到基本都是同一个select语句，只是where条件不同罢了，故猜想，肯定是该查询表缺失了索引导致，现在查询该服务器缺失索引情况
上图显示为缺失索引影响较大的前10条，尤其是第一行显示的表，添加该索引会有显著性提高，所以，综合以上来看，导致CPU居高不下的原因是由于缺失索引的慢语句所致。
2、内存使用情况
上图所示，内存使用在正常范围内，但是根据该服务器的整体特性看，还可以做进一步优化
查询服务器总内存，服务器总内存为24G
查询分配给SQL server的使用内存，为16G
查询当前SQL server已经使用的内存
根据上图可见，服务器分配给SQL server16G,SQL server目前已经使用16G，虽然整体内存在合理范围内，但是不可避免的会使用一点交换空间，所以，建议分配给SQL server的内存是服务器内存的90%左右，大概20G.
3、数据库使用情况
查询上次（4月1日）巡检和今天（5月27）巡检概况
数据库大小
根据以上显示，近两个月数据库增长1G多一点
查询数据文件大小
4、文件系统资源
根据上图可知，D盘的剩余空间仅剩5G
再看数据库在磁盘上的分布
可见，重要数据库分布在D盘，这是很危险的，虽然数据文件增长较慢，但是可能会因为日志或者其他原因导致D盘空间撑爆，届时SQL server也会由于数据文件或日志文件无法写入而停止运行。
5、会话资源
根据上图所示，该服务器的整体会话连接很少，但是这么少的会话就有10个未提交，在结合上边第一条提到的有关缺失索引的语句，极有可能因为占用资源而导致死锁，建议养成一个良好的操作习惯，事务完成之后及时提交。
总结
建议：
1、 根据慢语句、索引缺失添加相关的索引，降低CPU使用率；
2、 增加SQL server的可利用内存，合理分配不浪费；
3、 清理SQL server的日志大小或者清理D盘的空间，防止D盘撑爆；
4、 空闲事务及时提交，避免死锁。
附录：
根据SQL标识查询对应的SQL语句，查询脚本为
SELECT SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset END
- qs.statement_start_offset)/2) + 1)
FROM
sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE
qs.sql_handle=sql_handle
--sql_handle 为上图中的sql标识
