Return-Path: <root@fatcity.cts.com>
Received: from ensim.rackshack.net (root@localhost)
 by orafaq.net (8.11.6/8.11.6) with ESMTP id h0AIa7a30118
 for <oracle-l@orafaq.net>; Fri, 10 Jan 2003 12:36:07 -0600
X-ClientAddr: 209.68.248.164
Received: from newsfeed.cts.com (newsfeed.cts.com [209.68.248.164])
 by ensim.rackshack.net (8.11.6/8.11.6) with ESMTP id h0AIa7c30113
 for <oracle-l@orafaq.net>; Fri, 10 Jan 2003 12:36:07 -0600
Received: from fatcity.UUCP (uucp@localhost)
 by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id HAA39139;
 Fri, 10 Jan 2003 07:17:53 -0800 (PST)
Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 0052C472; Fri, 10 Jan 2003 06:48:56 -0800
Message-ID: <F001.0052C472.20030110064856@fatcity.com>
Date: Fri, 10 Jan 2003 06:48:56 -0800
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
X-Comment: Oracle RDBMS Community Forum
X-Sender: "Hand, Michael T" <HANDM@polaroid.com>
Sender: root@fatcity.com
Reply-To: ORACLE-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
From: "Hand, Michael T" <HANDM@polaroid.com>
Subject: RE: Tru64 Direct I/O
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks, Stephen

I'll pass this along to our SA's.  We will be migrating to the Compaq SAN;
upgrading our controllers to fiber (HSG80's ?) but we have 2 older 8400's as
production primary & failover, and yes, they both have access to the same
disk farm, though not concurrently (currently).


-----Original Message-----
Sent: Thursday, January 09, 2003 5:06 PM
To: ORACLE-L@fatcity.com


Mike, 

Compaq SAN and Tru64 and direct I/O have been nothing but trouble in my
recent experience.  I put in over 35 hours over Christmas and last
weekend working on recoveries of system crashes.  Our problem appears to
have been relating to the fact that several machines had mount points on
disks that were striped and accessed from different machines.  According
to vendor techs, this shouldn't be a problem, but told us to move all
mount points around so that there were no "splits" where a disk was
being used from more than one host.   So far, we have not had a crash
since we did that (uptime of 4 days -- a new record for the past 2-3
months).  We've disabled direct I/O, but I don't know whether or not
this was part of the problem.  Our problems started getting worse after
going to 5.1a and got severe when we started using multiple nodes of our
cluster.  Compaq said for awhile that the problem was with the GS160 so
we bought 4 ES45's.  Talk about a sales pitch "Our big machine we sold
you 12 months ago stinks, you should 'upgrade' to a bunch of our smaller
ones."  

Good luck.

Stephen

>>> HANDM@polaroid.com 01/09/03 01:54PM >>>
OK, everything I've read so far on using Direct I/O with an Oracle
database
says it's a bad idea.  Either performance problems or block corruption
may
occur.  The notes on metalink (132391.1) refer to Tru64 5.0A and 5.1
but not
5.1A (to which we've recently upgraded).  So is anyone using Direct I/O
on
Tru64 successfully.
 
Oracle V8.1.7.3 EE (non-OPS)
Tru64 5.1A on Alpha Servers
 
Mike Hand
Polaroid Corp
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Hand, Michael T
  INET: HANDM@polaroid.com

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

