My preferred method is to have one set of binaries 'per VCS group'. So
if you have a group per oracle instance, then you need dedicated
binaries per instance, if not, then have only one. If you need to
upgrade one of the db's, just install a set of binaries in parallel
(e.g. $ORACLE_BASE/product/9.2.0; $ORACLE_BASE/product/10.2.0
 
I do not prefer to ever have binaries on the host (not shared storage),
for reasons mentioned below (can accidentally bring up db on a
mispatched host).
 
-a

  _____  

From: John Cronin [mailto:[EMAIL PROTECTED] 


  

   John Cronin wrote:
   
   > It should be possible to use one set of Oracle binaries for
   multiple
   > Oracle instances, I think - somebody please correct me if I am
   wrong.
   > Unless it was a very strange situation, you would almost certainly
   > need to have one copy of the identical binaries in identical
   locations
   > on each of the three nodes though (or one copy on NFS, or a cluster
   > filesystem that was globally accessible), so that really wouldn't
   be
   > one copy of Oracle binaries, I guess.
   >
   > That said, I have generally not done that for the following
   reasons:
   >
   > 1) Disk space keeps getting cheaper and the binaries don't take up
   > that much space (relatively speaking).
   >
   > 2) People virtually always forget to make changes (e.g. patching)
   to
   > all three nodes equally - they patch one, or something like that,
   and
   > they always get out of sync.  For this reason I generally prefer
   the
   > binaries on shared storage, failing over with the data, but there
   are
   > valid reasons not to do it this way too.
   >
   > 3) Someday someone might want upgrade for one of the instances, but
   > not the others.  At that point you have the possibility of some
   > screwing up one or more of the instances you didn't want to
   upgrade. 
    
    


_______________________________________________
Veritas-ha maillist  -  Veritas-ha@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha

Reply via email to