WEBVTT

00:00:00.000 --> 00:00:01.830
>> SQL Server 2019 bietet

00:00:01.830 --> 00:00:04.995
eine neue Funktion für Linux namens
Persistente Protokollpuffer.

00:00:04.995 --> 00:00:06.960
Es war für Windows verfügbar,

00:00:06.960 --> 00:00:08.385
heutzutage auch unter Linux,

00:00:08.385 --> 00:00:10.740
und es hilft Ihnen,
Engpässe, die

00:00:10.740 --> 00:00:14.130
Auftreten beim Warten auf ein Protokoll
Puffer zwei Bündig auf Disc.

00:00:14.130 --> 00:00:18.300
Brian ist hier, um uns alle zu sagen
darüber heute auf Data Exposed.

00:00:18.300 --> 00:00:29.040
[MUSIK]

00:00:29.040 --> 00:00:32.115
>> Hallo, und willkommen zu einem anderen
Episode von Data Exposed.

00:00:32.115 --> 00:00:35.220
Ich bin dein Gastgeber Jeroen, und
heute habe ich Brian bei mir

00:00:35.220 --> 00:00:38.460
um über Persistent zu sprechen
Protokollpuffer in SQL 2019.

00:00:38.460 --> 00:00:40.230
Also hallo, Brian, willkommen in der Show.

00:00:40.230 --> 00:00:42.195
>> Hallo, Jeroen. Danke.

00:00:42.195 --> 00:00:46.045
>> Was werden wir also reden?
über Persistent Long Buffers?

00:00:46.045 --> 00:00:47.160
>> Ja. So-

00:00:47.160 --> 00:00:47.685
>> Was ist das?

00:00:47.685 --> 00:00:50.400
>> So Persistent Log
Puffer ist eines von dem, was

00:00:50.400 --> 00:00:53.325
wir nennen das In-Memory
Datenbank-Feature-Familie,

00:00:53.325 --> 00:00:55.965
einschließlich In-Memory OLTP,

00:00:55.965 --> 00:00:59.265
Persistenter Protokollpuffer, der
Ich werde heute demonstrieren,

00:00:59.265 --> 00:01:01.845
manchmal auch Tail of Log Caching genannt,

00:01:01.845 --> 00:01:05.040
eine Daten- und Protokolldatei
Aufklärung in Linux,

00:01:05.040 --> 00:01:07.470
Hybrid-Pufferpool in
Linux und Windows,

00:01:07.470 --> 00:01:09.870
und Memory-Optimize TempDB-Metadaten.

00:01:09.870 --> 00:01:11.370
>> Okay. Cool.

00:01:11.370 --> 00:01:17.195
>> Also erwähne ich nur schnell
über persistente Speichergeräte.

00:01:17.195 --> 00:01:19.550
Viele Leute haben nicht
gesehen, sondern im Wesentlichen

00:01:19.550 --> 00:01:21.730
Dies sind normale DIMMs, die Sie

00:01:21.730 --> 00:01:26.275
in Ihren Server einspeisen, der
in unterschiedlichen Kapazitäten kommen.

00:01:26.275 --> 00:01:30.545
MVDIMM-N, eine Art von
persistente Speichertechnologie,

00:01:30.545 --> 00:01:34.325
kommt eine 8, 16 oder 32
Gig DIMM Kapazität,

00:01:34.325 --> 00:01:36.980
und dann die neuesten Intel erhalten

00:01:36.980 --> 00:01:41.150
DC Persistent Speicher kommt in
wesentlich höhere Kapazitäten eines 128,

00:01:41.150 --> 00:01:44.810
256 Gigabyte oder 512 Gigabyte DIMMs.

00:01:44.810 --> 00:01:46.820
>> Das sind alles
persistenten Speicher. Beeindruckend.

00:01:46.820 --> 00:01:48.060
>> Ja. So können Sie,

00:01:48.060 --> 00:01:49.290
auf einem nate Socket-Server,

00:01:49.290 --> 00:01:52.370
Sie können bis zu 24
Terabyte persistenten Speichers.

00:01:52.370 --> 00:01:53.750
>> Ich kann alle

00:01:53.750 --> 00:01:55.970
dass mit diesem hartnäckigen
Protokollpuffer, oder?

00:01:55.970 --> 00:01:56.570
>> Richtig.

00:01:56.570 --> 00:01:57.680
>> Wow.

00:01:57.680 --> 00:02:00.110
>> Persistentes Protokoll
Puffer ist so konzipiert, dass

00:02:00.110 --> 00:02:02.075
Lösen eines bestimmten Anwendungsfalles

00:02:02.075 --> 00:02:07.400
wo Sie Verlangsamungen
oder wartet in Ihrer Workload,

00:02:07.400 --> 00:02:12.385
Warten auf den Protokollpuffer, der
ist im Arbeitsspeicher, um auf die Festplatte zu spülen.

00:02:12.385 --> 00:02:13.005
>> Okay.

00:02:13.005 --> 00:02:16.114
>> So nutzt es die
Persistentes Speichergerät

00:02:16.114 --> 00:02:19.355
auf es weiß, dass, sobald es ist
auf dieses Gerät geschrieben,

00:02:19.355 --> 00:02:21.650
dass es nicht braucht
auf den Flush warten

00:02:21.650 --> 00:02:24.270
weil es bereits auf
ein persistentes Gerät.

00:02:24.270 --> 00:02:26.195
>> Dann wird das Gerät
kümmern sich um den Rest.

00:02:26.195 --> 00:02:28.835
>> Ja, das Gerät wird
dann kümmern sich um den Rest

00:02:28.835 --> 00:02:31.730
während Sie im Wesentlichen weitermachen
mit Ihrer Workload.

00:02:31.730 --> 00:02:32.180
>> ja.

00:02:32.180 --> 00:02:35.585
>> Also, wenn Sie einrichten
diese Geräte in Windows,

00:02:35.585 --> 00:02:41.600
wir haben einige grundlegende Empfehlungen
dass Sie Seiten im Speicher sperren,

00:02:41.600 --> 00:02:44.150
Sie verwenden die beiden Megabyte
Verteilungseinheitsgröße

00:02:44.150 --> 00:02:46.760
für NTFS, die nicht standardmäßig sein werden.

00:02:46.760 --> 00:02:47.180
>> Okay.

00:02:47.180 --> 00:02:49.715
>> Auch Müssen Sie
setzen Sie dieses Flag DAX.

00:02:49.715 --> 00:02:51.920
DAX ist also wirklich das, was uns in die Lage versetzt,

00:02:51.920 --> 00:02:55.280
Behandeln eines persistenten Speichers
Gerät und schreiben Sie darauf

00:02:55.280 --> 00:02:57.260
direkt es überspringen, alle

00:02:57.260 --> 00:02:59.795
den Kernel-Stack, der

00:02:59.795 --> 00:03:03.090
Sie würden in der Regel
beim Umgang mit Dateien.

00:03:03.090 --> 00:03:05.145
Wird nicht in der GUI verfügbar sein,

00:03:05.145 --> 00:03:07.250
So müssen Sie verwenden,
einige PowerShell dafür.

00:03:07.250 --> 00:03:09.560
>> Okay. Alles klar. Sie werden
zeigen Sie uns, wie das funktioniert, oder?

00:03:09.560 --> 00:03:13.325
>> Ja. Ich werde zeigen, wie
diese konfiguriert werden.

00:03:13.325 --> 00:03:16.430
Auch ein Teil Ihres OS-Levels
Disc-Zähler, die Sie

00:03:16.430 --> 00:03:19.510
kann verwendet werden, um wie
diese Transfers und so weiter,

00:03:19.510 --> 00:03:21.830
möglicherweise nicht verfügbar für

00:03:21.830 --> 00:03:24.200
Sie, wenn Sie mit arbeiten
persistente Speichergeräte.

00:03:24.200 --> 00:03:28.865
Das ist nur eines der Dinge
Sie müssen sich dessen bewusst sein.

00:03:28.865 --> 00:03:29.330
>> Sicher.

00:03:29.330 --> 00:03:33.575
>> Das sind neue Geräte und
ist sehr neue spannende Tack.

00:03:33.575 --> 00:03:33.935
>> Okay.

00:03:33.935 --> 00:03:37.565
>> So kann es einige Fangen
auf der Überwachungsseite zu tun.

00:03:37.565 --> 00:03:38.245
>> Sicher.

00:03:38.245 --> 00:03:42.580
>> Für Linux, nichtflüchtig
Gerätesteuerung

00:03:42.580 --> 00:03:45.110
ist das Dienstprogramm, das Sie
verwenden, um dies zu konfigurieren.

00:03:45.110 --> 00:03:47.840
Sie setzen es in den fsdax-Modus,

00:03:47.840 --> 00:03:50.795
verwenden Sie zwei Megabyte riesige Seitenfehler,

00:03:50.795 --> 00:03:53.555
Festlegen der Blockzuordnung
auch auf zwei Megabyte.

00:03:53.555 --> 00:03:56.180
Wir unterstützen XFS oder EXT

00:03:56.180 --> 00:04:00.620
für diese sind zwei unterstützte
Dateisysteme mit DAX.

00:04:00.620 --> 00:04:01.295
>> Okay.

00:04:01.295 --> 00:04:03.050
>> So Persistent Log Buffer,

00:04:03.050 --> 00:04:05.585
dies war verfügbar
tatsächlich in SQL seit

00:04:05.585 --> 00:04:10.140
SQL 2016 bisher nur für Windows.

00:04:10.140 --> 00:04:12.470
Mit SQL 2019 haben wir auch

00:04:12.470 --> 00:04:15.875
Diese Funktion jetzt verfügbar
in Linux und Windows.

00:04:15.875 --> 00:04:18.590
Verwendet nur eine sehr kleine
Kapazitätsmenge,

00:04:18.590 --> 00:04:21.720
Der Protokollpuffer beträgt nur 20
Megabyte pro Benutzerdatenbank.

00:04:21.720 --> 00:04:22.355
>> Okay.

00:04:22.355 --> 00:04:26.330
>> So dauert es wirklich nicht
eine enorme Menge an Kapazität,

00:04:26.330 --> 00:04:28.850
und das Verhalten, das Sie erhalten, ist sehr

00:04:28.850 --> 00:04:31.250
ähnlich wie erzwingend
verzögerte Haltbarkeit.

00:04:31.250 --> 00:04:31.910
>> Okay.

00:04:31.910 --> 00:04:34.040
>> Also wieder, Sie warten nicht auf

00:04:34.040 --> 00:04:36.890
dass Protokoll-Flush auf Festplatte passieren

00:04:36.890 --> 00:04:40.040
förderte jedoch keines der Risiken, die

00:04:40.040 --> 00:04:43.235
nehmen Sie, was Gezwungen verzögert
Haltbarkeit rund um Datenverlust.

00:04:43.235 --> 00:04:45.290
>> So können Sie uns eine
etwas mehr über

00:04:45.290 --> 00:04:47.550
Erzwungene verzögerte Haltbarkeit
für diejenigen, die

00:04:47.550 --> 00:04:48.615
>> Sicher, für diejenigen, die

00:04:48.615 --> 00:04:49.425
>> -nicht bewusst?

00:04:49.425 --> 00:04:52.095
>> Ja. Für diejenigen, die
nicht bekannt sind,

00:04:52.095 --> 00:04:53.840
dies ist im Wesentlichen

00:04:53.840 --> 00:04:57.260
Ein asynchroner Commit
Mechanismus in SQL Server.

00:04:57.260 --> 00:04:57.710
>> Okay.

00:04:57.710 --> 00:05:01.280
>> So gibt es ein Paar
Möglichkeiten, dies zu tun.

00:05:01.280 --> 00:05:03.740
Eine ist erlaubt, in diesem Fall

00:05:03.740 --> 00:05:07.190
Ihre normalen Commits
geschehen, wie Sie erwarten,

00:05:07.190 --> 00:05:08.270
Sie auf den Flush warten,

00:05:08.270 --> 00:05:10.455
warten, bis sie auf der Scheibe gehärtet sind,

00:05:10.455 --> 00:05:15.440
oder in einem erzwungenen Modus, in dem alle
Commits verhalten sich so.

00:05:15.440 --> 00:05:16.000
>> Okay.

00:05:16.000 --> 00:05:19.220
>> Was also erlaubt ist
Sie auf einem pro angeben

00:05:19.220 --> 00:05:22.880
Commit-Basis, wenn Sie dies wünschen
Verhalten und das ist erlaubt,

00:05:22.880 --> 00:05:24.935
nicht zulässig, was der Standardwert ist

00:05:24.935 --> 00:05:27.425
spielt keine Rolle, was Sie in
dort wird es nicht passieren.

00:05:27.425 --> 00:05:27.905
>> Sicher.

00:05:27.905 --> 00:05:30.170
>> Dann alle erzwungen
Commits verhält sich so.

00:05:30.170 --> 00:05:32.285
>> Okay. Also in einem hartnäckigen
niedriges Niveau ist sehr

00:05:32.285 --> 00:05:34.890
ähnlich, aber nicht ganz gleich.

00:05:34.890 --> 00:05:37.215
>> Sehr ähnlich, aber
nicht ganz dasselbe,

00:05:37.215 --> 00:05:39.845
weil wir die
persistentes Speichergerät,

00:05:39.845 --> 00:05:42.965
wir setzen unseren Protokollpuffer dort an,

00:05:42.965 --> 00:05:46.640
und wenn wir dort schreiben, wissen wir,
dass es bestand und wir

00:05:46.640 --> 00:05:50.360
kein Risiko für Datenverlust haben
im Falle eines Serverabsturzes

00:05:50.360 --> 00:05:53.000
Stromausfall, alles
dieser Art,

00:05:53.000 --> 00:05:56.570
können wir uns von den Daten auf
das persistente Speichergerät.

00:05:56.570 --> 00:05:57.920
>> Okay. Cool.

00:05:57.920 --> 00:06:00.230
>> Es ist eigentlich ganz einfach.

00:06:00.230 --> 00:06:01.640
Viele Menschen merken es nicht,

00:06:01.640 --> 00:06:04.355
Sie fügen einfach eine Protokolldatei hinzu

00:06:04.355 --> 00:06:07.580
von 20 Megabyte auf der
persistentes Speichergerät,

00:06:07.580 --> 00:06:10.370
SQL Server wird
erkennen Sie dieses Gerät,

00:06:10.370 --> 00:06:13.265
und behandelt sie als Protokollpuffer.

00:06:13.265 --> 00:06:14.405
>> Es ist sehr einfach

00:06:14.405 --> 00:06:15.665
>> Wirklich so einfach.

00:06:15.665 --> 00:06:16.205
>> Wow.

00:06:16.205 --> 00:06:19.550
>> ja, und wie wir sehen können
hier sind Log-Puffer sitzen auf

00:06:19.550 --> 00:06:23.090
unser Speicherklassenspeicher
was PMM manchmal ist

00:06:23.090 --> 00:06:26.480
wir nennen es Speicherklasse
Erinnerung und an einigen Stellen

00:06:26.480 --> 00:06:30.405
aber das gleiche und unsere
Protokolldatensätze sind da,

00:06:30.405 --> 00:06:31.950
und wie ich bereits erwähnte,

00:06:31.950 --> 00:06:33.200
wir müssen nicht warten
für sie durch

00:06:33.200 --> 00:06:36.365
auf die Haupt-
Transaktionsprotokolldatei.

00:06:36.365 --> 00:06:37.010
>> Cool.

00:06:37.010 --> 00:06:41.875
>> Also schalte ich einfach um
schnell zu meiner Demo hier.

00:06:41.875 --> 00:06:42.990
>> ja.

00:06:42.990 --> 00:06:46.280
>> Zuerst zeige ich nur
die wir konfiguriert haben

00:06:46.280 --> 00:06:49.310
hier unsere persistenten Speichergeräte.

00:06:49.310 --> 00:06:50.945
Wie ich bereits erwähnte,
sind normale DIMMs,

00:06:50.945 --> 00:06:53.180
Sie können die Geräte-IDs dort sehen.

00:06:53.180 --> 00:06:56.405
Wir haben zwei
Geräte eins pro NUMA-Knoten.

00:06:56.405 --> 00:06:56.855
>> Okay.

00:06:56.855 --> 00:07:01.565
>> Überdiebend über die Geräte
bei DIMMs auf diesem NUMA-Knoten.

00:07:01.565 --> 00:07:05.330
Dies ist also die empfohlene
wie wir sagen, es einzurichten.

00:07:05.330 --> 00:07:06.410
>> Okay.

00:07:06.410 --> 00:07:08.950
>> Auch hier können wir sehen, dass

00:07:08.950 --> 00:07:12.920
unser DAX-Wert ist aktiviert
es hat sich hier auf den Fall gebracht,

00:07:12.920 --> 00:07:17.464
und wenn wir unsere älteren
Befehlszeilentyp-Dienstprogramm,

00:07:17.464 --> 00:07:21.830
wir können nur so wenig bekommen
mehr Infos hier und wir können

00:07:21.830 --> 00:07:26.450
sehen, dass wir die Zuweisung
Einheitsgröße auf zwei Megabyte.

00:07:26.450 --> 00:07:28.640
>> Wie Sie gerade beschrieben haben.
Es sollte - ja sein.

00:07:28.640 --> 00:07:31.505
>> ja. Da ich gerade
beschrieben und recht

00:07:31.505 --> 00:07:36.185
einfach fügen wir einfach die
Log-Datei, wie ich bereits erwähnte,

00:07:36.185 --> 00:07:38.205
und wir erstellen und

00:07:38.205 --> 00:07:40.700
unabhängig davon, welche Größe Sie
hier werden wir tatsächlich

00:07:40.700 --> 00:07:42.860
Integriert für 20 Megabyte

00:07:42.860 --> 00:07:46.025
aber einfach weitermachen und
sagen 20 Megabyte sitzt.

00:07:46.025 --> 00:07:47.975
>> ja. Nur um sicher zu gehen.

00:07:47.975 --> 00:07:50.960
>> ja, und es ist wirklich so einfach.

00:07:50.960 --> 00:07:52.550
>> Wow. Alles klar.

00:07:52.550 --> 00:07:54.200
Das ist beeindruckend.

00:07:54.200 --> 00:07:56.900
So kann ich im Grunde entsperren
all diese neuen Technologien mit

00:07:56.900 --> 00:07:58.580
einen persistenten Protokollpuffer von nur

00:07:58.580 --> 00:08:00.650
sehr einfachen Befehl ausführen, nicht wahr?

00:08:00.650 --> 00:08:01.055
>> ja.

00:08:01.055 --> 00:08:02.930
>> Sicher. Sie müssen
das Gerät zuerst konfigurieren,

00:08:02.930 --> 00:08:05.965
und dann, nachdem das getan ist
In SQL fügen Sie einfach ein Protokoll hinzu.

00:08:05.965 --> 00:08:09.350
>> ja, und dieser Typ

00:08:09.350 --> 00:08:12.725
der Technologie ist wirklich
eine neue Stufe der

00:08:12.725 --> 00:08:15.020
Speicher hilft, einige der

00:08:15.020 --> 00:08:17.075
die traditionelle
Engpässe, die wir sehen

00:08:17.075 --> 00:08:19.640
SQL Server auf High-End-Workloads.

00:08:19.640 --> 00:08:22.220
>> Richtig. So große Innovation, aber

00:08:22.220 --> 00:08:24.710
dann auf sehr einfache Weise

00:08:24.710 --> 00:08:26.570
für den Benutzer und für
konfiguration.

00:08:26.570 --> 00:08:29.360
>> Ja. Wir bauen Intelligenz
in SQL Server, um

00:08:29.360 --> 00:08:32.240
Erkennen sie diese Geräte
und verhalten sich entsprechend.

00:08:32.240 --> 00:08:34.295
>> ja. Sehr cool. Gut
vielen Dank für das Teilen.

00:08:34.295 --> 00:08:34.895
>> Vielen Dank.

00:08:34.895 --> 00:08:36.560
>> Ich denke, das war sehr nützlich,

00:08:36.560 --> 00:08:37.910
sehr interessant, zumindest für mich.

00:08:37.910 --> 00:08:40.490
Ich hoffe, dass dies nützlich war und
auch für Sie interessant.

00:08:40.490 --> 00:08:43.065
Bitte abonnieren Sie, wie,
Kommentar zum Video,

00:08:43.065 --> 00:08:44.660
und ich hoffe, Sie das nächste Mal auf zu sehen

00:08:44.660 --> 00:08:47.040
eine weitere Episode von
Verfügbar gemachte Daten. Danke.

00:08:47.040 --> 00:09:01.630
[MUSIK]

