기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
이 섹션에는 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를 사용하여 재실행 로그 또는 아카이빙된 로그를 읽고 있는지 확인합니다. Oracle LogMiner 또는 AWS DMS Binary Reader를 사용할 수 있습니다. LogMiner는 온라인 재실행 로그와 아카이브된 재실행 로그 파일을 읽는 반면, Binary Reader는 원시 재실행 로그 파일을 직접 읽고 구문 분석합니다. 따라서 Binary Reader의 성능이 더 높습니다. 재실행 로그 생성률이 시간당 10GB를 초과할 경우 Binary Reader를 사용하는 것이 좋습니다. 자세한 내용은 CDC용 Oracle LogMiner 또는 AWS DMS Binary Reader 사용 단원을 참조하십시오.
ArchivedLogsOnly
를Y
로 설정했는지 확인합니다. 이 엔드포인트 설정이 설정되어 있으면 AWS DMS는 아카이브된 재실행 로그에서 읽기를 수행합니다. 이렇게 하면 읽기를 시작하기 전에 AWS DMS는 온라인 재실행 로그가 아카이브될 때까지 대기하므로, 소스 지연 시간이 증가합니다. 자세한 내용은 ArchivedLogsOnly 섹션을 참조하세요.Oracle 소스가 Automatic Storage Management(ASM)를 사용하는 경우, 데이터 스토어를 올바르게 구성하는 방법에 대한 자세한 내용은 Oracle을 소스로 사용할 때 Oracle ASM에 REDO 저장 AWS DMS 섹션을 참조하세요. 추가 연결 속성(ECA)
asmUsePLSQLArray
를 사용하여 읽기 성능을 더욱 최적화할 수도 있습니다.asmUsePLSQLArray
사용에 대한 자세한 내용은 Oracle을의 소스로 사용할 때 엔드포인트 설정 AWS DMS을 참조하십시오.