WEBVTT

00:00:00.000 --> 00:00:10.500
[MUSIQUE].

00:00:10.500 --> 00:00:12.270
Salut, mon nom est Pam,

00:00:12.270 --> 00:00:15.495
et je suis gestionnaire de programme avec
l'équipe d'ingénierie serveur SQL.

00:00:15.495 --> 00:00:17.790
Aujourd'hui, j'aimerais faire
une démo rapide pour vous

00:00:17.790 --> 00:00:19.800
sur l'un des nouveaux
fonctionnalités de SQL Server.

00:00:19.800 --> 00:00:23.310
Mémoire optimisée 2019
Métadonnées TempDB.

00:00:23.310 --> 00:00:26.070
J'ai déjà fait un
vidéo d'aperçu sur

00:00:26.070 --> 00:00:27.480
cette fonctionnalité où
Je parle un peu

00:00:27.480 --> 00:00:29.040
sur certains des défis avec

00:00:29.040 --> 00:00:32.295
TempDB performance que vous
peuvent avoir fait face dans le passé et

00:00:32.295 --> 00:00:35.850
sur le travail que nous faisons en 2019
pour améliorer les performances de TempDB.

00:00:35.850 --> 00:00:38.945
Donc, je vous encourage à regarder que
vidéo si vous ne l'avez pas encore vu.

00:00:38.945 --> 00:00:41.600
Ce que nous allons faire
dans cette démo aujourd'hui est

00:00:41.600 --> 00:00:45.185
en se concentrant sur la mémoire optimisée
Fonction de métadonnées TempDB,

00:00:45.185 --> 00:00:46.805
comment vous l'activez,

00:00:46.805 --> 00:00:47.975
comment vous le désactiver.

00:00:47.975 --> 00:00:49.640
Mais aussi, comment pouvez-vous

00:00:49.640 --> 00:00:51.790
dire si vous avez besoin de
activer cette fonctionnalité.

00:00:51.790 --> 00:00:55.600
Avez-vous le problème que
cette fonctionnalité est conçue pour résoudre?

00:00:55.600 --> 00:00:58.770
Alors sautons dans le
démo et jetez un oeil.

00:01:00.220 --> 00:01:02.960
J'ai donc un carnet ouvert ici dans

00:01:02.960 --> 00:01:05.420
Studio de données Azure
avec quelques commandes.

00:01:05.420 --> 00:01:09.050
Ce que nous allons commencer par est en cours d'exécution
la charge de travail sur SQL Server.

00:01:09.050 --> 00:01:14.315
2019 sans activer la Mémoire
Fonctionnalité de métadonnées TempDB optimisée

00:01:14.315 --> 00:01:15.560
et nous allons essayer de jeter un oeil à

00:01:15.560 --> 00:01:17.930
cette affirmation selon laquelle
peut se produire à TempDB.

00:01:17.930 --> 00:01:21.050
Donc, la première chose que je suis
va faire est de commencer

00:01:21.050 --> 00:01:24.170
un moniteur de performance
collectionner et collecter

00:01:24.170 --> 00:01:26.120
quelques différents
compteurs qui donneront

00:01:26.120 --> 00:01:28.430
nous une idée de la
performance de la charge de travail.

00:01:28.430 --> 00:01:31.955
Alors je vais utiliser
l'outil de stress O

00:01:31.955 --> 00:01:34.415
d'exécuter une charge de travail multithreaded.

00:01:34.415 --> 00:01:37.700
J'ai donc huit processeurs
sur cette machine particulière,

00:01:37.700 --> 00:01:39.950
mais je lance 100
fils simultanés.

00:01:39.950 --> 00:01:42.350
J'ai donc une charge de travail très occupée

00:01:42.350 --> 00:01:44.810
ici et c'est un très
charge de travail tempDB lourde.

00:01:44.810 --> 00:01:47.210
C'est une procédure stockée de base
qui crée une table temporaire,

00:01:47.210 --> 00:01:48.360
y mettre des données,

00:01:48.360 --> 00:01:49.805
et puis sélectionne de lui.

00:01:49.805 --> 00:01:52.200
Donc vous pouvez voir ici dans Perf man.

00:01:52.200 --> 00:01:54.090
J'ai des poids en cours,

00:01:54.090 --> 00:01:55.740
poids de loquet de page en cours.

00:01:55.740 --> 00:01:58.895
J'ai aussi le temps d'attente moyen

00:01:58.895 --> 00:02:00.380
énuméréicie ici dans Perf homme ainsi.

00:02:00.380 --> 00:02:02.390
Donc vous pouvez voir que j'ai
poids de loquet bipés

00:02:02.390 --> 00:02:04.775
se passe pendant que je suis
l'exécution de cette charge de travail.

00:02:04.775 --> 00:02:07.640
Ce n'est pas inhabituel avec un
charge de travail fortement simultanée.

00:02:07.640 --> 00:02:11.580
La question ici est de savoir ce qui est
ces poids de loquet de page de?

00:02:11.580 --> 00:02:12.770
Nous ne savons pas nécessairement.

00:02:12.770 --> 00:02:14.405
Ils pourraient être de
votre base de données utilisateur.

00:02:14.405 --> 00:02:16.430
Ils pourraient venir de TempDB.

00:02:16.430 --> 00:02:18.740
Nous ne savons vraiment pas juste
en regardant la performance

00:02:18.740 --> 00:02:21.620
surveiller où ces verrous de page
poids proviennent.

00:02:21.620 --> 00:02:23.210
Donc, nous voulons retourner à

00:02:23.210 --> 00:02:25.850
Azure Data Studio et jetez un oeil à

00:02:25.850 --> 00:02:27.110
un script qui peut nous aider

00:02:27.110 --> 00:02:30.880
déterminer où ces pages
poids de loquet viennent de.

00:02:30.880 --> 00:02:32.230
On dirait que ma charge de travail est finie.

00:02:32.230 --> 00:02:34.190
Donc je vais juste le botter
reculer à nouveau afin que nous

00:02:34.190 --> 00:02:36.925
peut regarder cela Azure Data Studio.

00:02:36.925 --> 00:02:40.090
Alors revenons ici.

00:02:42.130 --> 00:02:47.135
Je vais exécuter cette requête
que j'ai au point.

00:02:47.135 --> 00:02:51.740
Ce que cette requête fait, c'est
en examinant toutes les demandes de

00:02:51.740 --> 00:02:56.510
DM demande exacte qui ont
un type de poids comme la page,

00:02:56.510 --> 00:03:00.335
ce qui signifie une sorte de
poids de loquet de page.

00:03:00.335 --> 00:03:04.010
Ce que je peux voir dans les résultats
voici que je n'ai effectivement

00:03:04.010 --> 00:03:07.295
plusieurs sessions qui sont
attente sur le loquet de la page.

00:03:07.295 --> 00:03:09.305
Si je regarde la ressource de poids,

00:03:09.305 --> 00:03:11.990
Je peux dire juste à partir du poids
ressource qu'ils sont en

00:03:11.990 --> 00:03:15.905
TempDB parce que le poids
ressource ici est 2:1:1:20.

00:03:15.905 --> 00:03:17.420
Deux est ID de base de données,

00:03:17.420 --> 00:03:18.665
deux qui est TempDB.

00:03:18.665 --> 00:03:23.570
L'un est le fichier numéro 1 et
puis 120 est le numéro de page.

00:03:23.570 --> 00:03:25.325
Donc je peux dire que c'est à TempDB.

00:03:25.325 --> 00:03:30.395
Mais si j'utilise cette nouvelle fonction
appelé dMDB page info,

00:03:30.395 --> 00:03:34.039
ce que cela me permet de faire
est de prendre cette ressource page

00:03:34.039 --> 00:03:38.330
et le casser ouvert et voir
ce qui est exactement sur cette page.

00:03:38.330 --> 00:03:41.355
Donc, à partir de cette fonction d'info page DMDB,

00:03:41.355 --> 00:03:44.150
J'obprends cet objet
nom et vous pouvez voir

00:03:44.150 --> 00:03:46.810
ici que le nom de l'objet
est sys schema objets,

00:03:46.810 --> 00:03:48.095
qui est une table système.

00:03:48.095 --> 00:03:50.944
Donc, c'est que TempDB
contention de métadonnées

00:03:50.944 --> 00:03:52.685
dont nous parlions.

00:03:52.685 --> 00:03:54.754
C'est le problème

00:03:54.754 --> 00:03:58.220
que Memory Optimized TempDB
métadonnées a été introduite pour résoudre.

00:03:58.220 --> 00:03:59.960
Revenons donc à
notre fenêtre de commande.

00:03:59.960 --> 00:04:01.115
Nous pouvons voir que c'est fini.

00:04:01.115 --> 00:04:02.450
Les deux fois qu'il a exécuté,

00:04:02.450 --> 00:04:06.005
il a fallu environ 52 secondes
pour exécuter la charge de travail.

00:04:06.005 --> 00:04:09.675
Nous pouvons bien sûr voir la page
poids de loquet qui se passe.

00:04:09.675 --> 00:04:12.300
Nous pouvons voir le lot
demandes par seconde,

00:04:12.300 --> 00:04:14.100
qui sont en tête à,

00:04:14.100 --> 00:04:18.225
Voyons ici, environ 350 maximum.

00:04:18.225 --> 00:04:20.210
Donc, c'est sans le
fonction activée.

00:04:20.210 --> 00:04:22.265
Alors allons-y et
activer la fonction.

00:04:22.265 --> 00:04:23.795
Pour ce faire,

00:04:23.795 --> 00:04:25.925
nous devons activer la fonctionnalité dans

00:04:25.925 --> 00:04:29.090
SQL Server et nous avons aussi besoin
pour redémarrer le serveur.

00:04:29.090 --> 00:04:34.250
Cette configuration de serveur alter
commande ici nécessite un redémarrage.

00:04:34.250 --> 00:04:38.875
Donc, nous allons définir cette mémoire
Des métadonnées TempDB optimisées.

00:04:38.875 --> 00:04:43.540
Ensuite, je vais aller de l'avant et
redémarrer le serveur.

00:04:44.360 --> 00:04:48.025
Puis une fois que je fais ça,

00:04:48.025 --> 00:04:50.810
Je pourrai revenir

00:04:50.810 --> 00:04:54.155
à Azure Data Studio et
exécuter une autre commande,

00:04:54.155 --> 00:04:57.470
sélectionner la propriété serveur
commande pour voir si

00:04:57.470 --> 00:05:01.160
la tempDB optimisée pour la mémoire
la fonction de métadonnées est en cours.

00:05:01.160 --> 00:05:03.265
Alors, dirigeons cette commande.

00:05:03.265 --> 00:05:07.245
Vous pouvez le voir exécuté
et la fonctionnalité est maintenant en cours.

00:05:07.245 --> 00:05:10.565
C'en est un. Alors allons-y
et exécuter notre charge de travail à nouveau.

00:05:10.565 --> 00:05:13.470
Commençons Perf man.

00:05:16.490 --> 00:05:19.350
Reprenons le coup d'envoi de notre charge de travail.

00:05:19.350 --> 00:05:20.775
Mêmes charges de travail exactes.

00:05:20.775 --> 00:05:24.130
Même procédure stockée, 100 threads.

00:05:24.130 --> 00:05:27.080
Vous remarquerez peut-être quelque chose
différent dans Perf homme tout de suite.

00:05:27.080 --> 00:05:29.900
Tout d'abord, les demandes par lots
par seconde est beaucoup plus élevé.

00:05:29.900 --> 00:05:34.520
Nous allons jusqu'à plus de 500.

00:05:34.520 --> 00:05:36.320
Il pourrait même aller un peu plus haut.

00:05:36.320 --> 00:05:37.580
Je vais laisser ça s'endira pendant un moment,

00:05:37.580 --> 00:05:40.790
mais aussi remarquer ces pages
poids de loquet ont disparu.

00:05:40.790 --> 00:05:42.605
Plus de poids de loquet de page.

00:05:42.605 --> 00:05:45.740
Si nous revenons à Azure Data
Studio et moi gérons cette commande

00:05:45.740 --> 00:05:48.990
à nouveau à regarder les séances.

00:05:48.990 --> 00:05:52.310
Notez qu'il n'y a pas de sessions
qui attendent sur le verrou de la page.

00:05:52.310 --> 00:05:55.865
Nous avons complètement éliminé
les poids de loquet de page.

00:05:55.865 --> 00:05:57.590
Si je reviens à Perf man,

00:05:57.590 --> 00:06:00.005
Oui, ma charge de travail est déjà terminée.

00:06:00.005 --> 00:06:02.990
Donc, vous pouvez voir que j'ai
amélioration du débit.

00:06:02.990 --> 00:06:05.675
J'ai éliminé ceux
poids de loquet de page.

00:06:05.675 --> 00:06:07.580
Si je descends à ma charge de travail,

00:06:07.580 --> 00:06:10.130
il est maintenant terminé en 35 secondes

00:06:10.130 --> 00:06:13.760
par rapport aux 52 secondes
sans la fonction sur.

00:06:13.760 --> 00:06:19.220
Donc, cette fonctionnalité est conçue
pour vous permettre d'aider à l'échelle

00:06:19.220 --> 00:06:23.240
jusqu'à votre TempDB lourd
charges de travail litigieuses

00:06:23.240 --> 00:06:25.400
sans faire de
changements de code à tous.

00:06:25.400 --> 00:06:28.085
Il vous suffit d'activer la configuration,

00:06:28.085 --> 00:06:31.640
redémarrer le serveur et puis vous
peuvent immédiatement s'être améliorés

00:06:31.640 --> 00:06:33.770
débit et moins
poids de loquet de page

00:06:33.770 --> 00:06:36.320
sur vos charges de travail contentieuses TempDB.

00:06:36.320 --> 00:06:38.300
J'espère donc que cela vous aidera à apprendre

00:06:38.300 --> 00:06:40.790
un peu plus sur le
fonctionnalité, comment vous l'utiliseriez,

00:06:40.790 --> 00:06:42.860
comment vous sauriez si
vous devez l'allumer

00:06:42.860 --> 00:06:45.020
ou pas et vous obtient un peu plus

00:06:45.020 --> 00:06:46.970
excités par les améliorations
qui arrivent

00:06:46.970 --> 00:06:49.610
SQL Server 2019 Merci beaucoup.

00:06:49.610 --> 00:07:04.210
[MUSIQUE]