Re: Edifice Central Inventory

From: Ls Cheng <exriscer_at_gmail.com>
Date: Tue, 7 May 2019 11:32:29 +0200
Message-ID: <CAJ2-Qb-84z7i+EbOSLzzXYbCiYv9sUuwCWk57evXQj0Fq3dL6Q_at_mail.gmail.com>



Hi

You can have several orainst.loc and then opatch and -invPtrloc /etc/oraInst.loc.101 which specify the orainst.loc you want to use

Not sure if this is what you are looking for

Thanks

On Tue, May 7, 2019 at 6:25 AM Tiwari, Yogesh <dmarc-noreply_at_freelists.org> wrote:

> List,
>
>
>
> I have been playing around with central inventory lately. Apparently, we
> have huge boxes with many DBs(40+) on them, and we don’t share Oracle Homes
> between databases. While this offers nice isolation in terms of maintenance
> to a particular home, but it is a nightmare getting them patched.
>
> By design, central inventory gets locked whenever there is maintenance on
> any Oracle Home. This results in operational difficulties to get all
> databases on the host patched, quickly.
>
>
>
> Anyway, as a possible resolution, I am experimenting with central
> inventory. Oracle allows having independent central inventory for each
> home. However, I see Oracle has inherent hard dependency on
> /etc/oraInst.loc for central inventory location.
>
>
>
> Upon grid install, /etc/oraInst.loc points to central inventory created,
> which has info about CRS. Now, if I were to implement separate central
> inventory for each new home. I have to remove /etc/oraInst.loc so that next
> Oracle Home (DB) install creates its own central inventory. However, if I
> remove oraInst.loc, it results in Bug 29716919(raised an ER), for db home
> install. As a workaround, I create an empty /etc/oraInst.loc and installer
> runs fine. I have to repeat same thing, for all new homes. You can see
> where this is going. This also means, I cant do 2 parallel installs
> either(‘d love to have it though).
>
>
>
> My initial rationale was keeping separate central inventory shall allow me
> to do parallel patching of db homes. Although, this has worked so far, as
> opatch supports invPtrloc flag, doesn’t directly depend upon
> /etc/oraInst.loc. Interestingly, not all utilities do…e.g. Runinstall in OH
> doesn’t have this flag, while runinstall in OH/oui/bin does. :P
>
>
>
> My worries grow…
>
> 1. when I decide to do deinstalls, via deinstall utility. If
> /etc/oraInst.loc doesn’t exist deinstall utility errors out (ERROR: null).
> This means, if I were to have deinstall and install run on separate homes
> at sametime, in parallel. It won’t work. Workaround, do a hard
> deinstall(rm), after dropping db.
> 2. If I don’t have /etc/oraInst.loc, adrci wonders where is ADR_BASE,
> (adrci_dir.mif file workaround doesn’t work). I have to explicitly export
> ADR_BASE on prompt to work.
> 3. Goldimage deployment(INSTALL_DB_SWONLY) doesn’t work if
> /etc/oraInst.loc doesn’t exist.
> 4. It is even messier when we move to RAC systems. Although, having an
> empty /etc/oraInst.loc on first node allows installer to work.
>
>
>
> How do you handle multiple homes on a box, in your environments? How do
> make patching faster?
>
>
>
> Thanks,
>
> *Yogi *
>
> Disclaimer: The information transmitted is intended for the person or
> entity to which it is addressed and may contain confidential, privileged or
> copyrighted material or attorney work product. If you receive this in
> error, please contact the sender and delete the material from any system.
> Any unauthorised copying, disclosure or distribution of the material in
> this e-mail is strictly forbidden. Any comments or statements made are not
> necessarily those of Fidelity. All e-mails may be monitored or recorded.
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue May 07 2019 - 11:32:29 CEST

Original text of this message