데이터 아카이브를위한 테이블 파티셔닝

13

대본:

  • 두 개의 데이터베이스 : table_이라는 하나의 매우 큰 테이블이있는 DB_A 및 DB_Archive.
  • 매일 60 일이 지난 레코드는 DB_A에서 삭제되고 DB_Archive로 이동하여 주로 2 개의 레코드에 대해 tableA가 DB_A에 많이 쿼리되므로 주로 "분리 된"항목을 남겨 둡니다.

이 프로세스는 느리고 많은 리소스를 소비하기 때문에이 프로세스를 제거하고 싶습니다. 날짜 열에 파티션 함수를 사용하여 DB_A에서 테이블 파티셔닝을 구현하고 하나의 파티션에서 2 개월 미만의 모든 레코드를 저장하고 다른 파티션에서 2 개월 이상 모든 레코드를 저장하려고합니다. 내 질문 :

  • 이 시나리오는 두 개의 다른 데이터베이스가있는 경우처럼 작동합니까? 레코드> getdate ()-30에 대해 tableA를 쿼리하면 보관 파티션을 읽을 수 있습니까?
  • 인덱스도 분할해야한다고 생각했습니다.
  • 내일 파티션 기능이 "변경"될 것이라는 사실을 어떻게 처리 할 수 ​​있습니까? 오늘 함수를 작성하면 (7 월 2 일, 범위는 5 월 2 일이지만 내일은 5 월 3 일) 의미합니다. 동적 파티션 기능을 만들 수 있습니까?
sql-server  sql-server-2005  partitioning 
— 디에고
소스
나는 동적 함수가 허용 된 경우에도 좋은 생각이라고 생각하지 않습니다 (그렇지 않다고 생각합니다) ... 우리는 더 자세하게 알아볼 수 있지만 달력 날짜를 기준으로 파티션을 나누고 떠날 것이라고 생각합니다. 한 번에 하나의 파티션 ...하지만 여기에는 다양한 옵션이 있습니다.
— JNK
작년에하고 싶은 일을 따라 예제를 작성했습니다. 우리는 x 일 동안의 데이터를 빠른 (비싼) 어레이에 보관하고 아카이브 데이터를 더 저렴한 스토리지로 옮기고 자하는 특별한 경우였습니다. 예제 스크립트를 위생 처리 할 수 ​​있으면 게시하고 그렇지 않으면 프로세스의 요약 일뿐입니다.
— Mark Storey-Smith
마크, 예, 제발, 그리고 당신의 경험을 공유 할 수 있다면. 성공 했습니까?
— Diego
그것은 작동하지만 궁극적으로 불필요했습니다 (우리는 더 간단한 길을 택했습니다). 아마도 귀하의 케이스에 60 일 경계가 존재하는 이유를 확장 할 수 있습니까? 모두가 올바른 방향으로 당신을 가리 키도록 도와 줄 것입니다.
— Mark Storey-Smith

답변:

6

파티셔닝을 사용하면 매일 파티셔닝을 수행해야하므로 3 년 동안 만 아카이브 할 수 있으므로 Pre-SQL 2012 제한 1000 개 파티션을 새로운 관점에서 볼 수 있습니다. SQL Server 2012를 사용하면 하루에 1 개의 파티션으로 충분한 15000 개의 파티션을 얻을 수 있습니다.

매일 새로운 파티션을 추가 할 것입니다. 61 일 과거 파티션을 이동하려는 경우 효율적으로 수행 할 수 있지만 여전히 오프라인 작업입니다. 효율적으로 파티션을 다른 파일 그룹으로 이동을 참조하십시오 .

모든 인덱스를 정렬해야합니다 ( 파티션 된 인덱스에 대한 특별 지침 참조) .

파티셔닝으로 구매하는 것은 쉬운 결정이 아니며 씹기에는 큰 물림 일 수 있습니다 ... 테이블 파티셔닝을 사용해야하는지 결정하는 방법을 참조하십시오 . 특히 파티셔닝으로 성능 향상을 기 대해서는 안됩니다. 날짜 시간별로 클러스터링하여 시계열 성능 문제에 접근해야합니다.

— 레무스 루사 누
소스
새로운 제한은 2008 SP2 및 2008 R2 SP1에서 사용할 수 있습니다. blogs.msdn.com/b/hanspo/archive/2010/11/29/…
— Jon Seigel
@Jon : 2008 SP2의 2008R2 SP1 구현에는 큰 경고가 표시 . As explained in this white paper, there are implications on certain features, including performance. 됩니다. SQL 2012 지원에는 경고가 없습니다.
— Remus Rusanu
지적 해 주셔서 감사합니다. 2008/2008 R2에서 사용할 때주의해야 할 사항이 있지만 필요한 경우 사용 가능한 옵션입니다.
— Jon Seigel
귀하의 의견에 감사드립니다. 나중에 자료에 대한 내용을 읽을 것입니다
— Diego
2

파티션 기능이 동적 일 수 있는지 모르겠지만 의심합니다. 그 길을 가지 않고 당신을위한 몇 가지 옵션 :

1-캘린더 DATE의 파티션 및 매일 가장 오래된 파티션에서 이동

2-날짜별로 필터링하는보기를 작성하고 기존의 모든 조회를 가리 킵니다 (기본 테이블의 이름을 다른 것으로 바꾸고보기의 현재 테이블 이름을 명명하여 쉽게 관리 할 수 ​​있음). 인덱스 변경으로 최적화 할 수 있습니다.

위의 첫 번째 옵션은 쿼리에서 날짜 필드를 사용하는 경우 훨씬 더 효과적입니다. 그렇지 않으면 여전히 현재 프로세스보다 빠르지 만 쿼리는 크게 향상되지 않습니다. 파티션은 일반적으로 파티션 필드를 필터링 할 수 있고 옵티마이 저가 볼 파티션을 알고있는 경우 가장 잘 작동합니다.

— JNK
소스
"매일"수동 작업을 피하고 싶습니다
— Diego
2

DB_A-지난 60 일 동안 서로 다른 파티션을 가진 tableA-가장 오래된 파티션에서 데이터를 이동하는 stagingTable

DB_Archive 테이블 A-60 일보다 오래된 모든 데이터를 저장합니다. (파티션되지 않음)

프로세스 : 1. 하루가 끝나기 전에 : 파티션 기능 변경-새로운 날에 대한 새로운 파티션을 추가하기 위해 분할 범위. (NB : "오늘 날짜 + 1 일"에 대한 파티션을 생성하는 대신 몇 단계 더 나아가고 싶을 수 있습니다. 예 : "오늘 날짜 + 5 일"

  1. 매일이 끝나면 먼저 DB_A.tableA에서 가장 오래된 파티션을 DB_A.stagingTable로 전환합니다. 가장 오래된 파티션을 병합하십시오.

  2. DB_A.stagingTable에서 DB_Archive.tableA로 데이터를 가져 오십시오. 마지막으로 DB_A.stagingTable을 자릅니다.

위의 내용은 Rolling Window라고하며 VLDB의 경우 매우 일반적인 시나리오입니다. 파티션에 대한 Microsoft의 백서 : 파티션 테이블 및 인덱스 전략을 참조 하거나 슬라이딩 창 시나리오 에서 구체적으로 시도하십시오.

— 다르 멘 다르 쿠마르 'DK'
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.