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