Die Nutzung von SSDT zum Testen der Migration von SQL Anywhere auf MSSQL

Was ist SQL Server Data Tools und warum ist es hilfreich bei der Migration?

SSDT (SQL Server Data Tools) in Visual Studio ist ein leistungsstarkes Werkzeug für die Entwicklung und Verwaltung von Datenbanken, insbesondere in Microsoft SQL Server. Es ermöglicht die Modellierung, Entwicklung und das Testen von Datenbanken direkt innerhalb der gewohnten Entwicklungsumgebung. Für Datenbanktests ist SSDT besonders geeignet, da es die Erstellung von Unit Tests für Stored Procedures, Funktionen und Datenbanklogik unterstützt, wodurch die Qualität und Stabilität des Codes sichergestellt werden kann. Bei einer Migration von SQL Anywhere zu MSSQL ist SSDT äußerst nützlich, da es hilft, den migrierten Code zu validieren und sicherzustellen, dass die Funktionalität korrekt übertragen wurde. Zusätzlich ermöglicht es die Verwaltung des Datenbankschemas in einem Versionskontrollsystem, welches bei komplexen Migrationsprojekten Transparenz und Nachvollziehbarkeit bietet.

Einrichtung des Repositories für SSDT

Voraussetzung

Um SSDT nutzen zu können, muss es in Visual Studio installiert sein. Dafür muss der Installer geöffnet und geprüft werden, ob unter „Andere Toolsets“ die Erweiterung „Datenspeicherung und -verarbeitung“ installiert ist. Falls nicht, bitte installieren.

Basis-Projekt anlegen

  1. Unter Los geht’s auf der rechten Seite Neues Projekt erstellen wählen.
  2. Vorlage SQL Server-Datenbankprojekt auswählen. Als Unterstützung kann mithilfe des oberen Eingabefelds danach gesucht werden.
  3. Im Feld Projektname einen Namen Ihrer Wahl eingeben.
  4. Das Kontrollkästchen unter dem letzten Eingabefeld aktivieren, falls es noch nicht aktiviert ist.

Datenbankschema importieren

Möchte man das Datenbankschema einer vorhandenen Datenbank für SSDT importieren, kann dies mit den folgenden Schritten durchgeführt werden:

  1. Im Menü Projekt das Feld Importieren auswählen und dann auf Skript (*.sql) klicken.
  2. Klicken Sie auf Weiter, nachdem Sie die Informationen auf der Willkommensseite gelesen haben.
  3. Klicken Sie auf Durchsuchen, und wechseln Sie zu dem Verzeichnis, in dem Sie die SQL-Datei gespeichert haben.
  4. Doppelklicken Sie auf die SQL-Datei, und klicken Sie auf Fertig stellen.
  5. Das Skript wird importiert, und die im Skript definierten Objekte werden dem Datenbankprojekt hinzugefügt.
  6. Überprüfen Sie die Zusammenfassung, und klicken Sie dann auf Fertig stellen , um den Vorgang abzuschließen.

Projekt für Komponententests hinzufügen

Um SQL-Server Komponententests hinzufügen zu können, braucht man ein weiteres Projekt in der Projektmappe, das vom Typ Klassenbibliothek ist.

  1. Rechtsklick auf die Projektmappe, dann auf Hinzufügen und anschließend Projekt.
  2. Klassenbibliothek auswählen und benennen.

Komponententest hinzufügen

  1. Rechtsklick auf das neu hinzugefügte Projekt vom Typ „Klassenbibliothek“ und wieder auf Hinzufügen und Neues Element.
  2. In der Suche nach SQL-Server Komponententest suchen, auswählen und benennen.

Komponententests aus importierten Prozeduren erstellen

Hat man Prozeduren über ein Skript importiert, kann man über den SQL Server-Objekt-Explorer Komponententests für diese Prozeduren erstellen lassen. Ist der Explorer noch nicht links angeheftet, kann man ihn über den Reiter Ansicht oder die Tastenkombination Strg+^, Strg+S öffnen. Außerdem ist es ratsam, das Projekt mit der lokalen Datenbank zu verbinden. Dies wird konfiguriert, indem man Rechtsklick auf das Projekt mit den importierten Skripts ausführt, auf die Eigenschaften klickt und dann unter dem Reiter Debuggen die Zielverbindungszeichenfolge bearbeitet. Dort kann die Datenbank ausgewählt werden, wenn sie vorgeschlagen wird, oder man gibt die Informationen manuell ein. Mit Rechtsklick auf eine der Prozeduren und der Auswahl von Komponententests erstellen…, öffnet sich ein Menü, in dem für alle Prozeduren die Tests automatisch generiert werden können.

Öffnet man dieses neu hinzugefügten Test, öffnet sich die SSDT-Ansicht, zum Erstellen und Ausführen von Tests.

Nutzung von Git zur Versionskontrolle in SSDT

Die Integration von Git in SQL Server Data Tools (SSDT) ermöglicht es, Datenbankprojekte effizient zu verwalten, Änderungen nachzuverfolgen und gemeinsam an Projekten zu arbeiten. Git bietet die Möglichkeit, den Quellcode der Datenbank, wie zum Beispiel Tabellen, Stored Procedures und Views, zu versionieren und Änderungen transparent nachzuvollziehen. Dies ist besonders hilfreich, um Änderungen in der Datenbankstruktur zu dokumentieren und konsistente Deployments sicherzustellen.

Vorteile der Nutzung von Git in SSDT

  1. Versionierung des Datenbankschemas:
    • Jede Änderung an der Datenbank (z. B. Hinzufügen von Spalten, Ändern von Indizes) wird als Commit gespeichert und ist nachvollziehbar.
    • Frühere Versionen des Schemas können leicht wiederhergestellt werden.
  2. Nachvollziehbarkeit von Änderungen:
    • Mit Git können Entwickler sehen, wer wann welche Änderungen vorgenommen hat.
    • Der Einsatz von Branches ermöglicht es, parallel an neuen Features zu arbeiten, ohne die Stabilität des Hauptschemas zu gefährden.
  3. Teamarbeit und Zusammenarbeit:
    • Git unterstützt die Zusammenarbeit mehrerer Entwickler, indem es Konflikte bei Änderungen erkennt und die Integration von Änderungen über Pull Requests erleichtert.
  4. Sicherheit und Rückverfolgbarkeit:
    • Änderungen können durch Rollbacks rückgängig gemacht werden, falls Probleme auftreten.
    • Historie und Diffs bieten Einblicke in jede Änderung an der Datenbankstruktur.
  5. Automatisierte Deployments:
    • In Verbindung mit Continuous Integration/Continuous Deployment (CI/CD)-Pipelines können Änderungen aus dem Git-Repository automatisch in Test- oder Produktionsumgebungen deployt werden.

Einrichtung von Git für ein SSDT-Projekt

  1. Git-Repository erstellen:
    • Erstelle ein neues Git-Repository auf einer Plattform wie GitHub, GitLab oder Azure DevOps.
    • Falls lokal, initialisiere ein Repository mit git init im Projektverzeichnis.
  2. SSDT-Projekt erstellen:
    • In Visual Studio ein neues SQL Server-Projekt anlegen.
    • Alle Datenbankobjekte (Tabellen, Stored Procedures, Views etc.) in das Projekt hinzufügen.
  3. Git in Visual Studio aktivieren:
    • Öffne das SSDT-Projekt in Visual Studio.
    • Gehe zu Tools > Options > Source Control und wähle Git als Quellcodeverwaltungs-Plugin.
  4. Projekt zu Git hinzufügen:
    • Öffne die Git Changes-Ansicht in Visual Studio (Ansicht > Git-Änderungen).
    • Klicke auf Add to Source Control, um das Projekt dem Git-Repository hinzuzufügen.
    • Führe den ersten Commit aus, um die aktuelle Version des Datenbankschemas zu speichern.
  5. Branching und Zusammenarbeit:
    • Erstelle Branches für neue Features oder Hotfixes (git checkout -b feature/xyz).
    • Nutze Pull Requests (z. B. in GitHub oder Azure DevOps), um Änderungen in den Hauptbranch zu integrieren.
  6. Konflikte lösen:
    • Falls mehrere Entwickler gleichzeitig Änderungen vornehmen, unterstützt Git das Auflösen von Konflikten direkt in Visual Studio.

Best Practices

  • Commit-Frequenz: Regelmäßig committen, um kleine, überschaubare Änderungen zu speichern.
  • Aussagekräftige Commit-Messages: Beschreibe Änderungen klar und prägnant, z. B. „Added new column to Customers table for email addresses.“
  • Branches für Features: Nutze separate Branches für verschiedene Features, um paralleles Arbeiten zu ermöglichen.
  • Code-Reviews: Führe regelmäßige Reviews durch, bevor Änderungen in den Hauptbranch integriert werden.
  • CI/CD-Integration: Verknüpfe das Repository mit einem CI/CD-Tool (z. B. Azure DevOps), um das Deployment zu automatisieren.

Die Nutzung von Git in SSDT vereinfacht nicht nur die Zusammenarbeit im Team, sondern verbessert auch die Qualität der Datenbankentwicklung, da jede Änderung kontrolliert und rückverfolgbar ist. In Kombination mit Visual Studio wird die Versionskontrolle nahtlos in den Entwicklungsprozess integriert und unterstützt moderne, agile Arbeitsmethoden.

Wie Git bei der Migration von SQL Anywhere zu MSSQL unterstützt

Die Nutzung von Git bietet während der Migration von SQL Anywhere zu MSSQL mehrere Vorteile:

  1. Versionierung während der Migration:
    • Alle Änderungen, die während der Migration an der Datenbankstruktur vorgenommen werden, können als Commits dokumentiert werden. Dadurch wird der Fortschritt der Migration nachvollziehbar.
  2. Schrittweise Anpassung und Tests:
    • Migrationen können iterativ durchgeführt werden. Jede Phase (z. B. Schemaübertragung, Anpassung von Stored Procedures) kann in separaten Branches erfolgen, wodurch paralleles Arbeiten und sauberes Testen ermöglicht wird.
  3. Vergleich von Änderungen:
    • Git ermöglicht es, die Unterschiede zwischen dem ursprünglichen SQL Anywhere-Schema und dem angepassten MSSQL-Schema zu analysieren. Dies hilft, sicherzustellen, dass keine wichtigen Elemente übersehen werden.
  4. Rollback-Funktionalität:
    • Falls bestimmte Änderungen in der Migration fehlschlagen, erlaubt Git ein einfaches Zurückrollen zu einer vorherigen stabilen Version.
  5. Zusammenarbeit im Team:
    • Wenn mehrere Entwickler an der Migration beteiligt sind, unterstützt Git die Zusammenarbeit durch Branches, Pull Requests und Merge-Mechanismen. Konflikte können sauber behoben werden.
  6. Dokumentation der Migration:
    • Mit gut dokumentierten Commit-Messages und einer klaren Branching-Strategie entsteht eine lückenlose Historie der Migrationsschritte, die später nachvollzogen werden kann.

Git macht den Migrationsprozess sicherer und strukturierter und ermöglicht es, Änderungen transparent zu dokumentieren und schrittweise umzusetzen. Dies minimiert das Risiko von Fehlern und stellt sicher, dass die Migration effizient und nachvollziehbar durchgeführt wird. Aber auch wenn Git einen stark dabei unterstützt, Änderungen an einer Datenbank mit anderen zu synchronisieren, müssen diese Änderungen noch auf den Datenbankserver übertragen werden. Dies funktioniert nur mithilfe von Software wie dem SSMS, mit dem man einen Schemaabgleich oder das aktualisieren mithilfe einer Bacpac-Datei durchführt.

Testen der Migration von SQL Anywhere auf Microsoft SQL

Testen von Tabellen & Views

SSDT bietet keine automatische Erstellung für Komponententests von Tabellen und Views. Diese können also nur indirekt darüber getestet werden, indem man z.B. Prozeduren schreibt, die ein Select Count(*) auf die gleiche Tabelle bei MSSQL und bei ASA ausführt und dann beide Werte vergleicht.

In MSSQL gibt es die Möglichkeit, innerhalb eines Scripts eine Anfrage an eine MSSQL Datenbank und auch an eine per OLE DB erreichbare Datenbank (z.B. SQL Anywhere) zu schicken, um beispielsweise zwei Tabellen miteinander zu vergleichen. In unserem Fall hilft das sehr, um eine Tabelle auf Änderungen durch Fehler während der Migration zu prüfen. Bevor man das Script ausführt, muss man sicherstellen, dass der SQL Anywhere OLE DB-Provider installiert ist. Außerdem müssen wir den sogenannten „Linked Server“ einrichten, um über Openquery den SQL Anywhere Server direkt ansprechen zu können. Dies kann entweder über das UI eingestellt werden, indem man unter Server Objects>Linked Servers und dann über Rechtsklick>New Linked Server einen neuen Server erstellt und konfiguriert, oder über folgendes Skript:

EXEC master.dbo.sp_addlinkedserver 
    @server = N'DEMO_LINKED', 
    @srvproduct=N'SQL Anywhere', 
    @provider=N'SAOLEDB.17', 
    @location=N'localhost', 
    @provstr=N'Server=DEMO;UID=dba;PWD=sql', 
    @catalog=N'demo'

EXEC master.dbo.sp_addlinkedsrvlogin
    @rmtsrvname=N'DEMO_LINKED',
    @useself=N'False',
    @locallogin=NULL,
    @rmtuser=NULL,
    @rmtpassword=NULL

EXEC sp_serveroption
    @server = N'DEMO_LINKED',
    @optname = N'data access',
    @optvalue = N'true';

EXEC sp_serveroption
    @server = N'DEMO_LINKED',
    @optname = N'use remote collation',
    @optvalue = N'true';

EXEC sp_serveroption
    @server = N'DEMO_LINKED',
    @optname = N'remote proc transaction promotion',
    @optvalue = N'true';

Wir haben einmal mit der Demo-Datenbank, die einer SQL Anywhere 17 Installation beiliegt, eine Migration durchgeführt und testen den Erfolg der Migration einer Tabelle, indem wir die Anzahl der Zeilen vergleichen, mit folgendem Script:

SELECT  Count(*)
FROM demo.GROUPO.Customers

SELECT *
FROM OPENQUERY(demo_LINKED, 'Select Count(*) From GROUPO.Customers')

Man kann sich entweder beide Zahlen direkt anschauen oder mithilfe von Selektion sich direkt ausgeben lassen, ob sie gleich sind.

Ein anderer Weg wäre, sich die Tabelle als JSON ausgeben zu lassen und den String dann zu vergleichen. Wichtig dabei ist, dass in beiden Anfragen ein Order By verwendet wird, da die Reihenfolge sonst unterschiedlich sein kann und dann der JSON-Vergleich fehlschlägt, auch wenn die Daten in beiden Tabellen identisch sind. Das funktioniert mit folgendem Code:

DECLARE @JsonMssql NVARCHAR(MAX);
DECLARE @JsonAnywhere NVARCHAR(MAX);

SELECT @JsonMssql = (
    SELECT *
    FROM demo.GROUPO.Customers
    ORDER BY CustomerId
    FOR JSON AUTO
);

SELECT @JsonAnywhere = (
    SELECT *
    FROM OPENQUERY(demo_LINKED, 'Select * From GROUPO.Customers ORDER BY CustomerId') AS Help
    FOR JSON AUTO
);

IF @JsonMssql = @JsonAnywhere
BEGIN
    PRINT 'Die JSON-Daten sind identisch.';
END
ELSE
BEGIN
    PRINT 'Die JSON-Daten unterscheiden sich.';
    
    SELECT 
        'Unterschiede im JSON' AS Result,
        @JsonMssql AS JSON_Aus_DB1,
        @JsonAnywhere AS JSON_Aus_DB2;
END;

Da es jedoch viel Zeit kostet, diese Tests manuell nacheinander auszuführen, ist es sinnvoller, die Tests im SSDT zu konfigurieren. Dies erfordert anfangs mehr Aufwand, lohnt sich mit wachsener Anzahl zu vergleichender Tabellen/Views immer mehr. Ich gehe anhand eines einfachen Beispiels einmal darauf ein, wie man einen Test erstellt.

In Visual Studio sollten (links) am besten die Fenster Test-Explorer (Strg + E, T) und SQL Server-Objekt-Explorer (Strg + ^, Strg + S) geöffnet sein. Auf der rechten Seite sollte der Projektmappen-Explorer (Strg + Alt + L) offen sein.

Als Voraussetzung sollte sollte überprüft werden, ob das Testprojekt mit dem richtigen Server verbunden ist, auf dem man mit dem Linked Server verbunden ist. Im Projektmappen-Explorer findet man die Datei app.config. Darin findet man unter SqlUnitTesting den Key ConnectionString, sowohl in der Property ExecutionContext als auch in der Property PrivilegedContext. Diesen ConnectionString sollte daraufhin geprüft werden, ob er mit dem richtigen Server verbunden ist, nämlich dem MSSQL Server, zu dem von der SQL Anywhere migriert wurde.

In der Mitte sollte das Fenster für den Code eines Tests offen sein. Wir wechseln zu SqlServerUnitTest1.cs, um den SQL-Code zum Prüfen der Migration hier zu verfassen. Folgender Code kann dann eingefügt werden:

CREATE TABLE #TempResult (ResultColumn INT);

INSERT INTO #TempResult
SELECT *
FROM OPENQUERY(DEMO_LINKED, 'Select Count(*) From GROUPO.Contacts')

DECLARE @CountTableAnyWhere INT;
SELECT @CountTableAnyWhere = ResultColumn FROM #TempResult;

DECLARE @CountTableMSSQL INT;
SELECT @CountTableMSSQL = Count(*) FROM Demo.dbo.Contacts

IF @CountTableAnyWhere != @CountTableMSSQL
BEGIN
    SELECT 0 AS ExpectedResult;
END
ELSE
BEGIN
    SELECT 1 AS ExpectedResult;
END

Es gibt mehrere Ansätze, um die beiden Zeilenanzahlen zu vergleichen. Ich habe mich dafür entschieden, das Ergebnis der Openquery in einer Temptable zu speichern und später wieder auszulesen. Anschließend erstellen wir eine Testbedingung, indem wir mit dem roten X die aktuelle Löschen und mit dem grünen Plus eine neue erstellen. Wir wählen die vorerstellte Testbedingung Skalarwert. Nun stellen wir rechts unten im Fenster Eigenschaften bei Erwarteter Wert die Zahl 1 ein. Durch das Select 1 AS ExpectedResult, nimmt SSDT diesen Wert für die Testbedingung, die wir nun konfiguriert haben. Stimmt die Zeilenanzahl beider Tabellen überein, ist das ExpectedResult 1, sonst 0.

Den Test können wir nun oben links ausführen, indem wir ihn einzeln auswählen und anschließend auf das einzelne Play-Symbol klicken.

Testen von Funktionen

Funktionen werden beispielsweise von Prozeduren aufgerufen. Hier ist es wichtig, diese Funktionen einzeln zu testen, bevor man die aufrufende Prozedur testet, da in dem Fall, dass der Test der Prozedur aufgrund eines Fehlers in der Funktion fehlschlägt, die Rückmeldung vom Fehler oftmals nicht auf die fehlerhafte Funktion verweist.

Testen von Prozeduren

Das Testen von Prozeduren kann sich als komplex gestalten. Da diese sich gegenseitig aufrufen können, muss man eine Reihenfolge herausfinden, in der sie migriert werden können, ohne dass fehlende Referenzierungen entstehen. Unser Tool dbmAIgrate stellt Lösungen für diese Funktionalität bereit, indem es eine Liste an Cross-Referenzierungen bereitstellt, die die funktionierende Reihenfolge der Migration bereitstellt.

Das Testen der Migration einer Prozedur kann je nach Funktion der Prozedur, ähnlich zum Test einer Tabelle sein. Ich habe mit dem folgenden Skript eine Prozedur erstellt, die den PostalCode eines Kontakts anpasst.

CREATE PROCEDURE [dbo].[ChangePostalCode]
    @ContactId INT, 
    @PostalCode INT
AS
BEGIN
  IF EXISTS (SELECT 1 FROM dbo.Contacts WHERE Id = @ContactId)
  BEGIN
      UPDATE dbo.Contacts SET PostalCode = @PostalCode WHERE Id = @ContactId;
  END

END
RETURN 0

Als nächstes schreiben wir den Test, mit dem diese Änderung getestet werden soll. Dafür nehmen wir als Testbedingung wieder Skalarwert. Als Skript für den Test nehmen wir das folgende:

declare @NewPostalCode	INT = 10000;
declare @ContactId		INT = 5;

Exec Demo.dbo.ChangePostalCode @ContactId, @NewPostalCode;

Select PostalCode as ExpectedResult from dbo.Contacts where Id = @ContactId

Anschließend müssen wir wieder unten rechts, wie im Abschnitt zum Testen der Migration von Tabellen beschrieben, bei Erwarteter Wert den Wert eintragen, der von uns für @NewPostalCode festgelegt wird, also in diesem Beispiel 10000. Je nach Inhalt der Prozedur muss die Testbedingung abgeändert werden, aber so ist das grundlegende Vorgehen im SSDT.

Wie ich weiter oben erläutert habe, gibt es die Möglichkeit in SSDT, Komponententests für Prozeduren automatisch generieren zu lassen. Trotzdem sollte man diese Tests noch einmal überprüfen, aber es kann einem Zeit und Stress sparen.

Fazit

Die Nutzung von SSDT in Visual Studio erleichtert die Migration von SQL Anywhere zu MSSQL durch die Validierung des migrierten Codes sowie die Möglichkeit, Datenbanktests automatisiert durchzuführen. Zudem ermöglicht die Integration von Git eine transparente Versionskontrolle und vereinfacht die Zusammenarbeit im Team. Durch systematische Tests von Tabellen, Views, Funktionen und Prozeduren lässt sich die Migration effizient und fehlerfrei umsetzen.