| 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 ServerEMERGENCY 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 Warunki powrotu bazy do stanu ONLINEPrzejś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 Po zmianie stanu trzeba zweryfikować wynik w Naprawa spójności przed odblokowaniem dostępuPodstawową 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, Kontrola po przywróceniu normalnej dostępnościPo 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 |