Nasza usługa SQL Server nie działała dziś rano, co spowodowało uszkodzenie niektórych naszych stron internetowych. Kiedy poszedłem sprawdzić Podgląd zdarzeń systemu Windows, zobaczyłem następujące błędy:
Aktualizacja poziomu skryptu dla bazy danych „master” nie powiodła się, ponieważ krok aktualizacji „SSIS_hotfix_install.sql” napotkał błąd 942, stan 4, dotkliwość 25
Nie można odzyskać głównej bazy danych. Nie można uruchomić programu SQL Server. Przywróć wzorzec z pełnej kopii zapasowej, napraw ją lub odbuduj. Aby uzyskać więcej informacji o tym, jak odbudować główną bazę danych, zobacz Książki SQL Server Online.
Pierwszą rzeczą, którą zrobiłem, było Google, aby błędy. W końcu znalazłem wpis na forum z dokładnym problemem i jego rozwiązaniem (również na blogu, w którym szukam rozwiązania ). Problem ma coś wspólnego z grupami AlwaysOn Availability, a poprawka wymaga:
Uruchom usługę SQL Server z flagą śledzenia 902:
Net Start MSSQL $ InstanceName / T902
Otwórz SQL Server Management Studio, przejdź do grupy dostępności i usuń SSISDB z baz danych dostępności
Otwórz nowe zapytanie, uruchom skrypt SSIS_hotfix_install.sql, który można znaleźć w folderze Instaluj w folderze \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQL $ InstanceName \ MSSQL
Zatrzymaj usługi SQL Server:
Net Stop MSSQL $ InstanceName
Uruchom usługę serwera SQL z menedżera konfiguracji programu SQL Server
Dodaj SSISDB z powrotem do grupy dostępności
Nie udało mi się jednak przejść obok kroku 2, ponieważ podczas próby rozszerzenia folderu „AlwaysOn High Availability” wystąpił następujący błąd:
Funkcja „AlwaysOn” musi być włączona dla instancji serwera „InstanceName”, aby można było utworzyć grupę dostępności w tej instancji.
Następnie wykonałem instrukcje, aby przejść do „SQL Server Configuration Manager” i karty „AlwaysOn High Availability”, aby włączyć tę funkcję. Tym razem funkcja ta była wyszarzona i pojawił się komunikat informujący, że węzeł komputera nie znajduje się w klastrze pracy awaryjnej.
Moje pytanie brzmi:
Jak mogę rozwiązać ten problem, jeśli nie mamy nawet konfiguracji klastra pracy awaryjnej, która korzystałaby z tej funkcji?
Pobiegłem dbcc checkdbna mistrza; wyniki były:
CHECKDB znalazł 0 błędów alokacji i 0 błędów spójności w bazie danych „master”.
Grupa AlwaysOn Availability NIE jest włączona, ponieważ nie mam nawet klastra pracy awaryjnej.
źródło