Oracle Application Turning
since June 24, 1999 last modified July 2, 1999, woriking
Turning 규칙 (SQL 문 및 Oracle Application 개발시)
- Turning에 들어가기 전에 충분한 계획하에서 Application을 개발하는 것이 중요하다. 예 1에서 보는 바와 같이 SQL 문장이전에 전처리 방법, Application의 구조등이 훨씬 Performance에 영향을 미칠 수 있다.
- 불필요한 Join은 제거한다. 이는 Join에 참여하는 Table 수도 감소시킨다.
- 검색 대상 Table 및 Record를 가능하면 줄인다. (=> Query의 설계를 철저히 한다.)
- TABLE의 Attribute Type에 맞는 Where 절을 구성하라.
(예) WHERE ID = '021A' (ID 는 RAW Type) - TABLE의 Attribute Type에 맞는 Host variable을 사용하라.
(예) EXEC SQL VAL variable IS RAW() 을 사용 Type Equivalancing - TABLE의 Attribute Type에 맞는 Oracle Function을 사용하라.
(예) SUBSTR()은 Character Type 용이므로 RAW Type에 사용하면 속도가 느려진다. 이때는 SUBSTRB() 를 사용한다.
Turning 예
1) 1999.5.1 VPM DB내에 Part Assy 관계 및 관련 Option Effectivity 생성
상황 : 17만개의 Part Master는 입력되었고 Part 사이의 Assy 관계가 4개 모델, 각기 4개 관계(3 개 Configuration과 Part 사이의 관계)를 가진 16개의 PC Database file형태로 입력되었다. 이를 Oracle VPM DB에 필요한 Record와 ID를 생성하는 Application Program을 작성하였다.
오류 및 개선 : 16 개의 File에는 공유되는 Assy 관계가 존재하므로 4 개 모델의 Table을 Union 하고 중복을 피하여 (SQL Order by와 간단한 Application으로 동일한 Record를 Skip) Application 작성한 결과 16개 File 에 대한 Application 실행이 4 개로 축소되었고 시간은 16*3시간 = 48 시간이 약 30분으로 축소되었다. => 중복된 입력정보를 사전에 처리해주는 것의 중요성
2) 1999.6.24 기존 VPM DB에서 특정 Effectivy와 ASS관계 제거 App 개발
상황 :십만단위 Record를 가진 데이타베이스에서 총 3개의 Table을 이용하여 필요한 Migration 용 자료를 추출하는 Application을 작성하였다. 정의된 자료는 특정상 Oracle Raw Type을 Key로 조인해야 하는 상황이었다.
- 오류 1 : 두개이상의 Join 연결로 중복된 Instance 가 생겼다. 최악의 경우 불필요한 검색을 4회 반복하게 되었다. (불필요한 Join 제거후 시간 1/4 로감소)
- 오류 2 : 검색 대상의 선택 - 검색대상을 잘못선택하여 15000 개의 검색대상이 50000 개로 확장되었으며 검색에 대한 변경 실행시 치명적 오류가 될수 있었다 (시간 1/3으로 감소).
- 오류 3 : Oracle Application 상에서 Raw Type attribute 값을 Character Type으로 관리하여 약 1.5배의 시간이 더 소요되었다 (EXEC SQL VAL variable IS RAW() 사용후 응용 프로그램 속도 증가).
- 오류 4 : Row Type에 String Type 함수를 적용함에 따라 많은 시간이 소요되었으며 System Table Space 부족 Error를 발생시켰다 (SUBSTR()을 SUBSTRB()로 변경후 속도 증가).
결과 : 최초 실행결과 18 시간예측, 오류 1, 2 수정후 8시간 예측, 오류 수정후 4시간 예측
Knowledge and Engineering Databases © copyright Namchul Do, 1999