Examples: System Filters - Advanced SQL Engine - Teradata Workload Management

Teradata Vantage™ - Workload Management User Guide

Product
Advanced SQL Engine
Teradata Workload Management
Release Number
17.05
17.00
Published
June 2020
Language
English (United States)
Last Update
2021-01-22
dita:mapPath
nbl1556236178169.ditamap
dita:ditavalPath
lze1555437562152.ditaval
dita:id
B035-1197
lifecycle
previous
Product Category
Software
Teradata Vantage
The following examples show cases in which system filters are useful.
Problem Reason for Filtering out the Request
A request accesses a large, detailed table using an unconstrained product join. A request with no join constraints against a large table is poorly written and uses too many resources. A DBA will have to abort this type of request anyway. Rejecting the request before it runs prevents resources from being wasted on a request that will never finish.
A request uses a full-table scan on very large, detailed data tables, such as call detail data or deep history data, and on Native Object Store tables. Requests that use indexed access would still be allowed to run. Full-table scans on very large tables could prohibitively impact other users, particularly at peak processing times. If such access is appropriate for a small group of users, a DBA can create a filter that excludes those users. If this type of filter were active only during normal daytime hours, batch reports or maintenance jobs could execute without issues during off-hours.
Maintenance activity requires that all users log off the system, while requests in progress be allowed to complete. New requests must be prevented from running. After the maintenance work is done, the DBA can disable the filter.

The preceding examples show system-wide filters, in which all requests are candidates. However, you could simulate a filter at the workload level. For example, if you want to reject all queries submitted to WD-B while in the CriticalFocus state, set a workload throttle using the “Reject” option.