Re: EMC Storage Array Issue

Hi Scott/All,

  We have been able to identify the root cause for the issues we had with EMC during the last 2 weeks. The root cause was an issue with EMC PowerPath in a SAN environment where it was not able to resolve alternate paths. We are upgrading from PowerPath Version 1.3 to Version 2.0 to resolve the problem.

  The frame didn't dial out to EMC and it took some time before "we" identified the root cause.

Regards,
Denny

> Recently we had issues with EMC. Last week we started getting IO timeout on
> one of our frames followed by files being accessed disappearing. We lost
> controlfiles, redo log files and library files. EMC hasn't been able to tell
us
> why it happended. I would like to hear about solutions/explanation they come
up
> with for your problem.

Quoting Scott Canaan <srcdco_at_ritvax.rit.edu>:

> Since I started this thread, I thought I'd update everyone on what the
> problem ended up being. There is a problem with one of the power
> supplies
> on the switch in the SAN. The other power supply was not plugged in, so
> it
> halted everything occasionally. We plugged the other power supply in,
> and
> haven't had the problem since. Now we need to get the power supply
> replaced. Interesting that EMC tried to blame it on Oracle first.
>
> Scott Canaan wrote:
>
> > We have implemented a Sun Solaris Cluster (4 machines), connected
> to
> > an EMC storage array. The migration began last fall, and we now have
> 15
> > Oracle instances, with a mixture of 8.1.6 and 8.1.7, located there.
> We
> > recently have had 2 occurances of asynchronous I/O wait times
> exceeded.
> > When this occurs, every database crashes at the same time. The
> solution
> > from EMC is to turn asynchronous I/O off in all of the Oracle
> instances
> > (disk_async_io = false) and to increase the database writer slaves
> > (dbwr_io_slaves = <something not 0>) to emulate asynchronous I/O.
> > Has anyone run into this problem before? If so, how did you
> > "correct" it? My feeling is that EMC is trying to give us a bandage
> to
> > cover up the real problem, by trying to get Oracle to ignore it.
> >
> > Thank you.
> >
> > --
> > Scott Canaan (srcdco_at_rit.edu)
> > (585) 475-7886

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Denny Koovakattu
  INET: groups_at_koovakattu.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).