You many wonder why you should care about Oracle Resource Manager wait events. You should care because every Oracle 11g database uses Resource Manager by default during the maintenance windows. So, even if you have not intentionally configured RM you may see waits that start with resmgr: which are RM waits. It is helpful to understand what the two main RM waits are and what they mean.
The default maintenance windows are M-F 22:00 for four hours and 06:00 for 20 hours on the weekend. Several times we have had performance complaints and had people say that one of the main waits during the slow time was “resmgr:cpu quantum“.
The resmgr:cpu quantum wait event means that your database server’s CPU is high enough that resource manager has kicked in and is dividing up the CPU cycles among the various sessions that need it. The plan that runs by default during the maintenance window is called DEFAULT_MAINTENANCE_PLAN. This plan allocates most of the CPU resources to tasks other than the maintenance tasks. This is really a helpful feature because it prevents the maintenance tasks like gathering optimizer statistics from eating up a lot of CPU resources that are needed by user processes. But, if you have a busy system and see a bunch of resmgr:cpu quantum waits and don’t know what they are it can be disconcerting. The solution is to look at what is using so much CPU and tune that. Resource Manager actually does a great job of dialing back the CPU of the maintenance jobs so there is no need to disable it.
I’ve seen one situation where resmgr:cpu quantum indicated a real problem. The active plan had a 0% CPU allocation. In this case the session was waiting on a resmgr:cpu quantum wait but never got a CPU slice. This is essentially a hang and needs to be addressed by giving the user associated with the session a > 0% CPU allocation.
The second RM wait that I have seen is “resmgr:become active“. You will only see this wait if you have configured RM yourself to have limits on the number of active sessions. When the number of active sessions that are in a given consumer group reaches the maximum then any other sessions that want to become active will wait on resmgr:become active. I really don’t like active session limits and encourage you to carefully consider whether these limits make sense in your situation. The sessions waiting on resmgr:become active are essentially hung and eventually will timout. If you have a hang like situation and see a bunch of resmgr:become active waits then there is cause for concern and you may need to increase or eliminate your active session limits.
So, to summarize:
resmgr:cpu quantum – sessions are sharing CPU, not necessarily a problem
resmgr:become active – sessions are hung , can be a big problem
– Bobby
