Refresh w Power BI padł i nie wiadomo czemu: jak w 10 minut znaleźć prawdziwą przyczynę

Gdzie w Power BI najszybciej sprawdzić szczegóły błędu refresh i co jest w nich najbardziej istotne?

Najszybciej sprawdzisz je w usłudze Power BI (Power BI Service), w historii odświeżeń dla konkretnego zestawu danych: wejdź w Workspace → wybierz Semantic model / Dataset → Refresh history (Historia odświeżeń) i otwórz nieudane uruchomienie. To miejsce jest najszybsze, bo pokazuje błąd dokładnie dla konkretnego podejścia do refresh (manualny, zaplanowany, API) i dla środowiska, w którym refresh realnie się wykonuje (Service, a nie Desktop).

W szczegółach błędu kluczowe są trzy rzeczy: pierwszy konkretny komunikat wskazujący przyczynę (np. uwierzytelnienie, brak dostępu, timeout, brama), kontekst „na czym” refresh się wyłożył (konkretne źródło danych/tabela/zapytanie lub etap) oraz techniczny identyfikator zdarzenia (np. Activity/Request/Correlation ID), bo pozwala jednoznacznie zidentyfikować próbę odświeżenia w logach i przy eskalacji do administratora/Microsoft Support. Z praktycznego punktu widzenia najczęściej najbardziej „mówią” pierwsze 1–2 linie komunikatu oraz identyfikator zdarzenia; długie ogólne opisy poniżej często są tylko kontekstem.

Jak odróżnić problem po stronie źródła danych od problemu w Power Query lub w gateway?

Najprościej rozdzielić te dwie klasy problemów przez sprawdzenie, czy źródło działa niezależnie od Power BI. Jeśli w tej samej sieci i z tych samych poświadczeń potrafisz połączyć się ze źródłem poza Power BI (np. zalogować się do bazy, wykonać zapytanie, pobrać plik z udziału, wejść na endpoint API), a odświeżanie w Power BI nadal się wywraca, to przyczyna jest zwykle po stronie Power Query lub warstwy połączenia (gateway/uwierzytelnianie w usłudze). Jeżeli natomiast problem odtwarza się także poza Power BI, to jest to sygnał, że źródło jest niedostępne, przeciążone, zwraca błędy lub wymaga innych parametrów/poświadczeń.

Drugi pewny test to porównanie zachowania w różnych środowiskach wykonania. Jeśli w Power BI Desktop odświeżenie działa, ale w Power BI Service się sypie, podejrzewaj gateway, mapowanie źródła, różnice w poświadczeniach albo ograniczenia środowiska usługi (np. brak dostępu sieciowego z usługi do zasobu on-prem). Jeśli natomiast identyczny błąd pojawia się już w Desktop, częściej winny jest sam krok w Power Query (np. transformacja, typy danych, odwołanie do nieistniejącej kolumny) albo problem po stronie źródła, który Desktop również „widzi”.

Trzeci sygnał daje charakter błędu. Błędy transportowe i dostępowe (timeout, „could not connect”, DNS/SSL, „gateway unreachable”, „credentials”, „access denied”) wskazują na ścieżkę sieć/uwierzytelnianie/gateway. Błędy, które pojawiają się dopiero po nawiązaniu połączenia (np. „The column … of the table wasn’t found”, błędy konwersji typów, błędy składni zapytania generowanego przez kroki), zwykle oznaczają problem w logice Power Query albo zmianę schematu danych w źródle, która „psuje” transformacje.

W praktyce chodzi o ustalenie, czy awaria występuje przed pobraniem danych (połączenie, autoryzacja, gateway), czy dopiero w trakcie ich przetwarzania (kroki Power Query). Jeśli potrafisz potwierdzić, że źródło odpowiada poprawnie poza Power BI, a błąd jest specyficzny dla odświeżania w usłudze, to najczęściej jest to problem w konfiguracji gateway/poświadczeń lub w samych krokach Power Query uruchamianych w innym kontekście niż Desktop.

Jak zdiagnozować błędy poświadczeń, MFA i wygasłych tokenów, które wyglądają jak losowe awarie?

Tego typu problemy często wyglądają „losowo”, bo odświeżanie działa do czasu wygaśnięcia tokenu OAuth, zmiany hasła/warunków dostępu, włączenia MFA albo utraty uprawnień. W praktyce nie są losowe: mają wspólny mianownik w tym, że Power BI (gateway, usługa lub źródło) nie może już uzyskać ważnego tokenu lub nie może użyć zapisanych poświadczeń.

Diagnozę zacznij od ustalenia miejsca uwierzytelnienia: czy odświeżanie idzie przez gateway (on-premises), czy jest to połączenie chmurowe bez gateway. Następnie sprawdź szczegóły ostatniego niepowodzenia w historii odświeżeń zestawu danych w usłudze Power BI i odczytaj dokładny komunikat (nie tylko „Refresh failed”). Jeżeli w treści pojawiają się sformułowania typu invalid_grant, unauthorized, token expired, need admin approval, interaction required, claims challenge lub wzmianki o AAD/Entra ID, to niemal zawsze jest to problem z tokenem/warunkami logowania, a nie z danymi.

Potwierdzenie wykonasz przez kontrolę stanu poświadczeń w ustawieniach zestawu danych: w Power BI Service wejdź w ustawienia datasetu i sprawdź sekcję poświadczeń/źródeł danych. Jeśli widzisz wymóg „zaloguj ponownie”, „poświadczenia są nieprawidłowe” lub brak możliwości walidacji, to przyczyną jest wygasły token albo zmiana zasad logowania. W przypadku gateway dodatkowo zweryfikuj, czy w samym gateway (zarządzanie źródłami danych) konto nadal ma poprawnie zapisane dane logowania i czy nie nastąpiła zmiana typu uwierzytelnienia (np. z konta użytkownika na konto usługi).

Rozróżnij trzy najczęstsze scenariusze:

• Wygasły token/odwołana zgoda – odświeżanie działało, potem nagle przestało; w komunikatach typowo widać ślady OAuth/AAD (np. invalid_grant). Rozwiązanie diagnostyczne: ponowne uwierzytelnienie w poświadczeniach datasetu (i ewentualnie ponowne udzielenie zgody aplikacji/łącznikowi, jeśli jest wymagane).
• MFA/Conditional Access – odświeżanie przestaje działać po zmianie polityk bezpieczeństwa; błędy często sugerują konieczność interakcji użytkownika (interaction required, claims). Diagnostycznie kluczowe jest stwierdzenie, że konto używane do odświeżania jest kontem użytkownika podlegającym MFA/politykom, więc odświeżanie bezinterakcyjne nie może dokończyć logowania.
• Zmiana hasła/uprawnień – błąd jest stały od momentu zmiany; w logach/komunikatach częściej będzie „unauthorized/forbidden” niż „timeout”. Diagnostyka: weryfikacja, czy konto nadal ma dostęp do źródła (baza, plik, API) i czy zapisane hasło/sekret jest aktualne.

Jeżeli komunikat jest ogólny, a podejrzenie nadal dotyczy poświadczeń, najprostszy test rozstrzygający to: wymuś ponowne logowanie w poświadczeniach datasetu i uruchom refresh ręcznie. Jeśli po tym odświeżanie wraca, a po pewnym czasie znów zaczyna „losowo” padać, to praktycznie pewne, że źródło opiera się o tokeny, które wygasają lub są blokowane politykami (MFA/Conditional Access), a nie o problem w samych transformacjach czy wydajności.

Jak wykryć zmiany schematu w źródle (kolumny, typy) zanim rozbiją odświeżenie na produkcji?

Najczęstszy powód „nagle padło” po stronie danych to zmiana schematu: zniknęła kolumna, zmieniła nazwę, doszła nowa, albo zmienił się typ (np. liczba stała się tekstem). Żeby złapać to zanim trafi na produkcję, trzeba wprowadzić kontrolę schematu na etapie developmentu i pipeline’u wdrożeniowego, a nie dopiero w samym odświeżeniu datasetu.

Praktycznie robi się to przez „kontrakt schematu” i test odświeżenia przed publikacją. Kontrakt oznacza, że dla kluczowych tabel/joinów trzymasz listę oczekiwanych kolumn wraz z typami (i ewentualnie informacją, które są obowiązkowe). Następnie w Power Query dodajesz krok, który jawnie wymusza oczekiwane kolumny i typy (np. przez wybór kolumn i ustawienie typów), a na końcu dodajesz krok walidujący: jeśli brakuje kolumny lub typ jest inny niż oczekiwany, zapytanie powinno zakończyć się czytelnym błędem. Dzięki temu problem wychodzi natychmiast w środowisku testowym i w logach widać wprost, czego brakuje albo co zmieniło typ, zamiast enigmatycznych błędów dalej w transformacjach.

Drugim elementem jest „preflight refresh” poza produkcją: wprowadzasz obowiązkowe odświeżenie testowe na kopii datasetu (albo w workspace testowym) uruchamiane po zmianach w źródle/ETL lub przed wdrożeniem. Jeśli odświeżenie nie przechodzi, nie promujesz zmian dalej. To jest jedyny pewny sposób, żeby sprawdzić realne zachowanie połączeń i transformacji na aktualnym schemacie źródła, bo samo „otworzyłem PBIX i działa” nie wykryje zmian, które ujawnią się dopiero przy pełnym odświeżeniu w usłudze.

Warto też ograniczać „dynamiczne” zachowania, które maskują zmiany schematu: automatyczne wykrywanie typów, rozwijanie kolumn z rekordów/JSON bez jawnego wyboru pól czy poleganie na kolejności kolumn. Im bardziej transformacje są deterministyczne (wyraźnie wybierasz kolumny, nadajesz typy i kontrolujesz nazwy), tym wcześniej zmiana schematu zamienia się w jednoznaczny błąd walidacji zamiast awarii w losowym miejscu procesu.

Jak rozpoznać time-outy i limity zasobów oraz co zmienić, żeby refresh mieścił się w oknie?

Time-out rozpoznasz po tym, że odświeżanie kończy się po stałym, powtarzalnym czasie i w historii odświeżeń pojawia się komunikat o przekroczeniu limitu czasu po stronie źródła danych, bramy (On-premises data gateway) albo usługi Power BI. W praktyce wygląda to tak, że długość trwania kolejnych prób „dobija” do podobnej wartości, a błąd jest typu „timeout”, „operation timed out”, „execution time exceeded” lub analogiczny. Z kolei limity zasobów (CPU/pamięć) najczęściej objawiają się komunikatami o braku pamięci, zbyt dużym zapytaniu/odpowiedzi, „resource exceeded”, „out of memory”, nieoczekiwanym przerwaniem procesu albo znaczącą niestabilnością czasu odświeżania: raz trwa krótko, innym razem nagle rośnie, mimo że dane źródłowe są podobne.

Żeby upewnić się, gdzie powstaje ograniczenie, porównaj trzy rzeczy: czas trwania w historii odświeżeń w usłudze, informacje diagnostyczne po stronie bramy (logi gateway pokazują, czy zapytania są przerywane i po jakim czasie) oraz zachowanie tych samych kroków w Power Query Desktop. Jeśli w Desktop działa, a w usłudze regularnie „ucina” po podobnym czasie, to typowo ograniczenie jest po stronie usługi/bramy/źródła uruchamianego w trybie serwerowym (inne warunki wykonania niż lokalnie). Jeśli już w Desktop zapytanie często kończy się błędem pamięci lub trwa nieproporcjonalnie długo przy rosnącej objętości danych, to problemem jest koszt obliczeń lub ilość przetwarzanych danych (czyli zasoby), a nie tylko limit czasu.

Aby refresh mieścił się w oknie, najpewniejszą dźwignią jest zmniejszenie pracy wykonywanej podczas odświeżenia i skrócenie czasu pojedynczych zapytań: ogranicz wolumen danych pobieranych do modelu (filtrowanie po dacie/zakresie, selekcja tylko potrzebnych kolumn), dopilnuj, by transformacje wykonywały się po stronie źródła (query folding), unikaj kosztownych operacji w Power Query, które wymuszają przetworzenie całej tabeli lokalnie (np. sortowania, dodawania indeksów, złożonych grupowań na dużych tabelach), oraz rozbij zbyt ciężkie zapytania na etapy realizowane w źródle (widoki, zapytania natywne) albo na kilka mniejszych tabel ładowanych niezależnie. Jeśli problemem jest „ściana” czasowa po stronie źródła lub bramy, weryfikuj też ustawienia limitu czasu w konektorze/źródle (tam, gdzie jest to obsługiwane) i przede wszystkim przyspiesz zapytanie: indeksy w bazie, eliminacja niepotrzebnych JOIN-ów, agregacje w źródle zamiast w Power Query. Jeżeli natomiast odświeżanie przekracza okno, bo dane przyrastają, rozważ wprowadzenie odświeżania przyrostowego (incremental refresh), aby przetwarzać tylko nowy zakres danych zamiast całości przy każdym odświeżeniu.

Jak incremental refresh potrafi maskować lub generować błędy i jak to sprawdzić?

Incremental refresh odświeża tylko część danych (partycje) na podstawie kolumny daty i zdefiniowanego okna „odśwież” oraz „przechowuj”. To powoduje, że błąd może „zniknąć” albo pojawić się tylko czasami: jeśli problem dotyczy rekordów spoza okna odświeżania, to nie jest już wykonywane zapytanie dla tych danych, więc refresh przechodzi mimo że źródło (lub logika w Power Query) dla starszego zakresu jest wadliwe. Z drugiej strony błąd może pojawić się dopiero po włączeniu incremental refresh, bo mechanizm opiera się na parametrach zakresu i zapytaniach filtrowanych do źródła; jeśli filtrowanie nie jest składane do źródła (brak query folding) albo typ/semantyka kolumny daty jest niejednoznaczna, to odświeżanie partycji może generować inne zapytania niż wcześniej i wywołać błąd, którego nie było przy pełnym odświeżeniu.

Najczęstsze „maskowanie” wynika z faktu, że incremental refresh nie dotyka partycji historycznych, więc nie uruchamia kroków, które dla starego zakresu danych kończyły się błędem (np. nietypowe wartości, zmiany schematu w archiwum, brakujące kolumny w dawnych plikach). Najczęstsze „generowanie” wynika z tego, że silnik musi konsekwentnie wyliczyć zakres dat dla każdej partycji i wymusić filtr w zapytaniu; jeśli w źródle występują problemy z konwersją typów daty/czasu, strefą czasową albo porównaniem wartości (np. data jako tekst), to błąd może ujawnić się dopiero przy filtrowaniu zakresowym.

Żeby sprawdzić, czy to incremental refresh „ukrywa” problem, najprościej jest na chwilę wymusić odświeżenie większego zakresu: w ustawieniach polityki incremental zmniejsz „Przechowuj” lub zwiększ „Odśwież” tak, aby objąć podejrzany okres, a następnie uruchom refresh i porównaj, czy błąd wraca oraz w którym momencie. Jeśli podejrzewasz, że incremental refresh „tworzy” problem, sprawdź w Power Query, czy krok filtrowania po dacie zachowuje query folding (w praktyce: czy po dodaniu filtra i kolejnych kroków nadal da się wyświetlić natywne zapytanie). Brak folding oznacza, że część pracy wykonuje się lokalnie, a to bywa źródłem rozjazdów wydajności i błędów podczas odświeżania partycji.

Weryfikację warto domknąć analizą dziennika odświeżania w usłudze: przy incremental refresh błędy często wskazują konkretną partycję (zakres dat) lub tabelę, co pozwala zawęzić zakres danych, dla którego zapytanie jest problematyczne. Jeśli błąd pojawia się zawsze dla tego samego przedziału dat, to jest to silny sygnał, że przyczyna leży w danych lub w zmianie schematu w tym okresie; jeśli pojawia się losowo, częściej wskazuje na niestabilność źródła, timeouty lub problemy z zasobami podczas równoległego odświeżania partycji.

Jak użyć diagnostyki Power Query i logów gateway, żeby znaleźć konkretny krok powodujący awarię?

Cel jest prosty: dopasować identyfikowalny moment awarii (błąd, timeout, reset połączenia) do konkretnego kroku w Power Query (konkretna transformacja lub odpytywanie źródła). Najpewniejsza metoda to uruchomić zapytanie z włączoną diagnostyką w Power Query, a potem skorelować znaczniki czasu z wpisami w logach On-premises data gateway.

1) Power Query: włącz diagnostykę i odtwórz odświeżenie zapytania
W Power BI Desktop / Power Query włącz narzędzia diagnostyczne (Query Diagnostics), uruchom Start Diagnostics, a następnie odśwież tylko podejrzane zapytanie (lub cały model, jeśli nie wiesz które) i po awarii wybierz Stop Diagnostics. Otrzymasz dwie tabele z logami diagnostycznymi (m.in. zdarzenia i śledzenie zapytań). W praktyce szukasz:

• wpisów z najdłuższym czasem trwania tuż przed błędem (często wskazują krok, który „wisi” lub generuje najcięższe zapytanie),
• wpisu kończącego się tym samym komunikatem błędu co w odświeżeniu (np. błąd źródła, odmowa dostępu, przerwanie połączenia),
• informacji o zapytaniu natywnym (SQL/MDX/OData) albo o tym, że zapytanie nie jest składane (brak folding) — wtedy ciężar jest po stronie silnika M i danego kroku transformacji.

Żeby wskazać konkretny krok M, porównaj czas trwania i charakter zdarzeń z edytorem zapytań: najczęściej awaria pojawia się na pierwszym kroku, który generuje kontakt ze źródłem (Source/Nawigacja) albo na pierwszym kroku, który przestaje się składać do źródła (np. niestandardowa funkcja, złożone Table.AddColumn, niektóre operacje na typach danych), powodując pobranie dużej ilości danych i dopiero potem lokalne przetwarzanie.

2) Gateway: znajdź w logach ten sam moment i to samo połączenie
Jeśli odświeżenie działa przez On-premises data gateway, pobierz logi gateway z komputera z gateway (lub użyj opcji eksportu logów w aplikacji gateway). Następnie:

a) znajdź w logach przedział czasu odpowiadający awarii (z diagnostyki Power Query lub historii odświeżenia w usłudze).
b) wyszukaj wpisy wskazujące na problem komunikacji lub źródła: timeout, reset połączenia, błąd TLS, odmowa uwierzytelnienia, błędy sterownika/ODB C/SQL (w zależności od źródła).
c) zwróć uwagę na identyfikatory żądania/aktywności (jeśli są logowane) i koreluj je z pojedynczym zapytaniem/operacją — to pozwala odróżnić błąd konkretnego źródła od problemu ogólnego gateway.

3) Korelacja: jak dojść do „tego kroku”
Masz dwie osie: (1) diagnostyka Power Query pokazuje sekwencję operacji i ich czasy, (2) logi gateway pokazują, co faktycznie wychodzi do źródeł i gdzie następuje przerwanie. Konkretny krok uznajesz za winny, gdy spełnione są jednocześnie warunki: (i) tuż przed awarią w diagnostyce pojawia się długi/ostatni wpis związany z daną operacją, (ii) w tym samym czasie gateway loguje błąd dla połączenia do danego źródła lub timeout, (iii) po wyłączeniu/ominięciu tego kroku (np. czasowo usuwając go lub zastępując prostszą transformacją) odświeżenie przechodzi — to potwierdza, że problem jest związany z tym etapem, a nie z inną częścią modelu.

Jakie szybkie działania naprawcze przywracają refresh, a jakie tylko ukrywają problem na chwilę?

Szybkie działania „naprawcze” można podzielić na dwie grupy: takie, które realnie usuwają przyczynę awarii odświeżania (zmieniają warunki, które powodowały błąd), oraz takie, które jedynie powodują, że pojedynczy refresh przejdzie (albo wygląda, jakby działał), ale ryzyko powrotu problemu pozostaje. Kluczowe kryterium jest proste: jeśli po zmianie jesteś w stanie wskazać, co było źródłem błędu i dlaczego już nie wystąpi, to jest to naprawa; jeśli „zadziałało” bez wyjaśnienia lub kosztem jakości/kompletności danych, to zwykle maskowanie.

Do działań, które często rzeczywiście przywracają refresh, należą te, które eliminują konkretną przeszkodę techniczną: np. korekta nieaktualnych poświadczeń/rodzaju uwierzytelniania do źródła, poprawienie błędnego parametru środowiskowego (serwer, baza, ścieżka), usunięcie lub obejście niedostępnego elementu po stronie źródła (zmieniona nazwa tabeli/kolumny, usunięty widok), a także przywrócenie zgodności gatewaya ze środowiskiem (gateway działa i ma dostęp do źródeł, jest w odpowiedniej wersji, ma skonfigurowane źródło danych). To są naprawy, bo usuwają bezpośrednią przyczynę niepowodzenia.

Z kolei działania, które najczęściej tylko „gaszą pożar”, to takie, które zmniejszają prawdopodobieństwo błędu lub omijają go kosztem danych, zamiast go usunąć. Przykładem jest ręczne ponowne uruchamianie refreshu bez zmiany czegokolwiek (problem wróci przy tych samych warunkach), tymczasowe wyłączenie części zapytań/tabel, żeby odświeżanie przeszło (raport przestaje odzwierciedlać całość modelu), albo podniesienie limitów/timeoutów bez ustalenia, dlaczego zapytanie nagle trwa dłużej (objawy mogą ustąpić, ale przyczyna, np. regresja wydajności w źródle lub w M/SQL, zostaje). Podobnie „ukrywa” problem zmiana logiki tak, by ignorować błędy danych (np. zastępowanie błędów wartościami pustymi) – refresh przechodzi, ale błędne rekordy nadal istnieją i zwykle wrócą w innej formie.

Najbezpieczniejsze podejście w praktyce: jeśli musisz użyć obejścia, traktuj je jako doraźne tylko wtedy, gdy równolegle potrafisz wskazać element, który trzeba docelowo naprawić (źródło, poświadczenia, gateway, schema, wydajność). Jeśli obejście polega na „ucinaniu” danych lub ignorowaniu błędów, to nie jest to przywrócenie poprawnego refreshu, tylko przywrócenie jego pozoru.

T-SQL w analizie danych – przygotowanie danych do Microsoft Power BI 10 lipca 2026

Świeżość danych w Power BI przy źródłach o różnych godzinach: jak to ogarnąć bez zgadywania 08 lipca 2026