SQL Server磁盘I/O性能分析

SQL Server中的I/O操作类型:

1.对于内存中没有缓存的数据,第一次访问时需要将数据从所在的页面从数据文件中读取到内存中

2.在任何Insert/Update/Delete提交前,SQL Server需要保证日志记录能够写入到日志文件中

3.当SQL Server做Checkpoint时,需要将内存缓冲区中已经发生修改的数据页面同步到硬盘的数据文件中,一般一分钟一次Checkpoint。如果修改较多,频率高一些,写的数量 和上次checkpoint依赖发生的数据修改量有直接关系

4.当SQL Server Buffer Pool发生压力时,会触发Lazy Writer,主动将内存里的一些很久没有使用过的数据页面和执行计划清空。如果这些页面上发生的修改还未由checkpoint写回硬盘,Lazy Writer会将其写回

5.一些特殊操作,例如DBCC Checkdb、Reindex、Updata Statistics、Backup等,会带来较大的硬盘读写。这些操作应该给都发生在一些固定的时间段

数据库级别的I/O影响: 1.Recovery Interval(sp_configure)控制着SQL Server多久进行一次checkpoint

checkpoint pages/sec(Buffer Manager)呈周期性上升

MSSQL:SQL Statistics-Batch Requests/sec:每秒钟完成的批处理(batch)数目

MSSQL:Databases-Active Transactions:SQL Server里打开的,还没有提交的事物数目

2.数据/日志文件的自动增长和收缩

3.数据文件里面碎片程度:页面碎片越多,SQL Server就需要读取和写入更多的页面,增加硬盘读写量

4.表格上的索引结构

5.数据文件和日志文件分开放在不同的磁盘上。如果可能的话,日志文件要放在写入速度较快的磁盘上

6.一个数据文件组是否有多个文件,并且放在不同的磁盘上。但是对于日志文件,在一个时间点,SQL Server只会写一个日志文件,所以在不同磁盘上创建多个日志文件对性能没有任何提高

系统级别的I/O影响: %Disk Time:只观察其曲线趋势,值本身没有参考价值

%idle Time:磁盘处于空闲状态百分比。当磁盘处于空闲状态时,值为100%。当磁盘满负荷操作时,值为0,所以可以根据该值反推%Disk Time

Disk Bytes/sec:每秒钟磁盘读和写总量(磁盘的吞吐量)。需要先确认该磁盘的最大读写速度才有参考价值,可以看出是否已经达到了该磁盘的读写上限

Avg.disk sec/transfer:磁盘每一次读或写的动作所花的平均时间

Avg.Disk Queue Length:发出的磁盘操作正在等待被磁盘处理的请求数目。理论上讲,这个值不应该长时间大于2

Current Disk Queue Length:当前正在等待被磁盘处理的请求数目

当Avg.Disk Queue Length高时,需要分别观察Disk Bytes/sec和Avg.disk sec/transfer哪个计数器已经达到了其最大值

SQL Server中的性能计数器

Buffer Manager:

Page Reads/sec和Page Writes/sec:每秒钟读写了多少页面。了解到由于Buffer Pool的行为带来了多少磁盘读写

Lazy Writes/sec:Lazy Writer为了清空Buffer Pool每秒钟做了多少页面写入操作

Checkpoint Writes/sec:每秒钟从Buffer Pool里写入到磁盘上的Dirty Page数目

Freespace Scans/sec:在堆(heap)结构里找能够使用的空间。对于没有聚集索引的表格,SQL Server会以堆的形式存储。如果该值很高,应该多建立一些聚集索引

Full Scans/sec:每秒钟SQL Server做全表扫描数目,该值越小越好

Databases(Log Activity):

Log Flush Wait Time:写入日志的动作曾经因为磁盘来不及响应而遇到的等待时间,会导致前端的事务不能提交,会严重影响SQL Server性能。该值应该在绝大多数时间都为0

Log Flush Waits/sec:在每秒提交的事务里,有多少个事务曾经等待过日志写入完成。理想情况下,日志写入应该立刻完成,不需要等待。

时间: 2024-08-01 10:41:23

SQL Server磁盘I/O性能分析的相关文章

分析下自己写的SQL Server同步工具的性能和缺陷

分析下自己写的SQL Server同步工具的性能和缺陷 1. C#同步SQL Server数据库Schema 2. C#同步SQL Server数据库中的数据--数据库同步工具[同步新数据] 通过测试我写的同步程序,得出结论: 1.程序第一次调用SQLBulkCopy会耗时较长 2.同步程序放在目标机器在耗时方面相对少些 测试数据: declare @varI varchar(200) set @varI=0 while(@varI<100000) begin set @[email prote

SQL Server 磁盘请求超时的833错误原因分析以及解决

本文出处:http://www.cnblogs.com/wy123/p/6984885.html 最近遇到一个SQL Server服务器响应极度缓慢,并且出现客户端请求报错的情况,在数据库中的errorlog中出现磁盘请求超过一定时间才完成的error消息.对于此类问题,到底是存储系统或者磁盘的故障,还是SQL Server 自己的问题,亦或是应用程序引发的呢?又要如何解决?本文将对引起此问题的某一方面的因素进行简单的分析,但是无法涵盖所有潜在的可能性,因此遇到类似问题还要做具体的分析. SQL

SQL SERVER - 谈死锁的监控分析解决思路

1 背景 1.1 报警情况 最近整理笔记,打算全部迁移到EVERNOTE.整理到锁这一部分,里边刚好有个自己记录下来的案例,重新整理分享下给大家. 某日中午,收到报警短信,DB死锁异常,单分钟死锁120个. 死锁的xml文件如下: 1 <deadlock-list> 2 <deadlock victim="process810b00cf8"> 3 <process-list> 4 <process id="process810b00c

为什么SQL语句Where 1=1 and在SQL Server中不影响性能

    最近一个朋友和我探讨关于Where 1=1 and这种形式的语句会不会影响性能.最后结论是不影响.     虽然结论正确,但对问题的认识却远远没有解决问题的根本.实际上在T-SQL语句的书写过程中经常犯得错误就是得出一个很窄的结论,然后教条式的奉若圣经,对于T-SQL领域来说,在网上经常可以看到所谓的优化守则,随便在网上搜了一些摘录如下: 不要有超过5个以上的表连接(JOIN) 考虑使用临时表或表变量存放中间结果 少用子查询 视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 对出现在wh

sql server 使用nolock提升性能

博客园有许多关于nolock的文章,大部分都写得很好,例如:http://www.cnblogs.com/huangxincheng/p/4292320.html 这里仅结合个人项目,作为个人笔记记录. nolock 的使用方法如: select * from table1 with(nolock) with 后面加“锁定提示”,具体的锁定提示有许多种,有表级别,页级别,行级别等等.具体可以参照上面的链接. nolock 是锁定级别是:不采用任何锁.在允许脏读的情况下,使用nolock可以提升查

SQL Server 2014里的性能提升

在这篇文章里我想小结下SQL Server 2014引入各种惊艳性能提升!! 缓存池扩展(Buffer Pool Extensions) 缓存池扩展的想法非常简单:把页文件存储在非常快的存储上,例如SSD硬盘,用来扩展缓存池.缓存池扩展来得非常方便,如果你不能给你的数据库服务器物理上增加更多的内存,可以考虑使用缓存池扩展. 资源调控器(Resource Governor) 资源调控器首次是在SQL Server 2008里引入的,但那个时候还不是个成熟的技术,因为你不能在存储级别调控I/O操作,

SQL Server 磁盘空间告急(磁盘扩容)转载

一.背景 在线上系统中,如果我们发现存放数据库文件的磁盘空间不够,我们应该怎么办呢?新买一个硬盘挂载上去可以嘛?(linux下可以直接挂载硬盘进行扩容),但是我们的SQL Server是运行在Windows下的,有什么办法可以解决这燃眉之急呢? 有两种方法可以解决上面的问题:第一种就是把数据库磁盘转换为[动态磁盘],新增新的磁盘就可以解决了:第二种就是我今天要讲述的,使用SQL Server在其它磁盘(或者逻辑分区)中添加新的文件,添加完成后,SQL Server马上就能进新的数据了. 上面两种

【SQL server初级】数据库性能优化三:程序操作优化

数据库优化包含以下三部分,数据库自身的优化,数据库表优化,程序操作优化.此文为第三部分 数据库性能优化三:程序操作优化 概述:程序访问优化也可以认为是访问SQL语句的优化,一个好的SQL语句是可以减少非常多的程序性能的,下面列出常用错误习惯,并且提出相应的解决方案 一.操作符优化 1. IN.NOT IN 操作符 IN和EXISTS 性能有外表和内表区分的,但是在大数据量的表中推荐用EXISTS 代替IN . Not IN 不走索引的是绝对不能用的,可以用NOT EXISTS 代替 2. IS 

SQL SERVER中一些常见性能问题的总结

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免使用 left join 和 null 值判断.left join 比 inner join 消耗更多的资源,因为它们包含与 null (不存在)数据匹配的数据,所以如果可以重新编写查询以使得该查询不使用任何 inner join ,则会得到相应的回报.例如有两表:product(product_id int not null,product_type_id int nul