Serwisanci dostępni teraz · czynne całą dobę, także w weekendy i świętaWarszawa i okolice · dojazd bezpłatny
Darmowa diagnoza laptopa
Darmowa diagnoza laptopa
Dojazd do klienta bezpłatnie
Dojazd do klienta bezpłatnie
Laptopy zastępcze bezpłatnie
Laptopy zastępcze bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie
Odbiór i zwrot sprzętu bezpłatnie

Przejście z EMERGENCY do ONLINE

Termin Definicja
Przejście z EMERGENCY do ONLINE

Przejście z EMERGENCY do ONLINE następuje po skutecznej naprawie bazy, przywracając jej normalną dostępność.

Co oznacza stan EMERGENCY w SQL Server

EMERGENCY to awaryjny stan bazy danych w Microsoft SQL Server, używany wtedy, gdy baza została oznaczona jako podejrzana albo wystąpił problem uniemożliwiający jej normalne uruchomienie. W tym stanie dostęp do bazy jest ograniczony. SQL Server traktuje ją jako wymagającą diagnostyki, a operacje wykonywane przez administratora mają na celu ustalenie, czy da się odzyskać spójność struktur i danych.

Stan EMERGENCY nie jest zwykłym trybem pracy aplikacji. Nie oznacza również, że sama zmiana statusu na ONLINE naprawi uszkodzone strony danych, indeksy lub metadane. Przed wykonaniem zmian należy ustalić aktualny stan w widoku sys.databases, sprawdzić dziennik błędów SQL Server oraz potwierdzić, czy problem dotyczy pliku danych, pliku dziennika transakcji, braku miejsca, uprawnień, urządzenia dyskowego albo nieudanego procesu odzyskiwania.

Warunki powrotu bazy do stanu ONLINE

Przejście do ONLINE oznacza, że SQL Server uznał bazę za dostępną do normalnej pracy. W praktyce powinno ono nastąpić dopiero po ustaleniu przyczyny awarii i zakończeniu czynności odzyskiwania. Jeżeli baza pozostaje w EMERGENCY po usunięciu problemu infrastrukturalnego, administrator może użyć polecenia ALTER DATABASE [NazwaBazy] SET ONLINE;. Polecenie wymaga odpowiednich uprawnień i nie powinno być traktowane jako zamiennik kontroli spójności.

Po zmianie stanu trzeba zweryfikować wynik w sys.databases, obserwować komunikaty SQL Server oraz wykonać kontrolę bazy poleceniem DBCC CHECKDB ([NazwaBazy]) WITH NO_INFOMSGS;. Kontrola powinna zakończyć się bez błędów integralności. Należy także sprawdzić, czy aplikacja może otworzyć połączenie, odczytać wymagane tabele i wykonać bezpieczną operację testową. Sama wartość ONLINE nie gwarantuje, że każda tabela, procedura lub relacja została poprawnie odzyskana.

Naprawa spójności przed odblokowaniem dostępu

Podstawową metodą przywracania bazy jest odzyskanie jej z poprawnej kopii zapasowej. Jest to rozwiązanie preferowane, ponieważ pozwala odtworzyć znany, spójny stan i ograniczyć ryzyko utraty danych. Przed próbą naprawy należy zabezpieczyć istniejące pliki oraz ustalić, jaki zakres zmian nastąpił od ostatniej pełnej, różnicowej lub dziennika transakcji kopii zapasowej. Jeżeli problem wynika z uszkodzenia dysku albo systemu plików, najpierw trzeba usunąć przyczynę sprzętową lub systemową.

Jeżeli odtworzenie kopii nie jest możliwe, DBCC CHECKDB może wskazać zalecany poziom naprawy. Opcja REPAIR_ALLOW_DATA_LOSS może usunąć uszkodzone elementy, aby przywrócić spójność struktur, ale jej użycie może spowodować utratę wierszy, stron lub innych danych. Nie należy uruchamiać jej bez analizy raportu, kopii zabezpieczającej i świadomej akceptacji skutków. Po naprawie wymagane są ponowne kontrole, weryfikacja kluczowych danych oraz sprawdzenie działania zależnych zadań, indeksów, procedur i aplikacji.

Kontrola po przywróceniu normalnej dostępności

Po przejściu z EMERGENCY do ONLINE administrator powinien potwierdzić, że baza jest nie tylko widoczna dla SQL Server, ale także użyteczna dla systemu, który z niej korzysta. Należy sprawdzić stan wszystkich plików bazy, dostępne miejsce, autogrowth, stan dziennika transakcji i ostatnie komunikaty dotyczące odzyskiwania. Warto również przeanalizować, czy nie pozostały oczekujące transakcje, błędy wejścia-wyjścia lub problemy z połączeniami.

Test aplikacyjny powinien obejmować co najmniej logowanie, odczyt reprezentatywnych danych oraz kontrolowaną operację zapisu, jeżeli jest to bezpieczne i zgodne z procedurą. Po potwierdzeniu poprawności należy wykonać nową kopię zapasową i udokumentować przyczynę awarii, zastosowane polecenia oraz wynik kontroli DBCC CHECKDB. Jeżeli błędy spójności nadal występują, pozostawienie bazy w ONLINE może tylko ukryć problem przed użytkownikami i doprowadzić do dalszego uszkodzenia danych. W takim przypadku potrzebna jest ponowna analiza logów, kopii zapasowych i warstwy pamięci masowej.

+48 22 100 48 29Zadzwoń teraz · serwisant w 1 godzinę