Note: Tracing requires server admin rights, if you do not have these the trace buttons will be disabled
Because of the fact that Server Timings and Query Plan filter the trace events to only those comming from the current window and All Queries does not, you cannot run both types of traces from the same query window.
The ‘All Queries” trace is really useful when you wish to see the queries that are generated by a client tool like Power BI Desktop.
The following window shows a list of queries generated by clicking on some slicers in report in Power BI Desktop.
If you find a query that you wish to examine further you can double click on the query to copy it up to the editor.
Because the All Queries trace can capture a lot of events you may find it helpful to use the filter option to help find specific queries.
At the top of the All Queries tab is a small toolbar
From left to right these buttons are as follows:
|Start/Resume||will start or resume a paused / stopped trace|
|Pause||will temporarily pause the current trace|
|Stop||will stop the current trace (the captured events will remain in the output window)|
|Delete||will clear all the captured events|
|Copy to Editor||will copy the content of the currently highlighted query to the edit pane|
|Show Filters||will show/hide the filter controls|
|Clear Filters||will clear any currently set filters|
When connecting the All Queries trace to to Power BI you need to be aware that Power BI has it’s own level of internal caching. At a very high level it looks something like the following:
What this means is that if a visual has already rendered before DAX Studio has connected you will normally not capture any queries unless you do something like changing a filter or crossfiltering so that you are requesting different data to that which has been stored in the Visual level cache.
So the recommended procedure when attempting to performance profile the DAX queries from a Power BI report is to do the following:
At this point, DAX Studio should show you all the queries.