회사에서 개발 중인 애플리케이션은
DB2®에 대해 실행 중인 GSDB 데이터베이스에 대해
정적으로 SQL을 실행해야 합니다. 이 레슨에서는 Inventory_LevelsData 인터페이스에 있는
SQL문을 바인드하여 정적으로 실행합니다.
정적 SQL은 다음과 같은 이점을 제공합니다.
- 동적문 캐시 방지
- 정적 SQL 사용은 동적 SQL을 사용하는 애플리케이션의 성능을 향상시켜 DB2의 동적문 캐시 경쟁을 줄입니다.
- 액세스 경로 일관성
- 정적 SQL은 애플리케이션을 실행하기 전에 액세스 경로를 잠금으로써 응답 시간을 예측 가능하게 하며 안정되게 합니다. 반대로,
동적 SQL의 액세스 경로는 런타임 시 계산됩니다.
- 애플리케이션의 성능 향상 가능성
- 동적 SQL은 애플리케이션의 성능을 향상시킬 수 있습니다.
- 액세스 플랜은 런타임 이전에 판별되므로 런타임 시 SQL문을 준비하지 않아도 됩니다.
- 각 명령문을 준비하고 설명할 필요가 없기 때문에,
클라이언트 애플리케이션과 데이터베이스 서버 간에 네트워크 트래픽이 저하됩니다.
- 정적 SQL은 술어에 사용되는 호스트 변수 또는 매개변수에 대한
데이터 유형을 엄격하게 적용합니다. 엄격하게 적용하므로
데이터베이스에서 입력 데이터가 목표 유형과 일치하게 됩니다.
- 보다 엄격한 보안
- 사용자에게 데이터베이스 오브젝트에서의 특권을 부여하지 않고 DB2 패키지에서의 EXECUTE 특권을
부여할 수 있습니다.
- 쉬운 패키지 수정
- DB2 패키지를 버전화하여
이전의 좋은 액세스 경로를 유실하지 않고 패키지를 리바인드할 수 있습니다.
Inventory_LevelsData 인터페이스에 있는
SQL문을 바인드하여 정적으로 실행하려면 다음을 수행하십시오.
- 패키지 탐색기에서, pureQuery_test Java 프로젝트에 있는
pureQueryFolder 폴더에서 Default.genProps 파일을 찾으십시오(). 파일을 더블 클릭하여 편집을 위해 여십시오.
- Default.genProps 파일의 공백 라인에서
인터페이스의 이름과 패키지를 지정하십시오. 사용자가 수동으로 패키지 및 이름을 입력하거나 pureQuery가
사용자를 도울 수 있습니다. pureQuery가 돕도록 하려면
다음을 수행하십시오.
- CTRL 키를 누른 상태에서 스페이스바를 누르십시오. 작은 창이 열립니다.
그림 1. Java 프로젝트의
인터페이스를 나열하는 pureQuery
- 공백 라인에 이름을 포함시킬 인터페이스의 이름을
더블 클릭하십시오.
- 라인이 다음과 유사하도록 공백, 등호 및 다른 공백을
입력하십시오.
com.mycompany.pureQuery.test.InventoryLevelsData =
- 콜렉션의 이름과 루트 패키지 이름을 설정하기 위해 사용할 수 있는
옵션을 판별하십시오. CTRL 키를 누른 상태에서 스페이스바를 누르십시오. 또 다른 작은 창이 열립니다.
팁: 옵션을 클릭할 때 설명이 목록 옆에
나타납니다. 설명을 클릭하고 노란색 창의 맨 아래에 있는 스크롤 막대를
사용하여 전체 텍스트를 볼 수 있습니다.
그림 2. Default.genProps 파일에서 인터페이스에 지정할 수 있는 옵션
- 다음과 유사하도록 라인을 완성하십시오.
com.mycompany.pureQuery.test.InventoryLevelsData = -collection "GOSALES" -rootPkgName "invlevl"
- 파일을 저장하고 나타나는 메시지에 대해 예를
클릭하십시오. pureQuery는 사용자가 Default.genProps 파일에서 입력한
값을 인터페이스에 대한 구현 클래스에 저장해야 합니다.
인터페이스에 있는 SQL을 바인드할 때 pureQuery의
StaticBinder 유틸리티는 데이터베이스 패키지를 작성하는 방법을
파악하기 위해 구현 클래스에서 해당 값을 찾습니다.
- 작성하려고 하는 패키지의 구조를 검토하십시오. SQL 아웃라인 보기에서 데이터베이스
패키지 탭을 클릭하십시오.
팁: SQL 아웃라인 보기가 계속
테이블로 배열된 성능 데이터를 계속 표시하는 경우
트리 보기 또는
테이블 보기 표시 단추(

)를 클릭하십시오.
보기에는 하나의 패키지만 나타나지만 분리 수준마다 하나씩, 네 개의
패키지를 작성할 것입니다. 그러나 각 패키지는
invlevl의 동일한 루트 이름과 동일한 SQL문을 보유합니다. 단일 분리
수준에 대해서만 패키지를 작성하려면 Default.bindProps 파일을 편집할 수
있습니다. 이 파일을 사용하여, 패키지를 작성하는
StaticBinder 유틸리티의 옵션을 지정할 수 있습니다.
그러나 이 자습서의 경우에는 StaticBinder 유틸리티의 옵션을
기본값으로 유지합니다.
- 패키지를 바인드하십시오.
- 패키지의 이름을 마우스 오른쪽 단추로 클릭한 후 바인드를 선택하십시오. 연결 선택 창이 열립니다.
- GSDB 연결을 선택하고 완료를 클릭하십시오.
pureQuery는 StaticBinder 유틸리티를 실행하고
콘솔 보기에서 해당 유틸리티의 출력을 인쇄합니다.
================================================================================
The StaticBinder utility successfully bound the package 'invlevl1' for the isolation level UR.
The StaticBinder utility successfully bound the package 'invlevl2' for the isolation level CS.
The StaticBinder utility successfully bound the package 'invlevl3' for the isolation level RS.
The StaticBinder utility successfully bound the package 'invlevl4' for the isolation level RR.
The StaticBinder utility successfully bound 'com.mycompany.pureQuery.test.InventoryLevelsDataImpl'.
================================================================================
StaticBinder 유틸리티의 활동 결과:
Number of implementation classes and pureQueryXml files for which the bind operation SUCCEEDED: 1
Bind for package invlevl using connection GSDB succeeded.
데이터 소스 탐색기에서
패키지를 검사할 수 있습니다. SQL 아웃라인 보기를 사용하면 패키지를 쉽게 찾을 수 있습니다.
- SQL 아웃라인 보기에서 패키지의 이름을
마우스 오른쪽 단추로 클릭하고 데이터 소스 탐색기에서
찾기를 선택하십시오. 데이터 소스 탐색기가 열리고
패키지를 찾아서 강조 표시할 때까지 GSDB 연결의 폴더가
펼쳐집니다.
- SQL문을 정적으로 실행하십시오. 이를 통해 SQL문을 동적으로 실행할 때 캡처한
데이터와 이 데이터를 비교할 수 있습니다.
- 프로젝트 폴더를 마우스 오른쪽 단추로 클릭하고 을 선택하십시오.
- 실행 구성 창에서,
첫 번째 성능 데이터 세트를 캡처하기 위해 사용한 구성을
여십시오. 인수 페이지의 VM 인수 필드에
다음 라인을 입력한 후 적용을 클릭하십시오.
-Dpdq.executionMode="STATIC"
- 실행을 클릭하십시오.
- 프로젝트 탐색기에서 프로젝트 폴더를 마우스 오른쪽 단추로 클릭하고
을 선택하십시오. 그런 다음
성능 데이터를 조사하십시오.
- SQL 아웃라인 보기에서 비교 체크 박스를 선택하십시오. 보기가 새로 고쳐집니다. 프로젝트에 두 개 이상의 저장된
성능 데이터 세트가 포함된 경우 비교 체크 박스 옆에 있는 필드에서
이 세트 중 하나를 선택할 수 있습니다.
그림 3. 성능 데이터 세트를 비교하기 위한 제어사항이제 각 열에는 회색 열과 흰색 열이 있습니다. 회색 열은
SQL문의 정적 실행에서 생성된 현재 성능 데이터를 표시합니다.
흰색 열은 동일한 SQL문의 이전 동적 실행에서 생성된
성능 데이터를 표시합니다.
기본으로, 보기는 명령문의 실행 시간을 밀리초 단위로
비교합니다.
- 다른 두 가지 방법으로 성능 데이터를 비교하려면 보기의 맨 위에 있는
표시 필드를 사용하십시오.
- 차이
- 회색 열은 현재 데이터 세트에 대한 시간을 밀리초 단위로 표시합니다.
흰색 열은 시간 사이의 차이를 표시합니다. 예를 들어,
다음은 보기에 있는 첫 번째 명령에 대한 통계입니다.
표 1. 현재 시간 및 이전 시간 사이의 차이에 대해 비교되는
명령문에 대한 밀리초 단위 현재 시간전체 클라이언트 시간 |
최대 시간 |
평균 클라이언트 시간 |
최소 시간 |
18.32 |
11.11 |
15.92 |
-0.25 |
6.11 |
3.70 |
1.11 |
1.08 |
그림은 이전 데이터 세트에서의
다음 사항을 표시합니다. - 총 런타임이 현재 데이터 세트보다 11.11밀리초 많습니다.
- 최대 런타임이 현재 데이터 세트보다 0.25밀리초 적습니다.
- 평균 런타임이 현재 데이터 세트보다 3.70밀리초 많습니다.
- 최소 런타임이 현재 데이터 세트보다 1.08밀리초 많습니다.
- 백분율
- 회색 열은 현재 데이터 세트에 대한 시간을 밀리초 단위로 표시합니다.
흰색 열은 시간 사이의 차이를 백분율로 표시합니다. 마찬가지로,
다음은 보기에 있는 첫 번째 명령에 대한 통계입니다.
표 2. 현재 시간 및 이전 시간 사이의 차이에 대해 백분율로 비교되는
명령문에 대한 밀리초 단위 현재 시간전체 클라이언트 시간 |
최대 시간 |
평균 클라이언트 시간 |
최소 시간 |
18.32 |
60.66% |
15.92 |
-1.56% |
6.11 |
60.66% |
1.11 |
97.29% |
그림은 이전 데이터 세트에서의
다음 사항을 표시합니다. - 총 런타임이 현재 데이터 세트의 런타임보다 60.66% 높습니다.
- 최대 런타임이 현재 데이터 세트의 런타임보다 1.56% 낮습니다.
- 평균 런타임이 현재 데이터 세트의 런타임보다 60.66% 높습니다.
- 최소 런타임이 현재 데이터 세트의 런타임보다 97.29% 높습니다.