WEBVTT

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

00:00:10.560 --> 00:00:12.975
>> Hey, willkommen zu einem neuen
Episode von Data Exposed.

00:00:12.975 --> 00:00:14.460
Mein Name ist Pedro Lopes.

00:00:14.460 --> 00:00:16.920
Ich bin Programmmanager in der
SQL Server Engineering-Team.

00:00:16.920 --> 00:00:18.510
Heute werde ich reden

00:00:18.510 --> 00:00:20.670
über Intelligent
Datenbank, insbesondere,

00:00:20.670 --> 00:00:23.809
Intelligente Abfrageverarbeitung
in SQL Server 2019,

00:00:23.809 --> 00:00:25.925
und auch Azure SQL-Datenbank.

00:00:25.925 --> 00:00:29.390
Lassen Sie uns also darauf einsteigen. Sql
Server 2019 führt ein

00:00:29.390 --> 00:00:31.864
bahnbrechende Abfrage
Leistungsverbesserungen

00:00:31.864 --> 00:00:34.655
und sie sind die Intelligenten
Abfrageverarbeitungsfamilie.

00:00:34.655 --> 00:00:37.820
Diese bilden die neuesten
Microsofts Mission,

00:00:37.820 --> 00:00:41.690
dass kritische parallele Workloads
verbessern, wenn Sie in der Skala laufen,

00:00:41.690 --> 00:00:45.470
während sie an die
sich ständig verändernde Welt der Daten,

00:00:45.470 --> 00:00:47.855
wenn Daten ein- und
aus Datenbanken.

00:00:47.855 --> 00:00:49.670
In diesem Video werde ich Ihnen

00:00:49.670 --> 00:00:51.980
einen schnellen Überblick über die
Intelligente Datenbankwelt

00:00:51.980 --> 00:00:53.030
die wirklich einen Sprung macht

00:00:53.030 --> 00:00:56.150
mit den kommenden
SQL Server 2019,

00:00:56.150 --> 00:00:58.700
und stellen Sie eine Nummer vor
von Funktionen, die wir tauchen werden

00:00:58.700 --> 00:01:02.130
tiefer in andere
Videos in dieser Serie.

00:01:03.170 --> 00:01:07.510
Intelligente Abfrageverarbeitung
in SQL Server ist verfügbar von

00:01:07.510 --> 00:01:11.245
Standardeinstellung für die neueste Datenbank
Kompatibilitätseinstellung.

00:01:11.245 --> 00:01:13.210
Das bedeutet, dass nach dem Upgrade

00:01:13.210 --> 00:01:15.130
dies kann nur durch

00:01:15.130 --> 00:01:18.000
umdrehen des Schalters, um die
neueste Kompatibilitätseinstellung.

00:01:18.000 --> 00:01:22.030
Intelligente Abfrageverarbeitung
auch breite Wirkung

00:01:22.030 --> 00:01:23.440
das die Leistung der

00:01:23.440 --> 00:01:26.650
bestehende Workloads mit
minimaler Implementierungsaufwand.

00:01:26.650 --> 00:01:28.390
Das bedeutet wirklich, dass die meiste Zeit,

00:01:28.390 --> 00:01:30.965
es besteht kein Bedarf an
Ihren Code umgestalten.

00:01:30.965 --> 00:01:33.310
Intelligente Abfrageverarbeitung verbessert

00:01:33.310 --> 00:01:36.190
kritische parallele Workloads
wenn sie in großem Maßstab ausgeführt werden,

00:01:36.190 --> 00:01:39.355
und wie Daten fließen und
aus Ihrer Datenbank heraus,

00:01:39.355 --> 00:01:41.380
werden wir uns darauf einstellen und

00:01:41.380 --> 00:01:44.660
ein Niveau der
vorhersagbare Leistung.

00:01:44.660 --> 00:01:47.450
Zum Beispiel durch die Einführung

00:01:47.450 --> 00:01:49.880
ein Feedback-Mechanismus
in die Speichernutzung,

00:01:49.880 --> 00:01:53.630
können wir sicherstellen, dass Ihre Arbeitsbelastung
auf vorhersehbare Weise ausgeführt werden.

00:01:53.630 --> 00:01:58.190
Wenn eine bestimmte Abfrageausführung
vielleicht zu viel Speicher in Anspruch nehmen,

00:01:58.190 --> 00:01:59.750
wir können es korrigieren und

00:01:59.750 --> 00:02:02.375
Erhöhen der Parallelität
Faktor Ihrer Datenbank.

00:02:02.375 --> 00:02:06.020
Wenn eine bestimmte Eigenkapitalausführung
nicht genügend Speicher und

00:02:06.020 --> 00:02:09.560
wird am Ende zusätzliche IO verwendet
im ganzen ist als Verschüttung bekannt,

00:02:09.560 --> 00:02:11.315
dann können wir auch feststellen, dass

00:02:11.315 --> 00:02:13.565
und korrigieren Sie die Situation
so dass die Operation

00:02:13.565 --> 00:02:15.260
ausgeführt im Speicher und

00:02:15.260 --> 00:02:18.200
wie erwartet in
nachfolgende Ausführungen.

00:02:18.200 --> 00:02:20.540
Diese Funktion ist jetzt für

00:02:20.540 --> 00:02:22.835
alle Ausführungsmodi in
das Datenbankcenter.

00:02:22.835 --> 00:02:27.170
Batch-Modus für mehr Data Warehouse
und analytische Arbeitsbelastungen,

00:02:27.170 --> 00:02:31.410
und Zeilenmodus für Ihre
kritische OLTP-Workloads.

00:02:31.700 --> 00:02:34.640
Wir gehen auch in neue Bereiche

00:02:34.640 --> 00:02:37.220
die wir anrufen
ungefähre Abfrageverarbeitung.

00:02:37.220 --> 00:02:40.640
Denken Sie beispielsweise an ein Szenario
wo ein Eisenbahnunternehmen

00:02:40.640 --> 00:02:42.350
Spur der Anzahl der Tickets, die

00:02:42.350 --> 00:02:44.935
gekauft und in der
gesamten Eisenbahnsystem.

00:02:44.935 --> 00:02:47.030
Sie verfolgen dies
um die Umsetzung

00:02:47.030 --> 00:02:49.730
einige Durchflusssteuerungsmessungen
wenn es gebraucht wird,

00:02:49.730 --> 00:02:52.610
vielleicht durch Anpassung der
Fahrpläne der Züge,

00:02:52.610 --> 00:02:53.630
oder die Anzahl der Züge in

00:02:53.630 --> 00:02:55.810
das System, um die
Bedürfnisse des Augenblicks.

00:02:55.810 --> 00:02:58.920
Diese Informationen sind auch
in einem Dashboard aktualisiert

00:02:58.920 --> 00:03:02.530
dass Leute in Downtown
Central kann einen Blick auf.

00:03:02.530 --> 00:03:04.220
Nun, in diesem Szenario Teil der

00:03:04.220 --> 00:03:06.830
die Arbeitsbelastung wird sicherlich
, um eine Abfrage auszuführen, die

00:03:06.830 --> 00:03:09.020
ständig auf der Suche nach

00:03:09.020 --> 00:03:12.005
die Zeilenanzahl aller
Tickets, die verkauft und verwendet werden,

00:03:12.005 --> 00:03:14.600
und dies ist wahrscheinlich
aus einem sehr

00:03:14.600 --> 00:03:17.605
großen Stall vielleicht mit
Milliarden und Milliarden von Reihen.

00:03:17.605 --> 00:03:20.540
Nun wird diese wiederkehrende Abfrage
würde in der Regel

00:03:20.540 --> 00:03:23.735
erhebliche Ressourcen für
Ihrem Server, nämlich Demspeicher.

00:03:23.735 --> 00:03:25.639
Wenn es wiederholt ausgeführt wird,

00:03:25.639 --> 00:03:26.690
kann wirklich beeinflussen

00:03:26.690 --> 00:03:28.900
die Leistungsmerkmale
Ihrer Datenbank.

00:03:28.900 --> 00:03:30.670
In diesem Szenario

00:03:30.670 --> 00:03:32.750
die Eisenbahngesellschaft
braucht nicht unbedingt

00:03:32.750 --> 00:03:35.830
eine tatsächliche Anzahl aller
Tickets, die verkauft und verwendet werden.

00:03:35.830 --> 00:03:37.790
Aber eine sehr hohe
Annäherung reicht aus

00:03:37.790 --> 00:03:40.280
um alle
erforderlichen Entscheidungsfindung.

00:03:40.280 --> 00:03:42.935
Hier liegt die ungefähre
Zählen sie deutlich,

00:03:42.935 --> 00:03:45.500
durch Zulassen einer Abfrage
um wiederholt

00:03:45.500 --> 00:03:48.185
die ungefähre Anzahl
der verkauften und genutzten Tickets

00:03:48.185 --> 00:03:51.080
ohne die schwerwiegenden Auswirkungen auf
Ihre Datenbankleistung, die

00:03:51.080 --> 00:03:55.420
Ihre normale Zählabfrage
würde heute dauern.

00:03:55.640 --> 00:03:58.695
Durch Aktivieren des Batch-Modus im Row Store

00:03:58.695 --> 00:03:59.950
wir effektiv entfesseln

00:03:59.950 --> 00:04:02.150
den Verarbeitungsmodus, der
besonders optimiert

00:04:02.150 --> 00:04:05.975
für analytische Workloads über
jede Tabelle in der Datenbank.

00:04:05.975 --> 00:04:08.180
Dies bedeutet, dass selbst
für Szenarien, in denen

00:04:08.180 --> 00:04:10.385
ein Spaltenspeicherindex
wäre keine Option,

00:04:10.385 --> 00:04:14.395
Das Datenbankmodul kann weiterhin
diese auf optimierte Weise auszuführen.

00:04:14.395 --> 00:04:17.375
Dies wiederum eröffnet den Umfang der

00:04:17.375 --> 00:04:20.630
Funktionen wie Adaptive Join
von Ihrer Workload verwendet werden.

00:04:20.630 --> 00:04:24.170
Adaptive Verknüpfung, die nur
im Batch-Modus verfügbar

00:04:24.170 --> 00:04:28.940
jetzt über alle
Tabellen und die meisten Ihrer Workloads.

00:04:29.590 --> 00:04:33.170
Wir haben auch einige der
die meisten wiederkehrenden Anti-Muster

00:04:33.170 --> 00:04:36.260
die zu einem Problem für
verwaltete SQL Server-Workloads.

00:04:36.260 --> 00:04:38.150
Die Verwendung von Tabelle
Variablen und die Verwendung

00:04:38.150 --> 00:04:40.105
scalar UDFs, z. B.

00:04:40.105 --> 00:04:42.440
und jetzt können wir neue Ebenen der

00:04:42.440 --> 00:04:46.375
Abfrageoptimierung, die
bis vor kurzem nicht möglich.

00:04:46.375 --> 00:04:49.310
All dies, wir werden
tiefer diskutieren und mit

00:04:49.310 --> 00:04:51.080
Demos in kommenden Videos in

00:04:51.080 --> 00:04:53.270
die Serie über die
intelligente Datenbank,

00:04:53.270 --> 00:04:56.020
speziell intelligent
Abfrageverarbeitung.

00:04:56.020 --> 00:04:59.505
Aber wenn Sie wissen wollen,
mehr darüber heute,

00:04:59.505 --> 00:05:04.200
dann gehen Sie bitte zu diesem aka.ms/IQP

00:05:04.200 --> 00:05:06.899
URL, wo Sie alle sehen
die Dokumentation

00:05:06.899 --> 00:05:09.535
auf Intelligent Query
Verarbeitung in SQL-Datenbanken.

00:05:09.535 --> 00:05:13.100
Wenn Sie einige experimentieren möchten
von ihnen selbst jetzt,

00:05:13.100 --> 00:05:16.040
wir haben auch Demos, die
Sie können sich ansehen, ob Sie

00:05:16.040 --> 00:05:18.980
Gehen Sie zu unserem GitHub-Repository
und die kurze URL würde

00:05:18.980 --> 00:05:22.430
aka.ms/IQPDemos, wo Sie

00:05:22.430 --> 00:05:25.900
in der Lage sein, all diese
und selbst experimentieren.

00:05:25.900 --> 00:05:27.795
Also wieder, vorsicht.

00:05:27.795 --> 00:05:28.980
Ich werde bald mit Ihnen sprechen.

00:05:28.980 --> 00:05:43.780
[MUSIK].