WEBVTT

00:00:00.000 --> 00:00:10.500
[MUZYKA].

00:00:10.500 --> 00:00:12.270
>> Witam mam na imię PAM,

00:00:12.270 --> 00:00:15.495
i jestem menedżerem programu z
zespołu inżynierów programu SQL Server.

00:00:15.495 --> 00:00:17.790
Dzisiaj chciałbym zrobić
szybkie demo dla Ciebie

00:00:17.790 --> 00:00:19.800
na jednym z nowych
funkcje programu SQL Server.

00:00:19.800 --> 00:00:23.310
2019 Pamięć zoptymalizowana pod kątem pamięci
Metadane TempDB.

00:00:23.310 --> 00:00:26.070
Już zrobiłem
przegląd wideo na

00:00:26.070 --> 00:00:27.480
tej funkcji, w której
Mówię trochę

00:00:27.480 --> 00:00:29.040
o niektórych wyzwaniach z

00:00:29.040 --> 00:00:32.295
TempDB wydajność, która
mogły stawić czoła w przeszłości i

00:00:32.295 --> 00:00:35.850
o pracy robimy w 2019
do poprawy wydajności TempDB.

00:00:35.850 --> 00:00:38.945
Więc zachęcam do oglądania, że
wideo, jeśli jeszcze go nie widziałem.

00:00:38.945 --> 00:00:41.600
Co będziemy robić
w tym demo dziś jest

00:00:41.600 --> 00:00:45.185
koncentrując się na pamięci zoptymalizowanej
Funkcja metadanych TempDB,

00:00:45.185 --> 00:00:46.805
jak go włączysz,

00:00:46.805 --> 00:00:47.975
jak to wyłączyć.

00:00:47.975 --> 00:00:49.640
Ale także, jak można

00:00:49.640 --> 00:00:51.790
stwierdzić, czy trzeba
włączyć tę funkcję.

00:00:51.790 --> 00:00:55.600
Czy masz problem, który
Ta funkcja jest przeznaczona do rozwiązania?

00:00:55.600 --> 00:00:58.770
Przejdźmy więc do
demo i przyjrzyj się.

00:01:00.220 --> 00:01:02.960
Mam więc Notebook otwarty tutaj w

00:01:02.960 --> 00:01:05.420
Usługa Azure Data Studio
z kilkoma poleceniami.

00:01:05.420 --> 00:01:09.050
Co Zacznijmy od działa
obciążenie pracą na SQL Server.

00:01:09.050 --> 00:01:14.315
2019 bez włączania pamięci
Zoptymalizowana funkcja metadanych TempDB

00:01:14.315 --> 00:01:15.560
i postaramy się przyjrzeć

00:01:15.560 --> 00:01:17.930
tego twierdzenia, że
może się zdarzyć w TempDB.

00:01:17.930 --> 00:01:21.050
Więc pierwszą rzeczą, którą jestem
zamiar zrobić, to zacząć

00:01:21.050 --> 00:01:24.170
monitora wydajności
zbierania i zbierania

00:01:24.170 --> 00:01:26.120
kilka różnych
liczniki, które dadzą

00:01:26.120 --> 00:01:28.430
nam pomysł
wydajności pracy.

00:01:28.430 --> 00:01:31.955
Następnie zamierzam użyć
Narzędzie O naprężenie

00:01:31.955 --> 00:01:34.415
, aby uruchomić wielowątkowe obciążenie pracą.

00:01:34.415 --> 00:01:37.700
Mam więc osiem procesorów
na tej konkretnej maszynie,

00:01:37.700 --> 00:01:39.950
ale jestem rzucanie 100
współbieżnych wątków.

00:01:39.950 --> 00:01:42.350
Więc mam bardzo zajęty obciążenia

00:01:42.350 --> 00:01:44.810
tu i to bardzo
ciężkich TempDB obciążenia.

00:01:44.810 --> 00:01:47.210
Jest to podstawowa procedura składowana
tworzącą tabelę tymczaso-

00:01:47.210 --> 00:01:48.360
umieścić w nim pewne dane,

00:01:48.360 --> 00:01:49.805
a następnie wybiera z niego.

00:01:49.805 --> 00:01:52.200
Więc można zobaczyć tutaj w Perf człowieka.

00:01:52.200 --> 00:01:54.090
Mam kilka ciężarów w toku,

00:01:54.090 --> 00:01:55.740
szerokości zatrzasku strony w toku.

00:01:55.740 --> 00:01:58.895
Ive ' także dostał ten średni czekać czas

00:01:58.895 --> 00:02:00.380
również w Perf Man.

00:02:00.380 --> 00:02:02.390
Więc można zobaczyć, że mam
Ciężar zatrzasku stronicowanej

00:02:02.390 --> 00:02:04.775
dzieje się, gdy jestem
uruchomione to obciążenie pracą.

00:02:04.775 --> 00:02:07.640
To nie jest niezwykłe z
mocno współbieżne obciążenie pracą.

00:02:07.640 --> 00:02:11.580
Pytanie o to, co jest
te strony zatrzask wagi?

00:02:11.580 --> 00:02:12.770
Nie wiemy koniecznie.

00:02:12.770 --> 00:02:14.405
Mogą one być z
bazy danych użytkownika.

00:02:14.405 --> 00:02:16.430
Mogą być z TempDB.

00:02:16.430 --> 00:02:18.740
Naprawdę nie wiemy tylko
patrząc na wydajność

00:02:18.740 --> 00:02:21.620
Monitor, w którym te strony zatrzasnąć
wagi.

00:02:21.620 --> 00:02:23.210
Więc chcemy wrócić do

00:02:23.210 --> 00:02:25.850
Azure Data Studio i przyjrzeć się

00:02:25.850 --> 00:02:27.110
skrypt, który może nam pomóc

00:02:27.110 --> 00:02:30.880
określić, gdzie te strony
zapadki.

00:02:30.880 --> 00:02:32.230
Wygląda na to, moje obciążenia zakończone.

00:02:32.230 --> 00:02:34.190
Więc jestem po prostu zamiar kopać
ponownie, aby

00:02:34.190 --> 00:02:36.925
można spojrzeć na to Azure Data Studio.

00:02:36.925 --> 00:02:40.090
Więc Wróćmy tutaj.

00:02:42.130 --> 00:02:47.135
Zamierzam uruchomić tę kwerendę
które mam w centrum uwagi.

00:02:47.135 --> 00:02:51.740
Co robi ta kwerenda jest
patrząc na wszystkie wnioski

00:02:51.740 --> 00:02:56.510
DM dokładne żądanie, które
Typ wagi jak strona,

00:02:56.510 --> 00:03:00.335
czyli pewnego rodzaju
Ciężar zatrzasku strony.

00:03:00.335 --> 00:03:04.010
Co mogę zobaczyć w wynikach
o to, że faktycznie mam

00:03:04.010 --> 00:03:07.295
kilka sesji, które są
oczekiwanie na zatrzask strony.

00:03:07.295 --> 00:03:09.305
Jeśli patrzę na zasób wagi,

00:03:09.305 --> 00:03:11.990
Mogę powiedzieć tylko z wagi
zasobów, które są w

00:03:11.990 --> 00:03:15.905
TempDB ponieważ waga
zasób tutaj jest 2:1:1:20.

00:03:15.905 --> 00:03:17.420
Dwa to identyfikator bazy danych,

00:03:17.420 --> 00:03:18.665
dwa, które jest TempDB.

00:03:18.665 --> 00:03:23.570
Jednym z nich jest numer pliku 1 i
następnie 120 jest numerem strony.

00:03:23.570 --> 00:03:25.325
Więc mogę powiedzieć, że jest w TempDB.

00:03:25.325 --> 00:03:30.395
Ale jeśli używam tej nowej funkcji
zwane informacjami o stronie DMDB,

00:03:30.395 --> 00:03:34.039
Co to pozwala mi zrobić
jest podjęcie tego zasobu strony

00:03:34.039 --> 00:03:38.330
i roztrzaskać ono otworzyć i zobaczyć
co dokładnie znajduje się na tej stronie.

00:03:38.330 --> 00:03:41.355
Więc z tej funkcji info strony DMDB,

00:03:41.355 --> 00:03:44.150
Dostałam ten obiekt
nazwę i można zobaczyć

00:03:44.150 --> 00:03:46.810
tutaj, że nazwa obiektu
jest sys obiektów schematu,

00:03:46.810 --> 00:03:48.095
który jest tabelą systemową.

00:03:48.095 --> 00:03:50.944
Tak to jest, że TempDB
Rywalizacja metadanych

00:03:50.944 --> 00:03:52.685
o których mówiliśmy.

00:03:52.685 --> 00:03:54.754
To jest problem

00:03:54.754 --> 00:03:58.220
że pamięć zoptymalizowana TempDB
metadanych został wprowadzony do rozwiązania.

00:03:58.220 --> 00:03:59.960
Więc Wróćmy do
naszego okna poleceń.

00:03:59.960 --> 00:04:01.115
Widzimy, że skończyła.

00:04:01.115 --> 00:04:02.450
Obydwaj czasy ono wykonany,

00:04:02.450 --> 00:04:06.005
zajęło około 52 sekund
, aby uruchomić obciążenie pracą.

00:04:06.005 --> 00:04:09.675
Możemy oczywiście zobaczyć stronę
zatrzask ciężarów dzieje.

00:04:09.675 --> 00:04:12.300
Możemy zobaczyć partię
żądań na sekundę,

00:04:12.300 --> 00:04:14.100
które są na szczycie,

00:04:14.100 --> 00:04:18.225
Zobaczmy tutaj, o 350 maksimum.

00:04:18.225 --> 00:04:20.210
Więc to bez
włączona funkcja.

00:04:20.210 --> 00:04:22.265
Więc przejdźmy do przodu i
włączyć tę funkcję.

00:04:22.265 --> 00:04:23.795
Aby to zrobić,

00:04:23.795 --> 00:04:25.925
Musimy włączyć funkcję w

00:04:25.925 --> 00:04:29.090
SQL Server i potrzebujemy również
, aby ponownie uruchomić serwer.

00:04:29.090 --> 00:04:34.250
Ta konfiguracja serwera ALTER
polecenie wymaga ponownego uruchomienia komputera.

00:04:34.250 --> 00:04:38.875
Więc mamy zamiar ustawić, że pamięć
Zoptymalizowane metadane TempDB na.

00:04:38.875 --> 00:04:43.540
Potem pójdę dalej i
Zrestartuj serwer.

00:04:44.360 --> 00:04:48.025
Wtedy, gdy to zrobię,

00:04:48.025 --> 00:04:50.810
Będę w stanie wrócić

00:04:50.810 --> 00:04:54.155
do usługi Azure Data Studio i
uruchomić inne polecenie,

00:04:54.155 --> 00:04:57.470
Wybierz właściwość serwera
polecenie, aby sprawdzić, czy

00:04:57.470 --> 00:05:01.160
TempDB zoptymalizowany pamięci
Funkcja metadanych jest włączona.

00:05:01.160 --> 00:05:03.265
Więc niech uruchomić to polecenie.

00:05:03.265 --> 00:05:07.245
Możesz zobaczyć to wykonane
i funkcja jest teraz włączona.

00:05:07.245 --> 00:05:10.565
To jeden. Więc przejdźmy do przodu
i ponownie uruchomić nasze obciążenie pracą.

00:05:10.565 --> 00:05:13.470
Zacznijmy perf człowieka.

00:05:16.490 --> 00:05:19.350
Zacznijmy od naszego obciążenia ponownie.

00:05:19.350 --> 00:05:20.775
Same dokładne obciążeń.

00:05:20.775 --> 00:05:24.130
Ta sama procedura składowana, 100 wątki.

00:05:24.130 --> 00:05:27.080
Można zauważyć coś
w Perf Man od razu.

00:05:27.080 --> 00:05:29.900
Po pierwsze, żądania wsadowe
na sekundę jest znacznie wyższa.

00:05:29.900 --> 00:05:34.520
Idziemy do ponad 500.

00:05:34.520 --> 00:05:36.320
To może nawet pójść trochę wyżej.

00:05:36.320 --> 00:05:37.580
Dam, że biegać na chwilę,

00:05:37.580 --> 00:05:40.790
ale również zauważyć te strony
nie zostały usunięte ciężary zatrzasku.

00:05:40.790 --> 00:05:42.605
Nie więcej grubości zatrzasku strony.

00:05:42.605 --> 00:05:45.740
Jeśli wrócimy do usługi Azure Data
Studio i uruchamiam to polecenie

00:05:45.740 --> 00:05:48.990
ponownie, aby spojrzeć na sesje.

00:05:48.990 --> 00:05:52.310
Zauważ, że nie ma sesji
oczekujących na zatrzask strony.

00:05:52.310 --> 00:05:55.865
Całkowicie wyeliminowaliśmy
Grubość zatrzasku strony.

00:05:55.865 --> 00:05:57.590
Jeśli wróci do perf człowieka,

00:05:57.590 --> 00:06:00.005
yep, moje obciążenie pracą jest już zakończona.

00:06:00.005 --> 00:06:02.990
Więc widać, że
lepszą przepustowość.

00:06:02.990 --> 00:06:05.675
Wyeliminowałem te
Grubość zatrzasku strony.

00:06:05.675 --> 00:06:07.580
Jeśli przychodzę do mojego obciążenia,

00:06:07.580 --> 00:06:10.130
jego ' teraz zakończony w 35 sekundy

00:06:10.130 --> 00:06:13.760
w porównaniu z 52 sekund
bez tej funkcji.

00:06:13.760 --> 00:06:19.220
Więc ta funkcja jest zaprojektowana
, aby umożliwić Ci pomoc w skali

00:06:19.220 --> 00:06:23.240
się ciężki TempDB
obciążeń spornych

00:06:23.240 --> 00:06:25.400
bez dokonywania
zmiany kodu w ogóle.

00:06:25.400 --> 00:06:28.085
Po prostu Włącz konfigurację,

00:06:28.085 --> 00:06:31.640
Zrestartuj serwer i wtedy
może natychmiast poprawić

00:06:31.640 --> 00:06:33.770
przepustowość i mniej
Ciężar zatrzasku strony

00:06:33.770 --> 00:06:36.320
na Twoje TempDB kontrowersyjne obciążeń.

00:06:36.320 --> 00:06:38.300
Więc mam nadzieję, że pomoże Ci nauczyć się

00:06:38.300 --> 00:06:40.790
nieco więcej na temat
, jak można go używać,

00:06:40.790 --> 00:06:42.860
jak byś wiedział, czy
musisz go włączyć

00:06:42.860 --> 00:06:45.020
Czy nie i dostaje trochę więcej

00:06:45.020 --> 00:06:46.970
podekscytowany poprawą
które idą w

00:06:46.970 --> 00:06:49.610
SQL Server 2019 dzięki bardzo dużo.

00:06:49.610 --> 00:07:04.210
MUZYKI