Nieudana aktualizacja SQL Server

Nieudana aktualizacja SQL Server wymaga analizy logów w katalogu Setup Bootstrap, wskazujących nieudany krok instalacji.

Jak rozpoznać nieudaną aktualizację SQL Server

Nieudana aktualizacja SQL Server oznacza, że program instalacyjny nie zakończył poprawnie jednego lub kilku etapów zmiany istniejącej instancji. Aktualizacja może obejmować zmianę wersji silnika, zastosowanie dodatku Service Pack, instalację aktualizacji zbiorczej albo modyfikację wybranych składników instancji. Sam komunikat wyświetlony na końcu instalatora zwykle opisuje skutek, a nie rzeczywistą przyczynę problemu. Dlatego konieczne jest ustalenie, który krok zakończył się błędem i jaki warunek środowiska uniemożliwił jego wykonanie.

Podstawowym miejscem analizy są logi instalatora zapisywane w katalogu Setup Bootstrap. W systemie Windows znajdują się one w strukturze katalogu Microsoft SQL Server, najczęściej w podkatalogu Setup Bootstrap\Log. Dla każdej próby instalacji tworzony jest osobny katalog oznaczony datą lub znacznikiem czasu. W jego zawartości mogą znajdować się między innymi pliki Summary.txt i Detail.txt. Pierwszy z nich przedstawia skrócony wynik operacji oraz składniki, które zakończyły się powodzeniem lub błędem. Drugi zawiera bardziej szczegółowy przebieg działań instalatora, w tym uruchamiane akcje, kody zwrotne i komunikaty wyjątków.

Odczyt logów z katalogu Setup Bootstrap

Analizę warto rozpocząć od najnowszego katalogu odpowiadającego nieudanej próbie, a następnie porównać wpisy z plików podsumowania i szczegółowego przebiegu. W pliku Summary.txt należy odszukać nazwę instancji, aktualizowanego składnika oraz wynik poszczególnych reguł instalacyjnych. Szczególne znaczenie mają pozycje oznaczone jako nieudane, pominięte albo wymagające ponowienia. Jeżeli podsumowanie wskazuje tylko ogólny błąd instalacji, dokładniejsze informacje trzeba odszukać w Detail.txt oraz w logu przypisanym do konkretnego składnika.

Ważne jest odróżnienie logów instalatora od logów działania silnika. Plik ERRORLOG instancji SQL Server opisuje zdarzenia występujące podczas uruchamiania i pracy usługi bazy danych, natomiast logi Setup Bootstrap dokumentują proces instalacji lub aktualizacji. Jeżeli awaria nastąpiła podczas uruchamiania usługi po podmianie plików, potrzebne mogą być oba źródła: log instalatora pokaże etap, na którym wystąpił problem, a ERRORLOG może wskazać, dlaczego silnik nie wystartował. Wyszukiwanie pojedynczego słowa „error” bez uwzględnienia kolejności zdarzeń może prowadzić do błędnej diagnozy, ponieważ logi zawierają także ostrzeżenia, informacje o wycofaniu zmian i komunikaty dotyczące kontroli warunków wstępnych.

Przydatne jest ustalenie pierwszego błędu w czasie, a nie tylko ostatniego komunikatu. Późniejsze wpisy mogą być następstwem wcześniejszej awarii: jeżeli aktualizacja plików wspólnych nie powiedzie się, kolejne składniki mogą zostać pominięte, a instalator może rozpocząć procedurę wycofywania zmian. Wnioski powinny opierać się na nazwie akcji, składniku, kodzie zwrotnym oraz treści wyjątku. Sam fakt, że instalator zakończył pracę z błędem, nie przesądza jeszcze, czy przyczyną był brak uprawnień, niezgodność wersji, problem z usługą czy niewystarczająca ilość miejsca.

Najczęstsze przyczyny przerwania procesu aktualizacji

Jedną z grup przyczyn są niespełnione warunki wstępne. Aktualizacja może zostać zatrzymana przez oczekujący restart systemu, brak wymaganych składników Windows, niezgodną wersję systemu, zablokowane pliki albo aktywny proces korzystający z plików SQL Server. Znaczenie ma również dostępne miejsce na woluminie systemowym i na woluminie, na którym znajdują się pliki danych, logów transakcyjnych lub tymczasowe pliki instalatora. Brak miejsca może wystąpić dopiero podczas rozpakowywania pakietu albo tworzenia kopii roboczych, dlatego początkowe przejście kontroli nie wyklucza późniejszej awarii.

Problemy mogą dotyczyć także usług i uprawnień. Instalator musi mieć możliwość odczytu pakietu aktualizacyjnego, zapisu w katalogach systemowych oraz wykonania operacji związanych z usługą SQL Server. Jeżeli usługa jest zatrzymana w nieoczekiwanym stanie, konto używane przez usługę nie może uzyskać dostępu do wymaganych katalogów albo oprogramowanie zabezpieczające blokuje zmianę plików wykonywalnych, etap aktualizacji może zakończyć się niepowodzeniem. W logu należy sprawdzić, czy błąd wystąpił przy zatrzymywaniu usługi, kopiowaniu plików, wykonywaniu skryptów systemowych bazy danych czy ponownym uruchamianiu instancji.

Osobną kategorię stanowią niezgodności wersji i konfiguracji. Pakiet musi odpowiadać właściwej edycji, architekturze oraz obsługiwanej ścieżce aktualizacji danej instancji. Nie każdy składnik jest aktualizowany identycznie: silnik bazy danych, narzędzia klienckie, usługi pomocnicze i komponenty współdzielone mogą mieć odrębne wyniki. Jeżeli log wskazuje błąd podczas wykonywania skryptu aktualizującego systemowe bazy danych, ponowienie instalacji bez usunięcia przyczyny może pozostawić instancję w stanie wymagającym ostrożnego odtworzenia poprzedniej konfiguracji lub przeprowadzenia naprawy.

Postępowanie po zatrzymaniu aktualizacji

Po zabezpieczeniu logów należy zapisać dokładną wersję SQL Server przed próbą aktualizacji, wersję zastosowanego pakietu, nazwę instancji, godzinę rozpoczęcia oraz etap zakończony błędem. Warto zachować cały katalog logów z danej próby, ponieważ późniejsze uruchomienie instalatora może utworzyć nowy katalog i utrudnić powiązanie komunikatów z pierwszą awarią. Nie należy usuwać plików logów ani wykonywać kolejnych prób w sposób przypadkowy, zanim nie zostanie ustalone, czy problem dotyczył warunków wstępnych, dostępu do plików, usługi czy samego pakietu.

Jeżeli aktualizacja została wycofana, trzeba sprawdzić, czy instancja uruchamia się w stanie sprzed operacji oraz czy bazy danych są dostępne. Należy zweryfikować stan usługi, możliwość połączenia z instancją i obecność komunikatów o błędach w ERRORLOG. Gdy instalator pozostawił częściowo zmienione składniki, ponowienie operacji powinno być poprzedzone analizą dokumentacji dla konkretnej wersji SQL Server oraz pełną kopią zapasową baz danych. Nie wolno zakładać, że komunikat o pomyślnym wycofaniu zmian oznacza automatyczne przywrócenie każdego elementu konfiguracji.

W przypadku diagnostyki technicznej najważniejsze są: katalog logów z właściwej próby, plik Summary.txt, odpowiedni fragment Detail.txt, wersja instancji i pakietu oraz informacja o stanie usługi po awarii. Taki zestaw pozwala odtworzyć kolejność zdarzeń i oddzielić pierwotną przyczynę od komunikatów wtórnych. Przy pracy na komputerze należy także uwzględnić kopie zapasowe, wolne miejsce, oczekujące restarty i działające programy blokujące pliki, ponieważ wszystkie te elementy mogą zmienić wynik kolejnej próby aktualizacji.