SQL Server "Cannot open database requested by the login" — Login Var, Veritabanı Yok
Error 4060 + 18456 State 38/40: varsayılan veritabanı silinmiş, offline, RESTORING veya autoclose. Yetim kullanıcı onarımı dahil adım adım çözüm.
Hata mesajı semptomdur, kök neden değildir. Sunucuyu yeniden başlatmadan veya rastgele ayar değiştirmeden önce aşağıdaki "Nedeni ayırt eden tek sorgu"yu çalıştırarak gerçek senaryoyu netleştirin.
▸Belirti
Cannot open database "uygulama_db" requested by the login. The login failed.
Login failed for user 'uygulama'. Reason: Failed to open the explicitly
specified database. [CLIENT: 10.0.4.22]Bu hata, kimlik doğrulamanın başarılı olduğunu söyler: şifre doğru, login mevcut. Sorun, login'in açılmak istediği veritabanındadır. SQL Server ERRORLOG dosyasındaki State: 38 veya 40, tam olarak bu senaryoyu işaret eder.
▸Adım adım çözüm
1. Veritabanının durumuna bakın.
SELECT name, state_desc, user_access_desc, recovery_model_desc, is_auto_close_on
FROM sys.databases;state_desc | Anlamı | Müdahale |
|---|---|---|
ONLINE | Veritabanı açık, sorun kullanıcıda | 2. adıma geçin |
RESTORING | Restore işlemi bitmemiş | RESTORE DATABASE ... WITH RECOVERY çalıştırın |
RECOVERY_PENDING | Kaynak bekliyor / disk hatası | Dosya yollarını ve OS diskini kontrol edin |
OFFLINE | Elle kapatılmış | ALTER DATABASE uygulama_db SET ONLINE |
SUSPECT | Veritabanı bozuk | DBCC CHECKDB ile hasar tespiti yapın |
2. Login'in varsayılan veritabanını kontrol edin. En sık neden: varsayılan veritabanı silinmiş bir login.
SELECT name, default_database_name, is_disabled
FROM sys.server_principals
WHERE type IN ('S', 'U');Silinmiş bir veritabanı adı yazıyorsa bağlantı anında reddedilir. Geçici onarım:
ALTER LOGIN [uygulama] WITH DEFAULT_DATABASE = [master];3. Yetim kullanıcı (Orphan User) kontrolü. Veritabanı başka bir sunucudan geri yüklendiğinde, içindeki kullanıcılar sunucudaki login'lerle SID üzerinden eşleşmez:
USE [uygulama_db];
SELECT dp.name AS db_kullanici, dp.type_desc,
sp.name AS sunucu_login
FROM sys.database_principals dp
LEFT JOIN sys.server_principals sp ON dp.sid = sp.sid
WHERE dp.type IN ('S', 'U')
AND sp.name IS NULL;Eğer yetim kullanıcı varsa onarın:
ALTER USER [uygulama] WITH LOGIN = [uygulama];4. `AUTO_CLOSE` tuzağı. SQL Server Express ve geliştirici ortamlarında AUTO_CLOSE açık gelir: son bağlantı kapandığında veritabanı unmount edilir, bir sonraki bağlantıda yeniden açılır — yoğun anda bu durum rastgele "cannot open database" hataları üretir.
ALTER DATABASE uygulama_db SET AUTO_CLOSE OFF;5. Veritabanı `SINGLE_USER` modunda mı? Bir restore işlemi veya bakım script'i veritabanını tek kullanıcı modunda bırakmış olabilir:
SELECT name, user_access_desc FROM sys.databases WHERE user_access_desc <> 'MULTI_USER';
ALTER DATABASE uygulama_db SET MULTI_USER;▸Bunu bir daha yaşamamak için
Restore sonrası kontrol listesine üç madde ekleyin: state_desc = ONLINE mı, yetim kullanıcı var mı, AUTO_CLOSE kapalı mı. Bu üçü, felaket kurtarma sonrası en sık atlanan ve gereksiz kesintiye yol açan kontrollerdir.
- •İlgili Hata: SQL Server Error 18456: Login Failed
- •İlgili Hata: SQL Server Connection Pool Timeout
Diğer Veritabanı Hata Teşhisleri
Kriz anında başvurabileceğiniz diğer doğrulanmış hata rehberleri.
PostgreSQL too many clients already Hatası: 6 Adımda Çözüm
FATAL: sorry, too many clients already hatasının üç nedeni, nedeni ayırt eden tek sorgu ve max_connections ile PgBouncer üzerinden kalıcı çözümü.
PostgreSQL password authentication failed Hatası: Neden ve Çözüm
psql password authentication failed hatasının dört nedeni: yanlış şifre, md5/SCRAM uyuşmazlığı, pg_hba.conf sırası ve yanlış cluster. Adım adım teşhis.
MySQL ERROR 1045 Access denied: root Şifresi Sıfırlama Rehberi
MySQL 1045 hatasının dört nedeni, "using password: YES/NO" ayrımının anlamı ve kilitli kalınca --init-file ile güvenli şifre sıfırlama.