데이터 흐름의 성능 향상
이 항목에서는 일반적인 성능 문제를 방지할 수 있도록 Integration Services 패키지를 디자인하는 방법에 대한 제안 사항을 제공합니다. 또한 이 항목에서는 패키지의 성능 문제를 해결하기 위해 사용할 수 있는 기능 및 도구에 대한 정보를 제공합니다.
데이터 흐름 구성
성능 향상을 위해 데이터 흐름 태스크를 구성하려면 태스크의 속성을 구성하고 버퍼 크기를 조정하며 패키지에 대해 병렬 실행을 구성합니다.
데이터 흐름 태스크의 속성 구성
[!참고]
이 섹션에 설명된 속성은 패키지의 각 데이터 흐름 태스크에 대해 개별적으로 설정해야 합니다.
성능에 영향을 주는 다음 데이터 흐름 태스크 속성을 구성할 수 있습니다.
버퍼 데이터의 임시 저장소 위치(BufferTempStoragePath 속성)와 BLOB(Binary Large Object) 데이터가 들어 있는 열의 임시 저장소 위치(BLOBTempStoragePath 속성)를 지정합니다. 기본적으로 이러한 속성에는 TEMP 및 TMP 환경 변수의 값이 포함됩니다. 다른 폴더를 지정하여 임시 파일을 다른 하드 디스크 드라이브 또는 보다 빠른 하드 디스크 드라이브에 넣거나 해당 파일을 여러 드라이브로 분산할 수 있습니다. 디렉터리 이름을 세미콜론으로 구분하여 여러 디렉터리를 지정할 수 있습니다.
DefaultBufferSize 속성을 설정하여 태스크에서 사용되는 버퍼의 기본 크기를 정의하고, DefaultBufferMaxRows 속성을 설정하여 각 버퍼의 최대 행 개수를 정의합니다. 기본 버퍼 크기는 10MB이고 최대 버퍼 크기는 100MB입니다. 기본 최대 행 개수는 10,000개입니다.
EngineThreads 속성을 설정하여 실행 중에 태스크에서 사용할 수 있는 스레드 수를 설정합니다. 이 속성은 데이터 흐름 엔진에 사용할 스레드 수에 대한 제안 사항을 제공합니다. 기본값은 5이고 최소값은 3입니다. 그러나 데이터 흐름 엔진은 이 속성 값에 관계없이 필요한 만큼의 스레드만 사용합니다. 동시성 문제를 방지하기 위해 필요한 경우에는 엔진에서 이 속성에 지정된 것보다 많은 수의 스레드를 사용할 수도 있습니다.
데이터 흐름 태스크가 최적 모드에서 실행되는지 여부(RunInOptimizedMode 속성)를 나타냅니다. 최적화된 모드는 데이터 흐름에서 사용되지 않은 열, 출력 및 구성 요소를 제거함으로써 성능을 향상시킵니다.
[!참고]
같은 이름의 속성인 RunInOptimizedMode를 Business Intelligence Development Studio의 프로젝트 수준에서 설정하여 데이터 흐름 태스크가 디버깅 중에 최적화된 모드에서 실행되도록 나타낼 수 있습니다. 이 프로젝트 속성은 디자인 타임에 데이터 흐름 태스크의 RunInOptimizedMode 속성보다 우선합니다.
버퍼 크기 조정
데이터 흐름 엔진은 단일 데이터 행의 예상 크기를 계산하여 버퍼 크기 조정 태스크를 시작합니다. 그런 다음 예상 행 크기를 DefaultBufferMaxRows 값으로 곱하여 버퍼 크기의 예비 작업 값을 구합니다.
결과가 DefaultBufferSize 값보다 크면 엔진은 행 개수를 줄입니다.
결과가 내부적으로 계산된 최소 버퍼 크기보다 작으면 엔진은 행 개수를 늘립니다.
결과가 최소 버퍼 크기와 DefaultBufferSize 값 사이에 있으면 엔진은 예상 행 크기에 DefaultBufferMaxRows 값을 곱한 값에 가능한 한 근접하게 버퍼 크기를 조정합니다.
데이터 흐름 태스크의 성능 테스트를 시작할 때는 DefaultBufferSize 및 DefaultBufferMaxRows의 기본값을 사용합니다. 데이터 흐름 태스크에 대한 로깅을 설정하고 BufferSizeTuning 이벤트를 선택하여 각 버퍼에 포함된 행 개수를 확인합니다.
버퍼의 크기를 조정하기 전에 불필요한 열을 제거하고 데이터 형식을 적절하게 구성하여 각 데이터 행의 크기를 줄이는 방식으로 성능을 향상시켜 보는 것이 좋습니다.
사용 가능한 메모리가 충분하면 많은 수의 작은 버퍼를 사용하는 것보다는 적은 수의 큰 버퍼를 사용하는 것이 좋습니다. 즉, 데이터를 보관하는 데 필요한 총 버퍼 수를 줄이고 가능한 한 많은 데이터 행을 한 버퍼에 넣어서 성능을 향상시킬 수 있습니다. 최적의 버퍼 수와 버퍼 크기를 확인하려면 DefaultBufferSize 및 DefaultBufferMaxRows 값으로 시험하면서 BufferSizeTuning 이벤트에서 보고된 정보와 성능을 모니터링합니다.
디스크에 대한 페이징이 발생하는 수준까지 버퍼 크기를 늘리지 마십시오. 디스크에 대한 페이징은 최적화되지 않은 버퍼 크기 이상으로 성능을 저하시킵니다. 페이징의 발생 여부를 확인하려면 MMC(Microsoft Management Console)의 성능 스냅인에서 "Buffers spooled" 성능 카운터를 모니터링합니다.
패키지에 대해 병렬 실행 구성
병렬 실행은 실제 프로세서나 논리적 프로세서가 여러 개 있는 컴퓨터에서 성능을 향상시킵니다. 패키지에 있는 다른 태스크의 병렬 실행을 지원하기 위해 Integration Services에서는 MaxConcurrentExecutables와 EngineThreads라는 두 개의 속성을 사용합니다.
MaxConcurrentExcecutables 속성
MaxConcurrentExecutables 속성은 패키지 자체의 속성입니다. 이 속성은 동시에 실행할 수 있는 태스크 수를 정의합니다. 기본값인 -1은 논리적 프로세서나 실제 프로세서 수에서 2를 더한 수를 의미합니다.
이 속성이 작동하는 방식을 이해하기 위해 세 개의 데이터 흐름 태스크가 있는 샘플 패키지를 살펴 봅니다. MaxConcurrentExecutables를 3으로 설정하면 세 개의 데이터 흐름 태스크가 모두 동시에 실행될 수 있습니다. 그러나 각 데이터 흐름 태스크에 원본에서 대상으로의 실행 트리가 10개 있다고 가정할 때 MaxConcurrentExecutables를 3으로 설정하면 각 데이터 흐름 태스크 내에서 실행 트리가 병렬로 실행되지 않을 수 있습니다.
EngineThreads 속성
EngineThreads 속성은 각 데이터 흐름 태스크의 속성입니다. 이 속성은 데이터 흐름 엔진에서 만들어 병렬로 실행할 수 있는 스레드 수를 정의합니다. EngineThreads 속성은 데이터 흐름 엔진에서 원본에 대해 만드는 원본 스레드와 해당 엔진에서 변환 및 대상에 대해 만드는 작업자 스레드 모두에 동일하게 적용됩니다. 따라서 EngineThreads를 10으로 설정하면 엔진에서 원본 스레드와 작업자 스레드를 각각 10개까지 만들 수 있습니다.
이 속성이 작동하는 방식을 이해하기 위해 세 개의 데이터 흐름 태스크가 있는 샘플 패키지를 살펴 봅니다. 각 데이터 흐름 태스크에 10개의 원본에서 대상으로의 실행 트리가 포함되어 있을 때 각 데이터 흐름 태스크에서 EngineThreads를 10으로 설정하면 30개의 실행 트리가 모두 동시에 실행될 수 있습니다.
[!참고]
스레딩에 대한 설명은 이 항목의 범위를 벗어납니다. 그러나 사용 가능한 프로세서 수보다 많은 스레드를 병렬로 실행하지 않는 것이 일반적인 규칙입니다. 사용 가능한 프로세서 수보다 많은 스레드를 실행하면 스레드 간 컨텍스트 전환이 빈번하게 발생하므로 성능이 저하될 수 있습니다.
개별 데이터 흐름 구성 요소 구성
성능 향상을 위해 개별 데이터 흐름 구성 요소를 구성하려면 몇 가지 일반적인 지침을 따라야 합니다. 데이터 흐름 구성 요소의 각 유형(원본, 변환 및 대상)과 관련된 지침도 있습니다.
일반적인 지침
데이터 흐름 구성 요소와 상관없이 성능 향상을 위해서는 쿼리를 최적화하고 불필요한 정렬을 사용하지 않는다는 두 가지 일반적인 지침을 따라야 합니다.
쿼리 최적화
많은 데이터 흐름 구성 요소가 원본에서 데이터를 추출할 때나 참조 테이블을 만들기 위해 조회 작업에서 쿼리를 사용합니다. 기본 쿼리는 SELECT * FROM <tableName> 구문을 사용합니다. 이 유형의 쿼리는 원본 테이블의 모든 열을 반환합니다. 디자인 타임에 모든 열을 사용할 수 있도록 만들면 모든 열을 조회, 통과 또는 원본 열로 선택할 수 있습니다. 그러나 사용할 열을 선택한 후에는 선택한 열만 포함되도록 쿼리를 수정해야 합니다. 열 수가 적을수록 더 작은 행이 만들어지므로 여분의 열을 제거하면 패키지의 데이터 흐름이 보다 효율적으로 개선됩니다. 행이 작을수록 하나의 버퍼에 더 많은 행을 넣을 수 있으며 데이터 집합의 모든 행을 보다 적은 작업으로 처리할 수 있습니다.
쿼리를 생성하려면 쿼리를 직접 입력하거나 쿼리 작성기를 사용합니다.
[!참고]
Business Intelligence Development Studio에서 패키지를 실행하면 SSIS 디자이너의 진행률 탭에 경고가 나열됩니다. 이러한 경고에는 원본에서 데이터 흐름에 제공되지만 나중에 다운스트림 데이터 흐름 구성 요소에 사용되지 않는 데이터 열이 식별되어 포함됩니다. RunInOptimizedMode 속성을 사용하여 이러한 열을 자동으로 제거할 수 있습니다.
불필요한 정렬 방지
정렬은 근본적으로 느린 작업이므로 불필요한 정렬을 방지하면 패키지 데이터 흐름의 성능을 향상시킬 수 있습니다.
원본 데이터가 다운스트림 구성 요소에 의해 사용되기 전에 이미 정렬되어 있는 경우가 있습니다. SELECT 쿼리에 ORDER BY 절이 사용되거나 데이터가 원본에 정렬된 순서대로 삽입되면 이러한 사전 정렬이 발생할 수 있습니다. 이렇게 사전 정렬된 원본 데이터의 경우 데이터가 정렬되어 있음을 나타내는 힌트를 제공하여 특정 다운스트림 변환의 정렬 요구 사항을 만족시키기 위해 정렬 변환을 사용하는 것을 방지할 수 있습니다. 예를 들어 병합 및 병합 조인 변환에는 정렬된 입력이 필요합니다. 데이터가 정렬되어 있음을 나타내는 힌트를 제공하려면 다음 태스크를 수행해야 합니다.
업스트림 데이터 흐름 구성 요소의 출력에 있는 IsSorted 속성을 True로 설정합니다.
데이터가 정렬되는 정렬 키 열을 지정합니다.
자세한 내용은 방법: 병합 및 병합 조인 변환을 위한 데이터 정렬을 참조하십시오.
데이터 흐름에서 데이터를 정렬해야 하는 경우 정렬 연산을 가능한 한 적게 사용하도록 데이터 흐름을 디자인하여 성능을 향상시킬 수 있습니다. 예를 들어 데이터 흐름에서 멀티캐스트 변환을 사용하여 데이터 집합을 복사합니다. 변환 후 여러 출력을 정렬하는 대신 멀티캐스트 변환을 실행하기 전에 데이터 집합을 한 번 정렬합니다.
원본
OLE DB 원본
OLE DB 원본을 사용하여 뷰에서 데이터를 검색할 때는 "SQL 명령"을 데이터 액세스 모드로 선택하고 SELECT 문을 입력합니다. SELECT 문을 사용하여 데이터에 액세스하면 "테이블 또는 뷰"를 데이터 액세스 모드로 선택하는 것보다 성능이 향상됩니다.
변환
집계, 유사 항목 조회, 유사 항목 그룹화, 조회, 병합 조인 및 느린 변경 차원 변환의 성능을 향상시키려면 이 섹션의 제안 사항을 사용합니다.
집계 변환
집계 변환에는 Keys, KeysScale, CountDistinctKeys 및 CountDistinctScale 속성이 포함됩니다. 이 속성은 변환이 캐시하는 데이터에 필요한 메모리 양을 미리 할당할 수 있도록 하여 성능을 향상시킵니다. Group by 연산의 결과로 반환될 그룹의 정확한 수 또는 대략적인 수를 아는 경우 각각 Keys 및 KeysScale 속성을 설정합니다. 고유 카운트 연산의 결과로 반환될 고유 값의 정확한 수 또는 대략적인 수를 아는 경우 각각 CountDistinctKeys 및 CountDistinctScale 속성을 설정합니다.
한 데이터 흐름에 여러 집계를 만들어야 하는 경우 여러 변환을 만드는 대신 하나의 집계 변환을 사용하는 여러 집계를 만드십시오. 이 방법을 사용하면 한 집계가 다른 집계의 하위 집합인 경우 성능이 향상됩니다. 이는 변환이 한 번만 들어오는 데이터를 검색하고 내부 저장소를 최적화할 수 있기 때문입니다. 예를 들어 집계에서 GROUP BY 절 및 AVG 집계를 사용하는 경우 이를 하나의 변환으로 조합하면 성능을 향상시킬 수 있습니다. 그러나 하나의 집계 변환 내에서 여러 집계를 수행하면 집계 작업이 직렬화되므로 여러 집계가 독립적으로 계산되어야 하는 경우 성능이 향상되지 않을 수 있습니다.
자세한 내용은 집계 변환을 참조하십시오.
유사 항목 조회 및 유사 항목 그룹화 변환
유사 항목 조회 및 유사 항목 그룹화 변환의 성능 최적화에 대한 자세한 내용은 백서 SQL Server Integration Services 2005에서 유사 항목 조회 및 유사 항목 그룹화(Fuzzy Lookup and Fuzzy Grouping in SQL Server Integration Services 2005)를 참조하십시오.
조회 변환
필요한 열만 조회하는 SELECT 문을 입력하여 메모리에서 참조 데이터의 크기를 최소화합니다. 이 옵션은 불필요한 데이터를 대량 반환하는 전체 테이블 또는 뷰 선택 작업보다 성능을 향상시킵니다.
병합 조인 변환
병합 조인 변환은 각 입력과 동시에 활성화할 수 있는 최대 버퍼 수를 제안하는 MaxBuffersPerInput 속성을 포함합니다. 하지만 MaxBuffersPerInput 속성에 설정한 값은 제안 사항입니다. 병합 조인 변환은 대부분의 경우 항상 이 제안보다 큰 값으로 버퍼 수를 늘려야 합니다. 일반적으로 버퍼 수를 늘려야 하는 경우는 다음과 같습니다.
각 입력의 병합에 충분한 데이터를 가져오기 위해
데이터를 처리하는 스레드 간의 교착 상태로 인한 위험을 방지하기 위해
[!참고]
병합 조인 변환이 사용하는 버퍼 수는 매우 커질 수 있으며 이로 인해 Integration Services에서 컴퓨터의 메모리를 많이 사용할 수 있습니다.
변환에 각 입력의 데이터가 충분히 있는 경우 스레딩 교착 상태의 위험이 없으며 MaxBuffersPerInput 속성에서 제안하는 값을 사용하여 변환이 다시 시작됩니다.
MaxBuffersPerInput 속성의 기본값은 5이며 대부분의 시나리오에서 잘 작동하는 버퍼 수입니다. 성능을 향상시키려면 버퍼 수를 늘이십시오. 메모리 가중을 감소시키려면 버퍼 수를 줄이십시오. 하지만 버퍼 수가 아주 작은 경우 오히려 성능이 저하되며 값을 0으로 지정하면 모든 스로틀이 비활성화되므로 사용해서는 안 됩니다.
느린 변경 차원 변환
느린 변경 차원 마법사 및 느린 변경 차원 변형은 사용자 대부분의 요구를 충족하는 일반적인 용도의 도구입니다. 그러나 마법사에서 생성하는 데이터 흐름은 성능을 위해 최적화되지 않습니다.
일반적으로 느린 변경 차원 변환에서 가장 느린 구성 요소는 한 번에 하나의 행에 대해 UPDATE를 수행하는 OLE DB 명령 변환입니다. 따라서 느린 변경 차원 변환의 성능을 향상시키는 가장 효과적인 방법은 OLE DB 명령 변환을 바꾸는 것입니다. 업데이트할 모든 행을 준비 테이블에 저장하는 대상 구성 요소로 이러한 변환을 바꿀 수 있습니다. 그런 다음 모든 행에 대해 동시에 단일 집합 기반 Transact-SQL UPDATE를 수행하는 SQL 실행 태스크를 추가할 수 있습니다.
고급 사용자는 느린 변경 차원 처리를 위해 대규모 차원에 대해 최적화된 사용자 지정 데이터 흐름을 디자인할 수 있습니다. 이 방법에 대한 설명 및 예는 백서 Project REAL: 비즈니스 인텔리전스 ETL 디자인 방법의 "고유 차원 시나리오" 섹션을 참조하십시오.
대상
대상에서 성능을 향상시키려면 SQL Server 대상을 사용하고 대상의 성능을 테스트하십시오.
SQL Server 대상
패키지가 같은 컴퓨터에 있는 SQL Server 인스턴스에 데이터를 로드하면 SQL Server 대상을 사용합니다. 이 대상은 고속 대량 로드를 위해 최적화되어 있습니다.
대상 성능 테스트
대상에 데이터를 저장하는 데는 예상보다 많은 시간이 소모됩니다. 대상의 낮은 데이터 처리 능력으로 인해 속도 저하가 일어났는지 여부를 식별하려면 임시로 대상을 행 개수 변환으로 대체하십시오. 처리량이 크게 향상되면 데이터를 로드하는 대상에서 속도 저하가 일어난 것입니다.
패키지 성능 모니터링
Integration Services에서는 패키지 성능을 모니터링하는 데 사용할 수 있는 도구 및 기능을 제공합니다. 예를 들어 로깅을 통해 패키지에 대한 런타임 정보를 캡처하고 성능 카운터를 사용하여 데이터 흐름 엔진을 모니터링할 수 있습니다. 성능에 가장 큰 영향을 주는 패키지 부분을 확인하려면 다음 제안 사항을 사용합니다.
진행률 탭의 정보 검토
SSIS 디자이너는 Business Intelligence Development Studio에서 패키지를 실행할 때 제어 흐름과 데이터 흐름 모두에 대한 정보를 제공합니다. 진행률 탭에는 태스크와 컨테이너가 실행 순서대로 나열되며 패키지 자체를 포함하여 각 작업 및 컨테이너에 대한 시작 및 종료 시간, 경고 및 오류 메시지가 표시됩니다. 또한 데이터 흐름 구성 요소가 실행 순서대로 표시되고, 진행률(완료율로 표시)과 처리된 행 개수에 대한 정보가 포함됩니다.
진행률 탭에 메시지를 표시할지 여부는 SSIS 메뉴의 디버그 진행률 보고 옵션을 선택 또는 선택 취소하여 설정합니다. 진행률 보고를 사용하지 않으면 BI Development Studio에서 복잡한 패키지를 실행하는 동안 성능을 높일 수 있습니다.
패키지의 로깅 구성
Integration Services에서는 패키지가 런타임 정보를 여러 형식의 파일 또는 SQL Server에 기록할 수 있도록 해주는 다양한 로그 공급자를 제공합니다. 태스크 및 컨테이너와 같은 개별 패키지 개체 및 패키지 자체에 대한 로그 항목을 활성화할 수 있습니다. Integration Services에서는 광범위한 작업 및 컨테이너를 포함하며 각 작업 및 컨테이너가 자체 설명 로그 항목 집합을 가집니다. 예를 들어 SQL 실행 태스크를 포함하는 패키지는 태스크가 실행되는 SQL 문과 문의 매개 변수 값을 나열하는 로그 항목을 작성합니다.
로그 항목이 제공하는 패키지 및 패키지 개체의 시작 시각 및 종료 시간과 같은 정보를 사용하여 느리게 실행되는 태스크 및 컨테이너를 식별할 수 있습니다. 자세한 내용은 패키지 실행 로깅, 패키지에서 로깅 구현 및 로깅할 메시지 사용자 지정를 참조하십시오.
데이터 흐름 태스크에 대한 로깅 구성
데이터 흐름 태스크에서는 성능을 모니터링하고 조정하는 데 사용할 수 있는 여러 가지 사용자 지정 로그 항목을 제공합니다. 예를 들어 메모리 손실을 유발할 수 있는 구성 요소를 모니터링하거나 특정 구성 요소를 실행하는 데 소요되는 시간을 추적할 수 있습니다. 이러한 사용자 지정 로그 항목의 목록과 예제 로깅 출력은 데이터 흐름 태스크을 참조하십시오.
PipelineComponentTime 이벤트 사용
가장 유용한 사용자 지정 로그 항목은 PipelineComponentTime 이벤트일 수 있습니다. 이 로그 항목은 5개의 각 주요 처리 단계에서 데이터 흐름의 각 구성 요소에 소요된 시간(밀리초)을 보고합니다. 다음 표에서는 이러한 처리 단계에 대해 설명합니다. Integration Services 개발자는 이러한 단계를 PipelineComponent의 주요 메서드로 인식할 수 있습니다.
단계 |
설명 |
|---|---|
Validate |
구성 요소가 유효한 속성 값 및 구성 설정을 확인합니다. |
PreExecute |
구성 요소가 데이터 행을 처리하기 전에 일회성 처리를 수행합니다. |
PostExecute |
구성 요소가 모든 데이터 행을 처리한 후 일회성 처리를 수행합니다. |
ProcessInput |
변환 또는 대상 구성 요소가 업스트림 원본이나 변환에서 전달한 들어오는 데이터 행을 처리합니다. |
PrimeOutput |
원본 또는 변환 구성 요소가 다운스트림 변환이나 대상 구성 요소에 전달할 데이터의 버퍼를 채웁니다. |
PipelineComponentTime 이벤트를 설정하면 Integration Services는 각 구성 요소가 수행하는 각 처리 단계에 대해 각각 하나씩의 메시지를 기록합니다. 다음 로그 항목은 Integration Services CalculatedColumns 패키지 예제가 기록하는 메시지의 일부를 보여 줍니다.
ProcessInput에서 "Calculate LineItemTotalCost"(3522) 구성 요소에 356밀리초가 소요되었습니다.
ProcessInput에서 "Sum Quantity and LineItemTotalCost"(3619) 구성 요소에 79밀리초가 소요되었습니다.
ProcessInput에서 "Calculate Average Cost"(3662) 구성 요소에 16밀리초가 소요되었습니다.
ProcessInput에서 "Sort by ProductID"(3717) 구성 요소에 125밀리초가 소요되었습니다.
ProcessInput에서 "Load Data"(3773) 구성 요소에 0밀리초가 소요되었습니다.
PrimeOutput에서 "Extract Data"(3869) 구성 요소가 "OLE DB Source Output"(3879) 출력의 버퍼를 채우는 데 688밀리초가 소요되었습니다.
PrimeOutput에서 "Sum Quantity and LineItemTotalCost"(3619) 구성 요소가 "Aggregate Output 1"(3621) 출력의 버퍼를 채우는 데 141밀리초가 소요되었습니다.
PrimeOutput에서 "Sort by ProductID"(3717) 구성 요소가 "Sort Output"(3719) 출력의 버퍼를 채우는 데 16밀리초가 소요되었습니다.
이러한 로그 항목은 데이터 흐름 태스크의 대부분의 시간이 아래 나열된(내림차순) 단계에 소요되었음을 나타냅니다.
"Extract Data"라는 OLE DB 원본이 데이터를 로드하는 데 688밀리초가 소요되었습니다.
"Calculate LineItemTotalCost"라는 파생 열 변환이 들어오는 열을 계산하는 데 356밀리초가 소요되었습니다.
"Sum Quantity and LineItemTotalCost"라는 집계 변환이 데이터를 계산하고 다음 변환에 전달하는 데 PrimeOutput과 ProcessInput에서 각각 141밀리초와 79밀리초씩 총 220밀리초가 소요되었습니다.
데이터 흐름 엔진의 성능 모니터링
Integration Services에서는 데이터 흐름 엔진의 성능을 모니터링하기 위한 성능 카운터 집합을 제공합니다. 예를 들어 모든 버퍼에서 사용하는 총 메모리 양(바이트)을 추적하고 구성 요소에서 메모리가 부족한지 여부를 확인할 수 있습니다. 버퍼는 구성 요소에서 데이터를 저장하는 데 사용하는 메모리 블록입니다. 자세한 내용은 데이터 흐름 엔진의 성능 모니터링을 참조하십시오.
외부 리소스
technet.microsoft.com의 기술 문서 - SQL Server 2005 Integration Services: 성능에 대한 전략(SQL Server 2005 Integration Services: Strategy for Performance)
technet.microsoft.com의 기술 문서 - Integration Services: 성능 튜닝 기술
msdn.microsoft.com의 비디오 - 엔터프라이즈의 SSIS 패키지 데이터 흐름 튜닝
msdn.microsoft.com의 비디오 - SSIS 데이터 흐름 버퍼 이해
|
.gif "Integration Services 아이콘(작은 아이콘)")
Integration Services 관련 최신 정보 얻기변경 내역
업데이트된 내용 |
|---|
|