Poza tworzeniem nowych i obsługiwaniem już istniejących baz danych, do podstawowych zadań każdego administratora SQL Server należy również instalowanie i konfigurowanie nowych instancji serwera SQL Server na serwerach fizycznych lub wirtualnych. Jak to jednak zwykle bywa w przypadku złożonych i profesjonalnych systemów serwerowych, najważniejszą, a niekiedy również najtrudniejszą fazą w procesie ich wdrażania jest faza planowania, która rozpoczyna się na długo przed tym, zanim jeszcze przystąpimy do etapu instalacji takiego oprogramowania w naszym środowisku. Nie inaczej jest w przypadku systemu zarządzania bazą danych SQL Server, który uchodzi za jeden z bardziej skomplikowanych i dosyć rozbudowanych produktów serwerowych, jakie dostępne są obecnie na rynku.

Zanim więc przystąpimy do instalacji jakiejkolwiek instancji serwera SQL Server, musimy dokładnie zaplanować, z jakich funkcji systemu SQL Server będziemy korzystać. To z kolei wiąże się z koniecznością dogłębnego zapoznania się z dostępnymi wersjami tego produktu i ich poszczególnymi edycjami, a także sposobem licencjonowania, wymaganiami i kosztami każdej z nich. To oczywiście tylko jedna strona medalu, bo powinniśmy jeszcze dobrze poznać obecne i przewidzieć przyszłe potrzeby naszego biznesu, specyfikacje i możliwości posiadanego sprzętu oraz wykorzystywane oprogramowanie. Po takiej dogłębnej analizie może się przecież okazać, że wcale nie potrzebujemy lokalnej instancji serwera bazy danych, gdyż przykładowo znacznie lepsze będzie wydelegowanie bazodanowych obciążeń do ogólnodostępnego rozwiązania w chmurze, takiego jak choćby baza danych SQL w Microsoft Azure. Niewykluczone też, że system SQL Server wcale nie jest tym, czego tak naprawdę potrzebujemy, bo charakter i możliwości tego produktu znacznie przewyższają lub w ogóle nie spełniają naszych oczekiwań.

Należy bowiem zwrócić uwagę, że w przeciwieństwie do bazy danych Microsoft Access, która jest produktem samowystarczalnym, zintegrowanym i w pełni zamkniętym, ze ściśle powiązanymi komponentami do przechowywania, zarządzania i raportowania danych, system SQL Server ma nieco inny charakter i stanowi zbiór współpracujących ze sobą, ale mimo wszystko niezależnych usług systemowych, które możemy rozproszyć po wielu fizycznych lub wirtualnych serwerach. Z założenia więc bazy danych SQL Server nie są obsługiwane przez użytkowników końcowych wprost, lecz mają służyć za tzw. wewnętrzną bazę danych (ang. backend) dla dwu- lub wielowarstwowych aplikacji biznesowych, obsługiwanych przez dedykowany interfejs użytkownika.

Edycje i funkcje systemu SQL Server

W zależności od wybranej wersji systemu SQL Server, do rozważenia będziemy mieć od kilku do kilkunastu edycji tego produktu, z których każda oferuje nieco inny zestaw funkcji, ma nieco inne przeznaczenie, a przy tym cechuje się określonymi ograniczeniami i nierzadko wpisuje się w inny model licencjonowania. Jednym z podstawowych kroków fazy planowania będzie więc przegląd dostępnych edycji wybranej wersji produktu SQL Server. Szczegółowy wykaz edycji oraz przegląd dostępnych w nich funkcji wraz z objaśnieniem dostępnych modeli licencjonowania znajduje się w osobnym artykule.

Wymagania sprzętowe

W ramach fazy planowania wdrożenia systemu SQL Server w naszym środowisku docelowym musimy wziąć pod uwagę również to, które z komponentów i funkcji zamierzamy zainstalować i wykorzystywać. W środowisku testowym liczba i rodzaj zainstalowanych na serwerze funkcji nie ma praktycznie żadnego znaczenia, więc będziemy zazwyczaj dokonywać pełnej instalacji tego systemu. W środowisku produkcyjnym instalacja wszystkich dostępnych w ramach nabytej licencji funkcji systemu SQL Server również może wydawać się dobrym rozwiązaniem, bo po pierwsze zapłaciliśmy za nie, a pod drugie dzięki temu w razie potrzeby będą one od razu dostępne, jednak z podejścia tego należy stanowczo zrezygnować. W procesie instalacji serwera SQL Server powinniśmy uwzględnić tylko te jego składniki, z których faktycznie będziemy korzystać. Powodów, dla których należy trzymać się tej zasady jest kilka, z czego dwa najważniejsze są następujące:

• Po pierwsze, mniejsza liczba funkcji to przede wszystkim mniejsza powierzchnia ataku. Jako że bezpieczeństwo oprogramowania (czy bezpieczeństwo w ogóle) jest z definicji pojęciem względnym, a tym samym dowolny komponent serwera może być względem innego komponentu mniej lub bardziej bezpieczny, ale nigdy w pełni bezpieczny, redukujemy w ten sposób potencjalne luki w kodzie, przez które atakujący mógłby uzyskać niepowołany dostęp do serwera lub co gorsza do przechowywanych w nim danych.
• Po drugie, mniejsza liczba uruchomionych w tle komponentów to mniejsze obciążenie i wykorzystanie zasobów serwera, a tym samym podwyższona wydajność dla funkcji i usług faktycznie przez nas wykorzystywanych.

Jak każde inne oprogramowanie, SQL Server do swojego działania potrzebować będzie określonych zasobów systemowych, których rodzaj i ilość uzależnione będą od wybranych podczas instalacji komponentów i obsługiwanych przez nie obciążeń. W przypadku produktu SQL Server interesować nas będą trzy podstawowe rodzaje zasobów systemowych: moc obliczeniowa, pamięć oraz magazyn danych (nazywany również podsystemem wejścia/wyjścia). W przypadku instalacji serwera bazy danych w środowisku małej organizacji lub wydziału, usługa silnika bazy danych może być zainstalowana wraz z innymi aplikacjami i usługami uruchomionymi na tym samym serwerze, z którymi współdzielić będzie dostępne zasoby sprzętowe. W bardziej złożonych środowiskach serwer bazy danych będzie zazwyczaj serwerem dedykowanym konkretnej instancji serwera, tak aby udostępniał on jej wszystkie swoje zasoby sprzętowe.

Wymagania procesora

Aby na danej maszynie możliwe było zainstalowanie dowolnej instancji serwera SQL Server, musi ona spełniać podstawowe wymagania minimalne co do obecnego w niej procesora. Wymagania te są jednak na tyle niskie, że dziś na rynku trudno raczej będzie znaleźć komputer, nawet tani komputer mobilny, który nie spełniałby tych warunków. W kwestii mocy obliczeniowej system SQL Server do poprawnego działania wymaga komputera wyposażonego co najmniej w pojedynczy i jednordzeniowy procesor fizyczny o częstotliwości taktowania na poziomie 1 GHz lub wyższej (w przypadku architektury x86 - tylko starsze wersje SQL Server), lub o częstotliwości taktowania 1,4 GHz lub wyższej (w przypadku architektury x64). Tyle, jeśli chodzi o dolną granicę mocy obliczeniowej pozwalającą na pomyślne zainstalowanie i swobodną pracę silnika bazy danych SQL Server.

Korzystanie z systemu SQL Server, a w szczególności z jego silnika bazy danych, sprowadza się w większości przypadków do wykonywania odpowiednich zapytań w zakresie manipulacji danymi, które w zależności od swojej złożoności i ilości pozyskiwanych danych generować będą mniejsze lub większe obciążenia na serwerze. Jedynym więc realistycznym testem pozwalającym trafnie określić wymaganą moc obliczeniową dla konkretnego środowiska jest użycie tego systemu na docelowych danych, zebranie odpowiednich informacji i wyciągnięcie na tej podstawie odpowiednich wniosków co do ewentualnego przeskalowania serwera.

Aby zmaksymalizować wydajność serwera bazy danych, instancja SQL Server powinna zostać zainstalowana na dedykowanym serwerze fizycznym lub wirtualnym, bez żadnych dodatkowych aplikacji czy usług. SQL Server zyska sporo na wydajności na maszynach wieloprocesorowych i wielordzeniowych, nawet jeśli wykonywane przez nas zapytania nie są zoptymalizowane pod kątem współbieżności. Przykładowo na maszynie wieloprocesorowej nawet proste operacje wydobywania danych pochodzące od różnych użytkowników mogą wykonywać się jednocześnie. Wsparcie dla wielu procesorów fizycznych to w większości przypadków również wsparcie dla architektury NUMA, która w przeciwieństwie do systemów bazujących na przetwarzaniu symetrycznym SMP cechuje się oddzielnymi magistralami pamięci pomiędzy poszczególnymi gniazdami procesora i dedykowanymi im bankami pamięci, tworząc w ten sposób tzw. węzły NUMA będące w zasadzie odrębnymi systemami SMP. Systemy SQL Server i Windows Server zawierają wsparcie dla architektury NUMA i potrafią wykorzystywać jej możliwości.

Wymagania pamięci

SQL Server 2016 dostępny jest już wyłącznie w wersji 64-bitowej, więc całkowicie odpada nam problem związany z ograniczeniem widoczności przestrzeni adresowej pamięci do 4 GB (pozostała pamięć poza tym obszarem pozyskiwana była w systemach 32-bitowych w ramach rozszerzeń Address Windowing Extensions). Aby mieć pewność, że nasza instancja będzie w stanie wykorzystać całą dostępną pamięć operacyjną, należy dokonać wyboru odpowiedniej edycji systemu SQL Server.

Na ogół SQL Server wykorzystuje tylko niewielką ilość dostępnej pamięci, jako że wszystkie dane znajdujące się w spoczynku (nie licząc tabel optymalizowanych pod kątem pamięci) przechowywane są stale na dysku. W zależności od złożoności zapytań i rozmiaru dostępnych danych zapotrzebowanie na pamięć będzie odpowiednio rosnąć, a poprawne oszacowanie niezbędnej ilości pamięci będziemy mogli określić wyłącznie drogą testów.

Wymagania magazynu danych

Podawane w dokumentacji technicznej minimalne wymagania dotyczące przestrzeni dyskowej dotyczą oczywiście wyłącznie instalacji podstawowych komponentów systemu SQL Server i nie uwzględniają przy tym miejsca potrzebnego do przechowywania danych użytkownika. Warto podkreślić, że wydajność systemu SQL Server praktycznie w całości uzależniona jest od wydajności podsystemu wejścia/wyjścia, tak więc to właśnie magazyn danych będzie podstawowym komponentem systemu, który powinniśmy sobie dobrze zaplanować i przetestować przed wdrożeniem do niego serwera bazy danych. W ramach fazy planowania magazynu danych powinniśmy dobrze poznać wymagania aplikacji korzystającej z bazy danych, wliczając w to częstotliwość i rozmiary odczytów i zapisów, jakie wysyłane będą do serwera. W przypadku systemów OLTP aplikacje te produkować będą wysoką liczbę losowych operacji wejścia/wyjścia w plikach zawierających właściwe dane oraz sekwencyjne operacje zapisu w plikach dziennika transakcji bazy danych. Z kolei aplikacje korzystające z systemów OLAP oraz hurtowni danych będą zamiast tego dokonywać znaczących operacji skanowania na plikach danych.

Jeśli zdecydujemy się na zainstalowanie serwera SQL Server w obrębie lokalnego magazynu danych zrealizowanego w ramach dysków przyłączonych bezpośrednio (Directly Attached Storage, DAS), należy pamiętać, że SQL Server lepiej radzić sobie będzie na systemie złożonym z kilku mniejszych dysków niż z pojedynczego dysku o dużej pojemności. Pojedynczy dysk cechować się będzie stosunkowo niską liczbą operacji wejścia/wyjścia, co prawdopodobnie nie pozwoli nam osiągnąć zadowalającej wydajności serwera. Idealnymi dyskami w takim przypadku będą więc talerzowe dyski SAS o wysokich prędkościach obrotowych lub dyski półprzewodnikowe SSD połączone w macierz RAID na poziomie 1,5 lub 10.

Jeśli jednak nasze dane zamierzamy trzymać w ramach magazynu zrealizowanego w oparciu o sieć SAN, wówczas po sprecyzowaniu przez nas odpowiedniego poziomu wydajności, jaki chcielibyśmy osiągnąć, szczegółami implementacji i konfiguracji takiego magazynu w większości przypadków zajmie się administrator sieci SAN.

Narzędzia oceny wydajności magazynu danych

Microsoft oferuje nam dwa niewielkie narzędzia pozwalające na dosyć sprawne oszacowanie możliwości posiadanego przez nas magazynu danych. Pierwszym narzędziem jest SQLIOSim, który symuluje aktywność operacji wejścia/wyjścia generowaną przez system SQL Server. Narzędzie to nie jest oficjalnie wspierane przez Microsoft, jednak jego podstawową zaletą jest to, że nie wymaga instalacji serwera SQL Server, dzięki czemu możemy nim przeegzaminować docelowy magazyn jeszcze przed zainstalowaniem jakiejkolwiek instancji serwera bazy danych. Narzędziem tym możemy sterować zarówno z poziomu wiersza poleceń, jak i z poziomu graficznego interfejsu użytkownika. Co więcej, nie wymaga ono instalacji w systemie i jest gotowe do uruchomienia bezpośrednio po skopiowaniu go ze strony Microsoft. Należy jednak podkreślić, że narzędzie to stanowi jedynie losowo realizowaną symulację, której wyniki w żaden sposób nie mogą stanowić podstawy do końcowej oceny wydajności testowanego magazynu danych.

Uzupełnieniem tego programu, swoją drogą również niewspieranym przez Microsoft, jest narzędzie SQLIO. W przeciwieństwie do programu SQLIOSim narzędzie to dokonuje powtarzalnych testów w zakresie operacji wejścia/wyjścia, zgodnie z opracowanym przez nas plikiem konfiguracyjnym, z którego jeden po drugim odczytywane i wykonywane są poszczególne rodzaje operacji.

Tym samym najlepiej jest korzystać z obu tych narzędzi. Program SQLIOSim umożliwi nam rozpoznanie słabych stron naszego magazynu, zaś program SQLIO pozwoli nam je dokładnie przetestować.

Wymagania programowe

Choć SQL Server może zostać z powodzeniem zainstalowany na klienckim systemie operacyjnym takim jak Windows 7 czy Windows 10, jest to produkt projektowany specjalnie z myślą o serwerowych wariantach Windows, takich jak Windows Server 2008, Windows Server 2012 i Windows Server 2016. To, którego konkretnie systemu należy użyć jako podstawy dla serwera bazy danych, zależeć będzie głównie od wersji i edycji tego serwera. Wyższe edycje SQL Server wymagają zazwyczaj wyższych edycji systemu Windows Server. Dokładna lista systemów dla poszczególnych edycji dostępna jest w dokumentacji technicznej systemu SQL Server 2016.

Instalacji serwera SQL Server można również dokonać na kontrolerze domeny, jednak Microsoft zdecydowanie odradza nam tę czynność, jako że nie będziemy wówczas mogli uruchamiać usług SQL Server w kontekście kont lokalnych lub sieciowych. Co więcej, instalacja serwera SQL Server uniemożliwi nam podwyższenie serwera członkowskiego do poziomu kontrolera domeny lub zdegradowanie go z poziomu kontrolera domeny do serwera członkowskiego, a w przypadku kontrolera domeny tylko do odczytu instalacja w ogóle nie powiedzie się, jako że instalator nie będzie w stanie utworzyć odpowiednich grup zabezpieczeń.

SQL Server do swojego działania wymaga również pewnych komponentów zewnętrznych, określanych mianem oprogramowania wstępnego. Obecne wersje systemu SQL Server nie instalują już automatycznie tak dużej ilości oprogramowania wstępnego, jak miało to miejsce w starszych wersjach. Zamiast tego instalator przyjmuje, że odpowiednie komponenty, takie jak choćby powłoka PowerShell czy środowisko .NET Framework, są już w systemie obecne, zaś w razie ich braku użytkownik proszony jest o ich ręczne uzupełnienie i niekiedy powtórne rozpoczęcie procesu instalacji. Jako że niektóre z tych komponentów po instalacji w systemie wymagają zazwyczaj jego ponownego uruchomienia, w celu maksymalnego skrócenia czasu instalacji serwera SQL Server dobrze jest zainstalować wcześniej całe niezbędne oprogramowanie wstępne, w szczególności środowisko instalacyjne Windows Installer 4.5 lub nowsze.

Konta usług SQL Server

Podobnie jak przed instalacją planujemy wybór poszczególnych funkcji SQL Server do zainstalowania, warto również rozplanować sobie w naszym środowisku poszczególne konta użytkowników, w kontekście których wykonywane będą działające usługi serwera bazy danych. Konta te poświadczać będą wymaganą w środowisku Windows tożsamość dla poszczególnych usług, za pomocą której będą one uzyskiwać dostęp do zasobów serwera. Choć SQL Server wiele swoich komponentów pozwala obsługiwać z poziomu jednego konta o odpowiednio rozbudowanych uprawnieniach, to jednak w idealnym przypadku powinniśmy się mocno trzymać zasady najmniejszego uprzywilejowania i każdą odrębną usługę uruchamiać i wykonywać w kontekście osobnego konta użytkownika z minimalnymi uprawnieniami i prawami w systemie. Dzięki temu nawet jeśli pojedyncze konto zostanie skompromitowane, to ewentualnie poczynione szkody zostaną ograniczone wyłącznie do tej jednej usługi.

Planowanie wdrożenia systemu SQL Server

Przed zdefiniowaniem i wyborem konkretnych kont użytkownika dla poszczególnych usług serwera bazy danych warto zapoznać się z dostępnymi typami kont oraz dzielącymi je różnicami. Każde takie konto musi dysponować pewnymi uprawnieniami wymaganymi do obsługi konkretnej usługi serwera, przy czym nie należy stosować w tym celu kont administratora lub jakichkolwiek innych kont wyposażonych w nadmierną ilość uprawnień. Zgodnie ze wspomnianą już zasadą najmniejszego uprzywilejowania konto usługi powinno mieć nadane wyłącznie te uprawnienia, które pozwolą danej usłudze na jej poprawną interakcję z systemem i umożliwią jej swobodne wykonywanie pracy.

Proces wyboru konta użytkownika dla poszczególnych usług systemu SQL Server jest bardzo prosty i polega jedynie na wskazaniu istniejącego konta użytkownika podczas instalacji instancji serwera SQL Server lub w dowolnym innym momencie z wykorzystaniem narzędzia SQL Server Configuration Manager. Takie powiązanie wybranego konta z konkretną usługą spowoduje automatyczne umieszczenie tego konta w odpowiedniej grupie zabezpieczeń z uprawnieniami odpowiednimi dla tej usługi. Jako konto dla usług SQL Server możemy wybrać:

• konto użytkownika w domenie - konto zwykłego użytkownika odpowiednie dla usług działających w środowisku domenowym
• konto użytkownika lokalnego - konto zwykłego użytkownika odpowiednie dla usług działających w środowiskach bezdomenowych, takich jak sieci obwodowe
• konto usługi lokalnej - predefiniowane konto usługi z ograniczonymi uprawnieniami umożliwiającymi uzyskiwanie dostępu do wyłącznie lokalnych zasobów. Jeszcze do niedawna było to najczęściej wykorzystywane konto przez usługi i aplikacje działające w systemie Windows, które nie wymagają dostępu do zasobów zdalnych. Obecnie jednak zaleca się wykorzystywanie wirtualnych kont usługi.
• konto usługi sieciowej - konto zbliżone do konta usługi lokalnej, przy czym dysponuje ono znacznie mniejszymi uprawnieniami, ale za to z możliwością uzyskania dostępu do zasobów zdalnych. Nie zaleca się jego stosowania, jako że z jednego takiego konta korzysta zazwyczaj więcej niż jedna usługa.
• zarządzane konto usługi - rodzaj konta wprowadzony w systemach Windows Server 2008 R2 i Windows 7, wspierane od wersji SQL Server 2012. Konto zbliżone do konta domenowego i powiązane z konkretnym serwerem. Umożliwia zarządzanie usługami, a przy tym pozbawione jest możliwości logowania do serwera, przez co jest bezpieczniejsze. Konto to nie wymaga od nas ręcznego tworzenia hasła, ale musi ono uprzednio zostać utworzone i skonfigurowane przez administratora domeny.
• wirtualne konto usługi - rodzaj konta wprowadzony w nowszych systemach Windows oraz w systemie SQL Server 2012. Konto zbliżone do zarządzanego konta usługi, przy czym jest to wariant konta lokalnego do zarządzania usługami, nie zaś konta domenowego. Jako że konto to jest zwirtualizowaną instancją wbudowanego konta usługi sieciowej z własnym identyfikatorem, administrator nie musi go uprzednio tworzyć i konfigurować.
• konto systemu lokalnego - konto systemowe o wysokim poziomie uprawnień wykorzystywane przez liczne usługi systemu Windows. Konto to nie powinno być wykorzystywane przez usługi SQL Server.