Es kann in verschiedenen Szenarien sinnvoll sein, einmal den Unterschied zwischen zwei Versionen einer SQL Server-Datenbank zu vergleichen. Gibt es überhaupt Unterschiede? Welche Unterschiede sind das? Wurden Tabellen, Felder, Sichten, gespeicherte Prozeduren oder Trigger hinzugefügt oder entfernt? Wenn wir das herausfinden, können wir zum Beispiel identifizieren, welche Änderungen seit der letzten Veröffentlichung einer Datenbank als Produktivdatenbank in der Entwicklungsdatenbank durchgeführt wurden oder wir können herausfinden, wodurch ein Fehler ausgelöst werden könnte, der seit einem bestimmten Versionsstand immer wieder auftritt. In diesem Beitrag schauen wir uns zunächst einmal an, wie wir die Unterschiede zwischen den Schemata zweier Datenbanken ermitteln können. Dazu nutzen wir die SQL Server Data Tools, die wir in einem anderen Artikel bereits vorgestellt haben.
Unter dem Titel SQL Server Data Tools installieren und starten (www.access-im-unternehmen.de/1520) haben wir uns bereits angesehen, wie wir die SQL Server Data Tools installieren und starten können. Die SQL Server Data Tools sind ein Bestandteil von Visual Studio.
Die SQL Server Data Tools liefern unter anderem eine komfortable Möglichkeit zum Vergleichen von Datenbankschemata. Diese schauen wir uns auf den nächsten Seiten als Erstes an. Danach gehen wir noch einen Schritt weiter und untersuchen, ob und wie wir die Kenntnis dieser Unterschiede dafür nutzen können, eine der Datenbanken auf den Stand der anderen Datenbank zu bringen.
Datenbankschemata vergleichen
Warum sollte man überhaupt zwei Datenbankschemata vergleichen? Meist handelt es sich dabei um zwei Versionen einer Datenbank. Es kann sein, dass wir eine Version einer SQL Server-Datenbank entwickelt und beim Kunden oder auch bei uns selbst in den Produktivbetrieb übernommen haben. Nun entwickelt man solche Datenbanken normalerweise in einer Entwicklungsversion weiter, bis man den gewünschten Stand erreicht hat. Dann möchte man natürlich die Änderungen, die man in der Zwischenzeit durchgeführt hat, irgendwann auch auf die Produktivdatenbank übertragen. Hier gibt es zwei Wege:
- Wir legen die Entwicklungsdatenbank als neue Produktivdatenbank an und kopieren die Daten der alten Version der Produktivdatenbank in die neue Version.
- Oder wir übertragen die Änderungen, die am Datenbankschema durchgeführt wurden, in die aktuelle Version der Produktivdatenbank und bringen diese somit auf den aktuellen Entwicklungsstand.
In diesem Beitrag schauen wir uns die zuletzt genannte Variante an.
Es gibt auch noch weitere Gründe, sich die Unterschiede zwischen zwei Datenbankschemata anzuschauen. Es kann auch passieren, dass man versehentlich (oder auch absichtlich) an zwei verschiedenen Versionen unterschiedliche neue Elemente hinzufügt. Wenn man dies nicht sauber dokumentiert, kann man auch hier im Nachhinein den nachfolgend vorgestellten Schemavergleich nutzen, um die Unterschiede herauszufinden und die gewünschten Elemente bei einer der Datenbanken nachträglich hinzuzufügen.
Beispieldatenbanken
Um die nachfolgend vorgestellten Techniken zu testen, benötigen wir zwei Datenbanken, deren Schemata möglichst vielfältige Unterschiede aufweisen. Vielleicht finden Sie zu einer aktuellen SQL Server-Datenbank noch eine alte Sicherung, die Sie zu diesem Zweck einmal wiederherstellen können (unter anderem Namen, natürlich).
Diese beiden Datenbanken sollten von der gleichen Instanz der SQL Server Data Tools aus erreichbar sein, was aber in der Regel kein Problem sein sollte.
Schemavergleich á la SSDT
Dann können wir bereits beginnen und wie im oben genannten Beitrag beschrieben Visual Studio und den SQL Server-Objekt-Explorer starten. Hier wählen wir nun die erste Datenbank aus, deren Schema wir vergleichen wollen. Wir sollten hier direkt die ältere Datei wählen, denn später bekommen wir die Gelegenheit die Unterschiede aus der Sicht dieser Datenbank als Basis für eine Aktualisierung zu nutzen. Dann klicken wir mit der rechten Maustaste auf den Datenbanknamen. Im nun erscheinenden Kontextmenü finden wir den Eintrag Schemavergleich… vor, den wir nun betätigen (siehe Bild 1).
Bild 1: Starten eines Schemavergleichs
Es erscheint ein neuer Bereich, der oben zwei Auswahlfelder bereithält, mit denen wir die Quelldatenbank und die Zieldatenbank auswählen können. Die Auswahlliste für die Quelldatenbank wurde bereits mit der Datenbank gefüllt, für die wir den Kontextmenübefehl aufgerufen haben. Die Zieldatenbank wählen wir aus, indem wir die Liste ausklappen und wie in Bild 2 auf Ziel auswählen… klicken.
Bild 2: Auswählen von Quelle und Ziel des Schemavergleichs
Im Text im grauen Bereich können wir bereits lesen, dass wir hier nicht nur die Unterschiede zwischen den beiden Schemata ermitteln können. Wir haben anschließend die Möglichkeit, das Ziel zu aktualisieren und es so an die Quelldatenbank anzupassen – oder wir können ein SQL-Skript generieren, mit dem wir diese Schritte ausführen können.
Klicken wir auf den Befehl Ziel auswählen…, erscheint der Dialog aus Bild 3. Hier können wir auch ein Projekt auswählen. In diesem Fall liegen uns nur reine SQL Server-Datenbanken vor, also wählen wir die zweite Option Datenbank und klicken auf Verbindung auswählen…, was einen weiteren Dialog öffnet.
Bild 3: Auswahl der Zieldatenbank
Dieser heißt Verbinden und erlaubt es, einen lokalen SQL Server, einen Server aus dem Netzwerk oder einen Azure-Server auszuwählen. Nach der Auswahl des Servers können wir die übrigen Daten zur Authentifizierung eingeben (siehe Bild 4).
Bild 4: Eigenschaften der Zieldatenbank
Damit sind wir soweit, dass wir den Vergleich starten können. Das erledigen wir mit einem Klick auf die Schaltfläche Vergleichen. Danach erhalten wir nach wenigen Augenblicken (oder auch später, je nach der Größe der Datenbankschemata) ein Ergebnis wie das aus Bild 5.
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