none
QUERY HINT MERGE UNION / CONCAT UNION / HASH UNION does not work with union all - cannot force same MERGE UNION as query opimizer produces the plan on another system RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    I am facing an issue with an execution plan on two systems with almost identical data (backup restore a couple of days ago and since then the same data modifications on both) and some hardware differences (24 Cores bs 32 Cores, 200 GB SQL Memory vs 500 GB SQL Memory).

    SQL Server 2008 R2 (10.50.4000) Enterprise Edition

    A Query produces different execution plans - one with CONCAT UNION and one with MERGE UNION (the query is a UNION ALL of for queries) - which results in 2.5 times the execution time for the merge concat

    I now tried to force the same execution plan by specifying an query hint.

    According to http://msdn.microsoft.com/en-us/library/ms181714(v=sql.105).aspx I can force a union (HASH CONCAT MERGE) by query hint.

    For example

    select top 10 * from sys.tables
    union all
    select top 10 * from sys.tables
    option (merge union)

    which does not change the execution plan - this simply does not work. 

    AS far as I have tested it only works when the query does not include the "ALL" keyword. But my Query aktually includes 3 queries and uses both times union all. I cannot force the merge union there - but my PROD system generates this plan somehow.

    How does it do this? and how can I force a MERGE / HASH or CONCAT "Union ALL" by query hint?

    Thanks for your help

    Best Regards

    Hannes

    http://www.hmayer.net/



    Dienstag, 9. April 2013 14:28
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Hannes,

    da wir hier in einem deutschsprachigen Forum sind, die Antwort auf deutsch.

    Grundsätzlich gilt für alle Abfragehinweise, dass sie Empfehlungen (und keine Befehle sind).
    Dem Query Optimizer steht letztendlich frei, ob er sie beachtet oder verwirft.

    Der Concatentation Operator wiederum steht für ein UNION ALL.
    Und sollte die wenigste Last produzieren, da er sehr einfach Ergebnisse zusammenfasst,
    in dem er beginnend mit dem ersten alle weiteren Folgeergebnisse ausgibt.

    Dass bei Dir in einem Falle ein MERGE UNION verwendet wird, ist insofern etwas überraschend.

    Die Erklärung vermute ich bei den nicht bekannten Teilen der realen Abfrage.

    Mehr zum realen Abfrageplan wäre insofern hilfreich.

    Werden in den (Teil-)Abfrage parallele Pläne verwendet?
    Gibt es größere Unterschiede in den Teilkosten der Pläne?
    Werden bei den Teilplänen unterschiedliche Abfrageoperationen verwendet?

    Zum Angleichen der beiden Systeme:
    Sind die Statistiken für die beteiligten Tabellen aktuell?
    Bei ungünstig verteilten Daten kann ein UPDATE STATISTICS mit FULLSCAN / SAMPLE
    bessere Ergebnisse liefern als das Standardverhalten.
    Auch solltest Du schauen ob unterschiedliche hohe Fragmentierungen vorliegen.

    Gruß Elmar

    Dienstag, 9. April 2013 16:48
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Ja, da war leider im Browser die falsche Sprache eingestellt. Ich hab den Thread jetzt im EN Forum erstellt.

    Die Statistiken sind aktuell, bzw. haben sich die Daten die ich in der Query abfrage seit dem Backup Restore nicht verändert.

    "Werden in den (Teil-)Abfrage parallele Pläne verwendet": Ja

    "Gibt es größere Unterschiede in den Teilkosten der Pläne?": Kann ich nicht beurteilen da die Struktur komplett anders wird.

    "Werden bei den Teilplänen unterschiedliche Abfrageoperationen verwendet?": Ja, komplett andere Planstruktur.

    Leider tu ich mir sehr schwer hier die 15.000 Zeilen des XML Plans zu pasten - das mag die Browser Sitzung nicht.

    Und es könnte auch mit dem Thread zusammen hängen - da wir noch kein Trace Flag verwenden, es aber um diese System geht (http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/d3a7cfdd-24e8-4d4b-8390-f9faee3c5355).

    Gibt es jetzt einen Hint oder Schrweibweise wie ich den UNION Operator erzwingen kann. Immerhin macht es der Optimizer ja bei einem normalen Union wenn ich den Hint angebe, aber bei einem UNION ALL ignoriert er es! Sowas wie ich ja in einem Join auch INNER HASH JOIN schrieben kann und er das dann machen muss - es keine Empfehlung mehr ist sondern zwang. 

    Damit wär mir schon geholfen.

    Danke

    Hannes


    http://www.hmayer.net/

    Mittwoch, 10. April 2013 09:15
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Hans,

    Wie schon geschrieben:
    Zwänge gibt es nicht, wenn im Optimierer ein Pfad nicht implementiert ist, so wird er den Hinweis nicht beachten.
    (Der JOIN Vergleich passt insofern nicht, da es die Optionen dort generell gibt)

    Da die Verwendung mindestens ungewöhnlich - wie auch MVP Kollege Tibor Karaszi meint -
    und die bessere Performance sogar unlogisch ist, dürfte der "Verusacher" tiefer im Plan begraben liegen -
    und nur mit dem Hinweis alleine wird es nicht anders werden.

    Lasse mal die UNIONs weg und führe die Teilabfragen isoliert aus.
    Da parallele Pläne vorkommen, solltest Du mal mit MAXDOP Einfluss nehmen.

    Was die großen Plan angeht: Anstatt hier zu posten, könntest Du den ihn als sqlplan speichern
    und auf Skydrive oder anderem Hoster ablegen.
    Die Verfügbarkeit könnte auch im US-Forum für mehr Rückmeldung sorgen.

    Was das Trace Flag angeht:
    Das lässt sich mit dem Informationsstand nicht wirklich beurteilen - ich würde es aber bezweifeln.

    Gruß Elmar


    Mittwoch, 10. April 2013 11:35
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,

    bist Du hier inzwischen weitergekommen?

    Gruss,
    Raul

    Raul Talmaciu, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Montag, 15. April 2013 06:43
    |