Como posso interpretar os resultados dessas DMVs para me ajudar a avaliar nossa estratégia de particionamento?

Versão: SQL Server 2008 R2 Enterprise Edtn. (10.50.4000)

Na tentativa de avaliar nossa estratégia de particionamento, escrevi essa consulta para obter os métodos de acesso aos índices nas partições (no sentido mais amplo do termo, embora eu esteja eliminando heaps). À medida que refiro meu foco às tabelas particionadas, acredito que preciso olhar range_scan_counte singleton_lookup_countestou tendo dificuldades para conceituar.

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 ;

Saída relevante (dada a lacuna na formatação de tabelas do SO, esta é uma amostra das 9 primeiras colunas da consulta acima, sendo as duas últimas colunas range_scan_counte 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 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝

Vejo algumas possibilidades diferentes, mas preciso de alguma orientação sobre como pensar sobre isso (é claro que estou falando disso em " maio " porque sei que "depende", mas também estou procurando compreensão conceitual):

1. Valores semelhantes para todas as partições de range_scan_count podem indicar que não estamos obtendo uma boa eliminação de partições porque estamos verificando todas as partições aproximadamente o mesmo número de vezes.
2. Valores variáveis ​​para todas as partições singleton_lookup_countacompanhados de valores significativamente menores para range_scan_count maio indicar boa eliminação frequente de partições, porque estamos verificando menos do que procuramos.
3. ?

Esses são os meus pensamentos até agora. Eu esperava que alguém pensasse em como eu poderia usar isso, ou outro conjunto de informações, para determinar quais tabelas provavelmente se beneficiariam com a exclusão do particionamento em favor dos índices.

EDITAR

Aqui está um 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

Em vez de examinar a utilização do índice, eu examinaria o cache do plano para encontrar suas consultas com as maiores quantidades de leituras lógicas. Normalmente, quando estou lidando com particionamento, encontro apenas algumas consultas que estão dominando as leituras - como 50-80% das leituras dos servidores em geral. Verifique essas consultas para ver se elas estão eliminando a partição com êxito.

Se eles não estiverem eliminando a partição, mas você acha que deveria (com base no seu esquema de partição), trabalhe com os gravadores de consulta para obter a eliminação da partição.

Se eles não estão eliminando partições e não podem (por causa da maneira como a consulta é gravada ou a partição é projetada), é hora de começar a fazer perguntas difíceis.

Se as maiores consultas de leitura lógica não tiverem nada a ver com sua tabela particionada, prossiga e concentre-se nessas outras consultas.