Dataverse: proč nesedí volná kapacita

V přehledu je dost volného místa, přesto nejde obnovit prostředí. Nebo se po úklidu stále zobrazuje červené varování. U Dataverse to nemusí znamenat chybný nákup ani neúspěšné mazání. Správce často porovnává ukazatele, které odpovídají na různé otázky.

Databáze, soubory a logy nejsou zaměnitelné kapacity. Vyhodnocení překročení navíc není totéž jako podmínka konkrétní operace s prostředím. Nejdříve určete, co je skutečně nedostupné a kterou kapacitu operace potřebuje. Teprve potom rozhodujte mezi úklidem, archivací, doplněním kapacity a průběžným účtováním.

Článek pracuje se současným kapacitním modelem Dataverse. Microsoft odděluje relační data, přílohy a auditní logy. Starý model úložiště, Dataverse for Teams a některé zvláštní typy prostředí mají jiné souvislosti. Screenshot jediného procenta bez názvu prostředí a typu kapacity proto nestačí.

Tři kontroly místo jednoho procenta

U incidentu si oddělte stav tenanta, konkrétního prostředí a požadované operace. Kapacita přidělená prostředí pomáhá řídit spotřebu; zvýšení této alokace samo nevytváří nové oprávnění na úrovni tenanta. Pro přehled spotřeby použijte kapacitní report Power Platform.

Tabulka je náš diagnostický postup. Brání například tomu, aby správce nakoupil souborovou kapacitu kvůli problému databáze, nebo smazal auditní historii kvůli tabulce, která zabírá jiný typ úložiště.

Volné soubory nezachrání plnou databázi

Aktuální pravidla připouštějí kompenzaci některých deficitů nevyužitou vyšší kapacitou: databáze může pomoci logům a souborům, logy souborům. Opačný směr neplatí. Jde o vyhodnocení kapacity, nikoli o přesun tabulek či změnu jejich datového typu. Směr a účinný deficit popisuje Microsoft v kapacitních pravidlech.

Modelový tenant má nárok na 40 GB databáze a využívá 42 GB. Ve File zbývá 100 GB. Databázový deficit je stále 2 GB: volné File ho nepokrývá. Pokud však vyřešíte jen přebytečné přílohy, databázovou příčinu můžete úplně minout.

Opačný příklad: tenant má 20 GB databáze, spotřebuje 19,6 GB a jeho Log překračuje vlastní oprávnění o 0,3 GB. Volných 0,4 GB databáze může tento logový deficit při povoleném přepočtu pokrýt. Po jeho pokrytí ale návrh nemá rozumnou rezervu pro další růst.

To je vlastní aritmetický příklad pro vysvětlení směru kompenzace. Není to úplná implementace výpočtu varovných prahů Microsoftu. Při incidentu vycházejte z reportovaného účinného deficitu; stejný volný prostor nesmíte v interním rozpočtu slíbit současně dalším logům i souborům.

Proč může být blokovaná obnova

Microsoft u operací jako vytvoření, kopírování a obnova uvádí požadavek dostupné kapacity nejméně 1 GB. Posuzuje se požadovaný typ kapacity; kompenzace pro varování není univerzální oprávnění provést operaci. Toto rozlišení je výslovně uvedeno v popisu kapacitních omezení.

V předchozím modelu má tenant pouze 0,4 GB volné databáze. I když povolená kompenzace odstraní logový deficit, není doložené minimum pro operaci vyžadující 1 GB. Zvýšení souborové kapacity nepřidá chybějící databázovou rezervu.

Provozní důsledek: rezerva musí být plánovaná i pro obnovu a testování. Rozpočet „všechny GB smíme spotřebovat v produkci“ přehlíží údržbu. Konkrétní velikost rezervy určete podle operací, které potřebujete provádět, a růstu prostředí; povinné minimum není doporučená rezerva pro celý provoz.

Nejdříve najděte tabulku, potom objednávejte

Microsoft nabízí postupy úklidu podle kapacitního typu a tabulky. Přehled uvolnění místa rozlišuje například auditní historii a záznamy asynchronních procesů. Název obsahující slovo „log“ sám o sobě neprokazuje spotřebu Log kapacity.

Tabulka není seznam příkazů k okamžitému smazání. U každé kandidátní skupiny si vyžádejte souhlas vlastníka dat a ověřte závislosti na aplikacích. Šetřit kapacitu odstraněním historie, kterou firma potřebuje pro reklamaci, není úspora.

DataverseSearch je nynější název položky dříve uváděné jako RelevanceSearch. Indexy mohou přispívat k databázové spotřebě. Pokud aplikace ukládá málo řádků, ale široce indexuje obsah, posouzení jen podle objemu obchodní tabulky bude neúplné. Rozsah indexace ověřte v dokumentaci kapacitního reportu.

Auditní retence není tlačítko na vyprázdnění

Vypnutí dalšího auditu a odstranění existující historie jsou odlišné zásahy. V aktuální dokumentaci správy auditu Microsoft rozlišuje nastavení doby uchování i odstranění auditních logů. U běžného nastavení se doba uchování zapisuje k nově vzniklým auditním záznamům; změna nemusí zpětně změnit staré záznamy. Dokumentace zároveň uvádí možnost politiky na stránce Security aplikovat retenci i na existující logy.

Před změnou proto zapište, kterou správní cestu používáte, na jaké záznamy dopadne a zda potřebujete kontrolované odstranění staré historie. Tvrzení „nastavili jsme 90 dní, tedy všechny starší logy už zmizely“ musí potvrdit výsledek, nikoli screenshot nastavení.

U modelové firmy roste audit o 0,2 GB týdně a nová pravidla omezí budoucí uchování. Jednorázový existující deficit tím nemusí zmizet včas. Oddělte nápravu již spotřebované kapacity od omezení příštího růstu. Číslo je ilustrace plánování, ne odhad spotřeby vašeho prostředí.

Dlouhodobá retence má cenu v použitelnosti

Dataverse long-term retention ponechává data pro omezené čtení. Nelze je přesunout zpět do aktivního aplikačního stavu. Prostředí s politikou musí být Managed Environment; bez splnění požadavku mohou existující definice politik zůstat zakázané. Retence nepodporuje auditní ani elastic tabulky a nezaručuje úsporu souborových příloh.

Microsoft uvádí průměrné snížení databázové spotřeby o 50 % u přesunutých dat; skutečný výsledek závisí na datech. To nelze použít jako slib, že archivace půlky řádků zmenší celý tenant na polovinu. Report zahrnuje i ponechaná neaktivní data a aktualizace výsledku trvá další čas.

Pro výběr kandidátů si položte konkrétní otázku: bude firma tyto uzavřené případy jen číst, nebo je potřebuje znovu otevřít a zpracovat v původní aplikaci? U druhého scénáře může nevratný přechod do retence znemožnit požadovaný postup. Nejdříve otestujte práci s uchovanými daty a vztahy na malém vzorku.

Také zahrnutí Managed Environments má licenční dopady. Před jeho zapnutím ověřte oprávnění uživatelů; postup rozebírá článek Power Apps v Managed Environments.

Nové omezení sandboxů čtěte s podmínkami

Dokumentace popisuje připravovanou Dataverse Storage Validation. Nejde o doklad, že všechny popsané restrikce už platí ve vašem tenantovi. Microsoft odkazuje na rollout a Message center. Pro popsaný rozsah uvádí po nevyřešeném překročení režim administrace sandboxů po 30 dnech a jejich deaktivaci po 90 dnech; data zůstávají uchována.

Produkční prostředí, sandboxy s aktivním pay-as-you-go a tenanty s Finance & Operations mají v tomto mechanismu uvedené výjimky. Výjimka z deaktivace však není nová kapacita ani potvrzení, že přestanou platit podmínky správních operací. Přesný rozsah je v kapacitní dokumentaci Microsoftu.

Pro vlastní provoz zapište datum skutečné aktivace funkce v tenantovi a začátek účinného překročení. Obecná hláška „po 90 dnech přestane fungovat CRM“ zaměňuje typ prostředí, podmínky rolloutu a konkrétní mechanismus. Bez jejich ověření ji neposílejte vedení jako termín výpadku.

Úklid, nákup, nebo pay-as-you-go

Úklid dává smysl, pokud dokážete identifikovat nepotřebná data a jejich odstranění opravdu uvolní nedostatkový typ kapacity. Doplnění kapacity dává smysl, pokud potřebná data rostou dlouhodobě a chcete rozpočtovou předvídatelnost. Pay-as-you-go může pomoci u oddělené nebo proměnlivé spotřeby, vyžaduje však odpovědného vlastníka Azure účtování.

Governance politiky Dataverse poskytují nástroje pro řízení životního cyklu dat. U politiky posuzujte výběrové podmínky, dopad na vztahy a obchodní proces. Přidání kapacity bez změny příčiny růstu kupuje čas; odstranění dat bez vlastníka vytváří jiný incident.

Pro nabídku připravte současné oprávnění, skutečnou spotřebu podle typu, měsíční růst, seznam prostředí a požadovanou rezervu. Doplňte, zda se očekává obnova, kopie nebo nové prostředí. Tento podklad je přesnější než požadavek „přidejte nám deset GB“.

Ověření po zásahu

1. Uložte původní report a konkrétní chybovou zprávu.
2. Proveďte schválený zásah do přesně určeného typu kapacity.
3. Zkontrolujte čerstvou spotřebu a účinný deficit; nezaměňte přidělení kapacity prostředí za nákup.
4. Znovu proveďte původně blokovanou operaci, až její podmínky odpovídají dostupné kapacitě.
5. Odděleně sledujte banner. Microsoft uvádí přibližně denní vyhodnocení kapacity a samostatný obnovovací cyklus bannerů, který může trvat až sedm dní.

Poslední bod brání opakovanému nákupu jen kvůli pomalu obnovované hlášce. Zároveň není důvodem ignorovat chybu skutečné operace. Uzavření incidentu musí doložit čerstvý report i výsledek pracovního úkonu.