DBMS_SCHEDULER.DROP_JOB solo se esiste

Ci sono due modelli principali che puoi applicare alla gestione delle eccezioni; "guarda prima di saltare" (LBYL) e "è più facile chiedere perdono che permesso" (EAFP). LBYL consiglia di verificare se il lavoro esiste prima di tentare di eliminarlo. EAFP comporterebbe il tentativo di abbandonare il lavoro e quindi acquisire e ignorare quell'errore specifico, se si verifica.

Se dovessi applicare LBYL puoi interrogare la vista di sistema USER_SCHEDULER_JOBS per vedere se il tuo lavoro esiste. Se lo fa, lascialo cadere.

declare
   l_job_exists number;
begin
   select count(*) into l_job_exists
     from user_scheduler_jobs
    where job_name = 'STATISTICS_COLUMNS_JOB'
          ;

   if l_job_exists = 1 then
      dbms_scheduler.drop_job(job_name => 'STATISTICS_COLUMNS_JOB');
   end if;
end;

Per EAFP è leggermente diverso; definisci la tua eccezione denominando un'eccezione definita internamente e istanziandolo con il codice di errore che stai cercando di catturare. Se l'errore viene quindi generato, non fare nulla.

declare
   job_doesnt_exist EXCEPTION;
   PRAGMA EXCEPTION_INIT( job_doesnt_exist, -27475 );
begin
   dbms_scheduler.drop_job(job_name => 'STATISTICS_COLUMNS_JOB');
exception when job_doesnt_exist then
   null;
end;

Vale la pena notare due cose su questo secondo metodo.

Sono solo catturare l'errore generato da questa specifica eccezione. Sarebbe possibile ottenere lo stesso risultato utilizzando EXCEPTION WHEN OTHERS ma consiglio vivamente contro facendo questo.

Se gestisci un'eccezione, dovresti sapere esattamente cosa ne farai. È improbabile che tu abbia la capacità di gestire correttamente ogni singola eccezione Oracle utilizzando OTHERS e se lo fai probabilmente dovresti registrarli da qualche parte dove verranno notati. Per citare le Linee guida per evitare e gestire le eccezioni :
propagazione delle eccezioni di Oracle funziona da blocco interno a blocco esterno, quindi la causa originale dell'errore sarà la prima eccezione.