AD Utilities

What are AD Utilities?

AD Utilities are a group of tools designed to install, upgrade, maintain, and patch a specific set of products contained in a given release of Oracle Applications.

What is AutoPatch (or adpatch)?

AutoPatch (adpatch) is a utility that is used to apply individual patches, mini-packs, or maintenance packs to an existing Oracle Applications instance. For more information on the adpatch utility, see Note 109666.1

What is AD Administration (or adadmin)?

AD Administration (adadmin) performs maintenance tasks on an installed Oracle Applications system to ensure that it runs smoothly. The tasks performed with this utility fall into two categories: database and file system. For more information on the AD Administration utility, see Note 109667.1

What is AD Controller (or adctrl)?

AD Controller (or adctrl) is used in conjunction with other AD Utilities (such as AutoInstall/AutoUpgrade, adadmin or adpatch) to determine the status of workers and restart failed tasks.

What is AD Relink (or adrelink)?

AD Relink (or adrelink) allows you to relink Oracle Applications executable programs with the Oracle Server product libraries. You can run the adrelink utility manually to relink individual executable programs, or use the relink option in the AD Administration utility to relink all executable programs.

For additional AD Utility FAQs, check out the following articles:
Note 62418.1 Patching/Patchset FAQ
Note 60766.1 Patch Installation FAQ

Table ReOrg Analyzer

Table ReOrg Analyzer


Finding and repairing chained rows is an important part of Oracle administration. When an Oracle rows expands,
it sometimes chains onto multiple data blocks. Excessive row chaining can cause a dramatic increase in disk I/O
because several I/O’s are required to fetch the block instead of one single I/O.





Of course, row chaining can be prevented by setting the PCTFREE storage parameter high enough to keep space on each data block
for row expansion. In cases where the data columns contain RAW and LONG RAW columns, row chaining may be unavoidable because the average row
length may exceed the data block size. That is why the query below filters out tables with RAW data types.
Here is the code that we use to generate a report showing all tables with excessive chained rows. Note that the use of this script is
predicated on the use of Oracle’s ANALYZE command to populate the chain_cnt and num_rows columns of the DBA_TABLES data dictionary view.
Once identified, the tables should be reorganized using Create Table As Select (CTAS) or by using the Oracle export-import utilities.



spool chain.lst;
set pages 9999;
column c1 heading "Owner" format a9;
column c2 heading "Table" format a12;
column c3 heading "PCTFREE" format 99;
column c4 heading "PCTUSED" format 99;
column c5 heading "avg row" format 99,999;
column c6 heading "Rows" format 999,999,999;
column c7 heading "Chains" format 999,999,999;
column c8 heading "Pct" format .99;
set heading off;
select 'Tables with chained rows and no RAW columns.' from dual;
set heading on;
select
owner c1,
table_name c2,
pct_free c3,
pct_used c4,
avg_row_len c5,
num_rows c6,
chain_cnt c7,
chain_cnt/num_rows c8
from
dba_tables
where
owner not in ('SYS','SYSTEM')
and
table_name not in
(select table_name from dba_tab_columns
where
data_type in ('RAW','LONG RAW')
)
and
chain_cnt > 0
order by
chain_cnt desc ;
This will produce a nice report that shows tables that you will want to reorganize:
Owner Table PCTFREE PCTUSED avg row Rows Chains Pct
------ --------- ------- ------- ------- --------- --------- ----
SAPR3 ZG_TAB 10 40 80 5,003 1,487 .30
SAPR3 ZMM 10 40 422 18,309 509 .03
SAPR3 Z_Z_TBLS 10 40 43 458 53 .12
SAPR3 USR03 10 40 101 327 46 .14
SAPR3 Z_BURL 10 40 116 1,802 25 .01
SAPR3 ZGO_CITY 10 40 56 1,133 10 .01
6 rows selected.



Cheers,


SpicyOracle.

FRM Performance issue on R12

Issue :

Forms Process (FRMWEB) Consumes 100% of CPU in Oracle Applications R12

Issue Confirmation :

From " top " command output, FRMWEB shows 100% of CPU usages on all FE nodes.

Node 1

Tasks: 252 total, 4 running, 248 sleeping, 0 stopped, 0 zombie
Cpu(s): 39.1% us, 0.2% sy, 0.0% ni, 60.5% id, 0.2% wa, 0.0% hi, 0.0% si
Mem: 33277600k total, 7763548k used, 25514052k free, 120288k buffers
Swap: 6731224k total, 0k used, 6731224k free, 857572k cached

PID USER PR NI %CPU TIME+ %MEM VIRT RES SHR S COMMAND
7954 applmgr 25 0 100 7:38.16 0.3 130m 84m 20m R frmweb
23357 applmgr 25 0 100 254:40.80 0.2 121m 75m 19m R frmweb
29362 applmgr 25 0 100 241:52.23 0.2 109m 62m 18m R frmweb
19146 applmgr 15 0 5 0:08.18 0.2 99.8m 55m 16m S frmweb
10994 applmgr 16 0 3 8:26.54 3.8 1918m 1.2g 7036 S java
10224 applmgr 16 0 2 2:02.79 0.3 133m 86m 20m S frmweb
26093 applmgr 17 0 1 0:00.04 0.0 56472 9264 6068 S frmweb
26068 applmgr 16 0 1 0:00.07 0.0 2644 1108 760 R top
10993 applmgr 17 0 0 11:24.62 3.8 1901m 1.2g 10m S java
14619 applmgr 15 0 0 0:05.47 0.1 86212 41m 13m S frmweb


Node 2

Tasks: 242 total, 3 running, 238 sleeping, 0 stopped, 1 zombie
Cpu(s): 15.0% us, 0.2% sy, 0.0% ni, 84.8% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 33277600k total, 7983180k used, 25294420k free, 111600k buffers
Swap: 6731224k total, 0k used, 6731224k free, 878220k cached

PID USER PR NI %CPU TIME+ %MEM VIRT RES SHR S COMMAND
1677 applmgr 25 0 100 238:31.17 0.1 85976 38m 14m R frmweb
29169 applmgr 15 0 13 0:04.91 0.2 107m 62m 17m S frmweb
31279 applmgr 15 0 2 1:14.63 0.3 147m 98m 22m S frmweb
12726 applmgr 15 0 2 0:11.64 0.2 99.1m 54m 16m S frmweb
30388 applmgr 17 0 1 0:00.04 0.0 56472 9264 6068 S frmweb


Node 3

PID USER PR NI %CPU TIME+ %MEM VIRT RES SHR S COMMAND
16225 applmgr 25 0 101 250:24.90 0.2 120m 74m 19m R frmweb
24725 applmgr 25 0 101 141:44.18 0.2 100m 55m 17m R frmweb
8339 applmgr 25 0 99 375:46.78 0.2 114m 68m 19m R frmweb
26492 applmgr 25 0 99 167:46.88 0.2 119m 72m 19m R frmweb
32477 applmgr 25 0 99 151:14.55 0.2 120m 74m 19m R frmweb
1 root 16 0 0 0:02.42 0.0 2652 508 432 S init

Cause :

The root cause of the issue is that returning rows from LOVs in core forms causes the forms process to grow up into memory depending on the number of rows returned.

When an end user login to forms and start working with LOV within core forms sometimes and according to the search criteria that the user will provide to filter the results in LOV, it may fetch huge numbers of records in which causes the frmweb process to grow very large, and in extreme cases this can even lock up the current process or even the whole machine.

So when executing a LOV query, every row is fetched into memory on the middle tier, the frmweb process can get extremely large, and the larger it gets the more likely it is to start paging.
Eventually it starts consuming excessive CPU just paging the process in and out of memory, which is probably what you can see here in this case as the amount of memory consumed when the LOV records are fetched into memory obviously depends on the amount of data in each record.

Solution :

1. The cleaner and consistent way is to set "s_forms_catchterm"=0 in the CONTEXT FILE and run autoconfig.

2. If you can't afford autoconfig now, then we need to update the following files with FORMS_CATCHTERM=0

$APPL_TOP/$CONTEXT_NAME.env
$ORA_CONFIG_HOME/10.1.2forms/server/socket.env
$ORA_CONFIG_HOME/10.1.2forms/server/default.env

Reference :

Metalink Doc : 745711.1 - Forms Process (FRMWEB) Consumes 100% of CPU in Oracle Applications R12

Happy New Year 2010

Wish everybody a Happy New Year 2010

Best wishes from SpicyOracle Group Blogging Team.