70% din tichetele deschise în echipele care administrează Power BI Service sunt despre refresh-uri eșuate. Asta nu spune că tool-ul e prost. Spune că refresh-ul e locul unde se concentrează toată complexitatea: surse de date care se schimbă, gateway-uri care cad, credențiale care expiră, modele care depășesc limitele capacității. Iar majoritatea echipelor reacționează la fiecare incident în loc să-și proiecteze proactiv strategia de refresh.

Articolul ăsta strânge best practices pentru refresh Power BI Service într-un format pragmatic — ce funcționează în 2026, ce s-a schimbat față de anii anteriori și unde se ascund costurile pe care nu le vede nimeni la început.

Câte refresh-uri pe zi, de fapt?

Cea mai des întâlnită eroare de design în Power BI Service: refresh la fiecare oră pentru un raport care e folosit o dată pe zi.

Frecvența refresh-ului trebuie să se alinieze cu frecvența deciziilor pe care raportul le susține. Un dashboard executiv consultat dimineața la 9 și — eventual — după prânz nu are nevoie de refresh-uri din oră în oră. Are nevoie de două refresh-uri pe zi: unul la 7 dimineața, eventual unul la 12.30. Un raport operațional folosit în call-center pentru decizii în timp real are alte cerințe — și acolo discuția merge în zona DirectQuery sau composite models, nu refresh frecvent pe import.

Power BI Service permite până la 8 refresh-uri pe zi pe Pro și 48 pe Premium. Faptul că poți nu înseamnă că trebuie. Fiecare refresh consumă capacitate, încarcă gateway-ul, generează potențiale erori. Un raport cu 48 de refresh-uri pe zi nu e mai bun, e doar mai fragil.

Regula utilă: începi de la întrebarea „când se uită cineva la acest raport?”. Programezi refresh-ul cu 15-30 de minute înainte de fiecare interval principal de consultare. Restul timpului, raportul stă liniștit.

Scheduled refresh vs incremental refresh

Scheduled refresh — refresh-ul complet al dataset-ului la intervale definite — e configurația implicită pentru cele mai multe rapoarte. Funcționează bine până la un punct: când dataset-ul depășește 1-2 milioane de înregistrări, durata refresh-ului devine prohibitivă și apar timeout-urile.

Incremental refresh — feature disponibil pe Premium și pe Pro din 2023 — schimbă paradigma. Power BI reține partiționarea istorică și refresh-ează doar perioada recentă (de exemplu, ultimele 30 de zile), nu întregul istoric. Datele mai vechi rămân stocate la nivel de service și se actualizează doar dacă ai configurat asta explicit.

Pentru un dataset de 50 milioane de înregistrări care acoperă 5 ani, incremental refresh înseamnă diferența între un refresh de 90 de minute și unul de 4 minute. Dincolo de viteză, e și o protecție: dacă pică sursa, doar partiția curentă e afectată, restul rămâne valabil. Configurarea cere setarea unor parametri RangeStart și RangeEnd în Power Query, apoi definirea politicii de partiționare în Power BI Desktop. Documentația Microsoft Power BI incremental refresh descrie pașii exacți.

Dincolo de teorie, în practică: orice dataset peste 10 milioane de rânduri ar trebui să folosească incremental refresh. Sub asta, scheduled refresh standard rămâne soluția cea mai simplă și suficient de rapidă.

Power BI Service vs gateway-uri locale

Sursele cloud (Azure SQL, Snowflake, BigQuery, Dataverse) se conectează direct la Power BI Service fără gateway. Sursele on-premises (SQL Server local, fișiere pe un share intern, baze de date legacy) cer un On-premises Data Gateway instalat pe un server intern.

Gateway-ul e cel mai frecvent punct de eșec. Trei recomandări care reduc dramatic problemele:

Server dedicat, nu laptopul cuiva. Am văzut companii la care gateway-ul rula pe stația de lucru a unui developer. La fiecare restart, toate refresh-urile cădeau. Gateway-ul cere o mașină virtuală sau un server dedicat, cu uptime 99%+. Costul: 50-100 USD pe lună pentru un VM mic. Beneficiul: dispariția unei întregi categorii de incidente.

Cluster, nu instanță singulară. Gateway-urile pot fi configurate ca cluster — două sau trei noduri care preiau una de la alta când o instanță cade. Pentru orice mediu de producție serios, asta nu e opțional.

Monitorizare separată. Power BI Service îți spune că refresh-ul a eșuat, dar nu îți spune întotdeauna de ce — sau e mesaj generic. Activarea monitorizării prin Azure Log Analytics sau o soluție echivalentă scoate la lumină cauza reală: timeout pe sursă, memorie insuficientă pe gateway, schemă modificată.

Gestionarea credențialelor

Refresh-urile cad cu un mesaj de tip „credentials are invalid” pentru două motive principale: parola s-a schimbat (cineva a făcut password rotation pe SQL Server și a uitat de Power BI) sau token-ul OAuth a expirat (sursele cloud cu autentificare delegată au token-uri cu durată limitată).

Practica sănătoasă: foloseți service accounts dedicate pentru toate sursele Power BI. Nu credențiale individuale ale unui developer care părăsește compania. Service account cu parolă pe interval de minim 1 an, password rotation programat și — important — verificare manuală a tuturor rapoartelor care folosesc acel account înainte de schimbarea parolei.

Pentru sursele cu OAuth (Microsoft 365, Dataverse, etc.) — Power BI suportă astăzi service principals în loc de utilizatori individuali. E un drum mai bun pentru orice tenant cu mai mult de 20 de rapoarte în producție.

Capacitatea Premium și fereastra de refresh

Pe Premium per Capacity (P1, P2, P3, F-SKU-urile noi), refresh-urile concomitente consumă memorie. Dacă programezi 10 dataset-uri să se refresh-eze la 7 dimineața, capacitatea poate fi suprasolicitată și unele refresh-uri vor eșua sau vor intra în coadă.

Best practice: eșalonează refresh-urile. Dataset-urile mari (peste 1 GB) au orele lor proprii, dataset-urile mici se pot grupa. Pe o capacitate F64 (echivalent P1), capacitatea recomandată e maxim 2-3 refresh-uri concomitente de dataset-uri peste 500 MB.

Există însă o capcană aici. Mulți administratori se uită doar la statisticile de refresh și uită că în paralel rulează și interacțiunile utilizatorilor cu rapoartele — query-uri DAX care cer memorie. Un raport interactiv intens consultat dimineața + 5 refresh-uri concomitente = capacitate epuizată.

Power BI Blog a publicat în 2026 update-uri privind metrici-app pentru capacitate, care arată în timp real consumul. Pentru echipele care administrează capacitate Premium, e instrumentul obligatoriu.

Tratarea erorilor și retry-urile

Power BI Service are retry automat pentru refresh-uri eșuate — încearcă din nou de două ori la interval de 30 de minute. Pentru cele mai multe erori tranzitorii (rețea, timeout temporar), asta rezolvă incidentul fără intervenție. Pentru erorile persistente (schemă schimbată, credențiale expirate, sursă căzută), retry-ul doar consumă capacitate fără rezultat.

Configurarea alertelor proactive face diferența. La fiecare refresh eșuat după trei încercări, echipa de BI ar trebui să primească o notificare structurată — pe Teams sau email — care să conțină dataset-ul, sursa, codul de eroare și ora. Asta se face fie cu Power Automate, fie cu un script PowerShell pe API-ul Power BI.

Companiile care nu au alertare proactivă descoperă refresh-urile căzute când un utilizator se plânge că dashboard-ul are date vechi de două zile. Asta e exact momentul în care încrederea în Power BI se prăbușește.

Audit periodic pe dataset-uri

O practică pe care puține echipe o aplică, dar care plătește dividende: o dată pe trimestru, audit complet al tuturor dataset-urilor active. Sub formă de listă cu trei coloane: dataset, ultimul refresh, ultimul utilizator care a deschis raportul asociat.

Rezultatul tipic: între 30% și 50% dintre dataset-uri sunt fie nefolosite (niciun utilizator în ultimele 60 de zile), fie folosite atât de rar încât justifică o frecvență mai mică de refresh. Eliminarea sau reconfigurarea acestora eliberează capacitate, reduce timpul total de refresh și — important — face inventarul mai gestionabil.

Power BI Service expune aceste informații prin Usage Metrics. Pentru companii cu peste 100 de dataset-uri, e exercițiul cel mai eficient de optimizare.

Trei lucruri de făcut săptămâna viitoare

Pentru oricine administrează un tenant Power BI cu mai mult de 30-40 de rapoarte:

• Audit pe frecvența refresh-urilor. Câte rapoarte se refresh-ează mai des decât sunt consultate? Probabil majoritatea. Scade frecvența unde nu se justifică.
• Verifică gateway-urile. Rulează pe servere dedicate? Sunt în cluster? Sunt monitorizate? Dacă răspunsul la oricare e nu, ai un risc pe care îl rezolvi într-o săptămână de muncă.
• Setează alertare proactivă. Power Automate pe API-ul Power BI, notificare pe Teams, alertă structurată. O după-amiază de lucru, valoare zilnică.

Refresh-ul nu e ceva spectaculos. E muncă invizibilă care fie merge — și nimeni nu observă — fie cade și toată lumea își amintește brusc că Power BI există. Echipele bune fac munca asta proactiv. Restul reacționează la incidente.

Întrebări frecvente

De câte ori pe zi ar trebui să fac refresh?

De câte ori se iau decizii pe raportul acela. Cea mai frecventă eroare de design e refresh din oră în oră pentru un raport consultat o dată pe zi. Power BI Service permite până la 8 refresh-uri pe zi pe Pro și 48 pe Premium, dar regula utilă e să pornești de la întrebarea „când se uită cineva la acest raport?”.

Când folosesc incremental refresh?

Orice dataset de peste 10 milioane de rânduri ar trebui să îl folosească. Pentru un set de 50 de milioane de înregistrări care acoperă 5 ani, diferența e între un refresh de 90 de minute și unul de 4 minute.

De ce cad refresh-urile cel mai des?

Din două locuri. Gateway-ul, care e cel mai frecvent punct de eșec — trebuie să stea pe un server dedicat, nu pe laptopul cuiva, în cluster și nu ca instanță unică, cu monitorizare separată. Și credențialele: mesajul „credentials are invalid” apare de obicei după o rotire de parolă de care nu a știut nimeni. Practica sănătoasă e conturi de serviciu dedicate pentru toate sursele.