"아카이브되었지만 사용 가능한"데이터를위한 SQL Server 데이터베이스 디자인

우리는 "축소"하려는이 큰 데이터베이스 (> 1TB)를 가지고 있습니다. 데이터베이스는 하나의 주 엔터티를 중심으로 진행됩니다. "방문"이라고합니다. 토론을 위해 그것이 의료 행위를위한 데이터베이스라고 가정 해 봅시다.

절차, 연간, 후속 조치, 예방 접종 등과 같은 총 30 개의 방문 "유형"이 있으며, 각각 "방문"에 대한 보조 테이블 (예 : "visit_immuno")입니다.

데이터베이스는 2000 년 이후 약 12 ​​년간의 데이터를 축적했습니다. 누군가가 "라이브"버전에 약 3 년의 데이터를 보관하고 나머지는 "old_data"데이터베이스에 보관할 것을 제안했습니다. 날짜는 정규화 된 이후 "방문"테이블에만 저장됩니다. 방문 테이블에는 ROWVERSION열과 BIGINT의사 ID (클러스터) 열도 포함됩니다. 모든 의도와 목적을 위해 클러스터링 키가 SEQUENCE (SQL Server 2012 Enterprise)로 채워져 있다고 가정 해 보겠습니다 cid.

(가) visit.date의사가 확장의 방문 및 데이터의 그의 "서류 가방"을 반환에 갈 때, 예를 들어 클러스터링 키와 같은 순서로 항상 아니라, 메인 테이블에 병합됩니다. 원인 것 "방문"테이블에 일부 업데이트도 있습니다 ROWVERSION열이 모두와 동기화로 cid하고 date간단히 말해,도 - 열 ROWVERSION이나 cid이러한 이유에 적합한 파티션 키를 만들 것입니다.

"라이브"에서 데이터를 제거하기위한 비즈니스 규칙은이 있다는 것입니다 visit.date이상 36개월해야 하고 자식 visit_payment레코드가 존재해야합니다. 또한 "old_data"데이터베이스에는를 제외한 기본 테이블이 없습니다 visit%.

그래서 우리는 다음과 같이 끝납니다.

라이브 DB (일일 사용)-모든 테이블 Old-Data DB- visit%테이블의 이전 데이터

이 제안 은 (제외 ) 의 모든 기본 테이블에 대한 동의어 를 포함하는 쉘인 결합 된 DB 와 두 데이터베이스 의 테이블에서 UNION ALL의 뷰 를 요구 합니다.Live DBvisit%visit%

Old-DataDB 에서 동일한 인덱스가 생성되었다고 가정하면 쿼리는 UNION-ALL Views ? 어떤 유형의 쿼리 패턴이 UNION-ALL 뷰 의 실행 계획을 넘어 설 수 있습니까?

편의상 라이브 데이터베이스를 호출 LiveDb하고 achive 데이터베이스를 호출 한다고 가정합니다.ArchiveDb

• 동의어를 통해 데이터베이스 LiveDb의 테이블 을 가리키는 UNION ALL보기 추가 ArchiveDb(동의어와 결합 된 db를 수행 할 필요가 없음)
• visit.date이 열 visit_payments이 아직없는 경우 "파티션"을 설정 하고이 열을 비정규 화합니다 (공존 된 결합 성능이 향상됨)
• 가능한 경우 두 개의 큰 테이블 만 아카이브하십시오 (최적화 프로그램이 트립 될 가능성을 줄입니다). LiveDb더 작은 테이블에 대한 모든 조인이 로컬로 유지되도록 UNION ALL보기 및 다른 테이블을 유지하십시오.
• 모두의 테이블에 CHECK 제약 조건을 추가 LiveDb하고 ArchiveDb 그 범위에 대해 설명 visit.date테이블에 포함합니다. 이것은 옵티마 이저가 열이 포함 된 탐색 및 스캔에서 아카이브 테이블을 제거하는 데 도움이됩니다 visit.data. 이 제약 조건을 주기적으로 업데이트해야합니다.
• UNION ALL보기에서에서 필터링하는 WHERE 기준을 추가하십시오 visit.data. 이것은 점검 제한 조건에서 이미 제공 한 힌트에 추가 된 것입니다. 이것은 필터가 눌려 질 가능성을 최대화합니다
• EE가있는 경우 테이블을 아카이브 데이터베이스에 파티션하십시오 (그러나 라이브 데이터베이스에는 없습니다). 정말 화려하고 싶다면 파일 그룹 수준 백업 / 복원 아카이브 데이터베이스의 백업을 사용하여 백업 시간을 절약하십시오.
• 퍼팅 고려 AchiveDb가 아직없는 경우 단순 복구 모드. 트랜잭션 로그 백업이 필요하지 않을 것ArchiveDb
• 사용 INSERT WITH ... (TABLOCK) SELECT ... WITH (ROWLOCK) 사이에서 데이터를 이동시킬 때 목적지에서 최소 로깅을 강제 LiveDb하고ArchiveDb

위의 모든 내용이 옵티마이 저가 아카이브 테이블을 탐색 및 스캔에서 제거한다고 보장하지는 않지만 더 가능성이 높습니다.

제거가 일어나지 않을 때. 이것은 당신이 볼 수있는 효과입니다 (이 목록이 불완전 할 수 있습니다). 검색의 경우 모든 쿼리에 대해 추가 검색을 수행합니다 (이로 인해 IOPS가 증가 함). 스캔의 경우 아카이브 테이블과 라이브 테이블을 모두 스캔 할 수 있으므로 성능이 저하 될 수 있습니다. 옵티 마이저를 트립 할 수있는 일반적인 방법은 다음과 같습니다.

• 당신이 가입하는 경우 visit%함께 테이블과 수행이 포함되지 visit.data의 기준을 (당신이 denormalise하려는 이유가있다)에 가입. 이 때문에 일부 쿼리를 수정하고 싶을 수도 있습니다
• visit.data다른 테이블과 다른 테이블 사이에 해시 조인을 얻는 경우 (예 : 날짜 차원) 테이블을 올바르게 제거하지 못할 수 있습니다.
• 보관 된 테이블을 통해 데이터를 집계하려고하면
• 그러나 아무 항목이나 필터링 visit.data하면보기의 키에서 직접 찾기 등을 수행 할 수 있습니다.

마지막 시나리오의 cid경우 가능 하면 - 에 다른 점검 제한 조건을 추가하여 최악의 영향으로부터 자신을 보호 할 수 있습니다. cid테이블에서 행의 날짜 및 진행과 관련하여 "정리되지 않은" 순서를 언급했습니다 . 그러나 정보를 포함하는 테이블을 유지할 수있다 : "더이 없습니다 cid이 숫자 이상이 이후 visit.data또는 유사한?" 그러면 추가적인 제약이 발생할 수 있습니다.

주의해야 할 또 다른 사항은 분할 된 뷰를 쿼리하면 병렬 쿼리가 많은 스레드를 생성 할 수 있다는 것입니다 (두 "서브 테이블"이 동일한 병렬 최적화에 노출되므로). 따라서 서버 또는 병렬 쿼리에서 MAXDOP를 제한 할 수 있습니다.

그건 그렇고, 쿼리를 잘 알고 있다면 두 데이터베이스에 동일한 인덱스가 필요하지 않을 수도 있습니다 (이는 테이블을 올바르게 제거한다고 100 % 확신한다고 가정합니다). 에 대한 열 저장소 사용을 고려할 수도 ArchiveDb있습니다.

우리가 한 방법은 이전 데이터를 일괄 적으로 새로 만든 데이터베이스에 쓰고 라이브 DB에서 이전 데이터를 삭제하는 것입니다. 그렇게하면 두 db 모두 액세스 할 수 있습니다. 새로 작성된 데이터베이스를 백업하고 다른 위치로 복원하여 프로덕션 서버에서 큰 공간을 제거 할 수도 있습니다. 그것이 귀하의 요구에 적합한 솔루션이기를 바랍니다.