Oracle9i Database Administrator's Guide
Release 2 (9.2)
Part Number A96521-01

What Is the Database Resource Manager?
The main goal of the Database Resource Manager is to give the Oracle database server more control over resource management decisions, thus circumventing problems resulting from inefficient operating system management.

This section contains the following topics:

What Problems Does the Database Resource Manager Address?
How Does the Database Resource Manager Address These Problems?
What are the Elements of the Database Resource Manager?
Understanding Resource Plans
What Problems Does the Database Resource Manager Address?
When database resource allocation decisions are left to the operating system, you may encounter the following problems:

Excessive overhead

Excessive overhead results from operating system context switching between Oracle server processes when the number of server processes is high.

Inefficient scheduling

The operating system deschedules Oracle database servers while they hold latches, which is inefficient.

Inappropriate allocation of resources

The operating system distributes resources equally among all active processes and is unable to prioritize one task over another.

Inability to manage database-specific resources, such as parallel execution servers and active sessions
How Does the Database Resource Manager Address These Problems?
Oracle's Database Resource Manager helps to overcome these problems by allowing the database more control over how machine resources are allocated.

Specifically, using the Database Resource Manager, you can:

Guarantee certain users a minimum amount of processing resources regardless of the load on the system and the number of users
Distribute available processing resources by allocating percentages of CPU time to different users and applications. In a data warehouse, a higher percentage may be given to ROLAP (relational on-line analytical processing) applications than to batch jobs.
Limit the degree of parallelism of any operation performed by members of a group of users
Create an active session pool. This pool consists of a specified maximum number of user sessions allowed to be concurrently active within a group of users. Additional sessions beyond the maximum are queued for execution, but you can specify a timeout period, after which queued jobs will abort.
Allow automatic switching of users from one group to another group based on administrator defined criteria. If a member of a particular group of users creates a session that executes for longer than a specified amount of time, that session can be automatically switched to another group of users with different resource requirements.
Prevent the execution of operations that are estimated to run for a longer time than a predefined limit
Create an undo pool. This pool consists of the amount of undo space that can be consumed in by a group of users.
Configure an instance to use a particular method of allocating resources. You can dynamically change the method, for example, from a daytime setup to a nighttime setup, without having to shut down and restart the instance.

killed None0Если уж у кого и буду спрашивать, то у вас, Киллед, последнего. Вы конечно мужик в "афторитете", но, сдается, с документацией и практикой дружили давно. Ваши теоретические изыскания мне не интересны. Удачи!

Вам бы подумать, как будете рулить приоритетами процессов со стороны ОС , когда Оракл работает в режиме shared server'a. А потом уже про практику, афторитет и прочее.

Оracle не рулит пользовательскими серверными процессами ну просто никак и в доке строго настрого запрещает вмешиваться со стороны ОС в это дело.

None0Да, верно. В shared моде никак.
Но для этого есть Аппликэйшн Сервер. Вот пусть он и тромбует большое кол-во запросов пользователей в маленькое кол-во сессий.
А кстате, комуто известна статистика насколько shared <, > dedicated?

Для трамбовки есть еще Connection Manager