기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Oracle 엔드포인트 문제 해결
이 섹션에는 Oracle과 관련된 복제 시나리오가 나와 있습니다.
## 소스 읽기 일시 중지
AWS DMS 는 다음 시나리오에서 Oracle 소스에서 읽기를 일시 중지합니다. 이 동작은 설계에 따른 것입니다. 태스크 로그를 사용하여 이 문제의 원인을 조사할 수 있습니다. 태스크 로그에서 다음과 비슷한 메시지를 찾아보세요. 태스크 로그에 대한 자세한 내용은 [AWS DMS 작업 로그 보기 및 관리](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs) 섹션을 참조하세요.
+ **SORTER 메시지**: DMS가 복제 인스턴스에서 트랜잭션을 캐싱하고 있음을 나타냅니다. 자세한 내용은 [태스크 로그의 SORTER 메시지](CHAP_Troubleshooting_Latency_Target.md#CHAP_Troubleshooting_Latency_Target_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 ;
```
이 시나리오의 지연 시간 문제를 해결하려면 다음 사항을 확인하세요.
+ 복제의 네트워크 대역폭과 단일 스레드 성능을 확인하여 기본 네트워크가 소스 재실행 생성률을 지원할 수 있는지 확인합니다. 네트워크 대역폭이 복제 성능에 어떤 영향을 미치는지에 대한 자세한 내용은 이전의 [네트워크 속도 및 대역폭](CHAP_Troubleshooting_Latency.md#CHAP_Troubleshooting_Latency_Causes_Replication_Network) 섹션을 참조하세요.
+ 보충 로깅을 올바르게 설정했는지 확인합니다. 소스에 대한 추가 로깅(예: 테이블의 모든 열에 대한 로깅 활성화)을 사용하지 않아야 합니다. 보충 로깅 설정에 대한 자세한 내용은 [보충 로깅 설정](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging) 섹션을 참조하세요.
+ 올바른 API를 사용하여 재실행 로그 또는 아카이빙된 로그를 읽고 있는지 확인합니다. Oracle LogMiner 또는 AWS DMS Binary Reader를 사용할 수 있습니다. LogMiner는 온라인 재실행 로그와 아카이브된 재실행 로그 파일을 읽는 반면, Binary Reader는 원시 재실행 로그 파일을 직접 읽고 구문 분석합니다. 따라서 Binary Reader의 성능이 더 높습니다. 재실행 로그 생성률이 시간당 10GB를 초과할 경우 Binary Reader를 사용하는 것이 좋습니다. 자세한 내용은 [CDC용 Oracle LogMiner 또는 AWS DMS Binary Reader 사용](CHAP_Source.Oracle.md#CHAP_Source.Oracle.CDC) 단원을 참조하십시오.
+ `ArchivedLogsOnly`를 `Y`로 설정했는지 확인합니다. 이 엔드포인트 설정이 설정되어 있으면 AWS DMS 는 아카이브된 재실행 로그에서 읽기를 수행합니다. 이렇게 하면가 읽기 전에 온라인 다시 실행 로그가 보관될 AWS DMS 때까지 기다리기 때문에 소스 지연 시간이 증가합니다. 자세한 내용은 [ArchivedLogsOnly](https://docs.aws.amazon.com/dms/latest/APIReference/API_OracleSettings.html#DMS-Type-OracleSettings-ArchivedLogsOnly) 섹션을 참조하세요.
+ Oracle 소스가 Automatic Storage Management(ASM)를 사용하는 경우, 데이터 저장소를 올바르게 구성하는 방법에 대한 자세한 내용은 [Oracle을의 소스로 사용할 때 Oracle ASM에 REDO 저장 AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.REDOonASM) 섹션을 참조하세요. 추가 연결 속성(ECA) `asmUsePLSQLArray`를 사용하여 읽기 성능을 더욱 최적화할 수도 있습니다. `asmUsePLSQLArray` 사용에 대한 자세한 내용은 [Oracle을의 소스로 사용할 때 엔드포인트 설정 AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib)을 참조하세요.