Re: Upgrade 8i to 9i --- multiple oracle_base !!!!!!

EdStevens wrote:
> Sanity Check needed
>
> System: Oracle 8.1.7.1.0 on AIX 5.1
>
> This is my last holdout on 8.1, to be upgraded to 9.2, and I have a
> rather unusual challenge. Asking for a sanity check if my approach
> will work, if there is a better approach, and what I might be
> overlooking.
>
> On this particular box, we have two databases, spd01 for dev work and
> spq01 for QA. Not only did the original DBA choose to give each its
> own $ORACLE_HOME, he chose to give each its own $ORACLE_BASE, and
> it's own system owning account. Sign on to AIX with oraspd if you
> want to work with spd01, with oraspq if you want to work with spq01.
>
> I know there has been some recent debate here over giving each db its
> own $ORACLE_HOME, but separate ORACLE_BASE is a whole new ballgame.
> Also, my recent misadventure patching another box has sensitized me to
> issues dealing with $ORACLE_BASE and the inventory location. This
> particular setup is screaming to be cleaned up. Even though each
> orasp* user account gets its own $ORACLE_BASE, there is still only one
> /etc/oraInst.loc, pointing to only one inventory location. My guess is
> this simply won't work.

Why? It is especially useful in testing patches.... Now you can patch your dev install, and leave the qa working with the good old working version...
I have been using this setup on several occasions (cst insisting on having this possibility, not willing to fund and extra 3k for an extra machine...)
>
> (Just to make it even more interesting, he gave each its own
> installation of BMC's SQL-Backtrack for the backups! And those
> installations are unnecessarily intertwined into the ORACLE_BASE
> structures.)
>
> So, what we have is this:
> For database SPD01, account oraspd gets the environment:
> $ORACLE_BASE = /02fs01/vendors/oracle1
> $ORACLE_HOME = /02fs01/vendors/oracle1/product/spd01/8.1.7
>
> For database SPQ01, account oraspq gets the environment:
> $ORACLE_BASE = /02fs01/vendors/oracle2
> $ORACLE_HOME = /02fs01/vendors/oracle2/product/spq01/8.1.7
>
> and the single /etc/oraInst.loc has:
> inventory_loc=/02fs01/vendors/oracle1/oraInventory
> inst_group=dba

Oops! Someone goofed here... I always copy the oraInst.loc to the home directory of the software owner; suggest you search for other copies of oraInst.loc, with possible different contents.

>
> What I have in mind for the upgrade, and to clean up this mess is this:
>
> 1) Install one copy of the latest version of SQL-Backtrack into its own
> directory structure, completely separate from any Oracle directories.
> (The discussion of SQL-BT vs. rman is not on the table.) Get that
> working, then delete all of the old installations out of the Oracle
> related directories.
>
> 2) Shutdown and cold backup both databases.
>
> 3) Create a new, single AIX account to own Oracle. Call it (drum roll
> please!) -- oracle.
>
> 4) TAR, then delete both ORACLE_BASE directories
>
> 5) Tar, then delete /etc/ora* At this point, there should be no
> remnants of an Oracle installation, other than the databases
> themselves.
>
> 6) Create a new directory at /02fs01/vendors/oracle to be a new,
> unified ORACLE_BASE
>
> 7) Install Oracle 9.2.0.1.0 into a single ORACLE_HOME at
> $ORACLE_BASE/product/9.2.0
>
> 8) Restore the original $ORACLE_BASE db 'admin' directories from
> the tars to $ORACLE_BASE/admin/<sid>
>
> 9) Restore the original contents of $ORACLE_HOME/dbs from the tars to
> $ORACLE_HOME/dbs
>
> 10) Restore the original init<sid>.ora parameter files to
> $ORACLE_BASE/admin/<sid>/pfile/init<sid>.ora (currently located in
> $ORACLE_HOME/dbs). Create links in $ORACLE_HOME/dbs, to refer to the
> actual location.
>
> 11) Try as I might, I can't find current password files. And I see
> we have remote_os_authent = true. ???
>
> 12) Begin the migration procedure.
>
> It also occurs to me that after removing the existing installation, and
> before installing 9.2, I might want to install 8.1.7 in the new single
> $ORACLE_BASE, to make sure I can bring up the db, before introducing
> 9.2 into the mix. At that point, I would have a clean, single-home,
> single-base installation to work with.
>
> Thoughts, comments, criticisms welcome.
>

You have my thought on multiple vs single software trees. Can't, and thus won't, comment on SQL-Backtrack. Now, as there are QA and dev, I would *guess* their size is moderate. Perhaps QA is large(r), but is exp/imp an option? It would give you the option of using all these beautiful new features, and not be blessed with remnants of an ancient incarnation... Of course, size-wise (temporarily: yet another install!) it has to be an option...

-- 
Regards,
Frank van Bortel

Top-posting is one way to shut me up...