Customers also create exceptions on the Short and Medium workloads so that longer-running requests move to a lower-priority workload.
Another way to prioritize shorter requests is to enable the Timeshare Decay option. This option decreases the resources available to longer-running requests. This option applies to all requests running in the Timeshare tier; it does not apply to workloads in the Tactical or SLG tiers. TIWM does not include exceptions, but DBAs can use the Timeshare Decay option to provide similar functions in demoting requests.
- A request starts with the resource access rate assigned to it based on workload and workload management method (tier).
- TASM halves the resources available to the request on that node after the request consumes 10 seconds of CPU or 100 MB of I/O on that node.
- TASM again halves the resources available to the request on that node after the request consumes 200 seconds of CPU or 10,000 MB of I/O on that node. This access rate remains constant until the request ends.
- All Timeshare tier workloads are affected. TASM cannot target decay to specific workloads.
- The thresholds that trigger decay are the same for all workloads in all access levels. Top is treated the same as Low.
- If many Low requests experience decay, they may receive so few resources that they hold locks and AMP worker tasks for unreasonably long times.
- If most of the requests in Timeshare experience automatic decay, most of the requests have the same relative priority to each other as they did before the decay was applied.
If you enable query logging, the level of decay for a request is logged in the CPUDecayLevel and IODecayLevel fields of DBQLogTbl.