首先打开性能监视器工具 运行中输入 perfmon
sql server 现在通过 一组 动态管理视图(DMV) 和 动态管理函数(DMF) ,在内部提供相关数据.
sql server 的总体性能:
丢失索引
为了分析 丢失索引造成表扫描或者大的数据集检索的可能性, 使用如下计数器
对象 | 计数器 | ||
SQL SERVER:Access Methods |
|
1.FreeSpace Scans/sec
这个计数器表示 在 没有物理顺序的表上的插入操作数量---堆表.
2.Full Scans/sec
这个计数器监视 基本表或索引 上下受限制的完全扫描次数.高值的主要原因:
3.动态管理视图
检查丢失的索引 的另一个办法是 查询 动态管理视图
sys.dm_db_missing_index_details . 返回 可以根据数据上运行的查询计划 建议候选索引的信息.
sys.dm_db_index_usage_stats 返回索引的使用情况
select * from sys.dm_db_index_usage_stats where object_id= object_id('b') and index_id=1
可以看到 索引的最后浏览时间和表的更新时间, 这只是截取的部分列.
sys.dm_db_index_operational_stats 表值函数 查看正在使用的索引
数据库阻塞
对象 | 计数器 | ||
SQLServer:Latches | Total Latch Wait Time(ms) 总闩锁等待时间 | ||
SQLServer:Locks(_Total) |
|
1.Total Latch Wait Time(ms) 总闩锁等待时间
闩锁 被sql server 用于保护 内部结构 如表行的完整性,不由用户控制.
2.Lock timeouts/sec 和 lock wait time(ms)
Lock timeouts/sec 为0 和lock wait time(ms) 很小,是我们所期待的.如果反之,那么说明数据库阻塞过多.
可以使用 sql profiler 的信息 或者 查询 sys.dm_exec_query_stats 来识别 开销较大的查询,来优化它.
3.number of deadlocks/sec
期望值为了0. 应该定位并解决死锁.
不可重用的执行计划
因为 生成存储过程查询的 执行计划需要 cpu周期,所以可以通过重用执行计划来减少cpu的压力.分析重编译的存储过程数量通过:
对象 | 计数器 |
SQLServer:Sql Statistics | SQL Re-Compilations/sec 每秒 sql重编译数 |
总体表现
sql server还提供了 额外的性能计数器 来跟踪 sql server 系统的总体特征.
对象 | 计数器 |
SQL Server:General Statistics | User Connections (用户连接数) |
SQL Server:S QL Statistics | Batch Requests/sec 每秒批请求数 |
1. User Connections (用户连接数)
当sqlserver 分布在多台机器上,坚持 此计数器 以评估多个sqlserver 实例上用户连接分布 好一些.
2.Batch Requests/sec 每秒批请求数
这个计数器 是 sql server上的负载的 好指标,
创建一个基线:
首先打开 性能检测器
添加一个 SQL Server:Latched 的 Latch Wait/sec 计数器:
之后便可以查看总闩锁等待时间 的 数值;
之后可以导出到html文件: 监视器窗口 任意位置 右击,
打开生成的html,页面显示如图:
使用性能计数器 列表 创建一个 计数器日志
可以自己来创建 自动 跟踪任意计数器,并记录成日志 .当然可以使用计划任务,定期执行>
用户定义 右键, 新建 数据收集器集.
命名,选择手动创建! 点击下一步:
选中 性能计数器; 下一步.
添加相应的计数器. 点击下一步:
直到完成的那一步.
选择 打开 数据收集器集 的属性.
选择计划:
就可以 定期执行这个监视了.
最小化性能监视器的开销
最小化开销的办法: