Re: shared_pool_size v/s large_pool_size

Hello Gunjeet and Howard,

Other than the use of the large pool by RMAN, it is used for most of the session memory for MTS sessions, if it exists. It is strongly recommended (by me at least) that you use a large pool if you are running MTS. Have a look at the 'session uga memory max' statistic in v$sysstat to get a feel for how big your large pool might need to be. The shared pool can be reduced accordingly.

Regards,
Steve Adams

http://www.ixora.com.au/
http://www.oreilly.com/catalog/orinternals/
http://www.christianity.net.au/

On Fri, 09 Jun 2000 02:10:56 GMT, "Howard J. Rogers" <howardjr_at_www.com> wrote:

>
>"Gunjeet Singh" <gunjeet.singh_at_corp.sun.com> wrote in message
>news:394045D3.716C210F_at_corp.sun.com...
>>
>> Hi,
>>
>> Could someone please explain the use of the new Oracle8 init parameter
>> "large_pool_size" ? How is it related to
>> shared_pool_size ?
>>
>> We are using MTS mode for Oracle 8.1.6.
>
>The large poool size parameter sets a memory space which RMAN will use when
>it does its backup and recovery stuff. If you don't plan on using RMAN, you
>don't need a large pool. Even if you *do* plan on using RMAN, you can get
>away without using a large pool -in such cases, RMAN pinches whatever it
>needs by way of memory out of the shared pool. Not exactly the most
>performance-enhancing response, but it will still do its stuff.
>
>So the short answer to your question is: 'It's not (related to
>shared_pool_size)'. However, use of RMAN without a large pool will mean
>that you end up eating large portions of your shared pool that should
>otherwise be used for Libray and Data Dictionary Cache functions.
>
>If you are going to use RMAN, you'd be mad NOT to set a large pool size, on
>the grounds that backups and recoveries will then cripple the rest of your
>system (by causing, amongst other things, parsed SQL statements to drop out
>of a shrunken library cache). If you are not going to use it, then don't
>bother with a large pool.
>
>HJR
>
>
>>
>> Thanks,
>>
>> Gunjeet
>
>
Received on Fri Jun 09 2000 - 00:00:00 CDT