Simple Clone Process in 11i/R12

Oracle Applications 11i/R12 Cloning Process
In normal cloning process, we do archive the Source node then copy the archived files to the Target node then extract the archived files back.
If you want to speed up this process, you can follow this one:
Example: Ine One step, we have to copy the ORACLE_HOME form Source Node (Prod) to Target Node (Test).
On the Target node create the ORACLE_HOME directory if it does not exist:
$ mkdir -p /u01/app/oracle/product/10.2.0./
On the Source node:
$ cd $ORACLE_HOME
$ tar cf – * | ssh TEST ‘(cd /u01/app/oracle/product/10.2.0./; tar xf – )’
on the Target node, you can check files are copying and extracting by giving:
$ cd /u01/app/oracle/product/10.2.0./db
$ ls -ltr
total 240
drwxr-x— 3 oracle dba 4096 Oct 25 20:38 jre
drwxr-x— 7 oracle dba 4096 Oct 25 20:38 javavm
drwxr-x— 3 oracle dba 4096 Oct 25 20:38 has
drwxr-x— 3 oracle dba 4096 Oct 25 20:38 diagnostics
drwxr-x— 3 oracle dba 4096 Oct 25 20:38 demo
drwxr-x— 6 oracle dba 4096 Oct 25 20:38 crs
drwxr-x— 4 oracle dba 4096 Oct 25 20:38 clone
drwxr-x— 7 oracle dba 4096 Oct 25 20:38 assistants
drwxr-x— 4 oracle dba 4096 Oct 25 20:49 jdbc

 Oracle Applications Multi Node To Single Node Cloning

With Oracle Applications 11.5.10, the ability to clone from a multi node to a single node system using rapid clone has now been certified.  This is accomplished by the Shared APPL_TOP and Merging APPL_TOP features.
For a more elaborate explanation you might want to refer to the metalink note Sharing the Application Tier File System in Oracle E-Business Suite 11i (Note 233428.1).
Source System here refers to the multi node system to be cloned
Target System refers to the newly to be created single node system
Applications Version 11.5.10
Operating System Linux ES 4
The following Steps are required to be performed on the source system
1.  Apply application tier patches using adpatch
Apply patch 4038964Apply patch 4175764
Both the above patches are include in the consolidated update 2 or CU2 so in case you are on 11.5.10.2 or later you can ignore this step.
2.  Maintain snapshot information
Log in as the applications user on each application tier node and run ‘Maintain Snapshot Information’ by using adadmin.
3.  Merge existing APPL_TOPs
Log in to the primary node of your application tier as the application user user and run:
$ cd [COMMON_TOP]/admin/scripts/[CONTEXT_NAME]
$ perl adpreclone.pl appsTier merge
This will prompt you with option to merge secondary nodes
Now log in as the applications user to each of the secondary application tier nodes being merged and run:
$ cd [COMMON_TOP]/admin/scripts/[CONTEXT_NAME]
$ perl adpreclone.pl appltop merge
4.  Prepare the source system database tier.
Log on to the database tier of the source system as the oracle user and run the following commands:
$ cd [RDBMS ORACLE_HOME]/appsutil/scripts/[CONTEXT_NAME]
$ perl adpreclone.pl dbTier
With this all the pre clone tasks on the source system have been completed.
The next set of tasks are required to be carried out on the target system that is the system on which you wish to place the merged single node instance.
1.  Create OS user accounts
Create a OS user account for your applications
$ useradd -g dba -d [home_directory] -p password username
Similarly create a OS user account for your database
2.  Modify the orainventory to reflect the new location
$ vi /etc/oraInst.loc
3.  Copy the following application tier directories
Copy the following application tier directories from the primary node of your source system to the target application tier node, retaining the original directory structure:
– [APPL_TOP]– [OA_HTML]– [OA_JAVA]– [COMMON_TOP/util]– [COMMON_TOP/clone>– [806 ORACLE_HOME]– [iAS ORACLE_HOME]
4.  Copy the required files for merging
Log in as the applications user to each of the secondary source nodes and recursively copy:
directory [COMMON_TOP]/clone/appl- to -directory [COMMMON_TOP]/clone/appl on the target system node
Before proceeding with the next steps you must shutdown your oracle applications services and the database on the source system
5. Copy the database tier file system
Log on to the source system as the database user
Copy the database (DBF) files from the source to the target systemCopy the source database ORACLE_HOME to the target system
After this you can now startup the database and applications services on your source system and release it for use.
6.  Configure the target system database server
Log on to the target system as the database user and type the following commands to configure and start the database:
$ cd [RDBMS ORACLE_HOME]/appsutil/clone/bin
$ perl adcfgclone.pl dbTier
This will prompt for new ORACLE_SID,ORACLE_HOME,Port Pool,JAVA_TOP and DATA_TOP give the appropriate values matching your target system
Once successful this should start your database and listener
7.  Configure the application tier server nodes
The database and its listener should remain up before executing the next set of commands.Log in to the merged APPL_TOP node as the applications user and execute the following commands:
$ cd [COMMON_TOP]/clone/bin
$ perl adcfgclone.pl appsTier
This will prompt you new port pool for applictaion tier services as well as new APPLTOP,COMMON_TOP,ORACLE_HOME and IAS_TOP
Successful completion of this task will bring up your application tier services on the target or the cloned node.
8. Post Clone Tasks
Log in to the target system application tier node as the APPLMGR user.Run the following tasks in adadmin for all products:o generate JAR fileso generate message fileso relink executableso copy files to destination
9. Clean up of the target system
Remove the temporary directory [COMMON_TOP]/clone/appl to reduce disk space usage.
Note: The version of Oracle Applications used is 11.5.10 and the operating system is Linux ES 4

How to clean FND_NODES table in Oracle Applications
Step 1:   Always apply the latest cloning patches to avoid all the bugs and fixes
Step 2:  SQL> EXEC FND_CONC_CLONE.SETUP_CLEAN;
COMMIT;
EXIT;
It will delete all old data from the table.
Step 3:  Run AutoConfig on all tiers, firstly on the DB tier and then the APPS tiers to repopulate the required system tables.

Oracle Applications Cloning Issues:
1.  While running adpreclone on EBS , APPS user locked continiously.
Soultion – Follow metalink Note Id – ID 420001.1
2.  PDF output problem in Instance. No PDF output produced after cloning .
Solution – Follow metalink Note Id ID 981163.1
3.  Got this in alert.log WARNING: Oracle executable binary mismatch detected.
Solution – Follow the metal…ink Note ID – 369260.1.
4.  After cloning, forms will not launch.
Performed the below Steps:
EXEC FND_CONC_CLONE.SETUP_CLEAN;
commit;
Run the cmclean.sql scripts
Run Autoconfig on all nodes.(DB+CM+WEB Nodes)
5.  After cloning Purge Concurrent Request and/or Manager Data request status alway is running , it is not completing.
As per Metalink ID 1016766.102 ( OS Files are Purged from Wrong Instance when Running Purge Concurrent Requests),It is because of
FNDCPPUR is trying to delete files it can’t access because they are belonging to the original environment.
The following table and columns still contain PATH referencing the original environment :
FND_CONCURRENT_REQUESTS.LOGFILE_NAME
FND_CONCURRENT_REQUESTS.OUTFILE_NAME
Perform the below Steps:
a) Stop the concurrent managers.
b) Start a SQL*Plus session as APPLSYS.
c) Issue the following commands:
TRUNCATE TABLE fnd_concurrent_requests;
TRUNCATE TABLE fnd_concurrent_processes;
UPDATE fnd_concurrent_queues
SET running_processes = 0,
max_processes = 0;
COMMIT;
d) Exit the SQL*Plus session.
e) Restart the concurrent managers.
6.  While running adcfgclone.pl getting the Inventory problem , so enter the correct entry in /etc/oraInst.loc location.
7.  After starting the services , the listener will not coming up because of missing listener.ora file in $TNS_ADMIN location.
Solution:
Then Stop the APPS Services ./adstpall.sh apps/<appspwd>
run the Autoconfig . ./adautocfg.sh
Then start the APPS Services ./adstrtal.sh apps/<appspwd>

Reducing Patching Downtimes for Apps

Reducing Patching Downtimes for Apps

How to reduce patching downtime in oracle apps??
One of the most commonly-cited reasons for not patching E-Business Suite environments is that it takes too much downtime.  If you’re relatively new to Apps system administration, here’s a primer on the key techniques compiled by our Applications Release Engineering group for reducing patching downtimes.  Although some of the linked documents are …written specifically for Release 11i, these techniques may be used for both Apps 11i and 12.

1. Use a staged applications system.  This major time-saver hinges on a key principle:  all of your applications filesystem patches are applied to aclone of your production Apps environment.  This can be done while your production system is still running.  Your production system is down only for the time needed to apply database patches.  For details, see:
2. • Using a Staged Applications System to Reduce Patching Downtime [Release 11i] (Note 242480.1)
   • Using a Staged Applications System to Reduce Patching Downtime in Oracle E-Business Suite Release 12 (Note 734025.1)
3. Use a shared application-tier file system.  If you have a pool of application-tier servers set up for load-balancing, make sure that all of the individual servers share a single application filesystem.  Patches applied to this central shared filesystem are instantly available to all application-tier servers.  I’ve previously given an overview of this technique in this article.
4. Distribute worker processes across multiple servers.  When applying a patch that includes a large number of processes, you can reduce the downtime even further by distributing the worker processes across multiple servers on multiple nodes. Using the Distributed AD feature of AutoPatch and AD Controller, you can assign workers to run on the primary node and on other nodes that share the filesystem. See:  Distributed AD (Metalink Note 236469.1)
5. Merge multiple patches using AD Merge Patch.  Merging patches saves time because the AutoPatch overhead of starting a new session is eliminated for those patches that are consolidated.  Duplicate linking, generating or database actions are run once only.  If two patches update the same file, AD Merge Patch will save time by applying only the latest one.  Patches can — and should — be merged with their listed prerequisite patches.For more details about this AD utility, see the Oracle Applications Maintenance Procedures guide for your Apps release.
6. Run AD Patch in non-interactive mode .  Applying a set of patches using AD Patch in non-interactive mode eliminates the delay between successive tasks.
7. Defer system-wide database tasks until the end.  Using adpatch options=nocompiledb,nomaintainmrc defers system-wide database tasks such as “Compile APPS schema” and “Maintain MRC” until after all patches have been applied.  As of AD.H, AutoPatch automatically compiles the APPS schema and maintains MRC when applying standard patches.
8. Avoid resource-related bottlenecks.  Patching can grind to a halt if you bump into the ceiling on your system.  Before patching, make sure that you’ve enabled automatic tablespace management, and that you have sufficient hardware and free disk and temp space.

The cumulative downtime reductions of all of these techniques can be quite significant.  I’ve touched on some of the biggest timesavers, but this short article isn’t comprehensive, by any means.  The linked Notes in this article and below discuss a number of other tips for shrinking your patching downtimes.  A small investment in learning these techniques can pay off in large reductions in patching times, and is well worth your time.

OPATCH AND IT’S OPTIONS

How to apply database opatch?
How to apply opatch in oracle database
This post will explain about OPATCH and it’s options.
What is Opatch?
OPatch is a java based utility.
How to check the Opatch version?
$ ./opatch version
Invoking OPatch 10.2.0.3.0
OPatch Version: 10.2.0.3.0
OPatch succeeded.
How to know which version is the correct version of Opatch for your RDBMS home?
You can verify whether the Opatch version for your RDBMS release is correct or not using metalink note ID 357221.1.
This note ID gives the copatibilities between OPatch version and RDBMS version.
How to get the latest version of OPatch?
You can download the latest version of OPatch from metalink using following URL.
http://updates.oracle.com/download/6880880.html
In the release dropdown you can select the OPatch release that you want to download based on your RDBMS version. Please read the README.txt before applying the patch.
Opatch help
You can get all the options using opatch -help
$ ./opatch -help
Invoking OPatch 11.1.0.6.0
Oracle Interim Patch Installer version 11.1.0.6.0
Copyright (c) 2007, Oracle Corporation.  All rights reserved.
Usage: opatch [ -help ] [ -r[eport] ] [ command ]
apply
lsinventory
prereq
query
rollback
util NApply
version
<global_arguments> := -help       Displays the help message for the command.
-report     Print the actions without executing.

example:
‘opatch -help’
‘opatch apply -help’
‘opatch lsinventory -help’
‘opatch prereq -help’
‘opatch rollback -help’
‘opatch util -help’

‘opatch util NApply-help

How to apply a single patch using opatch

You MUST read the Readme.txt file included in opatch file, look for any prereq. steps/ post installation steps or and DB related changes. Also, make sure that you have the correct opatch version required by this patch.

Make sure you have a good backup of database.

Make a note of all Invalid objects in the database prior to the patch.

Shutdown All the Oracle Processes running from that Oracle Home , including the Listener and Database instance, Management agent etc.

You MUST Backup your oracle Home and Inventory

Unzip the patch in $ORACLE_HOME/patches

If you are applying a single intrim patch to oracle home, then change the location to the directory of that patch and then invoke following command.
Example if I need to apply patch 6972343 to RDBMS Oracle Home
-bash-3.00$ cd 6972343
-bash-3.00$ pwd
/slot/ems2029/oracle/db/tech_st/11.1.0/patches/6972343
-bash-3.00$ ls
etc  files  README.txt
$ORACLE_HOME/OPatch/opatch apply
If you have created local inventory then you need to give the correct path for local inventory stored in oraInst.loc. If you have updated /etc/oraInst.loc with correct location of your inventory, then above command will work, If not you can give the correct location by giving local oraInst.loc file.
$ORACLE_HOME/OPatch/opatch apply -invPtrLoc /slot/ems2029/oracle/db/tech_st/11.1.0/oraInst.loc
Remember that when we are applying patch, patch number is NOT provided as an input to opatch command. So we have to to be in the directory of patch since opatch will pick the patch files from current directory.
Rolling back a patch
In case if a patch did not fix the issue or if you has applied wrong patch to oracle home, you can always rollback the patch using following comamnd.
opatch rollback -id <Patch Number>
Applying bundle patches
Some times if you have to apply bundle patch having many patches, example lets say you want to a bundle patch 6778860 (11.1.0.6 BUNDLED PATCH FOR EBS 11I)) containing many other patches to RDBMS home, OPatch provides a facility to apply many patches to RDBMS home using a single comamnd. Following command should be used for applying bundle patches.
Download the patch and extract the same. You will see many directories (one for each patch) inside the main patch directory. Execute following command to apply all patches.
$ORACLE_HOME/OPatch/opatch util NApply -invPtrLoc /slot/ems2029/oracle/db/tech_st/11.1.0/oraInst.loc
NApply -> Will apply all patches to RDBMS home.
You can also use -phBaseDir to point to the directory where bundle patch is installed. So you can run opatch command from any location
$ORACLE_HOME/OPatch/opatch util NApply -phBaseDir /slot/ems2029/oracle/db/tech_st/11.1.0/patches/6778860 -invPtrLoc /slot/ems2029/oracle/db/tech_st/11.1.0/oraInst.loc
You can also apply specific patches using NApply
opatch util napply <patch_location> -id 1,2,3 -skip_subset -skip_duplicate
This will apply patches 1, 2, and 3 which are under < the patch_location> directory. OPatch will skip duplicate patches and subset patches (patches under <patch_location> that are subsets of patches installed in the ORACLE_HOME)
You can see all the options for NApply using following help command.
$ORACLE_HOME/OPatch/opatch util NApply -help
Query the inventory for patches applied
We can query the inventory to check various components installed for database as well as to check various patches applied to database. Use following command to get a minimum information from inventory about patches applied and components installed.
$ORACLE_HOME/OPatch/opatch lsinventory -invPtrLoc /slot/ems2029/oracle/db/tech_st/11.1.0/oraInst.loc
Patch  5763576      : applied on Wed May 28 03:20:53 PDT 2008
Created on 6 Feb 2008, 02:26:04 hrs PST8PDT
Bugs fixed:
5763576
If you are using central inventory then -invPtrLoc variable is not required.
You can also get the detailed view of inventory using following command. In case of detail information it gives which are the files that this patch have touched.
$ORACLE_HOME/OPatch/opatch lsinventory -detail -invPtrLoc /slot/ems2029/oracle/db/tech_st/11.1.0/oraInst.loc
Patch  6318357      : applied on Wed May 28 03:33:27 PDT 2008
Created on 4 Dec 2007, 22:02:16 hrs PST8PDT
Bugs fixed:
6318357
Files Touched:
udjvmrm.sql –> ORACLE_HOME/javavm/install/udjvmrm.sql
Patch Location in Inventory:
/slot/ems2029/oracle/db/tech_st/11.1.0/inventory/oneoffs/6318357
Patch Location in Storage area:
/slot/ems2029/oracle/db/tech_st/11.1.0/.patch_storage/6318357_Dec_4_2007_22_02_16
Which options are installed in Oracle Home?
You can check the options installed in RDBMS home using above command. The options installed will be listed at the start of output.
Example: $ORACLE_HOME/OPatch/opatch lsinventory -detail -invPtrLoc /slot/ems2029/oracle/db/tech_st/11.1.0/oraInst.loc
The complete output of this command can be seen at this location.
Opatch Log files
Log file for Opatch utility can be found at $ORACLE_HOME/cfgtoollogs/opatch

How to merge Oracle Applications patches

How to merge Oracle Applications patches
Merging apps patches will be useful when you want to reduce the downtime for patch application
Simple steps to merge two patches.
1.  Download two required apps patches (Patch1.zip) and (Patch2.zip).
2.  Create one source directory (for e.g. source)
3.  Unzip two apps patches into src directory.
4.  Create one destination directory (for e.g. destination)
5.  Source the Apps env and issue the following command.
6.  Perl <ad_top>/bin/admerge.pl –s source –d destination
7.  Patch is merged and created u_merged.drv.
Use this u_merged.drv file for adpatch application