Du bist Entwickler, kein Datenbankadministrator. Trotzdem landet die SQL Server Migration auf deinem Tisch, weil die interne IT mit SQL Server wenig anfangen kann und die Lieferanten immer nur ihren eigenen Teil umziehen. Pro Stunde abgerechnet, versteht sich. Und während die Datenbank selbst schnell verschoben ist, frisst die Server-Ebene drumherum die Zeit: Logins, Jobs, Linked Server, Konfiguration. Genau hier hilft ein Werkzeug, das die meisten Entwickler nicht kennen.
Das Verschieben der Datenbank ist nicht das Problem
Eine Datenbank umzuziehen, ist Handwerk: Backup, Restore, fertig. Das schafft jeder, der einmal RESTORE DATABASE getippt hat. Der teure Teil ist alles, was nicht in der Datenbank steckt, sondern auf Server-Ebene.
Server-Logins liegen nicht in der Anwenderdatenbank. Ziehst du nur die Datenbank um, hast du verwaiste Benutzer und Anmeldungen, die ins Leere laufen. SQL-Agent-Jobs liegen in der msdb, nicht in deiner Datenbank. Linked Server stehen in der master. Dazu kommen Credentials, Datenbank-Mail, sp_configure-Einstellungen, Zertifikate für verschlüsselte Datenbanken. Jedes vergessene Objekt ist ein Ticket am Montagmorgen.
Und wenn ein Lieferant nach Stunden abrechnet, hat er keinen Anreiz, das schnell und vollständig zu machen. Du als Entwickler hast den Anreiz, aber oft nicht das Detailwissen eines DBA, was alles mit muss. Genau diese Lücke schließt dbatools.
Was dbatools ist
dbatools ist ein freies, quelloffenes PowerShell-Modul mit über 700 Befehlen für die Automatisierung von SQL Server. Es wird seit Jahren von Chrissy LeMaire und einer großen Community gepflegt, liegt in der PowerShell Gallery (die alle Module auf Schadsoftware prüft) und wird laut Projekt sogar von Microsoft selbst eingesetzt. Es ersetzt nicht den DBA, aber es verpackt dessen Erfahrungswissen in Befehle, die auch ein Entwickler sicher bedienen kann.
Der entscheidende Punkt für unsere Lage: dbatools ist von Anfang an für Migrationen gebaut. Es funktioniert bis hinunter zu sehr alten SQL Server Versionen und sogar mit SQL Server Express, also genau dem Bestand, den man im Mittelstand vorfindet. Du musst nicht wissen, in welcher Systemdatenbank ein Agent-Job steht. Der Befehl weiß es.
Installation und gefahrloses Ausprobieren
Die Installation ist eine Zeile in PowerShell. Der folgende Befehl lädt das Modul aus der PowerShell Gallery, das dauert etwa eine halbe Minute:
Install-Module dbatools -Scope CurrentUser
Der Scope CurrentUser installiert ohne Administratorrechte nur für dein Konto, was zum Ausprobieren völlig reicht. dbatools läuft unter Windows mit PowerShell 5.1 und unter PowerShell 7, plattformübergreifend auch auf Linux und macOS.
Bevor du irgendetwas veränderst, kannst du gefahrlos schauen. Lesende Befehle richten keinen Schaden an. Der folgende Aufruf listet alle Datenbanken einer Instanz auf:
Get-DbaDatabase -SqlInstance sql01
Der Wert hinter -SqlInstance ist dein Servername oder, wenn du den vorherigen Beitrag gelesen hast, am besten dein DNS-Alias. Fast alle Befehle folgen diesem Muster: ein Verb, ein Objekt mit dem Präfix Dba, dann der Parameter -SqlInstance. Wer ein Kommando kennt, kann die anderen erraten.
Der „easy button“: eine ganze Instanz mit einem Befehl
Für den Fall, dass du wirklich eine komplette Instanz auf neue Hardware oder eine neue Version umziehst, gibt es Start-DbaMigration. Das Projekt nennt es selbst den „easy button“. Der folgende Aufruf migriert per Backup und Restore über eine Dateifreigabe von einem Server auf den nächsten:
$params = @{
Source = 'sql01'
Destination = 'sql02'
BackupRestore = $true
SharedPath = '\\nas\migration'
}
Start-DbaMigration @params -Verbose
Was dieser eine Befehl alles mitnimmt, ist der eigentliche Wert: alle Benutzerdatenbanken, alle Logins inklusive Passwörter, SIDs sowie Datenbank- und Serverrollen, dazu SQL-Agent-Jobs mit Zeitplänen und Operatoren, Linked Server, Credentials, Datenbank-Mail, sp_configure-Einstellungen und einiges mehr. Die Logins werden mit ihrer originalen SID übertragen, womit das Problem der verwaisten Benutzer von selbst verschwindet, ohne dass du ein einziges sp_help_revlogin-Skript anfassen musst.
Für eine kontrollierte Übergabe gibt es nützliche Schalter. -UseLastBackup nutzt vorhandene Sicherungen statt neue zu ziehen. -DisableJobsOnDestination schaltet die migrierten Jobs auf dem Zielserver erst einmal ab, damit nachts nichts losläuft, bevor du bereit bist. Mit -Exclude lässt du gezielt Bestandteile weg.
Der realistische Fall: ein Stück nach dem anderen
In der Praxis migrierst du selten eine ganze Instanz auf einmal. Bei dir zieht ein Lieferant nach dem anderen seine eine Anwendung um. Für genau diese gestaffelte Realität gibt es die granularen Befehle, aus denen Start-DbaMigration zusammengesetzt ist.
Eine einzelne Datenbank samt der zugehörigen Anmeldung holst du so auf den neuen Server. Der erste Befehl kopiert die Datenbank per Backup und Restore, der zweite bringt die passende Anmeldung mit allen Berechtigungen hinterher:
Copy-DbaDatabase -Source sql01 -Destination sql02 -Database WaWi `
-BackupRestore -SharedPath '\\nas\migration'
Copy-DbaLogin -Source sql01 -Destination sql02 -Login 'kunde\wawi_app'
Das Entscheidende ist die zweite Zeile: Sie ist der Schritt, den Handarbeit am häufigsten vergisst und der die meisten Tickets nach einer Migration verursacht. Brauchst du nur die Jobs oder nur die Linked Server eines Bestandsservers, gibt es dafür eigene Befehle:
Copy-DbaAgentJob -Source sql01 -Destination sql02
Copy-DbaLinkedServer -Source sql01 -Destination sql02
So baust du dir aus drei, vier Befehlen genau den Umzug zusammen, den ein Lieferant für seine eine Anwendung schuldig bleibt, und kümmerst dich um die Querschnitts-Objekte, die zwischen den Zuständigkeiten durchfallen.
Inventur und Sicherheitsnetz
Zwei Befehle lohnen sich, bevor überhaupt migriert wird. Export-DbaInstance schreibt alles, was auf einem Server lebt, als Skripte heraus: Logins, Jobs, Datenbanken, Konfiguration. Das ist gleichzeitig deine Notfall-Dokumentation und die Inventur, die jede saubere Migration braucht.
Export-DbaInstance -SqlInstance sql01 -Path C:\temp\inventur
Der zweite ist Test-DbaLastBackup. Er nimmt die letzte Sicherung, spielt sie auf einem Testserver ein, führt DBCC CHECKDB darauf aus und wirft sie wieder weg. Damit weißt du nicht nur, dass ein Backup existiert, sondern dass es sich auch wirklich zurücksichern lässt. Ein Backup, das nie getestet wurde, ist eine Hoffnung, kein Sicherungskonzept.
Wo dbatools an Grenzen stößt
Eine ehrliche Einordnung gehört dazu, sonst klingt das nach einem Wundermittel, und das ist es nicht. dbatools automatisiert die Ausführung, nicht das Urteil. Du brauchst trotzdem einen Migrationsplan, ein Wartungsfenster und einen Rückweg, falls etwas schiefgeht. Erst im Testsystem proben, dann in Produktion.
Die Befehle brauchen ausreichende Rechte, für eine Instanz-Migration in der Regel sysadmin auf beiden Servern, und PowerShell-Zugriff zwischen den Maschinen, was mit der internen IT und manchmal mit dem Sicherheitsteam abzustimmen ist. Cluster und Always-On-Verfügbarkeitsgruppen verhalten sich anders und wollen gesondert getestet werden. Sehr große Datenbanken zieht man besser über Log Shipping vor, statt sie im Wartungsfenster komplett zu kopieren. Und eines übernimmt dbatools bewusst nicht: die Verbindungseinstellungen der Anwendungen umzubiegen. Das ist die Aufgabe der DNS-Alias-Schicht aus dem vorigen Beitrag.
Was das wirtschaftlich bedeutet
Solange jeder Lieferant seinen Teil nach Stunden abrechnet, ist Handarbeit das Geschäftsmodell der anderen Seite. Wer als interner Entwickler die Querschnitts-Aufgaben (Logins, Jobs, Linked Server, Konfiguration) in Minuten statt in abgerechneten Stunden erledigt, dreht die Wirtschaftlichkeit um. Eine Instanz-Migration, die mit Klickarbeit ein langes Wochenende war, wird zu einem überschaubaren Skript, das man vorher im Testsystem geprobt hat.
Wenn dich nicht das Werkzeug interessiert, sondern die Frage, ob diese Migrationen überhaupt jedes Mal teuer extern eingekauft werden müssen oder ob man die Landschaft so aufstellt, dass Umzüge intern beherrschbar bleiben: dazu schreibe ich aus Entscheider-Sicht. Frag mich danach, dann verlinke ich den passenden Beitrag.
Fazit
dbatools nimmt dir als Entwickler genau das ab, was an einer SQL Server Migration DBA-Wissen verlangt: die vollständige Übertragung der Server-Ebene, ohne dass du wissen musst, in welcher Systemdatenbank welches Objekt liegt. Über 700 geprüfte Befehle, frei und quelloffen, lauffähig bis zum ältesten Bestand. Ein Werkzeug, das genau für diese Aufgabe gebaut wurde, schlägt jede von Hand abgerechnete Stunde.
Ein guter Einstieg ist, das Modul zu installieren und mit den lesenden Befehlen die eigene Landschaft anzuschauen. Wer eine anstehende Migration vorher einmal mit jemandem durchsprechen möchte, der das oft gemacht hat, erreicht mich über sesoft.de/kontakt.
Quellen
- dbatools, Projektseite und Befehlsübersicht (700+ Befehle, frei und quelloffen): dbatools.io
- Erste Schritte und Installation: dbatools.io/getting-started, dbatools.io/install
Start-DbaMigration, migrierte Bestandteile (Logins mit SID und Passwort, Jobs, Linked Server, Credentials, sp_configure): dbatools.io/Start-DbaMigration- Buch zum Einstieg, „Learn dbatools in a Month of Lunches“ von Chrissy LeMaire, Rob Sewell, Jess Pomfret und Cláudio Silva: Manning
Über den Autor
Sönke Schäfer ist selbstständiger IT-Berater und Datenarchitekt aus Ostholstein und arbeitet seit über 25 Jahren mit Microsoft Access, VBA und SQL Server. Er begleitet im norddeutschen Mittelstand Migrationen und Datenbank-Modernisierungen und automatisiert wiederkehrende SQL-Server-Aufgaben, damit Entwicklerzeit nicht in Klickarbeit versickert. Mehr über Sönke Schäfer und Der Datenschäfer.
