Perform a remote update Job, discover the old newspaper "Waiting for INSERT_GZ_CALLCENTRE_DATA Unlock" timeout error, then view User_Jobs: Select Job from users User_JOBS;
Job ---------- 80 81 75
View DBA_JOBS_RUNNING Table: SID JOB FAILURES LAST_DATE LAST_SEC this_date ----------------------------------- - ----------------------------------------- ----- 7 67
8 68
49 72
The above 67, 68, 72 is a task that has been deleted, but actually is still running, thereby initially estimating the problem of deadlock. The solution is as follows: First go to the V $ SESSION view to find the SID 7,8,49 session information: SILECT SID, PADDR, STATUS, USERNAME FROM V $ session where sID = 7;
7, A60C8C, Active, Greatwall
Username and executive Job are consistent, it is determined that the user, find the V $ process view, find the corresponding background process: SELECT SPID from V $ process where addr = 'a60c8c';
Then kill the process:
Kill SPID; It is possible to kill on Linux, use Kill -9 SPID; use PS-EF | GREP ORACLE, where Oracle is the user to view the process is still (check the value of PID)
Note: There is also a method of ending a session: Alter System Kill Session 'SID, Serial #', however, these session becomes killed, then slowly cleared by the PMON process, this time is not unlocked So when I use this method, I found the session status of the V $ Session into Killed, but I want to try the same fault when INSERT_GZ_CALLCENTRE_DATA is deleted.
If Oracle is installed under Windows, you can use orakill to kill.
Another medium ideas: Query V $ locked_Object; then use the obtained object_id to DBA_Objects to find Object_name, see if it is Job, if so, prove that Job is dead lock, use the session_id in v $ locked_Object to kill the process.
- Used to query the background Select Rawtohex (Paddr) Paddr_hex, Name from V $ BGPROCESSWHERE RAWTOHEX (PADDR) <> hextoraw (0) and name like 'snp%';
