Oracle_030. Triggers #1 - BEFORE_AFTER INSERT

Page 30. Triggers

  #1.

  이번에 원래 Import Data Pump 에 대해 사용했던 방법을 기술하려 했지만, 이번에 트리거를 작성할 일이 생겨서 Trigger 에 대하여 좋은 샘플이 있기에 무단으로 퍼옵니다. ' -';;

  트리거란 INSERT, UPDATE, DELETE 같은 DML 작업이 수행할때 DML 작업의 전후에 특정한 작업이 일어나게 설정해 놓는것을 말합니다.  예를들어 중요한 테이블에 DELETE를 수행하게 되면 DELETE 가 수행되기 전에 DELETE 될 행을 미리 트리거 테이블에 기록해 놓을 수 있습니다. 그래서 추후 복구할때 트리거 테이블을 참조하면 쉽게 복구가 가능하게 됩니다.

  #2-1.

  BEFORE INSERT Trigger.

  글자 그대로 Insert 작업 수행전에 일어나는 행위입니다. 다음은 Syntax 입니다.

    CREATE OR REPLACE TRIGGER TRIGGER_NAME

    BEFORE INSERT ON TABLE_NAME

       [ FOR EACH ROW ]

    DECLARE

        -- variable declarations

    BEGIN

        -- trigger code

    EXCEPTION

        WHEN ...

       -- exception handing

    END;

    TRIGGER_NAME 은 만들 트리거 이름입니다.

    다음은 해당 트리거의 제한사아이라고 합니다.

• 뷰에는 Before Trigger 를 생성할 수 없습니다.
• :NEW 값을 업데이트 할 수 있다고 하네요.
• :OLD 값은 업데이트 할 수 없습니다.

  다음은 예제입니다. 다음과 같은 테이블을 생성했다고 가정합니다.

    CREATE TABLE ORDERS  (

        ORDER_ID           NUMBER(5),

        QUANTITY           NUMBER(5),

        COST_PER_ITEM NUMBER(6,2),

        TOTAL_COST      NUMBER(8,2),

        CREATE_DATE    DATE,

        CREATED_BY      VARCHAR2(10)

     );

  BEFORE INSERT 트리거는 다음과 같이 만들 수 있습니다.

    CREATE OR REPLACE TRIGGER ORDERS_BEFORE_INSERT

    BEFORE INSERT ON ORDERS

         FOR EACH ROW

    DECLARE

         v_username  varchar2(10);

    BEGIN

         -- 테이블에 인서트 작업을 수행하는 사용자 명을 찾습니다.

         SELECT username INTO v_username

         FROM DUAL;

         -- CREATE_DATE 컬럼을 현재 시스템 날짜로 업데이트 합니다.

         :new.create_date := sysdate;

         :new.created_by := v_username;

    END;

  #2-2

  AFTER INSERT Trigger

  인서트 작업 이후에 일어납니다. Syntax 는 다음과 같습니다.

    CREATE OR REPLACE TRIGGER TRIGGER_NAME

    AFTER INSERT ON TABLE_NAME

       [ FOR EACH ROW ]

    DECLARE

        -- variable declarations

    BEGIN

        -- trigger code

    EXCEPTION

        WHEN ...

       -- exception handing

    END;

  다음은 예제입니다.

    CREATE OR REPLACE TRIGGER ORDERS_BEFORE_INSERT

    BEFORE INSERT ON ORDERS

         FOR EACH ROW

    DECLARE

         v_username  varchar2(10);

    BEGIN

         -- 테이블에 인서트 작업을 수행하는 사용자 명을 찾습니다.

         SELECT username INTO v_username

         FROM DUAL;

         -- 추적테이블에 인서트 되는 행을 넣습니다..

         INSERT INTO orders_audit

         ( order_id, quantity, cost_per_item, total_cost, username )

         VALUES

         ( :new.order_id,

           :new.quantity,

           :new.cost_per_item,

           :new.total_cost,

           v_username );

    END;

 

ORACLE_029. UTILITY - DATA PUMP #1 - EXPDP

PAGE 29 DATA PUMP #1 - EXPORT DATA PUMP

 #1

  데이터를 EXPORT/IMPORT 할 일들이 최근 많아졌습니다. 그래서 그런지 대용량 TABLE 을 적재할때는 그 소요되는 시간하며, DUMP 파일로 떨구는데도 굉장히 오랜 시간이 걸리던 터라 결국 다른 방법을 찾아보게 되었습니다.  그래서 이번에 데이터 펌프를 처음으로 사용해 보았는데 그 속도에 아주 만족하고 있습니다.

  실제 사용했던 DATA PUMP 사용법을 이곳에 기록으로 남겨 나중에 참고할 수 있도록 해야겠네요. 혹시나, 검색을 통해 이 문서를 보시는 분들께서도 좋은 참고자료가 되길 바래봅니다.

 #2

  EXPORT DATA PUMP 는 종전의 EXPORT 와는 조금 다른 인터페이스 방식으로 작동되는 것 같습니다. 예전 EXPORT 의 경우엔 콘솔상에서 BREAK 신호를 보내면 아예 EXPORT 자체가 중단되어 버렸었죠. 하지만 DATA PUMP 는 INTERACTIVE 상태로 들어갑니다. 거기서 추가적으로 병렬처리 값을 증가시켜준다던지등 여러가지 값을 새로이 설정해서 수행할 수 있습니다. 정말 이 병렬처리가 된다는 것이 너무 편리합니다. 게다가 TABLESPACE 를 REMAP 시킬 수 있어 LOB 컬럼이 있다 하더라도 문제 없이 데이터 적제가 가능해 집니다.

  참고로 EXPORT 를 통해 받은 DUMP 파일은 IMPORT DATA PUMP에서 사용할 수 없습니다. 역으로 DATA PUMP 를 통해 받은 DUMP 파일 역시 일반 IMPORT 로 적재가 불가능 하다고 하니 참고하시기 바랍니다.

 #3

  EXPORT DATAPUMP 는 다음의 모드중 한가지 모드를 사용합니다. 일반 EXPORT 와 마찬가지로 각각의 모드는 중복해서 사용할 수 없습니다.

• FULL - 전체 DATABASE 를 EXPORT 합니다. (EXP_FULL_DATABASE 권한 필요)
• SCHEMAS - 스키마 단위로 EXPORT 를 수행합니다.
• TABLES - 해당 테이블만 EXPORT 합니다.
• TABLESPACES - 테이블 스페이스를 EXPORT 합니다.

  EXAMPLE)

    # expdp schemas=scott

    # expdp tables=scott.employees

 #4

  모드를 설정했다면 이제 받을 덤프파일명등 그외 옵션들을 설정해 주어야 합니다.

• DUMPFILE - 떨궈질 파일명을 지정합니다. 파일명에 %U 옵션을 붙이면 01-99 번까지 자동으로 번호가 붙습니다. %U는 병렬로 받을시, 파일명을 일일이 열거할 필요가 없어 편리합니다. :)
• STATUS - 진행 상황을 보여줍니다. 단위는 초 입니다. 20으로 설정하면 20초마다 진행되는 상황을 보여줍니다.
• LOGFILE - 로그를 기록할 파일명을 지정합니다.
• FILESIZE - 떨어질 덤프파일의 최대 용량을 지정합니다. 파일명을 여러개 지정했다면 첫번째 지정된 파일이 꽉 찼을경우 두번째 파일에 기록합니다. %U로 파일명을 지정하면 오라클이 알아서 숫자를 붙여줍니다.
• QUERY - 해당 조건에 해당하는 ROW들만 EXPORT 합니다. (QUERY=\"WHERE EMP_ID=3727\") - Unix 계열일 경우 이처럼 Escape 문자가 필요합니다.
  
• JOB_NAME - 해당 EXPORT DP작업명을 지정합니다. 지정하지 않을경우 오라클이 임의로 작업명을 붙여줍니다.
• PARALLEL - 병렬처리 갯수를 지정합니다. 병렬처리를 4개로 했다면 DUMPFILE 옵션에도 파일을 4개 지정해야 합니다. %U를 지정했다면 오라클이 알아서 번호를 붙여 생성합니다.
• EXCLUDE / INCLUDE - 특정 오브젝트들을 제외하거나 포함시킬 수 있습니다.
  VIEW, PACKAGE, PROCEDURE, FUNCTION, GRANT, TRIGGER,
  CONSTRAINT, REF_CONSTRAINT
  (EXCLUDE = Object_type:Obj_name,...)
  (EXCLUDE = INDEX:"LIKE 'DEPT%'")
• DIRECTORY - 덤프를 받을 디렉토리명을 지정합니다. 디렉토리를 지정하는 방법은 밑에 기술하도록 하겠습니다.
• NETWORK_LINK - 원격지에 있는 DB의 데이터를 EXPORT 받을때 사용합니다. TNS 명이 아닌 DBMS상에 있는 DATABASE LINK 명을 사용합니다. 단 원격 DATABASE 로 접속하는 해당 계정이 EXPORT 권한을 가지고 있어야 합니다. (계정은 DATABASE LINK 생성시 지정하는거 아시죠?)
• TRANSPORT_TABLESPACES - Y 지정시 TTS 모드가 됩니다.

 #5

  DATA PUMP 를 사용하기 위해서는 오라클 내부적으로 DIRECTORY 를 선언해 주어야 합니다. 이 디렉토리에 관련된 뷰는 DBA_DIRECTORIES 를 조회하면 현재 지정된 디렉토리들을 볼 수 있습니다. 다음 구문은 디렉토리를 생성하는 방법입니다.

  SQL> CREATE DIRECTORY PUMPDIR AS '/data/pump';

  CREATE DIRECTORY <DIRECTORY_NAME> AS <Real directory Path> 가 기본 형식입니다. 실제 디렉토리를 생성후 오라클에서 그 디렉토리에 EXPORT 받겠다는 것이죠. 디렉토리가 생성되었다면 EXPORT 를 수행할 스키마에 대해 해당 디렉토리에 읽고 쓸 수 있는 권한을 주어야 합니다.

  SQL> GRANT READ, WRITE ON DIRECTORY PUMPDIR TO SCOTT;

  이렇게 해당 계정에 디렉토리에 대한 권한을 제공하고 이제 EXPORT DATA PUMP 를 수행해 주면 됩니다.

 #6

  일반적인 DATA PUMP 를 수행하기 위한 기본 지식은 이제 다 갖추게 된 것 같군요. 대충 어떤 식으로 받는지 샘플을 통해서 알아보도록 하지요.

1. 전체 DATABASE EXPORT  
   expdp dba/dba full=y dumpfile=fullexp_%U.dmp directory = pumpdir logfile=fullexp.log parallel=10 status = 20
   
   
2. 특정 테이블 파티션 EXPORT
   expdp dba/dba tables=scott.employees:partition03 dumpfile=expdp_%U.dmp directory = pumpdir logfile=partition.log parallel=5 status = 20
   
   
3. 인덱스를 제외한 테이블 EXPORT
   expdp dba/dba tables=scott.department dumpfile=department_%U.dmp directory=pumpdir logfile=department.log parallel = 5 exclude=index
   
   

 #7

  DATA PUMP 의 모든 사용방법을 알아본건 아니지만 적어도 이정도 옵션들만 알고 있다면, 그리 큰 문제는 없을거라 생각됩니다. 받은 DUMP 파일을 이용해 IMPORT DATA PUMP 를 사용할시 테이블 스페이스를 변경해서 올린다던지, 혹은 스키마를 변경해서 올린다든지 하는 옵션이 매우 간결하고 편리합니다.  다음 포스팅때에는 IMPORT DATA PUMP 에 관해서 이번처럼 간단히 알아보는 방법을 기록해 보겠습니다.

FALLENSTAR.

 

ORACLE_025. Managing Job Queues

Enabling Process Used for Excuting Jobs
 잡 큐(Job Queue)를 이용하여 주기적으로 스케쥴 루틴(Jobs)을 수행할 수 있습니다. DBMS_JOB 패키지를 이용하여 작업의 스케쥴을 잡 큐에 넣을 수 있으며, 어떤 작업을 수행하게 할 지 결정할 수 있습니다. 또한 이미 적용한 작업을 변경, 보류, 혹은 삭제를 수행할 수 있습니다.

 잡 큐(Jnnn) 프로세서는 잡 큐에 있는 작업을 수행합니다. 각각의 인스턴스에서 이러한 잡 큐는 CJQ0(Coordinator Job Queue) 백그라운드 프로세스에 의해 동적으로 수행됩니다. 선택되어 수행되어질 작업들은 DBA_JOBS 뷰를 통해 확인할 수 있습니다. 시간순으로 정렬되어 있으며 선택된 작업은 Jnnn 프로세스가 선택된 작업을 수행합니다. 각각의 Jnnn 프로세스는 선택된 작업을 수행합니다.(Jnnn 프로세스는 CJQ 프로세스가 가지고 있는 하위 프로세스 입니다.)

 JOB_QUEUE_PROCESSES 초기화 파라메터로 인스턴스가 CJQ 프로세스를 시작할지 안할지를 결정할 수 있습니다. 파라메터가 0으로 선언되어 있으면 데이타베이스가 시작될때 CJQ 프로세스를 시작하지 않으며 잡 큐에 있는 작업들을 수행하지 않습니다. JOB_QUEUE_PROCESSES 파라메터는 또한 인스턴스에서 수행될 수 있는 최대 Jnnn 프로세스의 갯수를 정의하기도 합니다. 최대값은 1000 입니다.

 다음과 같이 파라메터를 설정하면 CJQ 프로세스는 데이터베이스가 시작할때 같이 시작됩니다. 그리고 최대 60개의 Jnnn 프로세스를 가지게 됩니다.

  JOB_QUEUE_PROCESS = 60

 새로운 값이 기존의 값보다 작거나 현재 수행중인 Jnnn 의 갯수보다 작으면 수행중인 프로세스는 수행중인 작업이 종료되는 순간 정지하게 됩니다.

 Jnnn 프로세스는 데이터베이스가 Restricted 상태라면 Jnnn 프로세스는 수행되지 않습니다.

 

 

 

Managing Job Queues

 

The DBMS_JOB Package

 잡 큐(Job Queue)에 있는 작업을 등록하고 관리하려면 DBMS_JOB 패키지에 있는 프로시저를 수행하면 됩니다. 작업큐를 사용하기 위해 필요한 데이터베이스 권한은 따로 존재하지 않습니다. 잡 큐를 사용할 수 있는 모든 사용자는 잡 큐 프로시저를 실행할 수 있습니다.

 다음은 DBMS_JOB 패키지에 있는 프로시저들 입니다.

• SUBMIT :
  잡 큐에 작업을 등록합니다.
• REMOVE :
  잡 큐에 등록되어 있는 작업을 삭제합니다.
• CHANGE :
  잡 큐에 등록되어 있는 작업을 변경합니다. 작업의 주석을 변경하거나, 수행 시간, 수행 간격등을 조정할 수 있습니다.
• WHAT :
  특정 작업의 주석을 변경합니다.
• NEXT_DATE :
  특정 작업의 다음 수행 날짜를 지정합니다.
• INTERVAL :
  특정 작업의 수행 주기를 변경합니다.
• BROKEN :
  작업이 실패했음을 나타내는 플레그를 설정하거나 해제합니다. 실패로 설정되어 있다면 해당 작업을 수행하지 않습니다.
• RUN :
  특정 작업을 강제로 수행합니다.

Submitting a Job to the Job Queue
 새로운 작업을 잡 큐에 넣기 위해 DBMS_JOB 패키지의 SUBMIT 프로시저를 이용합니다. SUBMIT 프로시저에서 다음 파라메터들을 사용할 수 있습니다.

• JOB :
  출력 파라메터. 새로 생성한 작업의 식별 이름입니다. 작업을 변경하거나 삭제할때 반드시 이 번호를 사용해야 합니다.
• WHAT :
  수행하고자 하는 PL/SQL 코드 입니다.
• NEXT_DATE
  작업이 수행될 날짜를 정합니다. 기본값은 SYSDATE 입니다.
• INTERVAL :
  다음번 수행될 날짜를 지정합니다. 기본값은 NULL 입니다. 반드시 시간 혹은 NULL 값만을 취합니다.
• NO_PARSE
  플래그(FLAG)입니다. FALSE(기본값)로 설정시 해당 적업과 관련된 프로시저를 해석(PARSE)합니다. TRUE 일 경우 처음 실행될때 해석을 합니다. 예를들어 테이블을 만들기전에 작업을 SUBMIT 하기 위해선 NO_PARSE 값을 TRUE 로 놓습니다.

 예로, 다음 작업을 큐에 넣는다고 가정하고 작업 번호(jobnumber)를 출력해 보겠습니다. 작업은 DBMS_DDL.ANALYZE_OBJECT 를 호출하여 hr.employees 테이블의 통계정보를 생성합니다. 통계정보는 해당 테이블이 가지고 있는 행의 반개를 기준으로 작성됩니다. 이 작업은 매 24시간마다 수행됩니다.

  VARIABLE jobno NUMBER
  BEGIN
    DMBS_JOB.SUBMIT(:jobno,
      'DBMS_DDL.ANALYZE_OBJECT(''TABLE'',
      ''HR'',''EMPLOYEES'',
      ''ESTIMATE'',NULL, 50);',
      SYSDATE,'SYSDATE+1');
    COMMIT;
   END;
   /
   PRINT jobno

   JOBNO
   ----------
   14144

Job Environment

 작업을 잡 큐에 넣거나 혹은 변경하였을때 오라클은 다음과 같은 환경 특징을 기록합니다.

• 현재 사용자
• 작업을 넣거나 변경한 사용자
• 현 스키마(ALTER SESSION SET CURRENT_SCHEMA 구문을 입력했었다면 현재 사용자와 큐에 넣은 사용자가 다를 수 있습니다.)

 또한 다음과 같은 NLS 파라메터도 함께 기록됩니다.

• NLS_LANGUAGE
• NLS_TERRITORY
• NLS_CURRENCY
• NLS_ISO_CURRENCY
• NLS_NUMERIC_CHARATER
• NLS_DATE_FORMAT
• NLS_DATE_LANGUAGE
• NLS_SORT

 오라클은 매번 작업이 수행될때 마다 이러한 환경 변수들을 복원합니다. NLS_LANGUAGE 와 NLS_TERRITORY 파라메터는 정의되지 않은 NLS 파라메터에 기본값을 제공해 줍니다.

 DBMS_SQL 패키지나 ALTER SESSION 구문을 이용하여 이러한 작업의 환경변수값을 변경할 수 있습니다.

 

Jobs and Import/Export

 작업을 익스포트 하거나 임포트 할 수 있습니다.. 따라서 해당 작업을 한 데이터베이스에서 익스포트 하여 다른 데이터베이스에 전송이 가능합니다. 익스포팅이나 임포팅 작업을 수행시, 작업 번호, 환경변수, 정의는 그대로 유지됩니다.

 

Job Owner

 작업을 잡 큐에 넣을때, 오라클은 작업을 집어넣는 사람을 작업의 소유자로 간주합니다. 작업의 소유자만이 작업을 변경하거나 강제로 수행시키고 큐에서 삭제할 수 있습니다.

 

Job Number

 큐에 들어간 작업은 작업 번호로써 구분이 됩니다. 작업을 큐에 넣을때 JOBSEQ라는 SYS소유의 시퀀스로부터 작업 번호를 자동으로 부여 받습니다. 한번 작업 번호를 할당받으면 작업번호는 변경할 수 없습니다. 작업이 익스포트 혹은 임포트 되어진다 해도 작업 번호는 불변입니다.

 

Job Definition

 작업 정의는 SUBMIT 프로시저의 WHAT 파라메터 에 정의되어 있는 PL/SQL 코드 입니다. 보통, 작업 정의는 단일 프로시저 호출로 정의됩니다. 프로시저는 여러개의 파라메터를 호출 할 수 있습니다.

 다음 예시는 올바른 작업 정의 입니다.

• 'myproc(''10-JAN-99'', next_date, broken);'
• 'scott.emppackage.give_raise(''JFEE'',3000.00);'
• 'dbms_job.remove(job);'

Job Execution Interval

 작업이 일정한 간격으로 주기적으로 실행되어야 한다면 INTERVAL 파라메터에 'SYSDATE + 7'과 같은 날짜 표현식을 사용하시면 됩니다. 다음 예시를 참고하세요.

• 'SYSDATE + 7'  :
  마지막 수행 후 정확히 7일 후
• 'SYSDATE + 1/48' :
  매 30분 마다
• 'NEXT_DAY(TRUNC(SYSDATE),''MONDAY'') + 15/24'
  매 월요일 오후 3시마다
• 'NEXT_DAY(ADD_MONTH(TRUNC(SYSDATE),''Q''),3),''THURSDAY'')'
  매 분기의 첫번째 목요일

 항상 특정 시간에 작업을 수행하게 만들고 싶으면 INTERVAL 과 NEXT_DATE 파라메터를 'NEXT_DAY(TRUNC(SYSDATE),''MONDAY'');' 와 비슷한 방식으로 선언해 주시면 됩니다.

 

Database Links and Jobs

 데이터베이스 링크를 사용하는 작업을 큐에 넣으면 해당 링크는 반드시 사용자 이름과 암호를 포함시켜야 합니다. 익명의 데이터베이스 링크는 작업을 성공적으로 수행할 수 없습니다.

 

 

How Job Execution

 Jnnn 프로세스가 작업을 수행합니다. 작업을 수행하기 위해 프로세스는 세션을 생성합니다. Jnnn프로세스가 작업을 수행할때 작업의 소유자와 같은 권한을 가진 환경에서 수행됩니다. 작업에 기술되어 있는 오브젝트들에 접근하기 위한 권한이 모두 있는지 반드시 확인하십시요.

 DBMS.JOB.RUN 프로시저를 이용해 강제로 작업을 수행할때 작업은 사용자 프로세스(User process)와 기본 권한을 가진 상태로만 수행합니다. 롤을 통해 위임받은 권한들은 사용할 수 없습니다. 작업이 수행되는 중 참조하게 되는 오브젝트들에 대한 접근 권한이 있는지 확인하십시요.

 

Job Queue Locks

 한번에 한 세션에서만 작업이 수행될 수 있도록 오라클은 수행중인 작업에 대해 잡 큐를 잠급니다. 작업이 수행될때 해당 세션은 해당 작업에 대해 잠금(Lock)을 겁니다. 세션이 현재 잡고 있는 잠금에 대한 정보는 데이터 딕셔너리를 통해 확인해 볼 수 있습니다.

 다음 쿼리를 참고하세요.

  SELECT SID, TYPE, ID1, ID2 FROM V$LOCK WHERE TYPE = 'JQ';
            SID   TY        ID1       ID2
             12    JQ          0    14114
   1 row selected.

 위 쿼리에서 잠금(Lock)을 잡고 있는 세션은 12 입니다. ID1 열은 JQ 블럭에 대해 항상 0 입니다. ID2 열은 세션이 수행중인 작업의 작업 번호 입니다. 위 뷰는 DBA_JOBS_RUNNING 뷰와 결합(JOIN) 하여 좀더 상세한 정보를 획득할 수 있습니다.

 

Job Execution Errors

 작업이 실패했을시, 추적파일(trace file)과 alert log 파일에 해당 정보가 기록됩니다. ORA-12012 메세지를 작성하고 실패한 작업의 작업 번호를 기록합니다.

 다음의 경우 잡 큐에 있는 작업이 실패합니다.

• 네트워크나 인스턴스의 실패
• 작업 수행중 발생한 예외

 작업을 수행하기 위해 시도하는 중 에러가 반환되면 오라클은 다시한번 그 작업을 수행하려 합니다. 첫번째 재시도는 실패후 1분후, 두번째 시도는 2분후, 세번째 시도는 4분후... 이런 방식으로 전 시도의 대기 시간보다 2배의 시간 간격을 두고 재시도 합니다. 작업이 16번 실패하면 오라클은 자동으로 작업에 BROKEN 플레그를 선언하고 더이상 그 작업을 수행하지 않습니다. 하지만 재시도 중간 중간 작업이 제대로 돌아갈 수 있게 문제를 해결할 수 있는 기회들이 있습니다. 이 기회들은 오라클이 작업을 재수행 하는데 방해를 주지 않습니다.

 

 

Removing a Job from the Job Queue
 잡 큐에서 작업을 삭제하기 위해 REMOVE 파라메터를 사용할 수 있습니다.
 다음 구문은 잡 큐에서 14114의 작업번호를 가진 작업을 잡큐에서 삭제하는 방법입니다.

  BEGIN
   DBMS_JOB.REMOVE(14114);
  END;
  /

 제한사항

• 현재 수행중인 작업을 잡 큐에서 제거할 수 있습니다만, 수행중인 작업은 중단되지 않고 끝까지 수행됩니다.
• 자기 자신의 작업만 삭제할 수 있습니다. 자신의 소유 작업이 아닌 작업을 삭제하려 할 경우 해당 작업이 잡큐에 존재하지 않는다는 메세지를 받게 될 것 입니다.

 

Altering a Job

 잡 큐에 있는 작업을 변경하기 위해 DBMS_JOB 패키지의 CHANGE, WHAT, NEXT_DATE 혹은 INTERVAL 프로시저를 사용할 수 있습니다. 오직 자신이 소유하고 있는 작업만 변경할 수 있습니다.

 

CHANGE
 DBMS_JOB.CHANGE 프로시저를 이용하여 사용자가 정의한 어떠한 파라메터도 수정할 수 있습니다. 다음 예제를 참고하세요.

  BEGIN
  DBMS_JOB.CHANGE(14114, NULL, NULL, 'SYSDATE +3');
  END;
  /

 WHAT, NEXT_DATE 혹은 INTERVAL 을 NULL 값으로 정하면 기존에 있는 값이 변동되지 않고 그대로 유지되게 됩니다.

 

WHAT
 DBMS_JOB.WHAT 프로시저를 이용하여 작업을 변경할 수 있습니다.

  BEGIN
  DBMS_JOB.WHAT(14114,
              'DBMS_DDL.ANALYZE_OBJECT(''TABLE'',''HR'',''DEPARTMENTS'',''ESTIMATE'',
              NULL,50);');
  END;
  /

 

NEXT_DATE
 DBMS_JOB.NEXT_DATE 프로시저를 이용하여 다음 수행될 시간을 변경할 수 있습니다.

  BEGIN
  DBMS_JOB.NEXT_DATE(14114, SYSDATE + 4);
  END;
  /

 

INTERVAL
 DBMS_JOB.INTERVAL 프로시저를 이용하여 작업과 작업 사이의 간격을 결정할 수 있습니다.

  BEGIN
  DBMS_JOB.INTERVAL(14114,'NULL');
  END;
  /

 위 예시의 경우 작업은 더이상 수행되지 않고 잡 큐에서 제거될 것 입니다.

 

 

Broken Jobs

 오라클은 BROKEN 플래그가 있는 작업은 수행하지 않습니다. 하지만 DBMS_JOB.RUN. 프로시저를 이용하여 강제로 작업을 수행할 수 있습니다.

 

How a Job Becomes Broken

 실패하지 않을거라 생각되는 작업을 잡 큐에 넣습니다. 그럼에도 BROKEN 이 발생하는 경우는 다음과 같습니다.

• 16번의 재시도가 모두 실패할 경우
• DBMS_JOB.BROKEN 을 이용하여 작업에 BROKEN 플레그를 설정한 경우
  BEGIN
  DBMS_JOB.BROKEN(14114);
  END;
  /

 오라클은 한번 BROKEN 마크를 단 작업은 사용자가 BROKEN 마크를 해제하기 전까지나 DBMS_JOB.RUN 프로시저를 호출하지 않는한 다시는 수행하지 않습니다.

 다음 예시는 BROKEN 으로 표시된 14114 작업을 다음 월요일 에 수행될 수 있도록 하는 방법입니다.

  BEGIN
  DBMS_JOB.BROKEN(14114, FALSE, NEXT_DAY(SYSDATE, 'MONDAY'));
  END;
  /

Running Broken Jobs

 16번의 작업 실패가 일어났다면 작업은 BROKEN 으로 표시됩니다. 문제를 해결했다면 다음 방법을 통해 작업을 재개할 수 있습니다.

• DBMS_JOB.RUN 을 통한 강제 수행
• DBMS_JOB.BROKEN 을 통한 BROKEN 플레크 해제

 DBMS_JOB.RUN 프로시저를 통해 강제로 작업을 수행하면 오라클은 해당 작업을 즉시 수행합니다. 작업이 성공적으로 수행되면 BROKEN 플레그는 해제되며 실패 횟수가 초기화 됩니다.

 

 

Forcing a Job to Execute

 작업을 스케쥴에 맞춰 수행하는 것이 아닌 직접 수행해 주어야 할 때가 있을 수도 있습니다. 실패한 작업을 수정을 했을경우 수정한 작업을 바로 수행시켜 보고 싶을 것 입니다. 작업을 강제로 수행하기 위해서는 DBMS_JOB 패키지의 RUN 프로시저를 사용합니다.

 DBMS_JOB.RUN 프로시저를 수행할때 다음번 작업이 시작할 시간을 다시 계산 합니다. 예를들어 월요일에 작업을 새로 작성하면서 NEXT_DATE 값으로 SYSDATE를 주고, INTERVAL 에 'SYSDATE +7' 이라고 정해주었다면 해당 작업은 매 월요일에 수행 될 것 입니다. 하지만 수요일날 RUN 프로시저를 사용하여 강제로 작업을 수행했다면 다음 작업이 수행되는 날은 다음주 수요일이 될 것 입니다.

 다음 구문은 14114 작업을 현 세션에서 수행하고 다음 수행날자를 재 계산하여 입력되는 예제 입니다.

  BEGIN
  DBMS_JOB.RUN(14114);
  END;

 

Terminating a Job
 수행중인 작업을 중지시키는 방법으로 해당 작업에 BROKEN 플레그를 설정하고 해당 작업이 수행되는 세션을 확인한 다음 그 세션을 잘라내는 방법을 사용합니다. BROKEN 설정을 하는 이뉴는 오라클이 해당 작업을 다시 수행하지 않게 하기 위함 입니다.

 

 작업을 수행하는 세션을 확인후에 (V$SESSION 혹은 V$LOCK 뷰를 이용합니다.) SQL 구문인 ALTER SYSTEM 으로 해당 세션을 잘라낼 수 있습니다.

 

 

Viewing Job Queue Information
 다음에 나열된 딕셔너리 뷰를 통하여 잡 큐와 작업에 대해 확인할 수 있습니다.

• DBA_JOBS, ALL_JOBS, USER_JOBS
  DBA 뷰는 데이터베이스 내의 모든 작업에 대하여 보여줍니다. ALL 은 현 사용자가 접근할 수 있는 모든 작업에 대한 리스트를 반환하며 USER 뷰는 현 사용자가 소유하고 있는 작업에 대해서만 보여줍니다.
• DBA_JOBS_RUNNING
  현 데이터베이스가 수행중인 작업의 목록을 보여줍니다. 이 뷰는 V$LOCK 뷰와 조인하여 잠금 (LOCK)을 가진 작업을 확인할 수 있습니다.

Displaying Information About a Job
 다음 쿼리는 작업 번호, 다음 수행일, 실패 횟수, BROKEN 상태를 보여줍니다.

  SELECT JOB, NEXT_DATE, NEXT_SEC, FAILURES, BROKEN
  FROM DBA_JOBS;

Displaying Information About Running Jobs
 현재 수행중인 작업만 조회하여 볼 수도 있습니다. 다음 쿼리는 현제 데이터베이스가 수행중인 작업에 대하여 세션 식별자(Session Identifier -SID), 작업 번호, 작업을 등록한 사람, 그리고 시작 시간을 보여줍니다.

  SELECT SID, r.JOB, LOG_USER, r.THIS_DATE, r.THIS_SEC
  FROM DBA_JOBS_RUNNING r, DBA_JOBS j
  WHERE r.JOB = j.JOB;

 

Fin.
REF) Oracle documents (server.920/a96521)