DirectQuery in Power BI

In Power BI Desktop o nel servizio Power BI è possibile connettersi a molte origini dati diverse in modi diversi. È possibile importare dati in Power BI, che è il modo più comune per ottenere i dati. È anche possibile connettersi direttamente ad alcuni dati nel repository di origine originale, denominato DirectQuery. Questo articolo illustra principalmente le funzionalità di DirectQuery.

L'articolo illustra:

• Opzioni di connettività dei dati di Power BI diverse.
• Indicazioni su quando usare DirectQuery anziché importare.
• Limitazioni e implicazioni dell'uso di DirectQuery.
• Consigli per l'uso corretto di DirectQuery.
• Come diagnosticare i problemi di prestazioni di DirectQuery.

L'articolo è incentrato sul flusso di lavoro DirectQuery quando si crea un report in Power BI Desktop, ma illustra anche la connessione tramite DirectQuery nel servizio Power BI.

Nota

DirectQuery è anche una funzionalità di SQL Server Analysis Services. Questa funzionalità condivide molti dettagli con DirectQuery in Power BI, ma esistono anche differenze importanti. Questo articolo riguarda principalmente DirectQuery con Power BI, non SQL Server Analysis Services.

Per altre informazioni sull'uso di DirectQuery con SQL Server Analysis Services, vedere Usare modelli compositi in Power BI Desktop). È anche possibile scaricare il PDF Directquery in SQL Server 2016 Analysis Services.

Modalità di connettività dei dati di Power BI

Power BI si connette a un numero elevato di origini dati diverse, ad esempio:

• Servizi online come Salesforce e Dynamics 365.
• Database come SQL Server, Access e Amazon Redshift.
• File semplici in Excel, JSON e altri formati.
• Altre origini dati, ad esempio Spark, siti Web e Microsoft Exchange.

È possibile importare dati da queste origini in Power BI. Per alcune origini, è anche possibile connettersi usando DirectQuery. Per un riepilogo delle origini che supportano DirectQuery, vedere Origini dati di Power BI. Le origini abilitate per DirectQuery sono principalmente origini che possono offrire prestazioni di query interattive ottimali.

È opportuno importare i dati in Power BI laddove possibile. L'importazione sfrutta il motore di query ad alte prestazioni di Power BI e offre un'esperienza estremamente interattiva e completa.

Se non è possibile raggiungere gli obiettivi importando dati, ad esempio se i dati cambiano frequentemente e i report devono riflettere i dati più recenti, è consigliabile usare DirectQuery. DirectQuery è fattibile solo quando l'origine dati sottostante può fornire risultati di query interattive in meno di cinque secondi per una query di aggregazione tipica e può gestire il carico di query generato. Considerare attentamente le limitazioni e le implicazioni dell'uso di DirectQuery.

Le funzionalità di importazione e DirectQuery di Power BI si evolvono nel tempo. Le modifiche che offrono maggiore flessibilità quando si usano i dati importati consentono di importare più spesso ed eliminare alcuni degli svantaggi dell'uso di DirectQuery. Indipendentemente dai miglioramenti, le prestazioni dell'origine dati sottostante sono una considerazione importante quando si usa DirectQuery. Se un'origine dati sottostante è lenta, l'uso di DirectQuery per tale origine rimane infeasible.

Le sezioni seguenti illustrano queste tre opzioni per la connessione ai dati: importazione, DirectQuery e connessione dinamica. La parte restante dell'articolo è incentrata su DirectQuery.

Connessioni di importazione

Quando ci si connette a un'origine dati come SQL Server e si importano dati in Power BI Desktop, sono presenti le condizioni di connettività seguenti:

• Quando si usa inizialmente Recupera dati, ogni set di tabelle selezionato definisce una query che restituisce un set di dati. È possibile modificare tali query prima di caricare i dati, ad esempio per applicare filtri, aggregare i dati o unire tabelle diverse.

• Al caricamento, tutti i dati definiti dalle query importano nella cache di Power BI.

• La compilazione di un oggetto visivo all'interno di Power BI Desktop esegue una query sui dati memorizzati nella cache. L'archivio di Power BI garantisce che la query sia veloce e che tutte le modifiche apportate all'oggetto visivo riflettano immediatamente.

• Gli oggetti visivi non riflettono le modifiche apportate ai dati sottostanti nell'archivio dati. È necessario reimportare per aggiornare i dati.

• La pubblicazione del report nel servizio Power BI come file con estensione pbix crea e carica un modello semantico che include i dati importati. È quindi possibile pianificare l'aggiornamento dei dati per reimportare i dati ogni giorno, ad esempio. A seconda del percorso dell'origine dati originale, potrebbe essere necessario configurare un gateway dati locale per l'aggiornamento.

• L'apertura di un report esistente o la creazione di un nuovo report nel servizio Power BI esegue di nuovo una query sui dati importati, garantendo l'interattività.

• È possibile aggiungere oggetti visivi o intere pagine del report come riquadri del dashboard nel servizio Power BI. I riquadri vengono aggiornati automaticamente ogni volta che viene aggiornato il modello semantico sottostante.

Connessioni DirectQuery

Quando si usa DirectQuery per connettersi a un'origine dati in Power BI Desktop, sono presenti le condizioni di connettività dei dati seguenti:

• Usare Recupera dati per selezionare l'origine. Per le origini relazionali, è comunque possibile selezionare un set di tabelle che definiscono una query che restituisce logicamente un set di dati. Per le origini multidimensionali come SAP Business Warehouse (SAP BW), è possibile selezionare solo l'origine.

• Durante il caricamento non vengono importati dati nell'archivio di Power BI. Al contrario, quando si compila un oggetto visivo, Power BI Desktop invia query all'origine dati sottostante per recuperare i dati necessari. Il tempo necessario per aggiornare l'oggetto visivo dipende dalle prestazioni dell'origine dati sottostante.

• Eventuali modifiche ai dati sottostanti non vengono propagate immediatamente agli oggetti visivi esistenti. È sempre necessario eseguire l'aggiornamento. Power BI Desktop invia nuovamente le query necessarie per ogni oggetto visivo e aggiorna l'oggetto visivo in base alle esigenze.

• La pubblicazione del report nel servizio Power BI crea e carica un modello semantico, come per l'importazione. Tuttavia, tale modello semantico non include dati.

• L'apertura di un report esistente o la creazione di un nuovo report nel servizio Power BI esegue una query sull'origine dati sottostante per recuperare i dati necessari. A seconda del percorso dell'origine dati originale, potrebbe essere necessario configurare un gateway dati locale per ottenere i dati.

• È possibile aggiungere oggetti visivi o intere pagine del report come riquadri del dashboard. Per garantire che l'apertura di un dashboard sia rapida, i riquadri vengono aggiornati automaticamente secondo una pianificazione, ad esempio ogni ora. È possibile controllare la frequenza di aggiornamento a seconda della frequenza di modifica dei dati e dell'importanza di visualizzare i dati più recenti.

• Quando si apre un dashboard, i riquadri riflettono i dati al momento dell'ultimo aggiornamento, non necessariamente le modifiche più recenti apportate all'origine sottostante. È possibile aggiornare un dashboard aperto per visualizzare sempre il contenuto più recente.

Connessioni dinamiche

Quando ci si connette a SQL Server Analysis Services, è possibile scegliere di importare i dati o di usare una connessione dinamica al modello di dati selezionato. L'uso di una connessione dinamica è simile all'uso di DirectQuery. Non vengono importati dati e viene eseguita una query sull'origine dati sottostante per aggiornare gli oggetti visivi.

Ad esempio, quando si usa l'importazione per connettersi a SQL Server Analysis Services, si definisce una query sull'origine esterna di SQL Server Analysis Services e si importano i dati. Se ci si connette in tempo reale, non si definisce una query e l'intero modello esterno viene visualizzato nell'elenco dei campi.

Questa situazione si applica anche quando ci si connette alle origini seguenti, ad eccezione del fatto che non è possibile importare i dati:

• Modelli semantici di Power BI, ad esempio la connessione a un modello semantico di Power BI già pubblicato nel servizio, per creare un nuovo report su di esso.

• Microsoft Dataverse.

Quando si pubblicano report di SQL Server Analysis Services che usano connessioni dinamiche, il comportamento nel servizio Power BI è simile ai report DirectQuery nei modi seguenti:

• L'apertura di un report esistente o la creazione di un nuovo report nel servizio Power BI esegue una query sull'origine SQL Server Analysis Services sottostante, eventualmente richiedendo un gateway dati locale.

• I riquadri del dashboard vengono aggiornati automaticamente in base a una pianificazione, ad esempio ogni ora.

Una connessione dinamica differisce anche da DirectQuery in diversi modi. Ad esempio, le connessioni dinamiche passano sempre l'identità dell'utente che apre il report all'origine SQL Server Analysis Services sottostante.

Casi d'uso di DirectQuery

La connessione con DirectQuery può essere utile negli scenari seguenti. In molti di questi casi, lasciare i dati nella posizione di origine originale è necessario o vantaggioso.

DirectQuery in Power BI offre i vantaggi maggiori negli scenari seguenti:

• I dati cambiano frequentemente e sono necessari report quasi in tempo reale.
• È necessario gestire dati di grandi dimensioni senza dover preaggregare.
• L'origine sottostante definisce e applica le regole di sicurezza.
• Si applicano limitazioni a livello di sovranità dei dati.
• L'origine è multidimensionale e contiene misure, ad esempio SAP BW.

Modifiche ai dati di frequente ed è necessario creare report quasi in tempo reale

È possibile aggiornare i modelli con dati importati al massimo una volta all'ora o più frequentemente con le sottoscrizioni di Power BI Pro o Power BI Premium. Se i dati cambiano continuamente ed è necessario che i report visualizzino i dati più recenti, l'importazione con l'aggiornamento pianificato potrebbe non soddisfare i requisiti. È possibile trasmettere dati direttamente in Power BI, anche se esistono limiti ai volumi di dati supportati in questo caso.

L'uso di DirectQuery significa che l'apertura o l'aggiornamento di un report o di un dashboard visualizza sempre i dati più recenti nell'origine. I riquadri del dashboard possono essere aggiornati anche più frequentemente, anche ogni 15 minuti.

Dati di dimensioni molto grandi

Se i dati sono molto grandi, non è possibile importarli tutti. DirectQuery non richiede un trasferimento di dati di grandi dimensioni, perché esegue query su dati sul posto. Tuttavia, i dati di grandi dimensioni potrebbero anche rendere le prestazioni delle query su tale origine sottostante troppo lenta.

Non è sempre necessario importare dati completi e dettagliati. L'editor di Power Query semplifica la pre-aggregazione dei dati durante l'importazione. Tecnicamente, è possibile importare esattamente i dati aggregati necessari per ogni oggetto visivo. Anche se DirectQuery è l'approccio più semplice per i dati di grandi dimensioni, l'importazione di dati aggregati può rappresentare una soluzione se l'origine dati sottostante è troppo lenta per DirectQuery.

Questi dettagli si riferiscono solo all'uso di Power BI. Per altre informazioni sull'uso di modelli di grandi dimensioni in Power BI, vedere Modelli semantici di grandi dimensioni in Power BI Premium. Non esistono limitazioni alla frequenza di aggiornamento dei dati.

L'origine sottostante definisce le regole di sicurezza

Quando si importano dati, Power BI si connette all'origine dati usando le credenziali di Power BI Desktop dell'utente corrente o le credenziali configurate per l'aggiornamento pianificato dal servizio Power BI. Nella pubblicazione e nella condivisione di report che hanno importato dati, è necessario prestare attenzione alla condivisione solo con gli utenti autorizzati a visualizzare i dati oppure è necessario definire la sicurezza a livello di riga come parte del modello semantico.

DirectQuery consente a un visualizzatore di report di passare le credenziali all'origine sottostante, che applica regole di sicurezza. DirectQuery supporta l'accesso Single Sign-On (SSO) alle origini dati SQL di Azure e tramite un gateway dati a server SQL locali. Per altre informazioni, vedere Panoramica dell'accesso Single Sign-On (SSO) per i gateway dati locali in Power BI.

Limitazioni di sovranità dei dati

Alcune organizzazioni hanno criteri di sovranità dei dati, ovvero i dati non possono uscire dall'organizzazione. Questi dati presentano problemi per le soluzioni basate sull'importazione dei dati. Con DirectQuery, i dati rimangono nella posizione di origine sottostante. Tuttavia, anche con DirectQuery, il servizio Power BI mantiene alcune cache di dati a livello di oggetto visivo, a causa dell'aggiornamento pianificato dei riquadri.

L'origine dati sottostante usa misure

Un'origine dati sottostante, ad esempio SAP HANA o SAP BW, contiene misure. Le misure indicano che i dati importati sono già a un determinato livello di aggregazione, come definito dalla query. Oggetto visivo che richiede dati a un'aggregazione di livello superiore, ad esempio Vendite totali per Anno, aggrega ulteriormente il valore aggregato. Questa aggregazione funziona per le misure additive, come Sum e Min, ma può rappresentare un problema per le misure non additive, come Average e DistinctCount.

Ottenere facilmente i dati aggregati corretti necessari per un oggetto visivo direttamente dall'origine richiede l'invio di query per oggetto visivo, come in DirectQuery. Quando ci si connette a SAP BW, la scelta di DirectQuery consente questo trattamento delle misure. Per altre informazioni, vedere DirectQuery e SAP BW.

Attualmente DirectQuery su SAP HANA tratta i dati come un'origine relazionale e produce un comportamento simile all'importazione. Per altre informazioni, vedere DirectQuery e SAP HANA.

Limitazioni di DirectQuery

L'uso di DirectQuery ha alcune implicazioni potenzialmente negative. Alcune di queste limitazioni variano leggermente a seconda dell'origine esatta usata. Le sezioni seguenti elencano le implicazioni generali dell'uso di DirectQuery e le limitazioni correlate a prestazioni, sicurezza, trasformazioni, modellazione e creazione di report.

Implicazioni generali

Di seguito sono riportate alcune implicazioni generali e limitazioni dell'uso di DirectQuery:

• Se i dati cambiano, è necessario aggiornare per visualizzare i dati più recenti. Dato l'uso delle cache, non esiste alcuna garanzia che gli oggetti visivi visualizzino sempre i dati più recenti. Un oggetto visivo può ad esempio visualizzare le transazioni dell'ultimo giorno. Una modifica del filtro dei dati potrebbe aggiornare l'oggetto visivo per visualizzare le transazioni degli ultimi due giorni, incluse le transazioni recenti appena arrivate. Tuttavia, la restituzione del filtro dei dati al valore originale potrebbe comportare di nuovo la visualizzazione del valore precedente memorizzato nella cache. Selezionare Aggiorna per cancellare tutte le cache e aggiornare tutti gli oggetti visivi nella pagina per visualizzare i dati più recenti.

• Se i dati cambiano, non esiste alcuna garanzia di coerenza tra gli oggetti visivi. oggetti visivi diversi, indipendentemente dal fatto che si trovino nella stessa pagina o in pagine diverse, potrebbero essere aggiornati in momenti diversi. Se i dati nell'origine sottostante cambiano, non è certo che ogni oggetto visivo mostri i dati nello stesso momento.

  Dato che più query potrebbero essere necessarie per un singolo oggetto visivo, ad esempio per ottenere i dettagli e i totali, anche la coerenza all'interno di un singolo oggetto visivo non è garantita. Per garantire questa coerenza, è necessario l'overhead dell'aggiornamento di tutti gli oggetti visivi ogni volta che viene aggiornato qualsiasi oggetto visivo, oltre all'uso di funzionalità costose, ad esempio l'isolamento dello snapshot nell'origine dati sottostante.

  È possibile attenuare questo problema in larga misura selezionando Aggiorna per aggiornare tutti gli oggetti visivi nella pagina. Anche per la modalità di importazione, esiste un problema simile a quello di mantenere la coerenza quando si importano dati da più tabelle.

• Per riflettere le modifiche dello schema, è necessario eseguire l'aggiornamento in Power BI Desktop. Dopo la pubblicazione di un report, l'aggiornamento nel servizio Power BI aggiorna gli oggetti visivi nel report. Tuttavia, se lo schema di origine sottostante cambia, il servizio Power BI non aggiorna automaticamente l'elenco dei campi disponibili. Se vengono rimosse tabelle o colonne dall'origine sottostante, la query potrebbe restituire un errore durante l'aggiornamento. Per aggiornare i campi nel modello in modo che riflettano le modifiche, è necessario aprire il report in Power BI Desktop e scegliere Aggiorna.

• Un limite di 1 milione di righe può restituire su qualsiasi query. Esiste un limite fisso di 1 milione di righe che possono restituire in qualsiasi singola query all'origine sottostante. Questo limite in genere non ha implicazioni pratiche e gli oggetti visivi non visualizzano molti punti. Tuttavia, il limite può verificarsi nei casi in cui Power BI non ottimizza completamente le query inviate e richiede un risultato intermedio che supera il limite.

  Il limite può anche verificarsi durante la creazione di un oggetto visivo, prima di ottenere uno stato finale più ragionevole. Ad esempio, includendo Cliente e TotalSalesQuantity potrebbe raggiungere questo limite se sono presenti più di 1 milione di clienti, fino a quando non si applica un filtro. L'errore restituito è: Il set di risultati di una query all'origine dati esterna ha superato le dimensioni massime consentite di '1000000' righe.

  Nota

  Le capacità Premium consentono di superare il limite di un milione di righe. Per altre informazioni, vedere Numero massimo di set di righe intermedi.

• Non è possibile modificare un modello dall'importazione alla modalità DirectQuery. È possibile cambiare un modello dalla modalità DirectQuery alla modalità di importazione se si importano tutti i dati necessari. Non è possibile tornare alla modalità DirectQuery, principalmente a causa del set di funzionalità non supportato dalla modalità DirectQuery. Per le origini multidimensionali come SAP BW, non è possibile passare dalla modalità DirectQuery alla modalità di importazione, a causa del diverso trattamento delle misure esterne.

Implicazioni per le prestazioni e il carico

Quando si usa DirectQuery, l'esperienza complessiva dipende dalle prestazioni dell'origine dati sottostante. Se l'aggiornamento di ogni oggetto visivo, ad esempio dopo la modifica di un valore del filtro dei dati, richiede meno di cinque secondi, l'esperienza è ragionevole, anche se potrebbe risultare lenta rispetto alla risposta immediata con i dati importati. Se la lentezza dell'origine causa l'aggiornamento di singoli oggetti visivi richiede più di decine di secondi, l'esperienza diventa poco ragionevole. Le query potrebbero anche verificarsi un timeout.

Oltre alle prestazioni dell'origine sottostante, il carico posizionato sull'origine influisce anche sulle prestazioni. Per ogni utente che apre un report condiviso e ogni riquadro del dashboard che viene aggiornato viene inviata almeno una query per oggetto visivo all'origine sottostante. L'origine deve essere in grado di gestire tale carico di query mantenendo prestazioni ragionevoli.

Implicazioni per la sicurezza

A meno che l'origine dati sottostante non usi l'accesso SSO, un report DirectQuery usa sempre le stesse credenziali fisse per connettersi all'origine dopo la pubblicazione nel servizio Power BI. Subito dopo la pubblicazione di un report DirectQuery, è necessario configurare le credenziali dell'utente da usare. Fino a quando non si configurano le credenziali, il tentativo di aprire il report nel servizio Power BI genera un errore.

Dopo aver specificato le credenziali utente, Power BI usa tali credenziali per chiunque apra il report, come per i dati importati. Ogni utente vede gli stessi dati, a meno che nell'ambito del report non sia definita la sicurezza a livello di riga. È necessario prestare la stessa attenzione alla condivisione del report per i dati importati, anche se sono presenti regole di sicurezza definite nell'origine sottostante.

• La connessione a modelli semantici di Power BI e Analysis Services in modalità DirectQuery usa sempre l'accesso SSO, quindi la sicurezza è simile alle connessioni dinamiche ad Analysis Services.

• Le 'credenziali alternative' non sono supportate quando si effettuano connessioni DirectQuery a SQL Server da Power BI Desktop. È possibile usare le credenziali di Windows o le credenziali di database correnti.

• È possibile usare più origini dati in un modello DirectQuery usando modelli compositi. Quando si usano più origini dati, è importante comprendere le implicazioni di sicurezza del modo in cui i dati si spostano avanti e indietro tra le origini dati sottostanti.

Limitazioni della trasformazione dei dati

DirectQuery limita le trasformazioni dei dati che è possibile applicare all'interno dell'editor di Power Query. Con i dati importati, è possibile applicare facilmente un set sofisticato di trasformazioni per pulire e rimodellare i dati prima di usarli per creare oggetti visivi. Ad esempio, è possibile analizzare documenti JSON o dati pivot da una colonna a una maschera di riga. Queste trasformazioni sono più limitate in DirectQuery.

Quando ci si connette a un'origine OLAP (Online Analytical Processing) come SAP BW, non è possibile definire alcuna trasformazione e l'intero modello esterno viene ricavato dall'origine. Per le origini relazionali, come SQL Server, è comunque possibile definire un set di trasformazioni per ogni query, ma tali trasformazioni sono limitate per motivi di prestazioni.

Tutte le trasformazioni devono essere applicate a ogni query all'origine sottostante, anziché una volta all'aggiornamento dati. Le trasformazioni devono essere in grado di tradurre ragionevolmente in una singola query nativa. Se si usa una trasformazione troppo complessa, viene visualizzato un errore che indica che deve essere eliminato o che il modello di connessione deve essere passato all'importazione.

Inoltre, la finestra di dialogo Recupera dati o l'editor di Power Query usano selezioni secondarie all'interno delle query generate e inviate per recuperare i dati per un oggetto visivo. Le query definite nell'editor di Power Query devono essere valide all'interno di questo contesto. In particolare, non è possibile usare una query con espressioni di tabella comuni, né una query che richiama stored procedure.

Limitazioni di modellazione

In questo contesto il termine modellazione indica l'azione di modifica e arricchimento dei dati non elaborati, nell'ambito della creazione di un report che usa i dati. Esempi di modellazione includono:

• Definizione di relazioni tra tabelle.
• Aggiunta di nuovi calcoli, come colonne calcolate e misure.
• Ridenominazione e disattivazione della visualizzazione di colonne e misure.
• Definizione di gerarchie.
• Definizione della formattazione delle colonne, riepilogo predefinito e ordinamento.
• Raggruppamento o clustering dei valori.

È comunque possibile apportare molti di questi arricchimenti del modello quando si usa DirectQuery e usare il principio di arricchimento dei dati non elaborati per migliorare l'utilizzo successivo. Tuttavia, alcune funzionalità di modellazione non sono disponibili o sono limitate con DirectQuery. Le limitazioni vengono applicate per evitare problemi di prestazioni.

Le limitazioni seguenti sono comuni a tutte le origini DirectQuery. Altre limitazioni possono essere applicate alle singole origini.

• Nessuna gerarchia di date predefinita: con i dati importati, ogni colonna date/datetime include anche una gerarchia data predefinita disponibile. Ad esempio, se si importa una tabella di ordini di vendita che include una colonna OrderDate e si usa OrderDate in un oggetto visivo, è possibile scegliere il livello di data appropriato da usare, ad esempio anno, mese o giorno. Questa gerarchia di data predefinita non è disponibile con DirectQuery. Se è disponibile una tabella Data nell'origine sottostante, come avviene in molti data warehouse, è possibile usare le funzioni di Business Intelligence per le espressioni di analisi dei dati (DAX) come di consueto.

• Supporto di data/ora solo a livello di secondi: per i modelli semantici che usano colonne di tempo, Power BI genera query sull'origine DirectQuery sottostante solo fino al livello di dettaglio dei secondi, non ai millisecondi. Rimuovere i dati in millisecondi dalle colonne di origine.

• Limitazioni nelle colonne calcolate: le colonne calcolate possono essere solo all'interno di righe, ovvero possono fare riferimento solo ai valori di altre colonne della stessa tabella, senza usare funzioni di aggregazione. Inoltre, le funzioni scalari DAX consentite, ad esempio LEFT(), sono limitate a quelle di cui è possibile eseguire il push nell'origine sottostante. Le funzioni variano a seconda delle funzionalità esatte dell'origine. Le funzioni non supportate non sono elencate nel completamento automatico durante la creazione della query DAX per una colonna calcolata, e generano un errore se usato.

• Nessun supporto per le funzioni DAX padre-figlio: In modalità DirectQuery non è possibile usare la famiglia di funzioni DAX PATH() che in genere gestiscono strutture padre-figlio, ad esempio grafici di account o gerarchie dei dipendenti.

• Nessun clustering: quando si usa DirectQuery, non è possibile usare la funzionalità di clustering per trovare automaticamente i gruppi.

Limitazioni della creazione di report

Quasi tutte le funzionalità di creazione di report sono supportate per i modelli DirectQuery. Se l'origine sottostante offre un livello di prestazioni appropriato, è possibile usare lo stesso set di visualizzazioni per i dati importati.

Una limitazione generale è che la lunghezza massima dei dati in una colonna di testo per i modelli semantici DirectQuery è di 32.764 caratteri. La segnalazione di testi più lunghi genera un errore.

Le funzionalità di creazione di report di Power BI seguenti possono causare problemi di prestazioni nei report basati su DirectQuery:

• Filtri di misure: gli oggetti visivi che usano misure o aggregati di colonne possono contenere filtri in tali misure. L'immagine grafica seguente visualizza ad esempio il valore di SalesAmount per categoria, ma solo per le categorie con oltre 20 milioni di vendite.

  

  Questo approccio causa l'invio di due query all'origine sottostante:

  • La prima query recupera le categorie che soddisfano la condizione SalesAmount maggiore di 20 milioni.
  • La seconda query recupera i dati necessari per l'oggetto visivo, che include le categorie che soddisfano la condizione WHERE.

  Questo approccio in genere funziona bene in presenza di centinaia o migliaia di categorie, come in questo esempio. Se il numero di categorie è molto più elevato, le prestazioni possono peggiorare. La query ha esito negativo se sono presenti più di un milione di categorie.

• Filtri TopN: è possibile definire filtri avanzati per filtrare solo i valori N superiore o inferiore classificati da una misura. Ad esempio, i filtri possono includere le prime 10 categorie. Questo approccio invia nuovamente due query all'origine sottostante. La prima query restituisce tuttavia tutte le categorie dell'origine sottostante, e quindi le TopN verranno determinate in base ai risultati restituiti. A seconda della cardinalità della colonna interessata, questo approccio può causare problemi di prestazioni o errori di query a causa del limite di un milione di righe nei risultati della query.

• Mediana: Di qualsiasi aggregazione, ad esempio Sum o Count Distinct, viene eseguito il push nell'origine sottostante. Tuttavia, l'aggregazione median non è in genere supportata dall'origine sottostante. Per median, i dati di dettaglio vengono recuperati dall'origine sottostante e la mediana viene calcolata dai risultati restituiti. Questo approccio è ragionevole per calcolare la mediana su un numero relativamente ridotto di risultati.

  I problemi di prestazioni o gli errori di query possono verificarsi se la cardinalità è elevata a causa del limite di un milione di righe. Ad esempio, l'esecuzione di query per la popolazione di paese/area mediana potrebbe essere ragionevole, ma il prezzo di vendita mediano potrebbe non essere ragionevole.

• Filtri di testo avanzati come 'contains': il filtro avanzato per una colonna di testo consente filtri come contains e begins with. Questi filtri possono comportare prestazioni ridotte per alcune origini dati. In particolare, non usare il filtro contains predefinito se è necessaria una corrispondenza esatta. Anche se i risultati possono essere gli stessi, a seconda dei dati effettivi, le prestazioni potrebbero differire notevolmente a causa dell'uso degli indici.

• Filtri dei dati a selezione multipla: Per impostazione predefinita, i filtri dei dati consentono solo di effettuare una singola selezione. Consentire la selezione multipla in filtri può causare problemi di prestazioni. Ad esempio, se l'utente seleziona 10 prodotti di interesse, ogni nuova selezione comporta l'invio di query all'origine. Anche se l'utente può selezionare l'elemento successivo prima che la query venga completata, questo approccio comporta in ogni caso un carico aggiuntivo sull'origine sottostante.

• Totali per gli oggetti visivi di tabella: per impostazione predefinita, le tabelle e le matrici visualizzano totali e subtotali. In molti casi, ottenere i valori per tali totali richiede l'invio di query separate all'origine sottostante. Questo requisito si applica ogni volta che si usa l'aggregazione DistinctCount o in tutti i casi che usano DirectQuery su SAP BW o SAP HANA. È possibile disattivare tali totali usando il riquadro Formato.

Raccomandazioni per DirectQuery

Questa sezione fornisce indicazioni generali su come usare correttamente DirectQuery, in base alle implicazioni.

Prestazioni dell'origine dati sottostante

Verificare che gli oggetti visivi semplici vengano aggiornati entro cinque secondi, offrendo un'esperienza interattiva ragionevole. Se l'aggiornamento degli oggetti visivi richiede più di 30 secondi, è probabile che altri problemi dopo la pubblicazione del report rendano impossibile la soluzione.

Se le query sono lente, esaminare le query inviate all'origine sottostante e il motivo della lentezza delle prestazioni. Per altre informazioni, vedere Diagnostica delle prestazioni.

Questo articolo non tratta l'ampia gamma di raccomandazioni per l'ottimizzazione dei database nel set completo delle possibili origini sottostanti. Per la maggior parte delle situazioni si applicano le procedure di database standard seguenti:

• Per prestazioni migliori, le relazioni di base sulle colonne integer anziché unire colonne di altri tipi di dati.

• Creare gli indici appropriati. La creazione dell'indice indica in genere l'uso di indici dell'archivio di colonne nelle origini che li supportano, ad esempio SQL Server.

• Aggiornare le statistiche necessarie nell'origine.

Progettazione del modello

Quando si definisce il modello, seguire queste indicazioni:

• Evitare query complesse nell'editor di Power Query. L'editor di Power Query converte una query complessa in una singola query SQL. La singola query viene visualizzata nella selezione secondaria di ogni query inviata alla tabella. Se la query è complessa potrebbero verificarsi problemi di prestazioni per ogni query inviata. È possibile ottenere la query SQL effettiva per un set di passaggi facendo clic con il pulsante destro del mouse sull'ultimo passaggio in Passaggi applicati nell'editor di Power Query e scegliendo Visualizza query nativa.

• Mantenere le misure semplici. Almeno inizialmente, limitare le misure alle aggregazioni semplici. Se le misure operano in modo soddisfacente, è possibile definire misure più complesse, ma prestare attenzione alle prestazioni.

• Evitare relazioni sulle colonne calcolate. Nei database in cui è necessario eseguire join a più colonne, Power BI non consente relazioni di base su più colonne come chiave primaria o chiave esterna. La soluzione alternativa comune consiste nel concatenare le colonne usando una colonna calcolata e basare il join su tale colonna.

  Questa soluzione alternativa è ragionevole per i dati importati, ma per DirectQuery produce un join in un'espressione. Questo risultato in genere impedisce l'uso di indici e comporta prestazioni scarse. L'unica soluzione alternativa è materializzare effettivamente più colonne in una singola colonna nell’origine dati sottostante.

• Evitare relazioni sulle colonne “uniqueidentifier”. Power BI non supporta dati di tipo uniqueidentifier in modo nativo. La definizione di una relazione tra colonne uniqueidentifier genera una query con un join che prevede un cast. Anche questo approccio provoca generalmente una riduzione delle prestazioni. L'unica soluzione alternativa consiste nel materializzare le colonne di un tipo alternativo nell'origine dati sottostante.

• Nascondere la colonna "to" nelle relazioni. La colonna to nelle relazioni è in genere la chiave primaria della tabella to. La colonna deve essere nascosta, ma, se nascosta, non viene visualizzata nell'elenco dei campi e non può essere usata negli oggetti visivi. Spesso le colonne su cui si basano le relazioni sono in realtà colonne di sistema, ad esempio chiavi surrogate in un data warehouse. È comunque consigliabile nascondere tali colonne.

  Se la colonna ha significato, introdurre una colonna calcolata visibile e avente un'espressione semplice equivalente alla chiave primaria, ad esempio:

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• Esaminare tutte le colonne calcolate e le modifiche ai tipi di dati. È possibile usare tabelle calcolate quando si usa DirectQuery con modelli compositi. Queste funzionalità non sono necessariamente dannose, ma generano query che contengono espressioni anziché semplici riferimenti alle colonne. Tali query potrebbero comportare l'uso di indici.

• Evitare il filtro incrociato bidirezionale per le relazioni. L'uso di filtri incrociati bidirezionali può determinare istruzioni di query che non offrono prestazioni ottimali. Per altre informazioni sul filtro incrociato bidirezionale, vedere Abilitare il filtro incrociato bidirezionale per DirectQuery in Power BI Desktop o scaricare il white paper filtro incrociato bidirezionale . Gli esempi nel documento sono relativi a SQL Server Analysis Services, ma i punti fondamentali si applicano anche a Power BI.

• Provare l'impostazione Considera integrità referenziale. L'impostazione Presupporre l'integrità referenziale sulle relazioni consente alle query di usare INNER JOIN anziché istruzioni OUTER JOIN. Le prestazioni delle query generalmente migliorano seguendo queste indicazioni, anche se ciò dipende dalle specifiche dell'origine dati.

• Non usare il filtro della data relativa in editor di Power Query. È possibile definire filtri data relativi nell'editor di Power Query. Ad esempio, è possibile filtrare in base alle righe in cui la data si trova negli ultimi 14 giorni.

  

  Tuttavia, questo filtro si traduce in un filtro basato su una data fissa, ad esempio l'ora di creazione della query, come si può vedere nella query nativa.

  

  Questi dati probabilmente non sono quelli desiderati. Per assicurarsi che il filtro venga applicato in base alla data in cui viene eseguito il report, applicare il filtro data nel report. È possibile creare una colonna calcolata che calcola il numero di giorni fa usando la funzione DAX DATE() e usare tale colonna calcolata nel filtro.

Progettazione del report

Quando si crea un report che usa una connessione DirectQuery, seguire queste indicazioni:

• Prendere in considerazione l'uso delle opzioni di riduzione delle query: Power BI offre opzioni di report per inviare meno query e disabilitare determinate interazioni che causano un'esperienza scarsa se l'esecuzione delle query risultanti richiede molto tempo. Queste opzioni si applicano quando si interagisce con il report in Power BI Desktop e si applicano anche quando gli utenti usano il report nel servizio Power BI.

  Per accedere a queste opzioni in Power BI Desktop, passare a File>Opzioni e impostazioni>Opzioni e selezionare Riduzione query.

  

  Le selezioni nella schermata di riduzione della query consentono di visualizzare un pulsante Applica per filtri dei dati o selezioni di filtri. Non viene inviata alcuna query finché non si seleziona il pulsante Applica sul fitro o sul filtro dei dati. Le query usano quindi le selezioni per filtrare i dati. Questo pulsante consente di effettuare diverse selezioni di filtro dei dati e filtro prima di applicarle.

• Applicare prima i filtri: applicare sempre eventuali filtri all'inizio della creazione di un oggetto visivo. Ad esempio, invece di trascinare TotalSalesAmount e ProductName, e quindi filtrare in base a un anno specifico, applicare il filtro su anno all'inizio.

  Ogni passaggio della creazione di un oggetto visivo invia una query. Anche se è possibile apportare un'altra modifica prima del completamento della prima query, questo approccio lascia comunque un carico superfluo sull'origine sottostante. Applicando subito i filtri, le query intermedie diventano generalmente meno impegnative. Se non si applicano i filtri in anticipo, è possibile che si raggiunga il limite di un milione di righe.

• Limitare il numero di oggetti visivi in una pagina: quando si apre una pagina o si modifica un filtro dei dati o un filtro a livello di pagina, tutti gli oggetti visivi nell'aggiornamento della pagina. Esiste un limite al numero di query parallele. Con l'aumentare del numero di oggetti visivi, alcuni oggetti visivi vengono aggiornati in modo seriale, aumentando il tempo necessario per aggiornare la pagina. Pertanto, è consigliabile limitare il numero di oggetti visivi in una singola pagina e avere invece pagine più semplici.

• Valutare la possibilità di disattivare l'interazione tra oggetti visivi: per impostazione predefinita, le visualizzazioni in una pagina del report possono essere usate per applicare filtri incrociati ed evidenziare in modo incrociato le altre visualizzazioni nella pagina. Ad esempio, se si seleziona 1999 nel grafico a torta, l'istogramma viene evidenziato in modo da visualizzare le vendite per categoria per il 1999.

  

  Il filtro incrociato e l'evidenziazione incrociata in DirectQuery richiedono l'invio di query all'origine sottostante. È consigliabile disattivare questa interazione se il tempo impiegato per rispondere alle selezioni degli utenti è eccessivamente lungo.

  È possibile usare le impostazioni di riduzione delle query per disabilitare l'evidenziazione incrociata in tutto il report o caso per caso. Per altre informazioni, vedere Come gli oggetti visivi si filtrano tra loro in un report di Power BI.

Numero massimo di connessioni

È possibile impostare il numero massimo di connessioni che DirectQuery può aprire per ogni origine dati sottostante e controllare così il numero di query inviate simultaneamente a ogni origine dati.

Il numero massimo predefinito di connessioni simultanee che DirectQuery può aprire è 10. Per modificare il numero massimo per il file corrente in Power BI Desktop, passare a File>Opzioni e impostazioni>Opzioni, e selezionare DirectQuery nella sezione File corrente del riquadro sinistro.

L'impostazione è abilitata solo se nel report corrente è presente almeno un'origine DirectQuery. Il valore si applica a tutte le origini DirectQuery e a tutte le nuove origini DirectQuery aggiunte a tale report.

Aumentare il Numero massimo di connessioni per origine dati consente di inviare più query, fino al numero massimo specificato, all'origine dati sottostante. Questo approccio è utile se in un'unica pagina sono presenti numerosi oggetti visivi o se molti utenti accedono a un report contemporaneamente. Quando viene raggiunto il numero massimo di connessioni, le query in eccesso vengono accodate fino a quando non diventa disponibile una connessione. Un limite più elevato comporta un carico maggiore sull'origine sottostante, pertanto l'impostazione non garantisce un miglioramento delle prestazioni complessive.

Dopo aver pubblicato un report nel servizio Power BI, il numero massimo di query simultanee dipende anche dai limiti fissi impostati nell'ambiente di destinazione in cui viene pubblicato il report. Power BI, Power BI Premium e Server di report di Power BI impongono limiti diversi. La tabella seguente elenca i limiti superiori delle connessioni attive per ogni origine dati per ogni ambiente Power BI. Questi limiti si applicano alle origini dati cloud e alle origini dati locali, ad esempio SQL Server, Oracle e Teradata.

Ambiente	Limite massimo per origine dati
Power BI Pro	10 connessioni attive
Power BI Premium	Dipende dalla limitazione dello SKU del modello semantico
Server di report di Power BI	10 connessioni attive

Nota

L'impostazione del numero massimo di connessioni DirectQuery si applica a tutte le origini DirectQuery quando si abilita metadati avanzati, ovvero l'impostazione predefinita per tutti i modelli creati in Power BI Desktop.

DirectQuery nel servizio Power BI

Tutte le origini dati DirectQuery sono supportate da Power BI Desktop e alcune origini sono disponibili direttamente dal servizio Power BI. Un utente aziendale può usare Power BI per connettersi ai dati in Salesforce, ad esempio, e ottenere immediatamente un dashboard, senza usare Power BI Desktop.

Nel servizio Power BI sono disponibili solo le due origini abilitate per DirectQuery seguenti:

• Spark
• Azure Synapse Analytics (in precedenza SQL Data Warehouse)

Anche per queste due origini, è comunque consigliabile iniziare a usare DirectQuery in Power BI Desktop. Sebbene sia facile stabilire inizialmente la connessione nel servizio Power BI, esistono delle limitazioni per migliorare ulteriormente il report risultante. Ad esempio, nel servizio non è possibile creare calcoli o usare molte funzionalità analitiche o aggiornare i metadati per riflettere le modifiche apportate allo schema sottostante.

Le prestazioni di un report DirectQuery nel servizio Power BI dipendono dal grado di carico inserito nell'origine dati sottostante. Il carico dipende da:

• Numero di utenti che condividono il report e il dashboard.
• Complessità del report.
• Indica se il report definisce la sicurezza a livello di riga.

Comportamento del report nel servizio Power BI

Quando si apre un report nel servizio Power BI, tutti gli oggetti visivi nell'aggiornamento della pagina attualmente visibile. Ciascun oggetto visivo richiede almeno una query sull'origine dati sottostante. Alcuni oggetti visivi potrebbero richiedere più query. Ad esempio, un oggetto visivo potrebbe visualizzare valori aggregati di due tabelle dei fatti diverse oppure contenere una misura più complessa o totali di una misura non additiva come Count Distinct. Se ci si sposta su una nuova pagina, questi oggetti visivi vengono aggiornati. L'aggiornamento invia un nuovo set di query all'origine sottostante.

Ogni interazione dell'utente con il report può comportare l'aggiornamento degli oggetti visivi. La selezione di un valore diverso in un filtro dei dati richiede ad esempio l'invio di un nuovo set di query per aggiornare tutti gli oggetti visivi interessati. Lo stesso vale per la selezione di un oggetto visivo per l'evidenziazione incrociata di altri oggetti visivi o la modifica di un filtro. In modo analogo, la creazione o la modifica di un report richiede l'invio di query per ogni passaggio necessario per produrre l'oggetto visivo finale.

I risultati vengono memorizzati nella cache, L'aggiornamento di un oggetto visivo è istantaneo se gli stessi risultati sono stati ottenuti di recente. Se non è stata definita la sicurezza a livello di riga, queste cache non vengono condivise tra gli utenti.

L'uso di DirectQuery impone alcune limitazioni importanti in alcune delle funzionalità offerte dal servizio Power BI per i report pubblicati:

• Informazioni rapide non sono supportate: Informazioni rapide di Power BI eseguono ricerche in diversi subset del modello semantico applicando una serie di algoritmi complessi per individuare informazioni potenzialmente interessanti. Poiché le informazioni rapide richiedono query ad alte prestazioni, questa funzionalità non è disponibile nei modelli semantici che usano DirectQuery.

• L'uso di Esplora in Excel comporta prestazioni scarse: è possibile esplorare un modello semantico usando la funzionalità Esplora in Excel, che consente di creare tabelle pivot e grafici pivot in Excel. Questa funzionalità è supportata per i modelli semantici che usano DirectQuery, ma le prestazioni sono più lente rispetto alla creazione di oggetti visivi in Power BI. Se si usa Excel è importante per gli scenari tenere conto di questo problema per decidere se usare DirectQuery.

• Excel non mostra gerarchie: ad esempio, quando si usa Analizza in Excel, Excel non mostra alcuna gerarchia definita nei modelli di Azure Analysis Services o nei modelli semantici di Power BI che usano DirectQuery.

Aggiornamento del dashboard

Nel servizio Power BI è possibile aggiungere singoli oggetti visivi o intere pagine ai dashboard come riquadri. I riquadri basati sui modelli semantici DirectQuery vengono aggiornati automaticamente inviando query alle origini dati sottostanti in base a una pianificazione. Per impostazione predefinita, i modelli semantici vengono aggiornati ogni ora, ma è possibile configurare gli intervalli di pianificazione degli aggiornamenti tra ogni settimana e ogni 15 minuti come parte delle impostazioni del modello semantico.

Se nel modello non è definita alcuna sicurezza a livello di riga, ogni riquadro viene aggiornato una sola volta e i risultati vengono condivisi tra tutti gli utenti. Se si usa la sicurezza a livello di riga, ogni riquadro richiede l'invio di query separate per utente all'origine sottostante.

L'effetto moltiplicatore può essere notevole. Un dashboard con 10 riquadri, condivisi con 100 utenti, creati in un modello semantico usando DirectQuery con sicurezza a livello di riga, comporta l'invio di almeno 1.000 query all'origine dati sottostante per ogni aggiornamento. Prestare attenzione all'uso della sicurezza a livello di riga e alla configurazione della pianificazione dell'aggiornamento.

Timeout della query

Alle singole query nel servizio Power BI viene applicato un timeout di quattro minuti. Le query che richiedono più di quattro minuti hanno esito negativo. Questo limite è progettato per evitare problemi causati da tempi di esecuzione eccessivamente lunghi. È consigliabile usare DirectQuery solo per le origini che possono offrire prestazioni di query interattive.

Performance Diagnostics

Questa sezione descrive come diagnosticare i problemi di prestazioni o come ottenere informazioni più dettagliate per ottimizzare i report.

Iniziare a diagnosticare i problemi di prestazioni in Power BI Desktop, anziché nel servizio Power BI. I problemi di prestazioni sono spesso basati sulle prestazioni dell'origine sottostante. Identificare e diagnosticare i problemi è più facile nell'ambiente più isolato di Power BI Desktop.

Questo approccio elimina inizialmente alcuni componenti, come Power BI Gateway. Se i problemi di prestazioni non si verificano in Power BI Desktop, è possibile esaminare le specifiche del report nel servizio Power BI.

L’Analizzatore prestazioni di Power BI Desktop è uno strumento utile per identificare i problemi. Provare a isolare eventuali problemi con un oggetto visivo, anziché molti oggetti visivi in una pagina. Se un singolo oggetto visivo in una pagina di Power BI Desktop è lento, usare Analizzatore prestazioni per analizzare le query inviate da Power BI Desktop all'origine sottostante.

È anche possibile visualizzare tracce e informazioni di diagnostica che alcune origini dati sottostanti generano. Anche se non sono presenti tracce dall'origine, il file di traccia potrebbe contenere dettagli utili su come viene eseguita una query e su come migliorarla. È possibile usare il processo seguente per visualizzare le query inviate da Power BI e i relativi tempi di esecuzione.

Usare SQL Server Profiler per visualizzare le query

Per impostazione predefinita, Power BI Desktop registra gli eventi di una sessione specifica in un file di traccia denominato FlightRecorderCurrent.trc. Il file di traccia si trova nella cartella di Power BI Desktop per l'utente corrente, in una cartella denominata AnalysisServicesWorkspaces.

Per alcune origini DirectQuery, questo file di traccia include tutte le query inviate all'origine dati sottostante. Le origini dati che inviano query al log sono le seguenti:

• SQL Server
• Database SQL di Azure
• Azure Synapse Analytics (in precedenza SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

È possibile leggere i file di traccia usando SQL Server Profiler, parte del download gratuito di SQL Server Management Studio.

Per aprire il file di traccia per la sessione corrente:

1. Durante una sessione di Power BI Desktop selezionare File>Opzioni e impostazioni>Opzioni e quindi selezionare Diagnostica.

2. In Raccolta dump di arresto anomalo del sistema, selezionare Aprire la cartella dump/tracce di arresto anomalo del sistema.

   

   Verrà visualizzata la cartella Power BI Desktop\Traces.

3. Passare alla cartella padre e quindi alla cartella AnalysisServicesWorkspaces, che contiene una cartella dell'area di lavoro per ogni istanza aperta di Power BI Desktop. Queste cartelle sono denominate con un suffisso intero, ad esempio AnalysisServicesWorkspace2058279583. La cartella dell'area di lavoro viene eliminata al termine della sessione di Power BI Desktop associata.

   All'interno della cartella dell'area di lavoro per la sessione corrente di Power BI, la cartella \Data contiene il file di traccia FlightRecorderCurrent.trc. Prendi nota dell'ubicazione.

4. Aprire SQL Server Profiler e selezionare File>Apri>file di traccia.

5. Passare o immettere il percorso del file di traccia per la sessione corrente di Power BI e aprire FlightRecorderCurrent.trc.

SQL Server Profiler visualizza tutti gli eventi della sessione corrente. Lo screenshot seguente evidenzia un gruppo di eventi per una query. Ogni gruppo di query ha gli eventi seguenti:

• Un evento Query Begin e Query End, che rappresenta l'inizio e la fine di una query DAX generata modificando un oggetto visivo o un filtro nell'interfaccia utente di Power BI oppure filtrando o trasformando i dati nell'editor di Power Query.

• Una o più coppie di eventi DirectQuery Begin e DirectQuery End, che rappresentano query inviate all'origine dati sottostante, nell'ambito della valutazione della query DAX.

È possibile eseguire più query DAX in parallelo, quindi con possibilità di interfoliazione degli eventi di diversi gruppi. È possibile usare il valore ActivityID per determinare quali eventi appartengono allo stesso gruppo.

Anche le colonne seguenti sono di interesse:

• TextData: dettagli testuali dell'evento. Per gli eventi Query Begin e Query End, il dettaglio è la query DAX. Per gli eventi DirectQuery Begin e DirectQuery End, il dettaglio è la query SQL inviata all'origine sottostante. Il textData per l'evento attualmente selezionato viene visualizzato anche nel riquadro nella parte inferiore della schermata.
• EndTime: L'ora di completamento dell'evento.
• Durata: La durata, in millisecondi, necessaria per eseguire la query DAX o SQL.
• Errore: indica se si è verificato un errore, nel qual caso l'evento viene visualizzato anche in rosso.

Per acquisire una traccia per diagnosticare un potenziale problema di prestazioni:

1. Aprire una singola sessione di Power BI Desktop per evitare la confusione di più cartelle di aree di lavoro.

2. Eseguire il set di azioni di interesse in Power BI Desktop. Includere alcune altre azioni per assicurarsi che gli eventi di interesse vengano scaricati nel file di traccia.

3. Aprire SQL Server Profiler ed esaminare la traccia. Tenere presente che se si chiude Power BI Desktop il file di traccia viene eliminato. Inoltre, le ulteriori azioni in Power BI Desktop non vengono visualizzate immediatamente: Per visualizzare nuovi eventi, è necessario chiudere e riaprire il file di traccia.

Mantenere le singole sessioni relativamente ridotte (10 secondi di azioni, non centinaia), per semplificare l'interpretazione del file di traccia. C'è anche un limite applicato alle dimensioni del file stesso, dal quale, nel caso di sessioni di lunga durata, possono essere eliminati gli eventi meno recenti.

Informazioni sul formato delle query

Il formato generale delle query di Power BI Desktop usa le selezioni secondarie per ogni tabella a cui fanno riferimento. La query dell'editor di Power Query definisce le query di selezione secondaria. Si supponga, ad esempio, di avere le tabelle TPC-DS seguenti in SQL Server:

Esecuzione della query seguente:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Risultati nell'oggetto visivo seguente in Power BI:

L'aggiornamento dell'oggetto visivo genera la query SQL nell'immagine seguente. Sono disponibili tre query di selezione secondaria per Web_Sales, Item e Date_dim, che restituiscono tutte le colonne nella rispettiva tabella, anche se l'oggetto visivo fa riferimento solo a quattro colonne.

L'editor di Power Query definisce le query di selezione secondaria esatte. Questo uso di query di selezione secondaria non è stato mostrato per influire sulle prestazioni per le origini dati supportate da DirectQuery. Origini dati come SQL Server ottimizzano i riferimenti alle altre colonne.

Power BI usa questo modello perché l'analista fornisce direttamente la query SQL. Power BI usa la query come specificato, senza alcun tentativo di riscriverla.

Contenuto correlato

Per altre informazioni su DirectQuery in Power BI, vedere:

• Usare DirectQuery in Power BI Desktop

Questo articolo descrive aspetti di DirectQuery comuni a tutte le origini dati. Per informazioni dettagliate su origini specifiche, vedere gli articoli seguenti:

• DirectQuery e SAP HANA
• DirectQuery e SAP BW
• Usare DirectQuery per modelli semantici di Power BI e Analysis Services