pureQuery 데이터 저장에 대한 옵션

pureQuery 클라이언트 최적화에 사용 가능한 애플리케이션을 실행할 때 pureQuery Runtime이 런타임 구성 정보 및 pureQueryXML 정보를 검색하는 위치를 지정할 수 있습니다. SQL 데이터를 캡처할 때에는 데이터의 저장 위치를 지정할 수 있습니다.
일반적으로는 pureQuery 클라이언트 최적화 인에이블먼트 프로세스 도중 및 런타임 중에 사용되는 다음 파일을 작성합니다.
  • pureQuery Runtime 구성 특성 파일
  • 런타임 중 사용된 SQL 데이터가 포함된 pureQueryXML 파일
  • 특성 구성 파일 및 특성 바인드 파일
  • 캡처한 SQL 데이터가 포함된 pureQueryXML 파일
pureQuery 특성 및 데이터를 저장할 위치를 결정해야 합니다. 기본 pureQuery Runtime 위치를 사용하거나 위치를 지정할 수 있습니다.
로컬 파일 시스템(기본 동작)
기본으로 pureQuery Runtime은 로컬 파일 시스템의 특성 및 데이터를 찾습니다. 이 모델에서는 pureQuery Runtime 특성 pureQueryXmloutputPureQueryXml이 pureQuery 데이터가 포함된 파일을 지정합니다. pdq.properties 및 pdq.appwide.properties라는 파일을 포함하여 다양한 위치에 이 두 특성을 지정할 수 있습니다.
데이터베이스의 저장소 또는 파일 시스템 지정
하지만 pureQuery 데이터 및 런타임 특성이 데이터베이스의 저장소, 파일 시스템 또는 이 둘의 조합에 있음을 지정할 수 있습니다. pureQuery Runtime 특성 finalRepositoryPropertiesoutputXmlRepository를 사용하여 위치를 지정하십시오.

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는 다음 간격에 변경을 감지하고 계속해서 새 값으로 전환합니다.


피드백