Bölümleme stratejimizi değerlendirmeme yardımcı olması için bu DMV'lerin sonuçlarını nasıl yorumlayabilirim?

Sürüm: SQL Server 2008 R2 Enterprise Edtn. (10.50.4000)

Bölümleme stratejimizi değerlendirmek amacıyla, bu sorguları bölümlerdeki dizinlere karşı erişim yöntemlerini almak için yazdım (terimlerin en geniş anlamıyla, yığınları ortadan kaldırıyorum). Odaklanmayı bölümlenmiş tablolara daraltırken, bakmam gerektiğine inanıyorum range_scan_countve singleton_lookup_countkavramsallaştırmakta zorlanıyorum.

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 ;

İlgili çıktı (SO'nun tablo biçimlendirmesindeki boşluk göz önüne alındığında, bu, yukarıdaki sorgudan sırasıyla son iki sütunun olduğu ilk 9 sütunun bir örneğidir range_scan_countve singleton_lookup_countsırasıyla):

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

Birkaç farklı olasılık görüyorum ama bunun hakkında nasıl düşüneceğime dair bir yönelime ihtiyacım var (tabii ki bunu " mayıs " ta alıyorum çünkü "buna bağlı" olduğunu biliyorum, ama aynı zamanda kavramsal anlama da arıyorum):

1. Tüm bölümler için benzer değerler range_scan_count olabilir kabaca aynı sayıda tüm bölümleri tarayarak çünkü biz iyi bölüm ortadan kaldırılması almıyorsanız göstermektedir.
2. Aradaki tüm bölümler için değişken değerler singleton_lookup_count, önemli ölçüde daha düşük değerlerle birlikte range_scan_count , sık sık bölüm elemine işaret edebilir , çünkü aradığımızdan daha az tararız.
3. ?

Bunlar benim düşüncelerim. Birisi nasıl bu tabloları veya başka bir bilgi kümesi, hangi tabloları büyük olasılıkla dizinleri lehine bölümleme bırakarak fayda sağlayacak belirlemek için tartmak umuyordum.

DÜZENLE

İşte kırpılmış bir 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

Dizin kullanımına bakmak yerine, en yüksek mantıksal okuma miktarına sahip sorgularınızı bulmak için plan önbelleğine bakarım. Genellikle bölümleme ile uğraşırken, okumalara hâkim olan bir avuç sorgu buluyorum - sunucuların toplam okumalarının% 50-80'i gibi. Bölüm eleme işlemini başarıyla gerçekleştirip gerçekleştirmediklerini görmek için bu sorguları kontrol edin.

Eğer bölüm eliminasyonu yapmıyorlarsa, ancak (bölüm şemanıza göre) yapmaları gerektiğini düşünüyorsanız, bölüm eliminasyonu almak için sorgu yazarlarıyla birlikte çalışın.

Bölümleri ortadan kaldırmazlarsa ve (sorgunun yazılma şekli veya bölümün tasarlanma şekli nedeniyle) yapamazlarsa, zor sorular sormaya başlama zamanıdır.

En büyük mantıksal okuma sorgularının bölümlenmiş tablonuzla bir ilgisi yoksa, devam edin ve bunun yerine diğer sorgulara odaklanın.