|Request Source||Request source comes from one of the following:
If a TASM rule contains multiple criteria of the same request source type (such as multiple users and multiple accounts), then only one of the types defined in the rule needs to match the attributes of the current request for the request to qualify for the rule. If the rule contains criteria of different request source types, then the attributes of the current request must match one of each of the types defined in the rule to qualify for the rule.
If a user and a profile are defined, you can select whether to AND or OR the user and profile criteria for the rule, since profiles are a collection of users.
|Request Target||Which database objects the request operates on and which type of step applies to that object:
In order for stored procedure requests to qualify for any rule, the rule must have stored procedure inclusion criteria. If a rule does not have stored procedure inclusion criteria, stored procedures do not qualify for that rule.
For the purpose of classification, all target objects are considered to be of the same type and will be OR'd together (except for a QueryGrid server, which is treated as a unique DBS object type).
|Query characteristics||Processing details:
|Utility criteria||Which utility issues the request. This criterion is not available for system throttles.|
The originating application may assign query band name/value pairs to a request. Use of the query band enables requests from a common logon to be classified into different workloads.
Adding More Specific Criteria for Request Targets
- Selecting or editing the Target criteria. An Edit Target Criteria dialogue box appears.
- Selecting the pencil icon in the Selected: area. An Edit Criteria dialogue box appears, where you can add more specific classification criteria.
- In one step, a small table will require a join.
- In another step, there is no join, but a large table will generate many rows.
- The large table
- Any joins
- Step row count
If you want TASM to detect if the large table returned many step rows AND was joined, the preceding request should not qualify for the rule, yet it may be a false positive. The only way to get the functionality you want is to specify Any Join and Estimated Step Row Count as more specific criteria for the large table. This means that you want both the join and the step row count to occur in any step in a request that operates on the large table.
- Full Table Scan (Include or Exclude)
- Join Type (all or no joins, all or no product joins, all or no unconstrained product joins)
- Estimated Step Row Count (above or below a specified number)
- Estimated Step Processing Time (above or below a specified number)
- Estimated percent of table blocks accessed during the query (greater than or equal to a specified percentage); this is the percentage of the table the request is expected to access
- Only statements of the following type:(DDL, DML, Select)
The following figure is an example of the Edit Target Criteria screen. To add more specific classification criteria to the inventory table, you would select the pencil icon in the Selected: area next to lumber.inventory.