WEBVTT

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

00:00:10.500 --> 00:00:12.270
>> Ahoj jmenuji se Pam,

00:00:12.270 --> 00:00:15.495
a jsem správce programů s
týmu technologie SQL Server Engineering.

00:00:15.495 --> 00:00:17.790
Dnes bych chtěl
Rychlá ukázka pro vás

00:00:17.790 --> 00:00:19.800
na jednom z nových
funkcí serveru SQL Server.

00:00:19.800 --> 00:00:23.310
2019 paměť optimalizovaná
Metadata databáze TempDB.

00:00:23.310 --> 00:00:26.070
Už jsem udělal
Přehled videa

00:00:26.070 --> 00:00:27.480
tuto funkci, kde
Trochu mluvím

00:00:27.480 --> 00:00:29.040
o některých výzvách k

00:00:29.040 --> 00:00:32.295
Výkon TempDB, který jste
mohlo v minulosti čelit a

00:00:32.295 --> 00:00:35.850
o práci, kterou děláme v roce 2019
ke zlepšení výkonu databáze TempDB.

00:00:35.850 --> 00:00:38.945
Tak vás povzbuzím, abyste se díval
video, pokud jste to ještě neviděli.

00:00:38.945 --> 00:00:41.600
Co budeme dělat
v této ukázce je dnes

00:00:41.600 --> 00:00:45.185
zaměření na paměť optimalizovanou
Funkce metadat TempDB,

00:00:45.185 --> 00:00:46.805
jak ji povolíte,

00:00:46.805 --> 00:00:47.975
Jak byste ho zakázali.

00:00:47.975 --> 00:00:49.640
Ale také, jak můžete

00:00:49.640 --> 00:00:51.790
zjistit, zda je nutné
tuto funkci zapnout.

00:00:51.790 --> 00:00:55.600
Máte potíže, které
je tato funkce určena k řešení?

00:00:55.600 --> 00:00:58.770
Tak pojďme skočit do
demo a podívejte se.

00:01:00.220 --> 00:01:02.960
Takže mám otevřený zápisník v

00:01:02.960 --> 00:01:05.420
Azurové datové Studio
s několika příkazy.

00:01:05.420 --> 00:01:09.050
To, s čím začneme, běží
pracovní vytížení na serveru SQL Server.

00:01:09.050 --> 00:01:14.315
2019 bez povolení paměti
Funkce optimalizované metadata databáze TempDB

00:01:14.315 --> 00:01:15.560
a pokusíme se podívat na

00:01:15.560 --> 00:01:17.930
Toto tvrzení, že
může se stát v databázi TempDB.

00:01:17.930 --> 00:01:21.050
Takže první věc, kterou jsem
bude třeba začít

00:01:21.050 --> 00:01:24.170
sledování výkonu
sběr a sběr

00:01:24.170 --> 00:01:26.120
několik různých
čítače, které budou poskytovat

00:01:26.120 --> 00:01:28.430
nám nápad
výkon pracovní zátěže.

00:01:28.430 --> 00:01:31.955
Pak se chystám použít
Nástroj O zátěži

00:01:31.955 --> 00:01:34.415
pro spuštění vícevláknového pracovního vytížení.

00:01:34.415 --> 00:01:37.700
Takže mám osm procesorů
na tomto konkrétním stroji,

00:01:37.700 --> 00:01:39.950
ale házím 100
souběžných podprocesů.

00:01:39.950 --> 00:01:42.350
Takže mám velmi zaneprázdněný pracovní vytížení

00:01:42.350 --> 00:01:44.810
tady a je to velmi
těžké pracovní vytížení TempDB.

00:01:44.810 --> 00:01:47.210
Jedná se o základní uloženou proceduru
vytvářející dočasnou tabulku,

00:01:47.210 --> 00:01:48.360
do něj vložit nějaká data,

00:01:48.360 --> 00:01:49.805
a pak z něj vybere.

00:01:49.805 --> 00:01:52.200
Takže tu můžete vidět v "Perf".

00:01:52.200 --> 00:01:54.090
Mám nějaké váhy,

00:01:54.090 --> 00:01:55.740
vah západky stránky.

00:01:55.740 --> 00:01:58.895
Mám také průměrnou čekací dobu

00:01:58.895 --> 00:02:00.380
v tomto seznamu uveden i v poli "perf Man".

00:02:00.380 --> 00:02:02.390
Takže můžeš vidět, že mám
závaží stránkovaného zámku

00:02:02.390 --> 00:02:04.775
se děje, když jsem
s tímto zatížením.

00:02:04.775 --> 00:02:07.640
To není neobvyklé u
silně souběžné pracovní zátěže.

00:02:07.640 --> 00:02:11.580
Otázkou je, co se
jsou tyto váhy zámku stránky z?

00:02:11.580 --> 00:02:12.770
To nevíme nutně.

00:02:12.770 --> 00:02:14.405
Mohou být z
uživatelské databáze.

00:02:14.405 --> 00:02:16.430
Mohou být z TempDB.

00:02:16.430 --> 00:02:18.740
Opravdu nevíme jen
pohledem na výkon

00:02:18.740 --> 00:02:21.620
sledovat, kde se tyto západky stránek
závaží přicházejí.

00:02:21.620 --> 00:02:23.210
Takže se chceme vrátit k

00:02:23.210 --> 00:02:25.850
Azure Data Studio a Prohlédněte si

00:02:25.850 --> 00:02:27.110
skript, který nám může pomoci

00:02:27.110 --> 00:02:30.880
určit, kde tato stránka
závaží z západky.

00:02:30.880 --> 00:02:32.230
Vypadá to, že jsem dokončil pracovní vytížení.

00:02:32.230 --> 00:02:34.190
Tak ho prostě vykopnu
znovu se vrátit, abychom

00:02:34.190 --> 00:02:36.925
může se podívat na ten Azure Data Studio.

00:02:36.925 --> 00:02:40.090
Tak pojďme zpátky.

00:02:42.130 --> 00:02:47.135
Chci spustit tento dotaz
které mám na výběr.

00:02:47.135 --> 00:02:51.740
Co tento dotaz dělá, je
pohled na všechny požadavky z

00:02:51.740 --> 00:02:56.510
DM přesný požadavek, který má
typ závaží, jako je stránka,

00:02:56.510 --> 00:03:00.335
což znamená nějaký druh
váha zámku stránky.

00:03:00.335 --> 00:03:04.010
Co je ve výsledcích vidět
Tady je, že opravdu mám

00:03:04.010 --> 00:03:07.295
několik relací, které jsou
čekání na západku stránky.

00:03:07.295 --> 00:03:09.305
Pokud se podívám na hmotnostní zdroj,

00:03:09.305 --> 00:03:11.990
Můžu to říct jen z váhy
zdroj, ve kterém jsou

00:03:11.990 --> 00:03:15.905
TempDB, protože váha
zdroj je 2:1:1:20.

00:03:15.905 --> 00:03:17.420
Dva je ID databáze,

00:03:17.420 --> 00:03:18.665
dva, což je TempDB.

00:03:18.665 --> 00:03:23.570
Jedno je číslo souboru 1 a
pak 120 je číslo stránky.

00:03:23.570 --> 00:03:25.325
Takže můžu říct, že je to v TempDB.

00:03:25.325 --> 00:03:30.395
Ale když budu používat tuto novou funkci
informace o stránce DMDB,

00:03:30.395 --> 00:03:34.039
Co to umožňuje
bere tento prostředek stránky

00:03:34.039 --> 00:03:38.330
a otevři ho a uvidíš
Co přesně je na této stránce.

00:03:38.330 --> 00:03:41.355
Z této funkce informací o stránce DMDB tedy

00:03:41.355 --> 00:03:44.150
Tento objekt se nachází
jméno a můžete zobrazit

00:03:44.150 --> 00:03:46.810
zde, že název objektu
je sys Object schématu,

00:03:46.810 --> 00:03:48.095
což je systémová tabulka.

00:03:48.095 --> 00:03:50.944
Takže to je to, že TempDB
konflikty metadat

00:03:50.944 --> 00:03:52.685
o tom, o čem jsme mluvili.

00:03:52.685 --> 00:03:54.754
Jedná se o problém

00:03:54.754 --> 00:03:58.220
to, že paměť optimalizována TempDB
byla zavedena metadata pro řešení.

00:03:58.220 --> 00:03:59.960
Tak pojďme zpátky do
Naše příkazové okno.

00:03:59.960 --> 00:04:01.115
Můžeme vidět, že to skončilo.

00:04:01.115 --> 00:04:02.450
V obou případech, kdy byla vykonána,

00:04:02.450 --> 00:04:06.005
trvalo asi 52 sekund
pro spuštění pracovního vytížení.

00:04:06.005 --> 00:04:09.675
Můžeme samozřejmě vidět stránku
závaží západky.

00:04:09.675 --> 00:04:12.300
Můžeme vidět tu dávku
požadavků za sekundu,

00:04:12.300 --> 00:04:14.100
které se vyvrcholují,

00:04:14.100 --> 00:04:18.225
Podívejme, asi 350 maximum.

00:04:18.225 --> 00:04:20.210
Takže bez
funkce zapnuta.

00:04:20.210 --> 00:04:22.265
Tak pojďme a
zapněte tuto funkci.

00:04:22.265 --> 00:04:23.795
Za tímto účelem

00:04:23.795 --> 00:04:25.925
je nutné povolit tuto funkci v

00:04:25.925 --> 00:04:29.090
SQL Server a také potřebujeme
Restartujte server.

00:04:29.090 --> 00:04:34.250
Tato změna konfigurace serveru
příkazu vyžaduje restartování.

00:04:34.250 --> 00:04:38.875
Takže si tu paměť dáme
Optimalizovaná metadata databáze TempDB.

00:04:38.875 --> 00:04:43.540
Tak já půjdu napřed a
Restartujte server.

00:04:44.360 --> 00:04:48.025
Tak jednou to udělám,

00:04:48.025 --> 00:04:50.810
Budu se moct vrátit

00:04:50.810 --> 00:04:54.155
do Azure Data Studio a
spustit jiný příkaz,

00:04:54.155 --> 00:04:57.470
vybrat vlastnost serveru
a zjistěte, zda

00:04:57.470 --> 00:05:01.160
optimalizace paměti TempDB
je funkce metadat zapnuta.

00:05:01.160 --> 00:05:03.265
Takže spustme tento příkaz.

00:05:03.265 --> 00:05:07.245
Můžete ji vidět popravit
a tato funkce je nyní zapnuta.

00:05:07.245 --> 00:05:10.565
To je jeden. Tak pojďme
a znovu si spusťte práci.

00:05:10.565 --> 00:05:13.470
Začneme s mužem.

00:05:16.490 --> 00:05:19.350
Pojďme zase vykopnout pracovní vytížení.

00:05:19.350 --> 00:05:20.775
Přesně stejné pracovní zatížení.

00:05:20.775 --> 00:05:24.130
Stejná uložená procedura, 100 podprocesů.

00:05:24.130 --> 00:05:27.080
Možná si všimnete něčeho
v tom muži jsou různí.

00:05:27.080 --> 00:05:29.900
Nejprve dávkové požadavky
za sekundu je mnohem vyšší.

00:05:29.900 --> 00:05:34.520
Jdeme na to přes 500.

00:05:34.520 --> 00:05:36.320
Možná by to šlo ještě trochu výš.

00:05:36.320 --> 00:05:37.580
Nechám to na chvíli běžet,

00:05:37.580 --> 00:05:40.790
ale Všimněte si také této stránky
závaží západky jsou pryč.

00:05:40.790 --> 00:05:42.605
Žádné další váhy zámku stránky.

00:05:42.605 --> 00:05:45.740
Když se vrátíme k Azure datům
Studio a já tento příkaz spustím

00:05:45.740 --> 00:05:48.990
znovu a Prohlédněte si relace.

00:05:48.990 --> 00:05:52.310
Všimněte si, že neexistují žádné relace
čekající na západku stránky.

00:05:52.310 --> 00:05:55.865
Úplně jsme eliminovali
závaží zámku stránky.

00:05:55.865 --> 00:05:57.590
Když se vrátím k perf,

00:05:57.590 --> 00:06:00.005
Jo, pracovní vytížení už skončilo.

00:06:00.005 --> 00:06:02.990
Takže můžeš vidět, že jsem
zlepšenou propustnost.

00:06:02.990 --> 00:06:05.675
Odstranil jsem ty
závaží zámku stránky.

00:06:05.675 --> 00:06:07.580
Když přijdu na pracovní vytížení,

00:06:07.580 --> 00:06:10.130
Nyní je dokončena za 35 sekund.

00:06:10.130 --> 00:06:13.760
oproti 52 sekund
bez této funkce.

00:06:13.760 --> 00:06:19.220
Tato funkce je tedy navržena
vám umožní škálovat

00:06:19.220 --> 00:06:23.240
Vaše silná databáze TempDB
sporná pracovní zátěž

00:06:23.240 --> 00:06:25.400
bez provedení
změny kódu.

00:06:25.400 --> 00:06:28.085
Jednoduše zapnete konfiguraci,

00:06:28.085 --> 00:06:31.640
Restartujte server a potom
lze okamžitě zlepšit

00:06:31.640 --> 00:06:33.770
propustnost a menší
závaží zámku stránky

00:06:33.770 --> 00:06:36.320
ve sporných pracovních vytížení aplikace TempDB.

00:06:36.320 --> 00:06:38.300
Doufám, že vám to pomůže naučit se

00:06:38.300 --> 00:06:40.790
trochu víc o
funkce, jak ji používat,

00:06:40.790 --> 00:06:42.860
Jak byste mohl vědět, zda
je třeba ji zapnout

00:06:42.860 --> 00:06:45.020
nebo ne a dostane tě trochu víc

00:06:45.020 --> 00:06:46.970
vzrušení z vylepšení
které přicházejí

00:06:46.970 --> 00:06:49.610
SQL Server 2019 díky moc.

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