Expert
Q: | |
25-39. | As we’ve seen, the REMOVE procedure doesn’t stop a running job; you need, instead, to use the ALTER SYSTEM KILL SESSION command, which requires two parameters: the SID of the job you want to kill and the job’s serial number. You can find the SID in the DBA_JOBS_RUNNING view, and the job’s serial number in the V$SESSION view: SELECT r.job,
r.sid,
s.serial#
FROM dba_jobs_running r,
v$session s
WHERE r.sid = s.sid
AND r.job = 47;
JOB SID SERIAL#
--------- --------- ---------
47 7 3The next step is to mark the job broken to prevent future execution: DBMS_JOB.BROKEN( 47, TRUE); COMMIT; Finally, issue the KILL command: ALTER SYSTEM KILL SESSION '7,3'; |
Q: | |
25-40. |
|
Q: | |
25-41. | We have: next_date IN VARCHAR2, in ISUBMIT and: next_date IN DATE DEFAULT sysdate, in SUBMIT. Since this makes no sense, it’s probably just somebody’s mistake during the creation of the DBMS_JOB package. What is really strange, however, is that this mistake migrates from version to version without changes, which causes two problems. The first is that since the next_date parameter doesn’t have a default value, you can’t omit the parameter in the ISUBMIT procedure. The second is that when you use an NLS_DATE_FORMAT different from the current default for the database instance, the ISUBMIT procedure truncates next_date to the beginning of the ... |
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access