frm-92101 there was a failure in the forms server during startup. invalid configuration 

After EBS Fresh Install accessing any Forms Responsibility fails with error "FRM-92101: Forms Server" (Doc ID 1192205.1)





After EBS Fresh Install accessing any Forms Responsibility fails with error "FRM-92101: Forms Server" (Doc ID 1192205.1)


APPLIES TO: Oracle Applications Technology Stack - Version 12.0.6 to 12.2.3 [Release 12.0 to 12.2]


$ORACLE_HOME/bin/frmweb: error while loading shared

libraries: libXm.so.2: cannot open shared object file: No such file or directory
CAUSE The issue is caused by the openmotif21 package which is missing from the system.

For example, for Oracle Enterprise Linux 5 or Red Hat Enterprise Linux 5 the missing package is:


openmotif21-2.1.30-11.EL5.i386.rpm.
Please check Note 402310.1 Oracle Applications Installation and Upgrade Notes Release 12 (12.0.4) for Linux (32-bit) in order to identify the missing RPM.

Note: Be sure you have all rpms displayed in Note 402310.1 Oracle Applications Installation and Upgrade Notes Release 12 (12.0.4) for Linux (32-bit).

SOLUTION

To implement the solution execute the following steps:

1. Install the correct package of openmotif rpm.

For example, for Oracle Enterprise Linux 5 or Red Hat Enterprise Linux 5 the missing package is:

openmotif21-2.1.30-11.EL5.i386.rpm

2. Restart the Middle-Tier Server and all services.

3. Retest forms access and confirm the error is resolved.

Manually Recover Standby Archived Logs

References: Metalink note 150214.1 – Synchronization of primary and standby database due to log transfer gap

Identify the missing log sequence numbers by running this SQL on the STANDBY database:

SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;

Identify the filenames of the missing logs by running this SQL on the PRIMARY database:


SQL> SELECT NAME

FROM V$ARCHIVED_LOG

WHERE DEST_ID = 1 AND SEQUENCE# BETWEEN &Low_Sequence AND &High_Sequence;

1. Cancel managed recovery in the STANDBY database

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

2. Copy the missing archive redo logs from primary to standby server.

This can be done using any available O/S utility. If you use ftp make sure the transfer is done in binary mode. We assume here that the redo files are going to the same location on the standby server.

3. Recover the STANDBY database

SQL> ALTER DATABASE REGISTER LOGFILE '/ebiz/backup/flash_recovery_area/PRODSTB/archivelog/2017_05_03/o1_mf_1_11129_djmd9bg4_.arc';

Database altered.

4. Restart the database (Not Mandatory)

SQL> shutdown immediate

ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.


SQL> startup mount

ORACLE instance started.
Total System Global Area 4275781632 bytes
Fixed Size 2260088 bytes
Variable Size 1895826312 bytes
Database Buffers 2365587456 bytes
Redo Buffers 12107776 bytes
Database mounted.

5. Put the STANDBY database back into managed recovery mode:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY USING CURRENT LOGFILE DISCONNECT;

6. Check that the archive redo gaps have been resolved byt running thie SQL on the STANDBY database:

SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;