Verwenden von In-Memory-OLTP in Azure SQL-Datenbank zur Verbesserung der Leistung Ihrer Anwendung
Gilt für: Azure SQL-Datenbank
Mit In-Memory-OLTP lässt sich die Leistung der Transaktionsverarbeitung, Datenerfassung und der vorübergehenden Datenszenarios verbessern, ohne das Dienstziel der Datenbank oder des Pools für elastische Datenbanken zu erhöhen.
- Datenbanken und elastische Pools in den Dienstebenen Premium (DTU) und Unternehmenskritisch (vCore) unterstützen In-Memory-OLTP.
- Die Dienstebene Hyperscale unterstützt eine Teilmenge von In-Memory-OLTP-Objekten, umfasst jedoch keine speicheroptimierten Tabellen. Weitere Informationen finden Sie unter Einschränkungen von Hyperscale.
Führen Sie diese Schritte durch, um In-Memory-OLTP in Ihren vorhandenen Datenbanken zu benutzen.
Schritt 1: Sicherstellen, dass eine Datenbank mit dem Tarif „Premium“ oder „Unternehmenskritisch“ verwendet wird
In-Memory-OLTP wird unterstützt, wenn das Ergebnis aus der folgenden Abfrage lautet 1
(nicht 0
):
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');
XTP steht für extreme Transaktionsverarbeitung, wobei es sich um einen informellen Namen des In-Memory-OLTP-Features handelt.
Schritt 2: Identifizieren der zu In-Memory OLTP zu migrierenden Objekte
SQL Server Management Studio (SSMS) umfasst einen Bericht Übersicht der Transaktionsleistungsanalyse, den Sie für eine Datenbank mit einer aktiven Workload erstellen können. Der Bericht identifiziert Tabellen und gespeicherte Prozeduren, die für die Migration zu In-Memory OLTP geeignet sind.
So generieren Sie den Bericht in SSMS:
- Klicken Sie im Objekt-Explorermit der rechten Maustaste auf den Datenbankknoten.
- Wählen Sie Berichte>Standardberichte>Übersicht der Transaktionsleistungsanalyse.
Weitere Informationen zur Bewertung der Vorteile von In-Memory-OLTP finden Sie unter Feststellen, ob eine Tabelle oder gespeicherte Prozedur auf In-Memory-OLTP portiert werden sollte.
Schritt 3: Erstellen einer vergleichbaren Testdatenbank
Nehmen Sie an, der Bericht zeigt, dass die Datenbank über eine Tabelle verfügt, für die eine Umwandlung in eine speicheroptimierte Tabelle von Vorteil wäre. Sie sollten diese Angabe zunächst zur Bestätigung testen.
Sie benötigen eine Testkopie der Produktionsdatenbank. Die Testdatenbank muss sich auf der gleichen Dienstebene befinden wie die Produktionsdatenbank.
Um das Testen zu erleichtern, optimieren Sie die Testdatenbank wie folgt:
Stellen Sie eine Verbindung zur Testdatenbank her, indem Sie SQL Server Management Studio (SSMS) verwenden.
Um zu vermeiden, dass die Option
WITH (SNAPSHOT)
in Abfragen benötigt wird, setzen Sie die OptionMEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT
für die aktuelle Datenbank, wie in der folgenden T-SQL-Anweisung gezeigt:ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
Schritt 4: Migrieren von Tabellen
Sie müssen eine speicheroptimierte Kopie der Tabelle, die Sie testen möchten, erstellen und auffüllen. Zum Erstellen können Sie eine der folgenden Möglichkeiten wählen:
- Der Speicheroptimierungs-Assistent in SSMS.
- Verwenden Sie T-SQL-Befehle.
Speicheroptimierungs-Assistent in SSMS
So verwenden Sie diese Migrationsoption:
Stellen Sie über SSMS eine Verbindung mit der Testdatenbank her.
Klicken Sie im Objekt-Explorer mit der rechten Maustaste auf die Tabelle, und wählen Sie Advisor für die Speicheroptimierung.
Der Assistent für den Ratgeber für die Tabellenspeicheroptimierung wird angezeigt.
Wählen Sie im Assistenten Migrationsüberprüfung (oder die Schaltfläche Weiter), um zu überprüfen, ob die Tabelle nicht unterstützte Features enthält, die in den speicheroptimierten Tabellen nicht unterstützt werden. Weitere Informationen finden Sie unter:
- Die Prüfliste für die Speicheroptimierung im Advisor für die Speicheroptimierung.
- Von In-Memory OLTP nicht unterstützte Transact-SQL-Konstrukte.
- Migrieren zu In-Memory OLTP.
Wenn die Tabelle nicht unterstützte Features enthält, kann der Ratgeber das aktuelle Schema und die Datenmigration für Sie ausführen.
Manuelles T-SQL
So verwenden Sie diese Migrationsoption:
- Stellen Sie über SSMS eine Verbindung mit Ihrer Testdatenbank her.
- Rufen Sie das vollständige T-SQL-Skript für Ihre Tabelle und ihre Constraints und Indizes ab.
- Klicken Sie in SSMS mit der rechten Maustaste auf Ihren Tabellenknoten.
- Wählen Sie Skript für Tabelle als>CREATE in>Neues Abfragezeitfenster.
- Fügen Sie im Skriptfenster der Anweisung
CREATE TABLE
einWITH (MEMORY_OPTIMIZED = ON)
hinzu. Weitere Informationen zu finden Sie unter Syntax für speicheroptimierte Tabellen. - Wenn ein Index als CLUSTERED gekennzeichnet ist, ändern Sie ihn in NONCLUSTERED.
- Benennen Sie die vorhandene Tabelle mittels sp_rename um.
- Erstellen Sie die neue speicheroptimierte Kopie der Tabelle, indem Sie das bearbeitete
CREATE TABLE
-Skript ausführen. - Kopieren Sie die Daten mit
INSERT...SELECT * INTO
in Ihre speicheroptimierte Tabelle:INSERT INTO [<new_memory_optimized_table>] SELECT * FROM [<old_disk_based_table>];
Schritt 5 (optional): Migrieren gespeicherter Prozeduren
In-Memory OLTP unterstützt auch systemeigene kompilierte gespeicherte Prozeduren, die die T-SQL-Leistung verbessern können.
Aspekte bei systemeigen kompilierten gespeicherten Prozeduren
Für die T-SQL-WITH
-Klausel einer systemeigen kompilierten gespeicherten Prozedur sind folgende Optionen erforderlich:
- NATIVE_COMPILATION: bedeutet, dass alle Transact-SQL-Anweisungen in der Prozedur in nativen Code kompiliert werden, um eine effiziente Ausführung zu gewährleisten.
- SCHEMABINDING: Bedeutet, dass die Definitionen der Tabellen, auf die in der gespeicherten Prozedur verwiesen wird, nicht in einer Weise geändert werden können, die sich auf die gespeicherte Prozedur auswirken würde, es sei denn, Sie löschen die gespeicherte Prozedur.
Ein nativ kompiliertes Modul muss einen großen ATOMIC-Block zum Verwalten von Transaktionen verwenden. Es werden keine expliziten BEGIN TRANSACTION
oder ROLLBACK TRANSACTION
-Anweisungen verwendet. Ihr Code kann den atomischen Block mit einer THROW-Anweisung beenden, z. B. wenn er eine Verletzung einer Geschäftsregel feststellt.
Ein Beispiel für eine nativ kompilierte gespeicherte Prozedur
Der T-SQL-Code zum Erstellen einer systemeigen kompilierten gespeicherten Prozedur ähnelt der folgender Vorlage:
CREATE PROCEDURE schemaname.procedurename
@param1 type1, ...
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
BEGIN ATOMIC WITH
(
TRANSACTION ISOLATION LEVEL = SNAPSHOT,
LANGUAGE = N'<desired sys.syslanuages.sysname value>'
)
...
END;
- Für
TRANSACTION_ISOLATION_LEVEL
istSNAPSHOT
der häufigste Wert für die systemeigenen kompilierten gespeicherten Prozeduren. Eine Teilmenge der anderen Werte wird jedoch ebenfalls unterstützt:REPEATABLE READ
SERIALIZABLE
- Der
LANGUAGE
-Wert muss in der Ansichtsys.syslanguages
in der Spaltename
vorhanden sein. Beispiel:N'us_english'
.
So migrieren Sie eine gespeicherte Prozedur zur Verwendung der nativen Kompilierung
Die Migrationsschritte sind wie folgt:
- Rufen Sie das
CREATE PROCEDURE
-Skript für die reguläre (übersetzte) gespeicherte Prozedur auf. - Schreiben Sie ihren Header entsprechend der vorherigen Vorlage neu.
- Stellen Sie fest, ob der T-SQL-Code der gespeicherten Prozedur Features verwendet, die für systemeigen kompilierte gespeicherte Prozeduren nicht unterstützt werden. Implementieren Sie ggf. Problemumgehungen. Weitere Informationen finden Sie unter Migrationsprobleme für nativ kompilierte gespeicherte Prozeduren.
- Benennen Sie die alte gespeicherte Prozedur mithilfe von sp_rename um, oder lassen Sie sie weg.
- Führen Sie Ihr bearbeitetes
CREATE PROCEDURE
T-SQL-Skript aus.
Schritt 6: Ausführen der Workload im Test
Führen Sie eine Workload in der Testdatenbank aus, die der Workload ähnelt, die in der Produktionsdatenbank ausgeführt wird. Dies sollte den Leistungsgewinn zeigen, den Sie mit der Verwendung des In-Memory-OLTP-Features für Tabellen und gespeicherte Prozeduren erzielen.
Wichtige Attribute der Workload sind:
- Anzahl gleichzeitiger Verbindungen.
- Lese-/Schreib-Verhältnis.
Um dern Test-Workload anzupassen und auszuführen, sollten Sie das ostress.exe
Tool aus der Gruppe der RML-Dienstprogramme verwenden. Weitere Informationen finden Sie unter In-Memory-Beispiel in Azure SQL-Datenbank.
Um die Netzwerklatenz zu minimieren, führen Sie ostress.exe
in derselben Azure-Region wie die Datenbank aus.
Schritt 7: Überwachen nach der Implementierung
Sie sollten die Leistungseffekte Ihrer In-Memory-OLTP-Implementierungen in der Produktion überwachen:
- Überwachen des In-Memory-OLTP-Speichers.
- Überwachen Sie die Verwendung dynamischer Verwaltungssichten.