一.概述

  在前几章介绍过 sql server
性能调优资源等待之PAGEIOLATCH,PAGEIOLATCH是出现在sql
server要和磁盘作交互的时候,所以加个IO两个字。这次来介绍PAGELATCH。PAGELATCH类型是sqlserver在缓冲池里的数据页面上经常加的另一类latch锁。

  既然缓冲池里的数据页面与PAGELATCH有关系,那先来介绍数据页面。

  1. 数据页面

  数据页面在”sql server 索引阐述系列二
索引存储结构”中有详细介绍,这里讲与PAGELATCH有关的知识点。
一个页面包含页头,数据存储,页尾偏移量。
在页头里包含了页面属性,页面编号,记录了当前页面空闲的起始位置,当sqlserver
在要插入的时候,就能够很快地找到插入的位置,而页尾的偏移量记录了每一条数据行所有页中的位置,当需要查找页中数据时,通过页尾的偏移量很快能定位。

  当数据行发生变化时, sql
server不但要去修改数据本身,还要维护页中数据行与偏移量的关系。

       2.  PAGELATCH

  讲了这么多关于数据页面, 现在来理清一下关系,
lock锁是保证数据页中数据的逻辑关系,PAGEIOLATCH的latch锁是保证数据页与磁盘进行存储的关系, 
PAGELATCH的latch锁是保证数据页中数据行与页尾的偏移量的关系。当然这种区别介绍是为了更好的去理解它们之间的关系,PAGELATCH作用并不只是这点,
它还会维护系统页面如SGAM,PFS,GAM页面等。

  3. HotPage现象

  当我们为一个表创建主键自增ID时, 那么sql
server将按照ID字段的值顺序进行存储,在大并发下,为了保证ID值按顺序存放在数据页中,这时PAGELATCH就会latch锁住数据页面里的存储结构,
使ID值排队保持先后顺序 。测试Hotpage现象可以是程序后端并发插入或使用
SQLIOSim工具来并发测试。

      下面来看一个简单的图:当前表里有一个page 100的页面,
该页中已有二行数据(rid1和rid2) 分别对应着页尾的偏移量1和2。
这时有二个插入任务,同时插入到page100页,假设第一个任务申请到了ex_latch锁,第二个任务就会等待,使数据行和偏移量对一
一对应。

  威尼斯城真人赌钱网站 1

  由于数据页的改动都是在内存中完成的,所以每次修改时间都应该非常短,几乎可以忽略。如果该资源成为了sql
server等待的瓶颈有以下几种情况:

  (1) sql server 没有的明显的内存和磁盘瓶颈。

       (2) 大量的并发集中在表里的一个数据页上叫hotpage

       (3) tempdb
临时表也可以会成为瓶颈,通常可以通过增加tempdb文件来缓解。
具体查看Tempdb怎么会成为性能瓶颈?。

     4. 查看PAGELATCH现象

       4.1 通过sys.dm_exec_query_stats来查看实例级别的等待

select wait_type,
waiting_tasks_count,
wait_time_ms ,
max_wait_time_ms,
signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_type like 'pagelatch%' 
order by  wait_time_ms desc

  威尼斯城真人赌钱网站 2

         在实例级别中等待次数最多的是PAGELATCH_EX的latch 排它锁,
平均每次耗时90毫秒,这个平均值应该是不会有性能问题。

       4.2 能过sys.dm_exec_requests 来实时查看sql语句级,
可以采用不定时监听能过session_id来获取sql
语句所对应的表,以及等待的数据页类型 。

SELECT * FROM sys.dm_exec_requests  WHERE wait_type LIKE 'pagelatch%'

   5.  解决思路

  (1)  通过设计表结构,使hotpage现象由单面的并发访问,分散到多个页面。

  (2)  如果是在identity字段上有瓶颈,
可以创建多个分区,因为每个分区都有自己的存储单位,这样hot
单页现象就分散了。

 

一.概念

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

  1.  下面根据总耗时排序来观察,这里分析的等待的wait_type 不包括以下

SELECT  wait_type ,
        waiting_tasks_count,
        signal_wait_time_ms ,
        wait_time_ms,
        max_wait_time_ms
FROM    sys.dm_os_wait_stats
WHERE   wait_time_ms > 0
        AND wait_type NOT IN ( 'CLR_SEMAPHORE', 'CLR_AUTO_EVENT',
                               'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE',
                               'SLEEP_TASK', 'SLEEP_SYSTEMTASK',
                               'SQLTRACE_BUFFER_FLUSH', 'WAITFOR',
                               'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE',
                               'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT',
                               'BROKER_TO_FLUSH', 'BROKER_TASK_STOP',
                               'CLR_MANUAL_EVENT',
                               'DISPATCHER_QUEUE_SEMAPHORE',
                               'FT_IFTS_SCHEDULER_IDLE_WAIT',
                               'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN',
                               'SQLTRACE_INCREMENTAL_FLUSH_SLEEP' )
ORDER BY signal_wait_time_ms DESC

  下图排名在前的资源等待是重点需要去关注分析:

威尼斯城真人赌钱网站 3

  通过上面的查询就能找到PAGEIOLATCH_x类型的资源等待,由于是实例级别的统计,想要获得有意义数据,就需要查看感兴趣的时间间隔。如果要间隔来分析,不需要重启服务,可通过以下命令来重置

DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);  

  wait_type:等待类型
  waiting_tasks_count:该等待类型的等待数
  wait_time_ms:该等待类型的总等待时间(包括一个进程悬挂状态(Suspend)和可运行状态(Runnable)花费的总时间)
  max_wait_time_ms:该等待类型的最长等待时间
  signal_wait_time_ms:正在等待的线程从收到信号通知到其开始运行之间的时差(一个进程可运行状态(Runnable)花费的总时间)
  io等待时间==wait_time_ms – signal_wait_time_ms

转载自:

等待分类与解决基本流程:

二. PAGEIOLATCH_x

  2.1 什么是Latch

    在sql
server里latch是轻量级锁,不同于lock。latch是用来同步sqlserver的内部对象(同步资源访问),而lock是用来对于用户对象包括(表,行,索引等)进行同步,简单概括:Latch用来保护SQL server内部的一些资源(如page)的物理访问,可以认为是一个同步对象。而lock则强调逻辑访问。比如一个table,就是个逻辑上的概念。关于lock锁这块在”sql server
锁与事务拨云见日”中有详细说明。

  2.2 什么是PageIOLatch 

  当查询的数据页如果在Buffer
pool里找到了,则没有任何等待。否则就会发出一个异步io操作,将页面读入到buffer
pool,没做完之前,连接会保持在PageIoLatch_ex(写)或PageIoLatch_sh(读)的等待状态,是Buffer
pool与磁盘之间的等待。它反映了查询磁盘i/o读写的等待时间。
  当sql
server将数据页面从数据文件里读入内存时,为了防止其他用户对内存里的同一个数据页面进行访问,sql
server会在内存的数据页同上加一个排它锁latch,而当任务要读取缓存在内存里的页面时,会申请一个共享锁,像是lock一样,latch也会出现阻塞,根据不同的等待资源,等待状态有如下:PAGEIOLATCH_DT,PAGEIOLATCH_EX,PAGEIOLATCH_KP,PAGEIOLATCH_SH,PAGEIOLATCH_UP。重点关注PAGEIOLATCH_EX(写入)和PAGEIOLATCH_SH(读取)二种等待。

2.1  AGEIOLATCH流程图

  有时我们分析当前活动用户状态下时,一个有趣的现象是,有时候你发现某个SPID被自己阻塞住了(通过sys.sysprocesses了查看)
为什么会自己等待自己呢? 这个得从SQL server读取页的过程说起。SQL
server从磁盘读取一个page的过程如下:

威尼斯城真人赌钱网站 4

威尼斯城真人赌钱网站 5

  (1):由一个用户请求,获取扫描X表,由Worker x去执行。

  (2):在扫描过程中找到了它需要的数据页同1:100。

  (3):发面页面1:100并不在内存中的数据缓存里。

  (4):sql
server在缓冲池里找到一个可以存放的页面空间,在上面加EX的LATCH锁,防止数据从磁盘里读出来之前,别人也来读取或修改这个页面。

  (5):worker x发起一个异步i/o请求,要求从数据文件里读出页面1:100。

  (6):由于是异步i/o(可以理解为一个task子线程),worker
x可以接着做它下面要做的事情,就是读出内存中的页面1:100,读取的动作需要申请一个sh的latch。

  (7):由于worker
x之前申请了一个EX的LATCH锁还没有释放,所以这个sh的latch将被阻塞住,worker
x被自己阻塞住了,等待的资源就是PAGEIOLATCH_SH。

  最后当异步i/o结束后,系统会通知worker
x,你要的数据已经写入内存了。接着EX的LATCH锁释放,worker
x申请得到了sh的latch锁。

总结:首先说worker是一个执行单元,下面有多个task关联Worker上,
task是运行的最小任务单元,可以这么理解worker产生了第一个x的task任务,再第5步发起一个异步i/o请求是第二个task任务。二个task属于一个worker,worker
x被自己阻塞住了。 关于任务调度了解查看sql server
任务调度与CPU。

 2.2 具体分析

  通过上面了解到如果磁盘的速度不能满足sql
server的需要,它就会成为一个瓶颈,通常PAGEIOLATCH_SH
从磁盘读数据到内存,如果内存不够大,当有内存压力时候它会释放掉缓存数据,数据页就不会在内存的数据缓存里,这样内存问题就导致了磁盘的瓶颈。PAGEIOLATCH_EX是写入数据,这一般是磁盘的写入速度明显跟不上,与内存没有直接关系。

下面是查询PAGEIOLATCH_x的资源等待时间:

select wait_type,
waiting_tasks_count,
wait_time_ms ,
max_wait_time_ms,
signal_wait_time_ms
from sys.dm_os_wait_stats
where wait_type like 'PAGEIOLATCH%' 
order by wait_type

下面是查询出来的等待信息:

PageIOLatch_SH
总等待时间是(7166603.0-15891)/1000.0/60.0=119.17分钟,平均耗时是(7166603.0-15891)/297813.0=24.01毫秒,最大等待时间是3159秒。

PageIOLatch_EX 总等待时间是(3002776.0-5727)/1000.0/60.0=49.95分钟,   
平均耗时是(3002776.0-5727)/317143.0=9.45毫秒,最大等待时间是1915秒。

威尼斯城真人赌钱网站 6

关于I/O磁盘 sys.dm_io_virtual_file_stats 函数也做个参考

SELECT  
       MAX(io_stall_read_ms) AS read_ms,
         MAX(num_of_reads) AS read_count,
       MAX(io_stall_read_ms) / MAX(num_of_reads) AS 'Avg Read ms',
         MAX(io_stall_write_ms) AS write_ms,
        MAX(num_of_writes) AS write_count,
         MAX(io_stall_write_ms) /  MAX(num_of_writes) AS 'Avg Write ms'
FROM    sys.dm_io_virtual_file_stats(null, null)
WHERE   num_of_reads > 0 AND num_of_writes > 0 

威尼斯城真人赌钱网站 7

  总结:PageIOLatch_EX(写入)跟磁盘的写入速度有关系。PageIOLatch_SH(读取)跟内存中的数据缓存有关系。通过上面的sql统计查询,从等待的时间上看,并没有清晰的评估磁盘性能的标准,但可以做评估基准数据,定期重置,做性能分析。要确定磁盘的压力,还需要从windows系统性能监视器方面来分析。
关于内存原理查看”sql server
内存初探“磁盘查看”sql
server I/O硬盘交互” 。

 

 

通过DMV查看当时SQL SERVER所有任务的状态(sleeping、runnable或running)

威尼斯城真人赌钱网站 8

2005、2008提供了以下三个视图工详细查询:

 

DMV

用处

Sys.dm_exec_requests

返回有关在SQL Server中执行的每个请求的信息,包括当前的等待状态

Sys.dm_exec_sessions

对于每个通过身份验证的会话都返回相应的一行。此时图是服务器范围的视图。此视图首先可以查到服务器负荷

Sys.dm_exec_connections

返回与SQL Server 实例建立的连接有关的信息以及每个连接的详细信息

步骤1.定位问题

系统等待往往能直观的反映出系统问题。通过一些常见的等待类型,同样可以找到系统瓶颈,结合性能计数器往往定位更准确。

如:系统中存在大量IO类等待,那么可能表示你的磁盘或内存是语句运行缓慢的原因,也是系统的瓶颈所在。

 

常见的等待类型

      • CXPACKET
        : 当尝试同步查询处理器交换迭代器时出现。如果针对该等待类型的争用成为问题时,可以考虑降低并行度。
      • IO_COMPLETION :   在等待 I/O
        操作完成时出现。通常,该等待类型表示非数据页 I/O。
      • PAGEIOLATCH_ : 在任务等待 I/O 请求中缓冲区的闩锁时发生。
      • PAGELATCH_ : 在任务等待不处于 I/O
        请求中的缓冲区闩锁时发生。
      • LCK_ :等待闩锁时出现。
      • ASYNC_NETWORK_IO :
        当任务被阻止在网络之后时出现在网络写入中。验证客户端是否正在处理来自服务器的数据。 
      • OLEDB :当 SQL Server 调用 Microsoft SQL Native Client OLE
        DB 访问接口时出现。该等待类型不用于同步。而是用于指示调用
        OLE DB 访问接口的持续时间 
      • WRITELOG
        :等待日志刷新完成时出现。导致日志刷新的常见操作是检查点和事务提交。 

 

 

 

 

 

Sys.sysprocesses是为了向后兼容,所以建议使用以上3个DMV。

步骤2.分析

问题与解决

 

CXPACKET 

CXPACKET
这个等待可以简单理解成CPU相关的等待,主要发生在并行计划中。由于并行计划需要协同多个task同时工作,那么“协同”分配等等操作的时候出现的就是这个等待。

如果 CXPACKET
在你系统中是最为严重的等待,这时候一般的表现是你的CPU很高。

威尼斯城真人赌钱网站 9

 

解决方案:适当调整并行度

 

 

威尼斯城真人赌钱网站 10

 

 

 一般建议系统如果超过32个CPU
那么设置成8或者4,如果系统中都是特别短小且频繁的语句建议设置成1(取消语句并行,要慎重真的符合你的场景才好)

    并行开销的阀值,主要控制SQL优化器何时选用并行计划,建议默认值,此值设置的越小优化器越容易选择并行计划。

    并行度的设置是针对实例级别的设置(2016中可以对单独数据库设置)

另外还有一个DMV:sys.dm_os_wait_stats可以返回从SQL
Server启动以来所有等待状态的等待数和等待时间。是个累积值。

IO类

  IO_COMPLETION和PAGEIOLATCH_和WRITELOG 这三个等待是最为常见的和磁盘相关的等待。他们的不同点是 IO_COMPLETION
 主要针对非数据页
I/O ,如备份操作所需的磁盘交互。PAGEIOLATCH_
是数据页相关的磁盘等待。WRITELOG 是日志相关。

  如果系统中这三个等待是主要等待,说明系统磁盘存在压力或已经成为瓶颈。

  这里用PAGEIOLATCH_ 为例进行说明

  PAGEIOLATCH_的 官方解释:在任务等待 I/O
请求中缓冲区的闩锁时发生。闩锁请求处于“XX”模式。长时间的等待可能指示磁盘子系统出现问题。

    PAGEIOLATCH_的相关等待:

 

PAGEIOLATCH_DT

在任务等待 I/O 请求中缓冲区的闩锁时发生。闩锁请求处于“破坏”模式。长时间的等待可能指示磁盘子系统出现问题。

PAGEIOLATCH_EX

在任务等待 I/O 请求中缓冲区的闩锁时发生。闩锁请求处于“独占”模式。长时间的等待可能指示磁盘子系统出现问题。

PAGEIOLATCH_KP

在任务等待 I/O 请求中缓冲区的闩锁时发生。闩锁请求处于“保持”模式。长时间的等待可能指示磁盘子系统出现问题。

PAGEIOLATCH_NL

仅供内部使用。

PAGEIOLATCH_SH

在任务等待 I/O 请求中缓冲区的闩锁时发生。闩锁请求处于“共享”模式。长时间的等待可能指示磁盘子系统出现问题。

PAGEIOLATCH_UP

在任务等待 I/O 请求中缓冲区的闩锁时发生。闩锁请求处于“更新”模式。长时间的等待可能指示磁盘子系统出现问题。

   
 怎么来理解这个官方解释呢? 首先明确一点,操作系统CPU操作的任何数据都是从内存中读取的,也就是说读取数据要经过这样的一条路:

这里的PAGEIOLATCH_ 就是发生在, 磁盘中 ——>  内存中 

  以读取为例:要读取的数据页不在内存中,所以就要去磁盘上读取这部分数据页,去磁盘读取数据的时候就会产生PAGEIOLATCH_的相关等待,如果磁盘压力大,长时间不能反回数据,那么PAGEIOLATCH_的时间也会越长,语句执行的时间也会越长。

威尼斯城真人赌钱网站 11

 

注 :
当你的系统出现大量的 PAGEIOLATCH_
类等待,说明你磁盘可能存在压力(磁盘速度不能满足当前业务需求)或你的内存不够用,不能缓存业务常用数据而经常要与磁盘交互!

 

 

WRITELOG
 和磁盘有关的另一个等待状态,正在等待写日志记录,意味着写入速度也明显跟不上。而速度跟不上一般有两种情况:磁盘压力大响应时间长或真的速度不能满足读写需要。

 

 

PAGELATCH_ 

PAGELATCH_和 上面讲述的PAGEIOLATCH_
 看似很像,但中间少了 IO 这个关键。

磁盘中——>内存中 的等待为PAGEIOLATCH_
  而 内存中——> 最终使用 的等待为 PAGELATCH_

 当数据已经在内存中的时候SQL SERVER
想要使用这个数据页就要给这个数据页加锁。

当等待中出现很多PAGELATCH_
等待,那么可以说明:

  1. SQL Server没有明显的内存和磁盘瓶颈。
  2. 应用程序发来大量的并发语句在修改同一张表格里的记录,而表格架构设计以及用户业务逻辑使得这些修改都集中在同一个页面,或者数量不多的几个页面上。这些页面有的时候也被称为Hot
    Page。这样的瓶颈通常只会发生在并发用户比较多的、典型的OLTP系统上。
  3. 这种瓶颈是无法通过提高硬件配置解决的,只有通过修改表格设计或者业务逻辑,让修改分散到尽可能多的页面上,才能提高并发性能。

 

TempDB造成的 PAGELATCH_(其实也是一种Hot
Page),这里简单的看一个例子:

威尼斯城真人赌钱网站 12

 

    系统中存在大量的 PAGELATCH_UP等待那么是什么成为了Hot
Page 呢?为什么说和TempDB有关呢?

     威尼斯城真人赌钱网站 13

 

     等待资源 “2:X:X:
”开头是TempDB,系统中存在大量且高并发的语句使用临时表和表变量,所以引起TEMPDB瓶颈。请参见:TempDB的诊断和优化。

 

 威尼斯城真人赌钱网站 14

LCK_ 

 LCK_类型中的所有很多,如果这种等待在系统中大量存在,可以说明,系统语句间的相互阻塞严重。如大家都知道的当你update一张表的时候,你的select会被阻塞直到update完成。这里就不过多介绍场景了,主要看一下解决此类等待的主要方法:

    1. 语句优化,让语句执行的更快,减少等待时间。
    2. 采用批量操作代替循环方式。
    3. 尽量减少事务的长度。
    4. 尝试降低事务隔离级别。
    5. 上述都不能缓解…请选用读写分离。

 

 LCK_类型中包含:(这里不做详细解读了)

LCK_M_RIn_NL

当某任务正在等待获取当前键值上的 NULL 锁以及当前键和上一个键之间的插入范围锁时出现。键上的 NULL 锁是指立即释放的锁。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_RIn_S

当某任务正在等待获取当前键值上的共享锁以及当前键和上一个键之间的插入范围锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_RIn_U

任务正在等待获取当前键值上的更新锁以及当前键和上一个键之间的插入范围锁。有关锁兼容性矩阵,请参阅sys.dm_tran_locks

LCK_M_RIn_X

当某任务正在等待获取当前键值上的排他锁以及当前键和上一个键之间的插入范围锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_RS_S

当某任务正在等待获取当前键值上的共享锁以及当前键和上一个键之间的共享范围锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_RS_U

当某任务正在等待获取当前键值上的更新锁以及当前键和上一个键之间的更新范围锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_RX_S

当某任务正在等待获取当前键值上的共享锁以及当前键和上一个键之间的排他范围锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_RX_U

当某任务正在等待获取当前键值上的更新锁以及当前键和上一个键之间的排他范围锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_RX_X

当某任务正在等待获取当前键值上的排他锁以及当前键和上一个键之间的排他范围锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_S

当某任务正在等待获取共享锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_SCH_M

当某任务正在等待获取架构修改锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_SCH_S

当某任务正在等待获取架构共享锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_SIU

当某任务正在等待获取共享意向更新锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_SIX

当某任务正在等待获取共享意向排他锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_U

当某任务正在等待获取更新锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_UIX

当某任务正在等待获取更新意向排他锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

LCK_M_X

当某任务正在等待获取排他锁时出现。有关锁兼容性矩阵,请参阅 sys.dm_tran_locks

1、  LCK_XX类型:

ASYNC_NETWORK_IO 

  此等待状态出现在SQLServer已经把数据准备好,但是网络没有足够的发送速度跟上,所以SQLServer的数据没地方存放。

  1. 出现这种情况一般不是数据库的问题,调整数据库配置不会有大的帮助。
  2. 网络层的瓶颈当然是一个可能的原因:对此要考虑是否真有必要返回那么多数据?
  3. 应用程序端的性能问题,也会导致SQLServer里的ASYNC_NETWORK_IO等待。如果见到了这个类型的等待,就要检查应用程序的健康状况,也要检查应用是否有必要想SQLServer申请这么大的结果集。
  4. 程序返回结果集的方式 。

如果SQL Server经常有阻塞发生,会经常看到以“LCK_”开头的等待状态:

等待状态

说明

LCK_M_BU

正在等待获取大容量更新锁(BU)

LCK_M_IS

等待获取意向共享锁(IS)

LCK_M_IU

等待获取意向更新锁(IU)

LCK_M_IX

等待意向排它锁(IX)

LCK_M_RIn_NL

等待获取当前键值上的NULL锁以及当前剪和上一个键之间的插入范围锁

LCK_M_RIn_S

等待获取当前键值上的共享锁以及当前键和上一个键之间的插入范围锁

LCK_M_RIn_U

等待获取当前键值上的更新锁以及当前键和上一个键之间的插入范围锁

LCK_M_RIn_X

等待获取当前键值上的排他锁以及当前键和上一个键之间的插入范围锁

LCK_M_RS_S

等待获取当前键值上的共享锁以及当前键和上一个键之间的共享范围锁

LCK_M_RS_U

等待获取当前键值上的更新锁以及当前键和上一个键之间的共享范围锁

LCK_M_RX_S

等待获取当前键值上的共享锁以及当前键和上一个键之间的排他范围锁

LCK_M_RX_S

等待获取当前键值上的共享锁以及当前键和上一个键之间的排他范围锁

LCK_M_RX_U

等待获取当前键值上的更新锁以及当前键和上一个键之间的排他范围锁

LCK_M_RX_X

等待获取当前键值上的排他锁以及当前键和上一个键之间的排他范围锁

LCK_M_S

等待获取共享锁

LCK_M_SCH_M

等待架构修改锁

LCK_M_SCH_S

等待获取架构共享锁

LCK_M_SIU

等待共享意向更新锁

LCK_M_SIX

等待获取共享意向排他锁

LCK_M_U

等待更新锁

LCK_M_UIX

等待更新意向排他锁

LCK_M_X

等待排他锁

2、  PAGEIOLATCH_X与WRITELOG:

在缓存池中的数据页面,为了同步多用户并发,SQL
Server会对内存的页面加锁。不同的是,加的是latch(轻量级的锁),而不是lock。

如果发生PAGEIOLATCH类型的等待时,SQL
Server一定是在等待某个I/O动作的完成。如果经常出现这类等待,说明磁盘速度不能满足要求,已经成为SQL
Server的瓶颈。

PAGEIOLATCH_X最常见的分两大类:PAGEIOLATCH_SH和PAGEIOLATCH_EX,PAGEIOLATCH_SH:经常发生在用户正想要访问一个数据页面,而同时SQL
Server却要把页面从磁盘读往内存。说明内存不够大,触发了SQL
Server做了很多读取页面的工作,引发了磁盘读的瓶颈。此时是内存有瓶颈。磁盘只是内存压力的副产品。

PAGEIOLATCH_EX:经常发生在用户对数据页面做了修改。SQL
Server要向磁盘回写的时候。意味着写的速度跟不上。这和内存没直接关系。

WRITELOG:和磁盘有关的另一个等待状态,正在等待写日志记录,意味着写入速度也明显跟不上。

3、 
PAGELATCH_X:SQLServer为了解决在插入数据时,到了物理层的插入冲突,所以引入了另一类页面上的latch:PAGELATCH,当一个任务要修改页面时,它必须先申请一个EX的latch。只有得到这个,才能修改页面的内容。由于数据页的修改都是在内存中完成,所以时间应该非常短,可以忽略不计。而PAGELATCH只是在修改过程中才出现,所以生存周期应该很短,如果出现了,说明:1、SQLServer没有明显的内存和磁盘瓶颈。2、应用程序发来大量的并发语句在修改同一张表。而设计及用户业务逻辑使得这些修改都集中在同一个页面,或者数量不多的几个页面,成为Hot
Page,通常在OLTP系统上出现比较多。3、这种瓶颈无法通过提高硬件配置解决,只能通过修改表设计或者业务逻辑,让修改分散,提高并发性。

对于Hot page的缓解方法:

相关文章