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

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

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

이를 방지하는 방법: 모든 삽입 및 업데이트 비즈니스 규칙, 알림 및 워크플로우가 실행되도록 하지 않는 한 변환 중에 비즈니스 규칙, 워크플로우, 승인 엔진 등과 같은 항목을 실행하지 마십시오. 예를 들어, 이전 시스템에서 모든 데이터를 임포트할 때 알림이 실행되지 않도록 할 수 있습니다. 이러한 항목이 실행되지 않도록 설정하고 해당 임포트의 변환 맵 내에서 감사 및 필드 정규화를 중단하려면 비즈니스 규칙 실행 확인란의 선택을 취소합니다.

주:

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만 개의 기록을 한 번 임포트하는 것보다 빠르게 완료됩니다.

해결할 참조가 많은 대량의 데이터를 임포트하면 예상보다 시간이 오래 걸리거나 데이터베이스 속도가 느려질 수 있습니다.

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

증상: 변환이 예상보다 오래 걸립니다. 임포트하는 동안 전체 데이터베이스의 속도가 느려집니다.

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

플러그인이 활성화되고 보조 스토리지 범주가 구성 및 사용하도록 설정되면 양식변환 맵 생성에 참조에 보조 스토리지 사용 확인란이 표시됩니다. 보조 스토리지를 활성화하거나 비활성화하려면 이 확인란을 사용합니다.

보조 저장소를 사용하는 경우 필드 맵에서 선택 작업 필드를 무시 또는 거부로 설정합니다. 선택 작업을생성으로 설정하면 참조 해결 방법이 새로 생성된 기록을 즉시 탐지하지 않기 때문에 기록의 여러 복사본이 생성될 수 있습니다. 선택 작업에 대한 자세한 내용은 해당 문서를 참조하십시오 필드 맵 생성.

보조 데이터베이스는 항상 기본 데이터베이스에 비해 약간 오래되었습니다. 임포트에 완전한 최신 데이터가 필요한 경우 보조 스토리지를 사용하지 마십시오.