Error 4060 – nie można otworzyć bazy danych

Error 4060 oznacza, że serwer SQL nie mógł otworzyć wskazanej bazy danych podczas próby połączenia.

Mechanizm autoryzacji i techniczne podłoże błędu 4060

Błąd o sygnaturze 4060 w środowisku Microsoft SQL Server to specyficzny komunikat zwracany przez warstwę sieciową silnika relacyjnego, najczęściej podczas fazy nawiązywania sesji poprzez protokół Tabular Data Stream (TDS). Architektura uprawnień w systemach MS SQL opiera się na dwupoziomowym modelu zabezpieczeń. Pierwszym poziomem jest instancja serwera, gdzie uwierzytelniane są konta dostępowe, czyli loginy (SQL Server Logins lub zintegrowane konta Windows). Drugim poziomem jest konkretna baza danych, w której dany login musi posiadać zmapowanego użytkownika (Database User). Komunikat 4060 jest generowany dokładnie w momencie, gdy uwierzytelnienie na poziomie instancji, czyli weryfikacja hasła lub tokenu Kerberos, przebiegło pomyślnie, lecz serwer odrzuca żądanie dostępu do docelowej bazy danych. Wynika to z faktu, że konto, z którego inicjowane jest połączenie, nie posiada rekordu w tabeli systemowej sys.database_principals wewnątrz żądanej bazy, brakuje mu odpowiednich uprawnień do nawiązania sesji, takich jak bezpośrednie uprawnienie CONNECT, lub sama baza znajduje się w stanie uniemożliwiającym przetworzenie żądania wejścia-wyjścia. Proces łączenia aplikacji klienckich zazwyczaj opiera się na ciągach połączeniowych, w których parametr Initial Catalog wskazuje konkretny kontener danych. Silnik bazy, po zweryfikowaniu tożsamości klienta, próbuje wykonać niejawną instrukcję USE dla wskazanego zasobu. Jeśli instrukcja ta zakończy się niepowodzeniem z powodu braku autoryzacji lub lokalnej niedostępności zasobu, warstwa kliencka otrzymuje omawiany błąd opatrzony poziomem ważności 11 (severity level 11). W nomenklaturze SQL Servera ten poziom klasyfikacji incydentu oznacza problem konfiguracyjny będący w gestii administratora kont, a nie wewnętrzną awarię jądra bazy lub procesów pamięci.

Scenariusze występowania i zjawisko osieroconych użytkowników

Zdecydowanie najczęstszą przyczyną występowania błędu 4060 jest zjawisko osieroconych użytkowników (orphaned users). Sytuacja ta ma miejsce w procesach przenoszenia baz danych pomiędzy różnymi instalacjami serwerowymi, co powszechnie występuje podczas odtwarzania kopii zapasowej z pliku .bak lub ręcznego podłączania struktury plików przy użyciu procedur systemowych. Użytkownicy wewnątrz bazy danych są powiązani z loginami na poziomie głównej instancji za pomocą unikalnych identyfikatorów bezpieczeństwa (SID). Kiedy baza zostaje przeniesiona na nową maszynę, loginy tam utworzone otrzymują nowe, generowane systemowo wartości SID, nawet jeśli ich nazwy literowe są identyczne z oryginalnymi z maszyny źródłowej. W efekcie wewnętrzne powiązanie kryptograficzne zostaje zerwane. System autoryzacji traktuje próbę połączenia jako nieautoryzowaną i zwraca błąd 4060. Kolejnym powszechnym scenariuszem jest brak definicji domyślnej bazy danych dla weryfikowanego loginu. Jeśli w konfiguracji konta na serwerze przypisano bazę domyślną, która została trwale usunięta lub dostęp do niej został administracyjnie zablokowany, jakakolwiek próba połączenia, w której aplikacja kliencka jawnie nie wskaże alternatywego i dostępnego zasobu, zakończy się odrzuceniem sesji i komunikatem błędu. Odmowa dostępu bywa również wynikiem celowej rekonfiguracji samej bazy, na przykład ustawienia jej w tryb SINGLE_USER celem wykonania operacji serwisowych. Gdy do bazy jest już podłączony jeden klient i wykorzystuje jedyną dostępną sesję, każda kolejna próba autoryzacji z innego wątku skutkuje błędem 4060. W środowiskach developerskich i produkcyjnych administratorzy diagnozują tego typu odrzucenia za pomocą mechanizmu Extended Events, badając pakiety logowania, co pozwala na analityczne odróżnienie problemów z weryfikacją SID od rzeczywistego usunięcia konta z grupy autoryzacyjnej.

Metody diagnostyki po stronie silnika relacyjnego

Rozwiązywanie problemu zasygnalizowanego kodem 4060 wymaga zastosowania interfejsów klienckich wyższego poziomu, takich jak SQL Server Management Studio (SSMS) lub narzędzi wiersza poleceń typu sqlcmd. Pierwszym krokiem diagnostycznym jest wymuszenie połączenia na czystej systemowej bazie master, która pozostaje zawsze dostępna dla lokalnych administratorów. W tym celu w oknie parametrów logowania SSMS należy uruchomić zakładkę właściwości zaawansowanych i jawnie zadeklarować bazę master w polu docelowego kontenera. Pozwala to całkowicie pominąć fazę weryfikacji uszkodzonego kontenera docelowego. Po uzyskaniu autoryzacji na poziomie instancji, administrator uruchamia kwerendy systemowe weryfikujące status baz w widoku sys.databases. Z punktu widzenia rekonfiguracji oprogramowania, jeśli baza danych figuruje pod statusem ONLINE, procesem naprawczym jest aktualizacja tabeli mapowania identyfikatorów. We współczesnych wersjach MS SQL operację tę wykonuje się instrukcją T-SQL, w której modyfikuje się definicję użytkownika, przypisując mu na nowo login serwerowy. Takie działanie asynchronicznie synchronizuje wskaźniki wewnątrz przeniesionej bazy z metadanymi instancji, trwale rozwiązując konflikt tożsamości. Jeśli mechanizmem wejściowym jest uwierzytelnianie Active Directory, diagnostyce podlegają tabele grup zabezpieczeń (GPO) oraz poprawne rozwiązywanie ról domenowych przez kontroler sieci, co może opóźniać proces logowania do momentu przekroczenia czasu oczekiwania. W środowiskach lokalnych, błąd ten jest regularnie rejestrowany przez programistów testujących i kompilujących aplikacje na wbudowanych silnikach SQL Express lub LocalDB. Najczęstszym krokiem naprawczym jest w ich przypadku inspekcja pliku appsettings.json w aplikacjach opartych o ramy .NET i weryfikacja flag bezpieczeństwa zintegrowanego wewnątrz łańcucha TDS.

Diagnoza sprzętowa w kontekście korupcji struktury plików

Problemy z uprawnieniami MS SQL Server, ze względu na swój profil, należą do inżynierii systemów bazodanowych. Obsługa tych systemów znajduje się w centrach danych oraz w architekturze chmurowej, co całkowicie wykracza poza kompetencje warsztatów zajmujących się elektroniką konsumencką. Niemniej jednak, istnieje specyficzny scenariusz, w którym błąd 4060 jest objawem krytycznej awarii fizycznej stacji roboczej, z którą można spotkać się w serwisie. Dzieje się tak, gdy środowisko deweloperskie funkcjonuje na lokalnym komputerze przenośnym, a błąd odmowy dostępu do bazy wynika ze stanu SUSPECT, spowodowanego degradacją komórek pamięci na dysku SSD lub uszkodzeniem mechanicznym wewnątrz dysku HDD. Skutkuje to automatycznym zablokowaniem autoryzacji dla wszystkich aplikacji klienckich na danej maszynie. Dalsza ingerencja poprzez skrypty naprawcze w takim wypadku narazi dane na nadpisanie. W takich okolicznościach interwencja musi skupić się na warstwie sprzętowej. Warszawskie Pogotowie Komputerowe świadczy w takich sytuacjach usługi odzysku fizycznego, realizując niskopoziomowe kopie binarne całego nośnika z pominięciem uszkodzonych transakcji sprzętowych kontrolera dysku. Praca serwisu opiera się na wyizolowaniu integralnych fizycznie plików MDF z martwego sektora dysku klienta. Po pomyślnym przekopiowaniu struktury danych na nowy nośnik półprzewodnikowy i zainstalowaniu go w komputerze, zadaniem użytkownika jest ponowne wdrożenie środowiska bazodanowego i wykonanie procedury podłączenia plików (attach) do nowej instancji programu MS SQL, co finalnie naprawia dostępność bazy.