Showing posts with label r12.2. Show all posts
Showing posts with label r12.2. Show all posts

Sunday, 21 February 2016

What Happens during adop prepare Phase?

The online patching cycle in R12.2  which uses ADOP  utility applies patch in 5 Phases
The phases are



1)Prepares the Filesystem

During Prepare phase,RUN and PATCH filesystems are synchronized.By Default, Synchronization is done in incremental mode.
Full Synchronization is also available, if needed.

Changing APPS Password in R12.2

APPS Password in R12.2 can be changed either using AFPASSWD or FNDCPASSS utility. AFPASSWD is an enhancement to FNDCPASS.
To change APPS password , follow the below steps

1. Shut down MT Services

2.Use the syntax below to change password.


Sample Output: Enter the ORACLE password of Application Object Library ‘APPSUSER’:
Connected successfully to APPS.
Enter the password for your ‘SYSTEM’ ORACLE schema:
Connected successfully to SYSTEM.  Working…
Enter new password for user:
Verify new password for user:
AFPASSWD completed successfully.

Note that, to change APPS password we need to give APPLSYS username in AFPASSWD syntax.
APPLSYS and APPS share the same password. Changing APPLSYS password using AFPASSWD utility changes APPS Password also.

3. After the password is changed, start only adminserver on RUN filesystem  using the script

Update the “apps” password in WLS Datasource as follows:
Log in to WLS Administration Console.
Click Lock & Edit in Change Center.
In the Domain Structure tree, expand Services, then select Data Sources.
On the “Summary of JDBC Data Sources” page, select EBSDataSource.
On the “Settings for EBSDataSource” page, select the Connection Pool tab.
Enter the new password in the “Password” field.
Enter the new password in the “Confirm Password” field.
Click Save.
Click Activate Changes in Change Center.

4. Start all the application services using

Wednesday, 17 February 2016

Online Patching Steps in R12.2 (ADOP)

Basics of online Patching in R12.2

Online patching uses the latest feature of the Oracle database 11gR2 which is called “Edition Based
Redefinition” and also uses multiple file systems on the application side.
While online Patching with adop is in progress, users can use the application and database on RUN Filesystem.
Patch is applied on the alternate filesystem, which is an exact copy of RUN filesystem,called PATCH filesystem.
Users are switched to PATCH filesystem after the patching is complete.
Application is only offline during the Cutover phase.Downtime is now redefined as Cutover.

ADOP Patching Steps
1. Download the patch and unzip in PATCH_TOP directory.

2. Prepare the system for Patching

Source the RUN environment file
cd /test12/applmgr
. ./EBSapps.env RUN

adop phase=prepare

3. Source the PATCH Environment & apply patches:
cd /test12/applmgr
. ./EBSapps.env PATCH
==> Apply patch 19697098

Patch Location: /test12/applmgr/patches
adop phase=apply patchtop=/test12/applmgr/patches  patches=19697098

4..Run finalize.
adop phase=finalize

5. Cutover Phase

    $ adop phase=cutover
6. Cleanup old editions

    $ adop phase=cleanup
7. Synchronize RUN and PATCH filesystems.Start Fs_clone

adop phase=fs_clone

Sunday, 31 January 2016

How to Check Patch Applied Status in Oracle Applications?


From Oracle Applications Release 11i to 12.1.x, Patch application Status can be queried from ad_bugs or ad_applied_patches tables

Query to check whether patch is applied on a instance.

SQL>select bug_number,creation_date,last_update_date from apps.ad_bugs where bug_number='&patchnum';

SQL> select PATCH_NAME,CREATION_DATE from apps.ad_applied_patches where PATCH_NAME='&patchnum';

What is difference between above two Queries?

Suppose, we applied a patch which has multiple bugfixes.The details of all bugs fixed by the patch are listed in ad_bugs table.
In Contrast,ad_applied_patches table give info only about the patches which are applied through adpatch utility.


From Release 12.2, Online Patching utility(adop) is used for Patching application Filesystem.

Querying the data from ad_bugs or ad_applied_patches tables may not give correct information.Because, online patching can be aborted anytime prior to Cutover Phase.
ad_bugs or ad_applied_patches tables may contain entries for patches which are started through adop and later aborted.

The below query gives accurate Information about Patch Applied Status in R12.2

select AD_PATCH.IS_PATCH_APPLIED(\'$release\',\'$appltop_id\',\'$patch_no\',\'$language\') from dual;

example sql:
SELECT adb.bug_number,ad_patch.is_patch_applied('11i', 1045, adb.bug_number)
FROM ad_bugs adb
WHERE adb.bug_number in (22498647);

or for single app tier installations:
select ad_patch.is_patch_applied('R12',-1,22498647) from dual;

Sample Output:

EXPLICIT = applied
NOT APPLIED = not applied / aborted


Login to Database node as the database os user

Set environment using commands below

$export ORACLE_HOME=/u01/app/oracle/product/112

$export PATH=$PATH:$ORACLE_HOME/Opatch

$which opatch
==>It should give output like /u01/app/oracle/product/112/Opatch

$opatch lsinventory -invPtrLoc $ORACLE_HOME/oraInst.loc

== This gives list of all patches applied to the ORACLE_HOME

$opatch lsinventory -invPtrLoc $ORACLE_HOME/oraInst.loc|grep 988765

==> To check if a particular patch is applied to the ORACLE_HOME

R12-Password Change Utility

Oracle has introduced a new utility to change the Oracle E-Business Suite passwords in R12.1.2.AFPASSWD is an enhanced version of FNDCPASS utility.
Differances between AFPASSWD and FNDCPASS

1) AFPASSWD only prompts for passwords required for the current operation. allowing separation of duties between applications administrators and database administrators.
Changing sysadmin Password using AFPASSWD prompts only for APPS Password. Changing APPLSYS password prompts for APPS and SYSTEM password.
Whereas, FNDCPASS requires SYSTEM and APPS password to change password for application and database users.

2) AFPASSWD can be run from the database tier as well as the application tier. Whereas, FNDCPASS can be run only on Concurrent Manager Node

3) When changing a password with AFPASSWD, the user is prompted to enter the new password twice to confirm.

Changing SYSADMIN Password  

Output:Enter the ORACLE password of Application Object Library ‘APPSUSER’:
Connected successfully to APPS.  Working…
Enter new password for user [SYSADMIN]:
Verify new password for user [SYSADMIN]:
Password is changed successfully for user SYSADMIN.
Password is changed successfully for user SYSADMIN.
AFPASSWD completed successfully.

Changing APPLSYS Password

Syntax: $AFPASSWD -c apps@PROD -s APPLSYS
Output: Enter the ORACLE password of Application Object Library ‘APPSUSER’:
Connected successfully to APPS.
Enter the password for your ‘SYSTEM’ ORACLE schema:
Connected successfully to SYSTEM.  Working…
Enter new password for user:
Verify new password for user:
AFPASSWD completed successfully.


AFPASSWD [-c [@]] -f
AFPASSWD [-c [@]] -o
AFPASSWD [-c [@]] -a
AFPASSWD [-c [@]] -s

-c [@]
Specify the connection string to be use, parameters

Application-manager user and/or TWO_TASK value,
this option can be use in combination with the others.
(If not provided, AFPASSWD will try to default the values
from the environment)
is the APPS schema owner.

Change the password for an Application user.

Change the password for an Oracle Applications Database user.

-a Modify ALLORACLE users.

Lock|Unlock account for a single Oracle Applications database user.

Lock|Unlock accounts for non-essential Oracle Applications database users

Modify APPLSYS user. This requires the execution
of autoconfig (in ALL-TIERS) to distribute the
changes on your instance ie DB-TIER and ADMIN-TIER.

Display this help.

- AFPASSWD will prompt for the required passwords.
- AFPASSWD will prompt for new passwords twice for confirmation.
- Data entered for which contains spaces must be enclosed
in double quotes. For example, AFPASSWD -f "SCOTT TIGER"
- The only option permitted in combination with other options is the -c option.
Otherwise, there should only be one option per command (see usage above).
If additional options are provided on the command line, only the first valid
option after -c (if -c is present) will be executed.

Script to Check History of a concurrent Program

Sometimes, While troubleshooting Performance issues related to Concurrent Requests, we need to know the duration for request completion in the past. The script below gives the start time,end time and arguments for a given Concurrent Program


set pagesize 2000
set linesize 120
set wrap off
column user_concurrent_program_name format a45 noprint
column argument_text format a45 print
column user_name format a15
column start_time format a15
column end_time format a15
column comp_time format 9999.99

select request_id,
       to_char(actual_start_date,'DD/MON HH24:MI:SS') START_TIME,
       (actual_completion_date-actual_start_date)*24*60 comp_time, argument_text,user_name, status_code, phase_code
from apps.fnd_concurrent_requests, apps.fnd_concurrent_programs_tl,apps.fnd_user
where fnd_concurrent_requests.concurrent_program_id = fnd_concurrent_programs_tl.concurrent_program_id
and user_concurrent_program_name like '%&%'
and fnd_concurrent_programs_tl.language='US'
and requested_by=user_id
and actual_start_date >(sysdate-1)
order by actual_start_date desc,ACTUAL_COMPLETION_DATE desc;


Monday, 18 January 2016

R12.2 Filesystem Layout

  • File System 1 (FS1)--Stores a complete copy of all  Applications and Middle Tier code
  • File System 2 (FS2)--Stores a complete copy of all Applications and Middle Tier code 
  • File System Non-Editioned (FS_ NE)--Stores data that is written or read from the file system,Report Outputs,Log Files etc.
FS1 and FS2 Rotate Run and Patch Designation

How to Put Concurrent Requests in Hold Status?

During some scheduled maintenance activities, oracle apps database administrator would require to keep the Pending Jobs on Hold before bounce and release them after the scheduled activity.
This process help to bring down Concurrent Manager quickly and the pending jobs are preserved for running after the maintenance is complete.

1) Create table apps.conc_req_on_hold as select * from fnd_Concurrent_requests where PHASE_CODE='P' and hold_flag='N';
2) select count(*) from apps.conc_req_on_hold
3) update fnd_Concurrent_requests set hold_flag='Y' where PHASE_CODE='P' and hold_flag='N' and request_id in (select request_id from apps.conc_req_on_hold);

NOTE: You have to commit if select & update are same number of records. Otherwise rollback and try again till the numbers are same

4) Commit;

To Release hold on Concurrent Requests patching, run the below sql :

5) update fnd_Concurrent_requests set hold_flag='N' where request_id in (select request_id from apps.conc_req_on_hold);

6)Commit the changes