Power BI Incremental Refresh: einrichten und Fehler vermeiden

Der Umsatzreport ist schnell, aber seine Aktualisierung dauert jeden Morgen länger. Immer wieder werden Jahre alter Buchungen geladen, obwohl sich überwiegend die jüngsten Daten ändern. Power BI Incremental Refresh kann diesen Aufwand reduzieren. Damit die Zahlen trotzdem stimmen, müssen Zeitfilter, Korrekturfristen und Datenquelle zusammenpassen. Dieser Leitfaden führt dich von der Einrichtung bis zu fünf konkreten Abnahmetests.

Was macht Incremental Refresh in Power BI?

Power BI Incremental Refresh, die inkrementelle Aktualisierung, verarbeitet ausgewählte Zeitpartitionen einer Importtabelle. Eine Partition ist ein abgegrenzter Datenbereich, beispielsweise ein Monat. Power BI erstellt und verwaltet diese Bereiche im Service anhand deiner Richtlinie. Nach dem initialen Laden der Historie werden bei regulären Folgeläufen die vorgesehenen aktuellen Partitionen verarbeitet; ältere bleiben bis zum Ende ihrer Aufbewahrung bestehen.

Innerhalb einer tatsächlich aktualisierten Importpartition werden die Daten des betreffenden Zeitraums neu eingelesen. Power BI sucht dabei nicht anhand eines Geschäftsschlüssels einzelne Änderungen in der gesamten Historie. Diese Unterscheidung ist entscheidend für Nachbuchungen und Löschungen.

Das Verfahren optimiert die Datenaktualisierung. Langsame DAX-Abfragen oder überladene Berichtsseiten brauchen eine eigene Untersuchung. Eine Power-BI-Performance-Diagnose hilft, den tatsächlichen Engpass einzugrenzen.

Welche Voraussetzungen müssen erfüllt sein?

Die reine inkrementelle Importaktualisierung ist bereits mit Power BI Pro möglich. Die optionale Echtzeitfunktion mit einer zusätzlichen DirectQuery-Partition benötigt eine unterstützte Premium-, PPU- oder Embedded-Umgebung. Für die hier beschriebene Importlösung brauchst du diese Zusatzfunktion nicht.

Prüfe vor dem Start drei Punkte: Gibt es eine geeignete, stabile Datumsspalte? Kann die Quelle den angeforderten Zeitraum effizient liefern? Sind Datenquellenzugang und gegebenenfalls Gateway für den Service eingerichtet?

Für den Einstieg empfehlen wir eine große, regelmäßig wachsende Faktentabelle. Eine kleine Stammdatentabelle rechtfertigt den zusätzlichen Betriebsaufwand häufig nicht. Eine saubere Datenmodellierung in Power BI erleichtert die Auswahl. Halte vor der Umstellung Laufzeit und Datenübertragung als Vergleichswerte fest.

Wie groß muss das Refresh-Fenster sein?

Stell dir ein Handelsunternehmen vor: Für Analysen werden fünf Jahre Umsatzhistorie benötigt. Verkäufe kommen täglich hinzu; reguläre Retouren und Rechnungskorrekturen reichen bis zu 45 Tage zurück.

Für diesen fiktiven Praxisfall wählen wir eine Aufbewahrungsrichtlinie von fünf Jahren und ein Aktualisierungsfenster von 60 Tagen. Die zusätzlichen Tage sind ein bewusst gewählter Puffer. Diese Werte sind keine allgemeine Empfehlung. Eine Richtlinie in Jahren folgt zudem Kalenderperioden; fünf Jahre bedeuten nicht pauschal exakt 1.825 Tage.

Entscheidung	Vereinbarung im Beispiel	Zuständigkeit
Analysehistorie	Fünf Jahre als Richtlinie	Fachbereich
Reguläre Korrekturen	Bis 45 Tage rückwirkend	Finance und Quellsystemteam
Aktualisierung	60 Tage mit begründetem Puffer	BI-Team
Ältere Sonderkorrekturen	Geplanter historischer Nachladeprozess	Benannter Modellverantwortlicher

Das Refresh-Fenster muss die regulären Korrekturfristen des Geschäftsprozesses abdecken. Nutze Änderungsprotokolle, um das Alter korrigierter Geschäftsvorfälle zu ermitteln. Ein Durchschnitt von drei Tagen hilft wenig, wenn reguläre Retouren nach sechs Wochen eintreffen.

Unterscheide normale Korrekturen von seltenen Sonderfällen. Wenn regelmäßig ältere Änderungen vorkommen, ist das Fenster zu kurz. Wenn eine einmalige Systembereinigung alte Buchungen betrifft, kann ein gesonderter Nachladeprozess sinnvoller sein. Prüfe die Vereinbarung erneut, sobald sich Retourenfristen oder Abschlussprozesse ändern.

Das Schaubild zeigt, welche Datenbereiche beim regulären Folgelauf erneut geladen werden und welche im Modell bestehen bleiben.

Schematische Partitionen, nicht maßstabsgetreu. Historische Partitionen bleiben bis zum Ende ihrer Aufbewahrung erhalten. Dargestellt ist der Grundbetrieb ohne „Datenänderungen erkennen“; der erste Service-Refresh lädt zunächst die vorgesehene Historie.

RangeStart und RangeEnd richtig einrichten

Lege in Power Query unter „Parameter verwalten“ die Parameter RangeStart und RangeEnd an. Beide erhalten den Typ Datum/Uhrzeit; Groß- und Kleinschreibung müssen stimmen. Verwende zunächst einen kleinen Zeitraum mit vorhandenen Daten, beispielsweise den 1. bis 3. September 2026.

Filtere damit eine stabile Datumsspalte. Das folgende Beispiel setzt eine SQL-Tabelle mit TransactionDate vom Typ Datum/Uhrzeit voraus. Ersetze Server, Datenbank und Tabelle durch eure Werte:

let
    Quelle = Sql.Database("SQLSERVER", "Analytics"),
    Umsatz = Quelle{[Schema="dbo", Item="FactSales"]}[Data],
    Zeitfenster = Table.SelectRows(
        Umsatz,
        each [TransactionDate] >= RangeStart
          and [TransactionDate] < RangeEnd
    )
in
    Zeitfenster

Die Startgrenze ist eingeschlossen, die Endgrenze ausgeschlossen. Dadurch gehört ein Grenzzeitpunkt genau zu einer Partition. Ein Datensatz am 2. September um 00:00 Uhr liegt im zweiten Tagesbereich. Die Kombination >= und <= würde ihn an einer gemeinsamen Grenze doppelt einschließen.

Die Desktop-Werte begrenzen deinen Testausschnitt. Nach der Veröffentlichung setzt der Service die Grenzen entsprechend der Richtlinie. Bei einem ganzzahligen Datumsschlüssel brauchst du eine passende Umrechnung der Parameter; wandle nicht unüberlegt jede Zeile der Quellspalte um.

An zwei angrenzenden Tagesbereichen wird sichtbar, wie ein Grenzzeitpunkt eindeutig zugeordnet wird.

Partition A endet vor dem 2. September um 00:00 Uhr. Genau zu diesem Zeitpunkt beginnt Partition B. Die Tagesbereiche illustrieren das Grenzprinzip; die tatsächliche Partitionsgranularität hängt von der Richtlinie ab.

Query Folding prüfen: Erreicht der Zeitfilter die Quelle?

Query Folding übergibt unterstützte Power-Query-Schritte an die Datenquelle. Für SQL soll die Zeitbedingung bereits dort wirken. Andernfalls kann die Quelle weiterhin den Gesamtbestand übertragen, den Power Query erst anschließend filtert.

Eine kleine Ergebnistabelle beweist noch keinen kleinen Datenabruf. Prüfe am Filterschritt „Native Abfrage anzeigen“, sofern der Connector dies unterstützt. Eine deaktivierte Option beweist allein noch keinen Folding-Fehler. Entscheidend ist die tatsächlich ausgeführte Quellabfrage mit wirksamer Start- und Endgrenze; ein Datenbank-Trace kann das nachweisen.

Platziere den Zeitfilter möglichst früh. Prüfe danach, ob weitere Transformationen seine Übergabe verhindern. Bei selbst geschriebenem SQL müssen beide Parameter wirksam in der Quellabfrage ankommen. Für reine Importlösungen kann auch eine direkt parametrisierte Quellabfrage den Zeitraum begrenzen.

Vergleiche kleine und größere Zeitfenster unter möglichst ähnlicher Quelllast. Dokumentiere den Cache-Zustand und betrachte Laufzeit, übertragene Datenmenge und Quellenbelastung gemeinsam. So wird aus „wirkt schneller“ eine nachvollziehbare technische Prüfung.

Entscheidend ist, an welcher Stelle der Zeitfilter greift. Derselbe Ergebnisausschnitt kann mit sehr unterschiedlicher Datenübertragung entstehen.

SQL-Beispiel: Die Datenströme sind schematisch und stellen keine gemessenen Datenmengen dar. Ob der Filter durch Query Folding oder eine parametrisierte Quellabfrage wirkt, prüfst du an der tatsächlich ausgeführten Abfrage.

Bei Excel- und CSV-Dateien fehlt die Datenbank-Engine für einen solchen Zeilenfilter. Prüfe dort, ob bereits die Dateiauswahl selektiv erfolgen kann. Ein beliebiger SharePoint-Ordner ist keine gleichwertige Übertragung des SQL-Beispiels. Für große Dateibestände kann eine vorgelagerte Aufbereitung sinnvoll sein.

Richtlinie und Zusatzoptionen einstellen

Lade die gefilterte Tabelle und öffne per Rechtsklick „Inkrementelle Aktualisierung“. Aktiviere die Richtlinie und setze im Beispiel fünf Jahre Aufbewahrung sowie 60 Tage Aktualisierung. Bleibt der Schalter deaktiviert, prüfe zuerst den erkannten Parameterfilter.

„Nur vollständige Tage aktualisieren“ lässt den laufenden Kalendertag aus. Die Option prüft jedoch nicht, ob alle Vortagesbuchungen bereits in der Quelle angekommen sind. Für unser Abschlussreporting empfehlen wir deshalb, den Refresh nach dem bestätigten Lieferabschluss zu starten.

Ein abgeschlossener Kalendertag ist noch kein vollständig gelieferter Datenstand. Kontrolliere zusätzlich die Zeitzone: Service-Refreshes berücksichtigen die konfigurierte Refresh-Zeitzone; direkt über XMLA ausgelöste Vorgänge verwenden standardmäßig UTC.

„Datenänderungen erkennen“ prüft je Zeitraum im Aktualisierungsfenster den maximalen Wert einer separaten Änderungsspalte. Ein unveränderter Wert kann zum Überspringen des Zeitraums führen. Die Option erweitert das Fenster nicht auf die gesamte Historie und erkennt physische Löschungen nicht zuverlässig.

Unsere Empfehlung: Starte ohne diese Zusatzoptimierung. Belege zuerst den fachlich korrekten Grundbetrieb. Aktiviere sie erst, wenn die Änderungsspalte zuverlässig gepflegt wird und das Löschkonzept dazu passt.

Den ersten Refresh und historische Nachladungen planen

Nach der Veröffentlichung prüfst du Anmeldedaten, Gateway-Zuordnung und Aktualisierungsplan. Beim ersten Service-Refresh werden die Partitionen aufgebaut und die vorgesehene Historie geladen. Plane und überwache diesen Lauf separat. Ein kurzer Desktop-Test belegt noch nicht, dass die gesamte Historie innerhalb der verfügbaren Laufzeit verarbeitet werden kann.

Für reguläre Service-Aktualisierungen gelten auf Shared Capacity zwei Stunden, in Premium fünf Stunden. Quellen können eigene Timeouts setzen. Prüfe deshalb bei Abbrüchen, welche Komponente die Grenze erreicht. Für XMLA-basierte Verfahren gelten teilweise andere Bedingungen.

Für Korrekturen außerhalb des Fensters braucht ihr vorab einen ausführbaren Plan:

• Mit schreibfähigem XMLA-Endpunkt: Betroffene historische Partitionen lassen sich in einer unterstützten Umgebung gezielt verarbeiten. Berechtigungen und Schreibzugriff müssen eingerichtet sein.

• Mit Pro auf Shared Capacity: Dieser XMLA-Weg steht nicht zur Verfügung. Ein geplanter Neuaufbau kann ältere Korrekturen übernehmen. Prüfe vorher, ob die Quelle noch die vollständige Historie liefert und der Aufbau innerhalb der Grenzen gelingt.

Ein gewöhnlicher Klick auf „Jetzt aktualisieren“ verarbeitet ältere archivierte Partitionen nicht automatisch. Ebenso ist erneutes Veröffentlichen aus Desktop kein beiläufiger Reparaturschritt: Dabei können bestehende Partitionen und Daten ersetzt werden. Plane Modelländerungen entsprechend; für unterstützte Umgebungen sind reine Metadaten-Deployments vorgesehen.

Typische Fehler gezielt eingrenzen

Symptom	Mögliche Ursache	Nächster Prüfschritt
Kleines Fenster, lange Laufzeit	Zeitfilter greift erst nach der Übertragung	Quellabfrage und Datenmenge prüfen
Ältere Korrektur fehlt	Buchung liegt außerhalb des Fensters	Partitionierungsdatum mit Fenster vergleichen
Geschäftsschlüssel doppelt	Überlappende Grenzen oder verändertes Datum	Alte und neue Partition untersuchen
Gelöschte Buchung bleibt	Partition wurde nicht erneut verarbeitet	Löschung und Änderungserkennung gemeinsam testen
Refresh nach Deployment sehr lang	Historie wird neu aufgebaut	Art des Deployments prüfen

Das Partitionierungsdatum sollte für einen Datensatz stabil bleiben. Wird es nachträglich geändert, kann eine neue Version in einer aktuellen Partition erscheinen, während die alte Version im historischen Bereich verbleibt. Nutze einen separaten Änderungszeitstempel für die Änderungserkennung.

Mit fünf Abnahmetests in den Betrieb starten

Prüfe den Handelsfall in einer Testumgebung und halte erwartete Ergebnisse vorher fest:

1. Neue Buchung: Sie erscheint nach dem vorgesehenen Refresh mit richtigem Schlüssel und Betrag.

2. 45 Tage alte Korrektur: Der neue Wert ersetzt den alten innerhalb des 60-Tage-Fensters; der Schlüssel bleibt eindeutig.

3. 90 Tage alte Korrektur: Der normale Lauf übernimmt sie erwartungsgemäß nicht. Anschließend weist der vereinbarte Nachladeprozess ihre Übernahme nach.

4. Physische Löschung: Eine Buchung innerhalb des Fensters verschwindet nach tatsächlicher Neuladung ihrer Partition. Prüfe separat, ob die Änderungserkennung diesen Lauf auslösen würde.

5. Grenzzeitpunkt: Eine Buchung exakt auf der Partitionsgrenze erscheint einmal. Ergänze bei Tagesreporting einen Test für die wirksame Zeitzone.

Vergleiche Geschäftsschlüssel, Zeilenanzahl und Betrag mit einem zeitlich passenden Quellstand. Eine fehlende Rechnung und eine doppelt geladene Rechnung gleichen Betrags können sich in der Gesamtsumme ausgleichen. Die Summe allein würde den Fehler verdecken.

Ein erfolgreicher technischer Refresh bestätigt noch keinen fachlich vollständigen Datenstand. Dokumentiere zusätzlich Lieferabschluss, letzten vollständigen Geschäftstag und Fehlerzuständigkeit. Bewahre die Testfälle für spätere Modelländerungen auf. Ein messbares Betriebsziel lautet beispielsweise: Der bestätigte Vortagesstand steht rechtzeitig vor dem vereinbarten Reporting-Termin bereit.

---

Fazit - Weniger Daten laden, schneller aktualisieren

Incremental Refresh ist dann gut eingerichtet, wenn weniger Daten bewegt werden und Korrekturen nachvollziehbar im Modell ankommen. Entscheidend sind überschneidungsfreie Parametergrenzen, ein wirksamer Quellfilter und ein Refresh-Fenster, das zu euren Korrekturfristen passt. Für ältere Sonderkorrekturen braucht ihr einen getesteten Nachladeprozess.

---

Nächste Schritte

Beginne mit einer relevanten Faktentabelle. Leite das Fenster aus dem Geschäftsprozess ab und prüfe den Datenweg bis zur Quelle. Übertrage die Lösung nach bestandener Abnahme auf weitere Tabellen.

Wenn eure Aktualisierung zu lange dauert oder Nachbuchungen fehlen, arbeiten wir im Power BI Coaching am konkreten Modell: Quellfilter prüfen, Richtlinie passend einstellen und belastbare Testfälle entwickeln.