Wersje 64-bitowe

Wersje 64-bitowe to standard obecnych wydań SQL Server, umożliwiający pełne wykorzystanie dostępnej pamięci.

Architektura x64 w SQL Server

Wersja 64-bitowa SQL Server korzysta z 64-bitowej przestrzeni adresowej procesu silnika bazy danych. W praktyce oznacza to możliwość adresowania znacznie większej ilości pamięci niż w aplikacji 32-bitowej, której przestrzeń adresowa jest ograniczona do zakresu wynikającego z 32-bitowych adresów. SQL Server może dzięki temu utrzymywać w pamięci większy bufor danych, planów wykonania i innych struktur roboczych. Nie oznacza to jednak, że sam zakup lub instalacja wersji 64-bitowej automatycznie przyspieszy każde zapytanie. Efekt zależy również od ilości zainstalowanej pamięci RAM, konfiguracji systemu, obciążenia, szybkości magazynu danych oraz poprawności zapytań i indeksów.

Współczesne wydania SQL Server są projektowane przede wszystkim dla platform 64-bitowych. Przykładowo SQL Server 2022 dla systemu Windows wymaga procesora zgodnego z architekturą x64, a instalacja linuksowa również jest przeznaczona dla obsługiwanych platform x86-64. Kompatybilność procesora to tylko jeden z warunków. Należy sprawdzić także obsługiwany system operacyjny, wymagania konkretnej edycji, dostępne sterowniki oraz zgodność aplikacji korzystających z serwera. Program kliencki może być 32-bitowy i nadal łączyć się z 64-bitowym SQL Server, ponieważ proces klienta i proces silnika bazy danych działają niezależnie.

Pamięć, bufor danych i limity edycji

Najważniejszą praktyczną konsekwencją architektury 64-bitowej jest możliwość efektywnego wykorzystania dużej pamięci RAM przez SQL Server. Silnik przechowuje w pamięci podręcznej między innymi strony danych i indeksów, a odczyt strony z pamięci jest szybszy niż ponowne pobranie jej z dysku. Przy odpowiedniej ilości RAM większa część aktywnego zbioru danych może pozostać w buforze, co ogranicza operacje wejścia-wyjścia. SQL Server nie powinien jednak otrzymywać całej pamięci komputera. System operacyjny i inne usługi także wymagają zasobów, dlatego administrator ustawia limit pamięci instancji za pomocą parametrów konfiguracji SQL Server, w szczególności opcji max server memory (MB).

Rzeczywisty limit pamięci zależy od wydania i wersji SQL Server, dlatego nie wolno zakładać, że sama architektura x64 usuwa wszystkie ograniczenia licencyjne. Edycje mogą mieć różne limity pamięci dla bufora silnika, a limity zmieniały się między wydaniami produktu. Przy planowaniu modernizacji trzeba więc sprawdzić dokumentację dokładnie używanej wersji, a następnie porównać ją z ilością RAM i wymaganiami aplikacji. Zbyt niski limit może powodować częstsze odczyty z dysku, natomiast zbyt wysoki może pozbawić pamięci system operacyjny, sterowniki, agenta SQL Server lub inne procesy działające na tym samym komputerze.

Kompatybilność instalacji i aplikacji

Przejście na 64-bitowy SQL Server wymaga rozdzielenia kilku kwestii: architektury systemu operacyjnego, architektury samego silnika, sterowników połączeniowych oraz dodatków używanych przez aplikację. Narzędzie lub program korzystający z ODBC, OLE DB albo sterownika dostawcy powinien mieć zainstalowany wariant zgodny z procesem, który go ładuje. 32-bitowa aplikacja wymaga 32-bitowego sterownika, nawet jeśli docelowa baza działa na 64-bitowym serwerze. Odwrotna sytuacja również może powodować problemy, gdy 64-bitowa aplikacja próbuje użyć wyłącznie 32-bitowego komponentu.

Przed instalacją warto zinwentaryzować istniejące instancje, dodatki, zadania SQL Server Agent, połączenia aplikacyjne i biblioteki dostawców. Należy też wykonać kopię zapasową baz oraz zweryfikować procedurę odtworzenia na osobnym środowisku. Sama baza danych nie staje się „32-bitowa” ani „64-bitowa” w taki sposób jak plik wykonywalny; ważna jest architektura procesu silnika, systemu i komponentów współpracujących. Po migracji można porównać czas zapytań, zużycie pamięci, opóźnienia operacji dyskowych oraz komunikaty w dzienniku SQL Server. Różnice w planach wykonania trzeba analizować na podstawie danych, a nie przypisywać automatycznie samej zmianie architektury.

Weryfikacja konfiguracji i obsługa serwisowa

Podstawową weryfikację można rozpocząć od sprawdzenia właściwości instancji oraz parametrów pamięci. Zapytanie SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('Edition'); zwraca numer wersji produktu i nazwę edycji. Informacje o systemie operacyjnym, procesorze i pamięci należy sprawdzić niezależnie, ponieważ wynik zapytania nie zastępuje diagnostyki całej platformy. Warto również ustalić, czy SQL Server działa jako instancja domyślna czy nazwana, jaki port wykorzystuje oraz czy aplikacja łączy się z właściwym hostem. Problemy po migracji często wynikają z niezgodnego sterownika, błędnego aliasu lub ustawionego limitu pamięci, a nie z uszkodzenia samej bazy.

Przy diagnozowaniu komputera z lokalną instalacją SQL Server sprawdza się wersję systemu, obsługę x64 procesora, ilość RAM, stan dysków, wolne miejsce oraz obciążenie procesora i pamięci. Analiza powinna obejmować także kopie zapasowe i możliwość bezpiecznego odtworzenia danych przed zmianą instalacji. W przypadku środowiska serwerowego naprawa wymaga dodatkowo kontroli usług, zależności instancji, uprawnień konta usługi i konfiguracji połączeń aplikacyjnych. Dobór wersji 64-bitowej powinien wynikać z wymagań konkretnego wydania SQL Server i całego środowiska, a nie wyłącznie z deklarowanej ilości pamięci w komputerze.