Users of the database are not the same; the database manager is not like a database user who performs one or two operations in a day on the database.

The accountant who deals with customers from early morning until three in the afternoon differs from the financial manager who needs reports at the end of the workday.

From here, the need arose for an equitable allocation of resources; particularly if resources are limited and users are many.

Let’s assume this scenario where you are the manager of a bank's database. This bank has a group of tellers who serve customers from eight in the morning until two in the afternoon.

Let’s assume that their number is one hundred tellers, and there are thousands of customers wanting to exchange currency and withdraw their funds. If the system is slow and cannot handle this number of tellers due to the congestion from other departments’ managers flooding the system since morning to extract reports that can be postponed to the end of the workday, if the situation is thus, the result will be catastrophic and most of these customers will switch to other banks that provide them with better service. In contrast, if you had managed the available resources well, you would have lost only one client who laments their luck that brought them to this bank.

In general, we will continue the explanation in this chapter, carrying the meaning of this scenario, which involves a bank with a number of tellers and numerous managers and database managers.

The truth is that users of the database are divided into several groups called Resource Manager consumer groups.

There are a number of plans to work with these consumer groups called Resource Manager plans. There will be one active plan in the database at any given moment.

This plan is identified by the variable RESOURCE_MANAGER_PLAN, and by default, this variable takes the value NULL.

Starting from version Oracle 8i, the resource management system began to be used, and the initial setup for the Resource Manager has been in place since the database was created.

However, this setup remains ineffective in actual practice.

Consumer Groups:

These refer to a group that includes several users who share similar resource requirements. A single user can be a member of more than one group, but at any given moment (i.e., session), they can only be active in one group. When the user session is created, they are actively a member of the original group.

However, if this user is a member of several other groups, they can switch to another group, meaning they can be actively a member of another group.

Of course, they cannot be actively a member of more than one group at the same moment.

In the previous scenario, the tellers group at the bank belongs to one consumer group called Teller, while the managers belong to another consumer group called Manager.

Generally, at the moment the database is created, a number of groups are established.

SELECT CONSUMER_GROUP FROM DBA_RSRC_CONSUMER_GROUPS;

1- SYS_GROUP: Under normal circumstances, this group is for database administrators, specifically the root. This group includes only the users SYS and SYSTEM.

SELECT USERNAME,INITIAL_RSRC_CONSUMER_GROUP FROM DBA_USERS WHERE USERNAME IN ('SYS','SYSTEM');

2- DEFAULT_CONSUMER_GROUP: This group includes all users who have not been assigned a specific group. Essentially, this group encompasses all database users except for the users SYS and SYSTEM.

SELECT USERNAME,INITIAL_RSRC_CONSUMER_GROUP FROM DBA_USERS WHERE USERNAME NOT IN ('SYS','SYSTEM');

3- OTHER_GROUPS: All users who are members of this group use it when the connected user is part of a group not included in the current active Resource Manager Plan.

4- LOW_GROUP: This group is designated for sessions with lower priority.

5- AUTO_TASK_CONSUMER_GROUP: This group is dedicated for the usage of system maintenance jobs.