Problembehandlung bei die Leistung von Ad-hoc-Abfragen in SQL Server

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 243588 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Dieser Artikel beschreibt die langsame Leistung viele gleichzeitige Ad-hoc-Abfragen in Microsoft SQL Server zu beheben. Wenn Sie nicht die genaue Ursache des Problems ermittelt haben, finden Sie im folgenden Artikel in der Microsoft Knowledge Base vor, die weiterhin:
224587Behandlung der Anwendungsleistung mit SQL Server

Es wird vorausgesetzt, dass Sie zum Eingrenzen des Problems KB 224587 verwendet haben und Sie ein Windows NT-Systemmonitorprotokoll erfasst haben und SQL Profiler Ablaufverfolgungsdetails, bestimmten Spalten Leistungsindikatoren, Ereignisse und Daten.

Merkmale von die Leistungsprobleme

Das Leistungsproblem weist die folgenden Merkmale auf:
  • Kurze Ad-hoc-Abfragen aus, in der Regel eine sehr kurze Dauer aufweisen, entstehen langsam Gesamtleistung des Systems, wenn eine hohe Anzahl gleichzeitiger Benutzer die Abfragen ausgeführt.
  • Sehr hoch oder 100 Prozent CPU-Auslastung.
  • Keine zugeordnete blockiert während der Zeiträume langsam.

    Sie können schnell suchen, für das Blocken durch Überprüfen der BLK -Spalte in der Ausgabe der gespeicherten Systemprozedur Sp_who . Wenn die BLK -Spalte ungleich NULL für eine Reihe von Systemprozess-IDs (SPIDs) ist, wird es blockiert.
  • In einigen Situationen Serverspeicher Produktionsbelastung und Sie wird möglicherweise Fehler, die die folgenden Fehlermeldungen ähnlich sind:
    Fehler: 701, Schweregrad: 17, Status: 1
    Ist genügend Arbeitsspeicher zum Ausführen dieser Abfrage.
    -oder-
    Msg 8645, auf 17, Status 1, Prozedur, 1
    Timeout beim Warten auf die Arbeitsspeicherressourcen für die Abfrageausführung. Führen Sie die Abfrage erneut aus.

Verbesserungen bei der Abfrage Kompilierungen

Sie möglicherweise aufgrund von Verbesserungen in Systemarchitektur starten im SQL Server 7.0, insbesondere der Abfrageoptimierer einen Unterschied in Systemressourcenauslastung von Anwendungen im Vergleich zu früheren Versionen von SQL Server fest. Insbesondere SQL Server 7.0 kann einen Anstieg in CPU- oder Arbeitsspeicherverwendung Auslastung anzeigen, jedoch frühere Versionen von SQL Server sind in der Regel Datenträger e/a-gebunden. Diese Änderungen können auf zwei Faktoren zurückzuführen:
  • Hash- und Verknüpfungen
  • Abfrage Kompilierungszeiten
Frühere Versionen von SQL Server verlassen sich vollständig auf geschachtelte Schleifeniterationen Verknüpfungen durchführen. Nested Loops-Verknüpfungen verwenden grundsätzlich Datenträger e/A. Beginnend mit SQL Server 7.0, eingeführt wurden Hash- und Verknüpfungen. Hash- und Verknüpfungen werden wesentlich mehr im Speicher als nested Loops-Verknüpfungen verarbeitet. Das logische Ergebnis ist, CPU- und Speichernutzung ist höher, wenn diese Verknüpfung Techniken verwendet werden. Weitere Informationen über Hash- und Verknüpfungen finden Sie unter die Themen "Understanding Hash-Verknüpfungen" und "Understanding Zusammenführen Verknüpfungen" in der SQL Server 7.0-Onlinedokumentation.

Abfrage Kompilierungszeiten sind betroffen, da der Abfrageoptimierer mehr Optionen und Informationen verfügbar als in früheren Versionen von SQL Server, einschließlich neue Hash- und Merge Join Techniken, verbesserte Suchalgorithmen und Spaltenstatistiken verfügt. Diese zusätzlichen Informationen ermöglicht den Abfrageoptimierer die effizienteste Methode zum Abrufen der Abfragedaten auswählen. Allerdings ist die Analyse und die Berücksichtigung dieser neue Techniken und Informationen Verarbeitungszeit erforderlich. Diese erhöhte CPU-Auslastung möglicherweise Kompilierungszeiten Abfrage, die länger als in früheren Versionen von SQL Server sind.

Für die meisten Abfragen ist dieser Anstieg der Kompilierzeit durch eine Abnahme der Ausführungszeit versetzt. Der allgemeine Effekt ist, dass die Abfrage schneller als in ausgeführt frühere Versionen von SQL Server. Eine Ausnahme tritt jedoch bei sehr kleine, einfach und OLTP-Typ Abfragen, die sehr niedrig Ausführungszeiten. Für diese Abfragen möglicherweise bei der Abfrage-Plan erzeugen eine Ausgabe gleich oder größere als die Ausführung der Abfrage. Als Ergebnis Ausführen der Abfrage etwas langsamer als in früheren Versionen von SQL Server. Da sich der Unterschied besteht i. d. r. in Millisekunden, werden diese Effekte für eine bestimmte Abfrage nicht bemerkt, wenn er einzeln ausgeführt wird. Jedoch können Sie feststellen, dass Gesamtsystem CPU-Auslastung höher als in früheren Versionen von SQL Server ist, wenn große Anzahl von Ad-hoc-Abfragen gleichzeitig eine hohe Anzahl von Benutzern ausgeführt werden.

Entwickeln Sie parametrisierte Abfragen

SQL Server 7.0 verwendet einige neue Verfahren, z. B. das Zwischenspeichern von Ad-hoc-Abfragen und automatische Parametrisierung. Allerdings die Abfragen, SQL Server 7.0 automatisch parameterizes sind begrenzt. Verwenden Sie die folgenden Methoden, um sicherzustellen, dass die Abfragepläne parametrisierte werden und effektiver wiederverwendet werden können:
  • Parametermarkierungen Sowohl der OLE DB und ODBC-APIs ermöglichen Parameter, die mit einem Fragezeichen angegeben werden, wenn Benutzer Abfragen absenden. Dies kann in jeder Anwendung, insbesondere für Anwendungen mittlerer Ebene sehr hilfreich sein, die Abfrage Generation Module verfügen, in denen mithilfe von gespeicherten Prozeduren nicht verfügbar ist. Abfrage-Plan, der für Abfragen generiert wird, die Parametermarkierungen kann von allen Clients, die die gleiche Abfrage ausführen wiederverwendet werden, selbst wenn andere Parameterwerte angegeben werden. Weitere Informationen finden Sie "Parametermarkierungen" in SQL Server 7.0-Onlinedokumentation Online.
  • sp_executesql Sp_executesql gespeicherten Prozedur wird von der OLE DB-Provider oder ODBC-Treiber aufgerufen, wenn Parametermarkierungen in einer Anwendung verwendet werden. Allerdings kann es auch direkt von der Anwendung oder in einer anderen gespeicherten Prozedur, die explizit Ad-hoc-Abfragen parametrisieren aufgerufen werden. Dies kann in Anwendungen oder Batchdateien, in denen die EXECUTE-Anweisung zum Ausführen von dynamischer SQL-Anweisungen verwendet wird, sehr nützlich sein. Im Gegensatz zu Sp_executesql lässt die EXECUTE-Anweisung nicht Parametrisierung. Dies schränkt die Wahrscheinlichkeit eines Wiederverwendung der Abfrage-Plan. Weitere Informationen finden Sie im "Sp_executesql (T-SQL)" und ? Verwenden von Sp_executesql ? Themen in SQL Server 7.0-Onlinedokumentation.
  • gespeicherte Prozeduren Gespeicherte Prozeduren haben viele Vorteile, einschließlich der Möglichkeit zum Parametrisieren von Abfragen und Ausführungspläne wiederverwenden. Weitere Informationen finden Sie die Themen "Stored Procedures" und "Programming Stored Procedures" in der SQL Server 7.0-Onlinedokumentation.

Die Systemmonitor-Daten anzeigen

Mithilfe des Systemmonitorprotokolls feststellen, welche Systemressourcen den Engpass verursacht werden. Das Systemmonitorprotokoll kann Ihnen ein Gesamtbild des Systems und helfen, Ihre Aufmerksamkeit konzentrieren, wenn Sie SQL Profiler-Daten anzeigen. Überprüfen Sie die Systemmonitor-Daten von der Zeit beim Leistung gut über die Zeit war, die Leistung verringert. Bestimmen Sie den Zähler, der zuerst betroffen war, und anschließend ermitteln Sie die folgenden Probleme auf Ihre Situation relevanten:
  • Objekt: Prozess
    Leistungsindikator: Prozessor
    Instanz: SQL Server
  • Objekt: Prozessor
    Leistungsindikator: Prozessorzeit %
    Instanz: Jede Prozessorinstanz überprüfen
  • Objekt: SQL Server: Puffer-Manager
    Leistungsindikator: Freie Puffer
  • Objekt: SQL Server: Puffer-Manager
    Leistungsindikator: Gestohlen Seitenzahl
  • Objekt: SQL Server: Speicher-Manager
    Leistungsindikator: Arbeitsspeicher ausstehende gewährt
  • Objekt: SQL Server: SQL-Statistik
    Leistungsindikator: SQL Kompilierungen/Sekunde
Wenn die CPU-Auslastung, SQL-Kompilierungen/Sekunde und freien Puffer sind hoch, Speicher erteilen aus und Seitenzahl gestohlen Leistungsindikatoren Leistungsindikatoren sind niedriger, gibt dies an, dass die CPU der Engpass. Wie effektiv parametrisieren und Wiederverwenden von Abfrageplänen, damit die Kosten eines Abfrageplanes konzentrieren, und den Abschnitt "Gruppieren SQL Profiler-Ablaufverfolgung nach Ereignisklasse" dieses Artikels sehen. Wenn der freie Puffer und SQL-Kompilierungen/Sekunde Leistungsindikatoren niedrig sind und die Seitenzahl gestohlen und Speicher gewährt aus Leistungsindikatoren hoch sind, ist SQL Server Arbeitsspeicher eingeschränkt. Suchen der Abfragen, in denen Hashverknüpfungen werden verwendet, und Schleife Verknüpfungen, und finden Sie unter "Nach der Dauer SQL Profiler verfolgen Group" geändert werden können, konzentrieren Abschnitt dieses Artikels. Weitere Informationen zu diesen Leistungsindikatoren verwenden Sie den Leistungsindikatornamen der SQL Server 7.0-Onlinedokumentation suchen.

Anzeigen der SQL Profiler-Daten

Beim Auflösen von Leistungsproblemen ist es überaus wichtig, SQL Profiler-Daten anzuzeigen. Sie müssen nicht alle Daten überprüfen, die Sie erfasst, selektive werden. SQL Profiler können Sie die erfassten Daten effektiv anzeigen. Auf der Registerkarte Eigenschaften (klicken Sie im Menü Datei auf Eigenschaften ), SQL Profiler ermöglicht Ihnen, die Daten beschränken, die durch Entfernen von Datenspalten oder Ereignissen, Gruppierung oder Sortierung nach Spalten und Anwenden von Filtern angezeigt wird. Sie können die gesamte Ablaufverfolgung oder nur eine spezielle Spalte nach speziellen Werten durchsuchen (klicken Sie im Menü Bearbeiten auf Suchen ). Sie können auch die SQL Profiler-Daten in einer SQL Server-Tabelle speichern (im Menü Datei auf Speichern unter zeigen und klicken Sie dann auf Ablaufverfolgungstabelle ), und führen Sie SQL-Abfragen für Sie.

Hinweis: Stellen Sie sicher, dass Sie nur eine gespeicherten Ablaufverfolgungsdatei filtern. Wenn Sie diese Schritte auf eine aktive Ablaufverfolgung riskieren Sie Verlust von Daten, die seit dem Start die Ablaufverfolgung erfasst wurde. Speichern Sie eine aktive Ablaufverfolgung in einer Datei oder Tabelle zuerst (klicken Sie im Menü Datei auf Speichern unter ), und öffnen Sie ihn erneut (klicken Sie im Menü Datei auf Öffnen ) bevor Sie fortfahren. Wenn Sie mit einer gespeicherten Ablaufverfolgungsdatei arbeiten, die Filterung wird nicht dauerhaft entfernt die Daten, die Daten nur ausgeblendet, nicht gelöscht. Sie können hinzufügen und Entfernen Ereignisse und Datenspalten zu Fokus Ihre Suchvorgänge.

Sie sollten auch auf die Bereiche konzentrieren, dass Sie die meisten Vorteile erhalten. Die folgenden Faktoren können Anwendungsleistung erhöht werden jedoch nicht unbedingt auf den gleichen Grad. Bevor Sie Änderungen implementieren, bestimmen Sie, je wie effektiv die Änderungen auf folgenden Faktoren nach werden können:
  • Wie oft die Abfrage ausgeführt wird
  • Wie viel Verbesserung die Abfrage verbessert werden kann
Ist z. B. möglicherweise verkleinern die Ausführungszeit einer einzelnen Abfrage von 1,5 Sekunden zu 1,2 Sekunden nicht hilfreich, wenn die Abfrage häufig im Laufe des Tages nicht ausgeführt wird. Wenn die Abfrage sehr häufig durch eine hohe Anzahl von gleichzeitigen Benutzern ausgeführt wird, kann die Leistungsverbesserung der jedoch sehr effektiv sein. Umgekehrt kann Erhöhung einer einzelnen Abfrage von 6 Minuten 3 Sekunden nicht führen einen deutlichen Anstieg der Gesamtleistung, wenn es selten verwendet wird. Verwenden Sie die Gruppierung und Filterung der Verfahren in SQL Profiler und Ihre Kenntnisse über die Anwendung, um die Auswirkungen der eine bestimmte Abfrage oder eine Prozedur zu schätzen, bevor Sie Änderungen implementieren. Am effektivsten Änderungen zuerst konzentrieren und fahren mit Iterationen über andere Abfragen und Prozeduren, bis zu eine Ebene, in denen Leistung ausreichend verbessert hat.

Nachdem Sie eine SQL Profiler-Ablaufverfolgung in einer Datei oder Tabelle speichern, öffnen Sie die Ablaufverfolgung in SQL Profiler erneut und überprüfen Sie den Inhalt. Gehen Sie folgendermaßen vor um SQL Profiler-Ablaufverfolgung zu gruppieren:
  • Gruppieren Sie SQL Profiler-Ablaufverfolgung nach Dauer:
    1. Klicken Sie im Menü Datei auf Eigenschaften .
    2. Klicken Sie auf die Registerkarte Datenspalten , und klicken Sie dann unter Gruppen auf, auf Dauer zu verschieben. Klicken Sie auf nach unten alle Spalten entfernen möchten.
    3. Klicken Sie auf die Registerkarte Ereignisse , und entfernen Sie alle Ereignisse außer TSQL-SQL:StmtCompleted und TSQL-RPC: Completed . Dadurch können Sie nur die Abfragen konzentrieren, die ausgeführt werden.
    4. Klicken Sie auf OK .
    Gruppieren nach Dauer ermöglicht, leicht erkennen, die SQL-Anweisungen, Batches und Prozeduren, die die langsamsten ausgeführt werden. Überprüfen Sie die Ablaufverfolgung, wenn das Problem auftritt, und Erstellen eines Basisplans gute Leistung. Sie können nach der Startzeit die Ablaufverfolgung in Abschnitte aufheben, wenn die Leistung bei schlechter Leistung gut und separate Abschnitte ist filtern. Suchen Sie die Abfragen mit der längsten Dauer bei Leistung gut ist. Diese sind wahrscheinlich die Ursache des Problems. Wenn die Leistung des Gesamtsystems sinkt können selbst gute Abfragen langen Dauer anzeigen, da diese Systemressourcen warten.

    Überprüfen Sie die Ausführungspläne für Abfragen, dass die meisten häufig lange Dauer haben. Wenn Sie sehen, dass eine Hashverknüpfung verwendet wird, sollten Sie verwenden die Abfrage LOOP JOIN eine nested Loops-Verknüpfung für die Abfrage zu erzwingen. Wenn die Ausführungszeit für die Abfrage mit einer Schleife Verknüpfung kleiner als, gleich oder sogar etwas höher als die Ausführungszeit mit der Hashverknüpfung ist, kann eine Schleife Verknüpfung eine bessere Option sein, wenn der Computer hohen Speicher- und CPU-Auslastung vorliegt. Durch verringern die Belastung Ressourcenengpass (CPU und Arbeitsspeicher), können Sie die Systemleistung verbessern. Für Weitere Informationen über die LOOP-Verknüpfung Hinweis abzufragen, finden Sie in der SQL Server 7.0-Onlinedokumentation unter "SELECT (T-SQL)".
  • Gruppieren Sie SQL Profiler-Ablaufverfolgung nach Ereignisklasse:
    1. Klicken Sie im Menü Datei auf Eigenschaften .
    2. Klicken Sie auf die Registerkarte Datenspalten , und klicken Sie dann unter der Überschrift Gruppen auf nach Ereignisklasse und Text mit Ereignisklasse auf oben zu verschieben. Klicken Sie auf nach unten um alle Spalten unter der Überschrift Gruppen zu entfernen.
    3. Klicken Sie auf die Registerkarte Ereignisse , und stellen Sie dann sicher, dass alle Ereignisse enthalten sind.
    4. Klicken Sie auf OK .

Arten von Ereignissen

Um festzustellen welche Arten von Ereignissen auftreten auf dem Computer mit SQL Server und wie häufig die Ereignisse eintreten, Gruppieren nach Spalte Ereignisklasse . Suchen Sie in dieser Spalte für die folgenden Ereignisse:
  • MISC: Vorbereiten von SQL und Exec Prepared SQL; CURSORS: Cursorprepare Ein Ereignis Prepare SQL zeigt an, dass eine SQL-Anweisung für die Verwendung mit ein Standardresultset (clientseitige Cursor) mit SQLPrepare/SQLExecute (für ODBC) oder ICommandText::Prepare/ICommandText::Execute (für OLE DB) mit die Standardcursoroptionen vorbereitet wurde: Vorwärts, schreibgeschützt nur Rowsetgröße = 1. Ein Cursorprepare -Ereignis zeigt an, dass ein serverseitiger Cursor auf eine SQL vorbereitet wurde-Anweisung mit SQLPrepare/SQLExecute (für ODBC) oder ICommandText::Prepare/ICommandText::Execute (für OLE DB) mit der vorherigen Cursoroptionen auf einen nicht standardmäßigen Wert festgelegt. Ein Exec Prepared SQL -Ereignis gibt an, dass eines der vorhandenen vorbereitete Anweisungen vorherigen Dateitypen ausgeführt wurde. Wenn Sie häufige Vorkommen dieser Ereignisse finden Ihrer Anwendung verwendet das Vorbereiten/Ausführen-Modell beim Öffnen Ergebnis setzt. Wenn dies der Fall ist, müssen Sie festlegen Wenn Sie das Vorbereiten/Ausführen-Modell ordnungsgemäß verwenden.

    Im Idealfall wird eine Anwendung eine SQL-Anweisung einmal vorbereiten und führt es oft, so dass der Abfrageoptimierer keinen neuen Plan jedes Mal kompiliert die Anweisung ausgeführt wird. Bei jedem eine vorbereitete Anweisung ausführen speichern Sie die Kosten der Abfrage-Kompilierung. Falls Sie eine Abfrage einmal ausführen möchten, empfiehlt es sich, dass Sie es nicht vorbereiten. Vorbereiten und dann Ausführen einer SQL-Anweisung erfordert drei Roundtrips Netzwerk: um die Anweisung, eine zum Ausführen der Anweisung und eine unprepare die Anweisung vorzubereiten. Vorbereiten von serverseitigen Cursorn benötigt mindestens fünf Roundtrips: eine zum Vorbereiten der Cursor, um ausführen oder öffnen Sie es, mindestens eine zum Abrufen aus, um es zu schließen und um es unprepare. Ausführen der Abfrage erfordert nur einen Roundtrip.

    Um anzuzeigen, wie effektiv die Anwendung das Vorbereiten/Ausführen-Modell verwendet, Vergleichen der Anzahl der diese beiden Ereignisse (prepare and execute) auftreten. Die Anzahl der Exec Prepared SQL -Ereignisse sollte wesentlich größer als die Summe der Prepare SQL und CursorPrepare Ereignisse (mindestens drei, fünf Mal größer ist eine gute Schätzung) sein. Dies bedeutet, dass vorbereitete Anweisungen häufig zur Überwindung der erhöhte wiederverwendet werden Aufwand erstellen. Wenn die Anzahl der Prepare SQL und CursorPrepare Ereignisse etwa die Anzahl der Exec Prepared SQL Ereignisse entspricht, kann dies bedeuten, dass die Anwendung das Vorbereiten/Ausführen-Modell nicht effektiv verwendet wird. Versuchen Sie, eine Anweisung einmal vorbereiten und so weit wie möglich wiederverwenden. Sie können auch Ihre Anwendung Anweisungen einmal vorbereiten und verwenden diese Anweisungen ändern.

    Die Anwendung muss insbesondere effiziente Verwendung das Vorbereiten/Ausführen-Modell geschrieben werden. Die Lebensdauer des ein Handle für eine vorbereitete Anweisung wird von wie lange Sie die HSTMT offene ODBC oder die ICommandText-Objekt in OLE DB beibehalten gesteuert. Eine gängige Regel besteht eine HSTMT erhalten, Vorbereiten einer SQL-Anweisung, die vorbereitete Anweisung auszuführen und die HSTMT, verlieren und somit das Handle auf den vorbereiteten Plan dann frei. Wenn Sie dies tun, erhalten Sie keine Vorteile aus dem Vorbereiten/Ausführen-Modell. Tatsächlich sehen Sie möglicherweise ein Leistungsabfall wegen der zusätzlichen Aufwand der Netzwerkroundtrips. Die Anwendung muss eine Methode, um das HSTMT oder das Objekt mit dem Handle vorbereitete Anweisung cache und darauf zugreifen, für die Wiederverwendung verfügen. Der Treiber oder Provider führt keine dieser automatisch; die Anwendung ist für das Implementieren, Verwalten und mithilfe dieser Informationen verantwortlich. Wenn die Anwendung dies nicht möglich, sollten Sie Parametermarkierungen anstelle der Prepare/execute-Methode verwenden.
  • mithilfe von Parametermarkierungen Anwendungen können Parametermarkierungen verwenden, um die gleichen Transact-SQL-Anweisung mehrmals mit unterschiedlichen Eingabe- und Ausgabewerte zu optimieren. Beim ersten eine Abfrage ausgeführt wird, wird Sie als eine parametrisierte Abfrage vorbereitet und SQL Server generiert und speichert einen parametrisierten Plan für die Abfrage. Für nachfolgende Aufrufe an die gleiche Abfrage mit der gleichen oder verschiedene Parameter besitzt SQL Server keinen neuen Abfrageplan generiert; SQL Server können vorhandene Abfrageplan wiederverwenden, indem der aktuellen Parameter ersetzen.

    Wenn die Anwendung Parametermarkierungen mit Aufrufen von SQLExecDirect (für ODBC) oder ICommandText::Execute (für OLE DB) verwendet, werden der Treiber oder Provider automatisch Pakete die SQL-Anweisung, und Sie als Sp_executesql -Aufruf ausgeführt. Die Anweisung hat keinen vorbereitet und separat ausgeführt werden. Wenn SQL Server einen Aufruf von Sp_executesql empfängt, es automatisch überprüft den Prozedurcache für einen entsprechenden Plan und verwendet diesen Plan oder generiert einen neuen Plan.

    Bestimmen, wenn Ihre Anwendung derzeit Parametermarkierungen verwendet, können Sie die Spalte Text in der SQL Profiler-Ablaufverfolgung für "Sp_executesql." Durchsuchen Jedoch da Sp_executesql direkt aufgerufen werden kann, Hinweisen nicht alle Instanzen, die Verwendung von Parametermarkierungen.

    Weitere Informationen über das Vorbereiten/Ausführen-Modell finden Sie "Ausführung planen Zwischenspeicherung und Wiederverwendung" in der SQL Server 7.0-Onlinedokumentation. Weitere Informationen zu Parametermarkierungen finden Sie "Parametermarkierungen" in der SQL Server 7.0-Onlinedokumentation.
  • SP: Completed Dynamische SQL-Anweisungen mit der EXECUTE-Befehl ausgeführt angezeigt als ein SP: abgeschlossen Ereignis mit dem Text "Dynamisches SQL". Erweitern Sie die SP: abgeschlossen Ereignis- und suchen Sie anschließend für alle Instanzen, die "Dynamisches SQL" als Text. Wenn viele dieser Ereignisse sind, können Sie Verbessern der Anwendungsleistung durch Verwenden von Sp_executesql anstelle der EXECUTE-Anweisung möglicherweise. Sp_executesql gespeicherten Prozedur ermöglicht SQL Server die Ausführungspläne wiederverwenden, wenn dieselbe Abfrage erneut mit andere Parametern ausgeführt wird. Wenn Sie die EXECUTE-Anweisung verwenden, der Plan ist nicht parametrisiert, und wird nicht wiederverwendet, wenn die Abfrage erneut mit den gleichen Parametern ausgeführt wird.

    Ermitteln der Abfragen oder Prozeduren, die dynamische SQL-Ereignisse mit der EXECUTE-Anweisung, Beachten Sie den Verbindungs-ID und Startzeit der für jedes Ereignis. Aufheben die Ablaufverfolgung (entfernen Ereignisklasse und Text aus der Überschrift Gruppen ). Nachdem Sie die Ablaufverfolgung Gruppierung aufheben, wird es in chronologischer Reihenfolge sortiert. Können die Ablaufverfolgung von Verbindungs-ID (auf der Registerkarte Filter ) filtern und entfernen Sie alle Ereignisklassen außer der SP: Starten und SP: vollständige Ereignisse für verbesserte Lesbarkeit. Sie können dann nach der Startzeit des Ereignisses suchen (klicken Sie im Menü Bearbeiten auf Suchen ). Die Ergebnisse anzeigen, wenn das dynamische SQL-Ereignis begonnen hat. Wenn das Ereignis in einer gespeicherten Prozedur aufgetreten ist, das Ereignis wird angezeigt, zwischen der SP: Starten und SP: abgeschlossen Ereignisse für die Prozedur. Wenn das Ereignis nicht in einer gespeicherten Prozedur auftraten, wurde es als Ad-hoc-Abfrage ausgeführt und können Sie anderen Datenspalten ( Anwendungsname , NT­Benutzername und andere) ermitteln, wo der Befehl ausgeführt wurde. Um zu bestimmen den Text des Befehls und der Kontext, in dem es ausgeführt wurde, können Sie auch Ereignis-Klassen, z. B. SQL: BatchCompleted und SQL:RPCCompleted hinzufügen.

    Nachdem Sie ermittelt, wo die EXECUTE-Anweisung verwendet wird, erwägen Sie es mit einem Aufruf von Sp_executesql zu ersetzen. Betrachten Sie z. B. das folgende Szenario, in denen die EXECUTE Befehl mit dynamischem SQL verwendet wird. Eine Prozedur wird ein Tabellenname, ID und IdValue als Eingabeparameter und anschließend eine SELECT-Anweisung aus der Tabelle auf der Grundlage des ID-Wertes ausgeführt. Eine EXECUTE-Anweisung die Prozedur ähnelt dem folgenden Code:
    drop proc dynamicUsingEXECUTE
    		  go create proc dynamicUsingEXECUTE @table sysname, @idName varchar(10),
    		  @idValue varchar(10) as declare @query nvarchar(4000) -- Build query string
    		  with parameter. -- Notice the use of escape quotes. select @query = 'select *
    		  from ' + @table + ' where ' + @idName + ' = ''' + @idValue + '''' exec (@query)
    		  go
    vorausgesetzt, dass die Abfrage nicht automatisch parametrisiert wird, wenn Sie diese Prozedur auf die Titles -Tabelle in der Pubs -Beispieldatenbank zweimal mit unterschiedlichen Werten für die @ IdValue ausführen SQL Server-Parameter muss einen separaten Abfrageplan für jede Ausführung generieren. Zum Beispiel:
    exec dynamicUsingEXECUTE
    		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    		  'title_id', 'BU7832'
    Hinweis in diesem Beispiel wird die Abfrage ist einfach, dass SQL Server automatisch Sie parametrisieren und tatsächlich den Ausführungsplan wiederverwenden können. Jedoch, wenn dies eine komplexe Abfrage, die SQL Server nicht automatisch parametrisieren kann war, SQL Server kann nicht wiederverwendet den Plan für die zweite Ausführung Wenn @ IdValue Parameter geändert wurde. Die folgende einfache Abfrage beschränkt die Komplexität der im Beispiel.

    Sie können diese Prozedur Sp_executesql anstelle der EXECUTE-Anweisung verwenden schreiben. Unterstützung für die Parameterersetzung macht Sp_executesql effizienter, da es Ausführungspläne generiert, die eher von SQL Server wiederverwendet werden. Beispielsweise:
    drop proc dynamicUsingSP_EXECUTESQL go create proc
    		  dynamicUsingSP_EXECUTESQL @table sysname, @idName varchar(10), @idValue
    		  varchar(10) as declare @query nvarchar(4000) -- Build query string with
    		  parameter select @query = 'select * from ' + @table + ' where ' + @idName + ' =
    		  @idValue' -- Now execute with parameter exec sp_executesql @query, N'@idValue
    		  varchar(10)', @idValue go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'MC2222' go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'BU7832'
    in diesem Beispiel wird das erste Mal, der die Sp_executesql -Anweisung ausgeführt wird, erzeugt SQL Server einen parametrisierten Plan für die SELECT-Anweisung von Titeln mit Title_id als Parameter. Für die zweite Ausführung verwendet SQL Server den Plan mit dem neuen Parameterwert. Weitere Informationen über Sp_executesql finden Sie in die "Sp_executesql (T-SQL)" und ? Verwenden von Sp_executesql ? Themen in SQL Server 7.0-Onlinedokumentation.
  • SP:RECOMPILES Dieses Ereignis zeigt an, dass eine gespeicherte Prozedur während der Ausführung neu kompiliert wurde. Viele kompilieren Ereignisse gibt an, dass SQL Server Ressourcen für die Kompilierung Abfrage anstelle der Ausführung der Abfrage verwendet.
Wenn Sie nicht diese Ereignisse sehen, wird die Anwendung nur Ad-hoc-Abfragen in SQL Server ausgeführt. Sofern SQL Server ermittelt, dass automatisch bestimmte Abfragen parametrisieren können oder wenn die gleichen Parameter wiederholt verwendet werden, erfordert jede Abfrage, die ausgeführt wird, SQL Server, um einen neuen Ausführungsplan zu generieren. Viele SQL-Kompilierungen/Sekunde sollte SQL Server-Systemmonitor angezeigt werden. Dies kann die CPU-intensiv sein für viele gleichzeitige Benutzer. Um dieses Problem zu umgehen, suchen Sie am häufigsten Abfragen häufig ausgeführt, und erstellen Sie gespeicherte Prozeduren für diese Abfragen mithilfe von Parametermarkierungen oder mithilfe von Sp_executesql .

Informationsquellen

Weitere Informationen über die Überwachung und Problembehandlung bei Leistungsproblemen in SQL Server finden Sie in den folgenden Artikeln der Microsoft Knowledge Base:
224587Behandlung der Anwendungsleistung mit SQL Server
224453INF: Verstehen und Lösen von SQL Server 7.0 oder 2000-Blockierungen
243586Problembehandlung bei der Neukompilierung von gespeicherten Prozedur
243589Problembehandlung bei langsame Ausführung von Abfragen auf SQL Server 7.0 oder höher
251004INF: Überwachen von SQL Server 7.0-Blockierungen

Eigenschaften

Artikel-ID: 243588 - Geändert am: Donnerstag, 8. Dezember 2005 - Version: 5.4
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-Bit Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Keywords: 
kbmt kbhowtomaster kbhowto kbinfo KB243588 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 243588
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com