Freigeben über

Behebung von Leistungsunterschieden bei Abfragen zwischen Datenbankanwendung und SSMS

  • Artikel

Wenn Sie eine Abfrage in einer Datenbankanwendung ausführen, wird sie langsamer als dieselbe Abfrage in einer Anwendung wie SQL Server Management Studio (SSMS), Azure Data Studio oder SQLCMD ausgeführt.

Dieses Problem kann aus folgenden Gründen auftreten:

  • Abfragen verwenden unterschiedliche Parameter oder Variablen.

  • Abfragen werden über verschiedene Netzwerke an den Server übermittelt, oder es gibt einen Unterschied, wie die Anwendungen Daten verarbeiten.

  • SET-Optionen in der Datenbankanwendung und SSMS unterscheiden sich.

Um das Problem zu beheben, führen Sie die folgenden Schritte aus:

Schritt 1: Überprüfen, ob die Abfragen mit denselben Parametern oder Variablen übermittelt werden

Führen Sie die folgenden Schritte aus, um diese Abfragen zu vergleichen und sicherzustellen, dass sie auf jede Weise identisch sind:

  1. Öffnen Sie Ihr SSMS, und verbinden Sie es mit dem von Ihnen verwendeten Datenbank-Engine.

  2. Führen Sie die folgenden Befehle aus, um eine Erweiterte Ereignissitzung zu erstellen:

    CREATE EVENT SESSION <EventSessionName> ON SERVER
ADD EVENT sqlserver.existing_connection(SET collect_options_text=(1)),
ADD EVENT sqlserver.login(SET collect_options_text=(1)
    ACTION(sqlserver.client_app_name)),
ADD EVENT sqlserver.rpc_completed,
ADD EVENT sqlserver.sp_statement_completed(
    ACTION(sqlserver.client_app_name)),
ADD EVENT sqlserver.sql_batch_completed(
    ACTION(sqlserver.client_app_name)),
ADD EVENT sqlserver.sql_statement_completed(
    ACTION(sqlserver.client_app_name))
ADD TARGET package0.event_file(SET filename=N'<FilePath>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 
SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

    Notiz

    Ersetzen Sie die Platzhalter <EventSessionName> und <FilePath> durch diejenigen, die Sie erstellen möchten.

  3. Führen Sie die folgenden Befehle aus, um die Sitzung "EventSessionName" zu starten:

    ALTER EVENT SESSION <EventSessionName> ON SERVER
STATE = START

  4. Führen Sie Ihre Abfragen aus, um das Problem zu reproduzieren.

  5. Verwenden Sie eine der folgenden Methoden, um die gesammelten Daten zu analysieren:

    • Öffnen Sie Windows Explorer, suchen Sie die Ziel -.xel-Datei , und doppelklicken Sie darauf. Die Datei wird in einem anderen SSMS-Fenster geöffnet, das Sie zum Anzeigen und Analysieren verwenden können.

    • Erweitern Sie> in Objekt-Explorer "EventSessionName für erweiterte Ereignissitzungen>>verwalten", klicken Sie mit der rechten Maustaste auf package0.event_file, und wählen Sie dann "Zieldaten anzeigen" aus.

    • Suchen Sie den Speicherort der .xel-Dateien , und lesen Sie diese Datei mithilfe der Funktion sys.fn_xe_file_target_read_file.

  6. Vergleichen Sie die Field-Anweisung , indem Sie die folgenden Ereignisse überprüfen:

    • sp_statement_completed
    • sql_batch_completed
    • sql_statement_completed
    • rpc_completed

Weitere Informationen zu den identischen Abfragen finden Sie in den folgenden Beispielen:

  • Wenn die gespeicherten Prozeduren oder Funktionen unterschiedliche Parameterwerte aufweisen, können die Abfragezeiten unterschiedlich sein:

    • SpUserProc @p1 = 100

    • SpUserProc @p1 = 270

  • Die folgenden Abfragen unterscheiden sich. Die erste Abfrage verwendet die durchschnittliche Dichte aus dem Histogramm für die Kardinalitätsschätzung, während die zweite Abfrage den Histogrammschritt für die Kardinalitätsschätzung verwendet:

    • declare @variable1 = 123
select * from table where c1 = @variable1

    • select * from table where c1 = 123

Aus demselben Grund wie oben kann der Vergleich der Ausführung einer gespeicherten Prozedur mit der Ausführung der entsprechenden Ad-hoc-Abfrage (unter Verwendung lokaler Variablen) unterschiedlich sein. Identische Anweisungen müssen verglichen werden.

Schritt 2: Messen der Ausführungszeit auf dem Server

Für einen genauen Vergleich von Abfragedauern können Sie die Zeit der Netzwerklatenz oder anwendungsspezifische Datenverarbeitungszeit ausschließen. Verwenden Sie eine der folgenden Methoden, um nur die Ausführungszeit auf dem SQL Server zu messen:

  • Führen Sie Ihre Abfrage mit SET STATISTICS TIME aus:

    SET STATISTICS TIME ON
<YourQuery>
SET STATISTICS TIME OFF

  • Verwenden Sie XEvent aus Schritt 1 , um die Dauer oder verstrichene Zeit einer Abfrage zu untersuchen (Ereignisklasse SQL:StmtCompleted, SQL:BatchCompletedoder RPC:Completed).

In einigen Fällen kann der Zeitunterschied zwischen den Abfragen durch eine Anwendung verursacht werden, die in einem anderen Netzwerk oder in der Anwendung selbst ausgeführt wird. Wenn Sie die Ausführung auf dem Server vergleichen, vergleichen Sie, wie lange die Abfragen auf dem Server ausgeführt wurden.

Schritt 3: Überprüfen der SET-Optionen für jede Verbindung

Es gibt SET-Optionen , die sich auf den Abfrageplan auswirken, was bedeutet, dass sie die Auswahl des Abfrageplans ändern können. Wenn eine Datenbankanwendung daher unterschiedliche Satzoptionen von SSMS verwendet, kann jede Satzoption einen anderen Abfrageplan erhalten. Beispielsweise ARITHABORT, NUMERIC_ROUNDABORT, ROWCOUNT, FORCEPLAN und ANSI_NULLS. Der häufigste Unterschied zwischen SSMS- und .NET-Anwendungen ist die SET ARITHABORT-Option . Standardmäßig ist die Option in SSMS auf "EIN" festgelegt, in den meisten Datenbankanwendungen jedoch auf "AUS" festgelegt. Legen Sie basierend auf Ihren Anwendungsanforderungen ARITHABORT auf die gleiche Einstellung sowohl in SSMS als auch in der Anwendung für einen gültigen Vergleich zwischen den beiden fest.

Warnung

Die Standardeinstellung von ARITHABORT für SQL Server Management Studio ist ON. Wenn ARITHABORT für Clientanwendungen auf OFF festgelegt ist, können diese unterschiedliche Abfragepläne empfangen, was die Problembehandlung von Abfragen mit schlechter Leistung erschwert. Das heißt, dieselbe Abfrage kann schnell in Management Studio ausgeführt werden, aber langsam in der Anwendung. Gleichen Sie die ARITHABORT-Einstellung des Clients bei der Problembehandlung von Abfragen mit Management Studio immer ab.

Eine Liste aller Optionen, die sich auf den Plan auswirken, finden Sie unter "Festlegen von Optionen".

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass die SET-Optionen sowohl in SSMS als auch in der Anwendung identisch sind, um einen gültigen Vergleich ausführen zu können:

  1. Verwenden Sie die gesammelten Daten in Schritt 1.

  2. Vergleichen Sie die festgelegten Optionen, indem Sie die Ereignisse login und existing_connectioninsbesondere die options_text Spalten und Optionen überprüfen.