|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. (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.