Think about the priority part of workload management for a minute.

The settings that the administrator makes when defining priorities for different workloads are on the surface--things like workload allocation percentages and access level assignments.  They are easy to see.  Below the surface are “global weights”, which starting in Teradata Database 14.10 indicate to you the actual percentage of platform resources your workload will receive, based on its allocation.

But they do more than translate your settings to an expected resource share.  Global weights are used by the database to order the queues for several internal entities.  For example, the AMP worker task (AWT) message queue is now ordered by global weight in SLES 11. 

So it’s time you spent a few minutes taking a closer look at what global weights are, how the SLES 11 priority scheduler calculates them, and how you can influence them.

Tactical Tier is Excluded

The first thing to recognize about global weights is that they are only given to workloads on SLG Tiers or Timeshare.  Workloads placed on the tactical tier do not carry a global weight. Tactical workloads are always considered the highest priority work and are placed above, and outside of global weight calculations which are applied only to other workoads lower in the hierarchy.

In addition to not being assigned a global weight, tactical workloads are ignored when it comes to calculating global weights for non-tactical workloads.   Global weight calculations described below assume that tactical workloads, if they exist, are not consuming anything.

But, if global weights are used for ordering internal queues (such as the AWT message queue), how do tasks from tactical requests get queued up if they do not have a global weight? 

Tactical requests are always expedited, which means their tasks will have a higher message work type (Work08/09) compared to tasks coming from non-expedited work (Work00/01).  Message work type is the primary sorting order for the AMP worker task message queue, global weight is secondary.  So tactical tasks will never compete against Timeshare or SLG Tier work for the next available AWT.  Expedited requests are also given priority over other requests within the other internal queues.  Tactical will always go to the front of the queue.

If for some reason that there is competition among tactical tasks for an internal resource, all tactical tasks across all virtual partitions (no matter what the virtual partition allocation) are treated equally, first in first out.  Global weight will not be a factor.

SLG Tier Global Weights

For sites utilizing full TASM, understanding the impact of giving, say, a 10% allocation to a workload on an SLG Tier is not always straightforward.  That setting might mean you actually can expect to receive 10% of platform resources, or it might not.  Confusion about what you will actually get is because an SLG Tier workload allocation represents a percent of the resources that flow into the tier.  What will flow into the tier depends on the level of resources being used above that workload in the tier.

Global weights are theoretical numbers.  They represent what a workload will receive with the assumption that there is no tactical work active, no work running outside of the database, and all workloads are active and using exactly what their allocation entitles them to.  In the real world, this is unlikely to happen.  Global weights are artificial constructs that express priority definition differences at the global level.  But they are a good indicator of how resources will by physically divided in your database.

You can calculate the global weight of an SLG Tier workload yourself if you don’t mind some simple math.  Just multiply the allocation percent of the workload by the allocations of all the parents above the workload in the SLES 11 priority hierarchy.


In the example above, the administrator has selected 40% as the allocation to be given to this workload referred to as “Child” when he defines the workload in Viewpoint Workload Designer.  That represents 40% of the resources that flow to the tier.  In order to calculate global weight, he needs to know how much of the platform resources will theoretically flow into this tier.  That is done by multiplying the workload’s allocation by the allocations of all parents above the workload in the hierarchy.

This is done for you in Viewpoint 15.0 Workload Designer portlet in the System Workload Report screen, as shown below.



The “% of System” column above represents the global weight of each SLG Tier workload.  In a later release of Viewpoint, Timeshare workload global weights will be included in the System Workload Report.  Currently, a single “Timeshare” row will show up in the bottom, one per virtual partition, to tell you how much global weight will be sent down to Timeshare.

Timeshare Global Weight

As mentioned, the System Workload Report will currently show you the percent of resources that flow into Timeshare as a sort of aggregate Timeshare global weight.  It doesn’t indicate to you how Timeshare will divide up that global weight among the workloads assigned there.

While the System Workload Report screen shown above will include that detail at a future time, it may benefit you to know your Timeshare global weights now.   What if some of your Timeshare workloads ended up with global weights higher than some of your SLG Tier workloads?  During the times you were out of AWTs on an AMP, work messages from those Timeshare workloads would be queued up higher, and be able to get an AWT ahead of similar work messages from all workloads with lower global weights, including SLG Tier workloads.  For most sites, that is not a  desirable situation.

For that reason, it is important to take the time to assess you Timeshare global weights, even if it involves a little mathematics.  And then make some changes to your setup to ensure higher priority work is not sorting below lower priority work in cases such as this.

Calculating Timeshare Global Weight

Here is a screen shot of a simple spreadsheet I put together to calculate global weight within one virtual partition.  I will describe the steps I took so you can create your own, similar spreadsheet if you wish, or just do the calculations by hand.

You need three pieces of input in order to calculate Timeshare global weights:

  1. The aggregate global weight that will flow down to Timeshare--the “(Timeshare)” entry in the System Workload Report shown above
  2. The Timeshare access rates (fixed at 8, 4, 2, 1)
  3. The number of workloads assigned to each Timeshare access level in your setup (look at the Workload Distribution Screen and you can easily add them up )

My spreadsheet looks like this:




Here is a step-by-step explanation of what the spreadsheet does:

  1. On the row labeled 1, enter the number of workloads defined on each Timeshare access level, and the Lowest SLG Tier Remaining Global Weight, as found in the System Workload Report in Viewpoint Workload Designer
  2. The row labeled 2 expresses the fixed access rates associated with each access level
  3. The values in Row 3 represent Row 1 (the number of workloads) * Row 2 (access level of the workload)
  4. Row 4 has a single entry under the column “Sum” which represents the sum of the four values calculated in Row 3
  5. Values in Row 5 are calculated by taking the values in Row 3 and dividing each by the Sum value in Row 4 (they should end up summing to 100%)
  6. Values in Row 6 are calculated by taking the values in Row 5 and multiply them by the “Lowest SLG Tier Remaining Global Weight” value in Row 1 (after the calculation they should sum up to Lowest Remaining value in Row 1)
  7. Convert the values calculated in Step 7 into percentages in order to get the global weights for the workloads in each Timeshare access level

Note:  All the workloads within the same Timeshare access level will carry the same global weight. Expected concurrency levels within each access level are not a factor in determining global weight.

Here is a copy of the Timeshare global weight spreadsheet shown above.




Once you have calculated or have access to the global weights for both SLG Tier workloads and Timeshare workloads, you can compare them and make sure that all SLG Tier workloads have larger global weights than all Timeshare workloads.   If not, adjust up the allocation percentages of those SLG Tier workloads so that their global weights are above those of Timeshare workloads.   This makes sure that SLG Tier workloads will always receive internal resources, such as AWTs, ahead of Timeshare workloads.

You might also consider increasing the allocation percentages of some SLG Tier workloads, if important, high priority work runs there, yet their global weights are lower than other, less critical SLG Tier workload global weights.    This will ensure that they sort higher in the various internal DBS queues when the system is busy, and give them an additional boost in access to CPU.


Here’s an example of how global weights might look for three SLG Tiers and four Timeshare access level workloads.  There is a single Timeshare Top workload, and two workloads in each of the other three access levels. This matches the Timeshare global weight spreadsheet numbers presented above.


Note that on SLG Tier 1 the workloads’ global weights are equal to their tier allocation percentages.  This is because global weight does not account for any tactical work, and in this example there is only a single virtual partition, and no WM COD in place.   If either the owning virtual partition allocation or WM COD is set at < 100%,  global weights for all SLG Tier workloads, including SLG Tier 1, will be reduced.  Both virtual partitions and the Tdat control group (where WM COD is set) are higher in the hierarchy than the SLG Tiers, and because they represent parent higher in the hierarchy, their allocations must be factored into global weight calculations if both or either are set at less than 100%.

With the setup shown above, MktgQry, which is on SLG Tier 3, has a global weight of 13%.  This gives MktgQry requests greater access to resources than requests coming from WebApps1 and WebApps2 on SLG Tier 1, which both have global weights of 10%.  In addition, messages from MktgQry requests will queue in the AMP worker task message queue up ahead of requests from those two SLG Tier 1 workloads, since they both have a slightly lower global weight.   Generally-speaking, it is recommended that you set workload allocations so that workloads on higher tiers have greater priority (and higher global weights) than those on lower tiers.  Comparing global weights gives you a mechanism for fine-tuning your workloads.


Global weights are the theoretical level of resources that each workload in a SLES 11 hierarchy will be offered.  Only the priority definitions as entered into Viewpoint Workload Designer are used to calculate global weight.  It is a persistent value that does not change based on run time characteristics or activity levels in the database.

Some important internal DBS queues are ordered by global weight.  For that reason, it is useful to understand, examine and compare these global weights as part of regular workload management reviews. In addition, global weights can be handy way to understand how the division of resources on your platform are being divided across your workloads.  This can be especially useful the more complex the setup has become, and the greater the number of virtual partitions being supported.  Some of the suggestions in this posting may be helpful in both monitoring and tuning your workload management setup.


Note:  A new section on the Tactical Tier was added on April 28, 2015.

Sandeepyadav 27 comments Joined 09/13
20 Jul 2015

Hi Carrie,
Please help me to understand the below points.
1. We have Appliance system with SLES 11 & DB. Can we consider "Lowest SLG tire Remaining Global Wgt" as 1 (100% as This sytem does not have any SLG tire) in calculation of Timeshare Global Weight for Appliance system?
If we can consider "Lowest SLG Trie Remaing Global wgt" is 1 for Appliance then I found "LOW" Access Level has higher Global weight value then AL "HIGH" but the same query executed lilltle fast in "HIGH" AL then "LOW" (This time no other query was running in "HIGH" & "LOW" AL). HIGH AL elapsed time: 37 sec and LOW AL elaspsed Time: 40 sec.
2. According "Tactical Tire excluded" part. Tactical Queries use Worktype08/09 but by default these worktype08/09 do not have any AWTs. Then do we need to reserve AWT in SLES 11 for tactical?

Thanks, -Sandeep.

Sandeepyadav 27 comments Joined 09/13
20 Jul 2015

Hi Carrie,
Typo Mistake:   please consider "MEDIUM" AL in place of "HIGH" AL in Point 1.

Thanks, -Sandeep.

carrie 595 comments Joined 04/08
27 Jul 2015

You are correct that for the Appliance, the global weight that is available for Timeshare workloads is 1 or 100% of all global weight in the system, since there is only a single virtual partition and no SLG Tiers.
An individual workload in Timeshare Low will never have a global weight that is higher than a workload in Timeshare Medium.  The global weight of a Timeshare Medium workload will always be two times the global weight of an individual Timeshare Low workload. The Timeshare access rate factors into the calculation of global weight, and the access rate of Medium is double (2) the access rate of Low (1).  Workloads from higher access levels will always carry a higher global weight.   If you look at the Timeshare Global Weight Calculation above in the spreadsheet you will see that each Medium workload has a global weight of 0.9% and each Low workload has a global weight of 0.4% (some rounding happens).
If you have many more workloads in Low than in Medium, it is possible the sum of their individual global weights could be higher than the sum of the global weights of all workloads in Medium.   But comparing one workload in Medium against one workload in Low, Medium will always be double.
Tactical work always runs in Work08/09, on the Appliance and on the EDW platform.    You can, if you need, reserve AWTs for tactical on the Appliance, in the same way as you would on the EDW platform.
Thanks, -Carrie

Sandeepyadav 27 comments Joined 09/13
27 Jul 2015

Thanks Carrie !!

Thanks, -Sandeep.

oshun 3 comments Joined 07/10
03 Aug 2015

Hi Carrie, you mention that Tactical workload always runs in Work08/09.

Does this mean that the "EnableExpediteExp" parameter is not used anymore?

visit my private blog at

carrie 595 comments Joined 04/08
06 Aug 2015

Enable expedited express requests allows express requests to use the same higher work types as tactical requests.  But express requests will only be expedited if there are reserves set up for tatical queries, and the reserve count is 2 or greater.
If you have tactical workloads running and active in Work08/09 that does not mean that you cannot also expedite express requests.  Tactical work and express requests are two different things.   Tactical requests are user-defined queries that are very short, highly-tuned and running in the tactical tier or tactical allocation group.  Express requests are requests generated by the database during parsing, optimization, logons, and a few other places in the DBS code.  The user does not issue express requests.
Please see my blog posting on expediting express requests for more information on this.
When you expedite express requests, you are letting those requests take advantage of certain priority boosts that are usually only given to tactical queries.   But because you are running tactical queries does not mean you cannot expedite express requests, and expediting express requests does not mean you cannot run tactical queries. 
Thanks, -Carrie

You must sign in to leave a comment.