Posted by: Amol Umbarkar in Untagged on
Jul 17, 2009
It doesn't surprise me much that the existing oracle applications systems will have to accept the new OATM (Oracle Applications Tablespace Model) before R12 upgrade. It will be inevitable especially because the R12 patch creates all DB objects in the tablespaces proposed by OATM. The model was proposed initially from Release 11.5.10 and remained as an optional step untill today.
Initially I assumed this is going to be the way forward and customers will have to migrate to OATM model but then I stumbled upon the following excerpt in a metalink note:
The reason for that is because the new products created with the R12 upgrade are created in the OATM model, but the old objects are still kept in the old tablespace model. This would keep the DB temporarily with a hybrid model, what is not recommended.
There are a lot of recommendations from oracle that remind me of those unreasonable parental advices but not this one. Prima facie I did have such notion but after getting to the depth of OATM design I realized its importance from perspective of better space management, especially with the present situation where the idea of "Unified Data Systems" is widely pursued. More companies especially multinationals are trying to reduce the maintenance costs by running all operations across all subsidiaries on a single ERP system. Considering this dire need of customers to bring all operations in single system, Oracle has also started including more and more of application modules that support almost every business need. There are as much as 191 modules available with R12 release.
The earlier releases comprised of two tablespaces for each application module, one to store data (tables) while other for index trees. It made umpteen sense as it provided comfort for differentiating application data at storage level too and also helped from performance perspective. Since each of tablespace could be maintained on a separate disk, the use of application modules did not cuase any contention with each other.
This approach of tablespace management was widely used and also recommended by database experts. So I had my own curiosities about OATM since it was going to replace the proven and most commonly used design.
A couple of hours into OATM gave me the following results:
- Effective space management. There are now 191 application modules available from Oracle now and supporting each module with separate table spaces (2 in total - one for data, one for index) would have meant 382 tablespaces. OATM avoids such difficulties and gathers similar data in one place.
- Ease in administration and configuration. There will be one locally managed table space for each type of object (tables, index, etc).
- Improves performance of buffer gets. Increased storage at block level
- Supports wide stripe configurations (?)
- Useful for RAC + Linux configuration. Such configuration has limitation of 255 raw devices, new OATM would just provide a workaround
The following type of tablespaces are being introduced in OATM. They are 12 in total and each has its unique purpose. Needless to mention, all will be shared by implemented modules on the application system.
- APPS_TS_TX_DATA - Transaction tables
- APPS_TS_TX_IDX - Transaction Indexes
- APPS_TS_SEED - Reference and setup data for Indexes. FND Objects
- APPS_TS_INTERFACE - Interface and Temporary data and indexes (interface tables like ra_interface_lines_all,etc)
- APPS_TS_SUMMARY - Summary Management objects such as materialized views
- APPS_TS_NOLOGGING - Materialized views not used for summary management and temporary objects
- APPS_TS_QUEUES - Advanced queuing objects
- APPS_TS_MEDIA - Multimedia objects
- APPS_TS_ARCHIVE- Archive purge related objects
- UNDO - Undo data
- TEMP - Temporary data. Global Temporary tables
- SYSTEM - system tablespace. Holds data dictionary
For custom schemas it is a wide practice to define separate tablespaces. The same approach can be employed with OATM. In case there are more than one custom application schemas it might be recommended to share one data and one index tablespace. This way the thought of OATM will stay on the course.
The migration utility is available in R12 code pack and patch 3942506. It is recommended to migrate for OATM before R12 upgrade since that would count for breathing time during the upgrade. It is possible to go with a hybrid model where the old objects stay in old tablespaces and new R12 objects will be created as per OATM but I am fairly certain that such approach leads to disaster.
Today there is dire need of unifying operations in a single source system, with such perspective oracle has been including application modules that suit various operational requirements in Organizations. Oracle Applications ERP is moving towards a day when almost any type of information can be captured and utilized by business. For example, a module like lease management sounds so useful for companies that have branches all across world.
Out of my experience, I have not seen any company implementing more than 50 modules yet but I am sure that it would start happening very soon. And this might be the right time we think about future data growth and turn towards solutions like OATM. From a futuristic perspective, I am fairly convinced over the move towards the new OATM.