Wat als u al de moeite zou nemen om een nieuwe SQL Server te implementeren of te upgraden voor een betere ervaring voor uw klanten - en zij klaagden dat de zaken eigenlijk slechter waren?
Zou je niet gegriefd zijn als je door al die zakelijke en technische hoepels zou springen om betere SQL Server-prestaties te krijgen, en dat niet deed?
Misschien had u wat prestatietests voor SQL Server moeten uitvoeren voordat u in productie ging. Dan had je geweten of je prestaties zouden verbeteren, hetzelfde blijven of, het ergste van alles, achteruitgaan.
Maar je zou in ieder geval niet onaangenaam verrast zijn geweest.
De prestatiebrug van SQL Server die we allemaal oversteken
Of het nu gaat om het overschakelen van een andere database naar SQL Server of het upgraden van een oudere versie van SQL Server naar een nieuwere, u moest uiteindelijk de prestatiebrug oversteken.
"Gaat het echt beter lopen dan voorheen?" vroeg je baas.
"O, zeker", zei je. “Met datavirtualisatie in SQL Server 2019 kunnen we queries uitvoeren zonder data te verplaatsen of te repliceren. En er is automatische afstemming met Intelligence Query Processing om query's op te schalen. De gegevens vliegen de servers uit.” Je was er zo zeker van dat je 'FLY' met een hoofdletter schreef.
Dus hoe had je je prestaties beter kunnen testen?
4 manieren om prestaties te testen . . .
Brent Ozar, SQL Server maven extraordinaire, vertelt je hoe je de prestaties op een nieuwe SQL Server kunt controleren:
- op de gemakkelijke manier, voor- en na-tijden vergelijken op een volledige back-up en CHECKDB
- de gemakkelijke maar verkeerde manier, met een synthetische werklast en TPC-C in HammerDB
- op de moeilijkere manier, individuele zoekopdrachten testen met sp_BlitzCache, zijn plancache-analysescript
- op de echt moeilijke manier, dezelfde zoekopdrachten uitvoeren die u in productie uitvoert
Maar zoals Brent duidelijk maakt, is het monitoren van de prestaties van uw SQL-server en de vaststelling dat deze met X procent is gedaald slechts het begin; je moet nog uitzoeken waar de klap vandaan komt.
Dat betekent zoeken naar trends in prestatiegegevens over hele weken en maanden, niet alleen over de laatste paar uur.
Hoe meer datapunten en geschiedenis je hebt, hoe beter het beeld dat je kunt vormen van wat er in, onder en rond je SQL Server-omgeving gebeurt.
En hoe meer rekenkracht u kunt gebruiken voor al die gegevens, hoe sneller u ze kunt analyseren.
SQL Server prestatiebewaking:klinkt als een taak voor de cloud
Ja. Het is een taak voor de cloud, de enige plek waar je ver genoeg kunt uitschalen om al die gegevens te verzamelen en te analyseren voor een breed, diep beeld van hoe SQL Server bronnen verbruikt. En hoe het die middelen in de loop van de tijd heeft verbruikt. Bijvoorbeeld:
- Op bepaalde tijden van de dag of maand moeten vaak uitgevoerde query's van schijf worden gelezen in plaats van uit de buffercache, de in-memory kopie van recent gebruikte databasepagina's. Moet u meer geheugen toewijzen aan uw buffercache? Kun je er nog meer geheugen voor over hebben?
- Hetzelfde geldt voor de levensduur van de pagina. Als het laag is, komt dat waarschijnlijk omdat SQL Server pagina's te vaak uit de buffercache verwijdert en zoekopdrachten moet uitvoeren vanuit de opslag in plaats van vanuit het geheugen. Dat belemmert de prestaties.
- Wordt de maximale I/O-wachttijd te hoog? Hoe is het trending? Dat is een aanwijzing dat het I/O-apparaat mogelijk verzadigd is.
- Hoe lang is de processorwachtrij nu? Hoe lang is het meestal? Te veel threads die constant wachten, kan duiden op een verstopping van de processor.
- Loopt de CPU tegen de limieten aan die uw server aankan? Wat als u de server niet meer kunt opschalen? Als u zeker weet dat uw query's goed zijn afgestemd en uw andere systeembronnen voldoende zijn, moet u mogelijk een socket voor fysieke hardware of vCPU's aan uw VM's toevoegen.
- Gefragmenteerde indexen zijn langzame indexen, maar u weet niet of ze de boosdoener zijn totdat u de fragmentatieniveaus controleert. Als u de effecten ziet van reorganiseren en opnieuw opbouwen in de loop van de tijd, kunt u een betrouwbaar proces voor indexonderhoud opzetten.
Het vinden van dergelijke problemen in al uw on-premises en clouddatabases wordt eenvoudiger en sneller wanneer u de prestaties van uw SQL-server vanuit de cloud kunt volgen. Het beste van alles is dat u overal in de bekende melkweg kunt monitoren wanneer alle rekenkracht, opslag en analyse in de cloud staat en u slechts een paar klikken verwijderd bent in elke browser.
Begin met het testen van uw SQL Server-prestaties in de cloud
Bij Quest hoeft niemand ons twee keer te vertellen dat onze klanten cloudgebaseerde tools willen, of het nu gaat om cloudmigratie, prestatiebewaking of Office 365. We stellen meer van onze producten beschikbaar als cloudaanbiedingen omdat technologieën en markten ze daar naartoe trekken.
Dus, hoe voer je prestatietests uit op je nieuwe of geüpgradede SQL-servers?
- Ik voer CHECKDB uit.
- Ik gebruik HammerDB.
- Ik gebruik de tools van Brent Ozar.
- Ik test met productieworkloads.
- Ik gooi de dobbelstenen en wacht tot gebruikers klagen.
- Ik heb mensen die dat voor me doen.
- Ik gebruik Spotlight Cloud van Quest. Dat zou jij ook moeten doen.