Oracle EBS R12 Report Manager FRM_FO_GENERATOR module: FO Generator - Failed With JAVA HEAP Space Error. Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

Report Manager FRM_FO_GENERATOR module: FO Generator - Failed With JAVA HEAP Space Error. Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 


Error message:
FRM_FO_GENERATOR module: FO Generator

Dec 15, 2009 5:51:27 PM oracle.adf.share.config.ADFConfigFactory findOrCreateADFConfig
INFO: oracle.adf.share.config.ADFConfigFactory No META-INF/adf-config.xml found
Generating FO for the file id = 1096
FO Generation Program Completed at Tue Dec 15 18:34:11 MST 2009
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2786)



Solution :
To implement the solution, please execute the following steps:

FO Generator Concurrent request is failing with Java Heap Size so you need to increase the heap size of the FO Generator program. Please increase the heap size of the FO Generator concurrent program.

Follow these steps to increase the heap size of the FO Generator program. Bounce the Apache, Middle Tier after performing the changes and retest the issue.

To Increase Heap Size of FO Generator concurrent program:
=====================================
1) Navigate to the form System Administrator > Concurrent > Program > Define
2) In this form query the
Program : "FO Generator"
Short Name : "FRM_FO_GENERATOR"
3) In the resulting record check the Executable properties are
Name : "FRM_FO_GENERATOR"
Method : "Java Concurrent Program"
4) In the "Options" field of Executable properties enter the following
java options
-Xmx1024m -Xms256m
and save the record.
It specifies,
-Xmx1024M - Maximum heap size
-Xms256M - Initial heap size

To Increase Heap Size of oacore process:
=======================================
.
1. Locate the file $ORA_CONFIG_HOME/10.1.3/opmn/conf/opmn.xml

2. In the file,
<process-type id="oacore" module-id="OC4J" status="enabled"
working-dir="$ORACLE_HOME/j2ee/home">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-server -verbose:gc -Xmx1024M
-Xms256M -XX:MaxPermSize=160M

oacore java-options
-Xmx1024M - Specifies maximum heap memory.(1024 MB)
-Xms256M - Initial heap memory.(256 MB)
.
Please increase the values to resolve out of memory error.

3.  Bounce the Concurrent Manager, Database Listener, and Apache Server.

4. Retest the issue.

5. Migrate the solution as appropriate to other environments.

6. If the report still fails with the java heap space errors, change parameter Maximum heap size to -Xmx1024M or -Xmx2048m based on your hardware compatibility.

Oracle EBS R12.2.5 // Fatal Error: TXK Install Service // Patch process failed //

Oracle EBS R12.2.5 // Fatal Error: TXK Install Service // Patch process failed // 


Fatal Error: TXK Install Service

oracle.apps.fnd.txk.config.ProcessStateException: OPatch process failed : Exit=1                 See log for details. CMD= perl /d01/oracle/ORAR1225/fs2/FMW_Home/webtier/OPatch                /opatch.pl apply -verbose -silent   -ocmrf /d01/oracle/ORAR1225/fs2/inst/apps/or                ar_erp/temp/ASInstallHome/fnd/admin/template/txkForms_ocm.rsp  -jdk /d01/oracle/                ORAR1225/fs2/FMW_Home/webtier/jdk /d01/oracle/ORAR1225/fs2/inst/apps/orar_erp/te                mp/patches/7695070/7695070

    at oracle.apps.fnd.txk.config.OPatchActionNode.processState(OPatchActionNode                .java:312)

    at oracle.apps.fnd.txk.config.PatchActionNode.processState(PatchActionNode.j                ava:187)

    at oracle.apps.fnd.txk.config.PatchNode.processState(PatchNode.java:338)

    at oracle.apps.fnd.txk.config.PatchesNode.processState(PatchesNode.java:79)

    at oracle.apps.fnd.txk.config.InstallNode.processState(InstallNode.java:68)

    at oracle.apps.fnd.txk.config.TXKTopology.traverse(TXKTopology.java:594)

    at oracle.apps.fnd.txk.config.InstallService.doInvoke(InstallService.java:22                4)

    at oracle.apps.fnd.txk.config.InstallService.invoke(InstallService.java:237)

    at oracle.apps.fnd.txk.config.InstallService.main(InstallService.java:291)



Cannot install one-off patches

    RW-50010: Error: - script has returned an error:   1
RW-50004: Error code received when running external process.  Check log file for                 details.
Running APPL_TOP Install Driver for orar instance



Solution :

when the size of fs2( here Patch File system)  becomes 6*** mb(38% here) then jdk directory is deleted and a directory jdk_backup_existing_version is created

Then u do the below

cp -R jdk_bak jdk

Oracle EBS 12.2 ADOP(AD Online Patching) Utility

You use the adop (AD Online Patching) utility to apply patches to the Oracle E-Business Suite file system or database.

You can either allow adop to prompt for the information required to apply a patch, or enter the information without being prompted.

Whichever method you choose, adop will then perform the tasks required to apply the patch:

most parameters can be defined in at least two locations, with patchtop able to be defined in three  different locations. If multiple different definitions are specified, the following order is used.

Command Line: An adop parameter specified on the command line will take precedence over all others.

Input File: An adop parameter given here will only be lower in precedence to a parameter specified on the command line.

Defaults File: Parameters defined here have the lowest level of precedence.

Patch Log Files

It is advisable to review the relevant log files after any patching operation. The adop log files are located on the non-editioned file system (fs_ne), under:

$NE_BASE/EBSapps/log/adop/<adop_session_id>/<phase>_<date>_<time>/<context_name>/log

For example, if s_ne_base was /u01/R122_EBS/fs_ne, the session ID was 15, and the <CONTEXT_NAME> was patch01_testsys, the path to the adop log files from 9th July 2014  would resemble this:

/u01/R122_EBS/fs_ne/EBSapps/log/adop/15/apply_20140709_112226/patch01_testsys/log

adop Patching Modes

The adop utility is normally used to apply patches in an online patching cycle. It can also be used:

To run a patching cycle, and test patch application without actually taking any apply actions, in test mode

To apply patches outside a patching cycle in downtime mode

To apply patches without connecting to the database in preinstall mode

Test Mode

In test mode, adop does not apply the patch. Instead, it lists each file it would have copied, relinked, executed, or generated, and shows exactly what actions it would have performed had it applied the patch. It also runs AutoConfig in test mode to determine any impending changes to the configuration  files. This allows you to see the effects of a patch on your system before you apply it.

To run adop in test mode, add the apply=no parameter to the adop command you would use if you were actually going to apply the patch. In test mode, adop will go through the process of applying the patch but will not perform any of the following actions:

Copy files from the patch directory to the Oracle E-Business Suite file system

Archive object modules into the product libraries

Relink executables

Generate forms, reports, PL/SQL libraries, or menu files

Run SQL or EXEC commands (commands that change the database)

Instantiate new configuration files

Update the patch information files

Update patch information and release version in the database

Downtime Mode

To optimize the process of upgrading to Oracle E-Business Suite Release 12.2, support is provided for  the capability to apply Oracle E-Business Suite patches in downtime mode.

When applying patches in this mode, adop will first confirm that the application tier services are down,

and will then proceed to apply the patch to the run edition of the Oracle E-Business Suite database and file system.

Downtime mode patching does not use an online patching cycle. The process of applying a patch in downtime mode completes more quickly than in online mode,

but at the cost of increased system downtime.

To run adop in downtime mode, you use the following command line options. In this example, patch 123456 is applied in downtime mode:

$ adop phase=apply patches=123456 apply_mode=downtime

Important: Be aware that:

Release 12.2 patches are not normally tested in downtime mode.

Downtime mode is only supported for production use where explicitly documented, or when directed by Oracle Support or Development.

Preinstall Mode

Preinstall mode is generally used during the upgrade process to update AD utilities, apply pre-upgrade patches, or work around other patching issues.

adop asks all startup questions except those relating to the database.

Important: Run adop in preinstall mode only if the patch readme instructs you to do so.

To run adop in preinstall mode, include preinstall=y on the adop command line. It performs the following actions:

Compares version numbers

Copies files

Relinks FND and AD executables

Saves patch information to the file system

Because adop does not read driver files in preinstall mode, it copies all product files in the patch to the APPL_TOP directory.

Additionally, even if a file in the patch should be both in the APPL_TOP and in another directory (such as in $OA_HTML), adop copies the file only to the APPL_TOP.

In preinstall mode, adop validates codelevels against the files Preinstall_Codelevel_AD.txt and  Preinstall_Codelevel_MP.txt.

These files are located in the $APPL_TOP/admin directory, and contain codelevel information about AD and other products registered in the database tables.

Since no database connection is available in preinstall mode,

adop tries to validate whether the current patch should be applied based on the codelevel information in these two files, as follows:

If Preinstall_Codelevel_AD.txt is missing from the APPL_TOP, adop will apply the patch in preinstall  mode without validating the patch for codelevel compatibility.

If Preinstall_Codelevel_MP.txt is missing from the APPL_TOP, adop will proceed with patch application without validating the patch for codelevel compatibility of the entities.

If both files are missing, adop will not validate codelevels in preinstall mode.

Note the following restrictions when applying a patch in preinstall mode:

NLS patches cannot be applied on the instance.

Baseline or codelevel-introducing patches cannot be applied on the instance.

adop will not check to see if the patch is already applied on the system.

Running adop

The following is a summary of the steps you use to run adop. For a complete procedural description of all the steps, see Creating Customized Instructions for Patching Using PAA.

Step 1: Set the environment

You must set the environment to apply the configuration parameters that define your system. This task is common to many AD utilities, and is performed using the following command:

$ . <EBS_ROOT>/EBSapps.env run

<EBS_ROOT> represents the Oracle E-Business Suite base install directory, such as /u01/oracle. There is no associated environment variable.

Note: The EBSapps.env file is provided by the AD-TXK release update packs.

Step 2: Unzip the patch

Download and unzip the patch into the patch top directory, which is identified by the $PATCH_TOP environment variable.

Step 3: Review the information in the readme file

In the directory where you unzipped the patch, you will find a README.txt file and a README.html file.

Review either readme file for information about the patch and for instructions on using Oracle Patch Application Assistant (PAA) to generate customized instructions for your system.

Step 4: Run Oracle Patch Application Assistant

Run PAA (admsi.pl) to generate customized instructions for your system. Follow the steps in the customized instructions to start the patching process.

Step 5: Run adop

The customized instructions generated by PAA describe how to run adop using the adop command.

Note: You can add arguments on the command line to refine the way adop runs. See adop Modes and  Command Line Arguments.

A simple example of the commands to execute a complete online patching cycle for patch 123456 is  as follows:

$ . <EBS_ROOT>/EBSapps.env run

$ adop phase=prepare

$ adop phase=apply patches=123456

$ adop phase=finalize

$ adop phase=cutover

$ . <EBS_ROOT>/EBSapps.env run

$ adop phase=cleanup

Monitoring Status

You can obtain a brief report for the current patching session by running the command:

$ adop -status

If you want information about a particular session, specify the relevant session ID:

$ adop -status <session ID>

If you want additional details of operations performed:

$ adop -status -detail

This option will give a summary of last ten adop session IDs, and full details of the file system and database changes introduced by a patch.

It also shows the log file location of the current patching cycle.

Aborting an Online Patching Cycle

If a patching cycle is failing and the issue cannot be resolved quickly, it is possible to abort the patching cycle and return to normal runtime operation.

The patch edition will be dropped.

You can abandon a patching cycle (without applying any patches) by running the command:

$ adop phase=abort

Important: This abort command can only be used before successful completion of the cutover phase. After cutover, the system is running on the new edition,

and abort is no longer possible for that patching cycle.

Aborting a patching cycle will drop the patch edition, but you must then run the cleanup and fs_clone phases before starting a new patching cycle. The cleanup must be a full cleanup.

For example:

$ adop phase=prepare

$ adop phase=apply patches=123456

[Patch application encounters problems and you want to abort]

$ adop phase=abort

$ adop phase=cleanup cleanup_mode=full

$ adop phase=fs_clone

Optionally, you can combine the abort and cleanup commands as follows:

$ $ adop phase=abort,cleanup cleanup_mode=full

Note: You cannot abort application of a patch applied in hotpatch mode (adop phase=apply apply_mode=hotpatch).

End of ADOP Utility -Concept

EBS (E-Business Suite)

Oracle EBS apache issue/error : 500 Internal Server Error

EBS 12.x Linux, MT Services(oacore) not comping

Ebusiness12.1.x : Apache startup issue on Linux OS // Apache not coming up on EBS

Procedure To Restore The Weblogic User Password On EBS 12.2 In Case Of Lost Or Forgotten Password

DataGuard // Standby Database

Standby MRP crashing

ORA-20011: Approximate NDV failed: ORA-16532: Data Guard broker configuration does not exist

RMAN

RMAN-06094: datafile must be restored // RMAN-06094: datafile 50 must be restored

RMAN duplicate failing with Error RMAN-05001

RMAN-06429 TARGET Database is not Compatible with this Version of RMAN

RMAN upgrade catalog failed with RMAN-06429

RMAN-06217

RMAN Restore and Recovery Scenarios

RMAN Configuration Parameters

Oracle EBS apache issue/error : 500 Internal Server Error

 Oracle EBS 12.x apache issue/error : 500 Internal Server Error


Fix/Solution:

cd $INST_TOP/ora/10.1.3/j2ee/oacore/config
vi oc4j.properties

LONG_RUNNING_JVM=false               >>> Change the Value to false

RMAN-06094: datafile must be restored // RMAN-06094: datafile 50 must be restored

RMAN-06094: datafile <dbfNo.> must be restored

Error Message:
RMAN> RECOVER DATABASE NOREDO;

Starting recover at 13-JUL-15
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/13/2015 05:27:38
RMAN-06094: datafile 50 must be restored


CAUSE:
Backup of datafile <dbf> not available in RMAN catalog.


Solution:
Take fresh backup and restore by below comamnd,
RMAN>RECOVER DATAFILE 15;

Example:
RMAN> restore datafile 50;

Starting restore at 13-JUL-15
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00050 to /prod/data/data01/a_txn_data11.dbf
channel ORA_DISK_1: reading from backup piece /prod/backup/standby/Jul_13/FORSTANDB_dbf5028qbu25o_1_1
channel ORA_DISK_1: piece handle=/prod/backup/standby/Jul_13/FORSTANDB_dbf5028qbu25o_1_1 tag=DBF15
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:02:25
Finished restore at 13-JUL-15

RMAN duplicate failing with Error RMAN-05001: auxiliary file name '' conflicts with a file used by the target database

RMAN duplicate failing
RMAN-05001: auxiliary file name '<dbfile>' conflicts with a file used by the target database


Error Message:
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_uid57.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_uid56.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data01/maximo_interfaz_03.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data74.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data73.dbf conflicts with a file used by the target database
RMAN-05001: auxiliary file name /prod/data/data02/a_uie_data72.dbf conflicts with a file used by the target database
...



CAUSE:
Production and Auxiliary have same directory structure and are running on two different machines.
RMAN must be told not check that the target datafiles are sharing the same names as the duplicated files being created.
Otherwise, the following errors will be returned:



Solution :

User CLAUSE "NOFILENAMECHECK" in Rman Duplicate command before parameter 'DB_FILE_NAME_CONVERT' and 'LOG_FILE_NAME_CONVERT'

Example:

DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
NOFILENAMECHECK
PARAMETER_VALUE_CONVERT '/prod/data','/prod/data','/prod/data','/prod/data'
SET "db_unique_name"="prod1stby" COMMENT "Is a duplicate"
set db_file_name_convert='/prod/oracle/','/prod/oracle/','/prod/oracle/','/prod/oracle/'


NOTE: Do not use NOFILENAMECHECK when target and destination database are on the same box because datafiles from target database will be overwritten !!

Standby MRP crashing due to ORA-00379: no free buffers available in buffer pool DEFAULT for block size 16K


Cause : 
SQL> show parameter 16k

NAME                                 TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
db_16k_cache_size                    big integer
0                                                                                        <<<<<<<<<<< Not set value

SQL>



Solution :
1.)
SQL> alter system set db_16k_cache_size=512M scope=SPFILE;

System altered.

Note: value of this parameter must in multiple of 16k.


2.)Restart DB


>>>> Note : To take effect of this parameter value, DB restart is required.

ORA-20011: Approximate NDV failed: ORA-16532: Data Guard broker configuration does not exist

ORA-20011: Approximate NDV failed: ORA-16532: Data Guard broker configuration does not exist 

Oracle DB : Release 11.2

% dgmgrl

DGMGRL> connect /

DGMGRL> show configuration

ORA-16532: Data Guard broker configuration does not exist

Solution :

Disable the DataGuard broker:

SQL> alter system set dg_broker_start=false scope=both;
SQL> > exec dbms_stats.gather_fixed_objects_stats;

PL/SQL procedure successfully completed.

EBS 12.x Linux, MT Services(oacore) not comping on 2nd host (MYHOST03), but was fine on Host : MYHOST02

On EBS 12.x Linux, MT Services(oacore) not comping on 2nd host (MYHOST03), but was fine on Host : MYHOST02

Issue : oacore not coming up

MSG_TEXT>Error reading config file {0}</MSG_TEXT>

<SUPPL_DETAIL><![CDATA[java.io.IOException: No locks available

at sun.nio.ch.FileDispatcherImpl.lock0(Native Method)

at sun.nio.ch.FileDispatcherImpl.lock(FileDispatcherImpl.java:90)

MSG_TEXT>Failed to acquire lock for /prod/product/1013/j2ee/home/applications/dms.war. It may fail to share the application with multiple oc4j instances.</MSG_TEXT>

>>>

Cause: /prod/product   >>> Not mounted with lock option, So it was failing to lock above file : dms.war( By using this configuration file oacore was deployed)

Fix/Solution : Get it mounted with lockoption.

and after reboot host, issue got fixed & MT services started normally.

Ebusiness12.1.x : Apache startup issue on Linux OS // Apache not coming up on EBS

Ebusiness 12.1.x : Apache startup issue  on Linux OS. Issue : Apache not coming up

Executing service control script:

/prod/inst/apps/PROD_MYHOST02/admin/scripts/adapcctl.sh start

script returned:

****************************************************

ERROR : Timed out( 100000 ): Interrupted Exception

You are running adapcctl.sh version 120.7.12010000.2

Starting OPMN managed Oracle HTTP Server (OHS) instance ...

06/26/15-05:57:13 :: Removing gantt cache directory

****************************************************

Fix/Solution :

Login to apps(MT) node using applmgr user cd /prod/applmgr/common/webapps/oacore/html/cabo/images/cache

mv gantt gantt.26June2015

SQL> startup ORA-29702: error occurred in Cluster Group Service operation

Issue while startup database:

SQL> startup mount
ORA-29702: error occurred in Cluster Group Service operation
SQL> Disconnected
bash-3.2$



1> If already RAC and cluster service not running then

Solution-1 :
check if cluster services are up and running, if not please start the cluster services.


2> If it's non-RAC / after cloning /after copied binary to new(to configure standby) database.

Solution-2:
$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk rac_off
$make -f ins_rdbms.mk ioracle


Above will resolved issue for sure.

ORA-27101: Shared Memory Realm Does Not Exist

Cause: Unable to locate shared memory realm 

Action: Verify that the realm is accessible

Solution:

As root user allow the oracle user to lock the SGA into memory by typing:

"setprivgrp dba MLOCK

Procedure To Restore The Weblogic User Password On EBS 12.2 In Case Of Lost Or Forgotten Password

Applies to: Oracle Applications DBA - Version 12.2 to 12.2.4 [Release 12.2]

"If the Admin Password of an EBS WebLogic Domain is lost or forgotten"

Please follow the below steps:

An EBS WebLogic domain uses NodeManager to control AdminServer and managed server startup. For an EBS WebLogic domain, the NodeManager and WebLogic AdminServer passwords should be same. When changing the password for an EBS domain, care has to be taken to ensure that both the passwords remain the same, or the AD control scripts will not work properly.

If the AdminServer password has been lost or forgotten, it can be reset by carrying out the following steps should be carried out on the run file system. As described in the final step, an fs_clone operation should then be performed to bring the patch file system into sync.

1. Shut down all running services. Since the AdminServer password is not known, the servers cannot be stopped from the console and so must be killed as follows.

   A. Connect to the Oracle E-Business Suite instance and source the application tier environment file.

   B. Identify the PIDs of NodeManager, AdminServer, and all running managed servers:

  ps -ef | grep "NodeManager"
  ps -ef | grep "weblogic.Name=AdminServer"
  ps -ef | grep "weblogic.Name=forms-c4ws_server"
  ps -ef | grep "weblogic.Name=forms_server"
  ps -ef | grep "weblogic.Name=oafm_server"
  ps -ef | grep "weblogic.Name=oacore_server"

   C. Kill all these processes, starting with NodeManager and followed by the servers.

2. Back up these folders, then delete them:

   <EBS_DOMAIN_HOME>/security/ DefaultAuthenticatorInit.ldift
   <EBS_DOMAIN_HOME>/servers/<server_name>/data/ldap
   <EBS_DOMAIN_HOME>/servers/<server_name>/security/boot.properties
   <EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager/boot.properties

   Where:

   <EBS_DOMAIN_HOME> is the absolute path of the EBS WebLogic domain
   <server_name> is the name of the server directory under <EBS_DOMAIN_HOME>.

  If the password is not reset correctly, the backed up files and folders can be restored.

  Note: For certain servers, the boot.properties file may be present in only one location of the two specified above. In such a case, back it up and then delete it.

3. Set up a new environment to change the WLS AdminServer password.

   A. Start a new session and connect to the Oracle E-Business Suite instance.

   B. Do NOT source the application tier environment file.

   C. Source the WebLogic domain environment as per the following command:

         $ cd <EBS_DOMAIN_HOME>/bin
         $ source setDomainEnv.sh

   D. Run the following commands:

         $ cd <EBS_DOMAIN_HOME>/security
         $ java weblogic.security.utils.AdminAccount <wls_adminuser> <wls_admin_new_password> .

         Note: Do not omit the trailing period ('.') in the above command, to specify the current domain directory.

         Where:

         <wls_adminuser> is the same as the value of context variable s_wls_admin_user
         <wls_admin_new_password> is the new WLS AdminServer password you wish to set.

4. Start AdminServer from the command line. You will be prompted for the WebLogic Server username and password, so that the AdminServer boot.properties file can be generated.

    A. Go to the EBS Domain Home:

        $ cd <EBS_DOMAIN_HOME>

    B. Start AdminServer:

        $ java <s_nm_jvm_startup_properties> -Dweblogic.system.StoreBootIdentity=true -Dweblogic.Name=AdminServer weblogic.Server

        Where:

        <s_nm_jvm_startup_properties> is the same as the value of context variable ss_nm_jvm_startup_properties

        The above command prompts for the WebLogic Server username and password:

        Enter username to boot WebLogic server:
        Enter password to boot WebLogic server:

        Provide the same credentials as you provided in Step 3.

5. Change NodeManager password

    A. Log in to the WebLogic Administration console.

    B. Click the Lock & Edit button.

    C. In the left panel, click on the EBS Domain link.

    D. Select the Security tab.

    E. Click on the 'Advanced' link.

    F.  Edit the 'Node Manager password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.

    G. Edit the 'Confirm NodeManager Password' field and set it to the new WebLogic Server password. The password should be same as set in Step 3.

    H. Save and activate the changes.

6. Shut down AdminServer from the console. For the first time, AdminServer has to be stopped from the Admin console. Follow these steps: 

   A. Log in to the WebLogic Administration console.

   B. Shut down AdminServer.

7. Set up your environment to start AdminServer again. AdminServer should now be started using the normal AD script, which will also start NodeManager using the new password.

   A. Launch a new session and connect to the Oracle E-Business Suite instance.

   B. Source the application tier environment file.

   C. Start AdminServer with the following command:

       $ $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start

8. Start the managed servers. For the first time, all managed servers should be started from the WebLogic Server Admin console. This step will create boot.properties for the respective managed servers. Follow these steps:

    A. Log in to the WebLogic Server Administration Console

    B. Start all managed servers, one at a time

9. Shut down all the managed servers. This is so the new credentials will be picked up at the next startup. Follow these steps:

    A. Log in to the WebLogic Administration Server console.

    B. Shut down all managed servers.

    C. Shut down AdminServer.

10. Shut down NodeManager using the normal AD script.

  $ $ADMIN_SCRIPTS_HOME/adnodemgrctl.sh stop

11. Copy the boot.properties file for all managed servers.

  WebLogic Server native scripts use the boot.properties file from the the folder. The above steps have created the boot.properties file under, which is used by NodeManager. Copy the newly-generated      boot.properties file from <EBS_DOMAIN_HOME>/servers/<server_name>/data/nodemanager to <EBS_DOMAIN_HOME>/ servers/<server_name>/security.

  The EBS WebLogic Server domain password has now been changed, and all servers can now be started using the normal AD scripts.

  To start AdminServer:

  $ADMIN_SCRIPTS_HOME/adadminsrvctl.sh start

 To start the managed servers:

  $ $ADMIN_SCRIPTS_HOME/admanagedsrvctl.sh start

12. The above steps have changed the Oracle WebLogic AdminServer password on the run file system. You now need to perform an fs_clone operation, to change the WebLogic EBS domain password on the patch file system:

  A. Launch a new session and connect to the Oracle E-Business Suite instance.

  B. Source the application tier environment file.

  C. Run the command:

      $ adop phase=fs_clone

Known Issues

This section lists any known issues with the AutoConfig-related configuration management of Oracle E-Business Suite Release 12.2 environments.

Problem: On a multi-node installation with the Forms Services and Batch Processing Services enabled on separate nodes, OAM fails to update the context variables on the Batch Processing Services node.

Solution: Check whether the Listener Service is up on the Forms Services node.If the service is down, start the service using one of the following options:

Start the TNS listener service manually using the following command:

$ $INST_TOP/admin/scripts/adalnctl.sh start <TWO_TASK>

1. Enable the TNS Listener Service by following the steps mentioned earlier.

2. Stop all the application tier services using adstpall.sh
3. Start all the application tier services using adstrtal.sh

RMAN-06429 TARGET Database is not Compatible with this Version of RMAN

RMAN-06438: error executing package DBMS_RCVMAN in TARGET database

    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============
    RMAN-00571: ===========================================================
    RMAN-00554: initialization of internal recovery manager package failed
    RMAN-06429: TARGET database is not compatible with this version of RMAN

Cause:

The relevant message in this case is RMAN-06438 because package DBMS_RCVMAN   in target database is invalid

Solution:

 SQL>@?/rdbms/admin/dbmsrman.sql
 SQL>@?/rdbms/admin/prvtrmns.plb

RMAN upgrade catalog failed with RMAN-06429

Run RMAN command 'upgrade catalog' to upgrade the RMAN recovery catalog schema from 11.2.0.2 to 11.2.0.3, but experienced the following errors, as shown here.

RMAN-06429: RCVCAT database is not compatible with this version of RMAN

RMAN> upgrade catalog;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06441: cannot upgrade catalog - catalog is already newer than this RMAN

Reason: The 'DBMS_RCVMAN' body package is invalid, because there are two synonyms, namely, TDATT and TFATT, that points to two non-existing RMAN tables.

Solution:

Dropped the two synonyms, namely, TDATT and TFATT, and the RMAN command "upgrade catalog" is successfully completed without any errors.

RMAN-06217

RMAN-06217
not connected to auxiliary database with a net service name


Cause: A command that moves files from the target instance to the
       auxiliary instance was requested.  Such a command requires a
       net service name be present in the connect string used to
       connect to the auxiliary instance.

Action: Issue a CONNECT AUXILIARY command and include a net serice name
        in the connect string.  That service name must be valid on
        the target instance.


Solution:
rman target sys/<syspwd>@<OrclDBNameCaps>prim1 auxiliary sys/<syspwd>@<OrclDBNameCaps>stby

RMAN Restore and Recovery Scenarios

Restore and Recovery Scenarios

 

Full Database Restore

 

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup mount;

RMAN> restore database;

RMAN> recover database;

RMAN> alter database open;

database opened

 

Tablespace Restore (online)

 

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> sql 'alter tablespace users offline';

RMAN> restore tablespace users;

RMAN> recover tablespace users;

RMAN> sql 'alter tablespace users online';

* A SYSTEM tablespace cannot be recovered with the database online.

 

 

Tablespace Restore (offline)

 

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup mount;

RMAN> restore tablespace users;

RMAN> recover tablespace users;

RMAN> alter database open;

database opened

 

Restoring a Specific Datafile

 

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup mount;

RMAN> restore datafile '/oradata/DB1/dbf/users01.dbf';

RMAN> recover datafile '/oradata/DB1/dbf/users01.dbf';

RMAN> alter database open;

database opened

 

Control File Restoration

 

Prerequisite: In your rman backup directory determine the latest control file backup.

Default Format: c-nnnnnnnnnn-nnnnnnnn-nn

 

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup nomount;

RMAN> set dbid = 1184749195

RMAN> restore controlfile from '/oradata/DB1/rman/c-1184749195-20060626-02'

RMAN> alter database mount;

RMAN> restore database;

RMAN> recover database;

RMAN> alter database open resetlogs;

database opened

Database Point-In-Time-Recovery (PITR)

Also known as time-based incomplete recovery.

 

$ORACLE_HOME/bin/rman target / nocatalog

RMAN> shutdown abort;

RMAN> startup mount;

RMAN> restore database until time "to_date('09/03/07 13:00:00', 'MM/DD/YY HH24:MI:SS')";

RMAN> recover database until time "to_date('09/03/07 13:00:00', 'MM/DD/YY HH24:MI:SS')";

RMAN> alter database open resetlogs;

database opened

* Make sure you perform a full backup after this operation!

 

Restore to Another System

Prerequisites

Ideally ensure destination system configured exactly like source.

Same OS version and patch level.

Same drives (C:, D:, S: etc.).

CPU and RAM same or better.

The same version of Oracle is installed on the target system as the source.

Ensure the ORACLE_HOME and ORACLE_SID environment variables are set.

Ensure the listener is running.

 

Copy RMAN backupset files to the destination system rman directory.

 

If Windows:

Create the password file.

orapwd file=orapwDB1 password=mypassword

Creates the file %ORACLE_HOME%\dbs\orapwDB1

Copy %ORACLE_HOME%\dbs\orapwDB1 to %ORACLE_HOME%\database.

In some instances of a restore like this it may look for the file here.

Create or start the Windows database instance service.

oradim -new -sid DB1 -intpwd mypassword -startmode MANUAL

Creates the file: %ORACLE_HOME%\database\PWDDB1.ORA

Ensure the drive\path to the admin (adump,bdump,cdump,udump), data and redo directories on the source and destination systems are identical.

Example:

Admin Dump Directories

mkdir C:\oracle\product\10.2.0\admin 

mkdir C:\oracle\product\10.2.0\admin\DB1 

mkdir C:\oracle\product\10.2.0\admin\DB1\adump 

mkdir C:\oracle\product\10.2.0\admin\DB1\bdump 

mkdir C:\oracle\product\10.2.0\admin\DB1\cdump 

mkdir C:\oracle\product\10.2.0\admin\DB1\udump 

 

 

Data Directories

mkdir D:\oradata

mkdir D:\oradata\DB1

 

 

Redo and Archive Log Directories

mkdir D:\oradata\DB1\recovery1

mkdir D:\oradata\DB1\recovery2

 

 

Procedure

 

Restore SPFILE and Control File

%ORACLE_HOME%\bin\rman target / nocatalog 

RMAN> set dbid 161080442 

RMAN> startup nomount; 

      Creates the file: %ORACLE_HOME%\database\hc_db1.dat

RMAN> restore spfile from 'R:\rman\C-161080442-20080313-00'; 

      Creates the file: %ORACLE_HOME%\database\SPFILEDB1.ORA

RMAN> startup force nomount

RMAN> restore controlfile from 'R:\rman\C-161080442-20080313-00'; 

RMAN> shutdown immediate 

RMAN> exit 

 

 

Restore and Recover the Data

 

%ORACLE_HOME%\bin\rman target / nocatalog 

RMAN> startup mount; 

RMAN> restore database; 

      For a large database this step may take some time.

RMAN> recover database; 

      If you do not have\need the very last log(s) you can disregard any error messages.

      ORA-00310: archived log contains sequence 100; sequence 101 required...

RMAN> alter database open resetlogs; 

      database opened