WEBVTT

00:00:00.000 --> 00:00:02.055
• 数据库恢复

00:00:02.055 --> 00:00:05.190
长时间运行的事务
一直是一个挑战。

00:00:05.190 --> 00:00:07.050
在 SQL Server 2019 中，

00:00:07.050 --> 00:00:09.780
我们介绍加速
数据库恢复

00:00:09.780 --> 00:00:11.190
帮助解决那个问题。

00:00:11.190 --> 00:00:13.605
凯文在这里告诉
我们都在谈论它，

00:00:13.605 --> 00:00:15.390
今天的数据公开。

00:00:15.390 --> 00:00:26.130
[音乐]

00:00:26.130 --> 00:00:28.755
• 嗨，欢迎来到另一个
一集数据暴露。

00:00:28.755 --> 00:00:30.745
我是你的东道主，杰琳，今天

00:00:30.745 --> 00:00:34.415
我们有凯文和我们谈论
加速数据库恢复。

00:00:34.415 --> 00:00:35.975
所以欢迎凯文来表演。

00:00:35.975 --> 00:00:36.665
谢谢

00:00:36.665 --> 00:00:39.125
• 因此加快了数据库恢复。

00:00:39.125 --> 00:00:40.750
那是什么？

00:00:40.750 --> 00:00:41.930
* 所以这是一个有趣的功能。

00:00:41.930 --> 00:00:43.340
我们简称为ADR。

00:00:43.340 --> 00:00:44.890
"好的，当然。

00:00:44.890 --> 00:00:46.970
• 它来自
看着一些

00:00:46.970 --> 00:00:48.530
客户有痛点

00:00:48.530 --> 00:00:51.770
运行数据库并保持
他们高度可用和

00:00:51.770 --> 00:00:53.270
它的一部分与时间

00:00:53.270 --> 00:00:55.475
需要使数据库联机。

00:00:55.475 --> 00:00:58.970
有很多阶段
数据库必须经过

00:00:58.970 --> 00:01:01.340
如果你有一个很长
运行事务，

00:01:01.340 --> 00:01:04.010
这可能需要很长时间
清理，并说

00:01:04.010 --> 00:01:07.080
导致不可用时
它正在做处理。

00:01:07.080 --> 00:01:10.545
* 正确。所以我们知道
恢复是一个痛点。

00:01:10.545 --> 00:01:13.530
把它带回来是
DBA 的东西，

00:01:13.530 --> 00:01:15.075
嗯，有点担心。

00:01:15.075 --> 00:01:16.790
* 正确。因此，团队看着

00:01:16.790 --> 00:01:19.520
整个过程和思想
我们怎么能重新想象它呢？

00:01:19.520 --> 00:01:21.335
所以他们想出了ADR

00:01:21.335 --> 00:01:23.210
它基于版本存储。

00:01:23.210 --> 00:01:26.170
所以所有的改变都是
在数据库中版本。

00:01:26.170 --> 00:01:29.920
住在文件中
组你选择。

00:01:30.140 --> 00:01:34.925
利用这一点，我们可以
恢复过程要快得多。

00:01:34.925 --> 00:01:35.600
• 冷却。

00:01:35.600 --> 00:01:40.965
* 我有一些幻灯片
演示。

00:01:40.965 --> 00:01:46.515
因此，在这里，我们有
经典恢复过程。

00:01:46.515 --> 00:01:48.350
因此，它开始，阶段 1 是分析。

00:01:48.350 --> 00:01:50.360
所以，你必须看看通过
所有交易

00:01:50.360 --> 00:01:53.020
在日志从最后
检查点前进。

00:01:53.020 --> 00:01:56.150
重做是任何数据更改

00:01:56.150 --> 00:01:58.700
尚未持久
在数据文件中，

00:01:58.700 --> 00:02:01.850
必须从
事务日志，

00:02:01.850 --> 00:02:03.020
一路通过从

00:02:03.020 --> 00:02:05.420
最古老的开始，
未提交的事务。

00:02:05.420 --> 00:02:07.790
所以，这是长期运行
交易真的伤害了你。

00:02:07.790 --> 00:02:08.560
* 对，确切地说。

00:02:08.560 --> 00:02:12.170
• 可能需要几分钟
一个小时或更长时间。

00:02:12.170 --> 00:02:14.660
然后，第 3 阶段撤消，

00:02:14.660 --> 00:02:17.270
在其中撤消任何交易，

00:02:17.270 --> 00:02:20.975
没有提交之前
时间，你期待。

00:02:20.975 --> 00:02:23.285
在阅读结束时，

00:02:23.285 --> 00:02:25.375
数据库部分可用。

00:02:25.375 --> 00:02:28.670
这意味着你可以
访问数据库，但

00:02:28.670 --> 00:02:33.270
未锁定的任何数据
从原始交易，

00:02:33.270 --> 00:02:34.320
现在将被锁住

00:02:34.320 --> 00:02:36.200
所以，即使有
没人做

00:02:36.200 --> 00:02:39.230
您无法访问该数据
直到撤消完成。

00:02:39.230 --> 00:02:41.930
* 所以基本上这是
长时间运行的进程

00:02:41.930 --> 00:02:45.835
然后只有在
我们到达了第3阶段

00:02:45.835 --> 00:02:47.900
我可以开始做

00:02:47.900 --> 00:02:49.580
所有我想要的
数据库又来了，对吧？

00:02:49.580 --> 00:02:50.165
* 正确。

00:02:50.165 --> 00:02:53.585
*所以告诉我它是如何。

00:02:53.585 --> 00:02:55.865
• 在底部，您只看到

00:02:55.865 --> 00:02:59.145
具有不同记录的日志记录
日志中的事件。

00:02:59.145 --> 00:03:00.165
* 当然可以。

00:03:00.165 --> 00:03:02.190
• ADR 会更改很多。

00:03:02.190 --> 00:03:03.750
我们有处理版本存储。

00:03:03.750 --> 00:03:06.375
您将看到它引用为 PVS。

00:03:06.375 --> 00:03:09.464
当我们在预览中把它拿出来时

00:03:09.464 --> 00:03:11.915
PVS 位于主文件组中

00:03:11.915 --> 00:03:13.820
没有能力
来改变它。

00:03:13.820 --> 00:03:16.780
所以，发生了，这是
所有这些版本都活了下来。

00:03:16.780 --> 00:03:19.550
我们得到的反馈是
客户希望

00:03:19.550 --> 00:03:22.280
能够指定哪个
文件组。

00:03:22.280 --> 00:03:26.180
我有一个批量文件组或
非常快的文件组，无论什么。

00:03:26.180 --> 00:03:27.740
所以现在你和

00:03:27.740 --> 00:03:31.130
发布候选和
GA 版本出来时，

00:03:31.130 --> 00:03:33.910
您将能够指定哪个
文件组并更改它，

00:03:33.910 --> 00:03:35.880
有过程
改变它以及。

00:03:35.880 --> 00:03:38.120
但是，让我们通过什么
恢复过程

00:03:38.120 --> 00:03:39.755
看起来像是ADR

00:03:39.755 --> 00:03:42.110
因此，它从分析开始，

00:03:42.110 --> 00:03:45.695
不变的
你以前拥有的东西

00:03:45.695 --> 00:03:47.015
这是相同的行为，对吗？

00:03:47.015 --> 00:03:49.805
* 正确。我们介绍了
sLog 的概念。

00:03:49.805 --> 00:03:52.705
sLog 是内存中日志

00:03:52.705 --> 00:03:55.640
只记录那些
系统事务

00:03:55.640 --> 00:03:57.005
不能进行版本控制。

00:03:57.005 --> 00:03:59.150
因此，大多数数据版本，你可以

00:03:59.150 --> 00:04:01.715
前后的变化
数据的图片。

00:04:01.715 --> 00:04:04.070
因此，一些方案的变化，

00:04:04.070 --> 00:04:06.195
诸如它之类的东西
不能进行版本控制。

00:04:06.195 --> 00:04:06.570
* 当然可以。

00:04:06.570 --> 00:04:07.890
* 因此，这些被记录在 sLog 中。

00:04:07.890 --> 00:04:09.195
所以这个想法是，

00:04:09.195 --> 00:04:11.580
很少重要。

00:04:11.580 --> 00:04:13.920
• 将有一个小
一套投影，对不对？

00:04:13.920 --> 00:04:17.525
• 因此，作为分析的一部分
重做阶段是

00:04:17.525 --> 00:04:23.100
重新创建这些内存日志
从事务日志记录。

00:04:23.230 --> 00:04:25.850
所以从sLog重做，

00:04:25.850 --> 00:04:28.300
只是利用版本存储。

00:04:28.300 --> 00:04:31.195
因为我们之前和之后
所有这些行的版本，

00:04:31.195 --> 00:04:34.010
所以它非常快，
然后你重做从

00:04:34.010 --> 00:04:38.905
日志刚刚从
最后一个检查点前进。

00:04:38.905 --> 00:04:42.810
此时，您的数据库
完全可用。

00:04:43.420 --> 00:04:46.910
撤消只是恢复

00:04:46.910 --> 00:04:48.875
版本，所以你只是

00:04:48.875 --> 00:04:51.710
指向以前的版本
而不是当前版本。

00:04:51.710 --> 00:04:55.345
你不必物理撤消
交易并反向。

00:04:55.345 --> 00:04:59.825
* 所以这将是方式
通常比旧一个快吗？

00:04:59.825 --> 00:05:01.880
• 速度更快。我们有一个客户

00:05:01.880 --> 00:05:04.280
实验室内的最后两个
周，做了一些测试

00:05:04.280 --> 00:05:10.050
ADR和他们有一个非常
活动更新工作负载。

00:05:10.050 --> 00:05:13.065
他们有一个长期运行
交易。

00:05:13.065 --> 00:05:14.430
他们做到了

00:05:14.430 --> 00:05:17.450
并做了回滚
长时间运行的事务。

00:05:17.450 --> 00:05:20.555
如果没有 ADR，它花了约
一分钟半做。

00:05:20.555 --> 00:05:24.765
* 哪些仍未
太糟糕了，但没关系，长。

00:05:24.765 --> 00:05:26.190
* 是的。在他们的业务中，

00:05:26.190 --> 00:05:28.105
它有很大的不同。

00:05:28.105 --> 00:05:30.680
于是他们重试
相同的场景

00:05:30.680 --> 00:05:32.780
与ADR和它所花的时间

00:05:32.780 --> 00:05:36.720
恢复是零秒。

00:05:36.720 --> 00:05:38.505
他们无法测量
它，它是如此快。

00:05:38.505 --> 00:05:40.110
* 令人印象深刻。

00:05:40.110 --> 00:05:43.580
他们回来了
在线上的速度要快得多，

00:05:43.580 --> 00:05:47.425
这有很大的不同
太，因为在他们的业务，

00:05:47.425 --> 00:05:49.560
任何中断都是收入损失。

00:05:49.560 --> 00:05:51.375
* 所以毫秒计数，对不对？

00:05:51.375 --> 00:05:52.230
* 非常如此。

00:05:52.230 --> 00:05:53.880
• 因此，如果我们能帮助这个客户

00:05:53.880 --> 00:05:55.575
从一分半钟开始

00:05:55.575 --> 00:05:58.305
你说基本上为零

00:05:58.305 --> 00:05:59.895
令人印象深刻哇哇

00:05:59.895 --> 00:06:02.930
因此，我们所有的客户

00:06:02.930 --> 00:06:05.810
可能想
试试这个，并启用这个。

00:06:05.810 --> 00:06:08.450
能告诉我我怎么做吗？

00:06:08.450 --> 00:06:09.470
我现在有一个数据库

00:06:09.470 --> 00:06:12.995
我有它正常
恢复，那么我该怎么办？

00:06:12.995 --> 00:06:14.585
• 因此，使用 Azure SQL 数据库，

00:06:14.585 --> 00:06:16.775
默认情况下全局打开。

00:06:16.775 --> 00:06:19.130
默认情况下，它已打开
全球数月。

00:06:19.130 --> 00:06:20.540
所以你不需要
做任何事情。

00:06:20.540 --> 00:06:22.520
你已经利用了它。

00:06:22.520 --> 00:06:23.740
• 冷却。

00:06:23.740 --> 00:06:26.940
* 对于 SQL Server 数据库，

00:06:26.940 --> 00:06:29.060
默认情况下关闭，因为有

00:06:29.060 --> 00:06:31.610
一些开销的范围

00:06:31.610 --> 00:06:35.880
1%到5%的
跟踪版本。

00:06:36.190 --> 00:06:41.015
所以，你必须打开它，
只是，改变数据库集，

00:06:41.015 --> 00:06:42.635
加速数据库恢复等于

00:06:42.635 --> 00:06:46.410
上和可选
文件组等于。

00:06:46.410 --> 00:06:47.310
* 东西。

00:06:47.310 --> 00:06:49.810
* 是的。所以非常简单的DDL。

00:06:49.810 --> 00:06:51.710
• 然后会发生什么？

00:06:51.710 --> 00:06:54.410
• 然后开始跟踪
版本，你会得到好处。

00:06:54.410 --> 00:06:55.970
• 冷却。是直接的吗

00:06:55.970 --> 00:06:58.065
立即，或是那样，

00:06:58.065 --> 00:06:59.250
需要重新启动。

00:06:59.250 --> 00:07:01.740
• 不重新启动。你只是在线。

00:07:01.740 --> 00:07:03.705
• 冷却。哇哇

00:07:03.705 --> 00:07:05.160
所以基本上，这就像

00:07:05.160 --> 00:07:08.545
一个非常酷的技术
非常快速地还原数据库。

00:07:08.545 --> 00:07:10.730
我还有别的吗？

00:07:10.730 --> 00:07:12.140
我是说这真的
非常令人印象深刻，但

00:07:12.140 --> 00:07:13.580
这些就像额外的好处。

00:07:13.580 --> 00:07:15.590
• 因此，在

00:07:15.590 --> 00:07:19.115
因为的方式
我们重用这些版本，

00:07:19.115 --> 00:07:22.470
我们不必保持作为
许多事务日志在线。

00:07:22.470 --> 00:07:24.920
所以，你可以截
事务日志更多

00:07:24.920 --> 00:07:28.725
积极到最后
检查站比你能之前。

00:07:28.725 --> 00:07:30.530
这意味着，如果你已经
得到了情况，

00:07:30.530 --> 00:07:32.540
我们有一个长期运行
保持你

00:07:32.540 --> 00:07:34.460
从能够截距

00:07:34.460 --> 00:07:36.620
您的日志和事务
日志开始爆炸，

00:07:36.620 --> 00:07:38.665
这不会发生
启用 ADR。

00:07:38.665 --> 00:07:41.400
* 所以基本上这是
额外的好处。

00:07:41.400 --> 00:07:43.650
无长事务
日志拖动。

00:07:43.650 --> 00:07:44.505
* 确切地说。

00:07:44.505 --> 00:07:45.990
我知道我会怎么做

00:07:45.990 --> 00:07:47.660
我的意思是MySQL服务器是去

00:07:47.660 --> 00:07:49.760
加速数据库
恢复现在。

00:07:49.760 --> 00:07:51.470
在这段视频之后，我会这样做。

00:07:51.470 --> 00:07:52.805
非常感谢大家的分享。

00:07:52.805 --> 00:07:53.345
谢谢

00:07:53.345 --> 00:07:55.940
* 感谢您的解释。
这一点非常清楚。

00:07:55.940 --> 00:07:57.575
谢谢你的收看。

00:07:57.575 --> 00:08:00.990
请喜欢和订阅和
敬请关注下一个。谢谢。

00:08:00.990 --> 00:08:13.210
[音乐]