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

Popular posts from this blog

19c ORACLE HOME Cloning -Linux/Solaris

  Cloning an Oracle home involves creating a copy of the Oracle home and then configuring it for a new environment. If you are performing multiple Oracle Database installations, then you may want to use cloning to create each Oracle home, because copying files from an existing Oracle Database installation takes less time than creating a new version of them. This method is also useful if the Oracle home that you are cloning has had patches applied to it. When you clone the Oracle home, the new Oracle home has the patch updates which is already applied on oracle home. Steps to clone an Oracle home step 1 : Stop Services Stop all processes related to the Oracle home. Step 2 : Create a ZIP or TAR file with the Oracle home (/u01/app/oracle/product/19.0.0/dbhome_1)    Use ROOT user for ZIP and UNZIP  # zip -r dbhome_1.zip /u01/app/oracle/product/19.0.0/dbhome_1 TAR option: # tar -cvf dbhome_1.tar /u01/app/oracle/product/19.0.0/dbhome_1 Step 3: s cp zip/tar to target s...

EBS R12.2.4 AutoConfig could not successfully execute the following scripts followed by error "txkGenADOPWrapper.pl INSTE8_APPLY 1"

issue:txkGenADOPWrapper.pl    INSTE8_APPLY       1 WARNING: [AutoConfig Error Report] The following report lists errors AutoConfig encountered during each phase of its execution.  Errors are grouped by directory and phase. The report format is:       <filename>  <phase>  <return code where appropriate>   [APPLY PHASE]   AutoConfig could not successfully execute the following scripts:     Directory: /u01/applprod/fs2/FMW_Home/webtier/perl/bin/perl -I /u01/applprod/fs2/FMW_Home/webtier/perl/lib/5.10.0 -I /u01/applprod/fs2/FMW_Home/webtier/perl/lib/site_perl/5.10.0 -I /u01/applprod/fs2/EBSapps/appl/au/12.0.0/perl -I /u01/applprod/fs2/FMW_Home/webtier/ohs/mod_perl/lib/site_perl/5.10.0/x86_64-linux-thread-multi /u01/applprod/fs2/inst/apps/PRODDB_epc-apps12-node41v/admin/install       txkGenADOPWrapper.pl    ...

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...