This is a quick note to share a SQL that will tell you the FND_USER.USER_NAME of the person that has locked a given table in Oracle APPS.
The column named "module" will tell you the name of the Form Function or the Concurrent Program Short name which has aquired a lock onto that table.
SELECT c.owner
,c.object_name
,c.object_type
,fu.user_name locking_fnd_user_name
,fl.start_time locking_fnd_user_login_time
,vs.module
,vs.machine
,vs.osuser
,vlocked.oracle_username
,vs.sid
,vp.pid
,vp.spid AS os_process
,vs.serial#
,vs.status
,vs.saddr
,vs.audsid
,vs.process
FROM fnd_logins fl
,fnd_user fu
,v$locked_object vlocked
,v$process vp
,v$session vs
,dba_objects c
WHERE vs.sid = vlocked.session_id
AND vlocked.object_id = c.object_id
AND vs.paddr = vp.addr
AND vp.spid = fl.process_spid(+)
AND vp.pid = fl.pid(+)
AND fl.user_id = fu.user_id(+)
AND c.object_name LIKE '%' || upper('&tab_name_leaveblank4all') || '%'
AND nvl(vs.status
,'XX') != 'KILLED';
Wednesday, June 11, 2008
Types of Apps Tables
There are following tables :
_ALL Conatains multi org data before using this table you need to set client_into to
specific org , Org_id is common column.
_V view created on base table
_VL view created on multi language tables.
always use the condition LANGUAGE = USERENV(’LANG’).
_TL Tables support multi language.
_B These Main base tables
_F these date tracked tables for only in HRMS and these table contain 2 common
columns effective_start_date and effective_end_date .
_S sequence related tables .
_AVN Audit view shadow tables contains data track information .
_ALL Conatains multi org data before using this table you need to set client_into to
specific org , Org_id is common column.
_V view created on base table
_VL view created on multi language tables.
always use the condition LANGUAGE = USERENV(’LANG’).
_TL Tables support multi language.
_B These Main base tables
_F these date tracked tables for only in HRMS and these table contain 2 common
columns effective_start_date and effective_end_date .
_S sequence related tables .
_AVN Audit view shadow tables contains data track information .
Tracing Jinitiator
Some times Jinitiator raises exception .You can figure it out by using Trace Jinitiator
Step 1: Windows select Start - Settings - Control Panel – Jinitiator
Step 2: Enter following in the "java Run Time parameters”
textfield:
-Djavaplugin.trace=true
-Djavaplugin.trace.option=basicnetsecurityextliveconnect.
Step 3: Restart Your Machine
You can see the trace file information under C:\Documents and Settings\jinitiator. Trace
Step 1: Windows select Start - Settings - Control Panel – Jinitiator
Step 2: Enter following in the "java Run Time parameters”
textfield:
-Djavaplugin.trace=true
-Djavaplugin.trace.option=basicnetsecurityextliveconnect.
Step 3: Restart Your Machine
You can see the trace file information under C:\Documents and Settings\jinitiator. Trace
How to get Version of Programs, Files, and Objects
1) ORACLE APPLICATIONS
To obtain version of form from any applications form, navigate to the form. Then in the Menu toolbar
select Help => About Oracle Applications.
Or
Run the following statement
select release_name from fnd_product_group;
2) DATABASE OBJECTS
select text from user_source where name='&package_name' and text like '%$Header%';
You can also obtain the pls version on the database by running:
select name, text
from dba_source
where text like '%.pls%'
and line
VIEWS
select VIEW_NAME, TEXT
from
USER_VIEWS
where VIEW_NAME = '&VIEW_NAME';
Oracle Workflow
$FND_TOP/sql/wfver.sql
OR
select TEXT from WF_RESOURCES where NAME='WF_VERSION';
UNIX : uname -a
WINDOWS : Start => Parameters => Control Panel => System
JAVA
java -version
sqlplus
start=>Run=>cmd
sqlplus
TNSPING
start=>Run=>cmd
TNSPING
D2k version
ORACLE_HOME\Orainst\nt.rgs
File versions
On Unix: strings -a "File name" | grep Header
On Windows : find "Header" File_name
To obtain version of form from any applications form, navigate to the form. Then in the Menu toolbar
select Help => About Oracle Applications.
Or
Run the following statement
select release_name from fnd_product_group;
2) DATABASE OBJECTS
select text from user_source where name='&package_name' and text like '%$Header%';
You can also obtain the pls version on the database by running:
select name, text
from dba_source
where text like '%.pls%'
and line
VIEWS
select VIEW_NAME, TEXT
from
USER_VIEWS
where VIEW_NAME = '&VIEW_NAME';
Oracle Workflow
$FND_TOP/sql/wfver.sql
OR
select TEXT from WF_RESOURCES where NAME='WF_VERSION';
UNIX : uname -a
WINDOWS : Start => Parameters => Control Panel => System
JAVA
java -version
sqlplus
start=>Run=>cmd
sqlplus
TNSPING
start=>Run=>cmd
TNSPING
D2k version
ORACLE_HOME\Orainst\nt.rgs
File versions
On Unix: strings -a "File name" | grep Header
On Windows : find "Header" File_name
Tracing TNS Entries Through Oracle Applications
When u login into Apps Page ..
Step 1: Click on About link Page.
Step 2: Click on Page Context Tab
You will Get following Information.
1) Data base Name (Hostname)
2) Port no#
3) SID Name
Step 4: Build Tns Entries With following method and Paste it in local machine
Try to connect with default Password apps/apps
"SID"=
(DESCRIPTION =
(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = "Host Name")
(PORT = "Port number")) )
(CONNECT_DATA =
(SERVICE_NAME ="SID" )
) )
Connect with Default username/password : APPLSYSPUB/PUB
This username/password is hard-coded in FND_TOP/secure/appsweb.cfg file.
Once you get the DataBase access Use following Select statement gets the front URL access.
select HOME_URL from icx_parameters
You will get Front-end access login Screen.
By useing APPS.FND_WEB_SEC package change the SYSADMIN or user password At SQL Prompt.
Example 1:
--Change Sysadmin Password from PL/SQL
set serverout on
declare
ret varchar2(200);
begin
ret := fnd_web_sec.change_password('SYSADMIN',
'Welcome1);
dbms_output.put_line('Result of Package'ret);
---Y Means Success Else Fail.
end;
Commit;
Step 4: Finally Click on Java System Properties Scroll Down the Page. Your able to see the Unix Login user name(Back End User Access)
Step 5:Try to connect unix server with Default Password.
Step 1: Click on About link Page.
Step 2: Click on Page Context Tab
You will Get following Information.
1) Data base Name (Hostname)
2) Port no#
3) SID Name
Step 4: Build Tns Entries With following method and Paste it in local machine
Try to connect with default Password apps/apps
"SID"=
(DESCRIPTION =
(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)
(HOST = "Host Name")
(PORT = "Port number")) )
(CONNECT_DATA =
(SERVICE_NAME ="SID" )
) )
Connect with Default username/password : APPLSYSPUB/PUB
This username/password is hard-coded in FND_TOP/secure/appsweb.cfg file.
Once you get the DataBase access Use following Select statement gets the front URL access.
select HOME_URL from icx_parameters
You will get Front-end access login Screen.
By useing APPS.FND_WEB_SEC package change the SYSADMIN or user password At SQL Prompt.
Example 1:
--Change Sysadmin Password from PL/SQL
set serverout on
declare
ret varchar2(200);
begin
ret := fnd_web_sec.change_password('SYSADMIN',
'Welcome1);
dbms_output.put_line('Result of Package'ret);
---Y Means Success Else Fail.
end;
Commit;
Step 4: Finally Click on Java System Properties Scroll Down the Page. Your able to see the Unix Login user name(Back End User Access)
Step 5:Try to connect unix server with Default Password.
Oracle APPS Password Security
Oracle applications 11i Implementations has a Security weakness. Oracle application 11i passwords are stored in the database. Apps password stores in2 tables: FND_USER and FND_ORACLE_USERID tables Stores internal oracle applications database accounts. The APPS and APPLSYS database accounts must always have the same password
The APPS.fnd_user table has all applications accounts and there Are 2 Password columns provide for ENCRYPTION.
ENCRYPTED_FOUNDATION_PASSWORD
ENCRYPTED_USER_PASSWORD
The above 2 columns any also contains 1 of the String Values
1.External: Means User Authentication is Delegated So password is not stored in the FND_USER Table
2.INVALID Some Default Oracle apps Accounts access is blocked by directly updating the FND_USER Table.
3.X Means like INVALID
4.ZG If the Encryption Algorithm fails the Error MSG is stord in password column
The Passwords in FND_ORACLE_USERID maintained independent of the database, So Any changes to the account passwords using ALTER USER statements not reflect in the table. If you want change the passwords in FND_ORACLE_USERID can done by utility called FNDCPASS or sysadmin “ORACLE Form”
The Oracle Application passwords can be 1 to 100 chars length and longer Passwords are truncated at 100 Chars.
Oracle Apps passwords Encryption done by APPS.FND_WEB_SEC Or JAVA Class Oracle.apps.fnd.security.websessionManagerProc
Oracle.apps.fnd.security.AolSecurity
Oracle.apps.fnd.security.AolSecurityPrivate
You can find this class information at $JAVA_TOP Directory.
You can download the class and Using Java class Converter You can see how the code is written. The Actual Encryption and Decryption calls are in the “oracle.apps.fnd.security.AolSecurityPrivate” Java class. The Guest account Password is stores in System Profile. You can get by using
Select APPS.FND_PROFILE.VALUE('GUEST_USER_PWD') from dual.
The APPS.fnd_user table has all applications accounts and there Are 2 Password columns provide for ENCRYPTION.
ENCRYPTED_FOUNDATION_PASSWORD
ENCRYPTED_USER_PASSWORD
The above 2 columns any also contains 1 of the String Values
1.External: Means User Authentication is Delegated So password is not stored in the FND_USER Table
2.INVALID Some Default Oracle apps Accounts access is blocked by directly updating the FND_USER Table.
3.X Means like INVALID
4.ZG If the Encryption Algorithm fails the Error MSG is stord in password column
The Passwords in FND_ORACLE_USERID maintained independent of the database, So Any changes to the account passwords using ALTER USER statements not reflect in the table. If you want change the passwords in FND_ORACLE_USERID can done by utility called FNDCPASS or sysadmin “ORACLE Form”
The Oracle Application passwords can be 1 to 100 chars length and longer Passwords are truncated at 100 Chars.
Oracle Apps passwords Encryption done by APPS.FND_WEB_SEC Or JAVA Class Oracle.apps.fnd.security.websessionManagerProc
Oracle.apps.fnd.security.AolSecurity
Oracle.apps.fnd.security.AolSecurityPrivate
You can find this class information at $JAVA_TOP Directory.
You can download the class and Using Java class Converter You can see how the code is written. The Actual Encryption and Decryption calls are in the “oracle.apps.fnd.security.AolSecurityPrivate” Java class. The Guest account Password is stores in System Profile. You can get by using
Select APPS.FND_PROFILE.VALUE('GUEST_USER_PWD') from dual.
Load Balancer in Oracle Apps 11i , E-Business Suite
What is Load Balancer in Oracle Applications 11i ?
As name suggest its used to balance load on oracle applications, so lets say you initially sized (How to size server configuration in your apps 11i Instance during Implementation coming soon..) your server for 100 concurrent users & now additional 90 users started using your system , you can configure one more Application Tier node & distribute load of 190 users across two application tier node by configuring load balancer (Currently I am discussing only about Application Tier & once you are comfortable with Middle Tier I'll discuss on database tier)
Why I need load balancer in Apps 11 ?
Is Increased load only reason for introducing load balancer in Apps 11i , No not at all . There are other reasons as well like (These are more advanced reasons & if you don't understand don't worry read it for understanding purpose at this minute)
- You want to Hide Server Name so instead of users accessing it via http://hostname:port you want users to access by http://somefancyname.com use load balancer (I know you can do this by various other ways as well like reverse proxy, via dns ..)
- You want on some node only web server & some both form server & web server
and there can lot of other reason why you need load balancer (May be you want to put it in your CV that you know how to configure load balancer, I know this is stupid reason :) )
What is Role of Load balancer in Oracle Application 11i ?
Usually load balancer act as mediator in passing your request to respective Middle Tiers (Usually web server ), so lets say you have configured load balancer in front of two middle tier which are part of your Applications 11i lets call them MT1 & MT2 . Load balancer will accept client's request and pass on to MT1 & MT2 ( round robin or the way you have configured load balancer, you here is Unix Administrators)
What are different kind of load balancer ?
Session Persistent - These kind of load balancers assign request from a client to same Application Tier. so lets say user1 tried connecting applications via load balancer and LB sent that request to MT1 then in future LB will send requests from user1 always to MT1 for time being specified in session persistence duration parameter specified in LB configuration or till user logs out from Applications. This property is called as Stickness or sticky Bit
Non Session Persistent - These kind assign request to MT in round robin way so lets assume user1 requested for login page , LB sends this request to MT1 then user1 again clicked on user responsibility and this time LB sent request from user1 to second middle tier i.e. MT2
Other types of LB, I am not discussing here as these are not required at this minute
What all different kind of load balancing options available in Oracle 11i ?
DNS Level Load Balancing ( Check image at top , this represent DNS level LB)
HTTP Layer Load balancing (You need hardware load balancer which accepts http requests)
Jserv Load balancing (This is example of software load balancer, via mod_oprocmgr Process Manager Module)
Forms level load balancing - Jserv load balancing via forms servlets (More coming in future) , forms metrics server adfmsctl.sh
This is HTTP Server level Hardware Load balancer.
Before configuring Load balancer in Oracle Apps , you should be familiar with following technologies
1. Cloning
Check my previous post to know about cloning
Cloning Basics
Cloning Part I
Cloning Part II
Metalink Note # 230672.1 Cloning Oracle Applications Release 11i with Rapid Clone
2. Load Balancer Basics
Check my previous post for Over of Load balancer
Load Balancer Overview
3. Autoconfig
Check About Autoconfig on My Site
Metalink Note 165195.1 Using AutoConfig to Manage System Configurations with Oracle Applications 11i
Broad Level steps for configuring Hardware Load balancer at HTTP Server layer
A. Configure Hardware Load Balancer for Session Persistence
B. Apply Prereq. Patch (If you are not on 11.5.10 or higher)
C. Add additional Web Node using Rapid Clone
D. Configure Load balancer on Node1
E. Test Load balancer via Node1
F. Configure Load balancer on Node2
G. Test Load balancer via Node2
H. Test Load balancer is sending requests to both nodes when both Web Nodes are Up
Yesterday I posted that you need extra attention while configuring Load balancer at HTTP layer is about Session Persistence - Hardware level Load Balancer should be configured for session persistence also called as stickness or sticky bit for Oracle Apps 11i . If this is not set & lets assume client1 first request went to Node1 after authentication if next request for client1 goes to Node2 who is not aware of client1 's previous request will throw authentication again. Don't worry about how to set it, ask vendor or Unix Administrator to set sticky bit or session persistence .
Now you have broad overview of configuring Load balancer at HTTP layer, I'll discuss in detail why you need to apply above patches & what all step by step configuration and parameters which needs to be changed and reasoning behind those changes . Till then check for Cloning, Autoconfig.
I am going to cover most common load balancer setup in Oracle Apps 11i i.e. Setup Two or more Middle tier with Web Server & Form Server with Hardware Load balancer in front of middle tier . This type of setup is also called as "HTTP Layer Hardware Load balancing" in Oracle Applications.
For overview & basics of Load balancing visit my previous post at
http://becomeappsdba.blogspot.com/2006/09/configure-load-balancer-in-oracle-apps.html
http://becomeappsdba.blogspot.com/2006/09/configure-hardware-load-balancer-at.html
Below are steps you need to follow to configure Multiple Middle Tier (Web & Forms Server ) with Hardware Load balancer in front.
1. Setup a Load balancer such that it forwards requests to first middle tier only.
2. Make sure sticky bit is set on load balancer for session persistence (Check Load balancer documentation), You can Network level switch as well to send requests to multiple middle tier
3. Apply Prereq. patches (3175852, 3077386, 3209878)
4. Edit following entry in XML or Context File directly ($APPL_TOP/admin/$CONTEXT_NAME.xml) or via Oracle Application Manager
-- 4.1 "Web entry point Host" to the HTTP load-balancer machine name
-- 4.2 "Web entry point Domain" to the HTTP load-balancer domain name
-- 4.3 "Web entry protocol" to the HTTP load-balancer protocol e.g. "http" or "https"
-- 4.4 "Active Web Port" to the value of the HTTP load-balancer's external port
-- 4.5 "Login Page" to include "Web entry protocol"://"Web Host entry point"."Web domain entry point":"Active Web Port"
-- 4.6 "disco_machine" to load balancer machine
5. Run Autoconfig
6. Start Services & check if you can login to applications via Load balancer
7. Now clone this middle tier to another node (where you want to add another node)
8. Make sure above parameter are pointing to load balancer in second node as well
9. Change load balancer to point to second node only
10. shutdown services on first node
11. try accessing application from second node (you should be able to access application without issues)
11.1 -- If forms are not opening properly , check "ICX Form Launcher .." Profile option should point to load balancer
12. Now start application on both middle tier
13. Point load balancer to both middle tier
14. You should be able to access applications
As name suggest its used to balance load on oracle applications, so lets say you initially sized (How to size server configuration in your apps 11i Instance during Implementation coming soon..) your server for 100 concurrent users & now additional 90 users started using your system , you can configure one more Application Tier node & distribute load of 190 users across two application tier node by configuring load balancer (Currently I am discussing only about Application Tier & once you are comfortable with Middle Tier I'll discuss on database tier)
Why I need load balancer in Apps 11 ?
Is Increased load only reason for introducing load balancer in Apps 11i , No not at all . There are other reasons as well like (These are more advanced reasons & if you don't understand don't worry read it for understanding purpose at this minute)
- You want to Hide Server Name so instead of users accessing it via http://hostname:port you want users to access by http://somefancyname.com use load balancer (I know you can do this by various other ways as well like reverse proxy, via dns ..)
- You want on some node only web server & some both form server & web server
and there can lot of other reason why you need load balancer (May be you want to put it in your CV that you know how to configure load balancer, I know this is stupid reason :) )
What is Role of Load balancer in Oracle Application 11i ?
Usually load balancer act as mediator in passing your request to respective Middle Tiers (Usually web server ), so lets say you have configured load balancer in front of two middle tier which are part of your Applications 11i lets call them MT1 & MT2 . Load balancer will accept client's request and pass on to MT1 & MT2 ( round robin or the way you have configured load balancer, you here is Unix Administrators)
What are different kind of load balancer ?
Session Persistent - These kind of load balancers assign request from a client to same Application Tier. so lets say user1 tried connecting applications via load balancer and LB sent that request to MT1 then in future LB will send requests from user1 always to MT1 for time being specified in session persistence duration parameter specified in LB configuration or till user logs out from Applications. This property is called as Stickness or sticky Bit
Non Session Persistent - These kind assign request to MT in round robin way so lets assume user1 requested for login page , LB sends this request to MT1 then user1 again clicked on user responsibility and this time LB sent request from user1 to second middle tier i.e. MT2
Other types of LB, I am not discussing here as these are not required at this minute
What all different kind of load balancing options available in Oracle 11i ?
DNS Level Load Balancing ( Check image at top , this represent DNS level LB)
HTTP Layer Load balancing (You need hardware load balancer which accepts http requests)
Jserv Load balancing (This is example of software load balancer, via mod_oprocmgr Process Manager Module)
Forms level load balancing - Jserv load balancing via forms servlets (More coming in future) , forms metrics server adfmsctl.sh
This is HTTP Server level Hardware Load balancer.
Before configuring Load balancer in Oracle Apps , you should be familiar with following technologies
1. Cloning
Check my previous post to know about cloning
Cloning Basics
Cloning Part I
Cloning Part II
Metalink Note # 230672.1 Cloning Oracle Applications Release 11i with Rapid Clone
2. Load Balancer Basics
Check my previous post for Over of Load balancer
Load Balancer Overview
3. Autoconfig
Check About Autoconfig on My Site
Metalink Note 165195.1 Using AutoConfig to Manage System Configurations with Oracle Applications 11i
Broad Level steps for configuring Hardware Load balancer at HTTP Server layer
A. Configure Hardware Load Balancer for Session Persistence
B. Apply Prereq. Patch (If you are not on 11.5.10 or higher)
C. Add additional Web Node using Rapid Clone
D. Configure Load balancer on Node1
E. Test Load balancer via Node1
F. Configure Load balancer on Node2
G. Test Load balancer via Node2
H. Test Load balancer is sending requests to both nodes when both Web Nodes are Up
Yesterday I posted that you need extra attention while configuring Load balancer at HTTP layer is about Session Persistence - Hardware level Load Balancer should be configured for session persistence also called as stickness or sticky bit for Oracle Apps 11i . If this is not set & lets assume client1 first request went to Node1 after authentication if next request for client1 goes to Node2 who is not aware of client1 's previous request will throw authentication again. Don't worry about how to set it, ask vendor or Unix Administrator to set sticky bit or session persistence .
Now you have broad overview of configuring Load balancer at HTTP layer, I'll discuss in detail why you need to apply above patches & what all step by step configuration and parameters which needs to be changed and reasoning behind those changes . Till then check for Cloning, Autoconfig.
I am going to cover most common load balancer setup in Oracle Apps 11i i.e. Setup Two or more Middle tier with Web Server & Form Server with Hardware Load balancer in front of middle tier . This type of setup is also called as "HTTP Layer Hardware Load balancing" in Oracle Applications.
For overview & basics of Load balancing visit my previous post at
http://becomeappsdba.blogspot.com/2006/09/configure-load-balancer-in-oracle-apps.html
http://becomeappsdba.blogspot.com/2006/09/configure-hardware-load-balancer-at.html
Below are steps you need to follow to configure Multiple Middle Tier (Web & Forms Server ) with Hardware Load balancer in front.
1. Setup a Load balancer such that it forwards requests to first middle tier only.
2. Make sure sticky bit is set on load balancer for session persistence (Check Load balancer documentation), You can Network level switch as well to send requests to multiple middle tier
3. Apply Prereq. patches (3175852, 3077386, 3209878)
4. Edit following entry in XML or Context File directly ($APPL_TOP/admin/$CONTEXT_NAME.xml) or via Oracle Application Manager
-- 4.1 "Web entry point Host" to the HTTP load-balancer machine name
-- 4.2 "Web entry point Domain" to the HTTP load-balancer domain name
-- 4.3 "Web entry protocol" to the HTTP load-balancer protocol e.g. "http" or "https"
-- 4.4 "Active Web Port" to the value of the HTTP load-balancer's external port
-- 4.5 "Login Page" to include "Web entry protocol"://"Web Host entry point"."Web domain entry point":"Active Web Port"
-- 4.6 "disco_machine" to load balancer machine
5. Run Autoconfig
6. Start Services & check if you can login to applications via Load balancer
7. Now clone this middle tier to another node (where you want to add another node)
8. Make sure above parameter are pointing to load balancer in second node as well
9. Change load balancer to point to second node only
10. shutdown services on first node
11. try accessing application from second node (you should be able to access application without issues)
11.1 -- If forms are not opening properly , check "ICX Form Launcher .." Profile option should point to load balancer
12. Now start application on both middle tier
13. Point load balancer to both middle tier
14. You should be able to access applications
Scripts to help with the concurrent manager
The concurrent manager is the job-scheduling component of Oracle Apps:
The following SQL scripts located under $FND_TOP/sql are useful when diagnosing concurrent manager problems:
1. afimchk.sql Tells the status of the ICM and PMON method
2. afcmstat.sql Lists active manager processes
3. afrqrun.sql Lists all the running, waiting and terminating requests
4. afrqwait.sql Lists requests that are constrained and waiting for the ICM to release them
5. afrqscm.sql Prints log file name of managers that can run a given request. It can be used to check for possible errors when a request stays in pending status. It requires a request id value.
6. afcmcreq.sql Prints the log file name of the manager that processed the request
7. afrqstat.sql Summary of completed concurrent requests grouped by completion status and execution type. It requires number of days prior to today on which to report parameter.
8. afimlock.sql Lists locks that the ICM is waiting to get
9. afcmrrq.sql Lists managers that currently are running a request
Techniques for checking the status of the concurrent manager:
1. Log in to applications as System Administrator responsibility and navigate to the concurrent manager administration page (Concurrent, Manager, Administrator) and under the processes column if the target and actual column equal the same number (above 0) this means the managers are up and running.
2. You can also go into SQL*PLUS as APPS and run the following script:
SQL> @$FND_TOP/sql/afimchk.sql
This script will return output similar to the below:
Status Since Method
-------------------------------------- --------- ----------- ------
Internal Conc Manager is running on - colapp03 05-MAR-99 06:41:32 PM LOCK
Also, this on bouncing (stopping and re-starting) the concurrent manager.
As an practice, u should stop ur concurrent manager service through adcmctl lying under $APPLCSF/scripts/host_sid
whenever there's a need to shutdown n then startup ur database.
As there could be a scenario that ur ICM wont work.
The following SQL scripts located under $FND_TOP/sql are useful when diagnosing concurrent manager problems:
1. afimchk.sql Tells the status of the ICM and PMON method
2. afcmstat.sql Lists active manager processes
3. afrqrun.sql Lists all the running, waiting and terminating requests
4. afrqwait.sql Lists requests that are constrained and waiting for the ICM to release them
5. afrqscm.sql Prints log file name of managers that can run a given request. It can be used to check for possible errors when a request stays in pending status. It requires a request id value.
6. afcmcreq.sql Prints the log file name of the manager that processed the request
7. afrqstat.sql Summary of completed concurrent requests grouped by completion status and execution type. It requires number of days prior to today on which to report parameter.
8. afimlock.sql Lists locks that the ICM is waiting to get
9. afcmrrq.sql Lists managers that currently are running a request
Techniques for checking the status of the concurrent manager:
1. Log in to applications as System Administrator responsibility and navigate to the concurrent manager administration page (Concurrent, Manager, Administrator) and under the processes column if the target and actual column equal the same number (above 0) this means the managers are up and running.
2. You can also go into SQL*PLUS as APPS and run the following script:
SQL> @$FND_TOP/sql/afimchk.sql
This script will return output similar to the below:
Status Since Method
-------------------------------------- --------- ----------- ------
Internal Conc Manager is running on - colapp03 05-MAR-99 06:41:32 PM LOCK
Also, this on bouncing (stopping and re-starting) the concurrent manager.
As an practice, u should stop ur concurrent manager service through adcmctl lying under $APPLCSF/scripts/host_sid
whenever there's a need to shutdown n then startup ur database.
As there could be a scenario that ur ICM wont work.
How To Use FNDCPASS to Change The Oracle Users, APPS, APPLSYS and Application Module Passwords (INV, AR, AP, etc.) For Applications 11.5 in Unix
goal: How to use FNDCPASS to change the oracle users, APPS, APPLSYS and
application module passwords (INV, AR, AP, etc.) for Applications 11.5 in Unix
fact: Oracle Application Object Library 11.5
fix:
1. Download and install the Password changing utility available from
patch 1685689 or later if not already included in your
version of Applications.
NOTE 1: FNDCPASS should be run from the database tier to prevent encryption issues.
2. Issue the commands at the Unix command line similar to the following:
To change the APPS and APPLSYS passwords:
FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS
Ex: $FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS NEWPASSWORD
NOTE 2: Changing the APPLSYS password automatically changes the APPS password
to match as these two must always agree.
To change an Oracle user password:
FNDCPASS apps/apps 0 Y system/manager ORACLE oracle user new
password
Ex: FNDCPASS apps/apps 0 Y system/manager ORACLE GL GLPASSWORD
NOTE 3: Altering the ORACLE User name (schemas) passwords with FNDCPASS without first updating the APPS/APPLSYS password with FNDCPASS will cause the ORACLE User password to be undecodable by Applications.
Use FNDCPASS to "refresh" the APPS/APPLSYS password, even if it is to the same value.
To change an application user password:
FNDCPASS apps/apps 0 Y system/manager USER username password
Ex: FNDCPASS apps/apps 0 Y system/manager USER VISION WELCOME
NOTE 4: VERY IMPORTANT!!
When changing the password for APPS it is important to manually change the APPS
password in the following files as well as necessary:
1. $ORACLE_HOME/listener/cfg/wdbsvr.app file as well. (Otherwise users will not
be able to login to the Personal Home Page or Self-service web apps.) This may also be necessary in the $IAS_ORACLE_HOME\Apache\modplsql\cfg\wdbsvr.app file
2. Workflow Notification Mailer - $FND_TOP/resource/wfmail.cfg
3. The concurrrent manager start script.
4. $OA_HTML/bin/appsweb.cfg
5. $AD_TOP/admin/template/CGIcmd.dat may contain the password if it is being
used.
(Please refer to Note 159033.1 How to Setup Oracle Reports in Portal to Use
CGICMD.DAT File)
6. If you instance is Multi-node and Autoconfig enabled, it may be necessary to invoke Autoconfig to implement the above changes.
For additional information, please see the README file included with the patch.
application module passwords (INV, AR, AP, etc.) for Applications 11.5 in Unix
fact: Oracle Application Object Library 11.5
fix:
1. Download and install the Password changing utility available from
patch 1685689 or later if not already included in your
version of Applications.
NOTE 1: FNDCPASS should be run from the database tier to prevent encryption issues.
2. Issue the commands at the Unix command line similar to the following:
To change the APPS and APPLSYS passwords:
FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS
Ex: $FNDCPASS apps/apps 0 Y system/manager SYSTEM APPLSYS NEWPASSWORD
NOTE 2: Changing the APPLSYS password automatically changes the APPS password
to match as these two must always agree.
To change an Oracle user password:
FNDCPASS apps/apps 0 Y system/manager ORACLE oracle user new
password
Ex: FNDCPASS apps/apps 0 Y system/manager ORACLE GL GLPASSWORD
NOTE 3: Altering the ORACLE User name (schemas) passwords with FNDCPASS without first updating the APPS/APPLSYS password with FNDCPASS will cause the ORACLE User password to be undecodable by Applications.
Use FNDCPASS to "refresh" the APPS/APPLSYS password, even if it is to the same value.
To change an application user password:
FNDCPASS apps/apps 0 Y system/manager USER username password
Ex: FNDCPASS apps/apps 0 Y system/manager USER VISION WELCOME
NOTE 4: VERY IMPORTANT!!
When changing the password for APPS it is important to manually change the APPS
password in the following files as well as necessary:
1. $ORACLE_HOME/listener/cfg/wdbsvr.app file as well. (Otherwise users will not
be able to login to the Personal Home Page or Self-service web apps.) This may also be necessary in the $IAS_ORACLE_HOME\Apache\modplsql\cfg\wdbsvr.app file
2. Workflow Notification Mailer - $FND_TOP/resource/wfmail.cfg
3. The concurrrent manager start script.
4. $OA_HTML/bin/appsweb.cfg
5. $AD_TOP/admin/template/CGIcmd.dat may contain the password if it is being
used.
(Please refer to Note 159033.1 How to Setup Oracle Reports in Portal to Use
CGICMD.DAT File)
6. If you instance is Multi-node and Autoconfig enabled, it may be necessary to invoke Autoconfig to implement the above changes.
For additional information, please see the README file included with the patch.
How to Find Patching History (10.7, 11.0, 11i)
Starting with Oracle Applications 11.5.5 (or 11i.AD.E (Patch 1945611) and
higher) a new autopatch feature that causes all patch history information to be
stored in the database instead of the applptch.txt and applpsum.txt files was
introduced.
Two scripts, adphrept.sql (patch history) and adfhrept.sql (file history),
provide the patch and file history reports (see Note 162498.1). Both are
located in the $AD_TOP/patch/115/sql directory. When the scripts are ran under
the APPS schema from Sql*Plus, they create report files called adphrept.r and
adfhrept.r, respectively.
There are 16 parameters to pass through the adphrept.sql script. It takes some
time to understand how to use these parameters effectively. As an alternative,
the following SQL statements may be used to obtain basic patch history from the
database:
a. To find a list of all the patches that have been applied:
select DRIVER_FILE_NAME
from AD_PATCH_DRIVERS;
b. To find if a particular patch has been applied:
select DRIVER_FILE_NAME
from AD_PATCH_DRIVERS
where DRIVER_FILE_NAME like '%2408149%';
Note: the SQL statements will return a listing of the respective C, D, and G
drivers of each patch. Thus, for the SQL statement in (b) above if the patch
had been applied to this instance, the results would be:
DRIVER_FILE_NAME
------------------------------
g2408149.drv
c2408149.drv
d2408149.drv
(Also note that any patches, which were applied using admrgpch, will not be
listed in the results of the above SQL statements.)
3. Here is a useful option to find details of patchsets applied to any Oracle
Applications instance, whether 10.7, 11.0, or 11i. It is called the Patchset
Comparison Utility tool (see Note 139684.1).
A UNIX shell script is used to compare the Oracle Applications' applptch.txt
file (or AD_PATCH_DRIVERS table) with the currently available patchsets. In
order to keep this script up to date, it is put out on the Oracle ftp site on a
nightly basis. Therefore, the patchset analysis is only as up to date as of the
last time this script was downloaded.
There are four sections within a typical output of this report:
a. The top of the script tells the date when the patchsets were last,
the date when the report was ran, the current Release Version from
the applptch.txt file, and the URL of a new version of the
patchsets.sh script with the latest patchset data.
b. The second section is a complete list of the applied patchsets that
match ARU.
c. The third section states the most recent patchsets for each of the
products that have not yet been applied.
d. The final section provides the base patchset listing that came
bundled in that particular Oracle Applications version.
4. A GUI for querying Patch History and File History information is available
as part of the HTML-based version of Oracle Applications Manager (OAM 11i).
RELATED DOCUMENTS
-----------------
139684.1 (Oracle Applications Current Patchset Comparison Utility)
162498.1 (Storing Applied Patch Information In The Database For Applications 11i)
162524.1 (How To Identify What Patches and Patchsets Installed in Applications 11i)
140848.1 (Where to Find the Applications Patch History File (applptch.txt))
181665.1 (Release 11i Adpatch Basics)
higher) a new autopatch feature that causes all patch history information to be
stored in the database instead of the applptch.txt and applpsum.txt files was
introduced.
Two scripts, adphrept.sql (patch history) and adfhrept.sql (file history),
provide the patch and file history reports (see Note 162498.1). Both are
located in the $AD_TOP/patch/115/sql directory. When the scripts are ran under
the APPS schema from Sql*Plus, they create report files called adphrept.r and
adfhrept.r, respectively.
There are 16 parameters to pass through the adphrept.sql script. It takes some
time to understand how to use these parameters effectively. As an alternative,
the following SQL statements may be used to obtain basic patch history from the
database:
a. To find a list of all the patches that have been applied:
select DRIVER_FILE_NAME
from AD_PATCH_DRIVERS;
b. To find if a particular patch has been applied:
select DRIVER_FILE_NAME
from AD_PATCH_DRIVERS
where DRIVER_FILE_NAME like '%2408149%';
Note: the SQL statements will return a listing of the respective C, D, and G
drivers of each patch. Thus, for the SQL statement in (b) above if the patch
had been applied to this instance, the results would be:
DRIVER_FILE_NAME
------------------------------
g2408149.drv
c2408149.drv
d2408149.drv
(Also note that any patches, which were applied using admrgpch, will not be
listed in the results of the above SQL statements.)
3. Here is a useful option to find details of patchsets applied to any Oracle
Applications instance, whether 10.7, 11.0, or 11i. It is called the Patchset
Comparison Utility tool (see Note 139684.1).
A UNIX shell script is used to compare the Oracle Applications' applptch.txt
file (or AD_PATCH_DRIVERS table) with the currently available patchsets. In
order to keep this script up to date, it is put out on the Oracle ftp site on a
nightly basis. Therefore, the patchset analysis is only as up to date as of the
last time this script was downloaded.
There are four sections within a typical output of this report:
a. The top of the script tells the date when the patchsets were last,
the date when the report was ran, the current Release Version from
the applptch.txt file, and the URL of a new version of the
patchsets.sh script with the latest patchset data.
b. The second section is a complete list of the applied patchsets that
match ARU.
c. The third section states the most recent patchsets for each of the
products that have not yet been applied.
d. The final section provides the base patchset listing that came
bundled in that particular Oracle Applications version.
4. A GUI for querying Patch History and File History information is available
as part of the HTML-based version of Oracle Applications Manager (OAM 11i).
RELATED DOCUMENTS
-----------------
139684.1 (Oracle Applications Current Patchset Comparison Utility)
162498.1 (Storing Applied Patch Information In The Database For Applications 11i)
162524.1 (How To Identify What Patches and Patchsets Installed in Applications 11i)
140848.1 (Where to Find the Applications Patch History File (applptch.txt))
181665.1 (Release 11i Adpatch Basics)
Thursday, June 5, 2008
What happens when you login to Apps?
Firstly and surely there is a URL for oracle applications that is structured possibly in below format, although it can vary from version of apps.
http://machinename:portnumber/OA_HTML/US/ICXINDEX.htm
http://machinename:portnumber /oa_servlets/AppsLogin
When you join an Oracle Apps development team for an employer, you will first be given URL of the development environment.
In any Oracle Apps implementation project (assuming it has gone live), there are minimum of three environments, each with different URL's and different database instances.
These are:-
---------------
Development environment
Testing environment
Production environment
You will most probably, as a techie, be given url,username ad password of the development environment.
What happens when you login(no advanced info here):-
--------------------------------------
A. Your login gets authenticated against a table named fnd_user for your username and password. The screen below is where username and password defined. This screen is called user definition screen. Only system administrators have access to this screen.
B. As you can see above, this username xxpassi is attached to two responsibilities (this will be discussed in details in latter training lesson). It is this assignment to the responsibility that controls what a logged in person can do and can't do. In layman’s words, a responsibility is a group of menu.
It will prompt you to change your password, to a value different than that assigned by System Administrator.
You might be prompted to install jinitiator…..just keep clicking OK…OK for all Jinitiator messages). Effectively, what I mean to say is that you do not need to download jinitiator from anywhere; Oracle will do this automatically (provided your DBA’s got this cofig’ed) for you during your first logon attempt from the PC. Once your jInitiator gets installed .
Oracle internally uses a login named GUEST, prior to invoking validation of actual username. Some people regard this as a security threat, but it isn’t. Your DBA’s can change the “guest” password from its default value after installation.
Oracle uses a DB User account named applsyspub to which it first connects during validation of LOGIN. This user account has very restricted privileges and has access to below objects (primarily for authentication purposes):-
FND_APPLICATION
FND_UNSUCCESSFUL_LOGINS
FND_SESSIONS
FND_PRODUCT_INSTALLATIONS
FND_PRODUCT_GROUPS
FND_MESSAGES
FND_LANGUAGES_TL
FND_APPLICATION_TL
FND_APPLICATION_VL
FND_LANGUAGES_VL
FND_SIGNON
FND_PUB_MESSAGE
FND_WEBFILEPUB
FND_DISCONNECTED
FND_MESSAGE
FND_SECURITY_PKG
FND_LOOKUPS
http://machinename:portnumber/OA_HTML/US/ICXINDEX.htm
http://machinename:portnumber /oa_servlets/AppsLogin
When you join an Oracle Apps development team for an employer, you will first be given URL of the development environment.
In any Oracle Apps implementation project (assuming it has gone live), there are minimum of three environments, each with different URL's and different database instances.
These are:-
---------------
Development environment
Testing environment
Production environment
You will most probably, as a techie, be given url,username ad password of the development environment.
What happens when you login(no advanced info here):-
--------------------------------------
A. Your login gets authenticated against a table named fnd_user for your username and password. The screen below is where username and password defined. This screen is called user definition screen. Only system administrators have access to this screen.
B. As you can see above, this username xxpassi is attached to two responsibilities (this will be discussed in details in latter training lesson). It is this assignment to the responsibility that controls what a logged in person can do and can't do. In layman’s words, a responsibility is a group of menu.
It will prompt you to change your password, to a value different than that assigned by System Administrator.
You might be prompted to install jinitiator…..just keep clicking OK…OK for all Jinitiator messages). Effectively, what I mean to say is that you do not need to download jinitiator from anywhere; Oracle will do this automatically (provided your DBA’s got this cofig’ed) for you during your first logon attempt from the PC. Once your jInitiator gets installed .
Oracle internally uses a login named GUEST, prior to invoking validation of actual username. Some people regard this as a security threat, but it isn’t. Your DBA’s can change the “guest” password from its default value after installation.
Oracle uses a DB User account named applsyspub to which it first connects during validation of LOGIN. This user account has very restricted privileges and has access to below objects (primarily for authentication purposes):-
FND_APPLICATION
FND_UNSUCCESSFUL_LOGINS
FND_SESSIONS
FND_PRODUCT_INSTALLATIONS
FND_PRODUCT_GROUPS
FND_MESSAGES
FND_LANGUAGES_TL
FND_APPLICATION_TL
FND_APPLICATION_VL
FND_LANGUAGES_VL
FND_SIGNON
FND_PUB_MESSAGE
FND_WEBFILEPUB
FND_DISCONNECTED
FND_MESSAGE
FND_SECURITY_PKG
FND_LOOKUPS
Autoconfig
What is Autoconfig ?
Autoconfig is tool in Apps to configure oracle Applications 11i , Application Tier as well Database Tier.
Autoconfig is method of configuring Oracle Applications . All the information required to configure Oracle Apps 11i is stored in file called as Context file. So there are two context file, one for Database Tier & Second for Application Tier. Context file is repository for configuration stored in xml format. Its xml file and file name format is_.xml so if your machine name is machine1 & SID is VISION then context file name will be VISION_machine1.xml
How to run Autoconfig ?
If you want to configure database tier then you have to execute autoconfig script adautocfg.sh on database tier else if you want to configure on application tier (Middle Tier ) then you have to execute one on middle tier .
Here is the script location
For Database tier its $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME
For Application Tier its $OAD_TOP/admin/scripts/$CONTEXT_NAME
adautocfg.sh calls adconfig.sh from $AD_TOP/bin which inturn calls adconfig.pl from $AD_TOP/bin
Don't forget to take backup before executing autoconfig.
What source of information for Autoconfig to update configuration files ?
If you are wondering where is configuration information stored about your apps 11i instance based on which it updates your Instance then this file is xml file also called as Context file and its in $APPL_TOP/admin for Application Tier or $ORACLE_HOME/appsutil in Database Tier
So xml file also called as context file or autoconfig configuration file stores configuration in these main tags for Application Tier
oa_context : For Start of Context file & context related information
oa_system : System related information under this there are further sections which I'll discuss in next post
oa_host : Information specific to local hosts like users, groups, Apps User, Groups..
oa_install : Installation related information like type of FS, Installation Location
oa_environments : environment specific information this tag has further subsections
oa_processes : this section is related to processes for forms, apache, reports, cm i.e. for all services
oa_custom : This section contain any custom setting (If any)
I'll explain subsections under this main section in my coming posts & few important parameters
Autoconfig Basics
Unwrapping Autoconfig Config file, XML file or Context File
Autoconfig Questions on My Site
Now lets understand how Autoconfig populate/creates files , In order to understand whole process you as apps dba need to understand template files under each product top or tech stack directory in oracle Applications 11i.
These template directory are under each top. In order to explain here I am taking example on how Apache (Oracle Web Server) related files are created when you run Autoconfig.
If you go to $IAS_ORACLE_HOME/appsutil/template directory, all template files related to iAS ORACLE HOME like http.conf , jserv.conf, zone.properties .. are stored in this their respective directories under template directory.
So template file to create httpd.conf is stored in $IAS_ORACLE_HOME/appsutil/template/Apache/Apache/conf
similarly template file for jserv.conf will be in
$IAS_ORACLE_HOME/appsutil/template/Apache/Jserv/etc
In these directories you will see file like httpd.conf or jserv.conf with parameter like
ApJServGroup OACoreGroup 1 1 %s_weboh_oh%/Apache/Jserv/etc/jserv.properties (in jserv.conf under template directory)
or
ServerAdmin applmgr@%s_domainname% ( in httpd.conf under template directory)
Now when Autoconfig executes , its picks up these files & replaces parameters like
%s_weboh_oh% & %s_domainname% from Autoconfig Configuration File i.e. Context file or XML file of format SID_HOSTNAME.xml (Discussed in previous post)
So in my case for vision instance in xml file has these values
s_weboh_oh is /u01/applmgr/VIS11i/ora9/iAS
s_domainname is co.in
Autoconfig is tool in Apps to configure oracle Applications 11i , Application Tier as well Database Tier.
Autoconfig is method of configuring Oracle Applications . All the information required to configure Oracle Apps 11i is stored in file called as Context file. So there are two context file, one for Database Tier & Second for Application Tier. Context file is repository for configuration stored in xml format. Its xml file and file name format is
How to run Autoconfig ?
If you want to configure database tier then you have to execute autoconfig script adautocfg.sh on database tier else if you want to configure on application tier (Middle Tier ) then you have to execute one on middle tier .
Here is the script location
For Database tier its $ORACLE_HOME/appsutil/scripts/$CONTEXT_NAME
For Application Tier its $OAD_TOP/admin/scripts/$CONTEXT_NAME
adautocfg.sh calls adconfig.sh from $AD_TOP/bin which inturn calls adconfig.pl from $AD_TOP/bin
Don't forget to take backup before executing autoconfig.
What source of information for Autoconfig to update configuration files ?
If you are wondering where is configuration information stored about your apps 11i instance based on which it updates your Instance then this file is xml file also called as Context file and its in $APPL_TOP/admin for Application Tier or $ORACLE_HOME/appsutil in Database Tier
So xml file also called as context file or autoconfig configuration file stores configuration in these main tags for Application Tier
oa_context : For Start of Context file & context related information
oa_system : System related information under this there are further sections which I'll discuss in next post
oa_host : Information specific to local hosts like users, groups, Apps User, Groups..
oa_install : Installation related information like type of FS, Installation Location
oa_environments : environment specific information this tag has further subsections
oa_processes : this section is related to processes for forms, apache, reports, cm i.e. for all services
oa_custom : This section contain any custom setting (If any)
I'll explain subsections under this main section in my coming posts & few important parameters
Autoconfig Basics
Unwrapping Autoconfig Config file, XML file or Context File
Autoconfig Questions on My Site
Now lets understand how Autoconfig populate/creates files , In order to understand whole process you as apps dba need to understand template files under each product top or tech stack directory in oracle Applications 11i.
These template directory are under each top. In order to explain here I am taking example on how Apache (Oracle Web Server) related files are created when you run Autoconfig.
If you go to $IAS_ORACLE_HOME/appsutil/template directory, all template files related to iAS ORACLE HOME like http.conf , jserv.conf, zone.properties .. are stored in this their respective directories under template directory.
So template file to create httpd.conf is stored in $IAS_ORACLE_HOME/appsutil/template/Apache/Apache/conf
similarly template file for jserv.conf will be in
$IAS_ORACLE_HOME/appsutil/template/Apache/Jserv/etc
In these directories you will see file like httpd.conf or jserv.conf with parameter like
ApJServGroup OACoreGroup 1 1 %s_weboh_oh%/Apache/Jserv/etc/jserv.properties (in jserv.conf under template directory)
or
ServerAdmin applmgr@%s_domainname% ( in httpd.conf under template directory)
Now when Autoconfig executes , its picks up these files & replaces parameters like
%s_weboh_oh% & %s_domainname% from Autoconfig Configuration File i.e. Context file or XML file of format SID_HOSTNAME.xml (Discussed in previous post)
So in my case for vision instance in xml file has these values
s_weboh_oh is /u01/applmgr/VIS11i/ora9/iAS
s_domainname is co.in
Installing Oracle Apps 11i
1.Check the prerequisites-Windows/Unix/Linux , jdk and perl is installed or not.
2.Check space: 26 Gb for file systems,16-20 GB for forms/reports/Web server, 32 GB for fresh db, 75 for vision,24 GB for stage area, 10GB for each language support, 800Mb in database for each language. – 150GB in total. Average of 60 GB.
2.Create the login accounts for applmgr and oracle logging in as root user who will have to be the owners for APPL_TOP and ORA_TOP respectively.
Adduser applmgr
3.Create mount points.
1.APPL_TOP
2.ORA_TOP
3.COMMON_TOP
4.DATA_TOP
5.DB_TOP
Then chown of appl_top and ora_top.
3.Insert the cd and run adautostg.pl
Go to the location where the rapidwiz is and run
Perl adautostg.pl
It will create different directories for the cds. – startdisk, oraApps, oradb, oraiAs, oraAppDb, oraNls.
We have to specify the directory where stage will be created. Eg /u01.
4. Run the rapidwiz
Go to the stage location
Unix:
Cd /u01/stage11i/startCD/Disk1/rapidwiz
rapidwiz
Windows:
Cd f:\
Cd stage11i\startCd\Disk1\rapidwiz
rapidwiz.cmd.
Single Node installation:
1.Start the rapidwiz wizard
2.TYPE OF OPERATION:select the wizard operation
1)install the e business suite
2)express configuration – just have to specify the top level directories and configuration. Rest the wizard will use default names.
3)upgrade to oracle apps e-business 11i.
3. CONFIGURATION:Specify YES and the location of configuration files or else NO for specifying the configuration by ourselves.
4. TYPE: single node or multimode.
5.DATABASE TYPE:fresh/vision vision (for training purposes)
6.DATABASE DIRECTOTIES:
Os user
Os Group
Base install directory
Oracle Home
DATA_TOP(SYS)
DATA_TOP(LOG)
DATA_TOP(TXN)
DATA top(ARCHIVE)
7.Product licence type
*E-business suite licensing – automatic
*Component application-each individual product is installed after getting the child option from us.
8.country specific functionality
9.Additional languages
10.NLS settings
11.Enter node specific functionality
Appl_top,Common_top,RDBMS home,ias oracle_home
12.review global settings
Dbport
Listener port
Forms listener port
Report port
13.perform pre – install check
14.install
15.perform post installation check.
If it is tick mark then success.
If ! mark then review
If X mark then go back and correct something.
Multinode installation
1.Start the rapidwiz
2.Select the type
1)ebuisiness suite
2)express configuration
3) upgrade
3.Give YES and specify the configuration file location or choose NO.
4.Select the TYPE of installation
1)single node
2)multimode
5.Choose whether to enable load balancing or not.
If YES then requests can be spread across concurrent programs and forms.
And specify the number of concurrent managers and forms server
6.assign servers to nodes indicating the operating system.
7.Setting up shared appl_top option is there
8.Choose the database type FRESH/VISION
9.Setup database installation directory
10.Select product licence type
*Ebusiness suite licensing
*component applications licensing
11. NLS language support
12.select additional languages
13.internationalization settings are selected (character set)
14. APPL_TOP,COMMON_TOP,iAS home, RDMS home is selected.
15.Review global settings
16.Perform pre-installation check
17.Begin installation
18. Perform post-installation.
2.Check space: 26 Gb for file systems,16-20 GB for forms/reports/Web server, 32 GB for fresh db, 75 for vision,24 GB for stage area, 10GB for each language support, 800Mb in database for each language. – 150GB in total. Average of 60 GB.
2.Create the login accounts for applmgr and oracle logging in as root user who will have to be the owners for APPL_TOP and ORA_TOP respectively.
Adduser applmgr
3.Create mount points.
1.APPL_TOP
2.ORA_TOP
3.COMMON_TOP
4.DATA_TOP
5.DB_TOP
Then chown of appl_top and ora_top.
3.Insert the cd and run adautostg.pl
Go to the location where the rapidwiz is and run
Perl adautostg.pl
It will create different directories for the cds. – startdisk, oraApps, oradb, oraiAs, oraAppDb, oraNls.
We have to specify the directory where stage will be created. Eg /u01.
4. Run the rapidwiz
Go to the stage location
Unix:
Cd /u01/stage11i/startCD/Disk1/rapidwiz
rapidwiz
Windows:
Cd f:\
Cd stage11i\startCd\Disk1\rapidwiz
rapidwiz.cmd.
Single Node installation:
1.Start the rapidwiz wizard
2.TYPE OF OPERATION:select the wizard operation
1)install the e business suite
2)express configuration – just have to specify the top level directories and configuration. Rest the wizard will use default names.
3)upgrade to oracle apps e-business 11i.
3. CONFIGURATION:Specify YES and the location of configuration files or else NO for specifying the configuration by ourselves.
4. TYPE: single node or multimode.
5.DATABASE TYPE:fresh/vision vision (for training purposes)
6.DATABASE DIRECTOTIES:
Os user
Os Group
Base install directory
Oracle Home
DATA_TOP(SYS)
DATA_TOP(LOG)
DATA_TOP(TXN)
DATA top(ARCHIVE)
7.Product licence type
*E-business suite licensing – automatic
*Component application-each individual product is installed after getting the child option from us.
8.country specific functionality
9.Additional languages
10.NLS settings
11.Enter node specific functionality
Appl_top,Common_top,RDBMS home,ias oracle_home
12.review global settings
Dbport
Listener port
Forms listener port
Report port
13.perform pre – install check
14.install
15.perform post installation check.
If it is tick mark then success.
If ! mark then review
If X mark then go back and correct something.
Multinode installation
1.Start the rapidwiz
2.Select the type
1)ebuisiness suite
2)express configuration
3) upgrade
3.Give YES and specify the configuration file location or choose NO.
4.Select the TYPE of installation
1)single node
2)multimode
5.Choose whether to enable load balancing or not.
If YES then requests can be spread across concurrent programs and forms.
And specify the number of concurrent managers and forms server
6.assign servers to nodes indicating the operating system.
7.Setting up shared appl_top option is there
8.Choose the database type FRESH/VISION
9.Setup database installation directory
10.Select product licence type
*Ebusiness suite licensing
*component applications licensing
11. NLS language support
12.select additional languages
13.internationalization settings are selected (character set)
14. APPL_TOP,COMMON_TOP,iAS home, RDMS home is selected.
15.Review global settings
16.Perform pre-installation check
17.Begin installation
18. Perform post-installation.
Clonning with Rapid Clone
Cloning Oracle Applications Release 11i with Rapid Clone
Cloning creates an identical copy of an existing Oracle Applications system. There are various reasons for cloning an Oracle Applications system such as:
Creating a copy of the production system for testing updates.
Migrating an existing system to new hardware.
Creating a stage area to reduce patching downtime.
This document describes the process of cloning an Oracle Applications Release 11i system. The most current version of this note is document 230672.1 on OracleMetaLink. A FAQ is also available in document 230672.1 on OracleMetaLink. A FAQ is also available in document 216664.1 on OracleMetaLink.document 216664.1 on OracleMetaLink.
Note: Rapid Clone is currently not supported on Windows Itanium or on Windows x86-64 (AMD64/EM64T).
Attention: Windows users. This document typically uses UNIX syntax when specifying directories; Please substitute the appropriate Windows syntax
Section 1: Prerequisites
Tasks to perform before using Rapid Clone.
Section 2: Clone Oracle Applications 11i
Tasks to prepare, copy, configure, and verify a cloned Applications System.
Section 3: Finishing Tasks
Tasks to complete the cloning process.
Section 4: Advanced Cloning Methods
Tasks for advanced options such as refreshing and multi-node cloning.
Conventions
Convention Meaning
Source system Applications system being cloned.
Target system Applications system being created as a copy of the source.
APPLMGR User which owns the applications file system (APPL_TOP and application tier technology stack)
ORACLE User which owns the database file system (RDBMS ORACLE_HOME and database files).
CONTEXT_NAME The CONTEXT_NAME variable refers to the name of the Applications Context file. For systems installed with Rapid Install 11.5.8 or earlier, this value will typically be set to. For new AutoConfig or Rapid Clone customers, CONTEXT_NAME will be set to _.
Monospace Text Represents command line text. Type this command exactly as shown.
< > Text enclosed in angle brackets represents a variable. Substitute a value for the variable text. Do not type the angle brackets.
________________________________________
Section 1: Prerequisites
Before cloning, prepare the source system by applying patches and running AutoConfig.
1. Verify source and target nodes software versions
In addition to the Oracle Applications software requirements (see Installing Oracle Applications Release 11i Part No. B10638-01), the following software component versions must exist on the source and/or target nodes. The location column indicates the node where the software component must be present.
Software Minimum Version Location Details
Oracle Universal Installer 2.2.0.19 All source system nodes Apply OUI22 patch 5035661 on every iAS and RDBMS ORACLE_HOME to be cloned. Do not apply the patch to your RDBMS ORACLE_HOME, if you have Oracle 10g or higher installed.
Perl 5.005 Source and target database nodes Use the Perl shipped with iAS1022 and RDBMS 9i if available or download it from Perl.com. Perl must be in the PATH before cloning. Windows users: do not use Perl from MKSToolKit.
JRE 1.1.8 Source database node If the RDBMS ORACLE_HOME was not installed using Rapid Install, install JRE 1.1.8 into the/jre/1.1.8 directory.
JRE 1.3.1 Source database node Windows users only: install JRE 1.3.1 into the/jre/1.3.1 directory. See Appendix A for installation instructions.
JDK 1.3.1 Target middle-tier applications nodes Refer to Upgrading to JDK 1.3 with Oracle Applications 11i on OracleMetaLink for instructions.
Zip 2.3 All source nodes Download from InfoZip. Zip must be in your PATH for cloning.
OS utilities N/A All target nodes OS utilities (see 11i Install Manual) must be in the the PATH when running adcfgclone.pl (Unix: make,ld,cc,ar - Windows: gnumake,link,cc,cmd)
2. Windows users only:
Apply patch 2237858 to enable long file names support.
3. Apply the latest AutoConfig Template patch
Update the Oracle Applications file system with the latest AutoConfig template files by applying the TXK AutoConfig Template rollup patch to all application tier server nodes.
Please refer to document 165195.1 on OracleMetaLink to obtain the latest Autoconfig165195.1 on OracleMetaLink to obtain the latest Autoconfig Template Rollup Patch available in Metalink.
4. Apply the latest Rapid Clone patches
Update the Oracle Applications file system with the latest Rapid Clone files by applying the following patches to all application tier server nodes :
o 3453499 (11i.ADX.F)
o 5225940 (Post ADX.F Fixes)
5. Setup Rapid Clone on the Applications Tier
a. If the source Applications system was created with Rapid Install version 11.5.5 or earlier and has not been migrated to AutoConfig, follow the instructions Migrating to AutoConfig on the Applications Tier Migrating to AutoConfig on the Applications Tier in document 165195.1 on OracleMetaLink).
b. All users must run AutoConfig on the Applications Tier (see section 5: Maintaining System Configuration Maintaining System Configuration in document 165195.1 on OracleMetaLink).
6. Setup Rapid Clone on the Database Tier
Implement AutoConfig in the RDBMS ORACLE_HOME (Follow the instructions in section Migrating to AutoConfig on the Database Tier Migrating to AutoConfig on the Database Tier in document 165195.1 on OracleMetaLink). Follow steps 1 and 4 of Section 7 in the AutoConfig document for all versions of RapidInstall and every time you apply a new version of the Rapid Clone patch.
7. Maintain Snapshot information
Log in to each Application Tier Node as the APPLMGR user and run Maintain Snapshot information in AD Administration.
See Oracle Applications Maintenance Utilities for more information.
________________________________________
Section 2: Clone Oracle Applications 11i
Use Rapid Clone to create template files for cloning on the source system. After the source system is copied to the target, Rapid Clone updates these templates to contain the new target system configuration settings. Rapid Clone will not change the source system configuration.
There are three phases to the cloning process:
1. Prepare the Source System
Execute the following commands to prepare the source system for cloning.
a. Prepare the source system database tier for cloning
Log on to the source system as the ORACLE user and run the following commands:
cd/appsutil/scripts/
perl adpreclone.pl dbTier
b. Prepare the source system application tier for cloning
Log on to the source system as the APPLMGR user and run the following commands on each node that contains an APPL_TOP:
cd/admin/scripts/
perl adpreclone.pl appsTier
2. Copy the Source System to the Target System
Copy the application tier file system from the source Applications system to the target node by executing the following steps in the order listed. Ensure the application tier files copied to the target system are owned by the target APPLMGR user, and that the database tier files are owned by the ORACLE user.
a. Copy the application tier file system
Log on to the source system application tier nodes as the APPLMGR user.
Shut down the application tier server processes
Copy the following application tier directories from the source node to the target application tier node:
/util
/clone
/_pages (when this directory exists)
<806 ORACLE_HOME>
b. Copy the database tier file system
Log on to the source system database node as the ORACLE user.
Perform a normal shutdown of the source system database
Copy the database (DBF) files from the source to the target system
Copy the source database ORACLE_HOME to the target system
Start up the source Applications system database and application tier processes
Note: Unix/Linux users, make sure that the softlinks are preserved when copying.
3. Configure the Target System
Execute the following commands to configure the target system. You will be prompted for the target system specific values (SID, Paths, Ports, etc)
a. Configure the target system database server
Log on to the target system as the ORACLE user and type the following commands to configure and start the database:
cd/appsutil/clone/bin
perl adcfgclone.pl dbTier
b. Configure the target system application tier server nodes
Log on to the target system as the APPLMGR user and type the following commands:
cd/clone/bin
perl adcfgclone.pl appsTier
Attention: Windows user only: add <806 ORACLE_HOME>\bin to the system path before running this step.
________________________________________
Section 3: Finishing Tasks
This section lists tasks that may be necessary depending on your implementation and the intended use of the cloned system.
1. Update profile options
Rapid Clone updates only site level profile options. If any other profile options are set to instance specific values, you must update them manually.
2. Update printer settings
If the new cloned system needs to utilize different printers, update the target system with the new printer settings now.
3. Update workflow configuration settings
Cloning an Oracle Applications instance will not update the host and instance specific information used by Oracle Workflow. Review the following tables and columns to verify there is no instance specific data in the Workflow configuration on the target system.
Table Name Column Name Column Value Details
WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE Value starts with http:// : Update to new web host
WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE Value starts with "http:// : Update to new web host
WF_SYSTEMS GUID Create a new system defined as the new global database name using the Workflow Administrator Web Applications responsibility.
WF_SYSTEMS NAME Value needs to be replaced with the database global name
WF_AGENTS ADDRESS Update database link with the new database global name.
FND_FORM_FUNCTIONS WEB_HOST_NAME Update with the new web host name
FND_FORM_FUNCTIONS WEB_AGENT_NAME Update to point at the new PLSQL listener name
FND_CONCURRENT_REQUESTS LOGFILE_NAME Update with the correct path to the logfile directory
FND_CONCURRENT_REQUESTS OUTFILE_NAME Update with the new directory path on the target system
4. Verify the APPLCSF variable setting
Source the APPS environment and review that the variable APPLCSF (identifying the top-level directory for concurrent manager log and output files) points to an acceptable directory. To modify it, change the value of s_applcsf in the contextfile and run AutoConfig.
5. Update the SESSION_COOKIE_DOMAIN value in ICX_PARAMETERS
If the target system is in a different domain name than the source system and SESSION_COOKIE_DOMAIN was not null in the source system, update that value to reflect the new domain name.
6. Windows users only reboot the target machine
Once cloning is completed reboot to enable the services.
________________________________________
Section 4: Advanced Cloning Options
This section describes advanced cloning procedures.
1. Refreshing a target system
You may need to refresh the target system periodically to synchronize it with changes from the source.
To refresh the target system, perform the following steps as described in previous sections:
a. Prepare the Source System
b. Copy the Source System to the Target System
o Copy the application tier file system if the APPL_TOP, 806 ORACLE_HOME, or iAS ORACLE_HOME needs to be refreshed. Copy the portion of the application tier file system which has been updated.
o Copy the database tier file system if the RDBMS ORACLE_HOME or the database needs to be refreshed. If refreshing the database, the ORACLE_HOME should be refreshed at the same time.
c. Configure the Target System
Specify the existing target system context file when running adcfgclone.pl commands:
o perl adcfgclone.pl dbTier
where database context file is:
/appsutil/.xml
o perl adcfgclone.pl appsTier
where appltop context file is:
/admin/.xml
d. Finishing Tasks
2. Cloning a single-node system to a multi-node system
This procedure allows the original single-node system to be cloned into a multi-node system. An Applications system comprises five server types:
o Database server (database tier)
o Forms server (application tier)
o Web server (application tier)
o Concurrent Processing server (application tier)
o Administration server (application tier)
During the single-node to multi-node cloning process, each of these servers can be placed on its own node, resulting in a multi-node target system.
f. Perform prerequisites
Perform these steps on all source and target nodes.
g. Clone Oracle Applications 11i
Prepare, copy and configure the cloned Applications System. When creating more than one application tier server node from a single node system, the copy and configure steps must be performed on each target node. You can specify the server type for each target node while answering the prompts during the configuration step.
The database ORACLE_HOME and database only need to be copied to the node on which the database will be run.
h. Finishing Tasks
Note: Another way of changing a single-node system to a multi-node system is to share the APPL_TOP. See document 233428.1 on OracleMetaLink document 233428.1 on OracleMetaLink for details.
3. Cloning a multi-node system to a multi-node system with same number of nodes
A multi-node system can be cloned provided the number of nodes and distribution of servers in the target system matches that of the source system.
To clone a multi-node system to a multi-node system, perform the cloning process on each node. For example, if the source system contains three nodes, perform the cloning process three times.
o Clone source system node 1 to target system node 1.
o Clone source system node 2 to target system node 2.
o Clone source system node 3 to target system node 3.
Attention: The database server node must be cloned first.
4. Adding a new node to an existing system
You can use Rapid Clone to clone a node and add it to the existing Application System. The new node will run the same or a subset of the server types running on the source node. Follow the instructions in the Application Tier part of Clone Oracle Applications 11i:
o Prepare the source system, copy it to the new node and configure it.
o After adcfgclone.pl completes, source the Applications environment and run the following commands on the target system:
o cd/clone/bin
o perl adaddnode.pl
Note: If the SQL*Net Access security is enabled in the existing system (enabled by default from 11i10), you first need to authorize the new node to access the database through SQL*Net. See Managed SQL*Net Access from HostsManaged SQL*Net Access from Hosts in document 281758.1 on OracleMetalink for instructions on how to achieve this from OAM.
5. Reducing the number of nodes of a multi-node system (merge APPL_TOP)
You can use Rapid Clone to clone a multi-node system to a single-node system (or a multi-node system with fewer nodes) by merging the APPL_TOPs filesystem together. Follow the procedure for Merging existing APPL_TOPs in document 233428.1 Merging existing APPL_TOPs in document 233428.1 on OracleMetaLink.
6. Cloning a RAC system
You can use Rapid Clone to clone a RAC system. While cloning, you have the possibility to remove or add nodes to the cluster in the target RAC system. To clone a RAC system, perform the following tasks:
. Verify the prerequisites
o Apply TXK patch 3571388 (AutoConfig support for Oracle RAC instances)
o Migrate the source system cluster ORACLE_HOMES to AutoConfig as documented in document 165195.1 on OracleMetaLinkdocument 165195.1 on OracleMetaLink
a. Prepare the Source System
Choose one of the ORACLE_HOMEs on the source cluster. This ORACLE_HOME will be used as a master to create all the target cluster system ORACLE_HOME. Run "perl adpreclone.pl dbTier" on it.
Note: You also have the option to clone each ORACLE_HOME from the source RAC cluster to the target cluster. In that case, run adpreclone.pl on every ORACLE_HOME.
b. Copy the Source System to the Target System
o Copy the master ORACLE_HOME from the source system to each node that will compose the target cluster. For example, if your source RAC system had 2 nodes, and you want to clone it to a 3 node target RAC system, you should copy the source master ORACLE_HOME to the 3 nodes on the target system.
o Copy the database files from the source to target system.
c. Configure the Target System
o Log on to any ORACLE_HOME in the target cluster and run
adcfgclone.pl dbTier
This step configures the first node of the target system RAC cluster and recreates the database control files. The prompts, however, will gather information about every node in the target RAC cluster and the data will be re-used when configuring each subsequent node in the next step.
o For each remaning RDBMS ORACLE_HOME in the target system, run the following command as the ORACLE file system owner:
adcfgclone.pl dbTier
o If your database is version 10g or higher, run the following commands to register the database and the instance to the cluster manager .
srvctl add database -d -o
srvctl add instance -d \
-i -n
Note: If the cluster manager is not on Linux (ORACM) or the database is version 10g or higher, manually start up the cluster manager on the target system before running adcfgclone.pl
d. Clone the application tier
Follow the steps in section 2 to prepare, copy and configure the application tier. When prompted for the database SID, specify any one of the RAC service names.
Note: To clone from RAC to non-RAC, follow the same above steps but copy the master ORACLE_HOME to one target node only, and answer "No" to the question "Target instance is a Real Application Cluster (RAC) instance (y/n)", when prompted by adcfgclone.pl.
7. Adding a node to an existing RAC Cluster
You can use Rapid Clone to add one or several nodes to an existing RAC Cluster. Perform the following tasks:
. Choose any one of the ORACLE_HOMEs in the existing cluster and run "perl adpreclone.pl dbTier" on it. This ORACLE_HOME will be used as a master to create the additional node(s).
a. Copy the master ORACLE_HOME filesystem to the new node(s).
b. Reconfigure the RAC Cluster to include the new node(s):
o Log on to the new node, or any one of the new nodes if adding more than one, and run the following command:
cd /appsutil/clone/bin
perl adcfgclone.pl dbTier
Note: You will be prompted for information about all the nodes forming the new cluster and asked to perform the next step before completing adcfgclone.pl on this node.
o When instructed so by the previous step, log on to every node from the original cluster and run the following command on each of them:
cd /appsutil/clone/bin
perl adcfgclone.pl addracnode
o Go back to the first node and complete adcfgclone.pl
o If you are adding more than one node to the original cluster, log on to each of the remaining new nodes and run
cd /appsutil/clone/bin
perl adcfgclone.pl dbTier
Note: If the cluster manager is not on Linux (ORACM) or the database is version 10g or higher, manually start up the cluster manager on the target systems before running adcfgclone.pl
8. Cloning a Shared File System
You can use Rapid Clone to clone a shared APPL_TOP system. Since all the nodes share a unique APPL_TOP you only need to fully clone one of the source system nodes to its target machine and add more nodes directly sharing the APPL_TOP on the target system. Choose one of the shared APPL_TOP nodes on source system (the rest of this section will refer to it as Node A) and perform the following tasks:
. Perform prerequisites
Perform these steps on Node A and and every target nodes.
a. Clone Oracle Applications 11i
Perform a full clone (Prepare, copy and configure steps) of the Database Tier and Node A (Application tier).
b. Add the shared file system nodes to the target system
On the target system, follow the instructions for adding a node to a shared APPL_TOP system in document 233428.1adding a node to a shared APPL_TOP system in document 233428.1 on OracleMetalink and add more nodes sharing the target system APPL_TOP to match the source system topology.
________________________________________
Appendix A: Install JRE 1.3.1 into RDBMS ORACLE_HOME
Windows customers will need to perform the following steps:
Download JRE 1.3.1 from Sun Microsystems.
Run the install executable
When prompted for the location to install jre, click browse and enter the location:
\jre\1.3.1
Accept the default installation options.
JRE 1.3.1 will be installed into the\jre\1.3.1 directory.
________________________________________
Appendix B: Recreating database control files manually in Rapid Clone.
This Appendix documents the steps to allow manual creation of the target database control files within the Rapid Clone process. Examples of when to use this method are for databases on raw partitions or hot backup cloning. Replace section 2.3a (Configure the target system database server) with the following steps:
Log on to the target system as the ORACLE user
Configure the
cd/appsutil/clone/bin
perl adcfgclone.pl dbTechStack
Create the target database control files manually
Start the target system database in open mode
Run the library update script against the database
cd/appsutil/install/
sqlplus "/ as sysdba" @adupdlib.sql
where is "sl" for HP-UX, "so" for any other UNIX platform and not required for Windows.
Configure the target database (the database must be open)
cd/appsutil/clone/bin
perl adcfgclone.pl dbconfig
where target context file is:
/appsutil/.xml
Cloning creates an identical copy of an existing Oracle Applications system. There are various reasons for cloning an Oracle Applications system such as:
Creating a copy of the production system for testing updates.
Migrating an existing system to new hardware.
Creating a stage area to reduce patching downtime.
This document describes the process of cloning an Oracle Applications Release 11i system. The most current version of this note is document 230672.1 on OracleMetaLink. A FAQ is also available in document 230672.1 on OracleMetaLink. A FAQ is also available in document 216664.1 on OracleMetaLink.document 216664.1 on OracleMetaLink.
Note: Rapid Clone is currently not supported on Windows Itanium or on Windows x86-64 (AMD64/EM64T).
Attention: Windows users. This document typically uses UNIX syntax when specifying directories; Please substitute the appropriate Windows syntax
Section 1: Prerequisites
Tasks to perform before using Rapid Clone.
Section 2: Clone Oracle Applications 11i
Tasks to prepare, copy, configure, and verify a cloned Applications System.
Section 3: Finishing Tasks
Tasks to complete the cloning process.
Section 4: Advanced Cloning Methods
Tasks for advanced options such as refreshing and multi-node cloning.
Conventions
Convention Meaning
Source system Applications system being cloned.
Target system Applications system being created as a copy of the source.
APPLMGR User which owns the applications file system (APPL_TOP and application tier technology stack)
ORACLE User which owns the database file system (RDBMS ORACLE_HOME and database files).
CONTEXT_NAME The CONTEXT_NAME variable refers to the name of the Applications Context file. For systems installed with Rapid Install 11.5.8 or earlier, this value will typically be set to
Monospace Text Represents command line text. Type this command exactly as shown.
< > Text enclosed in angle brackets represents a variable. Substitute a value for the variable text. Do not type the angle brackets.
________________________________________
Section 1: Prerequisites
Before cloning, prepare the source system by applying patches and running AutoConfig.
1. Verify source and target nodes software versions
In addition to the Oracle Applications software requirements (see Installing Oracle Applications Release 11i Part No. B10638-01), the following software component versions must exist on the source and/or target nodes. The location column indicates the node where the software component must be present.
Software Minimum Version Location Details
Oracle Universal Installer 2.2.0.19 All source system nodes Apply OUI22 patch 5035661 on every iAS and RDBMS ORACLE_HOME to be cloned. Do not apply the patch to your RDBMS ORACLE_HOME, if you have Oracle 10g or higher installed.
Perl 5.005 Source and target database nodes Use the Perl shipped with iAS1022 and RDBMS 9i if available or download it from Perl.com. Perl must be in the PATH before cloning. Windows users: do not use Perl from MKSToolKit.
JRE 1.1.8 Source database node If the RDBMS ORACLE_HOME was not installed using Rapid Install, install JRE 1.1.8 into the
JRE 1.3.1 Source database node Windows users only: install JRE 1.3.1 into the
JDK 1.3.1 Target middle-tier applications nodes Refer to Upgrading to JDK 1.3 with Oracle Applications 11i on OracleMetaLink for instructions.
Zip 2.3 All source nodes Download from InfoZip. Zip must be in your PATH for cloning.
OS utilities N/A All target nodes OS utilities (see 11i Install Manual) must be in the the PATH when running adcfgclone.pl (Unix: make,ld,cc,ar - Windows: gnumake,link,cc,cmd)
2. Windows users only:
Apply patch 2237858 to enable long file names support.
3. Apply the latest AutoConfig Template patch
Update the Oracle Applications file system with the latest AutoConfig template files by applying the TXK AutoConfig Template rollup patch to all application tier server nodes.
Please refer to document 165195.1 on OracleMetaLink to obtain the latest Autoconfig165195.1 on OracleMetaLink to obtain the latest Autoconfig Template Rollup Patch available in Metalink.
4. Apply the latest Rapid Clone patches
Update the Oracle Applications file system with the latest Rapid Clone files by applying the following patches to all application tier server nodes :
o 3453499 (11i.ADX.F)
o 5225940 (Post ADX.F Fixes)
5. Setup Rapid Clone on the Applications Tier
a. If the source Applications system was created with Rapid Install version 11.5.5 or earlier and has not been migrated to AutoConfig, follow the instructions Migrating to AutoConfig on the Applications Tier Migrating to AutoConfig on the Applications Tier in document 165195.1 on OracleMetaLink).
b. All users must run AutoConfig on the Applications Tier (see section 5: Maintaining System Configuration Maintaining System Configuration in document 165195.1 on OracleMetaLink).
6. Setup Rapid Clone on the Database Tier
Implement AutoConfig in the RDBMS ORACLE_HOME (Follow the instructions in section Migrating to AutoConfig on the Database Tier Migrating to AutoConfig on the Database Tier in document 165195.1 on OracleMetaLink). Follow steps 1 and 4 of Section 7 in the AutoConfig document for all versions of RapidInstall and every time you apply a new version of the Rapid Clone patch.
7. Maintain Snapshot information
Log in to each Application Tier Node as the APPLMGR user and run Maintain Snapshot information in AD Administration.
See Oracle Applications Maintenance Utilities for more information.
________________________________________
Section 2: Clone Oracle Applications 11i
Use Rapid Clone to create template files for cloning on the source system. After the source system is copied to the target, Rapid Clone updates these templates to contain the new target system configuration settings. Rapid Clone will not change the source system configuration.
There are three phases to the cloning process:
1. Prepare the Source System
Execute the following commands to prepare the source system for cloning.
a. Prepare the source system database tier for cloning
Log on to the source system as the ORACLE user and run the following commands:
cd
perl adpreclone.pl dbTier
b. Prepare the source system application tier for cloning
Log on to the source system as the APPLMGR user and run the following commands on each node that contains an APPL_TOP:
cd
perl adpreclone.pl appsTier
2. Copy the Source System to the Target System
Copy the application tier file system from the source Applications system to the target node by executing the following steps in the order listed. Ensure the application tier files copied to the target system are owned by the target APPLMGR user, and that the database tier files are owned by the ORACLE user.
a. Copy the application tier file system
Log on to the source system application tier nodes as the APPLMGR user.
Shut down the application tier server processes
Copy the following application tier directories from the source node to the target application tier node:
<806 ORACLE_HOME>
b. Copy the database tier file system
Log on to the source system database node as the ORACLE user.
Perform a normal shutdown of the source system database
Copy the database (DBF) files from the source to the target system
Copy the source database ORACLE_HOME to the target system
Start up the source Applications system database and application tier processes
Note: Unix/Linux users, make sure that the softlinks are preserved when copying.
3. Configure the Target System
Execute the following commands to configure the target system. You will be prompted for the target system specific values (SID, Paths, Ports, etc)
a. Configure the target system database server
Log on to the target system as the ORACLE user and type the following commands to configure and start the database:
cd
perl adcfgclone.pl dbTier
b. Configure the target system application tier server nodes
Log on to the target system as the APPLMGR user and type the following commands:
cd
perl adcfgclone.pl appsTier
Attention: Windows user only: add <806 ORACLE_HOME>\bin to the system path before running this step.
________________________________________
Section 3: Finishing Tasks
This section lists tasks that may be necessary depending on your implementation and the intended use of the cloned system.
1. Update profile options
Rapid Clone updates only site level profile options. If any other profile options are set to instance specific values, you must update them manually.
2. Update printer settings
If the new cloned system needs to utilize different printers, update the target system with the new printer settings now.
3. Update workflow configuration settings
Cloning an Oracle Applications instance will not update the host and instance specific information used by Oracle Workflow. Review the following tables and columns to verify there is no instance specific data in the Workflow configuration on the target system.
Table Name Column Name Column Value Details
WF_NOTIFICATION_ATTRIBUTES TEXT_VALUE Value starts with http://
WF_ITEM_ATTRIBUTE_VALUES TEXT_VALUE Value starts with "http://
WF_SYSTEMS GUID Create a new system defined as the new global database name using the Workflow Administrator Web Applications responsibility.
WF_SYSTEMS NAME Value needs to be replaced with the database global name
WF_AGENTS ADDRESS Update database link with the new database global name.
FND_FORM_FUNCTIONS WEB_HOST_NAME Update with the new web host name
FND_FORM_FUNCTIONS WEB_AGENT_NAME Update to point at the new PLSQL listener name
FND_CONCURRENT_REQUESTS LOGFILE_NAME Update with the correct path to the logfile directory
FND_CONCURRENT_REQUESTS OUTFILE_NAME Update with the new directory path on the target system
4. Verify the APPLCSF variable setting
Source the APPS environment and review that the variable APPLCSF (identifying the top-level directory for concurrent manager log and output files) points to an acceptable directory. To modify it, change the value of s_applcsf in the contextfile and run AutoConfig.
5. Update the SESSION_COOKIE_DOMAIN value in ICX_PARAMETERS
If the target system is in a different domain name than the source system and SESSION_COOKIE_DOMAIN was not null in the source system, update that value to reflect the new domain name.
6. Windows users only reboot the target machine
Once cloning is completed reboot to enable the services.
________________________________________
Section 4: Advanced Cloning Options
This section describes advanced cloning procedures.
1. Refreshing a target system
You may need to refresh the target system periodically to synchronize it with changes from the source.
To refresh the target system, perform the following steps as described in previous sections:
a. Prepare the Source System
b. Copy the Source System to the Target System
o Copy the application tier file system if the APPL_TOP, 806 ORACLE_HOME, or iAS ORACLE_HOME needs to be refreshed. Copy the portion of the application tier file system which has been updated.
o Copy the database tier file system if the RDBMS ORACLE_HOME or the database needs to be refreshed. If refreshing the database, the ORACLE_HOME should be refreshed at the same time.
c. Configure the Target System
Specify the existing target system context file when running adcfgclone.pl commands:
o perl adcfgclone.pl dbTier
where database context file is:
o perl adcfgclone.pl appsTier
where appltop context file is:
d. Finishing Tasks
2. Cloning a single-node system to a multi-node system
This procedure allows the original single-node system to be cloned into a multi-node system. An Applications system comprises five server types:
o Database server (database tier)
o Forms server (application tier)
o Web server (application tier)
o Concurrent Processing server (application tier)
o Administration server (application tier)
During the single-node to multi-node cloning process, each of these servers can be placed on its own node, resulting in a multi-node target system.
f. Perform prerequisites
Perform these steps on all source and target nodes.
g. Clone Oracle Applications 11i
Prepare, copy and configure the cloned Applications System. When creating more than one application tier server node from a single node system, the copy and configure steps must be performed on each target node. You can specify the server type for each target node while answering the prompts during the configuration step.
The database ORACLE_HOME and database only need to be copied to the node on which the database will be run.
h. Finishing Tasks
Note: Another way of changing a single-node system to a multi-node system is to share the APPL_TOP. See document 233428.1 on OracleMetaLink document 233428.1 on OracleMetaLink for details.
3. Cloning a multi-node system to a multi-node system with same number of nodes
A multi-node system can be cloned provided the number of nodes and distribution of servers in the target system matches that of the source system.
To clone a multi-node system to a multi-node system, perform the cloning process on each node. For example, if the source system contains three nodes, perform the cloning process three times.
o Clone source system node 1 to target system node 1.
o Clone source system node 2 to target system node 2.
o Clone source system node 3 to target system node 3.
Attention: The database server node must be cloned first.
4. Adding a new node to an existing system
You can use Rapid Clone to clone a node and add it to the existing Application System. The new node will run the same or a subset of the server types running on the source node. Follow the instructions in the Application Tier part of Clone Oracle Applications 11i:
o Prepare the source system, copy it to the new node and configure it.
o After adcfgclone.pl completes, source the Applications environment and run the following commands on the target system:
o cd
o perl adaddnode.pl
Note: If the SQL*Net Access security is enabled in the existing system (enabled by default from 11i10), you first need to authorize the new node to access the database through SQL*Net. See Managed SQL*Net Access from HostsManaged SQL*Net Access from Hosts in document 281758.1 on OracleMetalink for instructions on how to achieve this from OAM.
5. Reducing the number of nodes of a multi-node system (merge APPL_TOP)
You can use Rapid Clone to clone a multi-node system to a single-node system (or a multi-node system with fewer nodes) by merging the APPL_TOPs filesystem together. Follow the procedure for Merging existing APPL_TOPs in document 233428.1 Merging existing APPL_TOPs in document 233428.1 on OracleMetaLink.
6. Cloning a RAC system
You can use Rapid Clone to clone a RAC system. While cloning, you have the possibility to remove or add nodes to the cluster in the target RAC system. To clone a RAC system, perform the following tasks:
. Verify the prerequisites
o Apply TXK patch 3571388 (AutoConfig support for Oracle RAC instances)
o Migrate the source system cluster ORACLE_HOMES to AutoConfig as documented in document 165195.1 on OracleMetaLinkdocument 165195.1 on OracleMetaLink
a. Prepare the Source System
Choose one of the ORACLE_HOMEs on the source cluster. This ORACLE_HOME will be used as a master to create all the target cluster system ORACLE_HOME. Run "perl adpreclone.pl dbTier" on it.
Note: You also have the option to clone each ORACLE_HOME from the source RAC cluster to the target cluster. In that case, run adpreclone.pl on every ORACLE_HOME.
b. Copy the Source System to the Target System
o Copy the master ORACLE_HOME from the source system to each node that will compose the target cluster. For example, if your source RAC system had 2 nodes, and you want to clone it to a 3 node target RAC system, you should copy the source master ORACLE_HOME to the 3 nodes on the target system.
o Copy the database files from the source to target system.
c. Configure the Target System
o Log on to any ORACLE_HOME in the target cluster and run
adcfgclone.pl dbTier
This step configures the first node of the target system RAC cluster and recreates the database control files. The prompts, however, will gather information about every node in the target RAC cluster and the data will be re-used when configuring each subsequent node in the next step.
o For each remaning RDBMS ORACLE_HOME in the target system, run the following command as the ORACLE file system owner:
adcfgclone.pl dbTier
o If your database is version 10g or higher, run the following commands to register the database and the instance to the cluster manager .
srvctl add database -d
srvctl add instance -d
-i
Note: If the cluster manager is not on Linux (ORACM) or the database is version 10g or higher, manually start up the cluster manager on the target system before running adcfgclone.pl
d. Clone the application tier
Follow the steps in section 2 to prepare, copy and configure the application tier. When prompted for the database SID, specify any one of the RAC service names.
Note: To clone from RAC to non-RAC, follow the same above steps but copy the master ORACLE_HOME to one target node only, and answer "No" to the question "Target instance is a Real Application Cluster (RAC) instance (y/n)", when prompted by adcfgclone.pl.
7. Adding a node to an existing RAC Cluster
You can use Rapid Clone to add one or several nodes to an existing RAC Cluster. Perform the following tasks:
. Choose any one of the ORACLE_HOMEs in the existing cluster and run "perl adpreclone.pl dbTier" on it. This ORACLE_HOME will be used as a master to create the additional node(s).
a. Copy the master ORACLE_HOME filesystem to the new node(s).
b. Reconfigure the RAC Cluster to include the new node(s):
o Log on to the new node, or any one of the new nodes if adding more than one, and run the following command:
cd /appsutil/clone/bin
perl adcfgclone.pl dbTier
Note: You will be prompted for information about all the nodes forming the new cluster and asked to perform the next step before completing adcfgclone.pl on this node.
o When instructed so by the previous step, log on to every node from the original cluster and run the following command on each of them:
cd /appsutil/clone/bin
perl adcfgclone.pl addracnode
o Go back to the first node and complete adcfgclone.pl
o If you are adding more than one node to the original cluster, log on to each of the remaining new nodes and run
cd /appsutil/clone/bin
perl adcfgclone.pl dbTier
Note: If the cluster manager is not on Linux (ORACM) or the database is version 10g or higher, manually start up the cluster manager on the target systems before running adcfgclone.pl
8. Cloning a Shared File System
You can use Rapid Clone to clone a shared APPL_TOP system. Since all the nodes share a unique APPL_TOP you only need to fully clone one of the source system nodes to its target machine and add more nodes directly sharing the APPL_TOP on the target system. Choose one of the shared APPL_TOP nodes on source system (the rest of this section will refer to it as Node A) and perform the following tasks:
. Perform prerequisites
Perform these steps on Node A and and every target nodes.
a. Clone Oracle Applications 11i
Perform a full clone (Prepare, copy and configure steps) of the Database Tier and Node A (Application tier).
b. Add the shared file system nodes to the target system
On the target system, follow the instructions for adding a node to a shared APPL_TOP system in document 233428.1adding a node to a shared APPL_TOP system in document 233428.1 on OracleMetalink and add more nodes sharing the target system APPL_TOP to match the source system topology.
________________________________________
Appendix A: Install JRE 1.3.1 into RDBMS ORACLE_HOME
Windows customers will need to perform the following steps:
Download JRE 1.3.1 from Sun Microsystems.
Run the install executable
When prompted for the location to install jre, click browse and enter the location:
Accept the default installation options.
JRE 1.3.1 will be installed into the
________________________________________
Appendix B: Recreating database control files manually in Rapid Clone.
This Appendix documents the steps to allow manual creation of the target database control files within the Rapid Clone process. Examples of when to use this method are for databases on raw partitions or hot backup cloning. Replace section 2.3a (Configure the target system database server) with the following steps:
Log on to the target system as the ORACLE user
Configure the
cd
perl adcfgclone.pl dbTechStack
Create the target database control files manually
Start the target system database in open mode
Run the library update script against the database
cd
sqlplus "/ as sysdba" @adupdlib.sql
where
Configure the target database (the database must be open)
cd
perl adcfgclone.pl dbconfig
where target context file is:
Imp. Tables for Apps DBA
Concurrent Manager
FND_CONCURRENT_QUEUES
FND_CONCURRENT_PROGRAMS
FND_CONCURRENT_REQUESTS
FND_CONCURRENT_PROCESSES
FND_CONCURRENT_QUEUE_SIZE
FND
FND_APPL_TOPS
FND_LOGINS
FND_USER
FND_DM_NODES
FND_TNS_ALIASES
FND_NODES
FND_RESPONSIBILITY
FND_DATABASES
FND_UNSUCCESSFUL_LOGINS
FND_LANGUAGES
FND_APPLICATION
FND_PROFILE_OPTION_VALUES
AD / Patches
AD_APPLIED_PATCHES
AD_PATCH_DRIVERS
AD_BUGS
AD_INSTALL_PROCESSES
AD_SESSIONS
AD_APPL_TOPS
FND_CONCURRENT_QUEUES
FND_CONCURRENT_PROGRAMS
FND_CONCURRENT_REQUESTS
FND_CONCURRENT_PROCESSES
FND_CONCURRENT_QUEUE_SIZE
FND
FND_APPL_TOPS
FND_LOGINS
FND_USER
FND_DM_NODES
FND_TNS_ALIASES
FND_NODES
FND_RESPONSIBILITY
FND_DATABASES
FND_UNSUCCESSFUL_LOGINS
FND_LANGUAGES
FND_APPLICATION
FND_PROFILE_OPTION_VALUES
AD / Patches
AD_APPLIED_PATCHES
AD_PATCH_DRIVERS
AD_BUGS
AD_INSTALL_PROCESSES
AD_SESSIONS
AD_APPL_TOPS
Patching Scripts
/* Query to find out if any patch except localisation patch is applied or not, if applied, that what all drivers it contain and time of it's application*/
select A.APPLIED_PATCH_ID, A.PATCH_NAME, A.PATCH_TYPE, B.PATCH_DRVIER_ID, B.DRIVER_FILE_NAME, B.ORIG_PATCH_NAME, B.CREATION_DATE, B.PLATFORM, B.SOURCE_CODE, B.CREATIONG_DATE, B.FILE_SIZE, B.MERGED_DRIVER_FLAG, B.MERGE_DATE from AD_APPLIED_PATCHES A, AD_PATCH_DRIVERS B where A.APPLIED_PATCH_ID = B.APPLIED_PATCH_ID and A.PATCH_NAME = ''
/* To know that if the patch is applied successfully, applied on both node or not, start time of patch application and end time of patch application, patch top location , session id ... patch run id */
select D.PATCH_NAME, B.APPLICATIONS_SYSTEM_NAME, B.INSTANCE_NAME, B.NAME, C.DRIVER_FILE_NAME, A.PATCH_DRIVER_ID, A.PATCH_RUN_ID, A.SESSION_ID, A.PATCH_TOP, A.START_DATE, A.END_DATE, A.SUCCESS_FLAG, A.FAILURE_COMMENTS from AD_PATCH_RUNS A, AD_APPL_TOPS B, AD_PATCH_DRVIERS C, AD_APPLIED_PATCHES D where A.APPL_TOP_ID = B.APPL_TOP_ID AND A.PATCH_DRIVER_ID = C.PATCH_DRIVER_ID and C.APPLIED_PATCH_ID = D.APPLIED_PATCH_ID and A.PATCH_DRIVER_ID in (select PATCH_DRIVER_ID from AD_PATCH_DRIVERS where APPLIED_PATCH_ID in (select APPLIED_PATCH_ID from AD_APPLIED_PATCHES where PATCH_NAME = '')) ORDER BY 3;
/* To find the latest application version */
select ARU_RELEASE_NAME||'.'||MINOR_VERSION||'.'||TAPE_VERSION version, START_DATE_ACTIVE updated,ROW_SOURCE_COMMENTS "how it is done", BASE_RELEASE_FLAG "Base version" FROM AD_RELEASES where END_DATE_ACTIVE IS NULL
select A.APPLIED_PATCH_ID, A.PATCH_NAME, A.PATCH_TYPE, B.PATCH_DRVIER_ID, B.DRIVER_FILE_NAME, B.ORIG_PATCH_NAME, B.CREATION_DATE, B.PLATFORM, B.SOURCE_CODE, B.CREATIONG_DATE, B.FILE_SIZE, B.MERGED_DRIVER_FLAG, B.MERGE_DATE from AD_APPLIED_PATCHES A, AD_PATCH_DRIVERS B where A.APPLIED_PATCH_ID = B.APPLIED_PATCH_ID and A.PATCH_NAME = '
/* To know that if the patch is applied successfully, applied on both node or not, start time of patch application and end time of patch application, patch top location , session id ... patch run id */
select D.PATCH_NAME, B.APPLICATIONS_SYSTEM_NAME, B.INSTANCE_NAME, B.NAME, C.DRIVER_FILE_NAME, A.PATCH_DRIVER_ID, A.PATCH_RUN_ID, A.SESSION_ID, A.PATCH_TOP, A.START_DATE, A.END_DATE, A.SUCCESS_FLAG, A.FAILURE_COMMENTS from AD_PATCH_RUNS A, AD_APPL_TOPS B, AD_PATCH_DRVIERS C, AD_APPLIED_PATCHES D where A.APPL_TOP_ID = B.APPL_TOP_ID AND A.PATCH_DRIVER_ID = C.PATCH_DRIVER_ID and C.APPLIED_PATCH_ID = D.APPLIED_PATCH_ID and A.PATCH_DRIVER_ID in (select PATCH_DRIVER_ID from AD_PATCH_DRIVERS where APPLIED_PATCH_ID in (select APPLIED_PATCH_ID from AD_APPLIED_PATCHES where PATCH_NAME = '
/* To find the latest application version */
select ARU_RELEASE_NAME||'.'||MINOR_VERSION||'.'||TAPE_VERSION version, START_DATE_ACTIVE updated,ROW_SOURCE_COMMENTS "how it is done", BASE_RELEASE_FLAG "Base version" FROM AD_RELEASES where END_DATE_ACTIVE IS NULL
Patching Best Practices
As an Oracle Applications DBA we tend to spend a considerable amount of time applying patches. A newbie Applications DBA recently asked me the duties of an Applications DBA besides patching .At that moment i refrained myself just to a smile. But the question does highlight the significance of patching in an AppsDba's routine.
Patching, though not a very complicated process, inefficient or inappropriate patching can seriously jeopardize the functioning of your system. Most of the patching for oracle applications is done using adpatch tools and there are many more which have other methods of application like through a shell script. However in my current post i will talking only about the adpatch patches. The 'best practices' mentioned here are the ones which I have felt to be of use and have made my patching life a bit less complicated.
Patching Methodology
Having a proper patching process and methodology is always helpful. The ideal one for me is the PATCH -> TEST -> DEVELOPMENT -> PRODUCTION one. Under this the patch is first applied to a patch instance then it is propagated to the test environment where the testing is done after which it is applied on the development instance where the development team tests the patch against there customizations if any. Upon passing these stages the patch is finally applied to the production system. If you cannot afford these many instances at minimum you must ensure the patch is tested on TEST environment before you actually go
ahead and apply the patch to your production.
Consistency
There should be consistency in the patch application process. That is you should use the same steps to apply the patch in your production environment that you used in your TEST/PATCH environment for example if you applied a pre requisite patch A as part
of your main patch application, you must ensure the same pre requisite patch is also applied on the production environment and not a superseded version of patch A.
Needless to mention there must be also consistency among the all the different environments. That is your PATCH/TEST/DEVELOPMENT and PRODUCTION environments should have the same setups configuration and patchset levels.
Schedule Patch Application
Schedule the patch application as far as possible. There are multiple benefits you realize out of scheduling. The most important one being that the downtimes will be scheduled and will have help the business to be prepared for them and not be taking them by surprise. Also if your patching downtimes are scheduled you can plan to have the downtime following your backup schedule thereby eliminating the need for having a separate backups for each patch application. However there will be high priority patches that will have applied outside this schedule.
A Patch in Time
It is always advisable to be at the latest patch set level at most of the times. I have always felt that it is one of your duties as an Apps DBA to take the fear of patching out of the business's mind. My experience sys that being on the latest Consolidated Update or the latest Roll up patch helps in avoiding most of the pre requisite in case of applying any one off patch which might be required. Also you should apply the Critical Patch Updates that are released by oracle every quarter.
The Readme
Before applying a patch make sure you have gone through the readme file of the patch. This file might contain some special or additional steps that you might have to follow as a part of the patch application. Also it will tell you if there are any pre requisite patches that are require. Downloading and having the pre requisites ready saves you a lot of time.
Pre requisite Patch
In case you are required to apply a pre requisite patch before you can apply the main patch. it is better to apply the pre requisite patch only and not the superseded version of the pre requisite patch. In case you choose to apply the super seeded version of the of the pre requisite patch you must doubly make sure that the superseded patch qualifies as a pre requisite patch for the main patch.
Patch Impact Analysis
A patch impact analysis should be carried out as far as possible before going ahead with the actual pat6ch application. The simplest way of doing it would be to apply the path with apply=no option along with adpatch. You can then go through the actions the patch would have done either from the logfile or view it through the Oracle Applications manager.
NLS Environment
In case you are patching an NLS environment. Check if you have a translation patch also available for the main patch. if one is available make sure to download and keep it ready. You must install the US language patch first and immediately follow it by applying the translation patch.
Merge Patches
In cases where you are doing a bulk patch application like during a production setup the patch application time is reduced greatly by merging the patches using AD Merge Patch. However per requisite patches should not be merged. Also in an NLS environment its is not advisable to merge multiple language translation patches.
The Logfile
I most patching scenarios the patch log file is either over written by accepting the default logfile name adpatch.log or in other cases these are not maintained properly. I have found myself digging up patch logfiles for a variety of reasons, though you have a lot of this information available to you via Oracle Applications Manager's Patch Reports.
Maintenance Mode
With the latest AD.I patch set there is a pre requisite to put the system on maintenance mode before applying a patch. I have come across DBA's by passing this option by using options=hotpatch for reducing the patching related downtime. There is a reason for having the maintenance mode feature out there, it offers certain performance benefits and reduces the chances of any conflicts. There are other ways to reduce the patching related down times, which i will touch upon briefly next.
Reduce Your Patch Downtime
As discussed earlier merging your patches is one of the ways to reduce your patching related downtimes. There are also certain options you could use with adpatch which could reduce your downtime significantly. You must however understand each of there options clearly before using them with adpatch. For e.g. choosing not to compile invalid objects might reduce your patching downtime but you must be sure of the invalid objects or you must manually run the compilation script once you are through with all your patch application.
You can also implement the concept of a Shared Application Tier File System and a Staged APPL_TOP to further bring down your patching downtime and effort.
Patching, though not a very complicated process, inefficient or inappropriate patching can seriously jeopardize the functioning of your system. Most of the patching for oracle applications is done using adpatch tools and there are many more which have other methods of application like through a shell script. However in my current post i will talking only about the adpatch patches. The 'best practices' mentioned here are the ones which I have felt to be of use and have made my patching life a bit less complicated.
Patching Methodology
Having a proper patching process and methodology is always helpful. The ideal one for me is the PATCH -> TEST -> DEVELOPMENT -> PRODUCTION one. Under this the patch is first applied to a patch instance then it is propagated to the test environment where the testing is done after which it is applied on the development instance where the development team tests the patch against there customizations if any. Upon passing these stages the patch is finally applied to the production system. If you cannot afford these many instances at minimum you must ensure the patch is tested on TEST environment before you actually go
ahead and apply the patch to your production.
Consistency
There should be consistency in the patch application process. That is you should use the same steps to apply the patch in your production environment that you used in your TEST/PATCH environment for example if you applied a pre requisite patch A as part
of your main patch application, you must ensure the same pre requisite patch is also applied on the production environment and not a superseded version of patch A.
Needless to mention there must be also consistency among the all the different environments. That is your PATCH/TEST/DEVELOPMENT and PRODUCTION environments should have the same setups configuration and patchset levels.
Schedule Patch Application
Schedule the patch application as far as possible. There are multiple benefits you realize out of scheduling. The most important one being that the downtimes will be scheduled and will have help the business to be prepared for them and not be taking them by surprise. Also if your patching downtimes are scheduled you can plan to have the downtime following your backup schedule thereby eliminating the need for having a separate backups for each patch application. However there will be high priority patches that will have applied outside this schedule.
A Patch in Time
It is always advisable to be at the latest patch set level at most of the times. I have always felt that it is one of your duties as an Apps DBA to take the fear of patching out of the business's mind. My experience sys that being on the latest Consolidated Update or the latest Roll up patch helps in avoiding most of the pre requisite in case of applying any one off patch which might be required. Also you should apply the Critical Patch Updates that are released by oracle every quarter.
The Readme
Before applying a patch make sure you have gone through the readme file of the patch. This file might contain some special or additional steps that you might have to follow as a part of the patch application. Also it will tell you if there are any pre requisite patches that are require. Downloading and having the pre requisites ready saves you a lot of time.
Pre requisite Patch
In case you are required to apply a pre requisite patch before you can apply the main patch. it is better to apply the pre requisite patch only and not the superseded version of the pre requisite patch. In case you choose to apply the super seeded version of the of the pre requisite patch you must doubly make sure that the superseded patch qualifies as a pre requisite patch for the main patch.
Patch Impact Analysis
A patch impact analysis should be carried out as far as possible before going ahead with the actual pat6ch application. The simplest way of doing it would be to apply the path with apply=no option along with adpatch. You can then go through the actions the patch would have done either from the logfile or view it through the Oracle Applications manager.
NLS Environment
In case you are patching an NLS environment. Check if you have a translation patch also available for the main patch. if one is available make sure to download and keep it ready. You must install the US language patch first and immediately follow it by applying the translation patch.
Merge Patches
In cases where you are doing a bulk patch application like during a production setup the patch application time is reduced greatly by merging the patches using AD Merge Patch. However per requisite patches should not be merged. Also in an NLS environment its is not advisable to merge multiple language translation patches.
The Logfile
I most patching scenarios the patch log file is either over written by accepting the default logfile name adpatch.log or in other cases these are not maintained properly. I have found myself digging up patch logfiles for a variety of reasons, though you have a lot of this information available to you via Oracle Applications Manager's Patch Reports.
Maintenance Mode
With the latest AD.I patch set there is a pre requisite to put the system on maintenance mode before applying a patch. I have come across DBA's by passing this option by using options=hotpatch for reducing the patching related downtime. There is a reason for having the maintenance mode feature out there, it offers certain performance benefits and reduces the chances of any conflicts. There are other ways to reduce the patching related down times, which i will touch upon briefly next.
Reduce Your Patch Downtime
As discussed earlier merging your patches is one of the ways to reduce your patching related downtimes. There are also certain options you could use with adpatch which could reduce your downtime significantly. You must however understand each of there options clearly before using them with adpatch. For e.g. choosing not to compile invalid objects might reduce your patching downtime but you must be sure of the invalid objects or you must manually run the compilation script once you are through with all your patch application.
You can also implement the concept of a Shared Application Tier File System and a Staged APPL_TOP to further bring down your patching downtime and effort.
Types Of Patches
Types of Patches
Individual Patch, One-off, Standalone
These are terms used to describe an individual patch that is created to fix one particular bug. Currently, most Application products deliver their patches primarily through ‘Mini Packs’. Individual patches are possible, but rules for when one is created varies by product.
Mini Pack
‘Patch Set’ was the original term used in R10. In R11 the same type of patch is now being called a ‘Mini Pack’. Both terms mean a large, cumulative patch, for a particular product, that fixes most or all bugs that have been fixed for that release and product. These patches are….
· Named using a letter.
Þ 11i.PA.D
· Cumulative.
Þ For example, 11i.AP.D, would include fixes in AP.A, AP.B, AP.C, plus bugs fixed between when AP.C was released and when they began building AP.D.
· Created periodically.
Þ How often they are created varies by product.
· Require just one patch.
Þ However, if the install is a multi-node install, then the patch must be installed on each machine.
Þ If different platforms are used, the patch must be ported for each platform.
Family Pack
‘Family Pack’ is a group of Mini Packs for related products that are bundled together, and possibly some additional individual fixes that have been created after the Mini Packs. Some examples of product families are ERP, CRM, Procurement, or Order Management, but there are many others.
The same bulleted information for Mini Packs applies for Family Packs. The only difference is the naming structure. Family Packs will be named similar to:
· 11i.OM_PF.G or 11i.FINAP_PF.A
· The ‘_PF’ in the name indicates it is a Family Pack and not a Mini Pack.
FCUP or Family Consolidated Upgrade Patch
An FCUP (pronounced F-CUP) is a patch that needs to be applied before starting an upgrade. This patch includes performance improvements or bug fixes for processes that run during the upgrade. If an FCUP is required for an upgrade, it will be mentioned in the Release Notes.
Consolidated Patch or Mega Patch
These are unofficial terms that are used to name, or describe, a large patch that is a bundle of important bug fixes in one patch.
Maintenance Pack
Maintenance Pack is the term that Oracle began using for R11, while Release Update was used for R10.
A ‘Maintenance Pack’ is a collection of Mini Packs that are bundled together onto a set of CDs that can be ordered and easily installed by the customer.
· With the full installation of this type of patch, the 3rd digit of Applications Release will change.
Þ An example of a Maintenance Pack is 11.5.3 or 11.5.5
· When applying a Maintenance Pack, a user can choose to apply certain product’s Mini Packs individually, or they can apply all the product’s Mini Packs at once using one set of drivers.
Þ The Application’s version will not be updated, for example to 11.5.5, if the Mini Packs are applied individually.
· As with Mini Packs, Maintenance Packs are cumulative.
Þ So if 11.5.5 is applied, then prior Maintenance Packs do not need to be applied.
(11.5.1, 11.5.2, 11.5.3, 11.5.4).
· The primary purpose of Maintenance Packs is to fix bugs that have been identified. However, on occasion new functionality may be introduced.
NLS Patches
If your install has multiple languages, additional patches may need to be installed for each language. The
American patch needs to be applied first, then an NLS version of the same patch needs to be applied for each language. When applying the NLS patch, be sure to set the NLS_LANG variable to AMERICAN_AMERICA., substituting the appropriate character set for your language. For more information on other variables and steps, consult the NLS Installation manual.
Not ALL patches will require an NLS version of a patch. For example, if the patch is only creating a new package, an NLS patch would not be required. However a patch that is replacing a form or report, or all large patches, such as Mini Packs or Maintenance Packs will require an NLS patch. Consult Oracle Support to confirm if an NLS patch is needed when applying a patch.
Adpatch has a function that was introduced in 11i that will alert the customer if an NLS patch may be needed. During patch application, the user will receive a message that an NLS patch may be required, and ask the user if they want to continue with the application of the patch.
Minor Release
Examples of a minor release are 10.7, 11.0, or 11.5. A minor release is not a patch.
· A Minor Release is installed using autoUpgrade, not adpatch, to upgrade to the release.
· The primary purpose of a Minor release is to introduce new functionality.
· Supported versions of Applications are based off of a Minor Release.
II. Basic Explanation of R11 Architecture
In order to understand how R11 patches are applied, the R11 architecture needs to be explained. For a complete picture, reading the manual Oracle Applications Release 11 for UNIX Concepts (Part# A90380) is recommended.
Documented below is a very simple explanation of R11i Architecture. Note, this is not a complete description, and to get a full understanding the Concepts manual should be read.
Beginning with R11, Oracle allows the user to break up their install according to their needs. The user can determine where to install 4 different ‘servers’. The Forms, Web, Concurrent Manager, and Admin servers can be installed all on one machine or broken up onto numerous machines.
Database Tier
Concurrent Processing Server
· Concurrent processes (Ex: reports, executables)
Administration Server
· Files that maintain the database (Ex: patch/110/sql)
Application Tier
Forms Server
· GUI Forms (.fmb and .fmx)
Web Server
· html and java files
Desktop Client Tier
· Contains appletviewer or JInitiator to log on to Applications from the client
Do not interpret the term ‘Server’, such as Forms Server, to mean a machine, such as Solaris or NT. These servers can all be on the same machine (single node install), or divided into numerous machines (multi-node install). For example, the user could have the Concurrent Processing Server and the Administration Server on a Solaris, and the Forms Server and the Web Server on an NT. This is the commonly used ‘two-node’ type of install. Many other combinations can be used, including multiple Forms Servers for Load Balancing or Fault Tolerance.
When a patch was applied in R11.0, the patch process asked 4 questions to determine which of the 4 different servers existed on the machine the patch was being applied to. These questions are listed below. In ( ) under the question is the server that these questions correspond to.
Do you currently have files used for installing or upgrading the database
installed in this $APPL_TOP [Yes] ?
(Administration Server)
Do you currently have Java and HTML files for Self-Service Applications
installed in this $APPL_TOP [Yes] ?
(Web Server)
Do you currently have Oracle Applications forms files installed
in this $APPL_TOP [Yes] ?
(Forms Server)
Do you currently have concurrent program files
installed in this $APPL_TOP [Yes] ?
(Concurrent Processing Server)
After these questions were answered, adpatch would know which files it needed to copy and the jobs it would need to perform.
In R11i, the install process stores the answer to these 4 questions in the file $APPL_TOP/admin/adconfig.txt. Then when adpatch is run, it reads this file and automatically answers the 4 questions for the user. This makes adpatch easier, and helps prevent user error.
Example:
The Applications instance has two machines.
Solaris Machine A, has the Concurrent Manager and Administration servers
NT Machine B, has the Forms and Web servers
The patch, ported for Solaris, would need to be applied to Machine A. The adconfig.txt file would then be read and answer the 4 questions for the user. In this case the answers to the questions should be, ‘Yes’ for questions 1 and 4, and ‘No’ for questions 2 and 3.
The same patch, ported for NT, would then be applied to Machine B, and the questions answered in the reverse. ‘Yes’ to 2 & 3. ‘No’ to 1 & 4.
III. Anatomy of a Patch
All R11 and R11i patches use the zip function instead of ‘tar’, which was used in R10
To unbundle the patch, simply use the unzip command:
unzip p2145632_11i_SOLARIS.zip
When a patch is unbundled it creates a directory that is the same number as the bug number which is included in the patch name. For example, p2145632_11i_SOLARIS.zip will create the directory 2145632. The 2145632 directory will contain the following:
readme.txt This is a text file that contains a brief explanation of what the patch fixes,and instructions on how to apply the patch. It is VERY important to thoroughly read this file, some examples of important information it may contain are:
· Prerequisite patch(s) that must be applied before applying the current patch.
· References to .html file(s) that are also included in the patch, which contains additional installation steps or instructions.
· Manual steps that must be executed before or after applying the patch.
· An explanation of a new feature introduced by the patch.
· Restrictions on who or when the patch can be applied.
· Instructions to run the patch in preinstall mode.
IMPORTANT: It is very important that the instructions in the readme are followed closely. Not following the readme may cause the patch to fail, not correct the problem it was intended to fix, or potentially introduce additional problems.
cXXXXXX.drv The ‘c’ or copy driver, and the first driver file executed. A driver provides adpatch with the instructions on the jobs it needs to perform. This driver copies files from patch to directories, relinks executables, and regenerates jar files.
dXXXXXX.drv The ‘d’ or ‘Database’ driver, which is the second driver file executed, if it exists. A patch will contain a database driver only if the patch contains files that will update the database, such as files in the patch/115/ sub-directories. Some examples, are scripts that…
· Create packages
· Create new error messages
· Add a new table or view to the database
· Add a new column to a table
· Add new seed data to a table
dXXXXXX.cf R11i patches created after December 2001 will include an additional
d driver, but with the .cf extension instead of .drv. This is used by a new adpatch feature, called the checkfile feature, which is introduced in an AD Mini Pack, or with some individual AD patches.
This feature is explained in depth by patches that introduce the feature,
such as 1945611 or the latest AD Mini Pack. But the following is a quick
explanation.
The checkfile feature can reduce the time to apply a d driver by not running
processes that have already been run. Such as FNDLOAD, WFLOAD, akload.class or any process in the d driver. It does this by creating a table, which stores the versions for the files used by these processes, then adpatch will check the version in the patch against the version stored in this table. If the version in the patch is not a higher version, then the process will be skipped. Adpatch is run the exact same way, but the .cf driver file is used instead of the .drv driver.
If a patch is applied using this driver without the new feature installed, the adpatch session will fail at the start.
gXXXXXX.drv The ‘g’ or ‘Generate’ driver, which is the third driver file executed, if it exists. A patch will contain a generate driver only if the patch contains files,such as forms, reports, graphics or messages, that need to be generated.
jXXXXXX.zip This zip file may be included in Java patches. This file is called a
Zipped Resource Unit or ZRU. If a patch contains a ZRU, it does not need to be unzipped. This is a zip file that contains ‘.class’ files and other web related files. The .zip file will be called and applied when adpatch is run with the c driver.
Product directories Each patch will contain at least one product directory (ap, gl, inv, etc.) that will contain sub-directories and the files that are included in the patch. The product directories in the patch will mirror a $XX_TOP structure. Meaning
the files will be in the same directories and sub-directories that are found in the APPL_TOP product directories.
Example of an Unbundled Patch
Following is an example of the directory structure of an unbundled patch. After p2145632_11i_SOLARIS.zip is unzipped, it creates the directory 2145632.
2145632
____________________|________________________
| | | |
ad c2145632.drv d2145632.drv readme.txt
|________________________________
| | |
admin patch lib
| | |
115 115 adadmin.o
| |
driver sql
| |____________
adcon.drv | |
adnuniq.sql aduvers.pls
IV. Installing a Patch
Following are the basic steps to installing a patch on R11i.
1. Have all Oracle Application users log out and shut down the concurrent managers.
2. Run the environment file found in $APPL_TOP to set the environment.
3. Make sure $ORACLE_HOME and $ORACLE_SID or $TWO_TASK are set correctly.
4. unzip the patch.
unzip p2145632_11i_SOLARIS.zip
5. Go to the patch directory created by ‘unzip’.
6. Read the readme and follow the instructions! If there are any steps to execute before starting the patch, they must be executed first. Such as applying a prerequisite patch.
7. To begin applying the patch the first step will be to run the ‘c’ driver, c2145632.drv. To start the adpatch process, just type:
adpatch
8. After the patch completes successfully, adpatch may need to be run again using a ‘d’ (database) and/or ‘g’ (generate) driver that is included with the patch. Consult the readme for specifics.
OPTION: Beginning with R11i AutoPatch has a non-interactive mode. Using this mode, users can run all drivers for a given patch in a single non-interactive AutoPatch session by using a defaults file. This is a very useful feature, simplifying the patch process for the customer. Details on how to use this feature can be found in the R11i ‘Maintaining Oracle Applications’ document.
Following are examples of the questions that are asked when running adpatch. In bold are additional comments that I have added to explain the questions and their answers. Any values in [ ] are the default answer, and will be used if the user just presses the enter or return key.
Individual Patch, One-off, Standalone
These are terms used to describe an individual patch that is created to fix one particular bug. Currently, most Application products deliver their patches primarily through ‘Mini Packs’. Individual patches are possible, but rules for when one is created varies by product.
Mini Pack
‘Patch Set’ was the original term used in R10. In R11 the same type of patch is now being called a ‘Mini Pack’. Both terms mean a large, cumulative patch, for a particular product, that fixes most or all bugs that have been fixed for that release and product. These patches are….
· Named using a letter.
Þ 11i.PA.D
· Cumulative.
Þ For example, 11i.AP.D, would include fixes in AP.A, AP.B, AP.C, plus bugs fixed between when AP.C was released and when they began building AP.D.
· Created periodically.
Þ How often they are created varies by product.
· Require just one patch.
Þ However, if the install is a multi-node install, then the patch must be installed on each machine.
Þ If different platforms are used, the patch must be ported for each platform.
Family Pack
‘Family Pack’ is a group of Mini Packs for related products that are bundled together, and possibly some additional individual fixes that have been created after the Mini Packs. Some examples of product families are ERP, CRM, Procurement, or Order Management, but there are many others.
The same bulleted information for Mini Packs applies for Family Packs. The only difference is the naming structure. Family Packs will be named similar to:
· 11i.OM_PF.G or 11i.FINAP_PF.A
· The ‘_PF’ in the name indicates it is a Family Pack and not a Mini Pack.
FCUP or Family Consolidated Upgrade Patch
An FCUP (pronounced F-CUP) is a patch that needs to be applied before starting an upgrade. This patch includes performance improvements or bug fixes for processes that run during the upgrade. If an FCUP is required for an upgrade, it will be mentioned in the Release Notes.
Consolidated Patch or Mega Patch
These are unofficial terms that are used to name, or describe, a large patch that is a bundle of important bug fixes in one patch.
Maintenance Pack
Maintenance Pack is the term that Oracle began using for R11, while Release Update was used for R10.
A ‘Maintenance Pack’ is a collection of Mini Packs that are bundled together onto a set of CDs that can be ordered and easily installed by the customer.
· With the full installation of this type of patch, the 3rd digit of Applications Release will change.
Þ An example of a Maintenance Pack is 11.5.3 or 11.5.5
· When applying a Maintenance Pack, a user can choose to apply certain product’s Mini Packs individually, or they can apply all the product’s Mini Packs at once using one set of drivers.
Þ The Application’s version will not be updated, for example to 11.5.5, if the Mini Packs are applied individually.
· As with Mini Packs, Maintenance Packs are cumulative.
Þ So if 11.5.5 is applied, then prior Maintenance Packs do not need to be applied.
(11.5.1, 11.5.2, 11.5.3, 11.5.4).
· The primary purpose of Maintenance Packs is to fix bugs that have been identified. However, on occasion new functionality may be introduced.
NLS Patches
If your install has multiple languages, additional patches may need to be installed for each language. The
American patch needs to be applied first, then an NLS version of the same patch needs to be applied for each language. When applying the NLS patch, be sure to set the NLS_LANG variable to AMERICAN_AMERICA.
Not ALL patches will require an NLS version of a patch. For example, if the patch is only creating a new package, an NLS patch would not be required. However a patch that is replacing a form or report, or all large patches, such as Mini Packs or Maintenance Packs will require an NLS patch. Consult Oracle Support to confirm if an NLS patch is needed when applying a patch.
Adpatch has a function that was introduced in 11i that will alert the customer if an NLS patch may be needed. During patch application, the user will receive a message that an NLS patch may be required, and ask the user if they want to continue with the application of the patch.
Minor Release
Examples of a minor release are 10.7, 11.0, or 11.5. A minor release is not a patch.
· A Minor Release is installed using autoUpgrade, not adpatch, to upgrade to the release.
· The primary purpose of a Minor release is to introduce new functionality.
· Supported versions of Applications are based off of a Minor Release.
II. Basic Explanation of R11 Architecture
In order to understand how R11 patches are applied, the R11 architecture needs to be explained. For a complete picture, reading the manual Oracle Applications Release 11 for UNIX Concepts (Part# A90380) is recommended.
Documented below is a very simple explanation of R11i Architecture. Note, this is not a complete description, and to get a full understanding the Concepts manual should be read.
Beginning with R11, Oracle allows the user to break up their install according to their needs. The user can determine where to install 4 different ‘servers’. The Forms, Web, Concurrent Manager, and Admin servers can be installed all on one machine or broken up onto numerous machines.
Database Tier
Concurrent Processing Server
· Concurrent processes (Ex: reports, executables)
Administration Server
· Files that maintain the database (Ex: patch/110/sql)
Application Tier
Forms Server
· GUI Forms (.fmb and .fmx)
Web Server
· html and java files
Desktop Client Tier
· Contains appletviewer or JInitiator to log on to Applications from the client
Do not interpret the term ‘Server’, such as Forms Server, to mean a machine, such as Solaris or NT. These servers can all be on the same machine (single node install), or divided into numerous machines (multi-node install). For example, the user could have the Concurrent Processing Server and the Administration Server on a Solaris, and the Forms Server and the Web Server on an NT. This is the commonly used ‘two-node’ type of install. Many other combinations can be used, including multiple Forms Servers for Load Balancing or Fault Tolerance.
When a patch was applied in R11.0, the patch process asked 4 questions to determine which of the 4 different servers existed on the machine the patch was being applied to. These questions are listed below. In ( ) under the question is the server that these questions correspond to.
Do you currently have files used for installing or upgrading the database
installed in this $APPL_TOP [Yes] ?
(Administration Server)
Do you currently have Java and HTML files for Self-Service Applications
installed in this $APPL_TOP [Yes] ?
(Web Server)
Do you currently have Oracle Applications forms files installed
in this $APPL_TOP [Yes] ?
(Forms Server)
Do you currently have concurrent program files
installed in this $APPL_TOP [Yes] ?
(Concurrent Processing Server)
After these questions were answered, adpatch would know which files it needed to copy and the jobs it would need to perform.
In R11i, the install process stores the answer to these 4 questions in the file $APPL_TOP/admin/adconfig.txt. Then when adpatch is run, it reads this file and automatically answers the 4 questions for the user. This makes adpatch easier, and helps prevent user error.
Example:
The Applications instance has two machines.
Solaris Machine A, has the Concurrent Manager and Administration servers
NT Machine B, has the Forms and Web servers
The patch, ported for Solaris, would need to be applied to Machine A. The adconfig.txt file would then be read and answer the 4 questions for the user. In this case the answers to the questions should be, ‘Yes’ for questions 1 and 4, and ‘No’ for questions 2 and 3.
The same patch, ported for NT, would then be applied to Machine B, and the questions answered in the reverse. ‘Yes’ to 2 & 3. ‘No’ to 1 & 4.
III. Anatomy of a Patch
All R11 and R11i patches use the zip function instead of ‘tar’, which was used in R10
To unbundle the patch, simply use the unzip command:
unzip p2145632_11i_SOLARIS.zip
When a patch is unbundled it creates a directory that is the same number as the bug number which is included in the patch name. For example, p2145632_11i_SOLARIS.zip will create the directory 2145632. The 2145632 directory will contain the following:
readme.txt This is a text file that contains a brief explanation of what the patch fixes,and instructions on how to apply the patch. It is VERY important to thoroughly read this file, some examples of important information it may contain are:
· Prerequisite patch(s) that must be applied before applying the current patch.
· References to .html file(s) that are also included in the patch, which contains additional installation steps or instructions.
· Manual steps that must be executed before or after applying the patch.
· An explanation of a new feature introduced by the patch.
· Restrictions on who or when the patch can be applied.
· Instructions to run the patch in preinstall mode.
IMPORTANT: It is very important that the instructions in the readme are followed closely. Not following the readme may cause the patch to fail, not correct the problem it was intended to fix, or potentially introduce additional problems.
cXXXXXX.drv The ‘c’ or copy driver, and the first driver file executed. A driver provides adpatch with the instructions on the jobs it needs to perform. This driver copies files from patch to directories, relinks executables, and regenerates jar files.
dXXXXXX.drv The ‘d’ or ‘Database’ driver, which is the second driver file executed, if it exists. A patch will contain a database driver only if the patch contains files that will update the database, such as files in the patch/115/ sub-directories. Some examples, are scripts that…
· Create packages
· Create new error messages
· Add a new table or view to the database
· Add a new column to a table
· Add new seed data to a table
dXXXXXX.cf R11i patches created after December 2001 will include an additional
d driver, but with the .cf extension instead of .drv. This is used by a new adpatch feature, called the checkfile feature, which is introduced in an AD Mini Pack, or with some individual AD patches.
This feature is explained in depth by patches that introduce the feature,
such as 1945611 or the latest AD Mini Pack. But the following is a quick
explanation.
The checkfile feature can reduce the time to apply a d driver by not running
processes that have already been run. Such as FNDLOAD, WFLOAD, akload.class or any process in the d driver. It does this by creating a table, which stores the versions for the files used by these processes, then adpatch will check the version in the patch against the version stored in this table. If the version in the patch is not a higher version, then the process will be skipped. Adpatch is run the exact same way, but the .cf driver file is used instead of the .drv driver.
If a patch is applied using this driver without the new feature installed, the adpatch session will fail at the start.
gXXXXXX.drv The ‘g’ or ‘Generate’ driver, which is the third driver file executed, if it exists. A patch will contain a generate driver only if the patch contains files,such as forms, reports, graphics or messages, that need to be generated.
jXXXXXX.zip This zip file may be included in Java patches. This file is called a
Zipped Resource Unit or ZRU. If a patch contains a ZRU, it does not need to be unzipped. This is a zip file that contains ‘.class’ files and other web related files. The .zip file will be called and applied when adpatch is run with the c driver.
Product directories Each patch will contain at least one product directory (ap, gl, inv, etc.) that will contain sub-directories and the files that are included in the patch. The product directories in the patch will mirror a $XX_TOP structure. Meaning
the files will be in the same directories and sub-directories that are found in the APPL_TOP product directories.
Example of an Unbundled Patch
Following is an example of the directory structure of an unbundled patch. After p2145632_11i_SOLARIS.zip is unzipped, it creates the directory 2145632.
2145632
____________________|________________________
| | | |
ad c2145632.drv d2145632.drv readme.txt
|________________________________
| | |
admin patch lib
| | |
115 115 adadmin.o
| |
driver sql
| |____________
adcon.drv | |
adnuniq.sql aduvers.pls
IV. Installing a Patch
Following are the basic steps to installing a patch on R11i.
1. Have all Oracle Application users log out and shut down the concurrent managers.
2. Run the environment file found in $APPL_TOP to set the environment.
3. Make sure $ORACLE_HOME and $ORACLE_SID or $TWO_TASK are set correctly.
4. unzip the patch.
unzip p2145632_11i_SOLARIS.zip
5. Go to the patch directory created by ‘unzip’.
6. Read the readme and follow the instructions! If there are any steps to execute before starting the patch, they must be executed first. Such as applying a prerequisite patch.
7. To begin applying the patch the first step will be to run the ‘c’ driver, c2145632.drv. To start the adpatch process, just type:
adpatch
8. After the patch completes successfully, adpatch may need to be run again using a ‘d’ (database) and/or ‘g’ (generate) driver that is included with the patch. Consult the readme for specifics.
OPTION: Beginning with R11i AutoPatch has a non-interactive mode. Using this mode, users can run all drivers for a given patch in a single non-interactive AutoPatch session by using a defaults file. This is a very useful feature, simplifying the patch process for the customer. Details on how to use this feature can be found in the R11i ‘Maintaining Oracle Applications’ document.
Following are examples of the questions that are asked when running adpatch. In bold are additional comments that I have added to explain the questions and their answers. Any values in [ ] are the default answer, and will be used if the user just presses the enter or return key.
Starting and Stopping Apps Server
Startup / Shutdown Apps
As you are aware by now there is Database Tier ( Database & DB Listener ) and Application Tier ( WebServer, Forms, Reports, Concurrent Manager, Discoverer, Apps Listener, OnetoOne Fullfillment Server )
Order of StartUp of Services Should be
First DB Listener, Database & then Application Tier Services
Order of ShutDown of Services Should be
First Application Tier Services then Database & DB Listener
Database Startup/Shutdown Scripts
Depending on your AD Version these will be in ORACLE_HOME / appsutil/scripts /SID_hostname
addbctl.sh database startup shutdown script
addlnctl.sh database listener Script
Where
AD is for Application DBA
DB is for database
DLN is database listener
CTL is control
Application Tier Startup/Shutdown Scripts
Depending on your AD Version these will be in
OAD_TOP/admin/scripts/ SID_hostname
adalnctl.sh Apps Listener Control Script
adapcctl.sh Apache/Web Server Control Script
adcmctl.sh Concurrent Manager Control Script
addisctl.sh Discoverer Control Script
adfrmctl.sh Forms server Control Script
adrepctl.sh Report Server Control Script
adstpall.sh Stop All Middle/Application Tier
adstrtall.sh Start All Middle/Application Tier
Where
adl stand for Apps Listener
apc stand for Apache
cm Concurrent Manager
dis Discoverer
frm forms
rep report
As you are aware by now there is Database Tier ( Database & DB Listener ) and Application Tier ( WebServer, Forms, Reports, Concurrent Manager, Discoverer, Apps Listener, OnetoOne Fullfillment Server )
Order of StartUp of Services Should be
First DB Listener, Database & then Application Tier Services
Order of ShutDown of Services Should be
First Application Tier Services then Database & DB Listener
Database Startup/Shutdown Scripts
Depending on your AD Version these will be in ORACLE_HOME / appsutil/scripts /SID_hostname
addbctl.sh database startup shutdown script
addlnctl.sh database listener Script
Where
AD is for Application DBA
DB is for database
DLN is database listener
CTL is control
Application Tier Startup/Shutdown Scripts
Depending on your AD Version these will be in
OAD_TOP/admin/scripts/ SID_hostname
adalnctl.sh Apps Listener Control Script
adapcctl.sh Apache/Web Server Control Script
adcmctl.sh Concurrent Manager Control Script
addisctl.sh Discoverer Control Script
adfrmctl.sh Forms server Control Script
adrepctl.sh Report Server Control Script
adstpall.sh Stop All Middle/Application Tier
adstrtall.sh Start All Middle/Application Tier
Where
adl stand for Apps Listener
apc stand for Apache
cm Concurrent Manager
dis Discoverer
frm forms
rep report
Checking the Internal Concurrent Manager Status
On most sites the using Oracle Applications the common practice of an Oracle Apps DBA is to check the Unix Process of the Internal Concurrent Manager using the command:
ps –ef | grep CPMGR
or
ps –ef | grep FNDCPMBR
applmgr 24988 24984 0 Dec 26 ? 5:16 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/rpt/co
applmgr 20050 20040 0 Dec 16 ? 3:30 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/rpt/co
applmgr 19900 19889 0 Dec 16 ? 4:53 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/rpt/co
applmgr 22629 22624 0 Dec 16 ? 0:56 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/applmg
applmgr 24757 24753 0 Dec 26 ? 5:04 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/rpt/co
Well, either way the result of the output will be the same, because the search string exists in the output. If you have a single instance, then you would get just one output and that would help to know that the Internal Concurrent Manager Process is up (Note: Not necessarily running or active).
In case you have different releases of Oracle Apps on the same server and if the output of the command above is as shown, then it would be difficult to find out which background process belongs to which Application.
The goal of this Paper is to find out not only if the background process is alive, but also to find out if the Internal Manager is really active and to find the same across releases. Note different releases have different ways of addressing this problem, which you would see as we go along.
According to Oracle Notes:
Internal Concurrent Manager's function is only to run 'queue control' requests, which are requests to
startup or shutdown other managers. It is responsible for startup and shutdown of the whole
concurrent processing facility, and it also monitors the other managers periodically, and restarts them
if they should go down. It can also take over the Conflict Resolution manager's job, and
resolve incompatibilities. If the ICM itself should go down, requests will continue to run normally,
except for 'queue control' requests. If the ICM should go down, you can restart it with 'startmgr'.
You do not need to kill the other managers first.
From the above note it is clear that, if the Internal Concurrent Manager is not active, then the background process would still exist and might become a zombie. The Activation of the other managers and failed managers would not happen and the normal symptom would be the Conflict Resolution Manager piling up all the requests. An example of which would be when the Internal Manager goes down with an error :
APP-01167 Internal Concurrent Manager has encountered an error.
This error would be in the ORACLE_SID.mgr file in the directory $APPLCSF/$APPLLOG , where all the Manager information log goes into, provided you have set the environment correctly in the APPLSYS.env file. This error is logged when an Internal Manager encounters various errors and deactivates the Internal Concurrent Manager and sets its Active process to zero.
You can check if the the Active process is zero by logging in to the Application and navigate to,
Concurrent Manager Administor
You would see that the Internal Manager’s Active Process would be zero and the Target Process would be one. The background CPMGR related process would be running, so this does not reflect the correct status of the Internal Concurrent Manager.
You can also check which process belongs to which database by picking the OS Process ID ORACLE_SID.mgr file in the directory $APPLCSF/$APPLLOG , where the OS Process ID gets logged when the Internal Manager comes up but it is more work, example logfile output,
========================================================================
Starting dev3 internal concurrent manager -- shell process ID 24984
logfile=/Ora_base/thor/rpt/common/logdev3/dev3.mgr
PRINTER=ioo341
mailto=applmgr
restart=N
diag=N
sleep=30
pmon=20 (default)
quesiz=1 (default)
+---------------------------------------------------------------------------+
ps -ef | grep 24984
applmgr 24988 24984 0 Dec 26 ? 5:20 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 ogfile=/Ora_base/thor/rpt/co
From the above command we know that the Internal Manager Process exists and is running for Database DEV3, but does not show dev3 anywhere at the backend when you grep the PPID or the PID. You can then verify the Internal Manager from the front-end application to check if it is running.
This shows that it is imperative that we not only check the Internal Manager Background process, but also to make sure that the Actual Process of the Internal Manager is not set to zero and running.
From the above ps –ef | grep CPMGR command we got an output of Five Internal Manager Background process and we have to now figure out which process belongs to which database, which is essentially our goal.
10.7 SC/ NCA
In this release the Oracle Home was common for both the database and the Application, so the Internal Concurrent Manager background process was always spawned by a parent process that had an ORACLE_SID attached to it. We could easily check which process belongs to which database by comparing the parent process with the Internal Manager process like:
ps -ef | grep -v grep | grep FNDCPMBR | awk '{print $2}' | while read CMPID
do
ps -ef | nawk -v CMPPID=$CMPID '{if (CMPPID == $3) {print $0} }' | grep oracle
$ORACLE_SID >/dev/null
if [ $? == 0 ] ; then
echo "Conc Mgr for database=$ORACLE_SID is UP"
Here we check the background process only and presume that the Internal Manager is up and running and incase its Active process gets set to zero due to errors, it doesn’t raise a flag, only the users and developers would call up to say that all the request are clogging.
10.7 NCA Server Partition Mode:
In the server partition mode, the parent process drops off once the Internal Manager Process is spawned, so it becomes difficult to compare like we did in the previous script to find out which process belongs to which database. We have to manually check the log file and get the OS Process ID for the Internal Manager and then do a grep on the Process ID. Then use the Unix “ pstree ID“ command to trace the process and pick the parent ID and its corresponding ORACLE_SID.
The better way to do that would be to log on to the Application and pick the same OS Process ID of the Internal Concurrent Manager that gets logged in the $APPLCSF/$APPLLOG/ORACLE_SID.mgr file from the database by querying the table FND_CONCURRENT_PROCESSES. The table registers the OS Process ID in the field OS_PROCESS_ID and we can also check the Running_Processes to find out if the Actual Process is not equal to zero.
Once the OS Process Id and the active Process is checked we can then pick the corresponding ORACLE_PORCESS_ID from the same table and compare it with the SID in the dynamic view v$session. The FND_CONCURENT_QUEUE would identify if the process is the Internal Manager Process, and hence it would check comparing the APPLICATION_ID’s. The paddr of the v$session for the SID would then be compared with the addr of V$Process and the corresponding SPID can be retrieved. This SPID would be the spawned parent ID that would have the ORACLE_SID attached to it.
The script below exactly does the same:
********************************** CUT HERE **********************************************
#!/bin/ksh
#===========================================================================
# Filename: icmtest107
# Author : Shankar Govindan.
# Created : 12/25/2001
# Good for : Release 107 Server Partition Mode only
# Description : This script is used for checking out the status of Internal Manager in Oracle APPS,
# It picks up the OS_PROCESS_ID from FND_CONCURRENT_PROCESSES, spools
# them and then looks for the actual OS process with its corresponding ORACLE_SID.
# The grep looks for SPID and LOCAL = NO because of Oracle version 7x.
# Note : I have used a password file with system/manager which is in my /dba/etc dir.
#
# 1st Argument: status
# 2nd Argument: ORACLE_SID (optional)
#
#===========================================================================
if ( [ "$1" != "status" ] )
then
echo "Usage: $0 status "
echo " Eg.: $0 status OSID"
exit
fi
CMD=$1
OSID=$2
ORACLE_SID=`echo $ORACLE_SID`
TEMPDIR=`pwd`
GROUP=`groups | cut -d" " -f1`
function _icmtestcmd
{
echo "==========================================================================="
echo "checking Internal concurrent Manager status for Database ${ORACLE_SID} "
date
echo "==========================================================================="
echo
PWD_FILE=/dba/etc/.${GROUP}_${ORACLE_SID}.pwd
SYSTEM_PWD=`grep -i "^system/" $PWD_FILE`
case $CMD in
status)
if [ "$SYSTEM_PWD" = "" ] ; then
echo "\nERROR: userid=system does not exist in ${PWD_FILE}"
return 1
fi
# echo "** Sending status for Oracle database=${ORACLE_SID}"
(echo ${SYSTEM_PWD}; echo set pages 0 pause off verify off feedback off termout off; echo "select p
.spid from v\$process p, v\$session s, apps.fnd_concurrent_processes f, apps.fnd_concurrent_queues
q where p.addr = s.paddr and s.sid = f.oracle_process_id and f.concurrent_queue_id = q.concurrent_q
ueue_id and q.concurrent_queue_name = 'Internal Manager' and q.running_processes = 1 group by p.spi
d order by 1 ;") | sqlplus -s > $TEMPDIR/icmppid
ps -ef | grep -i `cat $TEMPDIR/icmppid` |grep NO | while read LINE
do
MATCH=`echo $LINE | awk '{print $9}'`
if [ "$MATCH" = "oracle${ORACLE_SID}" ] ; then
echo "For Database=$ORACLE_SID , Internal Concurrent Manager is UP and RUNNING !!"
echo
return 1
echo
else
echo "Database=$ORACLE_SID Internal Concurrent Manager is DOWN"
echo
fi
done
return 0
;;
*) echo "\nERROR: Invalid option=$CMD (in function _icmtestcmd)"
return 2
;;
esac
}
#
#MAIN
#
if [ "$CMD" = "status" ];
then
_icmtestcmd $CMD $OSID
else
echo "Check the Command again "
wait
return 1
fi
********************************** CUT HERE **********************************************
Oracle Apps Release 11 :
In Release 11, the setup is similar to 10.7 NCA without the server partition mode, the old scripts would hold good, but it does not the check the active process from the database to compare and hence the script of 10.7 NCA server Partition Mode would be a better one.
Although the concept for getting the information is the same, the stored information in the AOL tables has changed from 10.7 to Rel 11. The FND_CONCURRENT_QUEUES table does not store the CONCURRENT_QUEUE_NAME = ‘Internal Manager’ but as ‘FNDICM’, so we pick the information from the view FND_CONCURENT_QUEUE_VL.USER_CONCURRENT_QUEUE_NAME = ‘Internal Concurrent Manager ‘ and all the other info from the same view. The rest of the information are retrieved just like the above script used for 10.7 NCA Server Partition Mode.
In the Rel 11 we use Net 8 Adapter and according to Oracle,
The BEQUEATH adapter is essentially a true Net8 adapter though it has one unique distinction in
that it does not connect to Oracle kernel via a Listener process, it connects directly to the kernel.
Oracle 8 applications use the BEQUEATH adapter by default though you can specify a TNS
alias for BEQUEATH. The BEQUEATH adapter has been around since Oracle 7.3.3. However,
there were problems using 7.3.3. and Net 2.3.3 to connect to a local Oracle 8 kernel. These
were addressed in the 7.3.4/2.3.4 release.
In 10.7 Sever Partition Mode script we grep not only for the Process ID, but also grep for LOCAL=NO, since that identifies the connectivity for the process. In Release 11 we grep LOCAL = YES because of the above explanation for Net 8 adapter for Oracle 8 Kernel, the connection would look like:
oracle 22637 22633 0 Dec 16 ? 0:04 oracledev4 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
The script used for Release 11 Internal Manager status check:
************************************* Cut Here *********************************************
#!/bin/ksh
#===========================================================================
# Filename: icmtest_rel11
# Author : Shankar Govindan.
# Created : 01/04/2002
# Good for : Release 11 only
# Description : This script is used for checking out the status of Internal Manager in Oracle APPS,
# It picks up the OS_PROCESS_ID from FND_CONCURRENT_PROCESSES, spools them
# and then looks for the actual OS process with its corresponding ORACLE_SID.
# The grep looks for SPID and LOCAL = YES because of REL 11 SqlNet beq default mode.
# Note : I have used a password file with system/manager.
#
# 1st Argument: status
# 2nd Argument: ORACLE_SID (optional)
#
#===========================================================================
if ( [ "$1" != "status" ] )
then
echo "Usage: $0 status "
echo " Eg.: $0 status "
exit
fi
CMD=$1
OSID=$2
ORACLE_SID=`echo $ORACLE_SID`
TEMPDIR=`pwd`
GROUP=`groups | cut -d" " -f1`
function icmtestcmd_rel11
{
echo "==========================================================================="
echo "checking Internal concurrent Manager status for Database ${ORACLE_SID} "
date
echo "==========================================================================="
echo
PWD_FILE=/dba/etc/.${GROUP}_${ORACLE_SID}.pwd
SYSTEM_PWD=`grep -i "^system/" $PWD_FILE`
case $CMD in
status)
if [ "$SYSTEM_PWD" = "" ] ; then
echo "\nERROR: userid=system does not exist in ${PWD_FILE}"
return 1
fi
# echo "** Sending status for Oracle database=${ORACLE_SID}"
(echo ${SYSTEM_PWD}; echo set pages 0 pause off verify off feedback off termout off; echo "select p
.spid from v\$process p, v\$session s, apps.fnd_concurrent_processes f, apps.fnd_concurrent_queues_
vl q where p.addr = s.paddr and s.audsid = f.session_id and f.concurrent_queue_id = q.concurrent_qu
eue_id and f.queue_application_id = q.application_id and q.user_concurrent_queue_name = 'Internal M
anager' and q.manager_type = f.manager_type and q.running_processes = 1 group by p.spid order by 1
;") | sqlplus -s > $TEMPDIR/icmppid
ps -ef | grep -i `cat $TEMPDIR/icmppid` | grep YES | while read LINE
do
MATCH=`echo $LINE | awk '{print $9}'`
if [ "$MATCH" = "oracle${ORACLE_SID}" ] ; then
echo "For Database=$ORACLE_SID , Internal Concurrent Manager is UP and RUNNING !!"
echo
return 1
echo
else
echo "Database=$ORACLE_SID Internal Cocnurrent Manager is DOWN"
echo
fi
done
return 0
;;
*) echo "\nERROR: Invalid option=$CMD (in function _icmtestcmd)"
return 2
;;
esac
}
#
#MAIN
#
if [ "$CMD" = "status" ];
then
icmtestcmd_rel11 $CMD $OSID
else
echo " Check your command "
wait
return 1
fi
ps –ef | grep CPMGR
or
ps –ef | grep FNDCPMBR
applmgr 24988 24984 0 Dec 26 ? 5:16 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/rpt/co
applmgr 20050 20040 0 Dec 16 ? 3:30 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/rpt/co
applmgr 19900 19889 0 Dec 16 ? 4:53 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/rpt/co
applmgr 22629 22624 0 Dec 16 ? 0:56 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/applmg
applmgr 24757 24753 0 Dec 26 ? 5:04 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 logfile=/Ora_base/thor/rpt/co
Well, either way the result of the output will be the same, because the search string exists in the output. If you have a single instance, then you would get just one output and that would help to know that the Internal Concurrent Manager Process is up (Note: Not necessarily running or active).
In case you have different releases of Oracle Apps on the same server and if the output of the command above is as shown, then it would be difficult to find out which background process belongs to which Application.
The goal of this Paper is to find out not only if the background process is alive, but also to find out if the Internal Manager is really active and to find the same across releases. Note different releases have different ways of addressing this problem, which you would see as we go along.
According to Oracle Notes:
Internal Concurrent Manager's function is only to run 'queue control' requests, which are requests to
startup or shutdown other managers. It is responsible for startup and shutdown of the whole
concurrent processing facility, and it also monitors the other managers periodically, and restarts them
if they should go down. It can also take over the Conflict Resolution manager's job, and
resolve incompatibilities. If the ICM itself should go down, requests will continue to run normally,
except for 'queue control' requests. If the ICM should go down, you can restart it with 'startmgr'.
You do not need to kill the other managers first.
From the above note it is clear that, if the Internal Concurrent Manager is not active, then the background process would still exist and might become a zombie. The Activation of the other managers and failed managers would not happen and the normal symptom would be the Conflict Resolution Manager piling up all the requests. An example of which would be when the Internal Manager goes down with an error :
APP-01167 Internal Concurrent Manager has encountered an error.
This error would be in the ORACLE_SID.mgr file in the directory $APPLCSF/$APPLLOG , where all the Manager information log goes into, provided you have set the environment correctly in the APPLSYS.env file. This error is logged when an Internal Manager encounters various errors and deactivates the Internal Concurrent Manager and sets its Active process to zero.
You can check if the the Active process is zero by logging in to the Application and navigate to,
Concurrent Manager Administor
You would see that the Internal Manager’s Active Process would be zero and the Target Process would be one. The background CPMGR related process would be running, so this does not reflect the correct status of the Internal Concurrent Manager.
You can also check which process belongs to which database by picking the OS Process ID ORACLE_SID.mgr file in the directory $APPLCSF/$APPLLOG , where the OS Process ID gets logged when the Internal Manager comes up but it is more work, example logfile output,
========================================================================
Starting dev3 internal concurrent manager -- shell process ID 24984
logfile=/Ora_base/thor/rpt/common/logdev3/dev3.mgr
PRINTER=ioo341
mailto=applmgr
restart=N
diag=N
sleep=30
pmon=20 (default)
quesiz=1 (default)
+---------------------------------------------------------------------------+
ps -ef | grep 24984
applmgr 24988 24984 0 Dec 26 ? 5:20 FNDLIBR FND CPMGR FNDCPMBR sysmgr="" sleep=30 ogfile=/Ora_base/thor/rpt/co
From the above command we know that the Internal Manager Process exists and is running for Database DEV3, but does not show dev3 anywhere at the backend when you grep the PPID or the PID. You can then verify the Internal Manager from the front-end application to check if it is running.
This shows that it is imperative that we not only check the Internal Manager Background process, but also to make sure that the Actual Process of the Internal Manager is not set to zero and running.
From the above ps –ef | grep CPMGR command we got an output of Five Internal Manager Background process and we have to now figure out which process belongs to which database, which is essentially our goal.
10.7 SC/ NCA
In this release the Oracle Home was common for both the database and the Application, so the Internal Concurrent Manager background process was always spawned by a parent process that had an ORACLE_SID attached to it. We could easily check which process belongs to which database by comparing the parent process with the Internal Manager process like:
ps -ef | grep -v grep | grep FNDCPMBR | awk '{print $2}' | while read CMPID
do
ps -ef | nawk -v CMPPID=$CMPID '{if (CMPPID == $3) {print $0} }' | grep oracle
$ORACLE_SID >/dev/null
if [ $? == 0 ] ; then
echo "Conc Mgr for database=$ORACLE_SID is UP"
Here we check the background process only and presume that the Internal Manager is up and running and incase its Active process gets set to zero due to errors, it doesn’t raise a flag, only the users and developers would call up to say that all the request are clogging.
10.7 NCA Server Partition Mode:
In the server partition mode, the parent process drops off once the Internal Manager Process is spawned, so it becomes difficult to compare like we did in the previous script to find out which process belongs to which database. We have to manually check the log file and get the OS Process ID for the Internal Manager and then do a grep on the Process ID. Then use the Unix “ pstree ID“ command to trace the process and pick the parent ID and its corresponding ORACLE_SID.
The better way to do that would be to log on to the Application and pick the same OS Process ID of the Internal Concurrent Manager that gets logged in the $APPLCSF/$APPLLOG/ORACLE_SID.mgr file from the database by querying the table FND_CONCURRENT_PROCESSES. The table registers the OS Process ID in the field OS_PROCESS_ID and we can also check the Running_Processes to find out if the Actual Process is not equal to zero.
Once the OS Process Id and the active Process is checked we can then pick the corresponding ORACLE_PORCESS_ID from the same table and compare it with the SID in the dynamic view v$session. The FND_CONCURENT_QUEUE would identify if the process is the Internal Manager Process, and hence it would check comparing the APPLICATION_ID’s. The paddr of the v$session for the SID would then be compared with the addr of V$Process and the corresponding SPID can be retrieved. This SPID would be the spawned parent ID that would have the ORACLE_SID attached to it.
The script below exactly does the same:
********************************** CUT HERE **********************************************
#!/bin/ksh
#===========================================================================
# Filename: icmtest107
# Author : Shankar Govindan.
# Created : 12/25/2001
# Good for : Release 107 Server Partition Mode only
# Description : This script is used for checking out the status of Internal Manager in Oracle APPS,
# It picks up the OS_PROCESS_ID from FND_CONCURRENT_PROCESSES, spools
# them and then looks for the actual OS process with its corresponding ORACLE_SID.
# The grep looks for SPID and LOCAL = NO because of Oracle version 7x.
# Note : I have used a password file with system/manager which is in my /dba/etc dir.
#
# 1st Argument: status
# 2nd Argument: ORACLE_SID (optional)
#
#===========================================================================
if ( [ "$1" != "status" ] )
then
echo "Usage: $0 status "
echo " Eg.: $0 status OSID"
exit
fi
CMD=$1
OSID=$2
ORACLE_SID=`echo $ORACLE_SID`
TEMPDIR=`pwd`
GROUP=`groups | cut -d" " -f1`
function _icmtestcmd
{
echo "==========================================================================="
echo "checking Internal concurrent Manager status for Database ${ORACLE_SID} "
date
echo "==========================================================================="
echo
PWD_FILE=/dba/etc/.${GROUP}_${ORACLE_SID}.pwd
SYSTEM_PWD=`grep -i "^system/" $PWD_FILE`
case $CMD in
status)
if [ "$SYSTEM_PWD" = "" ] ; then
echo "\nERROR: userid=system does not exist in ${PWD_FILE}"
return 1
fi
# echo "** Sending status for Oracle database=${ORACLE_SID}"
(echo ${SYSTEM_PWD}; echo set pages 0 pause off verify off feedback off termout off; echo "select p
.spid from v\$process p, v\$session s, apps.fnd_concurrent_processes f, apps.fnd_concurrent_queues
q where p.addr = s.paddr and s.sid = f.oracle_process_id and f.concurrent_queue_id = q.concurrent_q
ueue_id and q.concurrent_queue_name = 'Internal Manager' and q.running_processes = 1 group by p.spi
d order by 1 ;") | sqlplus -s > $TEMPDIR/icmppid
ps -ef | grep -i `cat $TEMPDIR/icmppid` |grep NO | while read LINE
do
MATCH=`echo $LINE | awk '{print $9}'`
if [ "$MATCH" = "oracle${ORACLE_SID}" ] ; then
echo "For Database=$ORACLE_SID , Internal Concurrent Manager is UP and RUNNING !!"
echo
return 1
echo
else
echo "Database=$ORACLE_SID Internal Concurrent Manager is DOWN"
echo
fi
done
return 0
;;
*) echo "\nERROR: Invalid option=$CMD (in function _icmtestcmd)"
return 2
;;
esac
}
#
#MAIN
#
if [ "$CMD" = "status" ];
then
_icmtestcmd $CMD $OSID
else
echo "Check the Command again "
wait
return 1
fi
********************************** CUT HERE **********************************************
Oracle Apps Release 11 :
In Release 11, the setup is similar to 10.7 NCA without the server partition mode, the old scripts would hold good, but it does not the check the active process from the database to compare and hence the script of 10.7 NCA server Partition Mode would be a better one.
Although the concept for getting the information is the same, the stored information in the AOL tables has changed from 10.7 to Rel 11. The FND_CONCURRENT_QUEUES table does not store the CONCURRENT_QUEUE_NAME = ‘Internal Manager’ but as ‘FNDICM’, so we pick the information from the view FND_CONCURENT_QUEUE_VL.USER_CONCURRENT_QUEUE_NAME = ‘Internal Concurrent Manager ‘ and all the other info from the same view. The rest of the information are retrieved just like the above script used for 10.7 NCA Server Partition Mode.
In the Rel 11 we use Net 8 Adapter and according to Oracle,
The BEQUEATH adapter is essentially a true Net8 adapter though it has one unique distinction in
that it does not connect to Oracle kernel via a Listener process, it connects directly to the kernel.
Oracle 8 applications use the BEQUEATH adapter by default though you can specify a TNS
alias for BEQUEATH. The BEQUEATH adapter has been around since Oracle 7.3.3. However,
there were problems using 7.3.3. and Net 2.3.3 to connect to a local Oracle 8 kernel. These
were addressed in the 7.3.4/2.3.4 release.
In 10.7 Sever Partition Mode script we grep not only for the Process ID, but also grep for LOCAL=NO, since that identifies the connectivity for the process. In Release 11 we grep LOCAL = YES because of the above explanation for Net 8 adapter for Oracle 8 Kernel, the connection would look like:
oracle 22637 22633 0 Dec 16 ? 0:04 oracledev4 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
The script used for Release 11 Internal Manager status check:
************************************* Cut Here *********************************************
#!/bin/ksh
#===========================================================================
# Filename: icmtest_rel11
# Author : Shankar Govindan.
# Created : 01/04/2002
# Good for : Release 11 only
# Description : This script is used for checking out the status of Internal Manager in Oracle APPS,
# It picks up the OS_PROCESS_ID from FND_CONCURRENT_PROCESSES, spools them
# and then looks for the actual OS process with its corresponding ORACLE_SID.
# The grep looks for SPID and LOCAL = YES because of REL 11 SqlNet beq default mode.
# Note : I have used a password file with system/manager.
#
# 1st Argument: status
# 2nd Argument: ORACLE_SID (optional)
#
#===========================================================================
if ( [ "$1" != "status" ] )
then
echo "Usage: $0 status "
echo " Eg.: $0 status "
exit
fi
CMD=$1
OSID=$2
ORACLE_SID=`echo $ORACLE_SID`
TEMPDIR=`pwd`
GROUP=`groups | cut -d" " -f1`
function icmtestcmd_rel11
{
echo "==========================================================================="
echo "checking Internal concurrent Manager status for Database ${ORACLE_SID} "
date
echo "==========================================================================="
echo
PWD_FILE=/dba/etc/.${GROUP}_${ORACLE_SID}.pwd
SYSTEM_PWD=`grep -i "^system/" $PWD_FILE`
case $CMD in
status)
if [ "$SYSTEM_PWD" = "" ] ; then
echo "\nERROR: userid=system does not exist in ${PWD_FILE}"
return 1
fi
# echo "** Sending status for Oracle database=${ORACLE_SID}"
(echo ${SYSTEM_PWD}; echo set pages 0 pause off verify off feedback off termout off; echo "select p
.spid from v\$process p, v\$session s, apps.fnd_concurrent_processes f, apps.fnd_concurrent_queues_
vl q where p.addr = s.paddr and s.audsid = f.session_id and f.concurrent_queue_id = q.concurrent_qu
eue_id and f.queue_application_id = q.application_id and q.user_concurrent_queue_name = 'Internal M
anager' and q.manager_type = f.manager_type and q.running_processes = 1 group by p.spid order by 1
;") | sqlplus -s > $TEMPDIR/icmppid
ps -ef | grep -i `cat $TEMPDIR/icmppid` | grep YES | while read LINE
do
MATCH=`echo $LINE | awk '{print $9}'`
if [ "$MATCH" = "oracle${ORACLE_SID}" ] ; then
echo "For Database=$ORACLE_SID , Internal Concurrent Manager is UP and RUNNING !!"
echo
return 1
echo
else
echo "Database=$ORACLE_SID Internal Cocnurrent Manager is DOWN"
echo
fi
done
return 0
;;
*) echo "\nERROR: Invalid option=$CMD (in function _icmtestcmd)"
return 2
;;
esac
}
#
#MAIN
#
if [ "$CMD" = "status" ];
then
icmtestcmd_rel11 $CMD $OSID
else
echo " Check your command "
wait
return 1
fi
Subscribe to:
Posts (Atom)
