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
From the opatch read me make sure which oracle home you want to patch
Shutdown the instance related to particular oracle home.
Set the oracle home in the env .Set the opatch in the path.
Follow the readme whether opatch needs up gradation.
cd to the patch area and opatch apply
Proceed the post install steps
Run cpu_root.sh to give some permissions to the executables.
For rollback use opath rollback –id
“opatch lsinventory “ is used to list all the patches
“opatch lsinventory –details” is used to find the version belongs to particular oracle home.
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 WebPort (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
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 WebPort and DiscovererPort 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
I am going to cover basic concepts and Architecture of Oracle Database (9i, 10g, and 11g)
A. Data Blocksis 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. Extentis 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.
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.
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)
