SQL Server 4.2 (Windows NT)

SQL Server 4.2 to wydanie tego serwera dla systemu Windows NT z pierwszej połowy lat dziewięćdziesiątych.

SQL Server 4.2 na tle Windows NT 3.1

SQL Server 4.2 dla Windows NT był wczesnym, serwerowym systemem zarządzania relacyjnymi bazami danych przeznaczonym dla 32-bitowego środowiska Windows NT. Wersja ta pojawiła się w 1993 roku, w okresie wprowadzania Windows NT 3.1 i Windows NT Advanced Server 3.1. W materiałach historycznych można spotkać również oznaczenie SQL Server 4.21 dla NT, odnoszące się do wydania przygotowanego specjalnie dla tej platformy. Nie należy utożsamiać go bezpośrednio z późniejszymi wersjami SQL Server 6.0, 6.5 czy 7.0, ponieważ tamte wydania miały już inny zakres zmian i odmienny etap rozwoju produktu.

Rozwój SQL Server 4.2 wywodził się ze współpracy Microsoftu i firmy Sybase nad serwerem baz danych dla systemu OS/2. Wydanie przeznaczone dla Windows NT stanowiło przeniesienie tego środowiska do systemu operacyjnego wykorzystującego architekturę Win32. Była to technologia klasy serwerowej, a nie program biurowy instalowany wyłącznie na komputerze użytkownika. Jej zadaniem było obsługiwanie współbieżnego dostępu wielu aplikacji klienckich do centralnie przechowywanych danych.

Relacyjny silnik, język Transact-SQL i praca klient-serwer

SQL Server 4.2 przechowywał dane w relacyjnych tabelach z kolumnami i wierszami, a dostęp do nich odbywał się za pomocą języka SQL rozwijanego przez Microsoft i Sybase jako Transact-SQL. Administrator lub programista mógł definiować tabele, indeksy oraz zapytania, a także wykonywać operacje wstawiania, aktualizacji, usuwania i odczytu rekordów. W środowisku tego wydania stosowano również procedury składowane, czyli zapisane po stronie serwera zestawy instrukcji wykonywanych na żądanie klienta.

Model klient-serwer oznaczał rozdzielenie programu użytkownika od procesu obsługującego bazę. Aplikacja kliencka wysyłała polecenia do serwera SQL, a serwer analizował zapytanie, odczytywał odpowiednie strony danych i zwracał wynik. Taki sposób pracy ograniczał potrzebę kopiowania całych plików bazy na stację roboczą. W praktyce wymagał jednak zgodności biblioteki klienckiej, sterownika, protokołu komunikacyjnego, nazwy serwera oraz konfiguracji konta używanego do połączenia.

Integracja z zabezpieczeniami i ograniczenia epoki

Jedną z istotnych cech wydania dla Windows NT była możliwość powiązania dostępu do SQL Server z mechanizmami bezpieczeństwa systemu Windows NT. W określonych konfiguracjach użytkownicy mogli korzystać z kont i uprawnień zarządzanych przez system operacyjny, zamiast utrzymywać całkowicie niezależne hasła tylko dla serwera SQL. Nie oznaczało to współczesnego modelu wieloskładnikowego uwierzytelniania ani nowoczesnego zarządzania tożsamością. Był to mechanizm właściwy dla ówczesnego środowiska domenowego i lokalnych baz kont Windows NT.

SQL Server 4.2 należy traktować jako produkt historyczny, którego nie można bezpośrednio oceniać według funkcji znanych z obecnych edycji SQL Server. Nie oferował późniejszych mechanizmów, takich jak współczesne metadane systemowe, rozbudowane narzędzia administracyjne, usługi raportowe, grupy dostępności, szyfrowanie przezroczyste czy współczesne sterowniki komunikacyjne. Instalacja na aktualnym Windows zwykle nie jest praktycznym rozwiązaniem ze względu na niezgodność systemu, formatów instalacyjnych, sterowników i zabezpieczeń. Przy analizie starej aplikacji trzeba więc ustalić dokładne wydanie serwera, system operacyjny, sposób komunikacji oraz format kopii zapasowej.

Postępowanie z historyczną instalacją SQL Server 4.2

Diagnostyka działającego środowiska powinna rozpocząć się od zebrania informacji bez modyfikowania plików bazy. Należy ustalić, czy serwer rzeczywiście pracuje na Windows NT, jaki ma numer wydania, gdzie znajdują się pliki danych i dzienniki transakcji oraz które aplikacje korzystają z połączenia. Ważne jest również rozróżnienie problemu samego silnika od problemu warstwy klienckiej. Błąd logowania może wynikać z nieistniejącego konta, złego trybu uwierzytelniania, niedostępnej usługi albo niezgodnej biblioteki sieciowej, a nie z uszkodzenia tabel.

W przypadku awarii należy zachować oryginalne pliki i najpierw wykonać ich kopię sektorową lub kopię na poziomie plików, o ile stan systemu na to pozwala. Nie powinno się uruchamiać przypadkowych narzędzi naprawczych ani konwertować bazy do nowszego formatu bez sprawdzenia możliwości odtworzenia. Weryfikacja powinna obejmować dzienniki systemu Windows NT, komunikaty usługi SQL Server, dostępność woluminów, stan miejsca na dysku oraz możliwość odczytu kopii zapasowej. Przy migracji dane trzeba eksportować kontrolowanie, sprawdzając kodowanie znaków, typy danych, indeksy, procedury składowane i zależności aplikacji, ponieważ bezpośrednie podłączenie historycznych plików do współczesnego silnika nie jest gwarantowane.