Als Datenbankadministrator haben Sie viele Pflichten, und zu wissen, was auf Ihrem SQL Server passiert, ist eine davon. Proaktiv zu sein und auf Fehler aufmerksam zu machen, ist eine der Eigenschaften, die jemanden zu einem großartigen DBA machen. Und ich spreche nicht nur davon, dass Dinge scheitern, was die meisten Leute denken, wenn sie alarmiert werden; Sie können auch über Leistungsprobleme benachrichtigt werden. Innerhalb von SQL Server haben Sie die Möglichkeit, SQL Server-Agent-Warnungen zu erstellen (die ich ab jetzt nur noch „Warnungen“ nennen werde), und dies lässt sich einfach über die GUI oder T-SQL erreichen.
Konfigurieren von SQL Server-Agent-Warnungen
Um Warnungen verwenden zu können, müssen Datenbank-E-Mail und ein SQL-Agent-Operator konfiguriert sein. Die meisten SQL-Instanzen, auf die ich gestoßen bin, haben bereits Datenbank-E-Mail für Jobfehlerbenachrichtigungen konfiguriert. Wenn Sie weitere Informationen zum Einrichten dieser Funktion benötigen, besuchen Sie das Thema "Datenbank-E-Mail konfigurieren" in der Online-Dokumentation.
Eine weniger bekannte Aufgabe ist die Konfiguration des Operators. Sie können den Operator mit SSMS oder T-SQL erstellen. Erweitern Sie in SSMS den SQL Server-Agent, klicken Sie mit der rechten Maustaste auf Operator und wählen Sie Neuer Operator. Es wird ein neues Dialogfeld geöffnet, in dem Sie dem Operator einen Namen geben und die zu benachrichtigende E-Mail-Adresse angeben können. Ich ziehe es vor, eine Verteilergruppe für die E-Mail-Benachrichtigungen zu verwenden. Die meisten Unternehmen haben mehr als eine Person, die für die SQL-Umgebung verantwortlich ist, und wenn Sie eine Verteilergruppe angeben, kann das gesamte Team über die Warnungen benachrichtigt werden. Die Verwendung von Verteilergruppen macht es auch viel einfacher, Personen zu den Benachrichtigungen hinzuzufügen oder daraus zu entfernen.
Unten ist ein Beispiel-Screenshot des Dialogfelds „Neuer Operator“:
Ich bevorzuge die Verwendung von T-SQL, damit ich sicherstellen kann, dass das Erstellen des Operators Teil einer Server-Build-Vorlage ist. Beispielcode zum Erstellen des obigen Operators lautet wie folgt:
EXEC msdb.dbo.sp_add_operator @name = N'SQL_Alerts', @enabled = 1, @email_address = N'[email protected]';
Sobald Sie Datenbank-E-Mail und den Operator konfiguriert haben, können Sie die Warnungen erstellen und sie dem Operator zuweisen.
Wenn Sie SSMS verwenden, können Sie den SQL Server-Agent und dann Warnungen erweitern. Standardmäßig werden keine Warnungen erstellt. Wenn Sie mit der rechten Maustaste klicken und „Neue Benachrichtigung“ wählen, erhalten Sie einen Bildschirm ähnlich der folgenden Abbildung:
Sie werden feststellen, dass es unter Schweregrad 25 Schweregradcodes gibt. So wie es sich anhört, beschreibt der Schweregrad der Fehlerstufe, wie wichtig der Fehler ist. Schweregrad 10 ist informativ, während 19-25 schwerwiegend sind und Sie benachrichtigt werden möchten, wenn diese Fehler auftreten. Wenn beispielsweise ein Fehler mit Schweregrad 23 aufgetreten ist, liegt höchstwahrscheinlich eine Beschädigung in einer Ihrer Datenbanken vor. Diese schwerwiegenden Fehler können sich alle auf die Leistung Ihres Servers auswirken, was sich wiederum auf das Kundenerlebnis auswirkt.
Es gibt eine zusätzliche Warnung, die Sie erstellen müssen, für Fehler 825. Fehler 825, wie Paul Randal in seinem Blogbeitrag beschreibt, bezieht sich auf eine E/A-Operation, die SQL Server wiederholen musste, die aber schließlich erfolgreich war (während die Fehler 823 und 824 zeigen an, dass eine E/A-Wiederholungsoperation wiederholt wurde und schließlich fehlgeschlagen ist). Es ist wichtig, Fehler 825 zu kennen, da er Sie auf E/A-Probleme hinweist, die in Zukunft schwerwiegend werden könnten. Jeder Wiederholungsversuch ist schlecht, Sie sollten nicht warten, bis eine E/A-Operation nicht benachrichtigt wird. Wenn Sie Fehler 825-Meldungen erhalten, müssen Sie sich sofort an Ihre Speicher- und Hardwareteams wenden.
Sie können jede der Warnungen erstellen, indem Sie den Namen angeben und den Schweregrad auswählen. Für Fehler 825 würden Sie Fehler auswählen und die Nummer eingeben. Wie beim Operator bevorzuge ich die Verwendung von T-SQL. Wenn ich einen Prozess einfach skripten kann, ist es viel einfacher, ihn wiederzuverwenden und als Teil eines Server-Builds einzubinden.
Unten finden Sie das Skript, das ich auf meiner SQL Server 2014 Developer-Workstation verwendet habe. Dieses Skript erstellt alle Warnungen und fügt dem Operator SQL_Alerts eine Benachrichtigung für die Warnung hinzu.
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;
Wenn Sie dem gefolgt sind, hätten Sie Datenbank-E-Mail konfiguriert, einen Operator erstellt, der Sie oder eine Verteilergruppe per E-Mail über potenzielle Fehler informiert, und SQL Server-Agent-Warnungen für Schweregrad 19–25 und Fehler 825 konfiguriert.
Das ist toll. Jedes Mal, wenn eine dieser Warnungen ausgelöst wird, wird eine E-Mail an Ihr Team gesendet. Zusätzlich zu Ereigniswarnungen können Warnungen für eine Leistungsbedingung konfiguriert werden, wie ich in der Einleitung erwähnt habe. Wenn beispielsweise die Speicherauslastung einen definierten Schwellenwert überschreitet, könnte eine Warnung ausgelöst werden. Ich ermutige Sie, die verschiedenen Leistungswarnungen zu erkunden und diejenigen zu erstellen, von denen Ihre Organisation profitieren könnte. Um die Warnungen zu den SQL Server-Leistungsbedingungen zu finden, klicken Sie im Dialogfeld „Neue Warnung“ auf das Dropdown-Feld für Typ. Dort sehen Sie eine Warnung zur SQL Server-Leistungsbedingung aufgelistet. Sobald Sie diese Option ausgewählt haben, können Sie die Objekttypen durchsuchen, für die Sie eine Leistungsbedingungswarnung konfigurieren können.
Während wir der Warnungsantwort einen Operator zugewiesen haben, könnten Sie die Warnung auch so konfigurieren, dass sie einen SQL Agent-Job ausführt. Dies gibt Ihnen zwar eine gewisse Flexibilität, um Ereignisreaktionsaufgaben zu haben, bietet jedoch nicht die Möglichkeit, einfache bedingte Warnungen zu haben.
Verwenden von SQL Sentry für erweiterte Benachrichtigungen
Für eine erweiterte Benachrichtigung benötigen Sie ein besseres Tool. Hier kann SQL Sentry helfen. Eine meiner bevorzugten Warnfunktionen von SQL Sentry ist die Möglichkeit, benutzerdefinierte Bedingungen zu erstellen, um zu warnen oder zu handeln, wenn sich etwas in der Umgebung geändert hat. Wenn beispielsweise jemand den minimalen oder maximalen Speicherwert, maxdop oder den Kostenschwellenwert für Parallelität geändert hat, könnten Sie eine Warnung erhalten oder sogar einen Prozess starten. Diese Funktion wurde in SQL Sentry v8 eingeführt, und Greg Gonzalez (Blog | @SQLsensei) hat hier darüber gebloggt:„SQL Sentry v8:Intelligent Alerting Redefined.“
Mit dieser Funktion können Sie auch benutzerdefinierte Bedingungen für verschiedene Datenbanken innerhalb einer einzigen Warnung erstellen. Wenn Sie dies mit SQL Agent-Warnungen versuchen würden, müssten Sie unterschiedliche Warnungen pro Datenbank erstellen.
Eine weitere großartige Warnfunktion ist die Möglichkeit, verschiedene Warnzeitpläne zu erstellen. Viele Organisationen haben Teams, die für verschiedene Tageszeiten verantwortlich sind. Bei einigen sind die DBAs für die Produktion tagsüber verantwortlich, während ein Network Operations Center die Nachtschicht abdeckt und am Wochenende eine Bereitschaftsperson. Wäre es nicht großartig, einen Benachrichtigungszeitplan anpassen zu können, um die richtigen Teams während ihrer Verantwortungsstunden zu benachrichtigen?
Sie können Alarmfenster (wie in einem Zeitfenster) erstellen und diese mit verschiedenen Alarmen oder Gruppen verknüpfen. Dadurch können unterschiedliche Warnungen zu unterschiedlichen Zeiten aktiv sein und unterschiedliche Gruppen zu unterschiedlichen Zeiten benachrichtigt werden. Das ist wirklich cool, da Ihre Benachrichtigungen einem Support-Zeitplan folgen können, sodass die richtigen Personen benachrichtigt werden. Scott Fallen beschreibt diese Funktion in einem Blog-Beitrag „Alerting on a Call Schedule with SQL Sentry“, in dem Sie durch die Erstellung von Benachrichtigungen für verschiedene Bereitschaftsteams geführt werden.
Eine weitere Warnfunktion von Performance Advisor und Event Manager ist die Möglichkeit, andere Reaktionen zu konfigurieren, z. B. das Ausführen eines Windows-Prozesses, das Protokollieren des Ereignisses in einer Datenbank oder einem Fehlerprotokoll, das Senden einer SNMP-Trap an ein anderes Überwachungstool wie SCOM oder sogar das Beenden eines Prozesses . Ihre Optionen sind nahezu grenzenlos, was Sie vordefinieren können, wenn ein bestimmtes Ereignis eintritt. SQL Agent Alerts sind nicht so anpassbar.
Zusammenfassung
Die wichtige Erkenntnis aus diesem Beitrag ist, dass Sie unbedingt auf Fehler und Leistungsbedingungen achten müssen. Wenn Sie kein Tool wie SQL Sentry haben, ist die Verwendung von SQL Agent Alerts immer noch ein guter Anfang.
In meinen nächsten Beiträgen werde ich auf einige dieser Warnmeldungen eingehen, die sich auf die Leistung auswirken, und erörtern, welche Maßnahmen Sie ergreifen müssen, wenn sie auftreten.
