Oracle Applications DBA Blog

Oracle Applications 11i Certification

As most of you would have noticed Oracle has recently revived its e business suite certification program. The new program I  feel is more industry relevant and practical when compared to the previous Oracle Applications 11 certification.

The current Oracle E Business Suite 11i Certification comes in three tracks

• Oracle E-Business 11i Financials
• Oracle E-Business 11i Supply Chain
• Oracle E-Business 11i Advanced Technology

Successful completion of any of these tracks will earn you a Oracle Certified Professional (OCP) Certificate on the chosen track.

The first two tracks are aimed at the functional area within Oracle Applications. The third one Oracle 11i Applications Technology Certified Professional Administrator  is tailor made for the Oracle Applications DBA. This being an Oracle Applications DBA Blog I will limit my current post only to this certification track. The introduction of this track gives no excuse to Oracle Applications DBA's not be an OCP. :). Almost all of these exams are still available in beta release which means it will not have a pre defined passing score or the number of question. but roughly you could expect anything between 170 - 200 questions to be attempted in a three hour time duration.

Applications Technology Administrator OCP

To earn an OCP as an Applications Technology Administrator 11i you would need to successfully complete the following three exams and hands on course requirement.

Implement Oracle Workflow 11i (Exam Number:1Z0-231)

This exam is based on Oracle Workflow version 2.6.
A complete list of the exam topics and oracle recommended course can be found here.

Oracle 11i System Administration (Exam Number:1Z1-232)

This exam is based on the System Administration Duties of a DBA on Oracle Applications version 11.5.10.
A complete list of the exam topics and oracle recommended course can be found here.

11i Install Patch and Maintain Oracle Applications Ed 5.1 (Exam Number: 1Z1-233)

This exam focuses on the backend duties of the with respect to patching cloning and adadmin utilities on Oracle Application 11.5.10.
A complete list of the exam topics and oracle recommended course can be found here.

Oracle E-Business 11i Hands-On Course Requirement

Apart from passing the above three exams it is also required to meet the Hands-On Course Requirement. This i assume might make some of frown :) but the good news is that till May 2007 this requirement is waived by filling a Hands-on Requirement Waiver Form

If however you are not able to fulfill the waiver requirements you must attend one of the prescribed courses to be able to complete the requirement.

List of course that satisfy the Hands On Course requirement can be found here.

Useful Certification References

Getting Started On Certification
Certification FAQ
Certification Datasheet

Posted by Sam at 04:56 PM | Permalink | Comments (16) | TrackBacks (0)

Patching Best Practices

As an Oracle Applications DBA we tend to spend a considerable amount of time applying patches. A newbie Applications DBA recently asked me the duties of an Applications DBA besides patching .At that moment i refrained myself just to a smile. But the question does highlight the significance of patching in an AppsDba's routine.

Patching, though not a very complicated process, inefficient or inappropriate patching can seriously jeopardize the  functioning of your system. Most of the patching for oracle applications is done using adpatch tools and there are many more which have other methods of application like through a shell script. However in my current post i will talking only about the adpatch patches. The 'best practices' mentioned here are the ones which I have felt to be of use and have made my patching  life a bit less complicated.

Patching Methodology
Having a proper patching process and methodology is always helpful. The ideal one for me is the PATCH -> TEST -> DEVELOPMENT  -> PRODUCTION one. Under this the patch is first applied to a patch instance then it is propagated to the test environment where the testing is done after which it is applied on the development instance where the development team tests the patch against there customizations if any. Upon passing these stages the patch is finally applied to the production system. If you cannot afford these many instances at minimum you must ensure the patch is tested on TEST environment before you actually go 
ahead and apply the patch to your production.

Consistency
There should be consistency in the patch application process. That is you should use the same steps to apply the patch in your  production environment that you used in your TEST/PATCH environment for example if you applied a pre requisite patch A as part 
of your main patch application, you must ensure the same pre requisite patch is also applied on the production environment and  not a superseded version of patch A.
Needless to mention there must be also consistency among the all the different environments. That is your PATCH/TEST/DEVELOPMENT and PRODUCTION environments should have the same setups configuration and patchset levels.

Schedule Patch Application
Schedule the patch application as far as possible. There are multiple benefits you realize out of scheduling. The most  important one being that the downtimes will be scheduled and will have help the business to be prepared for them and not be  taking them by surprise. Also if your patching downtimes are scheduled you can plan to have the downtime following your backup schedule thereby eliminating the need for having a separate backups for each patch application. However there will be high priority patches that will have applied outside this schedule.

A Patch in Time
It is always advisable to be at the latest patch set level at most of the times. I have always felt that it is one of your  duties as an Apps DBA to take the fear of patching out of the business's mind. My experience sys that being on the latest  Consolidated Update or the latest Roll up patch helps in avoiding most of the pre requisite in case of applying any one off patch which might be required. Also you should apply the Critical Patch Updates that are released by oracle every quarter.

The Readme
Before applying a patch make sure you have gone through the readme file of the patch. This file might contain some special or additional steps that you might have to follow as a part of the patch application. Also it will tell you if there are any pre requisite patches that are require. Downloading and having the pre requisites ready saves you a lot of time.

Pre requisite Patch
In case you are required to apply a pre requisite patch before you can apply the main patch. it is better to apply the pre requisite patch only and not the superseded version of the pre requisite patch. In case you choose to apply the super seeded version of the of the pre requisite patch you must doubly make sure that the superseded patch qualifies as a pre requisite patch for the main patch.

Patch Impact Analysis
A patch impact analysis should be carried out as far as possible before going ahead with the actual pat6ch application. The simplest way of doing it would be to apply the path with apply=no option along with adpatch. You can then go through the actions the patch would have done either from the logfile or view it through the Oracle Applications manager.

NLS Environment
In case you are patching an NLS environment. Check if you have a translation patch also available for the main patch. if one is available make sure to download and keep it ready. You must install the US language patch first and immediately follow it by applying the translation patch.

Merge Patches
In cases where you are doing a bulk patch application like during a production setup the patch application time is reduced  greatly by merging the patches using AD Merge Patch. However per requisite patches should not be merged. Also in an NLS environment its is not advisable to merge multiple language translation patches.

The Logfile
I most patching scenarios the patch log file is either over written by accepting the default logfile name adpatch.log or in other cases these are not maintained properly. I have found myself digging up patch logfiles for a variety of reasons, though you have a lot of this information available to you via Oracle Applications Manager's Patch Reports.

Maintenance Mode
With the latest AD.I patch set there is a pre requisite to put the system on maintenance mode before applying a patch. I have come across DBA's by passing this option by using options=hotpatch for reducing the patching related downtime. There is a reason for having the maintenance mode feature out there, it offers certain performance benefits and reduces the chances of any conflicts. There are other ways to reduce the patching related down times, which i will touch upon briefly next.

Reduce Your Patch Downtime
As discussed earlier merging your patches is one of the ways to reduce your patching related downtimes. There are also certain options you could use with adpatch which could reduce your downtime significantly. You must however understand each of there options clearly before using them with adpatch. For e.g. choosing not to compile invalid objects might reduce your patching downtime but you must be sure of the invalid objects or you must manually run the compilation script once you are through with all your patch application.
You can also implement the concept of a Shared Application Tier File System and a Staged APPL_TOP to further bring down your patching downtime and effort.

Automate If Possible
In case your business can afford it you should opt for automating the patch application and management process using third party tools. My favorite ones have been Ringmaster APM and Kintana. You might have to still wait a little bit more to have all these features inbuilt through your oracle applications manager.

 

 

Posted by Sam at 08:08 PM | Permalink | Comments (7) | TrackBacks (0)

Unbreakable Linux

This year from the Oracle Open World one of the most exciting/interesting and a little surprising news  for me was Oracle's announcement on Oracle Unbreakable Linux or the Oracle Enterprise Linux.
Being a die  hard Linux endorser myself this made be stand up and pay attention. This year’s OOW I expected most of  the focus to be around the Release 12 and Fusion Applications. So the Linux decision did come  unexpected. But then again you do get the unexpected at OOWs ;)

But what does this mean? Well, according to oracle they plan to extend their "world class support" which they have currently for their enterprise products to RedHat Linux Enterprise 3 and 4.This the plan to deliver through a subscribed Unbreakable Linux Network(ULN).

Oracle's affair with Linux is not new or surprising in anyway. In fact  if i re collect correctly somewhere in June 2002 Oracle  along with DELL and EMC announced their commitment to Linux by developing enterprise class solution for the Linux platform.

There was always an anticipation that oracle coming out with its own Linux distribution but as of now  the Redwood Shores company seems to have been satisfied with just taking over the support of one of top  selling Linux distribution.

This is a commercial paid 24X7 support which will include OS patches, bug fixes kernel enhancements and multilingual support in 27 different languages. And perhaps the most unexpected part of this support is  that according to Oracle you need not be an oracle product customer to qualify for this support. Which  means Oracle is planning to hand out support for RedHat Enterprise Linux regardless of the applications  running on them.

Now that sure would have rung some alarm bells in the RedHat camp. They are currently the only vendor to  provide commercial support and bug fixes for Redhat Linux, with oracle's announcement to support RedHat Linux enterprise with bug fixes for the current, future and back versions of RedHat Linux Redhat's market share is surely headed for a change.

I read this nice post 'Partners, to The End? ' by Kevin Closson

Redhat has already hit back with 'Unfakable Linux'> RedHat Responds :)

According to Oracle.

"With the scale of our support organization we can provide much better Linux support at a much lower price,"

"We have the expertise and infrastructure to improve substantially the quality of support for enterprise  
Linux customers."

More on the Unbreakable Linux

Oracle Unbreakable Linux FAQ
Oracle Press Release

Posted by Sam at 02:33 PM | Permalink | Comments (4) | TrackBacks (0)

Changing the Net Listener Port in Oracle Applications Server 10g

In my previous post I discussed installing the 10g application server. The Application server installation uses the port 1521 as the default port for the application meta data repository. If you already have a listener using that port you have the option of either sharing the listener or configuring a new listener. In my case i tried to change the listener and found out it included just a little bit more than just changing the listener.ora file.

I am listing out the steps that i performed to configure a new listener and get the applications server back to shape.

System Overview

10g Application server with infrastructure and middle tier installed on the same box.

Infrastructure Tier Services  
OID
HTTP Server

Middle Tier Application
Portal

OS Users
Infrastructure OS user: asinf
Middle Tier OS user: asmid

Task
Current Listener running on port 1521.
Configuring a new listener on port 1525

Shutdown Services.

Shutdown all the infrastructure and middle tier services.

su - asmid
$opmnctl stopall
$emctl stop iasconsole

su - asinf
$opmnctl stopall
$emctl stop iasconsole

Shutdown Your Infrastructure Listener

# su - asinf
$lsnrctl stop

Change The Listener Configuration

Make the change to have the new post number in the lsitener.ora file on your infrastructure tier.

# su - asinf
$cd $ORACLE_HOME/network/admin
$vi listener.ora

SID_LIST_SAM =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /u03/oracleAS/asinf/OraHome)
      (PROGRAM = extproc)
    )
  )

SAM =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST =
samlnx02.appsdbablog.com)(PORT = 1525))
      )
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
      )
    )
  )

Change Your TNSNAMES

After this you need to make the change reflecting the new port in your TNSNAMES.ora file on both the infrastructure tier and the middle tier.

$su - asinf
$ vi $ORACLE_HOME/network/admin/tnsnames.ora
EXTPROC_CONNECTION_DATA =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = samlnx02.appsdbablog.com)(PORT
= 1525))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = PLSExtProc)
    )
  )

SAM =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = samlnx02.appsdbablog.com)(PORT =
1525))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = sam.appsdbablog.com)
    )
  )

Also replicate this change in middle tier tnsnames.ora.


Start Your Listener

Start your infrastructure tier listener.

# su - asinf
$lsnrctl start SAM

Set The New Listener At The Database Level.

You must execute this command in your infrastructure database to have the parameter local_listener set to your new listener.

# su - asinf
$sqlplus "/ as sysdba"
SQL*Plus: Release 10.1.0.4.2 - Production on Thu Oct 26 18:38:38 2006

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.4.2 - Production
With the Partitioning, OLAP and Data Mining options

SQL> alter system set local_listener='SAM';
system altered

Bounce The Database.

Stop and startup your meta data repository database to have it register the new listener name.

Start Your OID On The Infrastructure Tier

# su - asinf
$opmnctl startproc ias-component=OID

Change The Port Number In OID.

Start the Oracle Directory Manager from your desktop if you have the client installed else you can use the one on the server at $ORACLE_HOME/bin/oidadmin

Under Entry Management->cn=Oracle Context->cn=SAM->orclnetdescstring chnage the value of the new port here.

Change The Other Config Files.

Based on your installation you may need to change the following files also

$ORACLE_HOME/sysman/emd/targets.xml
$ORACLE_HOME/Apache/modplsql/conf/dads.conf

Posted by Sam at 09:37 PM | Permalink | Comments (6) | TrackBacks (0)

Installing 10G Application Server

Last week i spent a considerable amount of time working on Oracle Application server configurations, i also revisited some of the installation of the core application server components. For starters i will blog with about the installation of Oracle Applications server.

The Oracle Application Server is divided into two main server side components which are infrastructure  and middle tier. Apart from there it also includes developer kits.

These components can be installed on the same server but must have separate ORACLE_HOMEs. Also the  infrastructure must be installed first after which you must install your middle tier components as the  meta data repository is a part of the infrastructure installation.

Another important fact to note is that the oracle application server uses 1521 port as default for its listener. In case the port is used by another listener on your system you must share it with this instance or you must manually configure the application server DB listener to use a different port.

The OS is Redhat Linux AS
The Version Of Oracle Application Server is 10.1.2.0

1.Required OS packages
The first step would be to make sure you have the following packages (or a higher version) installed

glibc-2.3.4-2.9
glibc-common-2.3.4-2.9
binutils-2.15.92.0.2-13
compat-libstdc++-296-2.96-132.7.2
gcc-3.4.3-22.1
gcc-c++-3.4.3-22.1
libstdc++-3.4.3-22.1
libstdc++-devel-3.4.3-22.1
openmotif21-2.1.30-11.RHEL4.4
pdksh-5.2.14-30
setarch-1.6-1
make-3.80-5
gnome-libs-1.4.1.2.90-44.1
sysstat-5.0.5-1
compat-db-4.1.25-9
control-center-2.8.0-12
xscreensaver-4.18-5.rhel4.2

For Linux you can use the rpm -qa|grep <package_name> command to check.


2. OS Directories
Next we will make a directory structure to hold your application server components.

# cd /u03
# mkdir oracleAS
# chmod -R 777 oracleAS


3. OS User Accounts
Having two seperate OS accounts for the infrastructure and middle tier comapnets make it easier to manage the installation.

# useradd -g dba -d /u03/oracleAS/asinf asinf
# useradd -g dba -d /u03/oracleAS/asmid asmid

4.Oracle Inventory

Make sure to set your oracle inventory location to a accessible location.

vi /etc/oraInst.loc
inventory_loc=/u03/oracleAS/oraInventory
inst_group=dba

5. Starting the installation.
The installation has to be started as the infrastructure user (asinf), but executing the runInstaller  
executable. The first screen is the welcome screen.

6.In this screen you would specify your ORACLE_HOME for your infrastructure.

7. The next screen presents you with the option of installing either of the application server  
componets as bloged above we will proceed with the installation of the infrastructure first.

8.The next screen you can choose to install the Oracle Internet Directory, Single Sign On and Meta Data Repository, you could choose to make either of them or all of them included in your application server infrastructure.

9.Next the installer will carry out a pre installation check of your OS.

10. You must conform pre requisite as root privileges on your system.

11. This screen will allow you to choose the services which the installer will configure and start for  
you.

12. In this screen you can choose either to let the installer decide the ports for the various 10G  
Application server services or you can prove one manually using the static port file.

13. This screen will display the default realm for your OID

14. Here you can choose your database SID and also the location for your datafile locations.

15.Next you specify the passwords for your database schema (Unfortunately it does not allow you to  specify passwords for the PORTAL schema ;)

16. In this screen you specify the your instance name and the ias_admin password.

17. The next screen will display the components the installer will install.

 

18. After this a progress bar displays the status of the installation, allowing you just enough time to  catch up on your mails.

19.As a post installation step the installer configures and starts up the installed products.

 

20.You now can start with the installation of the middle tier component as the asmid OS user and choose to install the middle tier services like portal.

 

21. The other steps are all repetitive except the screen where you have register your middle tier component with your OID which was installed as part of your infrastructure.

There two important files that the installation process creates, the first is the portlist.ini located at the $ORACLE_HOME/install directory this file contains the various port numbers used by the application server services. The other file is the supportinfo.txt which contains the URLs to access the installation.

Posted by Sam at 11:26 PM | Permalink | Comments (11) | TrackBacks (0)

Changing The Character Set In Oracle Applications

Oracle Applications supports the installation of additional languages along with the base installed languages. In case you are doing the installation of these languages at the time of oracle applications installation rapidwiz will make sure you select a compatible character set. In case you plan to install a new language to an already installed instance of Oracle Applications you need to make sure that the database and application character set support the new language.

Changing the character set of Oracle Applications will happen at two places, firstly at the database level and then at the application file system level.

Although most of the character set conversion have a different set of process to follow which have been individually documented in various metalink notes. In this post i am will talking about the set of steps that generally hold true for most of the cases.

The main steps that would be required to perform the character set conversion in Oracle       Applications are

• Run the Character Set Scanner utility to identify data conversion issues.
• Export the identified objects marked for conversion.
• Perform the Database conversion by user the alter database command.
• Run adadmin to identify and perform the file system character set conversion.

For the sake of ease I am taking a US7ASCII instance running on (you guessed it rite ;) a Redhat Linux and converting it into a UTF8.Although US7ASCII being a binary subset of UTF8 would not really require much of the conversion.

Character Set Scanner utility

Though the change from US7ACII to UTF8 could be done with only using the 'alter database command' we will use the character set scanner utility CSSCAN to scan for any change required.

Installing the CSSCAN schema.

Before using the cssan you must install the schema as a user with DBA privilages.This is done by executing the csminst.sql script located at $ORACLE_HOME/rdbms/admin

cd $ORACLE_HOME/rdbms/admin
$sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.6.0 - Production on Tue Oct 17 16:00:16 2006
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
SQL> START csminst.sql

Executing CSSCAN

The CSSCAN executable is located at the $ORACLE_HOME/bin. After executing the script you must connect to the Database as a user with DBA privileges. The CSSCAN utility prompts you with options to scan a table, schema or the enter database. We choose to scan the entire database in our case.

The CSSCAN displays your current character set version and prompts you to enter the new character set version.


$ csscan
Character Set Scanner v1.1 : Release 9.2.0.1.0 - Production on Tue Oct
17 16:03:15 2006
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
Username: system
Password:
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production

(1)Full database, (2)User, (3)Table: 1 > 1
Enter new database character set name: > UTF8
Enter number of scan processes to utilize(1..32): 1 >


After the successful completion of the scan three report files will be created scan.txt,scan.out and scan.err.

In my case I have exported the database objects with exceptions as specified in the scan.out and plan to import it back after the database conversion is done.

Changing the Character Set At Database Level

Shutdown all application services and the database and listener.You must do a clean shutdown of your database and start it up in restricted mode before changing the character set.Also you must not have any active sessions before issuing the alter database command.

SQL> alter database character set internal_use UTF8;
alter database character set internal_use UTF8

Import Back Database Objects.

After a successful character set conversion at the database level now you can import back the objects and rebuild the indexes specified the in scan.out report.

Changing the Character Set Application Level

Run adadmin and choose  Maintain Applications Files menu. Under this choose the convert character set conversion option.

Here you will be presented with three choices.

 1. Scan the APPLTOP for exceptions
 2. Scan a CUSTOM directory for exceptions
 3. Convert character set
 4. Return to previous menu


You must choose the first option and after that in case of Custom directory you could choose the second option. This will scan the APPL_TOP and make a list of application files which would require conversion.

After the scan is complete you can choose to convert the character set.

Repeat the above steps on all your APPL_TOPs in case of a multi node instance.

Posted by Sam at 10:56 PM | Permalink | Comments (6) | TrackBacks (0)

Adding an Additional Node to an existing Oracle Applications Instance.

Coming to the advanced configurations in ebusiness suite, today my current post will talk about introducing a new node to an already existing ebusiness suite.

Current configuration
A single node instance of 11.5.10.2 on Linux This is referred as Node A in the rest of the post.

Task
Plan to introduce a new Linux node (referred as Node B) for the web and the forms server and split the instance into a two node configuration.

Node A Configuration

Application User: applsam
Home Dir: /u02/sam/applsam
Oracle User: orasam
Home Dir: /u02/sam/orasam
Instance SID: SAM

The task can be accomplished either by implementing a SHARED APPL_TOP concept or by using rapidclone. I am using rapidclone in my current post here.

The brief outline of steps to be performed to accomplish this task are.

• Running Pre Clone on Node A.
• Copying the Application Tier Files to Node B.
• Running Post Clone on Node A DB Tier and Apps Tier.
• Running post clone on Node B Apps Tier.
• Adding the additional node script on Node A.

Running Rapid Clone on Node A Database Tier and Applications Tier.

Pre-Clone on database Tier Of Node A

Login to Node A as the database owner and set the environment

# su - orasam
$ cd samdb
$ cd 9.2.0/
$ . ./Sam_Node_A.env
$cd $ORACLE_HOME/appsutil/scripts/Sam
$ perl adpreclone.pl dbTier

Pre-clone on Node A application tier

Login to to Node A which is also our source system as the applications user and set the environment.

# su - applsam
$ cd samappl
$ . ./APPSORA.env
$ cd $COMMON_TOP/admin/scripts/sam
$ perl adpreclone.pl appsTier

Disable security option

In Oracle Applications 11.5.10 the SQL*NET restricted security option is enabled by default. As a result your new node Node_B  will not be able to connect to the database. You must either disable this security option or the better way is to add Node_B  is the list of trusted nodes through OAM.

Oracle Applications Manager -> Security ->Disable Restricted Sectrity Option.

After this you must run Autoconfig on the database Tier and restart your listener.

# su - orasam
$ cd $ORACLE_HOME/appsutil/scripts/SAM_NOde_A
$ ./adautocfg.sh

Restart your listener.

$ ./addlnctl.sh stop sam

$ ./addlnctl.sh start sam

Preparing the new node (Node B) to copy the application tier file system.

On Node B make the following dir structure

# cd /u02
# mkdir sam
# chmod -R 777 sam

Copy the files across to Node B

Shutdown on Application and Database services on Node A
tar -cf - applsam | ssh Node_B tar -xf - -C /u02/sam/

Post Clone on Node A Database Tier 

Now you must run your post clone (adcfgclone.pl) on the database tier of Node A preserving the original values

# su - orasam
$ cd samdb/9.2.0/appsutil/clone/bin
$ perl adcfgclone.pl dbTier

Post Clone on Node A Applications Tier

Now you run your post clone (adcfgclone.pl) on Node A applications Tier. you must remember to configure the services you require on tiis node in our case the CM and the Admin Node.

$ perl adcfgclone.pl appsTier

Once completed sucessfully this will start the specified services only in our source Node Node A.

Running Post clone On Node B

Next you run your post clone on the Node B again specifying the services you like to configure which in our case were forms server and the web server.

$ perl adcfgclone.pl appsTier

Execute the Add Node script on Node A

After sourcing your environment file you must run the adaddnode.pl script on node A

#su - applsam
$ cd $COMMON_TOP/clone/bin
$ perl adaddnode.pl

The script will promt you for your APPS user and password and do the required new node entries to the database FND tables.

You can check the details of this new node and status through Oracle Applications Manager.

References.
Advanced Configurations and Topologies for Enterprise Deployments of E-Business Suite 11i Note Id 217368.1
Cloning Oracle Applications Release 11i with Rapid Clone Note Id 230672.1

Posted by Sam at 11:28 AM | Permalink | Comments (6) | TrackBacks (0)

Oracle Applications Tablespace Model - OATM

The Oracle Applications Tablespace Model was another long awaited feature that got introduced in 11.5.10.Prior to 11.5.10 by default each of the oracle applications product would have two dedicated tablespace holding the data element and the other for storing the index eg GLD (For General Ledger base tables) and GLX (For indexes relation to the General Ledger product).This easily resulted in some 300 odd tablespaces to manage apart from the system, temp and the rollback tablespaces.

In the new Oracle Applications Tablespace Model (OATM) all these product related tablespaces have been consolidated in two main tablespaces one for holding the base tables and the other for holding the related indexes. Apart from these two tablespace you have an additional ten tablespaces including system tablespace undo tablespace and the temporary tablespace. Thereby reducing the total number of tablespace in the OATM to twelve.

Apart from the obvious ease of management and administration with a reduced number of tablespace being involved the OATM also  provides benefits like efficient space utilization. This is achieved by supporting locally managed tablespaces as opposed to the dictionary managed tablespace in the previous model.

OATM also supports uniform extent allocation and auto allocate extent management. In uniform extent management all the extents have the same size and result in less fragmentation. Auto allocate extent management allows the system to determine the extent sizes automatically.

OATM also provides additional benefits when implementing Real Application Clusters (RAC) in Oracle Applications.

Under the OATM the following twelve tablespaces are created as a default.

• APPS_TS_TX_DATA - This tablespace hold the translational tables of all Oracle Applications products. For example the GL_JE_HEADERS will be a part of APPS_TX_DATA.
• APPS_TS_TX_IDX - All the indexes on the product tables are kept under this tablespace.
• APPS_TS_SEED - The seeded data that is setup and reference data tables and indexes form this tablespace. For example your FND_DATABASES table would reside in the APPS_TS_SEED tablespace.
• APPS_TS_INTERFACE - All the interface tables are kept in this tablespace for example the GL_INTERFACE table.
• APPS_TS_SUMMARY - All objects that record summary information are grouped under this tablespace.
• APPS_TS_NOLOGGING - This tablespace contains the materialized views that are not used for summary purposes and other temporary 
  object that do not require redo log entries.
• APPS_TS_QUEUES - With the support for advanced queuing in Oracle Applications, the advanced queue tables and related objects form a part of this tablespace.
• APPS_TS_MEDIA - This tablespace holds multimedia objects like graphics sound recordings and spital data.
• APPS_TS_ARCHIVE - Tables that are obsolete in the current release of Oracle Applications 11i are stored here. These tables are  preserved to maintain backward compatibility of custom programs or migration scripts.
• UNDO - The undo tablespace is used as automatic undo management is enabled by default in 11.5.10.This acts as a replacement to red log files.
• TEMP - The Temp tablespace is the default temporary tablespace for Oracle Applications.
• SYSTEM - This is the SYSTEM tablespace used by the Oracle Database.

For all new installation of 11.5.10 OATM is available as a default install. For prior applications system you can migrate your existing tables spaces to the oracle applications tablespace model. For this purpose you have the Tablespace Migration Utility(TMU) which is available as a patch (3381489).

The TMU is a Perl based interactive utility that helps in migrating the oracle applications schemas to implement the OATM.
For additional information refer to the Oracle Applications Tablespace Migration Utility User Documentation.

Posted by Sam at 12:53 PM | Permalink | Comments (6) | TrackBacks (0)

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.

The concurrent manager log files are a important place to check for any concurrent manager problems. The logfiles are in the .mgr format and can be located at the $APPLCSF/$APPLLOG

An oracle diagnostics test is also available to check the setup and the status of your concurrent manager under the Oracle Applications Library -> Setup -> concurrent Manager.

Posted by Sam at 10:53 PM | Permalink | Comments (11) | TrackBacks (0)

Oracle Applications Patch Types

In a continuous effort to improve applications performance, fix bugs address security vulnerabilities, perform language translations or simply add additional functionality oracle release a series of patches in addition to their base release of applications.

It goes without saying as with the case of any other applications it is recommended to be at the latest certified patch set level at most times.

The Oracle Application patches are categorized into the various types based on their purpose and the bugs they fix. This could get confusing at times to start with but once you have a understand of the oracle naming conventions, it will make your life  as an APPS DBA a whole lot easier.

Below are categories under which Oracle Application patches are divided.

• Standalone or Individual Patches - These kind of patches are delivered to fix a one off bug or introduce a new feature in any  of the oracle applications products. Mostly these patches would be independent and unrelated though they might require certain 
  pre requisite patches to be applied.
  
• Mini Packs - These are a consolidation of various standalone patches for a particular product in oracle applications like  AD,GL etc. The naming convention for mini packs would be in the form of 11i.<product>.<minipack letter> such as 11i.AD.I.Mini packs are cumulative in nature that is AD.I would include all the bug fixes that were included in AD.H and so on. Prior to release 11 the mini packs were referred as patch sets.
  
• Family Packs - A family pack is a consolidation of all the mini packs and various stand alone patches for a particular oracle 
  applications product family. The functional grouping of application products forms a product family like financials HRMS etc. The naming convention of these family packs are in the form of 11i<productfamily_product>.<Familypack letter> like  11i.HR_PF.K.As in the case of mini packs the family packs are also cumulative in nature.
  
• Consolidated Updates - Since the time between releases of oracle applications is significant, a number of patches mini packs and family packs would have been introduced. A consolidated update as the name implies is a consolidation of the recommended 
  patches that have been released up till the date of the release of the consolidated update. A consolidated update brings the entire oracle applications system to the latest recommended patch level. The consolidated updates are in the form of  CU<Update Number> like CU2.Consolidated updates are also cumulative.
  
• Technology Stack Updates - Recently oracle has started to introduce a new type of patch know as the technology stack update, these include consolidation of patches and mini packs for the underlying technology stack. As a result they do not include any  functional patches. An example of technology stack update is 11i.ATG_PF.H.Technology stack updates are cumulative.
  
• Maintenance Packs - A maintenance pack is a consolidation of all the mini packs for all products and all the family packs for the entire oracle applications. Maintenance packs upgrade the system from on release to a higher release for example when you apply the 11.5.10.2 maintenance pack to a 11.5.9 system you upgrade your entire oracle applications to a higher version.
  
• Critical Patch updates (CPU) - Every quarter oracle releases critical patch update that addresses the security vulnerabilities and alerts that have been identified. The critical patch updates were introduced in 2005 prior to which security alert were used address the security fixes for oracle products.
  
• Translation Patches - In a multilingual environment the patches are first applied in the base language. After that a translation patch is required to be applied for each of the additional language installed. The translation patches would be in the form of <patch number>_<Language code> like 3460000_FRC implies the Canadian French translation patch for 3460000  (consolidated update 2).
  
• Recommended Patch List (RPL) - A recommend patch list is a list of patches for a particular oracle applications product. The RPL is not a patch but just a list of recommendations. In fact the consolidated updates are built up on the RPL based on the cut off dates for inclusion.

 

Posted by Sam at 04:28 PM | Permalink | Comments (9) | TrackBacks (0)

Finally the blog is  back again and this is the new address

www.appsdbablog.com

RSS feed URL

http://appsdbablog.com/atom.xml

There are still some tweaks that i doing on this blog, like the email subscriptions are yet to be made up.

In case you find some changes that are missing or don’t like just drop in a comment, I will surly work on that.

Thanks for patience.

Posted by Sam at 11:02 AM | Permalink | Comments (3) | TrackBacks (0)