Upgrade ODI from 10g to 11g.
ODI Upgrade 절차 및 고려사항 정리.
on 2012.10.16
Written by Jeonghyeon, Cheon.
1. Literal SQL 오류 쿼리 정리
A. SQL 특성에 따른 해결 방안
|
Sql 대분류 |
설명 |
Sql 소분류 |
설명 |
해결 방안 |
|
Internal SQL |
ODI 솔루션이 내부적으로 수행하는 쿼리 |
N/A |
N/A |
11.1.1.6.4 버전 업그레이드 진행 후, 발생 빈도 확인 |
|
ODI 구현 SQL |
ODI를 사용하여 사용자가 구현한 쿼리 |
배치 SQL |
Interface, Procedure 등으로 구성된 ETL 작업 |
ETL 작업을 수정 |
|
ODI 구현 SQL |
상동 |
Procedure SQL |
Log 작업등과 같이 ETL 작업 선 후행으로 수행하여야 하는 작업을 프로시저를 사용하여 구성한 경우 |
Oracle Stored Procedure로 변환 |
|
ODI 구현 SQL |
상동 |
변수 새로고침 SQL |
변수의 값을 리턴 받아 오기 위한 select statement |
모름 |
B. 문서 관리 사항
|
번호 |
쿼리 |
사용 분류 |
사용 목적 |
발생 빈도 |
해결 가능 여부 |
해결 방법 |
변경 쿼리 |
관련 패키지 명 |
관련 시나리오 명 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. ODI Upgrade
A. 분석
i. 프로시저 및 변수 리스트 작성
|
분류 |
사용유무 |
사용목적 |
관련테이블 |
타겟 스키마 |
타겟 테이블 |
사용 방법 |
Literal 대상 여부 |
변경 유무 |
변경 쿼리 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ii. 이외 별도 작업 유무 확인
1. ODI 함수( ODI Package에서 수행하는 함수들 중 기존 운영에 영향을 줄 수 있는 사항이 없는지 확인 필요)
2. System Command 호출(시스템 명령 호출하는 경우 기존 운영작업에 영향을 줄 수 있는 사항이 있는지 확인 필요)
iii. Interface 작업 흐름도 확인
1. 기존 산출물 참조
B. 설계
i. 개발 환경
1. 개발 방안
|
번호 |
구성 방안 |
시스템 |
리포지토리 |
소스 스키마 |
작업 스키마 |
타겟 스키마 |
장점 |
단점 |
|
1 |
스키마 분리 |
동일 |
시스템 + 스키마 or 스키마 분리 |
그대로 사용 |
스키마 분리 |
스키마 분리 |
환경 구성시 작업 최소화 |
운영에 영향을 안주기 위해 검토, 또 검토하여야함 |
|
2 |
시스템 일부 분리 |
분리 |
시스템 + 스키마 or 스키마 분리 |
그대로 사용 |
시스템 + 스키마 분리 |
시스템 + 스키마 분리 |
타겟 스키마 분리 |
작업 수행 방법(KM)이 달라져야 할 수 있음 |
|
3 |
시스템 전체 분리 |
분리 |
시스템 + 스키마 or 스키마 분리 |
시스템 + 스키마 분리 |
시스템 + 스키마 분리 |
시스템 + 스키마 분리 |
운영 영향 없음 |
시간 소요 젤 큼 |
2. Upgrade & 검증 관련 스키마 정리
|
종류 |
스키마 분류 |
스키마 상세 분류 |
존재 여부 |
|
ODI Upgrade |
Repository 계정 |
Master Repository |
O |
|
ODI Upgrade |
Repository 계정 |
Work Repository |
O |
|
작업 검증 |
작업 & 접속 계정 |
Work Schema |
O |
|
작업 검증 |
타겟 계정 (데이터 적재 기준) |
DW Schema |
O |
|
작업 검증 |
타겟 계정 (데이터 적재 기준) |
DM Schema |
Possible |
C. ODI Upgrade 예상 절차
i. Repository User 생성
ii. Repository 데이터 Export & Import
iii. ODI 접속 테스트
1. Topology - 저장소 정보 수정
수정하지 않을 경우, 기존 저장되어 있는 상용 시스템에 영향을 줄 수 있으므로 반드시 수정하도록 한다.
2. Agent IP 정보 임시 삭제
iv. Upgrade 진행
v. 툴 업그레이드 설치
1. 11.1.1.6.4
2. 설치 방법
A. 리눅스 Silent Mode 설치
B. 윈도우 설치 후 Copy
vi. Repository Upgrade
1. UA.bat
vii. ODI 접속 테스트
* 전 후를 비교할 수 있는 대상을 몇개 잡아 정상적으로 Migration 되었는지 확인하는 기준으로 사용한다.
D. 검증을 하기 위한 환경 구성
i. ODI 시스템&스키마 추가
ii. ODI Context 추가
iii. 일정 등록 전체 삭제 or 비활성화
iv. 11g Agent 활성화
1. IP & Port 변경 시 방화벽 제거 작업 필요
E. 검증 방법
i. 전체 검증 후 전체 스위치
1. 전체를 검증한 후 한꺼번에 이관 작업 수행
2. 작업량을 최소화 할 수 있다.
3. 기존 작업으로 원복에 대한 방법을 논의 해 보아야 한다.
ii. 특정 작업 단위로 검증 후 스위치
1. 시나리오 기준으로 검증하여 검증된 경우 하나씩 이관 작업 수행
2. 일정한 속도로 작업 수행 가능
3. 오류가 발생했을 경우 원복으로 빠른 대처가 가능
4. 공통적으로 사용하는 Procedure 및 변수에 대한 작업 방법 고려
F. 검증 절차
i. 사전 확인 사항
1. 상용 시스템 영향도 파악
2. 프로시져, 변수, 타겟 테이블
3. 변경 사항 적용 여부 확인
4. Literal SQL 오류 대상 작업
5. 선 후행 단계 파악
ii. 테스트 단위
1. Scenario 단위
2. Package 단위
3. Interface 단위
iii. 검증 방안
1. 쿼리 비교
A. 시뮬레이션만으로도 가능
B. 별도로 검증 환경 구성할 필요 없을 듯?
2. 데이터 비교
A. 건수 비교
B. 데이터 상세 비교
iv. 검증 후 변경 작업
1. 변수 및 프로시저 적용
2. 변경된 경우 시나리오 재생성 고려
3. 일정 등록 or 활성화
4. 로그 확인
3. 그 외 고려 사항
A. Upgrade에 따른 추가 Object 사용 여부
i. Load Plan(작업 흐름 관리 객체)
1. 작업의 선 후행 관계 설정 가능
2. 기존 package의 일부 대체 가능할 것으로 보임
ii. Sub-Select(서브쿼리 구현 부분)
1. 하나의 인터페이스로 작업 가능
2. Interface 일부 제거가 가능할 것으로 보임
2012.11.17
Work process upgrading ODI from 10g to 11g.
1. ODI Upgrade
- DB 계정 생성(Master & Work Repository)
- Local 에 Import 후 UA 진행하여 Upgrade 수행
- Upgrade 된 데이터를 Export & Import 진행
2. 검증
- 쿼리 검증
* 시나리오 별 전체 작업을 Interface 사용 KM, 패키지 구성 요소 별로그루핑하여 대표 작업 별로 쿼리 검증 수행
* 검증 수행 이유: Upgrade 후 작업이 이상 없이 같은 명령어를 출력하는지 확인
- 건수 검증
* 시나리오 별 전체 작업을 패키지 프로세스(로직) 별로 그루핑하여 대표 작업 별로 테스트 계정의 테이블에 데이터 적재후 검증 수행
* Context 변경을 통해 작업을 최소화 할 수 있는 환경을 구성한 후 진행
* 검증 수행 이유: Upgrade 후 작업 프로세스가, 특히, 선후행 로직에 의한 변수 값 설정이 이상없이 수행되어 기존과 같은 로직을 수행하는지 데이터 적재와 로그 삽입 내역을 확인
3. 이관
- 일정 시나리오 별로 이관하면서 모니터링 수행
- Operator 와 별도의 로깅 방법을 통해 이슈 발생 여부를 추적하고 그에 따른 적절한 대처 수행