Microsoft SQL Server

SQL Server 2014 – zakres zastosowania i najważniejsze możliwości

Microsoft SQL Server 2014 jest systemem zarządzania relacyjnymi bazami danych przeznaczonym do przechowywania, porządkowania i udostępniania informacji aplikacjom działającym w środowisku Windows. W praktyce może obsługiwać między innymi programy księgowe, magazynowe, sprzedażowe, produkcyjne, kadrowe oraz aplikacje tworzone na potrzeby konkretnej organizacji. Silnik bazy danych odpowiada nie tylko za zapis rekordów, lecz także za kontrolę transakcji, współbieżność dostępu, mechanizmy bezpieczeństwa, odzyskiwanie po awarii i wykonywanie kopii zapasowych.

Wydanie SQL Server 2014 wprowadziło kilka istotnych zmian w sposobie przetwarzania danych. Jedną z nich jest In-Memory OLTP, czyli mechanizm pozwalający wybranym tabelom i procedurom korzystać z pamięci operacyjnej w celu ograniczenia opóźnień związanych z operacjami wejścia i wyjścia. Rozwiązanie to nie oznacza, że cała baza automatycznie działa wyłącznie w pamięci. Wymaga odpowiedniego zaprojektowania struktur, dobrania obsługiwanych tabel oraz uwzględnienia ograniczeń konkretnej edycji SQL Server.

W tej wersji rozwinięto również mechanizm analizy zapytań i szacowania liczby wierszy zwracanych przez poszczególne operacje. Nowy estymator liczności może poprawić dobór planów wykonania dla części zapytań, ale po aktualizacji starszej instalacji niektóre zapytania mogą zacząć działać inaczej niż wcześniej. SQL Server 2014 oferuje ponadto funkcje związane z kopiami zapasowymi do Microsoft Azure oraz możliwością wykorzystania zasobów chmurowych w określonych scenariuszach. Nie należy jednak przypisywać tej wersji funkcji wprowadzonych dopiero w kolejnych wydaniach, takich jak Stretch Database czy Automatic Tuning.

SQL Server 2014 – objawy spowolnienia i niestabilnej pracy

Problemy z SQL Server 2014 często są widoczne najpierw w aplikacji korzystającej z bazy. Program może długo otwierać dokumenty, opóźniać zapis danych, zawieszać się podczas generowania raportu albo okresowo tracić połączenie. Sam użytkownik nie zawsze widzi komunikat wskazujący na źródło problemu. Opóźnienie może wynikać z blokady transakcji, przeciążenia procesora, wolnego podsystemu dyskowego, braku pamięci lub nieefektywnego planu wykonania zapytania.

Do częstych sygnałów ostrzegawczych należą również błędy połączenia z instancją. W zależności od konfiguracji pojawiają się komunikaty dotyczące niedostępnej usługi, przekroczenia czasu oczekiwania, protokołu TCP/IP, Named Pipes albo błędu 10061. W przypadku uwierzytelniania może wystąpić błąd 18456, którego przyczyną bywa nieprawidłowe hasło, zablokowane konto, wyłączony tryb logowania SQL lub brak właściwych uprawnień.

Poważniejszy charakter mają informacje o stanie Suspect, Recovery Pending lub Emergency. Oznaczają one, że baza nie została prawidłowo otwarta albo silnik napotkał problem z odzyskiwaniem i spójnością danych. Nie powinno się wtedy pochopnie zmieniać stanu bazy ani uruchamiać poleceń naprawczych bez wcześniejszego zabezpieczenia plików oraz ustalenia, czy istnieje aktualna kopia zapasowa. Każda nieprzemyślana ingerencja może utrudnić późniejsze odtworzenie danych.

SQL Server 2014 – sprzętowe i systemowe przyczyny awarii

Stan serwera bazy danych zależy od kondycji komputera, na którym działa usługa. Uszkodzenia dysku mogą prowadzić do błędów odczytu lub zapisu plików MDF, NDF i LDF. W dzienniku SQL Server mogą pojawiać się błędy wejścia i wyjścia oznaczone kodami 823, 824 albo 825. Nie wolno zakładać, że pojedynczy komunikat jest wyłącznie problemem aplikacji. Powtarzające się błędy dyskowe mogą wskazywać na degradację nośnika, przewodów, kontrolera lub zasilania.

Problemy z pamięcią RAM także mogą powodować niestabilność. Wadliwy moduł może wywoływać nieoczekiwane zatrzymanie usługi, błędy systemu Windows, uszkodzenie danych przetwarzanych w pamięci albo sporadyczne niepowtarzalne awarie. Warto pamiętać, że test wykonany przez kilka minut nie zawsze wystarcza do wykrycia niestabilności. Jeżeli objawy są losowe, potrzebne może być dłuższe badanie pamięci oraz analiza zdarzeń systemowych.

Źródłem problemu może być również brak wolnego miejsca na woluminie, błędna konfiguracja automatycznego powiększania plików, nieprawidłowe uprawnienie konta usługi, konflikt z oprogramowaniem ochronnym lub przerwanie zasilania podczas operacji zapisu. Szczególną uwagę należy zwrócić na plik dziennika transakcji. W modelu Full jego rozmiar powinien być kontrolowany przez regularne kopie dziennika. Bez takiej procedury plik LDF może rosnąć aż do wyczerpania miejsca na dysku, chociaż sama baza nadal zawierałaby dane możliwe do wykorzystania.

SQL Server 2014 – diagnostyka usługi, plików i połączeń

Diagnostykę najlepiej prowadzić od informacji najmniej ingerujących w działającą bazę. Pierwszym krokiem jest sprawdzenie, czy usługa SQL Server działa, czy uruchamia się automatycznie oraz czy w systemie nie występują błędy związane z kontem usługi. Następnie analizuje się SQL Server Error Log, dziennik aplikacji Windows i dziennik systemowy. Wpisy należy zestawić z czasem wystąpienia problemu, ponieważ pojedynczy komunikat wyrwany z kontekstu może prowadzić do błędnych wniosków.

Kolejny etap obejmuje sprawdzenie dostępności plików danych i dziennika. Należy zweryfikować ich lokalizację, rozmiar, wolne miejsce na odpowiednich woluminach oraz możliwość odczytu przez konto, pod którym pracuje usługa. Nie powinno się przenosić ani zmieniać nazw plików MDF, NDF i LDF bez znajomości ich powiązań z bazą. Warto też ustalić, czy problem występuje w jednej bazie, czy dotyczy całej instancji.

W przypadku błędów połączenia sprawdza się nazwę instancji, aktywność wymaganych protokołów, reguły zapory, konfigurację SQL Server Browser oraz sposób rozwiązywania nazwy komputera. Port 1433 nie jest uniwersalnym rozwiązaniem dla każdej instalacji, ponieważ instancja nazwana może korzystać z portu dynamicznego. Zmiany w zaporze powinny wynikać z rzeczywistej konfiguracji, a nie z przypadkowego otwierania szerokiego zakresu komunikacji.

SQL Server 2014 – kontrola spójności i analiza wydajności

Podstawowym narzędziem kontroli spójności jest DBCC CHECKDB. Polecenie pozwala wykryć niezgodności w strukturach alokacji, stronach danych, tabelach, indeksach i zależnościach wewnętrznych. Badanie powinno być wykonane z uwzględnieniem bieżącego stanu systemu oraz dostępnego miejsca na nośniku. Parametr NO_INFOMSGS może ograniczyć liczbę komunikatów informacyjnych, lecz nie zastępuje pełnej analizy wyniku. Warto zachować raport z wykonania, aby można było porównać stan bazy po naprawie.

Jeżeli baza jest spójna, ale działa wolno, przyczyn trzeba szukać w obciążeniu i sposobie wykonywania zapytań. Widoki zarządzania dynamicznego pomagają ustalić, które zapytania zużywają procesor, wykonują intensywne operacje dyskowe albo długo czekają na zasoby. Analizuje się między innymi statystyki oczekiwania, blokady, zakleszczenia, czas trwania zapytań i liczbę odczytanych stron. Sprawdzenie samego użycia procesora często jest niewystarczające, ponieważ aplikacja może czekać głównie na dysk lub blokadę innej transakcji.

Ważne są także statystyki tabel i indeksów. Nieaktualne statystyki mogą prowadzić do wyboru planu, który dla bieżącej liczby danych jest niekorzystny. Z kolei nadmiar indeksów zwiększa koszt zapisu i może zajmować znaczną część przestrzeni. Optymalizacja powinna być poprzedzona obserwacją rzeczywistych zapytań, a nie wykonywana wyłącznie według ogólnej listy poleceń. Każda zmiana wymaga późniejszego sprawdzenia, czy poprawiła czas pracy aplikacji.

SQL Server 2014 – bezpieczny przebieg naprawy bazy danych

Naprawa powinna rozpocząć się od zabezpieczenia materiału wyjściowego. Jeżeli baza jest dostępna, wykonuje się kopię zapasową zgodnie z możliwościami instalacji. Przy podejrzeniu uszkodzenia nośnika dodatkowo zabezpiecza się pliki bazodanowe w sposób ograniczający ich dalsze obciążanie. Przed zmianami warto zapisać konfigurację instancji, listę baz, kont, zadań, harmonogramów oraz lokalizacje kopii zapasowych.

Następnie ustala się rodzaj problemu. Jeżeli usługa nie startuje, analizuje się Error Log, uprawnienia, dostępność plików, wolne miejsce i zależności systemowe. Jeżeli baza pozostaje w stanie Recovery Pending, sprawdza się, czy silnik może odczytać pliki oraz czy proces odzyskiwania nie został przerwany przez brak miejsca lub awarię nośnika. W przypadku podejrzenia niespójności wykonuje się kontrolę DBCC CHECKDB i porównuje wynik z dostępnymi kopiami zapasowymi.

Najbezpieczniejszą metodą odzyskania sprawnej bazy jest zwykle odtworzenie jej z poprawnej kopii zapasowej. Jeżeli kopii nie ma, a DBCC wskazuje uszkodzenia, możliwe działania zależą od rozmiaru i charakteru problemu. Opcje naprawcze mogą prowadzić do utraty części danych, dlatego nie powinny być uruchamiane jako pierwszy odruch. W szczególności nie należy używać poleceń zmieniających stan bazy bez świadomości konsekwencji i bez zachowania oryginalnych plików.

SQL Server 2014 – kopie zapasowe, dziennik transakcji i odzyskiwanie

Skuteczna ochrona bazy wymaga określenia, jakie dane można odtworzyć i z jakiego momentu. Kopia pełna zabezpiecza całą bazę w określonym czasie, natomiast kopie różnicowe i kopie dziennika mogą skrócić drogę do odtworzenia kolejnych zmian. Dobór modelu odzyskiwania powinien odpowiadać sposobowi pracy aplikacji oraz przyjętej procedurze wykonywania i testowania kopii.

Sam fakt utworzenia pliku kopii nie oznacza jeszcze, że odzyskanie będzie możliwe. Należy sprawdzać poprawność kopii, kontrolować logi zadań i okresowo wykonywać próbne odtworzenie w odizolowanym środowisku. Test pozwala wykryć nieprawidłowe ścieżki, brak uprawnień, niezgodność wersji, uszkodzone pliki oraz problemy z kolejnością odtwarzania. Warto także przechowywać kopie w innym miejscu niż podstawowe pliki bazy, aby awaria jednego nośnika nie pozbawiła dostępu do obu zestawów danych.

Rozmiar dziennika transakcji powinien być monitorowany razem z przyczyną jego wzrostu. Może nią być długotrwała transakcja, brak kopii dziennika w modelu Full, oczekiwanie na replikację albo proces, który nie został poprawnie zakończony. Samo zmniejszanie pliku logu nie usuwa przyczyny problemu i wykonywane regularnie może pogorszyć wydajność przez wymuszanie kolejnych powiększeń. Najpierw trzeba ustalić, dlaczego dziennik nie może zwolnić zajętego miejsca.

SQL Server 2014 – optymalizacja po usunięciu awarii

Po przywróceniu działania nie należy kończyć prac na samym uruchomieniu usługi. Trzeba sprawdzić, czy aplikacje poprawnie odczytują i zapisują dane, czy działają zadania cykliczne, czy wykonują się kopie zapasowe oraz czy nie powracają błędy wejścia i wyjścia. Warto obserwować obciążenie procesora, pamięci, dysków i sieci w czasie typowej pracy użytkowników. Dopiero porównanie tych danych z okresem sprzed awarii pokazuje, czy problem rzeczywiście został rozwiązany.

Optymalizacja może obejmować aktualizację statystyk, reorganizację lub przebudowę wybranych indeksów, korektę ustawień automatycznego powiększania oraz przeniesienie plików na odpowiednio przygotowane woluminy. Każda zmiana powinna mieć uzasadnienie wynikające z pomiarów. Nie zaleca się masowego przebudowywania wszystkich indeksów ani zmiany parametrów instancji bez sprawdzenia wpływu na konkretne obciążenie.

W środowisku SQL Server 2014 warto również zweryfikować zgodność zapytań z używanym estymatorem liczności. Po zmianie ustawień lub aktualizacji bazy niektóre plany wykonania mogą wymagać dodatkowej analizy. Pomocne bywa porównanie planów, sprawdzenie parametrów zapytań oraz identyfikacja sytuacji, w których estymowana liczba wierszy znacznie różni się od rzeczywistej. Celem nie jest zmiana konfiguracji dla samej zmiany, lecz uzyskanie stabilnej pracy aplikacji.

SQL Server 2014 – kiedy zgłosić problem do serwisu komputerowego

Do serwisu warto zgłosić się wtedy, gdy usługa SQL Server 2014 nie uruchamia się, baza przechodzi w stan Suspect lub Recovery Pending, pojawiają się powtarzające błędy 823, 824 albo 825, a także gdy komputer niespodziewanie się wyłącza lub traci dostęp do dysku. Pomocy wymagają również sytuacje, w których aplikacja przestała łączyć się z bazą po zmianie systemu, instalacji zabezpieczeń, wymianie nośnika albo awarii zasilania.

Przed przekazaniem urządzenia dobrze przygotować opis objawów, czas ich wystąpienia, komunikaty błędów, informacje o ostatniej poprawnej kopii zapasowej oraz dane o zmianach wykonanych przed awarią. Nie należy usuwać plików MDF, NDF ani LDF, kasować dzienników i przeinstalowywać instancji bez analizy. Takie działania mogą zniszczyć informacje potrzebne do odtworzenia bazy lub utrudnić ustalenie pierwotnej przyczyny.

Warszawskie Pogotowie Komputerowe 24/7 może przeprowadzić analizę komputera, nośnika, systemu Windows i konfiguracji SQL Server 2014, a naprawy z reguły są wykonywane do 3 dni roboczych. Zakres prac powinien być ustalany po rozpoznaniu objawów, ponieważ inaczej postępuje się przy uszkodzeniu dysku, inaczej przy błędnej konfiguracji połączeń, a jeszcze inaczej przy problemie ze spójnością plików bazy. Najważniejsze jest zachowanie danych, udokumentowanie wykonanych czynności i przywrócenie stabilnej pracy bez podejmowania ryzykownych zmian bez kopii zapasowej.