Five Errors Customers Make When Installing E-Business Suite 12[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. Each article will deal with a different subject. The first discusses installations; subsequent articles will discuss cloning, patching, migrating, upgrading, and general maintenance. 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

posted @ 2012-08-13 10:32  dbblog  阅读(196)  评论(0)  编辑  收藏  举报