WEBVTT

00:00:00.000 --> 00:00:01.830
SQL Server 2019 fournit

00:00:01.830 --> 00:00:04.995
une nouvelle fonctionnalité pour Linux appelé
Tampons de journal persistants.

00:00:04.995 --> 00:00:06.960
Il était disponible pour Windows avant,

00:00:06.960 --> 00:00:08.385
de nos jours sur Linux ainsi,

00:00:08.385 --> 00:00:10.740
et il vous aide à éliminer
goulots d'étranglement qui pourraient

00:00:10.740 --> 00:00:14.130
se produire en attendant un journal
tampon deux chasse d'eau au disque.

00:00:14.130 --> 00:00:18.300
Brian est ici pour nous dire à tous
à ce sujet aujourd'hui sur les données exposées.

00:00:18.300 --> 00:00:29.040
[MUSIQUE]

00:00:29.040 --> 00:00:32.115
Salut, et bienvenue dans un autre
épisode de Data Exposed.

00:00:32.115 --> 00:00:35.220
Je suis ton hôte Jeroen, et
aujourd'hui, j'ai Brian avec moi

00:00:35.220 --> 00:00:38.460
pour parler de Persistent
Tampons de journal dans SQL 2019.

00:00:38.460 --> 00:00:40.230
Salut, Brian, bienvenue au spectacle.

00:00:40.230 --> 00:00:42.195
Salut, Jeroen. Je vous remercie.

00:00:42.195 --> 00:00:46.045
Alors, qu'est-ce qu'on va parler
sur Persistent Long Buffers?

00:00:46.045 --> 00:00:47.160
Oui, c'est vrai. Donc-

00:00:47.160 --> 00:00:47.685
Qu'est-ce que c'est que ça ?

00:00:47.685 --> 00:00:50.400
- Si persistent Log
Buffer est l'un de ce que

00:00:50.400 --> 00:00:53.325
nous appelons la mémoire dans la mémoire
Famille de fonctionnalités de base de données,

00:00:53.325 --> 00:00:55.965
qui comprend L'OLTP en mémoire,

00:00:55.965 --> 00:00:59.265
Tampon de journal persistant qui
Je vais démontrer aujourd'hui,

00:00:59.265 --> 00:01:01.845
parfois appelé Tail of Log Caching,

00:01:01.845 --> 00:01:05.040
un fichier de données et de journal
L'illumination dans Linux,

00:01:05.040 --> 00:01:07.470
Hybrid Buffer Pool à
Linux et Windows,

00:01:07.470 --> 00:01:09.870
et les métadonnées TempDB Deminoptimise De mémoire.

00:01:09.870 --> 00:01:11.370
D'accord. Cool.

00:01:11.370 --> 00:01:17.195
Je vais donc mentionner rapidement
sur les dispositifs de mémoire persistants.

00:01:17.195 --> 00:01:19.550
Beaucoup de gens n'ont pas
vu, mais essentiellement

00:01:19.550 --> 00:01:21.730
ce sont des DIMM réguliers que vous

00:01:21.730 --> 00:01:26.275
alimenter votre serveur qui
différentes capacités.

00:01:26.275 --> 00:01:30.545
MVDIMM-N qui est un type de
technologie de mémoire persistante,

00:01:30.545 --> 00:01:34.325
vient un 8, 16, ou 32
gig DIMM capacité,

00:01:34.325 --> 00:01:36.980
et puis le dernier Intel obtenu

00:01:36.980 --> 00:01:41.150
DC Mémoire persistante entre en
capacités beaucoup plus élevées d'un 128,

00:01:41.150 --> 00:01:44.810
256 gigaoctets, ou 512 gigaoctets DIMM.

00:01:44.810 --> 00:01:46.820
C'est tout.
mémoire persistante. Wow.

00:01:46.820 --> 00:01:48.060
Oui, c'est vrai. Donc vous pouvez,

00:01:48.060 --> 00:01:49.290
sur un serveur de prise nate,

00:01:49.290 --> 00:01:52.370
vous pouvez soutenir jusqu'à 24
téraoctets de mémoire persistante.

00:01:52.370 --> 00:01:53.750
Je peux déverrouiller tous les

00:01:53.750 --> 00:01:55.970
qu'avec cette persistance
tampon de journal, non?

00:01:55.970 --> 00:01:56.570
C'est exact.

00:01:56.570 --> 00:01:57.680
C'est pas le tout.

00:01:57.680 --> 00:02:00.110
Journal persistant
Buffer est conçu pour

00:02:00.110 --> 00:02:02.075
résoudre un cas particulier d'utilisation

00:02:02.075 --> 00:02:07.400
où vous encouriez des ralentissements
ou attend dans votre charge de travail,

00:02:07.400 --> 00:02:12.385
en attente de la mémoire tampon de journal qui
est dans la mémoire de rincer au disque.

00:02:12.385 --> 00:02:13.005
D'accord.

00:02:13.005 --> 00:02:16.114
Il utilise donc le
dispositif de mémoire persistant

00:02:16.114 --> 00:02:19.355
sur elle sait qu'une fois qu'il est
écrit à cet appareil,

00:02:19.355 --> 00:02:21.650
qu'il n'a pas besoin
d'attendre la chasse d'eau

00:02:21.650 --> 00:02:24.270
parce qu'il est déjà sur
un dispositif persistant.

00:02:24.270 --> 00:02:26.195
Ensuite, l'appareil
s'occuper du reste.

00:02:26.195 --> 00:02:28.835
Oui, l'appareil
puis prendre soin du reste

00:02:28.835 --> 00:02:31.730
pendant que vous continuez essentiellement
avec votre charge de travail.

00:02:31.730 --> 00:02:32.180
Oui, c'est vrai.

00:02:32.180 --> 00:02:35.585
Donc, quand vous êtes en place
ces appareils dans Windows,

00:02:35.585 --> 00:02:41.600
nous avons quelques recommandations de base
que vous verrouillez les pages en mémoire,

00:02:41.600 --> 00:02:44.150
vous utilisez les deux mégaoctets
taille de l'unité d'allocation

00:02:44.150 --> 00:02:46.760
pour NTFS qui ne sera pas en défaut.

00:02:46.760 --> 00:02:47.180
D'accord.

00:02:47.180 --> 00:02:49.715
Il faut aussi que vous
définir ce drapeau DAX.

00:02:49.715 --> 00:02:51.920
Donc, DAX est vraiment ce qui nous permet de

00:02:51.920 --> 00:02:55.280
traiter une mémoire persistante
dispositif et lui écrire

00:02:55.280 --> 00:02:57.260
sauter directement tous les

00:02:57.260 --> 00:02:59.795
la pile de noyau qui

00:02:59.795 --> 00:03:03.090
vous auriez généralement besoin
lorsqu'il s'agit de dossiers.

00:03:03.090 --> 00:03:05.145
Ne sera pas disponible dans l'interface graphique,

00:03:05.145 --> 00:03:07.250
de sorte que vous aurez besoin d'utiliser
certains PowerShell pour cela.

00:03:07.250 --> 00:03:09.560
D'accord. D'accord. Vous
montrez-nous comment cela fonctionne, non?

00:03:09.560 --> 00:03:13.325
Oui, c'est vrai. Je vais montrer comment
ceux-ci sont configurés.

00:03:13.325 --> 00:03:16.430
Aussi certains de votre niveau OS
compteurs de disques que vous

00:03:16.430 --> 00:03:19.510
peut être habitué à regarder comme
ces transferts et ainsi de suite,

00:03:19.510 --> 00:03:21.830
peut ne pas être disponible pour

00:03:21.830 --> 00:03:24.200
vous quand vous travaillez avec
dispositifs de mémoire persistants.

00:03:24.200 --> 00:03:28.865
C'est juste une des choses
vous devez être conscient de.

00:03:28.865 --> 00:03:29.330
Bien sûr.

00:03:29.330 --> 00:03:33.575
Il s'agit de nouveaux appareils et
est très tout nouveau tack passionnant.

00:03:33.575 --> 00:03:33.935
D'accord.

00:03:33.935 --> 00:03:37.565
Il peut donc y avoir des captures
jusqu'à faire du côté de la surveillance.

00:03:37.565 --> 00:03:38.245
Bien sûr.

00:03:38.245 --> 00:03:42.580
Pour Linux, non volatil
contrôle de l'appareil

00:03:42.580 --> 00:03:45.110
est l'utilité que vous
utiliser pour configurer cela.

00:03:45.110 --> 00:03:47.840
Vous le définirez en mode fsdax,

00:03:47.840 --> 00:03:50.795
utiliser deux mégaoctets énormes défauts de page,

00:03:50.795 --> 00:03:53.555
définir votre allocation de bloc
aussi à deux mégaoctets.

00:03:53.555 --> 00:03:56.180
Nous soutenons XFS ou EXT

00:03:56.180 --> 00:04:00.620
car ce sont deux soutenus
systèmes de fichiers avec DAX.

00:04:00.620 --> 00:04:01.295
D'accord.

00:04:01.295 --> 00:04:03.050
- Donc, tampon de journal persistant,

00:04:03.050 --> 00:04:05.585
cela a été disponible
en fait dans SQL depuis

00:04:05.585 --> 00:04:10.140
SQL 2016 uniquement pour Windows jusqu'à présent.

00:04:10.140 --> 00:04:12.470
Avec SQL 2019, nous aurons aussi

00:04:12.470 --> 00:04:15.875
cette fonctionnalité maintenant disponible
Linux ainsi que Windows.

00:04:15.875 --> 00:04:18.590
Utilise seulement un très petit
quantité de capacité,

00:04:18.590 --> 00:04:21.720
le tampon de journal est seulement 20
mégaoctets par base de données utilisateur.

00:04:21.720 --> 00:04:22.355
D'accord.

00:04:22.355 --> 00:04:26.330
Donc, il ne faut vraiment pas
jusqu'à une énorme quantité de capacité,

00:04:26.330 --> 00:04:28.850
et le comportement que vous obtenez est très

00:04:28.850 --> 00:04:31.250
semblable à forcer
durabilité retardée.

00:04:31.250 --> 00:04:31.910
D'accord.

00:04:31.910 --> 00:04:34.040
Encore une fois, vous n'attendez pas

00:04:34.040 --> 00:04:36.890
que Log flush à arriver au disque

00:04:36.890 --> 00:04:40.040
mais n'a encouragé aucun des risques qui

00:04:40.040 --> 00:04:43.235
vous prenez ce que forcé retardé
Durabilité autour de la perte de données.

00:04:43.235 --> 00:04:45.290
Alors pouvez-vous nous dire un
un peu plus sur

00:04:45.290 --> 00:04:47.550
Durabilité retardée forcée
pour ceux qui sont-

00:04:47.550 --> 00:04:48.615
Bien sûr, pour ceux-

00:04:48.615 --> 00:04:49.425
-pas au courant de cela?

00:04:49.425 --> 00:04:52.095
Oui, c'est vrai. Pour ceux qui
ne sont pas familiers,

00:04:52.095 --> 00:04:53.840
c'est essentiellement

00:04:53.840 --> 00:04:57.260
un commit asynchrone
mécanisme dans SQL Server.

00:04:57.260 --> 00:04:57.710
D'accord.

00:04:57.710 --> 00:05:01.280
Il y a donc un couple
des moyens de le faire.

00:05:01.280 --> 00:05:03.740
On est autorisé, auquel cas

00:05:03.740 --> 00:05:07.190
vos commits normaux
se produire comme vous vous y attendez,

00:05:07.190 --> 00:05:08.270
vous attendez la chasse d'eau,

00:05:08.270 --> 00:05:10.455
attendre qu'ils soient durcis sur disque,

00:05:10.455 --> 00:05:15.440
ou dans un mode forcé où tous les
s'engage à se comporter comme ça.

00:05:15.440 --> 00:05:16.000
D'accord.

00:05:16.000 --> 00:05:19.220
Donc, ce qui a permis dans
vous spécifiez sur un par

00:05:19.220 --> 00:05:22.880
engager la base si vous voulez ce
comportement et c'est permis,

00:05:22.880 --> 00:05:24.935
refusé qui est la valeur par défaut

00:05:24.935 --> 00:05:27.425
n'a pas d'importance ce que vous avez dans
là, ça n'arrivera pas.

00:05:27.425 --> 00:05:27.905
Bien sûr.

00:05:27.905 --> 00:05:30.170
Puis forcé tous les
s'engage de cette façon.

00:05:30.170 --> 00:05:32.285
D'accord. Donc, dans un persistant
faible niveau est très

00:05:32.285 --> 00:05:34.890
similaires, mais pas tout à fait les mêmes.

00:05:34.890 --> 00:05:37.215
- Très similaire, mais
pas tout à fait la même chose,

00:05:37.215 --> 00:05:39.845
parce que nous avons le
dispositif de mémoire persistant,

00:05:39.845 --> 00:05:42.965
nous avons mis notre tampon de journal là-bas,

00:05:42.965 --> 00:05:46.640
et une fois que nous écrivons là-bas, nous savons
qu'il a persisté et nous

00:05:46.640 --> 00:05:50.360
n'ont aucun risque de perte de données
en cas de plantage de serveur,

00:05:50.360 --> 00:05:53.000
panne de courant, n'importe quoi
de cette nature,

00:05:53.000 --> 00:05:56.570
nous pouvons récupérer des données sur
l'appareil de mémoire persistant.

00:05:56.570 --> 00:05:57.920
D'accord. Cool.

00:05:57.920 --> 00:06:00.230
C'est en fait assez simple.

00:06:00.230 --> 00:06:01.640
Beaucoup de gens ne se rendent pas compte,

00:06:01.640 --> 00:06:04.355
il vous suffit d'ajouter un fichier journal

00:06:04.355 --> 00:06:07.580
de 20 mégaoctets sur le
dispositif de mémoire persistant,

00:06:07.580 --> 00:06:10.370
SQL Server
reconnaître cet appareil,

00:06:10.370 --> 00:06:13.265
et le traitera comme le tampon de journal.

00:06:13.265 --> 00:06:14.405
C'est très simple

00:06:14.405 --> 00:06:15.665
Vraiment aussi simple que ça.

00:06:15.665 --> 00:06:16.205
C'est pas le tout.

00:06:16.205 --> 00:06:19.550
Oui, et comme nous pouvons le voir
voici tampon de journal assis sur

00:06:19.550 --> 00:06:23.090
notre mémoire de classe de stockage
qui est PMM parfois

00:06:23.090 --> 00:06:26.480
nous l'appelons classe de stockage
mémoire et dans certains endroits

00:06:26.480 --> 00:06:30.405
mais la même chose et notre
les registres sont là,

00:06:30.405 --> 00:06:31.950
et comme je l'ai mentionné,

00:06:31.950 --> 00:06:33.200
nous n'avons pas à attendre
pour eux à travers

00:06:33.200 --> 00:06:36.365
rincé à la principale
fichier journal des transactions.

00:06:36.365 --> 00:06:37.010
Cool.

00:06:37.010 --> 00:06:41.875
Donc, je vais juste passer
rapidement à ma démo ici.

00:06:41.875 --> 00:06:42.990
Oui, c'est vrai.

00:06:42.990 --> 00:06:46.280
D'abord, je vais juste montrer
que nous avons configuré

00:06:46.280 --> 00:06:49.310
ici nos dispositifs de mémoire persistants.

00:06:49.310 --> 00:06:50.945
Comme je l'ai mentionné, ces
sont des DIMM réguliers,

00:06:50.945 --> 00:06:53.180
vous pouvez voir les ID de l'appareil là-bas.

00:06:53.180 --> 00:06:56.405
Nous avons configuré deux
d'appareils un par nœud NUMA.

00:06:56.405 --> 00:06:56.855
D'accord.

00:06:56.855 --> 00:07:01.565
Entrelacés sur les appareils
à DIMMs sur ce nœud NUMA.

00:07:01.565 --> 00:07:05.330
Donc, c'est le recommandé
façon dont nous disons de le mettre en place.

00:07:05.330 --> 00:07:06.410
D'accord.

00:07:06.410 --> 00:07:08.950
Encore une fois, nous pouvons voir que

00:07:08.950 --> 00:07:12.920
notre valeur DAX est activée
il mis à vrai ici,

00:07:12.920 --> 00:07:17.464
et si nous voulons utiliser notre ancien
utilitaire de type ligne de commande,

00:07:17.464 --> 00:07:21.830
nous pouvons juste obtenir ce petit
peu plus d'infos ici et nous pouvons

00:07:21.830 --> 00:07:26.450
voir que nous avons fixé l'allocation
d'unité à deux mégaoctets.

00:07:26.450 --> 00:07:28.640
Comme vous venez de le décrire.
Ca devrait être.oui.

00:07:28.640 --> 00:07:31.505
Oui, c'est vrai. Comme je viens de
décrit et tout à fait

00:07:31.505 --> 00:07:36.185
simple, nous venons d'ajouter le
fichier journal, comme je l'ai mentionné,

00:07:36.185 --> 00:07:38.205
et nous créons et créons

00:07:38.205 --> 00:07:40.700
quelle que soit la taille que vous
le mettre ici, nous allons effectivement

00:07:40.700 --> 00:07:42.860
intégré pour utiliser 20 mégaoctets

00:07:42.860 --> 00:07:46.025
mais il suffit d'aller de l'avant et
disons 20 mégaoctets se trouve.

00:07:46.025 --> 00:07:47.975
Oui, c'est vrai. Juste pour être sûr.

00:07:47.975 --> 00:07:50.960
Oui, et c'est aussi simple que ça.

00:07:50.960 --> 00:07:52.550
C'est pas le tout. D'accord.

00:07:52.550 --> 00:07:54.200
C'est impressionnant.

00:07:54.200 --> 00:07:56.900
Donc, fondamentalement, je peux déverrouiller
toutes ces nouvelles technologies avec

00:07:56.900 --> 00:07:58.580
un tampon de journal persistant par juste

00:07:58.580 --> 00:08:00.650
exécution commande très simple, non?

00:08:00.650 --> 00:08:01.055
Oui, c'est vrai.

00:08:01.055 --> 00:08:02.930
Bien sûr. Vous devez
configurer l'appareil en premier,

00:08:02.930 --> 00:08:05.965
et puis après que c'est fait
dans SQL vous venez d'ajouter un journal.

00:08:05.965 --> 00:08:09.350
Oui, et ce type

00:08:09.350 --> 00:08:12.725
de la technologie est vraiment
permettant un nouveau niveau de

00:08:12.725 --> 00:08:15.020
stockage aidant à supprimer une partie de

00:08:15.020 --> 00:08:17.075
les traditionnels
goulots d'étranglement que nous voyons

00:08:17.075 --> 00:08:19.640
dans SQL Server sur les charges de travail haut de gamme.

00:08:19.640 --> 00:08:22.220
C'est vrai. Si grande innovation, mais

00:08:22.220 --> 00:08:24.710
puis fait d'une manière très simple

00:08:24.710 --> 00:08:26.570
pour l'utilisateur et pour
la configuration.

00:08:26.570 --> 00:08:29.360
Oui, c'est vrai. Nous construisons l'intelligence
dans SQL Server à

00:08:29.360 --> 00:08:32.240
reconnaître ces dispositifs
et se comporter en conséquence.

00:08:32.240 --> 00:08:34.295
Oui, c'est vrai. Très cool. Bien
merci pour le partage.

00:08:34.295 --> 00:08:34.895
Merci.

00:08:34.895 --> 00:08:36.560
Je pense que c'était très utile,

00:08:36.560 --> 00:08:37.910
très intéressant, du moins pour moi.

00:08:37.910 --> 00:08:40.490
J'espère que cela a été utile et
intéressant pour vous aussi.

00:08:40.490 --> 00:08:43.065
S'll vous plaît, abonnez-vous, genre,
commenter la vidéo,

00:08:43.065 --> 00:08:44.660
et j'espère vous voir la prochaine fois sur

00:08:44.660 --> 00:08:47.040
un autre épisode de
Données exposées. Merci.

00:08:47.040 --> 00:09:01.630
[MUSIQUE]