SQL Server 6.0

SQL Server 6.0 to wydanie z połowy lat dziewięćdziesiątych, jedno z pierwszych rozwijanych samodzielnie przez Microsoft.

SQL Server 6.0 na tle rozwoju serwerowych baz danych

SQL Server 6.0 był wydaniem systemu zarządzania relacyjnymi bazami danych firmy Microsoft z połowy lat dziewięćdziesiątych. Został przeznaczony przede wszystkim dla środowiska Windows NT i należał do generacji produktów, które miały zastąpić wcześniejszy model oparty na współpracy Microsoftu i firmy Sybase. Wersja 6.0 była ważnym etapem samodzielnego rozwoju SQL Server, ponieważ wprowadzała rozwiązania projektowane z myślą o platformie Microsoftu, a nie tylko przeniesione z wcześniejszych implementacji.

Silnik przechowywał dane w relacyjnych tabelach, a dostęp do nich odbywał się za pomocą języka Transact-SQL, czyli rozszerzenia SQL używanego przez SQL Server. W praktyce oznaczało to możliwość definiowania tabel, indeksów, ograniczeń, zapytań oraz procedur składowanych. SQL Server 6.0 nie był współczesną aplikacją instalowaną na komputerze użytkownika, lecz oprogramowaniem serwerowym przeznaczonym do obsługi wielu połączeń i wspólnego dostępu do danych przez aplikacje klienckie.

Budowa silnika i komunikacja z aplikacjami

SQL Server 6.0 pracował w architekturze klient-serwer. Program kliencki wysyłał zapytania do procesu serwera, a serwer wykonywał operacje na tabelach i zwracał wyniki. Taki model oddzielał interfejs użytkownika od miejsca przechowywania danych. Komputer z aplikacją nie musiał posiadać lokalnej kopii całej bazy, ponieważ odczyt i modyfikacja rekordów odbywały się po stronie serwera.

Do komunikacji wykorzystywano między innymi interfejsy charakterystyczne dla ówczesnego ekosystemu Microsoftu, takie jak DB-Library oraz ODBC. DB-Library był starszym interfejsem programistycznym używanym przez aplikacje łączące się z SQL Server, natomiast ODBC zapewniał bardziej ogólny sposób dostępu do relacyjnych baz danych za pomocą sterownika. Różnice między tymi warstwami miały znaczenie diagnostyczne: błąd połączenia mógł wynikać z konfiguracji klienta, niezgodnego sterownika, ustawień sieciowych albo samego procesu SQL Server.

Zarządzanie bazą w realiach SQL Server 6.0

Administrację środowiskiem ułatwiały narzędzia dostarczane razem z produktem, w tym SQL Enterprise Manager oraz narzędzia wiersza poleceń. SQL Enterprise Manager służył do wykonywania typowych czynności administracyjnych, takich jak przegląd obiektów bazy, zarządzanie użytkownikami, konfiguracja serwera i kontrolowanie podstawowych zadań. Narzędzia tekstowe pozwalały natomiast wykonywać polecenia Transact-SQL bezpośrednio, co było przydatne podczas testowania połączenia oraz sprawdzania działania silnika.

W tej wersji szczególne znaczenie miały poprawna konfiguracja plików baz danych, dostępnego miejsca na dysku oraz mechanizmów kopii zapasowych. Relacyjna baza danych składała się z wielu obiektów zależnych od siebie: tabel, indeksów, widoków, procedur składowanych i uprawnień. Samo uruchomienie procesu serwera nie oznaczało jeszcze, że aplikacja będzie działać poprawnie. Konieczne było sprawdzenie, czy baza jest dostępna, czy użytkownik ma odpowiednie uprawnienia, czy aplikacja korzysta z właściwego sterownika oraz czy zapytania odpowiadają składni obsługiwanej przez SQL Server 6.0.

Rozpoznawanie problemów ze starym środowiskiem

SQL Server 6.0 ma dziś znaczenie głównie historyczne i migracyjne. Oprogramowanie napisane dla tej wersji może korzystać ze starych bibliotek klienckich, nieaktualnych metod uwierzytelniania oraz składni Transact-SQL, która nie powinna być automatycznie utożsamiana z funkcjami późniejszych wydań SQL Server. Przy analizie takiego środowiska trzeba więc ustalić dokładną wersję serwera, wersję systemu operacyjnego, typ używanego interfejsu klienta oraz sposób przechowywania plików bazy.

Objaw w rodzaju „brak połączenia z bazą” nie wskazuje jednoznacznie na awarię dysku ani uszkodzenie tabel. Przyczyną może być zatrzymana usługa, nieprawidłowa nazwa instancji, niedostępny protokół komunikacyjny, błędny sterownik ODBC, brak uprawnienia użytkownika albo uszkodzenie pliku bazy. W przypadku tak starego oprogramowania ważne jest także zachowanie oryginalnego środowiska przed próbą naprawy: pochopna konwersja plików lub uruchomienie bazy w niezgodnej wersji może utrudnić odzyskanie danych i odtworzenie działania aplikacji.