Oracle 엔드포인트 문제 해결 - AWS 데이터베이스 마이그레이션 서비스
소스 읽기 일시 중지높은 재실행 생성률

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Oracle 엔드포인트 문제 해결

이 섹션에는 Oracle과 관련된 복제 시나리오가 나와 있습니다.

소스 읽기 일시 중지

AWS DMS 다음 시나리오에서는 Oracle 소스에서의 읽기를 일시 중지합니다. 이 동작은 설계에 따른 것입니다. 태스크 로그를 사용하여 이 문제의 원인을 조사할 수 있습니다. 태스크 로그에서 다음과 비슷한 메시지를 찾아보세요. 태스크 로그에 대한 자세한 내용은 AWS DMS 작업 로그 보기 및 관리 섹션을 참조하세요.

  • SORTER메시지: 이는 복제 인스턴스에서 트랜잭션을 캐싱하고 있음을 DMS 나타냅니다. 자세한 내용은 SORTER작업 로그의 메시지 단원을 참조하십시오.

  • 디버그 작업 로그: 읽기 프로세스가 DMS 중단되면 작업은 컨텍스트 필드나 타임스탬프를 변경하지 않고 다음 메시지를 디버그 작업 로그에 반복적으로 기록합니다.

    • Binary reader: 

      [SOURCE_CAPTURE  ]T:  Produce CTI event: 
context '00000020.f23ec6e5.00000002.000a.00.0000:190805.3477731.16' 
xid [00000000001e0018] timestamp '2021-07-19 06:57:55' 
thread 2  (oradcdc_oralog.c:817)

    • Logminer: 

      [SOURCE_CAPTURE  ]T:  Produce INSERT event: 
object id 1309826 context '000000000F2CECAA010000010005A8F500000275016C0000000000000F2CEC58' 
xid [000014e06411d996] timestamp '2021-08-12 09:20:32' thread 1  (oracdc_reader.c:2269)

  • AWS DMS 새로 실행하거나 보관된 로그 작업마다 다음 메시지를 기록합니다.

    00007298: 2021-08-13T22:00:34 [SOURCE_CAPTURE ]I: Start processing archived Redo log sequence 14850 thread 2 name XXXXX/XXXXX/ARCHIVELOG/2021_08_14/thread_2_seq_14850.22977.1080547209 (oradcdc_redo.c:754)

    소스에 새 리두 또는 아카이브된 로그 작업이 있고 AWS DMS 이러한 메시지를 로그에 기록하지 않는 경우 이는 작업이 이벤트를 처리하고 있지 않음을 의미합니다.

높은 재실행 생성률

태스크가 재실행 로그 또는 아카이브된 로그를 처리하는 중인데도 소스 지연 시간이 여전히 높은 경우, 재실행 로그 생성률 및 생성 패턴을 파악해 보세요. 재실행 로그 생성 수준이 높을 경우, 복제된 테이블과 관련된 변경 사항을 가져오기 위해 태스크가 모든 재실행 로그 및 아카이브 로그를 읽으므로 소스 지연 시간이 증가합니다.

재실행 생성률을 확인하려면 아래의 쿼리를 사용합니다.

  • 일별 재실행 생성률:

    select trunc(COMPLETION_TIME,'DD') Day, thread#, 
round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) GB,
count(*) Archives_Generated from v$archived_log 
where completion_time > sysdate- 1
group by trunc(COMPLETION_TIME,'DD'),thread# order by 1;

  • 시간당 재실행 생성률:

    Alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS';
select trunc(COMPLETION_TIME,'HH') Hour,thread# , 
round(sum(BLOCKS*BLOCK_SIZE)/1024/1024) "REDO PER HOUR (MB)",
count(*) Archives from v$archived_log 
where completion_time > sysdate- 1
group by trunc(COMPLETION_TIME,'HH'),thread#  order by 1 ;

이 시나리오의 지연 시간 문제를 해결하려면 다음 사항을 확인하세요.

  • 복제의 네트워크 대역폭과 단일 스레드 성능을 확인하여 기본 네트워크가 소스 재실행 생성률을 지원할 수 있는지 확인합니다. 네트워크 대역폭이 복제 성능에 어떤 영향을 미치는지에 대한 자세한 내용은 이전의 네트워크 속도 및 대역폭 섹션을 참조하세요.

  • 보충 로깅을 올바르게 설정했는지 확인합니다. 소스에 대한 추가 로깅(예: 테이블의 모든 열에 대한 로깅 활성화)을 사용하지 않아야 합니다. 보충 로깅 설정에 대한 자세한 내용은 보충 로깅 설정 섹션을 참조하세요.

  • 올바른 API 방법을 사용하여 리두 또는 아카이브된 로그를 읽고 있는지 확인하십시오. 오라클 LogMiner 또는 AWS DMS 바이너리 리더를 사용할 수 있습니다. 온라인 리두 로그와 아카이브된 리두 로그 파일을 LogMiner 읽는 동안 Binary Reader는 원시 리두 로그 파일을 직접 읽고 분석합니다. 따라서 Binary Reader의 성능이 더 높습니다. 재실행 로그 생성률이 시간당 10GB를 초과할 경우 Binary Reader를 사용하는 것이 좋습니다. 자세한 내용은 CDC용 오라클 LogMiner 또는 AWS DMS 바이너리 리더 사용 단원을 참조하십시오.

  • ArchivedLogsOnly를 Y로 설정했는지 확인합니다. 이 엔드포인트 설정이 설정되어 있으면 AWS DMS 는 아카이브된 재실행 로그에서 읽기를 수행합니다. 이렇게 하면 읽기 전에 온라인 리두 로그가 보관될 AWS DMS 때까지 기다리기 때문에 소스 지연 시간이 늘어납니다. 자세한 내용은 ArchivedLogsOnly를 참조하세요.

  • Oracle 소스에서 자동 저장 영역 관리 (ASM) 를 사용하는 경우 데이터 저장소를 올바르게 구성하는 방법에 대한 자세한 내용은 을 참조하십시오Oracle을 소스로 사용하는 경우 Oracle ASM에 REDO를 저장합니다. AWS DMS. 추가 연결 속성 () 을 사용하여 읽기 성능을 추가로 최적화할 수도 asmUsePLSQLArray 있습니다. ECA asmUsePLSQLArray 사용에 대한 자세한 내용은 Oracle을 소스로 사용할 때의 엔드포인트 설정 AWS DMS을 참조하십시오.