Microsoft SQL Server

SQL Server 2012 – rola środowiska bazodanowego

Microsoft SQL Server 2012 jest systemem zarządzania relacyjnymi bazami danych przeznaczonym do przechowywania, porządkowania i udostępniania informacji aplikacjom. W praktyce może współpracować z programami magazynowymi, księgowymi, sprzedażowymi, kadrowymi oraz z oprogramowaniem tworzonym na potrzeby konkretnej organizacji. Baza danych nie jest zwykłym plikiem, który można bezpiecznie przenieść lub zastąpić dowolną kopią. Na jej działanie wpływają między innymi struktura plików, dziennik transakcji, uprawnienia systemowe, konfiguracja instancji, stan nośnika i sposób zamykania systemu Windows.

Wersja SQL Server 2012 wprowadziła rozwiązania poprawiające pracę z dużymi zbiorami danych. Należą do nich między innymi indeksy kolumnowe, usprawnienia w analizie danych, contained databases, środowisko SQL Server Data Tools oraz funkcje wyszukiwania semantycznego. Nie oznacza to jednak, że sama instalacja gwarantuje bezproblemową pracę. Usterka dysku, brak wolnej przestrzeni, nieprawidłowa aktualizacja systemu, błędna konfiguracja usługi albo nagłe odcięcie zasilania mogą doprowadzić do utraty dostępu do bazy.

Ważne jest odróżnienie problemu z samym silnikiem SQL Server od awarii programu, który korzysta z bazy. Jeżeli aplikacja sprzedażowa nie uruchamia się, przyczyną może być zatrzymana usługa SQL Server, uszkodzony plik danych, niedostępny komputer w sieci lub błąd po stronie aplikacji. Dlatego naprawa powinna rozpoczynać się od zebrania objawów i sprawdzenia stanu całego komputera, a nie od przypadkowego usuwania plików lub ponownej instalacji.

SQL Server 2012 – typowe objawy awarii instancji

Problemy z SQL Server 2012 mogą pojawić się podczas uruchamiania programu, logowania użytkownika, wykonywania raportu albo zapisywania nowej operacji. Czasem awaria jest wyraźna i usługa nie startuje. W innych przypadkach baza działa, lecz odpowiedzi są bardzo wolne, zapytania kończą się błędami lub użytkownicy tracą połączenie w trakcie pracy.

• aplikacja zgłasza brak połączenia z serwerem bazy danych;
• usługa SQL Server zatrzymuje się zaraz po uruchomieniu;
• pojawiają się komunikaty o przekroczeniu czasu oczekiwania;
• baza ma stan Recovery Pending, Suspect albo Emergency;
• odczyt danych działa, lecz zapis nowych informacji kończy się niepowodzeniem;
• po restarcie komputera trwa bardzo długo proces odzyskiwania bazy;
• SQL Server Browser nie wykrywa nazwanej instancji w sieci lokalnej;
• połączenie działa z jednego komputera, ale nie działa z innej stacji;
• raporty i zapytania wykonują się znacznie wolniej niż wcześniej;
• w dzienniku pojawiają się błędy wejścia i wyjścia, blokad lub braku miejsca.

Stan Recovery Pending zwykle oznacza, że silnik wie o potrzebie odzyskiwania bazy, ale nie może rozpocząć albo dokończyć wymaganych działań. Stan Suspect jest poważniejszy, ponieważ wskazuje, że baza nie została poprawnie udostępniona. Nie powinno się zmieniać tych stanów poleceniami znalezionymi przypadkowo w internecie. Działania naprawcze wykonane bez kopii zabezpieczającej mogą utrudnić późniejsze odzyskanie danych.

Warto także zwrócić uwagę na moment występowania problemu. Błąd pojawiający się wyłącznie po uruchomieniu komputera może mieć związek z kolejnością startu usług lub opóźnionym dostępem do dysku. Awaria występująca podczas dużego raportu może wskazywać na brak zasobów, przeciążenie nośnika, nieaktualne statystyki lub nieefektywny plan wykonania. Powtarzające się rozłączenia w czasie zapisu wymagają sprawdzenia zarówno bazy, jak i sprzętu.

SQL Server 2012 – pliki MDF, NDF i LDF

Podstawowe dane bazy SQL Server są przechowywane w plikach danych. Plik MDF jest głównym plikiem bazy, natomiast pliki NDF mogą zawierać dodatkowe obszary danych. Plik LDF pełni funkcję dziennika transakcji. Rejestruje operacje, które powinny zostać wykonane lub cofnięte, dzięki czemu silnik może odtworzyć spójność po nieoczekiwanym zamknięciu systemu.

Plik dziennika nie jest zwykłą kopią pliku MDF. Jego usunięcie, wyzerowanie albo mechaniczne zmniejszenie bez zrozumienia modelu odzyskiwania może doprowadzić do utraty możliwości odtworzenia ostatnich transakcji. Podobne ryzyko wiąże się z podmianą pliku danych na starszą wersję. Nawet jeśli baza zacznie się uruchamiać, część informacji może być niespójna z aplikacją lub z innymi plikami tej samej bazy.

Przed rozpoczęciem naprawy należy ustalić lokalizację wszystkich plików, ich rozmiary oraz daty modyfikacji. Pomocne jest porównanie tej informacji z konfiguracją instancji i z dokumentacją kopii zapasowych. Nie należy przenosić plików MDF, NDF ani LDF na inny nośnik, kiedy trwa aktywna operacja odzyskiwania. Jeżeli dysk wydaje nietypowe dźwięki, system zawiesza się podczas odczytu lub pojawiają się błędy wejścia i wyjścia, priorytetem staje się zabezpieczenie danych, a nie wielokrotne próby uruchamiania usługi.

SQL Server 2012 – najczęstsze przyczyny problemów

Awaria bazy może wynikać z kilku nakładających się przyczyn. Jedną z najczęstszych jest pogarszający się stan dysku. Uszkodzone sektory na dysku HDD albo zużycie komórek pamięci w SSD powodują błędy odczytu i zapisu. Jeżeli uszkodzeniu ulegnie strona zawierająca dane, indeks lub element struktury systemowej, silnik może zgłosić problem z integralnością bazy.

Drugą grupę przyczyn stanowi brak wolnej przestrzeni. Dotyczy to nie tylko miejsca na pliki danych, lecz także miejsca potrzebnego na rozrost dziennika transakcji, pliki tymczasowe, pliki systemowe i operacje odzyskiwania. Zapełniony wolumin może sprawić, że usługa przestanie przyjmować nowe transakcje, mimo że sam komputer nadal się uruchamia.

Ryzyko zwiększają nagłe zaniki zasilania, wymuszone restarty i wyłączanie komputera podczas zapisu. SQL Server posiada mechanizmy odzyskiwania, lecz nie zastępują one kopii zapasowej ani sprawnego sprzętu. Nieprawidłowo działająca pamięć RAM również może powodować trudne do powtórzenia błędy. Warto brać ją pod uwagę, szczególnie gdy uszkodzenia pojawiają się w różnych miejscach bazy albo towarzyszą im zawieszenia systemu.

Problemy mogą również wynikać z konfiguracji Windows. Usługa może działać na innym koncie niż wcześniej, utracić uprawnienia do katalogu z plikami danych albo zostać zablokowana przez oprogramowanie ochronne. Program antywirusowy powinien być skonfigurowany z uwzględnieniem plików i procesów SQL Server. Nie oznacza to wyłączania ochrony bez kontroli, lecz sprawdzenie, czy skanowanie nie przerywa operacji na aktywnych plikach.

SQL Server 2012 – diagnostyka bez pogarszania sytuacji

Diagnostyka powinna zaczynać się od zebrania informacji, zanim zostaną wykonane jakiekolwiek polecenia naprawcze. Należy zanotować dokładny komunikat, godzinę wystąpienia problemu, nazwę instancji oraz czynność, podczas której pojawiła się awaria. Przydatne są dzienniki SQL Server, Podgląd zdarzeń systemu Windows i informacje o ostatnim poprawnym uruchomieniu aplikacji.

W dzienniku błędów można znaleźć informacje o zatrzymaniu usługi, problemach z plikami, błędach autoryzacji, braku miejsca oraz błędach odczytu. Kody 823, 824 i 825 są sygnałem, że trzeba dokładnie sprawdzić podsystem dyskowy. Nie należy traktować ich wyłącznie jako problemu programowego. Jeżeli przyczyną jest fizycznie uszkodzony nośnik, kolejne intensywne odczyty mogą pogorszyć jego stan.

Następnie sprawdza się status usług, konto używane przez instancję, lokalizację plików, dostępne miejsce i możliwość połączenia lokalnego. W przypadku połączeń sieciowych weryfikuje się nazwę komputera, instancji, protokoły TCP/IP, zaporę oraz działanie SQL Server Browser. Trzeba odróżnić błąd sieci od błędu silnika. Jeżeli połączenie lokalne działa, a zdalne nie, przyczyny należy szukać między innymi w konfiguracji komunikacji.

Do oceny integralności używa się procedur DBCC CHECKDB, ale ich uruchomienie powinno być poprzedzone analizą stanu nośnika i dostępnych kopii. Wynik takiego sprawdzenia może wskazać uszkodzone strony, problemy z alokacją, niespójne indeksy lub błędy struktur systemowych. Polecenie naprawcze z opcją REPAIR_ALLOW_DATA_LOSS nie powinno być pierwszym wyborem. Sama nazwa wskazuje, że w pewnych sytuacjach naprawa może usunąć elementy, których nie da się poprawnie odtworzyć.

SQL Server 2012 – diagnostyka spowolnienia działania

Nie każda awaria objawia się całkowitym zatrzymaniem usługi. Częstym problemem jest stopniowe spowolnienie aplikacji. W takim przypadku sprawdza się czas wykonania zapytań, blokady transakcyjne, oczekiwanie na operacje dyskowe, zużycie pamięci oraz obciążenie procesora. Pomocne mogą być dynamiczne widoki zarządzania, między innymi sys.dm_exec_requests i sys.dm_os_wait_stats, jednak ich interpretacja wymaga uwzględnienia konfiguracji konkretnej instancji.

Długie oczekiwanie na zasoby nie zawsze oznacza uszkodzenie bazy. Przyczyną może być zapytanie skanujące całą tabelę, nieaktualne statystyki, brak właściwego indeksu, nadmierna liczba jednoczesnych operacji lub blokada pozostawiona przez aplikację. Warto sprawdzić plan wykonania zapytania, lecz nie należy dodawać indeksów automatycznie na podstawie pojedynczego podpowiedzenia. Każdy indeks zwiększa także koszt zapisu i może powodować dodatkowe obciążenie.

Ważne jest sprawdzenie, czy spowolnienie dotyczy całej instancji, jednej bazy, konkretnego użytkownika czy tylko pojedynczego raportu. Jeżeli wszystkie programy korzystające z komputera działają wolniej, podejrzenie może paść na dysk, pamięć, temperaturę podzespołów lub procesy systemowe. Jeżeli problem dotyczy wyłącznie jednej operacji, większe znaczenie może mieć jej konstrukcja, blokada albo zmiana ilości danych.

SQL Server 2012 – bezpieczny przebieg naprawy

Naprawa powinna być dopasowana do przyczyny i poprzedzona zabezpieczeniem materiału źródłowego. Jeśli nośnik jest sprawny, tworzy się kopię plików oraz dostępnych kopii zapasowych, zachowując oryginalny stan. Jeśli nośnik wykazuje błędy, korzystniejsze może być wykonanie kopii sektorowej na sprawny dysk, o ile pozwala na to jego stan. Próby naprawy na oryginale zwiększają ryzyko bezpowrotnej utraty informacji.

W przypadku problemu z usługą sprawdza się konfigurację instancji, konto usługi, uprawnienia do katalogów oraz zależności systemowe. Po usunięciu oczywistej przyczyny można wykonać kontrolowany restart i sprawdzić logi. Jeżeli problem dotyczy połączenia, analizuje się protokoły, porty, zaporę oraz nazwę instancji. Sama ponowna instalacja SQL Server nie jest uniwersalnym rozwiązaniem. Może pozostawić przyczynę bez zmian, a w niektórych sytuacjach utrudnić dostęp do istniejących plików.

Jeśli baza uruchamia się, ale zgłasza niespójność, wykonuje się kontrolę integralności i porównuje wynik z kopią zapasową. Najbezpieczniejszym sposobem odzyskania danych jest zwykle odtworzenie sprawnej kopii, a następnie zastosowanie dostępnych kopii różnicowych i dziennika transakcji zgodnie z przyjętym modelem zabezpieczeń. Jeżeli kopii nie ma, zakres możliwego odzysku zależy od stanu plików oraz od rodzaju uszkodzeń.

Po naprawie należy sprawdzić nie tylko możliwość uruchomienia usługi, lecz także działanie aplikacji, odczyt i zapis danych, raporty, konta użytkowników oraz komunikację z innymi stanowiskami. Warto również ustalić przyczynę pierwotną. Przywrócenie dostępu do bazy bez usunięcia problemu z dyskiem, zasilaniem lub brakiem miejsca może doprowadzić do powtórnej awarii.

SQL Server 2012 – kiedy zgłosić komputer do serwisu

Do serwisu warto zgłosić komputer, gdy usługa nie uruchamia się mimo prawidłowej konfiguracji, baza przechodzi w stan Suspect, pojawiają się błędy wejścia i wyjścia albo aplikacja przestaje zapisywać dane. Pomoc jest szczególnie potrzebna wtedy, gdy na komputerze znajdują się jedyne dostępne dane, a nie ma sprawdzonej kopii zapasowej. W takiej sytuacji dalsze samodzielne próby mogą zmienić strukturę plików i ograniczyć możliwości odzysku.

W Warszawie diagnostykę problemów z komputerem, na którym działa SQL Server 2012, można zlecić firmie Warszawskie Pogotowie Komputerowe 24/7. Przy zgłoszeniu warto przekazać nazwę instancji, treść komunikatów, informacje o ostatniej poprawnej pracy, opis wykonywanych zmian oraz dane dotyczące kopii zapasowych. Nie należy wysyłać plików bazy przez przypadkowe kanały ani udostępniać haseł bez ustalenia bezpiecznego sposobu pracy.

Przed rozpoczęciem czynności powinno zostać ustalone, czy priorytetem jest szybkie przywrócenie działania aplikacji, ochrona danych, odzyskanie części informacji czy analiza przyczyny awarii. Te cele mogą wymagać innej kolejności działań. Przy awarii nośnika najpierw chroni się dane. Przy błędzie sieciowym można skoncentrować się na konfiguracji połączenia. Przy spowolnieniu analizuje się obciążenie i zapytania, zamiast ingerować w pliki bazy.

SQL Server 2012 – kopie zapasowe i zapobieganie awariom

Najskuteczniejszą ochroną przed poważnymi skutkami awarii jest regularny, sprawdzony proces tworzenia kopii zapasowych. Sama obecność pliku kopii nie wystarcza. Trzeba sprawdzić, czy można go odtworzyć, czy obejmuje właściwą bazę oraz czy zawiera dane z oczekiwanego okresu. Kopie powinny być przechowywane w sposób ograniczający ryzyko utraty razem z komputerem, na którym znajduje się działająca instancja.

W zależności od potrzeb można stosować kopie pełne, różnicowe i kopie dziennika transakcji. Wybór zależy od modelu odzyskiwania, wielkości bazy, częstotliwości zmian oraz akceptowalnej utraty danych. Harmonogram powinien być opisany, a odpowiedzialność za kontrolę kopii jasno określona. Raz na jakiś czas należy przeprowadzić próbne odtworzenie w odseparowanym środowisku.

Równie istotne jest monitorowanie stanu dysków, wolnej przestrzeni, pamięci i dzienników błędów. Należy reagować na pierwsze ostrzeżenia, takie jak powtarzające się błędy odczytu, niekontrolowany wzrost pliku LDF, długotrwałe blokady i nieoczekiwane restarty. Aktualizacje systemu oraz składników SQL Server powinny być planowane, a przed większą zmianą warto wykonać i zweryfikować kopię zapasową.

SQL Server 2012 może nadal obsługiwać istniejące aplikacje, lecz wymaga świadomego zarządzania, kontroli bezpieczeństwa i dostosowania do środowiska, w którym pracuje. Rzeczowa diagnostyka, ochrona plików MDF, NDF i LDF oraz sprawdzony plan odtworzenia pozwalają ograniczyć skutki awarii. Gdy pojawia się podejrzenie uszkodzenia danych lub sprzętu, najbezpieczniejszym krokiem jest zatrzymanie przypadkowych zmian i przekazanie komputera do oceny technicznej.