WEBVTT

00:00:00.000 --> 00:00:02.055
Récupération de la base de données avec

00:00:02.055 --> 00:00:05.190
transactions de longue durée
a été un défi.

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

00:00:07.050 --> 00:00:09.780
nous introduisons accéléré
récupération de base de données

00:00:09.780 --> 00:00:11.190
pour aider à résoudre ce problème.

00:00:11.190 --> 00:00:13.605
Kevin est ici pour dire
nous tous à ce sujet,

00:00:13.605 --> 00:00:15.390
aujourd'hui sur les données exposées.

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

00:00:26.130 --> 00:00:28.755
Salut et bienvenue dans un autre
épisode de Data Exposed.

00:00:28.755 --> 00:00:30.745
Je suis ton hôte, Jeroen et aujourd'hui,

00:00:30.745 --> 00:00:34.415
nous avons Kevin avec nous pour parler
accélération de la récupération des bases de données.

00:00:34.415 --> 00:00:35.975
Alors bienvenue Kevin à l'émission.

00:00:35.975 --> 00:00:36.665
Merci.

00:00:36.665 --> 00:00:39.125
La récupération accélérée de la base de données.

00:00:39.125 --> 00:00:40.750
Qu'est-ce que c'est ?

00:00:40.750 --> 00:00:41.930
C'est donc une caractéristique intéressante.

00:00:41.930 --> 00:00:43.340
Nous allons l'appeler ADR pour faire court.

00:00:43.340 --> 00:00:44.890
D'accord, bien sûr.

00:00:44.890 --> 00:00:46.970
Il est venu de
en regardant certains des

00:00:46.970 --> 00:00:48.530
points de douleur que les clients ont eu

00:00:48.530 --> 00:00:51.770
l'exécution de bases de données et la conservation
très disponibles et

00:00:51.770 --> 00:00:53.270
une partie de celui-ci a à voir avec le temps qu'il

00:00:53.270 --> 00:00:55.475
prend pour mettre une base de données en ligne.

00:00:55.475 --> 00:00:58.970
Il y a un certain nombre de phases qui
une base de données doit passer,

00:00:58.970 --> 00:01:01.340
et si vous avez une longue
transaction en cours d'exécution,

00:01:01.340 --> 00:01:04.010
il peut prendre beaucoup de temps
pour nettoyer cela et que

00:01:04.010 --> 00:01:07.080
conduit à l'indisponibilité lorsque
il fait ce traitement.

00:01:07.080 --> 00:01:10.545
C'est vrai. Donc, nous savons que cette
la restauration est un point de douleur.

00:01:10.545 --> 00:01:13.530
Le ramener est
quelque chose que les DBA,

00:01:13.530 --> 00:01:15.075
Eh bien, genre d'inquiétude.

00:01:15.075 --> 00:01:16.790
C'est vrai. Alors l'équipe a regardé

00:01:16.790 --> 00:01:19.520
tout ce processus et la pensée
comment pouvons-nous le réimaginer?

00:01:19.520 --> 00:01:21.335
Donc, ils ont trouvé aDR,

00:01:21.335 --> 00:01:23.210
il est basé sur un magasin de version.

00:01:23.210 --> 00:01:26.170
Donc, tous les changements sont
version dans la base de données.

00:01:26.170 --> 00:01:29.920
Qui vit dans le dossier
groupe de votre choix.

00:01:30.140 --> 00:01:34.925
En tirant parti de cela, nous pouvons
processus de récupération beaucoup plus rapide.

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

00:01:35.600 --> 00:01:40.965
J'ai quelques diapositives
qui démontrent.

00:01:40.965 --> 00:01:46.515
Donc, ici, nous avons le
processus de récupération classique.

00:01:46.515 --> 00:01:48.350
Donc, il commence, la phase 1 est l'analyse.

00:01:48.350 --> 00:01:50.360
Donc, vous devez regarder à travers
toutes les transactions

00:01:50.360 --> 00:01:53.020
dans le journal de la dernière
point de contrôle vers l'avant.

00:01:53.020 --> 00:01:56.150
Redo est tout changement de données

00:01:56.150 --> 00:01:58.700
qui n'a pas été persisté
dans les fichiers de données,

00:01:58.700 --> 00:02:01.850
doivent être refaits à partir de
le journal des transactions,

00:02:01.850 --> 00:02:03.020
tout au long de la

00:02:03.020 --> 00:02:05.420
le début de la plus ancienne,
transactions non engagées.

00:02:05.420 --> 00:02:07.790
C'est donc là que le long terme
transactions vous ont vraiment fait mal.

00:02:07.790 --> 00:02:08.560
C'est vrai, exactement.

00:02:08.560 --> 00:02:12.170
Il peut prendre quelques minutes pour
une heure ou plus parfois.

00:02:12.170 --> 00:02:14.660
Ensuite, la phase 3 est défaire,

00:02:14.660 --> 00:02:17.270
où vous défaire toutes les transactions qui

00:02:17.270 --> 00:02:20.975
n'ont pas été commis avant le
temps que vous attends avec impatience.

00:02:20.975 --> 00:02:23.285
Au moment où la lecture se termine,

00:02:23.285 --> 00:02:25.375
la base de données est partiellement disponible.

00:02:25.375 --> 00:02:28.670
Ce que cela signifie, c'est que vous pouvez
accéder à la base de données, mais

00:02:28.670 --> 00:02:33.270
toutes les données qui n'étaient pas sous clé
des transactions initiales,

00:02:33.270 --> 00:02:34.320
sera sous clé maintenant.

00:02:34.320 --> 00:02:36.200
Donc, même s'il y a
personne ne les fait,

00:02:36.200 --> 00:02:39.230
vous ne pouvez pas accéder à ces données
jusqu'à ce qu'on se défaire.

00:02:39.230 --> 00:02:41.930
Donc, fondamentalement, c'est
un processus de longue durée

00:02:41.930 --> 00:02:45.835
et puis seulement après
nous arrivons à la phase 3,

00:02:45.835 --> 00:02:47.900
Je peux commencer à faire

00:02:47.900 --> 00:02:49.580
tout ce que je voulais avec
la base de données à nouveau, non?

00:02:49.580 --> 00:02:50.165
C'est vrai.

00:02:50.165 --> 00:02:53.585
Alors dis-moi comment c'était.

00:02:53.585 --> 00:02:55.865
Sur le fond, vous voyez juste

00:02:55.865 --> 00:02:59.145
enregistrement de journal avec différents
événements dans l'enregistrement du journal.

00:02:59.145 --> 00:03:00.165
Bien sûr.

00:03:00.165 --> 00:03:02.190
L'ADR change beaucoup.

00:03:02.190 --> 00:03:03.750
Nous avons le magasin de version de traitement.

00:03:03.750 --> 00:03:06.375
Vous verrez qu'il fait référence à PVS.

00:03:06.375 --> 00:03:09.464
Quand on l'a mis dans les avant-premières,

00:03:09.464 --> 00:03:11.915
PVS vivait dans le groupe de fichiers primaires

00:03:11.915 --> 00:03:13.820
et il n'y a pas de capa cité
pour changer cela.

00:03:13.820 --> 00:03:16.780
Donc c'est arrivé, c'est là que
toutes ces versions ont vécu.

00:03:16.780 --> 00:03:19.550
Nous avons reçu des commentaires qui
clients aimeraient

00:03:19.550 --> 00:03:22.280
être en mesure de préciser lequel
groupe de fichiers qui vit dans.

00:03:22.280 --> 00:03:26.180
J'ai un groupe de fichiers en vrac ou
groupe de fichiers très rapide, que ce soit.

00:03:26.180 --> 00:03:27.740
Alors maintenant, vous êtes avec

00:03:27.740 --> 00:03:31.130
le candidat de libération et avec
la version GA quand il sort,

00:03:31.130 --> 00:03:33.910
vous serez en mesure de spécifier lequel
groupe de fichiers et le changer,

00:03:33.910 --> 00:03:35.880
il ya un processus pour
le changer aussi.

00:03:35.880 --> 00:03:38.120
Mais passons par ce que
le processus de récupération

00:03:38.120 --> 00:03:39.755
ressemble à ADR.

00:03:39.755 --> 00:03:42.110
Donc, il commence par l'analyse,

00:03:42.110 --> 00:03:45.695
qui est inchangé par rapport à
ce que vous aviez avant.

00:03:45.695 --> 00:03:47.015
C'est le même comportement, non ?

00:03:47.015 --> 00:03:49.805
C'est vrai. Nous avons introduit
le concept d'un sLog.

00:03:49.805 --> 00:03:52.705
Un sLog est un journal de mémoire

00:03:52.705 --> 00:03:55.640
qui enregistre seulement ceux
transactions système

00:03:55.640 --> 00:03:57.005
qui ne peut pas être versionné.

00:03:57.005 --> 00:03:59.150
Ainsi, la plupart des versions de données que vous pouvez

00:03:59.150 --> 00:04:01.715
changement avant et après
photos des données.

00:04:01.715 --> 00:04:04.070
Donc, certains changements de régime,

00:04:04.070 --> 00:04:06.195
certaines choses comme ça,
ne peut pas être versionné.

00:04:06.195 --> 00:04:06.570
Bien sûr.

00:04:06.570 --> 00:04:07.890
Donc, ceux-ci sont enregistrés dans le sLog.

00:04:07.890 --> 00:04:09.195
Donc l'idée est que c'est,

00:04:09.195 --> 00:04:11.580
un très peu significatif.

00:04:11.580 --> 00:04:13.920
Il y aura une petite
ensemble de projections, non?

00:04:13.920 --> 00:04:17.525
Une partie de l'analyse
et refaire la phase est

00:04:17.525 --> 00:04:23.100
recréer ces journaux dans la mémoire
à partir des registres des transactions.

00:04:23.230 --> 00:04:25.850
Alors refaites de la sLog,

00:04:25.850 --> 00:04:28.300
est juste en tirant parti de la boutique de version.

00:04:28.300 --> 00:04:31.195
Parce que nous avons avant et après
versions de toutes ces lignes,

00:04:31.195 --> 00:04:34.010
donc c'est très rapide et
puis vous refaites à partir de

00:04:34.010 --> 00:04:38.905
le journal juste à partir de la
dernier point de contrôle en avant.

00:04:38.905 --> 00:04:42.810
À ce moment-là, votre base de données
est entièrement disponible.

00:04:43.420 --> 00:04:46.910
Annuler, c'est juste revenir

00:04:46.910 --> 00:04:48.875
les versions de sorte que vous venez

00:04:48.875 --> 00:04:51.710
point à la version précédente
au lieu de la version actuelle.

00:04:51.710 --> 00:04:55.345
Vous n'avez pas à défaire physiquement
la transaction et l'inverse.

00:04:55.345 --> 00:04:59.825
Donc, ça va être bien
plus rapide que l'ancien normalement?

00:04:59.825 --> 00:05:01.880
Beaucoup plus vite. Nous avions un client en

00:05:01.880 --> 00:05:04.280
le laboratoire dans les deux derniers de
semaines qui ont fait quelques tests avec

00:05:04.280 --> 00:05:10.050
ADR et ils ont eu un très
charge de travail active de mise à jour.

00:05:10.050 --> 00:05:13.065
Ils avaient une longue durée
transaction avec elle.

00:05:13.065 --> 00:05:14.430
Ils ont fait ça, ça,

00:05:14.430 --> 00:05:17.450
et a fait un retour en arrière de cette
transaction de longue durée.

00:05:17.450 --> 00:05:20.555
Sans ADR, il a fallu environ un
minute et demie pour le faire.

00:05:20.555 --> 00:05:24.765
Ce qui n'est toujours pas
dommage, mais d'accord, longtemps.

00:05:24.765 --> 00:05:26.190
Oui, c'est vrai. Dans leur entreprise,

00:05:26.190 --> 00:05:28.105
cela fait une grande différence.

00:05:28.105 --> 00:05:30.680
Alors ils ont retenté
ce même scénario

00:05:30.680 --> 00:05:32.780
avec ADR et le temps qu'il a fallu

00:05:32.780 --> 00:05:36.720
pour ce faire la récupération était de zéro seconde.

00:05:36.720 --> 00:05:38.505
Ils ne pouvaient pas mesurer
il, il était si rapide.

00:05:38.505 --> 00:05:40.110
C'est impressionnant.

00:05:40.110 --> 00:05:43.580
Donc, pour eux, ils sont de retour
sur la ligne que beaucoup plus vite,

00:05:43.580 --> 00:05:47.425
ce qui fait une grande différence
aussi parce que dans leur entreprise,

00:05:47.425 --> 00:05:49.560
toute panne est une perte de revenus.

00:05:49.560 --> 00:05:51.375
Donc, les millisecondes comptent, n'est-ce pas ?

00:05:51.375 --> 00:05:52.230
C'est tout à fait.

00:05:52.230 --> 00:05:53.880
Donc, si nous pouvons aider ce client

00:05:53.880 --> 00:05:55.575
passé d'une minute et demie,

00:05:55.575 --> 00:05:58.305
vous avez dit à fondamentalement zéro,

00:05:58.305 --> 00:05:59.895
c'est impressionnant. Tellement wow.

00:05:59.895 --> 00:06:02.930
Ainsi, tous nos clients

00:06:02.930 --> 00:06:05.810
sont probablement désireux de
essayez ceci et activez ceci.

00:06:05.810 --> 00:06:08.450
Pouvez-vous me dire comment je fais ça ?

00:06:08.450 --> 00:06:09.470
J'ai une base de données maintenant,

00:06:09.470 --> 00:06:12.995
Je l'ai sur la normale
récupération, alors que dois-je faire?

00:06:12.995 --> 00:06:14.585
Donc, avec la base de données Azure SQL,

00:06:14.585 --> 00:06:16.775
il est sur par défaut à l'échelle mondiale.

00:06:16.775 --> 00:06:19.130
Il a été allumé par défaut
à l'échelle mondiale pendant des mois.

00:06:19.130 --> 00:06:20.540
Donc, vous n'avez pas besoin de
faire n'importe quoi là-bas.

00:06:20.540 --> 00:06:22.520
Tu en as déjà profité.

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

00:06:23.740 --> 00:06:26.940
Pour les bases de données SQL Server,

00:06:26.940 --> 00:06:29.060
il est éteint par défaut parce qu'il ya

00:06:29.060 --> 00:06:31.610
quelques frais généraux sur la gamme de

00:06:31.610 --> 00:06:35.880
de un à cinq pour cent pour
garder une trace des versions.

00:06:36.190 --> 00:06:41.015
Donc, vous auriez à l'allumer et
c'est juste, modifier l'ensemble de base de données,

00:06:41.015 --> 00:06:42.635
accélération de la récupération des bases de données égale

00:06:42.635 --> 00:06:46.410
sur et en option avec
groupe de fichiers égal.

00:06:46.410 --> 00:06:47.310
Quelque chose.

00:06:47.310 --> 00:06:49.810
Oui, c'est vrai. Donc très simple DDL.

00:06:49.810 --> 00:06:51.710
Alors que se passe-t-il ?

00:06:51.710 --> 00:06:54.410
Puis il commence à suivre
versions et vous obtenez l'avantage.

00:06:54.410 --> 00:06:55.970
Cool. Est-ce direct,

00:06:55.970 --> 00:06:58.065
immédiate, ou est-ce comme,

00:06:58.065 --> 00:06:59.250
il y a un redémarrage requis.

00:06:59.250 --> 00:07:01.740
Pas de redémarrage. Tu es juste en ligne.

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

00:07:03.705 --> 00:07:05.160
Donc, fondamentalement, c'est comme

00:07:05.160 --> 00:07:08.545
une technologie très cool pour
restaurer une base de données très rapidement.

00:07:08.545 --> 00:07:10.730
Quelque chose d'autre que j'en retire ?

00:07:10.730 --> 00:07:12.140
Je veux dire que c'est vraiment
très impressionnant, mais

00:07:12.140 --> 00:07:13.580
ce sont comme des avantages supplémentaires.

00:07:13.580 --> 00:07:15.590
Il y a donc un avantage supplémentaire dans

00:07:15.590 --> 00:07:19.115
que parce que la façon dont
nous réutilisons les versions,

00:07:19.115 --> 00:07:22.470
nous n'avons pas à garder comme
beaucoup de journal de transaction en ligne.

00:07:22.470 --> 00:07:24.920
Ainsi, vous pouvez tronquer le
journal des transactions beaucoup plus

00:07:24.920 --> 00:07:28.725
agressivement jusqu'à la dernière
point de contrôle que vous ne pourriez pas avant.

00:07:28.725 --> 00:07:30.530
Ce qui signifie que, si vous avez
obtenu la situation,

00:07:30.530 --> 00:07:32.540
nous avons une longue durée
transaction qui vous garde

00:07:32.540 --> 00:07:34.460
d'être capable de tronquer

00:07:34.460 --> 00:07:36.620
votre journal et la transaction
journal commence à exploser,

00:07:36.620 --> 00:07:38.665
qui n'arrive pas
avec ADR activé.

00:07:38.665 --> 00:07:41.400
Donc, fondamentalement, c'est
l'avantage supplémentaire.

00:07:41.400 --> 00:07:43.650
Pas de longue transaction
journal traîner le long.

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

00:07:44.505 --> 00:07:45.990
Je sais ce que je vais faire,

00:07:45.990 --> 00:07:47.660
Je veux dire serveur MySQL a été aller à

00:07:47.660 --> 00:07:49.760
accélérer une base de données
récupération en ce moment.

00:07:49.760 --> 00:07:51.470
Après cette vidé o, je le ferai.

00:07:51.470 --> 00:07:52.805
Merci beaucoup pour le partage.

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

00:07:53.345 --> 00:07:55.940
Merci de m'expliquer.
C'était très clair.

00:07:55.940 --> 00:07:57.575
Merci d'avoir regardé.

00:07:57.575 --> 00:08:00.990
S'il vous plaît aimer et vous abonner et
restez à l'écoute pour la prochaine. Merci.

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