4
Mssql Server upgrade incl. OS
Hallo,
wir betreiben einen mssql Server 2014 unter Windows Server 2012.
Windows Server soll 2016 werden und mssql 2017.
Beides nebenher neu bauen ist kein Problem, wobei ich nicht weiß, ob ich beim letztendlichen Schwenk durch änderung des Hostnamens und Abschalten des alten Servers die alten Anwendungen zur Weiterarbeit bewegen kann.
Alternative könnte ich einzelne Instanzen umziehen von alt auf neu (mit dem Assistenten?) und der Anwendung den neuen sql-Server eintragen.
Wie geht man bei einer solchen Upgrade-Aktion sinnigerweise vor?
Danke.
wir betreiben einen mssql Server 2014 unter Windows Server 2012.
Windows Server soll 2016 werden und mssql 2017.
Beides nebenher neu bauen ist kein Problem, wobei ich nicht weiß, ob ich beim letztendlichen Schwenk durch änderung des Hostnamens und Abschalten des alten Servers die alten Anwendungen zur Weiterarbeit bewegen kann.
Alternative könnte ich einzelne Instanzen umziehen von alt auf neu (mit dem Assistenten?) und der Anwendung den neuen sql-Server eintragen.
Wie geht man bei einer solchen Upgrade-Aktion sinnigerweise vor?
Danke.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 468191
Url: https://administrator.de/forum/mssql-server-upgrade-incl-os-468191.html
Ausgedruckt am: 02.04.2025 um 03:04 Uhr
4 Kommentare
Neuester Kommentar
Hi,
müsstest klären, ob die Applikationen auch alle noch unter SQL 2017 laufen. Normal bei trivialen INSERT, SELECT Statements etc. gibt es kaum Probleme. Aber auf jedenfall wüde ich vorher mit den Software-Lieferanten sprechen.
Daneben kann es auch sein, dass DirectSQL in den Applikationen nur auf die alte Version zugeschnitten ist. Da ist auch natürlich die Frage, wie wird auf die Daten generell zugegriffen? Native SQL Client oder ODBC......
Backups kann man wunderbar von alter auf neuer SQL Version zurückspielen. ABER es gibt neben den reinen Daten auch Proceduren etc. Im schlimmsten Fall kann es sein, dass die Anwendung nicht mehr korrekt läuft.
Wenn du alt und neu nebeneinander betreiben kannst, so kannst du auch viele der Fragen selber beantworten. Testen.....
Ach ja, und schau dir auch die Berechtigungen an! Wenn nicht überall mit sa gearbeitet wird, musst du entsprechend die Berechtigungen setzen. Da kann man sonst übel auf die Nase fallen.
mfg Crusher
müsstest klären, ob die Applikationen auch alle noch unter SQL 2017 laufen. Normal bei trivialen INSERT, SELECT Statements etc. gibt es kaum Probleme. Aber auf jedenfall wüde ich vorher mit den Software-Lieferanten sprechen.
Daneben kann es auch sein, dass DirectSQL in den Applikationen nur auf die alte Version zugeschnitten ist. Da ist auch natürlich die Frage, wie wird auf die Daten generell zugegriffen? Native SQL Client oder ODBC......
Backups kann man wunderbar von alter auf neuer SQL Version zurückspielen. ABER es gibt neben den reinen Daten auch Proceduren etc. Im schlimmsten Fall kann es sein, dass die Anwendung nicht mehr korrekt läuft.
Wenn du alt und neu nebeneinander betreiben kannst, so kannst du auch viele der Fragen selber beantworten. Testen.....
Ach ja, und schau dir auch die Berechtigungen an! Wenn nicht überall mit sa gearbeitet wird, musst du entsprechend die Berechtigungen setzen. Da kann man sonst übel auf die Nase fallen.
mfg Crusher
Hallo,
falls Du keine allzu großen exotischen Dinge mit den Instanzen machst, also "normales" SQL/T-SQL nutzt, kannst Du auch einfach mit dem SQL-Backup-Statement für die DB eine BAK-Datei erzeugen. Diese DB dann einfach in der "neuen" Instanz wiederherstellen.
Du muss dabei nur danach die DB-User in dieser DB löschen und neu anlegen. Evtl auch die Schemata, Rollen anpassen.
Für einfache DBs sollte das funktionieren. Ich habe damit jedenfalls gute Erfahrungen gemacht.
Statement:
Wen der Instanzen/Servername gleich bleibt, dann sollte es auch bei ADO&Co keine Probleme geben.
(jedenfalls wenn die Programme die die DB nutzen, den Server nicht über IP ansprechen)
Ansonsten müssen evtl. die entsprechenden ConnectionStrings in den jeweiligen Programmen angepasst werden.
Problematischer kann es werden, wenn Du ReportingServices etc. nutzt.
LG
SH
falls Du keine allzu großen exotischen Dinge mit den Instanzen machst, also "normales" SQL/T-SQL nutzt, kannst Du auch einfach mit dem SQL-Backup-Statement für die DB eine BAK-Datei erzeugen. Diese DB dann einfach in der "neuen" Instanz wiederherstellen.
Du muss dabei nur danach die DB-User in dieser DB löschen und neu anlegen. Evtl auch die Schemata, Rollen anpassen.
Für einfache DBs sollte das funktionieren. Ich habe damit jedenfalls gute Erfahrungen gemacht.
Statement:
BACKUP DATABASE myDB TO DISK = 'D:\SQL\Backup\20190703_myDB.bak' WITH Name = '20190703_myDB.bak' , COPY_ONLY; (jedenfalls wenn die Programme die die DB nutzen, den Server nicht über IP ansprechen)
Ansonsten müssen evtl. die entsprechenden ConnectionStrings in den jeweiligen Programmen angepasst werden.
Problematischer kann es werden, wenn Du ReportingServices etc. nutzt.
LG
SH
Eventuell verwendest du wieder den selben Instanz-Namen auf dem neuen Server. Dann kannst du zusätzlich den DNS Namen des alten Servers mit der neuen IP auflösen.
Moin,
Gruß,
Dani
Dann kannst du zusätzlich den DNS Namen des alten Servers mit der neuen IP auflösen.
es könnte je nach Authentifizierungsart noch notwendig sein, den Dienstprinzipalnamen (SPN) des alten Servers dem neuen Server hinzufügen.Gruß,
Dani
