Dataverse: Warum freier Speicher täuscht

Die Übersicht zeigt ausreichend freien Speicher, trotzdem lässt sich eine Umgebung nicht wiederherstellen. Oder nach der Bereinigung bleibt eine rote Warnung sichtbar. Bei Dataverse muss dies weder einen falschen Einkauf noch erfolglose Löschung bedeuten. Administratoren vergleichen oft Anzeigen, die unterschiedliche Fragen beantworten.

Database, File und Log sind verschiedene Kapazitätstypen. Die Berechnung einer Überschreitung unterscheidet sich außerdem von den Voraussetzungen einer Umgebungsoperation. Bestimmen Sie zuerst, was nicht verfügbar ist und welche Kapazität der Vorgang benötigt. Entscheiden Sie erst danach zwischen Bereinigung, Aufbewahrung, zusätzlicher Kapazität und verbrauchsabhängiger Abrechnung.

Dieser Leitfaden nutzt das aktuelle Dataverse-Kapazitätsmodell. Microsoft trennt relationale Daten, Anhänge und Auditprotokolle. Das alte Speichermodell, Dataverse for Teams und bestimmte Umgebungstypen haben andere Zusammenhänge. Ein einzelner Prozentwert ohne Umgebung und Kapazitätstyp genügt nicht.

Drei Prüfungen statt eines Prozentwerts

Trennen Sie Mandantenstatus, Umgebungsstatus und gewünschten Vorgang. Zugewiesene Umgebungskapazität hilft bei der Verbrauchssteuerung; mehr Zuweisung schafft keine zusätzliche Berechtigung im Mandanten. Prüfen Sie den Verbrauch im Power-Platform-Kapazitätsbericht.

Dies ist unser Diagnoseverfahren. Es verhindert beispielsweise den Kauf von File-Kapazität für ein Database-Problem oder die Löschung von Audithistorie wegen einer Tabelle, die einen anderen Speichertyp verbraucht.

Freies File hilft einer vollen Database nicht

Aktuelle Regeln erlauben, bestimmte Defizite durch ungenutzte höherwertige Kapazität auszugleichen: Database kann Log und File unterstützen, Log wiederum File. Die Gegenrichtung ist nicht möglich. Es handelt sich um Kapazitätsbewertung, nicht um Tabellenverschiebung oder Datentypänderung. Microsoft beschreibt Richtung und effektives Defizit.

Ein Modellmandant hat 40 GB Database-Berechtigung und verbraucht 42 GB. Im File-Bereich sind 100 GB frei. Das Database-Defizit bleibt bei 2 GB, weil File es nicht abdecken kann. Wer nur überflüssige Anhänge entfernt, kann die eigentliche Database-Ursache verfehlen.

Ein anderer hypothetischer Mandant hat 20 GB Database und verbraucht 19,6 GB. Log überschreitet die eigene Berechtigung um 0,3 GB. Die freien 0,4 GB Database können dieses Log-Defizit im zulässigen Ausgleich abdecken. Eine sinnvolle Wachstumsreserve hat der Entwurf trotzdem nicht.

Das ist unser Rechenbeispiel für die Ausgleichsrichtung, keine vollständige Implementierung der Microsoft-Warnschwellen. Nutzen Sie im Incident das gemeldete effektive Defizit. Versprechen Sie dieselbe freie Kapazität im internen Budget nicht gleichzeitig zusätzlichem Log- und File-Verbrauch.

Warum die Wiederherstellung gesperrt bleiben kann

Für Vorgänge wie Erstellung, Kopie und Wiederherstellung nennt Microsoft mindestens 1 GB freie Kapazität. Der erforderliche Kapazitätstyp zählt; Ausgleich für Warnungen ist keine allgemeine Erlaubnis zur Durchführung. Die Kapazitätsbeschränkungen unterscheiden diese Prüfungen ausdrücklich.

Im vorherigen Modell sind nur 0,4 GB Database frei. Selbst wenn der Ausgleich das Log-Defizit behebt, ist das Minimum von 1 GB für einen entsprechend beschränkten Vorgang nicht nachgewiesen. Zusätzliche File-Kapazität schafft die fehlende Database-Reserve nicht.

Planen Sie Reserven auch für Wiederherstellung und Tests. Ein Budget, das der Produktion jeden verfügbaren GB überlässt, übersieht die Wartung. Bestimmen Sie die Reserve anhand benötigter Vorgänge und des Umgebungswachstums. Das vorgeschriebene Minimum ist keine empfohlene Reserve für den gesamten Betrieb.

Vor der Bestellung die Tabelle finden

Microsoft bietet Bereinigungsmethoden nach Kapazitätstyp und Tabelle. Der Leitfaden zur Speicherfreigabe unterscheidet beispielsweise Audithistorie und asynchrone Prozessdatensätze. „Log“ im Tabellennamen beweist keinen Verbrauch von Log-Kapazität.

Das ist keine Liste sofort auszuführender Löschbefehle. Holen Sie je Datengruppe die Freigabe des Verantwortlichen ein und prüfen Sie Anwendungsabhängigkeiten. Historie zu entfernen, die für eine Reklamation benötigt wird, spart nicht sinnvoll.

DataverseSearch ist der aktuelle Name des früheren Eintrags RelevanceSearch. Suchindizes können Database-Speicher belegen. Wenige Anwendungszeilen bei umfangreicher Indexierung lassen sich nicht allein anhand der Geschäftstabelle bewerten. Prüfen Sie den Umfang in der Dokumentation des Kapazitätsberichts.

Auditaufbewahrung leert den Speicher nicht einfach

Neue Auditaufzeichnungen zu stoppen und vorhandene Historie zu löschen sind verschiedene Eingriffe. Die Microsoft-Auditdokumentation trennt Aufbewahrungseinstellungen und Protokolllöschung. Bei der gewöhnlichen Einstellung erhalten neue Auditdatensätze die aktive Aufbewahrungsdauer; eine Änderung passt alte Datensätze nicht zwangsläufig rückwirkend an. Die Dokumentation nennt zugleich eine Richtlinienoption auf der Security-Seite für vorhandene Protokolle.

Dokumentieren Sie vor der Änderung Verwaltungsweg, betroffene Datensätze und die Notwendigkeit kontrollierter Löschung alter Historie. „Neunzig Tage eingestellt, ältere Protokolle sind weg“ benötigt einen Ergebnisnachweis statt eines Einstellungsbildes.

Eine Modellfirma erzeugt 0,2 GB Auditdaten je Woche und begrenzt mit einer neuen Regel die künftige Aufbewahrung. Das vorhandene Defizit kann trotzdem zu lange bestehen bleiben. Trennen Sie bereits verbrauchte Kapazität von der Begrenzung zukünftigen Wachstums. Die Zahl illustriert Planung und schätzt nicht Ihren tatsächlichen Verbrauch.

Langzeitaufbewahrung verändert die Nutzbarkeit

Dataverse Long-term Retention erhält Daten für eingeschränkten Lesezugriff. Sie lassen sich nicht in den aktiven Anwendungszustand zurückführen. Die Umgebung mit der Richtlinie muss eine Managed Environment sein; bei unerfüllter Voraussetzung können Richtliniendefinitionen deaktiviert bleiben. Audit- und Elastic-Tabellen werden nicht unterstützt; eine Einsparung bei Dateianhängen ist nicht garantiert.

Microsoft nennt durchschnittlich 50 % weniger Database-Verbrauch für aufbewahrte Daten. Das Ergebnis hängt von den Daten ab. Dies verspricht nicht, dass die Aufbewahrung halber Zeilen den gesamten Mandanten halbiert. Der Bericht enthält weiterhin erhaltene inaktive Daten; die Anzeige der Einsparung benötigt zusätzliche Zeit.

Fragen Sie konkret, ob die Firma abgeschlossene Fälle nur lesen oder in der ursprünglichen Anwendung wieder öffnen und bearbeiten muss. Im zweiten Fall kann der unumkehrbare Wechsel den gewünschten Ablauf verhindern. Testen Sie Zugriff und Beziehungen aufbewahrter Daten zunächst an einer kleinen Auswahl.

Auch Managed Environments haben Lizenzfolgen. Prüfen Sie Benutzerrechte vor der Aktivierung; siehe Power Apps in Managed Environments.

Sandboxbeschränkungen mit Bedingungen lesen

Die Dokumentation beschreibt die kommende Dataverse Storage Validation. Damit ist nicht belegt, dass sämtliche beschriebenen Einschränkungen bereits in Ihrem Mandanten aktiv sind. Microsoft verweist auf Rollout und Message center. Im beschriebenen Umfang führt eine ungelöste Überschreitung nach dreißig Tagen zum Administrationsmodus betroffener Sandboxes und nach neunzig Tagen zur Deaktivierung; die Daten bleiben erhalten.

Produktionsumgebungen, Sandboxes mit aktivem Pay-as-you-go und Mandanten mit Finance & Operations haben genannte Ausnahmen. Eine Ausnahme von der Deaktivierung schafft keine Kapazität und beweist nicht den Wegfall von Voraussetzungen für Verwaltungsoperationen. Den genauen Umfang nennt die Microsoft-Kapazitätsdokumentation.

Erfassen Sie für Ihren Betrieb den tatsächlichen Aktivierungszeitpunkt und den Beginn der effektiven Überschreitung. „CRM fällt nach neunzig Tagen aus“ vermischt Umgebungstyp, Rolloutbedingungen und Mechanismus. Ohne diese Prüfung ist es kein belastbarer Ausfalltermin für die Geschäftsführung.

Bereinigen, kaufen oder Pay-as-you-go

Bereinigung passt, wenn unnötige Daten identifizierbar sind und ihre Entfernung den fehlenden Kapazitätstyp freigibt. Zusätzliche Kapazität passt bei dauerhaftem Wachstum notwendiger Daten und Bedarf an Budgetplanbarkeit. Pay-as-you-go kann für getrennten oder schwankenden Verbrauch helfen, benötigt aber einen verantwortlichen Azure-Abrechnungsinhaber.

Dataverse-Governance-Richtlinien unterstützen den Datenlebenszyklus. Prüfen Sie Auswahlkriterien, Beziehungen und Geschäftsprozesse. Kapazität ohne Ursachenbehebung kauft Zeit; Datenlöschung ohne Verantwortlichen erzeugt einen anderen Incident.

Bereiten Sie für ein Angebot Berechtigung, tatsächlichen Verbrauch je Typ, monatliches Wachstum, Umgebungsliste und Reserve vor. Ergänzen Sie geplante Wiederherstellungen, Kopien und neue Umgebungen. Das ist präziser als „zehn GB hinzufügen“.

Ergebnis nach dem Eingriff prüfen

1. Sichern Sie ursprünglichen Bericht und genaue Fehlermeldung.
2. Führen Sie den freigegebenen Eingriff für den identifizierten Kapazitätstyp durch.
3. Prüfen Sie aktuellen Verbrauch und effektives Defizit. Verwechseln Sie Umgebungszuweisung nicht mit Einkauf.
4. Wiederholen Sie den gesperrten Vorgang, sobald dessen Voraussetzungen zur freien Kapazität passen.
5. Beobachten Sie das Banner getrennt. Microsoft beschreibt ungefähr tägliche Kapazitätsprüfung und einen eigenen Bannerzyklus, der bis zu sieben Tage dauern kann.

So kaufen Sie nicht erneut wegen einer langsam aktualisierten Meldung. Eine echte Fehlermeldung des Vorgangs darf trotzdem nicht ignoriert werden. Schließen Sie den Incident mit aktuellem Bericht und Ergebnis des verlangten Arbeitsvorgangs ab.