WEBVTT

00:00:00.000 --> 00:00:02.055
>> Recupero del database con

00:00:02.055 --> 00:00:05.190
transazioni a esecuzione prolungata
è stata una sfida.

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

00:00:07.050 --> 00:00:09.780
introduciamo accelerato
ripristino del database

00:00:09.780 --> 00:00:11.190
per aiutare a risolvere il problema.

00:00:11.190 --> 00:00:13.605
Kevin è qui per raccontare
noi tutto su di esso,

00:00:13.605 --> 00:00:15.390
oggi su Data Exposed.

00:00:15.390 --> 00:00:26.130
[MUSICA]

00:00:26.130 --> 00:00:28.755
>> Ciao e benvenuto a un altro
episodio di Data Exposed.

00:00:28.755 --> 00:00:30.745
Sono il vostro ospite, Jeroen e oggi,

00:00:30.745 --> 00:00:34.415
abbiamo Kevin con noi per parlare di
il ripristino accelerato del database.

00:00:34.415 --> 00:00:35.975
Quindi date il benvenuto a Kevin allo spettacolo.

00:00:35.975 --> 00:00:36.665
>> Grazie.

00:00:36.665 --> 00:00:39.125
>> Così il recupero del database accelerato.

00:00:39.125 --> 00:00:40.750
Allora, che cos'è?

00:00:40.750 --> 00:00:41.930
>> Quindi è una caratteristica interessante.

00:00:41.930 --> 00:00:43.340
Lo chiameremo ADR in breve.

00:00:43.340 --> 00:00:44.890
>> Ok, certo.

00:00:44.890 --> 00:00:46.970
>> E 'venuto da
guardando alcuni dei

00:00:46.970 --> 00:00:48.530
punti dolenti che i clienti hanno avuto

00:00:48.530 --> 00:00:51.770
l'esecuzione di database e la conservazione
disponibili e

00:00:51.770 --> 00:00:53.270
parte di esso ha a che fare con il tempo che

00:00:53.270 --> 00:00:55.475
per portare online un database.

00:00:55.475 --> 00:00:58.970
Ci sono diverse fasi che
un database deve passare attraverso,

00:00:58.970 --> 00:01:01.340
e se hai un lungo
transazione in esecuzione,

00:01:01.340 --> 00:01:04.010
può richiedere molto tempo
per pulire che e che

00:01:04.010 --> 00:01:07.080
porta all'indisponibilità quando
sta facendo che l'elaborazione.

00:01:07.080 --> 00:01:10.545
>> Destra. Quindi sappiamo che
ripristino è un punto di dolore.

00:01:10.545 --> 00:01:13.530
Riportarlo indietro è
qualcosa che gli amministratori di database,

00:01:13.530 --> 00:01:15.075
beh, una specie di preoccupazione.

00:01:15.075 --> 00:01:16.790
>> Destra. Così il team ha guardato

00:01:16.790 --> 00:01:19.520
che l'intero processo e il pensiero
come possiamo reinventarlo?

00:01:19.520 --> 00:01:21.335
Così hanno escolato con ADR,

00:01:21.335 --> 00:01:23.210
si basa su un archivio versioni.

00:01:23.210 --> 00:01:26.170
Quindi tutti i cambiamenti sono
versione nel database.

00:01:26.170 --> 00:01:29.920
Che vive nel file
gruppo di vostra scelta.

00:01:30.140 --> 00:01:34.925
Sfruttando questo, possiamo fare il
processo di recupero molto più velocemente.

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

00:01:35.600 --> 00:01:40.965
>> Ho alcune diapositive
che dimostrano.

00:01:40.965 --> 00:01:46.515
Quindi qui abbiamo il
processo di recupero classico.

00:01:46.515 --> 00:01:48.350
Quindi inizia, la Fase 1 è l'analisi.

00:01:48.350 --> 00:01:50.360
Quindi devi guardare attraverso
tutte le transazioni

00:01:50.360 --> 00:01:53.020
nel registro dall'ultimo
punto di controllo in avanti.

00:01:53.020 --> 00:01:56.150
Redo è qualsiasi modifica dei dati

00:01:56.150 --> 00:01:58.700
che non è stato persistente
nei file di dati,

00:01:58.700 --> 00:02:01.850
devono essere rifatti da
nel log delle transazioni,

00:02:01.850 --> 00:02:03.020
tutta la strada attraverso da

00:02:03.020 --> 00:02:05.420
l'inizio del più antico,
transazioni di cui non è stato eseguito il commit.

00:02:05.420 --> 00:02:07.790
Ecco dove il lungo corso
transazioni davvero male.

00:02:07.790 --> 00:02:08.560
>> Giusto, esattamente.

00:02:08.560 --> 00:02:12.170
>> Si può prendere un minuto per
un'ora o più a volte.

00:02:12.170 --> 00:02:14.660
Quindi, la Fase 3 è annulla,

00:02:14.660 --> 00:02:17.270
in cui si annullano tutte le transazioni che

00:02:17.270 --> 00:02:20.975
non sono stati impegnati prima del
tempo che non vedi l'ora di.

00:02:20.975 --> 00:02:23.285
Al momento della lettura,

00:02:23.285 --> 00:02:25.375
il database è parzialmente disponibile.

00:02:25.375 --> 00:02:28.670
Ciò significa che si può
accedere al database, ma

00:02:28.670 --> 00:02:33.270
tutti i dati che non erano sotto controllo
dalle transazioni originali,

00:02:33.270 --> 00:02:34.320
sarà sotto chiave ora.

00:02:34.320 --> 00:02:36.200
Quindi, anche se c'è
nessuno li fa,

00:02:36.200 --> 00:02:39.230
non è possibile accedere a tali dati
fino al completamento dell'annullamento.

00:02:39.230 --> 00:02:41.930
>> Quindi fondamentalmente questo è
un processo a esecuzione prolungata

00:02:41.930 --> 00:02:45.835
e poi solo dopo
arriviamo alla Fase 3,

00:02:45.835 --> 00:02:47.900
Posso iniziare a fare

00:02:47.900 --> 00:02:49.580
tutto quello che volevo con
il database di nuovo, giusto?

00:02:49.580 --> 00:02:50.165
>> Destra.

00:02:50.165 --> 00:02:53.585
>> Quindi dimmi com'era.

00:02:53.585 --> 00:02:55.865
>> In basso, si vede solo

00:02:55.865 --> 00:02:59.145
record di log con
eventi nel record del registro.

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

00:03:00.165 --> 00:03:02.190
>> ADR cambia che molto.

00:03:02.190 --> 00:03:03.750
Abbiamo l'archivio delle versioni di elaborazione.

00:03:03.750 --> 00:03:06.375
Lo vedrai referenziato come PVS.

00:03:06.375 --> 00:03:09.464
Quando lo mettiamo nelle anteprime,

00:03:09.464 --> 00:03:11.915
PVS viveva nel gruppo di file primario

00:03:11.915 --> 00:03:13.820
e non c'è capacità
per cambiare questo.

00:03:13.820 --> 00:03:16.780
Così che è successo, è lì che
tutte quelle versioni vissute.

00:03:16.780 --> 00:03:19.550
Abbiamo ricevuto un feedback che
clienti vorrebbero

00:03:19.550 --> 00:03:22.280
essere in grado di specificare quali
gruppo di file in cui si trova.

00:03:22.280 --> 00:03:26.180
Ho un gruppo di file in blocco o
gruppo di file molto veloce, qualunque cosa.

00:03:26.180 --> 00:03:27.740
Così ora sei con

00:03:27.740 --> 00:03:31.130
il candidato al rilascio e con
la versione GA quando esce,

00:03:31.130 --> 00:03:33.910
sarete in grado di specificare quale
gruppo di file e modificarlo,

00:03:33.910 --> 00:03:35.880
c'è processo per
cambiandolo pure.

00:03:35.880 --> 00:03:38.120
Ma andiamo attraverso ciò che
il processo di recupero

00:03:38.120 --> 00:03:39.755
sembra che con ADR.

00:03:39.755 --> 00:03:42.110
Quindi inizia con l'analisi,

00:03:42.110 --> 00:03:45.695
che è invariato da
quello che avevi prima.

00:03:45.695 --> 00:03:47.015
>> E 'lo stesso comportamento, giusto?

00:03:47.015 --> 00:03:49.805
>> Destra. Abbiamo introdotto
il concetto di sLog.

00:03:49.805 --> 00:03:52.705
Uno sLog è un log in memoria

00:03:52.705 --> 00:03:55.640
che registra solo quelli
transazioni di sistema

00:03:55.640 --> 00:03:57.005
che non può essere sottoposto a controllo delle versioni.

00:03:57.005 --> 00:03:59.150
Così la maggior parte delle versioni dei dati è possibile

00:03:59.150 --> 00:04:01.715
cambiare prima e dopo
immagini dei dati.

00:04:01.715 --> 00:04:04.070
Così alcuni cambiamenti di schema,

00:04:04.070 --> 00:04:06.195
alcune cose del genere,
non può essere sottoposto a controllo delle versioni.

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

00:04:06.570 --> 00:04:07.890
>> Quindi quelli vengono registrati in sLog.

00:04:07.890 --> 00:04:09.195
Quindi l'idea è che sia,

00:04:09.195 --> 00:04:11.580
pochissimi significativi.

00:04:11.580 --> 00:04:13.920
>> Ci sarà un piccolo
serie di proiezioni, giusto?

00:04:13.920 --> 00:04:17.525
>> Quindi parte dell'analisi
e la fase di rifare è

00:04:17.525 --> 00:04:23.100
ricreare i registri in memoria
dai record del log delle transazioni.

00:04:23.230 --> 00:04:25.850
Quindi rifare dal sLog,

00:04:25.850 --> 00:04:28.300
sta solo sfruttando l'archivio versioni.

00:04:28.300 --> 00:04:31.195
Perché abbiamo prima e dopo
versioni di tutte queste righe,

00:04:31.195 --> 00:04:34.010
quindi è molto veloce e
poi si rifa da

00:04:34.010 --> 00:04:38.905
il registro solo dal
l'ultimo checkpoint in avanti.

00:04:38.905 --> 00:04:42.810
A quel punto, il database
è completamente disponibile.

00:04:43.420 --> 00:04:46.910
Undo è solo il ripristino

00:04:46.910 --> 00:04:48.875
le versioni in modo da solo

00:04:48.875 --> 00:04:51.710
punto alla versione precedente
anziché la versione corrente.

00:04:51.710 --> 00:04:55.345
Non è necessario annullare fisicamente
la transazione e stornare.

00:04:55.345 --> 00:04:59.825
>> Quindi questo sta per essere modo
più veloce di quello più vecchio normalmente?

00:04:59.825 --> 00:05:01.880
>> Modo più veloce. Avevamo un cliente in

00:05:01.880 --> 00:05:04.280
il laboratorio all'interno dell'ultimo paio di
settimane che ha fatto qualche test con

00:05:04.280 --> 00:05:10.050
ADR e avevano un molto
carico di lavoro di aggiornamento attivo.

00:05:10.050 --> 00:05:13.065
Avevano un lungo periodo
transazione con esso.

00:05:13.065 --> 00:05:14.430
L'hanno fatto, questo,

00:05:14.430 --> 00:05:17.450
e ha fatto un rollback di tale
transazione a esecuzione prolungata.

00:05:17.450 --> 00:05:20.555
Senza ADR, ci sono voluti
minuto e mezzo per farlo.

00:05:20.555 --> 00:05:24.765
>> Che non è ancora
peccato ma va bene, a lungo.

00:05:24.765 --> 00:05:26.190
>> sì. Nei loro affari,

00:05:26.190 --> 00:05:28.105
fa una grande differenza.

00:05:28.105 --> 00:05:30.680
Così poi hanno ritentato
quello stesso scenario

00:05:30.680 --> 00:05:32.780
con ADR e il tempo che ci è voluto

00:05:32.780 --> 00:05:36.720
per fare che il recupero era zero secondi.

00:05:36.720 --> 00:05:38.505
Non potevano misurare
era così veloce.

00:05:38.505 --> 00:05:40.110
>> Questo è impressionante.

00:05:40.110 --> 00:05:43.580
>> Quindi, per loro, sono tornati
sulla linea che molto più veloce,

00:05:43.580 --> 00:05:47.425
che fa una grande differenza
anche perché nel loro business,

00:05:47.425 --> 00:05:49.560
qualsiasi interruzione è una perdita di entrate.

00:05:49.560 --> 00:05:51.375
>> Così millisecondi contano, giusto?

00:05:51.375 --> 00:05:52.230
>> Molto.

00:05:52.230 --> 00:05:53.880
>> Quindi, se possiamo aiutare questo cliente

00:05:53.880 --> 00:05:55.575
spostato da un minuto e mezzo,

00:05:55.575 --> 00:05:58.305
hai detto fondamentalmente zero,

00:05:58.305 --> 00:05:59.895
che è impressionante. Quindi wow.

00:05:59.895 --> 00:06:02.930
Così tutti i nostri clienti

00:06:02.930 --> 00:06:05.810
sono probabilmente voler
provare questo e abilitare questo.

00:06:05.810 --> 00:06:08.450
Quindi puoi dirmi come lo faccio?

00:06:08.450 --> 00:06:09.470
Ora ho un database,

00:06:09.470 --> 00:06:12.995
Ce l'ho sul normale
recupero, quindi cosa devo fare?

00:06:12.995 --> 00:06:14.585
>> Quindi, con il database SQL di Azure,

00:06:14.585 --> 00:06:16.775
è attivato per impostazione predefinita a livello globale.

00:06:16.775 --> 00:06:19.130
E 'stato acceso per impostazione predefinita
in tutto il mondo per mesi.

00:06:19.130 --> 00:06:20.540
Quindi non c'è bisogno di
fare qualsiasi cosa lì.

00:06:20.540 --> 00:06:22.520
Ne hai già approfittato.

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

00:06:23.740 --> 00:06:26.940
>> Per i database di SQL Server,

00:06:26.940 --> 00:06:29.060
è spento di default perché c'è

00:06:29.060 --> 00:06:31.610
qualche sovraccarico sulla gamma di

00:06:31.610 --> 00:06:35.880
uno al cinque per cento per
tenere traccia delle versioni.

00:06:36.190 --> 00:06:41.015
Quindi dovresti accenderlo e
che è solo, modificare il set di database,

00:06:41.015 --> 00:06:42.635
il recupero accelerato del database è uguale

00:06:42.635 --> 00:06:46.410
su e facoltativamente con
gruppo di file uguale a.

00:06:46.410 --> 00:06:47.310
>> Qualcosa.

00:06:47.310 --> 00:06:49.810
>> sì. Quindi DDL molto semplice.

00:06:49.810 --> 00:06:51.710
>> Allora cosa succede?

00:06:51.710 --> 00:06:54.410
>> Poi inizia il monitoraggio
versioni e si ottiene il vantaggio.

00:06:54.410 --> 00:06:55.970
>> Cool. È diretto,

00:06:55.970 --> 00:06:58.065
immediato, o è che come,

00:06:58.065 --> 00:06:59.250
è necessario un riavvio.

00:06:59.250 --> 00:07:01.740
>> Nessun riavvio. Sei solo online.

00:07:01.740 --> 00:07:03.705
>> Cool. Quindi wow.

00:07:03.705 --> 00:07:05.160
Quindi, in pratica, questo è come

00:07:05.160 --> 00:07:08.545
una tecnologia molto cool per
ripristinare un database molto rapidamente.

00:07:08.545 --> 00:07:10.730
C'è qualcos'altro che ottengo da questo?

00:07:10.730 --> 00:07:12.140
Voglio dire, questo è davvero
molto impressionante, ma

00:07:12.140 --> 00:07:13.580
questi sono come vantaggi extra.

00:07:13.580 --> 00:07:15.590
>> Quindi c'è un beneficio in più in

00:07:15.590 --> 00:07:19.115
che a causa del modo in cui
riutilizziamo le versioni,

00:07:19.115 --> 00:07:22.470
non dobbiamo tenere come
molto registro delle transazioni online.

00:07:22.470 --> 00:07:24.920
Così si può troncare il
registro delle transazioni molto di più

00:07:24.920 --> 00:07:28.725
aggressivamente fino all'ultimo
checkpoint di quanto si potesse prima.

00:07:28.725 --> 00:07:30.530
Il che significa che, se hai
ha la situazione,

00:07:30.530 --> 00:07:32.540
abbiamo un lungo running
transazione che ti tiene

00:07:32.540 --> 00:07:34.460
dall'essere in grado di troncare

00:07:34.460 --> 00:07:36.620
il tuo registro e la transazione
log inizia a saltare in aria,

00:07:36.620 --> 00:07:38.665
che non accade
con ADR attivato.

00:07:38.665 --> 00:07:41.400
>> Quindi, fondamentalmente questo è
il beneficio aggiuntivo.

00:07:41.400 --> 00:07:43.650
Nessuna transazione lunga
log trascinando lungo.

00:07:43.650 --> 00:07:44.505
>> Esattamente.

00:07:44.505 --> 00:07:45.990
>> So cosa farò,

00:07:45.990 --> 00:07:47.660
Voglio dire MySQL server era andare a

00:07:47.660 --> 00:07:49.760
accelerare un database
recupero in questo momento.

00:07:49.760 --> 00:07:51.470
Dopo questo video, lo farò.

00:07:51.470 --> 00:07:52.805
Grazie mille per la condivisione.

00:07:52.805 --> 00:07:53.345
>> Grazie.

00:07:53.345 --> 00:07:55.940
>> Grazie per la spiegazione.
Questo è stato molto chiaro.

00:07:55.940 --> 00:07:57.575
Grazie per la visione.

00:07:57.575 --> 00:08:00.990
Si prega di come e iscriversi e
rimanete sintonizzati per il prossimo. Grazie.

00:08:00.990 --> 00:08:13.210
[MUSICA]