Remote IT Support!! Please contact us

For Any Remote Support,Implementation/Upgrade Projects,Queries,Collaborations please mail us at

ASM disk and raw device mapping

No comments
If we need to know about the ASM disk and raw device mapping we can use the below script.


for asmlibdisk in `ls /dev/oracleasm/disks/*`
echo "ASMLIB disk name: $asmlibdisk"
asmdisk=`kfed read $asmlibdisk | grep dskname | tr -s ' '| cut -f2 -d' '`
echo "ASM disk name: $asmdisk"
majorminor=`ls -l $asmlibdisk | tr -s ' ' | cut -f5,6 -d' '`
device=`ls -l /dev | tr -s ' ' | grep -w "$majorminor" | cut -f10 -d' '`
echo "Device path: /dev/$device"

If an ASMLIB disk was already deleted, then we cannot find it in /dev/oracleasm/disks. We can use below script to check for devices that are (or were) associated with ASM.

for device in `ls /dev/sd*`
asmdisk=`kfed read $device | grep ORCL | tr -s ' ' | cut -f2 -d' ' | cut -c1-4`
if [ "$asmdisk" = "ORCL" ]
echo "Disk device $device may be an ASM disk"

Reference:How to map device name to ASMLIB disk (Doc ID 1098682.1)

No comments :

Post a Comment

Finding Patch related to a Product in Oracle Apps

No comments
If we need to find patches applied related to a product then we can use the below script to find them.

  FROM apps.ad_bugs
 WHERE trackable_entity_abbr = '&product_name'


  FROM apps.ad_bugs
 WHERE trackable_entity_abbr = 'fnd'


No comments :

Post a Comment

Skipping a worker in adctrl

No comments
If somtimes required to skip any worker via adctrl then we can use the below steps to do the same.

1. Run adctrl utility

2. We can only see option till 7 in the main menu. But there is an 8th option that is hidden.

3. Use option 8 to skip a failed worker. Enter 8 and the worker will be skipped.


No comments :

Post a Comment

Enabling About This Page Link in Oracle Apps R12

If we need to enable the "About This Page" link in Oracle Apps we have to set the below profile values.

Personalize Self-Service Defn = YES
FND: Personalization Region Link Enabled = YES
Disable Self-Service Personal = NO (Only at Site)
FND: Diagnostics = Yes

These values can be set at either site level or user level.

Please bounce Apache to make sure this take effect.



Post a Comment

Admrgpch Utility

No comments
Admrgpch utility is provided to merge mutliple application patches into single patch. This can help in saving time and effort for executing many patches again and again.
There are some restrictions with AD Merge, it can't be used to merge patches of different releases, platforms or parallel modes.
Syntax Walkthorugh
admrgpch  <source_directory> <destination_directory>

       admrgpch  <-s <source_directory>|-preinstall> -d <destination_directory>
                           [-master <master upgrade driver. Valid only
                                     with -preinstall or -driveronly options>]
                           [-verbose <level>] [-merge_name <pattern>]
                           [-manifest <filename>] [-logfile <filename>]
                           [-driveronly] [-admode]


 -help                                 Print help message.

 -verbose <level>              Can be one of: { 0(SILENT),
                                          1(QUIET), 2(VERBOSE) or 3(LOUD) }
                                          Default - 1(QUIET).

 -merge_name <pattern>  The name of the merged patch (up to 24 chars).
                                          Default - "merged".

 -s <source_directory>       Path of source directory where all patches to be
                                            merged have been unzipped.

 -d <destination_directory>  Path of destination directory where the merged
                                              patch will be created.

 -preinstall                        <APPL_TOP>/admin/<TWO_TASK>/preinstall is the
                                          source directory, like -s option

 -driveronly                         Merge only patch driver files. But files will not
                                            be copied.

 -master <upgrade driver>    Master upgrade driver to be merged with preinstall
                                              upgrade fix drivers

 -admode                              Only AD patches will be merged.
                                             By default non-AD mode

 -manifest <filename>        Full pathname of a file containing the list of
                                            patch zip files to be merged.
 -logfile <filename>           Admrgpch log file name.

Steps for patch merging.

1. Download all the patched which need to be merged.
2. Make a source directory .
    mkdir source_test
3. Unzip all the patches and copy them in source directory.
   -bash-3.2$ ls
    16759426  17385991

4. Make a target directory
    mkdir target_test

5. Now run the below command to merge the patches.

 admrgpch -s source_test -d target_test -merge_name test_patch

Executing the merge of the patch drivers
 -- Processing patch: source_test/16759426
 -- Processing file: source_test/16759426/u16759426.drv
 -- Done processing file: source_test/16759426/u16759426.drv
 -- Done processing patch: source_test/16759426

 -- Processing patch: source_test/17385991
 -- Processing file: source_test/17385991/u17385991.drv
 -- Done processing file: source_test/17385991/u17385991.drv
 -- Done processing patch: source_test/17385991

Copying files...

Character-set converting files...
  2 unified drivers merged.
Patch merge completed successfully
Please check the log file at ./admrgpch.log.
6. Now do to target directory
    cd target_test
    we can see that the merge patch is created with merged driver file.
$ cd target_test
$ ls
16759426_README.html  17385991_README.html  ad             b17385991.ldt  f17385991.ldt  metadata_files
16759426_README.txt   17385991_README.txt   b16759426.ldt  f16759426.ldt  fnd    u_test_patch.drv

Now use normal adpatch from target_test directory for  application of patches and pass u_test_patch.drv when prompted for driver file.

No comments :

Post a Comment

Adpatch Overview

Adpatch is a utility provide for applying patches in the Oracle Apps. Patching is perfomed for updating the files verison, bug fixing or while doing upgrades.

Patch can be applied 2 ways

1.Offline  (taking application services down) . We need to enable maintenance mode before applying patch in offline mode using adadmin utility.
2.Online  (with application services running). We need to use hotpatch option while applying patch in online mode

There are 3 modes in which adpatch runs.

Modes of ADPATCH

1) Pre-Install Mode
Pre-install mode is used to update AD utilities before an upgrade and to apply family consolidated upgrade packs.
AutoPatch Pre-AutoInstall mode allows you to apply patches when your installation is missing database information and/or filesystem information that AutoPatch requires to run in normal mode.
Examples of when you would run AutoPatch in Pre-AutoInstall mode (and cannot run it in normal mode) include:
    Prior to installing Oracle Applications for the first time
    Prior to upgrading Oracle Applications to the latest release.
    During an upgrade (to apply a bug fix that stopped your upgrade)
Applying patch in pre-install mode performs following tasks:
    Version checking
    File copy actions
    Relink FND and AD executables
    Save patch history information to file system
AutoPatch in pre-install mode will NOT:
    Run SQL of EXEC command
    Generate files
    Read product driver files
    Apply maintenance pack
To apply patch in pre-install mode, run  adpatch preinstall=y

2) Test Mode
AutoPatch provides a test mode in which it tells you everything it would have done in applying a patch, but doesn’t actually apply the patch.
To run AutoPatch in Test Mode, you must include ‘apply=no’ on the AutoPatch command line. For example:
$ adpatch apply=no
Instead of performing an action, AutoPatch indicates that it is not performing the action because “Apply=No”. In general, AutoPatch lists each file it would have copied, generated, relinked, or executed. This shows you exactly what actions it would have performed.
AutoPatch test mode works the same as normal mode, with the following exceptions:
    It does not copy any files from your patch directory into your installation area.
    It does not copy any files from your APPL_TOP to JAVA_TOP or OAH_TOP.
    It does not archive any object modules into your product libraries.
    It does not generate any forms or reports.
    It does not relink any executables.
    It does not run any ‘sql’ or ‘exec’ commands.
    It does not update the release version in the database.
    It does not update the patch history file.
AutoPatch asks you the same initial questions in test mode as in normal mode. It performs the following actions to determine what it would have done if run in normal mode:
    Reads and validates the patch driver file.
    Reads product file driver files.
    Extracts object modules from your product libraries (so it can perform version checking on the object modules it extracts).
    Performs version checking.
    Looks in the database to determine what ‘sql’ and ‘exec’ comands it would have run.
Its a good practice to run the patch in test mode and analyze the things before applying the patch in normal mode.

3) Non-Interactive Mode
Starting in Release 11.5, you can run AutoPatch non-interactively bycreating a defaults file

Before you can run AutoPatch non-interactively, you must first create an AutoPatch defaults file for your current environment.

Steps for creating AutoPatch defaults file for your current environment:
1. Specify defaultsfile=<New Defaults File Name> on the AutoPatch command line. The defaults file must be located under $APPL_TOP/admin/<SID>.
For example:
adpatch defaultsfile=$APPL_TOP/admin/testdb1/my_def.txt
2. Run AutoPatch up to the point where it asks you for the directory where your Oracle Applications patch has been unloaded. Then type ‘abort’ at this prompt.
3. Verify that your defaults file exists.
Once you have an AutoPatch defaults file for your current environment, you can run AutoPatch non-interactively.
Applying a single patch driver file non-interactively
Before applying any Oracle Applications patch, either interactively or non-interactively, you should read the README file (usually called readme.txt) supplied with the patch. You should also read the documentation supplied with the patch (if any).
It is possible to apply just a single patch driver file non-interactively using AutoPatch. Here is an example:
Assume the following:
    defaults file is $APPL_TOP/admin/testdb1/def.txt
    Applying copy driver for patch 987654, which is located in directory $APPL_TOP/patch/987654.
    Using three parallel workers
    AutoPatch log file name is cpy987654.log
The AutoPatch command line would be:
adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \
logfile=cpy987654.log \
patchtop=$APPL_TOP/patch/987654 \
driver=u987654.drv \
workers=3 \
If we dont give any of the mode as mentioned above and apply the patch simply using adpatch command then its a normal mode of patch application.

Various Options used during adpatch.

Either these can be passed like <option_name>=<value> or adpatch will ask these value once its start executing.

adpatch option_name= value
ex. adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt
adpatch workers=16

1) defaultsfile
Purpose: This option is used when we are running the patch in non interactive mode. In that case we create defaults file and provide that file as an option for running patch in non-interactive mode.
Default: none. No default file read or written.

2) logfile
Purpose: This is the name of adpatch log file which it will write during patch application.
Default: none. Adpatch prompts for this value.

3) workers
Purpose: Specifies the number of workers to run. This value depends on number of CPU and other factors.
Default: none. Adpatch prompts for this value.

4) patchtop
Purpose: Top-level directory for the current patch. This is the directory after unzipping the patch. This directory will a patch number.
Default: none. Adpatch prompts for this value.

5) driver
Purpose: Name of the patch driver file. This comes with the patch and is present in patch directory.
Default - none. Adpatch prompts for this value.

6) restart
Purpose: To restart an existing session. Only valid when interactive=no is also specified
Default: No

7) localworkers
Purpose: Used in Distributed AD to specify the number of workers to be run on the current machine. If you have multi node instance (example RAC and shared APPL_TOP), then you can utilize this paramter to run the patch parallely in multiple nodes. You can start few workers on node 1, few on node 2 and so on. The way this can be done is that, you can start adpatch on one node with localworker=<some value less then total workers>. Then run adctrl on other node in distributed mode and start some mode workers. This will speed up the process and utilized the resources effectively.
Default: Value specified for workers.

8) printdebug
Purpose: To display extra debugging information.
Default: No.

Some other parameters which can be helpful for application of speeding up the patch application.

adpatch options=<value>
1) checkfile
Purpose: To skip running exec, SQL, and exectier commands if they are recorded as already run. Indicates that Autopatch should run the command *only* if a certain file is newer than the version of it that was last run. The idea behind it is to reduce the duration of an Autopatch session by skipping actions that don’t really need to be performed. When used in the right manner, it can dramatically improve Autopatch performance, especially for big patches and/or long running actions.
Default: checkfile (use ‘nocheckfile’ to skip)

2) compiledb
Purpose: To compile invalid objects in the database after running actions in the database driver.
Default: compiledb (use ‘nocompiledb’ to skip)

3) compilejsp
Purpose: To compile out-of-date JSP files, if the patch has copy actions for at least one JSP file.
Default: compilejsp (use’nocompilejsp’ to skip)

4) copyportion
Purpose: To run commands found in a copy driver. This will copy the higher version files from patch to product top.
Default: copyportion (Use ‘nocopyportion’ to skip. Use it only when mentioned in readme of patch)

5) databaseportion
Purpose: To run commands found in a database driver. This portion includes applying the files (like sql, pls etc) to database.
Default: databaseportion (use ‘nodatabaseportion’ to skip. Use it only when mentioned in readme of patch)

6) generateportion
Purpose: To run commands found in a generate driver. This portion will generate new executable files from the copied code of patch. For example if will generate new forms files (fmx) from new .fmb files.
Default: generateportion (use ‘nogenerateporation’ to skip)

7) integrity
Purpose: To perform patch integrity checking. Tells adpatch whether to perform patch integrity checking, which verifies that the version of each file referenced in a copy action matches the version present in the patch.
Default: nointegrity (By default the integrity is not checked)

8) maintainmrc
Purpose: To maintain the MRC schema after running actions found in the database driver.
Default: maintainmrc (use ‘nomaintainmrc’ to skip)

9) autoconfig
Purpose: Tells adpatch to run Autoconfig after patch installation.
Default: autoconfig (use ‘noautoconfig’ to skip)

10) parallel
Purpose: To run actions that update the database or actions (like SQL) that generate files in parallel (like genform).
Default: parallel (use ‘noparallel’ to skip)

11) prereq
Purpose: Tells adpatch whether to perform prerequisite patch checking prior to running patch driver files that contain actions normally found in the copy driver.
Default: prereq (use ‘noprereq’ to skip)

12) validate
Purpose: To connect to all registered Oracle Applications schemas at the start of the patch. Adpatch validates the passwords for each schema.
Default: novalidate (use ‘validate’ to validate schema passwords)

Below Flags can be passed to adpatch

1) hidepw
Purpose: This argument is used to hide the passwords in log files
Default: nohidepw
adpatch flags=nohidepw
2) trace
Purpose: Tells the adpatch utility whether to log all database operations to a trace file
Default: notrace
adpatch flags=notrace
3) logging
Purpose: Tells the adpatch utility whether to create indexes using the logging or nologging mode.
Default: logging
adpatch flags=logging

Log File Location

Patch log file location:

Worker Log file location:



Post a Comment

Not able to view Responsibilities assigned to Users in Oracle Application

No comments
If the responsibilities assigned to user in Oracle Application is not appearing then we need new need to follow below steps.

1 .Login as System Administrator

2. Submit Concurrent Program ""Workflow Directory Services User/Role Validation'

Parameters to be passed
Batch Size - 10000(default value)
Username for the user having issue- HSINGH
Check_Dangling - Yes (Default value No)
Add missing user/role assignments - Yes (Default Value No)
Update WHO columns in WF tables - No (Default Value No)

This request would check all users and assigned responsibilities and will sync up users with attached responsibilities .
Users should be able to view assigned responsibilty once the program is completed succesfully.

No comments :

Post a Comment

Clearing Middle Tier cache in Oracle Apps R12

1 comment
For clearing cache in Apps R12 we can follow the below navigation steps.

  • Go to Functional Administrator Responsibility.
  • Click\Select Core Services Tab.
  • Click\Select Caching Framework Tab.
  • On Caching framework page click on Global configuration on left side pane.
  • In Cache policy click on "Clear ALL Cache" Button.
  • Click on Apply.

1 comment :

Post a Comment


No comments
AOLJ test can be executed when we need to determine the if the webserver is configure properly or not. It also verifies DBC file.

You need to pass few parameter as below to perform the test.
1.Apps Schema Name
2.Apps Schema Password
3.Oracle SID - Database Oracle SID
4.HostName - Database hostname
5.PortNo - Database Port No



If https is configured then you need to use https instead of http.



No comments :

Post a Comment

Enable Diagnostics in Oracle Apps

No comments
The below steps can be followed for enabling diagnostics at user level.

1. Navigate to System Administrator responsibility> Profile> System>

2. Enter profile name: Utilities:Diagnostics .
    Enter Application User for whom you want to enable Diagnostics.
Enter value Yes at User level and Save the Changes . You can set yes at site level for all application users.

3. Navigate to System Administrator responsibility> Profile> System>
Enter profile name: Hide Diagnostics menu entry.
Enter Application User for whom you do not want to hide Diagnostics menu entry .
Enter value No at User level and Save the Changes .

4. Logout from Oracle Application and login again.Diagnostic would be enabled.

No comments :

Post a Comment

Script for Changing Oracle Application Users Password

We can use the below API for changing the EBS(fnd_user) user password.
Sample Script:
   v_user_name      VARCHAR2 (100) := 'HSINGH';

   v_new_password   VARCHAR2 (100) := :NEWPASSWORD;
   v_status         BOOLEAN := NULL;
   v_status := fnd_user_pkg.changepassword (v_user_name, v_new_password);

   DBMS_OUTPUT.put_line (
      'Password is changed successfully for the user=> ' || v_user_name);
      DBMS_OUTPUT.put_line (
            'Error encountered while restting password for user and the Error Detail is '
         || SQLERRM);

The script can also be modified to reset bulk ebs user passworda. The below is a sample script, You need to modify as per you need.
Refer below syntax
   v_status   BOOLEAN;
   CURSOR c_user
      SELECT user_name
        FROM fnd_user
       WHERE     NVL (end_date, SYSDATE + 1) > SYSDATE
             AND user_name NOT IN ('SYSADMIN',
   FOR user_name_list IN c_user
         v_status :=
            fnd_user_pkg.ChangePassword (
               username      => user_name_list.user_name,
               newpassword   => 'welcome123');
      --  dbms_output.put_line('password sucessfully changed for' || user_name_list.user_name);

         WHEN OTHERS
            DBMS_OUTPUT.put_line (
                  'Error encountered while restting password for users and the Error Detail is '
               || SQLERRM);


Post a Comment

Change\Expire all application users password forcefully

We can forcefully expire password for all EBS user.This feature is available after RUP4.We need to apply  Patch 4676589 ATG RUP 4 enabling this feature.


The below script can be used to expire all passwords in the fnd_user table $FND_TOP/sql/AFCPEXPIRE.sql.

Execution Method

Connect to SQL*Plus


Submit Concurrent Program

 CP SQL*Plus Expire FND_USER Passwords

This script sets the fnd_user.password_date to null for all users which causes all user passwords to expire.The user will need to create a new password upon the next login.


Post a Comment

How to Enable\Disable large number of EBS users

No comments
To Disable/Enable bulk number of users in Oracle Applications, we can use the below API

apps.fnd_user_pkg.EnableUser =>To Enable Users
apps.fnd_user_pkg.DisableUser =>To Disable Users\End Date Users


The below synatx can be used for performing this activity.
We can modify the select statement in Cursor to customize according to need.

declare cursor cur1 is
select user_name from apps.fnd_user where LOWER(user_name) Not IN ('username','username', .......);
for all_user in cur1 loop
end loop;

   CURSOR cur1
      SELECT user_name
        FROM fnd_user
       WHERE person_party_id IS NOT NULL;
   FOR all_user IN cur1
      apps.fnd_user_pkg.DisableUser (all_user.user_name);

No comments :

Post a Comment

Not able to connect to Apps user in Database due to library cache locks

If there are many applications integrated with EBS then this issue arises, when we change apps password but the integrated applications keep trying to connect with old password causes library cache locks in the Database.
This prevent apps user from connecting to database.This scenario also arises when EBS instance is refreshed.
Numerous failed logins attempts can cause row cache lock waits and/or library cache lock waits.

We can observe  'Library cache lock' or 'row cache lock' when concurrent users login with wrong password to the database.
'row cache lock' is seen in 10.2 and 11.1
'library cache lock' is seen in 11.2.


1. Check for bad or incorrect password or login attack by running following sql:

select username,
count(*) failed_logins
from dba_audit_trail
where returncode=1017 and --1017 is invalid username/password
timestamp < sysdate -7
group by username,os_username,userhost, client_id,trunc(timestamp);

2. Set the below event in the spfile or init.ora file and restart the database:

alter system set event ="28401 TRACE NAME CONTEXT FOREVER, LEVEL 1" scope=spfile;



REF:Library Cache Locks Due to Invalid Login Attempts (Doc ID 1309738.1)


Post a Comment

TKPROF Overview

No comments
TKPROF is used for diagnosing performance issues.  It formats a trace file into readable format for performance analysis.

tkprof tracefile_name.trc  tracefileoutput.txt sys=no  sort='(prsela,exeela,fchela)'  explain=apps/apps
Options for tkprof
 print – Lists only the first n SQL statements in the output file.  If nothing is specified, all statements will be listed.  Use this option when the list needs to be limited to the 'Top n' statements.  This is useful when combined with a sorting option to enable the top n statements by CPU, or disk reads, or parses, etc.
aggregate – When 'Yes', tkprof will combine the statistics from multiple user executions of the same SQL statement.  When 'No', the statistics will be listed each time the statement is executed.
insert – Creates a file that will load the statistics into a table in the database for further processing.  Choose this option if you want to perform any advanced analysis of the tkprof output.
sys – Enables or disables the inclusion of SQL statements executed by the SYS user, including recursive SQL statements.  Default=enable. 
table – Used in the Explain Plan command (if specified) for Oracle to load data temporarily into an Oracle table.  The user must specify the schema and table name for the plan table.  If the table exists all rows will be deleted otherwise tkprof will create the table and use it.
record - creates a SQL script with the specified filename that contains all non-recursive SQL statements from the trace file.  Log the SQL statements in a separate *.sql file.
explain – Executes an Explain Plan for each statement in the trace file and displays the output. Explain Plan provides the predicted optimizer execution path without actually executing the statement.  tkprof shows you the actual execution path and statistics after the statement is executed.
sort – Sorts the SQL statements in the trace file by the criteria required.It provides SQL statements that consume the most resources at the top of the file, rather than searching the entire file contents for the poor performers.

Sort options are as below
  •  prscnt – The number of times the SQL was parsed.
  •  prscpu – The CPU time spent parsing.
  •  prsela – The elapsed time spent parsing the SQL.
  •  prsdsk – The number of physical reads required for the parse.
  •  prsmis – The number of consistent block reads required for the parse.
  •  prscu - The number of current block reads required for the parse.
  •  execnt – The number of times the SQL statement was executed. 
  •  execpu – The CPU time spent executing the SQL. 
  •  exeela – The elapsed time spent executing the SQL.
  •  exedsk – The number of physical reads during execution.
  •  exeqry – The number of consistent block reads during execution.
  •  execu – The number of current block reads during execution.
  •  exerow – The number of rows processed during execution.
  •  exemis – The number of library cache misses during execution.
  •  fchcnt – The number of fetches performed.
  •  fchcpu – The CPU time spent fetching rows.
  •  fchela – The elapsed time spent fetching rows.
  •  fchdsk – The number of physical disk reads during the fetch.
  •  fchqry – The number of consistent block reads during the fetch.
  •  fchcu – The number of current block reads during the fetch.
  •  fchrow – The number of rows fetched for the query.

No comments :

Post a Comment

Profiles used for setting up various URLs in an E-Business Suite

There are many profiles used in EBS. But below are the few profiles which are used to setting up the correct URL in EBS.
Mostly values for these profiles are populated from context files when we run autoconfig.
But in some cases when the EBS instance is cloned/refreshed or DMZ setup is performed then we need to make sure that these profiles are properly set at site level and server level(in case of DMZ setup).
The hostname and web port should be defined properly.

User Profile Name
Internal Name
 Applications Web Agent
 Applications Servlet Agent
 Applications JSP Agent
 Applications Framework Agent
 ICX:Forms Launcher
 ICX: Oracle Discoverer Launcher
 ICX: Oracle Discoverer Viewer Launcher
 Applications Help Web Agent
 Applications Portal
 BOM:Configurator URL of UI Manager
 QP: Pricing Engine URL
The default hierarchy type value for the above profile options is of Security .


Post a Comment