Wer für einen Kunden Datenbanken auf Basis von SQL Server programmiert, tut gut daran, nicht am offenen Herzen zu operieren, sprich: Änderungen an einer Datenbank erst an einer Kopie dieser Datenbank auszuprobieren. Wer seine eigenen Datenbanken auch auf dem SQL Server verwaltet, gerät da schon leichter in Versuchung, mal eben schnell eine Änderung am laufenden Produktivsystem durchzuführen. Auch wenn man meint, man wüsste genau, was man tut, macht es doch Sinn, zumindest eine Sicherheitskopie der zu bearbeitenden Datenbank anzulegen. Nun bietet der SQL Server keine einfache Lösung zum Herstellen einer Kopie á la Strg + C, Strg + V an. Allerdings wird man dennoch schnell fündig, wenn man nach einer entsprechenden Lösung sucht – in diesem Fall allerdings nur in höheren SQL Server-Editionen, also nicht in der Express Edition.
Logisch: Bevor man einem Kunden eine neue Version einer Datenbank übermittelt, wird diese erst einmal ordentlich getestet. Ohnehin werden Änderungen ja meist weniger durch Kopieren der kompletten Datenbank übertragen, sondern durch Hinzufügen der neuen Elemente und Entfernen oder Ändern vorhandener Elemente durch Methoden wie einem SQL-Skript realisiert.
Wenn man seine eigene Datenbank auf dem eigenen Rechner betreibt, kann es schon eher passieren, dass man mal eben schnell eine Änderung durchführt. Ein neues Feld, eine neue Tabelle, eine neue Beziehung sind schnell angelegt. Was aber, wenn man eine Änderung durchführt, die dazu führt, dass die Anwendung nicht mehr wie gewohnt funktioniert? Wenn man dann nicht regelmäßig eine Sicherung angelegt hat, kann die Wiederherstellung der letzten funktionierenden Variante schon aufwendiger werden.
Was man aber tun könnte, ist das Anlegen einer Kopie der SQL Server-Datenbank, mit der man die geplanten Änderungen erst einmal durchführt und diese dann nach erfolgreichem Test auf die Produktdatenbank überträgt.
Dazu fehlt nur noch eine einfache Methode, mal eben eine Kopie der Datenbank anzulegen. Diese Methode ist allerdings, wenn man das SQL Server Management Studio verwendet, gar nicht so weit weg. Wir brauchen dazu auch keine Sicherung anzulegen und diese unter einem neuen Namen wiederherzustellen, sondern wir können einfach die eingebaute Funktion zum Kopieren einer Datenbank verwenden.
Datenbank kopieren als Task
Diese Methode finden wir, wenn wir das Kontextmenü für die zu kopierende Datenbank aufklappen und dort den Eintrag Tasks|Datenbank kopieren… auswählen (siehe Bild 1).
Bild 1: Kopieren einer SQL Server-Datenbank
Auswählen des Quellservers
Im nächsten Schritt aus Bild 2 wählen wir den Quellserver aus, also den Datenbankserver, auf dem sich die zu kopierende Datenbank befindet. Hier legen wir außerdem die Authentifizierungsmethode fest und, falls die SQL Server-Authentifizierung verwendet werden soll, auch noch Benutzername und Kennwort (siehe Bild 3).
Bild 2: Festlegen des Quellservers
Bild 3: Erster Schritt im Assistenten zum Kopieren von Datenbanken
Auswählen der Übertragungsmethode
Nun wählen wir aus, wie die Datenbank kopiert werden soll. Es stehen zwei Methoden zur Auswahl. Bei der ersten muss die zu kopierende Datenbank zuvor getrennt werden und wird nach dem Kopieren wieder angefügt. Diese Option ist für sehr große Datenbanken geeignet, aber es dürfen zum Zeitpunkt des Kopiervorgangs keine Benutzer auf die Datenbank zugreifen. Die andere Option (SMO) ist langsamer, aber die Datenbank kann weiter verwendet werden (siehe Bild 4).
Bild 4: Auswählen der Übertragungsmethode
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo