쿼리 문제 해결
이 섹션은 Amazon Redshift 쿼리를 실행할 때 발생할 수 있는 가장 공통적이고 심각한 문제 몇 가지를 식별하여 해결할 수 있는 빠른 참조를 제공합니다.
다음은 처음에 문제를 해결할 때 시도할 수 있는 권장 방법입니다. 자세한 내용은 다음 리소스를 참조할 수도 있습니다.
연결 실패
다음과 같은 이유로 쿼리 연결이 중단되는 경우 아래와 같은 문제 해결 방법을 권장합니다.
클라이언트가 서버에 연결할 수 없음
SSL 또는 서버 인증서를 사용할 때는 먼저 연결 문제를 해결하면서 이러한 복잡성을 제거했다가 그런 다음 해결책을 발견하였을 때 SSL 또는 서버 인증서를 다시 추가합니다. 자세한 내용은 Amazon Redshift 관리 가이드의 연결에 대한 보안 옵션 구성 섹션을 참조하세요.
연결 거부
일반적으로 연결 구성에 실패했다는 오류 메시지가 수신되면 클러스터에 대한 액세스 권한과 관련된 문제를 의미합니다. 자세한 내용은 Amazon Redshift 관리 가이드의 연결이 거부되거나 실패함 섹션을 참조하세요.
쿼리 중단
쿼리는 다음과 같은 이유로 중단, 즉 응답을 멈출 수 있습니다. 이때는 아래와 같은 문제 해결 방법을 권장합니다.
데이터베이스 연결 해제
최대 전송 단위(MTU)의 크기를 줄이세요. 단일 이더넷 프레임으로 네트워크 연결을 통해 전송할 수 있는 패킷의 최대 크기(바이트)는 MTU의 크기에 따라 결정됩니다. 자세한 내용은 Amazon Redshift 관리 가이드의 데이터베이스 연결이 끊어짐 섹션을 참조하세요.
데이터베이스 연결 시간 초과
COPY 명령 같은 긴 쿼리를 실행할 때는 데이터베이스에 대한 클라이언트 연결이 멈추거나 제한 시간에 걸릴 수 있습니다. 이런 경우 Amazon Redshift 콘솔에서 쿼리의 완료 여부를 관찰할 수 있지만 클라이언트 도구에는 쿼리가 여전히 실행 중인 것으로 표시됩니다. 쿼리 결과는 연결 중단 시점에 따라 누락되거나 불완전할 수도 있습니다. 이러한 문제는 중간 네트워크 구성 요소에서 유휴 상태의 연결을 종료할 때 발생합니다. 자세한 내용은 Amazon Redshift 관리 가이드의 방화벽 시간 제한 문제 섹션을 참조하세요.
ODBC에 클라이언트 측 메모리 부족 오류 발생
클라이언트 애플리케이션이 ODBC 연결을 사용하고 쿼리가 메모리에 비해 너무 큰 결과 집합을 생성하는 경우, 커서를 사용하여 결과 집합을 클라이언트 애플리케이션으로 스트리밍할 수 있습니다. 자세한 내용은 DECLARE 및 커서 사용 시 성능 고려사항 섹션을 참조하세요.
JDBC에 클라이언트 측 메모리 부족 오류 발생
JDBC 연결을 통해 대용량의 결과 집합을 가져오려고 하면 클라이언트 측 메모리 부족 오류가 발생할 수 있습니다. 자세한 내용은 JDBC Fetch Size 파라미터 설정 섹션을 참조하세요.
잠재적 교착 발생
잠재적 교착 상황이 발생하면 다음과 같이 시도하세요.
-
STV_LOCKS 및 STL_TR_CONFLICT 시스템 테이블을 살펴보면서 테이블을 1개 이상 업데이트하는 데 따른 충돌 유무를 확인하세요.
-
PG_CANCEL_BACKEND 함수를 사용하여 충돌하는 쿼리를 1개 이상 취소하세요.
-
PG_TERMINATE_BACKEND 함수를 사용하여 세션을 종료하세요. 그러면 종료된 세션에서 실행 중이던 트랜잭션이 모든 잠금을 강제로 해제하여 트랜잭션을 롤백시킵니다.
-
주의하여 동시 쓰기 작업을 예약하세요. 자세한 내용은 동시 쓰기 작업 관리 섹션을 참조하세요.
쿼리가 너무 오래 걸림
다음과 같은 이유로 쿼리가 장기화되는 경우 아래와 같은 문제 해결 방법을 권장합니다.
테이블이 최적화되지 않음
테이블의 정렬 키, 분산 스타일 및 압축 인코딩을 설정하여 병렬 처리를 최대한 이용하세요. 자세한 내용은 자동 테이블 최적화 작업 섹션을 참조하세요.
쿼리가 디스크에 쓰고 있음
쿼리는 쿼리 실행 중 일부분이라도 디스크에 작성할 수 있습니다. 자세한 내용은 쿼리 성능 개선 섹션을 참조하세요.
다른 쿼리가 끝날 때까지 쿼리가 대기해야 함
이때는 쿼리 대기열을 생성한 후 유형에 따라 쿼리를 적합한 대기열에 할당하면 전반적인 시스템 성능을 개선할 수 있습니다. 자세한 내용은 워크로드 관리 구현 섹션을 참조하세요.
쿼리가 최적화되지 않음
실행 계획을 분석하여 쿼리를 재작성하거나 데이터베이스를 최적화하세요. 자세한 내용은 쿼리 계획 섹션을 참조하세요.
쿼리 실행에 더 많은 메모리 필요
특정 쿼리에 더 많은 메모리가 필요한 경우에는 wlm_query_slot_count 파라미터 값을 높여서 사용 가능한 메모리를 늘릴 수 있습니다.
데이터베이스에서 VACUUM 명령 실행 필요
정렬 키 순서에 따라 데이터를 로드하지 않는 경우에는 다수의 행을 추가, 삭제 또는 수정할 때마다 VACUUM 명령을 실행하세요. VACUUM 명령은 데이터를 재구성하여 정렬 순서를 유지하는 동시에 성능을 복원합니다. 자세한 내용은 테이블 Vacuum 단원을 참조하십시오.
장기 실행 쿼리 문제 해결을 위한 추가 리소스
다음은 쿼리 튜닝에 도움이 되는 시스템 뷰 주제 및 기타 설명서 섹션입니다.
STV_INFLIGHT 시스템 뷰는 클러스터에서 실행 중인 쿼리를 보여줍니다. 현재 실행 중이거나 최근에 완료된 쿼리를 확인하려면 STV_RECENTS와 함께 사용하면 유용할 수 있습니다.
SYS_QUERY_HISTORY는 문제 해결에 유용합니다.
running또는failed와 같은 현재 상태, 각 쿼리가 실행되는 데 걸린 시간, 쿼리가 동시성 확장 클러스터에서 실행되었는지 여부와 같은 관련 속성과 함께 DDL 및 DML 쿼리를 표시합니다.STL_QUERYTEXT는 SQL 명령의 쿼리 텍스트를 수집합니다. 또한 STL_QUERYTEXT를 STV_INFLIGHT에 결합하는 SVV_QUERY_INFLIGHT는 더 많은 쿼리 메타데이터를 표시합니다.
트랜잭션 잠금 충돌은 쿼리 성능 문제의 원인이 될 수 있습니다. 현재 테이블에 잠금을 유지하고 있는 트랜잭션에 대한 자세한 내용은 SVV_TRANSACTIONS를 참조하세요.
조정에 가장 적합한 쿼리를 식별하면 최근에 실행한 쿼리 중 가장 많은 시간이 소요된 쿼리를 파악하는 데 도움이 되는 문제 해결 쿼리를 제공합니다. 이를 통해 개선이 필요한 쿼리에 노력을 집중할 수 있습니다.
쿼리 관리를 더 자세히 살펴보고 쿼리 대기열을 관리하는 방법을 이해하려면 워크로드 관리 구현에서 그 방법을 확인하세요. 워크로드 관리는 고급 기능이며 대부분의 경우 자동화된 워크로드 관리를 권장합니다.
로드 실패
다음과 같은 이유로 데이터 로드가 중단되는 경우 아래와 같은 문제 해결 방법을 권장합니다.
데이터 원본이 다른 AWS 리전에 있습니다
기본적으로 COPY 명령에서 지정하는 Amazon S3 버킷 또는 Amazon DynamoDB 테이블은 클러스터와 동일한 AWS 리전에 있어야 합니다. 데이터와 클러스터가 서로 다른 리전에 있는 경우에는 다음과 유사한 오류 메시지가 표시됩니다.
The bucket you are attempting to access must be addressed using the specified endpoint.
가능하면 클러스터와 데이터 원본이 동일한 리전에 있어야 합니다. 그렇게 해도 COPY 명령에서 REGION 옵션을 사용하여 다른 리전을 지정할 수 있습니다.
참고
클러스터와 데이터 원본이 서로 다른 AWS 리전에 있는 경우 데이터 전송 비용이 발생합니다. 또한 지연 시간이 더 깁니다.
COPY 명령 실패
STL_LOAD_ERRORS에 대한 쿼리를 실행하여 특정 로드 도중 발생한 오류를 식별합니다. 자세한 내용은 STL_LOAD_ERRORS 섹션을 참조하세요.
로드가 너무 오래 걸림
다음과 같은 이유로 로드 작업이 장기화되는 경우 아래와 같은 문제 해결 방법을 권장합니다.
COPY가 단일 파일에서 데이터를 로드함
로드 데이터를 여러 파일로 분할합니다. 하나의 큰 파일에서 모든 데이터를 로드하면 Amazon Redshift는 훨씬 느린 직렬화된 로드를 수행해야 합니다. 이때 파일 수는 클러스터 조각 수의 배수가 되어야 하며, 파일 크기는 압축 이후 1MB~1GB에서 대략적으로 동일해야 합니다. 자세한 내용은 Amazon Redshift 쿼리 설계 모범 사례 섹션을 참조하세요.
로드 작업에서 여러 개의 COPY 명령 사용
동시에 다수의 COPY 명령을 사용하여 여러 파일에서 테이블 하나를 로드하면 Amazon Redshift가 강제로 직렬화 로딩을 실행하여 속도가 느려집니다. 이때는 COPY 명령을 하나만 사용하세요.
로드 데이터가 잘못됨
COPY 작업이 다음과 같은 방식으로 잘못된 데이터를 로드할 수도 있습니다. 이때는 아래와 같은 문제 해결 방법을 권장합니다.
잘못된 파일이 로드됨
객체 접두사를 사용하여 데이터 파일을 지정하면 원하지 않는 파일을 읽어올 수 있습니다. 이때는 매니페스트 파일을 사용하여 로드할 파일을 정확히 지정하세요. 자세한 내용은 COPY 명령의 copy_from_s3_manifest_file 옵션과 COPY 예의 Example: COPY from Amazon S3 using a manifest 섹션을 참조하세요.
JDBC Fetch Size 파라미터 설정
기본적으로 JDBC 드라이버는 모든 쿼리 결과를 한 번에 수집합니다. 그 결과, JDBC 연결을 통해 대용량의 결과 집합을 가져오려고 하면 클라이언트 측 메모리 부족 오류가 발생할 수 있습니다. 단 한 번에 모두 가져오거나 아무것도 가져오지 않는 방식이 아닌 배치(batch) 방식으로 결과 집합을 가져오려면 클라이언트 애플리케이션에서 JDBC Fetch Size 파라미터를 설정하세요.
참고
ODBC는 Fetch Size 파라미터가 지원되지 않습니다.
성능을 최적화하려면 메모리 부족 오류가 일어나지 않는 범위 내에서 페치 크기 값을 가장 높게 설정하세요. 페치 크기 값이 더 낮아지면 서버 전송이 늘어나서 실행 시간이 장기화될 수 있습니다. 서버는 클라이언트가 전체 결과 집합을 가져오거나 쿼리가 취소될 때까지 WLM 쿼리 슬롯이나 연결 메모리를 비롯한 리소스를 예약합니다. 이때 Fetch Size 값을 적절히 조정하면 이러한 리소스가 더욱 빠르게 해제되어 다른 쿼리에서도 사용할 수 있게 됩니다.
참고
대용량 데이터 집합을 추출해야 하는 경우에는 UNLOAD 문을 사용하여 데이터를 Amazon S3로 전송하는 것이 좋습니다. UNLOAD를 사용하면 컴퓨팅 노드가 병렬로 실행되어 데이터 전송 속도가 빨라집니다.
JDBC Fetch Size 파라미터 설정에 대한 자세한 내용은 PostgreSQL 설명서의 Getting results based on a cursor
