SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION

sys.dm_resource_governor_configuration zwraca bieżącą konfigurację mechanizmu Resource Governor.

SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION — czym jest ten widok

SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION to dynamiczny widok zarządzania danych w Microsoft SQL Server, przeznaczony do odczytu bieżących ustawień mechanizmu Resource Governor. Nie służy do definiowania reguł, tworzenia pul zasobów ani przypisywania sesji do grup obciążenia. Jego zadaniem jest pokazanie, w jakim stanie znajduje się konfiguracja i jakie podstawowe wartości sterują działaniem regulatora w danej chwili.

Odczyt z tego widoku przydaje się podczas sprawdzania, czy mechanizm jest aktywny, czy działa konfiguracja robocza oraz czy ostatnie zmiany zostały zastosowane. W środowisku, w którym wiele zapytań konkuruje o procesor, pamięć lub przepustowość operacji wejścia i wyjścia, sama obecność pul zasobów nie przesądza jeszcze o ich działaniu. Istotne jest także rozróżnienie między konfiguracją przygotowaną a konfiguracją aktywną. Widok pomaga uchwycić tę różnicę bez analizowania każdego obiektu osobno.

Wynik należy traktować jako migawkę stanu instancji. Odczyt nie przedstawia historii zmian, nie pokazuje pełnego przebiegu obciążenia i nie zastępuje monitorowania wydajności. Wartość diagnostyczna pojawia się dopiero po zestawieniu jej z informacjami o pulach zasobów, grupach obciążenia, klasyfikacji sesji oraz aktualnych oczekiwaniach zadań.

SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION w kontekście konfiguracji zasobów

Resource Governor działa warstwowo. Na niższym poziomie znajdują się pule zasobów, które opisują dostępny zakres wybranych zasobów. Nad nimi znajdują się grupy obciążenia, a jeszcze wyżej reguła klasyfikacji określająca, do której grupy ma trafić nowe żądanie. Widok SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION nie zastępuje tych elementów, lecz dostarcza punktu kontrolnego dla całego mechanizmu.

W praktyce rozróżnia się konfigurację przechowywaną w metadanych oraz konfigurację, która została zastosowana przez silnik. Zmiana definicji puli albo grupy może wymagać jawnego zastosowania konfiguracji. Dopiero wtedy nowe ustawienia zaczynają wpływać na pracę regulatora. Przy analizie rozbieżności między oczekiwanym i rzeczywistym zachowaniem pierwszym krokiem powinno być sprawdzenie stanu widocznego w SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION, a następnie porównanie go z definicjami zapisanymi w katalogowych widokach zarządzania.

Nie należy utożsamiać tego widoku z raportem wykorzystania zasobów. Nie odpowiada on na pytanie, która grupa zużywa najwięcej czasu procesora ani które zapytanie zostało ograniczone. Do takich wniosków potrzebne są inne źródła: widoki dotyczące pul i grup, informacje o sesjach, statystyki zapytań, liczniki systemowe oraz dane z monitoringu. SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION pokazuje warunki sterowania, natomiast pozostałe narzędzia pomagają ocenić skutek tych warunków.

Warto również uwzględnić wersję SQL Server i edycję używanego produktu. Dostępne kolumny, szczegółowość działania oraz zakres obsługiwanych zasobów mogą różnić się między wersjami. Skrypt diagnostyczny powinien więc odczytywać nazwy kolumn zgodne z dokumentacją konkretnej instancji, zamiast zakładać, że każdy serwer zwróci identyczny zestaw informacji.

SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION a typowe problemy diagnostyczne

Jednym z częstszych problemów jest wrażenie, że regulator nie działa, mimo że przygotowano pule i grupy obciążenia. Przyczyną może być brak zastosowania konfiguracji, niepoprawna klasyfikacja logowania albo fakt, że analizowana sesja została uruchomiona przed zmianą reguł. Sam odczyt z SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION może wskazać stan mechanizmu, ale nie potwierdzi poprawności całej ścieżki klasyfikacji. Należy sprawdzić także, jakie właściwości sesji są wykorzystywane przez funkcję klasyfikującą i czy warunki tej funkcji faktycznie pasują do analizowanego połączenia.

Inny przypadek dotyczy zmian, które zostały zapisane, lecz nie są jeszcze widoczne jako aktywne. Taka sytuacja bywa mylona z błędem silnika albo z nieskutecznością limitów. Porównanie konfiguracji roboczej z definicją obiektów pozwala ustalić, czy problem dotyczy etapu wdrożenia, czy dopiero późniejszego działania grupy. Należy przy tym pamiętać, że zmiana ustawień nie musi natychmiast zmienić zachowania już trwających żądań. Część zasad jest istotna przede wszystkim dla nowych połączeń lub nowych jednostek pracy.

Trudności interpretacyjne pojawiają się również wtedy, gdy ograniczenia są ustawione poprawnie, lecz przeciążenie wynika z innego źródła. Wysokie opóźnienia mogą być związane z blokadami, nieefektywnymi planami wykonania, brakiem indeksu, opóźnieniami magazynu danych albo niewystarczającą pamięcią dostępną poza zakresem kontrolowanym przez konkretną pulę. Dlatego SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION powinien być elementem szerszego rozpoznania, a nie jedynym dowodem na przyczynę problemu.

Ostrożności wymaga także interpretacja wartości domyślnych. Zastosowanie puli domyślnej lub grupy domyślnej nie oznacza automatycznie awarii. Często jest to prawidłowe zachowanie dla sesji, których nie objęto szczególną regułą. Dopiero zestawienie informacji o użytkowniku, aplikacji, bazie danych i nazwie hosta z definicją klasyfikatora pozwala stwierdzić, czy konkretne żądanie trafiło w miejsce zamierzone przez administratora.

SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION — praktyczne wskazówki odczytu

Najbezpieczniej rozpocząć od prostego odczytu kolumn zwracanych przez widok, bez zakładania kolejności ani znaczenia pól na podstawie samej nazwy. Następnie warto zapisać wynik wraz z datą, nazwą instancji i informacją o wykonywanej zmianie. Taki punkt odniesienia ułatwia porównanie stanu przed i po zastosowaniu konfiguracji oraz pomaga odróżnić trwałą zmianę od chwilowego efektu ponownego uruchomienia usługi.

Przy tworzeniu procedury kontrolnej przydatny jest następujący porządek:

• odczyt bieżącego stanu z SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION;
• sprawdzenie definicji pul zasobów i grup obciążenia;
• przegląd funkcji klasyfikującej oraz jej warunków;
• porównanie ustawień z obserwowanymi sesjami i obciążeniem;
• kontrola zachowania po zastosowaniu konfiguracji;
• udokumentowanie wyniku i ewentualne wycofanie zmiany, jeśli pojawiły się niepożądane skutki.

Nie powinno się wykonywać zmian wyłącznie na podstawie pojedynczego odczytu. Najpierw należy ustalić, czy problem jest powtarzalny, w jakich godzinach występuje i które grupy obciążenia są nim objęte. Warto także zebrać dane o czasie trwania żądań, oczekiwaniach, blokadach oraz obciążeniu procesora. Dzięki temu ograniczenie zasobów może zostać ocenione jako świadoma reguła ochronna, a nie jako przypadkowa przyczyna spowolnienia.

Odczyt widoku nie zmienia konfiguracji i zwykle może być elementem regularnego audytu. Przy automatyzacji należy jednak przewidzieć różnice wersji, uprawnienia wymagane do odczytu oraz sposób obsługi braku oczekiwanych kolumn. Raport powinien jasno wskazywać, czy opisuje stan bieżący, stan z chwili wykonania pomiaru, czy porównanie kilku punktów kontrolnych.

Kiedy zgłosić się do serwisu w sprawie SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION

Do specjalistycznego serwisu warto zgłosić problem wtedy, gdy odczyt SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION wskazuje stan trudny do pogodzenia z dokumentowaną konfiguracją, po zastosowaniu zmian pojawia się niestabilność albo nie da się ustalić, dlaczego sesje trafiają do niewłaściwych grup. Pomoc bywa potrzebna również przy analizie powtarzających się spowolnień, gdy same komunikaty aplikacji nie pokazują, czy źródłem jest konfiguracja SQL Server, system operacyjny, pamięć masowa czy sprzęt komputera.

W takich przypadkach przydatne jest przygotowanie kopii wyników odczytów, informacji o wersji SQL Server, opisu czasu występowania problemu oraz przykładów zapytań lub sesji, których dotyczy zjawisko. Należy unikać przekazywania haseł i innych danych uwierzytelniających. Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnostyką komputerów i laptopów, dzięki czemu możliwe jest uporządkowanie informacji o stanie urządzenia oraz przygotowanie materiału potrzebnego do dalszej analizy konfiguracji i wydajności.

Jeżeli problem dotyczy wyłącznie ustawień bazy danych, pomoc może ograniczyć się do zebrania danych, weryfikacji zależności i wskazania obszaru wymagającego konsultacji z administratorem SQL Server. Jeżeli równocześnie występują objawy sprzętowe, błędy systemowe lub przerwy w pracy aplikacji, warto opisać je razem z wynikami SYS.DM_RESOURCE_GOVERNOR_CONFIGURATION. Pełniejszy kontekst zwiększa szansę na właściwe rozdzielenie przyczyny od skutku i ogranicza ryzyko przypadkowej zmiany ustawień.