Problemen met de prestaties van Ad-Hoc query's in SQL Server


Samenvatting


Dit artikel wordt beschreven hoe u problemen met de prestaties van veel gelijktijdige ad hoc-query's in Microsoft SQL Server. Als u de precieze oorzaak van het probleem niet hebt bepaald, Zie het volgende artikel in de Microsoft Knowledge Base voordat u doorgaat:
224587 het prestaties met SQL Server oplossen


In dit artikel wordt ervan uitgegaan dat u het probleem isoleren KB 224587 hebt gebruikt en dat u een Windows NT Prestatiemeter-logboek hebt vastgelegd en SQL Profiler Traceerdetail die de specifieke items, gebeurtenissen en data-kolommen.

Kenmerken van de prestatieproblemen

Het prestatieprobleem heeft de volgende kenmerken:
  • Korte ad-hoc query's meestal een zeer korte duur hebben leiden tot trage prestaties wanneer een groot aantal gelijktijdige gebruikers de query's uitvoeren.
  • Zeer hoge of 100 procent CPU-gebruik.
  • Geen bijbehorende blokkering tijdens de periodes van trage prestaties.

    U kunt snel zoeken voor het blokkeren van de BLK -kolom in de uitvoer van het systeem opgeslagen procedure van sp_who . Als de kolom BLK is niet nul voor een aantal Systeemproces-id (SPID's), is er geblokkeerd.
  • In bepaalde situaties wordt geheugen van de server wordt benadrukt en kunnen er foutberichten die vergelijkbaar met de volgende fouten zijn:
    Fout: 701, ernst: 17, staat: 1
    Er is onvoldoende systeemgeheugen deze query uit te voeren.
    - of -
    Msg 8645, niveau 17, staat 1, Procedure, regel 1
    Er is een time-out opgetreden tijdens het wachten op geheugenbronnen de query uit te voeren. Voer de query opnieuw uit.

Verbeteringen in de querycompilaties

Dankzij verbeteringen in de systeemarchitectuur in SQL Server 7.0, met name de query optimizer starten mogelijk een verschil in het gebruik van systeembronnen door vergeleken met eerdere versies van SQL Server-toepassingen. Met name SQL Server 7.0 een toename in het gebruik van CPU of geheugen kan zien, maar eerdere versies van SQL Server worden meestal schijf-i/o gebonden. Deze wijzigingen kunnen worden getraceerd aan twee factoren:
  • Joins hash en samenvoegen
  • Query compilatie tijden
Eerdere versies van SQL Server berustte volledig op de geneste lus iteraties joins uitvoeren. Geneste lus joins gebruikt per definitie schijf-i/o. U start met SQL Server 7.0, zijn hash- en samenvoegen joins geïntroduceerd. Hash en samenvoegen joins doen nog veel meer in het geheugen dan een geneste lus joins worden verwerkt. Het logische resultaat van deze is dat de CPU en geheugengebruik is hoger wanneer deze join technieken worden gebruikt. Zie de onderwerpen "Wat hash-Joins" en 'Wat samenvoegen Joins' in de on line boekbestanden voor SQL Server 7.0 voor meer informatie over joins hash en samenvoegen.

Query compilatie tijden worden beïnvloed, omdat de query optimizer heeft meer opties en informatie beschikbaar dan in eerdere versies van SQL Server, inclusief nieuwe hash en samenvoegen join technieken, verbeterde zoekfuncties algoritmen en kolom statistieken. Deze aanvullende informatie kan de query optimizer de meest efficiënte methode voor het ophalen van querygegevens selecteren. De analyse en rekening te houden met deze nieuwe technieken en de informatie moet echter verwerkingstijd. Deze hogere CPU-gebruik kan leiden tot een query compilatie tijden die langer dan in eerdere versies van SQL Server zijn.

Deze toename van de compilatie is voor de meeste query's gecompenseerd door een afname in de tijd worden uitgevoerd. Het totale effect is dat de query sneller dan in eerdere versies van SQL Server. Echter één uitzondering treedt op bij zeer kleine, eenvoudige, OLTP-type query's met zeer lage uitvoeringstijden. Voor deze query's, kan het proces van het genereren van een queryplan hebben last gelijk of groter is dan de uitvoering van de query. Als gevolg hiervan kan uitvoeren van de query werkt iets langzamer dan in eerdere versies van SQL Server. Omdat het verschil meestal uitgedrukt in milliseconden wordt, worden deze effecten niet opgemerkt dat voor een bepaalde query als deze afzonderlijk wordt uitgevoerd. U merkt echter dat algehele systeem CPU-gebruik hoger dan in eerdere versies van SQL Server is als een groot aantal ad-hoc query's gelijktijdig worden uitgevoerd door een groot aantal gebruikers.

Query's met parameters te ontwikkelen

SQL Server 7.0 maakt gebruik van verschillende nieuwe technieken, zoals caching ad hoc query's en automatische parameters te voorzien. De query's die SQL Server 7.0 automatisch parameterizes zijn echter beperkt. Gebruik de volgende methoden om ervoor te zorgen dat de query's met parameters zijn en effectiever kunnen worden gebruikt:
  • Parametermarkeringen De OLE DB- en ODBC-API's staan de parameters worden opgegeven met een vraagteken wanneer gebruikers query's indienen. Dit is met name handig in een toepassing, met name voor de midden-tier toepassingen waarvoor query generatie modules waar gebruik van opgeslagen procedures niet beschikbaar is. Het queryplan dat wordt gegenereerd voor query's met parametermarkeringen opnieuw kan worden gebruikt door clients die de dezelfde query uitvoert, zelfs als de waarden van de verschillende parameters zijn opgegeven. Zie voor meer informatie het onderwerp 'Parametermarkeringen' in de on line boekbestanden voor SQL Server 7.0.
  • sp_executesql De sp_executesql opgeslagen procedure wordt aangeroepen door het ODBC-stuurprogramma of de OLE DB-provider wanneer parametermarkeringen in een toepassing worden gebruikt. Echter, deze ook genoemd door de toepassing of in een andere opgeslagen procedure op ad-hoc query's uitdrukkelijk voorzien. Dit is zeer nuttig in toepassingen of batch-bestanden waar de EXECUTE-instructie wordt gebruikt om dynamische SQL-instructies uitvoeren. In tegenstelling tot sp_executesqlmag de EXECUTE-instructie geen parameters voorzien. Dit beperkt de kans op query plan hergebruik. Zie de onderwerpen in de on line boekbestanden voor SQL Server 7.0 'Using sp_executesql' en 'sp_executesql (T-SQL)' voor meer informatie.
  • Opgeslagen procedures Opgeslagen procedures hebben veel voordelen, waaronder de mogelijkheid te voorzien van query's en opnieuw plannen worden uitgevoerd. Zie voor meer informatie de onderwerpen ' opgeslagen ' en 'Programming opgeslagen Procedures' in de on line boekbestanden voor SQL Server 7.0.

Prestatiemetergegevens bekijken

Prestatiemeter-logboek gebruiken om te bepalen welke bronnen het knelpunt veroorzaken. Prestatiemeter-logboek kan geven u een totaalbeeld van het systeem en helpen uw aandacht richten wanneer u de gegevens van SQL Profiler. Bekijk de prestatiemetergegevens vanaf het moment waarop prestaties tot en met het moment dat de prestaties minder goed is. Bepaalt de teller die eerst werd beïnvloed, en vervolgens bepalen welke van de volgende problemen is het meest relevant zijn voor uw situatie:
  • Object: proces
    Teller: Processor
    Instantie: SQL Server
  • Object: Processor
    Teller: percentage processortijd
    Instantie: Controleer elk processorexemplaar
  • Object: SQL Server: Buffer Manager
    Teller: Gratis Buffers
  • Object: SQL Server: Buffer Manager
    Teller: Gestolen aantal pagina 's
  • Object: SQL Server: geheugenbeheer
    Teller: Geheugentoekenningen in behandeling
  • Object: SQL Server SQL: statistieken
    Teller: SQL-compilaties/sec.
Als de CPU-gebruik, SQL-compilaties/sec en Buffers gratis tellers hoog zijn en de prestatiemeteritems voor geheugen subsidies die in behandeling zijn en een aantal gestolen pagina's laag zijn, betekent dit dat de CPU het knelpunt. Gericht op het effectief voorzien en hergebruik van queryplannen om te voorkomen dat de kosten van een queryplan genereren en Zie de sectie 'De trace SQL Profiler groeperen op klasse event' van dit artikel. Als de vrije Buffers en SQL-compilaties/sec items laag zijn en de items aantal gestolen pagina's en geheugen subsidies die in behandeling hoog zijn, is SQL Server geheugen worden beperkt. Gericht op het vinden van query's waarin hash-joins worden gebruikt en om joins loop en Zie de sectie 'De trace SQL Profiler groeperen op duur' van dit artikel kunnen worden gewijzigd. Gebruik de naam van het item te zoeken, de SQL Server 7.0 Books Online voor meer informatie over deze items.

De SQL Profiler-gegevens weergeven

Wanneer u problemen oplost, is het zeer belangrijk is om SQL Profiler-gegevens te bekijken. U hoeft niet te controleren van de gegevens die u vastgelegd; Wees voorzichtig. SQL Profiler kunt u de opgenomen gegevens effectief weergeven. Op het tabblad Eigenschappen (op de
Menu bestand , klik op Eigenschappen), SQL Profiler kunt u de gegevens beperken die wordt weergegeven door het verwijderen van kolommen met gegevens of gebeurtenissen groeperen of sorteren op kolommen met gegevens en toepassen van filters. U kunt de volledige tracering of specifieke kolom voor specifieke waarden zoeken (op de
Het menu bewerken , klikt u op Zoeken ). U kunt ook de SQL Profiler-gegevens opslaan in een SQL Server-tabel (in het menu bestand , wijs OpslaanAlsen klik vervolgens op Tabel Trace), en vervolgens SQL-query's uitvoeren tegen.

Opmerking Zorg ervoor dat u alleen een traceringsbestand opgeslagen filteren. Als u deze op een actieve trace stappen verloren gegevens die sinds de start van de tracering is opgenomen. Een actief overtrekken opslaan in een bestand of een andere tabel eerst (op de
Menu bestand op OpslaanAls ), en vervolgens opnieuw te openen (Klik in het menu bestand op openen) voordat u verdergaat. Als u met een traceringsbestand opgeslagen werkt, verwijdert het filter definitief u niet de gegevens; de gegevens wordt alleen verborgen, niet verwijderd. U kunt toevoegen en verwijderen van gebeurtenissen en kolommen met gegevens voor het scherpstellen uw zoekopdrachten.

Ook moet u zich richten op de gebieden waar u het meeste voordeel ontvangt. De volgende factoren verhogen de prestaties van toepassingen kunnen helpen, maar niet noodzakelijkerwijs dezelfde mate. Voordat u wijzigingen kunt implementeren, moet u bepalen hoe effectief de wijzigingen kunnen worden afhankelijk van de volgende factoren:
  • Hoe vaak de query wordt uitgevoerd
  • Hoeveel verbetering de query kan worden verbeterd.
Bijvoorbeeld: verkorting van de uitvoering van een enkele query 1,5 seconden op 1,2 seconden mogelijk niet handig zijn als de query niet vaak gedurende de dag wordt uitgevoerd. Als de query wordt zeer vaak uitgevoerd door een groot aantal gelijktijdige gebruikers, kan de prestatieverbetering echter zijn zeer effectief. Daarentegen kan één query uit 6 minuten op 3 seconden te verbeteren niet leveren een merkbare toename van de algehele prestaties als het wordt zelden gebruikt. Gebruik de groepering en filtering technieken in SQL Profiler en uw kennis van de toepassing de effecten van een bepaalde query of een procedure voordat u wijzigingen kunt implementeren. Zich eerst concentreren op de meest effectieve wijzigingen en gaat u verder met iteraties door een andere query's en -procedures tot een niveau waarbij voldoende prestaties zijn verbeterd.

Nadat u een SQL Profiler trace in een bestand of een tabel opgeslagen, opent u de tracering in SQL Profiler en controleer de inhoud. Als u wilt groeperen op het spoor SQL Profiler, volg deze stappen:
  • De trace SQL Profiler groeperen op duur:
    1. Klik in het menu bestand
      Eigenschappen.
    2. Klik op het tabblad Kolommen met gegevens en groepen, klikt u onder Omhoog verplaatsen
      Duur. Klik op Omlaag als u wilt verwijderen van alle andere kolommen.
    3. Klik op het tabblad gebeurtenissen en verwijder alle gebeurtenissen, met uitzondering van TSQL SQL:StmtCompleted en TSQL RPC: voltooid. Hierdoor kunt u zich richten op de query's die worden uitgevoerd.
    4. Klik op OK.
    Groeperen op duur kan gemakkelijk zien de SQL-instructies, batches en procedures waarop het langzaamst. De trace bekijken wanneer het probleem zich voordoet en maakt u een basislijn van goede prestaties. U kunt filteren op begintijd de trace opdelen in secties als prestaties goed en aparte secties kwaliteit is slecht. Zoek de query's met de langste duur als prestaties goed is. Dit zijn waarschijnlijk de oorzaak van het probleem. Als de algemene systeemprestaties afneemt, weergeven zelfs goede query's lange tijdsduur omdat ze op systeembronnen wachten.

    Bekijk de plannen worden uitgevoerd voor de query's die de meeste vaak lange duur hebben. Als u ziet dat er een join hash wordt gebruikt, kunt u de queryaanwijzing LUS JOIN te dwingen een geneste lus join voor de query. Als de uitvoeringstijd voor de query met behulp van een lus join kleiner dan, gelijk is aan of zelfs iets hoger dan de tijd kan worden uitgevoerd met de hash-join is, een lus join is misschien een betere optie als de computer is veel geheugen en CPU-gebruik. Vermindert de belasting op het knelpunt resources (CPU en geheugen), kunt u de algehele systeemprestaties te verbeteren. Zie voor meer informatie over de queryaanwijzing LUS deelnemen aan het onderwerp 'Selecteren (T-SQL)' in de on line boekbestanden voor SQL Server 7.0.
  • De trace SQL Profiler groeperen op de klasse event:
    1. Klik in het menu bestand
      Eigenschappen.
    2. Klik op het tabblad Kolommen met gegevens en klik vervolgens onder de kop groepen op Omhoog verplaatsen
      Event, klasse en tekst met de Klasse Event op de voorgrond. Klik op Omlaag als u wilt verwijderen van alle kolommen onder de kop groepen .
    3. Klik op het tabblad gebeurtenissen en zorg ervoor dat alle gebeurtenissen opgenomen worden.
    4. Klik op OK.

Typen gebeurtenissen

Om te zien welke typen gebeurtenissen optreden op de computer met SQL Server en hoe vaak de gebeurtenissen groeperen op kolom Klasse Event . Zoeken in deze kolom voor de volgende gebeurtenissen:
  • DIVERSE : voorbereiden, SQL en Exec voorbereide SQL; CURSORS: Cursorprepare een gebeurtenis Voorbereiden SQL geeft aan dat een SQL-instructie is voorbereid voor gebruik met een resultaatset standaard (cursor aan de clientzijde) met SQLPrepare/SQLExecute (voor ODBC) of ICommandText::Prepare/ICommandText::Execute (voor OLE DB) met de opties standaard cursor: voorwaarts, alleen-lezen, grootte van de rijenset = 1. Een Cursorprepare gebeurtenis geeft aan dat een cursor aan de serverzijde is voorbereid op een SQL-instructie met SQLPrepare/SQLExecute (voor ODBC) of ICommandText::Prepare/ICommandText::Execute (voor OLE DB) met een van de vorige opties voor de muiscursor ingesteld op een niet-standaard waarde. Een gebeurtenis Exec voorbereide SQL geeft aan dat een van de vorige soorten bestaande voorbereide instructies is uitgevoerd. Als er regelmatig exemplaren van deze gebeurtenissen, uw toepassing is met behulp van het model voorbereiden/uitvoeren bij het openen van resultaatsets. In dat geval moet u bepalen of u het model voorbereiden uitvoeren/goed gebruikt.

    In het ideale geval een toepassing eenmaal een SQL-instructie wordt voorbereid en wordt deze vaak uitgevoerd zodat de optimizer is niet nodig om het compileren van een nieuw plan telkens wanneer die de instructie wordt uitgevoerd. Telkens wanneer die u een voorbereide instructie uitvoert dat u de kosten van de opstelling van de query opslaan. Als u slechts één keer uitvoeren van een query, is het raadzaam dat u niet voorbereiden. Voorbereiden en uitvoeren van een SQL-instructie vervolgens drie netwerk interactie vereist: één voor het voorbereiden van de instructie, een de instructie uit te voeren, en een met de instructie unprepare. Cursors aan de serverzijde voorbereiding vereist ten minste vijf retouren: voorbereiden van de cursor, één voor het openen of uitvoeren, een of meer te halen uit een te sluiten, en aan het unprepare. De query wordt uitgevoerd alleen nodig één roundtrip.

    Vergelijken om te zien hoe effectief uw toepassing gebruikmaakt van het voorbereiden/uitvoeren, het aantal keren dat deze twee gebeurtenissen (voorbereiden en uitvoeren) optreden. Het aantal gebeurtenissen Exec voorbereide SQL moeten veel groter is dan het totaal van SQL voorbereiden en CursorPrepare -gebeurtenissen (ten minste drie tot vijf keer groter is een goede schatting). Dit geeft aan dat voorbereide instructies wordt opnieuw vaak genoeg gebruikt worden te overwinnen de verhoogde overhead ze te maken. Als het aantal gebeurtenissen SQL voorbereiden en CursorPrepare ongeveer gelijk aan het aantal Exec voorbereide SQL -gebeurtenissen is, betekent dit waarschijnlijk dat de toepassing wordt niet daadwerkelijk met behulp van het model voorbereiden/uitvoeren. Probeer een instructie één keer voorbereiden en deze zo veel mogelijk opnieuw gebruiken. Ook kunt u uw toepassing één keer overleggen en instructies voor het opnieuw gebruiken.

    De toepassing moet speciaal worden geschreven efficiënt gebruik van het model voorbereiden/uitvoeren. De levensduur van een ingang naar een voorbereide instructie wordt bepaald door hoe lang u de HSTMT in ODBC- of het ICommandText-object in de OLE DB houden. Een veelvoorkomende truc is het verkrijgen van een HSTMT voorbereiden van een SQL-instructie, de voorbereide instructie uitvoeren en vervolgens de HSTMT, waardoor de greep verliezen op de voorbereide plan vrij. Als u dit doet, ontvangt u niet de voordelen van het model voorbereiden/uitvoeren. In feite wordt er een verminderde prestaties vanwege de extra overhead van de interactie van het netwerk. De toepassing moet een methode om de HSTMT of het object met de greep voorbereide instructie cache en de toegang tot deze voor hergebruik. Het stuurprogramma of de provider doet dit niet automatisch; de toepassing is verantwoordelijk voor het implementeren, onderhouden en het gebruik van deze informatie. Als de toepassing niet meer doet, moet u rekening houden met parametermarkeringen in plaats van de methode execute voorbereiden /.
  • Met behulp van parametermarkeringen Toepassingen kunnen parametermarkeringen gebruiken voor het optimaliseren van het gebruik van dezelfde Transact-SQL-instructie verschillende malen met andere invoer- en uitvoerwaarden. De eerste keer dat een query wordt uitgevoerd, dit is bedoeld als een query met parameters en SQL Server genereert en slaat een plan met parameters voor de query. Volgende aanroepen naar dezelfde query met behulp van de parameters dezelfde of een andere is SQL Server niet voor het genereren van een nieuw queryplan gemaakt; SQL Server opnieuw kunt gebruiken voor het bestaande queryplan door te vervangen door de huidige parameters.

    Als de toepassing gebruikt de parametermarkeringen met aanroepen van SQLExecDirect (voor ODBC) of ICommandText::Execute (voor OLE DB), het stuurprogramma of de provider automatisch pakketten van de SQL-instructie en wordt deze uitgevoerd als een oproep voor een sp_executesql . De instructie moet niet worden opgesteld en worden afzonderlijk uitgevoerd. Als SQL Server een aanroep van sp_executesql ontvangt, het automatisch controleert de procedurecache voor een overeenkomstige plan en wordt gebruikgemaakt van dat plan of genereert een nieuw plan.

    Om te bepalen als uw toepassing momenteel parametermarkeringen gebruikt, kunt u zoeken de
    Kolom in de trace SQL Profiler voor 'sp_executesql'. Omdat de sp_executesql kan rechtstreeks worden aangeroepen, geven niet in alle gevallen het gebruik van parametermarkeringen.

    Zie het onderwerp 'Uitvoering plannen in cache opslaan en opnieuw gebruiken' in de on line boekbestanden voor SQL Server 7.0 voor meer informatie over het model voorbereiden/uitvoeren. Zie het onderwerp 'Parametermarkeringen' in de on line boekbestanden voor SQL Server 7.0 voor meer informatie over parametermarkeringen.
  • SP: voltooid Dynamische SQL-instructies met de opdracht uitvoeren wordt uitgevoerd weergegeven als een SP: voltooid gebeurtenis met de tekst "Dynamische SQL." Vouw de SP: voltooid gebeurtenis en zoek vervolgens naar overeenkomsten met 'Dynamische SQL' als de tekst. Als er veel van deze gebeurtenissen, kunt u mogelijk de prestaties verbeteren met behulp van sp_executesql in plaats van de EXECUTE-instructie. De sp_executesql opgeslagen procedure kunt SQL Server opnieuw plannen voor uitvoering gebruiken als dezelfde query is uitgevoerd met verschillende parameters. Het plan bevat geen parameters wanneer u de EXECUTE-instructie gebruikt, en deze niet opnieuw gebruikt als de query wordt uitgevoerd, opnieuw met dezelfde parameters.

    Opmerking om te bepalen van de query's of procedures die dynamische SQL-gebeurtenissen met de EXECUTE-instructie gebruiken, de verbindings-ID en de begintijd van de voor elke gebeurtenis. De tracering opheffen ( Klasse Event en tekst verwijderen uit de kop groepen ). Nadat u de tracering de groepering opheft, wordt deze in chronologische volgorde gesorteerd. Filteren van het traceren van de verbindings-ID (op het tabblad Filters ) en verwijder alle gebeurtenisklassen, met uitzondering van de SP: vanaf en SP: volledige gebeurtenissen voor een betere leesbaarheid. Vervolgens kunt u zoeken naar de begintijd van de gebeurtenis (Klik op het menu bewerken
    Zoeken). De resultaten geven wanneer de dynamische SQL-gebeurtenis wordt gestart. Als de gebeurtenis is opgetreden in een opgeslagen procedure, door de gebeurtenis wordt weergegeven tussen de SP: starten van en SP: voltooid gebeurtenissen voor die procedure. Als de gebeurtenis heeft plaatsgevonden in een opgeslagen procedure, het als een ad-hoc query is uitgevoerd en u kunt de andere kolommen met gegevens (Naam, NT-gebruikersnaamen anderen) om te bepalen waar de opdracht is uitgevoerd. Om te bepalen van de tekst van de opdracht en de context waarin deze is uitgevoerd, kunt u ook gebeurtenisklassen, zoals SQL:BatchCompleted en SQL:RPCCompletedtoevoegen.

    Nadat u hebt vastgesteld waar de EXECUTE-instructie wordt gebruikt, kunt u vervangen door een aanroep van sp_executesql. Neem bijvoorbeeld het volgende scenario waarin de opdracht uitvoeren met dynamische SQL wordt gebruikt. Een procedure wordt een naam, ID en idValue als invoerparameters en vervolgens een SELECT-instructie wordt uitgevoerd in de tabel op basis van de id-waarde. Met behulp van een EXECUTE-instructie, lijkt de procedure op de volgende 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
    Ervan uitgaande dat de query wordt niet automatisch met parameters, als u deze procedure ten opzichte van de tabel titles in de voorbeelddatabase pubs tweemaal met verschillende waarden voor de parameter @idValue uitvoert, moet SQL Server genereren een afzonderlijke queryplan voor elke uitvoering. Bijvoorbeeld:
    exec dynamicUsingEXECUTE
    'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    'title_id', 'BU7832'
    Opmerking In dit voorbeeld wordt is de query eenvoudig genoeg SQL Server, kunnen deze automatisch voorzien en daadwerkelijk gebruiken het uitvoeringsplan. Echter, als dit een complexe query SQL Server niet automatisch voorzien was kan, SQL Server kan niet opnieuw gebruiken het plan voor de uitvoering van de tweede als de parameter @idValue is gewijzigd. De volgende eenvoudige query beperkt de complexiteit van het voorbeeld.

    U kunt deze procedure voor het gebruik van sp_executesql in plaats van de instructie EXECUTE herschrijven. Ondersteuning voor het vervangen van een parameter maakt sp_executesql efficiënter omdat de uitvoering van plannen die waarschijnlijk zullen worden hergebruikt door SQL Server wordt gegenereerd. Bijvoorbeeld:
    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 dit voorbeeld wordt de eerste keer dat de sp_executesql -instructie is uitgevoerd, gegenereerd door SQL Server een plan met parameters voor de SELECT-instructie met de titels met title_id als parameter. Het plan met de nieuwe parameterwaarde voor de tweede uitvoering hergebruikt door SQL Server. Zie de onderwerpen in de on line boekbestanden voor SQL Server 7.0 'Using sp_executesql' en 'sp_executesql (T-SQL)' voor meer informatie over sp_executesql.
  • SP:RECOMPILES Deze gebeurtenis geeft aan dat een opgeslagen procedure is gecompileerd tijdens uitvoering. Veel recompile gebeurtenissen geeft aan dat SQL Server resources voor het compileren van een query in plaats van uitvoering van de query.
Als u een van deze gebeurtenissen niet ziet, kan de toepassing alleen ad hoc-query's op SQL Server wordt uitgevoerd. Tenzij SQL Server vaststelt dat deze automatisch bepaalde query's kan voorzien of als de parameters die herhaaldelijk worden gebruikt, moet elke query die wordt uitgevoerd in SQL Server genereren van een nieuw uitvoeringsplan. SQL Server Performance Monitor moet veel SQL-compilaties per seconde worden weergegeven. Dit is een CPU-intensieve veel gelijktijdige gebruikers. U kunt dit probleem omzeilen, vinden de meeste query's vaak uitgevoerd en kunt u opgeslagen procedures voor deze query's gebruikt parametermarkeringen of sp_executesqlmaken.

Referenties


Voor meer informatie over het controleren en het oplossen van prestatieproblemen in SQL Server, klikt u op de volgende artikelnummers om de artikelen in de Microsoft Knowledge Base:

224587 het prestaties met SQL Server oplossen

224453 , INF: begrijpen en oplossen van SQL Server 7.0 of 2000 problemen met blokkering

243586 probleemoplossing opgeslagen procedure hercompilatie

243589 problemen oplossen met trage query's in SQL Server 7.0 of hoger

251004 , INF: blokkering van SQL Server 7.0 controleren