Querying and processing in SSAS
Querying and processing activities affect SSAS performance—whether you’re using Multidimensional mode or Tabular mode. Many of the same concepts and best practices applied to queries and backups in relational databases such as SQL Server can be applied to or used to understand querying and processing in SSAS.
| Activity |
Description |
| Querying |
- Languages used when querying SSAS:
- Multidimensional Expressions (MDX); most often used in Multidimensional mode
- Data Mining Extensions (DMX)
- Data Analysis Expressions (DAX); most often used in Tabular mode
- Similar to querying relational databases
|
| Processing |
- Creates or updates data and recalculates and reorganizes existing data, primarily through XML for Analysis (XMLA)
- Similar to backups on relational databases
|
Finding the source of SSAS performance bottlenecks
When performing queries, SSAS uses two primary engines: the formula engine and the storage engine. Either engine can be the source of a performance bottleneck; troubleshooting identifies which engine is the problem. The table below breaks down the primary features of each type of engine.
| Engine Type |
Features |
| Formula Engine |
- Performs complex calculations
- Single-threaded per request
|
| Storage Engine |
- Reads data and writes data to storage
- In Multidimensional mode, can read from the file system on the server; both physical disk input/output (I/O) as well as Windows file cache
- In Tabular mode, data is typically already in-memory, unless there are paging or memory pressure issues; usually has no physical I/O
- Multithreaded
|
The first thing you need to determine when looking at performance problems is whether processing activities are happening at the same time as querying activities. Once you've ruled that out, SQL Server Profiler trace events can determine which query engine—formula or storage—is creating the bottleneck. The following table provides details on the Profiler trace events that are most important when troubleshooting SSAS performance challenges.
| Profiler Trace Event |
Trace Event Indicators |
| Command Begin/End |
Processing commands begin and end |
| Query Begin/End |
Queries begin and end |
| Query Subcube/ Verbose |
Duration the formula engine is querying to the storage engine (Multidimensional mode) |
| Progress Report Begin/End |
Begin and end of file reads (Multidimensional mode) |
| Get Data From Aggregation |
Time spent getting data from aggregations. This data is stored, pre-calculated data typically needed to handle the workload in the environment (Multidimensional mode) |
| VeritPaq SE Query Begin/End |
Duration the formula engine is querying to the storage engine (Tabular mode) |
| Direct Query Begin/End |
Time spent querying back to the relational data source for the data |
To determine which engine is the source of the problem, add up the cumulative durations indicated in Query Subcube/Verbose, Progress Report Begin/End, Get Data from Aggregation, VertiPaq SE Query Begin/End, and Direct Query End and compare to the Query Begin/End total time.
If the total duration is:
- 50% or more of the Query Begin/End total time, the problem is in the storage engine.
- Less than 50% of the Query Begin/End total time, the problem is in the formula engine.
Key areas to investigate when troubleshooting query performance issues
In addition to understanding which query engine is affecting performance, it’s essential to identify specific query and system attributes that are contributing to performance problems.
- Processing uses resources, impacting query performance if querying is happening at the same time. Questions to ask include: When is processing happening? How is processing happening? How often is processing happening?
- Un-optimized code, including MDX and DAX queries, can be rewritten to improve query performance.
- Server resources—CPU, memory, disk, and network—can negatively affect performance.
Optimizing MDX or DAX queries
In some cases, the identified performance problems involve query optimization. When MDX or DAX query optimization is necessary, there are three primary factors to consider:
- Query construction choices—There are many ways to construct a query, and some will perform better than others. Functions used in the query can make a significant difference in performance. For example, in DAX, many developers choose to use the Filter function instead of the Calculate function because it is easier to use. However, the Calculate function pushes more of the activity down to the VertiPaq storage engine, optimizing performance.
- Order of operations—Beyond the functions chosen, efficiency can also be affected by the way a query is written (i.e., its order of operations). For example, it might be more efficient to perform a calculation on data first, and then apply the filter after a quick scan in the storage engine for the results.
- Understanding the data—A deep understanding of the data also plays a significant role in query optimization. Team members need to know the data to understand how to apply the functions and order of operations since the data and environment will affect performance. In some cases, this will not be straightforward; optimization will be a matter of trial and error as new information about the data is understood.
