SQL Server Database Engine

Database Engine to główny komponent SQL Server odpowiedzialny za przechowywanie i przetwarzanie danych.

Rola SQL Server Database Engine w systemie bazodanowym

SQL Server Database Engine, nazywany także aparatem bazodanowym SQL Server, jest komponentem odpowiedzialnym za obsługę relacyjnych baz danych Microsoft SQL Server. Przyjmuje polecenia Transact-SQL, analizuje ich składnię i znaczenie, tworzy plan wykonania, a następnie odczytuje lub modyfikuje dane zapisane w plikach bazy. Silnik obsługuje między innymi tabele, indeksy, widoki, procedury składowane, funkcje, wyzwalacze oraz ograniczenia integralności. Nie jest to osobny produkt niezależny od SQL Server, lecz podstawowa usługa serwera baz danych.

W typowej instalacji silnik działa jako usługa systemu Windows o nazwie zależnej od instancji. Dla instancji domyślnej używana jest usługa SQL Server (MSSQLSERVER), natomiast dla instancji nazwanej nazwa zawiera identyfikator instancji, na przykład SQL Server (NAZWA_INSTANCJI). Do komunikacji klienckiej wykorzystywany jest protokół TDS, czyli Tabular Data Stream. Programy mogą łączyć się z aparatem bazodanowym przez sterowniki i biblioteki zgodne z SQL Server, takie jak Microsoft ODBC Driver for SQL Server, OLE DB lub dostawcy .NET.

Jak silnik zapisuje dane i wykonuje zapytania

SQL Server przechowuje dane w plikach bazy danych, zwykle z rozszerzeniem .mdf dla głównego pliku danych oraz .ndf dla dodatkowych plików danych. Zmiany wprowadzane przez użytkownika lub aplikację są rejestrowane w pliku dziennika transakcji, zwykle z rozszerzeniem .ldf. Dane są organizowane w stronach o rozmiarze 8 KiB, a osiem stron tworzy jeden extent o rozmiarze 64 KiB. Aparat korzysta z puli buforowej w pamięci RAM, aby ograniczyć liczbę operacji dyskowych. Strony zmienione w pamięci, ale jeszcze niezapisane na dysku, są określane jako dirty pages.

Po otrzymaniu zapytania optymalizator zapytań wybiera plan wykonania na podstawie tekstu polecenia, statystyk oraz dostępnych indeksów. Plan może obejmować skanowanie tabeli, wyszukiwanie po indeksie, sortowanie, łączenie zbiorów danych i agregację. Zmiana indeksów, nieaktualne statystyki, blokady lub niewystarczająca pamięć mogą spowodować, że zapytanie wykona się wolniej, mimo że jego składnia jest poprawna. Do analizy planu można użyć rzeczywistego lub szacowanego planu wykonania oraz poleceń SET STATISTICS IO i SET STATISTICS TIME.

W SQL Server indeks klastrowany określa fizyczny porządek wierszy tabeli, ponieważ jego struktura zawiera same dane tabeli. Tabela może mieć najwyżej jeden indeks klastrowany. Indeksy nieklastrowane przechowują osobną strukturę kluczy i odwołania do wierszy lub klucza indeksu klastrowanego. Ich obecność może przyspieszać odczyt, ale zwiększa koszt operacji INSERT, UPDATE i DELETE, ponieważ silnik musi aktualizować również struktury indeksowe.

Transakcje, blokady i odzyskiwanie po awarii

Database Engine zapewnia transakcyjność operacji za pomocą mechanizmów zgodnych z właściwościami ACID. Polecenia BEGIN TRANSACTION, COMMIT TRANSACTION i ROLLBACK TRANSACTION pozwalają grupować modyfikacje w logiczną całość. Dziennik transakcji stosuje zasadę write-ahead logging: odpowiedni zapis w dzienniku musi zostać utrwalony przed zapisaniem zmienionej strony danych. Dzięki temu po awarii silnik może odtworzyć zatwierdzone zmiany i wycofać zmiany transakcji, która nie została zatwierdzona.

SQL Server używa blokad do kontrolowania równoczesnego dostępu do danych. Blokady mogą dotyczyć między innymi wierszy, kluczy, stron, obiektów lub całej bazy. Ich zakres i czas utrzymywania zależą od rodzaju operacji oraz poziomu izolacji transakcji. Dostępne poziomy izolacji obejmują READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE i SNAPSHOT. Długotrwałe transakcje, nieodpowiednie indeksy oraz oczekiwanie na blokadę mogą prowadzić do spadku wydajności, a wzajemne oczekiwanie transakcji może zakończyć się wykryciem zakleszczenia przez silnik.

Model odzyskiwania bazy określa sposób zarządzania dziennikiem i możliwości odtwarzania. Model SIMPLE ogranicza konieczność wykonywania kopii dziennika, natomiast modele FULL i BULK_LOGGED pozwalają korzystać z kopii dziennika transakcji. Po niekontrolowanym zatrzymaniu usługi SQL Server wykonuje automatyczne odzyskiwanie bazy. Proces obejmuje analizę dziennika, ponowne zastosowanie potrzebnych zmian oraz wycofanie niezatwierdzonych transakcji. Problemy z uszkodzonym plikiem danych, brakiem miejsca na woluminie lub niespójnym dziennikiem mogą uniemożliwić prawidłowy start bazy.

Objawy problemów z aparatem bazodanowym i metody weryfikacji

Diagnostyka SQL Server Database Engine powinna zaczynać się od ustalenia, czy usługa działa, z jaką instancją próbuje połączyć się aplikacja oraz czy użytkownik korzysta z właściwego serwera i portu. Następnie sprawdza się dziennik błędów SQL Server, Podgląd zdarzeń systemu Windows, komunikaty sterownika oraz stan plików .mdf, .ndf i .ldf. Błąd połączenia może wynikać z zatrzymanej usługi, wyłączonego protokołu TCP/IP, nieprawidłowej nazwy instancji, niedostępnego portu, błędnych danych logowania albo braku uprawnień do konkretnej bazy.

Objawem przeciążenia silnika może być wysokie użycie procesora, presja pamięci, długie oczekiwanie na operacje dyskowe lub rosnąca liczba sesji oczekujących na blokady. Do sprawdzania aktywnych żądań i sesji służą między innymi widoki dynamicznego zarządzania sys.dm_exec_requests i sys.dm_exec_sessions. Widok sys.dm_os_waiting_tasks pomaga ustalić, na co czekają zadania. Do kontroli logicznej spójności bazy stosuje się DBCC CHECKDB, które może wykryć uszkodzenia struktur danych i indeksów. Przed próbą naprawy należy zachować kopię bazy lub plików, ponieważ opcje naprawcze mogą prowadzić do utraty części danych.

Podczas naprawy komputera, na którym lokalnie działa SQL Server, warto rozdzielić problem samego aparatu bazodanowego od problemu aplikacji korzystającej z bazy. Należy sprawdzić wersję sterownika, konfigurację połączenia, wolne miejsce, uprawnienia konta usługi oraz dostępność kopii zapasowych. Jeżeli komputer nie uruchamia usługi, zawiesza się podczas pracy albo utracił dostęp do dysku przechowującego bazę, konieczna jest ostrożna diagnostyka systemu, pamięci masowej i dzienników, aby nie pogłębić uszkodzenia danych.