Indeksy zjadają 70–80% Twojej bazy D365 F&O i co piąty z nich jest nieużywany

Gdy organizacja po raz pierwszy analizuje, co właściwie wypełnia jej bazę Dynamics 365 Finance & Operations (D365FO), spodziewa się zobaczyć dane: transakcje, dokumenty, historię operacji. Rzeczywistość wygląda inaczej. W wielu przypadkach, zwłaszcza dla tabel operacyjnych, rozmiar indeksów znacząco przekracza rozmiar samych danych, a w skali całej aplikacji indeksy odpowiadają bardzo często za 70–80% konsumowanej przestrzeni. Do tego z naszych obserwacji u klientów wynika, że około 20% przestrzeni zajmowanej przez indeksy przypada na indeksy absolutnie nieużywane.

Wnioski z tych dwóch liczb są daleko idące. Skoro konsumpcja przestrzeni jest rozliczana względem limitu Database Storage Capacity, a jej przekroczenie kosztuje od 337,20 do 448,80 EUR za gigabajt rocznie (stan na 2026 rok), to największa pojedyncza rezerwa oszczędności w typowej instalacji nie leży w danych. Leży w indeksach. I, co najlepsze, sięgnięcie po nią jest operacją relatywnie bezpieczną i w pełni odwracalną. W tym artykule pokazujemy, jak podejść do niej metodycznie.

‍

Anatomia rozmiaru tabeli: dane + indeksy + unused

Rozmiar każdej tabeli w bazie składa się z trzech elementów. Pierwszym są dane. Faktyczna treść rekordów. Drugim są indeksy: struktury pomocnicze przyspieszające wyszukiwanie. Trzecim jest przestrzeń prealokowana (unused), czyli potencjalnie mały zapas, który usprawnia zarządzanie pamięcią. Kolumna „Reserved” w analizie rozmiarów tabel pokazuje sumę tych trzech składników i to właśnie relacja między nią a rozmiarem danych oraz indeksów jest pierwszą rzeczą, na którą należy patrzeć.

Dlaczego przy danych operacyjnych indeksy przerastają dane

Intuicyjnie indeks powinien być „spisem treści”, czyli czymś znacznie mniejszym od książki. Problem w tym, że tabele operacyjne platformy klasy enterprise obsługują dziesiątki różnych scenariuszy dostępu: różne formatki, raporty, procesy batch i integracje sięgają po te same rekordy różnymi ścieżkami, a każda ścieżka chce mieć swój indeks. W efekcie jedna tabela obrasta wieloma indeksami, z których każdy przechowuje kopię części danych w innym ułożeniu. I sumarycznie te „spisy treści” ważą więcej niż książka. To nie jest patologia konkretnego wdrożenia, lecz cecha platformy; patologią staje się dopiero utrzymywanie indeksów, których nikt nie używa.

‍

Skąd biorą się zbędne indeksy

Odpowiedź na pytanie „kto to nam zrobił” jest ważna nie dla rozliczeń, lecz dla metody, ponieważ pokazuje, dlaczego zbędnych indeksów nie da się wskazać przeglądem konfiguracji.

Standard Microsoftu, modyfikacje partnerów, automaty systemowe

Indeksy w środowisku pochodzą z trzech źródeł. Pierwsze to standard aplikacji. Indeksy zaprojektowane przez Microsoft pod typowe scenariusze, z których dana organizacja używa tylko części. Drugie to modyfikacje partnerów wdrożeniowych oraz rozwiązania ISV. Każde dokłada indeksy pod własne funkcje, także te nigdy niewdrożone do użycia. Trzecie to automaty Microsoftu, które potrafią tworzyć indeksy samoczynnie. Trzy źródła, żadnej wspólnej listy, żadnego właściciela całości. Dlatego jedyną wiarygodną metodą oceny nie jest pytanie „po co ten indeks powstał”, lecz pomiar „czy ktokolwiek go używa”.

Dlaczego klient nie zawsze ma wpływ na schemat indeksów

Warto podnieść wprost: nie zawsze klient ma wpływ na schemat indeksów uwzględniony na konkretnym środowisku. Część struktur przychodzi ze standardem i aktualizacjami, część tworzą automaty. A mimo to koszt ich utrzymania, licencyjny i wydajnościowy, ponosi w całości klient. To asymetria, która dodatkowo uzasadnia regularny przegląd: skoro nie kontrolujemy dopływu, kontrolujmy przynajmniej stan posiadania.

‍

20% nieużywanych: jak to zmierzyć u siebie

Sercem całej operacji jest pomiar, nie opinia. Silnik bazodanowy gromadzi statystyki użycia indeksów. Wystarczy je zebrać i przeanalizować przez adekwatnie długi okres.

Gromadzenie statystyk przez pełny cykl biznesowy

Kluczowe słowo brzmi „adekwatnie”. Statystyki z tygodnia czy miesiąca są zwodnicze, ponieważ nie obejmują procesów cyklicznych: obok operacji dziennych i tygodniowych istnieją procesy zamknięcia miesiąca i zamknięcia roku, które sięgają po indeksy nieużywane na co dzień. Wyłączenie indeksu na podstawie zbyt krótkiego okna pomiarowego oznacza ryzyko, że problem ujawni się w najgorszym momencie, przy zamknięciu okresu, pod presją terminów sprawozdawczych. Dlatego analiza musi objąć pełny cykl biznesowy organizacji.

Trik: testowe zamknięcie roku na środowisku nieprodukcyjnym

Czy to oznacza, że na decyzję trzeba czekać do zamknięcia roku na produkcji? Niekoniecznie. Część organizacji wykonuje testowe zamknięcie roku na środowisku nieprodukcyjnym. A z takiego środowiska również można pobrać statystyki z konkretnego okresu i połączyć je ze statystykami produkcyjnymi w jeden materiał do analizy. W ten sposób pokrycie pełnego cyklu osiąga się szybciej, bez rezygnowania z rzetelności pomiaru.

‍

Koszykowanie indeksów: nieużywane, iluzorycznie używane, krytyczne

Zebrane statystyki pozwalają podzielić indeksy na koszyki decyzyjne. Pierwszy koszyk to indeksy o zerowym użyciu w pełnym cyklu. Kandydaci oczywiści, stanowiący około 20%

przestrzeni indeksów. Trzeci, przeciwległy, to indeksy intensywnie używane. Nietykalne, bo to one trzymają wydajność systemu. Najciekawszy jest koszyk środkowy.

Indeks użyty 100 razy w pół roku: wyłączać czy zostawić

Istnieje pula indeksów wykorzystywanych iluzorycznie: jeżeli w przeanalizowanym półroczu dany indeks został użyty sto razy. Być może nawet przez pomyłkę. To najprawdopodobniej istnieje dla tych zapytań wygodny substytut wśród pozostałych indeksów tabeli. Rachunek jest prosty: sto odczytów w pół roku nie uzasadnia kosztu utrzymywania struktury aktualizowanej przy każdym zapisie do tabeli i konsumującej płatną przestrzeń przez cały rok. Decyzja w tym koszyku wymaga jednak spojrzenia na kontekst. Czym są te nieliczne użycia. I właśnie tu wiedza ekspercka o platformie robi różnicę między odważną optymalizacją a nieodpowiedzialną.

‍

Procedura wyłączenia: najpierw test, potem produkcja, zawsze odwracalnie

Operacyjnie całość składa się z sekwencji: gromadzenie statystyk, analiza i koszykowanie, przygotowanie skryptu wyłączeń, wykonanie najpierw na środowisku testowym, a po weryfikacji. Na produkcyjnym. Dwie właściwości czynią tę procedurę wyjątkowo bezpieczną jak na operację dotykającą produkcji. Po pierwsze, wyłączanie i włączanie indeksów nie jest zasobożerne. To zabieg relatywnie łatwy do przeprowadzenia. Po drugie, jest w pełni odwracalny: jeżeli po wyłączeniu któregoś indeksu wystąpi potrzeba, decyzję można cofnąć. Celem końcowym jest utrzymanie wysokiej wydajności środowiska produkcyjnego bez zakłócania pracy biznesu. Przy jednoczesnym odzyskaniu przestrzeni konsumowanej przez struktury, które na tę wydajność nie pracowały.

Czego ta operacja NIE obejmuje: reorganize i rebuild to inny zabieg

Na koniec ważne rozgraniczenie, bo bywa mylone. Konserwacja indeksów. Operacje reorganize i rebuild. To zupełnie odrębny element utrzymania: porządkuje wewnętrzną strukturę indeksów, ale nie jest satysfakcjonujący pod kątem optymalizacji konsumowanej przestrzeni. Zespół, który regularnie wykonuje rebuildy, nie rozwiązał problemu opisanego w tym artykule. Utrzymuje w dobrej formie również te indeksy, których nikt nie używa. Odzyskanie przestrzeni wymaga zabiegu opisanego wyżej: pomiaru użycia i świadomej decyzji o wyłączeniu struktur zbędnych.

Chcesz wiedzieć, ile Twojej bazy pracuje, a ile tylko kosztuje? Skontaktuj się z nami. Wyślemy prostą instrukcję self-checku. Wystarczą zrzuty z Power Platform Admin Center i wynik skryptu SQL badającego rozmiary tabel na środowisku testowym, a przygotujemy estymację możliwych uzysków, z wyszczególnieniem udziału indeksów, i ofertę fixed price na ich realizację.