Re: CPUJAN2009 Patch Installation and Q/A

From: Rich Jesse <rjoralist_at_society.servebeer.com>
Date: Thu, 29 Jan 2009 10:33:30 -0600 (CST)
Message-ID: <64985e971bb340e31e17e7f083977965.squirrel_at_society.servebeer.com>



Hey Sam,

> 1. At what point should an Instance that is monitored with Grid Control
> be put in GC blackout ? Is this critical ?
>
> -- Shutdown, blackout, backup, startup-and-apply-CPU procedures,
> post-apply work, backup, shutdown, end-blackout, startup ?

It's not critical. Blackout is just a way to manage alarms. If a GC targeted host is not in blackout during an Oracle patch/upgrade, alarms will be sent for all Oracle products running on the OH (e.g. database, listener, Apache, etc.). If the host is blacked out, no alarms are issued. Can be especially handy for multiple DBAs not being unnecessarily paged at Midnight during an outage.

> 2. What do you like for an intuitive directory - OFA-happy - for storing
> the patch and its unzip ?
>
> -- $ORACLE_HOME/OPatch/patch is an obvious choice.
> $ORACLE_BASE/admin/patch is used, too. Preferences ???

My preference is $ORACLE_BASE/admin/PATCH (uppercased on purpose). Perhaps it's OCD ("Oracle Compulsive Disorder"?), but I don't touch anything in the $OH tree unless I need to, like the default $OH/network's log and admin dirs (which 11g has thankfully "solved"). While the $OH contents aren't strictly business data, they control how it's accessed, read, and written, and modifications to it require auditable business approval in my case.

My $.02,
Rich

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jan 29 2009 - 10:33:30 CST

Original text of this message