The workload analysis process consists of the following steps:
1 The user may optionally migrate existing priority scheduler definitions (PDSets1 created using PSA release 13.00 or earlier), to automatically create workload definitions with existing priority scheduler settings. (PSA has been discontinued for TMGR release 13.10.) If users choose not to migrate existing settings, they can instead choose to define up to 250 workload definitions from scratch. In so doing, users first collect query log information for the existing workload mix. Then they specify the dimensions to analyze and group queries against to form candidate workloads (account-based, application-based, and existing PDSets) and the date and time range over which to analyze the previously collected query log data.
2 Using this input, Teradata WA recommends candidate workload definitions based on analysis of Priority Scheduler settings, Database Query Log data, or both.
3 With the DBQL analysis path, the user can further refine the candidate workload definition and the queries in which it contains by either merging with another candidate workload or splitting the candidate workload into two or more separate candidate workloads to aid with accounting granularity or workload control. (For example, tactical queries need higher priority and therefore are split out from the “parent” candidate workload.) Next, users creating workload definitions from scratch (not for users migrating from existing priority scheduler settings) are guided through mapping workload definitions to priority scheduler allocation groups and allocation group weights. Those settings are guided to minimize necessary DBA involvement, though the DBA has the “advanced” option to refine those settings according to the administrator’s preference.
Note: A workload definition is mapped one-to-one to a priority scheduler performance group (PG). The priority scheduler for Teradata Release 13.10 allows 250 PGs to be defined. Four of these are reserved to be the standard PGs (R, H, M, and L) in the default resource partition. That leaves 246 PGs for use by Teradata DWM.
4 After the user has satisfactorily fine-tuned the candidate workload definition, the user sets service-level goals, optionally guided by Teradata WA. For example, the user might request recommendations based on actual response times achieved at a particular service-level percent, or other factors.
These paths are graphically displayed in Figure 2.Figure 2: Paths to Creating a Workload Rule Set