Bycie administratorem bazy danych wiąże się z wieloma obowiązkami, a jednym z nich jest wiedza o tym, co dzieje się na serwerze SQL. Bycie proaktywnym i ostrzeganym o błędach to jedna z cech, które sprawiają, że ktoś jest świetnym DBA. I nie mówię tylko o niepowodzeniach, o czym większość ludzi myśli, że są ostrzegani; możesz również zostać ostrzeżony o problemach z wydajnością. W SQL Server masz możliwość tworzenia alertów agenta SQL Server (które od teraz będę nazywać „alertami”), a to można łatwo osiągnąć za pomocą GUI lub T-SQL.
Konfigurowanie alertów agenta SQL Server
Aby używać alertów, musisz mieć skonfigurowaną pocztę bazy danych i operatora agenta SQL. Większość napotkanych przeze mnie wystąpień SQL ma już skonfigurowaną pocztę bazy danych dla powiadomień o niepowodzeniu zadania. Jeśli potrzebujesz dalszych informacji na temat konfigurowania tej funkcji, odwiedź temat Books Online „Konfigurowanie poczty bazy danych”.
Mniej znanym zadaniem jest konfiguracja Operatora. Operatora można utworzyć za pomocą SSMS lub T-SQL. W ramach SSMS rozwiń SQL Server Agent, kliknij prawym przyciskiem myszy Operator i wybierz Nowy operator. Otworzy się nowe okno dialogowe, w którym możesz nadać operatorowi nazwę i podać adres e-mail do powiadomienia. Wolę używać grupy dystrybucyjnej do powiadomień e-mail. Większość firm ma więcej niż jedną osobę odpowiedzialną za środowisko SQL i jeśli określisz grupę dystrybucyjną to cały zespół może zostać powiadomiony o alertach. Korzystanie z grup dystrybucyjnych znacznie ułatwia również dodawanie lub usuwanie osób z alertów.
Poniżej znajduje się przykładowy zrzut ekranu okna dialogowego Nowy operator:
Wolę używać T-SQL, aby mieć pewność, że tworzenie Operatora jest częścią szablonu budowy serwera. Przykładowy kod do utworzenia powyższego Operatora jest następujący:
EXEC msdb.dbo.sp_add_operator @name = N'SQL_Alerts', @enabled = 1, @email_address = N'[email protected]';
Po skonfigurowaniu poczty bazy danych i operatora możesz tworzyć alerty i przypisywać je do operatora.
Jeśli używasz programu SSMS, możesz rozwinąć SQL Server Agent, a następnie Alerty. Domyślnie nie są tworzone żadne alerty. Jeśli klikniesz prawym przyciskiem myszy i wybierzesz Nowy alert, pojawi się ekran podobny do poniższego:
Zauważysz, że pod Severity znajduje się 25 kodów ważności. Tak jak się wydaje, waga poziomu błędu opisuje, jak ważny jest błąd. Poziom ważności 10 ma charakter informacyjny, a 19-25 jest fatalny i będziesz chciał zostać powiadomiony, gdy pojawią się te błędy. Jeśli na przykład pojawił się błąd 23, najprawdopodobniej masz uszkodzenie jednej ze swoich baz danych. Te krytyczne błędy mogą mieć wpływ na wydajność serwera, co z kolei wpływa na wrażenia klientów.
Istnieje dodatkowy alert, który należy utworzyć dla błędu 825. Błąd 825, jak opisuje Paul Randal w swoim poście na blogu, jest związany z operacją we/wy, którą SQL Server musiał ponowić, ale która ostatecznie się powiodła (podczas gdy błędy 823 i 824 wskazują, że ponowna próba operacji we/wy zakończyła się niepowodzeniem). Błąd 825 ma kluczowe znaczenie, ponieważ ostrzega o problemach we/wy, które mogą w przyszłości stać się fatalne. Każda ponowna próba jest zła, nie należy czekać, aż operacja We/Wy nie zostanie powiadomiona. Jeśli zaczniesz otrzymywać komunikaty o błędzie 825, musisz natychmiast skontaktować się ze swoimi zespołami zajmującymi się pamięcią masową i sprzętem.
Możesz utworzyć każdy z alertów, określając nazwę i wybierając poziom ważności. W przypadku błędu 825 należy wybrać błąd i wpisać numer. Podobnie jak w przypadku Operatora, wolę używać T-SQL. Jeśli mogę z łatwością napisać skrypt, znacznie łatwiej będzie go ponownie użyć i włączyć jako część kompilacji serwera.
Poniżej znajdziesz skrypt, którego użyłem na mojej stacji roboczej SQL Server 2014 Developer. Ten skrypt tworzy każdy z alertów i dodaje powiadomienie dla alertu do operatora 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;
Jeśli postępowałeś zgodnie z instrukcjami, masz skonfigurowaną pocztę bazy danych, utworzysz operatora, który będzie wysyłał Ci e-maila lub grupę dystrybucyjną o potencjalnych błędach, oraz alerty agenta SQL Server skonfigurowane dla poziomu ważności 19–25 i błędu 825.
To jest świetne. Za każdym razem, gdy jeden z tych alertów zostanie uruchomiony, do Twojego zespołu zostanie wysłany e-mail. Oprócz alertów o zdarzeniach, alerty można skonfigurować dla stanu wydajności, o czym wspomniałem we wstępie. Na przykład, jeśli użycie pamięci przekracza zdefiniowany próg, może zostać wyzwolony alert. Zachęcam do zapoznania się z różnymi alertami dotyczącymi wydajności i stworzenia tych, z których Twoja organizacja może skorzystać. Aby znaleźć alerty dotyczące warunków wydajności programu SQL Server, w oknie dialogowym nowego alertu kliknij pole rozwijane typu. Zostanie tam wyświetlony alert dotyczący warunków wydajności programu SQL Server. Po wybraniu tej opcji możesz przeglądać typy obiektów, dla których możesz skonfigurować alert warunków wydajności.
Chociaż przypisaliśmy Operatora do odpowiedzi na alert, możesz również skonfigurować alert, aby wykonać zadanie SQL Agent. Chociaż daje to pewną elastyczność w zakresie zadania odpowiedzi na zdarzenia, nie zapewnia możliwości łatwego ostrzegania warunkowego.
Używanie SQL Sentry do zaawansowanego ostrzegania
Aby uzyskać bardziej zaawansowane alerty, potrzebujesz lepszego narzędzia. Tutaj może pomóc SQL Sentry. Jedną z moich ulubionych funkcji alertów SQL Sentry jest możliwość tworzenia niestandardowych warunków do ostrzegania lub działania, gdy coś się zmieniło w środowisku. Na przykład, jeśli ktoś zmienił minimalną lub maksymalną wartość pamięci, zmodyfikował maxdop lub próg kosztu dla równoległości, możesz otrzymać alert, a nawet uruchomić proces. Ta funkcja została wprowadzona w SQL Sentry v8, a Greg Gonzalez (blog | @SQLsensei) napisał o niej na blogu tutaj:„SQL Sentry v8:Intelligent Alerting Redefined”.
Dzięki tej funkcji możesz również tworzyć niestandardowe warunki dla różnych baz danych w ramach jednego alertu. Jeśli próbowałeś to zrobić za pomocą alertów SQL Agent, musiałbyś utworzyć różne alerty dla każdej bazy danych.
Kolejną świetną funkcją alertów jest możliwość tworzenia różnych harmonogramów alertów. Wiele organizacji ma zespoły odpowiedzialne w różnych porach dnia. Niektórzy mogą mieć odpowiedzialnego DBA ds. produkcji w ciągu dnia z centrum operacyjnym sieci obejmującym nocną zmianę, a następnie z osobą dyżurującą w weekendy. Czy nie byłoby wspaniale móc dostosować harmonogram alertów, aby powiadamiać odpowiednie zespoły w godzinach ich odpowiedzialności?
Możesz utworzyć Okna alertów (jak w oknie czasowym) i powiązać je z różnymi alertami lub grupami. Dzięki temu różne alerty mogą być aktywne w różnym czasie i różne grupy mogą być powiadamiane o różnych porach. To jest naprawdę fajne, ponieważ pozwala na śledzenie harmonogramu wsparcia, dzięki czemu powiadamiane są odpowiednie osoby. Scott Fallen szczegółowo opisuje tę funkcję w poście na blogu „Alerting on a Call Schedule with SQL Sentry”, prowadząc Cię przez proces tworzenia alertów dla różnych zespołów dyżurnych.
Inną funkcją ostrzegania Performance Advisor i Event Manager jest możliwość konfigurowania innych odpowiedzi, takich jak wykonanie procesu Windows, rejestrowanie zdarzenia w bazie danych lub dzienniku błędów, wysyłanie pułapki SNMP do innego narzędzia monitorującego, takiego jak SCOM, a nawet zabicie procesu . Twoje opcje są prawie nieograniczone, jeśli chodzi o to, co możesz wstępnie zdefiniować, aby wydarzyło się określone zdarzenie. Alerty agenta SQL nie są tak konfigurowalne.
Podsumowanie
Ważnym wnioskiem z tego postu jest to, że absolutnie musisz ostrzegać o błędach i warunkach wydajności. Jeśli nie masz narzędzia takiego jak SQL Sentry, korzystanie z alertów agenta SQL jest nadal dobrym początkiem.
W kilku następnych postach zagłębię się w niektóre z tych alertów wpływających na wydajność i omówię, jakie działania należy podjąć, gdy się pojawią.
