Kendimiz bir servis yazdığında veya SQL Server kurulumunda en çok karşımızı çıkan konusu servisi hangi kullanıcı çalıştıracak. Bu iş genel olarak Local System, Local Service, Network Service kullanıcı hesapları tercih edilir. Bu küçük yazıda bu kullanıcıların farkını belirtip SQL Server cephesinde nasıl bir tercih yapmamız gerektiğini not alacağız.
Local System : Makine üzerindeki en yetkili hesaptır. Hatta Administrator hesabından daha yetkilidir diyebiliriz. Hem yerel hem de network kaynaklarına erişebilir. Bu hesabın adı gerçekte “NT AUTHORITY\SYSTEM” olarak geçmektedir. Temelde NT AUTHORITY\SYSTEM ve Builtin\Administrators yetkilerini içerir. Bu yüzden SQL Server tarafından default olarak sysadmin rolünü alır.
Network Service : Local System / Administrator kullanıcısına göre daha az yetkili olup network kaynaklarına erişecek servis kullanıcısıdır. Bu hesabın kullanıcı adı “NT AUTHORITY\NETWORK SERVICE” olarak geçmektedir.
Local Service : Network Service kullanıcısıyla aynı sınırlı yetkilere sahip olup tek farkı network kaynaklarına erişemez. Bu hesabın kullanıcısı “NT AUTHORITY\LOCAL SERVICE” olarak geçmektedir. Bu account SQL Server veya SQL Server Agent servisleri tarafından desteklenmemektedir. Bu kullanıcı genellikle makinenin dışındaki kaynaklara erişmeyecek servisler tarafında tercih edilir.
SQL Server servisi için mümkün olduğunca Local non-system veya Service kullanıcısını kullanmak yerine bu iş oluşturulmuş bir Domain hesabının kullanılması tavsiye edilir. Ve bu domain hesabının da olabildiğince minimum yetkilere sahip olması gerekmektedir. Eğer SQL Server üzerinden dosya paylaşımı, linked server gibi network kaynak erişimi olacaksa doğru yetkilendirilmiş AD kullanıcısı tercih edilmesi daha doğru olacaktır. Ayrıca birden fazla SQL Server sunucusu varsa bunların tek bir domain kullanıcısı tarafından başlatılması yönetim kolaylığı sağlayacaktır. Eğer SQL Server’in bulunduğu makine Domain’de bulunmuyorsa yerel kullanıcı servisi kullanıcısı olarak tercih edilebilir. Tabi bu kullanıcının Administrator yetkilerine sahip olmamasına dikkat edilmelidir.
Özetle SQL Server ve alt birimlerini için mümkün olduğunca az yetkili bir kullanıcıyla çalıştırmak ve SQL Server ve Agent için ayrı kullanıcıları tercih etmek tavsiye edilir.

SQL Server’in bulunduğu makineyi değiştirdikten sonra mevcut sistemde tanımlı Job’ları da yeni sunucuya aktardık. Yöntem olarak msdb veritabanını attach ettik. Bu Job’lar SSIS paketlerini çalıştırıyor. Job’ları çalıştırdığımızda aşağıdaki hatayı aldım.
Unable to start execution of step 1 (reason: The SSIS subsystem failed to load [see the SQLAGENT.OUT file for details]; The job has been suspended). The step failed.
Bu sorunun nedeni eski ile yeni sunucunun SQL Server kurulum klasörlerinin farklı oluşuymuş. Çünkü SQL Server TSQL, CmdExec, SSIS, PowerShell, Snapshot, LogReader, Distribution . gibi SQL Server Agent üzerindeki alt sistemlere ait DLL bilgilerini msdb.dbo.syssubsystems tablosunda tutuyor. Bu tablodaki kütüphane adresleri eski sunucuda farklı olduğu için sistem SSIS paketlerini hangi motorla çalıştıracağını bilemiyor.
Bu sorunun kolay bir çözüm var. sp_verify_subsystems prosedürü ilgili alt sistemler için doğru DLL adreslerini yeniden oluşturuyor. Aşağıdaki gibi tablodaki mevcut kayıtları silip ilgili prosedürü çalıştırmamız yeterli olacaktır.

--Mevcut kayıtları sil
DELETE FROM msdb.dbo.syssubsystems

--Tabloyu yeni DLL adresleriyle yeniden doldur
EXEC msdb.dbo.sp_verify_subsystems 1

Birkaç gün önce sunucu iyileştirme kapsamında SQL Server 2008 instance üzerinde bulunan bir veritabanını detach edip network üzerinden ikinci sunucuya kopyalayıp aynı şekilde SQL Server 2008 R2 üzerine attach etmeye çalışırken aşağıdaki hatayla karşılaştım.
Msg 3415, Level 16, State 3, Line 1
Database [database_name] cannot be upgraded because it is read-only or has read-only files. Make the database or files writeable, and rerun recovery.
Msg 1813, Level 16, State 2, Line 1
Could not open new database [database_name]. CREATE DATABASE is aborted.

Mesajın içeriğine bakınca database dosyalarının işletim sistemi üzerinde salt-okunur olduğunu düşündüm. Oysa dosyaları read-only durumda değildi. SQL Server’i çalıştıran kullanıcının permission ayarlarına baktım onlar da full görünüyordu. Yaptığım araştırmalarda bu işin nedenlerinin farklı olabileceği ve farklı şekillerde çözülebileceği söyleniyor. Muhtemel neden ve çözümleri aşağıda bulabilirsiniz;
Öncelikle bu dosyaların attach edilmesi esnasında başka bir instance tarafından kullanılmadığında ve dosya özelliklerinden ve ya kullanıcı yetkilerinden salt-okunur olmadıklarından emin olmamız gerekiyor.
Birinci çözüm olarak “Everyone” kullanıcısına full access yetkisi verilir. Dosyalar attach edildikten sonra işlem başarılı olduktan sonra Everyone yetkisi geri alınır.
İkinci çözüm veya sorunun nedeni olarak SQL Server kullanıcısına bakılabilir. Benim sorunum buydu. SQL Server servisi AUTHORITY\NETWORKSERVICE kullanıcısıyla başlatılmıştı. Bu kullanıcının attach etmek hakkı olmadığı için servis kullanıcısını LOCAL ACCOUNT olarak değiştirince sorun çözüldü.