SQL Server 2008 R2: problemi dopo la modifica del nome del computer

Sto riscontrando un problema confuso dopo aver modificato il nome del computer di un server remoto che ospita un'istanza locale di SQL Server.

Fondamentalmente, un server remoto è stato spostato da un sito a un altro. Per facilitare ciò, ho eseguito il backup e ripristinato il vecchio database su un nuovo nome di database, cancellando i dati in modo che potesse essere utilizzato come nuovo database per il software client. Ho anche cambiato il nome del computer, poiché lo facciamo sempre per identificare ciascun server in base al numero del suo sito.

Il database può essere collegato correttamente dal software client e posso accedere direttamente a SQL Server. Tuttavia, uno dei miei lavori di SQL Server Agent ha esito negativo, con un errore nel registro eventi:

'Ripristino notturno' del processo pianificato di SQL Server (0x4F76FDFFF6DFFE4EA0DE4A70252AD3BD) - Stato: non riuscito - Richiamato il: 2012-02-07 08:10:05 - Messaggio: il lavoro non è riuscito. Impossibile determinare se il proprietario (Sito-19 \ Admin) del processo Ripristino notturno ha accesso al server (motivo: impossibile ottenere informazioni sul gruppo / utente di Windows NT "Sito-19 \ Admin", codice di errore 0x534. [SQLSTATE 42000] ( Errore 15404)).

Ora, "Sito-19" è il vecchio nome del computer, che è stato modificato e il server è stato ripristinato. Mi collego manualmente usando 'Site-28', il nuovo numero del sito, e mi mostra come connesso a SQL Server con Site-28 \ Admin. Tuttavia, quando guardo le proprietà del lavoro dell'agente, mostra il proprietario come Site-19 \ Admin e quando provo a cercare gli utenti per modificarlo, Site-28 \ Admin non viene visualizzato come opzione , solo Site-19 \ Admin. Se eseguo uno scripting di un nuovo lavoro da questo e cambio manualmente il proprietario in "Site-28 \ Admin", il nuovo lavoro viene creato con il proprietario "Site-19 \ Admin".

Guardando sys.servers (o tramite sp_helpserver), ho solo una voce: il nome del computer corrente. Tuttavia, SELECT @@ SERVERNAME restituisce il nome della macchina di sviluppo originale (due modifiche al nome sono state effettuate).

In breve, non posso eseguire questo importante lavoro di SQL Server Agent perché appartiene a un utente che non esiste più e non riesco a capire come modificarlo o crearlo come utente corretto.

Quando hai aggiunto il nuovo nome del server usando sp_addserver, ti sei ricordato di includere la designazione "locale". È quel tag che aggiorna i metadati per @@ SERVERNAME. Maggiori informazioni.

sp_addserver 'servername', local

Ho trovato la risposta ieri con l'aiuto di un mio amico. Ho dovuto accedere tramite SSMS con un utente diverso dall'accesso a Windows che stavo tentando di utilizzare, eliminare il vecchio accesso e aggiungere nuovamente il mio accesso a Windows. Successivamente, sono stato in grado di trasferire correttamente la proprietà del lavoro, SQL è stato in grado di ottenere i dati dell'utente da Windows e tutto è andato bene per il mondo.

Uso quanto segue per identificare i problemi e creare il drop corretto e aggiungere le istruzioni, se si ottiene TUTTO OK, quindi non è necessario fare nulla altrimenti è necessario eseguire i comandi.

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'

Ha avuto un problema simile: ha cambiato il nome host di un computer su cui è in esecuzione SQL Server e SQL Server Agent. I lavori sono stati assegnati a. Dopo aver creato un utente temporaneo / accedere a SSMS utilizzando questo nuovo utente temporaneo / rilasciare e creare il nome di accesso (public e sysadmin privs!) / Riassegnare i lavori a questo accesso ricreato tutto andava bene. Forse potresti manipolare una tabella di sistema per riflettere la stessa modifica; ma il metodo sopra non è così rischioso.