Dopo aver pubblicato un report su Power BI Service, il dataset (semantic model) espone dati statici finché non viene aggiornato. Il refresh pianificato (scheduled refresh) è il meccanismo che riesegue automaticamente l’importazione dei dati secondo una cadenza definita. Comprenderne limiti, dipendenze e interazione con il gateway è essenziale per chi progetta e mantiene soluzioni in produzione.

Scheduled refresh e i suoi limiti

Lo scheduled refresh si applica ai dataset in modalità Import (e alla porzione importata dei modelli Composite); DirectQuery e Live Connection non ne hanno bisogno perché interrogano la sorgente al volo. La frequenza massima dipende dalla licenza del workspace:

  • Power BI Pro: fino a 8 refresh al giorno.
  • Premium (capacity/P-SKU o F-SKU) e Premium Per User (PPU): fino a 48 refresh al giorno dall’interfaccia, con la possibilità di trigger più frequenti via XMLA endpoint o API.

Oltre alla frequenza, Premium/PPU alza anche il limite di durata del refresh e la dimensione del modello. In fase d’esame la scelta “quale licenza serve per aggiornare ogni ora?” si risolve contando: 24 refresh/giorno superano gli 8 di Pro, quindi serve Premium o PPU.

Quando serve il data gateway

Il data gateway è il ponte che permette a Power BI Service (cloud) di raggiungere sorgenti non pubblicamente accessibili: database on-premise, file su share aziendali, o risorse dietro una VNet. Esistono due modalità:

  • On-premises data gateway (standard/enterprise): installato su un server sempre acceso, condiviso tra più utenti e report, gestibile centralmente, supporta sia refresh scheduled sia DirectQuery/Live. È la scelta corretta per scenari di produzione e team.
  • Personal gateway (personal mode): legato al singolo utente, non condivisibile, supporta solo Import/refresh. Adatto ad analisti singoli, non a soluzioni condivise.

Per sorgenti cloud pubbliche (es. Azure SQL Database raggiungibile pubblicamente, SharePoint Online) il gateway in genere non è richiesto. Diventa necessario quando la sorgente vive in rete privata o dietro firewall. Per scenari di rete isolata su Azure si valuta anche il VNet data gateway (managed), che non richiede installazione su una VM.

Incremental refresh

L’incremental refresh aggiorna solo le partizioni di dati recenti anziché ricaricare l’intera tabella a ogni run: riduce drasticamente tempi, consumo di memoria e carico sulla sorgente. Il modello viene partizionato per data e Power BI mantiene storico in partizioni “fredde” (immutabili) aggiornando solo quelle “calde”.

La configurazione richiede due parametri obbligatori di tipo Date/Time in Power Query, denominati esattamente RangeStart e RangeEnd, usati per filtrare la tabella su una colonna data:

= Table.SelectRows(Source, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)

Nel dialogo della tabella si definisce poi la finestra di archiviazione (es. archivia gli ultimi 5 anni) e quella di refresh (es. aggiorna gli ultimi 10 giorni). Opzioni utili: detect data changes (aggiorna una partizione solo se una colonna di modifica cambia) e only refresh complete periods.

La dipendenza dal query folding

L’incremental refresh è efficace solo se il filtro RangeStart/RangeEnd viene tradotto in una WHERE sulla sorgente — cioè se c’è query folding. Se il folding regge, la sorgente restituisce solo le righe della partizione; se si rompe, Power BI scarica l’intera tabella e poi filtra in memoria, vanificando i benefici. Per questo l’incremental refresh è consigliato su sorgenti relazionali che supportano il folding (SQL Server, Azure SQL, ecc.) e sconsigliato su origini che non foldano (molti file, alcune Web API).

Trappole tipiche d’esame

  • Scenario: serve aggiornare un dataset ogni ora, ma il workspace è Pro → risposta giusta: passare a Premium capacity o PPU; con Pro il massimo è 8 refresh/giorno.
  • Scenario: refresh scheduled fallisce con errore di credenziali sul gateway dopo settimane di funzionamento → risposta giusta: le credenziali della sorgente memorizzate sul gateway sono scadute; aggiornarle in Manage gateways / impostazioni del dataset, non ricreare il report.
  • Scenario: incremental refresh configurato ma il refresh resta lentissimo e sembra ricaricare tutto → risposta giusta: una trasformazione (es. una custom function, un merge complesso o uno step che aggiunge una colonna prima del filtro) ha rotto il query folding; ripristinare il folding spostando le trasformazioni non-foldabili dopo il filtro o eliminandole.
  • Scenario: il modello legge da un database SQL on-premise e deve essere aggiornato da Service, ma è condiviso in un workspace di team → risposta giusta: installare l’on-premises data gateway in modalità standard/enterprise, non il personal gateway.
  • Scenario: bisogna abilitare incremental refresh ma manca qualcosa in Power Query → risposta giusta: creare i due parametri RangeStart e RangeEnd (nomi esatti, tipo Date/Time) e usarli per filtrare la colonna data.