At være databaseadministrator har mange ansvarsområder, og at vide, hvad der sker på din SQL Server, er en af dem. At være proaktiv og advaret om fejl er en af de egenskaber, der gør nogen til en god DBA. Og jeg taler ikke kun om, at tingene fejler, hvilket er det, de fleste mennesker tænker på at blive advaret om; du kan også blive advaret om ydeevneproblemer. Inden for SQL Server har du mulighed for at oprette SQL Server Agent Alerts (som jeg bare kalder 'alerts' fra nu af), og dette opnås nemt ved hjælp af GUI eller T-SQL.
Konfiguration af SQL Server Agent Alerts
For at bruge alarmer skal du have konfigureret Database Mail og en SQL Agent Operator. De fleste SQL-forekomster, jeg er stødt på, har allerede Database Mail konfigureret til notifikationer om jobfejl. Hvis du har brug for yderligere oplysninger om opsætning af denne funktion, kan du besøge emnet Books Online, "Konfigurer databasemail."
En mindre kendt opgave er at konfigurere operatøren. Du kan oprette operatøren ved hjælp af SSMS eller T-SQL. Udvid SQL Server Agent i SSMS, højreklik på Operatør og vælg Ny Operator. Du vil have en ny dialogboks åben, hvor du kan give operatøren et navn og angive den e-mailadresse, der skal underrettes. Jeg foretrækker at bruge en distributionsgruppe til e-mail-meddelelser. De fleste virksomheder har mere end én person, der er ansvarlig for SQL-miljøet, og hvis du angiver en distributionsgruppe, kan hele teamet få besked om advarslerne. Brug af distributionsgrupper gør det også meget nemmere at tilføje eller fjerne personer fra alarmerne.
Nedenfor er et eksempel på et skærmbillede af dialogboksen Ny operatør:
Jeg foretrækker at bruge T-SQL, så jeg kan sikre mig, at oprettelse af operatøren er en del af en serverbyggeskabelon. Eksempelkode til oprettelse af ovenstående operatør er som følger:
EXEC msdb.dbo.sp_add_operator @name = N'SQL_Alerts', @enabled = 1, @email_address = N'[email protected]';
Når du har konfigureret Database Mail og operatøren, kan du oprette advarslerne og tildele dem til operatøren.
Hvis du bruger SSMS, kan du udvide SQL Server Agent og derefter Alerts. Som standard oprettes der ingen advarsler. Hvis du højreklikker og vælger New Alert, får du et skærmbillede svarende til nedenstående figur:
Du vil bemærke, at der under Alvorlighed er 25 alvorlighedskoder. Ligesom det lyder, beskriver fejlniveauets sværhedsgrad, hvor vigtig fejlen er. Sværhedsgrad 10 er informativ, mens 19-25 er dødelig, og du vil gerne have besked, når disse fejl opstår. Hvis der for eksempel opstod en alvorlighedsgrad 23 fejl, så har du højst sandsynligt en korruption i en af dine databaser. Disse fatale fejl kan alle påvirke din servers ydeevne, hvilket igen påvirker kundeoplevelsen.
Der er en ekstra advarsel, som du skal oprette, for fejl 825. Fejl 825, som Paul Randal beskriver i sit blogindlæg, er relateret til en I/O-operation, som SQL Server måtte prøve igen, men som til sidst lykkes (hvorimod fejl 823 og 824 angiver, at en I/O-genforsøgsoperation blev forsøgt igen og til sidst mislykkedes). Fejl 825 er kritisk at vide om, fordi den advarer dig om I/O-problemer, der kan ende med at blive fatale i fremtiden. Ethvert genforsøg er dårligt, du bør ikke vente, indtil en I/O-operation ikke bliver underrettet. Hvis du begynder at få fejl 825-meddelelser, skal du straks kontakte dine lager- og hardwareteams.
Du kan oprette hver af advarslerne ved at angive navnet og vælge sværhedsgraden. For fejl 825 skal du vælge Fejl og indtaste nummeret. Som med operatøren foretrækker jeg at bruge T-SQL. Hvis jeg nemt kan scripte en proces, så er den meget nemmere at genbruge og inkludere som en del af en server build.
Nedenfor finder du scriptet, som jeg har brugt på min SQL Server 2014 Developer arbejdsstation. Dette script opretter hver af advarslerne og tilføjer en meddelelse om advarslen til Operator SQL_Alerts.
EXEC msdb.dbo.sp_add_alert @name = N'Severity 19 Error', @message_id = 0, @severity = 19, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 19 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 20 Error', @message_id = 0, @severity = 20, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 20 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name=N'Severity 21 Error', @message_id = 0, @severity = 21, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 21 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 22 Error', @message_id = 0, @severity = 22, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 22 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 23 Error', @message_id = 0, @severity = 23, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 23 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 24 Error', @message_id = 0, @severity = 24, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 24 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Severity 25 Error', @message_id = 0, @severity = 25, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Severity 25 Error', @operator_name = N'SQL_Alerts', @notification_method = 1; EXEC msdb.dbo.sp_add_alert @name = N'Error 825', @message_id = 825, @severity = 0, @include_event_description_in = 0; EXEC msdb.dbo.sp_add_notification @alert_name = N'Error 825', @operator_name = N'SQL_Alerts', @notification_method = 1;
Hvis du har fulgt med, ville du have konfigureret databasemail, oprettet en operatør til at e-maile dig eller en distributionsgruppe om potentielle fejl, og SQL Server Agent Alerts konfigureret til sværhedsgrad 19 – 25 og fejl 825.
Dette er godt. Hver gang en af disse advarsler udløses, vil der blive sendt en e-mail til dit team. Ud over hændelsesadvarsler kan advarsler konfigureres til en præstationstilstand, som jeg nævnte i introduktionen. For eksempel, hvis hukommelsesforbruget overstiger en defineret tærskel, kan en advarsel udløses. Jeg opfordrer dig til at udforske de forskellige præstationsalarmer og oprette dem, din organisation kan drage fordel af. For at finde advarslerne om SQL Server-ydeevnetilstand skal du i den nye advarselsdialogboks klikke på rullemenuen for Type. Der vil du se en advarsel om SQL Server-ydelsestilstand på listen. Når du har valgt denne mulighed, kan du gennemse de typer objekter, du kan konfigurere en alarm for ydeevnetilstand på.
Mens vi tildelte en operatør til advarselssvaret, kunne du også konfigurere advarslen til at udføre et SQL Agent-job. Selvom dette giver dig en vis fleksibilitet til at have en hændelsessvaropgave, giver det ikke mulighed for let betinget alarmering.
Brug af SQL Sentry til avanceret alarmering
For mere avanceret alarmering har du brug for et bedre værktøj. Det er her SQL Sentry kan hjælpe. En af mine foretrukne SQL Sentry-advarselsfunktioner er evnen til at skabe brugerdefinerede betingelser for at advare eller handle, når noget har ændret sig i miljøet. For eksempel, hvis nogen ændrede min eller maks. hukommelsesværdien, ændrede maxdop eller omkostningstærsklen for parallelitet, kunne du få en advarsel eller endda sætte gang i en proces. Denne funktion blev introduceret i SQL Sentry v8, og Greg Gonzalez (blog | @SQLsensei) bloggede om den her:"SQL Sentry v8:Intelligent Alerting Redefined."
Med denne funktion kan du også oprette brugerdefinerede betingelser for forskellige databaser inden for en enkelt advarsel. Hvis du forsøgte dette ved hjælp af SQL Agent-advarsler, skulle du oprette forskellige advarsler pr. database.
En anden fantastisk alarmfunktion er muligheden for at oprette forskellige alarmplaner. Mange organisationer har teams, der er ansvarlige på forskellige dele af dagen. Nogle kan have produktions-DBA's ansvarlige i dagtimerne med et Network Operations Center, der dækker nattevagten, derefter en vagtperson i weekenden. Ville det ikke være fantastisk at være i stand til at tilpasse en varslingsplan for at underrette de rette teams i løbet af deres timer med ansvar?
Du kan oprette alarmvinduer (som i et tidsvindue) og knytte dem til forskellige alarmer eller grupper. Dette gør det muligt for forskellige alarmer at være aktive på forskellige tidspunkter og for forskellige grupper at blive underrettet på forskellige tidspunkter. Dette er virkelig fedt, da det lader din alarmering følge en supportplan, så de korrekte personer får besked. Scott Fallen beskriver denne funktion i et blogindlæg, "Alerting on a Call Schedule with SQL Sentry", som leder dig gennem oprettelse af alarmer til forskellige vagthold.
En anden advarselsfunktion i Performance Advisor og Event Manager er muligheden for at konfigurere andre svar såsom at udføre en Windows-proces, logge hændelsen til en database eller fejllog, sende en SNMP-fælde til et andet overvågningsværktøj såsom SCOM eller endda dræbe en proces . Dine muligheder er næsten ubegrænsede med hensyn til, hvad du kan have foruddefineret til at ske, når en bestemt begivenhed indtræffer. SQL Agent-advarsler kan ikke tilpasses.
Oversigt
Det vigtige med dette indlæg er, at du absolut skal være opmærksom på fejl og ydeevneforhold. Hvis du ikke har et værktøj såsom SQL Sentry, er det stadig en god start at bruge SQL Agent Alerts.
I løbet af mine næste par indlæg vil jeg dykke ned i nogle af disse præstationspåvirkende advarsler og diskutere, hvilke handlinger du skal tage, når de opstår.