DBMS_Scheduler.DROP_JOB(있는 경우에만 해당)

DBMS_Scheduler.DROP_JOB(있는 경우에만 해당)

덤프를 가져온 후 실행해야 하는 SQL 스크립트가 있습니다. 이 스크립트는 다음 작업을 수행합니다.

BEGIN 
--remove program          
SYS.DBMS_SCHEDULER.DROP_PROGRAM(program_name=>'STATISTICS_COLUMNS_PROG',FORCE=>TRUE);
--remove job
SYS.DBMS_SCHEDULER.DROP_JOB (job_name => 'STATISTICS_COLUMNS_JOB');
END; 

원본 스키마에서 작업이 이미 삭제된 경우 작업 없이 덤프가 오고 스크립트가 실패하는 경우가 있습니다.

ERROR at line 1:
ORA-27475: "DMP_6633.STATISTICS_SET_COLUMNS_JOB" must be a job 
ORA-06512: at "SYS.DBMS_ISCHED", line 213 
ORA-06512: at "SYS.DBMS_SCHEDULER", line 657 
ORA-06512: at line 5 

작업이 존재하지 않지만 작업이 존재하는 경우 이 실패를 방지하려면 어떻게 해야 합니까?

예외 처리에 적용할 수 있는 두 가지 주요 패턴은 "뛰기 전에 확인"(LCIL)과 "허락보다 용서를 구하는 것이 더 쉽다"(EAFP)입니다.LBIL은 작업을 중단하기 전에 작업이 존재하는지 확인하는 것을 권장합니다. EAFP는 작업을 중단하려고 시도한 다음 특정 오류가 발생할 경우 해당 오류를 캡처하고 무시합니다.

LBIL을 적용한 경우 시스템 보기를 쿼리하여 작업이 존재하는지 확인할 수 있습니다.만약 그렇다면, 그것을 내려놓으세요.

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;

EAFP의 경우 약간 다릅니다. 내부적으로 정의된 예외의 이름을 지정하고 탐지하려는 오류 코드로 인스턴스화하여 자신만의 예외를 정의합니다.그런 다음 오류가 발생하면 아무것도 수행하지 않습니다.

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;

이 두 번째 방법에 대해 두 가지를 주목할 필요가 있습니다.

1. 저는 이 특별한 예외에 의해 제기된 오류를 이해하고 있을 뿐입니다.다음을 사용하여 동일한 작업을 수행할 수 있습니다.EXCEPTION WHEN OTHERS하지만 저는 이런 짓을 하지 않는 것을 강력히 추천합니다.

   예외를 처리할 경우 해당 예외를 사용하여 무엇을 수행할지 정확히 알아야 합니다.다음을 사용하여 모든 Oracle 예외를 적절하게 처리할 수 있는 능력은 거의 없습니다.OTHERS그리고 만약 그렇게 한다면, 당신은 아마도 그것들이 눈에 띄는 곳에 그것들을 기록해야 할 것입니다.오라클의 예외 방지 및 처리 지침에서 인용하기:

   가능할 때마다 다른 예외 처리기를 사용하는 대신 명명된 예외 처리기를 작성합니다.

2. Oracle의 예외 전파는 내부 블록에서 외부 블록으로 작동하므로 오류의 원래 원인은 첫 번째 예외입니다.

언급URL : https://stackoverflow.com/questions/20178030/dbms-scheduler-drop-job-only-if-exists