활동 데이터 스토리지
이 항목에서는 활동 데이터 저장소, 점증적인 활동 테이블 증가로 인한 성능 문제 및 BAM에서 진행 중인 활동과 완료된 활동에 대해 별개의 테이블을 사용하여 이러한 성능 문제를 해결하는 방법에 대해 설명합니다. 또한 이 항목에서는 데이터 쿼리를 위한 온라인 윈도 및 성능 향상을 위해 BAM에서 분할 기능을 사용하는 방법에 대해서도 설명합니다.
활동 데이터 저장소의 기본 개념은 각 활동 유형에 대해 별개의 테이블을 지정하여 각 레코드가 서로 다른 활동 인스턴스(예: 진행 중인 활동 또는 완료된 활동)를 나타내도록 하는 것입니다.
이 예제에서는 구매 주문서 활동에 대한 테이블을 보여 줍니다.
| PO# | RecvTime | City | 수량 | ShipTime | DeliveryTime |
|---|---|---|---|---|---|
| 123 | 오전 8:00 | 시애틀 | 150 | 오전 8:24 | 12:45pm |
| 124 | 오전 8:30 | 시애틀 | 234 | 오전 8:45 | 오후 1:20 |
| 125 | 오전 8시 35분 | Redmond | 87 | 오전 9:05 | 오후 2시 30분 |
| 126 | 오전 8:45 | 시애틀 | 450 | 오전 9:20 | 오후 3시 10분 |
| 127 | 오전 8:55 | Redmond | 200 | 오전 9:30 | <NULL> |
| 128 | 오전 8:57 | 시애틀 | 340 | 오전 9:20 | 오후 3:05 |
| 129 | 오전 9:12 | 시애틀 | 120 | 오전 9:45 | <NULL> |
| 130 | 오전 9:30 | Redmond | 25 | 오전 10:15 | <NULL> |
| 131 | 9:45 | 시애틀 | 250 | 오전 10:35 | <NULL> |
| 132 | 오전 10:00 | Redmond | 100 | <NULL> | <NULL> |
| 133 | 오전 10:15 | 시애틀 | 230 | <NULL> | <NULL> |
| 134 | 오전 10:25 | Redmond | 45 | <NULL> | <NULL> |
이 테이블의 경우 새 구매 주문서가 수신되면 BAM은 새 행을 추가하고 RecvTime, City, Quantity 등의 일부 열에 Null이 아닌 값을 설정합니다. 나중에 이 구매 주문서를 승인하고 배송하면 ShipTime이 Null이 아닌 값으로 설정됩니다. 마지막으로 출하 품목이 입고 및 확인되면 DeliveryTime이 Null이 아닌 값으로 설정됩니다.
이러한 간단한 구현 방식의 성능은 시간이 지날수록 빠르게 저하됩니다. 즉, 처음에는 SQL Server에서 처리할 수 있는 트랜잭션 수(CPU 처리 능력에 따라 다름)에 따라 성능이 일정 수준으로 유지되지만 어느 정도 시간이 지나면 성능이 크게 저하됩니다. 동시에 디스크 IO의 평균 큐 길이도 허용되는 한도 이상으로 증가합니다.
BAM 쓰기 성능과 디스크 큐 길이
이러한 성능 저하가 발생하는 이유는 완료되는 비즈니스 프로세스가 늘어날수록 테이블 크기가 증가하기 때문입니다. 예를 들어 처음에는 저장 프로시저의 UPDATE 문이 구매 주문서 번호를 찾기 위해 클러스터형 인덱스에서 검색을 수행하고 메모리에서 일부 페이지를 읽습니다. 구매 주문서 프로세스의 각 인스턴스는 소요되는 시간도 다르고 서로 독립적이기 때문에 저장 프로시저에 대한 다음 호출에서는 대상 구매 주문서 인스턴스가 다를 수 있으며 이 경우에는 메모리에서 다른 데이터 페이지를 읽어야 합니다. 구매 주문서 레코드의 총 개수가 적으면 SQL Server는 모든 데이터 페이지를 메모리에 캐시합니다. 그러나 레코드 수가 증가하면 캐시 적중률이 낮아지므로 각 작업에서 실제 디스크 읽기를 수행해야 합니다. 이렇게 되면 테이블에 대해 쿼리 활동을 수행할 수 없습니다.
BAM 테이블
이 문제를 방지하기 위해 BAM에서는 다음 그림에서와 테이블 두 개, 즉 진행 중인 활동을 위한 테이블과 완료된 활동을 위한 테이블을 사용합니다.
BAM 테이블
이 그림에서 중요한 개념은 업데이트가 발생하는 비교적 작은 테이블과 크게 증가하지만 증분 액세스되는(INSERT 전용) 테이블을 따로 유지하는 것입니다. 이 예제에서는 현재 처리 중인 주문만 활성 테이블에 저장되고 이미 배송된 모든 주문은 완료된 테이블에 저장됩니다.
이 테이블 구조를 사용하면 트리거 때문에 앞에서 설명한 단일 테이블의 INSERT/UPDATE보다 속도가 느리지만 시간이 지나도 안정적인 쓰기 성능을 유지할 수 있습니다.
활동 데이터용 온라인 윈도
활동 저장소는 기본적으로 현재 활동 또는 최근에 완료된 활동에 대한 쿼리를 처리합니다. BAM은 BAM 기본 가져오기 데이터베이스에서 오래 전에 완료된 활동을 보관한 다음 제거합니다. 따라서 활동 데이터는 BAM을 통과하면서 구성 가능한 온라인 윈도 동안만 쿼리의 대상이 될 수 있습니다.
BAM 분할
성능을 향상시키고 다운타임을 방지하기 위해 활동 저장소에서는 활동이 완료된 시점의 타임스탬프를 기준으로 분할을 사용합니다. BAM은 완료된 테이블을 동일한 형식의 다른 빈 테이블과 정기적으로 교체하여 분할 작업을 수행합니다. 이 작업을 수행하면 다음 그림에서와 같이 더 오래 전에 완료된 활동이 새 테이블로 이동되고 이전 테이블은 쿼리 용도로만 유지됩니다.
BAM 파티션 교체
파티션이 온라인 윈도를 완전히 벗어나면 BAM은 데이터를 보관한 다음 삭제합니다. 또한 사용자의 복잡한 작업을 최소화하기 위해 BAM은 다음 형식의 분할된 보기를 유지 관리합니다.
SELECT * FROM Active
UNION ALL
SELECT * FROM Completed
UNION ALL
BAM은 파티션을 만들거나 삭제할 때마다 자동으로 이 보기를 다시 만듭니다.
BAM 분할과 관련하여 다음 사항을 참고하십시오.
분할된 뷰의 이름은 bam_<ActivityName>_AllInstances. 이 보기는 직접 쿼리 용도로 사용할 수 없지만 BAM 계측 문제를 해결하는 데 유용합니다. 데이터 쿼리는 이 보기를 기반으로 각 비즈니스 사용자 범주를 위해 만들어진 특정 보기에 대해 수행해야 합니다. 자세한 내용은 인스턴스 데이터 쿼리를 참조하세요.
기본 가져오기 데이터베이스의 테이블 bam_Metadata_Activities 현재 활동에 대한 레코드에서 OnlineWindowTimeUnit 및 OnlineWindowLength 값을 수정하여 온라인 창을 설정합니다.
DTS 패키지인 BAM_DM_<ActivityName>은 분할 및 보관/제거를 수행합니다. 이 패키지는 실행될 때마다 다른 파티션을 자르거나 온라인 윈도 외부에 있는 모든 파티션을 보관/삭제합니다.
보관 데이터베이스가 구성되어 있지 않으면 BAM은 오래된 활동 데이터를 보관하지 않고 삭제합니다.