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
[音樂]