目录

机器指标

机器处理时间(Machine Processor TIme)

解释

指导值

另请检查

可能的解决方案

平均Cpu队列长度(Avg.Cpu Queue Length)

等效性能计数器

解释

指导值

可能的解决方案

内存(Memory)  页数/秒(Pages/s)

解释

指导值

网络利用率

性能计数器

说明

指导值

磁盘已用字节数

说明

指导值

磁盘平均读取时间

解释

指导值

可能的解决方案

磁盘平局写入时间

解释

指南值

可能的解决方案

磁盘传输/秒

说明

指导值

可能的解决方案

平均磁盘队列长度

说明

指南值

SQL Server 指标

用户连接数

说明

指导值

SQL Server:处理器时间(SQL Server: processor time)

说明

标准值

SQL Server:总内存

说明

参考值

检查其他

可能的解决方案

SQL Server:目标内存

说明

参考值

检查其他:

可能的解决方案

SQL Server:可用内存

说明

准则值

SQL Server:动态 SQL 缓存内存

指导值

SQL Server:连接内存

说明

指导值

SQL Server:锁定内存

说明

指导值

检查其他

SQL Server:缓冲缓存

说明

指导值

检查其他

SQL Server:日志池内存

说明

检查其他

批处理请求/秒

编译/秒

编译/批处理

重新编译/秒

缓存区页预期寿命

页面读取/秒

全扫描/秒

页拆分/秒

页拆分/批处理请求

闩锁等待时间

锁超时/秒

锁等待/秒

平均锁定等待时间

Data Base 指标

事务/秒

活动事务

总文件大小

总数据文件大小(MDF)

使用的数据文件总数


机器指标

机器处理时间(Machine Processor TIme)

解释

这是所有处理器繁忙程度的一个一般指标。每个数据点表示自前一个数据点以来所有处理器内核的平均非空闲时间。计算每个处理器的平均利用率,然后除以机器上的处理器数量。

指导值

理想情况下,机器:平均处理器时间应该小于50%,以获得最佳SQL Server性能。如果机器:处理器时间在一段持续时间内(五分钟或更长)超过平均80%,那么在此期间存在CPU瓶颈,您应该调查其原因。请记住机器上的短峰值:处理器时间超过80%是正常和预期的,只有持续的高CPU利用率才是问题。如果峰值表示平台期,而不是一个尖锐的峰值,这可能表明运行缓慢的查询导致了CPU问题。

注意:当在虚拟环境中运行时,机器:处理器时间是无关紧要的,因为它无法准确地测量虚拟机内的CPU活动。相反,请使用Hyper-V逻辑处理器性能计数器。

另请检查

  1. SQL Server处理器时间:在大多数专用的SQL Server机器中,Machine: processor时间和SQL Server: processor时间高度相关。如果机器:处理器时间比SQL Server:处理器时间高得多,那么除了SQL Server之外的某些进程造成了高CPU利用率,应该对该进程进行调查。
  1. 平均CPU队列长度:测量处理器队列中线程的数量。即使在多核计算机上,处理器时间也只有一个队列。如果计算机有多个处理器内核,每个处理器少于10个线程的持续处理器队列通常是可以接受的,这取决于工作负载。每个处理器超过10个线程的数字表示潜在的CPU瓶颈。

可能的解决方案

假设机器:处理器时间是由SQL Server进程造成的,可以通过许多不同的方法来降低CPU利用率,包括重写编写不良的查询,减少查询计划的重新编译,优化查询并行性,以及避免使用客户端游标。如果纠正上述错误不能解决CPU瓶颈,请考虑升级到更快的处理器或增加处理器的数量。

如果机器:处理器时间高,和SQL Server:处理器时间不高度相关,那么识别导致CPU活动过多的非SQL Server进程并纠正它。

平均Cpu队列长度(Avg.Cpu Queue Length)

测量处理器队列中等待执行的线程数。队列包含了准备运行的线程,但由于所有处理器内核都处于繁忙状态,因此无法运行。

等效性能计数器

操作系统:处理器队列长度(除以处理器核心数)

解释

即使在多核计算机上,也只有一个进程队列。因此,如果计算机有多个处理器内核,自动将处理器队列长度除以为工作负载提供服务的处理器内核的数量,以确定平均处理器队列长度。

指导值

数字越低越好,但是平均处理器队列长度小于10通常是可以接受的,具体取决于工作负载。每个处理器超过10个线程的数字表示CPU瓶颈。处理器平均队列长度偶尔超过10是正常的,但只有处理器平均队列长度持续出现尖峰才是问题。如果平均进程队列长度经常大于10,并且机器:处理器时间经常超过80%,那么您的机器就有CPU瓶颈。

可能的解决方案

如果确认存在CPU瓶颈,可以通过许多不同的方法来降低CPU利用率,包括重写写得不好的查询,减少查询计划的重新编译,优化查询并行性,以及避免使用客户端游标。如果纠正上述错误不能解决CPU瓶颈,请考虑升级到更快的处理器或增加处理器的数量。如果机器:处理器时间高,和SQL Server:处理器时间不高度相关,那么识别导致CPU活动过多的非SQL Server进程并纠正它。

内存(Memory)  页数/秒(Pages/s)

显示服务器上使用的物理内存数量(以字节为单位)。

解释

这是当前所有进程使用的内存字节总数。如果服务器上的应用运行缓慢,数据访问也缓慢,您可能需要检查此指标的值。

指导值

高值可能表明计算机内存不足,或表明计算机或应用程序没有释放内存。最佳值取决于机器有多少物理内存。例如,在一台6 GB的机器上,您可以为操作系统提供2 GB内存,并将剩余的RAM分配给SQL Server。

网络利用率

总带宽使用的百分比,以帮助确定您的网络适配器是否处于饱和点。

性能计数器

8 *((网络接口:接收字节数/秒)+(网络接口:发送字节数/秒))/(网络接口:当前带宽)*100

说明

表示网卡所连接的总带宽使用量。它有助于确定网络何时空闲、正常或繁忙。注意:这并不测量发送到服务器和从服务器发送的带宽数量。该值是通过将网络适配器每秒发送和接收字节的速率相加,然后将它们转换为比特计算出来的。然后将该值与网络适配器上的当前带宽进行比较,以计算网络利用率。

指导值

当主机上只有一个SQL Server实例且没有其他网络流量时,此值最有用。理想的百分比值取决于使用的网络连接类型,因此应该设置一个基准来衡量效率。平均而言,超过50%的网络利用率很高,超过80%的网络利用率非常高。为了获得最佳性能,您应该有一个网络连接到以全双工运行的专用交换机端口。

磁盘已用字节数

每个磁盘使用的空间大小(以GB为单位)。

说明

此信息允许您监视正在使用的存储空间以及每个磁盘上的可用空间。重要的是评估系统磁盘空间的充分性,以避免程序因为系统无法分配空间而失败,并防止为支持虚拟内存而限制页面归档的增长。

指导值

为保证系统盘的容量,您需要的磁盘容量计算如下:

  1. 为操作系统预留1 GB空间。
  2. 添加所有应用程序的大小。
  3. 为分页文件添加至少两倍的系统内存大小。
  4. 将每个用户的磁盘空间估计乘以用户数量。
  5. 至少乘以130%来考虑扩张的空间。

一般来说,如果使用的磁盘空间达到容量的80%或以上,您可以考虑运行磁盘清理工具,压缩或整理磁盘,将某些文件传输到其他磁盘或使用远程存储。

磁盘平均读取时间

解释

测量从逻辑磁盘读取数据时的延迟时间(磁盘响应的速度)。延迟越低,I/O性能越快,反之亦然。这个指标和磁盘平均写入时间指标是两个最重要的I/O瓶颈指标。

指导值

对于具有MDF和NDF文件和OLTP负载的驱动器,理想情况下平均读取延迟应该低于20 ms。对于带有OLAP负载的驱动器,延迟达到30 ms被认为是可接受的。对于具有LDF文件的驱动器,延迟理想情况下应该是5毫秒或更少。一般来说,超过50毫秒就是慢了,意味着可能存在严重的I/O瓶颈。写延迟会随着时间的推移而变化,因此这些指标忽略了偶尔出现的峰值。

检查磁盘平均写入时间。这些值应符合上述准则。

可能的解决方案

优化查询以减少执行它们所使用的资源,使用更快的磁盘驱动器,使用RAID 10,在RAID阵列中使用更多轴,使用更快的控制器,使用多个控制器,使用短描,避免使用san,在阵列上与其他应用程序共享数据文件。MDF和NDF文件应该始终与LDF文件隔离。理想情况下,每个LDF文件都应该放在自己的数组中以获得最佳性能。

磁盘平局写入时间

从逻辑盘写入数据的平均时间(以毫秒为单位)。

等效性能计数器:逻辑盘:平均磁盘秒/写

解释

测量数据写入逻辑磁盘时的延迟时间(磁盘响应的速度)。延迟越低,I/O性能越快,反之亦然。这个指标和磁盘平均读/秒指标是两个最重要的I/O瓶颈指标。

指南值

对于具有MDF和NDF文件和OLTP负载的驱动器,理想情况下平均写延迟应该低于20 ms。对于带有OLAP负载的驱动器,延迟达到30 ms被认为是可接受的。对于具有LDF文件的驱动器,延迟理想情况下应该是5毫秒或更少。一般来说,超过50毫秒就是慢了,意味着可能存在严重的I/O瓶颈。写延迟会随着时间的推移而变化,因此这些指标忽略了偶尔出现的峰值。

检查磁盘平均读取时间。这些值应符合上述准则。

可能的解决方案

优化查询以减少执行它们所使用的资源,使用更快的磁盘驱动器,使用RAID 10,在RAID阵列中使用更多轴,使用更快的控制器,使用多个控制器,使用短描,避免使用san,在阵列上与其他应用程序共享数据文件。MDF和NDF文件应该始终与LDF文件隔离。理想情况下,每个LDF文件都应该放在自己的数组中以获得最佳性能。

磁盘传输/秒

测量每秒逻辑磁盘上完成的读写请求的数量。

“Logical Disk”:磁盘传输数/秒

说明

此指标有助于确定逻辑磁盘上发生的IOPS(每秒的IOs)数量,以及您的SQL Server应用程序是否正在创建更多可以由磁盘子系统处理的I/O。

指导值

磁盘传输/秒不应该超过磁盘子系统的IOPS,否则将出现I/O瓶颈。

检查磁盘平均读时间和磁盘平均写时间。如果这些指标没有在推荐阈值内,那么很可能您的磁盘子系统没有满足当前应用程序工作负载所需的IOPS容量。

可能的解决方案

你应该做的第一件事是确定磁盘系统的IOPS容量。一旦你知道它是什么,那么你就可以知道是否需要做些什么来帮助提高磁盘子系统的IOPS能力,例如调整查询以减少执行它们所用的资源,使用更快的磁盘驱动器,使用RAID 10,在RAID阵列中使用更多的轴,使用更快的控制器,使用多个控制器,使用短划,避免使用san,在阵列上与其他应用程序共享数据文件。MDF和NDF文件应该始终与LDF文件隔离。理想情况下,每个LDF文件都应该放在自己的数组中以获得最佳性能。

平均磁盘队列长度

测量物理硬盘阵列上的压力。

Equivalent PerfMon counter: Logical Disk:平均磁盘队列长度

说明

这是物理磁盘排队的物理读和写请求的平均数量。

指南值

由于技术的变化,如虚拟化、磁盘和控制器技术、san等,该计数器不再是I/O瓶颈的良好指示器。更好的衡量I/O瓶颈的方法是平均磁盘读取时间和平均磁盘写入时间。

检查磁盘平均读时间和磁盘平均写时间。

SQL Server 指标

用户连接数

在给定时间内,连接到SQL Server实例的用户总数。

等价的PerfMon计数器:SQLServer:一般统计:用户连接

说明

该值提供了SQL Server繁忙程度的一般指导方针。每个到SQL Server实例的连接平均需要28 KB的内存开销,即使用户当前没有使用该连接。您可以调整SQL Server实例的设置,以便通过识别当前登录的用户数量自动确定允许的最大用户连接数。

一般来说,用户连接数和每秒的批量请求数之间存在相关性。

备注:用户连接数和用户数不一样。一个用户可能打开多个连接,或者多个用户共享一个连接。

指导值

随着时间的推移监控这个值很有用,可以指示SQL Server使用的增加或减少。工作线程的数量是根据SQL Server的安装类型和可用处理器的数量动态计算的:

对于32位服务器,基本工作线程数是256,服务器上的每个调度器在最初的4个线程之上添加了8个额外的工作线程((NumberOfSchedulers -4) *8) +256。

对于64位服务器,基本的工作线程数是512,服务器上的每个调度器都会增加16个额外的工作线程((NumberOfSchedulers -4) *16) +512)。

有关工作线程计数的更多信息,请参见配置最大工作线程服务器配置选项。

注意:如果使用连接池,服务器上的连接数量很容易是工作线程数量的三到四倍。每个应用程序域、每个连接字符串、每个服务器的连接都是池化的,并且不是每个连接都将在完全相同的时间执行。

SQL Server:处理器时间(SQL Server: processor time)

在Windows主机上运行SQL Server服务的处理器利用率(%)。

进程(sqlservr): %处理器时间

说明

这个值告诉您运行sqlservr进程(数据库引擎)所用处理器时间的百分比。它排除了其他与SQL Server相关的进程,如SQL Server代理、SSIS、报表服务、分析服务和全文搜索。因为SQL Server: processor time是Machine: processor time的子集,所以SQL Server: processor time值会更低。

注意:在多处理器计算机上,SQL Server通常会在一个处理器上使用超过100%的处理器时间。这是因为它的线程可能使用多个处理器。

标准值

理想情况下,SQL Server:处理器时间平均应该小于50%,以获得最佳SQL Server性能。如果它在一段时间内(5分钟或更长)平均超过80%,那么在此期间存在CPU瓶颈,您应该调查其原因。SQL Server中的短峰值:处理器时间超过80%是正常和预期的,只有持续的高CPU利用率才是问题。如果峰值表示平台期,而不是一个尖锐的峰值,这可能表明运行缓慢的查询导致了CPU问题。

一般来说,SQL Server: processor time应该是主机系统上最繁忙的进程,并且与Machine: processor time密切相关。如果SQL Server: processor time大大小于Machine: processor time,这可能表明主机系统上运行的其他进程正在使用CPU,潜在地使用了可以由数据库引擎使用的CPU资源,以提高其性能。如果是这种情况,请确定哪些进程正在使用任务管理器,以便诊断主机系统上发生的情况。

还需要检查—机器:

计算每个处理器的平均利用率,然后除以机器上处理器数量的处理器时间。如果这个平均值大于或等于80%,或者您记录的平均值总是大于50%,那么您的处理器可能需要升级。此外,平均CPU队列长度提供了一个更强的指示,是否您的处理器运行缓慢。

SQL Server:总内存

服务器当前使用的动态内存总量。

等价的性能计数器:SQLServer:内存管理器-服务器总内存(KB)

说明

mssqlserver服务当前使用的物理内存数量;包括提交给SQL Server BPool的缓冲区总数和“使用中的操作系统”类型的缓冲区。

参考值

如果SQL Server:总内存相对于计算机中的物理内存数量来说相对较高,这可能表明需要更多的物理内存。

检查其他

  1. 目标内存

显示SQL Server准备使用的最大动态内存(缓冲池)数量。此数字不能超过最大服务器内存设置。当SQL Server第一次启动时,这个值对应于SQL Server启动时预留的缓冲区。Microsoft SQL Server数据库引擎的默认内存管理行为是获取尽可能多的内存,而不会在系统上造成内存短缺。如果SQL Server在启动后需要更多的物理内存,并且有Mbytes可用,那么SQL Server会获取它,并且SQL Server: target内存会增加。如果操作系统从SQL Server请求内存回调,那么SQL Server:目标内存通常会减少,在某些情况下可能会导致SQL Server内存压力,影响SQL Server性能。

  1. 缓冲区空闲页

缓冲区缓存中可用的空闲空间的数量。一般来说,如果这个数字低于640页,这可能表明SQL Server内存压力过大。

  1. 缓冲页预期寿命

测量一个页在未被访问的情况下在缓冲缓存中停留的平均秒数。一般来说,如果他的值低于300秒,这可能表明SQL Server面临内存压力。

可能的解决方案

从服务器中删除不必要的应用程序和服务,并添加更多的物理RAM。

SQL Server:目标内存

SQL Server准备使用的最大动态内存(缓冲池)数量。

SQLServer:内存管理器-目标服务器内存(KB)

说明

显示SQL Server准备使用的最大动态内存(缓冲池)数量。该值不能超过最大服务器内存设置。当SQL Server第一次启动时,这个值对应于SQL Server启动时预留的缓冲区。Microsoft SQL Server数据库引擎的默认内存管理行为是获取尽可能多的内存,而不会在系统上造成内存短缺。如果SQL Server在启动后需要更多的物理内存,并且有Mbytes可用,那么SQL Server会获取它,并且SQL Server: target内存会增加。如果操作系统请求从SQL Server返回内存,那么SQL Server:目标内存通常会减少,在某些情况下可能会导致SQL Server内存压力,影响SQL Server的性能。

参考值

如果这个值很高(相对于你机器上可用的总物理内存),那么你应该考虑增加额外的物理内存,以提高SQL Server的性能。

检查其他:

  1. SQL Server: total memory

显示服务器当前使用的动态内存(缓冲池)总量。SQL Server:总内存将随着SQL Server的需要而增加,假设它是可用的。这个值总是小于或等于SQL Server: target memory。如果SQL Server:总内存与计算机中的物理内存数量相比相对较高,这可能表明需要更多的物理内存。

缓冲区空闲页:缓冲区缓存中可用的空闲空间的数量。如果这个数字低于640页,这可能表明SQL Server面临内存压力。

  1. 缓冲页预期寿命

测量一个页在未被访问的情况下在缓冲缓存中停留的平均秒数。如果他的值低于300秒,这可能表明SQL Server处于内存压力之下。

可能的解决方案

从服务器中删除不必要的应用程序和服务,并添加更多的物理RAM。

SQL Server:可用内存

服务器未使用的动态内存总量。

注意:该指标是在SQL Server 2012中引入的,用于替换缓冲区空闲页(在SQL Server 2008及更早版本中使用)。对于SQL Server 2008及更早版本,我们已经将空闲页面转换为内存(1页等于8 KB)。

等价的PerfMon计数器:SQLServer:内存管理器-空闲内存

说明

内存管理器监视SQL Server的整体内存使用情况。此指标可以帮助您确定是否存在内存不足导致的瓶颈(这意味着SQL Server必须从磁盘检索数据)。它还可以帮助您确定是否可以通过增加内存量来提高查询性能。

准则值

大于5 MB的空闲内存值应确保缓冲区缓存可以处理足够的新内存分配请求。小于5 MB的值可能意味着请求被搁置,这会影响性能。您可以考虑增加内存或为数据缓存提供更多内存。

SQL Server:动态 SQL 缓存内存

服务器用于动态SQL缓存的动态内存总量。

SQLServer:内存管理器- SQL缓存内存(KB)

指导值

这个计数器没有正确或错误的数字。在很多情况下,这个计数器的值不会随着时间的推移发生太大的变化,这正是在没有内存压力的服务器上所期望的。

该计数器随时间的突然下降可能表明实例处于内存压力下,SQL Server必须回收计划缓存的一部分以供其他使用。

或者,该计数器的快速增加可能表明可能执行了大量一次性使用的临时查询,从而导致计划缓存污染。这通常发生在SQL Server重启后不久。如果这种情况持续存在,请考虑打开“优化ad hoc工作负载”实例级选项,以停止计划缓存污染。

SQL Server:连接内存

服务器当前用于维护活动连接的动态内存总量。

SQLServer:内存管理器-连接内存(KB)

说明

此指标表明活动连接使用了多少内存。

指导值

该监控指标应该只占服务器总内存的一小部分。

检查其他

  1. 目标内存

显示SQL Server准备使用的最大动态内存(缓冲池)数量。此数字不能超过最大服务器内存设置。当SQL Server第一次启动时,这个值对应于SQL Server启动时预留的缓冲区。Microsoft SQL Server数据库引擎的默认内存管理行为是获取尽可能多的内存,而不会在系统上造成内存短缺。如果SQL Server在启动后需要更多的物理内存,并且有Mbytes可用,那么SQL Server会获取它,并且SQL Server: target内存会增加。如果操作系统从SQL Server请求内存回调,那么SQL Server:目标内存通常会减少,在某些情况下可能会导致SQL Server内存压力,影响SQL Server性能。

SQL Server:锁定内存

服务器当前用于锁的动态内存总量。

SQLServer:内存管理器-锁内存(KB)

说明

此指标指示用于存储锁的SQL Server内存的大小。

指导值

该监控指标应该只占服务器总内存的一小部分。

检查其他

  1. 目标内存

显示SQL Server准备使用的最大动态内存(缓冲池)数量。此数字不能超过最大服务器内存设置。当SQL Server第一次启动时,这个值对应于SQL Server启动时预留的缓冲区。Microsoft SQL Server数据库引擎的默认内存管理行为是获取尽可能多的内存,而不会在系统上造成内存短缺。如果SQL Server在启动后需要更多的物理内存,并且有Mbytes可用,那么SQL Server会获取它,并且SQL Server: target内存会增加。如果操作系统从SQL Server请求内存回调,那么SQL Server:目标内存通常会减少,在某些情况下可能会导致SQL Server内存压力,影响SQL Server性能。

SQL Server:缓冲缓存

服务器当前用于缓冲缓存(数据库缓存)的动态内存总量。

SQLServer:内存管理器-数据库缓存内存(KB)

说明

mssqlserver服务当前使用的物理内存数量;包括提交给SQL Server BPool的缓冲区总数和“使用中的操作系统”类型的缓冲区。

指导值

这通常应该是SQL Server使用的最大内存组件。如果SQL Server: buffer缓存内存相对于计算机中的物理内存数量来说是相对高的,这可能表明需要更多的物理内存。

检查其他

目标内存:显示SQL Server准备使用的最大动态内存(缓冲池)数量。此数字不能超过最大服务器内存设置。当SQL Server第一次启动时,这个值对应于SQL Server启动时预留的缓冲区。Microsoft SQL Server数据库引擎的默认内存管理行为是获取尽可能多的内存,而不会在系统上造成内存短缺。如果SQL Server在启动后需要更多的物理内存,并且有Mbytes可用,那么SQL Server会获取它,并且SQL Server: target内存会增加。如果操作系统从SQL Server请求内存回调,那么SQL Server:目标内存通常会减少,在某些情况下可能会导致SQL Server内存压力,影响SQL Server性能。

缓冲区空闲页:缓冲区缓存中可用的空闲空间的数量。一般来说,如果这个数字低于640页,这可能表明SQL Server内存压力过大。

缓冲页预期寿命:测量一个页在未被访问的情况下在缓冲缓存中停留的平均秒数。一般来说,如果他的值低于300秒,这可能表明SQL Server面临内存压力。

SQL Server:日志池内存

服务器当前为日志池使用的动态内存总量。

SQLServer:内存管理器-日志池内存(KB)

说明

日志池是事务日志的内存缓存,用于优化恢复和回滚等操作。SQL Server: log pool memory日志池使用的内存大小。

指导值:该监控指标应该只占服务器总内存的一小部分。

检查其他

目标内存

显示SQL Server准备使用的最大动态内存(缓冲池)数量。此数字不能超过最大服务器内存设置。当SQL Server第一次启动时,这个值对应于SQL Server启动时预留的缓冲区。Microsoft SQL Server数据库引擎的默认内存管理行为是获取尽可能多的内存,而不会在系统上造成内存短缺。如果SQL Server在启动后需要更多的物理内存,并且有Mbytes可用,那么SQL Server会获取它,并且SQL Server: target内存会增加。如果操作系统从SQL Server请求内存回调,那么SQL Server:目标内存通常会减少,在某些情况下可能会导致SQL Server内存压力,影响SQL Server性能。

批处理请求/秒

自上次收集时间以来,SQL Server每秒接收到的T-SQL批处理请求数。

等价的PerfMon计数器:SQLServer:SQL统计-批量请求/秒

说明:这给出了SQL Server繁忙程度的一般指标。它会测量发送到SQL Server的所有批数据。SQL Server可以处理的批量请求数量取决于硬件的能力。随着时间的推移,跟踪这个值,评估系统的可伸缩性,以及识别用户请求的峰值和低谷可能是有用的。

Batch requests/sec只跟踪批处理的数量,而不是批处理中的语句。有些批次可能只使用很少的资源,而其他批次可能使用大量的资源。每个批次都是不同的,并且此监控指标只提供SQL Server执行的批次的绝对计数。

指导值:一般来说,每秒超过1000批请求表明SQL Server非常繁忙,并可能突出出现CPU瓶颈的可能性。更强大的硬件当然可以处理更多的请求。

检查:编译/批和编译/秒。这些值应该尽可能低,因为高值可能表明正在运行许多临时查询。您可能需要优化T-SQL。

编译/秒

每秒SQL编译次数;每个数据点显示自前一个数据点以来的平均值。

SQLServer:SQL统计- SQL编译/秒

解释:每秒发生Transact-SQL编译的次数(包括重新编译)。值越低越好。每次编译都会使用CPU和其他资源,因此SQL Server会尽可能地重用缓存的执行计划。不需要重新编译存储过程可以减少服务器上的开销,提高整体性能。

准则值:一般来说,编译/秒应该小于批处理请求/秒的10%。高值通常表明过多的adhoc查询,应该尽可能低。

检查:批量请求/秒。

可能的解决方案:将临时查询重写为存储过程。减少临时表的使用,或者合并语句来消除存储过程中的临时表。检查“SET”语句——如ANSI_PADDING或ANSI_NULLS等会话设置的更改可能会导致查询被重新编译。如果SQL编译/秒过多,请考虑在数据库上使用“强制参数化”。这让SQL Server强制对几乎所有的SELECT、INSERT、UPDATE和DELETE语句进行参数化,这样可以减少语句的编译次数,因为可以重用更多的查询计划。

编译/批处理

SQL Server收到的每批请求的SQL编译。

等效的性能计数器:(SQLServer:SQL统计- SQL编译/秒)/ (SQLServer:SQL统计-批处理请求/秒)

说明:这应该提供SQL Server查询优化器处理用户查询的速度和效率的一般指示。

准则值:一般来说,编译/秒应该小于批处理请求/秒的10%。高值通常表明过多的adhoc查询,应该尽可能低。

检查:编译/秒和批处理请求/秒。

重新编译/秒

必须重新编译尝试执行Transact-SQL对象的次数(每秒)。

等价的PerfMon计数器:SQLServer:SQL统计-重新编译/秒

说明:通常,一旦对象被编译,就不必重新编译。当重新编译存储过程或查询时,将在过程引用的对象上放置编译锁,并可能发生数据库阻塞。过度的重新编译可能导致严重的性能问题,或者可能编译与任何已知锁类型不兼容的锁。

准则值:重新编译/秒应该尽可能小。任何大于10%的编译/秒的值都可能表明有问题。

还要检查:编译/秒、批处理请求/秒和编译/批处理请求,以确定SQL Server和查询优化器处理用户查询的速度和效率。还在分析器跟踪中检查SP:Recompile和SQL:StmtRecompile事件类,以确定每次运行时需要重新编译哪些存储过程和SQL语句。EventSubClass数据列会告诉你导致重新编译的原因。

缓存区页预期寿命

表示页在没有被引用的情况下在缓冲池中停留的平均秒数。

等价的性能计数器:SQLServer:缓冲管理器-页面预期寿命

说明:数据缓存在缓冲池中,因此检索数据的速度比从磁盘检索快得多。但是,一旦数据页存储在缓冲池中,就可能会重用,也可能不会重用。如果一段时间后页没有被引用,那么将从缓冲池中删除该页,以便其他数据可以使用该空间。较高的缓冲页预期寿命表明缓冲页经常被重用,这反过来表明SQL Server没有任何内存压力。

指导值:这个值取决于服务器上安装的RAM数量。最好的做法是记录一个基线测量,您可以根据它来比较一段时间内监视的值。通过运行公式(DataCacheSizeInGB/4GB*300)来实现这一点,正如查找计划缓存中使用特定索引的查询所建议的那样。有关如何查找数据缓存大小的详细信息,请参见浪费缓冲池内存带来的性能问题。

如果数据页始终保持在缓冲区中的值低于基线值,这可能表明系统上内存不足,或者没有为SQL Server配置足够的内存。您可以考虑通过增加RAM来提高性能。这个问题也可能是由于缺少索引、糟糕的索引设计或编写糟糕的应用程序代码(例如重新编译了太多的存储过程,或者在只有少量行需要更改时读取缓冲池中的大型表)引起的。解决特定于应用程序的问题可能会提高性能。

页面读取/秒

测量每秒停止等待空闲缓冲区变为可用的请求数。

等价的PerfMon计数器:SQLServer:缓冲管理器-空闲列表停顿/秒

说明:在SQL Server能够处理数据之前,数据必须加载到内存中的未使用页中。如果没有可用的页,SQL Server必须等待,直到有数据可用的页。这可能表明SQL Server没有足够的内存可用。

准则值:频繁值高于0可能表示内存压力。

如果SQL Server一直在等待空闲内存来获取新页面,那么可以通过以下方式解决:

增加SQL Server可用的内存

优化查询以请求更少的数据

全扫描/秒

测量每秒发生的基表或全索引扫描的次数。

等效的性能计数器:SQLServer:访问方法:全扫描/秒

说明:该值监视对表或索引执行了多少次全扫描。虽然索引扫描是SQL Server正常工作的一部分,但大量的全扫描可能表明索引缺失、访问许多小表或返回大量行的查询。

指标值:记录一个基准测量值是最好的做法,您可以根据它来比较您的监控值。如果监控的值与基线相比明显更高,并且CPU也很高,则可能意味着性能瓶颈。索引搜索/秒与全扫描/秒的比率一般不应超过1000:1。

检查还:机器:处理器时间,以确定CPU是否也高。还可以根据基线测量来查看批处理请求/秒的情况,以了解数据库处理查询的详细情况。然后,您可以检查锁等待/秒和锁超时/秒,以确定锁问题是否影响性能。

页拆分/秒

SQL Server表中每秒进行的页分割和新页分配的数量。

等效的性能计数器:SQLServer:访问方法:页面分割/秒

说明:当新数据被插入或添加到现有的数据页面时,页面没有足够的空间容纳所有的新数据,SQL Server分割页面,将一半数据留在旧页面上,另一半放在新页面上。这是一个普通的SQL Server事件,但是过多的页分割可能会导致索引碎片和各种相关的性能问题。

指标值:最好的做法是记录一个基线,您可以根据它来比较您的监控值。一般来说,这个值不应该大于每秒批量请求数的20%。较小的值是可取的,但是什么是较小的值取决于许多可变因素,包括用户数量、用户活动级别和I/O子系统的性能能力。

检查磁盘平均读时间和磁盘平均写时间。过多的I/O活动和过多的页拆分之间通常存在相关性。

可能的解决方案:解决页面分割问题通常很困难,因为原始的数据库设计可能是导致该问题的原因。除了重新考虑数据库设计之外,还可以考虑重新评估索引策略,并可能增加因过度页面分割而影响的索引的填充因子。如果无法有效消除过多的页分割,请考虑增加重建或重新组织索引的频率,以删除由页分割创建的碎片。

页拆分/批处理请求

SQL Server表中每秒页面分割的数量除以每秒接收到的T-SQL命令批处理请求的数量。

等效的性能计数器:(SQLServer:访问方法:页面分割/秒)/ (SQLServer:SQL统计-批量请求/秒)

解释:虽然拆分页面是SQL Server的正常功能,但过度的拆分页面会对SQL Server的性能产生负面影响。

指导值:平均来说,每个批处理请求的页面分割数应该低于每秒批处理请求数的20%,但理想情况下应该尽可能接近0。

还要检查:索引中表的填充因子。填充因子越低,空间越大,这有助于减少潜在的页面分割。有关填充因子的更多信息,请参阅MSDN文档。

闩锁等待时间

闩锁请求在执行之前必须等待的平均等待时间,以毫秒为单位。

SQLServer:Latches -平均闩锁等待时间(ms)

说明:将锁存器视为SQL Server用于管理许多内部操作的轻量级锁。它们防止一个SQL Server内部操作与另一个SQL Server内部操作发生冲突。这个平均值是通过闩锁等待毫秒数除以闩锁等待数计算出来的。

监控闩锁等待时间通常有助于识别可能导致性能瓶颈的用户活动和资源利用情况。应该将当前平均值与基线平均值进行比较。请注意,不需要等待请求被授予的锁存器不包括在该值中。

指导值:通常,该指标与闩锁等待时间/秒之间存在相关性。使用PerfMon检查闩锁等待/秒值。如果两个值都高于基线平均值,则SQL Server正在经历资源争用,需要进一步调查。

动态管理视图(DMV)包含以下功能,以帮助识别导致闩锁等待问题的活动:

Sys.Dm_os_latch_stats(按类划分闩锁等待信息)

Sys.Dm_os_wait_stats(执行中的线程遇到的等待的详细信息)

Sys.dm_db_index_operational_stats(表分区或数据库索引的I/O、锁存、锁定和访问方法活动的详细信息)

为了理解SQL Server实例的性能问题,必须检查每个闩锁类的相对等待数和时间。

锁超时/秒

每秒超时的锁数。

等价的PerfMon计数器:SQLServer:Locks -锁超时/秒

说明:在SQL Server资源上持有锁,以防止它们被另一个事务同时使用。例如,如果一个事务持有一行上的排它锁,在锁被移除之前,其他事务不能对该行进行更改。更少的锁允许更多的并发事务发生,这可以提高性能。

SQL Server中的锁超时限制取决于使用set LOCK_TIMEOUT命令设置的值。如果没有设置值,SQL Server将无限期地等待锁清除。

准则值:任何大于0的值都表明用户可能遇到了未完成查询的问题。

检查:锁等待/秒。这可以确定没有超时但必须等待资源的锁的数量。

锁等待/秒

每秒无法立即满足且必须等待资源的锁数量。

等价的PerfMon计数器:SQLServer:Locks -锁等待/秒

说明:在SQL Server资源上持有锁,以防止它们被另一个事务同时使用。例如,如果一个事务持有一行上的排它锁,在锁被移除之前,其他事务不能对该行进行更改。更少的锁允许更多的并发事务发生,这可以提高性能。

准则值:任何大于0的值都表明发生了某种程度的阻塞。最好的做法是将当前值与基线进行比较,以确定哪些值对SQL Server来说是正常的。增加的锁等待时间表明潜在的资源争用。

还要检查平均磁盘队列长度。磁盘排队过多可能是由于磁盘子系统配置不当或大小不足造成的。您可能需要检查索引并研究并发连接的数量。

平均锁定等待时间

不能立即满足要求而必须等待资源的每个锁的平均等待时间(以毫秒为单位)。

等价的性能计数器:SQLServer:Locks—平均等待时间(ms)

说明:在SQL Server资源上持有锁,以防止它们被另一个事务同时使用。例如,如果一个事务持有一行上的排它锁,在锁被移除之前,其他事务不能对该行进行更改。更少的锁允许更多的并发事务发生,这可以提高性能。

指导值:平均等待时间为500毫秒或更多可能表明过度阻塞,应该进行调查。一般来说,平均锁等待时间与锁等待时间/秒相关,如果您看到这两个时间都在增加,则需要调查是什么导致了阻塞问题。

还要检查—锁等待/秒以确定时间峰值,锁超时/秒以查看有多少锁达到使用set LOCK_TIMEOUT命令设置的阈值。

Data Base 指标

事务/秒

每秒数据库启动的事务数。每个数据点显示自前一个数据点以来每秒的平均事务数。

等价的性能计数器:SQLServer:数据库-事务/秒

说明:事务是一个或多个数据库操作组合成一个操作;可以是由BEGIN TRAN和COMMIT TRAN包围的用户定义事务,也可以是单独的数据修改语句,如INSERT或UPDATE。事务速率受到系统总体性能和资源(如I/O、用户数量、缓存大小和请求复杂度)的影响。此计数器仅记录显式交易或更改数据的交易。

注意:每秒事务数仅衡量事务内部的活动,而不是所有活动,批请求/秒指标更完整地描述了所有SQL Server活动。

准则值:每秒的事务数高并不一定表明有问题,只是说明SQL Server上有很多活动。您应该建立一个基线值,并在事务异常高或低时进行跟踪。

活动事务

数据库的活动事务数。每个数据点显示收集数据点的活动事务数。

SQLServer:数据库-活动事务

说明:活动事务是数据库上尚未提交或回滚的更新事务。

注意:此度量度量事务内的活动,而不是所有活动。Batch requests/sec指标是所有SQL Server活动的一个更完整的描述。

准则值:通常,活动事务的数量应该大大低于每秒钟的事务数量(因为活动事务只显示那些尚未完成的事务)。如果当前活动的事务数量高于transactions /sec指标,那么这可能表明您有长时间运行的事务。长时间运行的事务会增加锁时间并导致阻塞。

总文件大小

所有数据文件的总大小(以GB为单位).MDF和.ndf)和日志文件(.ldf)。

说明:该值是总数据文件大小和总日志文件大小的总和。它对于确定数据库所需的空间大小和确定趋势很有用。

准则值:为了最佳实践,应该主动管理MDF、NDF和LDF文件,以防止自动增长启动和增长数据库文件。

注意:如果该指标的值间歇性地降为零,最有可能的原因是影响sys的问题。

另外还可以查看:日志大小查看所有。ldf文件的详细信息,数据大小查看所有.mdf和.ndf文件的详细信息。

总数据文件大小(MDF)

所有数据文件的总大小(. MDF和.ndf文件)用于指定的数据库。

说明:此值是数据库的总大小,不包括事务日志。有关主数据文件(.mdf)和辅助数据文件(.ndf)的信息,如它们当前的大小、位置和自动增长设置,显示在SQL Server Management Studio中Database overview页面的files部分。

准则值:注意数据文件的大小是否有不寻常的大幅增长。理想情况下,你的数据库应该以最小化自动增长的方式调整大小,因为每增加一个大小都需要花费大量的I/O,并且还会对数据和日志文件进行物理分片。

按需扩展文件是一个代价昂贵的过程,会影响性能。Autogrowth应该只用作一个安全阀,以便在意外耗尽空间时允许数据库增长。它不应该用于管理您的MDF文件的增长。

一般来说,数据文件在创建时应该预先设置大小,以满足未来预期的增长,这有助于避免文件碎片并确保更好的数据库性能。

检查也:

所有生产数据库采用全量恢复模式。

在使用全恢复模式时,请确保定期进行全备份和事务日志备份。

文件被设置为正常活动所需的空间大小。监视数据文件并在数据增长时手动添加空间。你的数据文件应该有6-12个月的增长空间。

如果您没有空间让数据库以当前速度增长,请将数据库移动到更大的磁盘驱动器或升级磁盘本身。

注意:压缩文件以减少空间会导致碎片,不建议使用。

使用的数据文件总数

所有数据文件(. MDF和.ndf文件)用于指定的数据库。

说明:此值是数据库内的总数据使用情况,不包括事务日志。有关主数据文件(.mdf)和辅助数据文件(.ndf)的信息,如它们当前的大小、位置和自动增长设置,显示在SQL Server Management Studio中Database overview页面的files部分。

指导值:注意数据文件中不寻常的大量使用。理想情况下,你的数据库应该以最小化自动增长的方式调整大小,因为每增加一个大小都需要花费大量的I/O,并且还会对数据和日志文件进行物理分片。

按需扩展文件是一个代价昂贵的过程,会影响性能。Autogrowth应该只用作一个安全阀,以便在意外耗尽空间时允许数据库增长。它不应该用于管理您的MDF文件的增长。

一般来说,数据文件在创建时应该预先设置大小,以满足未来预期的增长,这有助于避免文件碎片并确保更好的数据库性能。

注意:如果该指标的值间歇性地降为零,最有可能的原因是影响sys的问题

检查其他:

所有生产数据库采用全量恢复模式。

在使用全恢复模式时,请确保定期进行全备份和事务日志备份。

文件被设置为正常活动所需的空间大小。监视数据文件并在数据增长时手动添加空间。你的数据文件应该有6-12个月的增长空间。

如果您没有空间让数据库以当前速度增长,请将数据库移动到更大的磁盘驱动器或升级磁盘本身。

注意:压缩文件以减少空间会导致碎片,不建议使用。

SQL Server 2008+ 性能调优相关推荐

  1. sql索引调优_使用内置索引利用率指标SQL Server索引性能调优

    sql索引调优 描述 (Description) Indexing is key to efficient query execution. Knowing what indexes are unne ...

  2. SQL Server 2008性能故障排查(二)——CPU

    原文: SQL Server 2008性能故障排查(二)--CPU 承接上一篇:SQL Server 2008性能故障排查(一)--概论 说明一下,CSDN的博客编辑非常不人性化,我在word里面都排 ...

  3. server sql top速度变慢解决方案_SQL Server的性能调优:解决查询速度慢的五种方法-数据库...

    编辑推荐: 本文主要通过一下几个方面介绍:使用SQL DMV查找慢速查询.通过APM解决方案查询报告.SQL Server扩展事件.SQL Azure查询性能洞察等相关内容. 本文来自博客园,由火龙果 ...

  4. sql server linux性能,详细了解SQL Server 2008性能和性能优化

    在SQL Server 2005或更早的版本中的中,表变量是不能作为存储过程的参数的.当多行数据到SQL Server需要发送多行数据到SQL Server ,开发者要么每次发送一列记录,或想出其他的 ...

  5. SQL Server 2008性能故障排查(三)——I/O

    接着上一章:CPU瓶颈 I/O瓶颈(I/O Bottlenecks): SQLServer的性能严重依赖I/O子系统.除非你的数据库完全加载到物理内存中,否则SQLServer会不断地把数据库文件从缓 ...

  6. azure云数据库_Azure SQL数据库的性能调优

    azure云数据库 With the latest versions of Azure SQL database, Microsoft has introduced a number of new m ...

  7. SQL Server 执行计划(8) - 使用 SQL 执行计划进行查询性能调优

    在本系列的前几篇文章(见底部索引)中,我们介绍了SQL 执行计划的多个方面,我们讨论了执行计划是如何在内部生成的,不同类型的计划,主要组件和运算符以及如何阅读和分析使用不同工具生成的计划.在本文中,我 ...

  8. SQL PASS北京用户群成功举办第一次线下活动,性能调优PPT分享

    昨天晚上在北京利星行举办了第一场PASS北京用户群的线下活动.     这次活动主要是由微软的大牛,也是MCM的何雷老师进行讲解SQL Server的性能调优.何老师内力深厚,由点带面的将性能调优的方 ...

  9. SQL Server 2008 高可用性视频(四)-- 故障转移群集

    做数据库的朋友都知道, 其实数据库的工作大致可以分为三类: 数据库设计与开发, 数据库管理, 数据库商业智能. 其中数据库管理的工作大部分是由DBA在做, DBA们除了要保证正常的数据库运行, 还要采 ...

最新文章

  1. 恭喜!中科大少年班放榜:2020年全国录取48人
  2. Spring Hiernate整合
  3. 对付网络盗贼的三板斧
  4. Java数据结构和算法:数组、单链表、双链表
  5. 【机器学习基础】GBDT--梯度提升树实例分析完全解读
  6. oracle创建表空间及用户,Oracle创建表空间和用户
  7. VSCode 多开、环境对比
  8. ResNet被全面超越了,是Transformer干的:轻量版优于MobileNet
  9. CentOS安装mysql*.rpm提示conflicts with file from package的解决的方法
  10. (转)EXCEL2007存储格式xlsx
  11. 零基础带你学习MySQL—not null 非空(二十四)
  12. 傅里叶变换性质证明卷积_图傅里叶变换
  13. 用分组编码解决算术编码的精度要求问题
  14. C语言--fseek()
  15. 客房管理系统java代码_java客房管理系统代码
  16. Mac电脑DisplayPort/HDMI连接显示器后没声音
  17. SAP 移动价(V)与标准价(S)
  18. 对antd中的表格筛选进行改造
  19. php显示汉字,在php中如何显示汉字?
  20. InfluxDB使用教程:数据库管理工具InfluxDBStudio

热门文章

  1. Power BI----认识Power BI
  2. ActiveX控件:设置控件属性和方法的一种简易办法(VS2013)
  3. 短信群发的频率应该是多少
  4. Java 多线程之间通讯(面试概念解答三)
  5. 2019电商生意经(五):明确中台化的概念、形式与战略
  6. VAE中重参数化技巧
  7. C++ Builder-程序无法在其他机器上运行(显示找不到vcl60.bpl 或者BORLANDMM.DLL等)
  8. 【SystemVerilog基础】SV常用的运算操作符总结
  9. layui 表格加载动画_移动UI设计中动画的3个主要用途
  10. DICOM:基于DCMTK实现C-FIND SCU