4064 – Nie można zalogować się do domyślnej bazy danych

Błąd 4064 pojawia się, gdy użytkownik nie może zalogować się do domyślnej bazy danych przypisanej do jego konta.

Co oznacza błąd SQL Server 4064

Komunikat 4064 w Microsoft SQL Server oznacza, że proces logowania użytkownika zakończył się niepowodzeniem, ponieważ serwer nie może otworzyć domyślnej bazy danych przypisanej do tego konta. Domyślna baza danych jest bazą wybieraną automatycznie po poprawnym uwierzytelnieniu. Jeżeli użytkownik nie wskaże innej bazy w żądaniu połączenia, SQL Server próbuje rozpocząć sesję właśnie w tej bazie.

Sam błąd nie musi oznaczać nieprawidłowego hasła. Konto może zostać rozpoznane prawidłowo, ale dalsze przejście do wskazanej bazy może być niemożliwe. Przyczyną bywa usunięcie bazy, zmiana jej nazwy, stan offline, brak dostępu użytkownika, brak uprawnień do połączenia albo niedostępność plików bazy. W praktyce numer 4064 opisuje problem z bazą startową użytkownika, a nie jedną, zawsze taką samą awarię.

Dlaczego ustawiona baza może być niedostępna

Każdy login SQL Server może mieć określoną właściwość default_database, czyli nazwę domyślnej bazy danych. Jeżeli administrator usunął tę bazę albo odtworzył ją pod inną nazwą, właściwość konta może wskazywać obiekt, którego już nie ma. Podobna sytuacja występuje po migracji, przywróceniu kopii zapasowej lub zmianie konfiguracji instancji, gdy baza istnieje, ale nie jest dostępna w sposób oczekiwany przez login.

Baza może także znajdować się w stanie, który uniemożliwia rozpoczęcie zwykłej sesji. Dotyczy to między innymi stanów OFFLINE, RECOVERY_PENDING, SUSPECT lub EMERGENCY, a także problemów z plikami danych i plikami dziennika transakcji. Jeżeli SQL Server nie może otworzyć bazy albo ukończyć jej odzyskiwania, użytkownik nie przejdzie do niej po zalogowaniu. Również brak mapowania loginu na użytkownika w konkretnej bazie może powodować problemy z dalszym dostępem, nawet gdy sam login jest prawidłowy.

Istotne jest odróżnienie loginu od użytkownika bazy danych. Login jest obiektem instancji SQL Server i służy do uwierzytelnienia, natomiast użytkownik bazy danych określa uprawnienia wewnątrz konkretnej bazy. Po odtworzeniu bazy na innej instancji identyfikator zabezpieczeń użytkownika może nie odpowiadać loginowi. Taki rozjazd, często określany jako osierocony użytkownik, wymaga osobnego sprawdzenia i nie powinien być leczony przypadkową zmianą uprawnień.

Bezpieczna kolejność rozpoznania problemu

Diagnostykę należy rozpocząć od ustalenia instancji SQL Server, loginu oraz dokładnej nazwy domyślnej bazy. Administrator może sprawdzić właściwość loginu w metadanych serwera, korzystając z widoku sys.server_principals, a dostępne bazy przeanalizować w sys.databases. Weryfikacja powinna obejmować nazwę bazy, stan kolumny state_desc oraz podstawowe informacje o dostępie. Warto również przejrzeć dziennik błędów SQL Server, ponieważ komunikaty towarzyszące mogą wskazać problem z plikiem, odzyskiwaniem lub uprawnieniami.

Jeżeli login jest poprawny, a problem dotyczy wyłącznie bazy startowej, można wykonać próbę połączenia z bazą systemową master. W narzędziu sqlcmd służy do tego parametr -d master, a w innych klientach podobny efekt daje wskazanie master jako bazy początkowej w ustawieniach połączenia. Takie połączenie nie naprawia przyczyny, ale pozwala administratorowi wejść do instancji i skorygować konfigurację loginu. Zmiana domyślnej bazy powinna wskazywać istniejącą i dostępną bazę, na przykład za pomocą polecenia ALTER LOGIN z opcją DEFAULT_DATABASE.

Przed zmianą konfiguracji trzeba ustalić, czy właściwym rozwiązaniem jest przywrócenie dostępności pierwotnej bazy, czy przypisanie innej bazy startowej. Nie należy automatycznie ustawiać master jako stałego zamiennika bez sprawdzenia sposobu pracy aplikacji, ponieważ aplikacja może oczekiwać określonego kontekstu bazodanowego. Po korekcie należy ponowić logowanie z użyciem tego samego klienta i parametrów, sprawdzić mapowanie loginu na użytkownika oraz potwierdzić, że aplikacja korzysta z właściwej bazy i wymaganych obiektów.

Naprawa konfiguracji bez maskowania przyczyny

Najczęstsza naprawa polega na przywróceniu bazy do stanu dostępnego albo zmianie domyślnej bazy loginu na prawidłowy obiekt. Jeżeli baza jest offline, trzeba ustalić, dlaczego została wyłączona. Jeżeli występuje stan RECOVERY_PENDING lub SUSPECT, potrzebna jest analiza dziennika SQL Server, systemu plików oraz dostępnych kopii zapasowych. Samo przełączanie stanów administracyjnych bez rozpoznania przyczyny może pogorszyć możliwość odzyskania danych. Gdy problem wynika z braku użytkownika w bazie, należy sprawdzić jego mapowanie i nadać wyłącznie uprawnienia wynikające z rzeczywistego sposobu użycia.

Po naprawie warto zweryfikować także konfigurację aplikacji: nazwę serwera, nazwę instancji, nazwę bazy, metodę uwierzytelniania oraz ewentualny parametr początkowej bazy danych. Błąd może powracać, jeżeli aplikacja używa nieaktualnej nazwy bazy albo wymusza połączenie z obiektem, który został przeniesiony. Test powinien obejmować zarówno logowanie administracyjne, jak i zwykłe konto aplikacyjne, ponieważ oba konta mogą mieć różne bazy domyślne i różne mapowania użytkowników.

W przypadku środowiska produkcyjnego diagnostykę należy prowadzić na podstawie kopii konfiguracji, dzienników i potwierdzonych kopii zapasowych. Zmiany w loginach, użytkownikach oraz stanie bazy powinny być dokumentowane, aby można było odtworzyć kolejność działań. Jeżeli 4064 pojawił się po migracji lub odtworzeniu bazy, szczególnej uwagi wymagają zgodność loginów, identyfikatory zabezpieczeń oraz zależności aplikacji od konkretnej bazy startowej.