WEBVTT

00:00:00.000 --> 00:00:02.055
>> Obnovení databáze s

00:00:02.055 --> 00:00:05.190
dlouhotrvající transakce
byl výzvou.

00:00:05.190 --> 00:00:07.050
Na serveru SQL Server 2019

00:00:07.050 --> 00:00:09.780
Představujeme urychlené
obnovení databáze

00:00:09.780 --> 00:00:11.190
k vyřešení tohoto problému.

00:00:11.190 --> 00:00:13.605
Kevin je tady, aby řekl
nám všechno,

00:00:13.605 --> 00:00:15.390
dnes v datech vystavených.

00:00:15.390 --> 00:00:26.130
HUDBY

00:00:26.130 --> 00:00:28.755
>> Hi a Vítejte v jiném
epizodu exponovaných dat.

00:00:28.755 --> 00:00:30.745
Jsem váš hostitel, Jeroen a dnes,

00:00:30.745 --> 00:00:34.415
Máme s sebou Kevina, abychom mluvili o
urychleného obnovení databáze.

00:00:34.415 --> 00:00:35.975
Tak vítám Kevina na představení.

00:00:35.975 --> 00:00:36.665
>> Děkuji.

00:00:36.665 --> 00:00:39.125
>> Tak urychlené obnovení databáze.

00:00:39.125 --> 00:00:40.750
Tak o co jde?

00:00:40.750 --> 00:00:41.930
>> Takže je to zajímavá vlastnost.

00:00:41.930 --> 00:00:43.340
Bude to zkratka ADR.

00:00:43.340 --> 00:00:44.890
>> Dobře, jasně.

00:00:44.890 --> 00:00:46.970
>> Pochází z
pohled na některé

00:00:46.970 --> 00:00:48.530
body bolesti, které měli zákazníci

00:00:48.530 --> 00:00:51.770
spouštění databází a uchovávání
jsou vysoce dostupné a

00:00:51.770 --> 00:00:53.270
jeho část má co dělat s dobou, kdy

00:00:53.270 --> 00:00:55.475
vyžaduje uvedení databáze do stavu online.

00:00:55.475 --> 00:00:58.970
Existuje řada fází, které
musí projít databáze,

00:00:58.970 --> 00:01:01.340
a pokud máte dlouhý
spuštěná transakce,

00:01:01.340 --> 00:01:04.010
může trvat dlouhou dobu
aby to vyčistí a

00:01:04.010 --> 00:01:07.080
vede k nedostupnosti při
To je to zpracování.

00:01:07.080 --> 00:01:10.545
>> Správně. Takže víme, že
obnovení je bod bolesti.

00:01:10.545 --> 00:01:13.530
Vrátit ji zpět je
něco, co DBAs,

00:01:13.530 --> 00:01:15.075
tak trochu se strachovat.

00:01:15.075 --> 00:01:16.790
>> Správně. A tak se tým podíval na

00:01:16.790 --> 00:01:19.520
celý proces a přemýšlel
Jak si to můžeme znovu představit?

00:01:19.520 --> 00:01:21.335
Takže přišli s ADR,

00:01:21.335 --> 00:01:23.210
je založena na úložišti verzí.

00:01:23.210 --> 00:01:26.170
Takže všechny změny jsou
verze v databázi.

00:01:26.170 --> 00:01:29.920
To žije v souboru
skupinu, kterou vyberete.

00:01:30.140 --> 00:01:34.925
Když to dokážeme, můžeme udělat
proces zotavení mnohem rychleji.

00:01:34.925 --> 00:01:35.600
>> Cool.

00:01:35.600 --> 00:01:40.965
>> Mám několik snímků
To dokazuje.

00:01:40.965 --> 00:01:46.515
Takže tady máme
klasický proces zotavení.

00:01:46.515 --> 00:01:48.350
Takže začíná, fáze 1 je analýza.

00:01:48.350 --> 00:01:50.360
Takže se musíš podívat
všechny transakce

00:01:50.360 --> 00:01:53.020
do protokolu z poslední
kontrolní bod vpřed.

00:01:53.020 --> 00:01:56.150
Znovu se změní všechny změny dat

00:01:56.150 --> 00:01:58.700
, které nebyly zachovány
v datových souborech,

00:01:58.700 --> 00:02:01.850
musí být přepracováno z
transakčním logu,

00:02:01.850 --> 00:02:03.020
celou cestu z

00:02:03.020 --> 00:02:05.420
začátek nejstaršího,
nepotvrzené transakce.

00:02:05.420 --> 00:02:07.790
Tak proto dlouho běžící
transakce vám opravdu ublížili.

00:02:07.790 --> 00:02:08.560
>> Přesně tak.

00:02:08.560 --> 00:02:12.170
>> Může trvat minuty
někdy hodinu nebo víc.

00:02:12.170 --> 00:02:14.660
Potom je fáze 3 zpět,

00:02:14.660 --> 00:02:17.270
vrácení všech transakcí, které

00:02:17.270 --> 00:02:20.975
nebyla potvrzena před
čas, na který se těšíme.

00:02:20.975 --> 00:02:23.285
V okamžiku, kdy čtení skončí,

00:02:23.285 --> 00:02:25.375
databáze je částečně k dispozici.

00:02:25.375 --> 00:02:28.670
To znamená, že můžete
přístup k databázi, ale

00:02:28.670 --> 00:02:33.270
všechny údaje, které nebyly uzamkněte
z původních transakcí,

00:02:33.270 --> 00:02:34.320
bude nyní zamčení.

00:02:34.320 --> 00:02:36.200
Takže i když je
Nikdo je nedělá,

00:02:36.200 --> 00:02:39.230
nemůžete získat přístup k těmto datům
do dokončení operace zpět.

00:02:39.230 --> 00:02:41.930
>> Takže v podstatě je to
dlouhotrvající proces

00:02:41.930 --> 00:02:45.835
a pak teprve po
dorazíme ke fázi 3,

00:02:45.835 --> 00:02:47.900
Můžu začít dělat

00:02:47.900 --> 00:02:49.580
všechno, co jsem chtěl s
databázi znovu, správně?

00:02:49.580 --> 00:02:50.165
>> Správně.

00:02:50.165 --> 00:02:53.585
>> Tak mi řekni, jak to bylo.

00:02:53.585 --> 00:02:55.865
>> V dolní části uvidíte jen

00:02:55.865 --> 00:02:59.145
záznam protokolu s odlišnými
událostí v záznamu protokolu.

00:02:59.145 --> 00:03:00.165
>> Jistě.

00:03:00.165 --> 00:03:02.190
>> ADR mění toto množství.

00:03:02.190 --> 00:03:03.750
Máme úložiště verzí pro zpracování.

00:03:03.750 --> 00:03:06.375
Uvidíte, že je odkazováno jako PVS.

00:03:06.375 --> 00:03:09.464
Když jsme to dali do náhledů,

00:03:09.464 --> 00:03:11.915
PVS žila v primární skupině souborů

00:03:11.915 --> 00:03:13.820
a neexistuje žádná možnost
to změnit.

00:03:13.820 --> 00:03:16.780
Takže se to stalo, tam
všechny ty verze žily.

00:03:16.780 --> 00:03:19.550
Máme zpětnou vazbu, která
Zákazníci by chtěli

00:03:19.550 --> 00:03:22.280
být schopny určit, které
skupina souborů, ve které bydlí.

00:03:22.280 --> 00:03:26.180
Mám skupinu hromadných souborů nebo
Velmi rychlá skupina souborů, cokoliv.

00:03:26.180 --> 00:03:27.740
Takže teď jsi s

00:03:27.740 --> 00:03:31.130
uvolňovací kandidát a s
verze GA, jakmile vyjde,

00:03:31.130 --> 00:03:33.910
budete moci určit, které
skupinu souborů a změnit ji,

00:03:33.910 --> 00:03:35.880
existuje proces pro
.

00:03:35.880 --> 00:03:38.120
Ale projdeme tím, co
proces obnovení

00:03:38.120 --> 00:03:39.755
vypadá jako ADR.

00:03:39.755 --> 00:03:42.110
Takže začíná analýzou,

00:03:42.110 --> 00:03:45.695
, která se nemění od
Co jsi měl předtím.

00:03:45.695 --> 00:03:47.015
>> Je to stejné chování, že?

00:03:47.015 --> 00:03:49.805
>> Správně. Zavedli jsme
koncept sLog.

00:03:49.805 --> 00:03:52.705
SLog je protokol v paměti.

00:03:52.705 --> 00:03:55.640
obsahující pouze záznamy
Systémové transakce

00:03:55.640 --> 00:03:57.005
to nemůže být číslo verze.

00:03:57.005 --> 00:03:59.150
Většina datových verzí je tedy

00:03:59.150 --> 00:04:01.715
změnit před a po
obrázky dat.

00:04:01.715 --> 00:04:04.070
Takže některé změny schématu,

00:04:04.070 --> 00:04:06.195
Některé takové věci,
nemůže být uvedena verze.

00:04:06.195 --> 00:04:06.570
>> Jistě.

00:04:06.570 --> 00:04:07.890
>> Takže ty se zaznamenají do Slogu.

00:04:07.890 --> 00:04:09.195
Takže myšlenka je, že je to tak,

00:04:09.195 --> 00:04:11.580
velmi málo významné.

00:04:11.580 --> 00:04:13.920
>> Bude malý
sadu předpovědí, že?

00:04:13.920 --> 00:04:17.525
>> Tak část analýzy
a fáze opětovného provedení je

00:04:17.525 --> 00:04:23.100
opakované vytváření protokolů v paměti
ze záznamů protokolu transakcí.

00:04:23.230 --> 00:04:25.850
Takže znovu z Slogu,

00:04:25.850 --> 00:04:28.300
pouze využívá úložiště verzí.

00:04:28.300 --> 00:04:31.195
Protože máme před a po
verze všech těchto řádků,

00:04:31.195 --> 00:04:34.010
Takže je to velmi rychlé a
potom se znovu provede z

00:04:34.010 --> 00:04:38.905
protokol právě z
poslední kontrolní bod vpřed.

00:04:38.905 --> 00:04:42.810
V tomto okamžiku databáze
je plně k dispozici.

00:04:43.420 --> 00:04:46.910
Vrácení zpět se právě vrací

00:04:46.910 --> 00:04:48.875
verze, takže jste právě

00:04:48.875 --> 00:04:51.710
odkazovat na předchozí verzi
namísto aktuální verze.

00:04:51.710 --> 00:04:55.345
Není nutné fyzicky vrátit
transakci a stornovat.

00:04:55.345 --> 00:04:59.825
>> Takže tohle bude cesta
rychlejší než ta starší normálně?

00:04:59.825 --> 00:05:01.880
>> Mnohem rychleji. Měli jsme zákazníka v

00:05:01.880 --> 00:05:04.280
laboratoř v posledních několika
týdnů, které se při testování s

00:05:04.280 --> 00:05:10.050
ADR a měli velmi
pracovní vytížení aktivní aktualizace.

00:05:10.050 --> 00:05:13.065
Měli dlouho běžící
transakce.

00:05:13.065 --> 00:05:14.430
Udělali to,

00:05:14.430 --> 00:05:17.450
a vrácení tohoto
dlouhotrvající transakce.

00:05:17.450 --> 00:05:20.555
Bez ADR, trvalo
za minutu a půl.

00:05:20.555 --> 00:05:24.765
>> Což stále není
Škoda, ale dobře, dlouho.

00:05:24.765 --> 00:05:26.190
>> Ano. V jejich podnikání

00:05:26.190 --> 00:05:28.105
To je velký rozdíl.

00:05:28.105 --> 00:05:30.680
A tak se opakovali
stejný scénář

00:05:30.680 --> 00:05:32.780
s ADR a doba, kterou trvalo

00:05:32.780 --> 00:05:36.720
provést toto obnovení, bylo nulové sekundy.

00:05:36.720 --> 00:05:38.505
Nemohli měřit
to bylo tak rychlé.

00:05:38.505 --> 00:05:40.110
>> To je působivé.

00:05:40.110 --> 00:05:43.580
>> Takže pro ně jsou zpátky
na lince, která je mnohem rychlejší,

00:05:43.580 --> 00:05:47.425
což je velký rozdíl
také proto, že v jejich byznyse

00:05:47.425 --> 00:05:49.560
jakékoliv výpadky jsou ztrátou příjmů.

00:05:49.560 --> 00:05:51.375
>> Tak počet milisekund, správně?

00:05:51.375 --> 00:05:52.230
>> Velmi mnoho.

00:05:52.230 --> 00:05:53.880
>> Takže pokud můžeme pomoci tomuto zákazníkovi

00:05:53.880 --> 00:05:55.575
přesunuta z jedné a půl minuty,

00:05:55.575 --> 00:05:58.305
řekl jste v podstatě nula,

00:05:58.305 --> 00:05:59.895
To je působivé. Tak Wow.

00:05:59.895 --> 00:06:02.930
Takže všichni naši zákazníci

00:06:02.930 --> 00:06:05.810
pravděpodobně chtějí
Vyzkoušejte toto a povolte toto.

00:06:05.810 --> 00:06:08.450
Můžete mi říct, jak to dělám?

00:06:08.450 --> 00:06:09.470
Mám teď databázi,

00:06:09.470 --> 00:06:12.995
Mám to v normálním
uzdravit, tak co mám dělat?

00:06:12.995 --> 00:06:14.585
>> S Azure databází SQL,

00:06:14.585 --> 00:06:16.775
ve výchozím nastavení je tato hodnota zapnuta.

00:06:16.775 --> 00:06:19.130
Ve výchozím nastavení je zapnutý
globálně celé měsíce.

00:06:19.130 --> 00:06:20.540
Takže nemusíte
tam něco udělat.

00:06:20.540 --> 00:06:22.520
Už jsi toho využil.

00:06:22.520 --> 00:06:23.740
>> Cool.

00:06:23.740 --> 00:06:26.940
>> Pro databáze serveru SQL Server,

00:06:26.940 --> 00:06:29.060
ve výchozím nastavení je tato hodnota vypnuta, protože je

00:06:29.060 --> 00:06:31.610
Některé režie v rozsahu

00:06:31.610 --> 00:06:35.880
jeden až pět procent pro
sledování verzí.

00:06:36.190 --> 00:06:41.015
Takže bys to musel zapnout a
To je jen, změnit databázovou sadu,

00:06:41.015 --> 00:06:42.635
zrychlené obnovení databáze se rovná

00:06:42.635 --> 00:06:46.410
zapnuto a volitelně s
skupina souborů je rovna.

00:06:46.410 --> 00:06:47.310
>> Něco.

00:06:47.310 --> 00:06:49.810
>> Ano. Tak jednoduchý skript DDL.

00:06:49.810 --> 00:06:51.710
>> Tak co se stane?

00:06:51.710 --> 00:06:54.410
>> Pak začne sledování
verze a získáte výhodu.

00:06:54.410 --> 00:06:55.970
>> Cool. Je to přímé

00:06:55.970 --> 00:06:58.065
přímo, nebo je to tak,

00:06:58.065 --> 00:06:59.250
je nutné restartovat počítač.

00:06:59.250 --> 00:07:01.740
>> Není restartován. Jsi jen online.

00:07:01.740 --> 00:07:03.705
>> Cool. Tak Wow.

00:07:03.705 --> 00:07:05.160
Takže v podstatě je to jako

00:07:05.160 --> 00:07:08.545
velmi cool technologie pro
velmi rychle obnovit databázi.

00:07:08.545 --> 00:07:10.730
Ještě něco, co z toho dostanu?

00:07:10.730 --> 00:07:12.140
Chci říct, že je to opravdu
Velmi působivé, ale

00:07:12.140 --> 00:07:13.580
To je jako extra přínos.

00:07:13.580 --> 00:07:15.590
>> Takže v

00:07:15.590 --> 00:07:19.115
to kvůli tomu, jak
opakované použití verzí,

00:07:19.115 --> 00:07:22.470
Nebudeme se muset držet, jak
mnoho transakčních protokolů online.

00:07:22.470 --> 00:07:24.920
Abyste mohli zkrátit
transakční protokol mnohem více

00:07:24.920 --> 00:07:28.725
agresivně do posledního
kontrolním stanovišti než předtím.

00:07:28.725 --> 00:07:30.530
Což znamená, že pokud jste
situaci,

00:07:30.530 --> 00:07:32.540
Máme dlouhotrvající
transakce, která vás drží

00:07:32.540 --> 00:07:34.460
možnost zkrácení

00:07:34.460 --> 00:07:36.620
váš protokol a transakce
protokol začne vyhazuje do povětří,

00:07:36.620 --> 00:07:38.665
To se nestane
se zapnutou ADR.

00:07:38.665 --> 00:07:41.400
>> Takže v podstatě je to
Extra výhodu.

00:07:41.400 --> 00:07:43.650
Žádná dlouhá transakce
protokol táhnout.

00:07:43.650 --> 00:07:44.505
>> Přesně.

00:07:44.505 --> 00:07:45.990
>> Vím, co budu dělat,

00:07:45.990 --> 00:07:47.660
Myslím tím, že MySQL server šel do

00:07:47.660 --> 00:07:49.760
urychlení databáze
zotavení.

00:07:49.760 --> 00:07:51.470
Po tom videu to udělám.

00:07:51.470 --> 00:07:52.805
Díky moc za sdílení.

00:07:52.805 --> 00:07:53.345
>> Děkuji.

00:07:53.345 --> 00:07:55.940
>> Díky za vysvětlení.
Bylo to naprosto jasné.

00:07:55.940 --> 00:07:57.575
Díky za sledování.

00:07:57.575 --> 00:08:00.990
Prosím vás, přihlaste se a
zůstat naladěn na další. Dík.

00:08:00.990 --> 00:08:13.210
HUDBY