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 \u00e1 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.<\/b><\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Diese Methode finden wir, wenn wir das Kontextmenü für die zu kopierende Datenbank aufklappen und dort den Eintrag Tasks|Datenbank kopieren… <\/b>auswählen (siehe Bild 1).<\/p>\n
![\"Kopieren](\"..\/fileadmin\/_temp_\/2024_05\/pic_1519_001.png\")
<\/p>\n
Bild 1: Kopieren einer SQL Server-Datenbank<\/span><\/b><\/p>\n 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).<\/p>\n Bild 2: Festlegen des Quellservers<\/span><\/b><\/p>\n Bild 3: Erster Schritt im Assistenten zum Kopieren von Datenbanken<\/span><\/b><\/p>\n 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).<\/p>\n Bild 4: Auswählen der Übertragungsmethode<\/span><\/b><\/p>\n Auch, wenn wir den Kontextmenübefehl zum Kopieren der Datenbank für die zu kopierende Datenbank aufgerufen haben, bekommen wir im nächsten Dialog nochmals Gelegenheit, die Datenbank auszuwählen. Diese ist allerdings zumindest schon einmal vorselektiert, sodass wir nur noch auf Weiter <\/b>klicken müssen (siehe Bild 5).<\/p>\n Bild 5: Auswählen der Quelldatenbank<\/span><\/b><\/p>\n Dass wir die Datenbank auch physisch kopieren, erkennen wir im folgenden Dialog aus Bild 6. Hier können wir nämlich nicht nur den Namen der neuen Datenbank festlegen, sondern auch noch die Zieldateien. Außerdem können wir hier angeben, ob eine eventuell bereits bestehende Datenbank überschrieben werden soll.<\/p>\n Bild 6: Angabe des Namens für die Zieldatenbank und der Zieldateien<\/span><\/b><\/p>\n Im übernächsten Schritt legen wir fest, ob wir den Kopiervorgang sofort ausführen wollen oder nach einem bestimmten Zeitplan. Wir wollen hier direkt kopieren, also behalten wir die erste Option bei und klicken auf Weiter <\/b>(siehe Bild 7).<\/p>\n Bild 7: Festlegen, wann die Kopie erstellt werden soll<\/span><\/b><\/p>\n Bevor der Kopiervorgang durchgeführt wird, sehen wir noch einmal eine Zusammenfassung der durchzuführenden Schritte. Schließlich erhalten wir, wie in Bild 8 zu sehen, eine Zusammenfassung des Kopiervorgangs. Danach finden wir nach dem Aktualisieren des Objekt-Explorers im SQL Server Management Studio die Kopie der Datenbank vor.<\/p>\n Bild 8: Ergebnisse des Kopiervorgangs<\/span><\/b><\/p>\n Damit haben wir eine Kopie einer Datenbank im laufenden Betrieb erstellt, was sonst eine höhere Edition des SQL Servers erfordert hätte – mit der Express Edition gelingt dies durch den fehlenden SQL Server Agent nicht. Wir können nun die gewünschten Tests an der Kopie durchführen. Was aber, wenn wir die notwendigen Änderungen durchgeführt und getestet haben – wie bekommen wir heraus, was wir nun genau geändert haben und wie wir diese Änderungen in die Produktivdatenbank überführen? Das erläutern wir im Beitrag Schemata von SQL Server-Datenbanken vergleichen <\/b>(www.access-im-unternehmen.de\/1519<\/b>).<\/p>\n","protected":false},"excerpt":{"rendered":" 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 \u00e1 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662024,66052024,44000022],"tags":[],"class_list":["post-55001519","post","type-post","status-publish","format-standard","hentry","category-662024","category-66052024","category-SQL_Server_und_Co"],"yoast_head":"\nAuswählen des Quellservers<\/h2>\n
![\"Festlegen](\"..\/fileadmin\/_temp_\/2024_05\/pic_1519_003.png\")
<\/p>\n![\"Erster](\"..\/fileadmin\/_temp_\/2024_05\/pic_1519_002.png\")
<\/p>\nAuswählen der Übertragungsmethode<\/h2>\n
![\"Auswählen](\"..\/fileadmin\/_temp_\/2024_05\/pic_1519_005.png\")
<\/p>\nDatenbank auswählen<\/h2>\n
![\"Auswählen](\"..\/fileadmin\/_temp_\/2024_05\/pic_1519_006.png\")
<\/p>\nZieldatenbank festlegen<\/h2>\n
![\"Angabe](\"..\/fileadmin\/_temp_\/2024_05\/pic_1519_007.png\")
<\/p>\nSofort kopieren?<\/h2>\n
![\"Festlegen,](\"..\/fileadmin\/_temp_\/2024_05\/pic_1519_009.png\")
<\/p>\nErgebnis des Kopiervorgangs<\/h2>\n
![\"Ergebnisse](\"..\/fileadmin\/_temp_\/2024_05\/pic_1519_011.png\")
<\/p>\nZusammenfassung und Ausblick<\/h2>\n