Как я могу интерпретировать результаты этих 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. ?

Это мои мысли до сих пор. Я надеялся, что кто-то придумает, как я могу использовать эту или другую информацию, чтобы определить, какие таблицы, скорее всего, выиграют от отказа от разбиения в пользу индексов вообще.

РЕДАКТИРОВАТЬ

Вот подрезанный 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% операций чтения серверов в целом. Проверьте эти запросы, чтобы увидеть, успешно ли они удаляют разделы.

Если они не делают удаление разделов, но вы думаете, что они должны (в зависимости от вашей схемы разделов), тогда работайте с авторами запросов, чтобы получить удаление разделов.

Если они не удаляют разделы и не могут (из-за того, как написан запрос или разработан раздел), то пришло время задать сложные вопросы.

Если самые большие логические запросы на чтение не имеют ничего общего с вашей секционированной таблицей, то вместо этого перейдите к другим запросам.