Re:RE: OFA and SAN - Why not group all db files on its own m

Mike,

    SAN or no SAN, IO can become a problem. We use the EMC solution as well and I can tell you that having too few channels into the storage array is worse than didicated disk systems. How does this affect your layout, depends on what you have for load balancing software on the server. EMC sells a product called PowerPath. It's suppose to spread the io load accross all of your channels into and out of the storage array. Works pretty good, we've seen a 4 fold increase in throughput, but we still map things out as in old even with the array. The reason is that although the EMC software is very intelligent it can't do much more than react to the load of the moment. By speading things out as one use to do we ended up with fewer hot drives, greater cache throughput and utilization, and a whole lot of happier end users.

    As for breaking up the storage instance by instance, DO IT. This is especially true with your development environment. We had a problem a few months ago where the SA got the same hyper volume mounted on two systems. Each trashed what the other was doing. It was a whole lot easier to recover that one instance since it was isolated. It was also much easier to explain to the SA what we needed restored and it was easier for them to troubleshoot.

Dick Goulet

____________________Reply Separator____________________
Author: "Lanteigne; Mike" <MLanteigne_at_edc-see.ca>
Date:       5/1/2001 5:05 AM

Hi Lisa,

Thanks for the response. The SAN is very new here. Our first test server is supposed to be hooked up to it this week. After that we start to play. I will look into the tuning software for EMC, however from the meetings I've been to, it looks like we'll (the DBA group) have little say in the SAN setup, including "..mapping all the way back into the physical controller..". Too bad, that sounded like fun.

The only drawback I see about equating a mount point to a database instance is that new mount points will have to be created for each new database. No big deal in the static production environment, however could be a pain in dev and test (assuming I follow the same strategy in these environments). In fact, I have no idea how I'd even make a mount point, or allocate storage to it? (SAN PFM I guess).

Thanks again

Mike

> Hi Mike,
>
> If you are running EMC hardware, there are several utilities you can use
> to determine if EMC's cache is performing up to par. There are also
> utilities to alleviate any i/o contention that may appear if the EMC cache
> does not take care of i/o problems. I can't tell you exactly what they
> are though, the sysadmins used them, not me. I've worked in two places
> where we ran EMC hardware (symmetrix) and was told it should not make a
> difference if you follow the standard or not from an i/o point of view.
> However, I just couldn't get over the thought that "i/o will never be a
> problem".
>
> Add to it I've heard contradicting stories from EMC support staff, in MN
> and here in FL. I think there is still merit to mapping all the way back
> into the physical controllers in the symmetrix, but it's a royal pain in
> the behind. When the EMC guy talked through it, it was difficult for me
> to follow. I still have the documentation but I couldn't tell you exactly
> what it meant. (I am not an SA !!) It's a lot of work for what little
> performance boost you may see.
>
> If you are interested in seeing this tuning software (I'm not talking
> about Precise/SQL DBTuner, it's lower level than that) I'd suggest
> contacting your EMC support staff.
>
> Sorry I couldn't be more specific, but I can tell you I've set up
> databases both ways (OFA and not) and haven't experienced huge i/o
> problems.
>
>
> Lisa Rutland Koivu
> Oracle Database Administrator
> Certified Self-Important Database Deity
> Slayer of Unix Administrators
> Wanton Kickboxing Goddess
>
>
>
> Hello List,
>
> I'm planning an upgrade of four databases on one server from 7.3.4 to
> 8.1.7
> on Solaris. We are in the initial stages of implementing a Storage Area
> Network (SAN) project, initially 10TB on EMC hardware. The database server
>
> will use the SAN for its storage so I will have no decision on where
> datafile are actually stored (those involved in a SAN implementation know
> what I mean). ....
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Lanteigne, Mike
  INET: MLanteigne_at_edc-see.ca

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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.com
-- 
Author: 
  INET: dgoulet_at_vicr.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
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).