¿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):

1. 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.
2. 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.
3. ?

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

En lugar de mirar la utilización del índice, miraría el caché del plan para encontrar sus consultas con la mayor cantidad de lecturas lógicas. Por lo general, cuando estoy lidiando con la partición, encuentro solo un puñado de consultas que dominan las lecturas, como el 50-80% de las lecturas de los servidores en general. Verifique esas consultas para ver si están eliminando correctamente la partición.

Si no están eliminando la partición, pero cree que deberían hacerlo (según su esquema de partición), entonces trabaje con los escritores de consultas para obtener la eliminación de la partición.

Si no están eliminando particiones, y no pueden (debido a la forma en que se escribe la consulta o la partición está diseñada), entonces es hora de comenzar a hacer preguntas difíciles.

Si las consultas de lectura lógica más grandes no tienen nada que ver con su tabla particionada, continúe y concéntrese en esas otras consultas.