WEBVTT

00:00:00.000 --> 00:00:02.055
>> Odzyskiwanie bazy danych z

00:00:02.055 --> 00:00:05.190
transakcje długo działające
wyzwaniem.

00:00:05.190 --> 00:00:07.050
W SQL Server 2019,

00:00:07.050 --> 00:00:09.780
wprowadzamy przyspieszone
odzyskiwanie bazy danych

00:00:09.780 --> 00:00:11.190
pomóc w rozwiązaniu tego problemu.

00:00:11.190 --> 00:00:13.605
Kevin jest tutaj, aby powiedzieć
nas o tym wszystkim,

00:00:13.605 --> 00:00:15.390
obecnie na danych narażonych.

00:00:15.390 --> 00:00:26.130
MUZYKI

00:00:26.130 --> 00:00:28.755
>> Witam i zapraszam na inny
odcinek danych narażonych.

00:00:28.755 --> 00:00:30.745
Jestem gospodarzem, Jeroen i dzisiaj,

00:00:30.745 --> 00:00:34.415
Mamy Kevin z nami, aby porozmawiać o
przyspieszone odzyskiwanie baz danych.

00:00:34.415 --> 00:00:35.975
Więc Witamy Kevin do pokazu.

00:00:35.975 --> 00:00:36.665
>> Dziękuję.

00:00:36.665 --> 00:00:39.125
>> Tak przyspieszone odzyskiwanie bazy danych.

00:00:39.125 --> 00:00:40.750
Więc co to jest?

00:00:40.750 --> 00:00:41.930
>> Więc jest to ciekawa cecha.

00:00:41.930 --> 00:00:43.340
Nazywamy to ADR na krótko.

00:00:43.340 --> 00:00:44.890
>> Dobra, pewnie.

00:00:44.890 --> 00:00:46.970
>> Pochodzi z
patrząc na niektóre z

00:00:46.970 --> 00:00:48.530
punkty bólowe, które klienci mieli

00:00:48.530 --> 00:00:51.770
prowadzenie baz danych i utrzymywanie
ich wysokiej dostępności i

00:00:51.770 --> 00:00:53.270
część z nich ma do czynienia z czasem

00:00:53.270 --> 00:00:55.475
ma doprowadzić do bazy danych w trybie online.

00:00:55.475 --> 00:00:58.970
Istnieje wiele faz, które
Baza danych musi pochodzić,

00:00:58.970 --> 00:01:01.340
a jeśli masz długą
uruchomiona transakcja,

00:01:01.340 --> 00:01:04.010
może to zająć dużo czasu
oczyścić to i że

00:01:04.010 --> 00:01:07.080
powoduje niedostępność podczas
to robi, że przetwarzanie.

00:01:07.080 --> 00:01:10.545
>> W prawo. Wiemy więc, że
przywrócenie jest punktem bólu.

00:01:10.545 --> 00:01:13.530
Wniesienie go z powrotem jest
coś, co DBAs,

00:01:13.530 --> 00:01:15.075
dobrze, rodzaj martwić.

00:01:15.075 --> 00:01:16.790
>> W prawo. Więc zespół spojrzał na

00:01:16.790 --> 00:01:19.520
cały proces i pomyślał, że
Jak możemy je ponownie wyobrazić?

00:01:19.520 --> 00:01:21.335
Więc oni wymyślić ADR,

00:01:21.335 --> 00:01:23.210
jest oparta na wersji magazynu.

00:01:23.210 --> 00:01:26.170
Więc wszystkie zmiany są
wersjonowany w bazie danych.

00:01:26.170 --> 00:01:29.920
Że mieszka w pliku
grupy wyboru.

00:01:30.140 --> 00:01:34.925
Wykorzystując to, możemy sprawić, że
proces odzyskiwania znacznie szybciej.

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

00:01:35.600 --> 00:01:40.965
>> Mam kilka slajdów
które wykazują.

00:01:40.965 --> 00:01:46.515
Więc mamy
klasycznego procesu odzyskiwania.

00:01:46.515 --> 00:01:48.350
Tak zaczyna się, faza 1 jest analiza.

00:01:48.350 --> 00:01:50.360
Więc trzeba patrzeć przez
wszystkie transakcje

00:01:50.360 --> 00:01:53.020
w dzienniku z ostatniego
punktu kontrolnego do przodu.

00:01:53.020 --> 00:01:56.150
Redo to wszelkie zmiany danych

00:01:56.150 --> 00:01:58.700
, które nie zostały utrwalone
w plikach danych,

00:01:58.700 --> 00:02:01.850
muszą zostać przerobione z
dziennika transakcji,

00:02:01.850 --> 00:02:03.020
przez całą drogę od

00:02:03.020 --> 00:02:05.420
Początek najstarszego,
niezakończone transakcje.

00:02:05.420 --> 00:02:07.790
Więc to, gdzie długo działa
transakcje naprawdę cię zranić.

00:02:07.790 --> 00:02:08.560
>> Prawo, dokładnie.

00:02:08.560 --> 00:02:12.170
>> Może potrwać kilka minut, aby
godzinę lub więcej czasami.

00:02:12.170 --> 00:02:14.660
Następnie faza 3 jest cofanie,

00:02:14.660 --> 00:02:17.270
gdzie cofasz wszystkie transakcje, które

00:02:17.270 --> 00:02:20.975
nie popełniono przed
czas, którego oczekujemy.

00:02:20.975 --> 00:02:23.285
W momencie zakończenia czytania

00:02:23.285 --> 00:02:25.375
Baza danych jest częściowo dostępna.

00:02:25.375 --> 00:02:28.670
Oznacza to, że możesz
dostęp do bazy danych, ale

00:02:28.670 --> 00:02:33.270
wszelkie dane, które nie były objęte blokową
z pierwotnych transakcji,

00:02:33.270 --> 00:02:34.320
będzie teraz pod blokada.

00:02:34.320 --> 00:02:36.200
Więc nawet jeśli nie ma
nikt ich nie robi,

00:02:36.200 --> 00:02:39.230
nie masz dostępu do tych danych
aż do zakończenia cofania.

00:02:39.230 --> 00:02:41.930
>> Więc w zasadzie jest to
długotrwały proces

00:02:41.930 --> 00:02:45.835
i dopiero po
docieramy do fazy 3,

00:02:45.835 --> 00:02:47.900
Mogę zacząć robić

00:02:47.900 --> 00:02:49.580
wszystko, co chciałem z
bazy danych ponownie, prawda?

00:02:49.580 --> 00:02:50.165
>> W prawo.

00:02:50.165 --> 00:02:53.585
>> Więc powiedz mi, jak to było.

00:02:53.585 --> 00:02:55.865
>> Na dole widać tylko

00:02:55.865 --> 00:02:59.145
rekord dziennika z różnymi
zdarzenia w rekordzie dziennika.

00:02:59.145 --> 00:03:00.165
>> Pewnie.

00:03:00.165 --> 00:03:02.190
>> ADR wiele się zmienia.

00:03:02.190 --> 00:03:03.750
Mamy magazyn wersji przetwarzania.

00:03:03.750 --> 00:03:06.375
Zobaczysz, że odwołuje się do PVS.

00:03:06.375 --> 00:03:09.464
Kiedy umieściliśmy to w zapowiedzi,

00:03:09.464 --> 00:03:11.915
PVS mieszkał w głównej grupie plików

00:03:11.915 --> 00:03:13.820
i nie ma możliwości
to zmienić.

00:03:13.820 --> 00:03:16.780
Tak się stało, to gdzie
wszystkie te wersje żyły.

00:03:16.780 --> 00:03:19.550
Otrzymaliśmy informację zwrotną,
Klienci chcieliby

00:03:19.550 --> 00:03:22.280
być w stanie określić, które
grupy plików, która mieszka w.

00:03:22.280 --> 00:03:26.180
Mam grupę plików masowych lub
Bardzo szybka grupa plików, cokolwiek.

00:03:26.180 --> 00:03:27.740
Więc teraz jesteś z

00:03:27.740 --> 00:03:31.130
kandydata do wydania oraz
wersji GA, gdy wychodzi,

00:03:31.130 --> 00:03:33.910
będziesz w stanie określić, które
grupę plików i zmienić ją,

00:03:33.910 --> 00:03:35.880
Istnieje proces
również zmienić.

00:03:35.880 --> 00:03:38.120
Ale przejdźmy przez to, co
proces odzyskiwania

00:03:38.120 --> 00:03:39.755
Wygląda jak w ADR.

00:03:39.755 --> 00:03:42.110
Więc zaczyna się od analizy,

00:03:42.110 --> 00:03:45.695
niezmienionej z
co trzeba było wcześniej.

00:03:45.695 --> 00:03:47.015
>> To samo zachowanie, prawda?

00:03:47.015 --> 00:03:49.805
>> W prawo. Wprowadziliśmy
koncepcji sLog.

00:03:49.805 --> 00:03:52.705
SLog jest dziennik w pamięci

00:03:52.705 --> 00:03:55.640
rejestruje tylko te
transakcje systemowe

00:03:55.640 --> 00:03:57.005
które nie mogą być wersjonowane.

00:03:57.005 --> 00:03:59.150
Tak więc Większość wersji danych można

00:03:59.150 --> 00:04:01.715
zmiany przed i po
Zdjęcia danych.

00:04:01.715 --> 00:04:04.070
Więc niektóre zmiany schematu,

00:04:04.070 --> 00:04:06.195
Niektóre takie rzeczy,
nie można wersjonować.

00:04:06.195 --> 00:04:06.570
>> Pewnie.

00:04:06.570 --> 00:04:07.890
>> Więc te zostają zarejestrowane w sLog.

00:04:07.890 --> 00:04:09.195
Więc chodzi o to, że to,

00:04:09.195 --> 00:04:11.580
bardzo niewiele znaczących.

00:04:11.580 --> 00:04:13.920
>> Będzie mały
zestaw prognoz, prawda?

00:04:13.920 --> 00:04:17.525
>> Więc część analizy
i powtórz faza jest

00:04:17.525 --> 00:04:23.100
odtworzenie tych dzienników w pamięci
z rekordów dziennika transakcji.

00:04:23.230 --> 00:04:25.850
Więc przerobić z sLog,

00:04:25.850 --> 00:04:28.300
jest tylko wykorzystanie magazynu wersji.

00:04:28.300 --> 00:04:31.195
Ponieważ mamy przed i po
wersje wszystkich tych wierszy,

00:04:31.195 --> 00:04:34.010
więc jest to bardzo szybkie i
następnie wykonaj ponownie z

00:04:34.010 --> 00:04:38.905
dziennika tylko z
ostatniego punktu kontrolnego do przodu.

00:04:38.905 --> 00:04:42.810
W tym momencie baza danych
jest w pełni dostępna.

00:04:43.420 --> 00:04:46.910
Cofnij jest po prostu odwracanie

00:04:46.910 --> 00:04:48.875
wersje więc po prostu

00:04:48.875 --> 00:04:51.710
wskaż poprzednią wersję
zamiast aktualnej wersji.

00:04:51.710 --> 00:04:55.345
Nie musisz fizycznie cofać
transakcji i odwrotnie.

00:04:55.345 --> 00:04:59.825
>> Więc to będzie sposób
szybciej niż starsze normalnie?

00:04:59.825 --> 00:05:01.880
>> Sposób szybciej. Mieliśmy klienta w

00:05:01.880 --> 00:05:04.280
laboratorium w ciągu ostatnich kilku
tygodni, w których niektóre testy

00:05:04.280 --> 00:05:10.050
ADR i mieli bardzo
obciążenia aktywnej aktualizacji.

00:05:10.050 --> 00:05:13.065
Mieli długą
transakcji.

00:05:13.065 --> 00:05:14.430
Zrobili to,

00:05:14.430 --> 00:05:17.450
i nie wycofał tego
długim transakcji.

00:05:17.450 --> 00:05:20.555
Bez ADR zajęło to około
minuty i pół, aby to zrobić.

00:05:20.555 --> 00:05:24.765
>> Który nadal nie jest
zbyt źle, ale dobrze, długo.

00:05:24.765 --> 00:05:26.190
>> tak. W swojej działalności,

00:05:26.190 --> 00:05:28.105
to sprawia, że duża różnica.

00:05:28.105 --> 00:05:30.680
Wtedy oni ponowiono
tym samym scenariuszu

00:05:30.680 --> 00:05:32.780
z ADR i czas, jaki zajęło

00:05:32.780 --> 00:05:36.720
to zrobić, że odzyskiwanie było zero sekund.

00:05:36.720 --> 00:05:38.505
Nie mogli zmierzyć
to było tak szybkie.

00:05:38.505 --> 00:05:40.110
>> To imponujące.

00:05:40.110 --> 00:05:43.580
>> Więc dla nich wracają
na linii, że znacznie szybciej,

00:05:43.580 --> 00:05:47.425
co sprawia, że duża różnica
ponieważ w swojej działalności,

00:05:47.425 --> 00:05:49.560
jakichkolwiek przestojów jest utrata przychodów.

00:05:49.560 --> 00:05:51.375
>> Więc milisekundy liczyć, prawda?

00:05:51.375 --> 00:05:52.230
>> Bardzo dużo.

00:05:52.230 --> 00:05:53.880
>> Więc jeśli możemy pomóc temu klientowi

00:05:53.880 --> 00:05:55.575
przeniesione z jednej i pół minuty,

00:05:55.575 --> 00:05:58.305
mówiłeś w zasadzie zero,

00:05:58.305 --> 00:05:59.895
To imponujące. Więc wow.

00:05:59.895 --> 00:06:02.930
Więc wszyscy nasi klienci

00:06:02.930 --> 00:06:05.810
prawdopodobnie chcą
próbować ten i umożliwiać ten.

00:06:05.810 --> 00:06:08.450
Więc możesz mi powiedzieć, jak to zrobić?

00:06:08.450 --> 00:06:09.470
Mam teraz bazę danych,

00:06:09.470 --> 00:06:12.995
Mam go na normalnym
odzysku, więc co mam zrobić?

00:06:12.995 --> 00:06:14.585
>> Więc z bazą danych Azure SQL

00:06:14.585 --> 00:06:16.775
jest domyślnie włączona globalnie.

00:06:16.775 --> 00:06:19.130
Jest on domyślnie włączony
globalnie dla miesięcy.

00:06:19.130 --> 00:06:20.540
Więc nie musisz
zrobić coś tam.

00:06:20.540 --> 00:06:22.520
Już skorzystałeś z tego.

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

00:06:23.740 --> 00:06:26.940
>> Dla baz danych programu SQL Server

00:06:26.940 --> 00:06:29.060
jest domyślnie wyłączona, ponieważ

00:06:29.060 --> 00:06:31.610
kilka narzutów na zakres

00:06:31.610 --> 00:06:35.880
od jednego do pięciu procent
śledzenie wersji.

00:06:36.190 --> 00:06:41.015
Więc trzeba go włączyć i
to tylko zmienić zestaw bazy danych,

00:06:41.015 --> 00:06:42.635
przyspieszone odzyskiwanie bazy danych jest równe

00:06:42.635 --> 00:06:46.410
i opcjonalnie z
Grupa plików jest równa.

00:06:46.410 --> 00:06:47.310
>> Coś.

00:06:47.310 --> 00:06:49.810
>> tak. Tak bardzo prosty DDL.

00:06:49.810 --> 00:06:51.710
>> To co się dzieje?

00:06:51.710 --> 00:06:54.410
>> Następnie rozpoczyna śledzenie
wersje i zyskujesz korzyści.

00:06:54.410 --> 00:06:55.970
>> Cool. Czy to bezpośrednie,

00:06:55.970 --> 00:06:58.065
natychmiastowe, lub jest to, że jak,

00:06:58.065 --> 00:06:59.250
jest wymagane ponowne uruchomienie komputera.

00:06:59.250 --> 00:07:01.740
>> Nie restart. Jesteś po prostu online.

00:07:01.740 --> 00:07:03.705
>> Cool. Więc wow.

00:07:03.705 --> 00:07:05.160
Tak w zasadzie, to jest jak

00:07:05.160 --> 00:07:08.545
Bardzo fajna technologia
bardzo szybko przywrócić bazę danych.

00:07:08.545 --> 00:07:10.730
Cokolwiek innego, co mogę z tego dostać?

00:07:10.730 --> 00:07:12.140
Mam na myśli to jest naprawdę
bardzo imponujące, ale

00:07:12.140 --> 00:07:13.580
są one jak dodatkowe korzyści.

00:07:13.580 --> 00:07:15.590
>> Więc nie ma dodatkowych korzyści w

00:07:15.590 --> 00:07:19.115
że ze względu na sposób
ponownie wykorzystujemy wersje,

00:07:19.115 --> 00:07:22.470
nie musimy trzymać tak
wiele dziennika transakcji w trybie online.

00:07:22.470 --> 00:07:24.920
Można więc obcinać
Dziennik transakcji znacznie więcej

00:07:24.920 --> 00:07:28.725
agresywnie aż do ostatniego
punktu kontrolnego niż wcześniej.

00:07:28.725 --> 00:07:30.530
Co oznacza, jeśli
ale sytuacja,

00:07:30.530 --> 00:07:32.540
Mamy długotrwały
transakcji, która jest utrzymanie

00:07:32.540 --> 00:07:34.460
z możliwości obcinania

00:07:34.460 --> 00:07:36.620
dziennika i transakcji
Dziennik zaczyna dmuchać,

00:07:36.620 --> 00:07:38.665
tak się nie dzieje
z włączonym ADR.

00:07:38.665 --> 00:07:41.400
>> Więc w zasadzie to
dodatkowe korzyści.

00:07:41.400 --> 00:07:43.650
Brak długiej transakcji
dziennika przeciągania wzdłuż.

00:07:43.650 --> 00:07:44.505
>> Dokładnie.

00:07:44.505 --> 00:07:45.990
>> Wiem co zrobię,

00:07:45.990 --> 00:07:47.660
Mam na myśli serwer MySQL był iść do

00:07:47.660 --> 00:07:49.760
przyspieszenie bazy danych
odzyskiwanie danych już teraz.

00:07:49.760 --> 00:07:51.470
Po tym filmie zrobię to.

00:07:51.470 --> 00:07:52.805
Bardzo dziękuję za dzielenie się.

00:07:52.805 --> 00:07:53.345
>> Dziękuję.

00:07:53.345 --> 00:07:55.940
>> Dzięki za wyjaśnienie.
To było bardzo jasne.

00:07:55.940 --> 00:07:57.575
Dziękujemy za oglądanie.

00:07:57.575 --> 00:08:00.990
Proszę jak i subskrybować i
Stay tuned na następne. Dzięki.

00:08:00.990 --> 00:08:13.210
MUZYKI