.dbc file administration

Q> What is the backup scenario you can give in case of .dbc file got deleted ?

Ans:

======

1.     Administering .dbc Files

-----------------Applications 11i -----------------

The .dbc file is contained on the web/applications server and holds information used by the database for authentication. The web/application server passes the information from the .dbc file, as well as login information, to the database server to authenticate the user. The authentication process is handled by the standard applications security feature.

The .dbc files required by the application server security system are not part of the delivered product and must be created after installation.

The Java script AdminAppServer is used to create the .dbc files.

Prior to running AdminAppServer you must ensure that:

JDBC classes are in the CLASSPATH and LD_LIBRARY_PATH and $JAVA_TOP is in the classpath

The syntax for the script begins with the call to the script.

jre oracle.apps.fnd.security.AdminAppServer [parameters]

The first parameter must be the connection string followed by the command string.
apps/apps@dbname
ADD

Some commands require additional parameter(s). For example, the ADD command must be followed by the GWYUID and FNDNAM parameters,
which are followed by any optional parameters. Optional parameters are indicated in brackets.

jre oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
ADD \
GWYUID=pub/pub FNDNAM=apps \
[SERVER_ADDRESS=<tcp.ip address>] \
[SERVER_DESCRIPTION=<machine_name>] \
[<env_name>=<env_value>] \
SECURE_PATH=$FND_TOP/secure \
GUEST_USER_PWD=<username/password>

In the example above, the parameter env_name allows you to enter additional information you wish to store in the .dbc file. Programs that access the Applications using the .dbc file will use all of the environment variable settings in the file. Additionally, if you do not provide a value for the SERVER_ADDRESS it will default to the ip address of the machine on which the utility is run.


Creating .dbc Files
Use the AdminAppServer script to create a .dbc file for the application server to access the database server. In addition to creating the .dbc file this script registers the application server with the database for the Applications Server Security feature.
To access additional database servers from the same application server, you must rerun the AdminAppServer script for each additional database. You must run the AdminAppServer script each time you create a .dbc file, and each .dbc file only allows access to one database.


To create a .dbc file for an application server:

1. You must set the username/password value for the GUEST_USER_PWD parameter. Create a valid username ("visitor" for example) in Oracle Applications.

Then use the username/password combination as the value for GUEST_USER_PWD. The syntax is illustrated in the following example:
GUEST_USER_PWD=visitor/welcome

Oracle recommends that you do not assign any responsibilities for this user.

2. From the command line, enter:
jre oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
ADD \
GWYUID=pub/pub FNDNAM=apps \
[SERVER_ADDRESS=<tcp.ip address>] \
[SERVER_DESCRIPTION="Public web access server"] \
[<env_name>=<env_value>] \
SECURE_PATH=$FND_TOP/secure \
GUEST_USER_PWD=<username/password>

The SECURE_PATH parameter provides the location of the directory which contains .dbc files. The value of this parameter must be
set to $FND_TOP/secure.


Updating or Deleting a .dbc File

When updating the .dbc file you can change as many parameters as you want, including the server ID, but you must enter at least one.
Settings that you do not update retain their value.

To update a .dbc file:
From the command line, enter:

jre oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
UPDATE \
[SERVER_ID] \
[SERVER_ADDRESS=<tcp.ip address>] \
[SERVER_DESCRIPTION="Public web access server" \
[<env_name>=<env_value>] \
SECURE_PATH=$FND_TOP/secure \
GUEST_USER_PWD=<username/password>

Attention: If you have not already set the username/password value for the GUEST_USER_PWD parameter, you can do so here using the UPDATE command. For instructions, see the section on Creating DBC files in .Administering Oracle Applications Security in Release 11.

To delete a .dbc file:
From the command line, enter:
jre oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
DELETE \
SERVER_ADDRESS=<tcp.ip address> \
SECURE_PATH=$FND_TOP/secure
This deletes the .dbc file and disallows access to the indicated database if Server Security is active.


Administering Server Security

Because Release 11 is deployed in a multi-tier configuration, the security model has been enhanced to include authentication of application servers
to the database servers they access. When this layer of security is activated, it uses "server IDs" or passwords that the application server passes to the
database server. If the database server recognizes the server ID, it grants access to the database. The server IDs are created using a Java utility.
The application server security system is not initially activated. You must activate it after installation. The application servers are registered
with the database and assigned server IDs when you create .dbc files for Oracle Applications Security in Release 11.

The Java script AdminAppServer is used to set up, activate, and check the status of the application server security feature. For a detailed
description of the AdminAppServer utility see Administering Oracle Applications Security in Release 11.


Server ID Status
You can check the Server ID status for a particular database using the STATUS command in the AdminAppServer script. The STATUS command
displays all registered application servers and their server IDs. The command also indicates whether the server security feature is currently active.

Attention: Check the server ID status of your databases before you activate server security and ensure that all desired Application Servers have been registered.

To check the server ID status for a database:
From the command line, enter:
jre oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
STATUS

Activation of Server Security
You can turn the server security feature on or off using the same AdminAppServer utility. When you turn off server security, you will not change or
delete your server IDs. You can restart server security without recreating server IDs for all of your applications servers.

To activate server security:
From the command line, enter:
jre oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
AUTHENTICATION ON

To deactivate server security:
From the command line, enter:
jre oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
AUTHENTICATION OFF

Updating or Deleting Server IDs

You can update or delete a application server's server ID at any time. When updating the server ID you can change as many parameters as
you want, including the server ID, but you must enter at least one.

Note: Server ID values are generated by the AdminAppsServer utility, and therefore cannot be supplied on the command line.

To update a server ID:
From the command line, enter:
jre oracle.apps.fnd.security.AdminAppServer apps/apps@dbname \
UPDATE \
SERVER_ID \
[SERVER_ADDRESS=<tcp.ip address>] \
[SERVER_DESCRIPTION="Public web access server" \
[<env_name>=<env_value>] \
SECURE_PATH=$FND_TOP/secure \
GUEST_USER_PWD=<username/password>


------------------------------------------------------------For Application R12------------------------------------------------
use below

java oracle.apps.fnd.security.AdminAppServer apps/apps
ADD FNDNAM=apps
GWYUID=applsyspub/pub
TWO_TASK=VIS
SECURE_PATH=$FND_TOP/secure
GUEST_USER_PWD=guest/oracle
APPS_JDBC_DRIVER_TYPE=THIN
DB_HOST=appsdemo.test.com
DB_PORT=1531

               

Concurrent Manager

Concurrent Program

A program that implements a business functionality and needs to be executed again and again at regular interval or as per business needs is called concurrent program. They can be implement in PL/SQL, Shell Script, C/C++ etc. 

Concurrent Manager

Now when a concurrent program is written, it needs to be executed daily at particular time. If we do it manual, there might be chances of delays or it might happen that two different people run the same program at the same time which might lead problems. So we need a manager which can do all this tasks for us. The responsibility for execution of concurrent programs is given to Concurrent Manager, which ensures that each concurrent program can run successfully without any conflicts. They also  ensures that the applications are not overwhelmed with requests. They also manages the batch processing and report generation.  

The default installation of Oracle Applications comes with a number of pre defined concurrent managers however you can create your custom concurrent managers to spread out the load of your job processing. Apart from taking care of the load of your jobs the concurrent managers can also schedule the jobs periodically. Also we can assign specific priority and specific times to the different programs, so that the concurrent managers can run them in specific workshifts.

Concurrent managers also allows you to tweak the number of concurrent process that it can handle concurrently. If any request exceed this prescribed limit they are automatically put on pending state. The processing of a request takes place based on the time of request submission and priority of the request submitted.

There are many pre-configured Concurrent Managers, each governing flow within each Oracle Apps areas. In addition there are "super" Concurrent Managers whose job is to govern the behavior of the slave Concurrent Managers. The Oracle e-Business suite has three important master Concurrent Managers:

• Internal Concurrent Manager — The master manager is called the Internal Concurrent Manager (ICM) because it controls the behavior of all of the other managers, and because the ICM is the boss, it must be running before any other managers can be activated. The main functions of the ICM are to start up and shutdown the individual concurrent managers, and reset the other managers after one them has a failure.
• Standard Manager — Another important master Concurrent Manager is called the Standard Manager (SM). The SM functions to run any reports and batch jobs that have not been defined to run in any specific product manager. Examples of specific concurrent managers include the Inventory Manager, CRP Inquiry Manager, and the Receivables Tax Manager.
• Conflict Resolution Manager — The Conflict Resolution Manager (CRM) functions to check concurrent program definitions for incompatibility rules. However, the ICM can be configured to take over the CRM's job to resolve incompatibilities.

Apart from these three concurrent manages there is another type of concurrent manager known as the Transaction Manager also exists. The transaction manager is responsible for taking the load off the concurrent request table for pooling the request submitted by the user.The transaction manager takes care of these requests and sends it to standard manager directly.In a RAC environment the Transaction manager is required to be activated on each node of the RAC environment.
 

Concurrent Manager Processes

The concurrent managers are like other process which run on the oracle applications executable FNDLIBR. The FNDLIBR executable is located at $FND_TOP/bin.
You could also grep the FNDLIBR executable to check if any concurrent manager process are running
$ ps -ef|grep FNDLIBR
The $FND_TOP/sql/afcmstat.sql script gives you a list of concurrent managers and their respective status.
Below is the list of Most of the Concurrent manager processes.
FNDLIBR manages following Managers

• Marketing Data Mining Manager
• Transportation Manager
• Session History Cleanup
• UWQ Worklist Items Release for Crashed session
• Collections Manager
• OAM Metrics Collection Manager
• Contracts Core Concurrent Manager
• Standard Manager
• WMS Task Archiving Manager
• Oracle Provisioning Manager

INVLIBR manages following Managers

• Inventory Manager

MRCLIB manages following Managers

• MRP Manager

PALIBR manages following Managers

• PA Streamline Manager

FNDSM The Generic Service Management Framework Process

• FNDSM is executable and core component in GSM ( Generic Service Management Framework discussed above). You start FNDSM services via application listener on all Nodes in Application Tier in E-Business Suite.

Concurrent Manager Scripts

Oracle supplies several useful scripts, (located in $FND_TOP/sql directory), for monitoring the concurrent managers:

afcmstat.sql	Displays all the defined managers, their maximum capacity, pids, and their status.
afimchk.sql	Displays the status of ICM and PMON method in effect, the ICM's log file, and determines if the concurrent manger monitor is running.
afcmcreq.sql	Displays the concurrent manager and the name of its log file that processed a request.
afrqwait.sql	Displays the requests that are pending, held, and scheduled.
afrqstat.sql	Displays of summary of concurrent request execution time and status since a particular date.
afqpmrid.sql	Displays the operating system process id of the FNDLIBR process based on a concurrent request id. The process id can then be used with the ORADEBUG utility.
afimlock.sql	Displays the process id, terminal, and process id that may be causing locks that the ICM and CRM are waiting to get. You should run this script if there are long delays when submitting jobs, or if you suspect the ICM is in a gridlock with another oracle process.

1.     Types Of Concurrent Managers and Concurrent Processes

Different Types of Concurrent Managers
===============================

Internal Concurrent Manager — The Internal Concurrent Manager (ICM) controls the other managers. It must be running before any other managers can be activated. The main functions of the ICM are to start up and shutdown the individual concurrent managers, and reset the other managers after one them has a failure.

Conflict Resolution Manager — The Conflict Resolution Manager (CRM) functions to check concurrent program definitions for incompatibility rules. However, the ICM can be configured to take over the CRM's job to resolve incompatibilities.

Standard Manager — The Standard Manager functions to run any reports and batch jobs that have not been defined to run in any specific product manager.

Product Specific Concurrent Manager — There are many product specific Concurrent Managers. The list includes Inventory, MRP, and Projects, as well as anyUser-defined managers. These managers are specialized to perform Concurrent Processing specifically for those products for which they are built. Utilizing these managers can help you off-load some of the processing from the

Scheduler Manager — Scheduler Manager, assists the ICM and the CRM in scheduling and conflict resolution.

Transaction Managers — A Transaction Manager is owned by an application and associated with a data group. Due to this association, and the fact that it runs immediate programs, the Transaction Manager can only run programs contained within its program Library.

Service Manager — Service Manager acts on behalf of the ICM, allowing the ICM to monitor and control service processes on that host. Services such as the Oracle Forms Listener, Oracle Reports Server, Apache Web listener, and Oracle Workflow Mailer can be run under Service Management. Generic Service Management (GSM) provides a fault tolerant system. If a service process exits unexpectedly, the ICM will automatically attempt to restart the process. If a host fails, the ICM may start the affected service processes on a secondary host. The ICM itself is monitored and kept alive by Internal Monitor processes located on various hosts.

The Internal Monitor — The IM is used in a PCP environment and monitors the Internal Concurrent Manager, and restarts any failed ICM on the local node. During a node failure in a PCP environment the IM will restart the ICM on a surviving node (multiple ICM's may be started on multiple nodes, but only the first ICM started will eventually remain active, all others will gracefully terminate). There should be an Internal Monitor defined on each node where the ICM may migrate.


Concurrent Manager Processes
=======================

FNDLIBR manages following Managers

Marketing Data Mining Manager
Transportation Manager
Session History Cleanup
UWQ Worklist Items Release for Crashed session
Collections Manager
OAM Metrics Collection Manager
Contracts Core Concurrent Manager
Standard Manager
WMS Task Archiving Manager
Oracle Provisioning Manager

INVLIBR is the process for the following Managers

Inventory Manager

MRCLIB is the process for the following Managers

MRP Manager

PALIBR is the process for the following Managers

PA Streamline Manager

FNDSM is the process for the Service Manager

We need to configure GSM and start the Apps Listener in order to start GSM Service on all Nodes in Application Tier in E-Business Suite.

Generic Service Management

Traditionally, application tier processes such as Forms listeners, HTTP servers, and concurrent managers had to be started and monitored individually by system administrators, a time-consuming and potentially error-prone exercise. With the transition to web-based applications, the number of application tier processes required for Oracle E-Business Suite products has increased significantly, with many Oracle E-Business Suite products making use of multiple application tier services to support one or more processes.

Service processes are similar to concurrent manager and transaction manager processes, and must be kept running on an application tier for the proper functioning of their associated products. Management of the services is complicated by the fact that they may be distributed across multiple host machines.

The Generic Service Management (GSM) feature simplifies management of these generic service processes, by providing a fault-tolerant framework with a central management console built into Oracle Applications Manager. With Generic Service Management, the Internal Concurrent Manager (ICM) manages the various service processes across multiple hosts. On each host, a Service Manager acts on behalf of the ICM, allowing the ICM to monitor and control service processes on that host.

System administrators can configure, monitor, and control services though Oracle Applications Manager, which communicates with the ICM. Generic Service Management provides a fault-tolerant system: if a service process exits unexpectedly, the ICM will automatically attempt to restart the process. If a host fails, the ICM may start the relevant service processes on a secondary host. The ICM itself is monitored and kept alive by Internal Monitor processes located on various hosts.

This new application tier service management infrastructure has several benefits:

• The service processes no longer need to be manually and individually started and monitored by Oracle E-Business Suite system administrators
• Administrators can configure and control the services through Oracle Applications Manager
• As with concurrent manager processes, system administrators can use work shifts to determine the number of processes that will be active for a service on a given node for a given time period
• Services can take advantage of the process distribution and fault tolerance capabilities that have been developed for concurrent processing

Generic Service Management is available out of the box with Oracle E-Business Suite Release 12, and can also be used with other AutoConfig-enabled releases.

Best Practices for Performance for Concurrent Managers in eBusiness Suite

Best Practices for Performance for Concurrent Managers in eBusiness Suite

This Document contains 3 topics:

1. Generic Tips

2. Transaction Manager (TM)

3. Parallel Concurrent Processing (PCP) Environment

Generic Tips

1) Sleep Seconds is the number of seconds your Concurrent manager waits between checking the list of pending concurrent requests (concurrent requests waiting to be started).

Tip: Set the sleep time to be very brief during periods when the number of requests submitted is expected to be high.  Otherwise set the sleep time to a high number (e.g. 2 minutes). This avoids constant polls to check for new requests.

2) Increase the cache size (number of requests cached) to at least twice the number of target processes.

For example, if a manager's work shift has 1 target process and a cache value of 3, it will read three requests, and try to run those three requests before reading any new requests.

Tip: Enter a value of 1 when defining a manager that runs long, time-consuming jobs, and a value of 3 or 4 for managers that run small, quick jobs.

3) Create Specilized concurrent managers to dedicate certain process either short or long running programs to avoid queue length.

4) To maximize throughput consider reducing the sleep time of the Conflict Resolution Manager (CRM).  The default value is 60 seconds. You can consider setting to 5 or 10 seconds.

5) Avoid enabling an excessive number of standard or specialized managers. It degrade the performance due polling on queue tables (FND_CONCURRENT_REQUESTS...). You need to create specialized managers only if there is a real need.

5) Set the system profile option "Concurrent: Force Local Output File Mode" to "Yes" if required. You need to apply patch 7530490 for R12 (or) 7834670 for 11i to get this profile.

Refer Note.822368.1 Purge Concurrent Request FNDCPPUR Does Not Delete Files From File System or Slow performance

Note:  This profile option "Concurrent: Force Local Output File Mode" is set to "No" by default. After applying the Patch, it set this profile option to YES will cause FNDCPPUR to always access files on the local file system. Hence FNDCPPUR will remove the OS files faster. To enable this feature, ALL Concurrent Manager nodes must be able to access the output file location via the local filesystem

6) Truncate the reports.log file in log directory.   Refer Note 844976.1 for more details

Truncation of file "reports.log" is a regular maintenance work of Application DBA. Make sure that reports log file size should not increase its maximum limit of 2 GB. There is no purge concurrent program to truncate file "reports.log". This maintenance needs to be done manually and regularly depending on number of concurrent program which uses "reports.log". You can safely truncate "reports.log".

7) Ensure "Purge Concurrent Request FNDCPPUR"  is run at regular interval with "Entity" parameter as "ALL".  High number of records in FND_CONCURRENT tables degrade the performance.

8) Ensure that it removes the log/out files from the below location as you run "Purge Concurrent Request".

 $APPLCSF/$APPLLOG

 $APPLCSF/$APPLOUT

8.1) Incase if it does not  remove the log/out files , Over a Period, It will slow down the performance.  Please refer below Note which suggests the patch which fixes it.

Note.822368.1  Purge Concurrent Request FNDCPPUR Does Not Delete Files From File System or Slow performance

9) Defragment the tables periodically to reclaim unused space / improve performance:

FND_CONCURRENT_REQUESTS

FND_CONCURRENT_PROCESSES

FND_CRM_HISTORY

FND_ENV_CONTEXT

FND_TEMP_FILES

How to defragment:

 9.1) alter table <owner>.<table_name> move;

 9.2) Note that, some indexes might become unusable after table is moved, check the index status from dba_indexes for the table moved and rebuild them too as explained in next bullet.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

select owner, index_name, status from dba_indexes

where table_owner = upper('&OWNER') and

table_name = upper('&SEGMENT_NAME');

Note: Please ensure the tablespace in which the object is currently existing, has sufficient space before you move/defragment.

Ensure to take necessary backup of the tables before moving the data. Its suggested to do it on test instance and test it before doing it on Production.

 9.3) You will need to collect the statistics for the tables.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

For example:

exec fnd_stats.gather_table_stats ('APPLSYS','FND_CONCURRENT_REQUESTS',PERCENT=>99);

Transaction Manager (TM)

10 ) Concurrent: Wait for Available TM – Total time to wait for a TM before switchover to next available TM.  Consider setting this to 1 (second).

11) Ensure enough TMs exist to service the incoming request load.

12) When the load is high, set the following profiles to optimum values to achieve better results.

 PO: Approval Timeout Value  -  Total time for workflow call (When initiated from Forms) to time out.

13)  Set the sleep time on the Transaction Manager to a high number (e.g. 10 minutes). This avoids constant polls to check for shutdown requests.

Parallel Concurrent Processing (PCP) Environment

14) Refer NOTE 551895.1 Failover Of Concurrent Manager Processes Takes More than 30 Minutes

15) Set profile option 'Concurrent: PCP Instance Check' to 'OFF' if instance-sensitive failover is not required. Setting it to 'ON' means that concurrent managers will fail over to a secondary application tier node if the database instance to which it is connected goes down.

16) ‘Concurrent: TM Transport Type' to ‘QUEUE',

17) Add these parameters depends on your Database version

                + _lm_global_posts=TRUE

                + _immediate_commit_propagation=TRUE  (11g RAC)

                + max_commit_propagation_delay=0  (9i RAC)

Best Practices for Performance for Concurrent Managers in eBusiness Suite

Best Practices for Performance for Concurrent Managers in eBusiness Suite

This Document contains 3 topics:

1. Generic Tips

2. Transaction Manager (TM)

3. Parallel Concurrent Processing (PCP) Environment

Generic Tips

1) Sleep Seconds is the number of seconds your Concurrent manager waits between checking the list of pending concurrent requests (concurrent requests waiting to be started).

Tip: Set the sleep time to be very brief during periods when the number of requests submitted is expected to be high.  Otherwise set the sleep time to a high number (e.g. 2 minutes). This avoids constant polls to check for new requests.

2) Increase the cache size (number of requests cached) to at least twice the number of target processes.

For example, if a manager's work shift has 1 target process and a cache value of 3, it will read three requests, and try to run those three requests before reading any new requests.

Tip: Enter a value of 1 when defining a manager that runs long, time-consuming jobs, and a value of 3 or 4 for managers that run small, quick jobs.

3) Create Specilized concurrent managers to dedicate certain process either short or long running programs to avoid queue length.

4) To maximize throughput consider reducing the sleep time of the Conflict Resolution Manager (CRM).  The default value is 60 seconds. You can consider setting to 5 or 10 seconds.

5) Avoid enabling an excessive number of standard or specialized managers. It degrade the performance due polling on queue tables (FND_CONCURRENT_REQUESTS...). You need to create specialized managers only if there is a real need.

5) Set the system profile option "Concurrent: Force Local Output File Mode" to "Yes" if required. You need to apply patch 7530490 for R12 (or) 7834670 for 11i to get this profile.

Refer Note.822368.1 Purge Concurrent Request FNDCPPUR Does Not Delete Files From File System or Slow performance

Note:  This profile option "Concurrent: Force Local Output File Mode" is set to "No" by default. After applying the Patch, it set this profile option to YES will cause FNDCPPUR to always access files on the local file system. Hence FNDCPPUR will remove the OS files faster. To enable this feature, ALL Concurrent Manager nodes must be able to access the output file location via the local filesystem

6) Truncate the reports.log file in log directory.   Refer Note 844976.1 for more details

Truncation of file "reports.log" is a regular maintenance work of Application DBA. Make sure that reports log file size should not increase its maximum limit of 2 GB. There is no purge concurrent program to truncate file "reports.log". This maintenance needs to be done manually and regularly depending on number of concurrent program which uses "reports.log". You can safely truncate "reports.log".

7) Ensure "Purge Concurrent Request FNDCPPUR"  is run at regular interval with "Entity" parameter as "ALL".  High number of records in FND_CONCURRENT tables degrade the performance.

8) Ensure that it removes the log/out files from the below location as you run "Purge Concurrent Request".

 $APPLCSF/$APPLLOG

 $APPLCSF/$APPLOUT

8.1) Incase if it does not  remove the log/out files , Over a Period, It will slow down the performance.  Please refer below Note which suggests the patch which fixes it.

Note.822368.1  Purge Concurrent Request FNDCPPUR Does Not Delete Files From File System or Slow performance

9) Defragment the tables periodically to reclaim unused space / improve performance:

FND_CONCURRENT_REQUESTS

FND_CONCURRENT_PROCESSES

FND_CRM_HISTORY

FND_ENV_CONTEXT

FND_TEMP_FILES

How to defragment:

 9.1) alter table <owner>.<table_name> move;

 9.2) Note that, some indexes might become unusable after table is moved, check the index status from dba_indexes for the table moved and rebuild them too as explained in next bullet.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

select owner, index_name, status from dba_indexes

where table_owner = upper('&OWNER') and

table_name = upper('&SEGMENT_NAME');

Note: Please ensure the tablespace in which the object is currently existing, has sufficient space before you move/defragment.

Ensure to take necessary backup of the tables before moving the data. Its suggested to do it on test instance and test it before doing it on Production.

 9.3) You will need to collect the statistics for the tables.
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->

For example:

exec fnd_stats.gather_table_stats ('APPLSYS','FND_CONCURRENT_REQUESTS',PERCENT=>99);

Transaction Manager (TM)

10 ) Concurrent: Wait for Available TM – Total time to wait for a TM before switchover to next available TM.  Consider setting this to 1 (second).

11) Ensure enough TMs exist to service the incoming request load.

12) When the load is high, set the following profiles to optimum values to achieve better results.

 PO: Approval Timeout Value  -  Total time for workflow call (When initiated from Forms) to time out.

13)  Set the sleep time on the Transaction Manager to a high number (e.g. 10 minutes). This avoids constant polls to check for shutdown requests.

Parallel Concurrent Processing (PCP) Environment

14) Refer NOTE 551895.1 Failover Of Concurrent Manager Processes Takes More than 30 Minutes

15) Set profile option 'Concurrent: PCP Instance Check' to 'OFF' if instance-sensitive failover is not required. Setting it to 'ON' means that concurrent managers will fail over to a secondary application tier node if the database instance to which it is connected goes down.

16) ‘Concurrent: TM Transport Type' to ‘QUEUE',

17) Add these parameters depends on your Database version

                + _lm_global_posts=TRUE

                + _immediate_commit_propagation=TRUE  (11g RAC)

                + max_commit_propagation_delay=0  (9i RAC)

rajesh

hi
this is my newly created blog