Oracle Applications DBA Blog

Oracle Critical Patch Update October 2007 for 11i (11.5.10.2)

Oracle yesterday released the Critical Patch Update (CPU) for October 2007.

As with the case of CPUs, the Oracle Database and Oracle Application Server are cumulative whereas CPU for Oracle eBusiness Suite are not cumulative.

Oracle ebusiness suite CPU are broadly categorized into

• Oracle Database CPU.
• Oracle HTTP Server CPU.
• Oracle Developer CPU.
• JInitiator Patches

This write up focuses on for UNIX /Linux environments running Oracle Applications 11i

Applications Database
For Oracle Applications 11i instance you must have your database upgraded to at least 9.2.0.8 to be able to apply this CPU.
11i instances running on 9i database you need to apply patch  6395038 (UNIX).
For 10g Release 1 apply patch 6395024
For 10g Release 2 apply patch 6395024

Applications HTTP Server
The Oracle HTTP Server does not have any additional patches released in the CPU Oct 2007.

Applications Developer Suite
You must upgrade to patchset 18 as a part of this CPU release and also apply patch 5687261 to the 8.0.6 Oracle home. This is a shell script (.sh) patch.

Oracle JInitiator
For JInitiator Oracle recommends to be upgraded to 1.3.1.26 or higher the latest version available however is 1.3.1.28.You can do this update via patch 5882294.

Oracle Application patches
You need to apply the following applications patches
5485003
4897479
4514856

If you have already applied ATG Rollup 5 you can omit patch 5485003.

Posted by Sam at 10:23 PM | Permalink | Comments (1) | TrackBacks (0)

Behind the Oracle HTTP Server - OHS

The OHS is the abbreviation for the Oracle HTTP Server. This is the core component for the client facing interface of Oracle Applications. Much of how Oracle Applications behaves is controlled from the OHS.

The OHS is built upon the Apache Server project. The Oracle Application server in Oracle Applications 11i (11.5.10.2) is based on Apache 1.3.

Oracle Application Server 10g Release2 is based on Apache 2.Though we do not have 10g release 2 application server by default  in 11i, we can choose to implement the 10g applications server with 11i.

You can find out the current version of OHS by the command httpd -version
$ httpd -version
Server version: Oracle HTTP Server Powered by Apache/1.3.19 (Unix)
Server built:   Apr  5 2004 16:17:45 (iAS 1.0.2.2.2 rollup 4)

There are some core files which control the behavior of the Oracle HTTP Server. Again most of these files are autoconfig  managed , so changes to them should be via the Oracle Applications Manager and autoconfig must be run to propagate these changes to the respective config files.

httpd.conf
This is manin config file for the Apache based OHS. It contains all vital configuration information for the OHS like the port on which the server is running, the portocol used etc.A detailed list of derivates supported by the httpd.conf file can be found in the apache documentation. Again as mentioned before this file is also autoconfig managed.

httpds.conf
The httpds.conf file is similar to the httpd.conf. The httpds.conf filers comes into use when apache runs in the Secure Sockets Layer implementation(SSL).Another way make sure if httpds.conf is being used in your environment or not is to open up the apachectl file in the Apache/bin directory and check if the httpds executable is being used along with the httpd executale. something similar to below

HTTPD=/d01/sam/samsora/iAS/Apache/Apache/bin/httpds

access.conf
The access.conf file is natively used to specify the acess control files for the HTTP server. But in Oracle Implementation of  Apache server this file is essentially kept empty and instead the AccessConfig directive in httpd.conf is used.

url_fw.conf
The URL firewall or the url_fw.conf file implementation is used to provide an additional layer of security on the external  tier.This file comes into play once you define a node as external. After this is enabled only the urls specified in the  url_fw.conf files will be accessible through the external tier in a DMZ architecture.Once enabled the httpd.conf file will have a link to include this file.

security.conf
This file contains the security configuration for the OHS.It has information regarding security auditing and also location of the security audit log file location.

oracle-apache.conf
This a file that stores the configuration information for various supported modules in Oracle applications like imeeting , OEM etc.It will contain entries to include these configuration files. These module specific configuration file like the imeeting.conf will also reside in the Apache/conf directory on the application server.

Posted by Sam at 04:21 AM | Permalink | Comments (5) | TrackBacks (0)

Archiving Oracle Applications

In my current post i will be touching upon one of the least talked about but extremely vital topic of data archiving in Oracle Applications. This post will talk about the need to archive and the pit falls of not archiving a production environment.
We will also briefly touch upon the various methods available to implement a effective archival policy for 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.

Posted by Sam at 03:01 AM | Permalink | Comments (0) | TrackBacks (0)