Re: shared_pool_size v/s large_pool_size

in addition to RMAN, the large_pool (when enabled) is used for:

• UGA memory for MTS
• multiple DB writer slaves
• parallel query execution buffers (when PARALLEL_AUTOMATIC_TUNING=TRUE)

as Howard said, none of these "require" the large_pool to be enabled, but if it isn't the memory required for these processes will be taken from the shared_pool, and may cause contention with your normal SQL operations.

HTH,
Roy

In article <3940522f_at_news.iprimus.com.au>,   "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
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Fri Jun 09 2000 - 00:00:00 CDT