Native Kompilierung von Tabellen und gespeicherten Prozeduren

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance

In-Memory Online Transaction Processing (OLTP) verwendet systemeigene Kompilierung, um schnelleren Datenzugriff und effizientere Abfrageausführung zu ermöglichen als interpretierte (herkömmliche) Transact-SQL. Die systemeigene Kompilierung von Tabellen und gespeicherten Prozeduren erzeugt Dynamic Link Libraries (DLLs).

Die SQL Server-Datenbank-Engine kann speicheroptimierte Tabellen, Stored Procedures, die auf speicheroptimierte Tabellen zugreifen, sowie speicheroptimierte Tabellentypen nativ kompilieren. Weitere Informationen finden Sie unter Schnellere temporäre Tabellen und Tabellenvariablen durch Speicheroptimierung.

In-Memory OLTP kompiliert speicheroptimierte Tabellen, wenn Sie sie erstellen, und kompiliert gespeicherte Prozeduren nativ in DLLs, wenn sie geladen werden. Darüber hinaus werden DLLs nach einem Datenbank- oder Serverneustart neu kompiliert. Die Datenbank speichert die erforderlichen Informationen, um die DLLs in Metadaten neu zu erstellen. Die DLLs sind nicht Teil der Datenbank, obwohl sie der Datenbank zugeordnet sind. Beispielsweise sind die DLLs nicht in Datenbanksicherungen enthalten.

Hinweis

Speicheroptimierte Tabellen werden nach einem Serverneustart neu kompiliert. Um die Datenbankwiederherstellung zu beschleunigen, kompiliert der Server nativ kompilierte gespeicherte Prozeduren beim Neustart nicht erneut. Stattdessen kompiliert sie sie bei der ersten Ausführung. Aufgrund dieser verzögerten Kompilierung werden nativ kompilierte gespeicherte Prozeduren beim Aufruf von sys.dm_os_loaded_modules erst nach der ersten Ausführung angezeigt.

Wartung von OLTP-DLLs im Arbeitsspeicher

Die folgende Abfrage zeigt alle DLLs für Tabellen und gespeicherte Prozeduren, die aktuell in den Arbeitsspeicher des Servers geladen sind:

SELECT mod1.name,
       mod1.description
FROM sys.dm_os_loaded_modules AS mod1
WHERE mod1.description = 'XTP Native DLL';

Datenbankadministratoren müssen dateien, die von der systemeigenen Kompilierung generiert werden, nicht verwalten. Die Datenbank-Engine entfernt automatisch generierte Dateien, die nicht mehr benötigt werden. Generierte Dateien werden beispielsweise gelöscht, wenn eine Tabelle und eine gespeicherte Prozedur gelöscht werden oder eine Datenbank gelöscht wird.

Hinweis

Wenn die Kompilierung fehlschlägt oder unterbrochen wird, werden einige generierte Dateien nicht entfernt. Diese Dateien werden absichtlich beibehalten, um die Unterstützbarkeit zu gewährleisten. Sie werden beim Löschen der Datenbank entfernt.

Die Datenbank-Engine kompiliert DLLs für alle Tabellen, die für die Datenbankwiederherstellung erforderlich sind. Wenn eine Tabelle direkt vor einem Datenbankneustart abgelegt wird, sind möglicherweise Reste der Tabelle in den Prüfpunktdateien oder im Transaktionsprotokoll vorhanden. Daher kann die DLL für die Tabelle während des Datenbankstarts neu kompiliert werden. Wenn dieser Vorgang nach dem Neustart der Datenbank auftritt, entlädt der normale Bereinigungsprozess die DLL und entfernt die Dateien.

Native Kompilierung von Tabellen

Wenn Sie mithilfe der CREATE TABLE Anweisung eine speicheroptimierte Tabelle erstellen, werden die Tabelleninformationen in die Datenbankmetadaten geschrieben, und die Tabellen- und Indexstrukturen werden im Arbeitsspeicher erstellt. Die Tabelle wird dann zu einer DLL kompiliert.

Das folgende Beispielskript erstellt eine Datenbank und eine speicheroptimierte Tabelle. Stellen Sie sicher, dass Sie den FILENAME Pfad zum Speicherort Des DATA Unterverzeichnisses festlegen.

USE master;
GO

CREATE DATABASE DbMemOpt3;
GO

ALTER DATABASE DbMemOpt3
ADD FILEGROUP DbMemOpt3_mod_memopt_1_fg
    CONTAINS MEMORY_OPTIMIZED_DATA;
GO

-- Change the FILENAME path to where your DATA subdirectory is located,
-- keeping only the trailing portion '\DATA\DbMemOpt3_mod_memopt_1_fn'.
ALTER DATABASE DbMemOpt3
ADD FILE (
    NAME = 'DbMemOpt3_mod_memopt_1_name',
    FILENAME = 'C:\DATA\DbMemOpt3_mod_memopt_1_fn'
)
TO FILEGROUP DbMemOpt3_mod_memopt_1_fg;
GO

USE DbMemOpt3;
GO

CREATE TABLE dbo.t1
(
    c1 INT NOT NULL PRIMARY KEY NONCLUSTERED,
    c2 INT
)
WITH (MEMORY_OPTIMIZED = ON);
GO

-- Retrieve the path of the DLL for table t1.
DECLARE @moduleName AS NVARCHAR (256);

SET @moduleName = ('%xtp_t_'
    + CAST (db_id() AS NVARCHAR (16))
    + '_' + CAST (object_id('dbo.t1') AS NVARCHAR (16))
    + '%.dll');

-- Search for the name: mod1.name LIKE '%xtp_t_8_565577053%.dll'
PRINT @moduleName;

SELECT mod1.name,
       mod1.description
FROM sys.dm_os_loaded_modules AS mod1
WHERE mod1.name LIKE @moduleName
ORDER BY mod1.name;
GO

-- Clean up.
-- DROP DATABASE DbMemOpt3;
-- GO

Durch das Erstellen der Tabelle wird auch die Tabellen-DLL erstellt und in den Arbeitsspeicher geladen. Die DMV-Abfrage unmittelbar nach der CREATE TABLE-Anweisung ruft den Pfad der Tabellen-DLL ab.

Die Tabellen-DLL kann die Indexstrukturen und das Zeilenformat der Tabelle lesen. Die Datenbank-Engine verwendet die DLL zum Durchlaufen von Indizes, zum Abrufen von Zeilen und zum Speichern des Inhalts der Zeilen.

Native Kompilierung gespeicherter Prozeduren

Markieren Sie gespeicherte Prozeduren mit NATIVE_COMPILATION, um sie nativ zu kompilieren. Transact-SQL Anweisungen in der Prozedur werden alle zur effizienten Ausführung leistungskritischer Geschäftslogik in systemeigenem Code kompiliert.

Weitere Informationen zu nativ kompilierten gespeicherten Prozeduren finden Sie in einer Anleitung zur Abfrageverarbeitung für Memory-Optimized Tabellen.

Die folgende gespeicherte Beispielprozedur fügt Zeilen in die Tabelle t1 aus dem vorherigen Beispiel ein:

CREATE PROCEDURE dbo.native_sp
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER
AS
BEGIN ATOMIC
WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english')
    DECLARE @i AS INT = 1000000;

    WHILE @i > 0
        BEGIN
            INSERT dbo.t1
            VALUES (@i, @i + 1);

            SET @i -= 1;

        END
END;
GO

EXECUTE dbo.native_sp;
GO

-- Reset.
DELETE dbo.t1;
GO

Die DLL für native_sp kann direkt mit der DLL für t1 und mit der In-Memory-OLTP-Speicher-Engine interagieren, um die Zeilen so schnell wie möglich einzufügen. Der Abfrageoptimierer erstellt einen effizienten Ausführungsplan für jede der Abfragen in der gespeicherten Prozedur.

Nativ kompilierte gespeicherte Prozeduren werden nicht automatisch neu kompiliert, wenn sich die Daten in der Tabelle ändern. Weitere Informationen zum Verwalten von Statistiken und gespeicherten Prozeduren mit OLTP im Arbeitsspeicher finden Sie in "Statistics for Memory-Optimized Tables".

Sicherheitsüberlegungen für die systemeigene Kompilierung

Die native Kompilierung von Tabellen und gespeicherten Prozeduren verwendet den OLTP-Compiler im Arbeitsspeicher. Der Compiler erzeugt Dateien, die auf den Datenträger geschrieben und in den Arbeitsspeicher geladen werden. Die Datenbank-Engine verwendet die folgenden Mechanismen, um den Zugriff auf diese Dateien zu beschränken.

Compiler

Die für die systemeigene Kompilierung erforderlichen Compilerdateien, Binärdateien und Headerdateien werden als Teil der Datenbank-Engine Instanz unter dem Ordner MSSQL\Binn\Xtpinstalliert. Wenn Sie die Standardinstanz unter C:\Program Filesinstallieren, befinden sich die Compilerdateien in C:\Program Files\Microsoft SQL Server\MSSQL\<version>.MSSQLSERVER\MSSQL\Binn\Xtp.

Um den Zugriff auf den Compiler einzuschränken, verwendet die Datenbank-Engine Zugriffssteuerungslisten (ACCESS Control Lists, ACLs), um den Zugriff auf Binärdateien einzuschränken. ACLs schützen alle Datenbank-Engine Binärdateien vor Änderungen oder Manipulationen. Die ACLs des nativen Compilers beschränken auch die Verwendung des Compilers; nur das Datenbank-Engine Dienstkontos und Systemadministratoren verfügen über Lese- und Ausführungsberechtigungen für systemeigene Compilerdateien.

Von einer nativen Kompilierung generierte Dateien

Die Dateien, die erstellt werden, wenn eine Tabelle oder gespeicherte Prozedur kompiliert wird, umfassen die DLL- und Zwischendateien, einschließlich Dateien mit den folgenden Erweiterungen: .c, , .obj, .xmlund .pdb. Die generierten Dateien werden im xtp Unterordner des Standarddatenordners gespeichert, der wie InstanceDefaultDataPath in SERVERPROPERTY definiert ist. Ein Beispiel für einen Dateipfad ist: C:\Program Files\Microsoft SQL Server\MSSQL\<version>.MSSQLSERVER\MSSQL\DATA\Xtp.

Die Datenbank-Engine verhindert die Manipulation der generierten DLLs auf drei Arten:

  • Wenn eine Tabelle oder gespeicherte Prozedur in eine DLL kompiliert wird, wird die DLL sofort in den Arbeitsspeicher geladen und mit dem sqlserver.exe Prozess verknüpft. Sie können eine DLL nicht ändern, während sie mit einem Prozess verknüpft ist.

  • Wenn eine Datenbank neu gestartet wird, werden alle Tabellen und gespeicherten Prozeduren (d. h. entfernt und neu erstellt) aus den Datenbankmetadaten neu kompiliert, wobei gespeicherte Prozeduren bei der ersten Ausführung kompiliert wurden. Durch erneute Kompilierung werden alle Änderungen verworfen, die an einer generierten Datei vorgenommen wurden, z. B. Manipulation durch einen böswilligen Agent.

  • Die generierten Dateien werden als Benutzerdaten behandelt und weisen dieselben Sicherheitseinschränkungen über ACLs wie Datenbankdateien auf. Nur das Datenbank-Engine Dienstkonto und Systemadministratoren können auf diese Dateien zugreifen.

Sie müssen diese Dateien nicht verwalten. Die Datenbank-Engine erstellt und entfernt die Dateien nach Bedarf.