기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 지연 시간 문제 해결
이 섹션에는 복제 지연 시간에 대한 문제 해결 단계가 나와 있습니다.
지연 시간 문제를 해결하려면 다음을 수행합니다.
+ 먼저, 태스크의 지연 시간 유형과 양을 확인합니다. DMS 콘솔 또는 CLI에서 태스크의 테이블 통계 섹션을 확인합니다. 카운터가 변경되면 데이터 전송이 진행 중인 것입니다. `CDCLatencySource` 및 `CDCLatencyTarget` 지표를 함께 확인하여 CDC 중에 병목 현상이 발생했는지 확인합니다.
+ 높은 `CDCLatencySource` 또는 `CDCLatencyTarget` 지표가 복제에서 병목 현상이 발생했음을 나타내는 경우 다음 사항을 확인하세요.
+ `CDCLatencySource`가 높고 `CDCLatencyTarget`와 같으면 소스 엔드포인트에 병목 현상이 있고 대상에 데이터를 원활하게 쓰 AWS DMS 고 있음을 `CDCLatencySource`나타냅니다. 다음을 [소스 지연 시간 문제 해결](CHAP_Troubleshooting_Latency_Source.md) 섹션을 참조하세요.
+ `CDCLatencySource`가 낮고 `CDCLatencyTarget`가 높으면 대상 엔드포인트에 병목 현상이 있고 소스에서 데이터를 원활하게 AWS DMS 읽고 있음을 나타냅니다. 아래의 [대상 지연 시간 문제 해결](CHAP_Troubleshooting_Latency_Target.md) 섹션을 참조하세요.
+ `CDCLatencySource`가 높고 `CDCLatencyTarget`가 `CDCLatencySource`보다 훨씬 더 높은 경우, 소스 읽기와 대상 쓰기 양쪽 모두에 병목 현상이 발생했음을 나타냅니다. 먼저 소스 지연 시간을 검사한 다음, 대상 지연 시간을 검사합니다.
DMS 태스크 지표의 모니터링에 대한 자세한 내용은 [AWS DMS 작업 모니터링](CHAP_Monitoring.md) 섹션을 참조하세요.
# 소스 지연 시간 문제 해결
아래의 주제에서는 소스 엔드포인트 유형별 복제 시나리오를 설명합니다.
**Topics**
+ [
# Oracle 엔드포인트 문제 해결
](CHAP_Troubleshooting_Latency_Source_Oracle.md)
+ [
# MySQL 엔드포인트 문제 해결
](CHAP_Troubleshooting_Latency_Source_MySQL.md)
+ [
# PostgreSQL 엔드포인트 문제 해결
](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md)
+ [
# SQL Server 엔드포인트 문제 해결
](CHAP_Troubleshooting_Latency_Source_SQLServer.md)
# 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)을 참조하세요.
# MySQL 엔드포인트 문제 해결
이 섹션에는 MySQL과 관련된 복제 시나리오가 포함되어 있습니다.는 MySQL 바이너리 로그를 주기적으로 AWS DMS 스캔하여 변경 사항을 복제합니다. 다음과 같은 시나리오에서는 이러한 프로세스 때문에 지연 시간이 증가할 수 있습니다.
**Topics**
+ [
## 소스에서 장시간 실행 중인 트랜잭션
](#CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning)
+ [
## 소스의 높은 워크로드
](#CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload)
+ [
## 바이너리 로그 경합
](#CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog)
## 소스에서 장시간 실행 중인 트랜잭션
MySQL은 커밋된 트랜잭션만 바이너리 로그에 작성하므로, 트랜잭션이 장시간 실행되면 쿼리 실행 시간에 비례하여 지연 시간이 급증합니다.
장시간 실행 중인 트랜잭션을 파악하려면 아래의 쿼리를 사용하거나 느린 쿼리 로그를 사용합니다.
```
SHOW FULL PROCESSLIST;
```
느린 쿼리 로그 사용에 대한 자세한 내용은 [MySQL 설명서](https://dev.mysql.com/doc/)의 [The Slow Query Log](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)를 참조하세요.
장시간 실행 중인 트랜잭션으로 인한 지연 시간 급증을 방지하려면 소스 트랜잭션을 재구성하여 쿼리 실행 시간을 줄이거나 커밋 빈도를 늘립니다.
## 소스의 높은 워크로드
DMS CDC는 단일 스레드 방식이므로, 트랜잭션 수가 많으면 소스 지연 시간이 증가할 수 있습니다. 소스 지연 시간이 과중한 워크로드로 인한 것인지 확인하려면, 지연 시간 동안 생성된 바이너리 로그의 수와 크기를 지연 시간 이전에 생성된 로그와 비교합니다. 바이너리 로그와 DMS CDC 스레드 상태를 확인하려면 아래의 쿼리를 사용합니다.
```
SHOW BINARY LOGS;
SHOW PROCESSLIST;
```
CDC 바이너리 로그 덤프 스레드 상태에 대한 자세한 내용은 [Replication Source Thread States](https://dev.mysql.com/doc/refman/8.0/en/source-thread-states.html)를 참조하세요.
소스에서 생성된 최신 바이너리 로그 위치를 DMS가 현재 처리 중인 이벤트와 비교하여 지연 시간을 확인할 수 있습니다. 소스 최신 바이너리 로그를 확인하려면 다음을 수행합니다.
+ SOURCE\$1CAPTURE 구성 요소에 대한 디버그 로그를 활성화합니다.
+ 태스크 디버그 로그에서 DMS 처리 바이너리 로그와 위치 세부 정보를 검색합니다.
+ 소스에 대한 최신 바이너리 로그를 확인하려면 아래의 쿼리를 사용합니다.
```
SHOW MASTER STATUS;
```
성능을 더 최적화하려면 `EventsPollInterval`을 튜닝합니다. 기본적으로 DMS는 5초마다 바이너리 로그를 폴링하지만, 이 값을 줄여 성능을 개선할 수 있습니다. `EventsPollInterval` 설정에 관한 자세한 내용은 [MySQL을의 소스로 사용할 때 엔드포인트 설정 AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.ConnectionAttrib)를 참조하세요.
## 바이너리 로그 경합
데이터의 양이 많은 여러 테이블을 마이그레이션할 경우, MySQL 5.7.2 이상에서는 테이블을 별도의 태스크로 분할하는 것이 좋습니다. MySQL 버전 5.7.2 이상에서는 마스터 덤프 스레드가 잠금 경합을 줄이고 처리량을 개선합니다. 따라서 덤프 스레드는 이벤트를 읽을 때마다 더 이상 바이너리 로그를 잠그지 않습니다. 이렇게 되면 여러 덤프 스레드가 바이너리 로그 파일을 동시에 읽을 수 있습니다. 이는 클라이언트가 바이너리 로그에 쓰는 동안 덤프 스레드가 바이너리 로그를 읽을 수 있다는 의미이기도 합니다. 덤프 스레드에 대한 자세한 내용은 [Replication Threads](https://dev.mysql.com/doc/refman/8.0/en/replication-threads.html) 및 [MySQL 5.7.2 릴리스 정보](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-2.html)를 참조하세요.
5.7.2 이전 버전의 MySQL 소스의 복제 성능을 개선하려면 CDC 구성 요소로 작업을 통합해 보시기 바랍니다.
# PostgreSQL 엔드포인트 문제 해결
이 섹션에는 PostgreSQL과 관련된 복제 시나리오가 나와 있습니다.
**Topics**
+ [
## 소스에서 장시간 실행 중인 트랜잭션
](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [
## 소스의 높은 워크로드
](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [
## 높은 네트워크 처리량
](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [
## Aurora PostgreSQL에서 파일 유출
](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)
## 소스에서 장시간 실행 중인 트랜잭션
소스 데이터베이스에 장시간 실행 중인 트랜잭션이 있는 경우(예: 단일 트랜잭션에 수천 개의 삽입이 있는 경우), 트랜잭션이 완료될 때까지 DMS CDC 이벤트 및 트랜잭션 카운터가 증가하지 않습니다. 이러한 지연으로 인해 `CDCLatencyTarget` 지표로 측정 가능한 지연 시간 문제가 발생할 수 있습니다.
장시간 실행 중인 트랜잭션을 검토하려면 다음 중 하나를 수행합니다.
+ `pg_replication_slots` 보기를 사용합니다. `restart_lsn` 값이 업데이트되지 않을 경우, 장시간 실행 중인 활성 트랜잭션으로 인해 PostgreSQL이 Write Ahead Log(WAL)를 릴리스하지 못할 수 있습니다. `pg_replication_slots` 보기에 대한 자세한 내용은 [PostgreSQL 15.4 설명서](https://www.postgresql.org/docs/15/)의 [pg\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html) 섹션을 참조하세요.
+ 아래의 쿼리를 사용하여 데이터베이스의 모든 활성 쿼리 목록을 관련 정보와 함께 반환합니다.
```
SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity WHERE query != ''
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
```
쿼리 결과의 `age` 필드에는 각 쿼리의 활성 기간이 표시되므로, 장시간 실행 중인 쿼리를 확인하는 데 사용할 수 있습니다.
## 소스의 높은 워크로드
소스에 PostgreSQL의 워크로드가 높은 경우, 다음 사항을 확인하여 지연 시간을 줄입니다.
+ 초당 트랜잭션(TPS) 값이 높은 소스 데이터베이스에서 테이블의 하위 집합을 마이그레이션하는 동안 `test_decoding` 플러그인을 사용하면 지연 시간이 길어질 수 있습니다. 그 이유는 `test_decoding` 플러그인이 모든 데이터베이스 변경 사항을 복제 인스턴스로 보낸 다음, DMS가 태스크의 테이블 매핑을 기반으로 필터링하기 때문입니다. 태스크의 테이블 매핑에 포함되지 않은 테이블의 이벤트는 소스 지연 시간을 증가시킬 수 있습니다.
+ 다음 방법 중 하나를 사용하여 TPS 처리량을 확인합니다.
+ Aurora PostgreSQL 소스의 경우 `CommitThroughput` CloudWatch 지표를 사용합니다.
+ Amazon RDS 또는 온프레미스에서 실행되는 PostgreSQL의 경우, PSQL 클라이언트 버전 11 이상을 활용하여 아래의 쿼리를 사용합니다(결과를 진행하려면 쿼리 중에 **enter**를 누릅니다).
```
SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
select pg_sleep(60);
SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
```
+ `test_decoding` 플러그인 사용 시 지연 시간을 줄이려면 `pglogical` 플러그인을 대신 사용하는 것이 좋습니다. `test_decoding` 플러그인과 달리, `pglogical` 플러그인은 원본에서 Write Ahead Log(WAL) 변경 사항을 필터링하고 관련 변경 사항만 복제 인스턴스로 전송합니다. 에서 `pglogical` 플러그인을 사용하는 방법에 대한 자세한 내용은 섹션을 AWS DMS참조하세요[pglogical 플러그인 구성](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical).
## 높은 네트워크 처리량
`test_decoding` 플러그인을 사용할 경우, 특히 대용량 트랜잭션 시 복제를 수행할 때 네트워크 대역폭 사용량이 높을 수 있습니다. 그 이유는 `test_decoding` 플러그인은 변경 사항을 처리한 후 이를 사람이 읽을 수 있는 형식으로 변환하는데, 원래 바이너리 형식보다 용량이 크기 때문입니다.
성능을 개선하려면 바이너리 플러그인인 `pglogical` 플러그인을 대신 사용하는 것이 좋습니다. `test_decoding` 플러그인과 달리 `pglogical` 플러그인은 바이너리 형식의 출력을 생성하므로, 압축된 Write Ahead Log(WAL) 스트림 변경 사항이 발생합니다.
## Aurora PostgreSQL에서 파일 유출
PostgreSQL 버전 13 이상에서 `logical_decoding_work_mem` 파라미터는 디코딩 및 스트리밍을 위한 메모리 할당을 결정합니다. `logical_decoding_work_mem` 파라미터에 대한 자세한 내용은 [PostgreSQL 13.13 설명서](https://www.postgresql.org/docs/13/)에서 [PostgreSQL의 리소스 소비](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)를 참조하세요.
논리적 복제는 트랜잭션이 커밋될 때까지 메모리의 모든 트랜잭션에 대한 변경 사항을 누적합니다. 모든 트랜잭션에 저장된 데이터의 양이 데이터베이스 파라미터 `logical_decoding_work_mem`에 지정된 양을 초과하는 경우 DMS는 트랜잭션 데이터를 디스크에 유출하여 새 디코딩 데이터에 대한 메모리를 릴리스합니다.
오래 실행되는 트랜잭션 또는 많은 하위 트랜잭션으로 인해 DMS에서 논리적 디코딩 메모리를 사용할 수 있습니다. 이렇게 메모리 사용량이 증가하면 DMS가 디스크에 유출 파일을 생성하여 복제 중에 소스 지연 시간이 높아집니다.
소스 워크로드 증가의 영향을 줄이려면 다음을 수행합니다.
+ 장기 실행 트랜잭션을 줄입니다.
+ 하위 트랜잭션 수를 줄입니다.
+ 단일 트랜잭션에서 전체 테이블을 삭제하거나 업데이트하는 등 대량의 로그 레코드 버스트를 생성하는 작업을 수행하지 마세요. 대신 더 작은 배치로 작업을 수행합니다.
다음 CloudWatch 지표를 사용하여 소스의 워크로드를 모니터링할 수 있습니다.
+ `TransactionLogsDiskUsage`: 논리적 WAL이 현재 점유하는 바이트 수입니다. 논리적 복제 슬롯이 새 쓰기 속도를 따라갈 수 없거나 오래 실행되는 트랜잭션으로 인해 오래된 파일의 폐영역 회수가 불가능한 경우 이 값은 단조롭게 증가합니다.
+ `ReplicationSlotDiskUsage`: 논리적 복제 슬롯이 현재 사용하는 디스크 공간의 양입니다.
`logical_decoding_work_mem` 파라미터를 조정하여 소스 지연 시간을 줄일 수 있습니다. 이 파라미터의 기본값은 64MB입니다. 이 파라미터는 각 논리적 스트리밍 복제 연결에 사용되는 메모리의 양을 제한합니다. DMS가 디스크에 쓰는 디코딩된 변경의 양을 줄이려면 `logical_decoding_work_mem` 값을 `work_mem` 값보다 크게 설정하는 것이 좋습니다.
특히 마이그레이션 활동이나 지연 시간이 많은 기간에는 유출 파일을 정기적으로 확인하는 것이 좋습니다. DMS가 상당한 수의 유출 파일을 생성하는 경우 논리적 디코딩이 효율적으로 작동하지 않아 지연 시간이 늘어날 수 있습니다. 이를 완화하려면 `logical_decoding_work_mem` 파라미터 값을 늘리세요.
`aurora_stat_file` 함수를 사용하여 현재 트랜잭션 오버플로를 확인할 수 있습니다. 자세한 내용은 *Amazon Relational Database Service 개발자 안내서*의 [논리적 디코딩을 위한 작업 메모리 조정](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem)을 참조하세요.
# SQL Server 엔드포인트 문제 해결
이 섹션에는 SQL Server와 관련된 복제 시나리오가 나와 있습니다. SQL 서버에서 복제할 변경 사항을 확인하려면 트랜잭션 로그를 AWS DMS 읽고 소스 데이터베이스에서 주기적 스캔을 실행합니다. 일반적으로 복제 지연 시간이 발생하는 이유는 리소스 제약으로 인해 SQL Server에서 이러한 스캔을 스로틀링해서 그렇습니다. 짧은 시간 내에 트랜잭션 로그에 작성되는 이벤트 수가 크게 증가하기 때문일 수도 있습니다.
**Topics**
+ [
## 인덱스 재구축
](#CHAP_Troubleshooting_Latency_Source_SQLServer_Indexrebuilds)
+ [
## 대규모 트랜잭션
](#CHAP_Troubleshooting_Latency_Source_SQLServer_Largetransactions)
+ [
## Amazon RDS SQL 서버의 MS-CDC 폴링 간격이 잘못 구성된 경우
](#CHAP_Troubleshooting_Latency_Source_SQLServer_MisconfiguredCDC)
+ [
## 동일한 소스 데이터베이스에서 복제되는 여러 CDC 태스크
](#CHAP_Troubleshooting_Latency_Source_SQLServer_MultipleCDC)
+ [
## RDS for SQL Server에 대한 트랜잭션 로그 백업 처리
](#CHAP_Troubleshooting_Latency_Source_SQLServer_backup)
## 인덱스 재구축
SQL Server는 큰 인덱스를 재구축할 때 단일 트랜잭션을 사용합니다. 이로 인해 많은 이벤트가 생성되며, SQL Server가 한 번에 여러 인덱스를 재구축할 경우 많은 양의 로그 공간을 모두 사용하게 될 수 있습니다. 이렇게 되면 일시적인 복제 급증이 발생할 수 있습니다. SQL Server 소스에서 지속적으로 로그 급증이 발생할 경우 다음 사항을 확인하세요.
+ 먼저, `CDCLatencySource` 및 `CDCLatencySource` CloudWatch 지표를 사용하거나 태스크 로그의 처리량 모니터링 메시지를 확인하여 지연 시간이 급증하는 기간을 확인합니다. 에 대한 CloudWatch 지표에 대한 자세한 내용은 섹션을 AWS DMS참조하세요[복제 작업 지표](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task).
+ 지연 시간이 급증하는 동안 활성 트랜잭션 로그 또는 로그 백업의 크기가 증가했는지 확인합니다. 해당 기간에 유지 관리 작업이나 재구축이 실행되었는지도 확인합니다. 트랜잭션 로그 크기 확인에 대한 자세한 내용은 [SQL Server 기술 설명서](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)의 [Monitor log space use](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) 섹션을 참조하세요.
+ 유지 관리 계획이 SQL Server 모범 사례를 준수하는지 확인합니다. SQL Server 유지 관리 모범 사례에 대한 자세한 내용은 [SQL Server 기술 설명서](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)의 [Index maintenance strategy](https://learn.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver16#index-maintenance-strategy) 섹션을 참조하세요.
인덱스 재구축 중 지연 시간 문제를 해결하려면 다음을 수행합니다.
+ 오프라인 재구축에 `BULK_LOGGED` 복구 모델을 사용하면 태스크가 처리해야 하는 이벤트를 줄일 수 있습니다.
+ 가능한 경우, 인덱스 재구축 중에는 태스크를 중지합니다. 또는 사용량이 많지 않은 시간에 인덱스 재구축을 예약하여 지연 시간 급증으로 인한 영향을 완화하시기 바랍니다.
+ 디스크 지연 시간 또는 I/O 처리량처럼 DMS 읽기 속도를 저하시키는 리소스 병목 현상을 확인하고 이를 해결합니다.
## 대규모 트랜잭션
이벤트가 많은 트랜잭션 또는 장시간 실행 중인 트랜잭션으로 인해 트랜잭션 로그가 커집니다. 이 경우 DMS 읽기 시간이 길어져 지연 시간이 발생합니다. 이는 인덱스 재구축이 복제 성능에 미치는 영향과 유사합니다.
소스 데이터베이스의 일반적인 워크로드에 익숙하지 않다면 이 문제를 확인하기 어려울 수 있습니다. 이 문제를 해결하려면 다음을 수행합니다.
+ 먼저, `ReadThroughput` 및 `WriteThroughput` CloudWatch 지표를 사용하거나 태스크 로그의 처리량 모니터링 메시지를 확인하여 지연 시간이 급증한 시간을 파악합니다.
+ 지연 시간이 급증했을 때 소스 데이터베이스에 장시간 실행 중인 쿼리가 있는지 확인합니다. 장시간 실행 중인 쿼리에 대한 자세한 내용은 [SQL Server 기술 설명서](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)의 [Troubleshoot slow-running queries in SQL Server](https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-slow-running-queries) 섹션을 참조하세요.
+ 활성 트랜잭션 로그 또는 로그 백업의 크기가 증가했는지 확인합니다. 자세한 내용은 [SQL Server 기술 설명서](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)의 [Monitor log space use](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) 섹션을 참조하세요.
이 문제를 해결하려면 다음 중 하나를 수행합니다.
+ 가장 좋은 해결 방법은 애플리케이션 측에서 트랜잭션을 재구성하여 트랜잭션이 빠르게 완료되도록 하는 것입니다.
+ 트랜잭션을 재구성할 수 없는 경우, 단기적인 해결 방법은 디스크 대기 또는 CPU 경합과 같은 리소스 병목 현상이 있는지 확인하는 것입니다. 소스 데이터베이스에서 병목 현상이 발견되면 소스 데이터베이스의 디스크, CPU, 메모리 리소스를 늘려 지연 시간을 줄일 수 있습니다. 이렇게 하면 시스템 리소스 경합이 감소하여 DMS 쿼리를 더 빨리 완료할 수 있습니다.
## Amazon RDS SQL 서버의 MS-CDC 폴링 간격이 잘못 구성된 경우
Amazon RDS 인스턴스에서 폴링 간격 설정이 잘못 구성되면 트랜잭션 로그가 증가할 수 있습니다. 복제로 인해 로그 잘림이 방지되기 때문입니다. 실행 중인 태스크를 지연 시간을 최소화하여 계속 복제할 수 있긴 하지만, 태스크를 중지 및 재개하거나 CDC 전용 작업을 시작할 경우 태스크가 실패할 수 있습니다. 대용량 트랜잭션 로그를 스캔하는 동안 시간 초과가 발생하기 때문입니다.
잘못 구성된 폴링 간격 문제를 해결하려면 다음을 수행합니다.
+ 활성 트랜잭션 로그 크기가 증가하고 있는지, 그리고 로그 사용량이 100%에 가까운지 확인합니다. 자세한 내용은 [SQL Server 기술 설명서](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)의 [Monitor log space use](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) 섹션을 참조하세요.
+ `log_reuse_wait_desc value`의 원인이 `REPLICATION`이기 때문에 로그 잘림이 지연되고 있는 것인지 확인합니다. 자세한 내용은 [SQL Server 기술 설명서](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16)의 [The Transaction Log (SQL Server)](https://learn.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver16#FactorsThatDelayTruncation) 섹션을 참조하세요.
이전 목록의 주제에서 문제가 발견될 경우, MS-CDC 폴링 간격을 튜닝합니다. 폴링 간격 튜닝에 대한 자세한 내용은 [RDS for SQL Server를 소스로 사용할 때 권장되는 설정 AWS DMS](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.Configuration.Settings) 섹션을 참조하세요.
## 동일한 소스 데이터베이스에서 복제되는 여러 CDC 태스크
전체 로드 단계에서는 태스크 전체에서 테이블을 분할하여 성능을 개선하고, 종속 테이블을 논리적으로 분리하고, 태스크 실패로 인한 영향을 완화하는 것이 좋습니다. 하지만 CDC 단계에서는 태스크를 통합하여 DMS 스캔을 최소화하는 것이 바람직합니다. CDC 단계에서 각 DMS 태스크는 1분에 여러 번 트랜잭션 로그를 스캔하여 새 이벤트가 있는지 확인합니다. 각 태스크는 독립적으로 실행되므로 모든 태스크는 각각의 트랜잭션 로그를 개별적으로 스캔합니다. 이 경우 소스 SQL Server 데이터베이스의 디스크 및 CPU 사용량이 증가합니다. 따라서 많은 태스크를 동시에 실행하면 SQL Server가 DMS 읽기 속도를 제한할 수 있으므로, 지연 시간이 증가하게 됩니다.
여러 태스크가 점진적으로 시작될 경우, 이 문제를 확인하기 어려울 수 있습니다. 이 문제의 가장 일반적인 증상은 대부분의 태스크 스캔에 소요되는 시간이 더 길어지기 시작한다는 것입니다. 이 경우 이러한 스캔의 지연 시간이 길어집니다. SQL Server는 몇 가지 태스크 스캔의 우선 순위를 지정하므로, 일부 태스크에서는 정상적인 지연 시간이 표시됩니다. 이 문제를 해결하려면 모든 태스크에 대한 `CDCLatencySource` 지표를 확인합니다. 일부 태스크는 `CDCLatencySource`가 증가하는 반면, 일부 태스크는 `CDCLatencySource`가 낮을 경우 SQL Server가 일부 태스크의 DMS 읽기 속도를 스로틀링하고 있을 가능성이 높습니다.
CDC 중에 SQL Server가 태스크 읽기 속도를 스로틀링할 경우, 태스크를 통합하여 DMS 스캔 수를 최소화합니다. 경합을 생성하지 않고 소스 데이터베이스에 연결할 수 있는 최대 태스크 수는 소스 데이터베이스 용량, 트랜잭션 로그 증가율, 테이블 수 등과 같은 여러 요인에 따라 달라집니다. 복제 시나리오에 적합한 태스크 수를 확인하려면 프로덕션 환경과 비슷한 테스트 환경에서 복제를 테스트하세요.
## RDS for SQL Server에 대한 트랜잭션 로그 백업 처리
AWS DMS 3.5.3 이상에서는 RDS for SQL Server 로그 백업에서 복제를 지원합니다. RDS 인스턴스의 백업 로그에서 이벤트를 복제하는 것은 활성 트랜잭션 로그에서 이벤트를 복제하는 것보다 느립니다. 이는 DMS가 트랜잭션 시퀀스를 유지하고 Amazon RDS 인스턴스 스토리지 채우기 위험을 최소화하기 위해 백업에 대한 액세스를 직렬로 요청하기 때문입니다. 또한 Amazon RDS 종료 시 DMS에 백업을 제공하는 데 걸리는 시간은 로그 백업 크기와 RDS for SQL Server 인스턴스의 로드에 따라 달라집니다.
이러한 제약으로 인해 ECA `ActivateSafeguard`를 `true`로 설정하는 것이 좋습니다. 이렇게 하면 DMS 작업이 활성 트랜잭션 로그에서 읽는 동안 트랜잭션이 백업되지 않습니다. 또한 이 설정은 DMS가 백업에서 트랜잭션을 읽을 때 활성 로그의 Amazon RDS 아카이빙 트랜잭션을 방지하여 DMS가 활성 로그를 따라잡을 수 없는 가능성을 제거합니다. 하지만 이렇게 하면 태스크를 따라잡는 동안 활성 로그 크기가 증가할 수 있습니다. 인스턴스에 공간이 부족하지 않도록 인스턴스에 충분한 스토리지가 있는지 확인합니다.
RDS for SQL Server 소스에서 복제하는 CDC 전용 작업의 경우 가능하면 네이티브 CDC 시작 시간 동안 네이티브 CDC 시작 위치를 사용합니다. 이는 DMS가 기본 시작 시간을 지정할 때 개별 로그 백업을 스캔하는 대신 시스템 테이블에 의존하여 기본 시작 위치의 시작점을 식별하기 때문입니다.
# 대상 지연 시간 문제 해결
이 섹션에는 대상 지연 시간에 영향을 미칠 수 있는 시나리오가 나와 있습니다.
**Topics**
+ [
## 인덱싱 문제
](#CHAP_Troubleshooting_Latency_Target_Indexing)
+ [
## 태스크 로그의 SORTER 메시지
](#CHAP_Troubleshooting_Latency_Target_Sorter)
+ [
## 데이터베이스 잠금
](#CHAP_Troubleshooting_Latency_Target_Locking)
+ [
## 느린 LOB 조회
](#CHAP_Troubleshooting_Latency_Target_LOB)
+ [
## 다중 AZ, 감사 로깅, 백업
](#CHAP_Troubleshooting_Latency_Target_MultiAZ)
## 인덱싱 문제
CDC 단계에서는 대상에서 DML 문(삽입, 업데이트 및 삭제)을 실행하여 소스의 변경 사항을 AWS DMS 복제합니다. DMS를 사용하는 이기종 마이그레이션의 경우, 소스와 대상의 인덱스 최적화 차이로 인해 대상에 쓰기 작업을 수행하는 데 더 오랜 시간이 걸릴 수 있습니다. 이 경우 대상 지연 시간 및 성능 문제가 발생합니다.
인덱싱 문제를 해결하려면 다음을 수행합니다. 이러한 단계의 절차는 데이터베이스 엔진마다 다릅니다.
+ 대상 데이터베이스의 쿼리 시간을 모니터링합니다. 대상과 소스의 쿼리 실행 시간을 비교하면 최적화가 필요한 인덱스를 나타낼 수 있습니다.
+ 느리게 실행 중인 쿼리에 대한 로깅을 활성화합니다.
장시간 실행 중인 복제의 인덱싱 문제를 해결하려면 다음을 수행합니다.
+ 소스 및 대상 데이터베이스의 인덱스를 튜닝하여 소스와 대상의 쿼리 실행 시간이 비슷해지도록 조정합니다.
+ 소스와 대상의 DML 쿼리에 사용된 보조 인덱스를 비교합니다. 대상의 DML 성능이 소스 DML 성능과 비슷하거나 더 나은지 확인합니다.
참고로, 인덱스를 최적화하는 절차는 데이터베이스 엔진에 따라 다릅니다. 소스 및 대상 인덱스를 튜닝할 수 있는 DMS 기능은 없습니다.
## 태스크 로그의 SORTER 메시지
대상 엔드포인트가 AWS DMS 에서 기록하는 변경 볼륨을 따라잡을 수 없는 경우 작업은 복제 인스턴스에 변경 사항을 캐싱합니다. 캐시가 내부 임계값보다 커지면 태스크는 소스에서 추가 변경 사항을 읽는 것을 중단합니다. DMS는 복제 인스턴스의 스토리지가 부족해지거나, 대기 중인 대량의 이벤트를 읽는 동안 태스크가 중단되는 것을 방지하기 위해 이러한 조치를 수행합니다.
이 문제를 해결하려면 CloudWatch 로그에서 다음 중 하나와 유사한 메시지가 있는지 확인합니다.
```
[SORTER ]I: Reading from source is paused. Total disk usage exceeded the limit 90% (sorter_transaction.c:110)
[SORTER ]I: Reading from source is paused. Total storage used by swap files exceeded the limit 1048576000 bytes (sorter_transaction.c:110)
```
로그에 첫 번째 메시지와 유사한 메시지가 있는 경우, 태스크에 대한 모든 추적 로깅을 비활성화하고 복제 인스턴스 스토리지를 늘립니다. 복제 인스턴스 스토리지 증가에 대한 자세한 내용은 [복제 인스턴스 수정](CHAP_ReplicationInstance.Modifying.md) 섹션을 참조하세요.
두 번째 메시지와 유사한 메시지가 로그에 있는 경우 다음을 수행합니다.
+ 트랜잭션이 많거나 장시간 실행 중인 DML 작업이 있는 테이블이 태스크의 다른 테이블에 종속되지 않을 경우, 해당 테이블을 별도의 태스크로 이동합니다.
+ `MemoryLimitTotal` 및 `MemoryKeepTime` 설정을 늘려 트랜잭션을 메모리에 보관하는 기간을 늘립니다. 이렇게 하면 지연 시간이 지속될 경우에는 도움이 되지 않지만, 트랜잭션 볼륨이 단기간에 급증하는 동안에는 지연 시간을 줄이는 데 도움이 될 수 있습니다. 이러한 태스크 설정에 대한 내용은 [변경 처리 튜닝 설정](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md) 섹션을 참조하세요.
+ `BatchApplyEnabled`를 `true`로 설정하여 트랜잭션에 일괄 적용을 사용할 수 있는지 평가합니다. `BatchApplyEnabled` 설정에 대한 내용은 [대상 메타데이터 작업 설정](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md) 섹션을 참조하세요.
## 데이터베이스 잠금
애플리케이션이 복제 대상으로를 사용하는 데이터베이스에 액세스하는 경우 애플리케이션 AWS DMS 은 DMS가 액세스하려는 테이블을 잠글 수 있습니다. 이 경우 잠금 경합이 발생합니다. DMS는 소스에서 발생한 순서대로 대상 데이터베이스에 변경 사항을 작성하므로, 잠금 경합으로 인해 한 테이블에 대한 쓰기 지연이 발생할 경우 모든 테이블에 대한 쓰기 작업이 지연됩니다.
이 문제를 해결하려면 대상 데이터베이스를 쿼리하여 잠금 경합 때문에 DMS 쓰기 트랜잭션이 차단되고 있는 것인지 확인합니다. 대상 데이터베이스가 DMS 쓰기 트랜잭션을 차단하고 있는 경우, 다음 중 하나 이상의 작업을 수행합니다.
+ 변경 사항을 더 자주 커밋하도록 쿼리를 재구성합니다.
+ 잠금 제한 시간 설정을 수정합니다.
+ 테이블을 분할하여 잠금 경합을 최소화합니다.
참고로, 잠금 경합을 최적화하는 절차는 데이터베이스 엔진에 따라 다릅니다. 잠금 경합을 튜닝할 수 있는 DMS 기능은 없습니다.
## 느린 LOB 조회
가 대형 객체(LOB) 열을 AWS DMS 복제하면 대상에 변경 사항을 쓰기 직전에 소스에 대한 조회를 수행합니다. 보통 이러한 조회로 인해 대상에 지연 시간이 발생하지는 않지만, 잠금으로 인해 소스 데이터베이스에서 조회가 지연되면 대상 지연 시간이 급증할 수 있습니다.
이 문제는 일반적으로 진단하기 어렵습니다. 이 문제를 해결하려면 태스크 로그에서 세부 디버깅을 활성화하고, DMS LOB 조회 호출의 타임스탬프를 비교합니다. 세부 디버깅 활성화에 대한 자세한 내용은 [AWS DMS 작업 로그 보기 및 관리](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs) 섹션을 참조하세요.
이 문제를 해결하려면 다음 작업을 수행합니다.
+ 소스 데이터베이스에 대한 SELECT 쿼리 성능을 개선합니다.
+ DMS LOB 설정을 튜닝합니다. LOB 설정에 대한 자세한 내용은 [대용량 이진 객체(LOB) 마이그레이션](CHAP_BestPractices.md#CHAP_BestPractices.LOBS) 섹션을 참조하세요.
## 다중 AZ, 감사 로깅, 백업
Amazon RDS 대상의 경우, 다음 작업을 수행하는 동안 대상 지연 시간이 증가할 수 있습니다.
+ 백업
+ 다중 가용 영역(다중 AZ)을 활성화한 후
+ 감사 또는 느린 쿼리 로그 등의 데이터베이스 로깅을 활성화한 후.
이러한 문제는 일반적으로 진단하기 어렵습니다. 이러한 문제를 해결하려면 Amazon RDS 유지 관리 기간 또는 데이터베이스 부하가 과중한 기간에 주기적인 급증이 발생하는 지연 시간을 모니터링합니다.
이러한 문제를 해결하려면 다음 작업을 수행합니다.
+ 가능하다면 단기 마이그레이션 중에는 다중 AZ, 백업 또는 로깅을 비활성화합니다.
+ 유지 관리 기간을 활동이 적은 기간으로 다시 예약합니다.