Well, I was talking about cursors, sort areas and hash areas. I probably
did confuse "GA stuff".
On 2003.06.02 22:27 Tim Gorman wrote:
> Almost. It is the UGA areas (not the PGA) for Shared Server (a.k.a.
> multi-threaded server) that are re-located to the Large Pool, if it exists.
> Otherwise, they reside in the Shared Pool and all hell breaks loose,
> performance wise...
>
> Also, if DBWR_IO_SLAVES > 0, then those IPC queues will reside in the Large
> Pool, if it is configured. Otherwise, these reside in the Shared Pool, and
> if you think having UGAs from Shared Server in the Shared Pool play hell
> with performance, then wait until you are pushing all of your I/O to the
> datafiles through the Shared Pool... :-)
>
>
>
> on 6/2/03 2:24 PM, Gogala, Mladen at MGogala_at_oxhp.com wrote:
>
> > Nope, it's not accurate. PGA areas for shared server sessions are also
> > allocated from the large pool.
> >
> > Mladen Gogala
> > Oracle DBA
> > Phone:(203) 459-6855
> > Email:mgogala_at_oxhp.com
> >
> >
> > -----Original Message-----
> > Sent: Monday, June 02, 2003 4:35 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > for some reason we have 100MB large pool. I dont think we need it at all. I
> > read that its only used by RMAN or Parallel server. Is that accurate?
> >>
> >> From: DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
> >> Date: 2003/06/02 Mon PM 03:39:42 EDT
> >> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> >> Subject: RE: question about large pool
> >>
> >> Use the large pool to store what? I can think of 3 aspects of a
> > transaction:
> >> - Rollback (you've probably read about SET TRANSACTION)
> >> - SQL statements, execution plans (more an issue with bind variables)
> >> - Data blocks
> >> It sounds like you might be thinking of data blocks. You didn't mention
> > your
> >> Oracle version, but from 8i on you can define 3 buffer pools. The normal
> > one
> >> is DEFAULT. You can also define a KEEP and RECYCLE pool. Someone on this
> >> list (sorry I can't recall who) pointed out that there isn't anything
> > magic
> >> about those labels. If your transaction uses different tables from the
> > other
> >> transactions, you could create what is needed for those tables in one of
> >> those pools, assign the tables to that pool, and this would minimize the
> >> interference. If all the transactions hit pretty much the same tables,
> > then
> >> Oracle is probably reusing the blocks anyway. Hope this responds to your
> >> question.
> >>
> >> Dennis Williams
> >> DBA, 80%OCP, 100% DBA
> >> Lifetouch, Inc.
> >> dwilliams_at_lifetouch.com
> >>
> >>
> >> -----Original Message-----
> >> Sent: Monday, June 02, 2003 1:40 PM
> >> To: Multiple recipients of list ORACLE-L
> >>
> >>
> >> I think I read this somewhere, but I cant find it. Is it possible to use
> > the
> >> large pool for a specific transaction? We run alot of large batch DML
> >> statements over night. We have one that involves an 8GB table. The blocks
> >> from this table are being knocked out of the buffer cache by shorter and
> >> quicker batches.
> >>
> >> Id like to find to store this transaction in memory without having to
> > worry
> >> about them getting knocked out of memory.
> >> Cache wont do it. It will stick get pushed out.
> >>
> >> --
> >> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> >> --
> >> Author: <rgaffuri_at_cox.net
> >> INET: rgaffuri_at_cox.net
> >>
> >> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> >> San Diego, California -- Mailing list and web hosting services
> >> ---------------------------------------------------------------------
> >> To REMOVE yourself from this mailing list, send an E-Mail message
> >> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> >> the message BODY, include a line containing: UNSUB ORACLE-L
> >> (or the name of mailing list you want to be removed from). You may
> >> also send the HELP command for other information (like subscribing).
> >> --
> >> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> >> --
> >> Author: DENNIS WILLIAMS
> >> INET: DWILLIAMS_at_LIFETOUCH.COM
> >>
> >> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> >> San Diego, California -- Mailing list and web hosting services
> >> ---------------------------------------------------------------------
> >> To REMOVE yourself from this mailing list, send an E-Mail message
> >> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> >> the message BODY, include a line containing: UNSUB ORACLE-L
> >> (or the name of mailing list you want to be removed from). You may
> >> also send the HELP command for other information (like subscribing).
> >>
> >>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Tim Gorman
> INET: tim_at_sagelogix.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>
--
Mladen Gogala
Oracle DBA
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Mladen Gogala
INET: mgogala_at_adelphia.net
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Tue Jun 03 2003 - 06:39:41 CDT
