WEBVTT

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

00:00:10.500 --> 00:00:12.270
>> Hallo mein Name ist Pam,

00:00:12.270 --> 00:00:15.495
und ich bin Programmmanager mit
SQL Server Engineering-Team.

00:00:15.495 --> 00:00:17.790
Heute möchte ich
eine kurze Demo für Sie

00:00:17.790 --> 00:00:19.800
auf einem der neuen
Funktionen von SQL Server.

00:00:19.800 --> 00:00:23.310
Speicher optimiert 2019
TempDB-Metadaten.

00:00:23.310 --> 00:00:26.070
Ich habe bereits eine
Übersichtsvideo zu

00:00:26.070 --> 00:00:27.480
diese Funktion, bei der
Ich rede ein wenig

00:00:27.480 --> 00:00:29.040
über einige der Herausforderungen mit

00:00:29.040 --> 00:00:32.295
TempDB-Leistung, die Sie
in der Vergangenheit konfrontiert und

00:00:32.295 --> 00:00:35.850
über die Arbeit, die wir 2019 leisten
, um die TempDB-Leistung zu verbessern.

00:00:35.850 --> 00:00:38.945
Ich ermutige Sie daher,
Video, wenn Sie es noch nicht gesehen haben.

00:00:38.945 --> 00:00:41.600
Was wir tun werden
in dieser Demo heute ist

00:00:41.600 --> 00:00:45.185
Fokussierung auf den Speicher optimiert
TempDB-Metadatenfunktion,

00:00:45.185 --> 00:00:46.805
wie Sie es aktivieren,

00:00:46.805 --> 00:00:47.975
wie Sie es deaktivieren würden.

00:00:47.975 --> 00:00:49.640
Aber auch, wie können Sie

00:00:49.640 --> 00:00:51.790
sagen, ob Sie
aktivieren Sie diese Funktion.

00:00:51.790 --> 00:00:55.600
Haben Sie das Problem, dass
diese Funktion soll gelöst werden?

00:00:55.600 --> 00:00:58.770
Also springen wir in die
Demo und werfen Sie einen Blick.

00:01:00.220 --> 00:01:02.960
So habe ich hier ein Notizbuch geöffnet

00:01:02.960 --> 00:01:05.420
Azure Data Studio
mit ein paar Befehlen.

00:01:05.420 --> 00:01:09.050
Wir beginnen damit, dass wir laufen
die Arbeitslast auf SQL Server.

00:01:09.050 --> 00:01:14.315
2019 ohne Aktivierung des Speichers
Optimierte TempDB-Metadatenfunktion

00:01:14.315 --> 00:01:15.560
und wir werden versuchen, einen Blick auf

00:01:15.560 --> 00:01:17.930
diese Behauptung, dass
kann in TempDB auftreten.

00:01:17.930 --> 00:01:21.050
Das erste, was ich bin
gehen zu tun ist beginnen

00:01:21.050 --> 00:01:24.170
ein Leistungsmonitor
Sammeln und Sammeln

00:01:24.170 --> 00:01:26.120
ein paar verschiedene
Zähler, die

00:01:26.120 --> 00:01:28.430
uns eine Idee der
Leistung der Arbeitslast.

00:01:28.430 --> 00:01:31.955
Dann werde ich verwenden
das O-Spannungswerkzeug

00:01:31.955 --> 00:01:34.415
, um eine Multithread-Workload auszuführen.

00:01:34.415 --> 00:01:37.700
Ich habe also acht Prozessoren
auf dieser speziellen Maschine,

00:01:37.700 --> 00:01:39.950
aber ich werfe 100
parallelen Threads.

00:01:39.950 --> 00:01:42.350
Ich habe also eine sehr beschäftigte Arbeitsbelastung

00:01:42.350 --> 00:01:44.810
hier und es ist ein sehr
hohe TempDB-Workload.

00:01:44.810 --> 00:01:47.210
Es ist eine grundlegende gespeicherte Prozedur
die eine Temporäre Tabelle erstellt,

00:01:47.210 --> 00:01:48.360
einige Daten hineinstecken,

00:01:48.360 --> 00:01:49.805
und wählt daraus aus.

00:01:49.805 --> 00:01:52.200
So können Sie hier in Perf Mann zu sehen.

00:01:52.200 --> 00:01:54.090
Ich habe einige Gewichte in Arbeit,

00:01:54.090 --> 00:01:55.740
Seitenverriegelungsgewichtungen in Bearbeitung.

00:01:55.740 --> 00:01:58.895
Ich habe auch die durchschnittliche Wartezeit

00:01:58.895 --> 00:02:00.380
auch hier in Perf Man aufgeführt.

00:02:00.380 --> 00:02:02.390
So können Sie sehen, ich habe
ausgelagerte Verriegelungsgewichte

00:02:02.390 --> 00:02:04.775
geschieht, während ich bin
ausführen dieser Workload.

00:02:04.775 --> 00:02:07.640
Das ist nicht ungewöhnlich mit einem
stark gleichzeitige Arbeitsbelastung.

00:02:07.640 --> 00:02:11.580
Die Frage ist hier, was
diese Seitenverriegelungsgewichte von?

00:02:11.580 --> 00:02:12.770
Wir wissen es nicht unbedingt.

00:02:12.770 --> 00:02:14.405
Sie könnten von
Ihre Benutzerdatenbank.

00:02:14.405 --> 00:02:16.430
Sie könnten von TempDB stammen.

00:02:16.430 --> 00:02:18.740
Wir wissen wirklich nicht nur
durch den Blick auf die Leistung

00:02:18.740 --> 00:02:21.620
Überwachen, wo diese Seite
Gewichte kommen von.

00:02:21.620 --> 00:02:23.210
Also wollen wir zurück zu

00:02:23.210 --> 00:02:25.850
Azure Data Studio und werfen Sie einen Blick auf

00:02:25.850 --> 00:02:27.110
ein Skript, das uns helfen kann

00:02:27.110 --> 00:02:30.880
Bestimmen Sie, wo diese Seite
Riegelgewichte kommen von.

00:02:30.880 --> 00:02:32.230
Sieht so aus, als ob meine Arbeitslast beendet ist.

00:02:32.230 --> 00:02:34.190
Also werde ich es nur treten
wieder ab, so dass wir

00:02:34.190 --> 00:02:36.925
können Sie sich Azure Data Studio ansehen.

00:02:36.925 --> 00:02:40.090
Kehren wir also hierher zurück.

00:02:42.130 --> 00:02:47.135
Ich werde diese Abfrage ausführen
die ich im Fokus habe.

00:02:47.135 --> 00:02:51.740
Diese Abfrage ist
alle Anfragen von

00:02:51.740 --> 00:02:56.510
DM-genaue Anfrage, die
eine Gewichtsart wie Seite,

00:02:56.510 --> 00:03:00.335
bedeutet, dass eine Art von
Seite VerriegelungGewicht.

00:03:00.335 --> 00:03:04.010
Was ich in den Ergebnissen sehen kann
hier ist, dass ich tatsächlich habe

00:03:04.010 --> 00:03:07.295
mehrere Sitzungen, die
warten auf Seite Verriegelung.

00:03:07.295 --> 00:03:09.305
Wenn ich mir die Gewichtsressource ansehe,

00:03:09.305 --> 00:03:11.990
Ich kann nur vom Gewicht unterscheiden
Ressource, in der sie sich befinden

00:03:11.990 --> 00:03:15.905
TempDB, da das Gewicht
Ressource hier ist 2:1:1:20.

00:03:15.905 --> 00:03:17.420
Zwei ist Datenbank-ID,

00:03:17.420 --> 00:03:18.665
zwei, die TempDB ist.

00:03:18.665 --> 00:03:23.570
Eine ist Datei Nummer 1 und
dann ist 120 die Seitenzahl.

00:03:23.570 --> 00:03:25.325
So kann ich sagen, es ist in TempDB.

00:03:25.325 --> 00:03:30.395
Aber wenn ich diese neue Funktion verwende
DMDB-Seiteninfo,

00:03:30.395 --> 00:03:34.039
was mir das ermöglicht zu tun
nimmt diese Seitenressource

00:03:34.039 --> 00:03:38.330
und knacken Sie es auf und sehen
was genau auf dieser Seite ist.

00:03:38.330 --> 00:03:41.355
Von dieser DMDB-Seiteninfofunktion

00:03:41.355 --> 00:03:44.150
Ich erhalte dieses Objekt
Name und Sie können sehen,

00:03:44.150 --> 00:03:46.810
hier, dass der Objektname
ist sys-Schema-Objekte,

00:03:46.810 --> 00:03:48.095
eine Systemtabelle.

00:03:48.095 --> 00:03:50.944
Das ist also, dass TempDB
Metadaten-Konflikt

00:03:50.944 --> 00:03:52.685
über die wir sprachen.

00:03:52.685 --> 00:03:54.754
Das ist das Problem

00:03:54.754 --> 00:03:58.220
dass Speicheroptimierte TempDB
Metadaten wurden eingeführt, um zu lösen.

00:03:58.220 --> 00:03:59.960
Kehren wir also zurück zu
unser Befehlsfenster.

00:03:59.960 --> 00:04:01.115
Wir können sehen, dass es fertig ist.

00:04:01.115 --> 00:04:02.450
Beide Male wurde es ausgeführt,

00:04:02.450 --> 00:04:06.005
es dauerte ca. 52 Sekunden
, um die Arbeitslast auszuführen.

00:04:06.005 --> 00:04:09.675
Wir können natürlich die Seite sehen
Latchgewichte passieren.

00:04:09.675 --> 00:04:12.300
Wir können die Charge sehen
Anträge pro Sekunde,

00:04:12.300 --> 00:04:14.100
die Richtfest sind,

00:04:14.100 --> 00:04:18.225
sehen wir hier, ca. 350 maximal.

00:04:18.225 --> 00:04:20.210
Das ist also ohne die
Funktion eingeschaltet.

00:04:20.210 --> 00:04:22.265
Lassen Sie uns also vorangehen und
schalten Sie die Funktion ein.

00:04:22.265 --> 00:04:23.795
Um dies zu tun,

00:04:23.795 --> 00:04:25.925
müssen wir die Funktion in

00:04:25.925 --> 00:04:29.090
SQL Server und wir brauchen auch
, um den Server neu zu starten.

00:04:29.090 --> 00:04:34.250
Dadurch wird die Serverkonfiguration geändert.
Befehl erfordert hier einen Neustart.

00:04:34.250 --> 00:04:38.875
Also werden wir diese Erinnerung
Optimierte TempDB-Metadaten auf.

00:04:38.875 --> 00:04:43.540
Dann gehe ich vor und
starten Sie den Server neu.

00:04:44.360 --> 00:04:48.025
Dann, wenn ich das tue,

00:04:48.025 --> 00:04:50.810
ich werde wiederkommen können

00:04:50.810 --> 00:04:54.155
zu Azure Data Studio und
einen anderen Befehl ausführen,

00:04:54.155 --> 00:04:57.470
Servereigenschaft auswählen
Befehl, um zu sehen, ob

00:04:57.470 --> 00:05:01.160
tempDB-Speicheroptimiert
Metadaten-Funktion ist eingeschaltet.

00:05:01.160 --> 00:05:03.265
Lassen Sie uns also diesen Befehl ausführen.

00:05:03.265 --> 00:05:07.245
Sie können sehen, wie es ausgeführt wird
und die Funktion ist jetzt eingeschaltet.

00:05:07.245 --> 00:05:10.565
Es ist eine. Also lasst uns weitermachen
und führen Sie unsere Workload erneut aus.

00:05:10.565 --> 00:05:13.470
Beginnen wir perf man.

00:05:16.490 --> 00:05:19.350
Lassen Sie uns unsere Arbeitsbelastung wieder starten.

00:05:19.350 --> 00:05:20.775
Gleiche exakte Workloads.

00:05:20.775 --> 00:05:24.130
Gleiche gespeicherte Prozedur, 100 Threads.

00:05:24.130 --> 00:05:27.080
Sie können etwas bemerken
anders in Perf Mann sofort.

00:05:27.080 --> 00:05:29.900
Zuallererst Batch-Anforderungen
pro Sekunde ist viel höher.

00:05:29.900 --> 00:05:34.520
Wir gehen auf über 500.

00:05:34.520 --> 00:05:36.320
Es könnte sogar ein wenig höher gehen.

00:05:36.320 --> 00:05:37.580
Ich lasse das eine Weile laufen,

00:05:37.580 --> 00:05:40.790
aber auch beachten Sie diese Seite
Riegelgewichte sind weg.

00:05:40.790 --> 00:05:42.605
Keine Seitenverriegelungsgewichtungen mehr.

00:05:42.605 --> 00:05:45.740
Wenn wir zu Azure Data zurückkehren
Studio und ich führen diesen Befehl aus

00:05:45.740 --> 00:05:48.990
, um sich die Sitzungen anzusehen.

00:05:48.990 --> 00:05:52.310
Beachten Sie, dass keine Sitzungen vorhanden sind
die auf Seitenverriegelung warten.

00:05:52.310 --> 00:05:55.865
Wir haben komplett eliminiert
die Seitenverriegelungsgewichte.

00:05:55.865 --> 00:05:57.590
Wenn ich auf den Perf-Mann zurückkomme,

00:05:57.590 --> 00:06:00.005
yep, meine Workload ist bereits beendet.

00:06:00.005 --> 00:06:02.990
So können Sie sehen, ich habe
verbesserten Durchsatz.

00:06:02.990 --> 00:06:05.675
Ich habe diese
Seitenverriegelungsgewichtungen.

00:06:05.675 --> 00:06:07.580
Wenn ich auf meine Arbeitsbelastung herunterkomme,

00:06:07.580 --> 00:06:10.130
es ist jetzt in 35 Sekunden abgeschlossen

00:06:10.130 --> 00:06:13.760
im Vergleich zu den 52 Sekunden
ohne die Funktion.

00:06:13.760 --> 00:06:19.220
Diese Funktion ist also
, damit Sie beim Skalieren helfen können

00:06:19.220 --> 00:06:23.240
bis zu Ihrem schweren TempDB
strittige Workloads

00:06:23.240 --> 00:06:25.400
ohne irgendwelche
Codeänderungen überhaupt.

00:06:25.400 --> 00:06:28.085
Sie schalten einfach die Konfiguration ein,

00:06:28.085 --> 00:06:31.640
Starten Sie den Server neu, und
kann sich sofort verbessert haben

00:06:31.640 --> 00:06:33.770
Durchsatz und weniger
Seitenverriegelungsgewichte

00:06:33.770 --> 00:06:36.320
auf Ihre TempDB-Strittigen Workloads.

00:06:36.320 --> 00:06:38.300
Ich hoffe also, dass das Ihnen hilft,

00:06:38.300 --> 00:06:40.790
ein wenig mehr über die
Funktion, wie Sie es verwenden würden,

00:06:40.790 --> 00:06:42.860
wie Sie wissen würden, ob
Sie müssen es einschalten

00:06:42.860 --> 00:06:45.020
oder nicht und bringt Sie ein wenig mehr

00:06:45.020 --> 00:06:46.970
begeistert von den Verbesserungen
die kommen

00:06:46.970 --> 00:06:49.610
SQL Server 2019 Vielen Dank.

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