Upgrade 8i to 9i --- multiple oracle_base !!!!!!
- From: "EdStevens" <quetico_man@xxxxxxxxx>
- Date: 19 Oct 2005 10:37:16 -0700
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.
(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
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.
.
- Follow-Ups:
- Re: Upgrade 8i to 9i --- multiple oracle_base !!!!!!
- From: Joel Garry
- Re: Upgrade 8i to 9i --- multiple oracle_base !!!!!!
- From: Frank van Bortel
- Re: Upgrade 8i to 9i --- multiple oracle_base !!!!!!
- Prev by Date: Re: Removing space padding from INSIDE a string?
- Next by Date: Re: v$session_wait
- Previous by thread: v$session_wait
- Next by thread: Re: Upgrade 8i to 9i --- multiple oracle_base !!!!!!
- Index(es):
Relevant Pages
|