Five Errors Customers Make When Installing E-Business Suite 12 (Part 1)

One customer recently asked if we could supply documentation and scripts to remove all the E-Business Suite objects from their database leaving them with an empty database. After a few questions, it became apparent they were concerned about performance and a third party consulting organisation had advised the best solution to performance problems was to export and then import the whole database.

Whilst it’s true an export/import might solve performance problems, there are many other things you can do before you conclude the best solution is an export/import; it’s certainly not the default solution. That’s a pretty extreme example but there are quite a few myths and misunderstandings which seem to crop up regularly in Service Requests.

This is the first in a series of short articles that lists a few of the technical myths or misunderstandings about Oracle E-Business Suite. Other articles have covered cloning, patching, migrations, upgrades, and maintenance. This first article discusses installations.

Each article is absolutely not definitive and I’d be particularly interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.


COMMON ERROR #1: In a global implementation, putting your database tier host in your global data centre and putting local application tier hosts in each country.

ORACLE’S RECOMMENDATION: You must put all host nodes of your E-Business Suite environment in one data centre with the fastest possible network connection between nodes. This applies regardless of the location of your users.


COMMON ERROR #2: Placing concurrent processing services and the database tier on the same node to improve performance.

ORACLE’S RECOMMENDATION: There is no significant performance benefit to placing concurrent processing and the database tier on the same node. Your system will be more scalable if your database tier hardware is dedicated solely to serving the needs of the database. Patching, cloning and E-Business Suite administration will also be much easier as you will have at least one less APPL_TOP and application tier technology stack to maintain. Placing concurrent processing on the database tier node to distribute load might suggest that your application tier hardware is already undersized. You should place concurrent processing on the same nodes as your web/forms services or create a dedicated concurrent processing tier in exceptionally busy environments.


COMMON ERROR #3: Installing only the default database character set although you know that you will need a different character set later.

ORACLE’S RECOMMENDATION: Failing to consider national language support (NLS) and database character set requirements when installing a new environment is a critical mistake. You should normally have a very good idea of language requirements before you start your installation. Implement the correct languages and database character set when you perform your installation. Characters sets can be changed later and languages can also be added but if you think you are going to need them then implement them early in your project. Realising that you have forgotten the purchasing team in Denmark the day before you go live will not make you a popular DBA.

You cannot specify a different character set when upgrading to R12. The R12 upgrade process cannot do a character set conversion.


COMMON ERROR #4: Separating Oracle database and application tier ownership by different operating system users/groups.

ORACLE’S RECOMMENDATION: In simple single node installations the whole E-Business Suite file system (including the database) can be owned by a single user/group. This can simplify installation and maintenance. Oracle documentation and Oracle Support engineers sometimes refer to the ‘applmgr’ user and the ‘oracle’ user. These are generic terms used loosely to describe the operating system owner of the application and database tier file systems respectively – they are not mandatory user names. It is also not mandatory to perform E-Business Suite installations as the root user.


COMMON ERROR #5: Before retrying a failed installation, forgetting to remove its entries from the central inventory.

ORACLE’S RECOMMENDATION: When deleting an E-Business Suite environment, in addition to shutting down and deleting files, you must also remove its entries from the central inventory. The central inventory is a file based repository of all Oracle homes installed on a node. This central inventory may exist outside the E-Business Suite file system and is not always removed when you remove the E-Business Suite file system. If the central inventory contains entries for previously deleted E-Business Suite environments then subsequent new installations may fail.

References

Related Articles

Comments:

I agree with all your points, except point 4. On a single server implementation, it is a nightmare to change environment variables every time you want to switch between "applmgr" tasks and "oracle" tasks.
Even on a multi-tier environment, using the same userid for "applmgr" and "oracle" creates more confusion than solving problems.

Posted by Pieter on July 15, 2012 at 11:56 PM PDT #

Hi Pieter

If you have to maintain your E-Business Suite(s) through a single session then I agree, having to switch environments is always going to be a chore. It's better to have a different session for application and database tier maintenance - this applies regardless of who owns the underlying filesystem. Avoid automating the setting of an environment when logging in if you are using a single owner.

I wanted to make the point that it is not mandatory to have different owners for different components of the E-Business Suite.

Regards

Nick

Posted by Nick Quarmby on July 16, 2012 at 12:36 AM PDT #

You were extremely gentle regarding the export/import suggestion from the "third party consulting organization".

Ken

Posted by Ken on July 19, 2012 at 12:20 PM PDT #

Hi Ken

I think there is definitely a minority mindset out there that considers an export/import is the first rather than the last resort to addressing performance problems.

Regards

Nick

Posted by Nick Quarmby on July 20, 2012 at 01:21 AM PDT #

Nick,

regarding item 2 above, I am not questioning the statement as I have seen evidence of the sense of this approach myself, but I've searched for an Oracle support document offering a corroborating reference to hosting the concurrent manager service on the middle tier rather than on the database tier, but been unsuccessful. Do you know of a metalink note I can use to support this argument?

Regards,

Michele

Posted by guest on April 23, 2013 at 06:20 AM PDT #

Hi Michele

I apologise for the delay in responding - I was on a brief holiday.

This issue is discussed in the following documentation. It encourages a separate host for concurrent processing which would also be appropriate. My point above was mainly to emphasise there is no significant benefit to placing concurrent processing on the database tier.

Oracle E-Business Suite Technology Stack Release Notes for Release 12.1.3 [Note 1098650.1]:

2.6 Updated Architectural Guidance
With fast local networks and the typical co-location of database and application tier machines, it is now generally preferable to perform concurrent processing on a separate machine from the database. This faciliates ease of management and maintenance, and provides deployment flexibility.

12.2 documentation will also reinforce this point although this is not yet currently available.

Thanks

Nick

Posted by Nick Quarmby on April 29, 2013 at 05:35 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today