Re: Re: question about large pool (now NetApp)

thanks for your excellent responses. I guess striping doesnt help with netapps.

I was finding alot of waits for redo logs, full table scans, and index reads. However, I guess I have to live with it with the netapps. I believe we have a 1GB pipe. Does it matter if I put my indexes in seperate datafiles from my tables with a netapp configuration?
> > From: "Binley Lim" <Binley.Lim_at_xtra.co.nz>> Date: 2003/06/04 Wed AM 07:49:39 EDT> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>> Subject: Re: question about large pool (now NetApp)> > For NetApp, the key thing is the number, and speed (100Mbit or 1Gbit?), of> network I/O cards connecting to the NFS server. Mount points are irrelevant> as they could all be going over the same I/O channel.> > There is a NetApp performance paper that recommends a number of things to> tweak for performance, including using multiple IO slaves/DBWRs, rather than> asynch_io. Check with your vendor. However, it comes with a disclaimer - do> your own tests as it may not apply. I ended up using asynch_io as there was> a 10-15% improvement over multiple slaves. In the scheme of things, this is> a minor issue.> > Things that you normally spend a lot of time on like striping and> distributing IO are no longer meaningful. After all, you bought a storage> server to take care of such things for you. What will kill you are the> things you never have to worry about in a DAS configuration. Like:> > - CPU utilisation will increase significantly, used for shuffling blocks> over the network.> - test your NFS mount options, especially rsize and wsize.> - adjust your OS kernel parameters, including NFS parameters> - make sure your OS and especially NFS, patches are up to date> - tweak the network interface (ndd command)> > Some other things that cannot be changed in a hurry:> > - mount as UDP rather than TCP if you have a dedicated segment for NFS> traffic. Trying to share the company-wide network for this is a particularly> bad idea. Chances are you will back it out in a hurry.> - a later version of OS is much better than an earlier version, eg Solaris> 2.8/9 over 2.6. Apparently significant improvements have been made in the> TCP/NFS components of the OS.> - if you have later version of OS, look at configuring for Ethernet Jumbo> Frames.> - if the hardware/software is capable, and you have more than 1 network> card, look at IP trunking.> - if you have older hardware in the DB server, you will run into limits like> Sun's SBUS max IO of ~40MB/s. If your requirements are below this, great.> > Sounds like sysadm type of issues? Yes, it does. If your sysadm (or boss)> is good enough to take care of all of these for you, great. In practise, I> find that seldom happens.> > ----- Original Message -----> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>> Sent: Wednesday, June 04, 2003 1:01 AM> > > > 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.> > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net> -- > Author: Binley Lim> INET: Binley.Lim_at_xtra.co.nz> > 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).