Comment puis-je interpréter les résultats de ces DMV pour m'aider à évaluer notre stratégie de partitionnement?

Version: SQL Server 2008 R2 Enterprise Edtn. (10.50.4000)

Dans le but d'évaluer notre stratégie de partitionnement, j'ai écrit cette requête pour obtenir les méthodes d'accès aux index sur les partitions (au sens le plus large du terme, bien que j'élimine les tas). Alors que je me concentre sur les tables partitionnées, je pense que je dois regarder range_scan_countet singleton_lookup_countmais j'ai du mal à conceptualiser.

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 ;

Sortie pertinente (compte tenu de l'écart dans le formatage des tables par SO, il s'agit d'un échantillon des 9 premières colonnes de la requête ci-dessus, les deux dernières colonnes étant range_scan_countet singleton_lookup_count, respectivement):

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

Je vois quelques possibilités différentes mais j'ai besoin d'une direction sur la façon de penser à cela (bien sûr, je présente cela dans " peut " parce que je sais que "cela dépend", mais je recherche également la compréhension conceptuelle):

1. Des valeurs similaires pour toutes les partitions de range_scan_count peuvent indiquer que nous n'obtenons pas une bonne élimination des partitions car nous analysons toutes les partitions à peu près le même nombre de fois.
2. Des valeurs variables pour toutes les partitions singleton_lookup_countaccompagnées de valeurs significativement plus faibles pour range_scan_count peuvent indiquer une bonne élimination fréquente des partitions car nous analysons moins que ce que nous recherchons.
3. ?

Telles sont mes pensées jusqu'à présent. J'espérais que quelqu'un réfléchisse à la façon dont je pourrais utiliser cela, ou un autre ensemble d'informations, pour déterminer quelles tables bénéficieraient le plus probablement de l'abandon du partitionnement au profit des index.

ÉDITER

Voici un DDL tronqué:

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

Plutôt que de regarder l'utilisation de l'index, je regarderais le cache du plan pour trouver vos requêtes avec le plus grand nombre de lectures logiques. Habituellement, lorsque je traite du partitionnement, je ne trouve qu'une poignée de requêtes qui dominent les lectures - comme 50 à 80% des lectures des serveurs dans l'ensemble. Vérifiez ces requêtes pour voir si elles réussissent à éliminer la partition.

S'ils ne font pas d'élimination de partition, mais que vous pensez qu'ils devraient (en fonction de votre schéma de partition), alors travaillez avec les rédacteurs de requêtes pour obtenir l'élimination de partition.

S'ils n'éliminent pas les partitions et qu'ils ne le peuvent pas (en raison de la façon dont la requête est écrite ou de la partition est conçue), alors il est temps de commencer à poser des questions difficiles.

Si les plus grandes requêtes de lecture logique n'ont rien à voir avec votre table partitionnée, passez à la place et concentrez-vous sur ces autres requêtes.