MS SQL-Server umbenennen
Moin,
wir haben noch einen MS SQL 2012 am Laufen, bekanntermaßen ist der nicht mehr supportet. Jetzt soll der auf einen SQL 2019 umgebettet werden, prinzipiell klappt das auch alles. Alle DBs laufen in der Standardinstanz, alle Server laufen in einer 2019-Domäne.
Ich möchte nun folgendes machen:
Nachdem alle Datenbanken migriert sind, soll die Clientsoftware mit bestehender Konfiguration auf den neuen Server zugreifen.
Name alter Server: SQL-SERVER
Name neuer Server: SQL-SERVER-NEU
Die Clients greifen auf SQL-SERVER zu. Meine Idee: Damit ich das nicht alles anpacken muss, benenne ich einfach nach der Migration der Datenbanken SQL-SERVER-NEU in SQL-SERVER um.
Das gibt doch aber SQL-intern bestimmt Stress, wenn ich jetzt den Servernamen ändere?
Habe dies hier gefunden:
https://learn.microsoft.com/de-de/sql/database-engine/install-windows/re ...
Reicht es aus, wenn ich das hier ausführe? Der Instanzname sollte ja keine Rolle spielen.
Muss ich sonst etwas beachten?
Gruß
wir haben noch einen MS SQL 2012 am Laufen, bekanntermaßen ist der nicht mehr supportet. Jetzt soll der auf einen SQL 2019 umgebettet werden, prinzipiell klappt das auch alles. Alle DBs laufen in der Standardinstanz, alle Server laufen in einer 2019-Domäne.
Ich möchte nun folgendes machen:
Nachdem alle Datenbanken migriert sind, soll die Clientsoftware mit bestehender Konfiguration auf den neuen Server zugreifen.
Name alter Server: SQL-SERVER
Name neuer Server: SQL-SERVER-NEU
Die Clients greifen auf SQL-SERVER zu. Meine Idee: Damit ich das nicht alles anpacken muss, benenne ich einfach nach der Migration der Datenbanken SQL-SERVER-NEU in SQL-SERVER um.
Das gibt doch aber SQL-intern bestimmt Stress, wenn ich jetzt den Servernamen ändere?
Habe dies hier gefunden:
https://learn.microsoft.com/de-de/sql/database-engine/install-windows/re ...
Reicht es aus, wenn ich das hier ausführe? Der Instanzname sollte ja keine Rolle spielen.
EXEC sp_dropserver '<old_name>';
GO
EXEC sp_addserver '<new_name>', local;
GO
Muss ich sonst etwas beachten?
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4102719900
Url: https://administrator.de/forum/ms-sql-server-umbenennen-4102719900.html
Ausgedruckt am: 01.04.2025 um 22:04 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
ähm warum? Lieg ich jetzt falsch oder reicht nicht die gleiche Instanz? Man kann query ja auch von remote via IP aufbauen. Ich würd einfach DNS ändern und fertig. Wenn das Mapping mit der neuen IP vollzogen wurde, sollten sich die Clients verbinden können.
localhost\Instanz geht ja auch.
Wenn du allein in die SQL MM Maske mal statt SQL-SERVER "localhost" einträgst bist du doch auch verbunden. Ein Instanzwechsel hätte dazu geführt, dass in jeden Client die neue Instanz hinterlegt hätte werden müssen.
So sehe ich da kein Problem. Geht auch mit 127.0.0.1 ....
mfg Crusher
PS: Hab den Artikel übersehen. Nein das sollte es dann gewesen sein.
Für ODBC und Pseudo-Failover nehmen manche bewusst den Weg über DNS und biegen es um. Ich grübel grad ob es zwingend notwendig ist bei deinen Konstrukt.
ähm warum? Lieg ich jetzt falsch oder reicht nicht die gleiche Instanz? Man kann query ja auch von remote via IP aufbauen. Ich würd einfach DNS ändern und fertig. Wenn das Mapping mit der neuen IP vollzogen wurde, sollten sich die Clients verbinden können.
localhost\Instanz geht ja auch.
Wenn du allein in die SQL MM Maske mal statt SQL-SERVER "localhost" einträgst bist du doch auch verbunden. Ein Instanzwechsel hätte dazu geführt, dass in jeden Client die neue Instanz hinterlegt hätte werden müssen.
So sehe ich da kein Problem. Geht auch mit 127.0.0.1 ....
mfg Crusher
PS: Hab den Artikel übersehen. Nein das sollte es dann gewesen sein.
Für ODBC und Pseudo-Failover nehmen manche bewusst den Weg über DNS und biegen es um. Ich grübel grad ob es zwingend notwendig ist bei deinen Konstrukt.

Wenn es wirklich nur um den Hostnamen geht, sollte es kaum Probleme geben.
N'Abend.
https://www.sqlshack.com/overview-of-sql-server-alias/
Cheers,
jsysde
Zitat von @Coreknabe:
[...]Alle DBs laufen in der Standardinstanz, alle Server laufen in einer 2019-Domäne.
Warum? Sicherheitstechnisch ist das ein Supergau. Richtigerweise sollte jede Applikation ihre DB(s) in einer eigenen Instanz haben. Schon allein um der DB-Collation willen...[...]Alle DBs laufen in der Standardinstanz, alle Server laufen in einer 2019-Domäne.
[...]Muss ich sonst etwas beachten?
Um in (ferner) Zukunft nicht wieder vor dem Problem zu stehen: Konfigurier' dir passende SQL-Aliasse:https://www.sqlshack.com/overview-of-sql-server-alias/
Cheers,
jsysde
Hallo, da hat @jsysde wohl noch etwas mehr Erfahrung.
Ich weiss auch nicht was passeirt, wenn man auf die stored procedure zum umbenennen verzichtet. Wir hatten damals keine schöne Software Lösung. Generell lief Zugriff auf MS SQL nur über ODBC. Failover Konzept sah ähnliches vor. Mit -Alias arbeiten und dann den Spiegelserver dann manuell umswitchern.
Würde da aber @jsysde Link folgen und da näher einsteigen. Bzw. einen kleinen Ausflug in Spiegelung machen. Ein paar Dinge kannst du dann auch für solche Aktionen mit einen einzelnen Server adaptieren.
Oder wenn du Zeit hast: SQL Dev ist ja kostenlos. Damit mal einen Test Ballon starten und schauen was so geht. Ggf. hab ihr ja eine Testumgebung. Könnte sich lohnen.
mfg Crusher
Ich weiss auch nicht was passeirt, wenn man auf die stored procedure zum umbenennen verzichtet. Wir hatten damals keine schöne Software Lösung. Generell lief Zugriff auf MS SQL nur über ODBC. Failover Konzept sah ähnliches vor. Mit -Alias arbeiten und dann den Spiegelserver dann manuell umswitchern.
Würde da aber @jsysde Link folgen und da näher einsteigen. Bzw. einen kleinen Ausflug in Spiegelung machen. Ein paar Dinge kannst du dann auch für solche Aktionen mit einen einzelnen Server adaptieren.
Oder wenn du Zeit hast: SQL Dev ist ja kostenlos. Damit mal einen Test Ballon starten und schauen was so geht. Ggf. hab ihr ja eine Testumgebung. Könnte sich lohnen.
mfg Crusher