EBS R12 Cloned Instance | opatch

Not being a DBA has it’s own perks ;) Freedom to try to fix everything that do not look “legit” from all angles.

My last attempt was to rebuild “Central Inventory” for a cloned instance of Oracle Applications R12 (EBS 12.0.6) on Linux. This instance was cloned from a certified platform, to a totally unsupported platform. In addition to, the DBAs those migrated from 10g R2 to 11g R2 left much of the post clone activities pending immediately once after the instance came online.

So, trying to patch Oracle database 11gR2(11.2.0.4) brought me to a situation that never existed:

  • “opatch” was “not” recognized as a command!
  • “opatch lsinventory” run always screamed about corrupt/missing central inventory location.

The “opatch” not being recongized as a command was due to $ORACLE_HOME/OPatch path missing, easily fixed by adding the path to the existing $PATH environment variable for the Oracle user.

One of the other issues you might face up with 11.2.0.4 could be the unsupported opatch version. You need to replace the current opatch version with the latest supported. Please refer to patch #6880880 & Install the patch marked in the below image

Please read the “README” to know how to replace the existing version with the latest supported.

Once the opatch stack taken care of, we still need to fix the central inventory, that keeps reported as being missing.

[oratest@bak clone]$ opatch lsinventory
 Oracle Interim Patch Installer version 11.2.0.3.25
 Copyright (c) 2020, Oracle Corporation.  All rights reserved.
 Oracle Home       : /u01/oratest/TEST/db/tech_st/11.2.0
 Central Inventory : /u01/oratest/TEST/db/tech_st/11.2.0/inventory
    from           : /u01/oratest/TEST/db/tech_st/11.2.0/oraInst.loc
 OPatch version    : 11.2.0.3.25
 OUI version       : 11.2.0.4.0
 Log file location : /u01/oratest/TEST/db/tech_st/11.2.0/cfgtoollogs/opatch/opatch2020-11-11_10-35-04AM_1.log
 LsInventorySession failed: OPatch failed to locate Central Inventory.
 Possible causes are:
     The Central Inventory is corrupted
     The oraInst.loc file specified is not valid.
 OPatch failed with error code 73

Let us see how to rebuild the Central Inventory for the EBS R12 cloned instance now.

If your current server (the one that has the cloned instance of the application) never had an Oracle installation executed from the same, will not have /etc/oraInst.loc file, instead the file must be available under $ORACLE_HOME & the file MUST BE pointing towards the source server paths. For example, my cloned instance oraInst.loc contents are like below:

>cat oraInst.loc
 inventory_loc=/u05/oraprod/oraInventory
 inst_group=oinstall

where inventory_loc path wrong for the current server.

You may create something equivalent to what already exists with the oraInst.loc file, for example (in my case) a path like /u01/oratest/oraInventory as “Oracle” user.

So, you need to amend the oraInst.loc file that is available with $ORACLE_HOME path like below

>cat oraInst.loc
 inventory_loc=/u01/oratest/oraInventory
 inst_group=oinstall

Now you can proceed building the Central Inventory.

logon as Oracle user

SHUTDOWN THE DATABASE & ALL OTHER ORACLE DATABASE RELATED SERVICES

  1. source the environment
  2. switch to $ORACLE_HOME/appsutil/clone
  3. execute ouicli.pl (./ouicli.pl)

Now, We will attach the current ORACLE_HOME with the Central Inventory. Many things could go wrong here, so make sure that you refer the document “How to create, update or rebuild the Central Inventory for Applications R12” in case if you are stuck for reasons those are not mentioned in this post.

As Oracle user

switch to $ORACLE_HOME/oui/bin

Execute

./runInstaller -ignoreSysPrereqs -silent -attachHome -invPtrLoc $ORACLE_HOME/oraInst.loc \
 ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME=""

Example:

./runInstaller -ignoreSysPrereqs -silent -attachHome -invPtrLoc $ORACLE_HOME/oraInst.loc \
 ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME="TEST_Oracle_HOME"

If there are no issues, you should get ” ‘AttachHome’ was successful ” confirmation once after the installer finishes the execution.

Test opatch once again

>opatch lsinventory

The above should provide you an output like below:

[oratest@bak bin]$ opatch lsinventory
 Oracle Interim Patch Installer version 11.2.0.3.25
 Copyright (c) 2020, Oracle Corporation.  All rights reserved.
 Oracle Home       : /u01/oratest/TEST/db/tech_st/11.2.0
 Central Inventory : /u01/oratest/oraInventory
    from           : /u01/oratest/TEST/db/tech_st/11.2.0/oraInst.loc
 OPatch version    : 11.2.0.3.25
 OUI version       : 11.2.0.4.0
 Log file location : /u01/oratest/TEST/db/tech_st/11.2.0/cfgtoollogs/opatch/opatch2020-11-11_10-42-05AM_1.log
 Lsinventory Output file location : /u01/oratest/TEST/db/tech_st/11.2.0/cfgtoollogs/opatch/lsinv/lsinventory2020-11-11_10-42-
 Local Machine Information::
 Hostname: bak.localdomain.com
 ARU platform id: 0
 ARU platform description::
 There are no Interim patches installed in this Oracle Home.
 
 OPatch succeeded.

That’s all folks. You can proceed with your patching for the database now! Hope this helps few certified DBAs out there ;)

rajesh

Oracle R12 Cloning | dbTier "ouicli.pl INSTE8_APPLY 1"

Hi guys

There could be thousands (exaggerated) reasons why a Oracle cloning process could go all bad. I’m not an application DBA, however, have enough experience with the architecture, technology as I interact with it everyday as a part of my job.

Few months back, I started doing something what a DBA should do, cloning. My prior attempts were mostly at home, using virtual machines and test instances and they were NOT as mission critical as what we do at work.

So, after the storage device was revamped with new partition structures I was asked to do a cloning for the production instance. Let me explain how the application was deployed prior the storage restructuring

  1. We had the database tier on mount point /u05
  2. Application on /u06 mount point

So, I recreated the same mount points and started the cloning process for dbTier and the process got terminated at 2% and the log files shown me an error that I was not familiar with.

“ouicli.pl INSTE8_APPLY 1”

Google searches fetched me hundreds of results for “ouicli.pl INSTE8_APPLY”, however the error codes were mostly for 255 or “-1” and apparently I didn’t have any clue what was going wrong.

So I unzipped the tar ball for database tier once again, and the cloning process got aborted at 2%,  and I was getting nervous as I was expected to make the instance online by early morning 7AM

Most of the reference materials were explaining about non-existent Oracle inventory locations, and I confirmed that it was not the case from my part (Obviously, I was overlooking at this constrain itself!)

After half a dozen times tasting failure, finally I tried to see what was written inside the oraInst.loc file

 

[code language=”text”]
oraprod@erp-prod:/home/oraprod>cd $ORACLE_HOME
oraprod@erp-prod:/u05/oraprod/PROD/db/tech_st/10.2.0>cat oraInst.loc
inventory_loc=/u01/oraprod/PROD/db/tech_st/10.2.0/admin/oui/PROD_erp-prod/oraInventory
[/code]

and I realized that inventory location was wrongly pointing towards an non-existing mount point and physical location!

I modified the oraInst.loc content with the correct mount point

[code language=”text”]
inventory_loc=/u05/oraprod/PROD/db/tech_st/10.2.0/admin/oui/PROD_erp-prod/oraInventory
[/code]

and the cloning process went ahead without giving another errors.

We had an instance that was running from last 6 years, which was only once cloned from a cold backup during the storage device change, and somehow the inventory location remain unchanged with the repositories.

I hope this finding could help few newbies like me out there

 

regards,

rajesh

Oracle EBS R12 | Inventory | Receipts stuck in pending status

Sometimes the receipts against internal requests could get into trouble with the status pending. While the requester tries to receive the transaction, receipts get created with zero quantities and the internal sales order yet in open status and the quantities are seen in staging location. Please follow the below to delete such pending lines to receive the quantities once again to the targeted sub-inventory

As inventory super user

Transactions -> Receiving -> Transactions Status Summary

1

Under the tab “Supplier and Internal”

Select the “Destination” tab

Enter the name of the requester name (the name of the user who has created the internal material request to limit the lines fetched) & find the transactions

Delete the lines matching the transaction & save

2

Go back to receipts and enter the request number once again to receive the materials

regards,

for Windows7bugs

rajesh