Hi
invPtrloc is available for runinstaller as well
On Tue, May 7, 2019 at 11:42 AM Tiwari, Yogesh <Yogesh.Tiwari@xxxxxxxxxxxxxx>
wrote:
“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
”
Thanks for your reply, Cheng.
I think, I m able to run multiple opatch sessions. I m looking for ways to
run multiple installs & deinstalls on box.
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.
*From:* Ls Cheng <exriscer@xxxxxxxxx>
*Sent:* 07 May 2019 15:02
*To:* dmarc-noreply@xxxxxxxxxxxxx
*Cc:* Oracle Mailinglist <oracle-l@xxxxxxxxxxxxx>; Tiwari, Yogesh <
Yogesh.Tiwari@xxxxxxxxxxxxxx>
*Subject:* Re: Edifice Central Inventory
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@xxxxxxxxxxxxx>
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.
