DBMS_SCHEDULER.DROP_JOB 존재하는 경우에만

Question

덤프를 가져온 후 실행해야하는 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; 

이 Somtimes 작업이 이미 원래의 스키마에 떨어졌다

, 덤프는 일없이 제공하고 스크립트가 실패

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 

어떻게 나는이 실패를 피할 수있다. 만약 그 일이 존재하지 않는다면 그것을 떨어 뜨릴 수 있을까?

Answer 1

예외 처리에 적용 할 수있는 두 가지 주요 패턴이 있습니다. "도약하기 전에보세요"(LBYL) "허가보다 용서를 구하는 것이 쉽습니다"(EAFP). LBYL은 작업을 삭제하기 전에 작업이 있는지 확인하기 위해 검사를 권장합니다. EAFP는 작업을 중단 한 후 특정 오류를 포착하고 무시하는 작업을 포함합니다.

LBYL을 적용하려면 시스템보기 USER_SCHEDULER_JOBS을 쿼리하여 작업이 있는지 확인하십시오. 그럴 경우 삭제하십시오.

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의 경우 약간 다릅니다. define your own exception에 naming an internally defined exception을 입력하고 잡으려고하는 오류 코드로 인스턴스화하십시오. 그런 다음 오류가 발생하면 아무 것도하지 마십시오.

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을 사용하여 동일한 결과를 얻을 수도 있지만에 대해 을 사용하는 것이 좋습니다.

   예외를 처리하는 경우 정확히 무엇을 할 것인지 알아야합니다. OTHERS을 사용하여 모든 단일 Oracle 예외를 올바르게 처리 할 수있는 가능성은 낮습니다. 그렇다면 사용자가 알게 될 곳에서 로깅해야 할 것입니다. 오라클의 Guidelines for Avoiding and Handling Exceptions에서 인용하려면 다음과 같이하십시오.

   가능한 경우 OTHERS 예외 처리기를 사용하는 대신 명명 된 예외에 대한 예외 처리기를 작성하십시오. 외부 블록 내부 블록에서

2. 오라클의 exception propagation 작품은 오류의 원래 원인은 첫째 예외 있도록.