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         3

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

You’ll find a suggested procedure in the runjob.sp file on the book’s web page.

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

Get Oracle PL/SQL Programming: A Developer's Workbook now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.