Verwenden von In-Memory-OLTP in Azure SQL-Datenbank zur Verbesserung der Leistung Ihrer Anwendung

  • Artikel

Gilt für:Azure SQL-Datenbank

In-Memory-OLTP kann verwendet werden, um die Leistung der Transaktionsverarbeitung, der Datenerfassung und der vorübergehenden Datenszenarien in Datenbanken des Tarifs „Premium“ und „Unternehmenskritisch“ zu verbessern, ohne den Tarif zu erhöhen.

Führen Sie diese Schritte durch, um In-Memory-OLTP in Ihrer vorhandenen Datenbank zu übernehmen.

Schritt 1: Sicherstellen, dass eine Datenbank mit dem Tarif „Premium“ oder „Unternehmenskritisch“ verwendet wird

In-Memory-OLTP wird nur für Datenbanken mit dem Tarif „Premium“ (DTU) und „Unternehmenskritisch“ (vCore) von Azure SQL-Datenbank unterstützt. In-Memory-OLTP wird unterstützt, wenn das zurückgegebene Ergebnis 1 ist (nicht 0):

SELECT DatabasePropertyEx(Db_Name(), 'IsXTPSupported');

XTP steht für Extreme Transaction Processing.

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:

  1. Stellen Sie eine Verbindung zur Testdatenbank her, indem Sie SQL Server Management Studio (SSMS) verwenden.

  2. Um zu vermeiden, dass die Option WITH (SNAPSHOT) in Abfragen benötigt wird, setzen Sie die Option MEMORY_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:

Speicheroptimierungs-Assistent in SSMS

So verwenden Sie diese Migrationsoption:

  1. Stellen Sie über SSMS eine Verbindung mit der Testdatenbank her.

  2. 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.

  3. 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:

  4. 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:

  1. Verbinden Sie sich mit der Testdatenbank mit SSMS (oder einem ähnlichen Dienstprogramm).
  2. Rufen Sie das vollständige T-SQL-Skript für die Tabelle und ihre 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.
  3. Fügen Sie im Skriptfenster der Anweisung CREATE TABLE ein WITH (MEMORY_OPTIMIZED = ON) hinzu.
  4. Wenn ein Index als CLUSTERED gekennzeichnet ist, ändern Sie ihn in NONCLUSTERED.
  5. Benennen Sie die vorhandene Tabelle mittels sp_rename um.
  6. Erstellen Sie die neue speicheroptimierte Kopie der Tabelle, indem Sie das bearbeitete CREATE TABLE-Skript ausführen.
  7. 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

Das In-Memory-Feature kann auch eine gespeicherte Prozedur zur Verbesserung der Leistung ändern.

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: Bezieht sich auf Tabellen, deren Spaltendefinitionen nicht in einer Weise geändert werden dürfen, die sich auf die gespeicherte Prozedur auswirkt, sofern Sie die gespeicherte Prozedur nicht löschen.

Ein systemeigenes Modul muss einen großen ATOMIC-Block zum Verwalten von Transaktionen verwenden. Es gibt keine Rolle für ein explizites BEGIN TRANSACTION oder ROLLBACK TRANSACTION. Wenn Ihr Code einen Verstoß gegen eine Geschäftsregel erkennt, kann er den atomischen Block mit einer THROW-Anweisung beenden.

In der Regel CREATE PROCEDURE für systemeigen kompilierte gespeicherte Prozeduren verwenden

In der Regel entspricht der T-SQL-Code zum Erstellen einer systemeigen kompilierten gespeicherten Prozedur 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 ist SNAPSHOT der häufigste Wert für die systemeigen kompilierte gespeicherte Prozedur. Eine Teilmenge der anderen Werte wird jedoch ebenfalls unterstützt:
    • REPEATABLE READ
    • SERIALIZABLE
  • Der LANGUAGE-Wert muss in der Ansicht sys.syslanguages in der Spalte name vorhanden sein. Beispiel: N'us_english'.

Migrieren einer gespeicherten Prozedur

Die Migrationsschritte sind wie folgt:

  1. Rufen Sie das CREATE PROCEDURE-Skript für die regulär übersetzte gespeicherte Prozedur auf.
  2. Schreiben Sie ihren Header entsprechend der vorherigen Vorlage neu.
  3. 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.
  4. Benennen Sie die alte gespeicherte Prozedur mithilfe von sp_rename um. Oder löschen Sie sie einfach (DROP).
  5. 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-Features für Tabellen und gespeicherte Prozeduren erzielen.

Wichtige Attribute der Workload sind:

  • Anzahl gleichzeitiger Verbindungen.
  • Lese-/Schreib-Verhältnis.

Zum Anpassen und Ausführen der Testworkload empfiehlt Sie praktische Tool „ostress.exe“. Weitere Informationen finden Sie unter In-Memory-Beispiel in Azure SQL-Datenbank.

Um die Netzwerklatenz zu minimieren, führen Sie den Test in der gleichen geografischen Azure-Region aus, in der die Datenbank vorhanden ist.

Schritt 7: Überwachen nach der Implementierung

Sie sollten die Leistungseffekte Ihrer In-Memory-Implementierungen in der Produktion überwachen:

Zugehöriger Inhalt