SQL Server 2008 R2: Probleme nach Änderung des Computernamens

10

Ich habe ein verwirrendes Problem, nachdem ich den Computernamen eines Remote-Servers geändert habe, auf dem sich eine lokale SQL Server-Instanz befindet.

Grundsätzlich wurde ein Remote-Server von einem Standort auf einen anderen verschoben. Um dies zu vereinfachen, habe ich die alte Datenbank gesichert und unter einem neuen Datenbanknamen wiederhergestellt, wobei die Daten gelöscht wurden, damit sie als neue Datenbank für die Client-Software verwendet werden können. Ich habe auch den Computernamen geändert, da wir dies immer tun, um jeden Server anhand seiner Standortnummer zu identifizieren.

Die Datenbank kann von der Client-Software problemlos verbunden werden, und ich kann mich direkt bei SQL Server anmelden. Einer meiner SQL Server Agent-Jobs schlägt jedoch mit einem Fehler im Ereignisprotokoll fehl:

Geplanter SQL Server-Job 'Nächtliches Zurücksetzen' (0x4F76FDFFF6DFFE4EA0DE4A70252AD3BD) - Status: Fehlgeschlagen - Aufgerufen am: 2012-02-07 08:10:05 - Meldung: Der Job ist fehlgeschlagen. Es kann nicht festgestellt werden, ob der Eigentümer (Site-19 \ Admin) des Jobs Nightly Reset Serverzugriff hat (Grund: Es konnten keine Informationen zur Windows NT-Gruppe / zum Benutzer 'Site-19 \ Admin', Fehlercode 0x534, abgerufen werden. [SQLSTATE 42000] ( Fehler 15404)).

Jetzt ist 'Site-19' der alte Computername, der geändert und der Server zurückgesetzt wurde. Ich verbinde mich manuell mit 'Site-28', der neuen Site-Nummer, und es wird angezeigt, dass ich mit Site-28 \ Admin mit dem SQL Server verbunden bin. Wenn ich mir jedoch die Eigenschaften des Agent-Jobs ansehe, wird der Eigentümer als Site-19 \ Admin angezeigt, und wenn ich versuche, nach Benutzern zu suchen, um ihn zu ändern, wird Site-28 \ Admin nicht als Option angezeigt , nur Site-19 \ Admin. Wenn ich einen neuen Job aus diesem herausschreibe und den Eigentümer manuell in "Site-28 \ Admin" ändere, wird der neue Job mit dem Eigentümer "Site-19 \ Admin" erstellt.

In sys.servers (oder über sp_helpserver) habe ich nur einen Eintrag: den aktuellen Computernamen. SELECT @@ SERVERNAME gibt jedoch den ursprünglichen Namen der Entwicklungsmaschine zurück (vor zwei Namensänderungen).

Kurz gesagt, ich kann diesen wichtigen SQL Server-Agent-Job nicht ausführen, da er einem Benutzer gehört, der nicht mehr vorhanden ist, und ich kann nicht herausfinden, wie er geändert oder als der richtige Benutzer erstellt werden kann.

sql-server-2008-r2 instance

— Geo Ego
quelle

Danke für den Link. Auf Ihren Vorschlag habe ich es auch dort gefragt. Ich denke, dass dies auch hier gültig ist, da die Frage zwar eher infrastrukturbezogen ist, die Antwort jedoch höchstwahrscheinlich Code enthält und es auch hier viele Fragen zur SQL Server-Methodik gibt.

— Geo Ego

Und was passiert, wenn Sie den Server 'Site-28' löschen? Was zeigt sp_helpserver an? Können Sie nicht einfach einen alten Job löschen und einen neuen erstellen?

1

Interessanterweise sagt mir der Versuch, 'Site-28' zu löschen, dass er nicht gefunden werden kann. Wenn ich versuche, es hinzuzufügen, heißt es, dass es bereits existiert. Wenn ich den Job neu erstelle, sei es über den Assistenten oder durch Herausschreiben aus dem Original, wird er immer mit 'Site-19 \ Admin' als Eigentümer erstellt.

— Geo Ego

Dem alten physischen Server wurde also ein neuer Name zugewiesen (und diese Änderung wurde auch in DNS vorgenommen), und SELECT @@ SERVERNAME im umbenannten Feld gibt seinen neuen Namen zurück.

— jl01

1

Ich habe die übertragene Frage in diese zusammengeführt, sodass alle Antworten konsolidiert sind.

— Jcolebrand

7

Haben Sie beim Hinzufügen des neuen Servernamens mit sp_addserver daran gedacht, die Bezeichnung "local" anzugeben? Dieses Tag aktualisiert die Metadaten für @@ SERVERNAME. Mehr Informationen.

sp_addserver 'servername', local

— Brian Knight
quelle

Nur eine Notiz, @@ServerNamedie nicht aktualisiert wurde, bis ich SQL Server neu startete

— Fiat

7

Ich habe die Antwort gestern mit Hilfe eines Freundes gefunden. Ich musste mich über SSMS mit einem anderen Benutzer als dem Windows-Login anmelden, den ich verwenden wollte, den alten Login löschen und meinen Windows-Login erneut hinzufügen. Danach konnte ich das Eigentum an dem Job ordnungsgemäß übertragen, SQL konnte die Benutzerdaten von Windows abrufen und alles war in Ordnung mit der Welt.

— Geo Ego
quelle

Ich habe die Antwort von AND @ brian-knight angewendet. Um die DB-Eigentümer zu ändern, habe ich dies verwendet

SELECT 'use ' + DB_NAME(database_id) + ';EXEC sp_changedbowner ''sa'';' FROM sys.databases where DB_NAME(database_id) like 'MyDbs%';

. Danach konnte ich die schlechte Anmeldung fallen lassen

— Fiat

4

Ich benutze das Folgende, um Probleme zu identifizieren und die richtigen Drop- und Add-Anweisungen zu erstellen. Wenn Sie ALL OK erhalten, müssen Sie nichts tun, sonst müssen Sie die Befehle ausführen.

declare @currentName as nvarchar(128)
declare @newName as varchar(max)
declare @serverName as varchar(max)
declare @serverInstance as varchar(max)

select  @currentName = @@SERVERNAME
select @serverInstance = cast(serverproperty('InstanceName') as varchar(max))
select  @serverName = cast(serverproperty('MachineName') as varchar(max))

set @newName = @serverName

if (@serverInstance <> '') 
begin
      set @newName = @serverName + '\' + @serverInstance
end

if (@currentName <> @newName)
Begin
      print 'sp_dropserver ''' + @currentName + '''';
      print 'go'
      print 'sp_addserver ''' + @newName + ''',local'
      print 'go'
end
else
Print 'ALL OK'

— Mike Miller
quelle

Mit diesem Skript konnte ich feststellen, dass ich den alten Servernamen manuell löschen und den neuen hinzufügen musste. Ich habe es getan, aber ich habe immer noch die gleichen Probleme.

— Geo Ego

Haben Sie die Instanz neu gestartet?

Ja, die Instanz wurde anschließend neu gestartet.

— Geo Ego

Tut mir leid, Alter muss sich beugen, ich bin mir nicht sicher, was das Problem sein könnte.

0

Hatte ein ähnliches Problem: Der Hostname eines Computers wurde geändert, auf dem SQL Server und SQL Server Agent ausgeführt werden. Jobs wurden zugewiesen. Nach dem Erstellen eines temporären Benutzers / der Anmeldung bei SSMS mit diesem neuen temporären Benutzer / drop und dem Erstellen des Anmeldenamens (public und sysadmin privs!) / Neuzuweisen der Jobs zu diesem neu erstellten Login war alles in Ordnung. Vielleicht könnten Sie eine Systemtabelle manipulieren, um dieselbe Änderung widerzuspiegeln. aber obige Methode ist nicht so riskant.

— Martin Bruegger
quelle