{"id":35306,"date":"2019-10-31T22:03:32","date_gmt":"2019-10-31T19:03:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/perenos-dannyh-bekapa-novoj-versii-ms-sql-server-na-bolee-staruyu-versiyu\/"},"modified":"2020-12-15T02:10:03","modified_gmt":"2020-12-15T00:10:03","slug":"perenos-dannyh-bekapa-novoj-versii-ms-sql-server-na-bolee-staruyu-versiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/perenos-dannyh-bekapa-novoj-versii-ms-sql-server-na-bolee-staruyu-versiyu","title":{"rendered":"\u00dcbertragung von Backupdateien einer neuen Version von MS SQL Server auf eine \u00e4ltere Version","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hintergrund<\/h2>\n

Eines Tages ben\u00f6tigte ich ein Backup der Produktionsdatenbank, um einen Bug zu reproduzieren.<\/p>\n

Zu meinem Erstaunen stie\u00df ich auf folgende Einschr\u00e4nkungen:<\/p>\n

    \n
  1. Das Backup der Datenbank wurde auf der Version SQL Server 2016<\/i> erstellt und war nicht kompatibel mit meiner SQL Server 2014<\/i>.<\/li>\n
  2. Auf meinem Arbeitscomputer wurde als Betriebssystem verwendet Windows 7<\/i>, deshalb konnte ich nicht auf SQL Server<\/i> Version 2016<\/li>\n
  3. Das unterst\u00fctzte Produkt war Teil eines gr\u00f6\u00dferen Systems mit stark verkn\u00fcpfter Legacy-Architektur und sprach auch mit anderen Produkten und Datenbanken, weshalb die Bereitstellung auf einem anderen Rechner sehr lange dauern k\u00f6nnte.<\/li>\n<\/ol>\n

    In Anbetracht des Vorangegangenen kam ich zu dem Schluss, dass es Zeit f\u00fcr kreative L\u00f6sungen war.<\/a><\/noindex><\/p>\n

    Wiederherstellung von Daten aus dem Backup<\/h2>\n

    Ich entschied mich, eine virtuelle Maschine zu verwenden Oracle VM VirtualBox<\/a><\/noindex> mit Windows 10 (man kann ein Test-Image f\u00fcr den Edge-Browser verwenden hier herunter<\/a><\/noindex>). Auf der virtuellen Maschine wurde SQL Server 2016 installiert und die Anwendungsdatenbank wurde aus dem Backup wiederhergestellt (finden Sie die Anleitung<\/a><\/noindex>).<\/p>\n

    Zugriff auf SQL Server auf der virtuellen Maschine einrichten<\/h2>\n

    Anschlie\u00dfend mussten einige Schritte unternommen werden, um den Zugriff auf SQL Server von au\u00dfen zu erm\u00f6glichen:<\/p>\n

      \n
    1. F\u00fcr die Firewall eine Regel hinzuf\u00fcgen, um Anfragen an den Port zuzulassen. 1433<\/i>.<\/li>\n
    2. Es w\u00e4re besser, dass der Zugriff auf den Server nicht \u00fcber Windows-Authentifizierung, sondern \u00fcber SQL mit Anmeldedaten (Benutzername und Passwort) erfolgt (dies erleichtert die Zugriffssteuerung). In diesem Fall muss jedoch in den Eigenschaften des SQL Servers die M\u00f6glichkeit der SQL-Authentifizierung aktiviert werden.<\/li>\n
    3. In den Benutzereinstellungen auf dem SQL Server unter dem Reiter User Mapping<\/i> muss f\u00fcr die wiederhergestellte Datenbank die Benutzerrolle db_securityadmin<\/i>.<\/li>\n<\/ol>\n

      Datenmigration<\/h2>\n

      Die eigentliche Datenmigration besteht aus zwei Schritten:<\/p>\n

        \n
      1. Migration des Datenmodells (Tabellen, Sichten, gespeicherte Prozeduren usw.)<\/li>\n
      2. Migration der tats\u00e4chlichen Daten.<\/li>\n<\/ol>\n

        Migration des Datenmodells.<\/h3>\n

        Wir f\u00fchren die folgenden Schritte aus:<\/p>\n

          \n
        1. W\u00e4hlen Sie Tasks -> Skripte generieren<\/i> f\u00fcr die zu migrierende Datenbank.<\/li>\n
        2. W\u00e4hlen Sie die Objekte aus, die migriert werden sollen, oder lassen Sie den Standardwert (in diesem Fall werden Skripte f\u00fcr alle Objekte der Datenbank erstellt).<\/li>\n
        3. 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\u00fcssen bei einem Fehler nicht alle Schritte erneut durchgef\u00fchrt werden.<\/li>\n<\/ol>\n

          Nachdem das Skript gespeichert wurde, kann es auf dem urspr\u00fcnglichen SQL Server (der alten Version) ausgef\u00fchrt werden, um die ben\u00f6tigte Datenbank zu erstellen.<\/p>\n

          Achtung:<\/b> Nach der Ausf\u00fchrung 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\u00fchrte und die Neu\u00aderstellung der Datenbank mit einem angepassten Skript erforderte.<\/p>\n

          Datenmigration<\/h3>\n

          Vor dem Datentransfer sollten alle Einschr\u00e4nkungspr\u00fcfungen in der Datenbank deaktiviert werden:<\/p>\n

          EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'<\/code><\/pre>\n
          Der Datentransfer erfolgt mithilfe des Datenimportassistenten Tasks -> Import Data<\/i> auf dem SQL Server, wo sich die vom Skript erstellte Datenbank befindet:<\/p>\n
            \n
          1. Geben Sie die Verbindungseinstellungen zur Quelle an (SQL Server 2016 auf einer virtuellen Maschine). Ich verwendete Data Source SQL Server Native Client<\/i> und die oben erw\u00e4hnte SQL-Authentifizierung.<\/li>\n
          2. Geben Sie die Verbindungseinstellungen zum Zielort an (SQL Server 2014 auf der Hostmaschine).<\/li>\n
          3. Anschlie\u00dfend konfigurieren wir das Mapping. Es sollten alle ausgew\u00e4hlt werden nicht nur read-only<\/b> Objekte (z. B. Ansichten sind nicht erforderlich). Als zus\u00e4tzliche Optionen sollte \"Die Einf\u00fcgung in Identity-Spalten zulassen\" ausgew\u00e4hlt werden , falls solche verwendet werden.<\/i>wenn bei dem Versuch, mehrere Tabellen auszuw\u00e4hlen und ihnen eine Eigenschaft zuzuweisen.
            \nAchtung:<\/b> wenn Sie versuchen, mehrere Tabellen auszuw\u00e4hlen und ihnen eine Eigenschaft zuzuweisen , falls solche verwendet werden.<\/i> Die Eigenschaft wurde bereits f\u00fcr mindestens eine der ausgew\u00e4hlten Tabellen festgelegt, im Dialog wird angezeigt, dass die Eigenschaft f\u00fcr alle ausgew\u00e4hlten Tabellen festgelegt wurde. Dies kann verwirrend sein und zu \u00dcbertragungsfehlern f\u00fchren.<\/li>\n
          4. Wir starten die \u00dcbertragung.<\/li>\n
          5. Wir stellen die \u00dcberpr\u00fcfung der Einschr\u00e4nkungen wieder her:\n
            EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'<\/code><\/pre>\n<\/li>\n<\/ol>\n
            Falls Fehler auftreten, \u00fcberpr\u00fcfen Sie die Einstellungen, l\u00f6schen Sie die fehlerhaft erstellte Datenbank, erstellen Sie sie erneut aus dem Skript, nehmen Sie Anpassungen vor und wiederholen Sie die Daten\u00fcbertragung.<\/p>\n
            Fazit<\/h2>\n
            Diese Aufgabe tritt eher selten auf und entsteht nur aufgrund der oben genannten Einschr\u00e4nkungen. Am h\u00e4ufigsten besteht die L\u00f6sung darin, SQL Server zu aktualisieren oder eine Verbindung zu einem entfernten Server herzustellen, wenn die Architektur der Anwendung dies zul\u00e4sst. Allerdings kann niemand vor Legacy-Code und schlechter Programmierung gesch\u00fctzt werden. Ich hoffe, Sie werden diese Anleitung nicht ben\u00f6tigen, und falls doch, wird sie Ihnen helfen, viel Zeit und Nerven zu sparen. Vielen Dank f\u00fcr Ihre Aufmerksamkeit!<\/p>\n
            Liste der verwendeten Quellen<\/h2>\n