SQL Server의 매우 큰 테이블

Question

SQL Server 2005 64 비트 Standard Edition에서 실행되는 매우 큰 테이블 (> 77M 레코드 증가)이 있으며 성능 문제가 있습니다. 매일 수십만 개의 레코드가 추가됩니다.

SQL Server Standard Edition에서 처리 할 수있는 레코드 수에 제한이 있는지 아는 사람 있습니까? 엔터프라이즈 에디션으로 전환을 고려 중이거나 사용할 수있는 트릭이 있습니까?

추가 정보 :

이

문제의 테이블 (14 열) 꽤 평평한는 6 개 필드 및 하나의 필드에 두 개의 다른 인덱스 클러스터 된 인덱스가있다.

하나의 문제 쿼리에서 select에있는 세 개의 필드를 사용하여 네 번째 인덱스를 추가했으며 예상 성능에 차이가 없음을 확인했습니다 (쿼리는 업무 시간에 실행해야하는 프로세스의 일부이므로 우리는 아직 통계가 없습니다.) 이러한 필드는 클러스터형 인덱스의 일부입니다.

Answer 1

[6 개 필드 및 하나의 필드에 두 개의 다른 인덱스 클러스터 된 인덱스가 있습니다.] 필드에 대한 자세한 내용을 모른 채

, 내가 찾으려고 것 클러스터 된 인덱스를 더 작게 만드는 방법.

SQL Server에서는 클러스터되지 않은 인덱스에서 실제 데이터 페이지로의 최종 조회를 수행하는 방법으로 모든 클러스터 된 인덱스에도 모든 클러스터 된 키 필드가 포함됩니다.

각 8 바이트 = 48 바이트의 필드가 6 개있는 경우 2 배 더 많은 인덱스를 곱하면 7,700 만 개의 행이됩니다. 많은 수의 낭비 공간이 있습니다. 많은 수의 입출력 작업이 발생합니다 ( ). (따라서 성능이 저하됩니다).

클러스터 된 인덱스의 경우 고유하고 안정적이며 가능한 한 작게 (바람직하게는 단일 INT 등) CRUCIAL입니다. 마크

Answer 2

http://msdn.microsoft.com/en-us/library/ms143432.aspx

당신은 성장의 여지를 가지고있다.

성능 문제에 관한 한 완전히 다른 질문입니다. 캐싱, 샤딩, 정규화, 인덱싱, 쿼리 튜닝, 앱 코드 튜닝 등.

Answer 3

가장 먼저 살펴볼 것은 색인 생성입니다. Management Studio에서 실행 계획 생성기를 사용하는 경우 인덱스 검색 또는 클러스터 된 인덱스 검색을 확인하려고합니다. 스캔 (특히 테이블 스캔)이 표시되면 일반적으로 검색하는 열의 색인을 작성하여 성능 향상 여부를 확인해야합니다.

확실히 Enterprise Edition으로 이동할 필요가 없습니다.

Answer 4

표준을 처리 할 수 ​​있어야합니다. 인덱스와 테이블에서 사용하는 쿼리를 살펴 보겠습니다. 인서트가 인덱스 재귀를 너무 많이 생성하지 않도록 구조를 만들고 싶지만, 쿼리는 여전히 인덱스를 이용하여 테이블의 작은 부분에 대한 조회를 제한 할 수 있습니다.

그 외에도 테이블을 파티션 할 수도 있습니다. 이렇게하면 테이블을 여러 논리 그룹으로 나눌 수 있습니다. "배후에서"할 수 있기 때문에 별도로 저장 했더라도 SQL Server에 하나의 테이블로 표시되거나 수동으로 수행 할 수 있습니다 (새 '아카이브'또는 연간 테이블을 만들고 행을 수동으로 이동할 수 있음) . 어느 쪽이든 이후에만을 먼저 보았습니다. 그렇지 않으면 모든 파티션을 검사하지 않아도됩니다. 또한 을 파티션하면require Enterprise Edition이되므로 최후의 수단으로 저장해야하는 또 다른 이유입니다.

Answer 5

그 자체로는 77M 레코드가 SQL Server에 많은 영향을 미치지 않습니다. 어떻게 10 만개의 레코드를로드하고 있습니까? 하루에 일괄로드입니까? 아니면 일종의 OLTP 응용 프로그램을 통해? 당신이 가지고있는 성능 문제, 즉 데이터를 추가한다는 것입니까? 또는 그것은 당신에게 가장 큰 문제를주는 질문입니까?

한 번에 100,000 개의 레코드를 추가하고 추가되는 레코드가 클러스터 인덱스를 강제로 테이블에 추가하면 성능이 빨리 저하됩니다. 삽입 된 데이터의 테이블 구조, 인덱스 및 유형에 대한 자세한 내용이 도움이 될 것입니다.

또한 램의 양과 디스크의 속도가 큰 차이를 만들 것입니다. 무엇을 실천하고 있습니까?

Answer 6

보유하고있는 디스크 유형은 무엇입니까?

일부 디스크 카운터를 모니터링하여 요청이 대기 중인지 확인할 수 있습니다.

다른 파일 그룹에 넣으면이 테이블을 다른 드라이브로 이동할 수 있습니다. 또한 인덱스와 동일하게 사용할 수 있습니다.

Answer 7

7700 만개의 레코드를 모두 하나의 테이블에 실제로 액세스해야합니까?

예를 들어 마지막 X 개월 분량의 데이터에만 액세스해야하는 경우 보관 전략을 수립하는 것이 좋습니다. 이것은 데이터의 양을 줄이기 위해 보관 테이블에 데이터를 재배치하고 이후에 '핫'테이블에서 쿼리 시간을 늘리는 데 사용할 수 있습니다.

이 접근법은 표준 버전에서 구현 될 수 있습니다.

엔터프라이즈 에디션으로 업그레이드하는 경우 테이블 파티셔닝을 사용할 수 있습니다. 다시 데이터 구조에 따라 성능이 크게 향상 될 수 있습니다. 파티셔닝은 앞서 언급 한 전략을 구현하는 데 사용할 수도 있지만 관리 오버 헤드가 적습니다. 여기

는

http://msdn.microsoft.com/en-us/library/ms345146.aspx

2005

나는 내가 무엇을 설명 한 것은 분명하고 이해할 수있는 희망 SQL Server의 테이블 파티셔닝에 우수한 백서입니다. 추가 도움이 필요하면 저에게 직접 연락하십시오.

건배,

Answer 8

처음에 나는 마크에 동의하고 싶었다. 클러스터 된 인덱스의 너비는 모든 레코드에서 조회를 수행하는 데 기본적으로 사용되므로 의심스러운 것으로 보입니다. 클러스터 된 인덱스가 넓을수록 일반적으로 액세스 속도가 느려집니다. 그리고 6 개 필드 클러스터 인덱스는 정말로 의심 스럽습니다.

클러스터 된 인덱스에는 고유성이 필요하지 않습니다. 사실, 클러스터 된 인덱스에 있어야하는 필드의 가장 적합한 후보는 고유하지 않고 조인에 사용되는 필드입니다.예를 들어, Persons 테이블의 각 Person는 하나의 Group을 어디에 속해 당신은 자주, Groups에 Persons에 참여 그룹에 의해 사람들의 배치에 액세스하는 동안, Person.group_id이 특정 사용 사례를위한 이상적인 후보가 될 것입니다.

Answer 9

위의 Marc 및 Unkown과 동의합니다. 클러스터 된 인덱스의 6 개의 인덱스는 너무 많습니다. 특히 14 개의 열만있는 테이블의 경우 특히 그렇습니다. 3 또는 4를 넘지 않아야합니다. 1 또는 2라고 말합니다. 클러스터 된 인덱스는 디스크의 실제 테이블이므로 레코드가 삽입되면 데이터베이스 엔진은이를 정렬해야하며 그것을 디스크에 정리 된 장소에 배치하십시오. 비 클러스터형 인덱스는 조회 테이블 '을 지원합니다. 내 VLDB는 아래 첫 번째 지점에 따라 디스크 (CLUSTERED INDEX)에 배치됩니다. 하나, 또는 필드가 데이터베이스에 추가되는 날짜 필드, 또는 다른 필드가있는 경우,

1. 1에 클러스터 된 인덱스를 줄이거 나 2. 최고의 필드 선택 (INT)이 IDENTITY 있습니다 그것은 데이터가 데이터베이스에 추가되는 방식의 자연스러운 종류입니다. 요점은 당신이 테이블의 하단에 그 데이터를 유지하려고하는 것입니다 ... 또는 그것을 (90 % +) 방식으로 디스크에 레이아웃 해두십시오. 이렇게하면 재구성 작업이 필요 없거나 최상의 읽기 작업을 위해 올바른 장소에서 데이터를 얻으려고 한 번만 치기 만하면됩니다. 제거 된 필드를 클러스터되지 않은 인덱스에 두어 조회 효율성을 잃지 않도록하십시오. 나는 VLDB에 4 개 이상의 필드를 두지 않았습니다. 자주 업데이트되는 필드가 클러스터 된 인덱스 OUCH에 포함되어 있으면 디스크의 레코드를 재구성하고 COSTLY 조각화를 일으킬 수 있습니다.
2. 색인에서 fillfactor를 확인하십시오. 채우기 비율 (100)이 클수록 데이터 페이지와 인덱스 페이지가 더 가득 차게됩니다. 가지고있는 레코드의 수와 삽입하는 레코드의 수와 관련하여 레코드가 삽입 될 때 채우기 공간을 허용하기 위해 비 클러스터형 인덱스의 fillfactor # (+ 또는 -)를 변경합니다. 클러스터 된 인덱스를 순차적 데이터 필드로 변경하면 클러스터 된 인덱스에서 그다지 중요하지 않습니다. 엄지 법칙 (IMO), 높은 쓰기의 경우 60-70 fillfactor, 중간 쓰기의 경우 70-90, 높은 읽기/쓰기의 경우 90-100 fillfactor를 70으로 떨어 뜨리면 한 페이지의 100 개 레코드 당 70 개의 레코드가 작성되어 새로운 레코드 나 재구성 된 레코드에 대해 30 개 레코드의 여유 공간이 남게됩니다. 더 많은 공간을 차지하지만 매일 밤마다 DEFRAG해야합니다 (아래 4 참조)
3. 통계가 테이블에 있는지 확인하십시오. "sp_createstats 'indexonly'"를 사용하여 통계를 작성하기 위해 데이터베이스를 스윕하려는 경우 SQL Server는 엔진이 통계를 필요로하는 모든 인덱스에 대한 모든 통계를 작성합니다. 그래도 'indexonly'속성을 그대로 두지 마십시오. 그렇지 않으면 모든 필드에 대한 통계를 추가 할 것입니다. 그러면 좋지 않을 것입니다.
4. DBCC SHOWCONTIG를 사용하여 테이블/인덱스를 검사하여 조각화가 가장 많이 발생하는 인덱스를 확인하십시오. 나는 여기에 세부 사항을 설명하지 않을 것이며, 단지 당신이 그것을해야한다는 것을 알고 있습니다. 그 정보를 기반으로 인덱스가 변화를 겪고있는 변화와 얼마나 빨리 (시간이 지남에 따라) 변화와 관련하여 fillfactor를 위 또는 아래로 변경하십시오.
5. 개별 인덱스에 온라인 (DBCC INDEXDEFRAG) 또는 오프라인 (DBCC DBREINDEX) 작업을 수행하여 조각 모음을 수행하도록 작업 일정을 설정하십시오. 경고 : CLCCTERED INDEX에서 특히 응용 프로그램을 중단시킬 수 있으므로 유지 관리 시간이 없다면이 큰 테이블에서 DBCC DBREINDEX을 수행하지 마십시오. 너는 경고 당했다. 이 부분을 테스트하고 테스트하십시오.
6. 실행 계획을 사용하여 SCANS 및 FAT PIPES의 존재를 확인하고 색인을 조정 한 다음 저장된 procs를 조각 모음하고 다시 작성하여 해당 핫 스폿을 없앱니다. 실행 계획에 RED 객체가 표시되면 해당 필드에 대한 통계가 없기 때문입니다. 그 나쁜. 이 단계는 "과학보다는 예술"에 가깝습니다.
7. 피크 시간대에 UPDATE STATISTICS WITH FULLSCAN을 실행하여 가능한 한 데이터 배포에 대한 많은 정보를 쿼리 엔진에 제공하십시오.그렇지 않으면 주간에 테이블에서 표준 UPDATE STATISTICS (표준 10 % 스캔)를 수행하거나 엔진이 데이터를 효율적으로 검색하기 위해 데이터 분포에 대한 자세한 정보를 가지고 있는지 확인하기 위해 관측치를보아야합니다.

죄송합니다. 매우 오래되었지만 매우 중요합니다. 나는 여기에 최소한의 정보만을 제공했지만 톤을 도울 것입니다. 당신의 시간과 시험이 요구되는 이러한 점들에 의해 사용되는 전략에 들어가는 관찰과 관상감이 있습니다.

엔터프라이즈 버전으로 이동할 필요가 없습니다. 나는 파티셔닝과 관련하여 이전에 사용 된 기능을 사용하기 위해 수행했습니다. 하지만 검색 및 온라인 DEFRAGING 및 유지 관리 기능을 통해 훨씬 우수한 멀티 스레딩 기능을 제공했습니다. Enterprise Edition에서는 VLDB를 사용하면 훨씬 편리하고 친숙합니다. Standard Edition은 온라인 데이터베이스에서도 DBCC INDEXDEFRAG를 처리하지 않습니다.

Answer 10

아마도 이것들은 부전승이지만 ... (1) 관계형 데이터베이스에는 FIELDS가 없습니다 ... COLUMNS가 있습니다. (2) IDENTITY 열은 일반적으로 데이터가 정규화되지 않았거나 디자이너가 게으른 것을 의미합니다. 일부 열의 조합은 고유해야하며 해당 열은 기본 키를 구성합니다. (3) datetime 열에 대한 인덱싱은 일반적으로 좋지 않습니다. datetime 열에 대한 CLUSTERING은 일반적으로 디스크에있는 동일한 물리적 공간에 대해 모든 삽입이 경쟁하기 때문에 항상 좋은 생각입니다. 특히 datetime 열이 증가합니다. 해당 열이 범위 제한의 일부인 읽기 전용 테이블의 datetime 열에 대한 클러스터링은 종종 좋은 아이디어입니다 (아이디어가 충돌하는 방식을 누가 알 수 있습니까?)