Zwei Server, unterschiedliche Ausführungspläne. Unterschied in der Laufzeit um mehrere Größenordnungen

Zwei Server, Entwicklung und Live. Der Live-Server ist eine Amazon RDS SQL Server-Webinstanz. Beide Server haben identisches Schema und identische Daten. Es gibt einen guten räumlichen Index für die Geometriespalte. Auf meinem Entwicklungsserver wird die Abfrage in <30 Millisekunden ausgeführt. Auf dem Live-Server dauert die Abfrage> 20 Minuten.

Die Prüfung der Ausführungspläne zeigt, dass sie sich drastisch unterscheiden. Zum einen ist die Abfrage in meiner Entwicklungsumgebung parallelisiert, auf dem Live-Server jedoch nicht.

Ich habe die Indizes neu erstellt und die Statistiken neu generiert.
Ich kann die massive Diskrepanz nicht erklären.
Der DOP der Server ist der gleiche.
Die CPU des Live-Servers wird während der Ausführung der Abfrage zu 100% gehämmert.

Ich würde mich über Einblicke in die Ursache oder darüber freuen, wie das Problem am besten diagnostiziert werden kann.

DECLARE @geoBoundary geometry;
SET @geoBoundary = geometry::STGeomFromText('POLYGON((407439.5 108792.25, 408022.5 108792.25, 408022.5 108575.75, 407439.5 108575.75, 407439.5 108792.25))', '0');

SELECT
     ogr_geometry.ToString() AS strGeometry
    ,ogr_geometry
FROM inspire as geo
WHERE geo.ogr_fid IN
(
    SELECT
        geo.ogr_fid
    FROM .inspire as geo
    WHERE
    (
        (@geoBoundary.STContains(geo.ogr_geometry) = 1)
    )
    UNION
    SELECT
        geo.ogr_fid
    FROM .inspire as geo
    WHERE
    (
        (@geoBoundary.STOverlaps(geo.ogr_geometry) = 1)
    )
)

Die cost threshold for parallelismauf beiden Servern ist 5 (die Standardeinstellung).
Die Entwicklungsinstanz hat 4 physische Kerne, 8 logische; Die Live-Instanz verfügt über 8 virtuelle Kerne.
max server memory ist bei beiden gleich.
Entwicklungsinstanz ist SQL Server 12.0.4100.1; Live ist SQL Server Web 12.0.2100.60
Es gibt große Unterschiede zwischen tatsächlichen und erwarteten Zeilen. Dies blieb jedoch nach dem Wiederaufbau der Statistik bestehen.
Ich habe den Plan-Cache geleert. Es wird immer der gleiche Plan erstellt.
Ausführungspläne können hier heruntergeladen werden .

— James B.
quelle

Zwei Vermutungen: 1. Unterschiedliche SQL Server-Version oder Kompatibilitätsstufe? Mit dem neuen Kardinalitätsschätzer passieren solche Dinge. Auch nur das Ändern der Kompatibilitätsstufe. 2. Parameter-Sniffing. Aktivieren Sie "Langsam in der Anwendung, schnell in SSMS?" sommarskog.se/query-plan-mysteries.html

— Jaime

Siehe auch Mehrere Pläne für eine "identische" Abfrage und Verschiedene Pläne für "identische" Server .

— Aaron Bertrand

Während die Web Edition maximal 4 Kerne unterstützt, scheint Ihr Server auf 1 beschränkt zu sein. Haben Sie dies überprüft EXEC sys.sp_configure N'max degree';? Möglicherweise haben Sie keinen Zugriff darauf, aber Sie sollten auch das Kleingedruckte in Ihrem Vertrag überprüfen. Amazon beschränkt Sie möglicherweise zu Recht auf einen Kern, basierend auf Ihrer Serviceebene. Alles in allem sollte es keinen Unterschied zwischen Sekunden und 20 Minuten geben, es sei denn, es sind andere Dinge im Gange (Blockieren, übermäßige Wartezeiten für externe Ressourcen usw.).

— Aaron Bertrand

Vergleich der Details aus den beiden bereitgestellten Ausführungsplänen:

Der langsame Plan wurde in Build 11.0.2100.60 - SQL Server 2012 RTM kompiliert
Der schnelle Plan wurde in Build 12.0.4100.1 - SQL Server 2014 SP1 kompiliert
Slow Plan verwendet den Kardinalitätsschätzer der Version 70
Fast Plan verwendet den Kardinalitätsschätzer der Version 120
Slow Plan hat den verfügbaren DOP auf 2 geschätzt (die Hälfte der sichtbaren CPUs).
Fast Plan hat den verfügbaren DOP auf 4 geschätzt (die Hälfte der sichtbaren CPUs).
Die geschätzte verfügbare Speicherzuweisung unterscheidet sich ebenfalls zwischen den beiden
Die beim Kompilieren verwendeten Parameterwerte sind identisch

Bei so vielen grundlegenden Software- und Hardwareunterschieden ist es nicht wirklich überraschend, dass die Pläne unterschiedlich sind.

Im Idealfall sollten Entwicklungs- und Testumgebungen so genau wie möglich zur Produktion passen. Sie sollten sich auf jeden Fall auf derselben Version von SQL Server befinden (und beachten Sie, dass die Installation 2012 noch bei RTM ist, zwei vollständige Service Packs und sieben weitere kumulative Updates hinter dem aktuellen Stand.

Ohne eine Nur-Statistik-Kopie des an der Abfrage beteiligten Schemas ist es schwierig zu wissen, was zur Verbesserung des aktuellen Abfrageplans 2012 vorgeschlagen werden kann. Wenn Sie mit Hinweisen vertraut sind, können Sie Folgendes hinzufügen:

OPTION (LOOP JOIN, HASH JOIN, CONCAT UNION, QUERYTRACEON 8649);

am Ende der Abfrage, um den Optimierer in die allgemeine Richtung des besseren Plans zu ermutigen. Der letzte Teil dieser Hinweissammlung (Setzen des Ablaufverfolgungsflags 8649 für die Abfrage) ist nicht dokumentiert und wird für die Produktion nicht unterstützt.

Diese Hinweise können erfolgreich sein oder auch nicht, da das zugrunde liegende Problem die ungenaue Kardinalitätsschätzung ist, die vom Kardinalitätsschätzer der Stufe 70 bereitgestellt wird. Das Umschreiben von Abfragen oder das Indizieren von Änderungen ist möglicherweise ebenfalls erfolgreich, aber es ist wirklich nicht praktisch, dies von hier aus zu erraten.

Verwandte Lektüre:

Erzwingen eines parallelen Ausführungsplans
Unterschiedliche Pläne für UAT und PROD
Mehrere Pläne für eine "identische" Abfrage
Unterschiedliche Pläne für "identische" Server

— Paul White 9
quelle