Self-check w 15 minut: jak sprawdzić, czy problem storage capacity dotyczy Twojego tenanta

O kosztach przekraczania limitu Database Storage Capacity w Dynamics 365 Finance & Operations można przeczytać wiele — ale każda taka lektura kończy się tym samym pytaniem: dobrze, a czy to dotyczy nas? Odpowiedź nie wymaga projektu, audytu ani zewnętrznego konsultanta. Wymaga kwadransa, dostępu do Power Platform Admin Center i — dla dociekliwych — jednego skryptu SQL na środowisku testowym. Ten artykuł jest instrukcją tego kwadransa: co przygotować, gdzie kliknąć, jak odczytać wynik i co z nim zrobić w każdym z trzech możliwych scenariuszy.

Czego potrzebujesz przed startem

Cały self-check opiera się na widoku, który znany i popularny Power Platform Admin Center (PPAC) oferuje w ramach szybkiego menu — wskazuje on wprost, czy problem dotyczy konkretnego tenanta.

Uprawnienia licencyjne — albo request do administratora

Jedynym warunkiem wstępnym są uprawnienia do przeglądania elementów licencyjnych w Power Platform Admin Center. Ścieżki są dwie. Jeżeli dysponujesz odpowiednimi uprawnieniami — wykonujesz sprawdzenie własnoręcznie. Jeżeli nie — wysyłasz konkretny request do administratora tenanta z prośbą o zrzuty odpowiedniego widoku; to również szybka i sprawna droga, bo administrator potrzebuje na nią kilku minut. W obu wariantach warto od razu poprosić o widok z rozbiciem na środowiska, nie tylko o wartość zbiorczą — rozbicie będzie potrzebne w interpretacji.

‍

Krok po kroku w PPAC

Gdzie znaleźć widok capacity

Po zalogowaniu do Power Platform Admin Center przejdź do sekcji poświęconej zasobom i pojemności (capacity). To centralne miejsce, w którym platforma zestawia uprawnienia licencyjne tenanta z jego rzeczywistym zużyciem — dla F&O interesuje nas pojemność bazodanowa środowisk finance and operations.

Jak odczytać należne vs konsumowane

Widok zestawia dwie wartości, których porównanie jest istotą całego self-checku. Pierwsza to pojemność należna — wyliczona z subskrypcji: pełnych stanowisk użytkowników, licencji activity, licencji device oraz puli dodawanej przez środowiska. Druga to pojemność konsumowana — suma rzeczywistego zużycia wszystkich środowisk Microsoft Managed w obrębie tenanta, czyli Tier 2–5 i produkcji; przy wielu projektach LCS sumowanie obejmuje środowiska wszystkich projektów. Różnica między tymi liczbami to Twoja ekspozycja — dodatnia albo ujemna.

Rozbicie na środowiska: gdzie siedzi ciężar

Trzeci element widoku to rozbicie konsumpcji na poszczególne środowiska. Warto mu poświęcić chwilę, bo to pierwsza wskazówka co do źródła problemu: jeżeli sandboxy ważą tyle co produkcja, są jej wiernymi kopiami i to od nich zacznie się redukcja; jeżeli dominuje produkcja, ciężar leży w danych i indeksach, a diagnozę pogłębi analiza tabel.

‍

Interpretacja wyniku: trzy scenariusze

Porównanie dwóch liczb daje jeden z trzech obrazów — i każdy oznacza inne zadanie domowe.

Scenariusz zielony: konsumpcja poniżej należnego

Konsumpcja mieści się w limicie — dziś problemu nie ma. „Dziś" jest tu jednak słowem kluczowym: baza rośnie nieprzerwanie, więc zielony wynik to nie rozgrzeszenie, lecz punkt odniesienia. Zadanie: zanotować obie wartości i powtarzać pomiar cyklicznie, na przykład kwartalnie — bo to trend, nie stan, powie, ile czasu zostało do progu.

Scenariusz żółty: zbliżasz się do progu — trend ważniejszy niż stan

Konsumpcja jest poniżej limitu, ale margines topnieje. W tym scenariuszu najcenniejszą informacją jest tempo: porównanie bieżącego pomiaru z wcześniejszym pokazuje, ile gigabajtów przyrasta na kwartał — a stąd prosty rachunek wskazuje kwartał przecięcia progu. Zadanie: wykonać pomiar pogłębiony (skrypt SQL niżej) i zaplanować redukcję z wyprzedzeniem, we własnym tempie — bo porządki robione bez presji są tańsze i bezpieczniejsze niż te wymuszone.

Scenariusz czerwony: przekroczenie — wyliczenie ekspozycji finansowej

Konsumpcja przekracza pojemność należną. Ekspozycję liczy się wprost: nadwyżka w gigabajtach pomnożona przez stawkę add-onu Database Capacity — 448,80 EUR za gigabajt rocznie przy nadwyżce poniżej 1000 GB, 337,20 EUR powyżej (stan na 2026 rok). Przykładowo nadwyżka 1355 GB to 456 906 EUR rocznie. Ta liczba jest argumentem, z którym idzie się do zarządu — nie po budżet na add-on, lecz po decyzję o redukcji, bo zwykle to ona jest tańszą drogą do zgodności.

Krok pogłębiony: skrypt SQL na kopii produkcji — rozmiary tabel

Widok w PPAC mówi „ile"; na pytanie „gdzie konkretnie" odpowiada analiza rozmiarów tabel. Wykonuje się ją skryptem SQL na środowisku testowym — najlepiej na wiernej kopii produkcji, bo tylko ona odzwierciedla rzeczywisty rozkład ciężaru. Wynik zestawia dla każdej tabeli przestrzeń zarezerwowaną (Reserved) z rozbiciem na dane i indeksy — i to na tę relację należy patrzeć w pierwszej kolejności: w skali aplikacji indeksy odpowiadają bardzo często za 70–80% konsumowanej przestrzeni. Czołówka listy jest zwykle przewidywalna — linie zamówień sprzedaży, transakcje magazynowe, linie faktur, logi, tabele stagingowe, alerty — ale proporcje są specyficzne dla każdego środowiska i to one wyznaczają kolejność działań redukcyjnych.

‍

Co dalej z wynikiem

Self-check kończy się jednym z dwóch wniosków. Pierwszy: problem nas nie dotyczy — wtedy wynik staje się punktem odniesienia dla pomiarów cyklicznych i temat wraca za kwartał. Drugi: problem istnieje albo nadciąga — wtedy zrzuty z PPAC i wynik skryptu SQL są dokładnie tym materiałem, na podstawie którego można oszacować uzyski z redukcji: ile odda czyszczenie kategorii bez wymogu retencyjnego, ile wyłączenie nieużywanych indeksów, ile odchudzenie sandboxów, a ile archiwizacja danych historycznych. W ANEGIS na podstawie właśnie tych dwóch materiałów przygotowujemy estymację uzysków oraz ofertę fixed price na ich realizację w skończonym czasie — zadania po stronie klienta ograniczają się do wykonania zrzutów i uruchomienia skryptu, a prostą instrukcję obu czynności wysyłamy i pomagamy w jej przejściu, jeśli to potrzebne.

‍

‍