Bagaimana saya bisa menginterpretasikan hasil DMV ini untuk membantu saya mengevaluasi strategi partisi kami?

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

Dalam upaya mengevaluasi strategi pemartisian kami, saya menulis kueri ini untuk mendapatkan metode akses terhadap indeks pada partisi (dalam pengertian istilah yang paling luas, meskipun saya menghilangkan banyak). Ketika saya mempersempit fokus saya ke tabel dipartisi, saya percaya saya perlu melihat range_scan_countdan singleton_lookup_counttetapi mengalami kesulitan konseptualisasi.

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 yang relevan (diberi celah dalam pemformatan tabel SO, ini adalah sampel dari 9 kolom pertama dari kueri di atas dengan dua kolom terakhir menjadi range_scan_countdan singleton_lookup_count, masing-masing):

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

Saya melihat beberapa kemungkinan yang berbeda tetapi saya perlu arahan tentang cara berpikir tentang ini (tentu saja saya menuliskan ini dalam " mungkin " karena saya tahu bahwa "itu tergantung", tetapi saya juga mencari pemahaman konseptual):

1. Nilai yang sama untuk semua partisi range_scan_count dapat menunjukkan bahwa kami tidak mendapatkan penghapusan partisi yang baik karena kami memindai semua partisi dengan jumlah yang sama.
2. Memvariasikan nilai untuk semua partisi singleton_lookup_countdisertai dengan nilai yang jauh lebih rendah untuk range_scan_count dapat mengindikasikan penghapusan partisi yang sering karena kami memindai kurang dari yang kami cari.
3. ?

Itulah pikiranku sejauh ini. Saya berharap ada seseorang yang mempertimbangkan bagaimana saya bisa menggunakan ini, atau serangkaian informasi lain, untuk menentukan tabel mana yang paling mungkin mendapat manfaat dari menjatuhkan partisi yang mendukung indeks sama sekali.

EDIT

Inilah DDL yang terpotong:

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

Daripada melihat pemanfaatan indeks, saya akan melihat cache rencana untuk menemukan pertanyaan Anda dengan jumlah pembacaan logis tertinggi. Biasanya ketika saya sedang berurusan dengan partisi, saya menemukan hanya beberapa pertanyaan yang mendominasi dibaca - seperti 50-80% dari server membaca secara keseluruhan. Periksa kueri itu untuk melihat apakah mereka berhasil melakukan penghapusan partisi.

Jika mereka tidak melakukan penghapusan partisi, tetapi Anda pikir mereka harus melakukannya (berdasarkan skema partisi Anda), kemudian bekerja dengan penulis kueri untuk mendapatkan penghapusan partisi.

Jika mereka tidak menghilangkan partisi, dan mereka tidak bisa (karena cara kueri ditulis atau partisi dirancang), maka sekarang saatnya untuk mulai mengajukan pertanyaan sulit.

Jika kueri baca logis terbesar tidak ada hubungannya dengan tabel dipartisi Anda, maka pindah dan fokuslah pada kueri lainnya.