那是那个connection的累积reads，可能是因为connection没有释放。

要追查执行成本，不是这样看的。

想不想时已是想，不如不想都不想。

lundi 20 février 2012 04:33

Modérateur

那是那个connection的累积reads，可能是因为connection没有释放。

要追查执行成本，不是这样看的。

想不想时已是想，不如不想都不想。

能不能再具体的说明一下？

lundi 20 février 2012 04:59

估计是Top 1 后有Order By，而没对应的索引导致

Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

lundi 20 février 2012 06:31

How many disks for database on the server? May need spread db files to multiple disks to reduce io contention.

lundi 20 février 2012 19:55

How many disks for database on the server? May need spread db files to multiple disks to reduce io contention.

有6个，但是主数据库与日志数据库是分开的，这个应该不是主要原因！还有一个问题就是，在服务器上面的Audit Logout出现的次数太频繁，在本地测试时没有出现这种情况！！！

mardi 21 février 2012 04:04

估计是Top 1 后有Order By，而没对应的索引导致

Try SQL Server 2008 QQ:315054403 dgdba@hotmail.com

top 1后面都不会有排序的！！！

mardi 21 février 2012 04:04

How many disks for database on the server? May need spread db files to multiple disks to reduce io contention.

有6个，但是主数据库与日志数据库是分开的，这个应该不是主要原因！还有一个问题就是，在服务器上面的Audit Logout出现的次数太频繁，在本地测试时没有出现这种情况！！！

Does app use connection pooling?

mardi 21 février 2012 04:19

那是那个connection的累积reads，可能是因为connection没有释放。

要追查执行成本，不是这样看的。

想不想时已是想，不如不想都不想。

能不能再具体的说明一下？

请google connection pool

想不想时已是想，不如不想都不想。

mardi 21 février 2012 05:41

Modérateur

How many disks for database on the server? May need spread db files to multiple disks to reduce io contention.

有6个，但是主数据库与日志数据库是分开的，这个应该不是主要原因！还有一个问题就是，在服务器上面的Audit Logout出现的次数太频繁，在本地测试时没有出现这种情况！！！

Does app use connection pooling?

Can

you speak Chinese?

My English is so-so！ Thanks

mardi 21 février 2012 06:00

How many disks for database on the server? May need spread db files to multiple disks to reduce io contention.

有6个，但是主数据库与日志数据库是分开的，这个应该不是主要原因！还有一个问题就是，在服务器上面的Audit Logout出现的次数太频繁，在本地测试时没有出现这种情况！！！

Does app use connection pooling?

？？？这个没有看懂！！！。。。connection的累积会造成Reads读取磁盘的次数增多吗？？？

mardi 21 février 2012 06:16

How many disks for database on the server? May need spread db files to multiple disks to reduce io contention.

有6个，但是主数据库与日志数据库是分开的，这个应该不是主要原因！还有一个问题就是，在服务器上面的Audit Logout出现的次数太频繁，在本地测试时没有出现这种情况！！！

Does app use connection pooling?

？？？这个没有看懂！！！。。。connection的累积会造成Reads读取磁盘的次数增多吗？？？

那是累计的reads，不是一次那么多。

想不想时已是想，不如不想都不想。

mardi 21 février 2012 10:29

Modérateur

这个值应该表明是该连接的一个累积值，这个值是一个逻辑读，不是物理读，该值不能表明IO一定有瓶颈。

如果采用profiler来收集数据并排查性能，一般看Duration。

如果采用point方式，需要看下当前正在运行的sql的等待类型。

Best Regards, nicofer

Modifié

nicofer

mercredi 22 février 2012 02:19

mercredi 22 février 2012 02:13

这个值应该表明是该连接的一个累积值，这个值是一个逻辑读，不是物理读，该值不能表明IO一定有瓶颈。

如果采用profiler来收集数据并排查性能，一般看Duration。

如果采用point方式，需要看下当前正在运行的sql的等待类型。

Best Regards, nicofer

Reads是很重要的，不过关键是要看RPC:Comleted事件，如果有存储过程，还要看SQL:BatchCompleted 事件。

想不想时已是想，不如不想都不想。

mercredi 22 février 2012 03:57

Modérateur

这个值应该表明是该连接的一个累积值，这个值是一个逻辑读，不是物理读，该值不能表明IO一定有瓶颈。

如果采用profiler来收集数据并排查性能，一般看Duration。

如果采用point方式，需要看下当前正在运行的sql的等待类型。

Best Regards, nicofer

Reads是很重要的，不过关键是要看RPC:Comleted事件，如果有存储过程，还要看SQL:BatchCompleted 事件。

想不想时已是想，不如不想都不想。

是的，Reads也重要，但是个人更强调Duration,而且这个Reads即不是page也不是KB，只是一个计数器值，这个值大也的确表逻辑读高，但它不一定存在物理读，速度也并不一定慢。Duration是一个Tsql开始执行到结束的时间，假如在Tsql执行过程中有遇到blocking，这个值也会一并增大，但Reads无法体现这一点，使用Duration更实用一些。当然，我们在日常调优中通常是这两个都会做筛选。

Best Regards, nicofer

Modifié

nicofer

mercredi 22 février 2012 05:36

mercredi 22 février 2012 05:31

这个值应该表明是该连接的一个累积值，这个值是一个逻辑读，不是物理读，该值不能表明IO一定有瓶颈。

如果采用profiler来收集数据并排查性能，一般看Duration。

如果采用point方式，需要看下当前正在运行的sql的等待类型。

Best Regards, nicofer

Reads是很重要的，不过关键是要看RPC:Comleted事件，如果有存储过程，还要看SQL:BatchCompleted 事件。

想不想时已是想，不如不想都不想。

是的，Reads也重要，但是个人更强调Duration,而且这个Reads即不是page也不是KB，只是一个计数器值，这个值大也的确表逻辑读高，但它不一定存在物理读，速度也并不一定慢。Duration是一个Tsql开始执行到结束的时间，假如在Tsql执行过程中有遇到blocking，这个值也会一并增大，但Reads无法体现这一点，使用Duration更实用一些。当然，我们在日常调优中通常是这两个都会做筛选。

Best Regards, nicofer

这个Reads就是page，*8就是KB。

BTW，在SQL Server 2008及以后，Profiler已经没有什么用处了。

想不想时已是想，不如不想都不想。

mercredi 22 février 2012 06:00

Modérateur

这个值应该表明是该连接的一个累积值，这个值是一个逻辑读，不是物理读，该值不能表明IO一定有瓶颈。

如果采用profiler来收集数据并排查性能，一般看Duration。

如果采用point方式，需要看下当前正在运行的sql的等待类型。

Best Regards, nicofer

Reads是很重要的，不过关键是要看RPC:Comleted事件，如果有存储过程，还要看SQL:BatchCompleted 事件。

想不想时已是想，不如不想都不想。

是的，Reads也重要，但是个人更强调Duration,而且这个Reads即不是page也不是KB，只是一个计数器值，这个值大也的确表逻辑读高，但它不一定存在物理读，速度也并不一定慢。Duration是一个Tsql开始执行到结束的时间，假如在Tsql执行过程中有遇到blocking，这个值也会一并增大，但Reads无法体现这一点，使用Duration更实用一些。当然，我们在日常调优中通常是这两个都会做筛选。

Best Regards, nicofer

这个Reads就是page，*8就是KB。

BTW，在SQL Server 2008及以后，Profiler已经没有什么用处了。

想不想时已是想，不如不想都不想。

no,Reads不是page，SQL Server内部在读和写的时候，会运行到某一特定的代码，每调用一次这个代码，Reads/Writes就会加1.

针对于调优，对于一段时间，还是用profiler(Server side trace)，对于一个点，当然DMV更有优势。

针对于非调优，Profiler功能依然很强大，举个例子，比如死锁分析，Porfiler能够看到申请与翻放的详细情况，这个DMV也搞不定。

Best Regards, nicofer

mercredi 22 février 2012 06:50

在服务器(windows2003 iis6.0)上用计算机性能监视查看Avg Disc Queue Length那条线一直处在最顶端，找到原因是由于数据库I/O造成的。。。通过Sql server Profiler查看时Reads那一列数据都很大，只读取一条数据TOP 1时，Reads那一列的数据还是那么多，但是在本地查看都只有四位数的？？？有谁知道是什么原因引起的？？？

1. 操作的表数据量多少

2. 贴你的执行计划

3. 最好贴一下你的SQL

4. 贴性能计数器显示每个分区上面的平均磁盘队列

看扯了半天理论都晕了，还不知道情况... ...

mercredi 22 février 2012 07:02

在服务器(windows2003 iis6.0)上用计算机性能监视查看Avg Disc Queue Length那条线一直处在最顶端，找到原因是由于数据库I/O造成的。。。通过Sql server Profiler查看时Reads那一列数据都很大，只读取一条数据TOP 1时，Reads那一列的数据还是那么多，但是在本地查看都只有四位数的？？？有谁知道是什么原因引起的？？？

1. 操作的表数据量多少

2. 贴你的执行计划

3. 最好贴一下你的SQL

4. 贴性能计数器显示每个分区上面的平均磁盘队列

看扯了半天理论都晕了，还不知道情况... ...

1，目前数据量在20W左右，不是很大，但访问量很高很频繁！

2，......

3，SQL语句很简单，普通的联表查询(inner join)，条件也不多，所联的两个表的数据都在20W左右

4，性能计数器上查看，Avg Disc Queue Length那条线一直处在最顶端！！！(主要是这个问题了，就是数据库I/O造成的，也就是数据库中的物理读取磁盘次数太多，是什么造成数据库物理读取磁盘次数太多就是不知道了！！！是硬件的问题还是SQL语句或者程序的问题？？？现在还在找。。。！！！)

贴一下服务器上的性能计数器：

mercredi 22 février 2012 08:49

no,Reads不是page，SQL Server内部在读和写的时候，会运行到某一特定的代码，每调用一次这个代码，Reads/Writes就会加1.

针对于调优，对于一段时间，还是用profiler(Server side trace)，对于一个点，当然DMV更有优势。

针对于非调优，Profiler功能依然很强大，举个例子，比如死锁分析，Porfiler能够看到申请与翻放的详细情况，这个DMV也搞不定。

Best Regards, nicofer

你可以说，按照严格的定义，Reads不是Page。但是，Reads=page。

A logical read occurs every time the Database Engine requests a page from the buffer cache.

关于第二个问题，显然你不知道SQL 2008有个新功能叫做Extend Event。

想不想时已是想，不如不想都不想。

mercredi 22 février 2012 08:57

Modérateur

no,Reads不是page，SQL Server内部在读和写的时候，会运行到某一特定的代码，每调用一次这个代码，Reads/Writes就会加1.

针对于调优，对于一段时间，还是用profiler(Server side trace)，对于一个点，当然DMV更有优势。

针对于非调优，Profiler功能依然很强大，举个例子，比如死锁分析，Porfiler能够看到申请与翻放的详细情况，这个DMV也搞不定。

Best Regards, nicofer

你可以说，按照严格的定义，Reads不是Page。但是，Reads=page。

A logical read occurs every time the Database Engine requests a page from the buffer cache.

关于第二个问题，显然你不知道SQL 2008有个新功能叫做Extend Event。

想不想时已是想，不如不想都不想。

1.以前曾经有网友提到过，同样的tsql，为什么在查询分析器执行时，用set statistics io on看到的逻辑读和在profiler看到的reads值不一样，当时我也很疑惑，后来知道这个reads是通过一种计算而得到的结果，并非真正的page.

2.Extend Event以前看过一点，没深入研究过，比如对于一个简单的update事句，我想知道申请与释放锁的每一步，我知道用profiler可以，但用Extend Event如何得到？类似于http://www.cnblogs.com/nzperfect/archive/2011/09/26/2192006.html

Best Regards, nicofer

Modifié

nicofer

mercredi 22 février 2012 09:35

mercredi 22 février 2012 09:26

你可以看看BOL里面介绍Extend Event的内容，不过内容有点不够详细，注意那些系统表的内容。简单的说，这个的事件比Profiler只多不少。

想不想时已是想，不如不想都不想。

mercredi 22 février 2012 09:34

Modérateur

1.以前曾经有网友提到过，同样的tsql，为什么在查询分析器执行时，用set statistics io on看到的逻辑读和在profiler看到的reads值不一样，当时我也很疑惑，后来知道这个reads是通过一种计算而得到的结果，并非真正的page.

看这篇文章，http://support.microsoft.com/kb/314648/en-us，解释了为啥看到的reads值不一样。reads=page，是微软文档说得很清楚的事实，没必要质疑这个。

想不想时已是想，不如不想都不想。

mercredi 22 février 2012 11:02

Modérateur

在服务器(windows2003 iis6.0)上用计算机性能监视查看Avg Disc Queue Length那条线一直处在最顶端，找到原因是由于数据库I/O造成的。。。通过Sql server Profiler查看时Reads那一列数据都很大，只读取一条数据TOP 1时，Reads那一列的数据还是那么多，但是在本地查看都只有四位数的？？？有谁知道是什么原因引起的？？？

1. 操作的表数据量多少

2. 贴你的执行计划

3. 最好贴一下你的SQL

4. 贴性能计数器显示每个分区上面的平均磁盘队列

看扯了半天理论都晕了，还不知道情况... ...

1，目前数据量在20W左右，不是很大，但访问量很高很频繁！

2，......

3，SQL语句很简单，普通的联表查询(inner join)，条件也不多，所联的两个表的数据都在20W左右

4，性能计数器上查看，Avg Disc Queue Length那条线一直处在最顶端！！！(主要是这个问题了，就是数据库I/O造成的，也就是数据库中的物理读取磁盘次数太多，是什么造成数据库物理读取磁盘次数太多就是不知道了！！！是硬件的问题还是SQL语句或者程序的问题？？？现在还在找。。。！！！)

贴一下服务器上的性能计数器：

It's total disk queue length on the server. You should check each disk to find out which one has most i/o, paging can cause huge disk i/o too.

mercredi 22 février 2012 14:22

在服务器(windows2003 iis6.0)上用计算机性能监视查看Avg Disc Queue Length那条线一直处在最顶端，找到原因是由于数据库I/O造成的。。。通过Sql server Profiler查看时Reads那一列数据都很大，只读取一条数据TOP 1时，Reads那一列的数据还是那么多，但是在本地查看都只有四位数的？？？有谁知道是什么原因引起的？？？

1. 操作的表数据量多少

2. 贴你的执行计划

3. 最好贴一下你的SQL

4. 贴性能计数器显示每个分区上面的平均磁盘队列

看扯了半天理论都晕了，还不知道情况... ...

1，目前数据量在20W左右，不是很大，但访问量很高很频繁！

2，......

3，SQL语句很简单，普通的联表查询(inner join)，条件也不多，所联的两个表的数据都在20W左右

4，性能计数器上查看，Avg Disc Queue Length那条线一直处在最顶端！！！(主要是这个问题了，就是数据库I/O造成的，也就是数据库中的物理读取磁盘次数太多，是什么造成数据库物理读取磁盘次数太多就是不知道了！！！是硬件的问题还是SQL语句或者程序的问题？？？现在还在找。。。！！！)

贴一下服务器上的性能计数器：

It's total disk queue length on the server. You should check each disk to find out which one has most i/o, paging can cause huge disk i/o too.

分页会造成巨大的磁盘I/O？？？但是数据量只有20W！！！。。。还是贴一下分页代码吧？？？

jeudi 23 février 2012 02:26

Paging means writing data from memory to pagefile here, so you are better to get queue length of each disk.

jeudi 23 février 2012 03:43

这个分页代码是比较差。不过楼上说的paging的意思是虚拟内存和磁盘之间的页交换。

想不想时已是想，不如不想都不想。

jeudi 23 février 2012 03:43

Modérateur

这个分页代码是比较差。不过楼上说的paging的意思是虚拟内存和磁盘之间的页交换。

想不想时已是想，不如不想都不想。

差在哪里，说下你的看法？？？

jeudi 23 février 2012 06:14

你的问题需要排查一下队列是读还写多，还要看下内存分配情况，你内存有多大，SQL分配了多少，是32or64bit ?

再加几个计数器，运行十分钟，贴下结果：

Best Regards, nicofer

Modifié

nicofer

vendredi 24 février 2012 01:02

vendredi 24 février 2012 00:59