Als DBA is het aanpakken van prestatieproblemen vaak een reactieve gebeurtenis; probleem optreedt, moet u reageren. Soms kijkt u naar een SQL Server-instantie die u goed kent, soms is het uw eerste kennismaking met een omgeving. Dit komt ook voor in de advieswereld. Bij het helpen van een vaste klant heb ik de details over het milieu al opgeslagen. Wanneer we echter een e-mail ontvangen van iemand met wie we nog niet eerder hebben gewerkt, en het is een noodsituatie waarin ze onmiddellijke hulp willen, hebben we geen achtergrond over het milieu en hebben we geen idee waar we tegenaan lopen. We bieden hulp zonder het uitgebreide gegevensverzamelings- en analyseproces te doorlopen waarmee elke nieuwe klantbetrokkenheid begint.
Om deze reden heb ik een set van vijf items die ik onmiddellijk controleer wanneer ik een nieuwe omgeving confronteer. De informatie die ik verzamel, vormt de basis voor hoe ik het oplossen van problemen in de toekomst benader, en hoewel het zelden HET aangeeft specifiek probleem, helpt het me uit te sluiten wat NIET is het probleem, dat soms net zo belangrijk is.
Methoden voor het verzamelen van gegevens
Ik erken dat iedereen een andere benadering heeft bij het aanpakken van een nieuwe omgeving. Er zijn verschillende gratis, algemeen beschikbare scripts die u kunt downloaden en uitvoeren om u de "lay of the land" voor een SQL Server-instantie te geven (denk aan Glenn Berry's DMV-scripts). De focus ligt hier niet op hoe u verzamelt de gegevens, het is wat gegevens die u verzamelt en wat u eerst analyseert .
Servereigenschappen
Het allereerste dat ik wil weten als ik naar een instance kijk, is de versie en editie van SQL Server. De snelste manier om deze informatie te krijgen is door het volgende uit te voeren:
SELECT @@VERSION;
Met deze uitvoer kan ik de build controleren om te bepalen welke servicepacks, cumulatieve updates en hotfixes zijn toegepast, en weet ik welke editie wordt gebruikt. Ik wil ook graag weten of de instantie geclusterd is, dus ik voer ook uit:
SELECT SERVERPROPERTY('IsClustered'); Ik heb deze informatie soms van de klant, maar het kan nooit kwaad om te verifiëren, omdat versie en editie van invloed kunnen zijn op volgende stappen voor probleemoplossing en aanbevelingen. Een klant heeft bijvoorbeeld onlangs contact met ons opgenomen over een intermitterend prestatieprobleem dat ze zagen met SQL Server 2008. Een snelle controle van de versie onthulde dat ze SQL Server 2008 SP3 gebruikten en dat er verschillende cumulatieve updates zijn uitgebracht na SP3 die een reeks van prestatie problemen. Hoewel ik meer informatie verzamelde voordat ik de aanbeveling deed dat ze de nieuwste CU toepassen, was dit een onmiddellijke waarschuwing over wat het probleem zou kunnen veroorzaken.
sys.configuraties
Deze catalogusweergave helpt voort te bouwen op de basis die is begonnen met servereigenschappen, en helpt ons te begrijpen hoe de instantie is geconfigureerd. Met deze weergave zoek ik naar instellingen die zijn gewijzigd ten opzichte van de standaardwaarden, maar dat niet hadden moeten zijn, en instellingen die niet hebben gewijzigd, maar zou moeten.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Houd rekening met de instelling max. servergeheugen (MB), die de hoeveelheid geheugen beperkt die beschikbaar is voor de bufferpool. De standaardwaarde is 2147483647, maar deze moet worden gewijzigd in een waarde die kleiner is dan het totale geheugen op de server om ervoor te zorgen dat er voldoende geheugen is voor het besturingssysteem, andere toepassingen en andere SQL Server-taken waarvoor geheugen nodig is dat niet uit de bufferpool wordt gehaald . Voor hulp bij het instellen van de juiste waarde voor max. servergeheugen (MB), raad ik Jonathan's post aan:Hoeveel geheugen heeft mijn SQL Server eigenlijk nodig?
Omgekeerd is de instelling voor prioriteitsversterking standaard nul en moet deze altijd als zodanig worden gelaten. Microsoft raadt zelfs aan om deze niet te wijzigen, en de optie zal in een toekomstige versie van SQL Server worden verwijderd.
sys.databases
Nadat ik begrijp hoe de instantie is geconfigureerd, kijk ik vervolgens wat er op databaseniveau bestaat.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Als ik de uitvoer van deze catalogusweergave bekijk, zoek ik naar anti-patronen - alles dat eruit springt als onverwacht of atypisch - in de gegevens. De output is bevorderlijk voor een snelle analyse – veel van de instellingen vermelden een 0 of 1 voor de waarde (uit of aan) en ik maak een mentale notitie van wat er anders is. Ik verwacht dat statistieken automatisch maken en statistieken automatisch bijwerken zijn ingeschakeld (ingesteld op 1). Ik verwacht dat automatisch sluiten en automatisch verkleinen worden uitgeschakeld (ingesteld op 0). Ik kijk om te zien wat de sortering is voor de gebruikersdatabases, met name of ze allemaal dezelfde sortering hebben en of die sortering hetzelfde is als tempdb. Ik merk ook beveiligingsopties op, zoals cross-database chaining en de optie is_trustworthy, beide standaard uitgeschakeld (0). Als ik merk dat een van deze instellingen afwijkt van wat ik verwacht, noteer ik dat en ga ik verder. Ik stop op geen enkel moment met mijn verzameling of analyse om iets te veranderen, want ik verzamel gewoon zo snel mogelijk informatie om een goed begrip van de omgeving te krijgen.
Naast het controleren van de instellingen voor de databases, let ik ook op het aantal gebruikersdatabases. Er is geen "juist aantal" gebruikersdatabases voor een instantie - een instantie kan slecht presteren met één database en kan wonderbaarlijk presteren met 100. Er zijn talloze factoren in het spel, en het aantal databases is gewoon een gegevenspunt vermeldenswaard.
Foutlogboeken
Ik geef toe dat ik de SQL Server ERRORLOG verwaarloosde; het was als een bijzaak toen ik een SQL Server-probleem onderzocht. Toen realiseerde ik me de fout van mijn wegen, en sindsdien heb ik het niet als vanzelfsprekend beschouwd. Ik heb de neiging om door Management Studio te navigeren om toegang te krijgen tot het logboek (in Management | SQL Server Logs), hoewel je de sp_readerrorlog opgeslagen procedure kunt gebruiken of naar het bestand kunt bladeren en het in je favoriete teksteditor kunt openen.
Binnen het ERRORLOG zoek ik naar recente fouten - bijvoorbeeld alles wat met geheugen te maken heeft - en ik kijk ook welke traceervlaggen, indien aanwezig, in gebruik zijn. Ik controleer ook of Pagina's vergrendelen in het geheugen is ingeschakeld, of de cache wordt leeggemaakt (met opzet of niet) en of er met regelmaat andere ongebruikelijke activiteiten plaatsvinden. Afhankelijk van hoe urgent het probleem is, kijk ik ook naar de Windows-logboeken (Event, Application en Security), wederom niet alleen op zoek naar fouten, maar ook naar onverwachte berichtpatronen.
Wachtstatistieken
Het laatste gebied van SQL Server dat ik bekijk wanneer ik naar een prestatieprobleem op een onbekende instantie kijk, zijn wachtstatistieken. Elke SQL Server-instantie heeft wachttijden - hoe goed de code ook is afgestemd, hoeveel hardware er ook achter zit. Als DBA wil je weten wat je typische wachttijden zijn voor een instantie, en als ik naar een nieuwe omgeving kijk, weet ik niet meteen of de wachttijden die ik zie typisch zijn, of vanwege het prestatieprobleem. Ik vraag de klant of ze de wachtstatistieken baseren, en zo niet, vraag ik of ik ze kan wissen en ze zich kan laten ophopen terwijl het prestatieprobleem zich voordoet. Om wachtstatistieken te controleren, kun je het script gebruiken in de post van Paul Randal waarnaar vaak wordt verwezen, of de versie in de DMV-query's van Glenn.
Nadat u de verzamelde wachtstatistieken hebt bekeken, heeft u het laatste stuk dat het "grote plaatje" van de SQL Server-instantie biedt, en de informatie die u nodig hebt om te beginnen met het oplossen van problemen. Het is niet ongebruikelijk om eerst de wachtstatistieken te controleren bij het oplossen van problemen, maar wachten alleen is niet voldoende informatie om te bepalen wat u vervolgens moet onderzoeken, tenzij u ook de basisconfiguratie van SQL Server begrijpt.
Volgende stappen
Zoals ik eerder al zei, is er meestal geen enkel gegeven dat u vertelt waar het prestatieprobleem ligt, het zijn meerdere verkregen gegevenspunten die u in de goede richting wijzen. Hoe u die informatie vastlegt, is aan u, maar zodra u de uitvoer bekijkt, moet u een goed begrip hebben van hoe de SQL Server-omgeving is geconfigureerd, en die kennis, in combinatie met de wachtstatistieken, kan u helpen beslissen wat u vervolgens moet onderzoeken. Het oplossen van problemen werkt het beste met een methodische aanpak, dus begin bij de basis en werk het uit, en als je denkt dat je de oorzaak hebt gevonden, graaf dan nog een klein beetje verder en vind een of twee extra bewijsstukken die je bevinding ondersteunen. Zodra u over die gegevens beschikt, kunt u een aanbeveling doen om het probleem te verbeteren of op te lossen.