SQL 2017 Server — przewodnik 2026

Q: Jak sprawdzić aktualny poziom Cumulative Update w mojej instancji?

Wykonaj zapytanie `SELECT @@VERSION` lub sprawdź pierwszą wartość w wynikach `SELECT SERVERPROPERTY('ProductUpdateLevel')`. Najnowszy CU dla SQL Server 2017 dostępny jest w Microsoft Update Catalog i w 2026 roku nosi oznaczenie CU31 z poprawkami bezpieczeństwa wydanymi poza cyklem zbiorczym.

SQL Server 2017 to wydanie, które na trwałe zapisało się w historii platformy Microsoft — głównie za sprawą pełnego wsparcia dla systemu Linux, kontenerów Docker oraz znaczącego skoku wydajnościowego w zakresie przetwarzania zapytań analitycznych. Mimo że od premiery minęło kilka lat, w 2026 roku wciąż wiele organizacji — zwłaszcza tych działających w sektorze publicznym, przemyśle oraz średnich przedsiębiorstwach — utrzymuje swoje środowiska właśnie na tej wersji. Powody są pragmatyczne: stabilność, przewidywalny cykl poprawek bezpieczeństwa w ramach rozszerzonego wsparcia oraz kompatybilność z dziesiątkami aplikacji lini biznesowych, których migracja na nowsze wydania wymagałaby kosztownych projektów refaktoryzacyjnych.

Poniższy przewodnik dostarcza aktualnych, sprawdzonych w 2026 roku informacji na temat wdrażania, konfiguracji, strojenia wydajności oraz najczęstszych problemów eksploatacyjnych SQL Server 2017. Skupiamy się na praktyce: znajdziesz tu konkretne parametry, skrypty diagnostyczne i wskazówki, które możesz zastosować natychmiast — niezależnie od tego, czy zarządzasz pojedynczą instancją na Windows Server 2022, czy farmą kontenerów linuxowych orkiestrowaną przez Kubernetesa.

Stan wsparcia i cykl życia w 2026 roku

SQL Server 2017 wszedł w fazę rozszerzonego wsparcia (Extended Support) 11 października 2022 roku. Zakończenie głównego nurtu (Mainstream Support) oznaczało koniec darmowych aktualizacji funkcjonalnych, ale Microsoft kontynuuje dostarczanie krytycznych poprawek bezpieczeństwa oraz zbiorczych aktualizacji (Cumulative Updates) dla klientów posiadających aktywną umowę Software Assurance lub subskrypcję (na przykład w modelu Azure Arc-enabled SQL Server).

W 2026 roku końcowa data rozszerzonego wsparcia — 12 października 2027 roku — jest już na horyzoncie. Oznacza to, że organizacje wciąż polegające na SQL Server 2017 powinny mieć opracowaną strategię migracji. Najczęściej rozważane ścieżki to: przejście na SQL Server 2022 (zgodność na poziomie bazy danych 140 pozwala na stopniową migrację), modernizacja do Azure SQL Managed Instance z wykorzystaniem Azure Migrate, bądź — w przypadku obciążeń kontenerowych — ewaluacja SQL Server 2025 dostępnego od niedawna w repozytoriach Microsoftu.

Warto pamiętać, że w ramach Extended Security Updates (ESU) Microsoft może zaoferować dodatkowy, płatny okres poprawek bezpieczeństwa wykraczający poza 2027 rok — podobnie jak miało to miejsce dla Windows Server 2008 i SQL Server 2012. Decyzje o ewentualnym przedłużeniu ogłaszane są zwykle na 12–18 miesięcy przed końcem wsparcia, więc w połowie 2026 roku warto monitorować oficjalne kanały komunikacji.

Wymagania sprzętowe i systemowe: co się zmieniło

Oryginalne wymagania SQL Server 2017 nie uległy zmianie, jednak praktyka operatorska z lat 2017–2026 zweryfikowała wiele oficjalnych zaleceń. Oto kluczowe ustalenia.

Procesor i pamięć. Minimalne 1 GB RAM dla Express Edition i 4 GB dla pozostałych edycji to wartości czysto teoretyczne. W rzeczywistych środowiskach produkcyjnych dolna granica komfortu to 16 GB RAM dla Standard Edition i 64 GB dla Enterprise Edition przy przeciętnych obciążeniach OLTP. SQL Server 2017 wykorzystuje mechanizm In-Memory OLTP (Hekaton), który wymaga wydzielenia puli pamięci poza buforem stron — przy aktywnym użyciu tej funkcji należy doliczyć dodatkowe 20–40% RAM względem rozmiaru gorącego zbioru danych. Co do procesorów: serwer skaluje się efektywnie do 32 rdzeni fizycznych; powyżej tej granicy przyrost wydajności jest sublinearny, chyba że obciążenie ma charakter czysto analityczny i wykorzystuje Columnstore.

Storage. Minimalne 6 GB wolnego miejsca na dysku systemowym to wymóg samej instalacji. W praktyce kluczowym parametrem jest wydajność I/O — dla baz OLTP zaleca się opóźnienia poniżej 5 ms dla plików danych i poniżej 1 ms dla plików logu transakcyjnego. W 2026 roku standardem stały się macierze NVMe oraz pamięci klasy storage-class memory (Intel Optane), które w połączeniu z SQL Server 2017 oferują nawet 3–4-krotne przyspieszenie operacji log flush względem tradycyjnych SSD SATA. Parametr target recovery time (seconds) w połączeniu z pośrednimi punktami kontrolnymi (indirect checkpoint) pozwala ustabilizować czasy odtwarzania, co jest szczególnie ważne przy rozmiarach logu przekraczających 100 GB.

Systemy operacyjne. Na platformie Windows wspierane są Windows Server 2016, 2019 i 2022 oraz Windows 10 i 11 (dla edycji Developer i Express). Na Linuxie wsparcie obejmuje dystrybucje Red Hat Enterprise Linux 7.3–7.x i 8.x, SUSE Linux Enterprise Server v12 SP2–SP5, Ubuntu 16.04, 18.04 i 20.04 LTS. W 2026 roku zalecaną konfiguracją produkcyjną na Linuxie jest RHEL 8.8+ lub Ubuntu 20.04 LTS z jądrem w wersji minimum 5.15, które zawiera poprawki do planisty I/O istotnie redukujące rywalizację o zasoby przy dużym obciążeniu tempdb.

Instalacja krok po kroku: Windows Server i Linux

Instalacja na Windows Server (2022)

Procedura instalacji SQL Server 2017 na Windows Server 2022 jest w 2026 roku dobrze udokumentowana, ale kilka pułapek wciąż regularnie pojawia się w zgłoszeniach administratorów.

Krok pierwszy: przed uruchomieniem instalatora upewnij się, że wszystkie składniki .NET Framework są zainstalowane — SQL Server 2017 wymaga .NET 3.5 SP1 oraz 4.6.1. Na Windows Server 2022 .NET 4.6.1 nie jest składnikiem domyślnym; należy go dodać przez Server Manager (Add Roles and Features). Drugi krok krytyczny: wyłącz tymczasowo Windows Defender Real-Time Protection na czas instalacji — aktywny skaner potrafi wydłużyć proces nawet o 45 minut, szczególnie przy instalacji komponentu R Services (Machine Learning Services).

Podczas konfiguracji silnika bazy danych zwróć uwagę na tryb uwierzytelniania. Tryb mieszany (SQL Server and Windows Authentication) jest zalecany nawet w środowiskach domenowych, ponieważ wiele współczesnych narzędzi monitorujących i automatyzujących (w tym agentów backupowych) wymaga kont SQL. Ustaw silne hasło dla konta sa i natychmiast po instalacji rozważ jego wyłączenie (ALTER LOGIN sa DISABLE) — w 90% przypadków rola sysadmin może być delegowana na konta grup domenowych.

Kluczowe parametry do skonfigurowania zaraz po instalacji: włącz Instant File Initialization (przyznaj użytkownikowi konta usługi SQL Server uprawnienie Perform volume maintenance tasks w Local Security Policy), skonfiguruj max degree of parallelism (MDOP) — dla serwerów z więcej niż 8 rdzeniami zacznij od wartości równej liczbie rdzeni NUMA, a dla serwerów jednordzeniowych NUMA ustaw wartość (liczba_rdzeni / 2), maksymalnie 8. Ustaw max server memory na 80% dostępnego RAM dla instancji dedykowanej lub 50–60% przy współdzieleniu zasobów.

Instalacja na Linuxie (Ubuntu 20.04 LTS)

Instalacja na Linuxie, niegdyś uważana za eksperymentalną, w 2026 roku jest dojrzałą i szeroko stosowaną opcją — szczególnie w środowiskach kontenerowych i przy wdrożeniach brzegowych (edge). Procedura sprowadza się do pięciu poleceń:

curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
sudo add-apt-repository "$(curl https://packages.microsoft.com/config/ubuntu/20.04/mssql-server-2017.list)"
sudo apt-get update
sudo apt-get install -y mssql-server
sudo /opt/mssql/bin/mssql-conf setup

Podczas konfiguracji (mssql-conf setup) wybierasz edycję (Evaluation, Developer, Express, Standard, Enterprise), ustawiasz hasło sa oraz wybierasz język. Po instalacji nadaj priorytet: sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 12288 (dla 12 GB RAM). W odróżnieniu od Windows, na Linuxie SQL Server nie zarządza pamięcią dynamicznie w ten sam sposób — parametr memorylimitmb jest twardym limitem i nie powinien przekraczać 80% fizycznego RAM.

W 2026 roku Microsoft rekomenduje na Linuxie używanie sterownika mssql-tools18 (pakiet mssql-tools18 z repozytorium) zamiast starszego mssql-tools — nowsza wersja obsługuje TLS 1.3 oraz domyślnie wymusza szyfrowanie połączeń, co eliminuje całą klasę błędów związanych z niekompatybilnością bibliotek OpenSSL.

Konfiguracja środowiska produkcyjnego

Produkcyjne wdrożenie SQL Server 2017 opiera się na kilku filarach konfiguracyjnych, które w latach 2017–2026 zostały wielokrotnie zweryfikowane w testach obciążeniowych przeprowadzanych przez społeczność i niezależne laboratoria.

Tempdb — optymalizacja krytyczna. Reguła mówi: jeden plik danych tempdb na każdy rdzeń logiczny procesora, maksymalnie 8 plików. W przypadku serwerów z 16 i więcej rdzeniami testy pokazują, że 8 plików to punkt nasycenia — powyżej tej liczby narzut zarządzania plikami przeważa nad zyskiem z równoległości. Wszystkie pliki tempdb muszą mieć identyczny rozmiar początkowy i przyrost (autogrowth) — zalecane jest ustawienie stałego przyrostu (np. 512 MB) zamiast procentowego, aby uniknąć fragmentacji na poziomie systemu plików.

Model odzyskiwania i strategia backupu. Dla baz produkcyjnych domyślnie stosuj model Full Recovery. W połączeniu z regularnymi backupami logu transakcyjnego (co 5–15 minut w zależności od wymagań RPO) daje to możliwość odtwarzania punktowego (point-in-time restore). W 2026 roku dominującym podejściem jest backup bezpośrednio do Azure Blob Storage (URL backup) lub na lokalny udział SMB 3.0 z szyfrowaniem — zapis na lokalne dyski traktowany jest wyłącznie jako bufor przed transferem do docelowej lokalizacji. Kompresja backupu (WITH COMPRESSION) jest standardem — redukuje rozmiar od 40% do 70% przy znikomym narzucie CPU.

Izolacja zasobów z Resource Governor. W środowiskach wielodzierżawionych (multi-tenant) Resource Governor staje się narzędziem pierwszej potrzeby. Definiujesz pule zasobów z limitami CPU i pamięci, a następnie przypisujesz do nich grupy obciążeń za pomocą funkcji klasyfikatora. Przykładowo: raporty zarządcze mogą otrzymać maksymalnie 20% CPU i 15% pamięci, podczas gdy OLTP zachowuje gwarantowane 60% CPU — reszta pozostaje w puli domyślnej.

Szyfrowanie — TDE i Always Encrypted. Transparent Data Encryption (TDE) chroni dane w spoczynku i jest zalecane dla wszystkich baz przechowujących dane osobowe lub podlegających regulacjom (RODO, HIPAA). W 2026 roku kluczowym udogodnieniem jest integracja z Azure Key Vault poprzez łącznik SQL Server Connector, umożliwiająca scentralizowane zarządzanie kluczami szyfrowania. Always Encrypted z kolei chroni dane wrażliwe w trakcie przesyłania — to podejście typu klient-szyfruje-serwer-nie-widzi, wymagające jednak modyfikacji aplikacji klienckich.

Strojenie wydajności: sprawdzone techniki

Strojenie SQL Server 2017 to proces iteracyjny, który w 2026 roku wspierany jest przez zaawansowane narzędzia, ale fundamenty pozostają niezmienne.

Statystyki i indeksy. Nieaktualne statystyki to przyczyna numer jeden degradacji wydajności zapytań. Na SQL Server 2017 domyślny próg automatycznej aktualizacji statystyk to 20% zmodyfikowanych wierszy + 500 wierszy — dla dużych tabel (powyżej 1 miliona wierszy) ten próg jest zbyt wysoki. Włącz flagę śledzenia 2371 (DBCC TRACEON(2371, -1)), która dynamicznie obniża próg proporcjonalnie do rozmiaru tabeli. Równolegle włącz opcję AUTO_UPDATE_STATISTICS_ASYNC na poziomie bazy danych, aby zapytania nie były blokowane w oczekiwaniu na aktualizację statystyk.

Odbudowa indeksów — tutaj kluczową innowacją jest fragmentacja na poziomie strony. Zamiast sztywno odbudowywać indeksy co weekend, monitoruj sys.dm_db_index_physical_stats. Indeksy o fragmentacji powyżej 30% odbudowuj (ALTER INDEX ... REBUILD), 10–30% reorganizuj (REORGANIZE), poniżej 10% pozostaw bez ingerencji. Dla dużych tabel (powyżej 500 GB) używaj operacji online (WITH ONLINE = ON) dostępnej w Enterprise Edition.

Query Store — niedoceniany skarb. Włączony na poziomie bazy danych (domyślnie wyłączony), Query Store rejestruje historię planów wykonania i statystyk zapytań. W 2026 roku to podstawowe narzędzie do diagnozowania regresji planów po aktualizacji statystyk lub zmianie parametrów — możesz w ciągu minut zidentyfikować zapytanie, które zmieniło plan i cofnąć się do poprzedniego, wymuszając go (sp_query_store_force_plan). Zalecany rozmiar Query Store: 1–2 GB dla baz o intensywnym ruchu OLTP.

In-Memory OLTP i Columnstore. Dla obciążeń o wysokiej rywalizacji (np. systemy kolejkowania, koszyki zakupowe e-commerce), migracja kluczowych tabel do In-Memory OLTP redukuje czasy odpowiedzi o rzędy wielkości — ale wymaga starannego przetestowania, ponieważ nie wszystkie konstrukcje T-SQL są kompatybilne z trybem natywnej kompilacji. Columnstore z kolei to technika dla obciążeń analitycznych: indeks Columnstore na tabeli faktów redukuje rozmiar danych nawet 10-krotnie i przyspiesza agregacje — szczególnie w połączeniu z trybem wsadowym (batch mode) dostępnym od poziomu zgodności bazy danych 140.

Najczęstsze problemy i ich rozwiązania

Problem 1: błąd 18456 — nieudane logowanie. W 2026 roku najczęstszym podtypem tego błędu jest stan 5 ("nieprawidłowy identyfikator użytkownika") spowodowany wygasłym hasłem konta SQL w trybie mieszanym. Rozwiązanie: sprawdź stan konta przez SELECT name, is_disabled, is_expired FROM sys.sql_logins. Jeśli hasło wygasło, administrator z rolą ALTER ANY LOGIN może je zresetować. W przypadku kont usług: używaj Managed Service Accounts (MSA/gMSA) na Windows lub odpowiedników na Linuxie.

Problem 2: THREADPOOL waits — przeciążenie puli wątków. Objawia się timeoutami połączeń i ogólną niereaktywnością serwera mimo niskiego użycia CPU. W SQL Server 2017 maksymalna liczba wątków roboczych (max worker threads) zależy od liczby procesorów logicznych. Rozwiązanie doraźne: zwiększ max worker threads (domyślnie 0 = automatycznie, do 960 na architekturze x64) lub — lepiej — zidentyfikuj długotrwałe zapytania blokujące wątki przez sys.dm_exec_requests i sys.dm_os_waiting_tasks.

Problem 3: VLF fragmentation w logu transakcyjnym. Zbyt wiele wirtualnych plików logu (VLF) — często setki tysięcy — powoduje spowolnienie operacji recovery i backupu logu. Diagnostyka: DBCC LOGINFO zwraca liczbę VLF. Rozwiązanie: opróżnij log transakcyjny (BACKUP LOG ... TO DISK), zmniejsz rozmiar pliku do minimum (DBCC SHRINKFILE), a następnie zwiększ go ponownie do docelowego rozmiaru w dużych przyrostach (np. 8 GB na raz), co utworzy małą liczbę dużych VLF.

Problem 4: wycieki pamięci przy Linked Servers. Połączenia przez Linked Servers do Oracle lub innych źródeł zewnętrznych potrafią alokować pamięć poza standardowym buforem SQL Server, omijając limit max server memory. Rozwiązanie: ustaw limit pamięci dla dostawcy OLE DB (opcja Allow inprocess = 0 dla dostawców zewnętrznych), a w ostateczności — izoluj Linked Server na dedykowanej instancji.

Bezpieczeństwo: najlepsze praktyki 2026

Krajobraz zagrożeń w 2026 roku sprawił, że bezpieczeństwo serwerów bazodanowych jest priorytetem numer jeden — nie tylko z powodów regulacyjnych, ale też wobec fali ataków ransomware celujących konkretnie w instancje SQL Server z otwartym portem 1433.

TLS 1.3 i szyfrowanie połączeń. SQL Server 2017 po zastosowaniu Cumulative Update 31+ (styczeń 2024) wspiera TLS 1.3 na Windows Server 2022. Wymuś szyfrowanie połączeń (Force Encryption = Yes w SQL Server Configuration Manager) i zastosuj certyfikat z zaufanego urzędu certyfikacji — self-signed certificate jest akceptowalny tylko w środowiskach deweloperskich.

Audyt i monitorowanie podejrzanej aktywności. SQL Server Audit (dostępny w Enterprise i Standard Edition) pozwala śledzić operacje DDL, DML na wrażliwych tabelach oraz zmiany uprawnień. W 2026 roku zaleca się kierowanie logów audytu do scentralizowanego systemu SIEM — natywna integracja z Azure Sentinel (teraz Microsoft Sentinel) przez łącznik SQL Server Auditing działa również dla instancji on-premises z Azure Arc.

Row-Level Security (RLS) i Dynamic Data Masking. RLS pozwala ograniczyć widoczność wierszy na podstawie kontekstu użytkownika — na przykład menedżer regionalny widzi tylko dane swojego regionu, bez potrzeby tworzenia widoków. Dynamic Data Masking maskuje wrażliwe kolumny (PESEL, numer karty kredytowej) dla użytkowników bez uprawnienia UNMASK — to nie jest szyfrowanie i nie chroni przed osobą z bezpośrednim dostępem do plików bazy, ale stanowi wartościową warstwę obrony w głąb.

Migracja z SQL Server 2017: dostępne ścieżki

Choć SQL Server 2017 wciąż działa niezawodnie, perspektywa końca rozszerzonego wsparcia w 2027 roku skłania organizacje do planowania migracji. Dostępne ścieżki w 2026 roku są następujące.

In-place upgrade do SQL Server 2022. Najprostsza technicznie opcja — instalator zachowuje bazy danych, loginy, zadania agenta i konfigurację. Ryzyko: niekompatybilność aplikacji klienckich z poziomem zgodności bazy danych 160. Rozwiązaniem jest tymczasowe ustawienie poziomu zgodności 140 po migracji i stopniowe testowanie wyższych poziomów. Uwaga: upgrade z SQL Server 2017 do 2022 pomija SQL Server 2019, co jest w pełni wspierane przez Microsoft — nie ma potrzeby wykonywania pośredniego kroku.

Migracja side-by-side. Instalujesz SQL Server 2022 na nowym serwerze (fizycznym lub wirtualnym), przenosisz bazy przez backup/restore lub log shipping, a następnie przełączasz aplikacje. Zaletą jest minimalne ryzyko — w każdej chwili możesz wrócić do starego środowiska. Wadą jest podwojenie kosztów licencyjnych na czas migracji (chyba że posiadasz Software Assurance z prawem do równoległego użycia).

Lift and shift do Azure SQL Managed Instance. Azure SQL Managed Instance oferuje niemal 100% zgodności z SQL Server 2017 na poziomie silnika. Migrację przeprowadzisz za pomocą Azure Database Migration Service w trybie online (minimalny downtime) lub offline. W 2026 roku narzędzie Azure Migrate rozpoznaje zależności między bazami i automatycznie proponuje grupowanie instancji — redukuje to ryzyko pominięcia bazy systemowej lub zależności między bazami.

Konteneryzacja i Kubernetes. Dla organizacji, które już zainwestowały w platformy kontenerowe, SQL Server 2017 na Linuxie w kontenerach Docker może być pomostem do pełnej konteneryzacji SQL Server 2025. Operator SQL Server dla Kubernetesa (dostarczany przez Microsoft od 2024 roku) automatyzuje wdrażanie, backup i failover — w 2026 roku to dojrzałe rozwiązanie używane nawet w środowiskach produkcyjnych klasy enterprise.

Częste pytania

Czy SQL Server 2017 będzie działał na Windows Server 2025? Oficjalnie Microsoft nie testuje SQL Server 2017 na wersjach Windows Server nowszych niż 2022. W praktyce społeczność zgłasza udane instalacje na Windows Server 2025 w trybie zgodności, ale środowiska produkcyjne powinny pozostać na Windows Server 2022, który jest w pełni wspierany.

Jak sprawdzić aktualny poziom Cumulative Update w mojej instancji? Wykonaj zapytanie SELECT @@VERSION lub sprawdź pierwszą wartość w wynikach SELECT SERVERPROPERTY('ProductUpdateLevel'). Najnowszy CU dla SQL Server 2017 dostępny jest w Microsoft Update Catalog i w 2026 roku nosi oznaczenie CU31 z poprawkami bezpieczeństwa wydanymi poza cyklem zbiorczym.

Czy mogę używać SQL Server 2017 z PowerShell 7? Tak, moduł SqlServer (dostępny w PowerShell Gallery, wersja 22.x w 2026 roku) w pełni wspiera PowerShell 7 na Windows i Linuxie. Starszy moduł SQLPS (przestarzały od 2019 roku) nie jest kompatybilny z PowerShell Core — musisz używać wyłącznie modułu SqlServer.

Jak skonfigurować wysoką dostępność na SQL Server 2017 Standard Edition? Enterprise Edition oferuje Always On Availability Groups. W Standard Edition dostępny jest Basic Availability Group — limit dwóch replik, jednej bazy na grupę, bez dostępu do odczytu na replice pomocniczej. Alternatywą dla Standard Edition jest log shipping lub klaster failover (FCI) z współdzielonym magazynem.

Dlaczego SQL Server 2017 zużywa 100% RAM mimo ustawienia max server memory? To zachowanie zgodne z projektem: SQL Server alokuje pamięć na bufory i plany wykonania aż do osiągnięcia limitu max server memory, a następnie utrzymuje tę pulę nawet przy spadku obciążenia. Pamięć nie jest zwalniana do systemu operacyjnego (poza sytuacjami presji pamięci zewnętrznej). Użyj DBCC DROPCLEANBUFFERS do natychmiastowego opróżnienia bufora — ale tylko na środowisku testowym.

Czy SQL Server 2017 w kontenerze Docker nadaje się do produkcji? Tak, pod warunkiem spełnienia kilku wymogów: używasz obrazu z oficjalnego Microsoft Container Registry, montujesz wolumeny dla danych (/var/opt/mssql) i logów jako trwałe, konfigurujesz limity pamięci (--memory) i CPU (--cpus) na poziomie kontenera za pomocą Docker lub orkiestratora. W 2026 roku tysiące organizacji używa tej konfiguracji na produkcji.

Jak rozwiązać problem wolnego zapytania, które wczoraj działało szybko? Włącz Query Store i porównaj plan wykonania z wczoraj z dzisiejszym (sys.query_store_plan). Jeśli plan się zmienił i nowy jest gorszy — wymuś poprzedni (sp_query_store_force_plan). Jeśli plan jest ten sam — sprawdź poziom fragmentacji indeksów (sys.dm_db_index_physical_stats), stan statystyk i ewentualną obecność blokad (sys.dm_tran_locks).

Czy potrzebuję licencji na SQL Server 2017, jeśli instancja jest używana tylko jako źródło replikacji do Azure? Tak. Każda działająca instancja SQL Server 2017 (poza Developer Edition i Express Edition) wymaga licencji — niezależnie od tego, czy jest aktywnym serwerem produkcyjnym, czy pasywnym źródłem replikacji. Jedyny wyjątek to pasywna replika w ramach Software Assurance, która jest objęta licencją na aktywny węzeł.

Gdzie szukać aktualnych sterowników ODBC/JDBC dla SQL Server 2017? Sterowniki są rozwijane niezależnie od wersji serwera i dostępne w Microsoft Learn pod hasłem "Microsoft ODBC Driver for SQL Server" oraz "Microsoft JDBC Driver for SQL Server". W 2026 roku wersja ODBC 18.x i JDBC 12.x zapewniają pełną kompatybilność z SQL Server 2017, łącznie z obsługą TLS 1.3 i Azure Active Directory Authentication.

Jakie narzędzie zastępuje SQL Server Management Studio w 2026 roku? SSMS w wersji 20.x wciąż jest rozwijane i w pełni wspiera SQL Server 2017. Alternatywnie Azure Data Studio (dawniej SQL Operations Studio) oferuje lżejszy, wieloplatformowy interfejs ze wsparciem dla notebooków Jupyter i rozszerzeń — szczególnie przydatny dla administratorów pracujących na Linuxie i macOS.

Zarządzanie środowiskiem SQL Server 2017 w 2026 roku wymaga połączenia solidnej wiedzy o samym silniku ze świadomością nadchodzącego końca wsparcia. Jeśli odpowiadasz w organizacji za infrastrukturę bazodanową i szukasz długoterminowej strategii — od audytu bieżących instancji, przez optymalizację, aż po bezpieczną migrację — zespół KluczeSoft oferuje usługę kompleksowego przeglądu środowiska SQL Server wraz z rekomendacjami szytymi na miarę Twojej architektury.

Sprawdź też

Potrzebujesz licencji? Microsoft Office — sprawdź ofertę KluczeSoft.pl — legalne klucze, faktura VAT, dostawa e-mail.