SQL Server 监控系列 —— 二
监控前言
上一节我们提到了MSSQL的基于SQL Event的监控,但是有些时候我们需要更加详细、适用于调优排错的监控。SQL Server内部运行的可见性是的查询调整、优化和综合排查成为可能!这一节主要和大家说说SQL Server跟踪(SQL Server Profile)的一些监控方式和途径。
使用场景
记得某次给一家公司调优的时候,负责人发给我一堆业务的T-SQL脚本,我面对海量脚本还是从容,虽然不了解内部复杂的业务,但是我们得专注问题的关键 “慢”,我们根据查询的“慢”把他们筛选出来,一一调式优化,不就迅速解决问题吗?三天后,负责人含泪握着我的手,哥们辛苦了,查询响应得到了质的改善。
跟踪提供者
SQL Server 为我们两者提供跟踪的方式:一种是一个物理文件(可保存在本机或者UNC网络路径),一种是行集。对于后者大家应该比较熟悉
这个工具在 SSMS 的 工具 –> SQL Profile
详细的我暂时不介绍,先说说两者的区别和类同点 DIFFAndSame(行集,文件提供者)。
- 两者都是用类似Buffer来保存当前的事件数据,很明显是为了减少IO的压力,这样可以不阻塞和尽量不遗漏 事件数据,当Buffer 到达一定量时候可能才会Flush到磁盘或者发送到网络的终端(客户端)显示监控行集。
- 物理文件保存监控结果的方式的重要保证是不能遗漏任何事件,一旦IO降速的时候,可能会影响到整个T-SQL的执行情况。
wait_type | waiting_tasks_count | wait_time_ms | max_wait_time_ms | signal_wait_time_ms |
IO_COMPLETION | 66030898 | 24377499 | 3634 | 418960 |
SQLTRACE_LOCK | 12007 | 175943 | 1001 | 1281 |
相关文章