Risolvere i problemi dei modelli DirectQuery in Power BI Desktop

  • Articolo

Questo articolo illustra come diagnosticare i problemi di prestazioni con i modelli di dati DirectQuery di Power BI sviluppati in Power BI Desktop o nel servizio Power BI. L'articolo descrive anche come ottenere informazioni dettagliate per ottimizzare i report.

È consigliabile avviare qualsiasi diagnosi dei problemi di prestazioni in Power BI Desktop, anziché nel servizio Power BI o nel Server di report di Power BI. I problemi di prestazioni spesso dipendono dal livello di prestazioni dell'origine dati sottostante. È possibile identificare e diagnosticare più facilmente questi problemi nell'ambiente Power BI Desktop isolato, senza coinvolgere componenti come un gateway locale.

Se non vengono riscontrati problemi di prestazioni in Power BI Desktop, è possibile concentrarsi sulle specifiche del report nel servizio Power BI.

È anche consigliabile provare a isolare i problemi a un singolo oggetto visivo prima di esaminare molti oggetti visivi in una pagina.

Analizzatore prestazioni

Analizzatore prestazioni è uno strumento utile per identificare i problemi di prestazioni durante il processo di risoluzione dei problemi. Se è possibile identificare un singolo oggetto visivo lento in una pagina in Power BI Desktop, è possibile usare Analizzatore prestazioni per determinare le query inviate da Power BI Desktop all'origine sottostante.

È anche possibile visualizzare tracce e informazioni di diagnostica che le origini dati sottostanti generano. Tali tracce possono contenere informazioni utili sui dettagli sulla modalità di esecuzione della query e su come migliorarla.

Anche senza tracce dall'origine, è possibile visualizzare le query inviate da Power BI, insieme ai relativi tempi di esecuzione.

Nota

Per le origini basate su SQL DirectQuery, Analizzatore prestazioni mostra le query solo per le origini dati SQL Server, Oracle e Teradata.

File di traccia

Per impostazione predefinita, Power BI Desktop registra gli eventi di una sessione specifica in un file di traccia denominato FlightRecorderCurrent.trc. È possibile trovare il file di traccia per la sessione corrente nella cartella AppData per l'utente corrente, in <Utente>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces.

Le origini dati DirectQuery seguenti scrivono tutte le query inviate da Power BI al file di traccia. Il log potrebbe supportare altre origini DirectQuery in futuro.

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

Per raggiungere facilmente la cartella di traccia, in Power BI Desktop selezionare File>Opzioni e impostazioni>Opzioni e quindi Diagnostica.

Screenshot della sezione Diagnostica della schermata Opzioni di Power BI Desktop con il collegamento per aprire la cartella dump di arresto anomalo/traccia del sistema.

In Raccolta dump di arresto anomalo del sistema selezionare il collegamento Apri cartella dump di arresto anomalo/traccia per aprire la cartella <Utente>\AppData\Local\Microsoft\Power BI Desktop\Traces.

Passare alla cartella padre e quindi alla cartella AnalysisServicesWorkspaces, che contiene una sottocartella dell'area di lavoro per ogni istanza aperta di Power BI Desktop. I nomi delle sottocartelle hanno suffissi integer, ad esempio AnalysisServicesWorkspace2058279583.

Ogni cartella AnalysisServicesWorkspace include una sottocartella Data che contiene il file di traccia FlightRecorderCurrent.trc per la sessione corrente di Power BI. Questa cartella scompare al termine della sessione di Power BI Desktop associata.

È possibile aprire i file di traccia usando lo strumento SQL Server Profiler, che è possibile ottenere come parte del download gratuito di SQL Server Management Studio (SSMS). Dopo aver scaricato e installato SQL Server Management Studio, aprire SQL Server Profiler.

Screenshot della finestra di SQL Server Profiler senza tracce evidenziate.

Per aprire un file di traccia:

  1. In SQL Server Profiler selezionare File>Apri>File di traccia.

  2. Passare o immettere il percorso del file di traccia per la sessione di Power BI corrente, ad esempio <Utente>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data 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.

Screenshot di SQL Server Profiler con gli eventi Query Begin e Query End evidenziati.

È 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 valore 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.

L'immagine precedente restringe alcune delle colonne meno interessanti, in modo da visualizzare più facilmente le colonne più interessanti.

Seguire questo approccio 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. Esiste anche un limite per le dimensioni del file di traccia, quindi per le sessioni lunghe è possibile eliminare gli eventi iniziali.

Formato di query e sottoquery

Il formato generale delle query di Power BI Desktop consiste nell'usare sottoquery per ogni tabella del modello a cui fanno riferimento le query. La query dell'editor di Power Query definisce le query di selezione secondaria. Si supponga ad esempio che siano presenti le tabelle TPC-DS seguenti in un database relazionale di SQL Server:

Screenshot di un diagramma di visualizzazione del modello di Power BI Desktop che mostra le tabelle correlate Item, Web_Sales, Customer e Date-dim TPC-DS.

Nell'oggetto visivo di Power BI l'espressione seguente definisce la misura SalesAmount:


SalesAmount = SUMX(Web_Sales, [ws_sales_price] * [ws_quantity])

Screenshot di un istogramma a colonne in pila di Power BI Desktop che mostra l'importo delle vendite per categoria.

L'aggiornamento dell'oggetto visivo genera la query T-SQL nell'immagine seguente. Esistono tre sottoquery per le tabelle del modello Web_Sales, Item e Date_dim. Ogni query restituisce tutte le colonne della tabella del modello, anche se l'oggetto visivo fa riferimento solo a quattro colonne.

Queste sottoquery ombreggiate sono la definizione esatta delle query di Power Query. Questo uso di sottoquery non influisce sulle prestazioni per le origini dati supportate da DirectQuery. Origini dati come SQL Server ottimizzano i riferimenti alle altre colonne.

Uno dei motivi per cui Power BI utilizza questo modello è che è possibile definire una query di Power Query per usare un'istruzione di query specifica. Power BI usa la query come specificato, senza alcun tentativo di riscriverla. Questo modello limita l'uso di istruzioni di query che usano espressioni di tabella comuni (CTE) e stored procedure. Non è possibile usare queste istruzioni nelle sottoquery.

Screenshot di una query T-SQL che mostra sottoquery incorporate, una per ogni tabella del modello.

Prestazioni del gateway

Per informazioni sulla risoluzione dei problemi relativi alle prestazioni dei gateway, vedere Risolvere i problemi relativi ai gateway Power BI.

Contenuto correlato

Per altre informazioni su DirectQuery, vedere le risorse seguenti:

Domande? Contattare la community di Power BI