Er zijn veel factoren die van invloed zijn op de prestaties van de database. Als u de normale fluctuaties van uw specifieke instantie kent door uw SQL-server te bewaken, kunt u vaststellen wanneer gedrag uit de hand loopt en kunt u anticiperen op problemen voordat ze zich voordoen.
Het helpt je ook om onderscheid te maken tussen wat natuurlijke groeipijnen zijn die worden veroorzaakt door een verhoogde werkdruk of seizoenspieken waarvoor misschien gewoon meer middelen nodig zijn, en diepere prestatieproblemen die afstemming van codes, indexoptimalisatie of afstemming van de configuratie vereisen.
Zodra u een lijst met SQL-servers in uw omgeving heeft opgesteld, wilt u enkele kritische vragen stellen:
- Hoe gezond is deze instantie?
- Wanneer is voor het laatst een back-up gemaakt?
- Heeft het voldoende CPU, geheugen en opslag om aan de SLA te voldoen?
- Wat voor soort workloads worden op deze instantie uitgevoerd?
- Welke applicaties en gebruikers gebruiken deze instantie?
- Wanneer is de werkdruk het drukst?
- Is er een failover-strategie?
- Is dit een bedrijfskritische instantie?
- Moet het 24/7 beschikbaar zijn?
- Wat voor soort prestatie-uitdagingen heeft deze instantie?
Dit lijken misschien voor de hand liggende vragen, maar als u voor de eerste keer begint met het controleren van uw SQL-server-workloads, zult u verrast en mogelijk een beetje geschokt zijn om te zien hoeveel van hen fundamentele problemen hebben.
Prestatiedoelen instellen voor SQL Server Monitoring
Denk na over wat u wilt bereiken met uw inspanningen voor het monitoren van SQL-servers en prioriteer deze doelen. Door uw activiteiten in te kaderen in key performance indicators, maakt u het gemakkelijker om de waarde van de energie en eventuele investeringen te verwoorden. De volgende lijst helpt u op weg.
Hoge beschikbaarheid
Wat zijn uw beschikbaarheidsstatistieken? Onthoud dat onbeschikbaarheid voor de gebruiker is wanneer deze geen toegang heeft tot de service. Dit kan worden veroorzaakt door een volledige storing of door een prestatieknelpunt waardoor de service in feite niet beschikbaar is. Heeft u een always-on configuratie? Zo ja, kent u de status ervan?
Responstijd
Vanaf het moment dat een probleem wordt gemeld, hoe snel kunt u de bron isoleren, de symptomen diagnosticeren en reageren op de gevolgen?
Oplossingstijd
Hoe snel kunt u het symptoom oplossen om de normale werking te herstellen? De "plakpleister"-oplossing is een belangrijk begin, maar mag niet het einde van de zaak betekenen. Heb je de oorzaak van het probleem onderzocht? Kunt u erop vertrouwen dat u geen herhaling zult zien?
Inzicht in de eigendomskosten van uw SQL Server-instanties
De eigendomskosten zijn een kritieke factor bij het bepalen waar uw SQL-serverinstanties zich moeten bevinden. Het is belangrijk om de initiële investeringskosten in verband met infrastructuur en licenties, de doorlopende onderhoudskosten en eventuele op verbruik gebaseerde kosten in verband met een cloudgebaseerde workload te meten.
Als u probeert te beslissen hoeveel uw instantie in de cloud gaat kosten, zijn de kritieke statistieken onder meer CPU-gebruik, lees- en schrijfactiviteit en opslag. U moet deze over een langere periode meten om uw werklastgrenzen te bepalen om ervoor te zorgen dat u over voldoende middelen beschikt voor het spectrum van werklast dat u voor een bepaalde instantie verwacht.
Als u vertrouwd raakt met de specifieke kenmerken van de workloads die op uw SQL-serverinstanties worden uitgevoerd, bent u in een veel betere plaats om ervoor te zorgen dat alles blijft werken zoals het hoort en om te voldoen aan zowel de huidige als toekomstige behoeften van uw bedrijf.
Bestudeer prestaties in de loop van de tijd met SQL Server Monitoring
Databases zijn vloeiende systemen. Slechts weinigen hebben een stabiele, repetitieve en voorspelbare workload. Het is veel gebruikelijker om in de loop van de tijd grote variaties te zien die fluctueren op basis van het aantal gebruikers, geautomatiseerde taken, het aantal transacties, de hoeveelheid gegevens, enzovoort.
Een verkoopdatabase zal aan het einde van de maand druk worden. Het zal ook een piek zien in de activiteit rond seizoensevenementen of gedreven door marketingpromoties.
Het classificeren van uw prestaties op basis van kleine snapshots is geen goed beleid. Hoe meer geschiedenis u kunt verzamelen en analyseren, hoe meer inzicht u kunt krijgen in de variaties en grenzen van elk van de kenmerken van uw workloads.
Je zult moeten beoordelen hoeveel geschiedenis het praktisch is om te bewaren en of je de middelen hebt om het te verwerken. Er zijn kosten- en prestatie-implicaties waarmee rekening moet worden gehouden.
Krijg een compleet beeld van uw databasebewaking
Elke database is een complex systeem met veel bewegende delen. Veel configuratiecriteria kunnen van invloed zijn op de prestaties.
Het ontwerp en de architectuur van de database zelf zullen de resultaten beïnvloeden. Code-efficiëntie kan ook prestaties maken of breken. Configuratie-opties bepalen hoe de SQL-serverinstantie de beschikbare bronnen gebruikt.
Overweeg het volgende scenario:Een instantie komt langzaam tot stilstand en de DBA ziet een piek in CXPACKET- of CXCONSUMER-wachttijd. De reflexmatige reactie is om het parallellisme uit te schakelen. De wachttijden verdwijnen en het huidige knelpunt wordt tijdelijk verholpen. Nu werkt de hele instantie langzamer, maar de DBA wil parallellisme niet opnieuw inschakelen. Als er wat verder onderzoek was gedaan, zou het hebben uitgewezen dat een zoekopdracht bijzonder traag verliep en dat de oorzaak een ontbrekende index was.
Door veel verschillende statistieken tegelijkertijd te monitoren, kunt u de hoofdoorzaak nauwkeurig identificeren en dure verkeerde diagnoses voorkomen die een herhaling of zelfs escalatie van hetzelfde probleem kunnen veroorzaken.