Today morning, when I received the mail from blogs.oracle.com, i was really surprised to see the content.. it was really useful.. when considering the client needs, we can consult them with all the possible better ways.. but it is their take and upto them to decide.. this is now the industry stand. Now Oracle provided extra hand to substantiate our recommendations.
Please read the full content.. Full blog from steven chan is here
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 myths or misunderstandings that seem to have gained a foothold in the wider E-Business Suite community. 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.
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 myths or misunderstandings that seem to have gained a foothold in the wider E-Business Suite community. 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.
No comments:
Post a Comment