Come posso interpretare i risultati di questi DMV per aiutarmi a valutare la nostra strategia di partizionamento?

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

Nel tentativo di valutare la nostra strategia di partizionamento, ho scritto questa query per ottenere i metodi di accesso rispetto agli indici sulle partizioni (nel senso più ampio del termine, anche se sto eliminando i cumuli). Mentre restringo la mia attenzione alle tabelle partizionate, credo di aver bisogno di guardare range_scan_counte singleton_lookup_countma ho difficoltà a concettualizzare.

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 ;

Output pertinente (dato il divario nella formattazione delle tabelle di SO, questo è un esempio delle prime 9 colonne della query sopra con le ultime due colonne che sono range_scan_counte singleton_lookup_count, rispettivamente):

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

Vedo alcune possibilità diverse, ma ho bisogno di alcune indicazioni su come pensare a questo (ovviamente lo dirò in " maggio " perché so che "dipende", ma sto anche cercando una comprensione concettuale):

1. Valori simili per tutte le partizioni range_scan_count possono indicare che non stiamo ottenendo una buona eliminazione delle partizioni perché stiamo analizzando tutte le partizioni all'incirca lo stesso numero di volte.
2. Valori variabili per tutte le partizioni singleton_lookup_countaccompagnati da valori significativamente più bassi per range_scan_count possono indicare una buona eliminazione frequente delle partizioni perché stiamo scansionando meno di quanto stiamo cercando.
3. ?

Questi sono i miei pensieri finora. Speravo di avere qualcuno che pesasse su come avrei potuto usare questo, o un'altra serie di informazioni, per determinare quali tabelle avrebbero probabilmente beneficiato della caduta del partizionamento a favore degli indici del tutto.

MODIFICARE

Ecco un DDL ritagliato:

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

Piuttosto che guardare l'utilizzo dell'indice, guarderei la cache del piano per trovare le tue query con il maggior numero di letture logiche. Di solito, quando ho a che fare con il partizionamento, trovo solo una manciata di query che dominano le letture, come nel complesso il 50-80% delle letture dei server. Controlla quelle query per vedere se stanno eseguendo correttamente l'eliminazione della partizione.

Se non stanno eseguendo l'eliminazione della partizione, ma pensi che dovrebbero (in base al tuo schema di partizione), quindi lavora con i writer di query per ottenere l'eliminazione della partizione.

Se non stanno eliminando le partizioni e non possono farlo (a causa del modo in cui la query viene scritta o la partizione è progettata), allora è il momento di iniziare a porre domande difficili.

Se le più grandi query di lettura logica non hanno nulla a che fare con la tua tabella partizionata, passa invece a concentrarti su quelle altre query.