Database Reference
In-Depth Information
------------------------------
PERFSTAT
SQL> EXEC sys.dbms_ijob.remove(29)
PL/SQL procedure successfully completed.
SQL> COMMIT;
Commit complete.
RUN Procedure
This procedure may be used to run jobs in any schema, irrespective of their status (
BROKEN=
Y/N
). The job is run by the foreground process of the user executing
DBMS_IJOB
instead of by a
job queue process. This facilitates troubleshooting or performance diagnosis of the job, since
the session to trace or monitor is known.
DBA_JOBS.NEXT_DATE
is recalculated.
Syntax
DBMS_IJOB.RUN(
job IN BINARY_INTEGER,
force IN BOOLEAN DEFAULT FALSE);
Parameters
Parameter
Description
job
Job number
force
If
TRUE
,
DBMS_IJOB.RUN
ignores the instance affinity setting of the job
specified with the parameters
INSTANCE
and
FORCE=TRUE
to
DBMS_JOB.SUBMIT
.
If
FORCE=TRUE
when calling
DBMS_IJOB.RUN
, then the job may be run in any
instance, thereby ignoring instance affinity.
Usage Notes
In a scenario where a database user approaches a DBA and asks the DBA to diagnose a failing
job, the DBA would normally need to start a database session as the owner of the job to repro-
duce the problem. Using
DBMS_IJOB
, the DBA can run and diagnose the job without knowing
the password of the job owner or asking the job owner to log him in.
Contrary to the Oracle10
g
scheduler (
DBMS_SCHEDULER
), which records the reason for a job's
failure in the data dictionary view
DBA_SCHEDULER_JOB_RUN_DETAILS
, the
DBMS_JOB
job queue
does not record errors from job runs in the database. Errors from failed
DBMS_JOB
jobs are recorded
in job queue slave process trace files in the background dump destination (parameter
BACKGROUND_
DUMP_DEST
). Job developers are expected to implement their own error logging. Three undocu-
mented PL/SQL metadata variables are available to
DBMS_JOB
jobs. Their variable names, data
types, and descriptions are provided in Table 18-1.
