Exemplarische Vorgehensweise für die Leistungsfeatures von SQL Server für Linux
Gilt für: SQL Server – Linux
Wenn Sie als Linux-Benutzer*in noch nicht mit SQL Server vertraut sind, lernen Sie in den folgenden Aufgaben einige der Leistungsfeatures kennen. Diese Features gelten nicht ausschließlich und speziell nur für Linux, aber mit diesem Artikel können Sie sich eine Übersicht über die Bereiche verschaffen, die Sie näher untersuchen sollten. In jedem Beispiel wird ein Link zu der ausführlichen Dokumentation für diesen Bereich bereitgestellt.
Hinweis
In den folgenden Beispielen wird die AdventureWorks2022
-Beispieldatenbank verwendet. Anweisungen zum Abrufen und Installieren dieser Beispieldatenbank finden Sie unter Migrieren einer SQL Server-Datenbank-Instanz von Windows zu Linux mit Sicherung und Wiederherstellung.
Erstellen eines Columnstore-Index
Ein Columnstore-Index ist eine Technologie zum Speichern und Abrufen von großen Datenspeichern in einem spaltenbasierten Datenformat, das als „Columnstore“ bezeichnet wird.
Fügen Sie der Tabelle
SalesOrderDetail
einen Columnstore-Index hinzu, indem Sie die folgenden Transact-SQL-Befehle ausführen:CREATE NONCLUSTERED COLUMNSTORE INDEX [IX_SalesOrderDetail_ColumnStore] ON Sales.SalesOrderDetail (UnitPrice, OrderQty, ProductID); GO
Führen Sie die folgende Abfrage aus, die den Columnstore-Index zum Überprüfen der Tabelle verwendet:
SELECT ProductID, SUM(UnitPrice) SumUnitPrice, AVG(UnitPrice) AvgUnitPrice, SUM(OrderQty) SumOrderQty, AVG(OrderQty) AvgOrderQty FROM Sales.SalesOrderDetail GROUP BY ProductID ORDER BY ProductID;
Überprüfen Sie, ob der Columnstore-Index verwendet wurde, indem Sie die
object_id
für den Columnstore-Index suchen und sicherstellen, dass sie in den Verbrauchsstatistiken für die TabelleSalesOrderDetail
angezeigt wird:SELECT * FROM sys.indexes WHERE name = 'IX_SalesOrderDetail_ColumnStore' GO SELECT * FROM sys.dm_db_index_usage_stats WHERE database_id = DB_ID('AdventureWorks2022') AND object_id = OBJECT_ID('AdventureWorks2022.Sales.SalesOrderDetail');
Verwenden von In-Memory-OLTP
SQL Server bietet In-Memory-OLTP-Funktionen, mit denen sich die Leistung von Anwendungssystemen erheblich verbessern lässt. Dieser Abschnitt führt Sie durch die Schritte zum Erstellen einer speicheroptimierten Tabelle, die im Arbeitsspeicher gespeichert ist, und einer nativ kompilierten gespeicherten Prozedur, die auf die Tabelle zugreifen kann, ohne kompiliert oder interpretiert werden zu müssen.
Konfigurieren einer Datenbank für In-Memory-OLTP
Es wird empfohlen, zur Verwendung von In-Memory-OLTP einen Kompatibilitätsgrad von mindestens 130 für die Datenbank festzulegen. Verwenden Sie die folgende Abfrage, um den aktuellen Kompatibilitätsgrad von
AdventureWorks2022
zu überprüfen:USE AdventureWorks2022; GO SELECT d.compatibility_level FROM sys.databases as d WHERE d.name = DB_NAME(); GO
Aktualisieren Sie den Grad ggf. auf 130:
ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 130; GO
Wenn sowohl eine datenträgerbasierte als auch eine speicheroptimierte Tabelle an einer Transaktion beteiligt sind, muss der speicheroptimierte Teil der Transaktion unbedingt auf der Transaktionsisolationsstufe SNAPSHOT ausgeführt werden. Um diese Stufe für speicheroptimierte Tabellen in einer containerübergreifenden Transaktion zuverlässig zu erzwingen, führen Sie folgenden Code aus:
ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON; GO
Bevor Sie eine speicheroptimierte Tabelle erstellen können, müssen Sie zunächst eine speicheroptimierte Dateigruppe und einen Container für Datendateien erstellen:
ALTER DATABASE AdventureWorks2022 ADD FILEGROUP AdventureWorks_mod CONTAINS memory_optimized_data; GO ALTER DATABASE AdventureWorks2022 ADD FILE (NAME='AdventureWorks_mod', FILENAME='/var/opt/mssql/data/AdventureWorks_mod') TO FILEGROUP AdventureWorks_mod; GO
Erstellen einer speicheroptimierten Tabelle
Der primäre Speicher für speicheroptimierte Tabellen ist der Hauptspeicher, daher müssen Daten im Gegensatz zu datenträgerbasierten Tabellen nicht von Datenträgern in Arbeitsspeicherpuffer eingelesen werden. Verwenden Sie zum Erstellen einer speicheroptimierten Tabelle die Klausel MEMORY_OPTIMIZED = ON.
Führen Sie die folgende Abfrage aus, um die speicheroptimierte Tabelle „dbo.ShoppingCart“ zu erstellen. Standardmäßig werden die Daten aus Gründen der Dauerhaftigkeit auf einem Datenträger gespeichert (DURABILITY kann auch so festgelegt werden, dass nur das Schema dauerhaft gespeichert wird).
CREATE TABLE dbo.ShoppingCart ( ShoppingCartId INT IDENTITY(1,1) PRIMARY KEY NONCLUSTERED, UserId INT NOT NULL INDEX ix_UserId NONCLUSTERED HASH WITH (BUCKET_COUNT=1000000), CreatedDate DATETIME2 NOT NULL, TotalPrice MONEY ) WITH (MEMORY_OPTIMIZED=ON); GO
Fügen Sie einige Datensätze in die Tabelle ein:
INSERT dbo.ShoppingCart VALUES (8798, SYSDATETIME(), NULL); INSERT dbo.ShoppingCart VALUES (23, SYSDATETIME(), 45.4); INSERT dbo.ShoppingCart VALUES (80, SYSDATETIME(), NULL); INSERT dbo.ShoppingCart VALUES (342, SYSDATETIME(), 65.4);
Systemintern kompilierte gespeicherte Prozeduren
SQL Server unterstützt nativ kompilierte gespeicherte Prozeduren, die auf speicheroptimierte Tabellen zugreifen. Die T-SQL-Anweisungen werden in Computercode kompiliert und als native DLLs gespeichert – so ermöglichen sie einen schnelleren Datenzugriff und eine effizientere Abfrageausführung als herkömmliches T-SQL. Gespeicherte Prozeduren, die mit NATIVE_COMPILATION markiert sind, werden systemintern kompiliert.
Führen Sie das folgende Skript aus, um eine nativ kompilierte gespeicherte Prozedur zu erstellen, die eine große Anzahl von Datensätzen in die Tabelle „ShoppingCart“ einfügt:
CREATE PROCEDURE dbo.usp_InsertSampleCarts @InsertCount INT WITH NATIVE_COMPILATION, SCHEMABINDING AS BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'us_english') DECLARE @i INT = 0 WHILE @i < @InsertCount BEGIN INSERT INTO dbo.ShoppingCart VALUES (1, SYSDATETIME(), NULL) SET @i += 1 END END
Fügen Sie 1.000.000 Zeilen ein:
EXEC usp_InsertSampleCarts 1000000;
Überprüfen Sie, ob die Zeilen eingefügt wurden:
SELECT COUNT(*) FROM dbo.ShoppingCart;
Verwenden des Abfragespeichers
Der Abfragespeicher sammelt detaillierte Leistungsinformationen zu Abfragen, Ausführungsplänen und Laufzeitstatistiken.
Vor SQL Server 2022 (16.x) ist der Abfragespeicher standardmäßig nicht aktiviert und kann mit ALTER DATABASE aktiviert werden:
ALTER DATABASE AdventureWorks2022 SET QUERY_STORE = ON;
Führen Sie die folgende Abfrage aus, um Informationen zu Abfragen und Plänen im Abfragespeicher zurückzugeben:
SELECT Txt.query_text_id, Txt.query_sql_text, Pl.plan_id, Qry.*
FROM sys.query_store_plan AS Pl
JOIN sys.query_store_query AS Qry
ON Pl.query_id = Qry.query_id
JOIN sys.query_store_query_text AS Txt
ON Qry.query_text_id = Txt.query_text_id;
Abfragen von dynamischen Verwaltungssichten
Dynamische Verwaltungssichten (DMVs) und geben Serverstatusinformationen zurück, mit denen Sie die Integrität einer Serverinstanz überwachen, Probleme diagnostizieren und die Leistung optimieren können.
So fragen Sie die dynamische Verwaltungssicht „dm_os_wait stats“ ab:
SELECT wait_type, wait_time_ms
FROM sys.dm_os_wait_stats;
Weitere Informationen
- Schnellstart 1: In-Memory-OLTP-Technologien für höhere Transact-SQL-Leistung
- Migrieren zu In-Memory OLTP
- Schnellere temporäre Tabellen und Tabellenvariablen durch Speicheroptimierung
- Überwachung und Fehlerbehebung für die Arbeitsspeicherauslastung
- In-Memory OLTP (In-Memory Optimization)