Hintergrund
Eines Tages benötigte ich ein Backup der Produktionsdatenbank, um einen Bug zu reproduzieren.
Zu meinem Erstaunen stieß ich auf folgende Einschränkungen:
- Das Backup der Datenbank wurde auf der Version SQL Server 2016 erstellt und war nicht kompatibel mit meiner SQL Server 2014.
- Auf meinem Arbeitscomputer wurde als Betriebssystem verwendet Windows 7, deshalb konnte ich nicht auf SQL Server Version 2016
- Das unterstützte Produkt war Teil eines größeren Systems mit stark verknüpfter Legacy-Architektur und sprach auch mit anderen Produkten und Datenbanken, weshalb die Bereitstellung auf einem anderen Rechner sehr lange dauern könnte.
In Anbetracht des Vorangegangenen kam ich zu dem Schluss, dass es Zeit für kreative Lösungen war.
Wiederherstellung von Daten aus dem Backup
Ich entschied mich, eine virtuelle Maschine zu verwenden mit Windows 10 (man kann ein Test-Image für den Edge-Browser verwenden ). Auf der virtuellen Maschine wurde SQL Server 2016 installiert und die Anwendungsdatenbank wurde aus dem Backup wiederhergestellt ().
Zugriff auf SQL Server auf der virtuellen Maschine einrichten
Anschließend mussten einige Schritte unternommen werden, um den Zugriff auf SQL Server von außen zu ermöglichen:
- Für die Firewall eine Regel hinzufügen, um Anfragen an den Port zuzulassen. 1433.
- Es wäre besser, dass der Zugriff auf den Server nicht über Windows-Authentifizierung, sondern über SQL mit Anmeldedaten (Benutzername und Passwort) erfolgt (dies erleichtert die Zugriffssteuerung). In diesem Fall muss jedoch in den Eigenschaften des SQL Servers die Möglichkeit der SQL-Authentifizierung aktiviert werden.
- In den Benutzereinstellungen auf dem SQL Server unter dem Reiter User Mapping muss für die wiederhergestellte Datenbank die Benutzerrolle db_securityadmin.
Datenmigration
Die eigentliche Datenmigration besteht aus zwei Schritten:
- Migration des Datenmodells (Tabellen, Sichten, gespeicherte Prozeduren usw.)
- Migration der tatsächlichen Daten.
Migration des Datenmodells.
Wir führen die folgenden Schritte aus:
- Wählen Sie Tasks -> Skripte generieren für die zu migrierende Datenbank.
- Wählen Sie die Objekte aus, die migriert werden sollen, oder lassen Sie den Standardwert (in diesem Fall werden Skripte für alle Objekte der Datenbank erstellt).
- Geben Sie die Einstellungen zum Speichern des Skripts an. Es ist am besten, das Skript in einer einzigen Datei im Unicode-Format zu speichern. So müssen bei einem Fehler nicht alle Schritte erneut durchgeführt werden.
Nachdem das Skript gespeichert wurde, kann es auf dem ursprünglichen SQL Server (der alten Version) ausgeführt werden, um die benötigte Datenbank zu erstellen.
Achtung: Nach der Ausführung des Skripts sollten die Einstellungen der Datenbank aus dem Backup mit der vom Skript erstellten Datenbank verglichen werden. In meinem Fall fehlte im Skript die COLLATE-Einstellung, was zu einem Fehler beim Datentransfer führte und die Neuerstellung der Datenbank mit einem angepassten Skript erforderte.
Datenmigration
Vor dem Datentransfer sollten alle Einschränkungsprüfungen in der Datenbank deaktiviert werden:
EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'Der Datentransfer erfolgt mithilfe des Datenimportassistenten Tasks -> Import Data auf dem SQL Server, wo sich die vom Skript erstellte Datenbank befindet:
- Geben Sie die Verbindungseinstellungen zur Quelle an (SQL Server 2016 auf einer virtuellen Maschine). Ich verwendete Data Source SQL Server Native Client und die oben erwähnte SQL-Authentifizierung.
- Geben Sie die Verbindungseinstellungen zum Zielort an (SQL Server 2014 auf der Hostmaschine).
- Anschließend konfigurieren wir das Mapping. Es sollten alle ausgewählt werden nicht nur read-only Objekte (z. B. Ansichten sind nicht erforderlich). Als zusätzliche Optionen sollte "Die Einfügung in Identity-Spalten zulassen" ausgewählt werden , falls solche verwendet werden.wenn bei dem Versuch, mehrere Tabellen auszuwählen und ihnen eine Eigenschaft zuzuweisen.
Achtung: wenn Sie versuchen, mehrere Tabellen auszuwählen und ihnen eine Eigenschaft zuzuweisen , falls solche verwendet werden. Die Eigenschaft wurde bereits für mindestens eine der ausgewählten Tabellen festgelegt, im Dialog wird angezeigt, dass die Eigenschaft für alle ausgewählten Tabellen festgelegt wurde. Dies kann verwirrend sein und zu Übertragungsfehlern führen. - Wir starten die Übertragung.
- Wir stellen die Überprüfung der Einschränkungen wieder her:
EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'
Falls Fehler auftreten, überprüfen Sie die Einstellungen, löschen Sie die fehlerhaft erstellte Datenbank, erstellen Sie sie erneut aus dem Skript, nehmen Sie Anpassungen vor und wiederholen Sie die Datenübertragung.
Fazit
Diese Aufgabe tritt eher selten auf und entsteht nur aufgrund der oben genannten Einschränkungen. Am häufigsten besteht die Lösung darin, SQL Server zu aktualisieren oder eine Verbindung zu einem entfernten Server herzustellen, wenn die Architektur der Anwendung dies zulässt. Allerdings kann niemand vor Legacy-Code und schlechter Programmierung geschützt werden. Ich hoffe, Sie werden diese Anleitung nicht benötigen, und falls doch, wird sie Ihnen helfen, viel Zeit und Nerven zu sparen. Vielen Dank für Ihre Aufmerksamkeit!
Liste der verwendeten Quellen
Quelle: habr.com
