Att vara databasadministratör har många ansvarsområden, och att veta vad som händer på din SQL Server är en av dem. Att vara proaktiv och uppmärksammad på fel är en av egenskaperna som gör någon till en bra DBA. Och jag pratar inte bara om att saker misslyckas, vilket är vad de flesta tycker om att bli varnade om; du kan också bli varnad om prestandaproblem. Inom SQL Server har du möjlighet att skapa SQL Server Agent Alerts (som jag bara kallar "varningar" från och med nu), och detta görs enkelt med GUI eller T-SQL.
Konfigurera SQL Server Agent Alerts
För att använda varningar måste du ha konfigurerat Databas Mail och en SQL Agent Operator. De flesta SQL-instanser jag har stött på har redan Database Mail konfigurerad för meddelanden om jobbfel. Om du behöver mer information om hur du ställer in den här funktionen, besök boken Online-ämnet, "Konfigurera databaspost."
En mindre känd uppgift är att konfigurera operatören. Du kan skapa operatören med SSMS eller T-SQL. Expandera SQL Server Agent inom SSMS, högerklicka på Operatör och välj New Operator. Du kommer att ha en ny dialogruta öppen där du kan ge operatören ett namn och ange den e-postadress som ska meddelas. Jag föredrar att använda en distributionsgrupp för e-postmeddelanden. De flesta företag har mer än en person som är ansvarig för SQL-miljön och om du anger en distributionsgrupp kan hela teamet meddelas om varningarna. Att använda distributionsgrupper gör det också mycket lättare att lägga till eller ta bort personer från varningarna.
Nedan är ett exempel på en skärmdump av dialogrutan Ny operatör:
Jag föredrar att använda T-SQL så att jag kan se till att skapa operatören är en del av en serverbyggmall. Exempelkod för att skapa ovanstående operatör är följande:
EXEC msdb.dbo.sp_add_operator @name = N'SQL_Alerts', @enabled = 1, @email_address = N'[email protected]';
När du har konfigurerat Databas Mail och operatören kan du skapa varningarna och tilldela dem till operatören.
Om du använder SSMS kan du utöka SQL Server Agent och sedan Alerts. Som standard skapas inga varningar. Om du högerklickar och väljer New Alert får du en skärm som liknar bilden nedan:
Du kommer att märka att under Allvarlighet finns det 25 allvarlighetskoder. Precis som det låter, beskriver felnivåns svårighetsgrad hur viktigt felet är. Allvarlighetsgrad 10 är informativ medan 19-25 är dödlig och du vill bli meddelad när dessa fel uppstår. Om ett allvarlighetsgrad 23-fel uppstod, till exempel, har du med största sannolikhet en korruption i en av dina databaser. Dessa allvarliga fel kan alla påverka prestanda på din server, vilket i sin tur påverkar kundupplevelsen.
Det finns en extra varning som du måste skapa för fel 825. Fel 825, som Paul Randal beskriver i sitt blogginlägg, är relaterat till en I/O-operation som SQL Server var tvungen att försöka igen men som så småningom lyckas (medan fel 823 och 824 indikerar att en I/O-försöksoperation gjordes om och så småningom misslyckades). Fel 825 är viktigt att känna till eftersom det varnar dig för I/O-problem som kan bli ödesdigra i framtiden. Alla försök igen är dåliga, du bör inte vänta tills en I/O-operation misslyckas med att meddelas. Om du börjar få fel 825-meddelanden måste du omedelbart kontakta dina lagrings- och maskinvaruteam.
Du kan skapa var och en av varningarna genom att ange namnet och välja svårighetsgrad. För Error 825 skulle du välja Error och skriva in numret. Precis som med operatören föredrar jag att använda T-SQL. Om jag enkelt kan skripta en process så är den mycket lättare att återanvända och inkludera som en del av en serverbuild.
Nedan hittar du skriptet som jag har använt på min SQL Server 2014 Developer-arbetsstation. Det här skriptet skapar var och en av varningarna och lägger till en avisering för varningen till operatörens 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;
Om du har följt med skulle du ha konfigurerat databaspost, skapat en operatör som skickar e-post till dig eller en distributionsgrupp om potentiella fel och SQL Server Agent Alerts konfigurerade för allvarlighetsgrad 19 – 25 och fel 825.
Det här är bra. Varje gång en av dessa varningar utlöses kommer ett e-postmeddelande att skickas till ditt team. Förutom händelsevarningar kan varningar konfigureras för ett prestandatillstånd, som jag nämnde i inledningen. Till exempel, om minnesanvändningen överstiger en definierad tröskel kan en varning utlösas. Jag uppmuntrar dig att utforska de olika prestandavarningarna och skapa de som din organisation kan dra nytta av. För att hitta varningarna för SQL Server-prestandavillkor, i den nya varningsdialogrutan, klicka på rullgardinsmenyn för Typ. Där kommer du att se en varning för SQL Server-prestandatillstånd listad. När du har valt det alternativet kan du bläddra bland de typer av objekt som du kan konfigurera en varning för prestandavillkor för.
Medan vi tilldelade en operatör till varningssvaret, kan du också konfigurera varningen för att utföra ett SQL Agent-jobb. Även om detta ger dig en viss flexibilitet att ha händelsesvarsuppgift, ger det inte möjligheten att ha lätt villkorlig varning.
Använda SQL Sentry för avancerade varningar
För mer avancerad varning behöver du ett bättre verktyg. Det är här SQL Sentry kan hjälpa. En av mina favoritfunktioner för SQL Sentry-varning är möjligheten att skapa anpassade villkor för att varna eller agera när något har förändrats i miljön. Till exempel, om någon ändrade min eller max minnesvärde, modifierade maxdop eller kostnadströskeln för parallellitet kan du få en varning eller till och med starta en process. Den här funktionen introducerades i SQL Sentry v8, och Greg Gonzalez (blogg | @SQLsensei) bloggade om den här:"SQL Sentry v8:Intelligent Alerting Redefined."
Med den här funktionen kan du också skapa anpassade villkor för olika databaser inom en enda varning. Om du försökte detta med SQL Agent-varningar måste du skapa olika varningar per databas.
En annan bra varningsfunktion är möjligheten att skapa olika varningsscheman. Många organisationer har team som är ansvariga under olika delar av dagen. Vissa kan ha produktions-DBA:s ansvariga under dagtid med ett Network Operations Center som täcker nattskiftet, sedan en jourhavande över helgerna. Skulle det inte vara bra att kunna anpassa ett varningsschema för att meddela de rätta teamen under deras ansvarstid?
Du kan skapa varningsfönster (som i ett tidsfönster) och koppla dessa till olika varningar eller grupper. Detta gör att olika varningar kan vara aktiva under olika tidpunkter och för olika grupper att meddelas vid olika tidpunkter. Det här är riktigt coolt eftersom det låter din varning följa ett supportschema så att rätt personer meddelas. Scott Fallen beskriver den här funktionen i ett blogginlägg, "Alerting on a Call Schedule with SQL Sentry", som leder dig genom att skapa varningar för olika jourteam.
En annan varningsfunktion i Performance Advisor och Event Manager är möjligheten att konfigurera andra svar som att köra en Windows-process, logga händelsen till en databas eller fellogg, skicka en SNMP-fälla till ett annat övervakningsverktyg som SCOM, eller till och med döda en process . Dina alternativ är nästan obegränsade när det gäller vad du kan ha fördefinierat som ska hända när en viss händelse inträffar. SQL Agent Alerts är inte så anpassningsbara.
Sammanfattning
Det viktiga med det här inlägget är att du absolut måste vara uppmärksam på fel och prestandaförhållanden. Om du inte har ett verktyg som SQL Sentry är det fortfarande en bra början att använda SQL Agent Alerts.
Under mina kommande inlägg kommer jag att dyka in i några av dessa prestandapåverkande varningar och diskutera vilka åtgärder du skulle behöva vidta när de uppstår.