UGA versus PGA

From Robs_Wiki
Jump to: navigation, search

So a connection a made when a client process sends a request to the server process and server process reverts back in establishing the session. But this happens in Dedicated Server Processes where each every user process has it's own dedicated server process attached to it and serving it's requests. In case of Shared Server Process, we have dispatchers and they take the User process requests, put them in a queue and from there, they are managed by shared server process. The number of Dispatcher and Shared Server processes can be managed by database parameters DISPATCHERS, MAX_DISPATCHERS, SHARED_SERVERS, MAX_SHARED_SERVERS.

In case of Dedicated Server Processes, all the session activity status is completely managed in PGA only i.e. Sessions PGA keeps track of the state of that Session and the order in which the queries are getting run the same. In case of Shared Server Processes, that information gets stored in SGA and that memory part of SGA is known as UGA (User Global Area). Why store in SGA? Since the dispatchers put all the requests from different sessions in a single COMMOM QUEUE from where shared processes picks them one by one (without knowing to which sessions it belong to), executes it and put the fetched data in a separate RESPONSE QUEUE which is different for every DISPATCHER process. The Shared Server Process doesn't directly contact with User Processes and hence it becomes impossible for them to keep the track of Sessions. That's why this information in stored in SGA in the form of UGA from where it becomes easier to track the State of the Sessions.