Slik feilsøker du ytelsen for Ad Hoc-spørringer i SQL Server


Sammendrag


Denne artikkelen beskriver hvordan du feilsøker dårlig ytelse av mange samtidige ad hoc-spørringer i Microsoft SQL Server. Hvis du ikke har funnet ut den nøyaktige årsaken til problemet, kan du se følgende artikkel i Microsoft Knowledge Base før du fortsetter:
224587 hvordan du feilsøker programytelse med SQL Server


Denne artikkelen forutsetter at du har brukt KB 224587 til å begrense omfanget av problemet, og at du har tatt opp en Windows NT Ytelsesmåler-logg og spore SQL Profiler detaljerte kolonnene for bestemte tellere, hendelser og data.

Egenskapene til ytelsesproblemene

Ytelsesproblemet har følgende egenskaper:
  • Kort ad hoc-spørringer som har en svært kort varighet vanligvis føre til treg systemytelsen når et høyt antall samtidige brukere kjøre spørringene.
  • Svært høy eller 100 prosent CPU-bruk.
  • Ingen tilknyttede blokkering i perioder med lav ytelse.

    Du kan raskt søke etter blokkering ved å merke kolonnen BLK i utdataene for sp_who systemlagrede prosedyre. Hvis kolonnen BLK ikke er null for en rekke systemprosess-IDer (SPIDer), blokkerer det.
  • I noen tilfeller serverminnet er stresset, og du kan motta feilmeldinger som ligner på følgende feil:
    Feil: 701, alvorlighetsgrad: 17, tilstand: 1
    Det er ikke nok minne til å kjøre denne spørringen.
    - eller -
    Msg 8645, nivå 17 tilstand 1, prosedyre, linje 1
    Det oppstod et tidsavbrudd under venting på minne til å kjøre spørringen. Kjør spørringen på nytt.

Forbedringer i spørringskompileringer

På grunn av forbedringer i systemarkitektur starter i SQL Server 7.0, spesielt spørringsoptimaliseringen, kan du merke en forskjell i systemet ressursbruk av sammenlignet med tidligere versjoner av SQL Server-applikasjoner. Spesielt, SQL Server 7.0 kan vise en økning i bruk av CPU- eller minne, men tidligere versjoner av SQL Server er vanligvis disk-IO bundet. Disse endringene kan spores til to faktorer:
  • Hash-kodealgoritmen og Flett sammenføyninger
  • Tidspunkt for kompilering av spørring
Tidligere versjoner av SQL Server spredde seg helt på nestet løkke gjentakelser til å utføre sammenføyninger. Nestet løkke sammenføyninger Bruk arvbart disk-IO. Starter med SQL Server 7.0, ble hash og Flett sammenføyninger introdusert. Hash-kodealgoritmen og Flett sammenføyninger gjøre mye mer i minnet behandling enn nestet løkke sammenføyninger. Logiske resultatet av dette er at CPU og minnebruk er høyere når du bruker disse teknikkene sammenføyning. Hvis du vil ha mer informasjon om hash og Flett sammenføyninger, se "Forstå Hash sammenføyninger" og "Forstå flettingen sammenføyninger" emner i SQL Server 7.0 Books Online.

Tidspunkt for kompilering av spørringen, er berørt fordi spørringsoptimaliseringen har flere alternativer og informasjon som er tilgjengelig i tidligere versjoner av SQL Server, inkludert nye teknikker for hash-kodealgoritmen og Flett sammenføyning, forbedret søkefunksjon algoritmer og statistikk for kolonnen. Denne tilleggsinformasjonen tillater at spørringsoptimaliseringen velger den mest effektive metoden for å hente spørringsdata. Analyse og vurdering av disse nye teknikker og informasjon krever imidlertid behandlingstid. Dette økt bruk av CPU, kan resultere i spørringen kompilering tidspunktene som er lengre enn i tidligere versjoner av SQL Server.

Denne økningen i kompileringstiden er motregnet av en nedgang i kjøretiden for de fleste spørringer. Den samlede effekten er at spørringen kjører raskere enn i tidligere versjoner av SQL Server. Det skjer imidlertid ett unntak med svært små, enkle, OLTP-type spørringer som har en svært lav kjøringstider. For disse spørringene, kan prosessen med å generere en spørringsplan er en utgift likt eller større enn spørjinga. Resultatet av spørringen kan utføre litt langsommere enn i tidligere versjoner av SQL Server. Forskjellen er vanligvis i millisekunder, disse effektene er ikke lagt merke til for en bestemt spørring hvis den utføres enkeltvis. Du kan legge merke til at hele systemet CPU-bruk er høyere enn i tidligere versjoner av SQL Server hvis store tall for ad hoc-spørringer utføres samtidig med et høyt antall brukere.

Utvikle parameteriserte spørringer

SQL Server 7.0 bruker nye teknikker, for eksempel bufring ad hoc-spørringer og automatisk parameterne. Spørringene som SQL Server 7.0 automatisk parameterizes er imidlertid begrenset. Bruk følgende metoder for å sikre at spørringen planene er parametriserte og kan brukes mer effektivt:
  • Parametermerker Tillater parametere angis med et spørsmålstegn når brukere sender spørringer både OLE DB og ODBC-APIer. Dette kan være svært nyttig i alle programmer, spesielt for midt-tier-programmer som har spørringen generasjon moduler der bruke lagrede prosedyrer ikke er tilgjengelig. Spørringsplanen som er generert for spørringer som har parametermerker kan brukes på nytt av alle klienter som kjører den samme spørringen, selv om ulike parameterverdier er angitt. Hvis du vil ha mer informasjon, se emnet "Parametermerker" i SQL Server 7.0 Books Online.
  • sp_executesql Sp_executesql lagret prosedyren kalles av ODBC-driver eller OLE DB-leverandøren når parametermerker brukes i et program. Men kan det også kalles direkte av programmet eller i en annen lagret prosedyre for å eksplisitt parameterisere ad hoc-spørringer. Dette kan være svært nyttig i programmer eller satsvise filer der EXECUTE-setningen er brukt til å utføre dynamiske SQL-setninger. I motsetning til sp_executesqltillater ikke EXECUTE-setningen parameterne. Dette begrenser risikoen for spørringen plan gjenbruk. Hvis du vil ha mer informasjon, se "sp_executesql (T-SQL)" og "Via sp_executesql" emner i SQL Server 7.0 Books Online.
  • Lagrede prosedyrer Lagrede prosedyrer har mange fordeler, inkludert muligheten til å parameterisere spørringer og gjenbruke kjøring av planer. Hvis du vil ha mer informasjon, se "Lagrede prosedyrer" og "Programming lagrede prosedyrer" emner i SQL Server 7.0 Books Online.

Vis data for Ytelsesmåler

Bruke Ytelsesmåler-loggen til å finne ut hvilke systemressurser som forårsaker flaskehalsen. Ytelsesmåler-loggen kan gi deg en god oversikt over systemet og hjelpe rette oppmerksomheten mot når du viser dataene SQL-Profiler. Se gjennom data for Ytelsesmåler fra tidspunktet da det ble godt gjennom tiden ytelsen redusert ytelse. Angi telleren som ble påvirket først, og deretter bestemmer du hvilke av følgende problemer som er mest relevant for din situasjon:
  • Objekt: prosessen
    Teller: prosessor
    Forekomst: SQLServer
  • Objekt: prosessor
    Telleren: % prosessortid
    Forekomst: Kontrollere hver forekomst av prosessor
  • Objekt: SQL Server: bufferen Manager
    Teller: Ledige buffere
  • Objekt: SQL Server: bufferen Manager
    Teller: Stjålet sideantall
  • Objekt: SQL Server: minnebehandling
    Teller: Minne gir venter
  • -Objektet: Statistikk for SQL Server: SQL
    Teller: SQL samlinger/sek
Hvis prosessorbruk, SQL samlinger/sek og ledige buffere tellere er høy, og minne gir ventende og stjålet sideantall tellerne er lav, indikerer dette at Prosessoren er flaskehalsen. Fokusere på hvordan du effektivt parameterisere og gjenbruke spørringsplaner å unngå kostnaden for en spørringsplan og se delen "Grupper Profiler for SQL-spor etter hendelsesklasse" i denne artikkelen. Hvis den ledige buffere og tellere for SQL spørringskompileringer/sek er lav, og stjålet sideantall og minne gir ventende tellerne er høy, er SQL Server minne begrenset. Fokuser på å finne spørringer der hash sammenføyninger som brukes og kan endres for å gjenta sammenføyninger, og se delen "Grupper Profiler for SQL-spor etter varighet" i denne artikkelen. Hvis du vil ha mer informasjon om disse tellerne, kan du bruke navnet på telleren for å søke SQL Server 7.0 Books Online.

Vis Profiler for SQL-data

Når du løser problemer med ytelse, er det svært viktig å vise data for SQL-Profiler. Du trenger ikke å gå gjennom alle data som du har tatt opp; være selektiv. SQL-Profiler hjelper deg med å vise opptaksdata effektivt. I kategorien Egenskaper (på den
Fil -menyen, velg Egenskaper), SQL-Profiler kan du begrense dataene som vises ved å fjerne datakolonner eller hendelser, gruppering eller sortering etter datakolonner og bruke filtre. Du kan søke i hele sporet eller bare en bestemt kolonne for bestemte verdier (på den
Rediger -menyen velger du Søk ). Du kan også lagre Profiler for SQL-data til en SQL Server-tabell (Velg Lagre somfil -menyen, og deretter klikker du Spor-tabellen), og deretter kjøre SQL-spørringer mot den.

Obs! Kontroller at du bare vil filtrere lagrede loggfiler. Hvis du følger disse trinnene på en aktiv spor, risikerer du å miste dataene som ble tatt siden sporingen ble startet. Lagre et aktivt spor i en fil eller tabellen først (på den
Fil -menyen klikker du Lagre som ), og åpne den på nytt (Klikk Åpnefil -menyen) før du fortsetter. Når du arbeider med lagrede loggfiler, fjerner filtreringen permanent ikke data. dataene er bare skjult, og ikke slettet. Du kan legge til og fjerne hendelser og datakolonner for å fokusere ditt søk.

Du bør også fokusere på områdene der du får størst fordel. Følgende faktorer kan bidra til å øke ytelsen i programmet, men ikke nødvendigvis samme grad. Før du implementerer endringer, kan du finne ut hvor effektive endringene kan være avhengig av følgende faktorer:
  • Hvor ofte spørringen kjører
  • Hvor mye forbedring spørringen kan forbedres.
For eksempel kan å redusere kjøringstid for en enkelt spørring fra 1,5 sekunder til 1,2 sekunder ikke være nyttig hvis spørringen ikke utføres ofte i løpet av dagen. Imidlertid kan, hvis spørringen kjøres veldig ofte av et høyt antall samtidige brukere, forbedring i systemytelsen være svært effektive. Forbedring av en enkelt spørring fra 6 minutter til 3 sekunder kan derimot ikke gir en merkbar økning i generelle ytelsen hvis det brukes sjelden. Bruke gruppering og filtrering teknikker i SQL-Profiler og dine kunnskaper om programmet til å beregne effekten av en bestemt spørring eller prosedyre før du implementerer endringer. Fokusere på de mest effektive endringene først, og fortsett deretter med gjentakelser gjennom andre spørringer og prosedyrer til du kommer til et nivå der ytelsen er forbedret tilstrekkelig.

Når du lagrer en sporing av SQL-Profiler til en fil eller en tabell, åpner du sporing i SQL-Profiler og se gjennom innholdet. Hvis du vil gruppere Profiler for SQL-spor, følger du denne fremgangsmåten:
  • Gruppere SQL Profiler sporingen av varighet:
    1. Klikk på fil -menyen
      Egenskaper.
    2. Velg kategorien Kolonner med Data , og klikk deretter opp å gå under grupper
      Varighet. Velg ned for å fjerne alle andre kolonner.
    3. Velg kategorien hendelser , og fjern deretter alle hendelser unntatt TSQL SQL:StmtCompleted og TSQL RPC: fullført. Dette gjør at du kan fokusere på bare spørringer som kjøres.
    4. Klikk OK.
    Gruppering av varighet tillater til enkelt for å se SQL-setninger, kladder og prosedyrer som kjører den slowest. Se sporet når problemet oppstår, og opprette en opprinnelig plan for god ytelse. Du kan filtrere etter starttidspunktet til å dele sporet i inndelinger når ytelsen er god og separate deler når ytelsen er dårlig. Se etter spørringer til den lengste varigheten når ytelsen er god. Dette er mest sannsynlig roten av problemet. Når systemytelsen synker, kan selv god spørringer vise lang varighet fordi de venter for systemressurser.

    Se gjennom kjøring av planene for spørringer som er at de fleste vanlige har lang varighet. Hvis du ser at en hash-sammenføyning som brukes, kan du vurdere å bruke LOOP sammenføyning spørringen tips til å tvinge en nestet løkke sammenføyning for spørringen. Hvis kjøringstid for spørringen ved hjelp av en løkke-sammenføyning er mindre enn, lik eller enda litt høyere enn utførelsestid med hash-sammenføyning, kan en løkke join kan være et bedre alternativ hvis datamaskinen har høy minne og CPU-bruken. Ved å redusere belastningen på flaskehalsen ressurs (CPU og minne), kan du forbedre systemytelsen. Hvis du vil ha mer informasjon om tipset LØKKE bli med i spørringen, kan du se emnet "VELGE (T-SQL)" i SQL Server 7.0 Books Online.
  • Gruppere Profiler for SQL-spor etter hendelsesklasse:
    1. Klikk på fil -menyen
      Egenskaper.
    2. Velg kategorien Kolonner med Data , og klikk deretter opp å gå under grupper -overskriften
      Hendelsesklassen og tekst med Hendelsesklasse på toppen. Velg ned for å fjerne alle kolonner under grupper -overskriften.
    3. Velg kategorien hendelser , og kontroller at alle hendelser er inkludert.
    4. Klikk OK.

Typer hendelser

Se hvilke typer hendelser oppstår på datamaskinen som kjører SQL Server, og hvor ofte hendelsene oppstår, grupper etter kolonnen Hendelsesklasse . Søk i denne kolonnen for følgende hendelser:
  • DIVERSE: forberede SQL og Exec forberedte SQL; MARKØRER: Cursorprepare en Forberede SQL -hendelse angir at en SQL-setning ble klargjort for bruk med et standard resultatsett (klientsidemarkør) ved hjelp av SQLPrepare/SQLExecute (for ODBC) eller ICommandText::Prepare/ICommandText::Execute (for OLE DB) med alternativene standard markøren: fremover, skrivebeskyttet, radsett størrelse = 1. En Cursorprepare -hendelse angir at en markør på serversiden ble forberedt på en SQL-setning som bruker SQLPrepare/SQLExecute (for ODBC) eller ICommandText::Prepare/ICommandText::Execute (for OLE DB) med en tidligere markøren alternativene som angis en ikke-standard verdi. En Exec forberedte SQL -hendelse angir enten av tidligere eksisterende klargjorte setninger ble utført. Hvis du ser hyppige forekomster av disse hendelsene, bruker programmet Forbered/kjøre modellen når du åpner resultatsett. I så fall må du bestemme om du bruker modellen Forbered/kjøre på riktig måte.

    Ideelt sett er et program som forbereder en SQL-setning i en gang og utfører den mange ganger slik at optimaliseringen ikke trenger å kompilere en ny plan hver gang at setningen er utført. Hver gang du kjører en klargjort setning lagre du kostnaden for spørring-kompilering. Hvis du bare vil utføre én gang i en spørring, anbefaler Microsoft at du ikke klargjøre den. Forbereder og deretter kjøre en SQL-setning krever tre nettverk rundturer: ett til å klargjøre setningen, en til å utføre oppgaven, og en til unprepare i setningen. Forbereder markører på serversiden krever minst fem rundturer: ett til å klargjøre markøren, til å kjøre, eller åpne den, én eller flere å hente fra den, én for å lukke den og ett til unprepare den. Kjører spørringen bare krever én rundtur.

    Hvis du vil se hvor effektivt programmet bruker Forbered/kjøre modellen, kan du sammenligne antall ganger disse to hendelsene (forberede- og kjøretilgang) inntreffer. Antall hendelser som Exec forberedte SQL bør være mye større enn summen av Forberede SQL og CursorPrepare hendelser (minst tre til fem ganger større er et godt estimat). Dette angir at klargjorte setninger, som brukes på nytt ofte nok for å overkomme den økte overhead å opprette dem. Hvis antall hendelser som Klargjør SQL - og CursorPrepare er omtrent lik antallet Exec forberedte SQL -hendelser, kan dette bety at programmet ikke bruker modellen Forbered/kjøre effektivt. Prøv å lage en setning én gang og bruke den så mye som mulig på nytt. Du kan også endre programmet til å klargjøre setninger én gang og bruke disse setningene.

    Programmet må være skrevet spesielt til å bruke modellen Forbered/kjøre effektivt. Levetiden til en referanse til en klargjort setning blir kontrollert av hvor lenge du holder HSTMT åpne i ODBC- eller ICommandText-objekt i OLE DB. En vanlig praksis er å få tak i en HSTMT, forberede en SQL-setning, utføre forberedt setning og frigjøre HSTMT, og dermed miste håndtaket til forberedt plan. Hvis du gjør dette, får du ikke noen fordel fra modellen Forbered/kjøre. Du kan faktisk se en nedgang i ytelsen på grunn av ekstra belastning med nettverk-rundturer. Programmet må ha en metode til å hurtigbufre HSTMT eller objekt med klargjort setning håndtaket og tilgang til dem for gjenbruk. Driveren eller leverandøren gjør ikke dette automatisk. Programmet er ansvarlig for å implementere, vedlikeholde og bruke denne informasjonen. Hvis programmet ikke gjør dette, kan du vurdere å bruke parametermerker i stedet for å klargjøre/execute-metode.
  • Bruker parametermerker Programmer kan bruke parametermerker for å optimalisere bruk av den samme Transact-SQL-setningen flere ganger med ulike inndata- og utdataverdier. Første gang en spørring kjøres, det er laget som en parameterisert spørring, og SQL Server genererer og bufrer en parameterisert plan for spørringen. Etterfølgende kall til samme spørring ved å bruke enten samme eller forskjellige parameterne er SQL Server ikke til å generere en ny spørringsplan; SQL Server kan bruke eksisterende spørringsplanen på nytt ved å erstatte de gjeldende parametrene.

    Hvis programmet bruker parametermerker med kall til SQLExecDirect (for ODBC) eller ICommandText::Execute (for OLE DB), driver eller leverandøren automatisk pakker SQL-setningen og utfører det som et sp_executesql kall. Setningen trenger ikke å være forberedt og kjøres separat. Når SQL-serveren mottar et kall til sp_executesql, den automatisk kontrollerer prosedyrebufferen for en samsvarende plan og blir brukt som planen eller genererer en ny plan.

    Å avgjøre Hvis programmet bruker parametermerker for øyeblikket, kan du søke i
    Tekst -kolonne i SQL-Profiler-spor for "sp_executesql". Fordi sp_executesql kan kalles direkte, viser ikke alle forekomster bruken av parametermerker.

    Hvis du vil ha mer informasjon om Forbered/kjøre modellen, kan du se emnet "Kjøring av planlegger bufring og bruke på nytt" i SQL Server 7.0 Books Online. Hvis du vil ha mer informasjon om parametermerker, kan du se emnet "Parametermerker" i SQL Server 7.0 Books Online.
  • SP: fullført Dynamisk SQL-setninger som utføres med kommandoen Kjør vises som en SP: fullført hendelse med teksten "Dynamiske SQL." Utvid den SP: fullført hendelsen, og deretter søke etter alle forekomster som har "Dynamiske SQL" som tekst. Hvis det er mange av disse hendelsene, kan det være at du kan forbedre ytelsen ved å bruke sp_executesql i stedet for EXECUTE-setningen. Sp_executesql lagret prosedyren gir SQL Server på nytt planer for kjøring av kode hvis den samme spørringen utføres på nytt ved hjelp av ulike parametere. Når du bruker EXECUTE-setningen, parametriseres ikke planen, og det brukes ikke på nytt Hvis spørringen utføres på nytt med de samme parameterne.

    Hvis du vil fastslå spørringer eller prosedyrer som bruker dynamiske SQL-hendelser med EXECUTE-setningen, noter tilkoblings-ID og starttid for for hver hendelse. Dele opp sporet (Fjern Hendelsesklasse og tekst fra grupper -overskriften). Når du deler opp sporet, sorteres den i kronologisk rekkefølge. Du kan filtrere sporingen av tilkoblings-ID (på fanebladet filtre ), og fjern deretter alle hendelsesklasser bortsett fra den SP: fra og SP: fullført hendelser for bedre lesbarhet. Du kan deretter søke etter starttid for hendelsen (Klikk på Rediger -menyen
    Søk etter). Resultatene viser når den dynamiske SQL-hendelsen startes. Hvis hendelsen oppstod i en lagret prosedyre, hendelsen vises mellom den SP: fra og SP: fullført hendelser for denne prosedyren. Hvis hendelsen ikke forekommer i en lagret prosedyre, det ble utført som et ad hoc-spørring, og du kan bruke andre datakolonnene (Programnavn, NT-brukernavnog andre) for å finne ut hvor kommandoen ble utført. For å finne teksten i kommandoen og konteksten der det ble utført, kan du også legge til klasser, for eksempel SQL:BatchCompleted og SQL:RPCCompleted.

    Når du finner ut hvor EXECUTE-setningen blir brukt, kan du vurdere å erstatte det med et kall til sp_executesql. Vurder for eksempel følgende scenario der kommandoen Kjør brukes med dynamiske SQL. En prosedyre tar et tabellnavn, ID og idValue som inndataparametere, og utfører deretter en SELECT-setning i tabell basert på ID-verdien. Fremgangsmåten ser bruker en EXECUTE-setningen, ut som følgende kode:
    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
    Forutsatt at spørringen ikke parametriseres automatisk, hvis du utfører denne prosedyren mot titler -tabellen i eksempeldatabasen pubs for to ganger med forskjellige verdier for parameteren @idValue , SQL Server må generere et separate spørringsplan for hver kjøring. For eksempel:
    exec dynamicUsingEXECUTE
    'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    'title_id', 'BU7832'
    Obs! Spørringen er så enkelt at SQL Server kan parameterisere det automatisk og gjenbruke faktisk utførelsesplanen i dette eksemplet. Men hvis dette var en sammensatt spørring SQL Server ikke kan automatisk parameterisere, kan SQL Server ikke bruke den planen for å utføre andre Hvis parameteren @idValue ble endret. Følgende enkle spørringer begrenser kompleksiteten i eksemplet.

    Du kan skrive om denne fremgangsmåten for å bruke sp_executesql i stedet for EXECUTE-setningen. Støtte for parameteren erstatning gjør sp_executesql mer effektiv fordi den genererer kjøring av planer som er mer sannsynlig til å brukes av SQL Server. For eksempel:
    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'
    I dette eksemplet genererer første gang sp_executesql -setningen er utført, SQL Server en parameterisert plan for SELECT-setningen fra titler med title_id som parameteren. For å utføre andre, bruker SQL Server på nytt planen med den nye parameterverdien. Hvis du vil ha mer informasjon om sp_executesql, kan du se "sp_executesql (T-SQL)" og "Via sp_executesql" emner i SQL Server 7.0 Books Online.
  • SP:RECOMPILES Denne hendelsen angir at en lagret prosedyre ble kompilert på nytt under kjøring. Mange ny kompilering hendelser angir at SQL Server bruker ressurser for kompilering av spørringen i stedet for kjøring av spørringen.
Hvis du ikke ser noen av disse hendelsene, utfører programmet bare ad hoc-spørringer mot SQL Server. Hvis SQL Server bestemmer at det automatisk kan parameterisere bestemte spørringer, eller hvis de samme parameterne som brukes flere ganger, krever hver spørring som utføres SQL Server til å generere en ny plan for kjøring av kode. SQL Server Performance Monitor skal vise mange SQL samlinger/sek. Dette kan være CPU-intensive for mange samtidige brukere. Hvis du vil omgå dette problemet, finner du mest vanlige kjøres spørringer, og vurdere å opprette lagrede prosedyrer for disse spørringene bruker parametermerker, eller ved hjelp av sp_executesql.

Referanser


Hvis du vil ha mer informasjon om overvåking og feilsøking av ytelsesproblemer med i SQL Server, klikker du artikkelnumrene nedenfor for å vise artiklene i Microsoft Knowledge Base:

224587 hvordan du feilsøker programytelse med SQL Server

224453 INF: Forstå og løse SQL Server 7.0 eller 2000 blokkerende problemer

243586 feilsøking lagret prosedyre kompileres på nytt

243589 hvordan du feilsøker treg kjører spørringer på SQL Server 7.0 eller senere

251004 INF: hvordan du overvåker blokkering av SQL Server 7.0