昨天聊了下SQLSERVER的spinlock，当时我认为spinlock是与Oracle LATCH相对应的结构，事实上碎片化的阅读会带来一些知识掌握的不准确。Oracle的LATCH是通过spin来实现锁的获取的，spin是LATCH获取轻量级锁的一种方式。而在SQLSERVER中，LATCH和spinlock被设计成两种轻量级锁，分别用于不同的场景。Oracle有shared pool，library cache等结构，可以用shared pool闩锁来保护整个共享池，共享池中新增的一些乱七八糟的数据结构可以通过shared pool闩锁以及mutex来实现串行化访问保护。
SQLSERVER中并无此类机制，因此对于一些重度访问的内存结构，设计了LATCH来保护，而其他的一些数据结构，使用spinlock。在SQLSERVER中，总是使用spinlock来保护那些访问十分快速的内存结构。
LATCH是 SQL Server 的SQL引擎用来保证内存结构的一致性的轻量级原子操作用来保护索引、数据页和内部结构等结构，例如 B 树中的非叶页。LATCH仅存在于SQL引擎内部。SQL Server 使用缓冲LATCH来保护缓冲池中的页面，并使用 I/O LATCH来保护尚未加载到缓冲池中的页面。每当向 SQL Server 缓冲池中的页面写入或读取数据时，工作线程必须首先获取该页面的缓冲LATCH。有多种缓冲LATCH类型可用于访问缓冲池中的页面，包括独占LATCH (PAGELATCH_EX) 和共享LATCH(PAGELATCH_SH)。
当 SQL Server访问一个尚未加载到缓冲池中的页面时，将通过一个异步 I/O操作将该页面加载到缓冲池中。如果 SQL Server 需要等待 I/O 子系统响应，它将根据请求类型等待独占 (PAGEIOLATCH_EX) 或共享 (PAGEIOLATCH_SH) I/O LATCH；这样做是为了防止另一个工作线程使用不兼容的LATCH将同一页面加载到缓冲池中。LATCH还用于保护对缓冲池页面以外的内部存储器结构的访问；这些被称为非缓冲LATCH。
PAGELATCH的争用在多 CPU 系统十分常见。当多个线程同时尝试获取相同内存结构的不兼容LATCH时，就会发生LATCH争用。闩锁是一种内部并发控制机制，SQL 引擎会自动确定何时使用它们。因为闩锁的行为是确定性的，数据库SCHEMA的设计，表、索引等的设计会影响闩锁争用。
非缓存页的闩锁名称为LATCH_XX，其中“_XX”后缀表示了闩锁的模式（PAGEIOLATCH/PAGELATCH也使用后缀表示模式）。SQL Server 的闩锁模式可以总结如下：
lKP——保持LATCH，确保引用的结构不会被破坏。当线程想要查看缓冲区结构时使用。因为 KP LATCH兼容除销毁（DT）之外的所有LATCH，因此 KP 闩锁被认为是“轻量级”的，这意味着使用它时对性能的影响最小。由于 KP 闩锁与 DT 闩锁不兼容，它会阻止任何其他线程破坏引用的结构。KP 闩锁将防止它引用的结构被lazywriter 进程破坏（脏块写盘并释放缓冲）；
lSH -- 共享闩锁，需要读取引用的结构（例如读取数据页）。多个线程可以同时访问共享闩锁下的资源以进行读取。
lUP——更新闩锁，与 SH（共享闩锁）和 KP 兼容，但不兼容其他闩锁，因此不允许 EX 闩锁写入引用的结构。
lEX——独占闩锁，阻止其他线程写入或读取引用的结构。一个使用示例是修改页面内容以保护页面损坏。
lDT -- 销毁闩锁，必须在销毁引用结构的内容之前获取。例如，lazywriter 进程必须获取一个 DT 闩锁以释放一个干净的页面，然后再将其添加到可供其他线程使用的空闲缓冲区列表中。
上面的描述中关于闩锁兼容性的描述，可以用上表来表示。如果我们看到一个闩锁，可以通过”_”之后的后缀来区分其模式。比如PAGEIOLATCH_EX是一个独享的PAGEIOLATCH，LATCH_DT是一个非缓冲区保护的销毁闩锁。
和Oracle的子闩锁类似，SQLSERVER也存在类似的结构，称为superlatch或者sublatch。目的是使用多个子闩锁来提高闩锁的并发性能。SQLSERVER使用多线程结构，并采用缓冲区动态扩展的方式。因此superlatch机制与NUMA架构做了一些优化，使之更好的适应NUMA。
SuperLatches 可以提高访问共享页面的性能，其中多个并发运行的工作线程需要 SH 闩锁。为此，SQL Server 引擎会将此类页面上的闩锁动态提升为 SuperLatch。
在为大型服务器设计的高吞吐量系统上，必定会出现高并发的闩锁争用，在此类系统中存在闩锁争用是十分正常的现象。但是当闩锁争用和闩锁等待类型等待时间大到足以降低 CPU 利用率的情况下，系统的整体吞吐量会严重下降。识别和识别闩锁争用的迹象很重要，所以让我们必须有能力来分析这种情况。SQL Server 闩锁的预期行为（与每秒事务数相关）是每秒事务数将随着平均 SQL Server 闩锁等待时间的增加而增加，其本身以缓慢的速度增加。如果数据库并发增长的趋势与闩锁等待的趋势十分接近，那么闩锁争用并没有产生额外的负面影响。如果闩锁等待幅度远远超过数据库负载的增长，那么就说明闩锁出现了严重的争用。这个判断原则在大多数情况下是有效的。
我已经比较长时间没有仔细阅读数据库厂商官方的白皮书了，通过这两天的学习，我学到了一个分析数据的方法。实际上有些指标之间是存在较为同步的关联关系的，通过上升或者下降的幅度（可以通过统计学方法计算出一个可评估的度量）之间的对比，可以发现一些系统的性能问题。以前我们做了一个指标关联性分析工具，用于发现数据库某个指标异常可能存在的问题。实际上用这种更为简单的算法，也可以发现系统中存在的一些背离预期行为的场景，并用于告警。
