Wersje 32-bitowe (starsze)

Starsze wersje 32-bitowe SQL Server są dziś przestarzałe — obecne wydania obsługują wyłącznie architekturę 64-bitową.

Architektura 32-bitowa w starszych wydaniach SQL Server

Wersje 32-bitowe SQL Server były przeznaczone dla systemów operacyjnych i procesorów korzystających z 32-bitowej przestrzeni adresowej. W praktyce oznaczało to, że pojedynczy proces serwera bazy danych mógł adresować znacznie mniej pamięci niż proces działający w środowisku 64-bitowym. Ograniczenie nie wynikało wyłącznie z ilości pamięci fizycznie zamontowanej w komputerze. Nawet gdy komputer miał więcej pamięci RAM, proces 32-bitowy nie mógł swobodnie wykorzystać całego zasobu, ponieważ jego adresy pamięci były reprezentowane za pomocą 32 bitów.

Starsze wydania SQL Server, między innymi SQL Server 2008 i SQL Server 2008 R2, występowały w wariantach dla architektury x86 oraz x64. Wariant x86 był przeznaczony dla 32-bitowego systemu Windows, natomiast wariant x64 wymagał 64-bitowego systemu operacyjnego. Nie były to jedynie dwa różne instalatory tej samej konfiguracji. Architektura wpływała na sposób uruchamiania procesu SQL Server, dostępny limit pamięci oraz możliwości wykorzystania zasobów sprzętowych.

Ograniczenia pamięci i wydajności procesu x86

Najważniejszym problemem starszej instalacji 32-bitowej był limit pamięci dostępnej dla procesu. W typowej 32-bitowej przestrzeni użytkownika system Windows udostępniał procesowi około 2 GB adresowalnej pamięci, choć dokładny zakres zależał od systemu operacyjnego, konfiguracji przełącznika /3GB oraz sposobu obsługi pamięci przez daną edycję SQL Server. Przełącznik /3GB mógł zwiększyć przestrzeń użytkownika w niektórych konfiguracjach 32-bitowego systemu Windows, ale zmniejszał obszar pamięci pozostający dla jądra systemu i nie usuwał podstawowych ograniczeń architektury x86.

SQL Server mógł wykorzystywać dodatkowe mechanizmy, takie jak AWE, czyli Address Windowing Extensions, aby mapować fragmenty pamięci fizycznej do ograniczonej przestrzeni adresowej procesu. AWE nie zmieniało jednak SQL Server w aplikację 64-bitową. Mechanizm wymagał odpowiedniej edycji systemu Windows, konfiguracji uprawnienia „Lock pages in memory” oraz właściwego ustawienia pamięci maksymalnej. Część pamięci pozostawała potrzebna dla samego procesu, sterowników i innych składników systemu, dlatego zwiększenie ilości RAM nie zawsze przekładało się na proporcjonalny wzrost wydajności.

Ograniczona przestrzeń adresowa była szczególnie odczuwalna przy dużych bazach, intensywnym buforowaniu stron danych, sortowaniu, tworzeniu indeksów i równoległym wykonywaniu zapytań. Gdy SQL Server nie miał wystarczającej ilości pamięci, częściej odczytywał dane z dysku, co zwiększało opóźnienia operacji wejścia i wyjścia. Problemy mogły dotyczyć także innych komponentów działających w tym samym procesie lub obciążających ten sam system, na przykład usług agenta, narzędzi administracyjnych albo sterowników dostępu do danych.

Kompatybilność systemu operacyjnego i aplikacji

Uruchomienie starego 32-bitowego SQL Server wymagało zgodności kilku elementów: wydania silnika, edycji systemu Windows, poziomu dodatku Service Pack, architektury procesora oraz sterowników używanych przez aplikacje klienckie. Sam fakt, że komputer miał procesor 64-bitowy, nie oznaczał jeszcze, że zainstalowana instancja SQL Server była 64-bitowa. O architekturze decydował zainstalowany wariant programu oraz system operacyjny, a nie wyłącznie model procesora.

W środowisku 64-bitowym możliwe było uruchamianie części starszych aplikacji 32-bitowych przez warstwę WOW64, ale nie oznaczało to automatycznej zgodności każdego wydania SQL Server. Silnik bazy danych, narzędzia konfiguracyjne, biblioteki Native Client, sterowniki ODBC oraz dostawcy OLE DB mogły mieć odrębne wymagania. Istotne było również rozróżnienie między aplikacją 32-bitową a serwerem bazy danych. Program kliencki x86 mógł łączyć się z instancją SQL Server działającą w wariancie x64, jeżeli dostępne były zgodne sterowniki i właściwy protokół połączenia.

Przy ocenie starej instalacji trzeba sprawdzić między innymi nazwę i wersję instancji, architekturę procesu sqlservr.exe, wersję systemu Windows, poziom aktualizacji oraz konfigurację pamięci. Pomocne są informacje zwracane przez właściwości serwera w SQL Server Management Studio, zapytania do widoków katalogowych oraz sprawdzenie wersji zainstalowanych składników. Nie należy zakładać, że migracja na komputer z większą ilością RAM sama usunie ograniczenia. Jeżeli pozostanie 32-bitowy silnik lub niezgodny sterownik, podstawowa przyczyna problemu nadal będzie obecna.

Przejście ze starszej instalacji x86 na środowisko 64-bitowe

Zmiana architektury SQL Server wymaga zaplanowania migracji, a nie prostego podmienienia pliku wykonywalnego. Przed rozpoczęciem prac należy zinwentaryzować bazy danych, konta logowania, zadania SQL Server Agent, certyfikaty, klucze szyfrujące, połączenia zewnętrzne, konfigurację usług oraz aplikacje korzystające z instancji. Kopia zapasowa bazy danych nie zawsze obejmuje wszystkie elementy konfiguracji instancji, dlatego procedura odtworzeniowa powinna uwzględniać również skrypty logowań, uprawnień, zadań i ustawień połączeń.

W zależności od wersji SQL Server oraz celu migracji można rozważyć aktualizację istniejącej instancji, migrację do nowej instancji 64-bitowej albo instalację równoległą i przeniesienie baz. Trzeba wtedy sprawdzić zgodność poziomu zgodności baz danych, aplikacji klienckich i sterowników. Po odtworzeniu baz należy zweryfikować integralność danych, dostęp użytkowników, działanie zadań automatycznych, połączenia aplikacji oraz wydajność zapytań. Sama zmiana na x64 nie gwarantuje poprawy, jeżeli wąskim gardłem pozostają dyski, indeksy, blokowanie transakcji, błędna konfiguracja pamięci lub nieoptymalne zapytania.

Starsza wersja 32-bitowa może nadal działać w zamkniętym środowisku, ale zwiększa zależność od historycznych systemów operacyjnych, sterowników i nieaktualnych narzędzi. Współczesne wydania SQL Server są dostarczane dla architektury 64-bitowej, ponieważ pozwala ona adresować znacznie większe zasoby pamięci i lepiej odpowiada obecnym serwerom oraz stacjom roboczym. Przy diagnostyce komputera, na którym działa lokalna, starsza instancja SQL Server, należy odróżnić problem samego silnika od problemu systemu Windows, aplikacji klienckiej i konfiguracji sprzętowej.