SQL Server Workgroup Edition (starsze wersje)

Workgroup Edition to wycofana już, uboższa funkcjonalnie edycja SQL Server dla mniejszych organizacji.

Zakres edycji Workgroup w SQL Server 2008

SQL Server Workgroup Edition była jedną z edycji Microsoft SQL Server 2008 oraz SQL Server 2008 R2. Przeznaczono ją do obsługi mniejszych instalacji bazodanowych, między innymi aplikacji oddziałowych, lokalnych systemów ewidencyjnych i niewielkich baz używanych przez kilka stanowisk. Nie była osobnym silnikiem baz danych, lecz ograniczoną edycją tego samego produktu SQL Server Database Engine. Oznacza to, że korzystała z relacyjnego modelu danych, języka Transact-SQL, tabel, indeksów, widoków, procedur składowanych, wyzwalaczy oraz transakcji.

W praktyce możliwości Workgroup zależały od konkretnej wersji głównej, dodatku Service Pack, zainstalowanych składników oraz systemu operacyjnego. Sama nazwa edycji nie określa jeszcze, czy na serwerze działały dodatkowe komponenty, takie jak Reporting Services lub narzędzia administracyjne. Podczas sprawdzania starej instalacji należy odczytać pełną nazwę produktu i numer kompilacji, na przykład za pomocą zapytania SELECT @@VERSION; albo właściwości serwera w SQL Server Management Studio. Pozwala to odróżnić SQL Server 2008 od SQL Server 2008 R2 i nie przypisywać instalacji funkcji dostępnych dopiero w innej wersji.

Silnik relacyjny, dane i typowe zastosowania

Podstawowym zadaniem Workgroup Edition było przechowywanie i przetwarzanie danych w silniku relacyjnym. Administrator mógł tworzyć bazy, definiować schematy, klucze główne i obce, ograniczenia integralności oraz indeksy. Aplikacje łączyły się z instancją przy użyciu sterowników Microsoft, między innymi przez interfejsy ADO.NET, ODBC lub OLE DB, zależnie od używanego programu. Uprawnienia mogły być nadawane na poziomie logowania, użytkownika bazy, schematu i obiektu, z wykorzystaniem ról oraz poleceń Transact-SQL takich jak CREATE LOGIN, CREATE USER i GRANT.

Ważnym mechanizmem pozostawały transakcje i dziennik transakcji. SQL Server zapisywał zmiany w logu przed ich trwałym zatwierdzeniem, dzięki czemu mógł odtwarzać spójność bazy po awarii procesu lub systemu. Do podstawowej obsługi należały kopie pełne, różnicowe i dziennika transakcji, o ile konfiguracja oraz model odzyskiwania bazy na to pozwalały. Polecenia BACKUP DATABASE, BACKUP LOG i RESTORE DATABASE dotyczą właśnie silnika SQL Server; nie należy zastępować ich kopiowaniem samego pliku .mdf, ponieważ taki plik może być niespójny z logiem i pozostałymi plikami bazy.

Ograniczenia funkcjonalne i ocena starej instalacji

Workgroup była pozycjonowana niżej od edycji Standard i Enterprise, dlatego nie zapewniała pełnego zestawu funkcji przeznaczonych do dużych środowisk. Różnice dotyczyły między innymi skalowania obciążenia, zaawansowanych mechanizmów wysokiej dostępności, rozbudowanych funkcji analitycznych oraz wybranych możliwości zarządzania. Konkretna macierz obsługiwanych funkcji zmieniała się między SQL Server 2008 i SQL Server 2008 R2, więc przy planowaniu migracji trzeba porównać dokładną edycję, wersję i wykorzystywane komponenty, a nie tylko nazwę SQL Server.

Diagnozę istniejącej instalacji warto rozpocząć od sprawdzenia usługi silnika, dziennika SQL Server, wolnego miejsca na woluminach z plikami danych i logów oraz stanu kopii zapasowych. Przydatne są widoki dynamiczne, takie jak sys.databases, sys.master_files i sys.dm_exec_requests. Pozwalają ustalić, jakie bazy istnieją, gdzie znajdują się ich pliki, czy baza jest w stanie ONLINE oraz czy w chwili kontroli występują oczekujące żądania. Warto również sprawdzić integralność poleceniem DBCC CHECKDB, po uprzednim uwzględnieniu obciążenia serwera i czasu potrzebnego na wykonanie kontroli.

Znaczenie wersji i bezpiecznej migracji danych

SQL Server 2008 zakończył podstawowy i rozszerzony okres wsparcia 9 lipca 2019 roku, a SQL Server 2008 R2 9 lipca 2019 roku. Workgroup Edition należy więc traktować jako rozwiązanie historyczne, które może nadal występować w starszym programie, na nieaktualnym serwerze lub w środowisku utrzymującym kompatybilność z dawną aplikacją. Brak wsparcia nie oznacza automatycznie uszkodzenia bazy, ale zwiększa znaczenie kopii zapasowych, testów odtwarzania i kontroli zgodności z nowszym systemem operacyjnym.

Przed migracją należy zinwentaryzować rozmiary baz, używane poziomy zgodności, konta, połączenia aplikacyjne, zadania, harmonogramy oraz zależności między bazami. Następnie trzeba wykonać kopię zapasową i sprawdzić jej odtworzenie w środowisku testowym. Przeniesienie do nowszej edycji SQL Server może wymagać aktualizacji sterowników, zmiany ustawień bezpieczeństwa, weryfikacji zapytań oraz przetestowania kodu aplikacji. Sama zmiana pliku wykonywalnego lub skopiowanie katalogu instalacyjnego nie jest prawidłową metodą migracji relacyjnej bazy danych.