You can check the status of a job in dba_jobs.broken column (Y/N). If the job is currently running you can follow above advise and kill its process then remove the job.
SQL> exec dbms_job.broken(<job_id>, TRUE); SQL> commit;
Paul G. Matuszyk wrote:And I questioned the validity of your answer as IMO it is a bad hack that should not be considered.
I am answering questions and not asking another one - if you want to ask if it is more secure start a new thread. Original question was how to remove it - i gave the answer.
Max Seleznev wrote:So opening a giant security hole, allowing a user or application schema to execute a job as sys, with the ability to do anything, is not wrong?
There is nothing wrong with using DBMS_IJOB package as Paul suggested. It saves a lot of time if the job is in another schema.
Max Seleznev wrote:Being fired after a disciplinary because you've opened a security hole that was exploited, is a lot worse... don't you think? ;-)
That's a pretty strong wording.
Nowhere in OP post or in the reply it says that any privileges have to be granted to anyone. There is a good chance OP already has DBA privileges or can connect as sys.It is about security principles. Neither you or Paul mentioned the security issues that goes with using this system package. Someone (even the OP perhaps) is bound to interpret this as being a kewl package to use, better that just plain old DBMS_JOB, and then proceed to create and open barn doors in the security of that database. Not realising the implications of exposing system packages to user land applications and code.
Besides there're situations when one has no other choice than to use DBMS_IJOB package because of its unique functionality.That is why one write wrappers - to provide this type of functionality, but in a secure and controlled fashion.