After one or more workloads are defined in the initial phase using first level of parameters (Account, Applications, User and Profiles), the Candidate Workloads Tree on the left pane is refreshed with the initial set of workloads.
Teradata WA provides the capability to continuously drill-down on a workload with various “Who”, “What”, “Where” and “Exceptions” parameters (see Supported Analysis Parameters for a list of parameters). It can visualize distinct clusters of requests within the workload, each with distinct service time patterns and other characteristics.
For example, an initial workload defined on just the Account parameter may include distinct users who execute tactical requests requiring higher priority, while the remaining users do not. Teradata WA helps the DBA identify these clusters by providing reports, correlation graphs and distribution graphs (with parameters such as CPU, Response Time, Estimated Processing Time, for example) on different dimensions.
Analysis of an individual workload is initiated by selecting the Analyze Workload option on the Workload Report shortcut menu (see the table in Analyzing Workloads Based On “Who” Parameters) or by clicking Analyze under the workload to be analyzed in the Candidate Workloads Tree. To further refine the initial set of workloads into one or more additional workloads, Teradata WA uses DBQL data for workload analysis.
Theoretically, a workload can be subclassified further into multiple workloads through additional classification criterion. Subclassification on any and all possible classification criterion may be confusing and result in many unnecessary workloads. Considering the operational performance points, there is a maximum limit on the number of workloads for a database.
Teradata WA guides the DBA towards the appropriate classification criterion. At any given point in the analysis, the DBA is allowed to choose correlation and distribution parameters in the drop-down list, and analyze the associated usage patterns. The DBA could drill deeper in analysis within a chosen cluster, or re-analyze by choosing different correlation and distribution parameters. Through trial-and-error and visualization, the DBA decides which parameters identify the ideal request group to isolate the most effectively. This trial-and-error process is streamlined by providing the DBA with distinct count and distribution range insight without having to click Analyze Workload. This time saving process eliminates unproductive visualizations on a single user, or a tight distribution, for example.
The figure shows the overall flow of workload analysis with deeper drill-down and refinement.
