sql >> Database >  >> RDS >> Sqlserver

4 manieren om overbelasting van waarschuwingen te voorkomen met SQL Server Monitoring

Voor databasebeheerders die verantwoordelijk zijn voor het reageren op SQL Server-waarschuwingen op alle uren van de dag en nacht, wordt het gevoel van overbelasting waarschijnlijk verergerd door het constante spervuur ​​​​van meldingen dat iets uw aandacht nodig heeft. RECHTSAF. NU.

Monitoring van SQL Server is cruciaal voor het handhaven van hoge beschikbaarheid en het volgen van prestatieproblemen in uw systeem, en waarschuwingen zijn zonder twijfel de meest efficiënte manier om erachter te komen dat er een probleem is. Maar het is mogelijk om te veel van het goede te hebben.

Zoals het gezegde luidt:"Als alles een prioriteit is, is niets een prioriteit." Waarschuwingsmoeheid is reëel en kan ertoe leiden dat u gebeurtenissen negeert of negeert die een negatieve invloed hebben op uw gebruikers.

Wanneer u uw SQL Server-prestatiebewaking instelt, is het belangrijk om alarmen bewust te configureren en op een manier die bepaalt wanneer, waarom en hoe vaak u meldingen ontvangt. Hier zijn vier manieren om waarschuwingen te beheren die de overbelasting van waarschuwingen helpen verminderen en redden wat er nog over is van uw gezond verstand.

1. Schakel de alarmen uit die u niet nodig heeft

Voor veel DBA's is dit makkelijker gezegd dan gedaan. Er is een klein element van angst bij de gedachte om te kiezen welke waarschuwingen je niet wilt ontvangen. Gelukkig zijn er enkele best practices die u kunt implementeren die uw FOMO een beetje minder pijnlijk kunnen maken.

Een van de gemakkelijkste dingen die u kunt doen, is de waarschuwingslogboeken bekijken en waarschuwingen uitschakelen die chronisch valse alarmen of valse positieven zijn. De kans is groot dat u geen echt probleem zult missen, en uw hersenen zullen het waarderen dat u niet meer hoeft te reageren op onnodige meldingen.

Een andere strategie is afkomstig van de site-betrouwbaarheidsingenieurs (SRE's) van Google. SRE's zijn verantwoordelijk voor beschikbaarheid, latentie, prestaties, efficiëntie, wijzigingsbeheer, monitoring, reactie op noodsituaties en capaciteitsplanning.

De SRE-teams beschikken over een Alert/Ticket/Log-systeem om de overbelasting van de waarschuwingen tot een minimum te beperken door een reactie toe te wijzen aan een gebeurtenis die is gebaseerd op hoe snel menselijke tussenkomst nodig is. De drie mogelijke antwoorden zijn:

  • Waarschuwing:er wordt alleen een waarschuwing verzonden als een persoon onmiddellijk actie moet ondernemen.
  • Ticket:als het evenement actie van een persoon vereist, maar het kan wachten tot de normale kantooruren, wordt een ticket ingediend en gaat het via de normale kanalen.
  • Logboek:als er geen actie vereist is, wordt de gebeurtenis geregistreerd voor diagnose.

2. Gebruik slimme alarmen om snel de hoofdoorzaak van een waarschuwing te achterhalen

Wanneer je telefoon om 3 uur 's nachts ontploft met meldingen, wil je geen uur lang rondsnuffelen om het probleem op te lossen.

Slimme alarmen vertellen u niet alleen dat u een probleem heeft, maar stellen ook manieren voor om het op te lossen en helpen u de oorzaak te achterhalen. Slimme alarmen bieden ook historische gegevens over de gebeurtenis, zodat u weet wat er direct voor en nadat de waarschuwing is geactiveerd, is gebeurd.

3. Geef prioriteit aan uw waarschuwingen om de meest urgente problemen te identificeren

Alle waarschuwingen zijn niet gelijk gemaakt, dus het is belangrijk om uw SQL Server-hulpprogramma voor prestatiebewaking zo te configureren dat deze alleen waarschuwingen verzendt voor de belangrijkste problemen. Door prioriteit te geven aan waarschuwingen op basis van het ernstniveau, de impact op het bedrijf of de klanten en of onmiddellijke actie vereist is, elimineert u een deel van de ruis die wordt gegenereerd door niet-kritieke waarschuwingen.

Richt u op het instellen van waarschuwingen voor problemen die ertoe kunnen leiden dat uw servers offline gaan, gegevens ernstig beschadigen of leiden tot aanzienlijk gegevensverlies (d.w.z. Severity 17 of hoger en foutmeldingen 823, 824 en 825).

4. Beheer alarmen door specifieke drempels en regels toe te passen

Het instellen van drempels en regels is een enorme besparing op uw gezond verstand, omdat het u zal helpen voorkomen dat u in korte tijd wordt gebombardeerd door meerdere waarschuwingen.

Wanneer u prestatiedrempels definieert, stelt SQL Server u niet op de hoogte totdat een waarde voor een opgegeven metriek een bepaald niveau bereikt, bijvoorbeeld de vrije schijfruimte of het vrije fysieke geheugen is gevaarlijk laag. Dit maakt DBA's vrij om aan andere taken te werken zonder constant de statistieken te controleren.

Door regels voor waarschuwingen in te stellen, kunt u acties aanpassen, zoals hoe vaak u een melding wilt ontvangen. U kunt SQL Server bijvoorbeeld zo instellen dat alleen een melding wordt verzonden wanneer een opgegeven waarschuwing vier keer is geactiveerd of als de waarschuwing een bepaald databaseobject of een bepaalde gebruikersnaam bevat.

Naarmate DBA's na COVID-19 in een nieuwe en heel andere zakelijke omgeving beginnen te navigeren, zullen de stressniveaus zeker stijgen. Het handhaven van een hoge beschikbaarheid en ervoor zorgen dat uw SQL Server-systemen veilig zijn en optimaal presteren, blijft een grote prioriteit. Maar dit is een goed moment om SQL Server-bewakingsfuncties in te schakelen om controle te krijgen over uw waarschuwingsconfiguraties en de onnodige ruis te verwijderen.


  1. Gegroepeerde LIMIT in PostgreSQL:toon de eerste N rijen voor elke groep?

  2. Taal voor SQL-gegevensbesturing

  3. Queryprestaties meten:uitvoeringsplan Querykosten versus benodigde tijd

  4. Leveringsoptie tijdens het indienen van een gelijktijdig verzoek in R12.1.3