User management responsibility is not working in oracle ebs r12

One of the application (ebs) user reported that he is getting the below error message when he tried to access user management responsibility. Please follow the steps below provided in the resolution section to fix this issue.

How to replicate the error?

- Log into ebs with named user
- Click user management responsibility

Error :

There are no valid navigations for this responsibility

Cause: Application Object Library was unable to loade the menu for the current responsibility

Cause: The Menu compilation has failed

CAuse: There is no valid Menu defined for this responsibility

Cause: There are no navigable forms associated with this responsibility

Action: Contact your system administrator. ensure that a valid menu, containing navigable forms, is defined for the responsibility. Ensure that the menu is correctly complied. 

Solution :

- Log into ebs as sysadmin user
- Navigate to user management responsibility
- Click users under user management
- Query for the reported user
- click Assign roles
- Assign Security administrator and Custom administrator responsibility to the reported user
- Clear FND cache
- Ask the user to relogin and check

** ITs highly recommended to test the fix in test before moving into production. 


Steps provided in pictures for better understanding.

Thanks!
~Sikky

How to apply CPU or PSU patch without downtime!

Dear Brothers/Sisters,

Oracle releases Critical Patch Update every quarter for a year. CPU or PSU patches are not mandatory but its highly recommended to mitigate security issues. We will be in safer side if our databases are applied with latest CPU. Also its either DBA's decision or management to choose which release to be applied.

This article contains the few best approaching towards cpu patch activity. Basically all services should be down in order to test the CPU patch on database. Getting downtime is not an easiest option in critical environment. Also if we get the conflicts we may have to raise SR and wait for engineer's feedback. At this case we need multiple downtimes. 

To overcome this scenario i have been following this method which does not need any downtime :

Mainly You don't need to shut down any services since our activity is going to affect only the binaries where no services are running. 

Lets understand what opatch does. Basically opatch performs or modifies any libraries or binaries only on oracle home. Thus we dont need any services to be running under the oracle home when we apply opatch. 

Lets see how can we achieve this method without having any services :

1) Copy the entire oracle home binaries to different location and place them adjacent to any of your test instance. 

Test instance              :  /u01/clone/DEV/product
Dummy oracle home :  /u01/clone//DEV/product/CPU_11204

2) Name it as you like. Usually if i am replicating DEV oracle home, i would name it DEVCPU

3)  Create a dummy env file with new oracle home and new oracle sid


bash-3.2$ cat CPU_DEV.env

export ORACLE_HOME=/***/******/DEV/product/CPU_11204
export ORACLE_SID=DEVCPU
export PATH=$PATH:/***/******/DEV/product/CPU_11204/OPatch


4)  Register the newly create oracle home to the inventory. Usually i hoot the duplicate oracle home to central inventory. 

** source the dummy oracle home env file

bash-3.2$ cd $ORACLE_HOME/oui/bin

bash-3.2$ ./runInstaller -silent -attachHome -invPtrLoc /var/opt/oracle/oraInst.loc ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME=ORAHOME11Gr24CPU

Please read  how to attach db oracle home to global inventory for detail steps.

5) Run opatch lsinventory and see you are able to see the global inventory and present patches in oracle home. You can verify at the values below

Oracle Home       : /d01/oraclone/UAT/product/11204
Central Inventory : /u01/oracle/PROD/oraInventory

   from           : /d01/oraclone/UAT/product/11204/oraInst.loc

Please make sure the below values reflect the dummy oracle home and global inventory properly. 

6) Test the CPU patch on duplicate oracle home. 

7) If you are getting any conflicts, we can directly apply the patch.

8)If there are conflicts we need rollback the conflicts and then we need to apply the cpu patch. Finally we need to apply overlay patches (reverted patches)

** Its highly recommended to open service request if there are conflicts. Mainly SR engineer can help you with the overlay patches and the exact release which should be applied.

Steps are in detail :

step 1 : Rollback all the conflicts
step 2 : apply cpu patch
step 3 : Re-apply the overlay patches (rollbacked patches at step 1)


Once you are confident on the action plan you can get the down time and move the patches to instance by instance.

Hope this article helps!

Thanks!
~Sikky

Dear DBA's,

Autoconfig was unable to create listener due to the error below while r12.2.4 cloning. It was returning the error below in the autoconfig logs. 

If you ever face any issue in the listener.ora or tnsnames.ora in the oracle applications, Never attempt to create them manually or through anyother wizard. Instead run autoconfig which will populate listener.ora and tnsnames.ora for every run. If autoconfig is unable to create them, then we can conclude something is wrong with the setup. 

Error captured in log :


Updating s_tnsmode to 'generateTNS'
UpdateContext exited with status: 0
AC-50480: Internal error occurred: java.lang.Exception: Error while generating listener.ora.
Error generating tnsnames.ora from the database, temporary tnsnames.ora will be generated using templates
Instantiating Tools tnsnames.ora
Tools tnsnames.ora instantiated

adgentns.pl exiting with status 2
ERRORCODE = 2 ERRORCODE_END
.end std out.

As soon as i see the message "Error generating tnsnames.ora from the database" from the log, nothing comes in my mind except fnd_nodes table. 

So i queried the fnd_nodes table and found the below :


SQL> select node_name from apps.fnd_nodes;

NODE_NAME
------------------------------
PRODERP --> Prod entry
PRODPDB --> Prod entry

Thats it. Error is due to the production entry in the fnd_nodes table and there is no entry for test. 

Solution is very simple. Clean the fnd_nodes table then Simply run autconfig on both side. Start with db tier then apps tier. 

how to clean fnd_nodes table in oracle apps  r12.2.4 ?

SQL> exec fnd_conc_clone.setup_clean();

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

SQL> select node_name from apps.fnd_nodes;

no rows selected

After cleaning the nodes double check you dont see any of the node entry in fnd_nodes.

Now just populate the host entries for test servers.

Run autoconfig in db tier.
Run autoconfig in apps tier. 

If you query fnd_nodes after autoconfig you should see the test servers entry. 

Thats it. The moment you ran autoconfig you can see the listener.ora and tnsnames.ora have been regenerated by autoconfig.

Just start the listener and it should start without any issue.

how to start oracle apps listener ?

Command to start listener : lsnrctl start APPS_UAT (ex : APPS_SID )

Thanks!
~Sikky

R12.2.4 autoconfig failed while cloning : ld.so.1: FNDCPUCF: fatal: /a01/appstier/UAT/fs2/EBSapps/10.1.2/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64

Dear DBA's,

This error encountered while cloning r12.2.4. My apps tier is repeatedly ended with error in apps side. Cloning ended with 100% completed status but autoconfig recorded some errors. I was able to start the services without any error status but i was unable to launch the forms. This issue is due to relink does not happen properly during autoconfig phase. So simply running autoconfig wont fix the issue. I had to fix the issue and re-run adcfgclone. 

I have described the steps i followed in detail through this article. 


Error returned at the bottom of the autoconfig log :

WARNING: [CVM Error Report]
The following report lists errors encountered during CVM Phase
      <filename>  <return code where appropriate>
  /a01/appstier/UAT/fs2/EBSapps/appl/ad/12.0.0/bin/adgentns.pl  2

 No. of scripts failed in CVM phase: 1



WARNING: [AutoConfig Error Report]
The following report lists errors AutoConfig encountered during each
phase of its execution.  Errors are grouped by directory and phase.
The report format is:
      <filename>  <phase>  <return code where appropriate>

  [PROFILE PHASE]
  AutoConfig could not successfully execute the following scripts:
    Directory: /a01/appstier/UAT/fs2/inst/apps/UAT_ahqtest/admin/install
      afcpctx.sh              INSTE8_PRF         137



AutoConfig is exiting with status 1


I wasted bunch of time on tracing out this issue. Later i found out this is not the reason for the error. 

I strongly recommend don't just come to conclusion that this is the reason for the error. We need to read through the entire autoconfig log to find actual issue. 

I just searched the autoconfig log with the keyword "error" and i found the below. 

Actual Error :

Uploading Metadata file /a01/appstier/UAT/fs2/EBSapps/appl/ad/12.0.0/admin/template/adctxinf.tmp
Metadata file /a01/appstier/UAT/fs2/EBSapps/appl/ad/12.0.0/admin/template/adctxinf.tmp upload failed.
Check log file created by FNDCPUCF program.
ERRORCODE = 137 ERRORCODE_END
.end std out.
ld.so.1: FNDCPUCF: fatal: /a01/appstier/UAT/fs2/EBSapps/10.1.2/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64
Killed
ld.so.1: FNDCPUCF: fatal: /a01/appstier/UAT/fs2/EBSapps/10.1.2/lib/libclntsh.so.10.1: wrong ELF class: ELFCLASS64
Killed


You can find the note below if you search with the above error.

R12 - adcfgclone appsTier fails with error for ld.so.1 'wrong ELF class: ELFCLASS64' (Doc ID 1078123.1)


After reading the note, i found out that the user does not have any permission to central inventory. But instead of giving him actual permission we could follow the below :

1. Create a global inventory under its default locations. 

For Solaris : /var/opt/oracle/ 

2. oraInst.loc must point to any directory location where the user has access

You should see : /var/opt/oracle/oraInventory

3. Rename the previous global inventory :

mv oraInventory to oraInventory_old 

create empty directory as oraInventory (mkdir oraInventory)

Make sure the user which you run cfgclone has full permission on the directory above.

4. Start the Cloning scripts again - for the DB-Tier and the APPS-Tier

I just re-run the apps tier and i was able to complete the cloning. 

5. Check the new created logfile ohclone.log

Thanks!
~Sikky