This is the last in a series of articles that list a few of the technical myths or misunderstandings about the E-Business Suite. Previous articles have covered installations, cloning, patching, migrations, and upgrades. This article discusses general maintenance.
Each article is absolutely not definitive and I’d be 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: Manually editing files that are maintained by AutoConfig. ORACLE’S RECOMMENDATION: When you run AutoConfig, in most circumstances any manual changes to AutoConfig controlled files will be overwritten. There is a process for adding custom entries to AutoConfig maintained files; you should use this process if you need to make manual changes to files maintained by AutoConfig. Refer to Section 4 of the AutoConfig Note for information on how to customise AutoConfig.
COMMON ERROR #2: Maintaining local file systems for multiple application tier servers instead of shared file systems. ORACLE’S RECOMMENDATION: An environment with, for example, four standalone web/forms nodes on Linux and four standalone Concurrent Processing / RAC nodes on Solaris each using a local file system is a very inefficient architecture that you will very quickly get bored of patching. Each E-Business Suite patch will need to be applied eight times. This can be reduced to one patch session if Concurrent Processing is placed on the same node(s) as web/forms and a shared application tier file system is introduced. If you cannot achieve acceptable performance from your shared disk subsystem then you should investigate the performance issue on your disk subsystem rather than compromising with an E-Business Suite architecture that has such expensive maintenance requirements.
COMMON ERROR #3: Sizing everything in the init.ora as large as possible. ORACLE’S RECOMMENDATION: Database tuning is a delicate exercise. Indiscriminately increasing values in the hopes that doing so will automatically improve performance is a dangerous approach. Use the performance tools in Oracle Enterprise Manager (OEM) and other tools to establish performance bottlenecks. Do not change init.ora parameters indiscriminately; all changes should be supported by your own empirical evidence that candidate changes result in performance improvements. Thoroughly stress-test all changes before implementing in production.
COMMON ERROR #4: Ignoring invalid objects for products you do not use. ORACLE’S RECOMMENDATION: All products are installed in an E-Business Suite installation in the database. All products must be patched and maintained. Invalid objects, even in products you do not use, indicate an underlying problem in your system that should always be investigated and resolved.
COMMON ERROR #5: Performing a complete database export/import to improve performance. ORACLE’S RECOMMENDATION: Well possibly, but there is certainly a lot of unnecessary exporting and importing of databases in an attempt to improve performance. This brings us nicely back to the introduction of our first article in this series. A significant amount of the data in your database is static. Tables may become fragmented but this is not automatically a performance problem. If this was the case, many databases would have performance problems.
An Oracle database is built to cope with a reasonable amount of fragmentation and will not suffer because of it. Analyse performance problems before assuming the issue will be solved by an export/import. Most performance problems are due to poor indexing of tables and inefficient SQL. Few are caused by table fragmentation.