AWS Database Migration Service에서 마이그레이션 작업 문제 해결 - AWS Database Migration Service

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

AWS Database Migration Service에서 마이그레이션 작업 문제 해결

아래에는 AWS Database Migration Service(AWS DMS)와 관련된 문제 해결에 대한 주제가 나와 있습니다. 이러한 주제는 AWS DMS 및 선택한 엔드포인트 데이터베이스를 모두 사용하여 일반적인 문제를 해결하는 데 도움이 될 수 있습니다.

AWS Support 사례를 열면 지원 엔지니어가 엔드포인트 데이터베이스 구성 중 하나와 관련된 잠재적인 문제를 파악할 수 있습니다. 엔지니어가 데이터베이스에 대한 진단 정보를 반환하는 지원 스크립트를 실행할 것을 요청할 수도 있습니다. 이러한 유형의 지원 스크립트에서 진단 정보를 다운로드, 실행, 업로드하는 방법에 대한 자세한 내용은 AWS DMS에서 진단 지원 스크립트 작업 섹션을 참조하세요.

문제 해결을 위해 복제 인스턴스에서 추적 및 덤프 파일을 AWS DMS 수집합니다. 문제 해결이 필요한 문제가 발생하는 경우 AWS Support에 이러한 파일을 제공할 수 있습니다. 기본적으로 DMS는 30일이 지난 추적 및 덤프 파일을 제거합니다. 추적 및 덤프 파일 수집을 거부하려면 AWS Support에 케이스를 여십시오.

마이그레이션 태스크가 느리게 실행됨

마이그레이션 작업이 느리게 실행되거나 연속 작업이 초기 작업보다 느리게 실행되도록 만들 수 있는 여러 문제가 있습니다.

마이그레이션 태스크가 느리게 실행되는 가장 일반적인 이유는 AWS DMS 복제 인스턴스에 부적절한 리소스가 할당되었기 때문입니다. 복제 인스턴스의 CPU, 메모리, 스왑 파일, IOPS 사용량을 확인하여 실행 중인 태스크를 지원하는 리소스가 인스턴스에 충분히 있는지 확인합니다. 예를 들어, 엔드포인트로서 Amazon Redshift에서 여러 태스크를 실행하면 I/O가 집중적으로 사용됩니다. 복제 인스턴스용 IOPS를 눌리거나 여러 복제 인스턴스에서 작업을 분할하면 보다 효율적인 마이그레이션이 가능합니다.

복제 인스턴스 크기 결정에 대한 자세한 내용은 복제 인스턴스에 가장 적합한 크기 선택 섹션을 참조하세요.

다음 작업을 수행하여 초기 마이그레이션 로드 속도를 촉진할 수 있습니다.

  • 대상이 Amazon RDS DB 인스턴스인 경우, 다중 AZ가 대상 DB 인스턴스에서 활성화되지 않도록 해야 합니다.

  • 로드 중에 대상 데이터베이스에서 자동 백업 또는 로깅 기능을 끄고, 마이그레이션이 완료된 후 이러한 기능을 다시 켭니다.

  • 이 기능을 대상에서 사용할 수 있는 경우, 프로비저닝된 IOPS를 사용합니다.

  • 마이그레이션 데이터에 LOB가 포함된 경우, 작업이 LOB 마이그레이션에 최적화되어 있는지 확인합니다. LOB를 위한 최적화에 대한 자세한 내용은 대상 메타데이터 작업 설정 섹션을 참조하세요.

태스크 상태 표시줄이 움직이지 않음

작업 상태 표시줄은 작업 진행률의 추정치를 나타냅니다. 이 추정치의 품질은 소스 데이터베이스의 테이블 통계 품질에 따라 달라지며, 테이블 통계 품질이 좋을수록 추정 정확도가 높아집니다.

추정 행 통계 없이 단 하나의 테이블을 사용하는 태스크의 경우, AWS DMS는 모든 유형의 완료율 추정치를 제공할 수 없습니다. 이 경우 태스크 상태와 로드되는 행 표시를 사용하여 태스크가 실제로 실행 및 진행되고 있다는 것을 확인할 수 있습니다.

태스크가 완료되었지만 아무것도 마이그레이션되지 않음

태스크가 완료된 후 아무것도 마이그레이션되지 않은 경우 다음을 수행합니다.

  • 엔드포인트를 생성한 사용자에게 마이그레이션하려는 테이블에 대한 읽기 권한이 있는지 확인합니다.

  • 마이그레이션하려는 객체가 테이블인지 확인합니다. 보기인 경우, 테이블 매핑을 업데이트하고 객체 로케이터를 'view' 또는 'all'로 지정합니다. 자세한 설명은 콘솔에서 테이블 선택 및 변환 규칙 지정 섹션을 참조하세요.

외부 키와 보조 인덱스 누락

AWS DMS는 테이블과 프라이머리 키를 생성하고 경우에 따라 고유 인덱스도 생성하지만, 소스의 데이터를 효율적으로 마이그레이션하는 데 필요하지 않은 다른 객체는 생성하지 않습니다. 예를 들어 보조 인덱스, 기본이 아닌 키 제약 조건 또는 데이터 기본값을 생성하지 않습니다.

데이터베이스에서 보조 객체를 마이그레이션하려면, 원본 데이터베이스와 동일한 데이터베이스 엔진으로 이동할 경우 데이터베이스의 기본 도구를 사용합니다. 보조 객체를 마이그레이션하기 위해 소스 데이터베이스가 사용하는 것과 다른 데이터베이스 엔진으로 마이그레이션할 경우 AWS Schema Conversion Tool(AWS SCT)을 사용합니다.

AWS DMS CloudWatch 로그를 생성하지 않습니다.

복제 작업에서 CloudWatch 로그가 생성되지 않는 경우 계정에 dms-cloudwatch-logs-role 역할이 있는지 확인하세요. 이 역할이 없는 경우 다음을 수행하여 생성합니다.

  1. AWS Management Console에 로그인하고 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.

  2. 역할 탭을 선택합니다. Create role(역할 생성)을 선택합니다.

  3. 신뢰할 수 있는 유형의 엔터티 선택 섹션에서 AWS 서비스를 선택합니다.

  4. 사용 사례 선택 섹션에서 DMS를 선택합니다.

  5. 다음: 권한을 선택합니다.

  6. 검색 AmazonDMSCloudWatchLogsRole 필드에 을 입력하고 CloudWatchLogsRoleAmazonDMS 옆의 체크박스를 선택합니다. 이렇게 하면 AWS DMS 액세스 권한이 부여됩니다. CloudWatch

  7. 다음: 태그를 선택합니다.

  8. 다음: 검토를 선택합니다.

  9. 역할 이름dms-cloudwatch-logs-role을 입력합니다. 이 이름은 대/소문자를 구분합니다.

  10. Create role(역할 생성)을 선택합니다.

Amazon RDS에 연결할 때 문제가 발생함

소스 또는 대상으로 설정한 Amazon RDS DB 인스턴트에 연결할 수 없는 이유에는 여러 가지가 있습니다. 확인해야 할 몇 가지 항목은 다음과 같습니다.

  • 사용자 이름과 암호 조합이 올바른지 확인합니다.

  • 인스턴스의 Amazon RDS 콘솔에 표시된 엔드포인트 값이 AWS DMS 엔드포인트를 생성하는 데 사용된 엔드포인트 식별자와 동일한지 확인합니다.

  • 인스턴스의 Amazon RDS 콘솔에 표시된 포트 값이 AWS DMS 엔드포인트에 할당된 포트와 동일한지 확인합니다.

  • Amazon RDS DB 인스턴스에 할당된 보안 그룹이 AWS DMS 복제 인스턴스의 연결을 허용하는지 확인합니다.

  • AWS DMS 복제 인스턴스와 Amazon RDS DB 인스턴스가 동일한 Virtual Private Cloud(VPC)에 없는 경우, DB 인스턴스에 공개적으로 액세스할 수 있는지 확인합니다.

오류 메시지: Incorrect thread connection string: incorrect thread value 0

이 오류는 흔히 엔드포인트와의 연결을 테스트할 때 발생할 수 있습니다. 이 오류는 연결 문자열에 오류가 있음을 나타냅니다. 호스트 IP 주소 뒤의 공백을 예로 들 수 있습니다. 또 다른 예로, 연결 문자열에 잘못된 문자를 복사하는 경우도 있습니다.

네트워킹 문제 발생

가장 일반적인 네트워킹 문제에는 AWS DMS 복제 인스턴스에서 사용하는 VPC 보안 그룹이 포함됩니다. 기본적으로 이 보안 그룹에는 모든 포트에서 0.0.0.0/0로의 발신을 허용하는 규칙이 있습니다. 대부분의 경우 이 보안 그룹을 수정하거나 자체 보안 그룹을 사용합니다. 이렇게 할 경우, 최소한 각 데이터베이스 포트의 소스 및 대상 엔드포인트에 송신을 제공해야 합니다.

그 밖의 구성 관련 문제에는 다음이 포함될 수 있습니다.

  • 동일한 VPC의 복제 인스턴스와 소스 및 대상 엔드포인트 – 엔드포인트에서 사용하는 보안 그룹은 복제 인스턴스의 데이터베이스 포트에서 수신을 허용해야 합니다. 복제 인스턴스에서 사용하는 보안 그룹에 엔드포인트로의 수신이 있는지 확인합니다. 그렇지 않을 경우, 복제 인스턴스 액세스의 프라이빗 IP 주소를 허용하고 엔드포인트가 사용하는 보안 그룹에 규칙을 생성할 수 있습니다.

  • 소스 엔드포인트가 복제 인스턴스에서 사용하는 VPC 외부에 있음(인터넷 게이트웨이 사용) – VPC 보안 그룹에는 VPC로 전달되지 않고 인터넷 게이트웨이로 트래픽을 전송하는 라우팅 규칙이 포함되어야 합니다. 이 구성에서 엔드포인트와의 연결이 복제 인스턴스의 퍼블릭 IP 주소에서 오는 것으로 나타납니다.

  • 소스 엔드포인트가 복제 인스턴스에서 사용하는 VPC 외부에 있음(NAT 게이트웨이 사용) - 단일 탄력적 네트워크 인터페이스에 연결된 단일 탄력적 IP 주소를 사용하여 Network Address Translation(NAT) 게이트웨이를 구성할 수 있습니다. 이 NAT 게이트웨이는 NAT 식별자(nat-#####)를 수신합니다.

    경우에 따라 VPC에는 인터넷 게이트웨이 대신, 이러한 NAT 게이트웨이에 대한 기본 경로가 포함됩니다. 이러한 경우 복제 인스턴스는 NAT 게이트웨이의 퍼블릭 IP 주소를 사용하여 데이터베이스 엔드포인트에 접속하는 것으로 보입니다. 이런 상황에서 VPC 외부에 있는 데이터베이스 엔드포인트로의 수신은 복제 인스턴스의 퍼블릭 IP 주소가 아닌 NAT 주소의 수신을 허용해야 합니다.

자체 온프레미스 네임 서버 사용에 대한 자세한 내용은 자체 온프레미스 이름 서버 사용 섹션을 참조하세요.

전체 로드 후 CDC 중단

느리거나 중단된 복제 변경은 여러 AWS DMS 설정이 서로 충돌할 때 전체 로드 마이그레이션 이후에 나타날 수 있습니다.

예를 들어 대상 테이블 준비 모드 파라미터가 아무 작업 안 함 또는 자르기로 설정되어 있다고 가정해 보겠습니다. 이 경우 기본 및 고유 인덱스 생성을 포함하여, 대상 테이블에서 설정을 수행하지 않도록 AWS DMS에 지시했습니다. 대상 테이블에서 기본 또는 고유 키를 생성하지 않은 경우, AWS DMS는 업데이트를 할 때마다 전체 테이블 스캔을 수행합니다. 이런 접근 방식은 성능에 상당한 영향을 미칠 수 있습니다.

태스크 재시작 시 프라이머리 키 위반 오류 발생

이 오류는 데이터가 이전 마이그레이션 작업의 대상 데이터베이스에 있을 때 발생할 수 있습니다. 대상 테이블 준비 모드 옵션을 아무 작업 안 함으로 설정하면, AWS DMS에서는 이전 태스크에서 삽입된 데이터 정리 등을 포함하여, 대상 테이블에서 어떠한 준비도 수행하지 않습니다.

작업을 다시 시작하고 이러한 오류를 방지하려면, 이전 태스크 실행에서 대상 테이블에 삽입된 행을 제거합니다.

스키마 초기 로드 실패

경우에 따라 Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails= 오류가 발생하여 스키마의 초기 로드가 실패할 수 있습니다.

이러한 경우 AWS DMS가 소스 엔드포인트에 연결하는 데 사용하는 사용자 계정에 필요한 권한이 없는 상태입니다.

알 수 없는 오류로 인해 태스크 실패

알 수 없는 유형의 오류가 발생하는 원인은 다양할 수 있습니다. 하지만 AWS DMS 복제 인스턴스에 할당된 리소스가 부족하기 때문에 문제가 발생하는 경우가 종종 있습니다.

복제 인스턴스의 CPU, 메모리, 스왑 파일, IOPS 사용량을 확인하여 마이그레이션을 수행하는 리소스가 인스턴스에 충분히 있는지 확인합니다. 모니터링에 대한 자세한 내용은 AWS Database Migration Service 지표 섹션을 참조하십시오.

시작부터 작업 재시작 시 테이블 로드

테이블의 초기 로드가 끝나지 않으면 AWS DMS는 테이블 로드를 처음부터 다시 시작합니다. 태스크가 다시 시작되면 AWS DMS는 초기 로드가 완료되지 않은 상태에서 테이블을 처음부터 다시 로드합니다.

태스크당 테이블 수로 인해 문제 발생

복제 태스크당 테이블 수에 대한 제한은 설정되어 있지 않습니다. 그러나 한 태스크의 테이블 수는 60,000개 미만으로 제한하는 것이 좋습니다. 단일 작업에서 60,000개 이상의 테이블을 사용할 때 리소스에 흔히 병목 현상이 발생할 수 있습니다.

LOB 열에 프라이머리 키가 생성되면 태스크가 실패함

FULL LOB 또는 LIMITED LOB 모드에서 AWS DMS는 LOB 데이터 형식인 프라이머리 키의 복제를 지원하지 않습니다.

DMS는 처음에 LOB 열이 null인 행을 마이그레이션한 다음 나중에 LOB 열을 업데이트합니다. 따라서 LOB 열에 기본 키가 생성되면 기본 키가 null이 될 수 없으므로 초기 삽입이 실패합니다. 차선책으로서 다른 열을 프라이머리 키로 추가하고 LOB 열에서 프라이머리 키를 제거합니다.

프라이머리 키가 없는 대상 테이블에서 중복 레코드 발생

전체 로드 및 CDC 태스크를 실행하면 프라이머리 키 또는 고유 인덱스가 없는 대상 테이블에 중복 레코드를 생성할 수 있습니다. 전체 로드 및 CDC 태스크 중에 대상 테이블에 레코드가 중복되지 않도록 하려면 대상 테이블에 프라이머리 키 또는 고유 인덱스가 있어야 합니다.

소스 엔드포인트가 예약된 IP 범위에 속함

AWS DMS 소스 데이터베이스가 예약된 IP 범위 내의 IP 주소 192.168.0.0/24를 사용하는 경우 소스 엔드포인트 연결 테스트가 실패합니다. 다음 단계에서는 가능한 해결 방법을 제공합니다.

  1. 192.168.0.0/24에서 소스 데이터베이스와 통신할 수 있는 예약된 범위에 없는 Amazon EC2 인스턴스를 찾습니다.

  2. socat 프록시를 설치하고 실행합니다. 다음은 그 한 예입니다.

    yum install socat socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port &

AWS DMS 엔드포인트에 대해 위에서 지정한 Amazon EC2 인스턴스 IP 주소와 데이터베이스 포트를 사용합니다. 엔드포인트에 AWS DMS가 데이터베이스 포트에 액세스할 수 있도록 허용하는 보안 그룹이 있어야 합니다. 단, 프록시는 DMS 태스크 실행 기간에 실행해야 합니다. 사용 사례에 따라, 프록시 설정을 자동화해야 할 수도 있습니다.

Amazon Athena 쿼리에서 타임스탬프가 깨져 보임

Athena 쿼리에서 타임스탬프가 제대로 표시되지 않는 경우 AWS Management Console 또는 ModifyEndpoint작업을 사용하여 Amazon S3 엔드포인트의 parquetTimestampInMillisecond 값을 로 설정하십시오. true 자세한 내용은 S3Settings 섹션을 참조하세요.

Oracle 관련 문제 해결

아래에서 AWS DMS를 Oracle 데이터베이스와 함께 사용했을 때 발생하는 문제에 대한 해결 방법을 배울 수 있습니다.

보기에서 데이터 가져오기

보기에서 데이터를 끌어와서 지속적인 복제에 사용할 수 없습니다. 보기에서 데이터를 추출하려면 Oracle 소스 엔드포인트 페이지의 엔드포인트 설정 섹션에 아래와 같은 코드를 추가해야 합니다. 보기에서 데이터를 추출하면 보기가 대상 스키마에서 테이블로 표시됩니다.

"ExposeViews": true

12c에서 LOB 마이그레이션

AWS DMS두 가지 방법, 즉 바이너리 리더와 Oracle을 사용하여 Oracle 데이터베이스의 변경 내용을 캡처할 수 있습니다. LogMiner 기본적으로 LogMiner Oracle을 AWS DMS 사용하여 변경 사항을 캡처합니다. 하지만 Oracle 12c에서는 오라클이 LOB 열을 LogMiner 지원하지 않습니다. Oracle 12c에서 LOB 열의 변경 사항을 캡처하려면, Binary Reader를 사용합니다.

LogMiner오라클과 바이너리 리더 간 전환

AWS DMS원본 Oracle 데이터베이스의 변경 내용을 캡처하는 데 바이너리 리더와 Oracle이라는 두 가지 방법을 사용할 수 LogMiner 있습니다. LogMiner Oracle이 기본값입니다. 변경 캡처를 위해 Binary Reader 사용으로 전환하려면, 다음 작업을 수행합니다.

변경 캡처를 위해 Binary Reader를 사용하려면
  1. https://console.aws.amazon.com/dms/v2/ 에서 AWS Management Console 로그인하고 AWS DMS 콘솔을 엽니다.

  2. 엔드포인트를 선택합니다.

  3. Binary Reader를 사용할 Oracle 소스 엔드포인트를 선택합니다.

  4. 수정을 선택합니다.

  5. 고급을 선택한 다음, 추가 연결 속성에 대해 아래의 코드를 추가합니다.

    useLogminerReader=N
  6. SQL-Plus와 같은 Oracle 개발자 도구를 사용하여 Oracle 엔드포인트에 연결하는 데 사용되는 AWS DMS 사용자 계정에 추가 권한을 부여합니다.

    SELECT ON V_$TRANSPORTABLE_PLATFORM

오류: Oracle CDC stopped 122301 Oracle CDC maximum retry counter exceeded.

AWS DMS에서 Oracle 보관 로그를 사용하여 변경 사항을 캡처하기 전에 서버에서 필요한 Oracle 보관 로그를 제거할 때 이 오류가 발생합니다. 데이터 서버에서 로그 보존 기간 정책을 증가시킵니다. Amazon RDS 데이터베이스에서는 다음 절차를 실행하여 로그 보존 기간을 증가시킵니다. 예를 들어, 다음 코드는 Amazon RDS DB 인스턴스에서 로그 보존 기간을 24시간으로 증가시킵니다.

exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

보충 로깅을 Oracle 소스 엔드포인트에 자동으로 추가합니다.

기본적으로 AWS DMS에서는 보충 로깅을 끕니다. 원본 Oracle 엔드포인트에서 보충 로깅을 자동으로 켜려면, 다음을 수행합니다.

보충 로깅을 소스 Oracle 엔드포인트에 추가하려면
  1. https://console.aws.amazon.com/dms/v2/ 에서 AWS Management Console 로그인하고 AWS DMS 콘솔을 엽니다.

  2. 엔드포인트를 선택합니다.

  3. 보충 로깅을 추가할 Oracle 원본 엔드포인트를 선택합니다.

  4. 수정을 선택합니다.

  5. 고급을 선택하고 나서 추가 연결 속성 텍스트 상자에 다음 코드를 추가합니다.

    addSupplementalLogging=Y
  6. 수정을 선택합니다.

LOB 변경 사항이 캡처되지 않음

현재 테이블에는 LOB 변경 사항을 캡처하기 위한 AWS DMS의 기본 키가 있어야 합니다. LOB를 포함하는 테이블에 기본 키가 없는 경우, LOB 변경 사항을 캡처하기 위해 취할 수 있는 몇 가지 조치가 있습니다.

  • 테이블에 기본 키를 추가합니다. 이 작업은 트리거를 사용하여 ID 열을 추가하고 이 열을 시퀀스로 채우는 것만큼이나 간편합니다.

  • 프라이머리 키로서 시스템에서 생성한 ID를 포함하는 테이블의 구체화된 뷰를 생성하고 테이블 이외에 구체화된 뷰를 마이그레이션합니다.

  • 논리 대기를 생성하고, 테이블에 기본 키를 추가하고, 논리 대기에서 마이그레이션합니다.

오류: ORA-12899: value too large for column column-name

"ORA-12899: value too large for column column-name" 오류는 주로 몇 가지 문제로 인해 발생합니다.

이러한 문제 중 하나는 소스 데이터베이스와 대상 데이터베이스에서 사용하는 문자 집합이 일치하지 않는 것입니다.

또 다른 문제는 두 데이터베이스의 National Language Support(NLS) 설정이 다르다는 점입니다. 이 원인의 일반적인 원인은 원본 데이터베이스 NLS_LENGTH_SEMANTICS 파라미터가 CHAR로 설정되고 대상 데이터베이스 NLS_LENGTH_SEMANTICS 파라미터가 BYTE로 설정되어 있기 때문입니다.

NUMBER 데이터 형식 오해

Oracle NUMBER 데이터 형식은 정밀도와 NUMBER 크기에 따라 여러 AWS DMS 데이터 형식으로 변환됩니다. 이 변환은 Oracle용 소스 데이터 형식에 소개되어 있습니다. 소스 Oracle 엔드포인트에 엔드포인트 설정을 사용할 경우 NUMBER 형식의 변환 방식에 영향을 미칠 수도 있습니다. 이러한 엔드포인트 설정은 Oracle을 소스로 사용할 때의 엔드포인트 설정 AWS DMS에 설명되어 있습니다.

전체 로드 중 레코드 누락

전체 로드를 수행할 경우, AWS DMS는 데이터베이스 수준에서 열린 트랜잭션을 찾은 후 트랜잭션이 커밋될 때까지 대기합니다. 예를 들어, 태스크 설정 TransactionConsistencyTimeout=600이 기준인 경우 AWS DMS는 테이블 매핑에 포함되지 않은 테이블에 열린 트랜잭션이 있더라도 10분간 대기합니다. 그러나 열린 트랜잭션이 테이블 매핑에 포함된 테이블에 있고, 트랜잭션이 제시간에 커밋되지 않으면 대상 테이블 결과에서 레코드가 누락됩니다.

열린 트랜잭션을 커밋하는 데 시간이 오래 걸린다는 점을 알게 된 경우, TransactionConsistencyTimeout 태스크 설정을 수정하고 대기 시간을 늘릴 수 있습니다.

또한 FailOnTransactionConsistencyBreached 태스크 설정의 기본값은 false입니다. 즉, AWS DMS가 다른 트랜잭션은 계속 적용하지만 열린 트랜잭션은 누락됩니다. 열린 트랜잭션이 제 시간에 종료되지 않은 경우 태스크가 실패하도록 설정하려면 FailOnTransactionConsistencyBreachedtrue로 설정하면 됩니다.

테이블 오류

Table Error 절이 프라이머리 키 열을 참조하지 않고, 모든 열에 보충 로깅이 사용되지 않을 경우 복제 중에 테이블 통계에 WHERE가 표시됩니다.

이 문제를 해결하려면 참조된 테이블의 모든 열에 대해 보충 로깅을 설정합니다. 자세한 설명은 보충 로깅 설정 섹션을 참조하세요.

오류: Cannot retrieve Oracle archived Redo log destination ids

이 오류는 Oracle 소스에 생성된 아카이브 로그가 없거나, V$ARCHIVED_LOG가 비어 있는 경우 발생합니다. 로그를 수동으로 전환하여 오류를 해결할 수 있습니다.

Amazon RDS 데이터베이스에서는 다음 절차를 실행하여 로그 파일을 전환합니다. switch_logfile 절차에는 파라미터가 없습니다.

exec rdsadmin.rdsadmin_util.switch_logfile;

자체 관리형 Oracle 소스 데이터베이스에서는 아래의 명령을 사용하여 로그 전환을 적용합니다.

ALTER SYSTEM SWITCH LOGFILE ;

Oracle 재실행 로그 또는 아카이브 로그의 읽기 성능 평가

Oracle 소스에서 성능 문제가 발생할 경우, Oracle 재실행 로그 또는 아카이브 로그의 읽기 성능을 평가하여 성능을 개선할 방법을 찾을 수 있습니다. 재실행 또는 아카이브 로그의 읽기 성능을 테스트하려면 AWS DMS 진단 Amazon Machine Image(AMI)를 사용합니다.

AWS DMS 진단 AMI를 사용하면 다음 작업을 수행할 수 있습니다.

  • bFile 메서드를 사용하여 재실행 로그 파일의 성능을 평가합니다.

  • LogMiner 메서드를 사용하여 리두 로그 파일 성능을 평가하십시오.

  • PL/SQL(dbms_lob.read) 메서드를 사용하여 재실행 로그 파일의 성능을 평가합니다.

  • 단일 스레드를 사용하여 ASMFile의 읽기 성능을 평가합니다.

  • 다중 스레드를 사용하여 ASMFile의 읽기 성능을 평가합니다.

  • Direct OS Readfile() Windows 또는 Pread64 Linux 함수를 사용하여 재실행 로그 파일을 평가합니다.

그런 다음, 결과에 따라 수정 단계를 진행할 수 있습니다.

Oracle 재실행 또는 아카이브 로그 파일의 읽기 성능을 테스트하려면
  1. AWS DMS 진단 AMI Amazon EC2 인스턴스를 생성한 후 이 인스턴스에 연결합니다.

    자세한 내용은 AWS DMS 진단 AMI 작업 섹션을 참조하세요.

  2. awsreplperf 명령을 실행합니다.

    $ awsreplperf

    이 명령은 AWS DMS Oracle 읽기 성능 유틸리티 옵션을 표시합니다.

    0. Quit 1. Read using Bfile 2. Read using LogMiner 3. Read file PL/SQL (dms_lob.read) 4. Read ASMFile Single Thread 5. Read ASMFile Multi Thread 6. Readfile() function
  3. 목록에서 옵션을 선택합니다.

  4. 아래의 데이터베이스 연결 및 아카이브 로그 정보를 입력합니다.

    Oracle user name [system]: Oracle password: Oracle connection name [orcllx]: Connection format hostname:port/instance Oracle event trace? [N]: Default N = No or Y = Yes Path to redo or archive log file []:
  5. 표시된 출력에서 관련 읽기 성능 정보를 확인합니다. 예를 들어, 다음은 옵션 번호 2, 읽기 사용을 LogMiner 선택한 결과 발생할 수 있는 출력을 보여줍니다.

    읽기 성능 유틸리티 출력
  6. 유틸리티를 종료하려면 0을 입력합니다.

다음 단계
  • 결과에 읽기 속도가 허용 가능한 임계값 미만인 것으로 표시될 경우, 엔드포인트에서 Oracle 진단 지원 스크립트를 실행하고 대기 시간, 로드 프로필, IO 프로필 섹션을 검토합니다. 그런 다음, 읽기 성능을 개선할 수 있는 비정상적인 구성을 조정합니다. 예를 들어, 재실행 로그 파일이 최대 2GB인 경우 LOG_BUFFER를 200MB로 늘리면 성능을 개선하는 데 도움이 될 수 있습니다.

  • AWS DMS 모범 사례를 검토하여 DMS 복제 인스턴스, 태스크, 엔드포인트가 최적으로 구성되어 있는지 확인합니다.

MySQL 관련 문제 해결

아래에서 AWS DMS를 MySQL 데이터베이스와 함께 사용했을 때 발생하는 문제에 대한 해결 방법을 배울 수 있습니다.

이진 로깅 비활성화로 인해 Amazon RDS DB 인스턴스 엔드포인트에서 CDC 작업 실패

이 문제는 자동 백업이 비활성화되어 있기 때문에 Amazon RDS DB 인스턴스에서 발생합니다. 백업 보존 기간을 0이 아닌 값으로 설정하여 자동 백업을 활성화합니다.

작업 중에 대상 MySQL 인스턴스 연결이 끊김

MySQL 대상과 연결이 끊긴 LOB가 포함된 태스크가 있을 경우, 태스크 로그에 다음과 같은 유형의 오류가 표시될 수 있습니다.

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection to MySQL server during query [122502] ODBC general error.
[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away [122502] ODBC general error.

이 경우 일부 태스크 설정을 조정해야 할 수도 있습니다.

작업이 MySQL 대상과 연결이 끊기는 문제를 해결하려면, 다음 작업을 수행합니다.

  • 데이터베이스 변수 max_allowed_packet이 가장 큰 LOB를 보유할 수 있을 정도로 충분히 크게 설정되어 있는지 확인합니다.

  • 다음 변수가 큰 시간 초과 값을 갖도록 설정했는지 확인합니다. 이 변수 각각에서 최소 5분 이상의 값을 사용할 것을 제안합니다.

    • net_read_timeout

    • net_write_timeout

    • wait_timeout

MySQL 시스템 변수 설정에 대한 자세한 내용은 MySQL 설명서Server System Variables를 참조하세요.

MySQL 호환 엔드포인트에 자동 커밋 추가

대상 MySQL 호환 엔드포인트에 자동 커밋을 추가하려면
  1. 에 AWS Management Console 로그인하고 https://console.aws.amazon.com/dms/v2/ 에서 AWS DMS 콘솔을 엽니다.

  2. 엔드포인트를 선택합니다.

  3. 자동 커밋을 추가할 MySQL과 호환되는 대상 엔드포인트를 선택합니다.

  4. 수정을 선택합니다.

  5. 고급을 선택하고 나서 추가 연결 속성 텍스트 상자에 다음 코드를 추가합니다.

    Initstmt= SET AUTOCOMMIT=1
  6. 수정을 선택합니다.

대상 MySQL 호환 엔드포인트에서 외래 키 비활성화

대상 MySQL, Amazon Aurora MySQL 호환 에디션 또는 MariaDB 엔드포인트의 고급 섹션에 있는 추가 연결 속성에 아래의 코드를 추가하여 MySQL에서 외부 키 검사를 비활성화할 수 있습니다.

대상 MySQL 호환 엔드포인트에서 외래 키를 비활성화하려면
  1. https://console.aws.amazon.com/dms/v2/ 에서 AWS Management Console 로그인하고 AWS DMS 콘솔을 엽니다.

  2. 엔드포인트를 선택합니다.

  3. 외부 키를 비활성화할 MySQL, Aurora MySQL 또는 MariaDB 대상 엔드포인트를 선택합니다.

  4. 수정을 선택합니다.

  5. 고급을 선택하고 나서 추가 연결 속성 텍스트 상자에 다음 코드를 추가합니다.

    Initstmt=SET FOREIGN_KEY_CHECKS=0
  6. 수정을 선택합니다.

물음표로 대체된 문자

이 문제를 유발하는 가장 일반적인 상황은 원본 엔드포인트 문자가 AWS DMS에서 지원되지 않는 문자 집합으로 인코딩되는 경우입니다.

'Bad event' 로그 항목

마이그레이션 로그에서 'Bad event' 항목은 대개 소스 데이터베이스 엔드포인트에서 지원되지 않는 출력 데이터 정의 언어(DDL) 작업이 시도되었음을 나타냅니다. 지원되지 않는 DDL 작업은 복제 인스턴스가 건너뛸 수 없는 이벤트를 유발하므로 잘못된 이벤트가 로깅됩니다.

이 문제를 해결하려면 태스크를 처음부터 다시 시작합니다. 이렇게 하면 지원되지 않는 DDL 작업이 실행된 후 테이블이 다시 로드되고 변경 사항 캡처가 시작됩니다.

MySQL 5.5로 변경 데이터 캡처

Amazon RDS MySQL 호환 데이터베이스를 위한 AWS DMS 변경 데이터 캡처(CDC)에는 전체 이미지 행 기반 바이너리 로깅이 필요하며, 이는 MySQL 버전 5.5 이하에서 지원되지 않습니다. AWS DMS CDC를 사용하려면 Amazon RDS DB 인스턴스를 MySQL 버전 5.6으로 업그레이드해야 합니다.

Amazon RDS DB 인스턴스를 위한 이진 로그 보존 기간 증가

AWS DMS에서는 변경 데이터 캡처를 위한 바이너리 로그 파일 보존이 필요합니다. Amazon RDS 인스턴스에서 로그 보존 기간을 연장하려면, 다음 절차를 실행합니다. 다음은 이진 로그 보존 기간을 24시간으로 연장하는 예제입니다.

call mysql.rds_set_configuration('binlog retention hours', 24);

로그 메시지: 소스 데이터베이스의 일부 변경 사항은 대상 데이터베이스에 적용될 때 영향이 전혀 없었습니다.

AWS DMS가 MySQL 데이터베이스 열의 값을 기존 값으로 업데이트하면, zero rows affected의 메시지가 MySQL에서 반환됩니다. 이러한 동작은 Oracle 및 SQL Server와 같은 다른 데이터베이스 엔진과 다릅니다. 이러한 엔진은 대체 값이 현재 값과 동일한 경우에도 하나의 행을 업데이트합니다.

오류: Identifier too long

다음 오류는 식별자가 너무 길 때 발생합니다.

TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)

대상 데이터베이스에 테이블과 프라이머리 키를 생성하도록 AWS DMS를 설정하는 경우도 있습니다. 이러한 경우 DMS는 현재 소스 데이터베이스에서 사용된 프라이머리 키에 동일한 이름을 사용하지 않습니다. 대신, DMS는 테이블 이름을 기준으로 프라이머리 키 이름을 생성합니다. 테이블 이름이 길면, 자동 생성된 식별자는 MySQL에 허용된 한도보다 길 수 있습니다.

이 문제를 해결하기 위한 현재의 접근 방식은 먼저 대상 데이터베이스에 테이블과 프라이머리 키를 미리 생성하는 것입니다. 그런 다음, 태스크 설정 대상 테이블 준비 모드아무 작업 안 함 또는 자르기로 설정된 태스크를 사용하여 대상 테이블을 채웁니다.

오류: 지원되지 않는 문자 집합으로 인해 필드 데이터 변환 실패

다음 오류는 지원되지 않는 문자 집합으로 인해 필드 데이터 변환이 실패할 때 발생합니다.

"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] A field data conversion failed. (mysql_endpoint_capture.c:2154)

연결과 관련된 데이터베이스의 파라미터를 확인합니다. 다음 명령은 이 파라미터를 설정하는 데 사용할 수 있습니다.

SHOW VARIABLES LIKE '%char%';

오류: Codepage 1252 to UTF8 [120112] A field data conversion failed

원본 MySQL 데이터베이스에 codepage-1252 문자가 없을 경우 마이그레이션 중에 다음과 같은 오류가 발생할 수 있습니다.

[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table 'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. (mysql_endpoint_capture.c:2248)

차선책으로 CharsetMapping 추가 연결 속성을 원본 MySQL 엔드포인트와 함께 사용하여 문자 세트 매핑을 지정할 수 있습니다. 이 엔드포인트 설정을 추가하면 AWS DMS 마이그레이션 태스크를 처음부터 다시 시작해야 할 수 있습니다.

예를 들어, 소스 문자 집합이 Utf8 또는 latin1인 MySQL 소스 엔드포인트에 아래와 같은 엔드포인트 설정을 사용할 수 있습니다. 65001은 UTF8 코드 페이지 식별자입니다.

CharsetMapping=utf8,65001 CharsetMapping=latin1,65001

인덱스, 외부 키 또는 하위 항목 업데이트 또는 삭제가 마이그레이션되지 않음

AWS DMS는 인덱스 및 외부 키와 같은 보조 객체의 마이그레이션을 지원하지 않습니다. 하위 항목 업데이트 또는 삭제 작업에서 하위 테이블의 변경 사항을 복제하려면 트리거하는 외부 키 제약 조건이 대상 테이블에서 활성화된 상태여야 합니다. 이러한 제한을 해결하려면 대상 테이블에서 외부 키를 수동으로 생성합니다. 그런 다음, 아래에 설명된 대로 전체 로드 및 CDC를 위한 단일 태스크를 생성하거나, 전체 로드 및 CDC를 위한 별도의 태스크 두 개를 생성합니다.

전체 로드 및 CDC를 지원하는 단일 태스크 생성

이 절차에서는 전체 로드 및 CDC를 위한 단일 태스크를 사용하여 외부 키와 인덱스를 마이그레이션하는 방법을 설명합니다.

전체 로드 및 CDC 태스크 생성
  1. 대상에서 외부 키와 인덱스가 있는 테이블을 수동으로 생성하여 소스 테이블과 일치하도록 합니다.

  2. 대상 AWS DMS 엔드포인트에 아래의 ECA를 추가합니다.

    Initstmt=SET FOREIGN_KEY_CHECKS=0;
  3. TargetTablePrepModeDO_NOTHING으로 설정하여 AWS DMS 태스크를 생성합니다.

  4. Stop task after full load completes 설정값을 StopTaskCachedChangesApplied로 설정합니다.

  5. 태스크를 시작합니다. 전체 로드가 완료되면 AWS DMS가 자동으로 태스크를 중지하고 캐시된 변경 사항을 적용합니다.

  6. 이전에 추가한 SET FOREIGN_KEY_CHECKS ECA를 제거합니다.

  7. 태스크를 재개합니다. 태스크는 CDC 단계에 진입하고, 소스 데이터베이스의 지속적인 변경 사항을 대상에 적용합니다.

전체 로드 태스크 및 CDC 태스크를 별도로 생성

이 절차에서는 전체 로드 및 CDC를 위한 별도의 태스크를 사용하여 외부 키와 인덱스를 마이그레이션하는 방법을 설명합니다.

전체 로드 태스크 생성
  1. 대상에서 외부 키와 인덱스가 있는 테이블을 수동으로 생성하여 소스 테이블과 일치하도록 합니다.

  2. 대상 AWS DMS 엔드포인트에 아래의 ECA를 추가합니다.

    Initstmt=SET FOREIGN_KEY_CHECKS=0;
  3. TargetTablePrepMode 파라미터를 DO_NOTHING으로 설정하고 EnableValidationFALSE로 설정하여 AWS DMS 태스크를 생성합니다.

  4. 태스크를 시작합니다. 전체 로드가 완료되면 AWS DMS가 자동으로 태스크를 중지하고 캐시된 변경 사항을 적용합니다.

  5. 태스크가 완료되면 전체 로드 태스크 시작 시간(UTC) 또는 바이너리 로그 파일의 이름과 위치를 기록하여 CDC 전용 작업을 시작합니다. 로그를 참조하여 초기 전체 로드 시작 시간에서 타임스탬프(UTC)를 가져옵니다.

CDC 전용 태스크 생성
  1. 이전에 설정한 SET FOREIGN_KEY_CHECKS ECA를 제거합니다.

  2. 시작 위치를 이전 단계에서 기록한 전체 로드 시작 시간으로 설정하여 CDC 전용 태스크를 생성합니다. 또는 이전 단계에서 기록된 바이너리 로그 위치를 사용할 수도 있습니다. TargetTablePrepMode 설정값을 DO_NOTHING로 설정합니다. 필요한 경우 EnableValidation 설정을 TRUE로 설정하여 데이터 검증을 활성화합니다.

  3. CDC 전용 태스크를 시작하고, 로그에 오류가 있는지 모니터링합니다.

참고

이 해결 방법은 MySQL에서 MySQL로 마이그레이션하는 경우에만 적용됩니다. 일괄 적용 기능을 사용하려면 대상 테이블에 활성화된 외부 키가 없어야 하므로, 이 방법은 일괄 적용 기능과 함께 사용할 수 없습니다.

PostgreSQL 관련 문제 해결

아래에서 AWS DMS를 PostgreSQL 데이터베이스와 함께 사용했을 때 발생하는 문제에 대한 해결 방법을 배울 수 있습니다.

잘리는 JSON 데이터 형식

AWS DMS에서는 PostgreSQL의 JSON 데이터 형식을 LOB 데이터 형식 열로 간주합니다. 다시 말해서 제한된 LOB 모드를 사용할 때 LOB 크기 제한이 JSON 데이터에 적용됨을 의미합니다.

예를 들어, 제한된 LOB 모드가 4,096KB로 설정되어 있다고 가정해 보겠습니다. 이 경우 4,096KB를 초과하는 모든 JSON 데이터는 4,096KB 한도에서 잘리며 PostgreSQL에서 검증 테스트에 실패합니다.

다음 로그 정보에는 제한된 LOB 모드 설정 및 실패한 검증으로 인해 잘린 JSON 데이터가 나와 있습니다.

03:00:49 2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt 2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)  03:00:49 2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, Error while executing the query [1022502] (ar_odbc_stmt.c:2421) 2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

사용자 정의 데이터 형식 열이 올바르게 마이그레이션되지 않음

PostgreSQL 소스에서 복제할 때 AWS DMS는 모든 열에서 동일한 데이터 형식을 사용하여 대상 테이블을 생성하고, 이때 사용자 정의 데이터 형식을 사용한 열은 제외됩니다. 그러한 경우에 데이터 형식은 대상에서 ‘character varying’으로 생성됩니다.

오류: 생성하도록 선택된 스키마가 없음

경우에 따라 “SQL_ERROR SqlState: 3F000 NativeError: 7 메시지: 오류: 생성할 스키마를 선택하지 않았습니다.” 라는 오류가 표시될 수 있습니다.

JSON 테이블 매핑에 스키마에 대한 와일드카드 값이 포함되어 있지만 소스 데이터베이스가 해당 값을 지원하지 않는 경우, 이 오류가 발생할 수 있습니다.

테이블 삭제와 업데이트가 CDC를 사용하여 복제되지 않음

소스 테이블에 프라이머리 키가 없는 경우, 변경 데이터 캡처(CDC) 중에 삭제 및 업데이트 작업이 무시됩니다. AWS DMS는 프라이머리 키가 있는 PostgreSQL 테이블의 변경 데이터 캡처(CDC)를 지원합니다.

테이블에 프라이머리 키가 없는 경우, Write Ahead Log(WAL)에 데이터베이스 행의 이전 이미지가 포함되지 않습니다. 이 경우 AWS DMS는 테이블을 업데이트할 수 없습니다. 복제할 작업을 삭제하려면 소스 테이블에서 프라이머리 키를 생성합니다.

자르기 문이 전파되지 않고 있음

변경 데이터 캡처(CDC)를 사용할 때 TRUNCATE 작업이 AWS DMS에서 지원되지 않습니다.

PostgreSQL에서 DDL이 캡처되지 않음

아래의 엔드포인트 설정 문을 추가하여 PostgreSQL 대상 엔드포인트가 DDL 문을 캡처하지 않도록 할 수 있습니다.

"CaptureDDLs": "N"

DDL 캡처를 위해 데이터베이스 객체가 생성되는 스키마 선택

DDL 캡처와 관련된 데이터베이스 객체가 생성되는 스키마를 제어할 수 있습니다. 아래의 엔드포인트 설정 문을 추가합니다. 엔드포인트 설정 파라미터는 소스 엔드포인트의 탭에서 제공됩니다.

"DdlArtifactsSchema: "xyzddlschema"

PostgreSQL로 마이그레이션한 후 Oracle 테이블 누락

이 경우 일반적으로 테이블과 데이터에는 계속 액세스할 수 있습니다.

Oracle 기본값을 대문자 테이블 이름으로 설정하고, PostgreSQL 기본값을 소문자 테이블 이름으로 설정합니다. Oracle에서 PostgreSQL로 마이그레이션할 경우, 태스크의 테이블 매핑 섹션 아래에 특정 변환 규칙을 제공하는 것이 좋습니다. 이는 테이블 이름의 대소문자를 변환하는 변환 규칙입니다.

변환 규칙을 사용하지 않고 테이블을 마이그레이션하여 테이블 이름의 대소문자를 변환할 경우, 테이블 이름을 참조할 때 테이블 이름을 따옴표로 묶어야 합니다.

ReplicationSlotDiskUsage ETL 워크로드와 같은 긴 트랜잭션 중에는 restart_lsn이 증가하고 restart_lsn이 앞으로 이동하지 않습니다.

논리적 복제가 활성화된 경우 트랜잭션당 메모리에 보관되는 최대 변경 사항 수는 4MB입니다. 그 후에는 변경 사항이 디스크로 유출됩니다. 따라서 트랜잭션이 완료/중지되고 롤백이 완료될 때까지 ReplicationSlotDiskUsage가 증가하며 restart_lsn이 진행되지 않습니다. 트랜잭션이 길기 때문에 롤백하는 데 시간이 오래 걸릴 수 있습니다.

따라서 논리적 복제가 활성화된 경우, 장기 실행 트랜잭션은 피하세요. 대신 트랜잭션을 여러 개의 작은 트랜잭션으로 나눕니다.

소스로 보기를 사용한 작업에서 복사된 행이 없음

보기를 마이그레이션하려면 table-typeall 또는 view로 설정합니다. 자세한 설명은 콘솔에서 테이블 선택 및 변환 규칙 지정 섹션을 참조하세요.

보기를 지원하는 소스는 다음과 같습니다.

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2 LUW

  • SAP Adaptive Server Enterprise(ASE)

Microsoft SQL Server 관련 문제 해결

아래에서 AWS DMS를 Microsoft SQL Server 데이터베이스와 함께 사용했을 때 발생하는 문제에 대한 해결 방법을 배울 수 있습니다.

SQL Server 데이터베이스에서 변경 사항을 캡처하는 동안 발생하는 오류

변경 데이터 캡처(CDC) 중에 발생하는 오류는 흔히 사전 요구 사항 중 하나에 부합하지 않음을 나타낼 수 있습니다. 예를 들어, 자주 간과되는 사전 요구 사항은 전체 데이터베이스 백업입니다. 이 작업 로그에는 다음 오류와 함께 이러한 누락이 나타납니다.

SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). To enable all changes to be captured, you must perform a full database backup. 120438 Changes may be missed. (sqlserver_log_queries.c:2623)

Microsoft SQL Server 데이터베이스를 원본으로 사용 AWS DMS에서 원본으로서 SQL Server를 위해 나열된 사전 요구 사항을 검토합니다.

자격 증명 열 누락

AWS DMS는 대상 스키마를 생성할 때 자격 증명 열을 지원하지 않습니다. 초기 로드가 완료된 후 자격 증명 열을 추가해야 합니다.

오류: SQL Server doesn't support publications

SQL Server Express를 원본 엔드포인트로 사용할 때 다음 오류가 생성됩니다.

RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 Message: This edition of SQL Server does not support publications.

AWS DMS는 현재 SQL Server Express를 원본 또는 대상으로 지원하지 않습니다.

대상에 변경 사항이 표시되지 않음

AWS DMS에서 변경 사항을 일관성 있게 캡처하려면 원본 SQL Server 데이터베이스가 'FULL' 또는 'BULK LOGGED' 데이터 복구 모델에 있어야 합니다. 'SIMPLE' 모델은 지원되지 않습니다.

SIMPLE 복구 모델은 사용자가 데이터베이스를 복구하도록 허용하는 데 필요한 최소한의 정보를 로깅합니다. 체크포인트가 발생하면 모든 비활성 로그 항목은 자동으로 잘립니다.

모든 작업은 여전히 기록됩니다. 하지만 체크포인트가 발생하는 즉시 로그는 자동으로 잘립니다. 이렇게 잘리면 로그를 재사용할 수 있게 되고, 이전 로그 항목을 덮어쓸 수 있습니다. 로그 항목을 덮어쓰면 변경 사항을 캡처할 수 없습니다. 이 문제는 AWS DMS가 SIMPLE 데이터 복구 모델을 지원하지 않는 이유입니다. SQL Server를 소스로 사용할 때 다른 필요한 사전 요구 사항에 대한 정보는 Microsoft SQL Server 데이터베이스를 원본으로 사용 AWS DMS 섹션을 참조하세요.

파티션 간에 매핑된 비균일 테이블

변경 데이터 캡처(CDC) 중 AWS DMS가 테이블에서 CDC를 제대로 수행할 수 없는 경우 특수한 구조의 테이블 마이그레이션이 일시 중단됩니다. 다음과 같은 메시지가 표시됩니다.

[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415) [SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)

SQL Server 테이블에서 CDC를 실행할 때 AWS DMS에서 SQL Server tlog를 구문 분석합니다. 각 tlog 레코드에서 AWS DMS는 변경 중에 삽입, 업데이트 또는 삭제된 열에 대한 데이터가 포함된 16진수 값을 구문 분석합니다.

16진수 레코드를 구문 분석하기 위해 AWS DMS는 SQL Server 시스템 테이블에서 테이블 메타데이터를 읽습니다. 이러한 시스템 테이블은 특수 구조화된 테이블 열이 무엇인지 식별하고 “xoffset”및 “null bit position”과 같은 내부 속성 중 일부를 나타냅니다.

AWS DMS는 해당 메타데이터가 테이블의 모든 원시 파티션에 대해 동일할 것으로 예상합니다. 하지만 특수하게 구성된 테이블의 모든 파티션의 경우에는 메타데이터가 동일하지 않을 때도 있습니다. 이러한 경우 AWS DMS는 변경 사항의 구문을 잘못 분석하여 대상에 잘못된 데이터를 제공하는 것을 방지하기 위해 해당 테이블에서 CDC를 일시 중단할 수 있습니다. 해결 방법은 다음과 같습니다.

  • 테이블에 클러스터링된 인덱스가 있는 경우 인덱스를 재구축합니다.

  • 테이블에 클러스터링된 인덱스가 없으면 테이블에 클러스터링된 인덱스를 추가합니다(원하는 경우 나중에 삭제할 수 있음).

Amazon Redshift 관련 문제 해결

아래에서 AWS DMS를 Amazon Redshift 데이터베이스와 함께 사용했을 때 발생하는 문제에 대한 해결 방법을 배울 수 있습니다.

다른 AWS 리전에서 Amazon Redshift 클러스터에 로드

AWS DMS 복제 인스턴스가 아닌 다른 AWS 리전에서 Amazon Redshift 클러스터에 로드할 수 없습니다. DMS를 사용하려면 복제 인스턴스와 Amazon Redshift 클러스터가 동일한 리전에 있어야 합니다.

오류: Relation "awsdms_apply_exceptions" already exists

오류 "Relation ‘awsdms_apply_exceptions’ already exists"는 흔히 Redshift 엔드포인트가 PostgreSQL 엔드포인트로써 지정될 때 발생합니다. 이 문제를 해결하려면, 엔드포인트를 수정하고 [Target engine]을 "redshift"로 변경합니다.

awsdms_changes"로 시작하는 테이블 이름이 있는 오류

'awsdms_changes'로 시작하는 이름과 관련된 테이블 오류 메시지는 데이터를 동일한 Amazon Redshift 클러스터로 로드하려고 하는 태스크 2개를 동시에 실행할 때 발생합니다. 임시 테이블 이름을 지정하는 방식으로 인해 동일한 테이블을 업데이트할 때 동시 작업이 충돌할 수 있습니다.

dms.awsdms_changes000000000XXXX와 같은 이름과 함께 클러스터에 테이블 표시

Amazon S3에 저장된 파일에서 데이터가 로드되면 AWS DMS가 임시 테이블을 생성합니다. 이 임시 테이블의 이름에는 접두사 dms.awsdms_changes가 있습니다. 처음 로드될 때와 최종 대상 테이블에 배치되기 전에 AWS DMS가 데이터를 복원할 수 있도록 이 테이블이 필요합니다.

Amazon Redshift 사용에 필요한 권한

Amazon Redshift와 함께 AWS DMS를 사용하려면 Amazon Redshift에 액세스하기 위해 사용하는 사용자 계정에 다음 권한이 있어야 합니다.

  • CRUD(선택, 삽입, 업데이트, 삭제)

  • 대량 로드

  • 생성, 변경, 삭제(필요한 경우 태스크의 정의에 따라)

대상으로서 Amazon Redshift를 사용할 때 필요한 모든 사전 요구 사항을 보려면, AWS Database Migration Service의 대상으로 Amazon Redshift 데이터베이스 사용 섹션을 참조하세요.

Amazon Aurora MySQL 관련 문제 해결

아래에서 AWS DMS를 Amazon Aurora MySQL 데이터베이스와 함께 사용했을 때 발생하는 문제에 대한 해결 방법을 배울 수 있습니다.

오류: CHARACTER SET UTF8 fields terminated by ',' enclosed by '"' lines terminated by '\n'

Amazon Aurora MySQL을 대상으로 사용 중인 경우, 로그에 다음과 같은 오류가 표시될 수 있습니다. 이러한 유형의 오류는 일반적으로 ANSI_QUOTES가 SQL_MODE 파라미터의 일부로 포함되어 있음을 나타냅니다. SQL_MODE 파라미터의 일부로서 ANSI_QUOTES가 포함되어 있으면 큰따옴표가 일반 따옴표로 처리되어 태스크를 실행할 때 문제가 발생할 수 있습니다.

이 오류를 수정하려면, SQL_MODE 파라미터에서 ANSI_QUOTES를 제거합니다.

2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile "/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table `VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`, `FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`, `RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`, `CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561)

SAP ASE 관련 문제 해결

아래에서 AWS DMS를 SAP ASE 데이터베이스와 함께 사용했을 때 발생하는 문제에 대한 해결 방법을 배울 수 있습니다.

오류: LOB columns have NULL values when source has a composite unique index with NULL values

NULL 값을 허용하는 복합 고유 인덱스로 구성된 테이블이 있는 소스로서 SAP ASE를 사용할 경우, 복제가 진행되는 동안 LOB 값이 마이그레이션되지 않을 수 있습니다. 일반적으로 이러한 동작은 DMS 복제 인스턴스 클라이언트에서 ANSI_NULL의 기본값이 1로 설정되었을 때 발생합니다.

LOB 필드를 올바르게 마이그레이션하려면 엔드포인트 설정 'AnsiNull=0'을 AWS DMS 소스 엔드포인트에 포함합니다.

IBM Db2 관련 문제 해결

아래에서 AWS DMS를 IBM Db2 데이터베이스와 함께 사용했을 때 발생하는 문제에 대한 해결 방법을 배울 수 있습니다.

오류: Resume from timestamp is not supported Task

지속적 복제(CDC)의 경우, 특정 타임스탬프에서 복제를 시작하려면 StartFromContext 연결 속성을 필수 타임스탬프로 설정해야 합니다. 자세한 내용은 Db2 LUW 사용 시 엔드포인트 설정을 참조하세요. StartFromContext를 필수 타임스탬프로 설정하면 아래와 같은 문제를 방지할 수 있습니다.

Last Error Resume from timestamp is not supported Task error notification received from subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual change was captured by this Replicate task earlier to the specified timestamp.