이러한 DMV의 결과를 어떻게 해석하여 파티셔닝 전략을 평가할 수 있습니까?

버전 : SQL Server 2008 R2 엔터프라이즈 Edtn. (10.50.4000)

파티셔닝 전략을 평가하기 위해 파티션의 인덱스에 대한 액세스 방법을 얻기 위해이 쿼리를 작성했습니다 (가장 넓은 의미에서 힙을 제거하고 있음). 내가 분할 된 테이블에 내 초점을 좁힐 때, 나는 내가보고 할 필요가 생각 range_scan_count하고 singleton_lookup_count있지만 힘든 시간의 개념화를있다.

SELECT 
    t.name AS table_name,
    i.name AS index_name,
    ios.partition_number, 
    leaf_insert_count,
    leaf_delete_count,
    leaf_update_count,
    leaf_ghost_count,
    range_scan_count,
    singleton_lookup_count,
    page_latch_wait_count ,
    page_latch_wait_in_ms,
    row_lock_count ,
    page_lock_count,
    row_lock_wait_in_ms ,
    page_lock_wait_in_ms,
    page_io_latch_wait_count ,
    page_io_latch_wait_in_ms
FROM sys.dm_db_partition_stats ps
    JOIN sys.tables t 
        ON ps.object_id = t.object_id
    JOIN sys.schemas s 
        ON t.schema_id = s.schema_id
    JOIN sys.indexes i 
        ON t.object_id = i.object_id
    AND ps.index_id = i.index_id
OUTER APPLY sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ios                            
WHERE   
    ps.object_id = ios.object_id
    AND ps.index_id = ios.index_id
    AND ps.partition_number = ios.partition_number
    and ps.index_id = ios.index_id
    and ps.partition_number = ios.partition_number                                  
    and s.name <> 'sys'     
    and ps.index_id <> 0 ;

관련 출력 (SO 테이블의 포맷으로 소정의 간격이 마지막 두 열이 존재와 상기 질의로부터 제 9 열 샘플이다 range_scan_count및 singleton_lookup_count각각) :

╔════════╦═════════════════╦════╦═══╦═══╦═══╦═══╦════════╦══════════╗
║ datetb ║ idx_datetb_col  ║  1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 205740 ║  3486408 ║
║ datetb ║ idx_datetb_col  ║  2 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  1079649 ║
║ datetb ║ idx_datetb_col  ║  3 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  1174547 ║
║ datetb ║ idx_datetb_col  ║  4 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  2952991 ║
║ datetb ║ idx_datetb_col  ║  5 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  3974886 ║
║ datetb ║ idx_datetb_col  ║  6 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  2931450 ║
║ datetb ║ idx_datetb_col  ║  7 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  3316960 ║
║ datetb ║ idx_datetb_col  ║  8 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  3393439 ║
║ datetb ║ idx_datetb_col  ║  9 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  3735495 ║
║ datetb ║ idx_datetb_col  ║ 10 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  4803804 ║
║ datetb ║ idx_datetb_col  ║ 11 ║ 0 ║ 0 ║ 0 ║ 0 ║  29617 ║  7655091 ║
║ datetb ║ idx_datetb_col  ║ 12 ║ 1 ║ 0 ║ 0 ║ 0 ║ 174326 ║ 47377226 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝

나는 몇 가지 다른 가능성을 볼 수 있지만 내가 (물론 내가이 코칭있어의 "이것에 대해 생각하는 방법에 대한 몇 가지 방향을 필요로 할 수 있습니다 내가 그"가 달려있다 "알아,하지만 때문에 또한 개념 이해를 찾고 있어요") :

1. 모든 파티션에 대한 비슷한 값은 range_scan_count 수 우리가 거의 동일한 횟수의 모든 파티션을 스캔하고 있기 때문에 우리가 좋은 파티션 제거를받지 못하고 있다는 것을 나타냅니다.
2. 값 singleton_lookup_count이 현저히 낮은 모든 파티션의 값을 변경 하면 원하는 것보다 스캔이 적기 때문에 파티션을 자주 제거 range_scan_count 할 수 있습니다 .
3. ?

그것들은 지금까지 나의 생각입니다. 나는 인덱스 또는 다른 정보 세트를 사용하여 인덱스를 선호하는 파티션 삭제로 어떤 테이블이 가장 유리한지 결정하기 위해 누군가가 어떻게 사용할 수 있는지에 대해 생각하기를 바랐습니다.

편집하다

잘린 DDL은 다음과 같습니다.

CREATE TABLE [dbo].[date_table](
    [date_id] [int] NOT NULL,
    [calendar_date] [datetime] NULL,
    [valdate] [datetime] NULL,
        CONSTRAINT [PK_datedb] PRIMARY KEY CLUSTERED 
        (
            [date_id] ASC
        ) ON [partschm]([date_id]);

CREATE UNIQUE NONCLUSTERED INDEX [idx_datetb_col] ON [dbo].[date_table]
(
    [calendar_date] DESC,
    [date_id] ASC
) ON [partschm]([date_id])
GO

인덱스 사용률을 검토하는 대신 계획 캐시를보고 논리적으로 많은 양의 논리적 읽기가있는 쿼리를 찾습니다. 일반적으로 파티셔닝을 처리 할 때 전체 서버 읽기의 50-80 %와 같이 읽기를 지배하는 소수의 쿼리를 찾습니다. 해당 쿼리가 파티션 제거를 성공적으로 수행하고 있는지 확인하십시오.

파티션 제거를 수행하지 않지만 파티션 구성표를 기반으로해야한다고 생각하면 쿼리 작성자와 함께 파티션 제거를 수행하십시오.

파티션을 제거하지 않고 쿼리를 작성하거나 파티션을 설계 한 방식으로 인해 파티션을 제거 할 수없는 경우 어려운 질문을 시작할 때입니다.

가장 큰 논리적 읽기 쿼리가 분할 된 테이블과 관련이없는 경우 다른 쿼리로 이동하여 집중하십시오.