WEBVTT

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

00:00:10.560 --> 00:00:12.975
>> Hej, Vítej v novém
epizodu exponovaných dat.

00:00:12.975 --> 00:00:14.460
Jmenuji se Pedro Lopes.

00:00:14.460 --> 00:00:16.920
Jsem správce programů v
Tým technologie SQL Server Engineering.

00:00:16.920 --> 00:00:18.510
Dnes budu mluvit

00:00:18.510 --> 00:00:20.670
o inteligentním
Databáze, konkrétně

00:00:20.670 --> 00:00:23.809
Inteligentní zpracování dotazů
na serveru SQL Server 2019,

00:00:23.809 --> 00:00:25.925
a také databáze SQL Azure.

00:00:25.925 --> 00:00:29.390
Tak se na to podíváme. Sql
Server 2019 zavádí

00:00:29.390 --> 00:00:31.864
průlomovací dotaz
vylepšení výkonu

00:00:31.864 --> 00:00:34.655
a jsou to inteligentní
Skupina zpracování dotazu.

00:00:34.655 --> 00:00:37.820
Tyto novinky tvoří nejnovější
Úkol společnosti Microsoft zajistit

00:00:37.820 --> 00:00:41.690
Toto kritické paralelní pracovní vytížení
zlepšení při běhu v měřítku,

00:00:41.690 --> 00:00:45.470
i když zůstává adaptivní na
neustále se měnící svět dat,

00:00:45.470 --> 00:00:47.855
Při přesunu dat a
z databází.

00:00:47.855 --> 00:00:49.670
V tomto videu vám dám

00:00:49.670 --> 00:00:51.980
Stručný přehled
Inteligentní databázový svět

00:00:51.980 --> 00:00:53.030
to opravdu chce skok

00:00:53.030 --> 00:00:56.150
vpřed s nadcházejícím
SQL Server 2019,

00:00:56.150 --> 00:00:58.700
a Představte si číslo
vlastností, které budeme potápět

00:00:58.700 --> 00:01:02.130
do hlubšího
videa v této řadě.

00:01:03.170 --> 00:01:07.510
Inteligentní zpracování dotazů
na serveru SQL Server je k dispozici

00:01:07.510 --> 00:01:11.245
výchozí v nejnovější databázi
nastavení úrovně kompatibility.

00:01:11.245 --> 00:01:13.210
To znamená, že po inovaci

00:01:13.210 --> 00:01:15.130
Tato možnost může být k dispozici pouze v

00:01:15.130 --> 00:01:18.000
přepínejte přepínač na použití
nejnovější nastavení kompatibility.

00:01:18.000 --> 00:01:22.030
Inteligentní zpracování dotazů
poskytuje také široký dopad

00:01:22.030 --> 00:01:23.440
zlepšující výkon

00:01:23.440 --> 00:01:26.650
existující pracovní vytížení s
minimálního úsilí o provedení.

00:01:26.650 --> 00:01:28.390
To opravdu znamená,

00:01:28.390 --> 00:01:30.965
není třeba
přečinitel svého kódu.

00:01:30.965 --> 00:01:33.310
Inteligentní zpracování dotazů zlepšuje

00:01:33.310 --> 00:01:36.190
kritické paralelní pracovní vytížení
při běhu v měřítku,

00:01:36.190 --> 00:01:39.355
a jak data proudí dovnitř a
z databáze,

00:01:39.355 --> 00:01:41.380
přizpůsobíme se tomu a

00:01:41.380 --> 00:01:44.660
udržovat úroveň
předvídatelným výkonem.

00:01:44.660 --> 00:01:47.450
Například zavedením

00:01:47.450 --> 00:01:49.880
mechanismus zpětné vazby
do využití paměti,

00:01:49.880 --> 00:01:53.630
můžeme zajistit, aby vaše pracovní vytížení
prováděn předvídatelným způsobem.

00:01:53.630 --> 00:01:58.190
Pokud by dané spuštění dotazu
Možná zabere moc paměti,

00:01:58.190 --> 00:01:59.750
Můžeme to napravit a

00:01:59.750 --> 00:02:02.375
zvýšit souběžnost
faktorem databáze.

00:02:02.375 --> 00:02:06.020
Pokud dané provedení vlastního kapitálu
nezískáte dostatek paměti a

00:02:06.020 --> 00:02:09.560
končí pomocí dalších vstupně-výstupních
v celém rozsahu je známá jako skvrna,

00:02:09.560 --> 00:02:11.315
pak můžeme také zjistit, že

00:02:11.315 --> 00:02:13.565
a napravit situaci
tak, aby operace

00:02:13.565 --> 00:02:15.260
spouští v paměti a

00:02:15.260 --> 00:02:18.200
provádí podle očekávání v
následných poprav.

00:02:18.200 --> 00:02:20.540
Tato funkce je nyní povolena pro

00:02:20.540 --> 00:02:22.835
všechny režimy spuštění v
databázového centra.

00:02:22.835 --> 00:02:27.170
Dávkový režim pro další datový sklad
a analytické pracovní zatížení,

00:02:27.170 --> 00:02:31.410
a řádkového režimu pro vaši
kritické zatížení OLTP.

00:02:31.700 --> 00:02:34.640
Jedeme také do nových oblastí

00:02:34.640 --> 00:02:37.220
kterým voláme
přibližné zpracování dotazů.

00:02:37.220 --> 00:02:40.640
Představte si například scénář
kde vede železniční společnost

00:02:40.640 --> 00:02:42.350
Přehled počtu lístků, které jsou

00:02:42.350 --> 00:02:44.935
koupené a používané v
celého železničního systému.

00:02:44.935 --> 00:02:47.030
Sledují tento
za účelem provedení

00:02:47.030 --> 00:02:49.730
Některé míry řízení toku
Pokud je to potřeba,

00:02:49.730 --> 00:02:52.610
Možná přizpůsobením
jízdní řády vlaků,

00:02:52.610 --> 00:02:53.630
nebo počet vlaků v

00:02:53.630 --> 00:02:55.810
systém, který má splňovat
potřeby okamžiku.

00:02:55.810 --> 00:02:58.920
Tyto informace jsou také
aktualizace v řídicím panelu

00:02:58.920 --> 00:03:02.530
že lidi v centru
Centrum se může podívat.

00:03:02.530 --> 00:03:04.220
Nyní, v tomto scénáři, je součástí

00:03:04.220 --> 00:03:06.830
pracovní vytížení bude jistě
spustíte dotaz, který je

00:03:06.830 --> 00:03:09.020
stále se dítím na získání

00:03:09.020 --> 00:03:12.005
počet řádků všech
prodané a použité jízdenky,

00:03:12.005 --> 00:03:14.600
a to je pravděpodobně
pochází z velmi

00:03:14.600 --> 00:03:17.605
Velká stáj, možná s
miliardy a miliardy řad.

00:03:17.605 --> 00:03:20.540
Nyní tento opakující se dotaz
by normálně

00:03:20.540 --> 00:03:23.735
značné množství prostředků na
váš server, jmenovitě paměť.

00:03:23.735 --> 00:03:25.639
Pokud je proveden opakovaně,

00:03:25.639 --> 00:03:26.690
může skutečně ovlivnit

00:03:26.690 --> 00:03:28.900
výkonnostní charakteristiky
databáze.

00:03:28.900 --> 00:03:30.670
V tomto scénáři však

00:03:30.670 --> 00:03:32.750
železniční společnost
nemusí nutně potřebovat

00:03:32.750 --> 00:03:35.830
skutečný počet všech
prodaných a použitých vstupenek.

00:03:35.830 --> 00:03:37.790
Ale velmi vysoká
přibližování je dostačující

00:03:37.790 --> 00:03:40.280
k aktivaci všech
požadované rozhodovací rozhodování.

00:03:40.280 --> 00:03:42.935
Zde je přibližný
se objeví odlišní počet,

00:03:42.935 --> 00:03:45.500
povolením dotazu
pro opakované získání

00:03:45.500 --> 00:03:48.185
přibližený počet
prodaných a použitých jízdenek

00:03:48.185 --> 00:03:51.080
bez vážných dopadů na
výkon databáze, který

00:03:51.080 --> 00:03:55.420
dotaz na normální počet
Dnes zabere.

00:03:55.640 --> 00:03:58.695
Povolením dávkového režimu v úložišti řádků,

00:03:58.695 --> 00:03:59.950
účinně rozpoutáme

00:03:59.950 --> 00:04:02.150
režim zpracování, který je
zvláště optimalizované

00:04:02.150 --> 00:04:05.975
pro analytické pracovní zatížení nad
libovolné tabulky v databázi.

00:04:05.975 --> 00:04:08.180
To znamená, že i
pro scénáře, ve kterých

00:04:08.180 --> 00:04:10.385
index úložiště sloupců
by nebyla možnost,

00:04:10.385 --> 00:04:14.395
databázový stroj může stále
provést tento způsob optimalizovaným způsobem.

00:04:14.395 --> 00:04:17.375
To zase otevírá rozsah

00:04:17.375 --> 00:04:20.630
funkce jako adaptivní spojení
pro použití v pracovním vytížení.

00:04:20.630 --> 00:04:24.170
Adaptivní spojení, které je pouze
k dispozici v dávkovém režimu, může

00:04:24.170 --> 00:04:28.940
nyní být zadlužena přes všechny
tabulky a většinu pracovní zátěže.

00:04:29.590 --> 00:04:33.170
Zabýváme se také některými
Většina opakujících se antivzorků

00:04:33.170 --> 00:04:36.260
které se stanou problémem pro
spravované pracovní vytížení serveru SQL.

00:04:36.260 --> 00:04:38.150
Použití tabulky
Proměnné a použití

00:04:38.150 --> 00:04:40.105
například skalární UDFs,

00:04:40.105 --> 00:04:42.440
a nyní můžeme odemknout nové úrovně

00:04:42.440 --> 00:04:46.375
optimalizace dotazu, která byla
až donedávna nebylo možné.

00:04:46.375 --> 00:04:49.310
Tohle všechno, budeme
diskutovat hlouběji a s

00:04:49.310 --> 00:04:51.080
ukázky v nadcházejících videích

00:04:51.080 --> 00:04:53.270
série o
Inteligentní databáze,

00:04:53.270 --> 00:04:56.020
konkrétně inteligentní
zpracování dotazu.

00:04:56.020 --> 00:04:59.505
Ale jestli chceš vědět
o tom dnes více,

00:04:59.505 --> 00:05:04.200
pak prosím přejděte na tento aka.ms/IQP

00:05:04.200 --> 00:05:06.899
Adresa URL, na které vidíte všechny
dokumentaci

00:05:06.899 --> 00:05:09.535
Inteligentní dotaz
Zpracování v databázích SQL.

00:05:09.535 --> 00:05:13.100
Chcete-li vyzkoušet některé
z toho právě teď,

00:05:13.100 --> 00:05:16.040
Máme také ukázky, které
Můžete se podívat, jestli jste

00:05:16.040 --> 00:05:18.980
Přejít do našeho úložiště GitHub
a Krátká adresa URL by

00:05:18.980 --> 00:05:22.430
být aka.ms/IQPDemos, kde budete

00:05:22.430 --> 00:05:25.900
mít možnost podívat se na všechny tyto
funkce a experiment.

00:05:25.900 --> 00:05:27.795
Tak znovu, dávej na sebe pozor.

00:05:27.795 --> 00:05:28.980
Brzy si promluvíme.

00:05:28.980 --> 00:05:43.780
[HUDBA].