Risolvere i problemi dei modelli DirectQuery in Power BI Desktop

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 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 nella 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 durante una determinata sessione 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 <User>\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 Microsoft Azure
  • Azure Synapse Analytics (in precedenza SQL Data Warehouse)
  • Oracle
  • Teradata
  • SAP HANA

Per accedere facilmente alla cartella del file di traccia in Power BI Desktop, selezionare Opzioni file>e impostazioni>Opzioni e quindi selezionare Diagnostica.

Screenshot of the Diagnostics section of the Power BI Desktop Options screen with the link to open the crash dump/traces folder.

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

Passare alla cartella padre di tale cartella e quindi aprire la 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 contenente 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 of SQL Server Profiler window with no highlighted traces.

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 <User>\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 Query Begin evento eQuery 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 o filtrando o trasformando i dati nella editor di Power Query.

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

Screenshot of SQL Server Profiler with highlighted Query Begin and Query End events.

È possibile eseguire più query DAX in parallelo, in modo che gli eventi di gruppi diversi possano interleaversi. È possibile utilizzare il valore di ActivityID per determinare quali eventi appartengono allo stesso gruppo.

Anche le colonne seguenti sono di interesse:

  • TextData: dettagli testuali dell'evento. Per Query Begin gli eventi e Query End , il dettaglio è la query DAX. Per DirectQuery Begin gli eventi 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: ora di completamento dell'evento.
  • Durata: 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 dell'area 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 la chiusura di Power BI Desktop elimina il file di traccia. Inoltre, non vengono visualizzate immediatamente altre azioni in Power BI Desktop. Per visualizzare nuovi eventi, è necessario chiudere e riaprire il file di traccia.

Mantenere le singole sessioni ragionevolmente piccole, forse 10 secondi di azioni, non centinaia. Questo approccio semplifica 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 editor di Power Query definisce le query di selezione secondaria. Si supponga, ad esempio, di avere le tabelle TPC-DS seguenti in un database relazionale di SQL Server:

Screenshot of a Power BI Desktop model view diagram that shows the related Item, Web_Sales, Customer and Date-dim TPC-DS tables.

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


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

Screenshot of a Power BI Desktop stacked column chart that displays sales amount by category.

L'aggiornamento dell'oggetto visivo genera la query T-SQL nell'immagine seguente. Esistono tre sottoquery per le Web_Salestabelle del modello , Iteme 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. Le origini dati come SQL Server ottimizzano i riferimenti alle altre colonne.

Un motivo per cui Power BI usa questo modello è quindi possibile definire una query di Power Query per usare un'istruzione di query specifica. Power BI usa la query come specificato, senza tentare di riscriverla. Questo modello limita l'uso di istruzioni di query che usano espressioni di tabella comuni e stored procedure. Non è possibile usare queste istruzioni nelle sottoquery.

Screenshot of a T-SQL query that shows embedded subqueries, one for each model table.

Prestazioni del gateway

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

Per altre informazioni su DirectQuery, vedere le risorse seguenti:

Domande? Contattare la community di Power BI