Re: RE: question about large pool

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: <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).