Migrieren von Daten von SQL Server 2005 nach 2016

Ich bin neu in der Verwaltung von SQL Server, aber ich bin mit der SQL-Sprache und der Erstellung von SSIS-Paketen vertraut.

Ich möchte Daten von SQL Server 2005 auf 2016 migrieren.

Meine Frage ist, ob ich mir Gedanken über die Systemdatenbanken und andere Objekte wie Indizes, gespeicherte Prozeduren, Ansicht, Sicherheit und Berechtigungen machen muss. Logins oder kann ich einfach Daten migrieren.

Welches wäre das empfohlene Verfahren in diesem Fall.

Max gab eine anständige Antwort, die ich positiv bewerten werde, sobald ich diese alternative Ansicht eingegeben habe.

Ich bin kein Fan von der Wiederherstellung von Systemdatenbanken, wenn ich eine Upgrade-Migration durchführe, und ich bevorzuge Migrationen gegenüber direkten Upgrades, wie ich in dieser ausführlichen Antwort auf eine andere Frage besprochen habe .

Grundsätzlich beginne ich gerne "neu", wenn ich eine Migration mache. Ich finde, dass das Spielen mit Migrationen und Upgrades von Systemdatenbanken durch Wiederherstellung manchmal zu Frustrationen bei den Wiederherstellungen führt und potenzielle Sünden übertragen kann.

Sie haben auch nach Indizes, gespeicherten Prozeduren und Ansichten gefragt. Diese Elemente auf Datenbankebene sollten sich alle in einer Benutzerdatenbank befinden. Wenn Sie also Datenbank X auf dem neuen Server wiederherstellen, sind auch alle Datenbankobjekte (Tabellen, Benutzer, Ansichten, Prozesse, Funktionen usw.) vorhanden.

In den Systemdatenbanken sind Jobs, Anmeldungen, Warnungen, Verbindungsserver, Verschlüsselungsschlüssel usw. vorhanden. Elemente auf Instanzebene.

Ich überprüfe diese gerne und migriere mit verschiedenen Skripten über das, was ich brauche - in letzter Zeit sind das die DBATools.Io- Powershell-Skripte. Ich mag es, ihr Skript zum Kopieren von SQL-Anmeldungen zu verwenden , da es die SQL-authentifizierten Benutzer so behandelt, dass ihre Kennwörter und Sicherheitskennungen gleich bleiben , damit die Datenbankbenutzer aus diesen Anmeldungen funktionieren. Sie haben auch einen vollständigen SQL Server-Migrationsbefehl , der ihre Unterbefehle ausführt, um die Elemente zu kopieren, über die ich normalerweise kopieren würde.

Ich glaube nicht, dass Max mit dieser Antwort falsch liegt, daher die Gegenstimme. Ich hatte einfach mehr Erfolg und mehr Glück und fühle mich wohler bei der Migration auf neue, anstatt zu versuchen, über Systemdatenbanken zwischen Versionen wiederherzustellen. Ich würde sagen, dass ich mich ehrlich gesagt nicht erinnern kann, wann ich das letzte Mal eine Versionsaktualisierungsmigration durchgeführt habe und dies nicht auf diese Weise getan habe, anstatt die Systemdatenbanken wiederherzustellen.

Sie sollten die Systemdatenbanken (Master, MSDB und möglicherweise Modell) migrieren, wenn Sie Zugriff auf die in diesen Datenbanken gespeicherten Metadaten benötigen.

Der Master speichert Elemente wie Anmeldungen, Sicherheitszertifikate usw.

msdb enthält Details zu Sicherungen und speichert unter anderem SQL Server Agent-Jobkonfigurationen.

Das Modell wurde möglicherweise von Ihnen oder Ihrem Team angepasst, damit neu erstellte leere Datenbanken eine Reihe vordefinierter Objekte enthalten können, die Sie in jeder Datenbank verwenden.

Die Migration von Systemdatenbanken kann relativ einfach durchgeführt werden. Detaillierte Anweisungen erhalten Sie von MSDN unter Sichern und Wiederherstellen von Systemdatenbanken (SQL Server) .

Abhängig von Ihren Anforderungen können Sie einen BACKUP DATABASEVorgang für die Benutzerdatenbanken auf der 2005-Instanz und dann RESTORE DATABASEauf der 2016-Instanz ausführen , um die gesamte Datenbank einschließlich aller Daten, Indizes und anderer Objekte abzurufen.

Dies erfordert zumindest anfänglich den gleichen Speicherplatz, den die Datenbank auf der 2005-Instanz belegt. Sobald Sie die Datenbank wiederhergestellt haben, können Sie die Datenkomprimierung nutzen, um den erforderlichen Platzbedarf erheblich zu verringern.

Siehe Informationen zum Arbeiten mit SQL Server - Backups , um Informationen über die Durchführung von Sicherungen und über Wiederherstellungsszenarien für Einzelheiten zu den Wiederherstellungen.

Ist es bis 2012 oder 2016? Es macht einen Unterschied, dass IIRC 2012 ein getesteter Migrationspfad ist, 2016 jedoch nicht. Daher werden bekannte Probleme dokumentiert und / oder von Upgrade Advisor für 2012 abgefangen. Ein nicht getesteter Pfad funktioniert möglicherweise weiterhin ohne Probleme. Er ist nur unbekannt. Ich empfehle Ihnen jedoch dringend, bis 2016 zu gehen. Ich vermute, dass die Anstrengungen fast gleich sein werden.

Siehe Aktualisieren Sie von SQL Server 2005? in der Dokumentation zu den Upgrade-Optionen für 2005 und Links zu einem sehr detaillierten Upgrade-Prozess. Der Upgrade-Prozess wurde für 2014 geschrieben, gilt jedoch weiterhin für 2016.