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