Odświeżanie w usłudze Power BI przekroczyło limit czasu

Power BI - Odświeżanie w usłudze i brama danych

Odświeżanie w usłudze Power BI przekroczyło limit czasu

W skrócie

Odświeżanie w Power BI Desktop trwa długo, ale kończy się sukcesem, a w usłudze po kilku godzinach albo minutach kończy się błędem przekroczenia limitu czasu. Za podobnymi objawami kryją się dwa limity: limit całego odświeżenia w usłudze i limit pojedynczego zapytania do źródła. Odróżniamy je po komunikatach i czasie trwania, a potem skracamy odświeżanie, z pomiarami na modelu Nordvelli z kursu.

Jak to wygląda w praktyce

W oknie Historia odświeżania wpis ma stan „Przekroczono limit czasu”, a w ustawieniach modelu usługa pisze „Upłynął limit czasu ostatniego odświeżenia:” z datą. Przy bramie osobistej komunikat brzmi „Nie można wykonać operacji odświeżania, ponieważ jej ukończenie trwało zbyt długo. Rozważ zmniejszenie rozmiaru zestawu danych lub podzielenie go na mniejsze zestawy danych.” Silnik modelu ma też komunikat „Niestety, odświeżanie trwało tak długo, że nastąpiło przekroczenie limitu czasu. Spróbuj ponownie.” (w angielskiej wersji: „Sorry, the refresh took so long it timed out. Please try again.”).

Inaczej wygląda limit zapytania do źródła. Odświeżenie kończy się wtedy wcześniej, a komunikat wskazuje źródło, na przykład „Przed zakończeniem importowania danych do tabeli FaktSprzedaz źródło danych przekroczyło limit czasu. Sprawdź, czy to źródło danych może przetwarzać zapytania importowania, a jeśli tak, ponów próbę.” Dla SQL Server usługa pisze, że źródło nie odpowiada i nie można wykonać bieżącej operacji zapytania z powodu przekroczenia limitu czasu oczekiwania. Czas trwania odczytasz ze startu i końca wpisu w historii.

Dlaczego tak się dzieje

Według dokumentacji Microsoft zaplanowane odświeżenie modelu importu musi się zmieścić w dwóch godzinach w pojemności współdzielonej, czyli w zwykłym obszarze roboczym z licencją Pro, i w pięciu godzinach na pojemności Premium. Limit obowiązuje niezależnie od odświeżania przyrostowego, a na pojemności Premium odświeżenia przez punkt końcowy XMLA nie mają limitu czasu. Na czas odświeżenia składa się wczytanie danych, budowa relacji i hierarchii oraz przeliczenie obiektów obliczanych. Dokumentacja dodaje, że pełne odświeżenie może zużyć nawet dwa razy więcej pamięci niż sam model, bo usługa trzyma jego kopię do końca operacji.

Drugi limit ma każde zapytanie do źródła. Dla funkcji Sql.Database opcja CommandTimeout ma domyślnie dziesięć minut, a przy odświeżaniu przyrostowym każda partycja wysyła osobne zapytanie z tym limitem. Oba limity łatwo przekroczyć zapytaniem, które nie składa się do bazy: filtr działa wtedy dopiero w Power Query, a brama pobiera całą tabelę, o czym piszemy w poście o parametrach RangeStart i RangeEnd. W modelu Nordvelli tabela FaktSprzedaz ma 108 675 wierszy od 1 stycznia 2022 do 31 maja 2026 i zajmuje 4 256 400 z 4 631 128 bajtów, które zapytanie z kroku 3 pokazuje dla całego modelu, czyli około 92 procent. Każde pełne odświeżenie czyta ją w całości.

Zobacz też: Szkolenie Power BI - Desktop, DAX i Online + Copilot

Co zrobić krok po kroku

1. W oknie Historia odświeżania porównaj start i koniec nieudanego wpisu. Koniec około dwóch albo pięciu godzin po starcie oznacza limit usługi, krótszy przebieg z komunikatem o źródle oznacza limit zapytania. W ustawieniach modelu kliknij Pokaż szczegóły, żeby przeczytać pełny komunikat w formacie JSON.
2. Zmierz czas odświeżania w Power BI Desktop. Dokumentacja Microsoft radzi sprawdzić go właśnie tam i przy ponad dwóch godzinach rozważyć pojemność Premium albo odświeżanie przyrostowe. Gdy Desktop też odświeża długo, szukaj przyczyny w zapytaniach, jak w poście o długim odświeżaniu w Power BI Desktop.
3. Sprawdź, które tabele są największe. W widoku zapytań w języku DAX uruchom zapytanie, które sumuje rozmiar segmentów kolumn według tabel. W modelu Nordvelli zwraca 19 tabel, na czele FaktSprzedaz (4 256 400 bajtów), FaktBudzet (121 752) i FaktZwroty (95 296). Z największych tabel usuń kolumny, których raport nie używa, i ogranicz zbędną historię, więcej w lekcji o optymalizacji modelu pod VertiPaq.

   EVALUATE
   GROUPBY(
       INFO.STORAGETABLECOLUMNSEGMENTS(),
       [DIMENSION_NAME],
       "Bajty", SUMX(CURRENTGROUP(), [USED_SIZE])
   )
   ORDER BY [Bajty] DESC

4. Dla dużej tabeli faktów z kolumną daty włącz odświeżanie przyrostowe, które według dokumentacji działa przy licencji Pro, Premium per user i na pojemności Premium. W kursie polityka z pięcioma latami archiwum i sześcioma miesiącami okna odświeżała partycje od maja do października 2026, a dane miał tylko maj: 2 419 z 108 675 wierszy FaktSprzedaz, czyli około 2,2 procent. Pierwsze odświeżenie po publikacji wykonaj ręcznie i obserwuj, bo buduje wszystkie partycje i trwa wyraźnie dłużej niż kolejne.
5. Sprawdź składanie zapytania, czyli przekazanie filtrów do bazy. W edytorze Power Query, w panelu Zastosowane kroki, otwórz menu ostatniego kroku tabeli faktów. Gdy pozycja Wyświetl zapytanie natywne jest aktywna, filtr trafia do serwera. Gdy jest wyszarzona, od tego kroku reszta liczy się lokalnie na wszystkich wierszach pobranych z bazy, więc przenieś krok, który zrywa składanie, na koniec zapytania albo zastąp go operacją po stronie bazy.
6. Gdy pojedyncze zapytanie do bazy trwa dłużej niż dziesięć minut, podnieś CommandTimeout w kroku źródła. Według dokumentacji Microsoft większość relacyjnych źródeł pozwala nadpisać ten limit w kodzie M. Wzorzec dla bazy Nordvella z kursu, do dostosowania (tu dwie godziny):

   Źródło = Sql.Database("192.168.1.206,1433", "Nordvella", [CommandTimeout = #duration(0, 2, 0, 0)])

7. Gdy po skróceniu odświeżenie dalej nie mieści się w dwóch godzinach, przenieś obszar roboczy na pojemność Premium z limitem pięciu godzin, a bardzo duży model podziel na mniejsze modele albo odświeżaj przez punkt końcowy XMLA. Według dokumentacji odświeżenia planuj poza godzinami szczytu, bo opóźniony start odświeżenia to sygnał przeciążonej pojemności.

Jak sprawdzić, że problem zniknął

Naprawione, gdy wpis w oknie Historia odświeżania ma stan Zakończono, a czas od startu do końca zostawia wyraźny zapas do limitu. Przy odświeżaniu przyrostowym kolejne odświeżenia mają być wyraźnie krótsze od pierwszego: w kursie pierwsze trwało 23 sekundy, a drugie, po zmianie jednej transakcji z maja, około 5 sekund, bo przebudowało jedną partycję. Jak działa takie wykrywanie zmian, opisujemy w poście o odświeżaniu przyrostowym i zmianach w starych danych.

Żeby limit nie wrócił, zapisuj czasy kolejnych odświeżeń, bo model rośnie z każdym miesiącem. W Nordvelli rok 2022 to 19 550 wierszy FaktSprzedaz, a rok 2025 już 29 545. Pamiętaj też, że według dokumentacji ponowna publikacja z Power BI Desktop modelu z polityką przyrostową usuwa istniejące partycje i dane, więc następne odświeżenie znów zbuduje całą historię i potrwa jak pierwsze.

Źródła i sposób sprawdzenia

• Microsoft Learn: Data refresh in Power BI (dwie godziny w pojemności współdzielonej, pięć na Premium, XMLA) (źródło)
• Microsoft Learn: Troubleshoot refresh scenarios (Scheduled refresh time-out, CommandTimeout) (źródło)
• Microsoft Learn: Incremental refresh and real-time data for semantic models (limity czasu, CommandTimeout na partycję, pierwsze odświeżenie, ponowna publikacja) (źródło)
• Microsoft Learn: Sql.Database (CommandTimeout domyślnie dziesięć minut) (źródło)
• Sprawdzone zapytaniami DAX na modelu Nordvelli: liczba wierszy FaktSprzedaz według lat i od maja 2026, rozmiar segmentów kolumn według tabel
• Kurs Power BI, lekcja 19: odświeżanie przyrostowe FaktSprzedaz, okno 6 miesięcy, 23 i 5 sekund w historii, składanie zapytania

Zachowanie programu sprawdziliśmy w Power BI Desktop 2.157 (wydanie z sierpnia 2026 r.) z polskim interfejsem, a przykłady na modelu sieci Nordvella z bezpłatnego kursu Power BI. Microsoft wydaje nową wersję Power BI Desktop co miesiąc, więc nazwy przycisków i limity usługi mogą się zmieniać. Aktualne wartości podaje dokumentacja Microsoft Learn.

Wróć do listy: 131 najczęstszych pytań i problemów związanych z Power BI