Skip to main content

How to Find Database Session (SID) & Process Associated with a Concurrent Program Which is Currently Running

Concurrent Processing - How to Find Database Session & Process Associated with a Concurrent Program Which is Currently Running

Goal

1. How to find database session and process associated with a concurrent program which is currently running.
2. How to cancel a concurrent request from database side.

Solution

A concurrent program can be canceled either from "Submit Request Submission" form or from database side also. In case of custom concurrent programs, sometimes concurrent program do not release database session and process even though it has canceled from "Submit Request Submission" form. Active database process can be seen in running status. In those cases there is a need to manually kill those process to release CPU memory.

1. Take the "request_id" of a Concurrent Program which is currently running or which is to be canceled from the database side.

2. Connect to SQLPLUS as APPS User :
SQL> SELECT ses.sid,
ses.serial#
FROM v$session ses,
v$process pro
WHERE ses.paddr = pro.addr
AND pro.spid IN (SELECT oracle_process_id
FROM fnd_concurrent_requests
WHERE request_id = &request_id);
Note : oracle_process_id is Unix PID and request_id is running concurrent program's request ID. If "sid" and "serial#" value is returning then it means that process is running at database level. When canceling a request from the "Submit Request Submission" form, then it should release associated database process and session but it doesn't mean that it will kill database process immediately. Database process will take their own time to validate concurrent program execution process that has been canceled and then it will kill database process. So ideally when canceling a request from "Submit Request Submission", wait for some time and then check associated database process.

3. Connect to SQLPLUS as the SYSTEM user:
SQL> ALTER SYSTEM KILL SESSION 'sid,serial#';
Note the "sid" and "serial#" value returned from step 1.

Comments

Post a Comment

Popular posts from this blog

EBS Standby Role Tranistion using standby database and standby application Tier

 Role Transitions A database can operate in either a primary or standby role - these roles are mutually exclusive. Oracle Data Guard enables you to change these roles dynamically by issuing SQL commands, and supports the following transitions: Switchover Allows the primary database to switch roles with one of its standby databases. There is no data loss during a switchover. After a switchover, each database continues to participate in the Oracle Data Guard configuration with its new role. Failover Changes a standby database to the primary role in response to a primary database failure. The following role transitions are discussed: 6.1 Performing a Switchover 6.2 Performing a Failover 6.3 Performing a Switchback to the Primary Following A Switchover/Failover Each of these three transitions requires some application configuration to be performed. Most of the application configuration step...
1 comment
Read more

How To Create LVM Using vgcreate in Linux

Logical Volume Management (LVM) creates a layer of abstraction over physical storage, allowing you to create logical storage volumes. With LVM in place, you are not bothered with physical disk sizes because the hardware storage is hidden from the software so it can be resized and moved without stopping applications or unmounting file systems. You can think of LVM as dynamic partitions. For example, if you are running out of disk space on your server, you can just add another disk and extend the logical volume on the fly. Below are some advantages of using Logical volumes over using physical storage directly: •Resize storage pools: You can extend the logical space as well as reduce it without reformatting the disks. •Flexible storage capacity: You can add more space by adding more disks and adding them to the pool of physical storage, thus you have a flexible storage capacity. •Use of striped, mirrored and snapshot volumes: Striped logical volume that stripes data across two or ...
Post a Comment
Read more
TRANSPARENT APPLICATION FAILOVER FOR RAC RAC provides near-continuous availability by hiding failures from end-user clients and application server clients. This provides continuous, uninterrupted data access. Transparent Application Failover (TAF) is what applications use to sync up with Oracle RAC availability. TAF in the database reroutes application clients to an available database node in the cluster when the connected node fails. Application clients do not see error messages describing loss of service. if the users connection to Node 1 dies, their transaction is rolled back but they can continue work without having to manually reconnect. To get a good understanding of how the TAF architecture works, it is helpful to walk through a failover scenario where a user is querying the database to retrieve 1000 rows from the database. Assume that the user is connected to Node 1/ Instance 1. 1.      The heartbeat mechanism between the various nodes...
Post a Comment
Read more