| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Re: question about large pool
Jared - You are probably right. I was just making the point that all your
disk interaction is going over a network link which can be a lot more
restrictive than the normal direct attached storage we are used to. When I
see people configuring multiple DB writers I tend to think it will just help
them fill that network link to capacity that much quicker. My way of working
around the problem was to move hot files to direct attached storage.
Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Tuesday, June 03, 2003 11:56 AM
To: Multiple recipients of list ORACLE-L
I would think that the situation where multiple DB writers would be useful on a single mount point would become more and more common.
This is due to SAME. If you were to create 5 RAID 10's with 5 physical disks each, and striped a single volume across them, and you are not using async IO, you could definitely use multiple DB writers.
The question of how many would depend on your environment. ( the usual disclaimer :)
Jared
DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
Sent by: root_at_fatcity.com
06/03/2003 08:49 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: RE: Re: question about large pool
My experience with NetApp says that it is easy to clog up your bandwidth
to
the device. I would worry more about that issue and finding just how much
throughput you could get to the device. Usually the DBWR tuning is for the
situation where you have lots of devices with separate paths to those
devices.
Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Tuesday, June 03, 2003 8:02 AM
To: Multiple recipients of list ORACLE-L
you only want DBWR_IO_SLAVES or multiple DBWRn if you have datafiles
spread
over multiple I/O points correct? We are using 'Network Appliance' hard
disk
array that Im not all that familiar with. It looks like we have 3 I/O
points
and 5 mount points.
my boss told me that striping data files and redo log files across the I/O points wotn help because there is only 1-2 I/O cards(forget the exact, I hope it isnt hard for anyone to figure out what Im referring to) on the server itself.
This does not sound accurate. Since Ive read several books and all say to stripe the files?
btw, thanks for the info on the large pool. I can free up about 300MB of
memory we aer wasting on that and the java pool for other areas.
>
> From: Mladen Gogala <mgogala_at_adelphia.net>
> Date: 2003/06/03 Tue AM 07:39:41 EDT
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> Subject: Re: question about large pool
>
> 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
> > >>
-- 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: INET: Jared.Still_at_radisys.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: 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).Received on Tue Jun 03 2003 - 14:34:51 CDT
 |
 |