Jak mogę zinterpretować wyniki tych DMV, aby pomóc mi ocenić naszą strategię partycjonowania?

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

Próbując ocenić naszą strategię partycjonowania, napisałem to zapytanie, aby uzyskać metody dostępu do indeksów na partycjach (w najszerszym tego słowa znaczeniu, chociaż eliminuję sterty). Jak ograniczyć moje skupienie na partycje tabel, wierzę, muszę patrzeć na range_scan_counta singleton_lookup_count, ale jestem posiadające czas twardy konceptualizacji.

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 ;

Odpowiednie wyjściowe (ze względu na różnice w formatowaniu So tablic, to próbki z pierwszych 9 kolumn z zapytania powyżej dwóch ostatnich kolumn jest range_scan_counti singleton_lookup_count, odpowiednio):

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

Widzę kilka różnych możliwości, ale potrzebuję wskazówek, w jaki sposób o tym myśleć (oczywiście robię to w „ może ”, ponieważ wiem, że „to zależy”, ale szukam również zrozumienia pojęciowego):

1. Podobne wartości dla wszystkich partycji range_scan_count mogą wskazywać, że nie uzyskujemy dobrej eliminacji partycji, ponieważ skanujemy wszystkie partycje mniej więcej tyle samo razy.
2. Różne wartości dla wszystkich partycji singleton_lookup_countwraz ze znacznie niższymi wartościami dla range_scan_count mogą wskazywać na dobrą częstą eliminację partycji, ponieważ skanujemy mniej niż szukamy.
3. ?

To są moje dotychczasowe myśli. Miałem nadzieję, że ktoś zastanowi się, w jaki sposób mógłbym użyć tego lub innego zestawu informacji, aby ustalić, które tabele najprawdopodobniej skorzystałyby na rezygnacji z partycjonowania na rzecz indeksów.

EDYTOWAĆ

Oto przycięty 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

Zamiast patrzeć na wykorzystanie indeksu, spojrzałbym na pamięć podręczną planu, aby znaleźć twoje zapytania z największą ilością logicznych odczytów. Zwykle, gdy mam do czynienia z partycjonowaniem, znajduję tylko garść zapytań, które dominują odczyty - na przykład 50-80% odczytów serwerów. Sprawdź te zapytania, aby sprawdzić, czy skutecznie eliminują partycje.

Jeśli nie przeprowadzają eliminacji partycji, ale uważasz, że powinni (na podstawie schematu partycji), współpracuj z programami do tworzenia zapytań, aby uzyskać eliminację partycji.

Jeśli nie eliminują partycji i nie mogą (ze względu na sposób napisania zapytania lub zaprojektowania partycji), czas zacząć zadawać trudne pytania.

Jeśli największe logiczne zapytania do odczytu nie mają nic wspólnego z twoją partycjonowaną tabelą, przejdź dalej i skup się na tych innych zapytaniach.