SQL 性能调优中可参考的几类Lock Wait

在我们的系统出现性能问题时,往往避不开调查各种类型 Lock Wait,如Row Lock Wait、Page Lock Wait、Page IO Latch Wait等。从中找出可能的异常等待,为性能优化做一定的参考 。具体的查询语句分享如下,

/*******************************************************************************************

Row Lock Wait

*******************************************************************************************/

SELECT ‘[‘ + DB_NAME(ddios.[database_id]) + ‘].[‘ + su.[name] + ‘].[‘

+ o.[name] + ‘]‘ AS [statement] ,
i.[name] AS ‘index_name‘ ,
ddios.[partition_number] ,
ddios.[row_lock_count] ,
ddios.[row_lock_wait_count] ,
CAST (100.0 * ddios.[row_lock_wait_count]
/ ( ddios.[row_lock_count] ) AS DECIMAL(5, 2)) AS [%_times_blocked] ,
ddios.[row_lock_wait_in_ms] ,
CAST (1.0 * ddios.[row_lock_wait_in_ms]
/ ddios.[row_lock_wait_count] AS DECIMAL(15, 2))
AS [avg_row_lock_wait_in_ms]
FROM sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ddios
INNER JOIN sys.indexes i ON ddios.[object_id] = i.[object_id]
AND i.[index_id] = ddios.[index_id]
INNER JOIN sys.objects o ON ddios.[object_id] = o.[object_id]
INNER JOIN sys.sysusers su ON o.[schema_id] = su.[UID]
WHERE ddios.row_lock_wait_count > 0
AND OBJECTPROPERTY(ddios.[object_id], ‘IsUserTable‘) = 1 and OBJECT_NAME(ddios.[object_id]) like ‘POS_TRANSMST‘
AND i.[index_id] > 0
ORDER BY ddios.[row_lock_wait_count] DESC ,
su.[name] ,
o.[name] ,
i.[name]

/*******************************************************************************************

--Page Lock Wait

*******************************************************************************************/

 SELECT OBJECT_NAME(ddios.object_id, ddios.database_id) AS object_name ,

i.name AS index_name ,

ddios.object_id,
ddios.partition_number ,
ddios.page_lock_wait_count ,
ddios.page_lock_wait_in_ms ,
CASE WHEN DDMID.database_id IS NULL THEN ‘N‘
ELSE ‘Y‘
END AS missing_index_identified
FROM sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ddios
INNER JOIN sys.indexes i ON ddios.object_id = i.object_id
AND ddios.index_id = i.index_id
LEFT OUTER JOIN ( SELECT DISTINCT
database_id ,
object_id
FROM sys.dm_db_missing_index_details
) AS DDMID ON DDMID.database_id = ddios.database_id
AND DDMID.object_id = ddios.object_id
WHERE ddios.page_lock_wait_in_ms > 0 and OBJECT_NAME(ddios.[object_id]) like ‘POS_TRANSMST‘
ORDER BY ddios.page_lock_wait_count DESC ;

/*******************************************************************************************

--Page IO Latch Wait

*******************************************************************************************/
SELECT ‘[‘ + DB_NAME() + ‘].[‘ + OBJECT_SCHEMA_NAME(ddios.[object_id])
+ ‘].[‘ + OBJECT_NAME(ddios.[object_id]) + ‘]‘ AS [object_name] ,
i.[name] AS index_name ,
ddios.page_io_latch_wait_count ,
ddios.page_io_latch_wait_in_ms ,
( ddios.page_io_latch_wait_in_ms / ddios.page_io_latch_wait_count )
AS avg_page_io_latch_wait_in_ms
FROM sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ddios
INNER JOIN sys.indexes i ON ddios.[object_id] = i.[object_id]
AND i.index_id = ddios.index_id
WHERE ddios.page_io_latch_wait_count > 0 and OBJECT_NAME(ddios.[object_id]) like ‘POS_TRANSMST‘
AND OBJECTPROPERTY(i.object_id, ‘IsUserTable‘) = 1
ORDER BY ddios.page_io_latch_wait_count DESC ,
avg_page_io_latch_wait_in_ms DESC

/*******************************************************************************************

SameZhao

时间: 2024-10-26 18:01:56

SQL 性能调优中可参考的几类Lock Wait的相关文章

SQL性能调优

部分转自:http://www.cnblogs.com/luckybird/archive/2012/06/11/2544753.html 及http://www.cnblogs.com/kissdodog/p/3160560.html 着色部分为实际解决问题的过程 最常见的索引问题查找: 1.检查实际执行计划,使用图形化或者在执行语句前增加 set statistics profile on 检查其中操作行数/执行次数/执行时间最多的地方 2.在发现问题的地方,检查表的索引情况,注意其中Row

理解统计信息(3/6):谁创建和管理统计信息?在性能调优中,统计信息的作用。

在理解统计信息(2/6):直方图 中,我们讨论了直方图,密度,还有SQL Server如何用统计信息做基数预估(cardinality estimation).这篇文章会讨论统计信息如何被创建,还有统计信息在性能调优中的重要性. 有2类统计信息,索引统计信息和列统计信息.索引统计信息是索引创建的一部分(建立索引会自动创建索引统计信息).在where条件列被引用或查询的group by子句里包含列,列统计信息都会由SQL Server自动创建. 有数据库属性设置里,可以设置数据库是否自动创建统计信

SQL性能调优基础教材

一.数据库体系结构 1.       Oracle数据库和实例 数据库:物理操作系统文件或磁盘的集合. 实例:一组Oracle后台进程/线程以及一个共享内存区,这些内存由同一个计算机上运行的线程/进程所共享. 2.       文件 参数文件 跟踪文件 警告文件 临时文件 控制文件 重做日志文件 密码文件 3.  内存结构和进程 SGA PGA PMON SMON RECO CKPT DBWn LGWR ARCn 4.  Redo和undo Undo和redo的作用及如何协作 Undo(撤销信息

sqlserver性能调优中的逻辑读,物理读,预读是什么意思

表 'T_EPZ_INOUT_ENTRY_DETAIL'.扫描计数 1,逻辑读 4825 次,物理读 6 次,预读 19672 次.SQL SERVER 数据库引擎当遇到一个查询语句时,SQL SERVER数据库引擎会分别生成执行计划(占用CPU和内存资源),同时存储引擎读取 IAM 以生成必须要读取的磁盘地址排序列表.这使 SQL Server 得以将其 I/O 优化为大型有序读取,根据它们在磁盘上的位置按顺序完成.磁盘中取得需要取的数据(占用I/O资源,这就是预读),注 意,两个步骤是并行的

[转] SQL性能调优日常积累

http://www.cnblogs.com/llrr/p/6655977.html (1)选择最有效率的表名顺序(只在基于规则的优化器中有效) ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表 driving table)将被最先处理,在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表.如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表.

SQL 性能调优日常积累【转】

阅读目录 (1)选择最有效率的表名顺序(只在基于规则的优化器中有效) (2)WHERE子句中的连接顺序 (3)SELECT子句中避免使用 ‘ * ‘ (4)减少访问数据库的次数 (5)在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 (6)使用DECODE函数来减少处理时间 (7) 整合简单,无关联的数据库访问 (8) 删除重复记录 (9) 用TRUNCATE替代DELETE (10)尽量多使用COMM

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 语句性能调优

经常听到有做应用的朋友抱怨数据库的性能问题,比如非常低的并发,令人崩溃的响应时间,长时间的锁等待,锁升级 , 甚至是死锁,等等.在解决这些问题的过程中,DBA 经常发现应用开发人员对数据库的"误用".包括 , 返回过多不必要的数据 , 不必要和不适当加锁,对隔离级别的误用和对存储过程的误用等等.但是,面对浩如烟海的数据库知识 , 要求完全掌握 , 对应用开发人员来说也确实枯燥艰深 . 因此,笔者特别提炼对应用开发人员有帮助的 SQL 书写部分,以期望能对数据库开发人员有所帮助. &qu

Android界面性能调优手册

转载:https://androidtest.org/android-graphics-performance-pattens/#11 界面是 Android 应用中直接影响用户体验最关键的部分.如果代码实现得不好,界面容易发生卡顿且导致应用占用大量内存. 我司这类做 ROM 的公司更不一样,预装的应用一定要非常流畅,这样给客户或用户的第一感觉就是快.又卡又慢的应用体验,会影响客户或用户对产品的信心和评价,所以不可忽视. 目录 一. Android渲染知识 1.1 绘制原理 1.2 掉帧 1.3