Konfiguracja Resource Governor w SQL Server 2025 — praktyczny przewodnik dla administratorów

Czym jest Resource Governor i dlaczego powinieneś go używać

Resource Governor to mechanizm zarządzania zasobami wbudowany w SQL Server, który pozwala kontrolować zużycie CPU, pamięci i fizycznego I/O przez poszczególne obciążenia użytkowników. Po 20 latach pracy z SQL Server mogę powiedzieć wprost — to jedno z najbardziej niedocenianych narzędzi w arsenale DBA.

W SQL Server 2025 Microsoft wykonał ruch, na który czekaliśmy latami. Resource Governor nie jest już zarezerwowany wyłącznie dla edycji Enterprise. Teraz dostępny jest również w edycji Standard, co otwiera możliwości zaawansowanego zarządzania zasobami dla znacznie szerszego grona administratorów.

Główne scenariusze użycia Resource Governor obejmują:

• Multitenancy — izolacja zasobów między wieloma aplikacjami na jednej instancji
• Gwarancje SLA — zapewnienie przewidywalnej wydajności dla krytycznych obciążeń
• Ochrona przed runaway queries — ograniczenie zapytań pochłaniających nadmierne zasoby
• Chargeback — śledzenie zużycia zasobów dla celów rozliczeniowych

Po latach wdrożeń Resource Governor nauczyłem się jednej rzeczy: nie czekaj na pożar. Konfiguruj go prewencyjnie, zanim pierwszy runaway query położy Ci produkcję w piątek o 17:00.

Architektura Resource Governor — trzy filary systemu

Resource Governor opiera się na trzech fundamentalnych konceptach, które musisz zrozumieć przed przystąpieniem do konfiguracji. Pominięcie któregokolwiek z nich to prosta droga do niedziałającej lub nieefektywnej konfiguracji.

Resource Pools — kontenery zasobów fizycznych

Resource Pool to abstrakcja reprezentująca pulę zasobów fizycznych serwera. Każda pula może mieć przypisane limity i rezerwacje dla CPU, pamięci oraz I/O. SQL Server zawsze posiada dwie wbudowane pule:

• internal — zarezerwowana dla procesów wewnętrznych silnika, nie możesz jej modyfikować
• default — domyślna pula dla wszystkich sesji niesklasyfikowanych do innych pul

Poza pulami wbudowanymi możesz tworzyć własne pule użytkownika. Kluczowe parametry konfiguracyjne to:

• MIN_CPU_PERCENT — minimalna gwarantowana przepustowość CPU
• MAX_CPU_PERCENT — maksymalny limit CPU
• MIN_MEMORY_PERCENT — minimalna rezerwacja pamięci
• MAX_MEMORY_PERCENT — maksymalny limit pamięci
• MIN_IOPS_PER_VOLUME i MAX_IOPS_PER_VOLUME — kontrola I/O

Workload Groups — logiczne grupowanie sesji

Workload Group to kontener dla sesji, które powinny być traktowane w ten sam sposób. Każda grupa jest przypisana do dokładnie jednej puli zasobów, ale jedna pula może obsługiwać wiele grup. To pozwala na granularne sterowanie zachowaniem zapytań w ramach wspólnej puli zasobów.

Parametry specyficzne dla grup obciążeń:

• IMPORTANCE — priorytet względem innych grup w tej samej puli (Low, Medium, High)
• REQUEST_MAX_MEMORY_GRANT_PERCENT — maksymalny grant pamięci dla pojedynczego zapytania
• REQUEST_MAX_CPU_TIME_SEC — limit czasu CPU dla zapytania
• REQUEST_MEMORY_GRANT_TIMEOUT_SEC — timeout oczekiwania na grant pamięci
• MAX_DOP — maksymalny stopień równoległości

Classifier Function — mózg klasyfikacji

Funkcja klasyfikująca to procedura T-SQL, która przypisuje każdą przychodzącą sesję do odpowiedniej grupy obciążeń. Wywoływana jest automatycznie przy każdym połączeniu i musi zwrócić nazwę grupy workload. To tutaj implementujesz logikę biznesową decydującą o przydziale zasobów.

Krok po kroku: podstawowa konfiguracja Resource Governor

Przejdźmy do praktyki. Załóżmy scenariusz typowy dla wielu środowisk: jedna instancja SQL Server obsługuje aplikację OLTP (krytyczną), aplikację raportową (ważną, ale nie krytyczną) oraz ad-hoc queries od analityków (niski priorytet).

Krok 1: Tworzenie pul zasobów

Zaczynamy od zdefiniowania pul zasobów dla każdego typu obciążenia:

Pula dla OLTP:

CREATE RESOURCE POOL PoolOLTP WITH (MIN_CPU_PERCENT = 40, MAX_CPU_PERCENT = 80, MIN_MEMORY_PERCENT = 40, MAX_MEMORY_PERCENT = 70, MIN_IOPS_PER_VOLUME = 500, MAX_IOPS_PER_VOLUME = 2000);

Pula dla raportów:

CREATE RESOURCE POOL PoolReporting WITH (MIN_CPU_PERCENT = 20, MAX_CPU_PERCENT = 50, MIN_MEMORY_PERCENT = 20, MAX_MEMORY_PERCENT = 40, MIN_IOPS_PER_VOLUME = 100, MAX_IOPS_PER_VOLUME = 800);

Pula dla ad-hoc:

CREATE RESOURCE POOL PoolAdHoc WITH (MIN_CPU_PERCENT = 5, MAX_CPU_PERCENT = 30, MIN_MEMORY_PERCENT = 5, MAX_MEMORY_PERCENT = 20, MIN_IOPS_PER_VOLUME = 50, MAX_IOPS_PER_VOLUME = 300);

Krok 2: Tworzenie grup obciążeń

Następnie tworzymy grupy workload przypisane do odpowiednich pul:

CREATE WORKLOAD GROUP GroupOLTP WITH (IMPORTANCE = HIGH, REQUEST_MAX_MEMORY_GRANT_PERCENT = 25, REQUEST_MAX_CPU_TIME_SEC = 30, MAX_DOP = 4) USING PoolOLTP;

CREATE WORKLOAD GROUP GroupReporting WITH (IMPORTANCE = MEDIUM, REQUEST_MAX_MEMORY_GRANT_PERCENT = 50, REQUEST_MAX_CPU_TIME_SEC = 300, MAX_DOP = 8) USING PoolReporting;

CREATE WORKLOAD GROUP GroupAdHoc WITH (IMPORTANCE = LOW, REQUEST_MAX_MEMORY_GRANT_PERCENT = 15, REQUEST_MAX_CPU_TIME_SEC = 120, MAX_DOP = 2) USING PoolAdHoc;

Krok 3: Funkcja klasyfikująca

Teraz kluczowy element — funkcja klasyfikująca. Musi być utworzona w bazie master:

USE master; GO CREATE FUNCTION dbo.fnResourceClassifier() RETURNS SYSNAME WITH SCHEMABINDING AS BEGIN DECLARE @WorkloadGroup SYSNAME; IF APP_NAME() LIKE '%OLTP_Application%' SET @WorkloadGroup = 'GroupOLTP'; ELSE IF APP_NAME() LIKE '%ReportServer%' OR APP_NAME() LIKE '%SSRS%' SET @WorkloadGroup = 'GroupReporting'; ELSE IF SUSER_SNAME() IN ('AnalystUser1', 'AnalystUser2') SET @WorkloadGroup = 'GroupAdHoc'; ELSE SET @WorkloadGroup = 'default'; RETURN @WorkloadGroup; END; GO

Krok 4: Aktywacja konfiguracji

Ostatni krok to powiązanie funkcji z Resource Governor i rekonfiguracja:

ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fnResourceClassifier); GO ALTER RESOURCE GOVERNOR RECONFIGURE; GO

Zawsze testuj funkcję klasyfikującą przed aktywacją na produkcji. Źle napisana funkcja może spowodować, że wszystkie połączenia trafią do puli default — albo gorzej, będą odrzucane.

Nowość SQL Server 2025: governance przestrzeni tempdb

SQL Server 2025 wprowadza długo wyczekiwaną funkcję — możliwość ograniczenia zużycia przestrzeni tempdb przez poszczególne obciążenia. To game-changer dla środowisk, gdzie runaway queries regularnie zapychają tempdb ogromnymi sortowaniami czy hash joinami.

Konfiguracja wymaga dodania parametru TEMPDB_MAX_DATA_SPACE_KB do grupy obciążeń:

ALTER WORKLOAD GROUP GroupAdHoc WITH (TEMPDB_MAX_DATA_SPACE_KB = 5242880); -- 5 GB

Gdy sesja przekroczy przydzielony limit, zapytanie zostanie przerwane z odpowiednim błędem. To znacznie bardziej eleganckie rozwiązanie niż czekanie, aż tempdb zapełni cały dysk.

Praktyczne zastosowania tej funkcji:

• Ochrona przed zapytaniami ad-hoc generującymi gigabajtowe operacje sortowania
• Izolacja środowisk deweloperskich współdzielących instancję
• Gwarancja dostępności tempdb dla krytycznych operacji OLTP
• Wymuszenie optymalizacji zapytań przez deweloperów

Monitorowanie i diagnostyka Resource Governor

Konfiguracja to dopiero początek. Bez ciągłego monitorowania nie wiesz, czy Resource Governor działa zgodnie z oczekiwaniami. SQL Server dostarcza bogaty zestaw DMV do tego celu.

Kluczowe widoki diagnostyczne

Statystyki pul zasobów:

SELECT pool_id, name, statistics_start_time, total_cpu_usage_ms, cache_memory_kb, compile_memory_kb, used_memgrant_kb, total_memgrant_count, total_memgrant_timeout_count, active_memgrant_count, active_memgrant_kb, memgrant_waiter_count, max_memory_kb, used_memory_kb, target_memory_kb FROM sys.dm_resource_governor_resource_pools;

Statystyki grup obciążeń:

SELECT group_id, name, pool_id, statistics_start_time, total_request_count, total_queued_request_count, active_request_count, queued_request_count, total_cpu_limit_violation_count, total_cpu_usage_ms, max_request_cpu_time_ms, blocked_task_count, total_lock_wait_count, total_lock_wait_time_ms, total_query_optimization_count, total_reduced_memgrant_count FROM sys.dm_resource_governor_workload_groups;

Weryfikacja klasyfikacji sesji

Aby sprawdzić, do jakiej grupy została przypisana bieżąca sesja:

SELECT s.session_id, s.login_name, s.program_name, wg.name AS workload_group, rp.name AS resource_pool FROM sys.dm_exec_sessions s JOIN sys.dm_resource_governor_workload_groups wg ON s.group_id = wg.group_id JOIN sys.dm_resource_governor_resource_pools rp ON wg.pool_id = rp.pool_id WHERE s.is_user_process = 1;

Alertowanie na przekroczenia limitów

Warto skonfigurować monitoring na kolumnę total_cpu_limit_violation_count oraz total_memgrant_timeout_count. Rosnące wartości sygnalizują, że limity są aktywnie egzekwowane — co może oznaczać zarówno prawidłowe działanie ochrony, jak i zbyt restrykcyjną konfigurację.

Najczęstsze błędy i pułapki konfiguracyjne

Przez lata widziałem dziesiątki nieudanych wdrożeń Resource Governor. Oto najczęstsze błędy, których powinieneś unikać:

Błąd 1: Zbyt skomplikowana funkcja klasyfikująca

Funkcja klasyfikująca jest wywoływana przy KAŻDYM połączeniu. Jeśli wykonuje złożone zapytania do tabel użytkownika, może stać się wąskim gardłem. Trzymaj ją prostą — używaj tylko funkcji systemowych jak APP_NAME(), SUSER_SNAME(), HOST_NAME().

Błąd 2: Suma MIN_CPU_PERCENT przekracza 100%

Suma minimalnych rezerwacji CPU dla wszystkich pul użytkownika nie może przekroczyć 100%. SQL Server odrzuci taką konfigurację. Pamiętaj też, że pula internal rezerwuje część zasobów.

Błąd 3: Ignorowanie puli default

Każda sesja, której nie sklasyfikujesz jawnie, trafia do puli default. Jeśli zostawisz ją bez limitów, jeden nieoczekiwany workload może zmonopolizować zasoby.

Błąd 4: Brak testów przed produkcją

Zawsze testuj konfigurację w środowisku nieprodukcyjnym. Szczególnie funkcję klasyfikującą — błąd w niej może uniemożliwić połączenie do serwera.

Błąd 5: Zbyt agresywne limity I/O

Governance I/O dotyczy tylko operacji użytkownika, nie procesów systemowych. Zbyt niskie limity mogą prowadzić do pozornej wydajności przy jednoczesnym wzroście opóźnień.

Złota zasada: zacznij od luźnych limitów i stopniowo je zaostrzaj, obserwując metryki. Zbyt agresywna konfiguracja na start to przepis na telefony o 3 w nocy.

Integracja z Always On i środowiskami wysokiej dostępności

Resource Governor w środowiskach HA wymaga szczególnej uwagi. Konfiguracja NIE jest automatycznie replikowana między replikami w SQL Server — musisz ją zsynchronizować ręcznie.

Always On Availability Groups

Każda replika wymaga identycznej konfiguracji Resource Governor. Rozbieżności między replikami prowadzą do nieprzewidywalnego zachowania po failover. Rekomendowane podejście:

• Przechowuj skrypty konfiguracyjne w systemie kontroli wersji
• Wdrażaj zmiany na wszystkie repliki w ramach jednego okna serwisowego
• Zaimplementuj automatyczne sprawdzanie zgodności konfiguracji między replikami

Azure SQL Managed Instance

W przypadku Managed Instance sytuacja jest inna — konfiguracja Resource Governor propaguje się automatycznie do replik pomocniczych, ponieważ baza master jest replikowana. To znaczne uproszczenie administracji.

Failover Cluster Instances

FCI współdzieli storage, ale Resource Governor konfigurowany jest na poziomie instancji. Przy failover konfiguracja wędruje wraz z instancją, więc nie wymaga dodatkowej synchronizacji.

Praktyczne wzorce konfiguracji dla typowych scenariuszy

Na zakończenie kilka sprawdzonych wzorców, które możesz zaadaptować do swoich potrzeb:

Wzorzec: Ochrona OLTP przed raportami

Cel: gwarancja zasobów dla transakcji przy jednoczesnym umożliwieniu raportowania. Pula OLTP: MIN_CPU 50%, MAX_CPU 100%. Pula Reports: MIN_CPU 10%, MAX_CPU 40%. Klasyfikacja po APP_NAME lub dedykowanym loginie raportowym.

Wzorzec: Multitenancy

Cel: izolacja zasobów między klientami. Osobna pula dla każdego tenanta z proporcjonalnymi limitami. Klasyfikacja po nazwie bazy danych lub loginie. Rozważ użycie tempdb governance w SQL Server 2025.

Wzorzec: Ochrona przed runaway queries

Cel: zapobieganie monopolizacji zasobów. Restrykcyjna pula dla ad-hoc z REQUEST_MAX_CPU_TIME_SEC = 60 i MAX_DOP = 2. Wszystkie niesklasyfikowane sesje kierowane do tej puli.