복원성에 대한 코드
복원형 데이터 통합을 개발하는 동안 이러한 모범 사례를 사용합니다.
자동화된 정리 프로시저 정의
자동 정리 절차를 정의하면 코드의 복원성에 도움이 됩니다.
코드를 개발하고 테스트를 실행할 때 버그를 수정하고 성능을 향상시키며 로드 전략을 최적화하는 동안 환경을 반복적으로 재설정해야 합니다. 정리 절차를 조기에 만들면 코드가 진화하면서 원하는 상태로 환경을 재설정할 수 있는 충분한 시점으로 이러한 절차를 개선할 수 있습니다.
- 모든 항목 재설정, 대상 시스템에 데이터가 없음
- 환경을 마지막 로드 이전의 상태로 재설정합니다(변수, 상태 또는 감사 테이블 등이 포함될 수 있음).
- 특정 로드(또는 batch_id 또는 run_id) 의 데이터가 다른 데이터에 영향을 주지 않고 환경 간에 재설정되도록 환경을 재설정합니다.
정리 프로세스를 자동화하면 일반적으로 프로세스가 더 효율적으로 실행됩니다. 재설정할 테이블 목록 또는 실행할 SQL 쿼리를 찾을 필요가 없습니다. 또한, 환경의 잘못된 부분을 재설정하는 사람들이 발생할 수 있는 위험을 크게 줄여줍니다. 특히 디버깅이 보여 주고 사람들이 만족스러울 경우 특히 그렇게 됩니다.
이러한 정리 절차는 보다 세밀하게 조정된 후 통합 프로세스에 포함될 수 있습니다. 다음과 같은 두 가지 방법으로 사용할 수 있습니다.
- 데이터를 로드하기 전에 항상 선점형 정리를 실행합니다. 일괄 처리 Id 또는 특정 날짜로 쉽게 식별할 수 있는 데이터를 로드하는 경우 실패한 동일한 데이터 집합의 이전 로드를 쉽게 겹쳐 쓸 수 있습니다.
- 오류 발생 시 워크플로우에서 이러한 정리 절차를 사용하십시오. 짧은 시간 동안 소스 또는 대상 환경에 대한 접속이 끊겼기 때문에 전체 로드를 중단하지 마십시오. 이 파일에서는 수백 개의 파일을 로드하고 복잡한 변환을 실행 중이라고 가정합니다. 분할 초에 대해 파일 중 하나에만 액세스하는 중 문제가 발생했기 때문에 모든 항목을 중단하겠습니까? 아니면 모든 항목을 완료한 후 가능한 빨리 해당 파일을 다시 시도하고 해당 파일을 로드할 수 없는 경우에만 더 많은 소방적 조치를 취하겠습니까? 실행 중인 환경의 안정성에 따라 적절한 개인을 경보하기 전에 여러 번 시도해 볼 수 있습니다. 마찬가지로, 환경에 있는 운용중단 유형에 따라 다시 시도하기 전에 일시 중지를 강제 수행할 수 있습니다.
다른 유형의 복구 절차를 고려하십시오. 간단한 작업의 경우 대개 다른 정리 또는 재설정 없이 실패한 작업을 재시도할 수 있습니다. 그러나 코드가 계속 발전되고 더 복잡해지면서 발생하는 오류 유형도 계속 발전됩니다. 로드 오류를 해결한 후(로드 자체가 작동하지 않음) 비즈니스 오류가 발생할 수 있습니다(데이터가 로드되었지만, 잘못된 데이터를 로드 중이거나 일부 계산이 오류 발생). 이러한 유형의 수정 사항을 처리하는 방법을 주의 깊게 조사해야 합니다. 초기 단계에서 비즈니스 오류가 발생할 경우 모든 항목을 재설정하는 것이 적합할 수 있습니다. 그러나 코드가 변화함에 따라 더 세밀하게 커지므로 사용자가 수정 시 더 많은 손상을 입힐 수 있습니다.
Oracle Data Integrator에서 루프를 정의하여 시도 횟수를 추적하는 정리 프로시저와 증분 카운터를 포함할 수 있습니다. 운용중단의 추적 가능성을 향상시키기 위해 최선의 방법은 발견된 오류 기록을 포함하므로 오류가 더 자주 발생할 경우 적절한 조치를 취할 수 있습니다. 발생 문제 숨기기 비용에는 복원성을 높지 않아야 합니다. 실패한 단계에서 오류 검색 에 설명된 방식을 사용할 수 있습니다.
프로세스의 특정 단계 중 한 개가 오류(예: 운용중단에 대한 설정 시간 없이 정기적으로 오프라인으로 전환하는 원격 시스템) 를 알고 있는 경우 Oracle Data Integrator 내장 기능을 사용하여 패키지에서 단계를 재시도할 수 있습니다. 자동 재시도 사용 은 단계의 자동 재시도를 설정하는 방법에 대해 설명합니다.
이 방법을 사용할 경우 다음 두 가지 사항에 유의하십시오.
- Oracle Data Integrator는 재시도로 설정된 경우 프로세스가 실패했음을 알리지 않습니다. 추가 시도 중 하나가 성공하면 단계가 Oracle Data Integrator 로그에 성공한 것으로 기록됩니다. 단, 자체 감사 테이블에서 이러한 시도를 추적할 수 있습니다.
- 재시도 후 대기하면 해당 단계의 실행 기간이 늘어납니다. 통합 프로세스의 성능을 검토할 때는 주의해야 합니다.
성능 편차 식별
지연이 있는 위치와 이러한 지연의 원인을 파악할 수 있습니다. 이 작업은 사용 가능한 대역폭, SQL 코드 실행에 악영향을 미치는 데이터베이스의 오래된 통계 또는 선택한 몇 에만 관심이 있는 서버의 파일 수익을 줄여주는 증가된 네트워크 작업과 관련될 수 있습니다.
Oracle Data Integrator의 모범 사례는 성능 향상을 위해 최대한 자주 로그(및 시나리오 보고서) 를 비우는 것입니다. 이 정보는 시간에 따른 성능을 설문 조사할 수 있도록 로그를 아카이브하거나 성능 관련 정보를 복사하는 데 매우 유용합니다.
성능 결정을 조사할 때 Oracle Data Integrator의 개별 단계를 살펴보십시오(전체 성능에서는 정지되지 않음). 지연이 발생하는 위치를 파악하는 가장 좋은 방법이 됩니다. 또한 Oracle Data Integrator 로그를 비우는 자동화된 프로세스가 있는지 확인하십시오. 실제로 시나리오 보고서를 포함하여 이러한 비우기를 수행하는 Oracle Data Integrator 작업을 생성할 수 있습니다. 자세한 내용은 Purge Logs with OdiPurgeLog를 참조하십시오.
Oracle Data Integrator는 연산자에 있는 세션에 링크된 시나리오 보고서만 비우므로 세션이 비워진 후 시나리오 보고서를 비우려면 Oracle Support의 지원이 필요합니다. 세션을 비우기 전에 시나리오 보고서를 지우지 않은 경우 Oracle 지원 센터에 문의하십시오. Oracle는 해당 절차를 안내할 수 있습니다.
장기 실행에서는 성능을 지속적으로 모니터하는 데 중요합니다. 성능 저하는 종종 환경 저하에 대한 경고 서명입니다. 특히, Oracle은 SPM(SQL 계획 관리) 을 사용하여 실행 계획을 제어할 것을 권장합니다. 운용 환경의 실행 계획 변경으로 인해 오류가 발생할 수 있으며, 테이블 로드로 인해 실행 계획에 대한 변경 위험이 발생할 수 있습니다.
OdiPurgeLog로 로그 비우기
Oracle Data Integrator 패키지의 유틸리티 전환기를 살펴보면 OdiPurgeLog 라는 툴이 표시됩니다. 이 시나리오는 Oracle Data Integrator 로그를 지우도록 설계된 시나리오에서 사용할 수 있으며 이 시나리오를 정기적으로 실행하여 가능한 한 적은 수의 로그를 유지하도록 할 수 있습니다.
최적의 사용법은 다음과 같습니다.
- 항상 보고서를 비워야 합니다. 로그를 비우는 동안 자신이 소유한 사용자보다 쉽게 제거할 수 없습니다.
- 비울 때 몇 가지 대기 시간 레벨을 설정할 수 있습니다. 변수를 사용하여 이전 시간 또는 이전 날짜를 저장한 후 모든 항목을 비워야 합니다(End Date 매개변수와 함께 사용).
- 시나리오 로그(및 보고서) 만 비우거나 시나리오 및 로드 계획 로그를 모두 비우도록 선택할 수 있습니다.
실패한 단계에서 오류 검색
getPrevStepLog() API는 일반적으로 Oracle Data Integrator 프로시저에 사용됩니다. 단계가 실패하는 경우, 해결 조치를 취하기 전에 해당 단계에서 보고된 오류를 검색하려는 경우 매우 편리합니다.
이 API는 적합한 정보를 반환할 속성 이름으로 호출됩니다. 예를 들어, 세션 이름, 실패한 단계 이름 및 연관된 오류 메시지를 원하는 경우 다음 코드를 사용하여 프로시저에 대한 오류를 검색할 수 있습니다.
Session:
<%=odiRef.getInfo("SESS_NAME")%> encountered the following
error at step: <%=odiRef.getPrevStepLog("STEP_NAME")%>Error Message:
<%odiRef.getPrevStepLog("MESSAGE")%>
해당 정보를 저장하는 추가 코드에 이 코드 조각을 줄바꿈하거나 적절한 처리를 위해 해당 정보를 전송합니다.
자동 재시도 사용
요약 또는 임시 미끄러로 인해 전체 프로세스를 완료하는 것과 취소할 수 있으므로 자동 재시도 저장 시간이 걸립니다.
패키지에서 재시도를 허용할 단계를 선택합니다. 속성 상자에서 ‘고급’ 탭을 누릅니다. 실패 후 처리 영역에서 다음을 수행합니다.
- 해당 단계를 재시도하려는 횟수를 정의합니다.
- 재시도 간격 정의
시나리오 세션에 고유한 또는 동적 이름 사용
서로 다른 데이터 집합을 로드하기 위해 동일한 시나리오를 여러 번 실행하는 경우 동일한 시나리오의 여러 인스턴스 목록이 모두 표시되는 경우에는 Oracle Data Integrator 연산자 뷰가 매우 유용하지 않으므로 오류가 발생할 수도 있습니다.
시나리오 호출 시 한 가지 방법은 세션 이름(SESS_NAME) 매개변수를 사용하는 것입니다. 동일한 시나리오가 여러 번 실행되는 경우 이 시나리오에 처리할 데이터(특정 데이터 슬라이스, load_id, 날짜 등) 를 나타내는 매개변수가 이미 있을 수 있습니다. 이 변수를 사용하여 시나리오의 각 실행에 대한 고유한 이름을 작성할 수 있습니다. 시나리오 호출에서 세션 이름을 설정하면 패키지의 추가 세션이 Oracle Data Integrator 연산자에 보다 읽기 쉬운 로그를 생성합니다. 그러면 문제 발생 시 문제가 되는 데이터 세트를 쉽게 이해할 수 있습니다.
이벤트 방식 툴 사용
Oracle Data Integrator는 패키지에서 새 데이터를 사용할 수 있을 때까지 기다리는 데 사용할 수 있는 다양한 도구를 제공합니다.
이러한 도구를 모두 사용하면 폴링 속도 및 시간 초과 기간을 설정할 수 있습니다.
- OdiFileWait 디렉토리에서 파일을 사용할 수 있을 때까지 기다립니다(Oracle Data Integrator 에이전트가 해당 디렉토리를 확인해야 합니다!).
- OdiWaitForData는 사용자가 제공한 질의에 준하여 테이블에서 새 데이터를 사용할 수 있을 때까지 기다립니다.
- OdiWaitForTable 테이블이 데이터베이스에 생성될 때까지 기다립니다.
에이전트 청사진 캐시 시간 초과 구성
Oracle Data Integrator 12c를 사용하면 실행된 시나리오의 정의를 캐싱하여 에이전트의 효율성이 향상되었습니다. Oracle Data Integrator 토폴로지의 물리적 에이전트 정의에서 시나리오가 캐시되는 기간을 제어할 수 있습니다.
에이전트의 시나리오를 캐시에 저장하면 실시간 작업에 유용하므로 에이전트가 모든 실행을 위해 저장소의 정보를 가져올 필요가 없습니다. 롤백은 새 버전의 시나리오 배포가 즉시 선택되지 않는다는 것입니다. 캐시에 저장된 시나리오의 새 버전을 선택할 때까지 기본 시간 초과는 600초(10분) 이며, 기본적으로 100개 항목이 캐시됩니다.
이러한 값을 관리할 수 있습니다. 에이전트 정의의 [정의 ] 탭에서 [세션 청사진 캐시 관리] 섹션을 사용하여 최대 캐시 항목 및 사용되지 않은 청사진 수명(초) 을 설정합니다.