대량 데이터 로드 문제 해결하기¶
이 항목에서는 대량 데이터 로드 문제를 해결하기 위한 체계적인 접근 방식을 설명합니다.
이 항목의 내용:
데이터 로드 실패¶
1단계: 테이블의 COPY 기록 보기¶
테이블에 대한 로드 활동 내역을 쿼리합니다. 자세한 내용은 COPY_HISTORY 섹션을 참조하십시오. STATUS
열은 특정 파일 세트의 로드 완료, 부분 로드 또는 로드 실패 여부를 보여줍니다. FIRST_ERROR_MESSAGE
열은 부분 로드 또는 로드 실패 시의 이유를 보여줍니다.
파일 세트에서 여러 문제가 발생한 경우 FIRST_ERROR_MESSAGE
열은 발생한 첫 번째 오류만 보여줍니다. 파일의 모든 오류를 살펴보기 위한 지침은 2단계. 데이터 로드 유효성 검사 를 참조하십시오.
2단계: 데이터 로드 유효성 검사¶
VALIDATION_MODE 복사 옵션은 COPY 문에 로드할 데이터의 유효성을 검사하고 지정된 유효성 검사 옵션에 따라 결과를 반환하도록 지시합니다. 이 복사 옵션이 지정되면 데이터가 로드되지 않습니다. 복사 옵션에 대한 자세한 내용은 COPY INTO <테이블> 을 참조하십시오.
VALIDATION_MODE 복사 옵션을 RETURN_ALL_ERRORS
로 설정하여 COPY 문을 실행합니다. 명령문에서 로드를 시도한 파일 세트를 참조합니다.
다음 예에서는 오류가 포함된 파일 세트의 유효성을 검사합니다. 오류 분석을 편리하게 수행할 수 있도록 COPY INTO <위치> 문은 오류가 발생한 레코드를 텍스트 파일로 언로드하여 원본 데이터 파일에서 분석 및 수정할 수 있는 기능을 제공합니다. 이 문은 RESULT_SCAN 테이블 함수를 쿼리하여 레코드를 검색합니다. LAST_QUERY_ID 함수를 사용하여 해당 레코드를 검색하려면 이 섹션의 명령을 연속으로 실행해야 합니다.
COPY INTO mytable
FROM @mystage/myfile.csv.gz
VALIDATION_MODE=RETURN_ALL_ERRORS;
SET qid=last_query_id();
COPY INTO @mystage/errors/load_errors.txt FROM (SELECT rejected_record FROM TABLE(result_scan($qid)));
기타 문제¶
오류: {1}
스테이지와 연결된 {0}
통합을 찾을 수 없습니다.¶
003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.
이 오류는 외부 스테이지와 스테이지에 연결된 저장소 통합 간의 연결이 끊어진 경우 발생할 수 있습니다. 이 오류는 저장소 통합 오브젝트가 다시 생성(CREATE OR REPLACE STORAGE INTEGRATION 사용)되었을 때 발생합니다. 스테이지는 저장소 통합 이름 대신 숨겨진 ID를 사용하여 저장소 통합에 연결됩니다. CREATE OR REPLACE 구문이 오브젝트를 삭제하고 다른 숨겨진 ID로 저장소 통합을 다시 만드는 작업이 백그라운드로 수행됩니다.
저장소 통합을 하나 이상의 스테이지에 연결한 후에 다시 만들어야 하는 경우 ALTER STAGE stage_name
SET STORAGE_INTEGRATION = storage_integration_name
을 실행하여 각 스테이지와 저장소 통합 사이의 연결을 다시 설정해야 합니다.
여기서
stage_name
은 스테이지의 이름입니다.storage_integration_name
은 저장소 통합의 이름입니다.
COPY_HISTORY 뷰에서 LOAD_TIME 값 이전에 CURRENT_TIMESTAMP를 사용하여 삽입된 로드 시간¶
테이블 디자이너는 레코드가 테이블에 로드될 때 현재 타임스탬프를 기본값으로 삽입하는 타임스탬프 열을 추가할 수 있습니다. 목적은 테이블에 각 레코드가 로드되는 시간을 캡처하는 것이지만, 타임스탬프가 COPY_HISTORY 함수 (Information Schema) 또는 COPY_HISTORY 뷰 (Account Usage)에서 반환된 LOAD_TIME 열의 값보다 이전입니다. 그 이유는 레코드가 테이블에 삽입될 때(즉, 로드 작업에 대한 트랜잭션이 커밋될 때)가 아닌 클라우드 서비스에서 로드 작업이 컴파일될 때 CURRENT_TIMESTAMP 가 평가되기 때문입니다.
대신 레코드 로딩을 더 정확히 표시해주는 METADATA$START_SCAN_TIME 을 포함하고 쿼리하는 것이 좋습니다.