I prefer to have binaries on the each host and sometimes per instance... It will make patching a lot easier. You can apply the patch on the passive node then failover run the post scripts and you are done as opposed to having the DB down throughout the whole process and install new binaries every time you need patches. If you have DBAs that forget to install patches on all nodes, I'd just fire them!!! People need to understand the environment they are working on before they start applying patches. Force them to use deployment plans.
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrey Dmitriev Sent: Wednesday, May 28, 2008 10:29 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: veritas-ha@mailman.eng.auburn.edu Subject: Re: [Veritas-ha] VSC5, multiple Oracle10g fail-over instances 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
