INF: Microsoft SQL Server-prestaties optimaliseren

Vertaalde artikelen Vertaalde artikelen
Artikel ID: 110352 - Bekijk de producten waarop dit artikel van toepassing is.
Alles uitklappen | Alles samenvouwen

Op deze pagina

Samenvatting

U moet een effectief optimale prestaties van Microsoft SQL Server identificeren van de gebieden die de grootste prestaties via levert de meest uiteenlopende situaties en analyse van de focus op deze gebieden. Anders kan u veel tijd en moeite op onderwerpen die marktkennis geen aanzienlijke verbeteringen opleveren.

Voor het grootste deel, de volgende informatie heeft geen betrekking op de problemen met prestaties van gelijktijdige gebruikers. Dit is een afzonderlijke, complexe onderwerp waarvoor in het document 'maximaliseren Database consistent en gelijktijdigheid,"die kan worden gevonden in de SQL-Server versie 4.2 x "Programmer's Reference voor C," bijlage E, en ook in andere Knowledge Base-artikelen. Is niet in de documentatie voor versie 6.0, maar kunt u vinden op de MSDN (Microsoft Developer Network)-CD die onder titel.

In plaats van een theoretische discussie in dit artikel richt zich voornamelijk op gebieden met jaren ervaring door de ondersteuning voor Microsoft SQL Server-team praktische waarde in concrete situaties worden weergegeven.

Gebleken is dat het grootste voordeel in de prestaties van SQL Server kan worden ervaring van de algemene logische databaseontwerp, ontwerp voor de index Queryontwerp en het ontwerp van toepassing. Daarentegen de grootste prestaties problemen worden vaak veroorzaakt door gebreken in deze gebieden dezelfde. Als u betrokken prestaties, u te concentreren op deze gebieden eerst Omdat grote prestaties kunnen vaak worden bereikt met een relatief kleine tijd investering.

Buffers, terwijl andere prestaties op systeemniveau, zoals het geheugen problemen, de cache hardware, enzovoort, zijn zeker kandidaten voor onderzoek, ervaring geeft de winst van de prestaties van deze gebieden is vaak incrementele. SQL Server beheerd beschikbare resources automatisch voor de meest deel, verminderen de noodzaak (en dus het voordeel) van uitgebreide hand op systeemniveau afstemmen.

Microsoft SQL Server 6.0 biedt nieuwe mogelijkheden voor platform-laag prestatieverbeteringen met grote hoeveelheden geheugen, symmetrisch multiprocessing, parallelle gegevens scannen, optimizer verbeteringen en schijf striping. Zo groot als deze verbeteringen zijn, ze zijn echter in beperkte de scope. De snelste computer omlaag kan worden lopen met inefficiënte query's of een slecht ontworpen toepassing. Dus zelfs met de extra prestaties verhogen dat SQL Server 6.0 toestaat, is het uitermate belangrijk te optimaliseren de database, index, query en het ontwerp van toepassing.

De meeste problemen kunnen niet is opgelost met alleen een server-side focus. De server is in feite een 'puppet' van de client welke besturingselementen welke query's worden verzonden en daarmee welke vergrendelingen zijn verkregen en vrijgegeven. Hoewel sommige afstemmen op de server mogelijk is Meestal is afhankelijk van de succesvolle oplossing van problemen met prestaties op de overheersende rol ERKENNEND de client speelt in het probleem en gedrag van de toepassing client analyseren.

Meer informatie

Hier volgen enkele suggesties die op basis van ervaring, hebt aanzienlijke prestatieverhogingen:

Logische databaseontwerp wordt normaliseren

Redelijke normalisatie van de meest logische database ontwerp opbrengsten prestaties. Een groter aantal kleine tabellen is een kenmerk van een genormaliseerde database. Een kleiner aantal breed tabellen is een kenmerk van een Gedenormaliseerde database. Een zeer genormaliseerde database hoort regelmatig met complexe relationele joins waarmee prestaties kunnen schade. Echter, de SQL Server optimizer is zeer efficiënt op snelle en efficiënte joins selecteren als zolang als de indexen daadwerkelijk beschikbaar zijn.

De voordelen van normalisatie zijn:
  • Versnelt sorteren en index maken, omdat de tabellen zijn smaller.
  • U kunt meer geclusterde indexen omdat er meer tabellen.
  • Indexen doorgaans smaller en compacte.
  • Minder indexen per tabel, waardoor de prestaties van de UPDATE.
  • Minder Null-waarden en minder redundante gegevens, database kan verhogen.
  • Gelijktijdigheid gevolgen van DBCC diagnostics beperkt omdat de benodigde tabel vergrendelingen worden minder gegevens beïnvloeden.
Met SQL Server redelijke normalisatie vaak helpt dan hard prestaties. Als normalisatie toeneemt, zodat het aantal handelingen en de complexiteit van joins vereiste gegevens op te halen. Als een ruwe vuistregel, Microsoft uitoefening van het proces van normalisatie, tenzij hierdoor veel voorgesteld query's hebben vier punten of groter joins.

Als het databaseontwerp reeds vaste en totale is ontwerp niet haalbaar is het mogelijk een grote tabel selectief normaliseren als analyse toont een knelpunt op deze tabel. Als toegang tot de database uitgevoerd via opgeslagen procedures, kan dit schema wijzigen plaatsvinden zonder invloed op toepassingen. Als u niet het mogelijk is om te verbergen de door het maken van een weergave die lijkt op een enkele tabel wijzigen.

Efficiënte Index ontwerpen gebruiken

In tegenstelling tot vele niet-relationele systemen relationele indexen worden niet beschouwd als een deel van het databaseontwerp. Indexen kunnen worden verwijderd, toegevoegd, en zonder de schema- of ontwerpen van databases in een gewijzigd manier om andere dan de prestaties. Efficiënte index ontwerpen is uitermate belangrijk in goede prestaties van SQL Server bereiken. Om deze redenen dient u niet experimenteren met verschillende indexen altijd.

De optimizer kiest betrouwbaar de meest effectieve index in de meeste gevallen. De totale index ontwerpstrategie moet bieden een goede selectie van indexen voor het optimaliseren en vertrouwen te maken van het recht besluit. Dit vermindert de tijd voor analyse en geeft goede prestaties over een breed uiteenlopende situaties.

Er zijn aanbevelingen voor het ontwerpen van index:
  • Onderzoek de WHERE-component van een SQL-query's, omdat dit de de primaire focus van de optimizer.

    Elke kolom weergegeven in de WHERE-component is een mogelijke kandidaat voor een index. Als er te veel query's bekijken, kies een vertegenwoordiger instellen, of gewoon die langzaam. Als uw ontwikkeling hulpprogramma transparant SQL-code genereert dit moeilijker is. Veel van deze hulpprogramma 's de registratie van de gegenereerde SQL-syntaxis in een bestand of scherm voor toestaan foutopsporing. U wilt weten van de leverancier van het programma als Deze functie is beschikbaar.
  • Smalle index gebruiken.

    Smalle indexen zijn vaak effectief dan met meerdere kolommen, samengestelde indexen. Smalle indexen hebben meer rijen per pagina en minder index niveaus hogere prestaties.

    De optimizer kan snel en effectief analyseren honderden of zelfs duizenden van index- en join-mogelijkheden. Dat een groter aantal smalle indexen biedt de optimizer met meer mogelijkheden te kiezen uit, die meestal prestaties helpt. Minder breed, met meerdere kolommen hebben indexen, biedt het optimaliseren minder mogelijkheden kiezen welke prestaties mogelijk schade.

    Het is vaak beter niet aannemen van een strategie voor het benadrukken van volledig gedekt query. Het is waar dat als alle kolommen in uw SELECT-component worden gedekt door een niet-geclusterde index kunt de optimizer herkennen dit en bieden zeer goede prestaties. Maar dit leidt vaak tot extreem groot indexen en te veel afhankelijk van de mogelijkheid dat de optimizer Gebruik deze strategie. Meestal moet u meer talrijke smalle indexen die vaak beter via een breder bereik van query's.

    U moet geen indexen meer dan nodig zijn om voldoende prestaties door de betrokken bij het bijwerken van de overhead lezen indexen. Zelfs de meeste bewerkingen van de update-georiënteerde vereisen echter veel meer dan schrijven lezen. Aarzel dus niet om een nieuwe index als u denkt dat het zal helpen; u kunt altijd neer later.
  • Gebruik van geclusterde indexen.

    Gebruik van geclusterde indexen kan overeind verhogen prestaties. Zelfs UPDATE en DELETE-bewerkingen worden vaak door versnelde geclusterde indexen, omdat deze bewerkingen veel lezen. EEN één geclusterde index per tabel is toegestaan, dus verstandig gebruik deze index. Query's die veel rijen of query waarbij een reeks retourneren waarden, zijn goede kandidaten voor hardwareversnelling op een geclusterde index.

    Voorbeelden:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    De kolommen ACHTERNAAM of MEMBER_NO bovengenoemde zijn daarentegen waarschijnlijk niet geschikt voor een niet-geclusterde index als dit type query is gebruikelijk. Niet-gegroepeerde indexen gebruikt voor kolommen waarin enkele rijen worden geretourneerd.
  • Kolom uniekheid controleren.

    Dit helpt u bepalen welke kolom is een kandidaat voor een geclusterde index niet-geclusterde index of geen index.

    Hier volgt een van de voorbeeldquery kolom uniekheid controleren:
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    Dit geeft het aantal unieke waarden in de kolom. Vergelijken met het het totale aantal rijen in de tabel. 10.000-Rij-tabel 5.000 unieke waarden zou u de kolom een goede kandidaat voor een niet-geclusterde index. Aan op dezelfde tabel 20 unieke waarden wilt aanpassen een geclusterde index. Drie unieke waarden moeten helemaal niet worden geïndexeerd. Deze zijn alleen voorbeelden geen vaste en snelle regels. Vergeet niet om de indexen op de afzonderlijke kolommen weergegeven in de WHERE-componenten van de query's.
  • Verdeling van de gegevens in geïndexeerde kolommen onderzoeken.

    Een langdurige query treedt vaak op omdat een kolom met enkele unieke waarden geïndexeerd of een dergelijke kolom-JOIN wordt uitgevoerd. Dit is een fundamenteel probleem met de gegevens en de query zelf, en meestal zonder het identificeren van deze situatie worden opgelost. Bijvoorbeeld, een fysieke telefoonboek alfabetisch gesorteerd op achternaam zal niet versnellen opzoeken van een persoon als alle personen in de stad zijn naam gewoon 'Smith' of "Jansen". Naast de bovenstaande query geeft één getal voor kolom uniekheid kunt u een query GROEPEREN om de gegevens te bekijken verdeling van de geïndexeerde waarden. Dit biedt een hogere afbeelding van de gegevens en een betere kijk hoe de resolutie optimaliseren bekijkt gegevens.

    Het volgende is een voorbeeldquery om verspreiding van gegevens geïndexeerde waarden, uitgaande van een sleutel met twee kolommen op Kol1 Kol2:
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    Het resultaat is één rij voor elke waarde, met een aantal van de exemplaren van elke waarde. Om het aantal geretourneerde rijen beperken, kan handig zijn te sluiten met een HAVING-component. Voorbeeld van de component
          HAVING COUNT(*) > 1
    
    						
    Sluit alle rijen met een unieke sleutel.

    Het aantal rijen in een query wordt geretourneerd, is ook een belangrijke factor in Indexselectie. De optimizer beschouwt een niet-geclusterde index voor de kosten ten minste één pagina I/O per rij geretourneerd. Deze snelheid wordt snel efficiënter scannen van de hele tabel. Dit is een andere reden om beperken van de grootte van de resultaatset of grote resultaat vinden een geclusterde index.
Niet kan worden altijd vergeleken index gebruik met goede prestaties en omgekeerd. Als u altijd de beste prestaties, het optimaliseren van geproduceerd taak heel eenvoudig - zou worden altijd alle beschikbare index gebruiken. Werkelijk, zeer slechte prestaties kan leiden tot onjuiste keuze van geïndexeerde ophalen. De optimizer taak is daarom geïndexeerde ophalen selecteert waarbij wordt Help de prestaties en geïndexeerde ophalen wanneer deze schade zal voorkomen prestaties.

Efficiënt queryontwerp gebruiken

Sommige typen query's die intrinsiek bronintensief. Dit is gerelateerd aan fundamentele database en index problemen gemeenschappelijke meest relationele database management systems (RDBMSs) niet specifiek naar SQL Server. Ze zijn niet omdat de optimizer de query's in de meest voert inefficiënte efficiënte wijze mogelijk. Ze zijn echter intensief en de set-georiënteerde karakter van SQL kan doen inefficiënt worden weergegeven. Geen graad van Optimizer intelligence kunt elimineren van de inherente resourcekosten constructies. Ze zijn intrinsiek dure vergeleken met een meer eenvoudige query. Hoewel SQL Server de meest optimale toegang plan gebruikt, is dit afhankelijk van wat is fundamenteel mogelijk.

Bijvoorbeeld:
  • Grote resultaatsets
  • IN, niet IN en of query
  • Zeer niet-unieke WHERE-componenten
  • ! = vergelijkingsoperatoren (niet gelijk aan)
  • Bepaalde kolom functies als som
  • Conversies expressies of gegevens in een WHERE-component
  • Lokale variabelen in de WHERE-component
  • Complexe weergaven GROEPEREN
Verschillende factoren kunnen het gebruik van sommige van deze query gegevens noodzakelijk. De gevolgen van deze zal worden verminderd als de optimizer kunt beperken de resultaatset voordat u de resource-intensieve gedeelte van de query. De Hier volgen enkele voorbeelden.

Intensief:
   SELECT SUM(SALARY) FROM TABLE
				

Minder intensief:
   SELECT SUM(SALARY) FROM TABLE WHERE
   ZIP='98052'
				

Intensief:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

Minder intensief:
   SELECT * FROM TABLE
   WHERE LNAME=@VAR AND ZIP='98052'
				

In het eerste voorbeeld de som-bewerking kan niet worden versneld met een index. Elke rij moet worden gelezen en worden opgeteld. Ervan uitgaande dat er een index op de kolom ZIP de optimizer zal waarschijnlijk gebruik deze aanvankelijk beperken de resultaatset voordat u de som. Dit is veel sneller.

In het tweede voorbeeld is de lokale variabele tot runtime niet opgelost. Echter, de optimizer de keuze van toegang tot het uitvoeren kan niet uitstellen tijd; het te compileren kiezen. Nog tijdens het compileren, wanneer de toegang plan is opgebouwd, de waarde van @ VAR niet bekend is en derhalve niet kan worden gebruikt als invoer voor de index selecteren.

Het geïllustreerde techniek voor verbetering omvat het resultaat te beperken met een AND-component ingesteld. Gebruik een opgeslagen procedure als een alternatieve techniek en de waarde voor @ VAR als parameter doorgeven aan de opgeslagen procedure.

In sommige gevallen is het beter om een groep van eenvoudige query's gebruiken tijdelijke tabellen tussentijdse resultaten dan gebruiken om één zeer complexe query opslaan.

Grote resultaatsets zijn dure op de meeste RDBMSs. Probeer niet te retourneren een grote resultaatset naar de client voor de definitieve gegevens selecteren door te bladeren. Deze veel efficiënter beperken de grootte van het resultaat is ingesteld, zodat de databasesysteem voor de functie waarvoor deze is bestemd. Dit ook vermindert netwerk I/O en wordt de toepassing meer lenen implementatie via trage externe communicatieverbindingen. Het verbetert tevens gelijktijdigheid gerelateerde prestaties als de toepassing wordt geschaald omhoog meer gebruikers.

Gebruik de efficiënte toepassing ontwerpen

De rol die het ontwerp van toepassingen in de prestaties van SQL Server speelt kan niet worden genoeg benadrukt. In plaats van de afbeelding de server de overheersende rol is meer nauwkeurigheid van de client als een eenheid beheren en de server als afbeelding een puppet van de client. SQL Server is volledig onder de opdracht van de client met betrekking tot het type query's wanneer ze worden ingediend en hoe de resultaten zijn verwerkt. Dit heeft belangrijke gevolgen voor het type en de duur van vergrendelingen, de hoeveelheid I/O- en CPU-belasting op de server en dus of prestatie is goed of slecht.

Daarom is het belangrijk de juiste beslissingen tijdens de ontwerp-fase van toepassing. Maar zelfs als u problemen geconfronteerd Gebruik een Independant toepassing waarbij wijzigingen in de clienttoepassing lijken onmogelijk, dit verandert niet de fundamentele factoren die invloed hebben op prestaties - namelijk dat de client een overheersende rol en veel speelt prestatieproblemen kunnen niet worden opgelost zonder de wijzigingen van de client.

Met een goed ontworpen toepassing is SQL Server ondersteunen duizenden gelijktijdige gebruikers. Met een slecht ontworpen toepassing zelfs de meest krachtige serverplatform kunt met een paar bog omlaag gebruikers.

Biedt de volgende suggesties gebruiken voor client-toepassing ontwerpen goede prestaties van SQL Server:
  • Gebruik kleine resultaatsets. Het ophalen van onnodig grote resultaatsets (bijvoorbeeld duizenden rijen) voor het surfen op de client toegevoegd CPU en i/o-belasting netwerk, wordt de toepassing minder geschikt voor extern gebruik en schaalbaarheid voor meerdere gebruikers kunt beperken. Beter ontwerp de toepassing vraagt de gebruiker voldoende input, zodat die query 's worden ingediend die bescheiden resultaatsets genereren.

    Toepassing ontwerptechnieken vergemakkelijken opnemen beperken jokertekens worden gebruikt bij het samenstellen van query's met bepaalde input wachtwoordbeleid velden en prohibiting geïmproviseerde query's.
  • Dbcancel() goed in DB-Library-toepassingen gebruiken. Alle toepassingen annulering van een query uitgevoerd moet worden toegestaan. Geen toepassing moet dat de gebruiker opnieuw opstarten van de clientcomputer als een query wilt annuleren. Niet na dit beginsel kan leiden tot problemen met de prestaties die niet kunnen worden opgelost. Wanneer dbcancel() wordt gebruikt, de juiste zorg moet worden uitgeoefend met betrekking tot het transactieniveau van de. Raadpleeg voor meer informatie de volgende artikel in de Microsoft Knowledge Base:
    117143: INF: wanneer en hoe u dbcancel() of sqlcancel()
    Dezelfde problemen toepassen op ODBC-toepassingen als de ODBC-sqlcancel() aanroep wordt gebruikt.
  • Altijd alle resultaten volledig verwerken. Niet ontwerpen van een toepassing of gebruik een Independant toepassing stopt resultaatrijen zonder verwerking de query annuleren. Meestal zal doet leiden tot het blokkeren en vertragen prestaties.
  • Implementeer altijd een time-out voor query's. Query's uitvoeren niet toestaan onbepaalde tijd. Juiste DB-Library- of ODBC-oproepen instellen maken een time-out voor query's. In DB-Library, wordt dit gedaan met de aanroep van dbsettime() in ODBC met SQLSetStmtOption().
  • Gebruik een hulpprogramma voor het ontwikkelen die geen geen expliciete controle over de SQL-instructies verzonden naar de server. Niet een hulpprogramma dat transparant wordt gegenereerd op basis van hogere SQL-instructies gebruiken Level-objecten, tenzij deze essentiële functies biedt zoals een query annulering, time-out voor query's en volledige controle voor transactionele. Het is vaak niet mogelijk om goede prestaties te handhaven of op te lossen een prestatieprobleem als de toepassing door zelf genereert 'transparante SQL', omdat dit kan geen expliciete controle transactionele en vergrendelen kwesties die cruciaal voor de prestaties zijn afbeelding.
  • Niet intermix besluitvormingsondersteuning en online transaction processing Query's (OLTP).
  • Ontwerp van een toepassing of niet een Independant toepassing waardoor de gebruiker opnieuw opstarten van de clientcomputer als een query wilt annuleren. Dit kan leiden tot een aantal problemen die moeilijk op te lossen omdat mogelijke zwevende verbindingen. Zie voor meer informatie de volgende artikel in de Microsoft Knowledge Base:
    137983: Procedure zwevende verbindingen in SQL-Server oplossen

Technieken voor het analyseren van prestaties

Misschien verleidelijk om een prestatieprobleem uitsluitend door op systeemniveau afstemmen van de serverprestaties. Bijvoorbeeld hoeveel geheugen, het type bestand systeem, het aantal en type processors, enzovoort. De ervaring van Ondersteuning voor Microsoft SQL Server is gebleken dat de meeste problemen met prestaties kan niet op deze manier opgelost. Zij moeten worden opgelost door het analyseren van de toepassing, de query van de aanvraag aan de database indienen en hoe worden deze query's werken met het databaseschema.

Eerste, de query of query's die traag isoleren. Blijkt vaak dat een volledige toepassing is traag, wanneer alleen een paar van de SQL-query's traag zijn. Het is meestal niet mogelijk is zonder problemen oplossen het splitsen van het probleem en de trage query's te isoleren. Als er een ontwikkelprogramma's die ongemerkt SQL gebruik beschikbaar genereert diagnostische of debugmodus van het hulpprogramma voor het vastleggen van de gegenereerde SQL. In veel aanvragen traceren functies beschikbaar zijn, maar ze kunnen niet worden openlijk beschreven. Neem contact op met de technische ondersteuning voor uw toepassing om te bepalen of een trace functie bestaat voor de bewaking van de SQL-instructies gegenereerd door de toepassing.

Voor de toepassing ontwikkelprogramma's die gebruikmaken van ingesloten SQL, is dit veel SQL is gemakkelijker - openlijk zichtbaar.

Als uw ontwikkeling gereedschap of eindgebruikers de toepassing geen traceren functie, zijn er verschillende alternatieven:
  • De 4032-traceringsvlag volgens de instructies in de SQL gebruiken Server 4.2 x 'Troubleshooting Guide' en de SQL-Server 6.0 'Transact-SQL Reference'. Hierdoor is het vastleggen van SQL-instructies verzonden naar de server in het foutenlogboek van SQL.
  • De query's via een netwerkanalyse zoals Microsoft Network Monitor Netwerkcontrole van Systems Management Server.
  • Gebruik de ODBC Administrator-programma te selecteren voor ODBC-toepassingen ODBC-oproepen traceren. Zie de ODBC-documentatie voor meer informatie.
  • Gebruik een hulpprogramma van derden clientzijde die onderschept de SQL op de DB-Library- of ODBC-lagen. Een voorbeeld hiervan is de SQL-inspecteur van blauw Lagoon Software.
  • Gebruik het hulpmiddel SQLEye als voorbeeld in Microsoft TechNet-CD. Opmerking: SQLEye wordt niet ondersteund door Microsoft technische Ondersteuning.
Nadat de trage query geïsoleerd is, moet u het volgende doen:
  • De vermoedelijke trage query uitvoeren in isolatie, zoals met behulp van een query-hulpprogramma ISQL, en controleer of traag is. Vaak is het aanbevolen de query uitvoeren op de servercomputer zelf ISQL en lokale pijpen en leiden de uitvoer naar een bestand. Dit helpt complicatie factoren zoals elimineren netwerk en I/O scherm en toepassing resultaat bufferen.
  • STATISTIEKEN IO instellen op de I/O die wordt verbruikt door de query controleren gebruiken. U ziet het aantal logische pagina bewerkingen. De optimizer doel is minimum aantal I/O. Als u een record van de logische I/O telling. Deze formulieren een basislijn referentieoplossing voor verbetering. Het is vaak effectieve concentreren uitsluitend op de uitvoer van i/o-statistieken en experimenteren met verschillende query- en dan het gebruik van de SET SHOWPLAN OP. Kunnen interpreteren en effectief toepassen van de uitvoer van SHOWPLAN Sommige bestuderen en tijd kan efficiënter kan verbruiken empirische tests is besteed. Als uw prestatieprobleem niet is opgelost Deze eenvoudige aanbevelingen en u kunt SHOWPLAN meer grondig onderzoek optimizer gedrag.
  • Als u de query moet een weergave of opgeslagen procedure, de query ophalen de weergave of opgeslagen procedure en afzonderlijk uitvoeren. Hierdoor kan de toegang plan als u met verschillende indexen experimenteren wijzigen. Deze ook helpt de query zelf, en hoe het probleem lokaliseren de optimizer weergaven of opgeslagen procedures worden verwerkt. Als het probleem niet in de query zelf maar alleen wanneer de query wordt uitgevoerd als onderdeel van een weergave of opgeslagen procedure, die de query zelf helpt dit vaststellen.
  • Zich bewust zijn van mogelijke triggers op de betrokken tabellen kunnen transparant I/O genereren als de trigger wordt uitgevoerd. U moet verwijderen Triggers die betrokken zijn bij een trage query. Dit helpt te bepalen of het probleem is in de query zelf of de trigger of weergave en daarom helpt uw vestigen.
  • De indexen van de tabellen die worden gebruikt door de trage query bekijken. Gebruik de eerder genoemde technieken om te bepalen of deze goede indexen zijn en Wijzig deze indien nodig. Als een eerste inspanning probeert elke kolom in indexeren de WHERE-component. Vaak problemen worden veroorzaakt door gewoon niet een kolom die in de WHERE-component die is geïndexeerd of niet met een handig index op een dergelijke kolom.
  • Unieke gegevens met behulp van de query's die eerder zijn vermeld, onderzoeken en voor elke kolom die is vermeld in de WHERE-component, en vooral voor elke geïndexeerde kolom. In veel gevallen eenvoudige controle de query, tabel, indexen en gegevens worden het probleem onmiddellijk weergegeven veroorzaken. Prestatieproblemen worden bijvoorbeeld vaak veroorzaakt doordat een index op een sleutel met slechts drie of vier unieke waarden of het uitvoeren van een Deelnemen aan een dergelijke kolom of een uitzonderlijk groot aantal rijen retourneert de client.
  • Op basis van dit onderzoek, eventueel wijzigingen aanbrengen aan de toepassing query of indexen. Na de wijziging opnieuw uitvoeren en observeren elke wijziging in aantal I/O.
  • Na het uitvoeren van de hoofdtoepassing als algehele verbetering waarbij de prestaties zijn beter.
Het programma voor i/o- of CPU-gebonden gedrag controleren. Het is vaak handig om bepalen of een query i/o- of CPU-gebonden is. Dit helpt de verbetering te concentreren de inspanningen op het knelpunt true. Bijvoorbeeld, als een query is CPU afhankelijk, meer geheugen toevoegen aan SQL Server zal waarschijnlijk niet verbeteren, omdat er meer geheugen alleen verbetert de verhouding treffers voor de cache, die in dit geval al is hoog.

Hoe I/O Query versus CPU-gebonden probleem onderzoeken:
  • Met Windows NT Prestatiemeter kunt watch I/O versus CPU-activiteit. Bekijk alle exemplaren van het item % Schijftijd"van de logische schijf object. Bekijk ook de "% Totaal processortijd ' teller van het systeem object. Geldige schijf prestatiegegevens wilt bekijken, moet u de instelling van de Windows NT DISKPERF eerder ingeschakeld door "diskperf -Y" vanaf een opdrachtprompt en opnieuw opstarten van het systeem. Zie de Windows NT-documentatie voor meer informatie.
  • Terwijl de query wordt uitgevoerd als de grafiek CPU voortdurend hoog (voor bijvoorbeeld, meer dan 70 procent) en de waarde '% schijftijd consistent lage dit geeft de status van een CPU-gebonden.
  • Terwijl de query wordt uitgevoerd als het CPU-grafiek voortdurend lage (voor bijvoorbeeld minder dan 50 procent), en het % schijftijd constant Hoog, dit geeft dat een I/O staat gebonden.
  • Vergelijk het diagram CPU statistieken i/o-gegevens.

Conclusie

SQL Server kan zeer hoge prestaties voor grote databases. Dit is met name het geval met SQL Server 6.0. Met deze prestaties potentiële, moet u efficiënte database, index en toepassing ontwerp. Deze gebieden zijn de beste kandidaten voor het verkrijgen van aanzienlijke prestatieverbetering van de. Probeer elke query zo efficiënt mogelijk te maken dat wanneer uw toepassing schaalvergroting van meer gebruikers, de collectieve gebruikers laden is gefundeerde. Studie van het gedrag van de toepassing client de query's ingediend door de toepassing en experimenten met indexen Gebruik de richtlijnen in dit document wordt geadviseerd. Een methodische aanpak bij het analyseren van problemen wordt vaak aanzienlijk rendement verbetering voor relatief weinig tijd investering.

Eigenschappen

Artikel ID: 110352 - Laatste beoordeling: maandag 9 juli 2012 - Wijziging: 4.0
De informatie in dit artikel is van toepassing op:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Trefwoorden: 
kbinfo kbother kbmt KB110352 KbMtnl
Automatisch vertaald artikel
BELANGRIJK: Dit artikel is vertaald door de vertaalmachine software van Microsoft in plaats van door een professionele vertaler. Microsoft biedt u professioneel vertaalde artikelen en artikelen vertaald door de vertaalmachine, zodat u toegang heeft tot al onze knowledge base artikelen in uw eigen taal. Artikelen vertaald door de vertaalmachine zijn niet altijd perfect vertaald. Deze artikelen kunnen fouten bevatten in de vocabulaire, zinsopbouw en grammatica en kunnen lijken op hoe een anderstalige de taal spreekt en schrijft. Microsoft is niet verantwoordelijk voor onnauwkeurigheden, fouten en schade ontstaan door een incorrecte vertaling van de content of het gebruik ervan door onze klanten. Microsoft past continue de kwaliteit van de vertaalmachine software aan door deze te updaten.
De Engelstalige versie van dit artikel is de volgende: 110352
Vrijwaring inhoud KB-artikelen over niet langer ondersteunde producten
Dit artikel heeft betrekking op producten waarvoor Microsoft geen ondersteuning meer biedt. Daarom wordt dit artikel alleen in de huidige vorm aangeboden en wordt het niet meer bijgewerkt.

Geef ons feedback

 

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