SQL Server 2008 R2: Masalah setelah perubahan nama komputer

Saya mengalami masalah membingungkan setelah mengubah nama komputer dari server jauh yang menjadi tuan rumah contoh SQL Server lokal.

Pada dasarnya, server jarak jauh dipindahkan dari satu situs ke situs lainnya. Untuk memfasilitasi ini, saya mencadangkan dan memulihkan database lama ke nama database baru, membersihkan data sehingga dapat digunakan sebagai database baru untuk perangkat lunak klien. Saya juga mengubah nama komputer, karena kami selalu melakukannya untuk mengidentifikasi setiap server dengan nomor situsnya.

Basis data dapat dihubungkan dengan perangkat lunak klien dengan baik, dan saya dapat masuk langsung ke SQL Server. Namun, salah satu pekerjaan SQL Server Agent saya gagal, dengan kesalahan dalam log peristiwa:

SQL Server Scheduled Job 'Nightly Reset' (0x4F76FDFFF6DFFE4EA0DE4A70252AD3BD) - Status: Gagal - Dipanggil pada: 2012-02-07 08:10:05 - Pesan: Pekerjaan gagal. Tidak dapat menentukan apakah pemilik (Situs-19 \ Admin) pekerjaan Reset Malam memiliki akses server (alasan: Tidak dapat memperoleh informasi tentang grup Windows NT / pengguna 'Situs-19 \ Admin', kode kesalahan 0x534. [SQLSTATE 42000] ( Kesalahan 15404)).

Sekarang, 'Situs-19' adalah nama komputer lama, yang telah diubah, dan server telah disetel ulang. Saya terhubung secara manual menggunakan 'Site-28', nomor situs baru, dan ini menunjukkan saya terhubung ke SQL Server dengan Site-28 \ Admin. Namun, ketika saya melihat properti dari pekerjaan Agen, itu menunjukkan pemilik sebagai Situs-19 \ Admin, dan ketika saya mencoba menelusuri pengguna untuk mengubahnya, Situs-28 \ Admin tidak muncul sebagai opsi , hanya Site-19 \ Admin. Jika saya skrip pekerjaan baru dari yang ini dan secara manual mengubah pemilik ke 'Situs-28 \ Admin', pekerjaan baru dibuat dengan pemilik 'Situs-19 \ Admin'.

Mencari di sys.servers (atau melalui sp_helpserver), saya hanya punya satu entri: nama komputer saat ini. Namun, SELECT @@ SERVERNAME mengembalikan nama mesin pengembangan asli (dua perubahan nama yang lalu).

Singkatnya, saya tidak bisa menjalankan pekerjaan SQL Server Agent yang penting ini karena itu milik pengguna yang sudah tidak ada, dan saya tidak tahu cara mengubahnya atau membuatnya sebagai pengguna yang benar.

Ketika Anda menambahkan nama server baru menggunakan sp_addserver, apakah Anda ingat untuk memasukkan penunjukan "lokal". Tag itulah yang memperbarui metadata untuk @@ SERVERNAME. Informasi lebih lanjut

sp_addserver 'servername', local

Saya menemukan jawabannya kemarin dengan bantuan seorang teman saya. Saya harus login melalui SSMS dengan pengguna selain login Windows yang saya coba gunakan, hapus login lama, dan tambahkan login Windows saya lagi. Setelah itu, saya bisa mentransfer kepemilikan pekerjaan dengan benar, SQL bisa mendapatkan data pengguna dari Windows, dan semuanya benar dengan dunia.

Saya menggunakan berikut ini untuk mengidentifikasi masalah dan membangun drop yang benar dan menambahkan pernyataan, jika Anda mendapatkan SEMUA BAIK, maka Anda tidak perlu melakukan apa pun jika tidak, Anda perlu menjalankan perintah.

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'

Punya masalah serupa: mengubah nama host komputer di mana SQL Server dan SQL Server Agent berjalan. Pekerjaan ditugaskan. Setelah membuat pengguna temp / logon ke SSMS menggunakan pengguna temp / drop baru ini dan membuat nama login (publik dan sysadmin privs!) / Menetapkan ulang pekerjaan untuk ini menciptakan kembali Login semuanya baik-baik saja. Mungkin Anda bisa memanipulasi tabel sistem untuk mencerminkan perubahan yang sama; tetapi metode di atas tidak terlalu berisiko.