Diagnostizieren und Behandeln von Problemen mit hoher CPU-Auslastung in Azure SQL-Datenbank

Gilt für:Azure SQL-Datenbank

Azure SQL-Datenbank bietet integrierte Tools, um die Ursachen der hohen CPU-Auslastung zu identifizieren und die Arbeitsleistung zu optimieren. Sie können diese Tools verwenden, um eine hohe CPU-Auslastung zu beheben, während sie auftritt, oder reaktiv, nachdem der Vorfall abgeschlossen ist. Sie können auch Automatische Optimierung aktivieren, um die CPU-Auslastung Ihrer Datenbank im Laufe der Zeit proaktiv zu reduzieren. Dieser Artikel lehrt Sie, eine hohe CPU-Auslastung mit integrierten Tools in der Azure SQL-Datenbank zu diagnostizieren und zu beheben und beschreibt, wann CPU-Ressourcen hinzugefügt werden sollen.

Verstehen der Anzahl virtueller Kerne

Es ist hilfreich, die Anzahl der virtuellen Kerne (vCores) zu verstehen, die Ihrer Datenbank zur Verfügung stehen, wenn Sie einen Vorfall hoher CPU-Auslastung diagnostizieren. Ein virtueller Kern entspricht einem logischen Prozessor. Die Anzahl der virtuellen Kerne hilft Ihnen, die CPU-Ressourcen zu verstehen, die Ihrer Datenbank zur Verfügung stehen.

Identifizieren der Anzahl der virtuellen Kerne im Azure-Portal

Sie können die Anzahl der virtuellen Kerne für eine Datenbank im Azure-Portal schnell ermitteln, wenn Sie eine auf virtuelle Kerne basierte Dienstebene mit der bereitgestellten Berechnungsebene verwenden. In diesem Fall enthält der auf der Übersicht-Seite der Datenbank aufgeführte Tarif die Anzahl der virtuellen Kerne. Beispielsweise kann der Tarif einer Datenbank „Universell: Standard-Serie (Gen5), 16 virtuelle Kerne“ sein.

Für Datenbanken in der serverlosen Berechnungsebene entspricht die Anzahl der virtuellen Kerne jener der maximalen Einstellung der virtuellen Kerne der Datenbank. Die Anzahl der virtuellen Kerne wird im für die Datenbank aufgeführten Tarif auf der Übersicht-Seite angezeigt. Beispielsweise kann der Tarif einer Datenbank „Universell: Standard-Serie (Gen5) serverlos, 16 virtuelle Kerne“ sein.

Wenn Sie eine Datenbank unter dem DTU-basierten Kaufmodell verwenden, müssen Sie Transact-SQL verwenden, um die Anzahl der virtuellen Kerne der Datenbank abzufragen.

Identifizieren der Anzahl der virtuellen Kerne mit Transact-SQL

Sie können die aktuelle Anzahl der virtuellen Kerne für jede Datenbank mit Transact-SQL ermitteln. Sie können Transact-SQL gegen Azure SQL Database mit SQL Server Management Studio (SSMS), Azure Data Studio oder dem Abfrag-Eeditor des Azure-Portals ausführen.

Stellen Sie eine Verbindung mit Ihrem Datenbank her, und führen Sie die folgende Abfrage aus:

SELECT 
    COUNT(*) as vCores
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE';
GO

Identifizieren der Ursachen für hohe CPU-Auslastung

Sie können die CPU-Auslastung mithilfe des Azure-Portals, der interaktiven Tools im Abfragespeicher in SSMS und der Transact-SQL-Abfragen in SSMS und Azure Data Studio messen und analysieren.

Das Azure-Portal und der Abfragespeicher zeigen Ausführungsstatistiken wie CPU-Metriken für abgeschlossene Abfragen an. Wenn Sie einen aktuellen Vorfall hoher CPU-Auslastung haben, der durch eine oder mehrere laufende, lang laufende Abfragen verursacht werden kann, identifizieren Sie die derzeit ausgeführte Abfragen mit Transact-SQL.

Häufige Ursachen für neue und ungewöhnlich hohe CPU-Auslastung sind:

  • Neue Abfragen im Workload, die eine große Menge an CPU verwenden.
  • Eine Erhöhung der Häufigkeit von regelmäßig laufenden Abfragen.
  • Abfrageplan-Regression, einschließlich durch PSP-Probleme (Parameter Sensitive Plan, parameterempfindlicher Plan) bedingte Regression, die zu einer oder mehreren Abfragen führt, die mehr CPU erfordern.
  • Eine signifikante Steigerung der Zusammenstellung oder Neukompilierung von Abfrageplänen.
  • Datenbanken, in denen Abfragen übermäßige Parallelität verwenden.

Um zu verstehen, was Ihre hohe CPU-Auslastung verursacht, identifizieren Sie, wenn eine hohe CPU-Auslastung gegen Ihre Datenbank und die Top-Abfragen mit CPU zu diesem Zeitpunkt auftritt.

Prüfen Sie Folgendes:

Hinweis

Azure SQL-Datenbank benötigt Computeressourcen zur Implementierung zentraler Dienstfeatures wie Hochverfügbarkeit und Notfallwiederherstellung, Datenbanksicherung und -wiederherstellung, Überwachung, Abfragespeicher, automatische Optimierung und Ähnliches. Der Einsatz dieser Berechnungsressourcen kann besonders auf Datenbanken mit geringer Anzahl an virtuellen Kernen oder Datenbanken in dichten Pools für elastische Datenbanken spürbar sein. Erfahren Sie mehr in Ressourcenverwaltung in Azure SQL-Datenbank.

Verwenden Sie das Azure-Portal, um verschiedene CPU-Metriken zu verfolgen, einschließlich des Prozentsatzes der verfügbaren CPU, der von Ihrer Datenbank im Laufe der Zeit verwendet wird. Das Azure-Portal kombiniert CPU-Metriken mit Informationen aus dem Abfragespeicher Ihrer Datenbank, mit denen Sie ermitteln können, welche Abfragen die CPU in Ihrer Datenbank zu einem bestimmten Zeitpunkt verbrauchen.

Befolgen Sie diese Schritte, um prozentuale Metriken Ihrer CPU zu finden.

  1. Navigieren zur Datenbank im Azure-Portal.
  2. Wählen Sie unter Intelligente Leistung im linken Menü Statistik zur Abfrageleistung.

Die Standardansicht von Statistik zur Abfrageleistung zeigt die Daten der letzten 24 Stunden. Die CPU-Auslastung wird als Prozentsatz der gesamten verfügbaren CPU angezeigt, die für die Datenbank verwendet wird.

Die Top-5-Abfragen in diesem Zeitraum werden in vertikalen Balken oberhalb des CPU-Verbrauchsdiagramms angezeigt. Wählen Sie ein Zeitband auf dem Chart oder verwenden Sie das Anpassen-Menü, um bestimmte Zeiträume zu erkunden. Sie können auch die Anzahl der angezeigten Abfragen erhöhen.

Screenshot shows Query Performance Insight in the Azure portal.

Wählen Sie jede Abfrage-ID mit hoher CPU aus, um Details für die Abfrage zu öffnen. Details enthalten Abfragetext zusammen mit Leistungsverlauf für die Abfrage. Prüfen Sie, ob die CPU kürzlich für die Abfrage erhöht wurde.

Beachten Sie die Abfrage-ID, um den Abfrageplan mithilfe des Abfragespeichers im folgenden Abschnitt weiter zu untersuchen.

Überprüfung von Abfrageplänen für Top-Abfragen im Azure-Portal

Befolgen Sie diese Schritte, um eine Abfrage-ID in den interaktiven Abfragespeicher-Tools von SSMS zu verwenden, um den Ausführungsplan der Abfrage im Laufe der Zeit zu überprüfen.

  1. Öffnen Sie SSMS.
  2. Stellen Sie im Objekt-Explorer eine Verbindung mit der Azure SQL-Datenbank her.
  3. Erweitern Sie den Knoten Datenbanken im Objekt-Explorer.
  4. Erweitern Sie den Ordner Abfragespeicher.
  5. Öffnen Sie den Bereich Nachverfolgte Abfragen.
  6. Geben Sie die Abfrage-ID im Feld Abfrage nachverfolgen oben links auf dem Bildschirm ein und drücken Sie die Eingabetaste.
  7. Wenn nötig, wählen Sie Konfigurieren, um das Zeitintervall an die Zeit anzupassen, in der eine hohe CPU-Auslastung auftrat.

Die Seite zeigt den Ausführungsplan/die Ausführungspläne und die zugehörigen Metriken für die Abfrage in den letzten 24 Stunden an.

Identifizieren aktuell laufender Abfragen mit Transact-SQL

Mit Transact-SQL können Sie aktuell laufende Abfragen mit der bisher verwendeten Prozessorzeit identifizieren. Sie können Transact-SQL auch verwenden, um die aktuelle CPU-Auslastung in Ihrer Datenbank abzufragen, Top-Abfragen nach CPU und Abfragen, die am häufigsten kompiliert wurden.

Sie können CPU-Metriken mit SQL Server Management Studio (SSMS), Azure Data Studio oder dem Abfrage-Editor des Azure-Portals abfragen. Wenn Sie SSMS oder Azure Data Studio verwenden, öffnen Sie ein neues Abfragefenster, und verbinden Sie es mit Ihrer Datenbank (nicht der master-Datenbank).

Suchen Sie derzeit laufende Abfragen mit CPU-Auslastung und Ausführungsplänen, indem Sie die folgende Abfrage ausführen. Die Prozessorzeit wird in Millisekunden angegeben.

SELECT
    req.session_id,
    req.status,
    req.start_time,
    req.cpu_time AS 'cpu_time_ms',
    req.logical_reads,
    req.dop,
    s.login_name,
    s.host_name,
    s.program_name,
    object_name(st.objectid,st.dbid) 'ObjectName',
    REPLACE (REPLACE (SUBSTRING (st.text,(req.statement_start_offset/2) + 1,
        ((CASE req.statement_end_offset    WHEN -1    THEN DATALENGTH(st.text) 
        ELSE req.statement_end_offset END - req.statement_start_offset)/2) + 1),
        CHAR(10), ' '), CHAR(13), ' ') AS statement_text,
    qp.query_plan,
    qsx.query_plan as query_plan_with_in_flight_statistics
FROM sys.dm_exec_requests as req  
JOIN sys.dm_exec_sessions as s on req.session_id=s.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as st
OUTER APPLY sys.dm_exec_query_plan(req.plan_handle) as qp
OUTER APPLY sys.dm_exec_query_statistics_xml(req.session_id) as qsx
ORDER BY req.cpu_time desc;
GO

Diese Abfrage gibt zwei Kopien des Ausführungsplans zurück. Kolonne query_plan enthält den Ausführungsplan von sys.dm_exec_query_plan. Diese Version des Ausführungsplans enthält lediglich Schätzwerte der Zeilenanzahl und beinhaltet keine Ausführungsstatistiken.

Wenn Kolonne query_plan_with_in_flight_statistics einen Ausführungsplan zurückgibt, so liefert dieser Plan weiterführende Informationen. Kolonne query_plan_with_in_flight_statistics gibt Daten von sys.dm_exec_query_statistics_xml zurück, einschließlich „in Flight“-Ausführungsstatistiken wie die aktuelle Anzahl an bisher zurückgegebenen Zeilen in einer laufenden Ausführungsabfrage.

Überprüfen der CPU-Nutzungsmetriken für die letzte Stunde

Die folgende Abfrage gegen sys.dm_db_resource_stats gibt die durchschnittliche CPU-Auslastung über 15-Sekunden-Intervalle für etwa die letzte Stunde zurück.

SELECT
    end_time,
    avg_cpu_percent,
    avg_instance_cpu_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC; 
GO

Es ist wichtig, sich nicht nur auf die avg_cpu_percent-Spalte zu konzentrieren. Die avg_instance_cpu_percent-Spalte enthält CPU, die sowohl von Benutzer‘innen als auch internen Workloads genutzt wird. Wenn avg_instance_cpu_percent nahe bei 100 % liegt, sind die CPU-Ressourcen gesättigt. In diesem Fall sollten Sie die hohe CPU-Auslastung beheben, wenn der App-Durchsatz unzureichend ist oder die Abfrage-Wartezeit hoch ist.

Erfahren Sie mehr in Ressourcenverwaltung in Azure SQL-Datenbank.

Lesen Sie die Beispiele in sys.dm_db_resource_stats für weitere Abfragen.

Abfrage der letzten 15 Abfragen nach CPU-Auslastung

Der Abfragespeicher zeichnet Ausführungsstatistiken für Abfragen auf, einschließlich CPU-Verbrauch. Die folgende Abfrage gibt die Top 15 Abfragen zurück, die in den letzten 2 Stunden ausgeführt wurden, gereiht nach CPU-Verbrauch. Die Prozessorzeit wird in Millisekunden angegeben.

WITH AggregatedCPU AS 
    (SELECT
        q.query_hash, 
        SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_ms, 
        SUM(count_executions * avg_cpu_time / 1000.0)/ SUM(count_executions) AS avg_cpu_ms, 
        MAX(rs.max_cpu_time / 1000.00) AS max_cpu_ms, 
        MAX(max_logical_io_reads) max_logical_reads, 
        COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans, 
        COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids, 
        SUM(CASE WHEN rs.execution_type_desc='Aborted' THEN count_executions ELSE 0 END) AS aborted_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Regular' THEN count_executions ELSE 0 END) AS regular_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Exception' THEN count_executions ELSE 0 END) AS exception_execution_count, 
        SUM(count_executions) AS total_executions, 
        MIN(qt.query_sql_text) AS sampled_query_text
    FROM sys.query_store_query_text AS qt
    JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
    JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id
    JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=rs.runtime_stats_interval_id
    WHERE 
            rs.execution_type_desc IN ('Regular', 'Aborted', 'Exception') AND 
        rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
     GROUP BY q.query_hash), 
OrderedCPU AS 
    (SELECT *, 
    ROW_NUMBER() OVER (ORDER BY total_cpu_ms DESC, query_hash ASC) AS RN
    FROM AggregatedCPU)
SELECT *
FROM OrderedCPU AS OD
WHERE OD.RN<=15
ORDER BY total_cpu_ms DESC;
GO

Diese Abfrage gruppiert sich nach einem Hashwert der Abfrage. Wenn Sie einen hohen Wert in der Spalte number_of_distinct_query_ids finden, untersuchen Sie, ob eine häufig ausgeführte Abfrage nicht richtig parametriert ist. Nicht-parametrierte Abfragen können bei jeder Ausführung kompiliert werden, was eine signifikanten CPU-Verbrauch zur Folge hat und die Leistung des Abfragespeichers beeinträchtigt.

Um mehr über eine individuelle Abfrage zu erfahren, notieren Sie den Abfrage-Hash und verwenden Sie ihn, um die CPU-Auslastung und den Abfrageplan für einen bestimmten Abfrage-Hash zu ermitteln.

Abfrage der am häufigsten kompilierten Abfragen nach Abfrage-Hash

Das Kompilieren eines Abfrageplans ist ein CPU-intensiver Prozess. Azure SQL-Datenbank führt eine Zwischenspeicherung von Plänen im Speicher zur späteren Verwendung aus. Einige Abfragen können häufig kompiliert werden, wenn sie nicht parametriert sind oder RECOMPILE auf erzwungene Rekompilierung hinweist.

Der Abfragespeicher zeichnet auf, wie oft Abfragen erstellt werden. Führen Sie die folgende Abfrage aus, um die Top-20-Abfragen im Abfragespeicher anhand der Kompilierungsanzahl zusammen mit der durchschnittlichen Anzahl von Kompilierungen pro Minute zu ermitteln:

SELECT TOP (20)
    query_hash,
    MIN(initial_compile_start_time) as initial_compile_start_time,
    MAX(last_compile_start_time) as last_compile_start_time,
    CASE WHEN DATEDIFF(mi,MIN(initial_compile_start_time), MAX(last_compile_start_time)) > 0
        THEN 1.* SUM(count_compiles) / DATEDIFF(mi,MIN(initial_compile_start_time), 
            MAX(last_compile_start_time)) 
        ELSE 0 
        END as avg_compiles_minute,
    SUM(count_compiles) as count_compiles
FROM sys.query_store_query AS q
GROUP BY query_hash
ORDER BY count_compiles DESC;
GO

Um mehr über eine individuelle Abfrage zu erfahren, notieren Sie den Abfrage-Hash und verwenden Sie ihn, um die CPU-Auslastung und den Abfrageplan für einen bestimmten Abfrage-Hash zu ermitteln.

Ermittlung des CPU-Verbrauchs und Abfrageplans für einen bestimmten Abfrage-Hash

Führen Sie die folgende Abfrage aus, um die individuelle Abfrage-ID, den Abfragetext und die Abfrageausführungspläne für ein bestimmtes query_hash zu ermitteln. Die Prozessorzeit wird in Millisekunden angegeben.

Ersetzen Sie den Wert für die Variable @query_hash durch einen gültigen query_hash für Ihren Workload.

declare @query_hash binary(8);

SET @query_hash = 0x6557BE7936AA2E91;

with query_ids as (
    SELECT
        q.query_hash,
        q.query_id,
        p.query_plan_hash,
        SUM(qrs.count_executions) * AVG(qrs.avg_cpu_time)/1000. as total_cpu_time_ms,
        SUM(qrs.count_executions) AS sum_executions,
        AVG(qrs.avg_cpu_time)/1000. AS avg_cpu_time_ms
    FROM sys.query_store_query q
    JOIN sys.query_store_plan p on q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats qrs on p.plan_id = qrs.plan_id
    WHERE q.query_hash = @query_hash
    GROUP BY q.query_id, q.query_hash, p.query_plan_hash)
SELECT qid.*,
    qt.query_sql_text,
    p.count_compiles,
    TRY_CAST(p.query_plan as XML) as query_plan
FROM query_ids as qid
JOIN sys.query_store_query AS q ON qid.query_id=q.query_id
JOIN sys.query_store_query_text AS qt on q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan AS p ON qid.query_id=p.query_id and qid.query_plan_hash=p.query_plan_hash
ORDER BY total_cpu_time_ms DESC;
GO

Diese Abfrage gibt eine Zeile für jede Variante eines Ausführungsplans für query_hash über den gesamten Verlauf Ihres Abfragespeichers zurück. Die Ergebnisse werden nach Gesamt-Prozessorzeit sortiert.

Verwendung interaktiver Abfragespeicher-Tools zur Nachverfolgung der CPU-Auslastung

Wenn Sie die Verwendung grafischer Tools bevorzugen, befolgen Sie diese Schritte zur Verwendung des interaktiven Abfragespeicher-Tools in SSMS.

  1. Öffnen SIe SSMS und stellen Sie im Objekt-Explorer eine Verbindung mit Ihrer Datenbank her.
  2. Erweitern Sie den Knoten Datenbanken im Objekt-Explorer.
  3. Erweitern Sie den Ordner Abfragespeicher.
  4. Öffnen Sie den Bereich Gesamter Ressourcenverbrauch.

Die gesamte Prozessorzeit für Ihre Datenbank im letzten Monat in Millisekunden wird im unteren linken Teil des Bereichs angezeigt. In der Standardansicht wird die Prozessorzeit pro Tag aggregiert.

Screenshot shows the Overall Resource Consumption view of Query Store in SSMS.

Wählen Sie Konfigurieren im rechten oberen Teil des Bereichs, um eine andere Zeitperiode auszuwählen. Sie können auch die Einheit der Aggregation ändern. Beispielsweise können Sie die Daten für einen bestimmten Datumsbereich anzeigen und die Daten nach Stunden aggregieren.

Verwendung interaktiver Abfragespeicher-Tools zur Ermittlung der Top-Abfragen nach Prozessorzeit

Wählen Sie für mehr Details einen Balken im Diagramm, um Abfragen anzuzeigen, die in einem bestimmten Zeitraum ausgeführt werden. Es öffnet sich der Bereich Abfragen mit dem höchsten Ressourcenverbrauch. Alternativ können Sie die Abfragen mit dem höchsten Ressourcenverbrauch direkt aus dem Abfragespeicher-Knoten unter Ihrer Datenbank im Object Explorer öffnen.

Screenshot shows the Top Resource Consuming Queries pane for Query Store in S S M S.

In der Standardansicht zeigt der Bereich Abfragen mit dem höchsten Ressourcenverbrauch Abfragen nach Dauer (ms). Die Dauer kann manchmal niedriger sein als die Prozessorzeit: Parallelität nutzende Abfragen verbrauchen eventuell mehr Prozessorzeit als ihre Gesamtdauer. Die Dauer kann auch höher sein als die CPU-Zeit, wenn Wartezeiten signifikant sind. Um Abfragen nach CPU-Zeit anzuzeigen, wählen Sie oben links im Bereich Metrik das Drop-Down-Menü und wählen Sie CPU-Zeit(ms).

Jeder Balken im oberen linken Quadranten stellt eine Abfrage dar. Wählen Sie einen Balken, um Details zu dieser Abfrage anzuzeigen. Der rechte obere Quadrant der Anzeige zeigt an, wie viele Ausführungspläne im Abfragespeicher für diese Abfrage vorhanden sind und wie viel Ihrer ausgewählten Metrik verwendet wurde. Wählen Sie jede Plan-ID aus, um zu steuern, welcher Abfrageausführungsplan in der unteren Anzeigehälfte angezeigt wird.

Hinweis

Eine Anleitung zur Interpretation von Abfragespeicher-Ansichten und der Formen, die in der Ansicht „Abfragen mit dem höchsten Ressourcenverbrauch“ angezeigt werden, finden Sie unter Bewährte Methoden für den Abfragespeicher

Reduzierung der CPU-Auslastung

Ein Teil Ihrer Problembehandlung sollte sein, mehr über die im vorherigen Abschnitt identifizierten Abfragen erfahren. Sie können den CPU-Verbrauch reduzieren, indem Sie Indizes optimieren, Ihre Anwendungsmuster ändern, Abfragen anpassen und CPU-bezogene Einstellungen für Ihre Datenbank anpassen.

Sehen Sie sich die folgenden Strategien in diesem Abschnitt an:

Reduzierung der CPU-Auslastung mit automatischer Indexoptimierung

Effektive Indexoptimierung reduziert die CPU-Auslastung für viele Abfragen. Optimierte Indizes reduzieren die logischen und physikalischen Reads für eine Abfrage, was oft dazu führt, dass die Abfrage weniger Arbeit verrichten muss.

Die Azure SQL-Datenbank bietet automatische Indexverwaltung für Workloads auf primären Replikaten. Die automatische Indexverwaltung nutzt maschinelles Lernen, um Ihren Workload zu überwachen und Rowstore-basierte, nicht gruppierte Indizes für Ihre Datenbank zu optimieren.

Überprüfen Sie Leistungsempfehlungen, einschließlich Index-Empfehlungen, im Azure-Portal. Sie können diese Empfehlungen manuell anwenden oder die Option CREATE INDEX automatische Optimierung aktivieren, um neue Indizes zu erstellen und deren Leistung in Ihrer Datenbank zu verifizieren.

Reduzierung der CPU-Auslastung mit automatischer Plankorrektur (Force Plan)

Eine weitere häufige Ursache für Zwischenfälle mit hoher CPU-Auslastung ist die Ausführungsplan-Auswahlregression. Die Azure SQL-Datenbank bietet die automatische Opimierungsoption Force Plan, um Regressionen in Abfrageausführungsplänen in Workloads auf primären Repliken zu identifizieren. Wenn diese automatische Optimierungsfunktion aktiviert ist, testet die Azure SQL-Datenbank, ob ein Abfrage-Ausführungsplan eine zuverlässige verbesserte Leistung für Abfragen mit Ausführungsplan-Regression ergibt.

Wenn Ihre Datenbank nach März 2020 erstellt wurde, wurde die automatische Optimierungsoption Force Plan automatisch aktiviert. Wenn Ihre Datenbank vor dieser Zeit erstellt wurde, können Sie die automatische Optimierungsoption Force Plan aktivieren.

Indizes manuell optimieren

Wenden Sie die in Identifizieren Sie die Ursachen für hohe CPU beschriebenen Methoden an, um Abfragepläne für Ihre Top-CPU-verbrauchenden Abfragen zu identifizieren. Diese Ausführungspläne helfen Ihnen dabei, nicht gruppierte Indizes zu ermitteln und hinzuzufügen, um Ihre Abfragen zu beschleunigen.

Jeder laufwerkbasierte, nicht gruppierter Index in Ihrer Datenbank benötigt Speicherplatz und muss von der SQL-Engine gepflegt werden. Ändern Sie wenn möglich vorhandene Indizes, anstatt neue Indizes hinzuzufügen, und stellen Sie sicher, dass neue Indizes die CPU-Auslastung erfolgreich reduzieren. Eine Übersicht nicht gruppierter Indizes finden Sie in Leitfaden zur Gestaltung von nicht gruppierten Indizes.

Für einige Workloads sind Columnstore-Indizes die beste Wahl, um die CPU häufiger Leseabfragen zu reduzieren. Siehe Leitfaden zum Entwerfen von Columnstore-Indizes für hochrangige Empfehlungen zu Szenarien, in denen Columnstore-Indizes geeignet sein könnten.

Optimierung Ihrer App, Abfragen und Datenbank-Einstellungen

Bei der Prüfung Ihrer Top-Abfragen kann es sein, dass Sie Anwendungs-Antipattern, wie „chatty“ Verhalten, Workloads, die von Sharding profitieren würde, und suboptimales Datenbank-Zugriffsdesign finden. Für leseintensive Workloads sollten Sie schreibgeschützte Repliken zur Auslagerung schreibgeschützter Abfrageworkloads und Application-Tier-Caching als langfristige Strategien zur Skalierung häufig gelesener Daten betrachten.

Sie können auch die Top-CPU manuell optimieren, indem Sie Abfragen in Ihrem Workload verwenden. Manuelle Optimierungsoptionen beinhalten das Neuschreiben von Transact-SQL-Anweisungen, Erzwingen von Plänen im Abfragespeicher und das Anwenden von Abfrage-Hinweisen.

Wenn Sie Fälle identifizieren, in denen Abfragen manchmal einen Ausführungsplan verwenden, der nicht optimal für die Leistung ist, überprüfen Sie die Lösungen in Abfragen, die Probleme mit dem Parameter sensitive plan (PSP) verursachen

Wenn Sie nicht-parametrierte Abfragen mit einer hohen Anzahl von Plänen identifizieren, sollten Sie diese Abfragen parametrisieren und sicherstellen, dass Parameterdatentypen einschließlich Länge und Genauigkeit vollständig deklariert werden. Dies kann durch Modifizieren der Abfragen, Erzeugen einer Planhinweisliste zur Erzwingung der Parametrierung einer bestimmten Abfrage oder durch Aktivieren der erzwungenen Parametrierung auf Datenbankebene erfolgen.

Wenn Sie Abfragen mit hohen Kompilierungsraten identifizieren, ermitteln Sie, was die häufige Kompilierung verursacht. Die häufigste Ursache für häufiges Kompilieren ist RECOMPILE-Hinweise. Wenn möglich, identifizieren, wann der RECOMPILE Hinweis hinzugefügt wurde und welches Problem er lösen sollte. Untersuchen Sie, ob eine alternative Leistungsoptimierungslösung implementiert werden kann, um eine konsistente Leistung für häufig ausgeführte Abfragen ohne einen RECOMPILE-Hinweis bereitzustellen.

Reduzierung der CPU-Auslastung durch Optimierung des maximalen Grads an Parallelität

Die Einstellung maximaler Grad an Parallelität (MAXDOP) steuert die Intra-Abfrage-Parallelität in der Datenbank-Engine. Höhere MAXDOP-Werte führen in der Regel zu mehr parallelen Threads pro Abfrage und zu einer schnelleren Abfrageausführung.

In einigen Fällen kann eine große Anzahl gleichzeitig ausgeführter Abfragen den Workload verlangsamen und eine hohe CPU-Auslastung verursachen. Eine übermäßige Parallelität tritt am ehesten in Datenbanken mit einer großen Anzahl von virtuellen Kernen auf, in denen MAXDOP auf eine hohe Zahl oder auf Null gesetzt ist. Wenn MAXDOP auf Null gesetzt ist, setzt die Datenbank-Engine die Anzahl an Planern, die von parallelen Threads verwendet werden sollen, auf die Gesamtanzahl logischer Prozessoren oder auf „64“ (je nachdem, welcher Wert kleiner ist).

Mit Transact-SQL können Sie Einstellung des maximalen Grads an Parallelität Ihrer Datenbank ermitteln. Verbinden Sie sich mit SSMS oder Azure Data Studio mit Ihrer Datenbank und führen Sie die folgende Abfrage aus:

SELECT 
    name, 
    value, 
    value_for_secondary, 
    is_value_default 
FROM sys.database_scoped_configurations
WHERE name=N'MAXDOP';
GO

Experimentieren Sie mit kleinen Änderungen in der MAXDOP-Konfiguration auf Datenbankebene oder ändern Sie einzelne problematische Abfragen, um einen nicht standardmäßigen MAXDOP mit einem Abfragehinweis zu verwenden. Weitere Informationen finden Sie in den Beispielen unter Einstellung des maximalen Grads an Parallelität.

Wann CPU-Ressourcen hinzugefügt werden sollen

Vielleicht stellen Sie fest, dass die Abfragen und Indizes Ihres Workloads richtig eingestellt sind oder dass die Leistungsoptimierung Änderungen erfordert, die Sie aufgrund interner Prozesse oder aus anderen Gründen kurzfristig nicht vornehmen können. Das Hinzufügen weiterer CPU-Ressourcen kann für diese Datenbanken von Vorteil sein. Sie können Datenbankressourcen bei minimaler Downtime skalieren.

Sie können weitere CPU-Ressourcen zu Ihrer Azure SQL-Datenbank-Instanz hinzufügen, indem Sie die Anzahl der virtuellen Kerne oder die Hardwarekonfiguration für Datenbanken mit dem Kaufmodell für virtuelle Kerne konfigurieren.

Unter dem DTU-basierten Kaufmodell können Sie Ihre Dienstebene und die Anzahl der Datenbanktransaktionseinheiten (DTUs) erhöhen. DTUs stellen eine kombinierte Messung von CPU, Arbeitsspeicher, Lese- und Schreibvorgängen dar. Ein Vorteil des Kaufmodells für virtuelle Kerne ist, dass es eine präzisere Kontrolle über die verwendete Hardware und die Anzahl der virtuellen Kerne ermöglicht. Sie können Azure SQL-Datenbank vom DTU-basierten Modell zum Modell für virtuelle Kerne migrieren, um zwischen Kaufmodellen zu wechseln.

Erfahren Sie mehr über die Überwachung und Leistungsoptimierung einer Azure SQL-Datenbank in den folgenden Artikeln: