sys.dm_os_sys_info zwraca ogólne informacje o środowisku, w tym liczbę rdzeni i ilość dostępnej pamięci.
Rola sys.dm_os_sys_info w SQL Server
sys.dm_os_sys_info jest dynamicznym widokiem zarządzania (DMV) należącym do silnika Microsoft SQL Server. Udostępnia informacje o środowisku, w którym działa instancja, między innymi o liczbie procesorów logicznych widocznych dla SQL Server, pamięci używanej przez system oraz czasie uruchomienia usługi silnika. Widok opisuje stan instancji i hosta w momencie wykonania zapytania, dlatego jego zawartość może zmieniać się po restarcie SQL Server, zmianie konfiguracji systemu lub zmianie dostępnych zasobów.
Podstawowe odczytanie danych wykonuje się poleceniem SELECT * FROM sys.dm_os_sys_info;. W praktyce bezpieczniej pobierać wyłącznie potrzebne kolumny, ponieważ ich zestaw może różnić się między wydaniami SQL Server i platformami uruchomieniowymi. Przykładowe zapytanie diagnostyczne to SELECT cpu_count, scheduler_count, hyperthread_ratio, physical_memory_kb, committed_kb, committed_target_kb, sqlserver_start_time FROM sys.dm_os_sys_info;. Wynik należy interpretować w odniesieniu do konkretnej wersji SQL Server, systemu operacyjnego oraz sposobu przydzielenia zasobów instancji.
Procesory logiczne, schedulery i pamięć raportowana przez DMV
Kolumna cpu_count pokazuje liczbę procesorów logicznych dostępnych dla SQL Server. Nie jest to bezpośrednio liczba fizycznych gniazd procesora ani liczba rdzeni fizycznych. Wartość może obejmować wątki sprzętowe wynikające z technologii SMT lub Hyper-Threading, a także odzwierciedlać ograniczenia środowiska, w którym działa instancja. Z kolei scheduler_count wskazuje liczbę schedulerów utworzonych przez silnik dla obsługi zadań. Różnica między tymi wartościami może wynikać z konfiguracji affinity, ograniczeń CPU albo charakterystyki danej wersji SQL Server.
hyperthread_ratio opisuje stosunek logicznych procesorów przypadających na rdzeń fizyczny według informacji dostępnych dla silnika. Nie powinien być używany jako samodzielny dowód rzeczywistej topologii sprzętu, szczególnie w maszynach wirtualnych lub środowiskach z ograniczonym dostępem do informacji o hoście. Do oceny obciążenia procesorów trzeba połączyć dane z tego DMV z widokami sys.dm_os_schedulers, licznikami wydajności oraz obserwacją czasu oczekiwania na CPU.
Kolumna physical_memory_kb przedstawia ilość pamięci fizycznej raportowaną SQL Server w kilobajtach. committed_kb określa pamięć zatwierdzoną przez proces silnika, natomiast committed_target_kb wskazuje docelowy poziom pamięci, do którego SQL Server dąży w aktualnych warunkach. Sama wartość pamięci fizycznej nie mówi, ile RAM pozostaje wolne dla całego systemu. Do rozpoznania presji pamięci potrzebne są również informacje z innych DMV, między innymi dane o pamięci bufora, oczekiwaniach oraz błędach stron.
Interpretacja czasu uruchomienia i stanu instancji
sqlserver_start_time zawiera datę i czas uruchomienia silnika SQL Server. Jest to przydatny punkt odniesienia podczas analizy przerw w działaniu aplikacji, nieoczekiwanych restartów oraz nagłego wyzerowania statystyk gromadzonych w pamięci. Restart usługi SQL Server powoduje ponowne utworzenie struktur pamięciowych i wyzerowanie wielu liczników runtime, dlatego porównywanie wyników sprzed restartu z wynikami po restarcie może prowadzić do błędnych wniosków.
Przykładowe zapytanie pozwalające obliczyć czas działania instancji ma postać SELECT sqlserver_start_time, DATEDIFF(MINUTE, sqlserver_start_time, SYSDATETIME()) AS uptime_minutes FROM sys.dm_os_sys_info;. Wynik określa czas działania procesu silnika, a niekoniecznie czas działania całego serwera fizycznego lub systemu Windows. Jeśli komputer został uruchomiony wcześniej, ale usługa SQL Server była zatrzymywana i uruchamiana ponownie, oba czasy będą różne. Z tego powodu podczas diagnostyki trzeba osobno sprawdzać zdarzenia systemowe, dziennik SQL Server i historię restartów usług.
DMV nie jest narzędziem do zmiany konfiguracji. Odczytane wartości służą do rozpoznania warunków pracy i doboru dalszych zapytań. Przykładowo wykrycie małej liczby schedulerów nie dowodzi jeszcze awarii procesora, a wysoka wartość committed_kb nie oznacza automatycznie wycieku pamięci. Każdy wniosek powinien uwzględniać obciążenie, konfigurację max server memory, liczbę baz danych, rodzaj wykonywanych zapytań oraz czas wystąpienia problemu.
Wykorzystanie sys.dm_os_sys_info w diagnostyce serwera
Podczas analizy wolnego działania SQL Server dane z sys.dm_os_sys_info pomagają ustalić, czy dalsze poszukiwania powinny obejmować przede wszystkim CPU, pamięć, restart instancji czy różnicę między zasobami hosta a zasobami widocznymi dla silnika. Warto zapisać wynik wraz ze znacznikiem czasu i nazwą instancji, a następnie porównać go z wynikami z sys.dm_os_schedulers, sys.dm_exec_requests oraz sys.dm_os_process_memory. Takie zestawienie pozwala odróżnić trwałe ograniczenie zasobów od krótkotrwałego skoku obciążenia.
Wartości pamięci podawane w kilobajtach można przeliczyć na megabajty, dzieląc je przez 1024, a na gigabajty, dzieląc przez 1048576. Podczas porównywania z dokumentacją sprzętową należy pamiętać, że SQL Server może raportować zasoby dostępne dla konkretnej instancji, a nie pełną pamięć zainstalowaną w urządzeniu. Ograniczenia systemowe, konfiguracja uruchomieniowa i ustawienia dostępności CPU mogą sprawić, że wynik będzie niższy od wartości podawanej w specyfikacji serwera.
W przypadku problemów z usługą lub wydajnością serwera diagnostykę należy rozpocząć od zebrania aktualnego wyniku DMV, informacji o wersji SQL Server oraz danych z dziennika błędów. Następnie można sprawdzić, czy czas uruchomienia odpowiada zgłaszanej awarii, czy liczba schedulerów jest zgodna z przydzielonymi procesorami logicznymi oraz czy poziom zatwierdzonej pamięci koreluje z presją pamięci obserwowaną przez system. Takie podejście ogranicza ryzyko przypisania problemu niewłaściwemu podzespołowi lub błędnej konfiguracji.
