sys.dm_db_partition_stats zwraca statystyki dotyczące partycji tabel i indeksów, w tym liczbę wierszy.
Zakres informacji zwracanych przez sys.dm_db_partition_stats
sys.dm_db_partition_stats jest dynamicznym widokiem zarządzania w Microsoft SQL Server. Zwraca informacje o liczbie stron i wierszy zajmowanych przez partycje tabel oraz indeksów w bieżącej bazie danych. Widok działa na poziomie pojedynczej partycji, dlatego jeden obiekt może pojawić się w wielu wierszach, jeżeli tabela albo indeks został podzielony na partycje. Dane są przechowywane i prezentowane osobno dla każdego identyfikatora obiektu, indeksu oraz partycji.
Wyniki obejmują między innymi object_id, index_id, partition_number, row_count, used_page_count i reserved_page_count. row_count określa liczbę wierszy przypisaną do danej partycji i indeksu. used_page_count opisuje liczbę używanych stron, natomiast reserved_page_count wskazuje strony zarezerwowane dla partycji. Strona danych w SQL Server ma rozmiar 8 KB, a osiem stron tworzy jeden extent o rozmiarze 64 KB.
Interpretacja object_id, index_id i numeru partycji
Sam wynik widoku nie zawiera nazwy tabeli ani nazwy indeksu w formie wygodnej dla człowieka. Kolumna object_id identyfikuje obiekt w bazie, więc do odczytania nazwy tabeli można połączyć wynik z sys.objects albo sys.tables. Kolumna index_id określa strukturę indeksową. Wartość 0 oznacza stertę, czyli tabelę bez indeksu klastrowanego, a wartość 1 oznacza indeks klastrowany. Wartości większe od 1 dotyczą indeksów nieklastrowanych.
partition_number wskazuje numer partycji w obrębie konkretnej tabeli lub indeksu. W tabeli niepartycjonowanej zwykle występuje jedna partycja, ale nie należy zakładać tego bez sprawdzenia metadanych. Dla indeksu klastrowanego liczba wierszy zwykle odpowiada liczbie wierszy tabeli, natomiast indeks nieklastrowany może zawierać inną liczbę wpisów, zależnie od jego definicji i charakteru danych. Sumowanie wszystkich wartości row_count bez rozdzielenia struktur może więc prowadzić do zawyżonego wyniku.
Przy analizie konkretnej tabeli należy odfiltrować właściwy object_id oraz wybrać odpowiedni index_id. Do zsumowania rozmiaru tabeli można agregować strony według obiektu i indeksu, ale osobno dla sterty, indeksu klastrowanego oraz indeksów nieklastrowanych. W praktyce identyfikacja struktury wymaga zestawienia widoku DMV z katalogiem systemowym, na przykład sys.indexes, ponieważ dopiero tam znajdują się nazwy i właściwości indeksów.
Ocena rozmiaru danych i obciążenia struktur indeksowych
Widok jest użyteczny przy sprawdzaniu, ile miejsca zajmują dane oraz poszczególne indeksy. Porównanie used_page_count z reserved_page_count pozwala zauważyć różnicę między przestrzenią faktycznie wykorzystaną a zarezerwowaną. Nie jest to jednak bezpośredni pomiar rozmiaru pliku danych ani wolnego miejsca w bazie. Informacje o plikach i przydzielonej przestrzeni należy analizować z użyciem odpowiednich widoków katalogowych oraz DMV dotyczących plików baz danych.
Porównanie liczby wierszy z liczbą używanych stron może pomóc wskazać nietypową gęstość danych, rozrost indeksu albo wpływ szerokich rekordów. Taki wynik nie zastępuje jednak analizy planów wykonania, fragmentacji indeksów ani statystyk optymalizatora. Duża liczba stron może wynikać z rozmiaru kolumn, wierszy o zmiennej długości, kolumn typu LOB lub z obecności wielu indeksów. Samo row_count nie informuje o czasie wykonywania zapytań i nie wskazuje automatycznie, że dany indeks jest nieprawidłowy.
Przykładowe zapytanie diagnostyczne może połączyć DMV z nazwami obiektów i indeksów:
SELECT s.name AS schema_name, t.name AS table_name, i.name AS index_name, ps.index_id, ps.partition_number, ps.row_count, ps.used_page_count, ps.reserved_page_count FROM sys.dm_db_partition_stats AS ps JOIN sys.tables AS t ON t.object_id = ps.object_id JOIN sys.schemas AS s ON s.schema_id = t.schema_id LEFT JOIN sys.indexes AS i ON i.object_id = ps.object_id AND i.index_id = ps.index_id; Wynik należy interpretować w kontekście konkretnej bazy, ponieważ DMV zwraca dane dla bazy, w której wykonywane jest zapytanie. Przed porównaniem z wcześniejszym pomiarem warto zachować takie same filtry i sposób agregacji.
Wykorzystanie DMV przy sprawdzaniu bazy SQL Server
sys.dm_db_partition_stats może być elementem kontroli wzrostu tabel, weryfikacji skutków masowego importu oraz porównywania rozmiaru indeksów przed i po zmianach. Przy tabelach partycjonowanych szczególnie istotne jest analizowanie każdej partycji oddzielnie. Nierównomierna liczba wierszy lub stron może wskazywać na nierówny rozkład danych względem funkcji partycjonującej, ale potwierdzenie przyczyny wymaga sprawdzenia schematu partycjonowania, granic funkcji oraz wartości klucza partycjonowania.
Dostęp do informacji zwracanych przez widoki dynamicznego zarządzania podlega uprawnieniom SQL Server. Wymagane uprawnienia zależą od wersji silnika i kontekstu użycia DMV, dlatego przy błędzie odmowy dostępu należy sprawdzić dokumentację konkretnej wersji SQL Server oraz uprawnienia konta wykonującego zapytanie. Brak wyników, niepełny wynik lub błąd uprawnień nie powinien być automatycznie uznawany za dowód pustej tabeli. Diagnostykę trzeba wykonywać na właściwej bazie i z konta, które ma prawo odczytać wymagane metadane.
Podczas serwisowej diagnostyki komputera używanego do pracy z SQL Server można sprawdzić, czy problem wynika z rozmiaru bazy, przeciążenia dysku, błędnej konfiguracji połączenia albo nieprawidłowo działającego programu klienckiego. Sam widok sys.dm_db_partition_stats opisuje stan struktur w silniku bazy danych; nie diagnozuje awarii pamięci RAM, dysku, systemu Windows ani uszkodzeń sprzętowych. Wnioski powinny więc łączyć odczyt DMV z obserwacją dzienników SQL Server, stanu nośnika i zachowania aplikacji wykonującej zapytania.
