Error 4064 – błąd domyślnej bazy danych

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

Co oznacza komunikat SQL Server Error 4064

Error 4064 w Microsoft SQL Server oznacza, że podczas logowania silnik nie może otworzyć domyślnej bazy danych przypisanej do danego loginu. Po uwierzytelnieniu loginu SQL Server próbuje ustawić tę bazę jako bieżący kontekst sesji. Jeżeli wskazana baza nie istnieje, jest niedostępna albo login nie ma do niej dostępu, sesja może zostać odrzucona właśnie z błędem 4064.

Problem dotyczy domyślnej bazy loginu na poziomie instancji SQL Server, a niekoniecznie samego hasła. Login może mieć prawidłowe dane uwierzytelniające, a mimo to nie uzyskać sesji, ponieważ przypisana baza znajduje się w stanie OFFLINE, RESTORING, RECOVERING lub SUSPECT, została usunięta albo nie można odnaleźć odpowiadającego użytkownika bazodanowego. W przypadku logowania Windows podobna sytuacja może wystąpić po zmianie członkostwa w domenie lub odebraniu uprawnień do wskazanej bazy.

Najczęstsze przyczyny niedostępnej bazy domyślnej

Jedną z typowych przyczyn jest usunięcie albo zmiana nazwy bazy, która nadal figuruje jako wartość domyślna loginu. Innym przypadkiem jest awaria lub przerwa administracyjna: baza może być odłączona, przywracana z kopii zapasowej, oznaczona jako niedostępna albo oczekiwać na zakończenie odzyskiwania. Wtedy sam login nadal istnieje, lecz jego ustawienie wskazuje obiekt, którego SQL Server nie może otworzyć w momencie tworzenia sesji.

Błąd może także wynikać z braku użytkownika mapowanego do loginu w tej konkretnej bazie. Login serwerowy i użytkownik bazodanowy to odrębne obiekty. Utworzenie loginu nie tworzy automatycznie użytkownika we wszystkich bazach. Jeżeli login został usunięty i utworzony ponownie, jego identyfikator SID może być inny niż SID użytkownika pozostałego w bazie. W takiej sytuacji baza istnieje, lecz mapowanie uprawnień może być niespójne. Warto również uwzględnić ograniczenia wynikające z trybu dostępu bazy, stanu instancji oraz uprawnień wymaganych do otwarcia bazy przez dany login.

Sprawdzenie loginu i odzyskanie dostępu przez master

Diagnostykę należy rozpocząć od połączenia z bazą master, ponieważ jest ona standardową bazą systemową i zwykle pozostaje dostępna nawet wtedy, gdy baza ustawiona jako domyślna ma problem. W narzędziu SQL Server Management Studio można wskazać master w opcjach połączenia. W aplikacji lub innym kliencie SQL Server można użyć parametru wyboru bazy, na przykład -d master w narzędziach korzystających z tego przełącznika. Sam sposób przekazania parametru zależy od używanego klienta, ale cel jest ten sam: ominąć automatyczne otwieranie niedostępnej bazy domyślnej.

Po uzyskaniu połączenia uprawniony administrator może sprawdzić ustawienie loginu oraz stan baz w widokach katalogowych. Przykładowe zapytanie pozwalające ustalić bazę domyślną loginu ma postać SELECT name, type_desc, default_database_name FROM sys.server_principals WHERE name = N'NAZWA_LOGINU';. Stan wskazanej bazy można zweryfikować przez SELECT name, state_desc, user_access_desc FROM sys.databases WHERE name = N'NAZWA_BAZY';. Należy porównać nazwę bazy, jej stan oraz faktyczne uprawnienia loginu; nie powinno się zmieniać konfiguracji wyłącznie na podstawie samego komunikatu.

Jeśli właściwa baza jest czasowo niedostępna albo login powinien domyślnie rozpoczynać pracę w innej bazie, administrator może ustawić bazę master poleceniem ALTER LOGIN [NAZWA_LOGINU] WITH DEFAULT_DATABASE = [master];. Po przywróceniu dostępności docelowej bazy można ponownie przypisać ją jako domyślną, pod warunkiem że login ma wymagane uprawnienia. Zmiana domyślnej bazy nie naprawia uszkodzenia bazy, nie tworzy użytkownika bazodanowego i nie nadaje uprawnień do danych; usuwa jedynie przeszkodę występującą przy inicjalizacji sesji.

Weryfikacja po zmianie ustawień

Po korekcie należy zamknąć nieudane połączenie i utworzyć nową sesję, ponieważ istniejąca sesja nie zawsze odzwierciedla zmianę domyślnego kontekstu. Trzeba sprawdzić zarówno logowanie do master, jak i dostęp do docelowej bazy. Pomocne jest zapytanie SELECT DB_NAME() AS current_database;, które pokazuje bazę bieżącego kontekstu. Następnie można wykonać kontrolę dostępu do konkretnego obiektu, ale zakres testu powinien odpowiadać rzeczywistym uprawnieniom loginu, bez wykonywania operacji modyfikujących dane.

Jeżeli po ustawieniu master logowanie działa, a próba przełączenia do właściwej bazy nadal kończy się błędem lub komunikatem o braku dostępu, przyczyną jest najczęściej stan bazy, brak użytkownika mapowanego do loginu albo nieprawidłowy SID. W takim przypadku trzeba przeanalizować wpisy w dzienniku SQL Server, stan bazy w sys.databases oraz mapowanie loginu i użytkownika. W środowisku produkcyjnym każdą zmianę należy odnotować, ponieważ domyślna baza wpływa na zachowanie aplikacji, skryptów i narzędzi administracyjnych korzystających z tego loginu.

Przy diagnostyce na komputerze lub serwerze należy rozdzielić problem silnika SQL Server od problemu konkretnego klienta. Jeżeli połączenie do master działa w jednym narzędziu, a aplikacja nadal zgłasza Error 4064, trzeba sprawdzić jej parametry połączenia, nazwę instancji, wskazaną bazę oraz sposób uwierzytelniania. Jeżeli błąd występuje niezależnie od klienta, większe znaczenie ma konfiguracja loginu, stan bazy i uprawnienia po stronie instancji SQL Server.