¿Cómo puedo interpretar los resultados de estos DMV para ayudarme a evaluar nuestra estrategia de partición?

Versión: SQL Server 2008 R2 Enterprise Edtn. (10.50.4000)

En un intento por evaluar nuestra estrategia de particionamiento, escribí esta consulta para obtener los métodos de acceso contra índices en particiones (en el sentido más amplio del término, aunque estoy eliminando montones). A medida que reduzco mi enfoque a las tablas particionadas, creo que necesito mirar range_scan_county singleton_lookup_countme cuesta mucho conceptualizar.

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 ;

Resultado relevante (dada la brecha en el formato de tablas de SO, esta es una muestra de las primeras 9 columnas de la consulta anterior con las dos últimas columnas range_scan_county singleton_lookup_count, respectivamente):

╔════════╦═════════════════╦════╦═══╦═══╦═══╦═══╦════════╦══════════╗
║ 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 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝

Veo algunas posibilidades diferentes, pero necesito alguna dirección sobre cómo pensar en esto (por supuesto, estoy expresando esto en " mayo " porque sé que "depende", pero también estoy buscando comprensión conceptual):

Los valores similares para todas las particiones de range_scan_count pueden indicar que no estamos obteniendo una buena eliminación de la partición porque estamos escaneando todas las particiones aproximadamente la misma cantidad de veces.
Los valores variables para todas las particiones de singleton_lookup_countacompañado con valores significativamente más bajos para range_scan_count pueden indicar una eliminación de partición buena y frecuente porque estamos escaneando menos de lo que estamos buscando.
?

Esos son mis pensamientos hasta ahora. Esperaba que alguien sopesara cómo podría usar esto u otro conjunto de información para determinar qué tablas probablemente se beneficiarían al eliminar la partición a favor de los índices por completo.

EDITAR

Aquí hay un DDL recortado:

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

sql-server-2008-r2 partitioning swasheck
fuente

¿Podría editar la pregunta para incluir el esquema de la tabla? Cualquier interpretación tiene que depender del significado comercial de la partición.

Jon Seigel

@ JonSeigel Me encantaría hacer eso, pero resultaría en un muro de código, así que estoy actualizando con un equivalente recortado

swasheck

¿Cómo puedo interpretar los resultados de estos DMV para ayudarme a evaluar nuestra estrategia de partición?

Respuestas: