Re: Oracle Binaries on NAS

"SLSiebenaler" <sieb_at_cinci.rr.com> wrote in message news:K1Cga.19$JI.192653_at_twister.neo.rr.com...
>

[snip]
>
> Now, our "client" thinks we can save disk space (and money) and
> administration headache by consolidating the Oracle binaries on a
separate,
> single NAS device.

Sounds utterly bonkers. To save how much disk space? All 16GB of it??? And that will save you precisely how much money???? It's not exactly bank-balance-breaking, is it?

Yet it's a lot of re-configuration, is distinctly non-standard, builds in (as you say) a single point of failure, and loses you a lot of administrative flexibility to boot.

Are they on piece-rates, or something? Maybe it's a government make-work scheme?!

>Now for Oracle Client installs, I'm not too worried.
> But for running an instance, I have major concerns, one of which is the
> "loss of NAS" incident, which may cause all instances to crash. Secondly,
> if a patch is needed, we would have to shutdown all the instances for a
> given ORACLE_HOME. Third, they propose putting /var/opt/oracle on NAS
also.
> This means that files like "oratab" and "listener.ora" would have to
contain
> entries for all the databases. Also, we need to address issues with
> symbolic links for the oracle password file, the spfile, pfile, and
listener
> log files, as well as the instance lk file (in the $ORACLE_HOME/dbs
> directory).
>
> Quite frankly, I'm against the whole idea, but I want to present a good
> argument for keeping things as they are. But our client really thinks
this
> is a "progressive move".

Progressive in what sense? Progressing backwards? I think you've already got your ingredients for a good argument. In particular, the need to shut down all instances of a particular version to perform a patch or an upgrade would be the killer. Just quantify that, because it seems to me that that could be the show-stopper. Last time I patched an 8.1.7 database, it took me about an hour (from memory). That's a lot of downtime for X number of databases. On the other side, quantify the administrative complexity of the existing set up: presuming it is properly documented, is it really such a headache? And how long/how much to properly document the new setup?

Apart from that, if it ain't broke, don't fix it.

Regards
HJR
>
> SLS...
>
>
Received on Thu Mar 27 2003 - 10:27:33 CST