When you think about priorities, you probably focus your attention on AMP work. Whether you are using Teradata Active System Management (TASM) or Teradata Integrated Workload Management (TIWM), AMP work performed by requests are typically spread across different workloads, with their priorities based on the importance of the work to the business and how long you expect the work to run.
Parsing engine work on behalf of a query runs within a workload as well. Work performed on the parsing engine is typically very quick and requires very few resources. So why not run some, or all, of your parsing activity in a very high priority workload where it may be able to complete sooner when your system is busy, just as you do with your short, critical AMP work? This posting will explain how parsing priority is determined, and will illustrate the steps involved in increasing parsing priority.
Background: Session Classification
A query's parsing engine (PE) work takes advantage of what is called "session classification". Session classification happens at session logon time and determines which TASM or TIWM workload will be used by tasks on the PE that do work (such as user validation) to get the session established before a query is issued.
The workload that a session classifies to can be identified in DBQLogTbl in field SessionWDID. The workload used for session handling is the same workload that will support all parsing and optimizing activity for the queries that are executed within that session.
How a Session Classifies to a Workload
A session classifies to a single workload, based strictly on the WHO classification criteria (referred to as Request Source criteria in Viewpoint) of the workload. Information about a session (and subsequently the queries within that session) that allows mapping to a workload is available at session logon time and includes WHO classification criteria such as Account string, Application, Username and Profile. All other non-WHO classification criteria that the workload might have (such as estimated processing time) are ignored at session classification time. That secondary criteria will be used only to determine which workload is chosen when a request executes on the AMPs.
TASM and TIWM determine the workload that will support session management (and secondarily request parsing) by doing the following:
- Find the workloads that satisfy the WHO criteria associated with the session
- Among the workloads with WHO criteria that satisfy the session detail, identify the workloads with the most number of individual WHO criteria
- Among the workloads with the highest number of WHO criteria that match the request’s session detail, select the workload associated with the highest priority
Consider these three workloads:
Case 1
MSI-Short: Account = ‘$M1$MSI&I’, Est Time <= 20 Sec. ==> High priority
MSI-Medium: Account = ‘$M1$MSI&I’, Est Time <= 500 Sec. ==> Medium priority
MSI-Long: Account = ‘$M1$MSI&I’, Est Time <= 2000 Sec. ==> Low priority
All requests whose Account is $M1$MSI&l will map (based solely on WHO criteria) to all three of these workloads. In this case parsing for all queries with that account will execute in MSI-Short because it has the highest priority among the three workloads that match the WHO criteria.
Case 2
MSI-Short: Account = ‘$M1$MSI&I’, Est Time <= 20 Sec. ==> High priority
MSI-Medium: Account = ‘$M1$MSI&I’, Est Time <= 500 Sec. ==> Medium priority
MSI-Long: Account = ‘$M1$MSI&I’, User = DRXU, Est Time <= 2000 Sec. ==> Low priority
In this case, parsing for all queries with Account $M1$MSI&I for User DRXU will execute in MSI-Long because it has the highest priority among workloads with the greatest number of WHO criteria matches (Account and User). However, all other queries with that Account (from users other than DRXU) will parse at MSI-Short, as it is the highest priority workload with one WHO criterion matching the session detail.
Case 3
MSI-Short: Account = ‘$M1$MSI&I’, Est Time <= 20 Sec. ==> High priority
MSI-Medium: Account = ‘$M1$MSI&I’, User = DRXU, Est Time <= 500 Sec. ==> Medium priority
MSI-Long: Account = ‘$M1$MSI&I’, User = DRXU, Est Time <= 2000 Sec. ==> Low priority
In this case, parsing for all queries with Account $M1$MSI&I for User DRXU will execute in MSI-Medium because among the workloads that have the greatest number of matching WHO criteria, MSI-Medium has the highest priority. Only requests from a user other than DRXU for Account $M1$MSI&I will parse in MSI-Short.
In summary, among the workloads with the highest number of WHO criteria that match a session’s characteristics, the workload with the highest priority will be used for session management as well as for the parsing of all queries in the session.
Setting up Special Parsing-Only Workloads
With this background, you can set up one, several or even many workloads specifically for parsing if you wish. Or you can just use the existing workloads and observe the information in the SessionWDID field in DBQLogTbl output using this new understanding to make better sense of the priority at which parsing is taking place.
If you decide to set up a single higher-priority workload for all parsing activities for all requests, then you will want to create a new workload and give it a very high priority.
To make sure this workload is chosen for the SessionWDID of all requests, consider including multiple WHO criteria (Username, Account, Application, for example) using the broadest possible matching scope (Username = *, Account = *, and Application = *). Make sure to use a greater number of WHO criteria than any other active workload uses. By making use of wild cards for three WHO criteria, you are setting up the condition where all requests are likely to match to that workload for their parsing work.
If such a parsing-only workload existed, then in Case 2 and Case 3 above, all MSI users would match to this single high-priority workload for parsing. That it because this parsing-only workload described above contains three matching WHO criteria (Username = *, Account = *, and Application = *), a greater number of WHO matches than the other defined workloads.
It is recommended that the Profile classification criterion not be used in defining a parsing-only workload, unless all users accessing the platform have an actual Profile assigned. When there is wild card classification on Profile (Profile = *), any session that logs on without providing a Profile will be disqualified from the workload.
A Second Important Step
Because you only want parsing work to run in the high-priority parsing-only workload, and you are using wild card WHO criteria, an important second step needs to be taken so you can prevent AMP work from running there. You must put in dummy secondary classification for that parsing-only workload so that no query will ever successfully map to the parsing-only workload for its AMP work.
For example, you could create a special dummy table just for this purpose that you are confident no one actually accesses. Then specify that table in the parsing workload’s secondary classification criteria. Or you could setup multiple criteria that are contradictory and therefore highly unlikely to ever be represented together in a query. For example, you could add query characteristic criteria that mandates that only single/few AMP queries will run in the workload, and at the same time include very large estimates, as shown in the following example.
You could consider placing this parsing workload on the SLES11 Tactical Tier, but be very careful in doing that. If some of the parsing activity consumes more than 2 CPU seconds per node, the parsing task risks being demoted to a lower priority workload due to the automatic tactical exception. If you wish parsing to take place at a tactical priority, consider increasing the CPU threshold for demotion in the parsing-only workload’s tactical exception definition, so that it accomodates max expected parser CPU times.
Conclusion
Establishing a parsing-only workload is not going to reduce the resources required to do parsing. If the plan is complex or many decisions have to be made by the optimizer in producing the plan, the same number of CPU seconds will be required to accomplish parsing. However, a high priority parsing-only workload may speed up the time to do that parsing when the system is busy, because parsing is running at a higher priority.
Of course, as is true with all workload management decisions, you need to examine the tradeoffs involved. When you increase the priority of one type of work, by definition you reduce the priority of some other work. So make sure you are keeping an eye on the overall balance of priorities on your platform. As a result, you may want to only apply this parsing-only workload technique to just a critical set of queries, rather than all active queries.