Oracle workloads do not need to be run at a high priority. A priority setting roughly equivalent to that used for TSO should provide good results. The exception to this is the TNS listener, which must be mapped to one of the highest priority groups.

If the priority of the Oracle workloads is set too high, then the system may well do more work than it needs (flushing modified buffers immediately after they are written for instance).

If the priority of the Oracle workloads is set too low (equivalent to, or less than batch) then serious consequences could arise. z/OS includes a ruthless 'pre-emptive resume' scheduling mechanism. This means that, if a higher priority workload becomes computable, it will pre-empt (or suspend) any lower priority workload, and take control of the CPU. In the very simplest terms, this means that lower priority workloads get resources only when higher priority workloads can't use them.

If the Oracle priority is too low, then the background tasks may not be activated sufficiently frequently, this could cause the buffer pool to fill with modified blocks and user processes would have to wait until Oracle was dispatched again to write out some database blocks. Even worse, an Oracle instance could lose control of the CPU whilst holding a lock or latch; this resource would then be unavailable until the instance was re-dispatched.

You can check the outcome of changes to your priority strategies quickly and easily with good Capacity Planning software. For a more complete explanation of the steps involved when using an analytical modeling product such as Metron's Athene, please e-mail the message title 'Oracle Priorities' to techinfo@metron.co.uk Further information on Oracle running under z/OS is available from the technical papers section