SQL Server阻塞之 PFS 页介绍

背景

在 SQLSERVER 的众多阻塞场景中，有不小的一部分是由于 PFS 页上的 闩锁 等待造成的，毕竟写页操作一定是要串行化的，在面对 闩锁(PAGELATCH_X) 等待问题上，一定要搞明白 PFS 页到底是什么？这篇就来好好聊一聊。

什么是 PFS 页

我们知道数据库是由海量的 数据页 组成，表记录会写入到 数据页 上，那海量的数据页如何管理呢？SQLSERVER 想到了一个办法，从海量的数据页中按一定规则择取一些作为 管理页 使用，比如：

• GAM 跟踪区分配情况
• SGAM 跟踪共享区分配情况
• PFS 跟踪数据页的空间使用情况

这里我简述一下吧，GAM数据页中一个 bit 跟踪一个 64k 的空间(一个区)，所以一个 8k 的GAM页 可以跟踪大约 (8 * 8192) * 64k = 4G 的空间，而 PFS 数据页用一个 byte 跟踪一个 8k 的数据页，理论上可以管理 8192 * 8k = 64M 的数据。

接下来的问题是这 1byte 是如何标记一个数据页的使用情况呢？简单的画个图吧。

从图中看，这一个跟踪 byte 差不多都给塞满了，有了这些基础之后，接下来用一个案例来演示一下。

案例演示

创建一个 MyTestDB 数据库，新建一个 post 表，参考sql如下：

创建好之后来观察下 MyTestDB 的 mdf 文件中的 PFS 数据页，可以使用 DBCC PAGE 命令，但这个命令需要获取 fileid, pageid 这两个参数，那如何提取呢？

• 如何提取 fileid

可以查询 sys.database_files 系统表提取。

• 如何提取 pageid

刚才说过了，这种管理页都是有规律的，比如 PFS 页是 64M 一个，在 file_id=1 的文件中，第一个区的第1号数据页就是 PFS 页，即 MyTestDB.mdf 文件偏移 8192byte 的位置，这里稍微补充一下，mdf 文件的第一个区中的 8 个 page 都是有特殊用途的，画个简图如下：

接下来观察下这个 PFS 数据页，它的 type=11，后续我们还会对它不断的观察。

好了，继续测试吧，插入一条数据，观察 PFS 页对应的位数是否有变化？比如空间使用率，参考sql如下：

从图中可以看到，插入的 aaaaa 记录写到了 240 号数据页，跟踪这个数据页的byte 理论上是在 PFS 页偏移 0n240 byte 的位置，那具体是哪一个位置的 byte 跟踪的呢？我们用 windbg 观察下 PFS 数据页的内存页地址即可，首先用 DBCC PAGE(MyTestDB,1,1,2) 找到 Page 页在内存的首地址。

接下来用 WinDbg 附加 SqlServer，由于前 96byte 是数据页头，所以理论位置应该是 000000C8177F8000+0x60 + 0n240 的位置，截图如下：

哈哈，终于给找到了，那 0x41 是什么意思呢？可以用 windbg 的 .formats 命令观察一下。

对应 byte 中位解读，可以知道当前 240 号数据页的空间使用率为 1 ~50%，同时 数据页已被分配。

这里我们顺带观察下 PageID=80 号这个 IAM 页，看看 PFS 中如何表示它的，在内存中计算位置应该是 000000C8177F8000+0x60 + 0n80，输出如下：

再对应 byte 位解读，可以知道当前的 80号数据页 的四点信息：

• 当前数据页已分配
• 当前数据页在混合区
• 当前数据页为 IAM 页
• 当前为特殊管理页

接下来再插入 4条 数据，观察下 空间使用率 是否有变化 ?

用 DBCC PAGE 观察内存页首地址之后，再次用 WinDBG 附加观察，输出如下：

从输出可以看到已经由原来的 41 变成了 42，其中的 010 刚好表示当前数据页为 51~80% 满，作为校验的话，可以直接观察 240号 页头上的 PFS (1:1) = 0x42 ALLOCATED 80_PCT_FULL 描述。

总结

总的来说 PFS页 瓶颈主要来自于用户创建的 临时表 和 表变量，常常在高并发的场景下由于高频的创建和删除临时表以及对临时表的插入，SQLSERVER 不得不高频的修改 PFS页 造成这一块的瓶颈，如果大家在阻塞中看到大量的PageLatch_x 等待资源，记得一定要将 Tempdb 中的 ndf 划分为多个来分摊写入压力。

参考

https://mp.weixin.qq.com/s/9omSA1YpN3LhouOGVJ9b9Q