Please contact me :- ajith.narayanan@infrastack-labs.in

Monday, July 13, 2009

Here is the explanation how you can define concurrent managers and specify when a manager is enabled.

A concurrent manager is itself a concurrent program that starts other concurrent programs running. When an application user submits a request to run a program, the request is entered into a database table that lists all of the requests. Concurrent managers read requests from the table and start programs running. See: Concurrent Managers.

Next , we explain how to specify when a manager is enabled, how to use managers to balance your applications processing workload across different time periods, and how to associate a library of immediate concurrent programs to be called by your manager.

Defining new managers

You can define as many concurrent managers as you want. When you define a manager, you:

Immediate concurrent programs are subroutines associated with concurrent managers. All other concurrent programs are spawned as independent processes at run time.

Assign work shifts to your manager, which determines what days and times the manager works.

For each work shift, you define the maximum number of operating system processes the manager can run concurrently to read requests (start programs) during the work shift.

Specialize your manager to read only certain kinds of requests.

Program Libraries

For a program that is spawned, a concurrent manager initiates or spawns another operating system process. A program that is immediate runs as part of the concurrent manager's operating system process.

A program library contains immediate concurrent programs that can be called by your manager.

An immediate concurrent program must be registered with a program library. Application developers using Oracle Application Object Library can register concurrent programs with a program library.

The Oracle Application Object Library FNDLIBR program library contains Oracle Applications immediate concurrent programs, and is assigned to the Standard concurrent manager. In most cases, you will include the FNDLIBR library with your manager's definition.

The Concurrent Manager Managing request

A typical Concurrent manager is managing request in typical the flow which is described below.

And if Concurrent manager is having work shift set up , one the top of above process, the best can be described as:

How many Concurrent Managers available in oracle Apps

Similar to other products in there are seeded, Transaction and Other Concurrent Managers available. The Creation of custom manager is also possible , I am unable to throw some light, as i hadn't exposed to setting up of these area . In a typical implementation , it would be taken care by DBA's , and you can find some documents in system admin user guide for further details.Here , I am going to list of the concurrent manager which are used for some of processing within the product.Lets start to explore options for managers in EBS Suite:

The Seeded Concurrent ManagersOracle seeds the Internal Manager and Conflict Manager with every implementation. Here are the list of some of them:

Internal Manager

The internal manager is the highest level manager that controls all the other managers

Conflict Resolution Manager

Resolves request conflicts. When programs are defined with incompatibilities with other programs, both programs will show up in the Conflict Resolution Manager if they are both trying to run at the same time. Programs that are submitted but have no place to run because of incorrect setup choices for the concurrent managers will also show up under the Conflict Resolution Manager.

The Transaction Managers

Inventory Manager

Runs Inventory Programs. As seeded, the Inventory Manager has a number of individual programs assigned to it

MRP Manager

Runs the Planning Manager. The MRP Manager is seeded by Oracle to only run the Planning Manager program. You may consider assigning a small number of other concurrent requests, including the MRP processes, to this manager if you are a heavy manufacturing user, to pull these critical processes out from under the Standard Manager.

PA Streamline Manager

Standard Manager

The general queue for handling requests. The Standard Manager was set up to run all concurrent requests.

Thursday, July 9, 2009

The Oracle Applications Tablespace Model was another long awaited feature that got introduced in 11.5.10.Prior to 11.5.10 by default each of the oracle applications product would have two dedicated tablespace holding the data element and the other for storing the index eg GLD (For General Ledger base tables) and GLX (For indexes relation to the General Ledger product).This easily resulted in some 300 odd tablespaces to manage apart from the system, temp and the rollback tablespaces.

In the new Oracle Applications Tablespace Model (OATM) all these product related tablespaces have been consolidated in two main tablespaces one for holding the base tables and the other for holding the related indexes. Apart from these two tablespace you have an additional ten tablespaces including system tablespace undo tablespace and the temporary tablespace. Thereby reducing the total number of tablespace in the OATM to twelve.

Apart from the obvious ease of management and administration with a reduced number of tablespace being involved the OATM also provides benefits like efficient space utilization. This is achieved by supporting locally managed tablespaces as opposed to the dictionary managed tablespace in the previous model.

OATM also supports uniform extent allocation and auto allocate extent management. In uniform extent management all the extents have the same size and result in less fragmentation. Auto allocate extent management allows the system to determine the extent sizes automatically.

Under the OATM the following twelve tablespaces are created as a default.• APPS_TS_TX_DATA - This tablespace hold the translational tables of all Oracle Applications products. For example the GL_JE_HEADERS will be a part of APPS_TX_DATA.• APPS_TS_TX_IDX - All the indexes on the product tables are kept under this tablespace.• APPS_TS_SEED - The seeded data that is setup and reference data tables and indexes form this tablespace. For example your FND_DATABASES table would reside in the APPS_TS_SEED tablespace.• APPS_TS_INTERFACE - All the interface tables are kept in this tablespace for example the GL_INTERFACE table.• APPS_TS_SUMMARY - All objects that record summary information are grouped under this tablespace.• APPS_TS_NOLOGGING - This tablespace contains the materialized views that are not used for summary purposes and other temporary object that do not require redo log entries.• APPS_TS_QUEUES - With the support for advanced queuing in Oracle Applications, the advanced queue tables and related objects form a part of this tablespace.• APPS_TS_MEDIA - This tablespace holds multimedia objects like graphics sound recordings and spital data.• APPS_TS_ARCHIVE - Tables that are obsolete in the current release of Oracle Applications 11i are stored here. These tables are preserved to maintain backward compatibility of custom programs or migration scripts.• UNDO - The undo tablespace is used as automatic undo management is enabled by default in 11.5.10.This acts as a replacement to red log files.• TEMP - The Temp tablespace is the default temporary tablespace for Oracle Applications.• SYSTEM - This is the SYSTEM tablespace used by the Oracle Database.

For all new installation of 11.5.10 OATM is available as a default install. For prior applications system you can migrate your existing tables spaces to the oracle applications tablespace model.

For this purpose you have the Tablespace Migration Utility(TMU) which is available as a patch (3381489).

The TMU is a Perl based interactive utility that helps in migrating the oracle applications schemas to implement the OATM.