The UGA contains cursors, session state info, etc. The PGA contains sort area, hash area, bitmap merge area, read buffers for direct-path, etc.
on 6/3/03 4:39 AM, Mladen Gogala at [EMAIL PROTECTED] wrote: > 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] >>> >>> >>> -----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 <[EMAIL PROTECTED]> >>>> Date: 2003/06/02 Mon PM 03:39:42 EDT >>>> To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >>>> 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. >>>> [EMAIL PROTECTED] >>>> >>>> >>>> -----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: <[EMAIL PROTECTED] >>>> INET: [EMAIL PROTECTED] >>>> >>>> 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] >>>> >>>> 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] >> >> 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
