SQL Server 2005: Indeks większy niż dane przechowywane

Question

Stworzyłem 1 bazę danych z 2 grupami plików: 1 podstawową i 1 indeksem.

• Podstawowa grupa plik zawiera 1 plik danych (* .mdf): przechowywać wszystkie tabele
• grupa plik Index obejmuje 1 plik indeksu (* .ndf): przechowywać wszystkie indeksy

większość indeksów są indeksami nieklastrowymi

Po krótkim czasie korzystania z bazy danych plik danych ma rozmiar 2 GB, ale plik indeksu ma wartość 12 GB. Nie wiem, co się stało w mojej bazie danych.

Mam kilka pytań:

1. Jak zmniejszyć rozmiar pliku indeksu?
2. Skąd wiadomo, co jest przechowywane w pliku indeksu?
3. Jak prześledzić wszystkie oddziaływania do pliku indeksu?
4. Jak mogę ograniczyć rozmiar pliku indeksu?

Answer 1

Jak zmniejszyć rozmiar pliku indeksu?

Upuść niektóre niepotrzebne indeksy lub zmniejsz liczbę kolumn w istniejących. Pamiętaj, że kolumna (kolumny) klastra jest "ukrytą" kolumną zawierającą wszystkie indeksy nieklastrowe.

Jeśli masz indeks na a,b,c,d i indeks na a,b,c możesz rozważyć upuszczenie drugiego, ponieważ pierwszy obejmuje drugi.

może także być w stanie find potential unused indexes patrząc na sys.dm_db_index_usage_stats

Jak wiedzieć, co jest przechowywane w pliku indeksu?

Przechowuje to, co zdefiniowałeś do przechowywania! Poniższe zapytanie pomoże Ci powiedzieć, która indeksuje korzysta najwięcej miejsca i z jakiego powodu (w danych rzędu, dane LOB)

SELECT convert(char(8),object_name(i.object_id)) AS table_name, i.name AS index_name, 
    i.index_id, i.type_desc as index_type, 
    partition_id, partition_number AS pnum, rows, 
    allocation_unit_id AS au_id, a.type_desc as page_type_desc, total_pages AS pages 
FROM sys.indexes i JOIN sys.partitions p 
     ON i.object_id = p.object_id AND i.index_id = p.index_id 
    JOIN sys.allocation_units a 
     ON p.partition_id = a.container_id 
     order by pages desc 

Answer 2

moje przypuszczenie (co moim zdaniem jest gdzie marc_s jest również na czele) to ty” ve zadeklarowało indeksy klastrowe, aby przynajmniej niektóre z twoich tabel były w grupie plików indeksu. Indeks klastrowy określa, w jaki sposób (i gdzie) są przechowywane rzeczywiste dane dla tabeli.

Opublikowanie niektórych kodu z pewnością pomoże innym zidentyfikować problem.

Myślę, że Martin Smith odpowiedział na twoje pozostałe pytania całkiem dobrze. Po prostu to dodaję ... Jeśli chcesz ograniczyć rozmiary indeksu, musisz ocenić swoje indeksy. Nie dodawaj indeksów tylko dlatego, że uważasz, że możesz ich potrzebować. Wykonuj testy z realistycznymi (lub idealnie rzeczywistymi) obciążeniami bazy danych, aby sprawdzić, które indeksy rzeczywiście będą potrzebne do zwiększenia wydajności. Indeksy mają dla nich koszty. Oprócz kosztów związanych z przestrzenią kosmiczną, które widzisz, zwiększają także nakładki i aktualizacje, które muszą zsynchronizować indeksy. Z powodu tych kosztów zawsze powinieneś mieć dobry powód, aby dodać indeks i powinieneś świadomie pomyśleć o kompromisach.

Answer 3

Należy pamiętać, że w rzeczywistości całkowita ilość pamięci wymagana dla indeksów jest większa niż pojemność wymagana do przechowywania danych tabeli w danej bazie danych.

Twój konkretny scenariusz wydaje się jednak dość wygórowany. Jak zauważyli inni, jeśli przypisałeś indeks klastrowany dla danej tabeli, aby zamieszkał w osobnym pliku danych (plik danych indeksu), to w tym pliku również będzie znajdował się cały sam stół fizyczny, ponieważ w sposób Indeks klastrowany jest tabelą.

Dostarczenie szczegółowych informacji na temat schematu tabel i struktur indeksu pozwoli nam uzyskać bardziej szczegółowe wskazówki.

Inne plakaty wspomnieli, że:

• Należy przejrzeć indeks definicje duplikatów indeksów. Spójrz na Identifying Overlapping Indexes przez Brent Ozar.
• Powinieneś sprawdzić, aby zidentyfikować nieużywane indeksy: . Zobacz artykuł SQL Server Pedia Artykuł: Finding Unused Indexes

Inne sposoby eksploracji obejmują przegląd fragmentacji indeksów, ponieważ może to zwiększyć wymagania dotyczące pamięci masowej.

Ciężka fragmentacja, szczególnie w indeksie klastrowym tabeli zawierającej dane LOB, może znacznie zwiększyć zapotrzebowanie na pamięć masową. Reorganizacja indeksu klastrowanego w tabelach zawierających dane LOB spowoduje kompaktowanie danych LOB.

See Reorganizing and Rebuilding Indexes

Answer 4

@ odpowiedź Martin-Smith jest prawie co potrzebne ...

Oto w jaki sposób sortowania według wielkości indeksu w GB (MSSQL używa 8kB informacjami ze stron == 128 stron/MB)

SELECT 
    object_name(p.object_id) AS table_name 
    , i.name AS index_name 
    , i.index_id 
    , i.type_desc AS index_type 
    -- , partition_id 
    -- , partition_number AS pnum 
    -- , allocation_unit_id AS au_id 
    , rows 
    , a.type_desc as page_type_desc 
    , total_pages/(1024 * 128.0) AS sizeGB 
FROM 
    sys.indexes i 
    JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id 
    JOIN sys.allocation_units a ON p.partition_id = a.container_id 
    JOIN sys.all_objects ao ON (ao.object_id = i.object_id) 
    WHERE ao.type_desc = 'USER_TABLE' 
ORDER BY 
    -- table_name 
    sizeGB DESC