Błąd podczas montowania bazy

Błąd podczas montowania bazy sygnalizuje niepowodzenie procesu udostępnienia struktury bazy danych przez silnik SQL Server.

Co oznacza błąd podczas montowania bazy w SQL Server

W SQL Server określenie „montowanie bazy” zwykle odnosi się do udostępnienia plików bazy danych przez instancję oraz przeprowadzenia operacji potrzebnych do otwarcia jej dla użytkowników. Dotyczy to między innymi dołączania istniejącej bazy za pomocą polecenia CREATE DATABASE ... FOR ATTACH, przywracania bazy z kopii zapasowej albo ponownego uruchamiania bazy po restarcie usługi. SQL Server korzysta przede wszystkim z pliku danych z rozszerzeniem .mdf, dodatkowych plików danych .ndf oraz pliku dziennika transakcji .ldf. Samo wskazanie pliku głównego nie wystarcza, jeżeli pozostałe pliki są wymagane, niedostępne albo niespójne.

Błąd pojawia się wtedy, gdy silnik nie może poprawnie otworzyć plików, odczytać ich struktury, odtworzyć zmian zapisanych w dzienniku transakcji lub przeprowadzić kontroli zgodności bazy z instancją SQL Server. W zależności od etapu operacji baza może pozostać w stanie RECOVERY_PENDING, SUSPECT, OFFLINE albo EMERGENCY. Komunikat z programu administracyjnego jest tylko skróconym opisem problemu; dokładniejszą przyczynę zwykle zawiera dziennik błędów SQL Server oraz dziennik zdarzeń systemu Windows.

Pliki MDF, NDF i LDF jako źródło problemu

Jedną z częstych przyczyn nieudanego dołączenia bazy jest brak dostępu do któregoś z plików. SQL Server musi mieć możliwość odczytu plików danych i zapisu do dziennika transakcji. Jeżeli plik został przeniesiony, zmieniła się jego ścieżka, udział sieciowy jest niedostępny albo konto usługi SQL Server nie ma odpowiednich uprawnień do folderu, operacja może zakończyć się błędem. Komunikat SQL Server o numerze 5120 wskazuje na problem z otwarciem pliku fizycznego. W takiej sytuacji należy sprawdzić pełną ścieżkę, istnienie każdego pliku wymienionego w metadanych bazy oraz uprawnienia systemu plików, bez ograniczania kontroli wyłącznie do pliku .mdf.

Problemy mogą wynikać również z uszkodzenia nagłówka pliku, niespójności metadanych lub nieprawidłowego zakończenia pracy instancji. Błąd 5173 jest związany z niezgodnością między plikami bazy, na przykład z nieprawidłowym zestawem plików dziennika. Błąd 945 oznacza, że baza nie może zostać otwarta z powodu problemów z dostępem do plików, niewystarczającej ilości pamięci lub innych ograniczeń uniemożliwiających uruchomienie bazy. Nie należy usuwać pliku .ldf ani tworzyć nowego dziennika bez rozpoznania sytuacji, ponieważ dziennik zawiera informacje potrzebne do odzyskiwania spójności transakcji.

Rozróżnienie błędu dostępu, odzyskiwania i niespójności

Pierwszym krokiem diagnostycznym jest odczytanie stanu bazy i komunikatów zapisanych przez silnik. Listę baz wraz ze stanami można uzyskać poleceniem SELECT name, state_desc, recovery_model_desc FROM sys.databases;. Informacje o plikach zarejestrowanych dla baz pokazuje widok sys.master_files, na przykład przez zapytanie SELECT DB_NAME(database_id), name, physical_name, state_desc FROM sys.master_files;. Dziennik błędów SQL Server można przeglądać procedurą sp_readerrorlog. Wpisy należy analizować razem z kodem błędu, nazwą pliku, ścieżką i czasem wystąpienia, ponieważ podobny komunikat ogólny może mieć różne przyczyny.

Jeżeli pliki są dostępne, a baza uruchamia się, lecz istnieje podejrzenie uszkodzenia logicznego, stosuje się polecenie DBCC CHECKDB, na przykład DBCC CHECKDB (NazwaBazy) WITH NO_INFOMSGS;. Wyniku tego polecenia nie należy utożsamiać z naprawą. DBCC CHECKDB kontroluje spójność struktur, ale nie przywraca automatycznie utraconych danych. Zalecaną metodą odzyskania poprawnej bazy jest przywrócenie sprawdzonej kopii zapasowej, z uwzględnieniem pełnej kopii, kopii różnicowych i dzienników transakcji, jeżeli taki łańcuch kopii istnieje. Opcje naprawcze, takie jak REPAIR_ALLOW_DATA_LOSS, mogą powodować utratę danych i wymagają wcześniejszego zabezpieczenia plików oraz świadomej oceny skutków.

Bezpieczne postępowanie przy niedostępnej bazie SQL Server

Przed zmianami należy ustalić, czy problem dotyczy samego SQL Server, systemu plików, konfiguracji ścieżek, uprawnień konta usługi, nośnika danych czy uszkodzenia zawartości. Warto zachować kopię plików .mdf, .ndf i .ldf w stanie zastanym oraz zanotować dokładne komunikaty z dziennika błędów. Jeżeli baza była przenoszona między instancjami, trzeba sprawdzić zgodność wersji SQL Server i sposób przeniesienia, ponieważ dołączanie plików nie zastępuje prawidłowego backupu i restore. Należy także odróżnić brak uprawnień do pliku od uszkodzenia danych: ponawianie operacji bez usunięcia przyczyny nie naprawia żadnego z tych problemów.

Diagnostyka baz SQL Server wymaga pracy na kopii lub na kontrolowanym środowisku, zwłaszcza gdy baza zawiera jedyne dostępne dane. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną diagnostykę i naprawę komputerów oraz podzespołów, natomiast w przypadku problemu z bazą konieczne jest przekazanie pełnych komunikatów SQL Server, informacji o sposobie utworzenia lub przeniesienia plików oraz danych o stanie nośnika. Takie informacje pozwalają rozdzielić awarię sprzętową od problemu z konfiguracją instancji i dobrać dalsze działanie bez pochopnego kasowania plików lub wymuszania naprawy, która mogłaby zmienić zawartość bazy.