sql server 性能调优之 逻辑内存消耗最大资源分析1 (自sqlserver服务启动以后)

原文:sql server 性能调优之 逻辑内存消耗最大资源分析1 (自sqlserver服务启动以后)

一.概述

  IO 内存是sql server最重要的资源,数据从磁盘加载到内存,再从内存中缓存,输出到应用端,在sql server 内存初探中有介绍。在明白了sqlserver内存原理后,就能更好的分析I/O开销,从而提升数据库的整体性能。 在生产环境下数据库的sqlserver服务启动后一个星期,就可以通过dmv来分析优化。在I/O分析这块可以从物理I/O和内存I/O二方面来分析, 重点分析应在内存I/O上,可能从多个维度来分析,比如从sql server服务启动以来 历史I/O开销总量分析,自执行计划编译以来执行次数总量分析,平均I/0次数分析等。

  sys.dm_exec_query_stats:返回缓存的查询计划,缓存计划中的每个查询语句在该视图中对应一行。当sql server工作负载过重时,该dmv也有可以统计不正确。如果sql server服务重启缓存的数据将会清掉。这个dmv包括了太多的信息像内存扫描数,内存空间数,cpu耗时等,具体查看msdn文档

  sys.dm_exec_sql_text:返回的 SQL 文本批处理,它是由指定sql_handle,其中的text列是查询的文本。

1.1 按照物理读的页面数排序 前50名

SELECT TOP 50
 qs.total_physical_reads,qs.execution_count,
 qs.total_physical_reads/qs.execution_count AS [avg I/O],
 qs. creation_time,
 qs.max_elapsed_time,
 qs.min_elapsed_time,
 SUBSTRING(qt.text,qs.statement_start_offset/2,
 (CASE WHEN qs.statement_end_offset=-1
 THEN LEN(CONVERT(NVARCHAR(max),qt.text))*2
 ELSE qs.statement_end_offset END -qs.statement_start_offset)/2) AS query_text,
 qt.dbid,dbname=DB_NAME(qt.dbid),
 qt.objectid,
 qs.sql_handle,
 qs.plan_handle
 from sys.dm_exec_query_stats qs
 CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
 ORDER BY qs.total_physical_reads DESC

  如下图所示:

  total_physical_reads:计划自编译后在执行期间所执行的物理读取总次数。

  execution_count :计划自上次编译以来所执行的次数。

  [avg I/O]:    平均读取的物理次数(页数)。

  creation_time:编译计划的时间。

query_text:执行计划对应的sql脚本

后面来包括所在的数据库ID:dbid,数据库名称:dbname

1.2 按照逻辑读的页面数排序 前50名

SELECT TOP 50
 qs.total_logical_reads,
 qs.execution_count,
  qs.max_elapsed_time,
 qs.min_elapsed_time,
 qs.total_logical_reads/qs.execution_count AS [AVG IO],
 SUBSTRING(qt.text,qs.statement_start_offset/2,
 (CASE WHEN qs.statement_end_offset=-1
 THEN LEN(CONVERT(NVARCHAR(max),qt.text)) *2
  ELSE qs.statement_end_offset END -qs.statement_start_offset)/2)
  AS query_text,
 qt.dbid,
 dbname=DB_NAME(qt.dbid),
 qt.objectid,
 qs.sql_handle,
  creation_time,
 qs.plan_handle
 from sys.dm_exec_query_stats qs
 CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
 ORDER BY qs.total_logical_reads DESC

如下图所示:

通过上面的逻辑内存截图来简要分析下:

  从内存扫描总量上看最多的是8311268次页扫描,自执行编译后运行t-sql脚本358次,这里的耗时是毫秒为单位包括最大耗时和最小耗时,平均I/O是23215次(页),该语句文本是一个update 修改,该表数据量大没有完全走索引(权衡后不对该语句做索引覆盖),但执行次数少,且每次执行时间是非工作时间,虽然扫描开销大,但没有影响白天客户使用。

  从执行次数是有一个43188次, 内存扫描总量排名39位。该语句虽然只有815条,但执行次数很多,如里服务器有压力可以优化,一般是该语句没有走索引。把文本拿出来如下

SELECT  Count(*)  AS TotalCount FROM [MEM_FlagshipApply]
 WITH(NOLOCK) Where (((([Status] = 2) AND ([IsDeleted] = 1)) AND ([MemType] = 0)) AND ([MEMID] <> 6))

下面两图一个是分析该语句的执行计划,sqlserver提示缺少索引,另一个是i/o统计扫描了80次。

新建索引后在来看看

 CREATE NONCLUSTERED INDEX ix_1
ON [dbo].[MEM_FlagshipApply] ([Status],[IsDeleted],[MemType],[MEMID])

  

原文地址:https://www.cnblogs.com/lonelyxmas/p/10229773.html

时间: 2024-10-07 02:03:38

sql server 性能调优之 逻辑内存消耗最大资源分析1 (自sqlserver服务启动以后)的相关文章

sql server 性能调优之 CPU消耗最大资源分析1 (自sqlserver服务启动以后)

原文:sql server 性能调优之 CPU消耗最大资源分析1 (自sqlserver服务启动以后) 一. 概述 上次在介绍性能调优中讲到了I/O的开销查看及维护,这次介绍CPU的开销及维护, 在调优方面是可以从多个维度去发现问题如I/O,CPU,  内存,锁等,不管从哪个维度去解决,都能达到调优的效果,因为sql server系统作为一个整体性,它都是紧密相连的,例如:解决了sql语句中I/O开销较多的问题,那对应的CPU开销也会减少,反之解决了CPU开销最多的,那对应I/O开销也会减少.解

SQL Server 性能调优(一)——从等待状态判断系统资源瓶颈

原文:SQL Server 性能调优(一)--从等待状态判断系统资源瓶颈 通过DMV查看当时SQL SERVER所有任务的状态(sleeping.runnable或running) 2005.2008提供了以下三个视图工详细查询: DMV 用处 Sys.dm_exec_requests 返回有关在SQL Server中执行的每个请求的信息,包括当前的等待状态 Sys.dm_exec_sessions 对于每个通过身份验证的会话都返回相应的一行.此时图是服务器范围的视图.此视图首先可以查到服务器负

sql server 性能调优之 资源等待PAGEIOLATCH

原文:sql server 性能调优之 资源等待PAGEIOLATCH 一.概念 在介绍资源等待PAGEIOLATCH之前,先来了解下从实例级别来分析的各种资源等待的dmv视图sys.dm_os_wait_stats.它是返回执行的线程所遇到的所有等待的相关信息,该视图是从一个实际级别来分析的各种等待,它包括200多种类型的等待,需要关注的包括PageIoLatch(磁盘I/O读写的等待时间),LCK_xx(锁的等待时间),WriteLog(日志写入等待),PageLatch(页上闩锁)Cxpa

SQL Server 性能调优3 之索引(Index)的维护

SQL Server 性能调优3 之索引(Index)的维护 热度1 评论 16 作者:溪溪水草 前言 前一篇的文章介绍了通过建立索引来提高数据库的查询性能,这其实只是个开始.后续如果缺少适当的维护,你先前建立的索引甚至会成为拖累,成为数据库性能的下降的帮凶. 查找碎片 消除碎片可能是索引维护最常规的任务,微软官方给出的建议是当碎片等级为 5% - 30% 之间时采用 REORGANIZE 来“重整”索引,如果达到 30% 以上则使用 REBUILD 来“重建”索引.决定采用何种手段和操作时机可

SQL Server 性能调优2 之索引(Index)的建立

前言 索引是关系数据库中最重要的对象之一,他能显著减少磁盘I/O及逻辑读取的消耗,并以此来提升 SELECT 语句的查找性能.但它是一把双刃剑,使用不当反而会影响性能:他需要额外的控件来存放这些索引信息,并且当数据更新时需要一些额外开销来保持索引的同步. 形象的来说索引就像字典里的目录,你要查找某一个字的时候可以根据它的比划/拼音先在目录中找到对应的页码范围,然后在该范围中找到这个字.如果没有这个目录(索引),你可能需要翻遍整本字典来找到要找的字. SQL Server 中的索引以 B-Tree

SQL Server 性能调优 之执行计划(Execution Plan)调优

执行计划中的三种 Join 策略 SQL Server 存在三种 Join 策略:Hash Join,Merge Join,Nested Loop Join. Hash Join:用来处理没有排过序/没有索引的数据,它在内存中把 Join 两边数据(的关联key)分别建立一个哈希表.例如有以下的查询语句,关联的两张表没有建立索引,执行计划将显示为Hash Join. SELECT sh.* FROM SalesOrdHeaderDemo AS sh JOIN SalesOrdDetailDemo

sql server 性能调优 资源等待之网络I/O

原文:sql server 性能调优 资源等待之网络I/O 一.概述 与网络I/O相关的等待的主要是ASYNC_NETWORK_IO,是指当sql server返回数据结果集给客户端的时候,会先将结果集填充到输出缓存里(ouput cache),同时网络层会开始将输出缓存里的数据打包,由客户端接收.如果客户端接收数据包慢,sql server没有地方存放新数据结果时,这时任务进入ASYNC_NETWORK_IO等待状态. 1. 从实例级别查看ASYNC_NETWORK_IO 平均耗时: 4636

SQL Server 性能调优4 之书写高效的查询

限制查询的行和列来提高性能 这条规则非常简单,这里就不细说了. 使用搜索可参数化判断(sargable conditions)来提高性能 Sargable 由 Search ARGument Able 简写而来,字面意思是搜索可参数化?还是比较晦涩哎... 总之使用Sargable判断可以帮助查询优化器更有效地利用索引,并提高采用 index seek 的可能性,我们先把所有的操作符分一下组. Sargable操作符 = > >= < <= BETWEEN LIKE (通配符必须出

SQL Server 性能调优培训引言

原文:SQL Server 性能调优培训引言 大家好,这是我在博客园写的第一篇博文,之所以要开这个博客,是我对MS SQL技术学习的一个兴趣记录. 作为计算机专业毕业的人,自己对技术的掌握总是觉得很肤浅,博而不专,到现在我才发现自己的兴趣所在,于是我通过网络找了各种MS SQL技术的相关文档,总觉得讲得比较干涩,没有一个系统性,今年3月底我无意浏览到一个网站提供免费的性能调优的半年培训(http://www.sqlpassion.at/academy/performance-tuning-tra