일광 절약 시간 및 네트워크 시간 서버

일광 절약 시간 및 네트워크 시간 서버 둘 다 서버 시스템의 현재 시간에 영향을 줍니다. 데이터 이동 서비스에서 서버가 새로운 데이터를 확인 및 데이터 이동을 수행하는 시기를 판별하는 데 시간소인이 사용됩니다. 시스템 시계를 변경하면 데이터 서비스 컴포넌트 및 파악된 성능에 영향을 줍니다.

수동으로 시스템 시계를 변경해도 시간에 영향을 줍니다. 시계를 변경한 방법에 상관 없이 시스템 동작은 같은 방식으로 영향을 받습니다. 시스템 시계가 이전 시간으로 변경되면 데이터 이동 서비스에서 원하지 않는 지연이 발생합니다. 시스템 시계가 이전 시간으로 변경되면 지연은 발생하지 않습니다. 하지만 데이터 이동 서비스 컴포넌트는 스케줄된 간격에 더 빨리 도달합니다.

컴포넌트에서 시간 변경의 영향

시스템 시계가 이전 시간으로 변경된 경우 영향을 받는 컴포넌트의 내부 시간소인은 이후 시간으로 설정되지만, 시스템 시계는 이전 시간으로 설정됩니다. 시스템 시계 변경은 시스템 시계, 해당 내부 시간소인 및 간격을 표시하는 매개변수에 영향을 줍니다.

시스템 시계가 이후 시간으로 변경된 경우 영향을 받는 컴포넌트의 내부 시간소인은 이전 시간으로 설정되지만, 시스템 시계의 현재 시간소인은 이후 시간으로 설정됩니다. 이는 시스템 시계의 일반적인 동작과 비슷합니다. 차이점은 '스케줄된 다음 실행 결정' 또는 '데이터베이스 레코드의 라이프사이클 결정'을 비롯한 일부 시간 측정에 영향을 준다는 점입니다. 실제 경과 시간은 계산된 경과 시간보다 줄어듭니다.

예제: 레코드는 레코드를 삭제할 시간 이후 24시간 동안 시스템에 남아 있습니다. 레코드를 삭제할 시간이 화요일 오후 3시였다고 가정해 봅시다. 여기서, 24시간 보존 정책 때문에 레코드는 수요일 오후 3시 이후 삭제됩니다. 또한 화요일 오후 3:01에 시스템 시계가 이후 시간인 금요일 오후 3:01으로 변경되었다고 가정해 봅시다. 여기서 실제 경과 시간은 단 1분이지만 시스템 경과 시간은 (3일 + 1분)이므로 해당 레코드에 대한 24시간의 보존 기간이 충족되었습니다. 이는 시간 변경으로 인해 시스템 시계가 변경되지 않았을 때 보다 레코드가 더 빨리 삭제될 수 있다는 것을 의미합니다.

다른 예제: 특정 ETL 컴포넌트가 24시간마다 실행되며 실행 후 바로 시스템 시계가 26시간 후로 변경됩니다. 다음 번 실행 전까지 실제 시간으로 24시간을 기다려야 한다는 전제조건을 따르지 않고, ETL 컴포넌트는 가능한 빨리 시작할 것입니다. 이는 마지막 실행 이후 26시간 이상이 경과되었다고 시스템이 계산하기 때문입니다. 실제로 이 경우에는 시계를 이후 시간으로 변경하여 ETL 간격이 줄어들었습니다. 시스템 시계가 더 이상 변경되지 않는다면 ETL 컴포넌트는 정의된 간격으로 실행된 후 정상적으로 재개됩니다.

다음 섹션에서는 시계를 되돌리기 전에 컴포넌트를 실행한 후 시계를 이전 시간으로 변경하는 경우에 대해서만 설명합니다.

Capture 컴포넌트는 추적 중인 테이블 전체 또는 일부의 변경사항을 계속해서 캡처합니다. 이러한 변경사항을 확약하는 시기 및 Apply 컴포넌트 및 Source Life Cycle 컴포넌트에 제공하는 시기를 결정하기 위해 시간 계산이 사용됩니다. Capture 컴포넌트가 차후에 시간소인을 내부적으로 표시할 가능성이 가장 큽니다. 이 컴포넌트는 내부 시계가 표시된 내부 시간소인에 확약 간 간격에 대한 일부 내부 매개변수를 더한 값보다 클 때까지 트랜잭션을 확약하지 않을 것입니다. 이 경우 시스템 시계를 1시간 이전으로 변경하면 최악의 경우 새로운 시간에 발생한 트랜잭션은 해당 시간이 지날 때까지 사용할 수 없습니다. 시계를 1년 전으로 설정하면 시스템이 따라 잡는 데 1년이 걸릴 것입니다.
주: Capture 컴포넌트는 정의된 트랜잭션 수 다음에 확약합니다(기본값: 120). 데이터를 정의된 시간보다 빨리 Apply 및 Source Life Cycle 컴포넌트에서 사용할 수도 있습니다.

Apply 컴포넌트는 새 레코드를 확인하는 시기를 결정하는 내부 시간소인도 유지보수합니다. 이 시나리오에서 내부 시간소인은 시스템 현재 시간소인보다 큽니다. Apply 컴포넌트는 새 레코드를 사용할 수 있는 경우에도 시스템 시간소인이 내부 시간소인을 따라잡을 때까지 대기합니다. 일단 현재 시간소인을 따라잡으면 데이터 이동을 위해 제공된 레코드를 찾기 시작합니다.

복제되는 행이 시간소인에 의해 결정되지는 않습니다. 이는 시스템 시계의 영향을 받지 않는 내부 값에 의해 결정됩니다. Source 및 Target Life Cycle 컴포넌트는 시간소인을 사용하여 시작 시기 및 제거 준비가 된 레코드를 결정합니다.

상태에서 런타임으로 데이터 이동 서비스의 Source Life Cycle 컴포넌트는 시간소인만을 사용하여 시작 시기를 결정합니다. 하지만 시간소인을 사용하여 삭제할 레코드를 결정하지는 않습니다. 이 서비스의 컴포넌트는 제거하려는 정보를 특정 보존 정책 기간 동안 남겨두는 보존 정책 기능을 지원하지 않습니다. 그러나 런타임에서 히스토리로 데이터 이동 서비스 Source Life Cycle 컴포넌트에는 이 기능이 있습니다. 일부 레코드는 현재 시스템 시계가 따라잡을 때까지 보존 정책 기준을 충족시키지 않습니다. 두 데이터 이동 서비스의 Target Life Cycle 컴포넌트는 보존 정책 정의를 지원하므로 시간을 변경하면 실행 시기 및 제거할 레코드에 영향을 줍니다.

ETL 컴포넌트는 내부 스케줄링의 일부로 시간소인을 사용합니다. 이들 컴포넌트는 일단 시작되면 시간이 증가할 것으로 예상합니다. 시스템 시계가 이전 시간으로 변경되면 ETL 스케줄링이 영향을 받으며 시스템이 따라잡을 때까지 아무런 ETL도 수행되지 않습니다.

시스템 시계 시간에 대해 가능한 시나리오는 다음과 같습니다.

복구

시간 서버에 의해 변경이 발생하는 동안 시간 차이가 아주 미세하므로(단지 몇 분 차이) 복구는 필요하지 않습니다. 컴포넌트가 따라잡는 동안 아무런 일도 발생하지 않으면 약간의 시간 차이가 발생합니다. 시간이 변경되는 동안 일광 절약 시간의 변경으로 인해, 이전 시간으로 변경하면 컴포넌트는 한 시간 동안 복제를 중단한 후 시스템을 따라잡아야 합니다. 이 점이 문제가 되는지 여부는 시스템에 따라 다릅니다.

이러한 대기가 문제가 될 수 있는 하나의 시나리오는 실수가 발생하여 컴포넌트 서버가 실행 중인 동안 시스템 시간이 미래의 먼 시간으로 설정되는 경우입니다. 이때 서버의 실행 여부에 상관 없이 시간은 현재 시간으로 복원됩니다. 또한 컴포넌트는 내부 시간소인을 이후 시간으로 설정했지만 현재 시간에 실행 됩니다. 한 동안 지연된 후에 데이터 이동 서비스가 행을 다시 처리할 것입니다. 이러한 지연으로 인해 복구 시간에 영향을 줄 수 있는 시스템 빌드가 발생할 수 있습니다. 관리자는 정정 조치를 취해야 합니다.

정정 조치

하나의 옵션은 Capture 및 Apply 컴포넌트의 전체 새로 고침을 강제 실행한 후 Source Life Cycle, Target Life Cycle 및 ETL 컴포넌트의 내부 시간소인을 갱신하는 것입니다.
  1. 시간이 이후 시간으로 변경된 후 다시 이전 시간으로 돌려진 서버에서 실행 중인 모든 데이터베이스를 식별하십시오. 여기에는 두 가지의 가능성(상태와 런타임 또는 런타임과 히스토리 데이터베이스)이 있습니다.
  2. 영향을 받는 시스템에서 데이터 이동 서비스를 지원하는 모든 서버를 중지하십시오. 이 프로세스 동안 사용자는 내부 매개변수를 수정하게 되며 일부 컴포넌트는 실행이 가능한 경우 동기화되지 않을 수 있습니다. 자세한 정보는 데이터 이동 서비스 시작 및 중지를 참조하십시오.
  3. Source Life Cycle 컴포넌트 및 Target Life Cycle 컴포넌트의 내부 시간소인을 수정하십시오.
    주: 이 조치는 릴리스될 때마다 변경될 수 있습니다.
    1. Source Life Cycle 삭제 시간소인 갱신. 이 경우 시스템에서 모든 비즈니스 측정 모델에 서비스를 제공하는 모든 Source Life Cycle 컴포넌트에 대한 설정이 수정됩니다.
      현재 설정을 확인하십시오.
      connect to <source_database>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL, CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME LIKE 'APP%'
      주: LAST_PRUNED, PRUNE_INTERVAL 및 CURRENT TIMESTAMP 값을 검토하십시오. 바로 삭제하기를 원하는지 아니면 다음 간격에서 삭제하기를 원하는지 결정하십시오.
      -- TO RUN As soon as possible.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME LIKE 'APP%';
      -- TO RUN at the next interval
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME LIKE 'APP%';
      connect reset;
    2. Target Life Cycle 제거 시간소인 갱신.
      CONNECT TO <target_database>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME NOT LIKE 'APP%';
      주: LAST_PRUNED, PRUNE_INTERVAL 및 CURRENT TIMESTAMP 값을 검토하십시오. 바로 삭제하기를 원하는지 아니면 다음 간격에서 삭제하기를 원하는지 결정하십시오.
      -- TO RUN As soon as possible.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME NOT LIKE 'APP%';
      -- TO RUN at the next interval
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(current timestamp)
      WHERE TABLE_NAME NOT LIKE 'APP%';
    3. ETL 스케줄 갱신.
      주: 이는 모델 전반에 걸쳐 모든 ETL 활동에 영향을 줍니다.
      CONNECT TO <TARGET>
      -- This query shows
      SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
      주: ETL_0_MINUTES, NEXTSTARTTIME 및 LASTUPDATED 값이 CURRENT TIMESTAMP와 비교됩니다.
      -- TO Run at the next interval
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP);
      -- To Run as soon as possible
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES);
      CONNECT RESET
    4. 전체 새로 고침. 복제 Capture 및 Apply 서버의 전체 새로 고침을 강제 실행하는 간단한 방법은 모든 비즈니스 측정 모델StartCapture 스크립트를 복사하고 수정하는 것입니다. 시스템에 배치된 모든 모델의 "start capture" 스크립트를 모두 찾아서("시작 및 중지 스크립트 통합" 섹션의 지시사항을 수행한 경우 asncap 명령만을 찾으면 됨) 명령행 끝에 STARTMODE=COLD 매개변수를 추가하십시오.
      주: 전체 새로 고침은 마지막 수단이며 완료될 때까지 성능은 많이 저하됩니다. 전체 새로 고침은 정상적인 데이터 서비스 오퍼페이션에는 거의 없는 추가 오버헤드가 발생하기 때문입니다. 따라서 전체 새로 고침은 사용량이 많지 않은 시간에 수행해야 합니다. 전체 새로 고침 성능은 데이터 이동 서비스의 소스 데이터베이스에 있는 데이터 크기에 상당한 영향을 받습니다.

      예제:

      이전:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."
      이후:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLD
      그런 다음 모든 스크립트를 시작하십시오. 전체 새로 고침은 Capture 및 Apply 컴포넌트가 해당 내부 시간소인을 모두 재설정하지만 데이터 이동 및 재처리를 위한 추가 비용이 발생합니다. 시스템이 시간을 따라잡을 때 발생할 수 있는 성능 저하를 예상하는 것이 중요합니다.

Copyright IBM Corporation 2005, 2006. All Rights Reserved.