WEBVTT

00:00:00.000 --> 00:00:01.830
• SQL 服务器 2019 提供

00:00:01.830 --> 00:00:04.995
Linux 的新功能称为
持久日志缓冲区。

00:00:04.995 --> 00:00:06.960
它以前可用于 Windows，

00:00:06.960 --> 00:00:08.385
现在在Linux上也是如此，

00:00:08.385 --> 00:00:10.740
它可以帮助你消除
瓶颈，可能

00:00:10.740 --> 00:00:14.130
在等待日志时发生
缓冲两个刷新到光盘。

00:00:14.130 --> 00:00:18.300
布赖恩是来告诉我们的
关于它今天的数据暴露。

00:00:18.300 --> 00:00:29.040
[音乐]

00:00:29.040 --> 00:00:32.115
• 嗨，欢迎来到另一个
一集数据暴露。

00:00:32.115 --> 00:00:35.220
我是你的东道主杰琳
今天我有布赖恩与我

00:00:35.220 --> 00:00:38.460
谈论持久
SQL 2019 中的日志缓冲区。

00:00:38.460 --> 00:00:40.230
好，布莱恩，欢迎参加演出。

00:00:40.230 --> 00:00:42.195
嗨，杰琳谢谢。

00:00:42.195 --> 00:00:46.045
那我们要谈什么
关于持久长缓冲区？

00:00:46.045 --> 00:00:47.160
* 是。所以-

00:00:47.160 --> 00:00:47.685
那是什么？

00:00:47.685 --> 00:00:50.400
* 因此持久日志
缓冲区是其中一个

00:00:50.400 --> 00:00:53.325
我们称之为内存中
数据库功能系列，

00:00:53.325 --> 00:00:55.965
包括内存中 OLTP，

00:00:55.965 --> 00:00:59.265
持久日志缓冲区
我今天要演示

00:00:59.265 --> 00:01:01.845
有时被称为日志缓存的尾部，

00:01:01.845 --> 00:01:05.040
a 数据和日志文件
Linux的启示，

00:01:05.040 --> 00:01:07.470
混合缓冲池
Linux 和 Windows，

00:01:07.470 --> 00:01:09.870
和内存优化临时DB元数据。

00:01:09.870 --> 00:01:11.370
"好的。酷。

00:01:11.370 --> 00:01:17.195
* 所以我快速提及
关于持久内存设备。

00:01:17.195 --> 00:01:19.550
很多人没有
看到他们，但基本上

00:01:19.550 --> 00:01:21.730
这些都是定期的DIMM，你

00:01:21.730 --> 00:01:26.275
馈入您的服务器，
以不同的能力出现。

00:01:26.275 --> 00:01:30.545
MVDIMM-N 是一种类型的
持久内存技术，

00:01:30.545 --> 00:01:34.325
来一个8，16，或32
千兆 DIMM 容量，

00:01:34.325 --> 00:01:36.980
然后最新的英特尔获得

00:01:36.980 --> 00:01:41.150
DC 持久内存进来
更高的容量的128，

00:01:41.150 --> 00:01:44.810
256 GB 或 512 GB DIMM。

00:01:44.810 --> 00:01:46.820
* 这是所有
持久内存。哇。

00:01:46.820 --> 00:01:48.060
* 是。所以你可以

00:01:48.060 --> 00:01:49.290
在内特套接字服务器上，

00:01:49.290 --> 00:01:52.370
您最多支持 24
TB 的持久内存。

00:01:52.370 --> 00:01:53.750
• 我可以解锁所有

00:01:53.750 --> 00:01:55.970
与这个持久
日志缓冲区，对不对？

00:01:55.970 --> 00:01:56.570
• 正确。

00:01:56.570 --> 00:01:57.680
• 哇。

00:01:57.680 --> 00:02:00.110
• 持久日志
缓冲区旨在

00:02:00.110 --> 00:02:02.075
解决特定的用例

00:02:02.075 --> 00:02:07.400
出现减速的地方
或等待您的工作负载，

00:02:07.400 --> 00:02:12.385
等待日志缓冲区，
在内存中以刷新到磁盘。

00:02:12.385 --> 00:02:13.005
"好的。

00:02:13.005 --> 00:02:16.114
• 因此，它使用
持久内存设备

00:02:16.114 --> 00:02:19.355
它知道，一旦它
写入该设备，

00:02:19.355 --> 00:02:21.650
它不需要
等待刷新

00:02:21.650 --> 00:02:24.270
因为它已经
持久性设备。

00:02:24.270 --> 00:02:26.195
• 然后设备将
照顾其余的。

00:02:26.195 --> 00:02:28.835
• 是，设备将
然后照顾其余的

00:02:28.835 --> 00:02:31.730
而你进行基本上
与你的工作负荷。

00:02:31.730 --> 00:02:32.180
* 是的。

00:02:32.180 --> 00:02:35.585
• 因此，当您设置
Windows 中的这些设备，

00:02:35.585 --> 00:02:41.600
我们有一些基本的建议
你把页面锁在内存中

00:02:41.600 --> 00:02:44.150
你使用两兆字节
分配单位大小

00:02:44.150 --> 00:02:46.760
NTFS 不会默认。

00:02:46.760 --> 00:02:47.180
"好的。

00:02:47.180 --> 00:02:49.715
• 您还需要
设置此标志 DAX。

00:02:49.715 --> 00:02:51.920
因此，DAX 是真正使我们能够

00:02:51.920 --> 00:02:55.280
处理持久内存
设备并写入它

00:02:55.280 --> 00:02:57.260
直接跳过所有

00:02:57.260 --> 00:02:59.795
内核堆栈，

00:02:59.795 --> 00:03:03.090
你通常需要
处理文件时。

00:03:03.090 --> 00:03:05.145
在 GUI 中不可用，

00:03:05.145 --> 00:03:07.250
所以你需要使用
一些电源外壳。

00:03:07.250 --> 00:03:09.560
"好的。好吧。您将
告诉我们这是如何运作的，对吗？

00:03:09.560 --> 00:03:13.325
* 是。我将展示如何
这些得到配置。

00:03:13.325 --> 00:03:16.430
还有一些您的操作系统级别
光盘计数器，你

00:03:16.430 --> 00:03:19.510
可能习惯于看像
这些转移等等，

00:03:19.510 --> 00:03:21.830
可能无法

00:03:21.830 --> 00:03:24.200
当你与
持久内存设备。

00:03:24.200 --> 00:03:28.865
这只是其中一件事
你需要注意。

00:03:28.865 --> 00:03:29.330
* 当然可以。

00:03:29.330 --> 00:03:33.575
• 这些是新设备，并且
是非常全新的令人兴奋的策略。

00:03:33.575 --> 00:03:33.935
"好的。

00:03:33.935 --> 00:03:37.565
* 所以可能会有一些捕捉
到监视端执行。

00:03:37.565 --> 00:03:38.245
* 当然可以。

00:03:38.245 --> 00:03:42.580
• 对于 Linux，非易失性
设备控制

00:03:42.580 --> 00:03:45.110
是实用程序，你
用于配置此。

00:03:45.110 --> 00:03:47.840
您将将其设置为 fsdax 模式，

00:03:47.840 --> 00:03:50.795
使用两兆字节的巨大页面错误，

00:03:50.795 --> 00:03:53.555
设置块分配
也到两兆字节。

00:03:53.555 --> 00:03:56.180
我们支持 XFS 或 EXT

00:03:56.180 --> 00:04:00.620
因为这些是两个支持
具有 DAX 的文件系统。

00:04:00.620 --> 00:04:01.295
"好的。

00:04:01.295 --> 00:04:03.050
* 因此，持久日志缓冲区，

00:04:03.050 --> 00:04:05.585
这已经可用
实际上在 SQL 中，因为

00:04:05.585 --> 00:04:10.140
SQL 2016 仅适用于 Windows 直到现在。

00:04:10.140 --> 00:04:12.470
使用 SQL 2019，我们还将有

00:04:12.470 --> 00:04:15.875
此功能现已可用
在Linux和Windows中。

00:04:15.875 --> 00:04:18.590
只使用非常小
容量量，

00:04:18.590 --> 00:04:21.720
日志缓冲区只有 20
每个用户数据库的兆字节。

00:04:21.720 --> 00:04:22.355
"好的。

00:04:22.355 --> 00:04:26.330
* 所以它真的不需要
巨大的容量，

00:04:26.330 --> 00:04:28.850
和你得到的行为是非常

00:04:28.850 --> 00:04:31.250
类似于强迫
延迟耐久性。

00:04:31.250 --> 00:04:31.910
"好的。

00:04:31.910 --> 00:04:34.040
* 所以，你并没有等待

00:04:34.040 --> 00:04:36.890
日志刷新发生在磁盘

00:04:36.890 --> 00:04:40.040
但鼓励没有风险，

00:04:40.040 --> 00:04:43.235
你采取什么被迫延迟
数据丢失的耐用性。

00:04:43.235 --> 00:04:45.290
* 所以，你能告诉我们一个
多一点关于

00:04:45.290 --> 00:04:47.550
强制延迟耐久性
对于那些是

00:04:47.550 --> 00:04:48.615
* 当然，对于那些

00:04:48.615 --> 00:04:49.425
* - 不知道吗？

00:04:49.425 --> 00:04:52.095
* 是。对于那些谁
不熟悉，

00:04:52.095 --> 00:04:53.840
这本质上是

00:04:53.840 --> 00:04:57.260
异步提交
SQL Server 中的机制。

00:04:57.260 --> 00:04:57.710
"好的。

00:04:57.710 --> 00:05:01.280
* 所以有一对夫妇
做它的方法。

00:05:01.280 --> 00:05:03.740
允许一个，在这种情况下

00:05:03.740 --> 00:05:07.190
您的正常提交
如你所料，

00:05:07.190 --> 00:05:08.270
你等待冲洗，

00:05:08.270 --> 00:05:10.455
等待它们在光盘上硬化，

00:05:10.455 --> 00:05:15.440
或在强制模式下，所有
提交的行为是这样的。

00:05:15.440 --> 00:05:16.000
"好的。

00:05:16.000 --> 00:05:19.220
• 所以允许进入
您指定每

00:05:19.220 --> 00:05:22.880
提交基础，如果你想这个
行为，这是允许的，

00:05:22.880 --> 00:05:24.935
不允许，这是默认

00:05:24.935 --> 00:05:27.425
不管你有什么
那里不会发生。

00:05:27.425 --> 00:05:27.905
* 当然可以。

00:05:27.905 --> 00:05:30.170
• 然后强制所有
提交的行为方式。

00:05:30.170 --> 00:05:32.285
"好的。因此，在一个持久的
低水平是非常

00:05:32.285 --> 00:05:34.890
相似，但不完全相同。

00:05:34.890 --> 00:05:37.215
* 非常相似，但
不完全一样，

00:05:37.215 --> 00:05:39.845
因为我们有
持久内存设备，

00:05:39.845 --> 00:05:42.965
我们把日志缓冲区放在那儿

00:05:42.965 --> 00:05:46.640
一旦我们写在那里，我们知道
它坚持，我们

00:05:46.640 --> 00:05:50.360
没有任何数据丢失的风险
在发生服务器崩溃时，

00:05:50.360 --> 00:05:53.000
电源故障，任何
性质，

00:05:53.000 --> 00:05:56.570
我们可以从数据中恢复
持久内存设备。

00:05:56.570 --> 00:05:57.920
"好的。酷。

00:05:57.920 --> 00:06:00.230
• 这实际上很简单。

00:06:00.230 --> 00:06:01.640
很多人没有意识到

00:06:01.640 --> 00:06:04.355
您只需添加一个日志文件

00:06:04.355 --> 00:06:07.580
20 兆字节的
持久内存设备，

00:06:07.580 --> 00:06:10.370
SQL 服务器将
识别此设备，

00:06:10.370 --> 00:06:13.265
并将其视为日志缓冲区。

00:06:13.265 --> 00:06:14.405
• 非常简单

00:06:14.405 --> 00:06:15.665
真的这么简单。

00:06:15.665 --> 00:06:16.205
• 哇。

00:06:16.205 --> 00:06:19.550
* 是的，正如我们可以看到的
这里是日志缓冲区坐上

00:06:19.550 --> 00:06:23.090
我们的存储类内存
这是PMM有时

00:06:23.090 --> 00:06:26.480
我们称之为存储类
内存和在一些地方

00:06:26.480 --> 00:06:30.405
但同样的事情和我们
日志记录在那里，

00:06:30.405 --> 00:06:31.950
正如我所提到的

00:06:31.950 --> 00:06:33.200
我们不必等待
为他们通过

00:06:33.200 --> 00:06:36.365
刷新到主
事务日志文件。

00:06:36.365 --> 00:06:37.010
• 冷却。

00:06:37.010 --> 00:06:41.875
* 所以我只是切换
快速到我的演示在这里。

00:06:41.875 --> 00:06:42.990
* 是的。

00:06:42.990 --> 00:06:46.280
* 首先，我只是显示
我们已经配置

00:06:46.280 --> 00:06:49.310
在这里，我们的持久内存设备。

00:06:49.310 --> 00:06:50.945
正如我提到的，这些
是常规的 DIMM，

00:06:50.945 --> 00:06:53.180
你可以看到那里的设备设备设备。

00:06:53.180 --> 00:06:56.405
我们配置了两个
每个 NUMA 节点一个设备。

00:06:56.405 --> 00:06:56.855
"好的。

00:06:56.855 --> 00:07:01.565
• 跨设备交错
在 NUMA 节点上的 DIMM。

00:07:01.565 --> 00:07:05.330
因此，这是推荐的
的方式，我们说设置它。

00:07:05.330 --> 00:07:06.410
"好的。

00:07:06.410 --> 00:07:08.950
* 再次，我们可以看到

00:07:08.950 --> 00:07:12.920
我们的 DAX 值已启用
这里设置成真，

00:07:12.920 --> 00:07:17.464
如果我们想使用我们的老
命令行类型实用程序，

00:07:17.464 --> 00:07:21.830
我们可以得到那一点点
位更多信息在这里，我们可以

00:07:21.830 --> 00:07:26.450
看到我们已经设置了分配
单位大小为两兆字节。

00:07:26.450 --> 00:07:28.640
* 如你刚才所述。
应该是，是的。

00:07:28.640 --> 00:07:31.505
* 是的。因为我只是
描述和相当

00:07:31.505 --> 00:07:36.185
简单，我们只是添加
日志文件，正如我提到的，

00:07:36.185 --> 00:07:38.205
我们只是创建和

00:07:38.205 --> 00:07:40.700
无论您大小
把它放在这里，我们实际上会

00:07:40.700 --> 00:07:42.860
集成使用 20 MB

00:07:42.860 --> 00:07:46.025
但只要继续前进，
假设 20 兆字节的坐。

00:07:46.025 --> 00:07:47.975
* 是的。只是为了确定。

00:07:47.975 --> 00:07:50.960
是的，真的很简单。

00:07:50.960 --> 00:07:52.550
• 哇。好吧。

00:07:52.550 --> 00:07:54.200
所以，这是令人印象深刻的。

00:07:54.200 --> 00:07:56.900
所以基本上我可以解锁
所有这些新技术

00:07:56.900 --> 00:07:58.580
一个持久性日志缓冲区，只需

00:07:58.580 --> 00:08:00.650
运行非常简单的命令，对不对？

00:08:00.650 --> 00:08:01.055
* 是的。

00:08:01.055 --> 00:08:02.930
* 当然可以。你必须
首先配置设备，

00:08:02.930 --> 00:08:05.965
然后，这完成后
在 SQL 中，只需添加一个日志。

00:08:05.965 --> 00:08:09.350
• 是，此类型

00:08:09.350 --> 00:08:12.725
技术真的是
启用新层

00:08:12.725 --> 00:08:15.020
存储帮助删除一些

00:08:15.020 --> 00:08:17.075
传统
我们看到的瓶颈

00:08:17.075 --> 00:08:19.640
在高端工作负载的 SQL Server 中。

00:08:19.640 --> 00:08:22.220
* 正确。如此巨大的创新，但

00:08:22.220 --> 00:08:24.710
然后以非常简单的方式完成

00:08:24.710 --> 00:08:26.570
用户和
配置。

00:08:26.570 --> 00:08:29.360
* 是。我们建立智能
到 SQL Server 到

00:08:29.360 --> 00:08:32.240
识别这些设备
并相应地进行。

00:08:32.240 --> 00:08:34.295
* 是的。很酷嗯，
感谢您的分享。

00:08:34.295 --> 00:08:34.895
谢谢

00:08:34.895 --> 00:08:36.560
我觉得这非常有用

00:08:36.560 --> 00:08:37.910
很有趣，至少对我来说是这样。

00:08:37.910 --> 00:08:40.490
我希望这是有用的，
对你也很有趣。

00:08:40.490 --> 00:08:43.065
请订阅，例如，
对视频的评论，

00:08:43.065 --> 00:08:44.660
我希望下次能见到你

00:08:44.660 --> 00:08:47.040
另一集
数据公开。谢谢。

00:08:47.040 --> 00:09:01.630
[音乐]

