Concurrent Managers

Concurrent processing is at the core of every oracle applications instance. Over the years Oracle Applications has come through a number of changes but concurrent processing has retained itself and in fact got new features added on to its self with very new version.

The request processing on Oracle Applications takes place through the implementation of concurrent Managers. These Managers allow for a concurrent processing of jobs and also scheduling and queuing of jobs.

The objective of the current post is to go through a overview of Concurrent Managers and concurrent processing in Oracle Applications.

The default installation of Oracle Applications comes with a number of pre defined concurrent managers however you can create your custom concurrent managers to spread out the load of your job processing.

Apart from taking care of the load of your jobs the concurrent managers can also be made to schedule periodic jobs and you could also have the concurrent managers run in specific workshifts thus allowing specific programs to be run with specific priority and specific times.

Concurrent managers also allows you to tweak the number of concurrent process that it can handle concurrent if the request exceed this prescribed limt they are automatically put on pending state. The processing of a request takes place based on the time of request submission and priority of the request submitted.

As mentioned there are different types of concurrent mangers in Oracle Applications among them the three important manager which are required by any oracle applications installation are stated below

• Internal Concurrent Manager (ICM) - The Internal concurrent manager or the ICM is the 'master' concurrent manager. Its primary responsibility is to take care of the starting and stopping of all other concurrent managers that have been defined in the system and activated. However once the other managers are up and running the ICM does not play much of a role. It is for the same reason that despite your ICM being down oracle applications continues to perform as expected most of the times. That is you would be able to continue submitting requests even with the ICM down. However there are cases where you can evolve your ICM to do larger roles like acting as a conflict resolution manager or in case you have generic service management enabled your ICM can take care of starting and stopping other application services also.

• Standard Concurrent Manager - This the core manger and the most hard working of the three. It takes care of managing all the concurrent requests in the system. If however specific programs have been defined to use specific concurrent manager they would be taken care by that manager in all other cases the standard manager will be the default concurrent manager and will process the request. That is by default all the concurrent programs are defined to be run by the standard manager and they should not be excluded unless you have included them to run by an other manager. Though we can change a few setting of the standard concurrent manager like the number of process it can handle, most of the other definition should remain unchanged.

• Conflict Resolution Manager (CRM) - The conflict resolution manager of the CRM is responsible of handling any conflicts that might occur within the concurrent programmes. This conflict could be as a result of various reasons for example there might be a business requirement that two instances of a particular report should not be executed at the same time or during a particular period. In case such a scenario occurs the CRM is responsible for taking care of such request. As in the case of the standard concurrent manager the definition for the CRM should be rarely changed.

Apart from these three concurrent manages there is another type of concurrent manager known as the Transaction Manager also exists. The transaction manager is responsible for taking the load off the concurrent request table for pooling the request submitted by the user.The transaction manager takes care of these requests and sends it to standard manager directly.In a RAC environment the Transaction manager is required to be activated on each node of the RAC environment.

From the front end you could view the status of your concurrent manager by logging with the System Administration responsibility and going to the Concurrent Manager administer screen.








The concurrent managers are like other process which run on the oracle applications executable FNDLIBR. The FNDLIBR executable is located at $FND_TOP/bin.

You could also grep the FNDLIBR executable to check if any concurrent manager process are running

$ ps -ef|grep FNDLIBR

The $FND_TOP/sql/afcmstat.sql script gives you a list of concurrent managers and their respective status.

The status of concurrent managers and the nodes on which they are configured can also be known from the Oracle Applications manager.

Check Versions of Oracle Applications Components

Help-> About Oracle Applications from any of the forms sessions.

Or

Connect as apps user
select release_name from apps.fnd_product_Groups;

Version of Applications Forms (fmb,fmx) or reports (rdf)

To find the version of any oracle applications files
strings -a ICQTYED.fmx | grep Header

Alternatively you can also use the adident command
adident Header ICQTYED.fmx

Version of a Java class File
To find the version of a java class file
$ strings | grep '$Header'

Version of JDBC

In your middle tier, edit the jserv.properties file located in the iAS_ ORACLE_HOME/Apache/Jserv/etc directory
Locate the wrapper.classpath that is pointing to the jdbc zip file
/d01/oracle/viscomn/java/jdbc14.zip

Or
http://.:port/OA_HTML/jsp/fnd/aoljtest.jsp
Look for String ” JDBC driver version” under Connection String

Version of Apache
Go to the $iAS/Apache/Apache/bin directory and enter the following command:
$ httpd -version

Version Of The OA Framework
To find out the version of your Oracle appplication Framework
Option 1
http://.:port/OA_HTML/OAInfo.jsp

Option 2
adident Header %FND_TOP%/html/OA.jsp
adident Header %OA_HTML%/OA.jsp

Note: OA.jsp should be of the same version in both the places

Version of Application Product or Patch Set Level.

One of the most common things you will asked by your support engineer is the version or commonly known as the patch set level of your Oracle Applications product, while or after raising your service request. You can query this by logging on to your application database as the apps user.

select patch_level from fnd_product_installations where patch_level like '%AD%';

Version of Discoverer

cd $APPL_TOP/admin
grep -I s_disco_ver_comma **xml

Version of OJSP

Log in to the application server as the applmgr user
cd $OA_HTML
edit the jtflogin.jsp file to add the following line
OJSP Version: <%= application.getAttribute("oracle.jsp.versionNumber") %>
clear your cache and bounce your apache server
soruce the jtflogin.jsp from your browser

http://[your web server]:[your port]/OA_HTML/jtflogin.jsp
OJSP Version: 1.1.3.5.2

Version of JSP
Log on to your HTTP Server node, and change to the OA_HTML directory.
Using a text editor, create a file called test.jsp with only the following line:
<%= application.getAttribute("oracle.jsp.versionNumber") %>

Access this JSP from a web browser, using the URL:
http://[your web server]:[your port]/OA_HTML/test.jsp

Version of Portal
select fnd_oracle_schema.getouvalue(’PORTAL’) from dual;

FND_ORACLE_SCHEMA.GETOUVALUE(’PORTAL’)
——————————————————————————–
PORTAL30 <= to retrieve the portal user

select version from PORTAL30.wwc_version$;

VERSION
——————————————————————————–
3.0.9.8.1

or

begin
execute immediate 'select fnd_oracle_schema.getouvalue(''PORTAL'') from
dual' into portal_user;
begin
execute immediate 'select user_name from fnd_user where user_name like
upper('''||portal_user||''')'
into portal_user_name;
if portal_user is not null then
execute immediate 'select version from '||portal_user||'.wwc_version$'
into portal_ver;
check_message := ' [PASS] Your Applications database contains
Portal version: '||portal_ver;
dbms_output.put_line(check_message);
end if;
exception
when no_data_found then
null;
end;
exception
when others then
null ;
end;

Version of XML Parser

You can find out the version of your XML Parser using the following query
SQL> select WF_EVENT_XML.XMLVersion() XML_VERSION
2 from sys.dual;
XML_VERSION
--------------------------------------------------------------------------------
Oracle XDK Java 9.0.4.0.0 Production

Version of XML Publisher

To check weather XML publisher is installed or not you can query the FND_PRODUCT_INSTALLATIONS table or you can lookup the
reports in Oracle Applications Manager. You can find out the version for your XML publisher from the output of your report or from MetaInfo.class file.

$OA_JAVA/oracle/apps/xdo/common/MetaInfo.class.

Version of WorkFlow

You can find out the version of your workflow using the following query
SQL> select TEXT Version from WF_RESOURCES
2 where TYPE = 'WFTKN' and NAME = 'WF_VERSION';
VERSION
--------------------------------------------------------------------------------
2.6.0

Version of Oracle Login Server

begin
execute immediate 'select fnd_oracle_schema.getouvalue(''LOGINSERVER'') from
dual' into sso_user;
begin
execute immediate 'select user_name from fnd_user where user_name like
upper('''||sso_user||''')' into
sso_user_name;
if sso_user is not null then
execute immediate 'select version from '||sso_user||'.wwc_version$' into
sso_ver;
check_message := ' [PASS] Your Applications database contains Login
Server version: '||sso_ver;
dbms_output.put_line(check_message);
end if;
exception
when no_data_found then
null;
end;
exception
when others then
null ;
end;

Check Developer Forms Patch Set Level

1.Login though applmgr account

2.Create a file fpslevel.sh

cat > fpslevel.sh
copy the following contents in fpslevel.sh file.

#!/bin/sh
########################################
#fpslevel.sh - Used to find out the forms patchset level
########################################
clear
PatchLevel=0
f60gen > /dev/null 2>&1
if [ $? -eq 127 ]
then
echo "Environment is not Set"
else
PatchLevel=`f60gen | grep '(Form Compiler)' | grep -v Release | awk -F. '{print $5}' `
echo 'Forms Patchset Level :' ` expr $PatchLevel - 9 `
fi
echo 'For More Information '
echo 'Refer to Metalink Note:232313.1 for More Information'

3.Grant the execute permission to the script
chmod 777 fpslevel.sh

4.Execute the script.
./fpslevel.sh

Check Database Performance by these queries

SELECT * FROM v$log;

SELECT COUNT(*) FROM v$process;

SELECT COUNT(*) FROM v$session WHERE status='ACTIVE'

SELECT COUNT(*) FROM dba_locks WHERE blocking_others='Blocking';

SELECT COUNT(*) FROM dba_objects WHERE status='INVALID' AND owner IN ('ABC','DEF') GROUP BY owner;

SELECT A.Tablespace_Name,TRUNC((SUM(A.Tots)/1024/1024),3) Tot_Size,
TRUNC(((SUM(A.Tots)/1024/1024)-(SUM(A.Sumb)/1024/1024)),3) Tot_Used
FROM (
SELECT Tablespace_Name,0 Tots,SUM(Bytes) Sumb,
MAX(Bytes) Largest,COUNT(*) Chunks
FROM Sys.Dba_Free_Space A
GROUP BY Tablespace_Name
UNION
SELECT Tablespace_Name,SUM(Bytes) Tots,0,0,0
FROM Sys.Dba_Data_Files
GROUP BY Tablespace_Name) A, V$instance B
GROUP BY A.Tablespace_Name
ORDER BY A.Tablespace_Name

SELECT (1-(SUM(DECODE(name,'physical reads', value, 0))/
(SUM(DECODE(name,'db block gets', value, 0)) +
SUM(DECODE(name,'consistent gets', value, 0))))) * 100 "Read Hit Ratio"
FROM v$sysstat

SELECT d.status "Status",
d.tablespace_name "Name",
d.CONTENTS "Type",
d.extent_management "Extent Management",
TO_CHAR(NVL(a.bytes / 1024 / 1024, 0),'99G999G990D900') "Size (M)",
TO_CHAR(NVL(NVL(f.bytes, 0), 0)/1024/1024 ,'99G999G990D900') "Free (MB)",
TO_CHAR(NVL((NVL(f.bytes, 0)) / a.bytes * 100, 0), '990D00') "Free %"
FROM sys.dba_tablespaces d, (SELECT tablespace_name, SUM(bytes) bytes
FROM dba_data_files GROUP BY tablespace_name) a,
(SELECT tablespace_name, SUM(bytes) bytes
FROM dba_free_space GROUP BY tablespace_name) f
WHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = f.tablespace_name(+)
AND NOT (d.extent_management LIKE 'LOCAL' AND d.CONTENTS LIKE 'TEMPORARY')
UNION ALL
SELECT d.status "Status", d.tablespace_name "Name", d.CONTENTS "Type", d.extent_management "Extent Management",
TO_CHAR(NVL(a.bytes / 1024 / 1024, 0),'99G999G990D900') "Size (M)",
TO_CHAR(NVL((a.bytes-t.bytes), a.bytes)/1024/1024,'99G999G990D900') "Free (MB)",
TO_CHAR(NVL((a.bytes-t.bytes) / a.bytes * 100, 100), '990D00') "Free %"
FROM sys.dba_tablespaces d, (SELECT tablespace_name, SUM(bytes) bytes
FROM dba_temp_files GROUP BY tablespace_name) a,
(SELECT tablespace_name, SUM(bytes_cached) bytes
FROM v$temp_extent_pool GROUP BY tablespace_name) t
WHERE d.tablespace_name = a.tablespace_name(+) AND d.tablespace_name = t.tablespace_name(+)
AND d.extent_management LIKE 'LOCAL' AND d.CONTENTS LIKE 'TEMPORARY'
ORDER BY 7

AutoConfig

What is Autoconfig?
Autoconfig is a tool for configuring application instance.

What are the programs and program name involved in Auto Config?
You can see perl,shell,cmd and java programs.

1.adconfig.pl- Its a main program which inturn call Java APIs for configuring appl instance.
args-appl context file location

2.adautocfg.sh/adautocfg.cmd-This program inturn calls adconfig.pl
args-apps password

3.adconfig.sh-This program again calls adconfig.pl

These three programs used for running Auto config.

4. adchgatname.pl - This program will validating the APPL_TOP name in context file .If the APPL_Top name is changed, then this utility will take care of storing the old APPL_TOP name in APPL_TOP/admin/ATName.txt.Adconfig.pl calls this program .

Archiving Oracle Applications

Why Archive?
After an implementation of Oracle Application which has been around from some years, you would see a substantial growth in the database size.
As your Oracle Application continues to grow and upgrade the database also grows with it. A lot of data which resides in this database would no longer be needed to be updated and a significat amount of this data would rarely be used for any kind of Reporting. Nevertheless we cannot simply go ahead and purge or trash this data for obvious compliance and regulatory reasons. Another added advantage of archiving is that you can implement data masking in your non production environment while in the process of archiving, this reduces the risks from exposing your production data after subsequent clones.

There are many challenges associated with a large growing database like

• Increase in storage costs.
• Decrease in system responsiveness.
• Increase in times taken to complete cloning cycles.
• Increase in recovery times in cases of system failures.

What to archive ?
This is the most difficult when it came to implement an archive policy. Fortunately most of the archive solutions available in the market came with an out of box solution for Oracle Applications which made sure to preserve the referential integrity of the data. since data in an application is in its normalized form its important to ensure that the archived data is valid enough to be reported from when required. To ensure this a meta data repository is bundled along with the solution which defines the rules for archiving and the associated constraints.

Archiving Options
when it came to archiving options available with the ebusiness suite. these were quite a few of them available. Most of these solutions adopted a similar approach to archiving.
After going through the popular ones solutions available i can categorize them in the following groups.

• Proprietary File Type Based Solutions.
• Archive Database Based Solutions.

Proprietary File Type Based Solutions
Under these kinds of archiving solution the data is archived from Oracle Applications and stored in a flat file system which is generally in a proprietary format. The main and the biggest advantage of adopting such kind of the solution is that the need to maintain a large database is reduced. Also the archived data in the file system can be further compressed further to shrink the size. The major disadvantage of this approach is that you loose the capacity to do a seemless reporting from within your application. That is in order to be able to report from your archived data you would need to be depended on the proprietary reporting tool, rather than being able to do so from with oracle applications.

Archive Database Solutions
In the archive database based solutions, the archived data is stored in a separate database as opposed to a file system. This archive database could reside on a low cost second tire storage system. The main advantage in this structure is that you have the ability to a get to your archive data from within the application itself, in other words you do not need any third party tools to access your data.
One of the disadvantages of this approach is that, this would result in atleast one more database to maintain apart from the production system despite of the fact that this database would be on a lost cost second tier storage.

Limitations.
One of the main limitations that most of these archiving solutions had that, although most of them were able to archive the data from your application they failed to do a database reorg.
After the archiving cycle the database would need to be reorged manually to reclaim the space and see an increase in the system performance.
Also in the even of applications upgrade when the structure of your database tables changed the process of propagating the changes in the archives, though available was a complex process.

AD Utilities

AD Utilities (Applications DBA Utilities) are set of Oracle supplied utilities that are used to administer Oracle Applications.

Some AD utilities are given below...

adadmin - Performs maintenance tasks for Oracle Applications.

adchkdig - Checks the integrity of Oracle Applications patches downloaded from OracleMetaLink.

adutconf.sql - Reports standard information about the installed configuration of Oracle Applications.

adctrl - Manages parallel workers in AD Administration and AutoPatch.

adident - Reports the version and translation level of an Oracle Applications file.

adncnv - Converts a file from one character set to another.

admrgpch - Merges multiple patches into a single merged patch.

adrelink.sh - Relinks Oracle Applications executable programs with the Oracle server product libraries.

adsplice - Adds off-cycle products.

adtimrpt.sql - Reports a summary of the timing for jobs run by parallel workers.

adpatch - Applies patches and other system updates.

admsi.pl - Generates customized installation instructions for a patch.

rapidwiz - Provides a wizard for entering parameters that are specific to a new installation or an upgrade of an Oracle Applications system.

Change DOMAIN NAME on Oracle Apps (11.5.10.2)

I have changed the domain name ies.apps.com to ies.oracle.com as follows

Step 1

Enter in to “vi /etc/hosts” then change the host name as u want

e.g.: (ies.apps.com) to (ies.oracle.com)

Enter to “vi /etc/sysconfig/network” then change to the new host name

e.g.: (ies.apps.com) to (ies.oracle.com)

Then run $ service network restart

Then reboot the computer

NOTE: Ensure that backup must be taken of .xml file of both DB Tier and Apps Tier…

Step 2

Go to DB Tier…..

“$ vi /v01/oracle/visdb/appsutil/VIS_ies.xml”

Values of following parameters you have to change:

Change the new values to “ies.oracle.com” or as u want

1. global_database_name oa_var="s_global_database_name"
2. domain oa_var="s_domainname"

Step 3

Go to Apps Tier….

“$ vi /v01/oracle/visappl/admin/VIS_ies.xml”

Values of following parameters you have to change:

1. domain oa_var="s_dbdomain"
2. domain oa_var="s_admdomain"
3. domain oa_var="s_cpdomain"
4. domain oa_var="s_wfdomain"
5. domain oa_var="s_smtpdomainname"
6. domain oa_var="s_formsdomain"
7. chronosURL oa_var="s_chronosURL"
8. domain oa_var="s_metdomain"
9. domain oa_var="s_mwadomain"
10. discoinstancename oa_var="s_discoinstance"
11. disco_machine oa_var="s_disco_machine"
12. webentrydomain oa_var="s_webentrydomain"
13. proxybypassdomain oa_var="s_proxybypassdomain"
14. apps_portal_url oa_var="s_apps_portal_url"
15. sysadminmail oa_var="s_sysadmin_mail" osd="unix"
16. cookiedomain oa_var="s_cookie_domain"
17. login_page oa_var="s_login_page"
18. jdbc_url oa_var="s_apps_jdbc_connect_descriptor"
19. ohs_serveradmin oa_var="s_ohs_serveradmin"
20. domain oa_var="s_webcache_domain"
21. domain oa_var="s_domainname"
22. FORMS60_MAPPING oa_var="s_f60map"

Step 4

Then manually login to apps/apps@vis

Then manually you have to update the following table in database:

1. HOME_URL in ICX_PARAMETERS

Then login to /sys as sysdba

Then manually you have to update the following table in database:

2. GLOBAL_NAME in GLOBAL_NAME

Then exit from sqlplus….

Step 5

Then go to “/v01/oracle/visdb/9.2.0/network/admin”

Then change the all old host name (apps) to new host name (oracle) of the following scripts:

$ vi listner.ora

$ vi tnsname.ora

$ vi sqlnet.ora

Step 6

Run Auto Config on DB Tier…

“/v01/oracle/visdb/9.2.0/appsutil/scripts/VIS_ies/”

Run ./adautocfg.sh app/apps

Run Auto Config on Apps Tier…

“$ /v01/oracle/viscomm/admin/scripts/VIS_ies/”

Run $ ./adautocfg.sh app/apps

OPatch in Apps

In Apps we need to use Opatch and adpatch for patching oracle apps. Why we need to use two utility to patch oracle apps.opatch is used to patch all oracle homes (for R12..10.1.2,10.1.3 and 10.2.0.2 oracle homes). Apps patches we need to use to adpatch.

How to use Opatch?

Opatch is one of the easiest and safest for patching oracle apps because you can rollback opatch if you find any issues applying the patches

1. From the opatch read me make sure which oracle home you want to patch
2. Shutdown the instance related to particular oracle home.
3. Set the oracle home in the env .Set the opatch in the path.
4. Follow the readme whether opatch needs up gradation.
5. cd to the patch area and opatch apply
6. Proceed the post install steps
7. Run cpu_root.sh to give some permissions to the executables.
8. For rollback use opath rollback –id
9. “opatch lsinventory “ is used to list all the patches
10. “opatch lsinventory –details” is used to find the version belongs to particular oracle home.

$ ORACLE_HOME/OPatch/ (Unzip Patch number)

$ cd ..

$ ./opatch apply (Patch number)/

Then system will ask for respond……. Y | N….

Give Y

Autoconfig in Oracle Apps 11i / R12 / 12i

In Oracle Applications 11i & R12 (12i) all the configuration parameters are captured in two context files:

Application context file called the .xml contains the configuration information for the application tier & is located in $APPl_TOP/admin for each node of application tier.

Database context file called the .xml contains the configuration information for the database tier & is located in $ORACLE_HOME/appsutil/.

Details stored in the context file contains host names,domain name , directory structure, port numbers used ……

The AutoConfig feature of Oracle application manager(OAM) is used to update & manage context files.

Updating Context file

Suppose we want to update the active port from to 80 , for this we will edit the application context file as follows:

Step 1 :Start all services
$ $COMMON_TOP/admin/scripts//adstrtal.sh APPS/
Step 2 :log on to OAM & click site map.
Step 3:Click AutoConfig from the list of System Configuration features in the Administration tab.
Step 4 : Click the Edit Parameter button for the application tier context file to access the Context File Parameters page & then click the system tab.
Step 5 : Click the Focus icon (blue triangle) for oa_web_server. This expands oa_web_server and shows the web server related parameters.
Step 6:Update the Web Port (s_active_webport) parameter from <> to 80.
Step 7 : Save it & answer the tab.Then logout of OAM

AutoConfig Script

The autoconfig script uses information from the context file to generate all applications configuration files & updates database profiles. It is located in

Application tier: $COMMON_TOP/admin/scripts/CONTEXT_NAME/adautoconfig.sh

Database tier: $ORACLE_HOME/appsutil/scripts/CONTEXT_NAME/adautoconfig.sh

Now we run the autoconfig script to reconfigure the oracle application system with the updated Applications context.

Step 1 : Stop all services
$ $COMMON_TOP/admin/scripts//adstpall.sh APPS/
Step 2:Run the autoconfig script, $adautocfg.sh & respond to the prompts.
Step 3:Check log files for any errors.log file for autoconfig is adconfig.log & is located in
/admin//log/MMDDhhmm/
Step 4: Restart all services :
$ $COMMON_TOP/admin/scripts//adstrtal.sh APPS/

Rolling back an autoconfig session

Each execution of AutoConfig creates a roll back script in case you want to revert back to the previous configuration settings. For this we perform the following steps:

Step 1 :Shut down all services:
$ cd $COMMON_TOP/admin/scripts/
$ adstpall.sh APPS/
Step 2:Restore AutoConfig session.
$ cd $APPL_TOP>/admin//out/MMDDhhmm
$ restore.sh
Step 3 : Restart all services:
$ $COMMON_TOP/admin/scripts//adstrtal.sh APPS/

Restoring the AutoConfig updated files and restarting the services allows you to log on to OAM.

Restoring the previous configuration

Now we run OAM AutoConfig to restore the Applications Context.

Step 1 :Log on to the Oracle Application Manager (OAM) & click site map.You will be able to log on but some services will be down.
Step 2: Click AutoConfig from the list of System Configuration features in the Administration tab.
Step 3 : Click the Show History button for the application tier context file to access the Context File History page.
Step 4 :Click the Show Differences from Current Configuration button to see the recently updated parameters & Select Restore Previous Value for the Web Port and Discoverer Port parameters.
Step 5 :Save & respond the tabs. Log out of OAM.
Step 6 :Shut down all services:
$ cd $COMMON_TOP/admin/scripts/
$ adstpall.sh APPS/
Step 7 :Run the AutoConfig script, adautocfg.sh & Respond to the prompts.
Step 8 : View the log file and check for any errors.
Step 9 : Restart all services:
$ $COMMON_TOP/admin/scripts//adstrtal.sh APPS/
Step 10 :Log on to the Oracle Application Manager (OAM)

If the status of some services appears to be down, click the Refresh icon to update the
status.

Related : Metalink Notes
218089.1 Autoconfig FAQ
165195.1 Using AutoConfig to Manage System Configurations with Oracle Applications 11i
387859.1 Using AutoConfig to Manage System Configurations in Oracle Applications Release 12
270519.1 Customizing an AutoConfig Environment
364927.1 How To Run Autoconfig On Database Tier (DB-Tier)
341322.1 How to change the hostname of an Applications Tier using AutoConfig
338003.1 How to change the hostname and/or port of the Database Tier using AutoConfig
315674.1 How To Verify if Autoconfig is Enabled on 11.5.x
391406.1 How to get a clean Autoconfig Environment

Blocks , Extents, Segments in Oracle Database

I am going to cover basic concepts and Architecture of Oracle Database (9i, 10g, and 11g)

A. Data Blocks is smallest logical unit to store Oracle Data.
ii) One data block represent specific number o

f bytes on physical hard disk.
iii) Data Block in Oracle is also called as logical block
iv) Data Block size is usually multiple of operating system block size
v) You can have multiple block sizes with in single database (max. five)

vi) Block Size is specified by initialization parameter DB_BLOCK_SIZE
vii) Format of Data Block is

a) Header : contains generic information like block address and type of segment (index, data..)
b) Table Directory : contains information about table having rows in that block
c) Row Directory : contains information about actual row contained in that block
d) Free Space : available space in data block for additional row or update of row which require more space.
e) Row Data : contains table or index data.First three component of data block (Header, Table & Row directory) collectively known as Overhead

B. Extent is collection of contiguous data blocks.
ii) One or more extents make up a segment.

C. Segment is set of extents allocated for specific data structure (like table or index).
ii) Various kind of segments are table, index, cluster, rollback, temporary …
iii) Important views for segments are dba_segments, user_segments, all_segments
iv) In a Segment, first block of first extent contains segment header information

Things to note w.r.t. Segment, Extent & Datablocks
i) Segment and its associated extents are stored in one table space.
ii) Extents of a segment may not be contiguous on disk
iii) Segment can span multiple datafiles of a particular tablespace (Information on tablespace & datafiles coming soon) but extent can contain data from only one datafile.

ADPATCH Options

You can execute adpatch by logging in as the applications OS user and sourcing the appropriate environment file.

# su - applmgr
$cd SAMAPPL
$. ./APPSORA.env
$adpatch

By default adpatch does not take any clause, but there are some clauses that you could use with adpatch

Running a patch in test mode
You can use the apply clause with adpatch to specify weather to run the patch in TEST mode or not, when you run the patch in test mode it does not do any changes but runs generates a log fiule with all the actions it would have performed.

$ adpatch apply=n|y
The default is apply=y

Pre-install Mode
You can also run a patch in pre install mode, this would be done normally during an upgrade or consolidated update. When a patch is applied in a preinstall mode the all the AD utilities are updated before the upgrade or update.

$ adpatch preinstall=y
The default is preinstall=n

Other Options with adpatch
You can use the options clause to specify some of the other options available with adpatch.

Autoconfig
You can use the options=noautoconfig top specify autopatch that you do not wish to run autoconfig as a part of the patch application. This can be useful when applying a large number of patches when they are not merged. By default autoconfig is run as a part of adpatch.

$ adpatch options=noautoconfig

Checkfile
The chekfile option of adpatch tells adpathc to check for already executed exec, SQL, and exectier commands.You can use options=nocheckfile skips this check, however this can cause performance overheds so should be used only when specified.

$ adpatch options=nocheckfile

Compile Database
By defaulty autopatch compiles the invalid objects after the patch application, in case you wish not to do so you can specify options=nocompiledb along with autopatch.

$ adpatch options=nocompiledb

Compile JSP
By defaulty autopatch compiles the java server pages (jsp) after the patch application, in case you wish not to do so you can specify options=nocompilejsp along with autopatch.

$ adpatch options=nocompilejsp

Copy Portion
If you wish adpatch not to execute the commands present in the copy driver portion of the patch you can use the options=nocopyportion.

$ adpatch options=nocopyportion

Database Portion
If you wish adpatch not to execute the commands present in the database driver portion of the patch you can use the options=nodatabaseportion.

$ adpatch options=nodatabaseportion

Generate Portion
If you wish adpatch not to execute the commands present in the generate driver portion of the patch you can use the options=nogenerateportion

$ adpatch options=nogenerateportion

Maintenance Mode
If you wish to apply a patch regardless of the system being in maintenance mode you can use options=hotpatch.

$adpatch options=hotpatch

Integrity Check
If you wish to check the integrity of the patch you can use the options=integrity. Since metalink patches are pre checked for their integrity it is generally not required to do an explicit check and the default value is nointegrity.

$ adpatch options=integrity

Maintain MRC
You can use the maintainmrc option to specify weather you wish adpatch to execute the Maintain MRC schema as a part of the patch application or not. By default maintain MRC is done for standard patches and is disbaled for tarnslation and documentation patches.

$ adpatch options=nomaintainmrc

Pre requisite Patch Check
If you wish adpatch not to check for pre requisite patches before application of the main patch you can use options=noprereq.By default pre requsite checking is enabled.

$ adpatch options=noprereq

Validate Schemas
If you wish adpatch to explicitly validate all the registed schems by making a connection you can use options=validate. By default this validation is not performed.

$ adpatch options=validate

Java Classes
If you wish adpatch not to copy new java classes from the patch you can use options=nojcopy.By default java classes are copied.

$ adpatch options=nojcopy

Force Copy
By default adpatch copies the files without check the version of the existing files already present on the system.If you do not wish the newer version of the file to be replaced by the older version contained in the patch use options=noforcecopy.

$ adpatch options=noforcecopy

Relinking
If you wish adpatch not do perform relinking you can use options=nolink.

$adpatch options=nolink

Generate Forms
If you wish adpatch not to generate the forms files you can specify options=nogenform.

$ adpatch options=nogenform

Generate Reports
If you wish adpatch not to generate the report files you can specify options=nogenrep.

$ adpatch options=nogenrep

You could specify multiple options at the command line using the , delimiter.

$ adpatch options=hotpatch,nojcopy

10 ways to protect APPS Password

1. Stay current with our latest Security Best Practices

Regularly review the latest version of Best Practices for Securing Oracle E-Business Suite (Note 189367.1). This note is regularly updated and will give security advice covering many different aspects of Applications 11i. For Release 12, see Best Practices For Securing Oracle E-Business Suite Release 12 (Note 403537.1)


2. Regularly change your APPS password

This is an essential activity from a security perspective and needs to be part of your routine operating procedures. Same applies for other schema passwords and SYSADMIN user. As an aside, don't use predicable passwords, or have a system to create passwords, such as using "0ct0ber" for the password in October as this will make it easier to guess


3. Always change passwords as part of a clone process from PROD

It is recomended to change ALL schema passwords and ALL eBiz user passwords in a cloned instance. You can use Removing Credentials from a Cloned EBS Production Database (Note 419475.1) to achieve this. Similarly, you don't want to have any relation in the passwords used for PROD compared to any other instances. Data masking and obfuscation is a large topic in its own right, but is also something you may need to consider doing for the cloned instance to protect sensitive data generally. With Release 12, EM plugin provides some data scrambling facilities


4. Perform data masking on any files sent to outside parties from the PROD system

When you need to send any log files or configuration files, ensure that you scan for any sensitive data before packing the files to be sent. In this article we are concerned about the APPS password, but this applies equally well for other data as well. For example, a crude mechanism would be to use "ed" or "sed" on all files to globally change any occurrences of the APPS password before creating a tar archive to email or upload. You may be uploading files to Oracle Support, or just emailing them within your Organization. Whenever the files are going to someone who cannot access them directly you should always check the files before sending.

5. Create separate schemas with minimal access required for direct database access

If anyone requires direct access to the E-Business Suite database, ensure that you create a new unique schema with the specific permissions required for them to perform their job role. Except for a very few Apps DBAs, there should be no reason that anyone else needs the APPS user password. Sometimes pressures of work make it easier to just give someone APPS access, but this should be resisted and the time taken to provide only the minimum access absolutely required. Every person should also have their own unique login (but this is digressing into a separate area that I'll address in a later article). When considering permissions to allocate, don't be tempted to give read only access to everything, as being able to read sensitive information may be just as damaging as being able to change it.

6. Protect Apps 11i middle tier file system files

These days, there is little need to give anyone UNIX-level access to the servers, but it is still important to ensure the "applmgr" operating system user password is well protected. Also consider whether any of your own startup scripts or monitoring scripts have the APPS password hard coded in them, and protect these scripts with chmod 700 permissions, or remove them if no longer needed

7. Ensure no processes are running with APPS username/password in command line

Generally the APPS password is not listed in "ps" output, but there may be some manual scripts or other processes intermittently running with the APPS password in clear text or trivially encoded. Ensure these scripts are changed to hide the APPS password. In addition, ensure operating system access is restricted to only those who really need it

8. Protect OID access

If you have integrated the E-Business Suite with Oracle Application Server 10g, Single Sign-On, and Oracle Internet Directory, then the Apps user password is stored in the OID database, as it is required for Provisioning to function. The OID administrator and anyone with ldapsearch rights in the Provisioning Profiles will be able to extract the APPS password from OID. This in turn implies the "AppsDN" OID password should be protected in the same way as the APPS password itself. For assistance in security hardening OID, refer to the Oracle Internet Directory Administrator's Guide 10g (10.1.4.0.1) - Part III Directory Security

9. Encrypt SQLNET traffic from Middle Tier to RDBMS

In a previous article, Steven highlighted that ANO is certified with the E-Business Suite. Use encryption to protect the APPS password from network sniffers tracing SQLNET connection packets and deciphering the APPS password on the wire.

10. Allow only specific IP addresses to access RDBMS via SQLNET

Slightly off topic, but if someone has acquired the APPS password they still have to be able to gain access to a tool that can use it. Restricting the IP addresses that can access your Apps database will help minimise this risk. If you are still using "fat" clients (Discoverer or ADI for example) then you will have to weigh up the risks against the administrative overhead. Oracle recommends upgrading to server-based equivalent tools or shared desktop technologies such as Citrix so desktop clients no longer need direct access. This topic is discussed further in E-Business Suite Recommended Set Up for Client/Server Products (Note 277535.1)