나의 향기에 젖다...

업무 기획

• 전산망 인프라 전략 및 실행 계획 수립
• 시스템에 대한 인프라 구축 전략 수립
• 전산교육 지원 분야 전략 및 실행 계획 수립
• IT 신기술 동향 수집/분석 및 적용 계획 수립
• 당해년도 업무 추진 계획 수립

 

팀 회의 진행

• 주간회의 자료 작성 및 회의 진행
• 주간 추진 업무 결과 보고 및 모니터링, 검토
• 업무 미비점 보완 및 토의, 지원
• 주간 업무 계획 보고 및 검토, 지시
• 기타 상시적인 업무 보고 및 회의 진행

 

E-mail 계정관리

• 계약직 사용자등 특수 용도 계정 발급 접수(업무 필요시 계정생성등)
• 계정 발급, 갱신, 삭제, 점검, 통보(퇴사자 메일 인계자 연동등)
• 계정 발급 이력 및 자료 작성, 정리(엑셀파일 정리 관리)
• 계정 발급 장애 처리(그룹웨어 연동 실패 시 수동 등록등)

 

시스템 유지보수

• 연간 유지보수 관련 업무 계획서 수립(네트워크/서버/DB/항온항습기/UPS등)
• 전년도 유지보수 업체 평가
• 유지보수 품목 선정 및 견적 의뢰
• 유지 보수 계약서 검토 및 의뢰
• 유지 보수 진행 및 유지 보수비용 신청
• 유지 보수 상세 계약서 작성
• 유지 보수 관련 자료 취합 정리

 

홈페이지 운영

• 홈페이지 운영을 위한 Server 관리
• 홈페이지 DB 관리
• 홈페이지 서비스 운영 및 처리(운영 장애발생시 원인파악 및 해결)
• 홈페이지 보안설정 관리(https 설정 및 Port 보안설정)
• 홈페이지 유지보수 업체 관리(상상디자인 업무 협업)

 

도메인 관리

• 도메인 신청 접수(업무필요시 도메인 사용 가능 확인 및 견적의뢰)
• 도메인 등록, 삭제, 갱신, 점검, 통보(소유주 및 관리자 갱신등)
• 도메인 등록 이력 관리(사용 기간 확인으로 불필요 도메인 연장X)
• 도메인 관리 장애 처리(해당 도메인 연결 실패시 원인 파악 및 해결)

 

전산실 주변 기기 관리

• 전산실 시설(UPS / 항온항습기 포함) 관리
• 전산실 주변 기기 구입
• 전산실 주변 기기 운영 및 장애 처리
• 점검 일지 및 보고서 작성 정리

 

서버 관리 및 운영

• 서버실 내 서버 관리 정책 수립(H/W, OS, Service)
• 하드웨어 운영 및 점검(내구한도 파악 및 스페어 장비 확보등)
• O/S 및 소프트웨어 운영 점검(서비스팩 설치등 최적화된 환경 구성)
• 시스템 장애 처리(H/W 수리 및 교체/OS 재설치/서비스 재구성)
• 서버별 보안패치 (Windows 보안패치등)
• 시스템 성능 관리 및 운영
• 시스템 구입 의뢰
• 장애 일지 및 보고서 작성 정리(이력관리)
• 서버별 보안 정책 수립 및 적용
• 서버별 보안 점검 및 모니터링, 프로그램운영
• 서버별 보안 정책 변경, 신규 룰 설정
• 서버별 보안 점검 일지 및 보고서 작성 정리

 

데이타 백업 관리

• 서버별 백업 정책 수립(그룹사 운영 서버)
• 백업 시스템 운영 및 점검
• 백업 시스템 장애 처리(백업 실패시 원인 및 해결)
• 백업 자료 복구(문제 발생시 백업자료를 통한 데이터 손실방지)
• 백업 이중화(백업데이타 이중화로 인해 데이터손실 방지)
• 백업 일지 및 보고서 작성 정리

 

네트워크 관리(유/무선망)

• 전산망 운영 기획 및 실행
• 네트워크 설계
• 네트워크 장비 구매 의뢰
• 네트워크 장비 운영 및 장애 처리
• 전산망 추가 및 변경
• 전산망 유지 보수 검토 및 업체 관리
• 각종 제안서 검토 및 관리
• 각 건물별 네트워크 장비 관리
• 건물별 랜실 주변기기 관리
• 네트워크 장비 모니터링 및 취약점분석, 조치/보안 관리
• 행사 네트워크 시설 지원
• 전산망 관리 프로그램 운영
• 건물 개.보수에 따른 랜 공사
• VPN 연결 관리
• 무선랜망 운영 기획 및 실행
• 무선랜망 네트워크 설계
• 장비 구매 의뢰
• 장비 운영 및 장애 처리 (무선랜 스위치, 허브, AP 등)
• 무선랜망 추가 및 변경
• 무선랜 장비 모니터링 및 취약점 분석, 조치/보안 관리
• 관리 프로그램 운영
• 관련 보고서 작성 및 정리

 

인터넷 전용회선 관리

• 인터넷망 운영 기획 수립(사용자 및 서버대역 분리 운영)
• 전용 회선 사용 현황 분석
• 전용 회선 운영 및 장애 처리
• 전용 회선 사용량 관리 시스템 운영
• 각 할당 공인IP 관리
• 각종 보고서 작성 및 정리
• 관련 업체 업무 협의

 

전산망 자원 관리

• IP 발급 정책 수립(DHCP 대역/고정IP 등 할당대역 관리)
• IP 발급, 회수, 이동 운영(고정IP 및 고정IP 할당 및 회수 관리)
• 공인 IP 관리 대장 작성 및 운영(IP사용 내역 관리등)
• 전산망 도면 작성 및 수정(현재 구성된 내용으로 최신화)
• 건물별 네트워크 선번장 관리 운영(문제 발생시 원인 파악위해 필요)
• 전산 장비(기자재) 관리
• IP 관리 프로그램 개발 및 운영

 

사용자 상담 및 장애 처리

• 전산망 사용자 Call 접수 및 상담(그룹웨어 및 네트워크 / 기타전산)
• 전산망 사용자 장애 처리(해당 내역 처리)
• 장애 처리 보고서 및 통계 작성
• 장애 처리 프로그램 개발 및 운영

 

사용자 PC유해 트래픽 관리

• 사용자(PC) 유해 트래픽 방지 정책 수립
• 자산관리 프로그램 배포
• 유해 트래픽 관련 사용자 상담
• 유해 트래픽 프로그램 장애 처리
• 프로그램 배포 이력 관리 및 점검
• 관련 정책 수정 및 관리

 

신규 입사자

• 네트워크지원 및 보안 교육
• 전산망 교육 계획 수립 및 자료 작성
• 보안 및 사용 프로그램 복사, 인계
• 각종 매뉴얼 제작(전산 기본 설정 및 사용자 메뉴얼등)

 

방화벽(Firewall) 관리

• 방화벽 정책 수립 및 실행(유해사이트 차단등(주식/게임등))
• 방화벽 장비 운영 및 점검 / 각 지사 방화벽 포함
• 방화벽 정책 적용 및 모니터링, 정책 변경
• 유해 트래픽 방지 정책 수립 및 적용(해당 장비 구입필요)
• 침입 탐지 시스템(H/W) 운영 및 관리(시스템 구축 운영필요)
• 그룹사 전산망 취약점 분석 및 대응
• 내.외부 해킹 사고 상담 및 처리
• 관련 보고서 작성 및 정리

 

전산 비품 관리 (노트북 / 데스크탑 / 스위치 / 모니터 등)

• 전산비품 반납 분출 대장 관리
• 전산비품 최적화 작업
• 전산비품 요청자 상담

 

소프트웨어 관리

• 소프트웨어 대출 및 반납
• 소프트웨어 분류 및 정리
• 소프트웨어 라이센스 관리
• 소프트웨어 보유 및 배정 현황 관리
• 소프트웨어 사용에 대한 홍보 활동
• 소프트웨어 수요량 파악 및 지원
• 불법 소프트웨어 사용 감시 및 모니터링 (자산관리툴 사용)
• 신규 소프트웨어 구입 신청 (백신 등)
• 소프트웨어 사용자 상담 및 장애 처리

 

그룹웨어 관리

• 그룹웨어 라이선스 관리
• 그룹웨어 이메일 관리 및 운영
• 그룹웨어 게시판 관리 및 운영
• 그룹웨어 조직도 관리 및 운영
• 그룹웨어 전자결재 관리 및 운영
• 그룹웨어 자료실 관리 및 운영
• 그룹웨어 공지사항 관리 및 운영
• 그룹웨어 시스템 오류 수정 및 개발

 

– 관련 보고서 작성 및 정리

 

 

 

[출처] http://www.sharedit.co.kr/%EC%A0%84%EC%82%B0%EC%8B%A4-%ED%95%A0%EC%9D%BC-%EB%A7%8E%EC%95%84%EC%9A%94-%EC%A0%84%EC%82%B0%EC%97%85%EB%AC%B4-%EB%A6%AC%EC%8A%A4%ED%8A%B8/

 

http://pino93.tistory.com/373

 

 

 

SQLCODE, SQLERRM

-       WHEN OTHERS문으로 트랩(Trap) 되는 오류들의 실제 오류 코드와 설명을 볼 때 사용한다

-       SQLCODE : 실행된 프로그램이 성공적으로 종료하였을 때는 오류번호 0을 포함하며, 그렇지 못할 경우에는 해당 오류코드 번호를 포함한다.

-       SQLERRM : SQLCODE에 포함된 오라클 오류 번호에 해당하는 메시지를 가진다

 

SQLCODE Value	Description
0	오류 없이 성공적으로 종료
1	사용자 정의 예외 번호
+100	DATA NOT FOUND 예외 번호
음수	위의 부분을 제외한 오라클 서버 에러 번호

 

  ================================================
    * Oracle Community OracleClub.com
    * http://www.oracleclub.com
    * http://www.oramaster.net
    * 운영자 : 김정식 (oramaster _at_ empal.com)
  ================================================ 

 

 

 

 

◆ MERGE INTO 구문

 

 - MERGE문은 조건에 따라서 데이터의 삽입,갱신,삭제 작업을 한번에 할 수 있다.
 - 해당 행이 존재하는 경우 UPDATE(DELETE포함 할 수 있음)를 수행하고, 새로운 행일경우 INSERT를 수행한다.
 - 대상 테이블에 대한 UPDATE/INSERT 조건은 ON절에 의해 결정된다.
 - MERGE문에서 CLOB 사용시 업데이트 할 내용이 2000bytes가 넘을때 ORA-00600 오류가 발생하며, patch set 11.2.0.2 버전으로 해결할 수 있다.

 

 

◆ 문법

 

MERGE INTO 테이블 a               -- update또는 insert할 테이블

       USING 대상테이블/뷰 b      -- 비교대상 (동일 테이블이라면 using dual 사용)

           ON (조건)                   -- a와 b의 조인식

        WHEN MATCHED THEN

                  UPDATE SET

                              컬럼1 = 값1

                              컬럼2 = 값2

                  DELETE WHERE (조건)

        WHEN NOT MATCHED THEN

                  INSERT(컬럼1, 컬럼2...)

                  VALUES(값1, 값2...)

 

 - INTO : DATA가 UPDATE되거나 INSERT 될 테이블 또는 뷰를 지정.
 - USING : 비교할 SOURCE 테이블 또는 뷰나 서브쿼리를 지정, INTO절의 테이블과 동일하거나 다를 수 있다.
 - ON : UPDATE나 INSERT를 하게 될 조건으로, 해당 조건을 만족하는 DATA가 있으면 WHEN MATCHED 절을 실행하게 되고, 없으면 WHEN NOT MATCHED 이하를 실행하게 된다.
 - WHEN MATCHED : ON 조건절이 TRUE인 ROW에 수행 할 내용 (UPDATE, DELETE포함 될 수 있음)
 - WHEN NOT MATCHED : ON 조건절에 맞는 ROW가 없을 때 수행할 내용 (INSERT)

 

※ 오라클 9버전이상에서 사용가능하다.

 

 

◆ SAMPLE

 

MERGE INTO STO_TEMP1 T1
     USING (SELECT EBELN, EBELP
              FROM STO_TEMP
             WHERE EBELN = '4501134859' AND EBELP = '00010') T
        ON (T1.EBELN = T.EBELN AND T1.EBELP = T.EBELP)
WHEN MATCHED
THEN
   UPDATE SET T1.MBLNR = T.MBLNR, T1.BUDAT = T.BUDAT
   DELETE
           WHERE T1.MBLNR = '4926768928'
WHEN NOT MATCHED
THEN
   INSERT     (T1.EBELN,
               T1.EBELP,
               T1.MBLNR,
               T1.BUDAT)
       VALUES (T.EBELN,
               T.EBELP,
               T.MBLNR,
               T.BUDAT)

 

 

1. 16진수 -> 10진수

 

SELECT  TO_CHAR(15,'0X'), TO_CHAR(16,'0X'), TO_CHAR(17,'0X') 
  FROM  DUAL;

 >> OF   10   11

 

SELECT  TO_CHAR(15,'000X'), TO_CHAR(16,'000X'), TO_CHAR(17,'000X') 
  FROM  DUAL;

 >> 000F   0010   0011

 

 

2. 10진수 -> 16진수

 

SELECT  TO_NUMBER('F', 'XX'), TO_NUMBER('10', 'XX'), TO_NUMBER('11', 'XX') 
  FROM  DUAL;

 >> 15   16   17

 

 

SELECT  S.FIRST_LOAD_TIME, TO_CHAR(S.BUFFER_GETS,'999,999,999,990') BUFFER_GETS,

              S.DISK_READS, S.ROWS_PROCESSED, S.EXECUTIONS,
              SUBSTR(U.NAME,1,1) USERNAME, S.MODULE, S.SQL_TEXT
   FROM  V$SQLAREA S, SYS.USER$ U
 WHERE  S.PARSING_USER_ID = U.USER#
     AND  U.NAME <> 'SYS'
     AND  S.DISK_READS > 10000
     AND  S.FIRST_LOAD_TIME >= TO_CHAR(SYSDATE,'yyyy-mm-dd')||'/00:00:00'
 ORDER BY  S.FIRST_LOAD_TIME DESC;

 

1. 파일 경로 문제

1. Before SQL & Plan

 

:

  UNION ALL
  SELECT  A.OWNERID,
                A.CUSTID OWNERCUSTID,

:

 

Call     Count CPU Time Elapsed Time       Disk      Query    Current       Rows
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Parse        1    0.320        0.318          0          9          0          0
Execute      1    0.000        0.000          0          0          0          0
Fetch        2   38.670      854.077     357665    2669098          0          2
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Total        4   38.990      854.396     357665    2669107          0          2

 

 

1.1 문제점 및 해결책

  - UNION ALL의 두번째 SQL 집합에서 TPURCHASEORDERHI 테이블 ACCESS시 데이터 필터링이 제대로 이루어 지지 않아 조인시 성능저하 현상 발생
  - TTASKTRANS 테이블이 leading 될 수 있도록 힌트 적용하여 성능개선(854s -> 1s)

 

 

2. After SQL & Plan

 

:

  UNION ALL
  SELECT  /*+ LEADING(TT) */ A.OWNERID,
                A.CUSTID OWNERCUSTID,

:

     FROM  TTASKTRANS TT,

:

 

Call     Count CPU Time Elapsed Time       Disk      Query    Current       Rows
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Parse        1    0.380        0.375          0          6          0          0
Execute      1    0.000        0.000          0          0          0          0
Fetch        2    0.510        0.511          0     114195          0          2
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Total        4    0.890        0.887          0     114201          0          2

 

 

◆ 개요
힌트는 SQL 튜닝의 핵심부분으로 일종의 지시구문이다.
SQL에 포함되어 쓰여져 Optimizer의 실행 계획을 원하는 대로 바꿀 수 있게 해준다.
오라클 Optimizer라고 해서 항상 최선의 실행 계획을 수립할 수는 없으므로 테이블이나 인덱스의 잘못된 실행 계획을 개발자가 직접 바꿀 수 있도록 도와주는 것이다.
사용자는 특정 SQL 문장에서 어떤 인덱스가 선택도가 높은지에 대해 알고 있는데 이 경우 오라클 서버의 Optimizer에 의존하여 나온 실행 계획보다 훨씬 효율적인 실행 계획을 사용자가 구사할 수 있다.
 
 
◆ 사용
힌트를 사용하여 아래와 같은 것들을 할 수 있다.
액세스 경로, 조인 순서, 병렬 및 직렬 처리, Optimizer의 목표(Goal)를 변경 가능하다.
 
 
◆ 오라클 힌트 사용예
 SELECT /*+ INDEX(idx_col1) */
             id, password, name
  FROM emp;
 SELECT /*+ ORDERED  INDEX(b idx_col1) */
             id, password, name
  FROM emp a
         , depart b
※ 주의! 주석 표시 뒤에 '+' 기호가 있다.

 

 

◆ INDEX Access Operation 관련 HINT

HINT	내용	사용법
INDEX	INDEX를 순차적으로 스캔	INDEX(TABLE_name, INDEX_name)
INDEX_ASC	INDEX를 내림차순으로 스캔.
INDEX_DESC	INDEX를 오름차순으로 스캔.	INDEX_DESC(TABLE_name, INDEX_name)
INDEX_FFS	INDEX FAST FULL SCAN	INDEX_FFS(TABLE_name, INDEX_name)
PARALLEL_INDEX	INDEX PARALLEL SCAN	PARALLEL_INDEX(TABLE_name, INDEX_name)
NOPARALLEL_INDEX	INDEX PARALLEL SCAN 제한	NOPARALLEL_INDEX(TABLE_name, INDEX_name)
AND_EQUALS	여러개의 INDEX MARGE 수행	AND_EQUALS(INDEX_name, INDEX_name)
FULL	FULL SCAN  지정된 테이블에 대한 전체 스캔.	FULL(TABLE_name)

 

 

◆ JOIN Access Operator 관련 HINT

HINT	내용	사용법
USE_NL	NESTED LOOP JOIN  옵티마이저가 NESTED LOOP JOIN을 사용하도록 한다.  먼저 특정 TABLE의 ROW에 액세스하고 그 값에 해당하는 다른 TABLE의 ROW를 찾는 작업을 해당범위까지 실행하는 조인.	USE_NL(TABLE1, TABLE2)
USE_NL_WITH_INDEX	INDEX를 사용해서 NESTED LOOP JOIN을 사용하도록 한다.	USE_NL_WITH_INDEX(TABLE  INDEX)
USE_MERGE	SORT MERGE JOIN  옵티마이저가 SORT MERGE JOIN을 사용하도록 한다.  먼저 각각의 TABLE의 처리 범위를 스캔하여 SORT한 후, 서로 MERGE하면서 JOIN하는 방식.	USE_MERGE(TABLE1, TABLE2)
USE_HASH	HASH JOIN  옵티마이저가 HASH JOIN을 사용하도록 한다.	USE_HASH(TABLE1, TABLE2)
HASH_AJ	HASH ANTIJOIN	HASH_AJ(TABLE1, TABLE2)
HASH_SJ	HASH SEMIJOIN	HASH_SJ(TABLE1, TABLE2)
NL_AJ	NESTED LOOP ANTIJOIN	NL_AJ(TABLE1, TABLE2)
NL_SJ	NESTED LOOP SEMIJOIN	NL_SJ(TABLE1, TABLE2)
MERGE_AJ	SORT MERGE ANTIJOIN	MERGE_AJ(TABLE1, TABLE2)
MERGE_SJ	SORT MERGE SEMIJOIN	MERGE_SJ(TABLE1, TABLE2)

 

 

◆ JOIN시 DRIVING 순서 결정 HINT

HINT	내용	사용법
ORDERED	FROM절에 명시된 테이블의 순서대로 DRIVING
LEADING	파라미터에 명시된 테이블의 순서대로 JOIN	LEAING(TABLE_name1, TABLE_name2, ...)
DRIVING	해당 테이블을 먼저 DRIVING	DRIVING(TABLE)

 

 

◆ 기타 HINT

HINT	내용	사용법
APPEND	INSERT시 DIRECT LOADING
PARALLEL	SELECT, INSERT시 여러개의 프로세스로 수행	PARALLEL(TABLE, 개수)
CACHE	데이터를 메모리에 CACHING
NOCACHE	데이터를 메모리에 CACHING하지 않음
PUSH_SUBQ	SUBQUERY를 먼저 수행
REWRITE	QUERY REWRITE 수행
NOREWIRTE	QUERY REWRITE를 수행 못함
USE_CONCAT	IN절을 CONCATENATION ACCESS OPERATION으로 수행
USE_EXPAND	IN절을 CONCATENATION ACCESS OPERATION으로 수행못하게 함
MERGE	VIEW MERGING 수행
NO_MERGE	VIEW MERGING 수행못하게 함

 

※ 추가
ALL_ROWS : 가장 좋은 단위 처리량의 목표로 문 블록을 최적화하기 위해 cost-based 접근 방법을 선택합니다. (즉, 전체적인 최소의 자원 소비, 모든 레코드의 처리하는 시간의 최소화를 목적으로 최적화)

FIRST_ROWS : 가장 좋은 응답 시간의 목표로 문 블록을 최적화하기 위해 cost-based 접근 방법을 선택합니다. (첫번째 레코드의 추출 시간을 최소화할 목적으로 최적화)

CHOOSE : 최적자(optimizer)가 그 문에 의해 접근된 테이블을 위해 통계의 존재에 근거를 두는 SQL문을 위해

 

rule-based 접근 방법과 cost-based 접근 방법 사이에 선택하게 됩니다.

CLUSTER : 지정된 테이블에 대한 클러스터 스캔.

HASH : 지정된 테이블에 대한 해쉬 스캔.

ROWID : 지정된 테이블에 대한 ROWID에 의한 테이블 스캔.

RULE : explicitlly chooses rule-based optimization for a statement block. rule-base Optimizer를 사용.

 

 

◆ 주의
 SELECT /*+ ORDERED USE_NL(A B C) INDEX(B ITOREDRETL1) */
    FROM TORDERDTL  B, TORDER  A, TITEM  C
  WHERE ...
1. ORDERED : FROM 절에 기술한 테이블 순(B → A → C 순)으로 조인함. USE_NL에 사용한 순서가 아님.
    ※ 참고) LEADING, 예) LEADING(B) : FROM 절의 기술 순서와 상관없이 B테이블이 가장 먼저 선행됨.
2. USE_NL : 조인방법을 Nested Loops방식으로 선택.
    예) USE_NL(A B), 테이블명이 아닌 테이블에 대한 Alias명
    참고) USE_HASH, USE_MERGE
3. INDEX : 특정 인덱스를 오름차순으로 읽음.
    예) INDEX(B  ITORDERDTL1) : B는 TORDERDTL 테이블의 Alias명, 사용할 인덱스명 기술
    참고) USE_DESC(B ITORDERDTL1) : ITORDERDTL1 인덱스를 내림차순으로 읽음
 

◆ 실행계획 살펴보기 1
 SELECT *
    FROM ( ==> 인라인뷰 3
                ( ==> 인라인뷰 2
                   ( ==> 인라인뷰 1
                   )
                )
              )
과 같이 되어 있다고 하자.
이럴 경우 실행계획을 보면, 우리가 예상했던대로 인라인뷰1 ==> 인라인뷰2 ==> 인라인뷰3 순서로 드라이빙 되지 않는 경우가 있다.
이런 경우 강제로 위 순서대로 실행계획을 수립하도록 하는 힌트
SELECT /*+ ORDERED */
            *
  FROM ( .....
위 힌트를 사용하면 맨 깊숙한 인라인뷰부터 실행된다.
 
 
◆ 힌트 사용하기
1. /*+ USE_CONCAT */
USE_CONCAT : 조건절에 있는 OR 연산자조건 (또는 IN 연산자 조건)을 별도의 실행단위로 분리하여 각각의 최적의 액세스 경로를 수립하여 이를 연결(Concatenation)하는 실행계획을 수립하도록 유도하는 힌트.
반드시 처리주관 조건이 OR로 나누어졌을 때 적용해야 하며, 잘못 사용하면 비효율이 발생할 수 있으므로 주의해야 함.
예>
SELECT /*+ USE_CONCAT */
   FROM employees
 WHERE job = &job
       OR dept_no = &deptno;
풀어쓰자면
SELECT *
    FROM employees
  WHERE job = &job
UNION ALL
SELECT *
    FROM employees
WHERER dept_no = &deptno;
WHERE 절 이후에 나오는  컬럼에 맞게 인덱스를 탄다.
 
2. /*+ NO_EXPAND */
조건절에 있는 OR 연산자 조건 또는 IN 연산자 조건을 연결 실행계획으로 처리되지 않도록 할 때 사용하는 힌트.
USE_CONCAT의 반대 개념.
예>
SELECT /*+ NO_EXPAND */
   FROM customer
 WHERE cust_type in ('A','B');
참고 : http://blog.naver.com/hkjhc107?Redirect=Log&logNo=130035827974


◆ 참고
1. Nested Loop
   - 테이블의 인덱스끼리 inner-outer 루프를 형성하여 결과를 쿼리하는 방식입니다.
   - 제일 많은 유형의 실행계획입니다.
2. Sort Merge
   - 쿼리의 결과가 많은 양의 데이터를 읽는 경우, 테이블들을 각각 full-scan하여 같은 키값을 갖는 데이터끼리 조인하여 실행합니다.
   - Sort-Merge 방식은 많은 메모리와 디스크 I/O를 필요로 하기 때문에, sqlplus를 실행하는 주체의 메모리/CPU/디스크 스펙에 많은 영향을 받습니다.
3. Hash Join
   - 한 테이블은 매우 많은 Row를 갖고, 다른 한 테이블은 매우 적은 Row를 가질 때, 해쉬 알고리즘에 의해 큰 테이블을 여러개의 버켓으로 나누어 쿼리를 수행하는 방식입니다. 작은 테이블은 인덱스를 태우는 것보다 full-scan을 하는 것이 유리할 때 사용됩니다.

 

 

1. Before SQL & Plan

 

               TITEMPACK B,
               TPURCHASEORDERHI C
  WHERE  C.OWNERID = '1101'
      AND  C.CUSTID IN (SELECT  OWNERCUSTID
                                      FROM   TOWNERCUSTOMER
                                    WHERE  OWNERID = '1101'
                                        AND   CUSTID = '137490')
      And  a.OwnerID = c.OwnerID

 

Call     Count CPU Time Elapsed Time       Disk      Query    Current       Rows
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Parse        1    0.030        0.014          0          0          0          0
Execute      1    0.000        0.000          0          0          0          0
Fetch        2   86.410     1154.691     727343    7614453          0          1
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Total        4   86.440     1154.705     727343    7614453          0          1

 

 

1.1 문제점 및 해결책

  - c.custid 조건절에 사용 되어지는 SUBQUERY에서 TPURCHASEORDERHI 테이블 액세스 시 성능저하가 발생하여 SubQuery를 인라인뷰로 변경하여 조인하는 방식으로 튜닝하여 성능개선
 

2. After SQL

 

               TITEMPACK B,
               TPURCHASEORDERHI C,
               (SELECT OWNERCUSTID
                FROM   TOWNERCUSTOMER
                WHERE  OWNERID = '1101'
                AND    CUSTID = '137490') D
  WHERE  C.OWNERID = '1101'
       AND  C.CUSTID = D.OWNERCUSTID
       AND  A.OWNERID = C.OWNERID

Call     Count CPU Time Elapsed Time       Disk      Query    Current       Rows
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Parse        1    0.010        0.011          0          0          0          0
Execute      1    0.000        0.000          0          0          0          0
Fetch        2    0.020        0.019          0       4245          0          1
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Total        4    0.030        0.030          0       4245          0          1

 

 

1. before SQL & plan

DELETE      TIMAGECOMPLETE
      WHERE (OWNERID, ORDERID) IN (
               (SELECT OWNERID, ORDERID
                  FROM TIMAGECOMPLETE
                INTERSECT
                SELECT OWNERID, ORDERID
                  FROM TTASKTRANSHI)
               MINUS
               SELECT OWNERID, ORDERID
                 FROM TTASKTRANS)
Execution Plan
--------------------------------------------------------------------------------
   0      DELETE STATEMENT Optimizer=CHOOSE (Cost=260K Card=3K Bytes=108K)
   1    0   DELETE OF 'TIMAGECOMPLETE'
   2    1     NESTED LOOPS (Cost=260K Card=3K Bytes=108K)
   3    2       VIEW OF 'SYS.VW_NSO_1' (Cost=260K Card=3K Bytes=62K)
   4    3         MINUS
   5    4           INTERSECTION
   6    5             SORT (UNIQUE) (Card=3K Bytes=46K)
   7    6               INDEX (FAST FULL SCAN) OF 'TIMAGECOMPLETE_PK' (UNIQUE) (Cost=3 Card=3K Bytes=46K)
   8    5             SORT (UNIQUE) (Card=32M Bytes=549M)
   9    8               TABLE ACCESS (FULL) OF 'TTASKTRANSHI' (Cost=133K Card=32M Bytes=549M)
  10    4           SORT (UNIQUE) (Card=378K Bytes=6M)
  11   10             TABLE ACCESS (FULL) OF 'TTASKTRANS' (Cost=2K Card=378K Bytes=6M)
  12    2       INDEX (UNIQUE SCAN) OF 'TIMAGECOMPLETE_PK' (UNIQUE) (Card=1 Bytes=18)
 

1.1 문제점 및 해결책

  - INTERSECT 와 MINUS 인해 TTASKTRANSHI, TTASKTRANS 테이블에 대해  full table scan이 발생하여 성능저하 현상이 발생과 동시에 Lock holding이 발생함.
  - INTERSECT와 MINUS를 join 및 not exists로 변경하여 성능개선 가능.
  - 업무담당자와 협의 및 데이터 검증 필요.
  
 
2. After SQL & plan

DELETE      TIMAGECOMPLETE
      WHERE (OWNERID, ORDERID) IN (
               SELECT A.OWNERID, A.ORDERID
                 FROM TIMAGECOMPLETE A, TTASKTRANSHI B
                WHERE 1 = 1
                  AND A.OWNERID = B.OWNERID
                  AND A.ORDERID = B.ORDERID
                  AND NOT EXISTS (
                         SELECT 1
                           FROM TTASKTRANS C
                          WHERE 1 = 1
                            AND A.OWNERID = C.OWNERID
                            AND A.ORDERID = C.ORDERID))
                       
Execution Plan
--------------------------------------------------------------------------------
   0      DELETE STATEMENT Optimizer=CHOOSE (Cost=8K Card=1 Bytes=42)
   1    0   DELETE OF 'TIMAGECOMPLETE'
   2    1     MERGE JOIN (SEMI) (Cost=8K Card=1 Bytes=42)
   3    2       INDEX (FULL SCAN) OF 'TIMAGECOMPLETE_PK' (UNIQUE) (Cost=12 Card=3K Bytes=46K)
   4    2       SORT (UNIQUE) (Cost=8K Card=2M Bytes=37M)
   5    4         VIEW OF 'SYS.VW_NSO_1' (Cost=5M Card=2M Bytes=37M)
   6    5           FILTER
   7    6             NESTED LOOPS (Cost=136 Card=2M Bytes=55M)
   8    7               INDEX (FAST FULL SCAN) OF 'TIMAGECOMPLETE_PK' (UNIQUE) (Cost=3 Card=132 Bytes=2K)
   9    7               INDEX (RANGE SCAN) OF 'TTASKTRANSHI_IDX02' (NON-UNIQUE) (Cost=3 Card=12K Bytes=214K)
  10    6             INDEX (RANGE SCAN) OF 'TTASKTRANS_IDX02' (NON-UNIQUE) (Cost=3 Card=1 Bytes=18)