Het oplossen van problemen met prestaties is een kunst en een wetenschap. De kunst komt voort uit ervaring (en leren van de ervaringen van anderen) en de wetenschap komt voort uit bekende richtlijnen over wat te doen in welke scenario's.
Of dat is tenminste wat ik graag denk en lesgeef.
In werkelijkheid oefenen veel DBA's en ontwikkelaars wat ik 'knee-jerk performance troubleshooting' noem. Dit gebeurt vaak wanneer een prestatieprobleem de kritieke fase heeft bereikt met bijvoorbeeld een time-out van query's, processen die traag verlopen of falen, gebruikers ontevreden zijn en het management snel antwoorden en actie wil!
De 'knie-jerk' komt van het doen van een oppervlakkige analyse van het probleem en tot de conclusie komen (eigenlijk is het grijpen naar een strohalm) dat het meest voorkomende symptoom de hoofdoorzaak moet zijn en proberen dat aan te pakken, zonder of met weinig resultaat, vaak met behulp van misleidend of ronduit onjuist advies dat online is gevonden. Dit leidt tot veel frustratie en tijdverspilling, en leidt vaak tot geldverspilling wanneer de organisatie besluit om hardware op het probleem te gooien door de server en/of het I/O-subsysteem te upgraden, om vervolgens te ontdekken dat het probleem er nog steeds is , of verschijnt vrij snel weer.
Analyse van wachtstatistieken is een van de gebieden waar het het gemakkelijkst is om te kniezen, en in dit bericht ga ik het hebben over een paar veelvoorkomende soorten wachten en de fouten die mensen om hen heen maken. Er is in een artikel als dit geen ruimte om uitgebreid in te gaan op wat u in elk geval moet doen, maar ik zal u voldoende informatie geven om u in de goede richting te wijzen.
LCK_M_XX
De meeste mensen gaan ervan uit dat als vergrendelingswachten het meest voorkomen, er een soort blokkeerprobleem moet zijn. Vaak is dit het geval, zoals het ontbreken van een geschikte niet-geclusterde index die een tabelscan in REPEATABLE_READ- of SERIALIZABLE-isolatieniveaus veroorzaakt die escaleert tot een S-tabelvergrendeling. (En als een snelle hint, als je denkt dat je SERIALIZABLE nooit zult gebruiken, doe je dat wel als je gedistribueerde transacties gebruikt - alles wordt onder de dekens geconverteerd naar SERIALIZABLE, wat kan leiden tot onverwachte blokkeringen en impasses.)
Het komt echter vaak voor dat de blokkering door iets anders wordt veroorzaakt. Onder het standaard READ_COMMITTED-isolatieniveau worden vergrendelingen die wijzigingen dekken vastgehouden totdat de transactie wordt doorgevoerd, en worden leesbewerkingen en andere updates naar dezelfde rij(en) geblokkeerd. Als iets verhindert dat een transactie wordt uitgevoerd, kan dat ertoe leiden dat er een blokkering wordt weergegeven.
Als de database bijvoorbeeld synchroon wordt gespiegeld, kan de transactie de vergrendelingen niet vastleggen en vrijgeven totdat de logrecords naar de mirror zijn verzonden en naar de logdrive van de mirror zijn geschreven. Als het netwerk ernstig overbelast is, of als er massale I/O-conflicten zijn op de mirror, kan dit de mirroring ernstig vertragen, waardoor de transactie veel langer duurt om door te voeren. Dit zou op blokkeren lijken, maar de hoofdoorzaak is een bronconflict dat te maken heeft met spiegelen.
Voor vergrendelingswachten, tenzij de oorzaak duidelijk is door te kijken naar het queryplan, vergrendelingsbron (bijv. tabelniveau die vergrendelingsescalatie of isolatieniveau aangeeft, volgt u de blokkeringsketen (met behulp van een script dat de blocking_session_id-kolom in sys.dm_exec_requests en vervolgens kijk om te zien waar de draad aan het begin van de blokkerende ketting op wacht. Dat gaat naar de oorzaak wijzen.
ASYNC_NETWORK_IO
De naam hiervan zorgt voor veel verwarring. Op welk woord focus je? NETWERK. De oorzaak van dit type wacht heeft meestal niets te maken met het netwerk. Het zou eigenlijk WAITING_FOR_APP_ACK (nowledgement) of iets dergelijks moeten heten, want dat is precies wat er gebeurt:SQL Server heeft wat gegevens naar een client gestuurd en wacht op de client om te bevestigen dat hij de gegevens heeft verbruikt.
Een van mijn favoriete demo's om te doen bij het lesgeven over wachtstatistieken, is om een query uit te voeren die een grote resultatenset retourneert in Management Studio en te kijken hoe de server ASYNC_NETWORK_IO wacht. Er is duidelijk geen netwerk bij betrokken - het duurt gewoon lang voordat SSMS op SQL Server reageert. Het doet wat bekend staat als RBAR (Row-By-Agonizing-Row), waarbij slechts één rij tegelijk uit de resultaten wordt gehaald en verwerkt, in plaats van alle resultaten in de cache op te slaan en vervolgens onmiddellijk te antwoorden op SQL Server en verder te gaan met het verwerken van de gecachete rijen.
Dit is de belangrijkste oorzaak van ASYNC_NETWORK_IO-wachttijden:slecht applicatieontwerp. Ik zou dan kijken of de server waarop de applicatiecode wordt uitgevoerd een prestatieprobleem heeft, zelfs als de applicatiecode zelf goed is ontworpen. Af en toe is het het netwerk, maar dat is zeldzaam in mijn ervaring.
OLEDB
De gebruikelijke reflexmatige reactie hier is om dit type wacht gelijk te stellen aan gekoppelde servers. Deze wachttijd werd echter gebruikelijker toen SQL Server 2005 werd uitgebracht, omdat 2005 een groot aantal nieuwe DMV's bevatte en DMV's meestal OLE DB onder de dekens gebruiken. Voordat ik op zoek ga naar problemen met gekoppelde servers, zou ik controleren of een monitoringtool constant DMV's op de server uitvoert.
Als je wel gekoppelde servers hebt, ga dan verder met het oplossen van problemen door naar de gekoppelde server te gaan en daar de wachtstatistieken te bekijken om te zien wat het meest voorkomende probleem is, en ga dan door met dezelfde analyse.
Een ander ding dat OLEDB-wachttijden kan veroorzaken, is DBCC CHECKDB (en gerelateerde opdrachten). Het gebruikt een OLE DB-rijenset om informatie te communiceren tussen de subsystemen Query Processor en Storage Engine.
Andere wachttijden
Enkele van de andere wachttijden die krampachtige reacties veroorzaken, zijn CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD en WRITELOG, en die zal ik volgende maand in mijn post behandelen.
Samenvatting
Als u een prestatieprobleem heeft, neem dan de tijd om de gegevens die u bekijkt te begrijpen en voer verder onderzoek uit om de oorzaak van het probleem te achterhalen. Grijp niet alleen naar wat de beste wachtstatistieken lijken en volg het eerste advies dat u online tegenkomt (tenzij het van een bekende en betrouwbare bron komt) of u zult uw probleem waarschijnlijk niet oplossen, en misschien zelfs maak het erger.
Wat algemene wachtstatistieken betreft, kunt u meer informatie vinden over het gebruik ervan voor het oplossen van problemen met de prestaties in:
- Mijn serie blogposts, te beginnen met Wachtstatistieken, of vertel me alsjeblieft waar het pijn doet
- Mijn bibliotheek met wachttypen en Latch-klassen hier
- Mijn online Pluralsight-trainingscursus SQL Server:prestatieproblemen oplossen met behulp van wachtstatistieken
- SQL Sentry Performance Advisor
Dit was de eerste in een reeks berichten die ik in de loop van dit jaar zal doen en die gaan over (re)acties rond SQL Server en waarom ze verkeerd zijn om te doen. Tot de volgende keer, veel plezier met het oplossen van problemen!