11
Migration SQL-Server 2008 R2 auf 2019
Hallo zusammen,
wir haben leider noch einen alten SQL-Server 2008 R2 im Einsatz und möchten nun auf SQL-Server 2019 migrieren.
Die Zugriffe und Schnittstellen zu dieser Datenbank wurden Jahr für Jahr immer mehr.
Dementsprechend wurde die Migration dieser Datenbank bisschen Stiefmütterlich behandelt.
Ich habe jetzt die gute Aufgabe die Migration durchzuführen. Da ich bisher noch nicht so viel Erfahrung mit SQL-Server Migrationen habe, würde ich mich sehr freuen hier ein wenig Input zu bekommen.
Mein Problem bei dem Thema sind vor allem die Verbindungen zu anderen System / Datenbanken.
Es werden einige Abfrage direkt auf die Datenbank gemacht und auf dem System gibt es einen Verbindungsserver zu einer anderen Datenbank und insgesamt drei weitere Systeme greifen auch als Verbindungsserver auf die Datenbank zu.
Da dies schon ein großer Ratenschwanz ist, was da hinter hängt, möchte ich versuchen die Migration so einfach wie möglich zu gestalten. Wie würdet ihr an dieser Sache rangehen?
Mein grober Plan wäre tatsächlich bei der Migration einen Alias zu vergeben, damit die Abfragen auf den alten SQL an den neuen gehen. Problem sehe ich nur an den ganzen Verbindungen.
Über Ideen und Vorschläge würde ich mich sehr freuen.
Vielen Dank und viele Grüße
wir haben leider noch einen alten SQL-Server 2008 R2 im Einsatz und möchten nun auf SQL-Server 2019 migrieren.
Die Zugriffe und Schnittstellen zu dieser Datenbank wurden Jahr für Jahr immer mehr.
Dementsprechend wurde die Migration dieser Datenbank bisschen Stiefmütterlich behandelt.
Ich habe jetzt die gute Aufgabe die Migration durchzuführen. Da ich bisher noch nicht so viel Erfahrung mit SQL-Server Migrationen habe, würde ich mich sehr freuen hier ein wenig Input zu bekommen.
Mein Problem bei dem Thema sind vor allem die Verbindungen zu anderen System / Datenbanken.
Es werden einige Abfrage direkt auf die Datenbank gemacht und auf dem System gibt es einen Verbindungsserver zu einer anderen Datenbank und insgesamt drei weitere Systeme greifen auch als Verbindungsserver auf die Datenbank zu.
Da dies schon ein großer Ratenschwanz ist, was da hinter hängt, möchte ich versuchen die Migration so einfach wie möglich zu gestalten. Wie würdet ihr an dieser Sache rangehen?
Mein grober Plan wäre tatsächlich bei der Migration einen Alias zu vergeben, damit die Abfragen auf den alten SQL an den neuen gehen. Problem sehe ich nur an den ganzen Verbindungen.
Über Ideen und Vorschläge würde ich mich sehr freuen.
Vielen Dank und viele Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6905691471
Url: https://administrator.de/contentid/6905691471
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
11 Kommentare
Neuester Kommentar
Hi,
also meines Wissens geht kein direktes Upgrade auf 2019. Lass mich aber gerne eines bessere belehren
Die Aktualisierung von älteren SQL-Server-Datenbanken kann über eine Datensicherung erfolgen.
Sicherungen von Datenbanken aus SQL Server 2008/2008 R2 lassen sich in SQL Server 2019 wiederherstellen.
Beginne einfach mit einem neuen Windows Server 2019/ 2022-Image, und installiere SQL Server 2019.
Führe dann eine Sicherung/Wiederherstellung aller Ihrer Benutzerdatenbanken von dem "alten"
SQL Server 2008 R2 auf dem neuen Rechner durch.
Aber vorab überlegen, ob die Kompatibilitätsebene und andere datenbankbezogene Einstellungen aktualisieren werden müssen/ funktionieren werden.
Anbei ein Link von MS-Docs (SQL Server Migration Assistant)
https://learn.microsoft.com/de-de/sql/ssma/sql-server-migration-assistan ...
Grüße
also meines Wissens geht kein direktes Upgrade auf 2019. Lass mich aber gerne eines bessere belehren
Die Aktualisierung von älteren SQL-Server-Datenbanken kann über eine Datensicherung erfolgen.
Sicherungen von Datenbanken aus SQL Server 2008/2008 R2 lassen sich in SQL Server 2019 wiederherstellen.
Beginne einfach mit einem neuen Windows Server 2019/ 2022-Image, und installiere SQL Server 2019.
Führe dann eine Sicherung/Wiederherstellung aller Ihrer Benutzerdatenbanken von dem "alten"
SQL Server 2008 R2 auf dem neuen Rechner durch.
Aber vorab überlegen, ob die Kompatibilitätsebene und andere datenbankbezogene Einstellungen aktualisieren werden müssen/ funktionieren werden.
Anbei ein Link von MS-Docs (SQL Server Migration Assistant)
https://learn.microsoft.com/de-de/sql/ssma/sql-server-migration-assistan ...
Grüße
1
Hallo.
nimm den MS Data Migration Assistant. Der regelt auch die Zwischenschritte von bspw. 2005 zu 2019.
Bereits mehrfach darüber eine Migration gefahren und für echt gut befunden (selbst die SQL User samt PW werden übernommen).
Sollte was nicht passen, meldet das Tool, was ihm nicht gefällt.
Soße:
MfG
nimm den MS Data Migration Assistant. Der regelt auch die Zwischenschritte von bspw. 2005 zu 2019.
Bereits mehrfach darüber eine Migration gefahren und für echt gut befunden (selbst die SQL User samt PW werden übernommen).
Sollte was nicht passen, meldet das Tool, was ihm nicht gefällt.
Soße:
Data Migration Assistant (DMA) enables you to upgrade to a modern data platform by detecting compatibility issues > that can impact database functionality on your new version of SQL Server. It recommends performance and reliability > improvements for your target environment. It allows you to not only move your schema and data, but also > uncontained objects from your source server to your target server
MfG
1Zitat von @6376382705:
Hallo.
nimm den MS Data Migration Assistant. Der regelt auch die Zwischenschritte von bspw. 2012r2 zu 2019.
Hallo.
nimm den MS Data Migration Assistant. Der regelt auch die Zwischenschritte von bspw. 2012r2 zu 2019.
Er hat geschrieben, dass er SQL-Server 2008 R2 verwendet.
Microsoft empfiehlt:
- restore der Datenbank auf neuem Server
- Kontrolle der Systemeinstellungen (Collation, Tuning Einstellungen, Kompatibilitätslevel etc)
- ACHTUNG! Es gibt auch Kompatibilitätsbrüche, z.B. zum Native Client 11 - muß aktualisiert werden sonst connectet sich der Client nicht mehr falls über Native Client 11
- Kopie der Datenbank in eine neue leere DB mit dem Datenimport-Assistenten vom SQL Server Management Studio
- Indizes etnweder über die Applikation erstellen lassen, alternativ in der Quell-DB mit dem Tool aus dem Management Studio "Skripte erstellen - Datenbankobjketen" rausschreiben, Indizes damit dann in der neuen DB erstellen lassen
- finaler Test...
- auf allen Clients den neuen Server und die neue Datenbank konfigurieren
- restore der Datenbank auf neuem Server
- Kontrolle der Systemeinstellungen (Collation, Tuning Einstellungen, Kompatibilitätslevel etc)
- ACHTUNG! Es gibt auch Kompatibilitätsbrüche, z.B. zum Native Client 11 - muß aktualisiert werden sonst connectet sich der Client nicht mehr falls über Native Client 11
- Kopie der Datenbank in eine neue leere DB mit dem Datenimport-Assistenten vom SQL Server Management Studio
- Indizes etnweder über die Applikation erstellen lassen, alternativ in der Quell-DB mit dem Tool aus dem Management Studio "Skripte erstellen - Datenbankobjketen" rausschreiben, Indizes damit dann in der neuen DB erstellen lassen
- finaler Test...
- auf allen Clients den neuen Server und die neue Datenbank konfigurieren
Er hat geschrieben, dass er SQL-Server 2008 R2 verwendet.
würde es trotzdem auf einen Versuch ankommen lassen, da das Tool auch unter Win7 (falls Du wegen des alten OS fragst) funktioniert. Selbstverständlich in der gebackuppten Umgebung.Supported source and target versions
Source:
SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, > SQL Server 2017, SQL Server 2019, SQL Server 2022 and, Amazon RDS for SQL Server
Target:
SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017, SQL Server 2019, SQL Server 2022, > Azure SQL Database, Azure SQL Database Managed Instance
SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, > SQL Server 2017, SQL Server 2019, SQL Server 2022 and, Amazon RDS for SQL Server
Target:
SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017, SQL Server 2019, SQL Server 2022, > Azure SQL Database, Azure SQL Database Managed Instance
Ich gehe davon aus, dass das problemlos läuft und migriert.
Moin,
jepp, sehe ich auch so. Der DMA sollte da dein erster Anlaufpunkt sein.
Neuen Windows Server aufsetzen, SQL Installieren, und erste DB umziehen.
In der Applikation den neuen SQL angeben und testen. Wenns nicht geht, einfach wieder Schritt zurück und Fehlersuche betreiben.
Habe ein ähnliches Projekt vor 2 Wochen ferstiggestellt. Win2012 mit SQL 2014 und ca 60 kleinen DBs auf Win2022 und SQL 2019.
DMA hat immer perfekt funktioniert.
Gruß und viel Erfolg
jepp, sehe ich auch so. Der DMA sollte da dein erster Anlaufpunkt sein.
Neuen Windows Server aufsetzen, SQL Installieren, und erste DB umziehen.
In der Applikation den neuen SQL angeben und testen. Wenns nicht geht, einfach wieder Schritt zurück und Fehlersuche betreiben.
Habe ein ähnliches Projekt vor 2 Wochen ferstiggestellt. Win2012 mit SQL 2014 und ca 60 kleinen DBs auf Win2022 und SQL 2019.
DMA hat immer perfekt funktioniert.
Gruß und viel Erfolg
jepp, sehe ich auch so. Der DMA sollte da dein erster Anlaufpunkt sein.
Komplett bei Dir. Funktioniert, ist unglaublich hilfreich, sichert wirklich die ganze Instanz.ferstiggestellt
Same here, bereits mehrfach (allerdings erst ab SQL 2012) - jedoch kann man davon ausgehen, dass das wuppt.Wie gesagt: nur am Backup rumspielen/raus migrieren!
MfG.
Hier mal die Quick & Dirty Variante wenn das Serverbetriebssystem kompatibel mit der SQL 2019 Version ist. Im Nachgang muss dann ggf. die Datenbankversion in den einzelnen Datenbanken noch angepasst werden, aber prinzipiell lassen sich die 2008er Datenbanken problemlos am 2019er anfügen.
1) Wichtig: Backup erstellen !!!!
2) Im SQL Management Studio Datenbanken trennen
3) Deinstallation SQL 2008 R2
4) Datenbankordner umbenennen
5) Neustart
6) Installation SQL 2019
7) MDF und LDF (aus 4) in den neuen Datenbankordner kopieren
8) Im SQL Management Studio Datenbanken anfügen
9) fertig
Haben wir auf einigen Kundenrechnern machen müssen, da dort ein alter SQL 2008 Express immer noch unter Windows 11 lief, da der Rechner immer nur ein Betriebsystemupgrade erhalten hatte. Die obigen Schritte waren in ca. 30 Minuten erledigt.
Wenn man viel Zeit hat, kann man auch von 2008 auf 2012, dann auf 2016 und dann auf 2019 per Inplace-Upgrade upgraden
1) Wichtig: Backup erstellen !!!!
2) Im SQL Management Studio Datenbanken trennen
3) Deinstallation SQL 2008 R2
4) Datenbankordner umbenennen
5) Neustart
6) Installation SQL 2019
7) MDF und LDF (aus 4) in den neuen Datenbankordner kopieren
8) Im SQL Management Studio Datenbanken anfügen
9) fertig
Haben wir auf einigen Kundenrechnern machen müssen, da dort ein alter SQL 2008 Express immer noch unter Windows 11 lief, da der Rechner immer nur ein Betriebsystemupgrade erhalten hatte. Die obigen Schritte waren in ca. 30 Minuten erledigt.
Wenn man viel Zeit hat, kann man auch von 2008 auf 2012, dann auf 2016 und dann auf 2019 per Inplace-Upgrade upgraden
Das war bei uns auch einer der möglichen Wege.
Wir haben uns dagegen entschieden, da dann alle Anwendungsserver die auf den SQL zugreifen gleichzeitig davon betroffen sind. Funktioniert nur einer davon nicht, musst du im worst case alles wieder zurück drehen.
side by side kannst du dich ganz auf eine Applikaiton konzentrieren.
Ausfallzeit und Risiko sind entsprechend zu Berücksichtigen.
Gruß
Wir haben uns dagegen entschieden, da dann alle Anwendungsserver die auf den SQL zugreifen gleichzeitig davon betroffen sind. Funktioniert nur einer davon nicht, musst du im worst case alles wieder zurück drehen.
side by side kannst du dich ganz auf eine Applikaiton konzentrieren.
Ausfallzeit und Risiko sind entsprechend zu Berücksichtigen.
Gruß
1
Ja, das ist wie gesagt die Quick&Dirty-Variante. Hier waren nur wenige Arbeitsplätze vom Ausfall betroffen und gab ja auch nur diesen einen 2008er
Hatte das ähnliche Problem mal mit einer veralteten SQL Express DB auf einer Server 2008 r2 Version
Hatte damals einen 2016 VM erstellt, dort die nächsthöhere SQL Version drauf. Von dort dann auf dem 2019 dort die aktúelle SQL .
Hatte gut funkt.
Hatte damals einen 2016 VM erstellt, dort die nächsthöhere SQL Version drauf. Von dort dann auf dem 2019 dort die aktúelle SQL .
Hatte gut funkt.
