Як я можу інтерпретувати результати цих DMV, щоб допомогти мені оцінити нашу стратегію розподілу?

Версія: SQL Server 2008 R2 Enterprise Edtn. (10.50.4000)

Намагаючись оцінити нашу стратегію розділення, я написав цей запит, щоб отримати методи доступу проти індексів на розділах (в широкому сенсі цього терміна, хоча я усуваю купи). Як я звузити фокус секціонованих таблиць, я вважаю , що потрібно дивитися на range_scan_countі , singleton_lookup_countале я насилу концептуалізації.

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 ;

Відповідний вихід (з огляду на розрив при форматуванні SO про таблиці, це зразок з перших 9 стовпців із запиту вище останні двох стовпців бути range_scan_countі singleton_lookup_count, відповідно):

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

Я бачу декілька різних можливостей, але мені потрібен певний напрямок, як думати про це (звичайно, я це розумію в " може ", тому що я знаю, що "це залежить", але я також шукаю концептуальне розуміння):

1. Подібні значення для всіх розділів range_scan_count може вказувати на те, що ми не отримуємо гарної елімінації розділів, оскільки ми скануємо всі розділи приблизно в однаковій кількості разів.
2. Варіативні значення для всіх розділів, що singleton_lookup_countсупроводжуються значно нижчими значеннями для, range_scan_count може свідчити про гарне часте усунення розділів, оскільки ми скануємо менше, ніж ми прагнемо.
3. ?

Це мої думки поки що. Я сподівався на те, щоб хтось зважився на те, як я можу використовувати цю чи інший набір інформації, щоб визначити, які таблиці, швидше за все, виграють від відміни розділів на користь індексів.

EDIT

Ось відрізаний DDL:

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

Замість того, щоб дивитись на використання індексу, я би роздивився кеш плану, щоб знайти ваші запити з найбільшою кількістю логічних читань. Зазвичай, коли я маю справу з розділенням, я знаходжу лише декілька запитів, які є домінуючими для читання - наприклад, 50-80% прочитаних серверів в цілому. Перевірте ці запити, щоб побачити, чи успішно вони роблять усунення розділів.

Якщо вони не роблять усунення розділів, але ви думаєте, що вони повинні (на основі вашої схеми розділів), тоді працюйте з авторами запитів, щоб отримати усунення розділів.

Якщо вони не усувають розділи, а вони не можуть (через те, як запит написаний або розроблений розділ), то саме час почати задавати складні питання.

Якщо найбільші запити логічного читання не мають нічого спільного з вашою розділеною таблицею, тоді замість цього перейдіть та зосередьтеся на цих інших запитах.