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.