Да бъдеш администратор на база данни има много отговорности и да знаеш какво се случва на вашия SQL Server е една от тях. Да бъдеш проактивен и предупреден за грешки е една от чертите, които правят някой страхотен DBA. И не говоря само за нещата, които се провалят, за което повечето хора си мислят, че ще бъдат предупредени; можете също да бъдете предупредени за проблеми с производителността. В рамките на SQL Server имате възможността да създавате сигнали за агент на SQL Server (които отсега нататък просто ще наричам „сигнали“) и това се постига лесно с помощта на GUI или T-SQL.
Конфигуриране на сигнали за агент на SQL Server
За да използвате сигнали, трябва да имате конфигурирани Database Mail и SQL Agent Operator. Повечето SQL екземпляри, на които съм срещал, вече имат Database Mail, конфигуриран за известия за неуспешни задачи. Ако имате нужда от допълнителна информация относно настройката на тази функция, посетете темата на Books Online, „Конфигуриране на поща от база данни.“
По-малко известна задача е конфигурирането на оператора. Можете да създадете оператора с помощта на SSMS или T-SQL. В рамките на SSMS разгънете SQL Server Agent, щракнете с десния бутон върху Оператор и изберете Нов оператор. Ще имате отворен нов диалогов прозорец, в който можете да дадете име на оператора и да посочите имейл адреса, който да уведоми. Предпочитам да използвам група за разпространение за имейл известия. Повечето компании имат повече от едно лице, отговорно за SQL средата и ако посочите група за разпространение, тогава целият екип може да бъде уведомен за сигналите. Използването на групи за разпространение също прави много по-лесно добавянето или премахването на хора от сигналите.
По-долу е дадена примерна екранна снимка на диалоговия прозорец за нов оператор:
Предпочитам да използвам T-SQL, за да мога да се уверя, че създаването на оператора е част от шаблон за изграждане на сървър. Примерен код за създаване на горния оператор е както следва:
EXEC msdb.dbo.sp_add_operator @name = N'SQL_Alerts', @enabled = 1, @email_address = N'[email protected]';
След като конфигурирате Database Mail и Оператора, можете да създадете сигнали и да ги присвоите на Оператора.
Ако използвате SSMS, можете да разширите SQL Server Agent и след това Alerts. По подразбиране не се създават сигнали. Ако щракнете с десния бутон и изберете Нов сигнал, ще получите екран, подобен на фигурата по-долу:
Ще забележите, че под сериозност има 25 кода за сериозност. Точно както звучи, нивото на тежест на грешката описва колко важна е грешката. Тежест 10 е информационна, докато 19-25 са фатални и ще искате да бъдете уведомени, когато възникнат тези грешки. Ако възникне грешка с тежест 23, например, тогава най-вероятно имате повреда в една от вашите бази данни. Всички тези фатални грешки могат да повлияят на производителността на вашия сървър, което от своя страна се отразява на изживяването на клиентите.
Има допълнителен сигнал, който трябва да създадете за грешка 825. Грешка 825, както Пол Рандал описва в публикацията си в блога, е свързана с I/O операция, която SQL Server трябваше да опита отново, но която в крайна сметка успява (докато грешки 823 и 824 показва, че операция за повторен I/O опит е била повторна и в крайна сметка е неуспешна). Грешка 825 е от решаващо значение, за да знаете, защото ви предупреждава за I/O проблеми, които могат да се окажат фатални в бъдеще. Всеки опит за повторен опит е лош, не трябва да чакате, докато една I/O операция не успее да бъде уведомена. Ако започнете да получавате съобщения за грешка 825, трябва незабавно да се свържете с вашите екипи за съхранение и хардуер.
Можете да създадете всяко от предупрежденията, като посочите името и изберете тежестта. За Грешка 825 ще изберете Грешка и ще въведете номера. Както при Operator, аз предпочитам да използвам T-SQL. Ако мога лесно да напиша даден процес, тогава е много по-лесно за повторно използване и включване като част от изграждане на сървър.
По-долу ще намерите скрипта, който използвах на моята работна станция за SQL Server 2014 Developer. Този скрипт създава всеки от сигналите и добавя известие за предупреждението към оператора 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;
Ако сте следвали, ще имате конфигурирана поща от базата данни, ще създадете оператор, който да изпраща имейл до вас или група за разпространение относно потенциални грешки, и сигналите за агент на SQL Server, конфигурирани за сериозност 19 – 25 и грешка 825.
Това е страхотно. Всеки път, когато някой от тези сигнали се задейства, имейл ще бъде изпратен до вашия екип. В допълнение към сигналите за събития, сигналите могат да бъдат конфигурирани за състояние на производителност, както споменах във въведението. Например, ако използването на паметта надхвърли определен праг, може да се задейства предупреждение. Насърчавам ви да проучите различните сигнали за ефективност и да създадете тези, от които вашата организация може да се възползва. За да намерите сигналите за условия на производителност на SQL Server, в новия диалогов прозорец за предупреждение щракнете върху падащото меню за Тип. Там ще видите изброен сигнал за състояние на производителност на SQL Server. След като изберете тази опция, можете да разглеждате типовете обекти, за които можете да конфигурирате сигнал за състояние на производителност.
Въпреки че присвоихме оператор към отговора на предупреждението, можете също да конфигурирате предупреждението да изпълнява задача на SQL агент. Въпреки че това ви дава известна гъвкавост, за да имате задача за реакция на събитие, то не предоставя възможност за лесно условно предупреждение.
Използване на SQL Sentry за разширени предупреждения
За по-разширено предупреждение се нуждаете от по-добър инструмент. Тук SQL Sentry може да помогне. Една от любимите ми функции за предупреждение на SQL Sentry е възможността да създавам персонализирани условия за предупреждение или действие, когато нещо се промени в средата. Например, ако някой промени минималната или максималната стойност на паметта, промени maxdop или прага на разходите за паралелизъм, можете да получите предупреждение или дори да стартирате процес. Тази функция беше въведена в SQL Sentry v8 и Грег Гонзалес (блог | @SQLsensei) публикува в блог за нея тук:„SQL Sentry v8:Интелигентно предупреждение е предефинирано.
С тази функция можете също да създадете персонализирани условия за различни бази данни в рамките на едно предупреждение. Ако сте опитали това с помощта на сигнали от SQL агент, ще трябва да създадете различни сигнали за всяка база данни.
Друга страхотна функция за предупреждение е възможността за създаване на различни графици за предупреждение. Много организации имат екипи, които отговарят през различни части на деня. Някои може да натоварят производствения DBA през дневните часове с център за мрежови операции, покриващ нощната смяна, а след това лице на повикване през уикендите. Не би ли било чудесно да можете да персонализирате график за известяване, за да уведомявате подходящите екипи по време на техните часове на отговорност?
Можете да създадете прозорци за предупреждения (както в прозорец от време) и да ги свържете с различни сигнали или групи. Това позволява различните сигнали да бъдат активни през различно време и различните групи да бъдат уведомявани по различно време. Това е наистина страхотно, тъй като позволява на вашето предупреждение да следва график за поддръжка, така че правилните хора да бъдат уведомени. Scott Fallen подробно описва тази функция в публикация в блога „Предупреждение при график за разговори с SQL Sentry“, като ви превежда през създаването на сигнали за различни екипи на повикване.
Друга предупреждаваща функция на Performance Advisor и Event Manager е възможността за конфигуриране на други отговори, като например изпълнение на процес в Windows, регистриране на събитието в база данни или регистър на грешки, изпращане на SNMP капан до друг инструмент за наблюдение, като SCOM, или дори убиване на процес . Възможностите ви са почти неограничени по отношение на това, което можете да сте дефинирали да се случи, когато настъпи определено събитие. Сигналите за SQL агент не са толкова персонализирани.
Резюме
Важното извлечение от тази публикация е, че абсолютно трябва да предупреждавате за грешки и условия за изпълнение. Ако нямате инструмент като SQL Sentry, тогава използването на сигнали за SQL агент все още е чудесно начало.
В следващите си няколко публикации ще се потопя в някои от тези сигнали, влияещи на производителността, и ще обсъдя какви действия трябва да предприемете, когато възникнат.
