pureQuery 클라이언트 최적화에 사용 가능한 응용프로그램을 실행할 때
pureQuery Runtime이 런타임 구성 정보 및 pureQueryXML 정보를 검색하는 위치를
지정할 수 있습니다. SQL 데이터를 캡처할 때에는 데이터의 저장 위치를
지정할 수 있습니다.
일반적으로는 pureQuery 클라이언트 최적화 인에이블먼트 프로세스 도중 및
런타임 중에 사용되는 다음 파일을 작성합니다.
- pureQuery Runtime 구성 등록 정보 파일
- 런타임 중 사용된 SQL 데이터가 포함된 pureQueryXML 파일
- 등록 정보 구성 파일 및 등록 정보 바인드 파일
- 캡처한 SQL 데이터가 포함된 pureQueryXML 파일
pureQuery
등록 정보 및 데이터를 저장할 위치를 결정해야 합니다. 디폴트 pureQuery Runtime
위치를 사용하거나 위치를 지정할 수 있습니다.
- 로컬 파일 시스템(디폴트 동작)
- 디폴트로 pureQuery Runtime은 로컬 파일 시스템의 등록 정보 및 데이터를
찾습니다. 이 모델에서는 pureQuery Runtime 등록 정보 pureQueryXml
및 outputPureQueryXml이 pureQuery 데이터가 포함된 파일을
지정합니다. pdq.properties 및
pdq.appwide.properties라는 파일을 포함하여 다양한 위치에 이 두 등록 정보를
지정할 수 있습니다.
- 데이터베이스의 저장소 또는 파일 시스템 지정
- 하지만 pureQuery 데이터 및 런타임 등록 정보가
데이터베이스의 저장소, 파일 시스템 또는 이 둘의 조합에 있음을 지정할
수 있습니다. pureQuery Runtime 등록 정보 finalRepositoryProperties
및 outputXmlRepository를 사용하여 위치를
지정하십시오.
pureQuery 클라이언트
최적화로 응용프로그램을 사용하고 pureQuery 데이터를 저장소에 저장할 때
pureQuery 유틸리틴인 ManageRepository를 사용하여 저장소의
pureQuery 데이터를 액세스하고 저장합니다. ManageRepository 유틸리티는
저장소를 작성하고 저장소를 관리 및 유지보수하는 데 사용할 수
있습니다.
pureQuery 데이터와 등록 정보를 저장소에
저장하면 장점이 있는 반면 저장소를 작성하고 유지보수할 때 적절한
계획이 필요합니다.
저장소 사용의 장점
데이터베이스의 저장소를
pureQuery 데이터의 중앙 저장소로 사용하는 경우의 장점은
다음과 같습니다.
- 응용프로그램 실행을 인터럽트하지 않고 pureQuery 데이터를 액세스하거나
갱신할 수 있습니다.
- 중앙에서 관리되는 저장소를 통해 pureQuery 등록 정보 및
XML 파일의 단일 사본을 여러 응용프로그램 서버(AS)에 전개되는 응용프로그램에
사용할 수 있습니다.
- pureQuery 등록 정보 및 XML 파일에 대한 갱신을 주기적으로 점검하고
자동으로 새 데이터 사용을 시작하도록 응용프로그램을 구성할 수 있습니다.
- pureQuery 데이터 액세스 및 갱신에 대한 권한 부여를 데이터베이스에서
강제 적용할 수 있습니다.
- 관리자는 pureQueryXML 파일을 보다 쉽게 검토하여 응용프로그램에 대한
SQL을 검사하고 소스 코드 위치 정보에서 문제점 SQL문을
확인할 수 있습니다.
저장소 구성 고려사항
데이터베이스를 사용하여
pureQuery 아티팩트를 저장하면 어느 정도 유연하게 구성할 수
있습니다. 기본 의사결정 위치는 다음과 같습니다.
- pureQuery 데이터가 포함된 단일 또는 복수 데이터베이스가 어디에
상주합니까?
- 응용프로그램이 초기화 중 저장소에 액세스할 수 없을 때 어떻게 반응해야
합니까?
- 응용프로그램이 자동 새로 고침 기능을 사용해야 합니까? 그러한 경우,
갱신을 위해 저장소 DBMS를 폴링할 권장 간격은 무엇입니까?
- 저장소 데이터베이스 위치 판별
- 두 가지 데이터 유형으로 입력 데이터와 출력 데이터가 있습니다.
- pureQuery Runtime 실행 및 구성 데이터(입력)
- pureQuery 캡처 SQL 데이터(출력)
입력 및 출력 데이터에 여러 다른
위치를 사용하도록 응용프로그램 실행 환경을 구성할 수 있습니다. 다음 중 하나의
각 데이터 유형을 찾을 수 있습니다.
- 응용프로그램이 트랜잭션 작업(the transaction database)을
수행하는 동일한 데이터베이스
- 응용프로그램 서버(AS)와 동일한 위치에서 실행하는 데이터베이스
- 응용프로그램 또는 트랜잭션 데이터베이스 서버와 별도인 원격
데이터베이스
디폴트 권장사항: 입력 및 출력 모두에 사용할 단일 저장소를
트랜잭션 데이터베이스에 작성하십시오. 두 가지 장점이 있습니다.
- 단순성
- 이 접근 방식은 별도의 데이터베이스에 데이터를 작성하고 유지보수할 필요가
없기 때문에 단순한 작업 방식을 제공합니다.
- 사용 가능성
- 초기화 중 pureQuery 데이터베이스 저장소가 사용 불가능한 경우에는
실패하도록 응용프로그램을 구성할 수 있습니다. 이러한 경우,
트랜잭션 데이터베이스에는 일반적으로 우수한 사용 가능성 및 기타 서비스 품질
특성이 있기 때문에 트랜잭션 데이터베이스를 사용하면 응용프로그램 사용 가능성이
증가할 수 있습니다. 유사한 특성의 개별 서버를 사용하면
가능한 실패 지점이 늘어납니다.
기타 데이터베이스
위치 고려사항:
- pureQuery 자동 새로 고침이나 출력 캡처 레코드 쓰기로 인한
네트워크 또는 트랜잭션 데이터베이스의 증가한 활동이 걱정되는 경우 응용프로그램
서버(AS)나 별도의 서버에 저장소 데이터베이스를 둘 것을 고려하십시오.
- 트랜잭션 데이터베이스에 허용되는 데이터 유형에 관한 표준이
사이트에 있을 수 있습니다. 이 요구사항도
데이터베이스 서버에 대해 개별 서버를 선택하도록 합니다.
- 고려할 수 있는 한 가지 절충 변형은
입력 데이터 저장소를 트랜잭션 데이터베이스에 두고 개별 서버에 저장소를
작성하여 출력 캡처 레코드를 저장하는 것입니다.
- 데이터베이스 저장소의 입력 데이터와 로컬 또는 원격 파일 시스템의
출력 데이터 조합의 구성도 허용됩니다.
- 저장소가 사용 불가능할 때의 동작
- 응용프로그램이 시작될 때 pureQuery 데이터가 사용 불가능할 경우
응용프로그램이 작동하는 방식을 미리 고려하는 것이
중요합니다. pureQuery Runtime 시간 등록 정보 repositoryRequired는
동작을 제어합니다.
디폴트 설정 no는
pureQuery Runtime이 모든 pureQuery 클라이언트 최적화 등록 정보의 디폴트 동작을
되돌리도록 합니다. 이는 응용프로그램이 동적
SQL을 사용하여 실행됨을 의미합니다. 응용프로그램 시작 시 실패하는 것보다
이 폴백(fallback)을 선호한다면 디폴트 동작을 유지하십시오.
하지만
일부 경우 SQL문을 정적으로 실행할 때처럼
응용프로그램을 디폴트 동작으로 실행하기 불가능하거나 문제가 유발될 수
있습니다. 예를 들어,
SQL문을 동적으로 준비하고 실행할 권한이 모든 응용프로그램 사용자에게
부여되지 않았을 수 있습니다. 그러한 경우에는 atStartUp 값으로
pureQuery Runtime 등록 정보
repositoryRequired를 지정해야 합니다.
마찬가지로
응용프로그램이 실행 중일 때 출력 데이터 캡처가 중요한 경우에는,
forOutput 값으로 repositoryRequired 등록 정보를
지정해서 응용프로그램이 시작될 때 pureQuery Runtime이 출력 데이터베이스의 사용 가능성을
검증하도록 할 수 있습니다. 대부분의 경우 이 설정은
필요하지 않습니다. 응용프로그램 실행 중 출력 데이터베이스가 사용 가능하게 되면
pureQuery는 변경을 감지하고 출력을 쓰기
시작합니다.
입력 및 출력
pureQueryXml 데이터베이스가 모두 사용 가능한지 확인해야 하는 경우
repositoryRequired 등록 정보를 atStartupAndForOutput
값으로 지정할 수 있습니다.
이 설정은 초기 구성 중 모든 구성이 올바른지 확인하고
무언가 올바르게 구성되지 않았음을 인식하기 전에 확장된 기간 동안 응용프로그램이
실행되지 않도록 하는 데 유용한 옵션일 수도 있습니다.
- 자동 새로 고침 간격
- pureQuery 기능을 통해 propertiesRefreshInterval 등록 정보를
사용하여 장기 실행 응용프로그램 및 캐싱된 연결에 대한 pureQuery Runtime
등록 정보와 pureQueryXML을 자동으로 새로 고칠 수 있습니다.
이 기능은 디폴트로 사용되지 않지만
새로 고침 시도 간격(분)을 지정하는 양의 정수를 지정해서 주기적 폴링 및
새로 고침을 사용할 수 있습니다.
빈번한 유지보수 갱신을 수신하는
응용프로그램 및 이전에 캡처되지 않은 SQL을 계속해서 생성하는 프레임워크는
새로 고침하기 좋은 예입니다. 지정된 간격은 반영된 갱신사항을 확인해야 하는
즉시성에 따라 다릅니다. 많은 응용프로그램에서는
하루에 한번 새로 고치면(propertiesRefreshInterval에
1440 값을 지정해서) 충분합니다.
캡처를 포함한
초기 응용프로그램 설정 도중 및 동적에서 정적으로 처음 전환할 때
간격을 보다 빈번하게(예를 들어, 10분으로) 설정하여 변경사항을 빠르게
갱신하고자 할 수 있습니다.
대부분의 경우에는 이 기능을 사용하지 않는
상태 그대로 둡니다. 전개 후 응용프로그램에
유지보수 갱신사항이 거의 또는 전혀 없고 가상으로 모든 SQL이 캡처 및 바인드된 경우에는
연속 캡처 모드에서 실행하거나 자동 새로 고침을 사용하지
않아도 됩니다. 또한 pureQuery
Runtime이 새 런타임 등록 정보 또는 pureQueryXML을 인식하도록 할 때마다
응용프로그램 및 응용프로그램 서버(AS)를 쉽게 다시 시작하면
자동 새로 고침 기능을 사용할 필요가 없습니다.
자동 새로 고침을
사용하며 나중에 응용프로그램이 실행 중인 동안에 새로 고침 간격을
변경하려면 데이터베이스 저장소의 등록 정보 값을 변경해서 이를
수행할 수 있습니다. pureQuery는 다음 간격에 변경을 감지하고
계속해서 새 값으로 전환합니다.