Übernahme von MSSQL-Datenbank-Servern in unsere Verantwortung

Brentozar.com - sp_BLITZ - SQL Server Takeover Script

Unser Arbeitgeber sieht eine seiner Kernkompetenzen im Bereich Outsourcing, dadurch kommen immer wieder neue Umgebungen, Installationen und Situationen rund um die Betreuung von MSSQL-Servern auf uns zu.
Somit stehen wir fast täglich vor der Aufgabe diese neuen Server erstmal zu analysieren und überprüfen, damit wir einen groben Überblick haben. Hierzu gehören Themen wie:

  • Welche Edition ist installiert? Standard, Enterprise? 32 oder 64 Bit?
  • Wieviele Instanzen gibt es?
  • Wie groß sind die Datenbanken?
  • Wo liegen die Datenbanken? Liegen die vielleicht sogar auf dem C-Laufwerk?
  • Wieviel Plattenplatz steht noch zur Verfügung?
  • Wann ist das letzte Backup gelaufen und womit wird gesichert?
  • Welche Wartungspläne gibt es? Wann laufen die?
  • Gibt es Auffälligkeiten in den Error-/System-Logs?
  • Welche User verfügen über „sysadmin“-Rechte?
  • Werden unsere „Best-Practise“-Standards eingehalten?
  • Können wir unsere Security-Baseline einhalten oder müssen wir Anpassungen durchführen?

Diese Fragestellungen tauchen jedes Mal wieder auf und jedes Mal benötigt man mehrere Stunden für einen Server, um sich die relevanten Punkte einzeln zusammenzuklicken. Dann müssen die entsprechend dokumentiert und ausgewertet werden. Jede MSSQL-Datenbank-Installation bzw Instanz muss dann aus diesen gesammelten Daten in eine CMDB eingepflegt werden.

Wie kann man solche wiederkehrenden Tätigkeiten vereinfachen?
Kann man das nicht irgendwie skripten?

Kann man bestimmt! Da wir aber nicht unbedingt die Experten in Sachen TSQL-Entwicklung sind, andere bestimmt ähnliche Themen haben und sich schon mal Gedanken gemacht haben, bemühten wir eine bekannte Suchmaschine… Zahlreiche Beiträge, Ideen und Skripte gelesen und ausprobiert.

Brentozar.com - sp_BLITZ - MSSQL Server Takeover Script
Brentozar.com - sp_BLITZ - SQL Server Takeover Script

Das einfachste und beste, was uns im Zusammenhang mit solchen „Betriebsübernahmen“ in die Hände kam, war die StoredProcedure „sp_blitz“ von Brent Ozar.
Brent und sein Team haben hier ein (aus unserer Sicht) super Skript geschrieben, es analysiert weitestgehend alle relevanten Themen wie Backup, Performance und Security und liefert zu jeder gefundenen „Auffälligkeit“ eine ausführliche und gut dokumentierte Beschreibung und Lösungsansätze. Mittels dieser ersten Analyse, welche wir in unserem Sharepoint ablegen, erhalten wir einen großen Teil an Informationen und Hinweise auf mögliche bestehende Probleme, hieraus erstellen wir dann einen ToDo-Plan für jeden MSSQL-Datenbankserver, den wir dann mit dem zuständigen Ansprechpartner besprechen und zur Umsetzung einen „Fahrplan“ aufsetzen.

Für alle anderen für uns wichtigen Punkte, die wir für unsere CMDB benötigen, ermitteln wir ebenfalls per Skript, dieses haben wir allerdings selbst geschrieben und ist auf unsere CMDB abgestimmt. Mittels beider Skripte konnten die benötigte Zeit für solch eine Übernahme mit gutem Gewissen von fast einem Tag auf gut 1 Stunde reduzieren.
Auch hier kommt wieder uns grundlegendes Motto zum Tragen: Nur ein ruhiger Tag ist ein guter Tag… möglichst alles automatisiert, standardisiert und dadurch genügend Zeit gewinnen um sich um andere Dinge zu kümmern. (z.B. aktuell MSSQL 2012 – Cluster Installation in den verschiedensten Ausprägungen – mit und/oder ohne AvailibilityGroups usw – darüber berichten wir später)

Björn arbeitet in Hamburg als Datenbank-Administrator und Head of Competence für MS SQL und mySQL. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und SQLGrillen teil und er organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.

3 thoughts on “Übernahme von MSSQL-Datenbank-Servern in unsere Verantwortung

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.