SQL Server 6.5

SQL Server 6.5 to kolejne wydanie z lat dziewięćdziesiątych, poprzedzające istotną przebudowę silnika w wersji 7.0.

SQL Server 6.5 na tle architektury Microsoft SQL Server

SQL Server 6.5 był relacyjnym systemem zarządzania bazami danych przeznaczonym dla środowiska Microsoft Windows NT. Wydanie to pochodzi z drugiej połowy lat dziewięćdziesiątych i należy do generacji poprzedzającej SQL Server 7.0. Jego konstrukcja była jeszcze blisko związana z wcześniejszą linią kodu wywodzącą się z produktów Sybase, natomiast wersja 7.0 przyniosła znacznie głębszą przebudowę silnika. Z tego powodu dokumentacja, skrypty administracyjne i sposób organizacji plików z SQL Server 6.5 nie powinny być automatycznie utożsamiane z rozwiązaniami znanymi z nowszych wydań.

Serwer pracował jako usługa systemowa Windows NT i udostępniał bazy przez mechanizmy charakterystyczne dla ówczesnej architektury klient-serwer. Aplikacje mogły łączyć się między innymi za pośrednictwem bibliotek DB-Library, ODBC lub innych składników dostarczanych z systemem. W praktyce oznaczało to konieczność zgodności nie tylko samej aplikacji, lecz także sterownika, protokołu komunikacyjnego i konfiguracji instancji. Problemy z połączeniem mogły występować jeszcze przed wykonaniem zapytania, na przykład wskutek nieprawidłowej nazwy serwera, wyłączonej usługi albo niezgodnego klienta.

Bazy danych, urządzenia i segmenty w wersji 6.5

Jedną z ważnych cech SQL Server 6.5 był model przechowywania oparty na tak zwanych urządzeniach bazodanowych, czyli database devices. Urządzenie mogło wskazywać plik systemu Windows albo surowy obszar dysku przeznaczony na dane. Baza danych korzystała z przydzielonej przestrzeni urządzeń, a jej organizacja była dodatkowo opisywana przez segmenty. W dokumentacji i narzędziach administracyjnych spotyka się w tym kontekście między innymi tabele systemowe sysdevices, sysusages i sysdatabases w bazie master.

Taki sposób zarządzania przestrzenią różni się od modelu plików danych i plików dziennika znanego z późniejszych wersji SQL Server. Nie można więc bez sprawdzenia przenosić procedur dotyczących rozszerzania plików, grup plików lub automatycznego wzrostu z nowoczesnych instalacji do środowiska 6.5. Przy analizie starej bazy trzeba ustalić, które urządzenia zawierają dane, które przechowują dziennik transakcji oraz jak przypisano im segmenty. Błędne rozpoznanie tej struktury może prowadzić do nieprawidłowej oceny wolnego miejsca albo do próby użycia niewłaściwego polecenia administracyjnego.

Ważną rolę odgrywała baza master, ponieważ przechowywała informacje o serwerze, urządzeniach, bazach danych i konfiguracji. Uszkodzenie lub utrata tej bazy mogły uniemożliwić prawidłowe odtworzenie środowiska, nawet jeśli osobne urządzenia z danymi użytkownika nadal znajdowały się na dysku. Dlatego kopia zapasowa samej bazy użytkowej nie była pełnym obrazem konfiguracji serwera.

T-SQL, transakcje i odtwarzanie danych

SQL Server 6.5 obsługiwał język Transact-SQL, obejmujący instrukcje zapytań, modyfikowania danych, definiowania obiektów oraz sterowania transakcjami. W tym środowisku używano między innymi tabel, indeksów, widoków, procedur składowanych i wyzwalaczy. Składnia oraz dostępne opcje zależały jednak od konkretnej wersji serwera. Skrypt napisany dla SQL Server 2019 lub SQL Server 2022 nie musi działać w 6.5, ponieważ nowsze typy danych, funkcje, składnia i mechanizmy administracyjne nie były wtedy dostępne.

Integralną częścią pracy silnika był dziennik transakcji. Pozwalał on rejestrować zmiany i uczestniczył w przywracaniu spójności po awarii. Kopie zapasowe wykonywano poleceniami takimi jak DUMP DATABASE oraz DUMP TRANSACTION, a odtwarzanie realizowano za pomocą LOAD DATABASE i LOAD TRANSACTION. Są to polecenia charakterystyczne dla starszej linii SQL Server i nie należy zastępować ich bezpośrednio współczesnymi instrukcjami tylko dlatego, że dotyczą podobnego celu.

Do kontroli spójności można było wykorzystywać polecenia rodziny DBCC, w tym DBCC CHECKDB. Wynik takiego sprawdzenia należało interpretować razem z informacjami o urządzeniach, wolnym miejscu i stanie dziennika. Sam komunikat o błędzie nie wskazywał zawsze jednej przyczyny: podobne objawy mogły wynikać z uszkodzenia stron danych, problemu z nośnikiem, braku miejsca lub niepełnego odtworzenia kopii. W środowisku historycznym szczególnie ważne było zachowanie oryginalnych kopii przed wykonaniem operacji naprawczych.

Rozpoznawanie starej instalacji i bezpieczna diagnostyka

Diagnostykę SQL Server 6.5 rozpoczyna się od ustalenia systemu operacyjnego, wersji serwera, zainstalowanych poprawek, lokalizacji urządzeń oraz sposobu uruchamiania usługi. Należy sprawdzić dzienniki systemu Windows NT, komunikaty serwera i dostępność plików przypisanych do urządzeń. Istotne jest także rozróżnienie problemu silnika od problemu klienta: brak połączenia nie dowodzi jeszcze uszkodzenia bazy, jeżeli usługa nie działa, biblioteka klienta jest niezgodna albo konfiguracja sieciowa wskazuje niewłaściwy adres.

Przy migracji należy najpierw wykonać kopie bezpieczeństwa i zinwentaryzować obiekty zależne od starego środowiska: procedury składowane, wyzwalacze, indeksy, uprawnienia, zadania wsadowe oraz aplikacje korzystające z DB-Library lub ODBC. Nie powinno się zakładać, że fizyczne pliki urządzeń można po prostu podłączyć do nowej wersji serwera. Bezpieczniejsza procedura obejmuje odtworzenie bazy w zgodnym środowisku pośrednim, kontrolę spójności, eksport danych i test aplikacji po konwersji. W przeciwnym razie różnice w typach danych, sortowaniu, kodowaniu znaków i zachowaniu zapytań mogą ujawnić się dopiero podczas normalnej pracy.

W przypadku awarii komputera analiza powinna obejmować stan dysku, dostęp do plików urządzeń, kopie DUMP, bazę master oraz konfigurację usług. Nie należy kasować ani nadpisywać plików starej instalacji przed potwierdzeniem, że istnieje możliwa do odtworzenia kopia. SQL Server 6.5 jest dziś technologią historyczną, dlatego diagnostyka wymaga zachowania zgodności z jego własnym modelem administracyjnym, a nie mechanicznego stosowania instrukcji przygotowanych dla współczesnych wydań SQL Server.