怎样查出SQLServer的性能瓶颈

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了怎样查出SQLServer的性能瓶颈相关的知识,希望对你有一定的参考价值。

SQLServer性能监控

这套性能优化的清单将至少准科学的帮助你找出你的SQLServer任何明显的性能问题。说是这样说,SQLServer的性能调优仍然是很困难的。我试图用这套清单去找出“容易”的sqlserver性能问题,困难的留待稍后。我这样做是因为很容易将容易和困难的的性能调优问题搞混。通过列出一个“容易”的性能调优范围,就很容易的将这些问题解决,一旦解决了这些容易的问题,那么你就能集中去解决更困难的问题。

使用这个SQLServer性能调优清单的一个好处是,它将不仅仅告诉你目前最容易解决的性能问题是什么,而且还帮助你正确的去解决。在某种程度上,你可以选择不同的顺序进行。换句话说,你可以故意做出特殊的决定而不是按照清单通常的顺序进行。某种意义上说你是对的,不是所有的性能调优建议都适合所有的情形。另外,你的决定是基于你的资源限制,例如没有足够的钱去买满足负荷的硬件。如果真是那样的话,你就别无选择了。还有,你的决定可能基于一些政治原因,那是你不得不作出的改变。不管怎样,你需要知道你能做什么,使用这个性能调优清单找出你能改变的范围并做出相应的改变提升你的SQLServer的性能。

一般来说,你将在你的每一个SQL服务器上执行这个清单。如果遇到清单中的一些问题,这会花掉你一些时间。我建议你从目前性能问题最多的的服务器开始,然后当你有时间的时候按照自己的思路去解决其他服务器。

一旦你完成了,可仍然有很多事情要去做。记住,这些只是一些容易的。一旦你完成了这些容易的,接下来你需要花时间去解决更困难问题。这个是另一篇文章要解决的问题了。

怎样进行你的SQLServer性能调优呢?

为了使其变得容易,我把它们分成了以下几个部分:
? 使用性能监视器找出硬件瓶颈
? SQLServer硬件性能监控列表
? 操作系统性能监控列表
? SQLServer2000配置性能监控列表
? 数据库配置设置性能监控列表
? 索引性能监控列表
? 应用程序和T-SQL性能监控列表
? SQLServer数据库作业性能监控列表
? 使用Profiler找出低效的查询
? 怎样最好的实现SQLServer性能监控
管理你的SQLServe性能的最好方法是首先回顾上面每一部分的内容,把它们打印出来。然后完成每一部分的内容,写下你收集到的结果。你也可以按照你喜欢的顺序进行。上面的步骤仅仅列出了我执行的顺序,因为那样通常能达到一个比较好的效果。

性能监控列表
计数器名称 均值 最小值 最大值
Memory: Pages/sec
Memory: Available Bytes
Physical Disk: % Disk time
Physical Disk: Avg. Disk Queue Length
Processor: % Processor Time
System: Processor Queue Length
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections

在上表输入你的结果.

使用性能监视器找出SQLServer硬件瓶颈

开始SQLServer性能调优的最佳地方就是从性能监视器(系统监视器)开始。通过一个24小时的周期对一些关键的计数器进行监控,你将对你SQLServer服务器的硬件瓶颈了如指掌。

一般来说,使用性能监视器去创建一个一些关键的计数器的24小时周期的监控日志。当你决定创建这个日志的时候,你需要选择一个典型的24小时的周期,例如,选择一个典型的比较忙的日期,而不是周日或节假日。

一旦你将这些捕获的数据形成日志后,在性能监视器的图形界面下会显示计数器的推荐值。你在上表中记下均值、最小值、峰值。做完这些后,用你的结果跟下面的分析比较。通过你的结果和下面的建议值进行比较,你将能快速的找到你的SQLServe正在经历的潜在的硬件瓶颈。

关键性能计数器说明

下面是不同关键性能计数器的一个讨论,它们的建议值和为了帮助解决硬件瓶颈问题的一些选项。注意我已经限制了性能监视器需要监视的一些关键计数器。我这么做是因为在本文我们的目的是为了容易的找到显而易见的性能问题,许多其他的性能监视器计数器你能在本网站其他地方找到。

Memory: Pages/sec

这个计数器记录的是每秒钟内存和磁盘之间交换的页面数。交换更多的页面、超过你服务器承受的更多的I/O,将轮流降低你SQLserver的性能。你的目的就是尽量将页面减少到最小,而不是消除它。

如果你的服务器上SQLServer是最主要的应用程序,那么这个值的理想范围是0~20之间。可能很多时候你看到的值都会超过20。这个值一般要保持在每秒的平均页数在20以下。

如果这个值平均总是超过20,其中最大的一个可能是内存瓶颈问题,需要增加内存。通常来说,更多的内存意味着需要执行的页面更少。
在大多数情况下,服务器决定SQLServer使用的适当内存的大小,页面将平均小于20。给SQLServer适当的内存意味着服务器的缓存命中率(Buffer Hit Cache Ratio 这个稍后会讲到)达到99%或者更高。如果在一个24小时的周期里你的sqlserver的缓存命中率达到99%或者更高,但是在这个期间你的页面数总是超过20,这意味着你或许运行了其他的程序。如果是这样的情况,建议你移除这些程序,使SQLServer是你的服务器的最主要的程序。

如果你的sqlserver服务器没有运行其他程序,并且在一个24小时的周期里页面数总是超过20,这说明你应该修改你对SQLServer的内存设置了。将其设置为“动态配置SQLServer的内存”,并且最大内存设置得高一些。为了达到最优,SQLServer将尽可能的获得多的内存以完成自己的工作,而不是去和其他的程序争夺内存。

Memory: Available Bytes

另一个检查SQLServer是否有足够的物理内存的方法是检查Memory Object: Available Bytes计数器。 这个值至少大于5M,否则需要添加更多的物理内存。在一个专门的SQLServer服务器上,SQLServer试图维持4-10M的自由物理内存,其余的物理内存被操作系统和SQLServer使用。当可用的物理内存接近5M或者更低时,SQLServer最可能因为缺少内存而遇到性能瓶颈。遇此情况,你需要增加物理内存以减少服务器的负荷,或者给SQLServer配置一个合适的内存。

Physical Disk: % Disk Time

这个计数器度量磁盘阵列繁忙程度(不是逻辑分区或磁盘阵列上独立的磁盘)。它提供一个对磁盘阵列繁忙程度相对较好的度量。原则上计数器% Disk Time的值应该小于55%。如果持续超过55%(在你24小时的监控周期里大约超过10分钟),说明你的SQLServer有I/O瓶颈。如果你只是偶尔看到,也不必太担心。但是,如果经常发生的话(也就是说,一个小时出现好几次),就应该着手寻找增加服务器I/O性能或者减少服务器负荷的解决之道了。一般是为磁盘阵列增加磁盘,或者更好更快的磁盘,或者给控制器卡增加缓存,或者使用不同版本的RAID,或者更换更快的控制器。

在NT4.0上使用该计数器之前,确认在NT命令提示符下输入diskperf -y,重启服务器,以便手动打开。在NT4.0下第一次必须将该计数器打开,Windows2000默认是打开的。

Physical Disk: Avg. Disk Queue Length

除了观察物理磁盘的% Disk Time计数器外,还可以用Avg. Disk Queue Length计数器。磁盘阵列中的各个磁盘的该值如果超过2(在你24小时的监控周期里大约超过10分钟),那么你的磁盘阵列存在I/O瓶颈问题。象计数器% Disk Time一样,如果只是偶尔看到,也不必太担心。但是,如果经常发生的话,就应该着手寻找增加服务器I/O性能的解决之道了。如前所述。

你需要计算这个值,因为性能监视器不知道你的磁盘阵列中有多少物理磁盘。例如,如果你有一个6个物理磁盘组成的磁盘阵列,它的Avg.
Disk Queue Length值为10,那么实际每个磁盘的值为1.66(10/6=1.66),它们都在建议值2以内。

在NT4.0上使用该计数器之前,确认在NT命令提示符下输入diskperf -y,重启服务器,以便手动打开。在NT4.0下第一次必须将该计数器打开,Windows2000默认是打开的。

一起使用这两个计数器将帮助你找出I/O瓶颈。例如,如果% Disk Time的值超过55%,Avg. Disk Queue Length计数器值超过2,服务器则存在I/O瓶颈。

Processor: % Processor Time

处理器对象: % Processor Time计数器对每一个CPU可用,并针对每一个CPU进行检测。同样对于所有的CPU也可用。这是一个观察CPU利用率的关键计数器。如果% Total Processor Time计数器的值持续超过80%(在你24小时的监控周期里大约超过10分钟),说明CPU存在瓶颈问题。如果只是偶尔发生,并且你认为对你的服务器影响不大,那没问题。如果经常发生,你应该减少服务器的负载,更换更高频率的CPU,或者增加CPU的数量或者增加CPU的2级缓存(L2 cache)。

System: Processor Queue Length

根据% Processor Time计数器,你可以监控Processor Queue Length计数器。每个CPU的该值如果持续超过2(在你24小时的监控周期里大约超过10分钟),那么你的CPU存在瓶颈问题。例如,如果你的服务器有4个CPU,Processor Queue Length计数器的值总共不应超过8。

如果Processor Queue Length计数器的值有规律的超过建议的最大值,但是CPU利用率相对不是很高,那么考虑减少SQLServer的"max worker threads"的配置值。Processor Queue Length计数器的值高的可能原因是有太多的工作线程等待处理。通过减少"maximum worker threads"的值,强迫线程池踢掉某些线程,从而使线程池得到最大的利用。

一起使用计数器Processor Queue Length和计数器% Total Process Time,你可以找到CPU瓶颈,如果都显示超过它们的建议值,可以确信存在CPU瓶颈问题。

SQL Server Buffer: Buffer Cache Hit Ratio

SQL Server Buffer中的计数器Buffer Cache Hit Ratio用来指出SQLServer从缓存中而不是磁盘中获得数据的频率。在一个OLTP程序中,该比率应该超过90%,理想值是超过99%。如果你的buffer cache hit ratio低于90%,你需要立即增加内存。如果该比率在90%和99%之间,你应该认真考虑购买更多的内存了。如果接近99%,你的SQLServer性能是比较快的了。某些情况下,如果你的数据库非常大,你不可能达到99%,即使你在服务器上配置了最大的内存。你所能做的就是尽可能的添加内存。

在OLAP程序中,由于其本身的工作原理,该比率大大减少。不管怎样,更多的内存总是能提高SQLServer的性能。

SQL Server General: User Connections

既然sqlserver的使用人数会影响它的性能,你就需要专注于sqlserver的General Statistics Object: User Connections计数器。它显示sqlserver目前连接的数量,而不是用户数。
如果该计数器超过255,那么你需要将sqlserver的"Maximum Worker Threads" 的配置值设置得比缺省值255高。如果连接的数量超过可用的线程数,那么sqlserver将共享线程,这样会影响性能。"Maximum Worker Threads"需要设置得比你服务器曾经达到的最大连接数更高。
参考技术A 打开sql server studio management
打开"工具"-"sql server profiler"
点击连接
点击运行
可以看到捕捉到的一些访问数据库的事件,其中有读写,点用cpu,持续时间等信息可以参考
点击某个事件,可以查看具体执行了什么sql脚本,进一步分析相关逻辑
参考技术B 硬件性能瓶颈 内存 内存对SQL Server性能的影响胜过任何其他硬件。因此,对SQL Server系统的内存使用情况进行定期监视以确保内存的可用百分比高于20%是很有必要的。如果用户遭遇性能问题,同时可用内存百分比低于20%,那么此问题一定是内存分配不足导致的。这要求技术人员密切关注显示平均页面预期寿命的性能计数器,并确保平均页面预期寿命总是高于300秒(5分钟)。一旦放生少于此标准的情况,就说明要么是糟糕的索引设计导致了磁盘输入/输出(I/O)的增加,要么就是对内存的利用效率很低,或者是实际的内存不足。技术人员需要监视SQL Server系统上的分页率,并确保它们常规为1000页每秒。检查PerfMon object MSSQL Buffer Manager(性能监视对象MSSQL缓冲管理器)和Memory Performance Counters(内存性能计数器)。 同样,还要监视计数器,即PerfMon object SQL Server Memory Manager Counters中的Memory Grants Pending。此计数器显示的是每秒钟等待工作负载分配的进程总数。一般来讲,小型OLTP事务不需要大内存分配。对一个OLTP事务来说,任何大于零的内存分配都说明SQL Server系统存在内存不足。 解决内存瓶颈的途径之一是找出内存高耗进程,这可以确认诸如内存泄漏之类潜在的应用程序问题。你还可以通过检查查询优化性能以消耗更少的内存。另外一种方法就是给SQL Server增加更多的物理内存来扩展升级SQL Server环境。扩展升级通常是解决任何与内存相关的性能瓶颈的济世良方。 磁盘I/O使用 对比其他的硬件资源,存储输入/输出通常是SQL Server中最慢的系统资源。因此,监视存储系统以确定存储是否成为一个影响性能的瓶颈是十分重要的。如果是,那么下个步骤就是要调查是否能够优化存储系统的设计和配置以获得扩展性和高性能。检查Average Disk Sec/Read(秒均磁盘读取)和Average Disk Sec/Write (秒均磁盘写入)的PerfMon磁盘计数器。确保OLTP系统和更高决策支持系统的一个读或写的时间在理想情况下少于12毫秒。 与内存一样,解决磁盘I/O性能瓶颈最简单的方法就是扩展升级SQL Server环境,即用更快的磁盘替换现有磁盘,可以更好地应对I/O负载和分配I/O负载到多个轴上。同时还要定期整理磁盘数据。 CPU CPU性能瓶颈的发生有诸多原因。它们包括非理想的查询计划,应用程序或是数据库的设计缺陷,糟糕的SQL Server配置或是硬件资源的不足。技术人员可以对Processor Queue Length(处理器队列长度)的PerfMon operation system CPU(PerfMon操作系统CPU)和处理器计数器进行检查以验证正在等待CPU周期的线程数在八个以内。如果这一数字大于12,那就意味着CPU产生了性能问题。 在确认了某个CPU瓶颈之后,便可以使用sys.dm_os_wait_stats动态管理视图(DMV)来确认对CPU来说排前十的性能最差的查询,如下所示。 SELECT TOP 10 (a.total_worker_time / a.execution_count) AS [Avg_CPU_Time] ,Convert(VARCHAR, Last_Execution_Time) AS [Last_Execution_Time] ,Total_Physical_Reads ,SUBSTRING(b.TEXT, a.statement_start_offset / 2, ( CASE WHEN a.statement_end_offset = - 1 THEN len(convert(NVARCHAR(max), b.TEXT)) * 2 ELSE a.statement_end_offset END - a.statement_start_offset ) / 2) AS [Query_Text] ,dbname = Upper(db_name(b.dbid)) ,b.objectid AS 'Object_ID', B.* FROM sys.dm_exec_query_stats a CROSS APPLY sys.dm_exec_sql_text(a.sql_handle) AS b ORDER BY [Avg_CPU_Time] DESC 接着,你可以对这些查询和底层索引进行调优以解决CPU瓶颈。同时,对你的SQL Server进行配置以使用所有可用的CPU机器。你还可以通过添加额外的CPU或用更快的CPU升级一个新的服务器来扩展你的SQL Server系统。 数据库设计问题 高度规范化的数据库 糟糕的数据库设计会导致数据库性能不足。例如,高度规范化的数据库是与复杂关系连接相关联的。这就造成了长时间执行查询对诸如CPU,内存,和磁盘I/O之类系统资源的浪费。显然,一个高度规范化的数据库会让SQL Server和数据库性能显著降低。编写高效查询的一般规则就是如果一个操作需要五个或者更多的表连接,就要对数据库进行重新设计。 重复和未使用的索引 索引是解决很多性能问题的杀手锏,但是在频繁更新的表上拥有过多的索引会招致额外开销,因为SQL Server在执行插入/更新/删除操作期间会执行额外的工作以保持索引处于最新状态。这就意味着在更新基于索引数量和复杂度的表中数据的时候,SQL Server数据库引擎需要更多的时间。同时,索引维护也会增加CPU和I/O使用,这会在一个密集写入的系统中对性能造成损害。因为任何重复和冗余的索引对系统资源来说毫无意义,所以需要将它们移除。本回答被提问者采纳

SQLSERVER如何在数据库里根据某个字段,查出该表名字

SQLSERVER如何在数据库里根据某个字段,查出该表名字

SQLSERVER中 根据字段名称查找所在表格名称的方法:

一、语句的思路:

SQLSERVER的两个系统表:1、保存表格字段属性的:syscolumns 2、保存数据库对象属性的:sysobjects ,它们都包含对象ID字段,所以可以使用两个表格的ID字段,作为表格联合检索依据来进行检索。

二、相关系统表格简介:

1、syscolumns :每个表和视图中的每列在表中占一行,存储过程中的每个参数在表中也占一行。

2、sysobjects :在数据库内创建的每个对象(约束、默认值、日志、规则、存储过程等)在表中占一行。

三、根据字段名称检索所在表格名称

select syscolumns.name,sysobjects.name --syscolumns.name:字段名、sysobjects.name:表格名称
from syscolumns,sysobjects 
where syscolumns.name = \'gc_lczt\' and syscolumns.id = sysobjects.id;--以字段名称\'gc_lczt\'为例,使用字段ID关联两个表格

四、检索结果如图:

五、注意:因为不同表格可能有相同的字段名称,所以结果有可能不只一条。

参考技术A 你可以用工具把数据库表定义导出来,导出的是excel文件,再在这个excel文件里检索这个字段名称 参考技术B SELECT t2.name 
FROM syscolumns t1,sysobjects t2
WHERE t1.id=t2.id
and t1.NAME='字段名'

以上是关于怎样查出SQLServer的性能瓶颈的主要内容,如果未能解决你的问题,请参考以下文章

怎样查出SQLServer的性能瓶颈

怎样查出SQLServer的性能瓶颈

怎样查出SQLServer的性能瓶颈

SqlServer性能瓶颈分析

如何防止聚合物1的性能瓶颈?

如何查看 mysql 性能瓶颈