4.Tuning Processing Performance
4.2 Tuning Dimension Processing
4.2.2 Dimension Processing Commands
차원처리명령를 통해 차원을 처리합니다.
각 처리 명령은 하나 이상의 job을 생성하고 operation을 수행합니다.
성능관점에서 차원처리 명령은 중요합니다
l ProcessData
l ProcessFull
l ProcessUpdate
l ProcessAdd
ProcessFull
ProcessFull, ProcessData 명령은 차원의 모든 저장소
내용을 삭제하고 다시 작성합니다.
ProcessFull은 모든 차원 처리 작업을 실행하고 모든 종속
파티션에서 암시적 ProcessClear를 수행합니다.
즉, 차원의 ProcessFull 작업을
수행할때는 종속파티션에 대해 ProcessFull 작업을 수행하여 큐브를 다시 온라인으로 가져와야합니다. (-> 팩트에 영향)
ProcessFull은 차원 데이터 자체에 대한 인덱스도 작성합니다 (파티션의 인덱스는 별도로 작성됩니다).
차원에서 ProcessData를 수행하는 경우 나중에 차원 쿼리에서
이러한 인덱스를 사용할 수 있도록 ProcessIndexes를 수행해야합니다.
ProcessUpdate
ProcessFull과 달리
ProcessUpdate는 차원 저장 내용을 삭제하지 않습니다.
대신 종속 파티션을 유지하기 위해 지능적으로 업데이트를 적용합니다.
특히 ProcessUpdate는
SQL 쿼리를 보내 전체 차원 테이블을 읽은 다음 변경 내용을 차원 저장소에 적용합니다.
ProcessAdd
ProcessAdd는 new
members를 삽입하기만 하면 되는 시나리오에 적합합니다.
기존 members를 삭제하거나 업데이트 하지 않습니다.
ProcessAdd의 성능 이점은 source
차원 테이블의 행이 new rows만 return하도록
제한하는 쿼리라는 다른 source table이나 data
source view를 사용할 수 있다는 것입니다.
이렇게하면 모든 소스 데이터를 읽을 필요가 없습니다.
또한 ProcessAdd는 모든 인덱스와 집계를 유지합니다.
ProcessUpdate 및
ProcessAdd에는 사용자가 알아야 할 몇 가지 특별한 동작이 있습니다.
이러한 동작은 다음 섹션에서 설명합니다.
4.2.2.1 ProcessUpdate
ProcessUpdate는 특성관계유형(rigid / flexible)에 따라 insert, update,
delete를 처리할 수 있습니다.
특성관계 > 속성 > RelationshipType
- Rigid : 일자차원의 2017년 1월은 2017년에 속한다. 계속..
- Flexible : 직원은 부서 이동이 가능하다.
Aggregations, indexes를 생성하므로 조회 성능을 유지
보수하기 위해 집계를 다시 작성해야합니다.
그러나 변경이 감지 된 경우에만 유연한 집계가 drop됩니다.
ProcessUpdate가 실행되면 차원에 종속 된 파티션을 통과해야합니다.
각 파티션에 대해 모든 인덱스와 집계를 점검하여 업데이트가 필요한지 확인해야합니다.
많은 파티션, 인덱스 및 집계가있는 큐브에서는 매우 오랜 시간이 걸릴
수 있습니다.
4.2.2.2 ProcessAdd
ProcessAdd는 Type2 변경
차원을 관리하는 기본 방법입니다.
Analysis Services는 기존 인덱스를 무효화 할 필요가
없다는 것을 알고 있기 때문에 일반적으로 ProcessAdd는
ProcessUpdate보다 훨씬 빠르게 실행됩니다.
Analysis Services의 기본 구성에서 ProcessAdd는 실행시 처리 오류를 트리거하고 중복 키 값을보고합니다.
이 오류는 이미 차원에 있는 키가 아닌 속성의 "추가"로 인해 발생합니다.
이 경우 해결 방법은 차원 처리 명령에서 <KeyDuplicate>를 IgnoreError로 설정하는 것입니다.
Empty차원에서 ProcessAdd를
실행할 수 없습니다.
4.3 Tuning Cube Dimension Processing
4.3.1 Reduce Attribute Overhead
Attribute의 수가 많으면 차원처리의 많은 비용이 발생합니다.
차원처리의 시간이 제한적인 경우, 성능향상을 위해선 attribute를 변경해야 합니다.
최종 사용자가 사용하지 않는 Attribute는 삭제하십시오.
4.3.1.1 Remove Bitmap Indexes
기본키 속성을 처리하는 동안, 모든 관련 속성에 대해 비트맵인덱스가
만들어집니다.
높은 카디널리티를 갖는 속성은 비트맵인덱스를 작성하는데 시간이 걸릴 수 있습니다.
예를 들어, 고객차원의 기본키는 계좌번호별로 각 고객을 고유하게 식별합니다.
그러나 사용자는 고객의 주민등록번호를 기준으로 데이터를 검색할 수 있습니다.
각 고객계좌번호는 주민등록번호와 1:1 관계입니다.
주민등록번호의 비트맵생성을 제거하는 것을 고려할 수 있습니다.
또한 매우 선택적인 비트맵인덱스가 있는 다른 속성과 함께 항상 질의되는 속성에서 비트맵인덱스를 제거하는 것도
고려할 수 있습니다.
다른 속성에 충분한 선택성이 있는 경우 다른 비트맵인덱스를 추가하여 필터링해도 큰 이점이 없습니다.
예를 들어 sales 팩트테이블을 만들고 사용자 쿼리가 항상 날짜
및 영업점 차원을 사용한다고 가정합니다.
영업점점원를 사용하여 필터를 적용하는 경우도 있습니다.
그러나 영업점에서 이미 필터링했기 때문에 영업점점원에 비트맵을 추가하면 성능에 큰 이점은 없습니다.
이 경우 영업점점원 특성에서 비트맵인덱스를 사용하지 않도록 설정할 수 있습니다.
Attribute 속성 >AttributeHierarchyOptimizedState
> Not Optimized
4.3.1.2 Optimize Attribute Processing Across Multiple Data Sources
계단식 속성 관계를 사용하여 여러 데이터 소스에서 차원을 가져 오는 경우 시스템은 데이터 소스에 따라 처리하는
동안 특성을 분할 할 수 있습니다.
속성의 키, 이름 및 속성 관계가 동일한 데이터베이스에서 제공된 경우, 시스템은 하나의 데이터베이스 만 조회하여 해당 속성에 대한 SQL 조회를
최적화 할 수 있습니다.
계단식 특성 관계를 사용하지 않으면 여러 원본의 데이터에 액세스하는 메서드를 제공하는 SQL Server OPENROWSET 함수가 데이터 스트림을 병합하는 데 사용됩니다.
이 상황에서는 여러 OPENROWSET 파생 테이블에 액세스해야하기 때문에 특성 처리가 매우 느립니다.
이 상황에서는 여러 OPENROWSET 파생 테이블에 액세스해야하기 때문에 특성 처리가 매우 느립니다.
옵션이있는 경우 ETL을 수행하여 차원에 필요한 모든 데이터를 동일한 SQL Server 데이터베이스로 가져와야합니다.
이를 통해 관계형 엔진을 활용하여 쿼리를 튜닝 할 수 있습니다.
이를 통해 관계형 엔진을 활용하여 쿼리를 튜닝 할 수 있습니다.
4.3.2 Tuning the Relational Dimenstion Processing Queries
파티션 당 하나의 쿼리만 서버에 보내는 팩트파티션과 달리 차원 프로세스 작업은 여러 쿼리를 보냅니다.
그 이유는 차원테이블과 팩트테이블이 다른 경향이 있기 때문입니다
l 차원은 작아지려고하고, 변화가 적으려하고,,.
l 팩트는 간단하지만
많은 변화가 있습니다.
차원의 특성을 갖는 테이블은 시스템에 대한 삽입 / 업데이트 성능
오버 헤드가 거의없이 과도하게 인덱싱 될 수 있습니다.
이를 처리하는 동안 이점을 이용하고 관계형 인덱스를 자유롭게 사용할 수 있습니다
차원 처리에 사용되는 관계형 쿼리를 신속하게 조정하려면 차원 처리의
Profiler 추적을 캡처하고 데이터베이스 엔진 튜닝 관리자를 사용하여 추적을 기반으로하는 권장 사항을 생성합니다.
작은 차원 테이블의 경우 제안 된 모든 인덱스를 추가 할 수있는 가능성이 있습니다.
큰 테이블의 경우, 가장 긴 실행 쿼리로 인덱스를 지정하십시오.
대규모 차원 테이블에 대한 자세한 조정 방법은 SQL Server 2008
R2 Analysis Services 운영 가이드를 참조하십시오.
4.3.2.1 Using ByTable Processing
Dimension의
ProcessingGroup 속성을 ByTable 값으로 설정하여 차원 처리 중에 Analysis Services의 동작 방식을 변경할 수 있습니다.
이 변경 작업을 수행하면 여러 SELECT DISTINCT 쿼리를
보내는 대신 처리 작업에서 하나의 쿼리를 사용하여 전체 테이블을 요청합니다.
처리 중에 모든 새 차원데이터를 보관할 만큼 충분한 메모리가있는 경우이 옵션을 사용하면 처리를 신속하게 최적화
할 수 있습니다.
각 특성에 대해 SELECT DISTINCT가 실행되지 않고 처리
중에 동일한 멤버가 반복적으로 발생하기 때문에 ByTable 처리로 인해 중복 키 (KeyDuplicate) 오류가 발생합니다.
따라서 사용자 정의 오류 구성을 지정하고 KeyDuplicate 오류를
비활성화 해야합니다.
댓글 없음:
댓글 쓰기