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 starten 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 Diese 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. Bild 5: Ergebnis des Schemavergleichs Die Unterschiede sind in drei Kategorien unterteilt: L schen: Enth lt alle Elemente, die in der Zieldatenbank enthalten sind, aber nicht in der Quelldatenbank. ndern: Enth lt alle Elemente, die in beiden Datenbanken vorhanden sind, sich aber unterscheiden. Hinzuf gen: Enth lt alle Elemente, die in der Quelldatenbank enthalten sind, aber nicht in der Zieldatenbank. F r die Elemente, die unter die Kategorie ndern fallen, k nnen wir uns noch die Details anschauen. Damit finden zum Beispiel bei einer Tabelle heraus, ob neue Felder angelegt wurden et cetera. Um beispielsweise die Unterschiede bez glich der Felder einer Tabelle zu untersuchen, klicken wir f r die entsprechende Tabelle unter ndern auf das Gr er-Zeichen. Dadurch erscheinen einige Untereintr ge wie Column, DEFAULT-Einschr nkungen, Erweiterte Eigenschaften, Fremdschl ssel, Index oder Prim rschl ssel. Wir ffnen hier auch noch das Alement Columns und erhalten die bersicht der Unterschiede beiden Feldern aus Bild 6. Bild 6: Unterschiede bei einer Tabelle Sp testens hier erkennen wir, dass die beiden Datenbanken vermutlich nicht unterschiedliche Versionen der gleichen Datenbank sind, sondern unterschiedliche Datenbanken. Das tut aber hier nichts zur Sache, denn wir wollen ja genau solche Unterschiede ermitteln. Ziel aktualisieren Wir k nnen nun direkt alle gefundenen nderungen in die Zieldatenbank bernehmen. Dazu brauchen wir nur auf die Schaltfl che Aktualisieren zu klicken. Vielleicht wollen wir aber auch etwas differenzierter an die Aufgabe herangehen und zun chst einmal untersuchen, welche der Objekte wir berhaupt in die Zieldatenbank bernehmen wollen. Dazu finden wir neben jedem Element ein Kontrollk stchen vor, das standardm ig aktiviert ist. Das bedeutet, dass das jeweilige Element in die Zieldatenbank berf hrt wird. Wir k nnen die Auswahl ndern, indem wir die Haken bei Elementen entfernen, die nicht aktualisiert werden sollen. Spannend ist hier, dass das Tool darauf achtet, dass die Konsistenz des Schemas gew hrleistet bleibt. Das hei t, wie k nnen beispielsweise die Tabelle tblMitarbeiter nur bernehmen, wenn wir auch die Tabellen bernehmen, auf die wir von der Tabelle tblMitarbeiter aus per Fremdschl sselfeld verweisen. Wir k nnen aber auch nur einzelne Felder aus der Quelldatenbank in die Zieldatenbank bernehmen. Dazu nehmen wir alle Felder aus der Auswahl heraus, die wir nicht bernehmen m chten. Im Beispiel markieren wir nun nur die Tabelle tblPositionen und bet tigen die Schaltfl che Aktualisieren. Nach dem Best tigen einer Meldung, ob wir das Ziel wirklich aktualisieren wollen, startet der Vorgang, den wir im unteren Bereich unter Datentoolvorg nge beobachten k nnen (siehe Bild 7). Bild 7: Ergebnis der Aktualisierung Das Tool l dt uns nun ein, erneut auf Vergleichen zu klicken, um die nun bestehenden Unterschiede aufzuzeigen und zu pr fen, ob die gew nschten nderungen in die Zieldatenbank bertragen wurden. Die bertragenen nderungen verschwinden erwartungsgem aus der Liste. Skript f r die Aktualisierung erstellen Wir k nnen die nderungen auch erst sp ter ausf hren, indem wir erst einmal nur ein Skript erstellen lassen. Dieses enth lt alle Anweisungen, die dazu notwendig sind, die gew nschten nderungen in der Zieldatenbank auszuf hren. Das Skript erstellt man, indem man auf die Schaltfl che rechts von der Schaltfl che Aktualisieren klickt oder mit Umschalt + Alt + G. Das neu erstellte Skript wird zun chst einmal in einem Editorfenster in Visual Studio angezeigt. Wir wollen nun noch die Tabelle tblAbteilungen anpassen, der wir ein Feld namens test hinzugef gt haben. Damit legen wir nun ein SQL-Skript zum bertragen der nderungen an. Dieses kopieren wir einmal in eine neue Abfrage der Zieldatenbank im SQL Server Management Studio und f hren es dort aus. Dazu m ssen wir f r die Abfrage den SQLCMD-Modus aktivieren, was wir mit dem Men befehl Abfrage|SQLCMD-Modus erledigen. Zusammenfassung und Ausblick Mit dem SQL Server Data Tools k nnen wir komfortabel die Unterschiede zwischen zwei Datenbankschemata aufdecken und den aktuellen Stand der Quelldatenbank auf die Zieldatenbank bertragen. Wichtig ist dazu nur, dass uns entsprechende Versionen vorliegen um zum Beispiel zu pr fen, durch welche nderung ein fehlerhaftes Verhalten ausgel st werden k nnte, m ssen wir noch eine Sicherung der SQL Server-Datenbank von dem Zeitpunkt haben, als noch alles funktionierte. In weiteren Beitr gen werden wir dieses Thema vertiefen beispielsweise zum zu zeigen, wie wir das Skript zum automatischen Aktualisieren des Datenmodells beim Kunden nutzen k nnen. The post Schemata von SQL Server-Datenbanken vergleichen appeared first on Access im Unternehmen.
Die SQL Server Data Tools sind eine Erweiterung f r Visual Studio, mit denen wir interessante Aufgaben rund um die Verwaltung von SQL Server-Datenbanken erledigen k nnen, die teilweise nicht mit dem SQL Server Management Studio m glich sind. Dazu geh rt u
zum Artikel gehenIn diesem Beitrag stellen wir die Vor- und Nachteil bei Nutzung eines lokalen Servers für JTL gegenüber eine Cloud Server gegenüber. Die JTL-Wawi ist eine Warenwirtschaft, die für ihren Betrieb einen Microsoft Datenbank Server (MS-SQL-Server) benötigt. Di
zum Artikel gehenGrundlagen des Data Warehousing - Konzepte - Architektur Modellierung eines Data Warehouse - Analyse - Entwurf - Datenmodellierung Data Warehousing-Techniken im Microsoft SQL Server - Extract - Transform - Load (ETL) mit SQL Server Integration
zum Artikel gehenIBM Power10 Server-Familie IBM Power-Server August 2022 Mehr über IBM Power10 Server erfahren: PDF-Broschüre herunterladen: IBM Power10 Server-Familie Der Beitrag IBM Power10 Server-Familie erschien zuerst auf ACSG.
Im Blog teilen wir heute Erfahrungen aus unseren Cloud-Projekten: Was ändert sich, wenn wir Daten aus verschiedenen Datenbanken abfragen und diese in Azure vorliegen statt on premises? Der Beitrag Datenbankübergreifende Abfragen in Azure-SQL-Datenbanken e
zum Artikel gehen