7
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ß
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-Key: 4102719900
Url: https://administrator.de/contentid/4102719900
Ausgedruckt am: 25.04.2024 um 06: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
Moin,
danke für Euren Input, merke immer wieder, wie sehr ich mich auf den so-muss-es-doch-aber-gehen-Weg eingeschossen habe und verliere Alternativen aus dem Auge
@Crusher79
Vielen Dank für Deine Ideen. Wenn ich aber DNS ändere, brauche ich doch so etwas wie Split-DNS? Der Name wäre ja sonst auch identisch... Oder ich verstehe das falsch.
@jsysde
Da gebe ich Dir Recht, sicherheitstechnisch muss ich das Design noch einmal überdenken. Was die Collation angeht, sollte das relativ egal sein, da sind nur zwei Produktiv- und zwei Testdatenbanken drauf, die alle dasselbe System bedienen.
Ich teste mal ein wenig weiter..
Gruß
danke für Euren Input, merke immer wieder, wie sehr ich mich auf den so-muss-es-doch-aber-gehen-Weg eingeschossen habe und verliere Alternativen aus dem Auge
@Crusher79
Vielen Dank für Deine Ideen. Wenn ich aber DNS ändere, brauche ich doch so etwas wie Split-DNS? Der Name wäre ja sonst auch identisch... Oder ich verstehe das falsch.
@jsysde
Da gebe ich Dir Recht, sicherheitstechnisch muss ich das Design noch einmal überdenken. Was die Collation angeht, sollte das relativ egal sein, da sind nur zwei Produktiv- und zwei Testdatenbanken drauf, die alle dasselbe System bedienen.
Ich teste mal ein wenig weiter..
Gruß
Moin,
ich habe jetzt mal ausgiebig getestet.
Abschließend kann ich sagen, dass das reine Umbenennen des Servers scheinbar ausreicht. Den praktischen Beweis sehe ich hoffentlich in der nächsten Woche, wenn ich das umswitche...
Das habe ich gemacht:
--> Schlägt fehl: Der Server "SQL-ALT" ist nicht vorhanden. Verwenden Sie sp_helpserver, um die verfügbaren Server anzuzeigen.
--> Zeigt nur den neuen Namen an. Etwas komisch, weil ich bei meinem ersten Versuch den alten Namen noch sehen konnte, aber egal.
Sollte so funktionieren. Danke Euch und ein schönes Wochenende!
Gruß
ich habe jetzt mal ausgiebig getestet.
Abschließend kann ich sagen, dass das reine Umbenennen des Servers scheinbar ausreicht. Den praktischen Beweis sehe ich hoffentlich in der nächsten Woche, wenn ich das umswitche...
Das habe ich gemacht:
- Server umbenannt und Reboot
- SQL MMS startet nach Änderung des Namens (localhost oder neuer Name)
- SQL-Abfrage, alten Server löschen und neuen hinzufügen:
EXEC sp_dropserver 'SQL-ALT';
GO
EXEC sp_addserver 'SQL-NEU', local;
GO - OK, das mache ich gleich mal.
sp_helpserverSollte so funktionieren. Danke Euch und ein schönes Wochenende!
Gruß
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
Moin,
der Abschlussbericht...
Hat mit der Umbenennung alles geklappt, was noch zu bedenken ist: Mögliche Wartungspläne müssen ggf. neu angelegt werden, weil die Verbindung sonst noch auf den alten Namen läuft! Dementsprechend laufen die Pläne nicht mehr.
Danach habe ich noch das hier gefunden, möglicherweise hilft das auch in diesem Fall, so dass die Pläne nicht neu erstellt werden müssen. Nicht getestet, weil zu spät gesehen... Sollte aber in jedem Fall gemacht werden, weil dort der Name hinterlegt ist, der bei der Installation verwendet wurde! Welche Auswirkungen das haben könnte, weiß ich nicht, lief bis auf die Pläne auch so vordergründig alles...
https://learn.microsoft.com/de-de/sql/ssms/register-servers/change-the-n ...
Vielleicht hilft das nochmal jemandem. Oder ich recycle die Info bei der nächsten Umbenennung selbst
Viele Grüße!
der Abschlussbericht...
Hat mit der Umbenennung alles geklappt, was noch zu bedenken ist: Mögliche Wartungspläne müssen ggf. neu angelegt werden, weil die Verbindung sonst noch auf den alten Namen läuft! Dementsprechend laufen die Pläne nicht mehr.
Danach habe ich noch das hier gefunden, möglicherweise hilft das auch in diesem Fall, so dass die Pläne nicht neu erstellt werden müssen. Nicht getestet, weil zu spät gesehen... Sollte aber in jedem Fall gemacht werden, weil dort der Name hinterlegt ist, der bei der Installation verwendet wurde! Welche Auswirkungen das haben könnte, weiß ich nicht, lief bis auf die Pläne auch so vordergründig alles...
https://learn.microsoft.com/de-de/sql/ssms/register-servers/change-the-n ...
Vielleicht hilft das nochmal jemandem. Oder ich recycle die Info bei der nächsten Umbenennung selbst
Viele Grüße!
