Ist es möglich, das Optimierungsprogramm zu zwingen, irrelevante Tabellen in dieser partitionierten Ansicht zu entfernen?

Ich teste verschiedene Architekturen für große Tabellen und ein Vorschlag, den ich gesehen habe, ist die Verwendung einer partitionierten Ansicht, bei der eine große Tabelle in eine Reihe kleinerer, "partitionierter" Tabellen aufgeteilt wird.

1 , 2 , 3 , 4

Beim Testen dieses Ansatzes habe ich etwas entdeckt, das für mich keinen Sinn ergibt. Wenn ich in der Faktensicht nach "Partitionierungsspalte" filtere, sucht der Optimierer nur in den relevanten Tabellen. Wenn ich in der Dimensionstabelle nach dieser Spalte filtere, entfernt das Optimierungsprogramm darüber hinaus unnötige Tabellen.

Wenn ich jedoch nach einem anderen Aspekt der Dimension filtere, sucht der Optimierer nach dem PK / CI jeder Basistabelle.

Hier sind die fraglichen Fragen:

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where o.ObservationDateKey >= 20000101
    and o.ObservationDateKey <= 20051231
group by od.[Year];

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where od.DateKey >= 20000101
    and od.DateKey <= 20051231
group by od.[Year];

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where od.[Year] >= 2000 and od.[Year] < 2006
group by od.[Year];

Hier ist ein Link zur SQL Sentry Plan Explorer-Sitzung.

Ich arbeite daran, die größere Tabelle tatsächlich zu partitionieren, um festzustellen, ob die Partitionseliminierung auf ähnliche Weise reagiert.

Für die (einfache) Abfrage, die nach einem Aspekt der Dimension filtert, wird die Partition entfernt.

In der Zwischenzeit ist hier eine Nur-Statistiken-Kopie der Datenbank:

https://gist.github.com/swasheck/9a22bf8a580995d3b2aa

Der "alte" Kardinalitätsschätzer bekommt einen günstigeren Plan, aber das liegt an den niedrigeren Kardinalitätsschätzungen für jeden der (unnötigen) Index-Suchvorgänge.

Ich möchte wissen, ob es eine Möglichkeit gibt, das Optimierungsprogramm dazu zu bringen, die Schlüsselspalte beim Filtern nach einem anderen Aspekt der Dimension zu verwenden, damit Suchvorgänge für irrelevante Tabellen vermieden werden.

SQL Server Version:

Microsoft SQL Server 2014 - 12.0.2000.8 (X64) 
    Feb 20 2014 20:04:26 
    Copyright (c) Microsoft Corporation
    Developer Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)

Aktivieren Sie das Trace-Flag 4199.

Ich musste auch folgendes ausstellen:

UPDATE STATISTICS dbo.ObservationDates 
WITH ROWCOUNT = 73049;

um die unten gezeigten Pläne zu erhalten. Statistiken für diese Tabelle fehlten im Upload. Die Zahl 73.049 stammt aus den Informationen zur Tabellenkardinalität im Plan-Explorer-Anhang. Ich habe SQL Server 2014 SP1 CU4 (Build 12.0.4436) mit zwei logischen Prozessoren, maximalem Speicher auf 2048 MB und keinen Ablaufverfolgungsflags außer 4199 verwendet.

Sie sollten dann einen Ausführungsplan erhalten, der die dynamische Eliminierung von Partitionen beinhaltet:

select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
where 
    od.[Year] >= 2000 and od.[Year] < 2006
group by 
    od.[Year]
option (querytraceon 4199);

Planfragment:

Dies könnte schlechter aussehen, aber die Filter sind alle Start-up - Filter. Ein Beispiel-Prädikat ist:

Pro Iteration der Schleife wird das Start-Prädikat getestet, und nur wenn es true zurückgibt, wird der darunter liegende Clustered-Index-Suchlauf ausgeführt. Daher dynamische Partitionsbeseitigung.

Dies ist möglicherweise nicht ganz so effizient wie die statische Beseitigung, insbesondere wenn der Plan parallel ist.

Unter Umständen müssen Sie Hinweise , wie versuchen MAXDOP 1, FAST 1oder FORCESEEKauf der Ansicht , den gleichen Plan zu erhalten. Optimierer-Kalkulationsoptionen mit partitionierten Ansichten (wie partitionierten Tabellen) können schwierig sein.

Der Punkt ist, dass Sie einen Plan benötigen, der Startfilter enthält, um eine dynamische Partitionsbeseitigung mit partitionierten Ansichten zu erreichen.

Abfragen mit eingebetteten USE PLANHinweisen: (über gist.github.com):

• Serienplan
• Paralleler Plan

Meine Beobachtung war immer, dass Sie den Wert (oder Wertebereich) für die Partitionsspalte explizit in der Abfrage angeben müssen, um "Tabelleneliminierung" in einer partitionierten Ansicht zu erhalten. Dies basiert auf Erfahrungen mit partitionierten Ansichten in der Produktion von SQL Server 2000 bis SQL Server 2014.

In SQL Server gibt es kein Konzept für einen Schleifenverknüpfungsoperator, bei dem das Modul die Suche dynamisch direkt auf die richtige Tabelle auf der Innenseite der Schleife ausrichten kann, basierend auf dem Wert der Zeile auf der Außenseite der Schleife. Wie Pauls Antwort erklärt , gibt es jedoch die Möglichkeit, einen Plan mit Startfiltern zu erstellen, um irrelevante Tabellen auf der Innenseite der Schleife in konstanter Zeit dynamisch zu überspringen (im Gegensatz zur logarithmischen Ausführung der Suche).

Beachten Sie, dass für partitionierte Tabellen diese Art der Suche (für eine bestimmte Partition) unterstützt wird.

Wenn Sie nur partitionierte Ansichten verwenden möchten, können Sie Ihre Abfrage auch in mehrere Abfragen aufteilen, z.

-- Gather than the min/max values for the partition column
DECLARE @minDateKey INT,
        @maxDateKey INT
SELECT @minDateKey = MIN(DateKey),
        @maxDateKey = MAX(DateKey)
FROM dbo.ObservationDates od
WHERE od.[Year] >= 2000 and od.[Year] < 2006

-- Since I have a stats-only copy of the database, simulate having run the query above
-- (You can comment this out since you have the actual data.)
SELECT @minDateKey = 20000101, @maxDateKey = 20051231

-- Adjust the query to use the min/max values of the partition column
-- rather than filtering on a different column in the dimension table
select 
    od.[Year], 
    AvgValue = avg(ObservationValue)
from dbo.v_Observation o 
join dbo.ObservationDates od
    on o.ObservationDateKey = od.DateKey
WHERE od.DateKey >= @minDateKey AND od.DateKey <= @maxDateKey
group by od.[Year]
-- Must use OPTION RECOMPILE; otherwise the plan will touch all tables because it
-- must do so in order to be valid for all values of the parameters!
OPTION (RECOMPILE)

Dies ergibt den folgenden Plan. Es gibt jetzt eine zusätzliche Abfrage, die auf die Dimensionstabelle trifft, aber die Abfrage über die (vermutlich viel größere) Faktentabelle ist optimiert.