In heterogenen IT-Umgebungen kann man auf vieles treffen. Heute geht es um die Überwachung von MSSQL. Hier gibt es verschiedene Kanäle die man nutzen kann.
Zum einen ist da das Betriebssystem, das einem in Eventlog und WMI viele Infos bereitstellt. Hierzu benötigt man z.B. den NSClient, zu dem es in diesem Blog eine komplette Serie gibt. Über diesen kommt man an beides ran.
Des weiteren gibt es von Gerhard Lauser das Plugin check_mssql_health mit Hilfe dessen man z.B. an Werte wie connection-time, connected-users, lock-waits oder deadlocks bekommt. Informationen und eine genaue Anleitung gibt’s hier.
Was man allerdings über diese Mittel nicht überwachen kann sind die konkreten Jobs die auf dem DBMS laufen.
Hierzu bietet MSSQL eine stored Procedure name sp_help_job. Um diese benutzen zu können und die Jobs aller User zu sehen muss der Monitoring User die Rolle SQLAgentReaderRole oder SQLAgentOperatorRole einnehmen.
Ruft man sp_help_job ohne alles auf, bekommt man eine Tabelle alles eingerichteten Jobs. Die sollte man prinzipiell mit ‚@enabled = 1‘ einschränken um nur aktive Jobs zu bekommen.
Reichen einem diese Informationen noch nicht, sollte man noch einen Blick auf die TARGETS Tabelle werfen. Hier befinden sich Informationen zu dem letzten Lauf wie die last_run_duration, last_run_outcome oder last_run_date. Aber Obacht: Die Formatierung des Datums und der Zeit ist sehr gewöhnungsbedürftig. Die Zahl 113300 bedeutet z.B. 11:33 Uhr. Führende Nullen werden weggelassen.
Der Aufruf in Transact SQL lautet: sp_help_job @job_name = ‚<jobname>‘, @job_aspect = ‚TARGETS‘
Möchte man das ganze jetzt automatisieren stehen einem auch wieder mehrere Wege offen. Hat man Perl in sein NSClient integriert kann man dieses benutzen. Dank DBD:Sybase kann man einfach auf alle Daten von MSSQL zugreifen.
Denkbar wäre aber auch ein Powershellscript oder eine beliebige andere Sprache die auf Windows ausführbar ist.
0 Kommentare