How to Rollback / Revert the autoconfig changes in EBS

When ever we run autoconfig, the autoconfig log files are stored under the following locations.

On Database Tier:
$ORACLE_HOME/appsutil/log/$CONTEXT_NAME/<MMDDhhmm>

On Middle Tier:
$APPL_TOP/admin/$CONTEXT_NAME/log/<MMDDhhmm>


At the same time, all the backup configuration files from each autoconfig session are saved under following directories:

On Database Tier:
$ORACLE_HOME/appsutil/out/$CONTEXT_NAME/<MMDDhhmm>

On Middle Tier:
$APPL_TOP/admin/$CONTEXT_NAME/out/<MMDDhhmm>

There is also a script called restore.sh / restore.cmd under these locations along with backup configuration files.

We can run restore.sh (unix) or restore.cmd (windows) to revert back the autoconfig changes.

DMZ/External URL redirecting to Internal SSO login page

Issue :
In EBS 12.2, External URL pointing to SSO even though external node not registered with OID. Instead of pointing to SSO URL, external login URL should redirect to AppsLocalLogin.jsp

Cause: 
In EBS 12.2 and Later, intergration of SSO/OID/OAM/OIM can be done at site level only and not at server level. We can have a separate OID/OAM for external users and register the external node with the OID/OAM intended for external users.


Fix:
In all cases, since integration is done at site level, by default the external URL also redirects to SSO URL. To avoid that, update the s_login_page context variable on external node to point to http://hostname:port/OA_HTML/AppsLocalLogin.jsp.

In EBS 12.2 with DMZ, internal URL is redirecting to external and vice versa.

Issue : In EBS 12.2 with DMZ, internal URL is redirecting to external and vice versa.

Cause : When autoconfig has been run on internal, external and internal nodes; entries of external node are added in mod_wl_ohs.conf which is causing the URL to redirect while login.

Fix : Make sure the mod_wl_ohs.conf does not have entries of the external node in internal application tier and vice versa. Take a backup and remove them manually (if any).
And restart the services and check.

NID-00600: Internal Error - [30] [3113] [0] [0] and ORA-00600: internal error code, arguments: [control file RSBY_RDI/IC mismatch], [3], []

Issue:

Below errors are encountered when a renaming a standby database to use as cloned instance.

NID-00600: Internal Error - [30] [3113] [0] [0]
ORA-00600: internal error code, arguments: [control file RSBY_RDI/IC mismatch], [3], []


Symptoms:

Trying to convert standby to clone instance.

Cause:

Controlfile was created for standby and same controlfile is used during rename.

Fix:

Take a trace from the database.

Rename existing controlfiles.

Create fresh controlfiles from the trace.

Open the database with resetlogs.

 

ORA-19566: exceeded limit of 0 corrupt blocks for file "/u01/db/oracle/db/apps_st/data/system09.dbf" while taking rman backup for fresh install of 12.1.1.

Issue:

After a fresh Install of 12.1.1, trying to take RMAN backup which failed with below errors.

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 05/12/2013 11:49:40
ORA-19566: exceeded limit of 0 corrupt blocks for file /u01/db/oracle/db/apps_st/data/system09.dbf


Fix:

alter database datafile "/u01/db/oracle/db/apps_st/data/system09.dbf" resize 1000m;

dbv file=/u01/db/oracle/db/apps_st/data/system09.dbf

Re-initiate the backup.

perl adcfgclone.pl appsTier fails with coredump error on AIX

Issue:

On AIX server, perl adcfgclon.pl appsTier is failing with below errors.

$ perl adcfgclone.pl appsTier
Enter the APPS password [APPS]:


First Creating a new context file for the cloned system.
The program is going to ask you for information about the new system:

sh: 758236 Illegal instruction(coredump)
ERROR: context creation not completed successfully.
Please check /tmp/adcfgclone_1515866.err file for errors


$ cat  /tmp/adcfgclone_1515866.err
        stackpointer=2ff207f0
JVMXM004: JVM is performing abort shutdown sequence
JVMDG217: Dump Handler is Processing a Signal - Please Wait.
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to /u01/app/comn/clone/bin/javacore1413304.1369742403.txt
JVMDG215: Dump Handler has Processed Exception Signal 4.


Cause:

The cause of the issue is because the symbolic links were missing from either $IAS_ORACLE_HOME/appsoui/jre/1.3.1 or $COMMON_TOP directory.


Fix:

1. Go to /<COMMON_TOP>/clone/jre. 
2. mv lib lib.old 
3. mv bin bin.old 
4. ln -s jre/bin bin 
5. ln -s jre/lib lib 
6. Repeat the steps in $IAS_ORACLE_HOME/appsoui/jre/1.3.1 
7. Run the perl adcfgclone.pl AppsTier again.

Procedure to take backup and recover OCR and Voting Disks in RAC

To take backup of OCR Disk:

Execute below command to take backup of OCR Disks as root user:

10g:

# ocrconfig -export <OCR export_filename> -s online

11g:

# ocrconfig -manualbackup

To Take backup Voting Disk:

Pre-11g:

Execute below command as root user:

# dd if=voting_disk_name of=backup_file_name

11g:

For 11.2+, it is no longer required to back up the voting disk. The voting disk data is automatically
backed up in OCR as part of any configuration change. The voting disk files are backed up
automatically by Oracle Clusterware if the contents of the files have changed in the following ways:

Configuration parameters, for example misscount, have been added or modified
After performing voting disk add or delete operations
The voting disk contents are restored from a backup automatically when a new voting disk is added or
replaced.

To List the backup:

# ocrconfig -showbackup

To Recover using backup:

# ocrconfig -import <OCR export_filename>

To check the health of OCR:

# ocrcheck