WEBVTT

00:00:00.000 --> 00:00:10.500
[音乐]。

00:00:10.500 --> 00:00:12.270
你好，我叫帕姆

00:00:12.270 --> 00:00:15.495
我是一个项目经理
SQL 服务器工程团队。

00:00:15.495 --> 00:00:17.790
今天我想做
为您提供快速演示

00:00:17.790 --> 00:00:19.800
在新的
SQL 服务器的功能。

00:00:19.800 --> 00:00:23.310
2019 内存优化
TempDB 元数据。

00:00:23.310 --> 00:00:26.070
我已经做了一个
概述视频

00:00:26.070 --> 00:00:27.480
此功能，
我谈了一点

00:00:27.480 --> 00:00:29.040
关于一些挑战

00:00:29.040 --> 00:00:32.295
您使用的临时 DB 性能
可能在过去面对和

00:00:32.295 --> 00:00:35.850
关于我们在2019年所做的工作
以提高 TempDB 性能。

00:00:35.850 --> 00:00:38.945
所以我鼓励你看
视频，如果你还没有看到它。

00:00:38.945 --> 00:00:41.600
我们要做什么
在这个演示今天是

00:00:41.600 --> 00:00:45.185
专注于优化的内存
TempDB 元数据功能，

00:00:45.185 --> 00:00:46.805
如何启用它，

00:00:46.805 --> 00:00:47.975
如何禁用它。

00:00:47.975 --> 00:00:49.640
但是，你怎么能

00:00:49.640 --> 00:00:51.790
告诉你是否需要
打开此功能。

00:00:51.790 --> 00:00:55.600
你有问题吗？
此功能旨在解决？

00:00:55.600 --> 00:00:58.770
因此，让我们跳进
演示，并看看。

00:01:00.220 --> 00:01:02.960
所以我有一个笔记本在这里打开

00:01:02.960 --> 00:01:05.420
Azure 数据工作室
与一些命令。

00:01:05.420 --> 00:01:09.050
我们先开始就是运行
SQL Server 上的工作负载。

00:01:09.050 --> 00:01:14.315
2019 年未启用内存
优化的 TempDB 元数据功能

00:01:14.315 --> 00:01:15.560
我们会试着看看

00:01:15.560 --> 00:01:17.930
这个论点，
可能发生在 TempDB。

00:01:17.930 --> 00:01:21.050
所以，我要做的第一件事
要做的是开始

00:01:21.050 --> 00:01:24.170
性能监视器
收集和收集

00:01:24.170 --> 00:01:26.120
几个不同的
计数器，将给予

00:01:26.120 --> 00:01:28.430
我们的想法
工作负载的性能。

00:01:28.430 --> 00:01:31.955
然后我要使用
O 应力工具

00:01:31.955 --> 00:01:34.415
运行多线程工作负载。

00:01:34.415 --> 00:01:37.700
所以我有八个处理器
在这台机器上

00:01:37.700 --> 00:01:39.950
但我扔了100
并发线程。

00:01:39.950 --> 00:01:42.350
所以我的工作量非常繁忙

00:01:42.350 --> 00:01:44.810
在这里，这是一个非常
繁重的 TempDB 工作负载。

00:01:44.810 --> 00:01:47.210
这是一个基本的存储过程
创建临时表，

00:01:47.210 --> 00:01:48.360
把一些数据放进去

00:01:48.360 --> 00:01:49.805
然后从中选择。

00:01:49.805 --> 00:01:52.200
所以你可以看到这里佩尔夫人。

00:01:52.200 --> 00:01:54.090
我有一些重量正在进行中，

00:01:54.090 --> 00:01:55.740
页面闩锁权重正在进行中。

00:01:55.740 --> 00:01:58.895
我也有平均等待时间

00:01:58.895 --> 00:02:00.380
列在这里的佩尔夫人以及。

00:02:00.380 --> 00:02:02.390
所以你可以看到我有
分页闩锁重量

00:02:02.390 --> 00:02:04.775
发生，而我
运行此工作负载。

00:02:04.775 --> 00:02:07.640
这是不寻常的与
大量并发工作负载。

00:02:07.640 --> 00:02:11.580
这里的问题是
这些页面闩锁重量来自？

00:02:11.580 --> 00:02:12.770
我们不一定知道。

00:02:12.770 --> 00:02:14.405
他们可能是从
用户数据库。

00:02:14.405 --> 00:02:16.430
他们可能是来自TempDB。

00:02:16.430 --> 00:02:18.740
我们真的不知道
通过查看性能

00:02:18.740 --> 00:02:21.620
监视这些页面闩锁的位置
重量来自。

00:02:21.620 --> 00:02:23.210
因此，我们想回到

00:02:23.210 --> 00:02:25.850
Azure 数据工作室，并查看

00:02:25.850 --> 00:02:27.110
一个脚本，可以帮助我们

00:02:27.110 --> 00:02:30.880
确定这些页面的位置
闩锁重量来自。

00:02:30.880 --> 00:02:32.230
看起来我的工作量完成了

00:02:32.230 --> 00:02:34.190
所以，我只是要踢它
再次退后，以便我们

00:02:34.190 --> 00:02:36.925
可以查看该 Azure 数据工作室。

00:02:36.925 --> 00:02:40.090
让我们回到这里。

00:02:42.130 --> 00:02:47.135
我要运行此查询
我有重点。

00:02:47.135 --> 00:02:51.740
此查询执行的操作是
查看来自

00:02:51.740 --> 00:02:56.510
DM 的确切请求，具有
像页面一样的重量类型，

00:02:56.510 --> 00:03:00.335
意味着某种
页面闩锁重量。

00:03:00.335 --> 00:03:04.010
我能在结果中看到的
这里是，我实际上有

00:03:04.010 --> 00:03:07.295
几个会话
等待页面闩锁。

00:03:07.295 --> 00:03:09.305
如果我查看重量资源，

00:03:09.305 --> 00:03:11.990
我只能从重量中分辨出
资源，他们在

00:03:11.990 --> 00:03:15.905
TempDB，因为重量
资源是 2：1：1：20。

00:03:15.905 --> 00:03:17.420
二是数据库 ID，

00:03:17.420 --> 00:03:18.665
两个是TempDB。

00:03:18.665 --> 00:03:23.570
一个是文件编号 1 和
然后 120 是页码。

00:03:23.570 --> 00:03:25.325
所以我可以分辨出它在TempDB。

00:03:25.325 --> 00:03:30.395
但是，如果我使用这个新功能
称为 DMDB 页面信息，

00:03:30.395 --> 00:03:34.039
这让我能做什么
是获取该页面资源

00:03:34.039 --> 00:03:38.330
并破解它打开，看到
该页面上的确切内容。

00:03:38.330 --> 00:03:41.355
因此，从DMDB页面信息功能，

00:03:41.355 --> 00:03:44.150
我得到这个对象
名称，你可以看到

00:03:44.150 --> 00:03:46.810
在这里，对象名称
是系统架构对象，

00:03:46.810 --> 00:03:48.095
这是一个系统表。

00:03:48.095 --> 00:03:50.944
这就是TempDB
元数据争用

00:03:50.944 --> 00:03:52.685
我们谈论的

00:03:52.685 --> 00:03:54.754
这就是问题所在

00:03:54.754 --> 00:03:58.220
内存优化 TempDB
引入元数据来解决。

00:03:58.220 --> 00:03:59.960
因此，让我们回到
我们的命令窗口。

00:03:59.960 --> 00:04:01.115
我们可以看到它完成了。

00:04:01.115 --> 00:04:02.450
两次执行

00:04:02.450 --> 00:04:06.005
花了大约52秒
以运行工作负载。

00:04:06.005 --> 00:04:09.675
我们当然可以看到页面
锁存重量发生。

00:04:09.675 --> 00:04:12.300
我们可以看到批次
每秒请求，

00:04:12.300 --> 00:04:14.100
这是在顶，

00:04:14.100 --> 00:04:18.225
让我们看看这里，大约350个最大值。

00:04:18.225 --> 00:04:20.210
因此，这是没有
功能已打开。

00:04:20.210 --> 00:04:22.265
因此，让我们继续前进，
打开功能。

00:04:22.265 --> 00:04:23.795
为了做到这一点，

00:04:23.795 --> 00:04:25.925
我们需要在

00:04:25.925 --> 00:04:29.090
SQL 服务器，我们还需要
重新启动服务器。

00:04:29.090 --> 00:04:34.250
这改变了服务器配置
命令需要重新启动。

00:04:34.250 --> 00:04:38.875
因此，我们要设置内存
优化了 TempDB 元数据。

00:04:38.875 --> 00:04:43.540
然后，我会继续前进，
重新启动服务器。

00:04:44.360 --> 00:04:48.025
一旦我这么做

00:04:48.025 --> 00:04:50.810
我会回来的

00:04:50.810 --> 00:04:54.155
到 Azure 数据工作室和
运行另一个命令，

00:04:54.155 --> 00:04:57.470
选择服务器属性
命令以查看是否

00:04:57.470 --> 00:05:01.160
临时数据库内存优化
元数据功能已打开。

00:05:01.160 --> 00:05:03.265
因此，让我们运行此命令。

00:05:03.265 --> 00:05:07.245
你可以看到它得到执行
功能现已打开。

00:05:07.245 --> 00:05:10.565
是一个因此，让我们继续前进
并再次运行我们的工作量。

00:05:10.565 --> 00:05:13.470
让我们开始佩尔夫

00:05:16.490 --> 00:05:19.350
让我们重新开始我们的工作量。

00:05:19.350 --> 00:05:20.775
完全相同的工作负载。

00:05:20.775 --> 00:05:24.130
相同的存储过程，100 个线程。

00:05:24.130 --> 00:05:27.080
你可能会注意到一些事情
不同的佩尔夫人马上。

00:05:27.080 --> 00:05:29.900
首先，批处理请求
每秒要高得多。

00:05:29.900 --> 00:05:34.520
我们要去超过500。

00:05:34.520 --> 00:05:36.320
它甚至可能更高一点。

00:05:36.320 --> 00:05:37.580
我会让它运行一段时间，

00:05:37.580 --> 00:05:40.790
但也注意到这些页面
闩锁重量已消失。

00:05:40.790 --> 00:05:42.605
没有更多的页面闩锁权重。

00:05:42.605 --> 00:05:45.740
如果我们返回 Azure 数据
工作室和我运行该命令

00:05:45.740 --> 00:05:48.990
再次查看会话。

00:05:48.990 --> 00:05:52.310
请注意，没有会话
正在等待页面闩锁。

00:05:52.310 --> 00:05:55.865
我们完全消除了
页面闩锁权重。

00:05:55.865 --> 00:05:57.590
如果我回到佩尔夫

00:05:57.590 --> 00:06:00.005
是的，我的工作量已经完成了。

00:06:00.005 --> 00:06:02.990
所以你可以看到我
提高了吞吐量。

00:06:02.990 --> 00:06:05.675
我已经淘汰了那些
页面闩锁权重。

00:06:05.675 --> 00:06:07.580
如果我归结到我的工作量，

00:06:07.580 --> 00:06:10.130
它在35秒内完成

00:06:10.130 --> 00:06:13.760
与52秒
不打开该功能。

00:06:13.760 --> 00:06:19.220
因此，此功能的设计
允许您帮助扩展

00:06:19.220 --> 00:06:23.240
起来你的沉重的TempDB
有争议的工作负载

00:06:23.240 --> 00:06:25.400
不做任何
代码更改。

00:06:25.400 --> 00:06:28.085
您只需打开配置，

00:06:28.085 --> 00:06:31.640
重新启动服务器，然后您
可以立即改善

00:06:31.640 --> 00:06:33.770
吞吐量和更少
页面闩锁权重

00:06:33.770 --> 00:06:36.320
在您的 TempDB 有争议的工作负载上。

00:06:36.320 --> 00:06:38.300
所以，我希望这能帮助你学习

00:06:38.300 --> 00:06:40.790
多一点关于
功能，你会如何使用它，

00:06:40.790 --> 00:06:42.860
你如何知道是否
你需要打开它

00:06:42.860 --> 00:06:45.020
或不，让你多一点

00:06:45.020 --> 00:06:46.970
兴奋的改进
即将进入

00:06:46.970 --> 00:06:49.610
SQL Server 2019 非常感谢。

00:06:49.610 --> 00:07:04.210
[音乐]