Tuesday 6 December 2016

concurrent manager related questions?

concurrent managers


1: What is concurrent manager?
Ans:

(I) When an Oracle Applications user submits a request to run a program, it's called concurrent request.
Concurrent manager are the programs, which are responsible for running the concurrent requests. When a user submits a report to be run as a concurrent request, the job enters in a request queue. Concurrent managers continously read request from this master queue and run the requests based on the request's schedule, priority, and compatibility rules. Concurrent managers run in background and they take care of initiating and completing the concurrent requests.

(I) When an Oracle Applications user submits a request to run a program, it's called concurrent request.
(2) When a user submits a report to be run as a concurrent request, the job enters in a request queue
(3) Concurrent managers continuously read request from this master queue and run the requests based on the request's schedule
(4)  and compatibility rules. Concurrent managers run background and they take care of initiating and completing the concurrent requests.


2: What are the different types of concurrent manager?
Ans:

Oracle Applications consist of several types of concurrent managers.
(1) The important ones are internal concurrent manager (icm)
(2)  standard concurrent manager
(3) and conflict resolution manager. (crm)
Apart from these, you can define your own custom concurrent manager.


3: What is an internal concurrent manager?
Ans:

(1)The internal manager is the one which is responsible for controlling all other concurrent managers.
(2)Its main task is to ensure that all other concurrent managers are up and running.
(3)The internal concurrent manager starts, sets the number of active processes, monitors and terminates all other concurrent (4)processes through requests made to the service manager, including restarting and failed processes.
(5)The internal concurrent manager also starts and stops, and restarts the service manager for each node.


4: What is conflict resolution manager?
Ans:

(1)The conflict resolution manager takes care of resolving the program incompatibilities and checks if a request in queue
(2)can be run in parallel with the running request.
(3) It also takes care of resolving the program incompatibilities.
(4) If a program is identified as run alone,
(5)then the conflict resolution manager prevents the concurrent managers from starting other programs in the same conflict domain.
(6)When a program lists other programs as being incompatible with it,
(7) the conflict resolution manager prevents the program from starting until any incompatible programs in the same domain have completed running.


5: What is a standard manager?
Ans:

(1)The standard manager is the master concurrent manager.
(2) This manager is always running and it can take care of processing any concurrent request.
(3)It has no specialization rules.
(4)This manager runs 24 hours a day for the whole year.
(5)The definition of this manager should never be altered.
(6)In case if you alter the definition of the standard manager and you have not defined additional managers to run your requests, some of the programs may not run in a proper way.


6: How do I enable/disable the conflict resolution manager?
Ans:

(1)This is a system profile option "Concurrent: Use ICM".
(2) The default value of this profile option is No which allows the conflict resolution manager to be started.
(3)Setting the same to Yes will cause the conflict resolution manager to be shutdown and the internal concurrent manager will take care of the conflict resolution duties.
(4)Using the internal concurrent manager to resolve the conflicts is not recommended.


7: What are the different ways to stop concurrent manager?
Ans:

(1)Concurrent manager can be stopped using the script adcmctl.sh. It can also be stopped using the Concsub utility.
(2)From the operating system, the concurrent manager can be stopped by querying the FNDLIBR process and killing the same.


8: What are the different ways to start concurrent manager?
Ans:

Concurrent manager can be started using the script adcmctl.sh located at the locations of the scripts or with the startmgr utility located at $FND_TOP/bin.


9: In administer concurrent manager form there are two columns labelled as actual and target. What are these columns and what is the thier significance?
Ans:

(1)Target column lists the number of processes that should be running for each manager for this particular workshift.
(2)Actual column lists the number of processes that are actually running.
(3) If the actual column is zero, there are no processes running for this manager.
(4)If the target column is zero, then either a workshift has not been assigned to this manager,
(5)or the current workshift does not specify any target processes. If the target column is not zero, then the manager processes have either failed to start up, or has gone down.


10: How do I run/schedule a concurrent request from operating system level without logging into the applications?
Ans:

A concurrent request can be scheduled/run from the operating system using the CONCSUB utility. CONCSUB means Concurrent Submit.


11: What are the different ways to check if concurrent manager (CM) is running or not?
Ans:

There are a couple of ways through which one can check if the CM is running or not. From the operating system, it can be checked by querying the FNDLIBR process. From the forms, it can be checked from the Navigation > Concurrent > Manager > Administer. It can be also checked using the scripts adcmctl.sh status and finally it can also be checked from Oracle Applications Manager.



12: What is the default location of the concurrent manager logfiles?
Ans:

The concurrent manager log files can be located in one of the following places:
(i) If the environment variable $APPLCSF is set, the default location is $APPLCSF/$APPLLOG.
(ii) If the environment variable $APPLCSF is not set, the logs go to $FND_TOP/$APPLLOG.



13: I have submitted a request and it's showing the status inactive/no manager. Concurrent manager is up and running and the request are being picked after some time. What could be the reason for the same?
Ans:

If the concurrent manager is up and running and the request goes to the status inactive/no manager for some time it means that cache cycle is less. Cache size is set on the Concurrent> Manager> Define form. Basically, this regulates how many requests a manager will pick up for each sleep cycle. The solution is either to increase the cache size of the manager or increase the actual number of the manager process. The manager could be standard manager or any other manager for which the issue is coming.


14: I have submitted a request, it has gone to pending standby status for a long time whereas other requests are getting completed normally without any issues. What could be the reasons?
Ans:

If any particular request is going to pending standby status and others are getting completed, it means that either it is waiting for the output of some other request or is conflicting with some other request. If the request is conflicting, check the queue of the conflict resolution manager for troubleshooting.


15: How do I process more concurrent requests in parallel?
Ans:

If you want to process more requests simultaneously, there are two ways for the same-one, increase the number of the target process for the manager and second, change the cache size of the concurrent manager.



16: When do the tables FND_CONCURRENT_REQUESTS and FND_CONCURRENT_PROCESS need to be purged?
Ans:

When the tables reach 20,000 rows, the performance begins to diminish. You may want to run purge concurrent request on a regular basis, depending on the amount of requests being run.


17: What are the concurrent request log file and output file naming conventions?
Ans:

Request log files: l<request id>.req

Output files: If $APPCPNAM is not set: <username>.<request id>

If $APPCPNAM = REQID: o<request id>.out

If $APPCPNAM = USER: <username>.out

Where: <request id> = The request id of the concurrent request

And: <username> = The id of the user that submitted the request

Manager log files:

ICM log file: Default is std.mgr, can be changed with the mgrname startup parameter

Concurrent manager log: w<XXXXXX>.mgr

Transaction manager log: t<XXXXXX>.mgr

Conflict Resolution manager log: c<XXXXXX>.mgr

Where: <XXXXXX> is the concurrent process id of the manager.



18: What happens when the internal concurrent manager dies? Are all the managers also killed immediately after it?
Ans:

No, if the internal manager dies, the request continues to run normally except for queue control requests.



19: Does the internal manager run or schedule any request for itself?
Ans:

No, the internal manager does not run or schedule any requests. It has nothing to do with scheduling requests, or deciding which manager will run a particular request. Its function is only to run 'queue control' requests, which are requests to startup or shutdown other managers. It is responsible for startup and shutdown of the whole concurrent processing facility, and it also monitors the other managers periodically, and restarts them if they should go down. It can also take over the conflict resolution manager's job, and resolve incompatibilities.


20: If the internal manager goes down, do I need to kill all the managers before restarting the internal manager?
Ans:

No, if the internal manager goes down you need not kill all the managers. You can simply start the internal manager using startmgr.


21: Can I delete concurrent manager?
Ans:

Yes, you can delete any concurrent manager. For deleting, query for the manager in the defined concurrent manager form and then delete the row.

Deleting the predefined concurrent managers is not recommended and it should never be done. Deletion may cause instability in the system.


22: What is internal monitor?
Ans:

This manager is used to implement parallel concurrent processing. It monitors whether the ICM is still running, and if the ICM crashes, it will restart in another node.


23: How do I clean out concurrent manager tables?
Ans:

For cleaning concurrent manager tables, Oracle provides a script called cmclean.sql.


24: I hit the restart button to start the standard manager but it still doesn't start?
Ans:

Asking a manager to restart sets the status to restart. The internal concurrent manager will start in the next process monitor session or the next time internal concurrent manager starts. Use activate, to start a manager immediately. Also, when a manager is deactivated manually, the internal concurrent manager will not restart it. You will need to set it to restart, or activate it manually.


25: I tried to stop the concurrent manager using the script adcmctl.sh. I can still see from the operating system that a few FNDLIBR processes are still running and adcmctl.sh is not able to stop the concurrent manager completely. What do I do in this situation?
Ans:

If you are not able to stop the concurrent manager using the script, query for the FNDLIBR process using the command


ps -ef | grep FNDLIBR


And then kill the process using the command


Kill -9 <process id>


If there are more than one process of the FNDLIBR, you can kill all of them in one go using the command


Ps -ef | grep FNDLIBR | awk '{ print $2}' | xargs kill -9


26: What are the circumstances in which you need to bounce the concurrent manager?
Ans:

The following are the situations in which one may need to bounce the concurrent manager.
- When you modify the definition of the printers
- When you modify the environment variables. Say you have changed the APPLTMP and APPLPTMP variable.
- When all the requests are pending and hanging


27: What are the reasons a concurrent manager hangs?
Ans:

The concurrent manager hangs due to many reasons. A few of them are:
- Long running jobs
- The internal manager was activated by someone other then owner of the application system
- The operating system files system is full
- It's not able to create the log file
- You've shut down the internal manager, but actual has a number in it
- The database is hanging may be because the archive log files have filled
- Pending/standby requests are too many

28: How can you stop concurrent manager using the CONSCUB utility?
Ans:

Concurrent manager can be stopped using the CONSCUB utility by the following command:

CONCSUB apps/apps@<dbname> SYSADMIN 'System Administrator' SYSADMIN CONCURRENT FND SHUTDOWN


29: What are the different parameters of the startmgr utility?
Ans:

The parameters of the startmgr utility:


Parameter: sysmgr
Description: Sqlplus username/password that owns the foundation tables
Default: Applsys/<passwd>



Parameter: Mgrname
Description: The name of the Manager
Default: Internal Manager




Parameter: Log file
Description: The log file of the Manager
Default:
$FND_TOP/$APPLLOG/$mgrname.mgr
or
$APPLCSF/$APPLLOG/$mgrname.mgr




Parameter: Sleep
Description: The number of seconds the ICM should wait before checking new request from the table FND_CONCURRENT_REQUESTS
Default: 60 seconds




Parameter: Restart
Description: If the CM goes down abnormally, it will automatically restart the manager. Y = the number of minutes the ICM waits before restarting the manager
Default: N=not to restart after abnormal termination



Parameter: mailto
Description: MAILTO is a list of users who should receive mail whenever the manager terminates
Default: Current user




Parameter: printer
Description: The default printer for sending the output files
Default:




Parameter: diag
Description: This is used for diagnosis. If the CM is started with the parameter diag=y then full diagnostic output is produced in the log file
Default: N




Parameter: Pmon
Description: The number of sleep cycles ICM will wait before checking failed managers
Default: 20


Parameter: Quesiz
Description: Number of pmon cycles the ICM waits between times it checks for normal changes in concurrent manager operation. Normal changes include the start or end of a work shift and changes to the concurrent manager definitions entered in the Define Concurrent Manager form. (Default 1)
Default: 1

30: What exactly happens when a concurrent request is submitted?
Ans:

Once a concurrent request is submitted by the user, the table FND_CONCURRENT_REQUESTS is automatically updated with the details of the request. The table is also updated with the information about the schedule of the concurrent request whether it's immediately scheduled or scheduled at a fixed fixed time. Once the request is scheduled to run the concurrent manager checks the FND_CONCURRENT_REQUESTS table to find out if the request is incompatible with any other request. If the request is incompatible then the conflict resolution manager takes care of the request and finds out what are the incompatibilities, it's checked whether any special manager is there to take care of this request. If there is any special manager to take care of this request then it goes to the queue of that manager else the standard manager takes care of the same. Once the request is processed, the FND_CONCURRENT_REQUESTS table is updated with the status.

31: In the administer concurrent manager form, what is the significance of the terminate button?
Ans:

The terminate button is used to terminate any concurrent manager. When you terminate internal manager, all the managers automatically get deactivated and all the running requests are terminated. If you want to terminate a particular manager, select the manager and click the terminate button. The status of the manager changes to deactivate after a few seconds and all the requests processed by that manager are immediately terminated. Once a manager is terminated, it doesn't restart automatically. You have to manually restart it using the restart button.


32: In administer concurrent manager form, what is the significance of the deactive button and how can you deactivate a manager from there?
Ans:

For deactivating a particular manager, select the manager and press the deactivate button. In case of deactivation, all the requests processed by the manager are allowed to complete before the manager shuts down. If you deactivated the internal manager, all the managers automatically get deactivated but all the running requests are allowed to complete before the manager is shut down. This is the only difference between termination and deactivation. In termination, all the running requests are terminated immediately whereas in case of deactivation all the running requests are allowed to complete first.


33: In administer concurrent manager form, what is the significance of the verify button and for which manager's it's available?
Ans:

The verify button becomes enable only when you select the internal manager. One of the functions of the internal manager is to monitor the processes of each concurrent manager. The process of monitoring the other concurrent manager by internal manager is known as the PMON cycle. When you click the verify button you can force the process monitoring or the PMON activity to occur. The verify button is also available for the conflict resolution manager which checks for the program incompatibilities.


34: What is parallel concurrent processing and what is the significance of the same?
Ans:

Parallel concurrent processing is the way to distribute concurrent managers across multiple nodes in a cluster, massively parallel, or networked environment. It helps in distributing the load across multiple nodes thereby fully utilizing the hardware resource.

The following are the advantages of the parallel concurrent processing.

Load Distribution:
Since the concurrent processing is distributed among multiple servers, as a result the load is distributed across various nodes which results in high performance.

Fault Tolerance:
When a node fails, the concurrent processes continues to run on other nodes, as a result the work is not hampered.


Single Point of Control:
The ability to administer concurrent managers running on multiple nodes from any node in a cluster, massively parallel, or networked environment.


35: Explain briefly how concurrent processing works?
Ans:

In case of parallel concurrent processing, all the managers are assigned a primary and a secondary node. The managers are started in their primary node by default. In case of node failure or Oracle instance failure, all the concurrent managers on that node are switched to their secondary nodes. Once the primary node is available again the concurrent managers on the secondary nodes are migrated back to the primary node. During the migration process, a manager may be spread across both primary and secondary nodes.

In case of parallel concurrent processing, it may happen that in a node where parallel concurrent processing is configured, the Oracle instance may or may not be running. The node which is not running Oracle, the concurrent managers connects via Net8 to a node which is running Oracle.


The internal concurrent manager can run on any node, and can activate and deactivate concurrent managers on all nodes. Since the internal concurrent manager must be active at all times, it needs high fault tolerance. To provide this fault tolerance, parallel concurrent processing uses internal monitor processes. The job of the internal monitor process is to constantly monitor the internal manager and start it when it fails. Only one internal monitor process can be active on a single node. You decide which nodes have an internal monitor process when you configure your system. You can also assign each internal monitor process a primary and a secondary node to ensure fail over protection. Internal monitor processes, like concurrent managers, can be assigned work shifts, and are activated and deactivated by the internal concurrent manager.

The concurrent log and output files from requests that run on any node are accessible online from any other node. Users need not log onto a node to view the log and output files from requests running on that node.



36: Where can I define the primary and the secondary nodes for the concurrent manager form?
Ans:

For defining the primary and secondary nodes of each manager, you need to launch forms with system administer and need to navigate the Concurrent > Manager > Define form. Query for the manager in which you want to define the primary and secondary node. In this screen, put the values for the primary and the secondary nodes and save.


37: I have defined for nodes of the concurrent manager. Now do I need to start the concurrent manager from all the nodes?
Ans:

No, even if you have defined the concurrent manager in four different nodes you need not start the concurrent manager from all the nodes. You just need to start the concurrent manager from the primary node and GSM takes care of starting the concurrent manager from all the other nodes.


38: My requests are making error out with the error-unable to create temporary files xxxxx.tmp. How do I fix it?
Ans:

This issue normally comes if the values of $APPLTMP, $APPLPTMP in the APPL_TOP and the utl_file_dir parameter of the database are not in sync. All the three variables should be exactly the same. If these issues come, change the values in the APPSORA.env, you need to bounce the concurrent manager for the changes to get effected. In case if you change the values of the init.ora, you need to bounce the database to reflect the changes. (Of course you need to bounce the application tier also if you are bouncing the database.)


39: The user comes to you saying that the request is taking a lot of time to complete. What will be your approach for debugging it?
Ans:

You can do the following to debug the same.
- You can run a trace on the request id to find the expensive sql's and then tell the developer to fix the same.
- You can check the program incompatibilities in the concurrent request.
- You can check the query which the concurrent program is executing and see if it is creating any locks in the database.
- Many times the users schedule the request to run at a later time.

You can check the parameters with which the request is run. (For example, once a user came saying the request is not printing the output. On Checking the possible things, it was realized that he scheduled the request with print copies = 0.)



40: How can you know which trace file is created for the particular request?
Ans:

You can find out the same using the script given below. The trace will be located in the udump location of the database server.


prompt
accept request prompt 'Please enter the concurrent request id for the appropriate concurrent program:'
prompt
column traceid format a8
column tracename format a80
column user_concurrent_program_name format a40
column execname format a15
column enable_trace format a12
set lines 80
set pages 22
set head off

SELECT 'Request id: '||request_id, 'Trace id: '||oracle_Process_id, 'Trace flag: '||req.enable_trace, 'Trace Name: '||dest.value||' '||lower(dbnm.value)||'_ora_'||oracle_process_id||'.trc', 'Prog. Name: '||prog.user_concurrent_program_name, 'File name: '||execname.execution_file_name||execname.subroutine_name , 'Status :'||decode(phase_code, 'R', 'Running')||' '||'-'||decode(status_code, 'R', 'Normal'), "SID Serial: "||ses.sid||" , "||ses.serial#, "Module : "||ses.module
from fnd_concurrent_requests req,
v$session ses, v$process proc,
v$parameter dest, v$parameter dbnm,
fnd_concurrent_programs_v1 prog,
fnd_executables execname
where req.request_id = &request
and req.oracle_process_id=proc.spid(+)
and proc.addr = ses.paddr(+)
and dest.name='user_dump_dest'
and dbnm.name='db_name'
and req.concurrent_program_id =
prog.concurrent_program_id
and req.program_application_id =
prog.application_id
and prog.application_id =
execname.application_id
and
prog.executable_id=execname.executable_id;

41: What are the things that need to be taken care when you define a concurrent program?
Ans:

When defining a concurrent program the following things need to be taken care.
- Selecting an executable file to run the program
- Choosing the execution method for the program (when defining your executable in define concurrent program executable)
- Defining parameters for the program, if any
- Defining printing information
- Specifying any incompatible program that must not run while the program runs
- Choosing whether to allow users to run this report from the run reports form or from within a form. If the latter option is chosen, the form from which you want to kick-off your program needs to be modified. If the first option is chosen, the program needs to be added to a report security group.

42: How do you schedule concurrent requests?
Ans:

For scheduling the concurrent requests, you need to click the schedule button while submitting the request. The concurrent program can be scheduled only once, periodically or on some specific days. You can also save this schedule for future reference and can use the same schedule for a different concurrent program by using the option apply a saved schedule. If you don't schedule the request then by default the concurrent requests are submitted immediately.


43: What does the completion option mean at the time of submitting a request?
Ans:

The completion option refers to what Oracle Applications will do once the request is completed. It can notify people via email, can save the output in a file, can take a print out of the same or simply won't do anything.


44: What is a work shift?
Ans:

The work shift defines the time for which the concurrent manager is active. You can define some fixed date or time for manager or can make the manager run 24*7 making it active all the times. The work shifts are defined by using the work shift form from the following navigation > Concurrent > Manager > Work Shifts.


45: What are the important scripts related to the concurrent managers and what are their locations?
Ans:

The following SQL scripts located under $FND_TOP/sql are useful when diagnosing concurrent manager problems.

(i) afimchk.sql: Informs about the status of the ICM and PMON method.

(ii) afcmstat.sql: Lists active manager processes.

(iii) afrqrun.sql: Lists all the running, waiting and terminating requests.

(iv) afrwait.sql: Lists requests that are constrained and waiting for the ICM to release them.

(v) afrqscm.sql: Prints log file name of managers that can run a given request. It can be used to check for possible errors when a request stays in pending status. It requires a request id value.

(vi) afcmcreq.sql: Prints the log file name of the manager that processed the request.

(vii) afrqstat.sql: Summary of completed concurrent requests grouped by completion status and execution type. It requires number of days prior to the current date, when to report parameter.

(viii) afimlock.sql: Lists locks that the internal concurrent manager is waiting to get.

(ix) afcmrrq.sql: Lists managers that currently are running a request.


46: What are the things you need to check if you are not able to view the logs of the concurrent manager?
Ans:

- You need to cross check the TNS entries.
- You need to check the DBC file.
- You need to check if the Apache/Jserv is running properly.
- You need to check if the connect descriptor is correct.

No comments:

Post a Comment