Re: Tale of woe - failed patch install and attempted recovery

From: EdStevens <quetico_man_at_yahoo.com>
Date: 14 Oct 2005 10:52:15 -0700
Message-ID: <1129312335.790827.206020@g14g2000cwa.googlegroups.com>

hpuxrac wrote:
> #EdStevens wrote:
> #>
> #> Well, now I really feel like an idiot (error: ID-10T) It was the
> #> OracleInventory in $ORACLE_BASE, not $ORACLE_HOME that was causing
> so
> #> much mischief. And the solution could have been applied immediately
> #> after the first failure of the patch installation. When the
> Installer
> #> listed all of the 9.2.0.6 components as installed, and greyed out on
> #> the inventory list .. don't believe they are 'really' greyed out.
> #> Click the plus sign and a good branch opens up to select for
> #> re-installing the patch for that component. Slowly work thru the
> #> entire list and it will happily re-install everything even though it
> #> thinks it has alrady done it. I feel like a rank beginner again,
> but
> #> at least I've learned a lot in the process -- not just the specifics
> of
> #> this problem, but more general about how things are put together and
> #> not believing every thing you think you see.
>
> Anytime changes are made in the oracle software area ( we are hpux rac
> 9.2.06 looking at 9.2.0.7 with a move to 10.2 sometime in the future )
> I make sure that the following things are backed up.
>
> 1) The unix oracle home ( /home/oracle ).
>
> 2) The oracle inventory ( usually in ORACLE_BASE for us
> /u01/app/oracle/oraInventory ... get the whole thing in ORACLE_BASE
> including the jre, oui, etc ).
>
> *** Special note, you may want to backup opatch related
> files/scripts/executables also, opatch can be considered logically
> related to the oui stuff.
>
> 3) The oracle software home(s) aka /u01/app/oracle/product/9.2.0
>
> 4) /var/opt/oracle
>
> 5) /etc/oratab
>
> 6) Anything you care about in /usr/local/bin such as oraenv, etc. ( We
> do something different here and don't use that ).
>
> My advice, make sure that backups for all these things are part of your
> plan. If you have bolixed up an install/maintenance action/whatever,
> if you are restoring one or more of these things, don't restore just
> part of this set of backups, restore all of them together or at least
> seriously look at each component and make an informed decision of why
> or why not each of them needs to be restored or not.
>
> Of course, opening a tar with oracle is something every one in a
> similar situation should also consider.

Points all well taken and accepted.

Before starting this, I knew about the inventory (actually remembered that there had been several recent threads here about it) but let it slip that it was in $ORACLE_BASE and not $ORACLE_HOME. Yes, after thinking about it for at least a millisecond one realizes that it CAN'T be in $ORACLE_HOME if they are going to support multiple homes.

I was on the verge of opening a tar. Really dreaded it. Late at night,

pressure is on, but it's clearly not a sev-1.  Given the nature of the
problem, I knew I couldn't even fake a sev-1.  And at that point, the
SA I needed to run root.sh was out of pocket.  I decided to search

MetaLink on "OraInventory", where I found a paper on dealing with corrupted inventories. It was there that I found the advice to run the installer and click on the components (even though they listed as 'installed' and were greyed out. Again to my shame, I've been too well conditioned by Windoze -- if I see something obviously greyed out, I assume it means you can't select on it.)

The happy end result (aside from fixing the problem) was that the structure and role of the inventory is much more firmly fixed in my head. I learned more about the use of the OUI. (interesting side observation .. the 9.2.0.6 patchset comes with the 10g installer). And I also discovered and learned about the .aud files in $ORACLE_HOME/rdbms/audit and have written a script to do housekeeping there. Received on Fri Oct 14 2005 - 12:52:15 CDT