Introduction
To better understanding of workload management concepts in Azure Synapse Analytics, I recommend reading my previous article titled "Workload Management Concepts in Azure Synapse Analytics." This article explores the significance of workload classification, the assignment of resource classes, and importance of requests, and the prioritization of data load and queries.
Classification in workload management
Classification in workload management allows us to configure policies that can be applied to incoming requests by assigning resource classes and importance. A better use case in a typical data warehousing environment would be when you want to prioritize your data load by assigning them higher resource classes and resources compared to queries from users, which can be considered with a lower resource class than the data load. Not only this, but you can also assign finer controls by subclassifying both the query and data loads to ensure the larger data load or query has higher resource class or importance settings than the smaller ones. For example, the biometric data load in a company might be huge and need to be loaded before the payroll calculation data which is small.

Note. DBCC commands like BEGIN, COMMIT, and ROLLBACK TRANSACTION statements cannot be classified.
How to create a workload classifier?
Workload classification is a function that can map the users with workload group that has been already defined.
Now let us look at each of these parameters in detail.
WORKLOAD_GROUP: The name which maps the request to a workload group at the time of creating the classifier.
MEMBERNAME: The security user account which can be a database user, role, or AAD login/AAD group.
WLM_LABEL: The label is like that of a tag that we use when creating any Azure services. It is an optional parameter, and one can use the OPTION(LABEL) in the request to match the classifier configuration.
WLM_CONTEXT: This is an optional parameter. Instead of labeling each query in a session, you can simply apply session context, which can last for the entire session.
START_TIME and END_TIME: Both start and end times are in HH:MM format under the UTC zone. Both must be specified together, and it is a great feature to route the activity to be carried out in a specific time frame only.
IMPORTANCE: It specifies the importance of a request that has been made, and it influences the order in which the requests are scheduled by assigning priority access to resources. There are 5 different types of importance that can be set, and NORMAL is the default one.
- LOW
- BELOW_NORMAL
- NORMAL (default)
- ABOVE_NORMAL
- HIGH
PARAMETER WEIGHTING: Weighting will be assigned to the requests based on their classification parameters, and the higher the weightage importance will be determined.
Classifier Parameter |
Weight |
USER |
64 |
ROLE |
32 |
WLM_LABEL |
16 |
WLM_CONTEXT |
8 |
START_TIME/END_TIME |
4 |
For example, when our workload classifier fits with the following parameters, the higher the weightage of the classifier priority will be given to that workload classifier. The second one with WLM_CONTEXT & USER wins in this below example. Hence the proper mix of weightage should be declared if prioritization for the classifier is expected.
- START & END_TIME, WLM_LABEL & ROLE: 4+16+32= 52 Points
- WLM_CONTEXT & USER: 8+64= 72 Points
![]()
Dropping Classifier
Example
An example of creating a classifier with staticrc20 workload group
Summary
These are practical implementation steps for creating classification after creating a workload group.
Reference: Official Microsoft documentation.