임포트 세트 성능 문제 해결

이러한 성능 문제를 검토하여 임포트 세트 작업의 문제를 해결하고 성능을 개선합니다.

변환 중 비즈니스 규칙 실행

변환 중에 비즈니스 규칙을 실행하면 변환이 예상보다 오래 걸리거나 인스턴스가 느려질 수 있습니다.

문제가 됨: 매우 많은 양의 데이터를 임포트하는 경우 예를 들어, 이전 시스템에서 모든 데이터를 임포트합니다.

증상: 변환이 예상보다 훨씬 오래 걸립니다. 또한 이 시간 동안 전체 인스턴스가 느려질 수 있습니다.

이를 방지하는 방법: 모든 삽입 및 업데이트 비즈니스 규칙, 알림 및 워크플로우를 실행하려는 경우가 아니면 변환 중에 비즈니스 규칙, 워크플로우, 승인 엔진 등의 항목을 실행하지 마십시오. 예를 들어, 이전 시스템에서 모든 데이터를 임포트할 때 알림을 실행하지 않으려는 경우가 있습니다. 이러한 항목이 실행되지 않도록 설정하고 해당 임포트에 대한 변환 맵 내에서 감사 및 필드 정규화를 중지하려면 비즈니스 규칙 실행 확인란의 선택을 취소합니다.
그림 1. 변환 맵 확인란
주:
비즈니스 규칙처럼 각 기록에 대해 실행하는 것이 아니라 임포트 끝에 계산과 같은 비즈니스 논리를 실행하려면 onComplete 변환 스크립트를 사용하는 것이 좋습니다.

느린 변환 스크립트

여러 GlideRecord 쿼리 또는 큰 루프를 사용하면 변환 스크립트의 속도가 느려질 수 있습니다.

문제가 됨: 변환 스크립트가 여러 GlideRecord 쿼리를 사용하거나 각 행에 대해 대규모 객체 컬렉션을 반복할 때 이 문제는 변환 스크립트가 효율적이지 않을 때 나타날 수 있습니다. 대부분의 경우 임포트 세트 애플리케이션의 내장 기능을 사용하여 스크립트 목표를 달성할 수 있습니다. 예를 들어, GlideRecord 쿼리를 사용하는 스크립트를 작성하는 대신 대소문자 구분 병합 을 스크립팅할 수 있습니다. GlideRecord 쿼리를 수행하면 일반적으로 임포트 속도가 느려집니다.

증상: 변환이 예상보다 훨씬 오래 걸립니다. 스크립트에 따라 이 시간 동안 전체 인스턴스가 느려질 수 있습니다.

이를 방지하는 방법: 가능하면 사용자 지정 스크립트를 작성하는 대신 기본 시스템 기능을 사용하고, 스크립트를 작성하는 경우 GlideRecord 쿼리를 사용하는 복잡한 스크립트를 작성하지 마십시오.

변경되지 않은 데이터 임포트

변경되지 않은 데이터를 반복적으로 임포트하면 건너뛴 행이 많아집니다.

문제가 됨: 매우 큰 테이블에서 데이터를 임포트하고 대부분의 기록이 정기적으로 업데이트되지 않는 경우

증상: 임포트 세트가 예상보다 오래 걸립니다. 아래 시스템 임포트 세트 > 진행률개수 가 매우 많고 건너뛴 개수 도 매우 높은 임포트를 볼 수 있습니다. 이는 메시지 열 아래에 있습니다. 임포트한 대부분의 기록이 실제로 변경되지 않았음을 나타냅니다. 이러한 기록은 임포트할 필요가 없었습니다.

이를 방지하는 방법: JDBC 임포트를 실행 중인 경우 임포트 세트 데이터 소스에서 마지막 실행 날짜/시간 옵션을 사용합니다. 파일 임포트 유형의 경우 파일을 생성하는 모든 것이 새로운 데이터나 변경된 데이터만 추가하도록 설정되어 있는지 확인하십시오.

인덱싱되지 않은 필드에서 병합

많은 양의 데이터가 있는 인덱싱되지 않은 필드에서 병합하면 변환 속도가 느려질 수 있습니다.

문제가 됨: 인덱싱되지 않은 필드에서 일치할 때 임포트의 변환 단계가 느리게 실행됩니다. 그러나 충분한 양의 데이터가 있는 경우에만 문제가 됩니다. 극단적인 경우 이로 인해 추가 로드로 인해 데이터베이스에 성능 문제가 발생합니다.

증상: 임포트의 변환 단계에서 소요되는 시간은 데이터를 로드하는 데 걸리는 시간에 비해 큽니다. 변환 시간이 길어질 것으로 예상됩니다.

이를 방지하는 방법: 가능하면 고유하고 이미 인덱싱된 필드를 병합해야 합니다. 필드가 이미 인덱싱되었는지 확인하려면 다음으로 이동하십시오. 시스템 정의 > 테이블 및 열 테이블을 찾습니다. 해당 테이블의 열 목록에서 인덱싱된 열에는 파란색 아이콘이 있으며 인덱싱된 경우 그 옆에 i가 표시됩니다. 필드 인덱싱에 대한 도움이 필요하면 기술 지원에 문의하십시오 ServiceNow .

임포트 동시 실행

가져오기를 동시에 실행하면 데이터베이스에 과도한 부하가 발생할 수 있습니다.

문제가 됨: 많은 양의 데이터를 임포트하면 데이터베이스에 추가 부하가 발생합니다. 예를 들어, 500,000명의 사용자를 임포트하고 200,000개의 구성 항목을 동시에 임포트할 수 있습니다. 이는 데이터베이스의 부하 증가로 인해 시스템의 모든 쿼리에 상당한 성능 영향을 미칠 수 있습니다. 이 문제는 두 개의 가져오기가 동일한 테이블로 가져올 때 특히 심각합니다. 이러한 경우 테이블에 경합 문제가 발생할 수 있습니다. 또한 처리에 관여하는 테이블에 따라 임포트 및 인스턴스의 성능이 크게 저하될 수 있습니다.

증상: 여러 동시 임포트가 느리게 실행되어 데이터베이스 부하가 결합되었습니다. 많은 수의 삽입과 업데이트가 함께 표시됩니다. 충분한 부하 또는 경합이 있는 경우 IO 대기 시간이 길어집니다.

이를 방지하는 방법: 임포트가 겹치지 않도록 시차를 둡니다.

대형 임포트 세트 테이블

임포트 세트 테이블을 정리하지 않으면 해당 테이블이 복잡해지고 느려질 수 있습니다.

임포트 세트 삭제자 작업이 실행되고 있지 않을 때 문제가 됩니다.

증상: 이것은 크기 문제입니다. 임포트 세트를 정기적으로 정리하지 않으면(7일 분량의 데이터를 정리한 후 정리하는 것이 좋음) 테이블이 채워져 임포트가 중지됩니다.

이를 방지하는 방법: 임포트 세트 삭제자 작업이 실행 중인지 확인합니다. 현재 실행 중이 아닌 경우 이 작업을 활성화하기 전에 모든 임포트 세트 테이블이 잘리므로 문의하십시오 고객 서비스 및 지원 .

임포트 중 테이블 스키마 변경 중

새 열 임포트와 같이 테이블 스키마를 변경하면 임포트 세트 테이블이 잠깁니다.

문제가 됨: 새 컬럼이 임포트될 때마다 해당 스키마 변경 중에 전체 임포트 세트 테이블이 잠기고 테이블 크기에 따라 5분에서 10분 정도 걸릴 수 있습니다. 이 시간 동안에는 데이터를 선택하거나 삽입할 수 없습니다. 해당 테이블을 자주 사용하지 않으면 문제가 발생하지 않을 수 있습니다. 그러나 LDAP 임포트 테이블과 같이 해당 테이블을 자주 사용하는 경우 문제가 발생할 수 있습니다.

증상: 이 문제의 증상은 다양할 수 있습니다. LDAP 임포트 테이블의 예에서 LDAP 임포트 테이블의 쿼리가 필요한 모든 트랜잭션은 스키마 변경이 완료될 때까지 기다려야 합니다.

이를 방지하는 방법: 새 열로 임포트하기 전에 임포트 테이블을 자릅니다.

매우 큰 데이터 세트 임포트

매우 큰 데이터 세트를 임포트하는 것은 여러 개의 작은 데이터 세트를 임포트하는 것보다 더 오래 걸립니다.

문제가 됨: 매우 큰 데이터 세트가 단일 작업으로 임포트되는 경우.

증상: 가져오기 작업을 완료하는 데 시간이 오래 걸립니다.

이를 방지하는 방법: 더 빠른 결과를 위해 매우 큰 데이터 집합을 여러 개의 작은 작업으로 나눕니다. 기록이 100,000개 미만인 임포트 세트를 가이드라인으로 고려하십시오. 예를 들어, 임포트된 총 데이터가 동일하더라도 100,000개 기록의 세트 10개를 임포트하는 것이 100만 개의 기록을 임포트하는 것보다 더 빨리 완료됩니다.

많은 참조 필드가 있는 대규모 데이터 임포트

해결해야 할 참조가 많은 많은 양의 데이터를 가져오면 예상보다 오래 걸리거나 데이터베이스 속도가 느려질 수 있습니다.

문제가 됨: 많은 참조 필드가 있는 대용량 데이터 임포트에 변환 맵을 사용하는 경우.

증상: 변환이 예상보다 훨씬 오래 걸립니다. 가져오는 동안 전체 데이터베이스 속도가 느려집니다.

이를 방지하는 방법: 보조 스토리지를 사용하여 참조를 조회합니다. 보조 스토리지는 참조 확인을 위해 보조 데이터베이스를 사용합니다. 일부 읽기 쿼리를 보조 데이터베이스로 리디렉션하여 기본 데이터베이스의 부하를 줄일 수 있습니다.

보조 스토리지를 활성화하려면 다음을 수행합니다.
  • 보조 데이터베이스 풀 [com.glide.secondary_db_pools] 플러그인을 활성화합니다. 자세한 내용은 Request a plugin 문서를 참조하십시오.
  • 보조 데이터베이스 범주 [sys_db_category] 테이블의 import_reference_resoultion 범주가 구성되고 사용 설정되었는지 확인합니다. 플러그인을 요청하면 ServiceNow 지원 팀에서 이 범주를 구성합니다.

플러그인이 활성화되고 보조 저장소 범주가 구성 및 활성화되면 에 대한 변환 맵 생성양식에 참조에 보조 저장소 사용 확인란이 나타납니다. 이 확인란을 사용하여 보조 스토리지를 사용하거나 사용하지 않도록 설정합니다.

보조 스토리지를 사용하는 경우 필드 맵의 선택 작업 필드를 무시 또는 거부로 설정합니다. 선택 작업을생성으로 설정하면 참조 해상도가 새로 생성된 기록을 즉시 감지하지 못하기 때문에 기록의 여러 사본이 생성될 수 있습니다. 선택 작업에 대한 자세한 내용은 다음 문서를 참조하십시오 필드 맵 생성.

보조 데이터베이스는 항상 주 데이터베이스에 비해 약간 오래된 상태입니다. 가져오기에 완전히 최신 데이터가 필요한 경우 보조 스토리지를 사용하지 마세요.