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 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/03/2003 08:49 AM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] -----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 <[EMAIL PROTECTED]> > Date: 2003/06/03 Tue AM 07:39:41 EDT > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > 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 [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). > > > > -- > Mladen Gogala > Oracle DBA > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Mladen Gogala > 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: <[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: 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).