Microsoft SQL Server

SQL Server 2017 – charakterystyka wersji i znaczenie dla baz danych

SQL Server 2017 to relacyjny system zarządzania bazami danych firmy Microsoft, przeznaczony do przechowywania, przetwarzania i udostępniania informacji aplikacjom oraz użytkownikom. Wersja ta została zaprojektowana z myślą o środowiskach Windows i Linux, a także o uruchamianiu w kontenerach. Dzięki temu SQL Server 2017 może pracować zarówno na komputerze lokalnym, jak i na infrastrukturze opartej na innych systemach operacyjnych. Sam silnik bazy danych pozostał zgodny z dotychczasowym modelem tabel, indeksów, transakcji i zapytań T-SQL, ale otrzymał kilka istotnych rozszerzeń poprawiających wydajność, analizę danych i administrację.

Jedną z ważnych zmian było wprowadzenie mechanizmów Adaptive Query Processing. Ich zadaniem jest ograniczanie skutków błędnych oszacowań liczby wierszy i niedopasowanych przydziałów pamięci. SQL Server 2017 oferuje między innymi funkcje Batch Mode Memory Grant Feedback, Batch Mode Adaptive Joins oraz Interleaved Execution dla wybranych funkcji tabelarycznych. Nie oznacza to, że każda baza automatycznie zacznie działać szybciej. Rezultat zależy od poziomu zgodności bazy, rodzaju zapytań, indeksów, statystyk i sposobu konfiguracji instancji.

W tej wersji pojawiły się również tabele grafowe, pozwalające opisywać węzły i relacje między nimi. Rozwiązanie może być przydatne przy analizie powiązań między obiektami, na przykład zależności organizacyjnych, relacji produktów lub połączeń między rekordami. SQL Server 2017 rozszerzył także możliwości Machine Learning Services o obsługę języka Python obok R. W praktyce najważniejsze dla codziennego utrzymania pozostają jednak stabilność usługi, poprawne kopie zapasowe, spójność plików danych oraz przewidywalna wydajność zapytań.

SQL Server 2017 – najczęstsze objawy awarii instancji

Problemy z SQL Server 2017 mogą być widoczne od razu albo narastać stopniowo. Najbardziej oczywistym objawem jest brak uruchomienia usługi po restarcie systemu, aktualizacji lub awarii zasilania. W konsoli usług może pojawić się próba startu zakończona błędem, natomiast w pliku dziennika SQL Server znajdą się informacje o braku dostępu do plików, problemie z odzyskiwaniem albo niewystarczającej ilości miejsca. W przypadku instancji nazwanej należy dodatkowo upewnić się, że analizowana jest właściwa usługa, a nie domyślna instancja MSSQLSERVER.

Innym sygnałem jest brak połączenia aplikacji z bazą danych. Komunikat może dotyczyć niedostępnego serwera, przekroczenia czasu oczekiwania, nieprawidłowego uwierzytelnienia lub blokady połączenia przez zaporę. Błąd logowania 18456 nie zawsze oznacza uszkodzenie bazy. Często wskazuje na nieprawidłowe hasło, wyłączone konto, niewłaściwy tryb uwierzytelniania albo próbę połączenia z inną instancją niż zamierzona.

Niepokój powinny wzbudzić także stany Suspect, Recovery Pending, Emergency lub Read-Only. Stan Suspect oznacza, że proces odzyskiwania bazy nie zakończył się poprawnie i wymaga szczegółowej analizy. Recovery Pending może wskazywać, że silnik nie rozpoczął odzyskiwania z powodu problemu z plikiem, zasobami albo konfiguracją. Samodzielne przełączanie bazy w tryb awaryjny i wykonywanie przypadkowych poleceń naprawczych może pogorszyć sytuację, szczególnie gdy nie istnieje aktualna kopia zapasowa.

Do objawów wydajnościowych należą długie oczekiwanie na wykonanie zapytań, blokowanie transakcji, zakleszczenia, rosnące zużycie pamięci i procesora oraz nagłe spowolnienie aplikacji korzystających z bazy. Warto odróżnić awarię silnika od problemu aplikacyjnego. Przyczyną może być nieoptymalne zapytanie, brak indeksu, zmiana planu wykonania, rozrost pliku dziennika, pełny dysk albo problem z systemem plików.

SQL Server 2017 – przyczyny problemów z plikami danych i dziennikiem

Pliki MDF i NDF przechowują dane, natomiast plik LDF zawiera dziennik transakcji potrzebny między innymi do odtworzenia spójności po przerwaniu pracy. Uszkodzenie nośnika, błędy kontrolera, niestabilna pamięć masowa albo nagła utrata zasilania mogą doprowadzić do problemów z odczytem stron danych. W dzienniku systemowym mogą być rejestrowane błędy wejścia i wyjścia, a SQL Server może zgłaszać kody 823, 824 lub 825. Takich komunikatów nie należy traktować wyłącznie jako problemu programowego, ponieważ ich źródłem może być sprzęt.

Ważną przyczyną awarii jest brak wolnego miejsca. Dotyczy to nie tylko partycji z plikami bazy, ale również lokalizacji plików tymczasowych, kopii zapasowych i logów. Gdy plik dziennika nie może się powiększyć, transakcje mogą przestać działać, nawet jeśli same pliki danych są dostępne. Automatyczne ustawienie nieograniczonego wzrostu plików nie rozwiązuje problemu. Może jedynie doprowadzić do szybkiego zapełnienia dysku i utrudnić późniejszą diagnozę.

Problemy powodują również nieprawidłowe uprawnienia konta usługi. Po zmianie konta, przeniesieniu bazy do innego katalogu lub przywróceniu plików z kopii SQL Server musi mieć możliwość odczytu i zapisu w odpowiednich lokalizacjach. Oprogramowanie ochronne może dodatkowo blokować dostęp do plików, skanować je w niewłaściwym momencie albo opóźniać operacje wejścia i wyjścia. Konfiguracja zabezpieczeń powinna być oceniana razem z logami, a nie zmieniana przypadkowo metodą prób i błędów.

SQL Server 2017 – diagnostyka usługi, połączeń i środowiska

Diagnostyka powinna rozpocząć się od zebrania informacji o momencie wystąpienia problemu. Istotne są ostatnie restarty, aktualizacje, zmiany haseł, przenoszenie plików, rozbudowa bazy, awarie zasilania oraz działania wykonywane przez aplikacje. Następnie należy sprawdzić stan usługi SQL Server, nazwę instancji, konto usługi i parametry uruchamiania. W przypadku problemu z połączeniem trzeba ustalić, czy błąd występuje lokalnie, z innego komputera, czy tylko w jednej aplikacji.

Podstawowym źródłem informacji jest plik ERRORLOG instancji. Należy analizować wpisy z kilku minut przed awarią oraz z okresu uruchamiania. Warto zwrócić uwagę na komunikaty o błędach wejścia i wyjścia, brakujących plikach, odmowie dostępu, odzyskiwaniu bazy, problemach z pamięcią i nieudanych próbach logowania. Uzupełnieniem są dzienniki zdarzeń systemu Windows, zwłaszcza sekcje dotyczące aplikacji, systemu, dysków i usług.

Kolejny etap obejmuje sprawdzenie dysków, wolnego miejsca, stanu systemu plików i dostępności ścieżek zapisanych w konfiguracji bazy. Nie należy zakładać, że pliki znajdują się w standardowym katalogu. Lokalizacje mogą być zmienione podczas instalacji lub późniejszej administracji. Należy również zweryfikować, czy litera dysku, udział sieciowy albo punkt podłączenia są obecnie dostępne dla konta, pod którym działa usługa.

W przypadku problemów sieciowych sprawdza się aktywność protokołu TCP/IP, port nasłuchiwania, nazwę instancji oraz ustawienia zapory. SQL Server Browser może być potrzebny przy określonych sposobach odnajdywania instancji nazwanych, ale jego uruchomienie nie zastępuje prawidłowej konfiguracji TCP/IP. Weryfikacja powinna obejmować także właściwy adres serwera wpisany w aplikacji. Częstym błędem jest kierowanie połączenia do komputera lub instancji, która nie zawiera wymaganej bazy.

SQL Server 2017 – sprawdzanie spójności danych i indeksów

Po zabezpieczeniu dostępnych danych można przystąpić do kontroli spójności. Służy do tego DBCC CHECKDB, który sprawdza między innymi struktury alokacji, strony danych, zależności między obiektami i wybrane elementy indeksów. Wariant PHYSICAL_ONLY ogranicza zakres kontroli do szybszej oceny fizycznej spójności stron, dlatego może być użyteczny jako wstępny test. Nie zastępuje pełnego sprawdzenia, gdy podejrzewa się błędy logiczne.

Wynik DBCC CHECKDB należy zachować w całości. Pojedynczy komunikat o błędzie nie wystarcza do oceny skali problemu, ponieważ dalsze wpisy mogą wskazywać uszkodzone obiekty, strony i możliwe działania. Polecenia DBCC CHECKALLOC oraz DBCC CHECKTABLE mogą uzupełniać analizę, lecz ich uruchamianie na aktywnej bazie powinno być zaplanowane z uwzględnieniem obciążenia. Kontrola spójności może zużywać zasoby i powodować wydłużenie czasu odpowiedzi.

Nie należy zaczynać od DBCC CHECKDB z opcją REPAIR_ALLOW_DATA_LOSS. Nazwa tej opcji wskazuje na najważniejsze ryzyko: procedura może usunąć uszkodzone lub niespójne elementy, aby doprowadzić strukturę do stanu używalnego. Nie jest to odpowiednik pełnego odzyskania danych. Jeżeli dostępna jest poprawna kopia zapasowa, bezpieczniejszym kierunkiem bywa odtworzenie bazy na osobnym nośniku i porównanie wyników z uszkodzonym środowiskiem.

SQL Server 2017 – przebieg bezpiecznej naprawy bazy

Naprawa powinna być poprzedzona zabezpieczeniem materiału do analizy. W zależności od stanu instancji może to oznaczać wykonanie kopii plików, skopiowanie logów, zachowanie wyniku poleceń diagnostycznych i sprawdzenie, czy istnieją pełne oraz różnicowe kopie zapasowe. Jeżeli nośnik wykazuje błędy fizyczne, dalsze zapisy mogą zwiększyć zakres uszkodzeń. W takiej sytuacji istotne jest ograniczenie zbędnych prób uruchamiania, automatycznych napraw i intensywnego skanowania.

Następnie ustala się źródło awarii. Gdy problem dotyczy konfiguracji lub uprawnień, naprawa może polegać na przywróceniu dostępu do właściwych katalogów, poprawieniu parametrów usługi albo odtworzeniu ustawień połączeń. Gdy problem wynika z pełnego dysku, należy najpierw zapewnić bezpieczną przestrzeń i ocenić, czy rozrost pliku był związany z długą transakcją, brakiem kopii dziennika, nieudaną konserwacją czy niewłaściwym modelem odzyskiwania.

Jeżeli baza jest spójna, ale działa wolno, zakres prac będzie inny. Analizuje się aktywne oczekiwania, blokady, zakleszczenia, plany wykonania, statystyki, indeksy, ustawienia pamięci oraz Query Store, o ile został wcześniej włączony i zawiera dane. Optymalizacja powinna wynikać z pomiarów. Samo dodanie wielu indeksów może przyspieszyć część odczytów, lecz zwiększa koszt zapisów i konserwacji.

W przypadku uszkodzenia logicznego należy porównać możliwe drogi odzyskiwania: przywrócenie pełnej kopii, odtworzenie kopii dziennika, eksport sprawnych tabel, odczyt danych z kopii roboczej lub kontrolowane użycie narzędzi naprawczych. Wybór zależy od aktualności kopii, zakresu błędów i znaczenia poszczególnych danych. Każdą operację o podwyższonym ryzyku warto najpierw wykonać na kopii, a nie na jedynym egzemplarzu bazy.

SQL Server 2017 – wydajność, blokady i problemy z zapytaniami

Spowolnienie SQL Server 2017 nie zawsze jest oznaką uszkodzenia danych. Częstym źródłem problemu jest zapytanie skanujące dużą tabelę, nieaktualne statystyki, niepasujący indeks albo nagła zmiana planu wykonania. Znaczenie ma również parametr zapytania, kolejność operacji i liczba równocześnie wykonywanych transakcji. Analiza powinna uwzględniać czas trwania zapytań, odczyty logiczne, oczekiwania oraz zasoby, na które proces rzeczywiście czeka.

Blokowanie występuje wtedy, gdy jedna transakcja przetrzymuje zasób potrzebny innej. Deadlock jest szczególną sytuacją, w której transakcje tworzą cykl wzajemnych oczekiwań i jedna z nich zostaje przerwana przez silnik. Doraźne zabijanie sesji może uwolnić zasób, ale nie usuwa przyczyny. Potrzebne może być skrócenie transakcji, poprawa kolejności dostępu do obiektów, zmiana indeksu albo modyfikacja kodu aplikacji.

Warto odróżnić problem z pamięcią od problemu z wyciekiem zasobów poza SQL Server. Konfiguracja maksymalnej pamięci instancji powinna pozostawiać miejsce dla systemu operacyjnego i innych wymaganych procesów. Gwałtowne użycie procesora może wynikać z zapętlenia aplikacji, kompilowania planów, nieefektywnego zapytania lub zadania konserwacyjnego. Wnioski powinny być oparte na logach i pomiarach z czasu wystąpienia problemu.

SQL Server 2017 – kopie zapasowe i przygotowanie do odzyskiwania

Najskuteczniejszą ochroną przed utratą danych jest sprawdzony plan kopii zapasowych. Sama obecność pliku backupu nie gwarantuje możliwości odtworzenia. Należy kontrolować, czy kopia zakończyła się poprawnie, czy można ją odczytać oraz czy da się odtworzyć ją w niezależnej lokalizacji. W przypadku baz używających modelu pełnego odzyskiwania trzeba ocenić również regularność kopii dziennika transakcji. Duży plik LDF nie powinien być zmniejszany automatycznie bez ustalenia przyczyny jego rozrostu.

Procedura odzyskiwania powinna określać kolejność odtwarzania, wymagane hasła, lokalizacje plików, zależności aplikacyjne i sposób weryfikacji danych po przywróceniu. Po awarii sprawdza się nie tylko możliwość uruchomienia bazy, ale także poprawność kluczowych tabel, uprawnień, zadań oraz połączeń aplikacyjnych. Test odtworzenia ujawnia problemy, których nie widać podczas samego wykonywania kopii.

Pomocne jest również ograniczenie ryzyka na poziomie sprzętu. Nośnik przeznaczony na pliki danych powinien być monitorowany, a komunikaty o błędach wejścia i wyjścia analizowane bez zwłoki. Nagłe wyłączanie komputera, przeciążenie dysku i brak wolnej przestrzeni mogą powtarzać awarie nawet po poprawnym uruchomieniu instancji.

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

Do serwisu warto zgłosić się wtedy, gdy SQL Server 2017 nie uruchamia się po restarcie, baza ma stan Suspect lub Recovery Pending, pojawiają się błędy 823, 824 albo 825, znikają pliki MDF lub LDF, a także gdy kopia zapasowa nie daje się odtworzyć. Szybkiej konsultacji wymaga również sytuacja, w której aplikacja przestała łączyć się z bazą po awarii dysku, zmianie hasła, aktualizacji systemu lub zaniku zasilania. Szczególnej ostrożności wymaga baza zawierająca jedyny dostępny egzemplarz ważnych danych.

Przed przekazaniem zgłoszenia dobrze przygotować nazwę instancji, opis pierwszego zauważonego objawu, informacje o ostatnich zmianach oraz komunikaty z ERRORLOG i dziennika systemowego. Należy wskazać, czy istnieje kopia zapasowa i kiedy została sprawdzona. Nie powinno się usuwać plików dziennika, kasować plików danych, reinstalować SQL Server ani uruchamiać przypadkowych poleceń naprawczych bez kopii i planu odzyskania.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się analizą problemów z komputerami i środowiskiem, w którym działa lokalna instancja SQL Server 2017. Przy zgłoszeniu można przekazać logi, wyniki kontroli spójności, informacje o kopiach oraz opis zachowania aplikacji. Takie dane ułatwiają rozróżnienie awarii sprzętu, konfiguracji, połączenia i samej bazy, a następnie dobranie postępowania ograniczającego ryzyko dalszej utraty informacji.

SQL Server 2017 – podsumowanie najważniejszych zasad postępowania

Problemy z SQL Server 2017 wymagają spokojnej i uporządkowanej analizy. Najpierw ustala się, czy niedostępność dotyczy usługi, instancji, sieci, uwierzytelniania, konkretnej bazy czy aplikacji. Następnie sprawdza się logi, miejsce na dysku, dostęp do plików, stan nośnika i wynik kontroli spójności. Dopiero po zebraniu tych informacji wybiera się naprawę konfiguracji, odtworzenie kopii, eksport danych, optymalizację zapytań albo procedurę odzyskiwania.

Największym błędem jest wykonywanie zmian bez zachowania materiału wyjściowego. Każda próba naprawy może zmienić stan bazy, usunąć część informacji albo utrudnić późniejsze odtworzenie. Dlatego warto zabezpieczyć pliki i logi, ograniczyć niepotrzebne uruchamianie instancji, sprawdzić dostępne kopie oraz dokumentować kolejne czynności. SQL Server 2017 oferuje rozbudowane narzędzia diagnostyczne, ale ich skuteczne wykorzystanie wymaga dopasowania polecenia do rodzaju problemu i oceny ryzyka dla danych.