Mit Microsoft anmelden
Melden Sie sich an, oder erstellen Sie ein Konto.
Hallo,
Wählen Sie ein anderes Konto aus.
Sie haben mehrere Konten.
Wählen Sie das Konto aus, mit dem Sie sich anmelden möchten.

Zusammenfassung

Dieser Artikel beschreibt die Behandlung von langsam viele gleichzeitige Ad-hoc-Abfragen in Microsoft SQL Server. Wenn Sie nicht die genaue Ursache des Problems ermittelt haben, finden Sie in folgendem Artikel der Microsoft Knowledge Base, bevor Sie fortfahren:

224587 Behandlung von Anwendungsperformance mit SQL Server


In diesem Artikel wird davon ausgegangen, dass Sie KB 224587 verwendet haben, um das Problem einzugrenzen und ein Windows NT-Systemmonitorprotokoll erfasst haben und SQL Profiler dem Detail verfolgen bestimmten Leistungsindikatoren, Ereignisse und Datenspalten.

Merkmale von Performance-Problemen

Das Leistungsproblem weist folgende Merkmale auf:

  • Kurze Ad-hoc-Abfragen, die in der Regel eine sehr kurze Dauer führen langsamen Systemleistung bei eine hohe Anzahl gleichzeitiger Benutzer Abfragen.

  • Sehr hohe oder 100 Prozent CPU-Auslastung.

  • Keine zugeordneten Sperrung Zeiten langsam.

    Sie finden schnell anhand der Spalte BLK in der Ausgabe der gespeicherten Systemprozedur Sp_who blockieren. Wenn Spalte BLK ungleich NULL für eine Anzahl von Systemprozess-IDs (SPIDs) ist, wird es blockiert.

  • In einigen Situationen Serverspeicher betont und möglicherweise Fehler wie die folgenden Fehler:

    Fehler: 701, Schweregrad: 17, Status: 1
    Es ist nicht genügend Arbeitsspeicher zum Ausführen dieser Abfrage.

    – oder –

    Msg 8645, Ebene 17, Status 1, Prozedur Zeile 1
    Timeout beim Warten auf Speicherressourcen verfügbar, um die Abfrage auszuführen. Führen Sie die Abfrage erneut aus.

Verbesserung der Abfrage Kompilierungen

Durch Verbesserung der Systemarchitektur ab SQL Server 7.0, insbesondere der Abfrageoptimierer bemerken Sie Unterschiede in der Verwendung der Systemressourcen durch Programme im Vergleich zu früheren Versionen von SQL Server. Insbesondere SQL Server 7.0 kann zeigen eine CPU oder Arbeitsspeicher Verwendung jedoch frühere Versionen von SQL Server sind in der Regel Datenträger-e/a gebunden. Diese Änderung können auf zwei Faktoren zurückzuführen:

  • Hash- und Mergeverknüpfungen

  • Abfrage Kompilierungszeiten

Frühere Versionen von SQL Server verlassen vollständig auf geschachtelte Schleife Wiederholungen für Joins. Nested Loops Joins verwenden grundsätzlich Datenträger-e/a. Ab SQL Server 7.0 wurden Hash- und Mergeverknüpfungen. Hash- und Mergeverknüpfungen werden mehr im Speicher zur Verarbeitung als nested Loops Joins. Das logische Ergebnis CPU und Speicher höher Wenn diese Verknüpfung Techniken verwendet werden. Weitere Informationen über Hash- und Mergeverknüpfungen finden Sie unter "Grundlegendes zu Hashverknüpfungen" und "Grundlegendes zu Mergeverknüpfungen" in der Onlinedokumentation zu SQL Server 7.0.

Abfrage Kompilierungszeiten sind betroffen, da der Abfrageoptimierer mehr Optionen und Informationen als in früheren Versionen von SQL Server, einschließlich Hash- und Merge Join neue, verbesserte Suchalgorithmen und Spaltenstatistiken hat. Diese zusätzlichen Informationen kann den Abfrageoptimierer die effizienteste Methode zum Abrufen der Daten auswählen. Die Analyse und diese neue Techniken und Informationen jedoch Verarbeitungszeit. Diese erhöhte CPU-Auslastung möglicherweise Kompilierungszeiten Abfrage, die länger als in früheren Versionen von SQL Server.

Dieser Anstieg der Kompilierung ist für die meisten Abfragen Rückgang Ausführungszeit versetzt. Insgesamt bewirkt, dass die Abfrage als schneller frühere Versionen von SQL Server. Eine Ausnahme tritt jedoch bei sehr kleine, einfache OLTP-Abfragen, die sehr niedrig Ausführungszeiten. Für diese Abfragen möglicherweise generieren einen Abfrageplan Aufwand gleich oder größer als die Ausführung der Abfrage. Daher Ausführen der Abfrage etwas langsamer als in früheren Versionen von SQL Server. Ist der Unterschied in der Regel in Millisekunden, werden diese Effekte für eine bestimmte Abfrage nicht bemerkt, wenn einzeln ausgeführt. Sie bemerken, dass die gesamten CPU-Auslastung ist höher als in früheren Versionen von SQL Server viele Ad-hoc-Abfragen durch eine hohe Anzahl von Benutzern gleichzeitig ausgeführt werden.

Entwickeln Sie parametrisierte Abfragen

SQL Server 7.0 verwendet verschiedene neue Techniken wie Ad-hoc-Abfragen und automatische Parametrisierung Zwischenspeichern. Abfragen, die SQL Server 7.0 automatisch parametrisiert sind jedoch beschränkt. Verwenden Sie die folgenden Methoden, um sicherzustellen, dass die Abfragepläne parametrisiert werden und effektiver wiederverwendet werden können:

  • Parametermarker OLE DB und ODBC-APIs ermöglichen Parameter mit einem Fragezeichen angegeben werden, wenn Benutzer Abfragen absenden. Dies kann in jeder Anwendung, insbesondere für Middle-Tier-Anwendung sehr nützlich sein, die Abfrage Generation Module mithilfe von gespeicherten Prozeduren nicht verfügbar ist. Abfrageplan für Abfragen generiert wird, die Parameter Marker kann von allen Clients, die die gleiche Abfrage wiederverwendet, selbst wenn andere Parameterwerte angegeben werden. Weitere Informationen finden Sie unter "Parametermarker" in SQL Server 7.0-Onlinedokumentation.

  • sp_executesql Sp_executesql gespeicherten Prozedur ist der OLE DB-Provider oder ODBC-Treiber aufgerufen, wenn Parametermarker in einer Anwendung verwendet werden. Allerdings kann es auch direkt von der Anwendung oder einer anderen gespeicherten Prozedur explizit Ad-hoc-Abfragen parametrisieren aufgerufen werden. Dies ist sehr nützlich in Applications oder Batch-Dateien, in denen die EXECUTE-Anweisung mit dynamische SQL-Anweisungen ausgeführt. Im Gegensatz zu Sp_executesqlerlaubt die EXECUTE-Anweisung keine Parametrisierung. Dadurch wird die Möglichkeit der Wiederverwendung. Weitere Informationen finden Sie unter "Sp_executesql (T-SQL)" und "Verwenden von Sp_executesql" Themen in der Onlinedokumentation zu SQL Server 7.0.

  • Gespeicherte Prozeduren Gespeicherte Prozeduren bieten viele Vorteile, einschließlich der Möglichkeit, Abfragen parametrisieren und Wiederverwendung von Ausführungsplänen. Weitere Informationen finden Sie in der Onlinedokumentation zu SQL Server 7.0 "Stored Procedures" und "Stored Procedures Programming".

Die Systemmonitor-Daten anzeigen

Verwenden des Systemmonitorprotokolls fest, welche Ressourcen den Engpass verursachen. Das Systemmonitorprotokoll kann Ihnen einen allgemeinen Überblick über das System und unterstützen Ihre Aufmerksamkeit bei der Anzeige von SQL Profiler-Daten. Überprüfen Sie die Systemmonitordaten von Leistung durch die Zeit war, die Leistung verringert. Bestimmen des Zählers, der zuerst auftrat, und ermitteln Sie Folgendes am erforderlich ist:

  • Objekt: Prozess
    Indikator: Prozessor
    Instanz: SQL Server-

  • Objekt: Prozessor
    Indikator: % Prozessorzeit
    Instanz: Überprüfen Sie jede Prozessorinstanz

  • Objekt: SQL Server: Puffer-Manager
    Indikator: Freie Puffer

  • Objekt: SQL Server: Puffer-Manager
    Indikator: Zähler für gestohlene Seiten

  • Objekt: SQL Server: Speicher-Manager
    Indikator: Speicher gewährt ausstehend

  • Objekt: SQL Server: SQL-Statistiken
    Indikator: SQL-Kompilierungen/Sekunde

Wenn die CPU-Auslastung, SQL-Kompilierungen/Sekunde und freie Puffer Leistungsindikatoren hoch sind Speicher gewährt ausstehenden und Seitenzahl gestohlen Leistungsindikatoren niedrig sind, bedeutet dies, dass die CPU der Engpass ist. Wie effektiv parametrisieren und Wiederverwendung von Abfrageplänen Kosten von Abfrageplänen zu konzentrieren Sie, und finden Sie im Abschnitt "Ereignisklasse SQL Profiler Trace gruppieren" dieses Artikels. Freie Puffer und SQL-Kompilierungen/Sekunde Leistungsindikatoren gering sind und die Seitenanzahl gestohlen und Speicher gewährt ausstehende Leistungsindikatoren sind hoch ist SQL Server Arbeitsspeicher beschränkt. Suchen Abfragen, Hash-Joins verwendet werden und können geändert werden, um loop Joins und finden im Abschnitt "SQL Profiler Trace Dauer Group" in diesem Artikel, konzentrieren. Weitere Informationen zu diesen Indikatoren verwenden Sie den Namen des Leistungsindikators SQL Server 7.0-Onlinedokumentation suchen.

SQL Profiler-Daten anzeigen

Beim Auflösen von Leistungsproblemen ist es äußerst nützlich, um SQL Profiler-Daten anzeigen. Sie müssen nicht alle Daten überprüfen, die Sie aufgezeichnet; Seien Sie wählerisch. SQL Profiler können Sie effektiv die erfassten Daten anzuzeigen. Auf der Registerkarte Eigenschaften (auf der
Menü Datei , klicken Sie auf Eigenschaften), SQL Profiler können Sie die Daten beschränken, die durch Entfernen von Datenspalten oder Ereignissen, Gruppierung oder Sortierung nach Spalten und Filter angezeigt. Sie können die gesamte Spur oder eine bestimmte Spalte nach bestimmten Werten suchen (auf der
Klicken Sie im Menü Bearbeiten klicken Sie auf Suchen ). Sie können auch SQL Profiler-Daten in einer SQL Server-Tabelle speichern (im Menü Datei auf Speichern unter, und klicken Sie dann auf Ablaufverfolgungstabelle), und dann SQL-Abfragen ausführen.

Hinweis Stellen Sie sicher, dass Sie nur eine gespeicherte Ablaufverfolgungsdatei filtern. Wenn Sie diese Schritte auf einem aktiven Spur verlieren Sie Daten, die seit dem Start Trace gesammelt wurde. Eine aktive Spur in einer Datei speichern oder Tabelle zuerst (auf der
Menü DateiSpeichern unter klicken), und dann erneut öffnen (klicken Sie auf im Menü Datei auf Öffnen) bevor Sie fortfahren. Beim Arbeiten mit einer gespeicherten Ablaufverfolgungsdatei wird das Filtern nicht dauerhaft Daten entfernt. die Daten werden nur ausgeblendet und nicht gelöscht. Sie können hinzufügen und Entfernen-Ereignisse und Datenspalten zu konzentrieren Ihre Suchvorgänge.

Sie sollten auf die Bereiche konzentrieren, die besten Ergebnisse erhalten. Die folgenden Faktoren können verbessern Leistung jedoch nicht um dieselbe Gradzahl. Bevor Sie Änderungen implementieren, stellen Sie fest, wie effektiv die Änderungen folgenden Faktoren abhängig sein können:

  • Wie oft die Abfrage ausgeführt wird

  • Die Abfrage verbessert werden verbessert

Zum Beispiel verringert die Ausführung einer einzelnen Abfrage von 1,5 Sekunden 1,2 Sekunden möglicherweise nicht hilfreich, wenn die Abfrage nicht mehrmals täglich ausgeführt wird. Wenn die Abfrage häufig durch eine hohe Anzahl von gleichzeitigen Benutzern ausgeführt wird, kann die Leistungssteigerung jedoch sehr effektiv sein. Umgekehrt kann eine einzelne Abfrage von 6 Minuten Sekunden verbessern nicht führen einen spürbaren Performance insgesamt selten verwendet. Verwenden Sie die Gruppierung und Filterung in SQL Profiler und Ihr Wissen über die Anwendung schätzen die Effekte einer bestimmten Abfrage oder Prozedur bevor Sie Änderungen implementieren. Konzentrieren Sie sich zunächst der effektivste ändert und fahren mit Iterationen durch andere Abfragen und Prozeduren bis zu eine Ebene, ausreichend verbessert hat.

Nach dem Speichern eines SQL Profiler-Trace in eine Datei oder Tabelle Trace in SQL Profiler öffnen und lesen. Gehen Sie folgendermaßen vor, um SQL Profiler Trace zu gruppieren:

  • Dauer gruppieren Sie den SQL Profiler-Trace:

    1. Klicken Sie im Menü Datei auf
      Eigenschaften.

    2. Klicken Sie auf der Registerkarte Datenspalten und Gruppenklicken Sie auf verschieben
      Dauer. Klicken Sie Sie alle Spalten entfernen.

    3. Klicken Sie auf die Registerkarte Ereignisse , und entfernen Sie alle Ereignisse außer TSQL-SQL:StmtCompleted und TSQL RPC: abgeschlossen. Dadurch können Sie sich auf den Abfragen, die ausgeführt werden.

    4. Klicken Sie auf OK.

    Gruppieren nach Dauer lässt sehen SQL-Anweisungen, Batches und Prozeduren, die am langsamsten ausgeführt werden. Überprüfen Sie Trace, wenn das Problem auftritt, und erstellen Sie eine Baseline für gute Leistung. Sie können Filtern nach Startzeit unterbrechen Trace in Abschnitte bei Leistung gut und separate Abschnitte bei Leistung schlechter. Suchen Sie nach Abfragen mit der längsten Dauer bei Leistung gut ist. Diese sind wahrscheinlich die Ursache für das Problem. Wenn Systemleistung sinkt, können selbst gute Abfragen, da sie auf Systemressourcen warten langer Dauer anzeigen.

    Überprüfen der Ausführungspläne für Abfragen, die meisten häufig lange dauern. Sollten Sie feststellen, dass ein Hash-Join verwendet wird, mit der Abfragehinweis-LOOP-JOIN eine nested Loops-Verknüpfung für die Abfrage erzwingen. Ist die Ausführungszeit für die Abfrage eine Verknüpfung Schleife kleiner, gleich oder sogar etwas höher als die Ausführungszeit mit dem Hash-Join eventuell eine Verknüpfung in einer Schleife eine bessere Option der Computer Speicher und CPU-Auslastung vorliegt. Durch Verringerung der Belastung Ressourcenengpass (CPU und Arbeitsspeicher), können Sie die Systemleistung verbessern. Weitere Informationen zum Abfragehinweis LOOP JOIN finden Sie unter dem Thema "SELECT (T-SQL)" in der Onlinedokumentation zu SQL Server 7.0.

  • Ereignisklasse gruppieren Sie SQL Profiler Trace:

    1. Klicken Sie im Menü Datei auf
      Eigenschaften.

    2. Klicken Sie auf der Registerkarte Datenspalten und Überschrift Gruppen klicken Sie auf verschieben
      Event-Klasse und Text mit Ereignisklasse auf. Klicken Sie auf nach unten alle anderen Spalten unter der Überschrift Gruppen entfernen.

    3. Klicken Sie auf die Registerkarte Ereignisse , und stellen Sie sicher, dass alle Ereignisse enthalten sind.

    4. Klicken Sie auf OK.

Ereignistypen

Welche Ereignisse auftreten, finden auf dem Computer mit SQL Server und wie häufig den Ereignissen Gruppieren nach Spalte Ereignisklasse . Durchsuchen Sie diese Spalte nach den folgenden Ereignissen:

  • SONSTIGE : SQL und Exec SQL; vorbereitet vorbereiten Cursor: Cursorprepare Vorbereiten SQL -Ereignis gibt an, dass eine SQL-Anweisung, mit einem Resultset (clientseitige Cursor vorbereitet wurde) mit SQLPrepare/SQLExecute (für ODBC) oder ICommandText::Prepare/ICommandText:: Execute (für OLE DB) mit den Standardoptionen Cursor: Vorwärts, schreibgeschützt, Rowsetgröße 1. Cursorprepare -Ereignis gibt an, dass ein serverseitiger Cursor für eine SQL-Anweisung mit SQLPrepare/SQLExecute (für ODBC) oder ICommandText::Prepare/ICommandText:: Execute (für OLE DB) vorbereitet wurde der vorherigen Cursoroptionen eines ein nicht-Standardwert. Ein Exec vorbereiteten SQL -Ereignis gibt an, dass entweder der oben vorhandenen vorbereiteten Anweisungen ausgeführt wurde. Häufige Vorkommen dieser Ereignisse angezeigt, verwendet die Anwendung bei Resultsets Vorbereiten/Ausführen-Modell. In diesem Fall müssen feststellen, ob das Vorbereiten/Ausführen-Modell korrekt arbeiten.

    Eine Anwendung im Idealfall bereitet eine SQL-Anweisung und oft, damit der Optimierer nicht jedesmal einen neuen Plan zu kompilieren, die die Anweisung ausgeführt. Jedem Ausführen eine vorbereitete Anweisung sparen Sie die Kosten für die Abfragekompilierung. Wenn Sie eine Abfrage einmal ausführen möchten, empfiehlt Microsoft, nicht vorbereitet. Vorbereiten und Ausführen einer SQL-Anweisung erfordert drei Netzwerk Roundtrips:, die Anweisung zur Ausführung der Anweisung, und um die Anweisung datenbankservice vorzubereiten. Vorbereiten der Servercursor erfordert mindestens fünf Roundtrips: Vorbereiten des Cursors, ausführen oder öffnen, mindestens abzurufenden, zu schließen und um es datenbankservice. Die Abfrage erfordert nur einen Roundtrip.

    Um anzuzeigen, wie die Anwendung des Modells Prepare/execute Vergleichen der Anzahl, wie oft diese beiden Ereignisse (vorbereiten und ausführen) auftreten. Die Anzahl der Ereignisse Exec SQL vorbereitet sollte größer als die Summe der SQL vorbereiten und CursorPrepare Ereignisse (mindestens drei-bis fünfmal größer ist eine gute Schätzung). Dies bedeutet, dass vorbereitete Anweisungen häufig wiederverwendet werden zu der Aufwand zum Erstellen. Anzahl der SQL vorbereiten und CursorPrepare entspricht die Anzahl der Ereignisse Exec SQL vorbereitet ist möglicherweise dadurch, dass die Anwendung nicht effektiv Vorbereiten/Ausführen-Modell. Versuchen Sie, eine Anweisung einmal vorbereiten und so weit wie möglich verwenden. Außerdem können Sie Ihre Anwendung Anweisung einmal vorbereiten und verwenden diese Aussagen.

    Die Anwendung muss speziell effiziente Verwendung das Vorbereiten/Ausführen-Modell geschrieben werden. Die Lebensdauer eines Handles für eine vorbereitete Anweisung gesteuert wie lange Sie das HSTMT öffnen in ODBC oder ICommandText Objekt in OLE DB halten. Eine gängige Praxis ist ein HSTMT erhalten eine SQL Anweisung vorzubereiten, vorbereitete Anweisung und frei HSTMT dabei den vorbereiteten Plan gegen das Handle. Wenn Sie dies tun, erhalten Sie keine Vorteile im Vorbereiten/Ausführen-Modell. Tatsächlich sehen Sie Leistungseinbußen durch den Mehraufwand der Netzwerkroundtrips. Die Anwendung muss eine Methode HSTMT oder Objekt mit der vorbereiteten Anweisung Zwischenspeichern und sie zur Wiederverwendung. Der Treiber oder Provider kann nicht automatisch verwendet werden; die Anwendung ist verantwortlich für das implementieren, verwalten und mithilfe dieser Informationen. Wenn die Anwendung nicht, sollten Sie Parametermarker nicht vorbereiten/ausführen.

  • Parametermarker verwenden Clientanwendungen können Parametermarker Optimierung derselben Transact-SQL-Anweisung mehrmals mit unterschiedlichen ein- und Ausgabewerte. Zum ersten Mal eine Abfrage ausgeführt wird, wird als eine parametrisierte Abfrage vorbereitet und SQL Server generiert und speichert einen parametrisierten Plan für die Abfrage. Für nachfolgende Aufrufe von derselben Abfrage mit denselben oder anderen Parametern SQL Server keinen neuen Abfrageplan generiert; SQL Server kann durch Ersetzen der aktuellen Parameter vorhandenen Abfrageplan wiederverwenden.

    Nutzt die Anwendung Parametermarker mit SQLExecDirect (für ODBC) oder ICommandText:: Execute (für OLE DB), Treiber oder Provider automatisch verpackt die SQL-Anweisung und führt als einen Aufruf von Sp_executesql . Die Anweisung muss nicht vorbereitet und separat ausgeführt werden. Wenn SQL Server einen Aufruf von Sp_executesqlempfängt, es automatisch überprüft den Prozedurcache für einen entsprechenden Plan wird dieser Plan erneut verwendet und erzeugt einen neuen Plan.

    Um zu bestimmen, wenn Ihre Anwendung derzeit Parametermarker verwendet, können Sie die
    Textspalten in SQL Profiler Trace für "Sp_executesql". Aber da Sp_executesql direkt aufgerufen werden kann, bedeuten nicht alle Instanzen Parametermarker.

    Weitere Informationen über das Vorbereiten/Ausführen-Modell finden Sie "Ausführung Zwischenspeichern und Wiederverwendung" in der Onlinedokumentation zu SQL Server 7.0. Weitere Informationen zu Parametermarker finden Sie "Parametermarker" in der Onlinedokumentation zu SQL Server 7.0.

  • SP: abgeschlossen Dynamische SQL-Anweisungen, die mit der EXECUTE-Befehl ausgeführt werden als ein SP: abgeschlossen Ereignis mit dem Text "Dynamic SQL." Erweitern Sie die SP: abgeschlossen Ereignis und dann nach auftreten, die "Dynamic SQL" als Text. Wenn viele Ereignisse, Sp_executesql anstelle der EXECUTE-Anweisung Leistungssteigerung Anwendung möglicherweise. Sp_executesql gespeicherten Prozedur ermöglicht SQL Server die Ausführungspläne wieder verwenden, wenn die Abfrage erneut mit anderen Parametern ausgeführt wird. Bei Verwendung die EXECUTE-Anweisung Plan nicht parametrisiert und wird nicht verwendet, wenn die Abfrage mit Parametern ausgeführt wird.

    Ermitteln, Abfragen oder Prozeduren, die dynamischen SQL-Ereignisse mit der EXECUTE-Anweisung verwenden, beachten Sie die Verbindungs-ID und Startzeit der für jedes Ereignis. Aufheben die Verfolgung ( Ereignisklasse und Text aus den Gruppen entfernt). Nach dem Aufheben der Verfolgung ist es chronologisch sortiert. Filtern nach Verbindungs-ID Trace (auf der Registerkarte Filter ) und entfernen Sie alle Ereignisklassen außer der SP: ab und SP: vollständige Ereignisse zur besseren Lesbarkeit. Sie können dann für die Startzeit des Ereignisses suchen (Menü Bearbeiten , klicken Sie auf
    Suchen). Die Ergebnisse zeigen beim dynamische SQL-Ereignis gestartet. Des Ereignisses in einer gespeicherten Prozedur das Ereignis erscheint zwischen dem SP: ab und SP: abgeschlossen Ereignisse für diese Prozedur. Wenn das Ereignis nicht in einer gespeicherten Prozedur aufgetreten ist, wurde als Ad-hoc-Abfrage ausgeführt und können anderen Datenspalten (Anwendungsname, NT-Benutzernameund andere) bestimmt, wo der Befehl ausgeführt wurde. Zum Bestimmen des Texts des Befehls und den Kontext, in dem es ausgeführt wurde, können Sie auch Ereignisklassen SQL: BatchCompleted und SQL:RPCCompletedhinzufügen.

    Nachdem Sie ermittelt, wo die EXECUTE-Anweisung verwendet wird, sollten Sie einen Aufruf von Sp_executesqlersetzen. Betrachten Sie beispielsweise das folgende Szenario, mit dynamic SQL EXECUTE-Befehl verwendet wird. Eine Prozedur nimmt einen Tabellennamen, ID und IdValue als Eingabeparameter und führt dann eine SELECT-Anweisung aus der Tabelle basierend auf den ID-Wert. Verwendung einer EXECUTE-Anweisung ähnelt die Prozedur den 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 ist Wenn Sie diese Prozedur für die Titles -Tabelle in der Pubs -Beispieldatenbank zweimal mit unterschiedlichen Werten für die Parameter @idValue ausführen, muss SQL Server generiert eine separate Abfrageplan für jede Ausführung. Zum Beispiel:

    exec dynamicUsingEXECUTE
    'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    'title_id', 'BU7832'

    Hinweis In diesem Beispiel wird die Abfrage so einfach, dass SQL Server automatisch parametrisieren und tatsächlich den Ausführungsplan wiederverwenden können. Jedoch war dies eine komplexe Abfrage, die SQL Server möglicherweise nicht automatisch parametrisieren, kann SQL Server nicht wiederverwenden des Plans für die zweite Ausführung @idValue Parameter geändert wurde. Folgende einfache Abfrage schränkt die Komplexität des Beispiels.

    Sie können dieses Verfahren zum Verwenden von Sp_executesql anstelle der EXECUTE-Anweisung erstellen. Unterstützung für Parameter ersetzt effizienter Sp_executesql da Ausführungspläne generiert, die eher SQL Server wiederverwendet werden. Zum Beispiel:

    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 generiert ersten Sp_executesql Anweisung SQL Server einen parametrisierten Plan für die SELECT-Anweisung von Titeln Title_id als Parameter. Die zweite Ausführung verwendet SQL Server den Plan mit der neuen Parameterwert. Weitere Informationen zu Sp_executesqlfinden Sie unter "Sp_executesql (T-SQL)" und "Verwenden von Sp_executesql" Themen in der Onlinedokumentation zu SQL Server 7.0.

  • SP:RECOMPILES Dieses Ereignis zeigt an, dass eine gespeicherte Prozedur während der Ausführung neu kompiliert wurde. Viele Recompile Ereignisse gibt an, dass SQL Server-Ressourcen für die Abfragekompilierung statt Abfrage.

Wenn eines dieser Ereignisse nicht angezeigt, wird die Anwendung nur Ad-hoc-Abfragen in SQL Server ausgeführt. SQL Server stellt fest, dass automatisch bestimmte Abfragen parametrisieren können oder wiederholt dieselben Parameter verwendet, muss jede Abfrage ausgeführt SQL Server einen neuen Ausführungsplan generiert. SQL Server-Systemmonitor weisen viele SQL-Kompilierungen/Sekunde. CPU-Intensive kann für viele gleichzeitige Benutzer. Um dieses Problem zu umgehen, finden Sie die meisten häufig Abfragen ausgeführt, und erstellen Sie Prozeduren für diese Abfragen Parametermarker oder Sp_executesql.

Referenzen

Weitere Informationen zum Überwachen und Problembehandlung bei Leistungsproblemen in SQL Server finden Sie in den folgenden zu Artikeln der Microsoft Knowledge Base:

224587 Behandlung von Anwendungsperformance mit SQL Server

224453 INF: verstehen und Lösen von SQL Server 7.0 oder 2000 blockierende Probleme

243586 Problembehandlung gespeicherte Prozedur Neukompilierung

243589 Behandlung von langsamen Abfragen auf SQL Server 7.0 oder höher

251004 -INF: SQL Server 7.0 Sperren überwachen

Benötigen Sie weitere Hilfe?

Ihre Office-Fähigkeiten erweitern

Schulungen erkunden >

Neue Funktionen als Erster erhalten

Microsoft Insider beitreten >

War diese Information hilfreich?

Wie zufrieden sind Sie mit der Sprachqualität?
Was hat Ihre Erfahrung beeinflusst?

Vielen Dank für Ihr Feedback!

×