これらの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列のサンプルで、最後の2列はそれぞれ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 ║
╚════════╩═════════════════╩════╩═══╩═══╩═══╩═══╩════════╩══════════╝

いくつかの異なる可能性がありますが、これについて考える方法が必要です（もちろん、「依存する」ことを知っているので、「may」でこれを説明していますが、概念の理解も求めています）：

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％のように。これらのクエリをチェックして、パーティションの削除が正常に行われているかどうかを確認してください。

パーティションの削除を行っていないが、（パーティションスキームに基づいて）行うべきだと思う場合は、クエリライターと協力してパーティションの削除を取得します。

パーティションを削除せず、（クエリの作成方法やパーティションの設計方法のために）できない場合は、難しい質問をし始めましょう。

最大の論理読み取りクエリがパーティションテーブルと関係がない場合は、代わりに他のクエリに移動して焦点を合わせます。