Odzyskiwanie bazy model przywraca wzorzec dla nowo tworzonych baz — jej uszkodzenie uniemożliwia start instancji.
Rola bazy model w SQL Server
Baza model jest systemową bazą danych programu Microsoft SQL Server i pełni funkcję wzorca używanego podczas tworzenia nowych baz. Jej struktura, ustawienia oraz obiekty zapisane w momencie utworzenia bazy są punktem wyjścia dla nowej bazy użytkownika. Dotyczy to między innymi podstawowych właściwości bazy, takich jak ustawienia wzrostu plików, model odzyskiwania, sortowanie ustalone przy tworzeniu oraz początkowy układ plików danych i dziennika transakcji.
Każda baza utworzona poleceniem CREATE DATABASE jest tworzona na podstawie systemowego wzorca. Z tego powodu uszkodzenie bazy model może powodować błędy podczas tworzenia nowych baz, nawet jeśli istniejące bazy użytkownika nadal są dostępne. W określonych przypadkach problem z plikami systemowej bazy lub jej metadanymi może również uniemożliwić prawidłowe uruchomienie instancji SQL Server, ponieważ silnik podczas startu musi otworzyć i zweryfikować systemowe bazy danych.
Objawy uszkodzenia i zakres rozpoznania
Typowym objawem jest nieudane uruchomienie usługi SQL Server albo zatrzymanie jej krótko po rozpoczęciu startu. W dzienniku błędów SQL Server mogą pojawić się informacje o niemożności otwarcia pliku bazy, błędach odczytu stron, niezgodności plików, problemie z lokalizacją pliku lub konieczności odtworzenia bazy systemowej. Sam komunikat o błędzie nie przesądza jeszcze, że uszkodzona jest właśnie baza model. Podobne symptomy mogą powodować problemy z bazą master, bazą msdb, uprawnieniami do katalogu, woluminem dyskowym albo brakiem miejsca.
Rozpoznanie powinno obejmować identyfikację instancji i jej wersji, odczyt dziennika błędów SQL Server, sprawdzenie konfiguracji ścieżek systemowych baz oraz weryfikację dostępności plików model.mdf i modellog.ldf. Należy odróżnić uszkodzenie logiczne od problemu infrastrukturalnego. Błąd wejścia-wyjścia, uszkodzony system plików lub niesprawny dysk może ponownie uszkodzić odtworzoną bazę, dlatego przed naprawą sprawdza się również stan nośnika i możliwość wykonania kopii plików.
Jeżeli instancja uruchamia się wystarczająco długo, można sprawdzić stan systemowych baz w widokach katalogowych, a następnie wykonać kontrolę integralności odpowiednim poleceniem DBCC. W przypadku bazy systemowej zakres i kolejność czynności zależą od tego, czy dostępna jest poprawna kopia zapasowa, czy zachowały się pliki bazy oraz czy problem dotyczy wyłącznie model, czy całego zestawu baz systemowych.
Odtwarzanie wzorca i odbudowa baz systemowych
Najbardziej przewidywalną metodą jest przywrócenie bazy model z poprawnej kopii zapasowej wykonanej dla tej samej instancji i zgodnej wersji SQL Server. Przywracanie bazy systemowej wymaga zatrzymania zwykłej pracy instancji, odpowiedniego uruchomienia silnika oraz zachowania kolejności wymaganej przez SQL Server. Przed rozpoczęciem należy zabezpieczyć istniejące pliki, ustalić ich lokalizację i sprawdzić, czy kopia zapasowa nie pochodzi z innej wersji lub innej konfiguracji, ponieważ niezgodność może uniemożliwić otwarcie bazy.
Gdy kopia zapasowa nie istnieje albo pliki systemowe są niekompletne, stosuje się procedurę odbudowy systemowych baz danych dostarczaną przez instalator SQL Server. W instalatorze używa się akcji /ACTION=REBUILDDATABASE, podając parametry właściwe dla konkretnej instancji, takie jak nazwa instancji, konto usługi, hasło konta administratora oraz lokalizacje plików. Odbudowa tworzy nowe, domyślne bazy systemowe, w tym master, model i msdb. Operacja nie jest zamiennikiem przywrócenia danych użytkownika i może usunąć wcześniejsze ustawienia oraz obiekty zapisane w bazach systemowych.
Po przywróceniu lub odbudowie trzeba ponownie uruchomić usługę, przeanalizować dziennik błędów i sprawdzić, czy można utworzyć testową bazę za pomocą CREATE DATABASE. Następnie należy zweryfikować właściwości nowej bazy, dostępność ścieżek plików, ustawienia wzrostu oraz możliwość wykonania kopii zapasowej. Jeżeli odbudowano także inne bazy systemowe, konieczne może być odtworzenie loginów, zadań SQL Server Agent, konfiguracji, uprawnień i pozostałych elementów zapisanych wcześniej w tych bazach.
Kontrola po odzyskaniu bazy model
Odzyskanie bazy model należy uznać za zakończone dopiero po sprawdzeniu rzeczywistego przepływu tworzenia bazy, a nie tylko po pomyślnym uruchomieniu usługi. Test powinien obejmować utworzenie tymczasowej bazy, kontrolę jej plików danych i dziennika, sprawdzenie parametrów odzyskiwania oraz usunięcie obiektu testowego zgodnie z przyjętą procedurą. Warto również potwierdzić, że nowe bazy otrzymują oczekiwane ustawienia i że nie są dziedziczone przypadkowe obiekty lub parametry pozostałe po błędnej kopii.
Wynik prac powinien zostać opisany wraz z wersją i edycją SQL Server, nazwą instancji, lokalizacją plików, źródłem kopii zapasowej, zastosowaną metodą oraz komunikatami z dziennika błędów. Należy zachować kopię plików przed naprawą i odnotować, czy przeprowadzono odbudowę baz systemowych. Jeżeli przyczyną była awaria nośnika, sama naprawa logiczna nie usuwa ryzyka ponownego uszkodzenia. W takim przypadku potrzebna jest dodatkowa weryfikacja warstwy dyskowej, wolnego miejsca i poprawności wykonywania kopii zapasowych.
Prace przy bazie model wymagają dostępu administracyjnego do instancji oraz ostrożności, ponieważ jest to element infrastruktury SQL Server, a nie zwykła baza aplikacyjna. Błędne nadpisanie plików, użycie niezgodnej kopii lub uruchomienie odbudowy bez zabezpieczenia konfiguracji może rozszerzyć zakres awarii. Dlatego przed zmianą zapisuje się stan wyjściowy, a po zmianie wykonuje kontrolowany test uruchomienia i tworzenia nowej bazy.
