co to jest Ostrzeżenie: Database < db-name> is SUSPECT? Prawdopodobnie widziałeś bazy danych oznaczone jako podejrzane w SSMS i nie wiesz, co to oznacza. Przeczytaj poniższy artykuł, aby dowiedzieć się więcej na ten temat!
co to jest Ostrzeżenie: Database db-name is SUSPECT?
czasami mamy do czynienia z sytuacją, która jest krytyczna, ze względu na to, że nasza baza danych SQL Server przechodzi w tryb podejrzany. W tym momencie baza danych nie może być już używana i nie można wykonać żadnej pracy.
głównym powodem, dla którego baza danych przechodzi w tryb podejrzany, jest to, że podstawowa grupa plików została uszkodzona, A bazy danych nie można odzyskać podczas uruchamiania serwera SQL.
ponadto baza danych może dostać się do stanu podejrzanego z wielu innych powodów, które mogą obejmować:
- błąd systemu, który może być spowodowany nieprawidłowym zamknięciem serwera bazy danych
- uszkodzony plik dziennika lub uszkodzony plik MDF
- w przypadku braku miejsca na dysku
- SQL Server nie jest w stanie wykonać operacji przewijania lub cofania
- ograniczenia miejsca na systemy plików FAT32 i inne przyczyny
aby naprawić bazę danych i odzyskać z tego stanu, musisz wykonać następujące kroki:
- zaczniemy od zmiany stanu bazy danych, wykonując procedurę składowaną sp_resetstatus
EXEC sp_resetstatus 'TestDB'
- Ustaw bazę danych na tryb „awaryjny”
ALTER DATABASE TestDB SET EMERGENCY;
- Sprawdź bazę danych pod kątem ewentualnych niespójności
DBCC checkdb ('TestDB');
- w przypadku napotkania jakichkolwiek błędów podczas fazy DBCC, natychmiast umieść bazę danych w trybie pojedynczego użytkownika za pomocą poniższego zapytania:
ALTER DATABASE TestDB SET SINGLE_USER with ROLLBACK IMMEDIATE;
- ponadto, w tym momencie, ze względów bezpieczeństwa zalecamy wykonanie kopii zapasowej bazy danych
- po zakończeniu tworzenia kopii zapasowej bazy danych należy przystąpić do uruchomienia następującego zapytania. Pamiętaj jednak, że podczas korzystania z następującego zapytania, z parametrem REPAIR_ALLOW_DATA_LOSS, wykonujesz operację jednokierunkową, która naprawi twoją bazę danych, ale wszystkie działania wykonane podczas tego procesu nie mogą zostać wycofane. Nie ma rozwiązania, aby wrócić do poprzedniego stanu bazy danych, dlatego zdecydowanie zalecamy wykonanie kopii zapasowej sugerowanej w poprzednim punkcie
DBCC CheckDB ('TestDB', REPAIR_ALLOW_DATA_LOSS);
- ostatnim zapytaniem, które powinieneś uruchomić, jest ustawienie bazy danych w tryb wielu użytkowników
ALTER DATABASE TestDB SET MULTI_USER;
- ostatnim krokiem jest odświeżenie serwera bazy danych i sprawdzenie, czy połączenie z bazą danych działa. Po tym momencie użytkownicy powinni mieć możliwość połączenia się z bazą danych. W przypadku utraty danych możesz przywrócić bazę danych, której wcześniej wykonałeś kopię zapasową