none
Unterschiedliche Abfrageergebnisse bei unterschiedlichem Kompatibilitätsgrad? RRS feed

  • Frage

  • Hallo zusammen,

    wir haben eine Software, welche zur Laufzeit SQL-Select-Statements generiert und diese an den SQL-Server schickt. Die Statements können durchaus kompliziert werden, mit jeder Menge (Outer)-Joins und etliche Tabellen beinhalten. Nun ist uns aufgefallen, dass gelegentlich falsche Ergebnisse zurückkommen. Die falschen Ergebnisse kommen allerdings nicht mehr, wenn wir den Kompatibilitätsgrad auf SQL Server 2000 zurückstellen. Wir arbeiten selber mit der Version 2008 R2.

    Nun ist guter Rat teuer. Wie geht man denn am besten an dieses Phänomen heran?

    Gruß, Karsten.

    Dienstag, 16. November 2010 15:49

Antworten

  • So, mittlerweile kann ich das Problem wohl auflösen:

    • Also, unser berechnetes Feld stützt sich bei der Berechnung auf die "vorhergehende Zeile" der angeforderten Daten (da ist so eine Art Gruppenwechsel dabei)
    • Es wird sehr wohl eine eigene Sortierung in unserem Report durchgeführt: Aber in dem Fall fehlte eine bestimmte wichtige Spalte in der Sortierung
    • Der SQL Server 2000 lieferte die Daten trotz allem richtig, aber eben der 2008er nicht mehr.
    • Der Fehler lag also eindeutig bei uns und ist nun durch die neue Arbeitsweise des 2008er Servers aufgetreten.

    Gruß, Karsten.

    • Als Antwort markiert Atlan Gonozal Donnerstag, 18. November 2010 13:02
    Donnerstag, 18. November 2010 12:40

Alle Antworten

  • Hallo Karsten,

    was konkret heisst "gelegentlich falsche Ergebnisse"? Kommen die falschen Datensätze, zuviele, zuwenige oder in der falschen Reihenfolge?

    Ohne ein etwas konkreteres Beispiel, bei dem es auftritt und ohne zu wissen, was/wie ihr die Daten selektiert, ist es schwer zu sagen, woran es liegen könnte.

    Zur Problemanalyse würde ich mir ein Statement, bei dem es auftritt vornehmen und es schrittweise immer weiter reduzieren (Du erwähntes etliche JOINs), bis es nicht mehr auftritt, dann hat man es zumindest schon mal etwas eingescränkt. 


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Mittwoch, 17. November 2010 06:45
  • Hallo Karsten,
    du könntest mit dem Profiler die Statements mitschneiden und diese dann auf Unterschiede der Ergebnisse überprüfen.

    Was sagt denn der Hersteller der Software dazu?

    Einen schönen Tag noch,
    Christoph


    Microsoft SQL Server MVP
    http://www.insidesql.org/blogs/cmu

    Mittwoch, 17. November 2010 06:47
    Beantworter
  • Ist das eine selbst geschriebene Software oder eine eingekaufte Software, die diese Statements generiert?

    Falls es eine eingekaufte ist, solltest Du dich mit dem Hersteller der Software in Verbindung setzen, bevor Du irgendetwas selber unternimmst. Vielleicht ist das Problem ja bereits bekannt und es existiert eine Lösung dafür. Ich würde vermeiden, etwas an irgendwelchen Einstellung zu ändern, ohne dies mit dem Hersteller abgesprochen zu haben.

    Falls es eine selbstgeschriebene ist, solltest Du den Profiler verwenden, um zu verifizieren, dass die Statements identisch sind in beiden Fällen identisch sind.  Falls es nicht umfangreich ist, könntest Du vielleicht mal eines dieser generierten Statements mit unterschiedlichem Ergebnis hier posten?


    -- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org
    Mittwoch, 17. November 2010 10:16
  • Hallo zusammen,

    erst mal vielen Dank für die Antworten. Also, die Software ist von uns selber, insofern werde ich jetzt die SQL-Statements analysieren. Was die gelegentlich unterschiedlichen Ergebnisse betrifft: Hier handelt es sich um ein Reporting, welches die Abfragergebnisse in einem Grid darstellt. Und da kommen je nach Filtereinstellungen unterschiedliche Ergebnisse heraus.

    Ein vereinfachtes Beispiel:

    • Ich kann sagen "selektiere die Summe der Buchungen von Konto 100 bis 200". Dann kommt beispielsweise für das Konto 150 ein Betrag von X heraus.
    • Nun sage ich "selektiere die Summe der Buchungen von Konto 100 bis 400". Und nun kommt für das Konto 150 auf einmal <>X heraus!

    Dies passiert nachvollziehbar nicht, wenn wir besagten Kompatibilitätsgrad auf SQL 2000 runter stellen. Offenbar wird dann das SQL-Statement anders ausgewertet.

    Gruß, Karsten.

    Mittwoch, 17. November 2010 16:06
  • Das klingt jetzt so, als ob ihr euch auf ein undokumentiertes Verhalten der Engine verlassen habt, welches sich zwischen den Versionen geändert hat. Falls möglich, kannst du das Statement mal hier posten?

    -- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org
    Donnerstag, 18. November 2010 07:34
  • Also, nach eingehender Analyse ist das Problem schwieriger als gedacht und der SQL Server nur mittelbar beteiligt.

    Das Abfrageergebnis, welches vom SQL Server angefordert wird, kann nämlich in unserem Reportingtool um weitere - berechnete - Felder ergänzt werden. Das ist praktisch eine Art Postprocessing. Und genau dort passiert wohl der Fehler. Die fehlerhafte Spalte ist ein berechnetes Feld, welches sich in irgendeiner Form auf die Sortierung der Datensätze verläßt. Und offenbar ist genau diese Sortierung eine andere, wenn man mit dem Kompatibilitätsgrad 2000 arbeitet. Der unmittelbare Fehler liegt also in dem berechneten Feld (der ist auch schon gelöst), die Frage bleibt offen, warum unter verschiedenen Kompatibilitäsgraden die Datenmengen unterschiedlich sortiert zurück kommen. Um das zu analysieren brauche ich allerdings einen Kollegen, der erst nächste Woche wieder da ist.

    PS: Dummerweise geht mein Profiler nicht mehr, seit wir von SQL 2008 auf SQL 2008 R2 aufgestiegen sind. Brauchts da auch neue Clienttools?

    Gruß, Karsten.

    Donnerstag, 18. November 2010 09:09
  • Hallo Karsten,

    wenn keine explizite Sortierung angegeben wurde, ist die Reihenfolge eh immer mehr Zufall, also präzise vorhersagbar. Warum sollte der SQL Server auch eine teure Sortierung vornehmen, wenn sie nicht explizt angefordert wird. Und je nach Ausführungsplan / Optimierung kann dann die Reihenfolge der Datensätze variieren.


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    • Als Antwort markiert Atlan Gonozal Donnerstag, 18. November 2010 09:32
    • Tag als Antwort aufgehoben Atlan Gonozal Donnerstag, 18. November 2010 09:32
    Donnerstag, 18. November 2010 09:23
  • Das wiederum klingt nach einem SELECT ... FROM View und im View ist ein ORDER BY. Da hat SQL Server 2000 die Sortierung von View "übernommen", während ab SQL Server 2005 dies nicht mehr zwingend der Fall war.

    Sollte dem so sein, such mal in der Knowledgebase. Da gibt es verschiedene Artikel dazu.


    -- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org
    Donnerstag, 18. November 2010 09:33
  • Hallo Karsten,

    wenn keine explizite Sortierung angegeben wurde, ist die Reihenfolge eh immer mehr Zufall, also präzise vorhersagbar. Warum sollte der SQL Server auch eine teure Sortierung vornehmen, wenn sie nicht explizt angefordert wird. Und je nach Ausführungsplan / Optimierung kann dann die Reihenfolge der Datensätze variieren.


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de


    Ja, da hast du sicher recht. Aber warum reagiert das System je nach Kompatibilitätsgrad nun anders? Es kommt sogar noch verrückter. Das Phänomen scheint von der gesamten abgerufenen Datenmenge noch abzuhängen. Der betreffende Report gestattet die Angabe eines Filters von-bis auf eines der Felder. Un ab einem bestimmten bis-Wert kommt der Fehler, vorher nicht. Verrückt.

    Aber wie gesagt, nächste Woche wird das näher untersucht, dann kann ich bestimmt berichten.

    Gruß, Karsten.

    Donnerstag, 18. November 2010 09:35
  • Hallo Karsten,

    eine wesentliche Änderung bei Sortierungen ist, dass eine ORDER BY Klausel in Sichten
    nicht berücksichtigt wird und auch bei Abfragen nur die äussere Sortierung berücksichtigt wird.
    Siehe u. a.:
    FIX: When you query through a view that uses the ORDER BY clause in SQL Server 2008,
    the result is still returned in random order

    Was das definierte Standardverhalten von ANSI SQL ist, da ORDER BY nunmal
    nur die Ausgabe beeinflusst. Und von SQL Server 2008 und später so umgesetzt wird,
    weil es eine verbesserte (schnellere) Abfrageausführung ermöglicht.
    (Im Kompatibilitätsgrad 2000 wird insofern teilweise mit angezogener Handbremse gearbeitet.)

    Eine langfristige Lösung sollte sich nicht auf ein früheres Verhalten stützen.
    Ihr (Du und Dein Kollege) solltet das Verhalten eurer Software so anpassen,
    dass dort explizit sortiert wird, wenn es gefordert wird.

    Gruß Elmar

    Donnerstag, 18. November 2010 09:38
  • Hallo Karsten,

    wenn keine explizite Sortierung angegeben wurde, ist die Reihenfolge eh immer mehr Zufall, also präzise vorhersagbar.


    Just for completeness...

    Du solltest dieses Statement korrigieren. Wer weiss, wer später mal darauf stösst... :-)


    -- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org
    Donnerstag, 18. November 2010 10:02
  • Hallo Karsten,

    wenn keine explizite Sortierung angegeben wurde, ist die Reihenfolge eh immer mehr Zufall, also präzise vorhersagbar.


    Just for completeness...

    Du solltest dieses Statement korrigieren. Wer weiss, wer später mal darauf stösst... :-)


    -- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org


    Hallo Frank,

    das berechnete Feld ist selbstverständlich korrigiert worden (es geht ja auch nur um die FIBU, nix wichtiges, gell... :-)).

    Die Ursachenforschung betreiben wir dann nächste Woche.

    Gruß, Karsten.

    Donnerstag, 18. November 2010 10:49
  • Hallo Karsten,

    eine wesentliche Änderung bei Sortierungen ist, dass eine ORDER BY Klausel in Sichten
    nicht berücksichtigt wird und auch bei Abfragen nur die äussere Sortierung berücksichtigt wird.
    Siehe u. a.:
    FIX: When you query through a view that uses the ORDER BY clause in SQL Server 2008,
    the result is still returned in random order

    Was das definierte Standardverhalten von ANSI SQL ist, da ORDER BY nunmal
    nur die Ausgabe beeinflusst. Und von SQL Server 2008 und später so umgesetzt wird,
    weil es eine verbesserte (schnellere) Abfrageausführung ermöglicht.
    (Im Kompatibilitätsgrad 2000 wird insofern teilweise mit angezogener Handbremse gearbeitet.)

    Eine langfristige Lösung sollte sich nicht auf ein früheres Verhalten stützen.
    Ihr (Du und Dein Kollege) solltet das Verhalten eurer Software so anpassen,
    dass dort explizit sortiert wird, wenn es gefordert wird.

    Gruß Elmar


    Hallo Elmar,

    dieser Link von Dir erklärt so einiges. Unser fehlerhaftes berechnetes Feld stützte sich nämlich auf 2 Spalten: Eine sortierte und eine unsortierte. Und genau hier liegt wohl der Hase im Pfeffer begraben. Wenn wir das unsortierte Feld mit sortieren, dann klappt alles. Da bleibt uns nicht anderes übrig, wie alle unsere so genannten Reportdefinitonen zu überarbeiten.

    Gruß, Karsten.

    Donnerstag, 18. November 2010 10:57
  • Hallo Karsten,

    wenn keine explizite Sortierung angegeben wurde, ist die Reihenfolge eh immer mehr Zufall, also präzise vorhersagbar.


    Just for completeness...

    Du solltest dieses Statement korrigieren. Wer weiss, wer später mal darauf stösst... :-)


    -- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org


    Hallo Frank,

    das berechnete Feld ist selbstverständlich korrigiert worden (es geht ja auch nur um die FIBU, nix wichtiges, gell... :-)).

    Die Ursachenforschung betreiben wir dann nächste Woche.

    Gruß, Karsten.

    Sorry für die Verwirrung!

    Der Kommentar war eigentlich an Olaf gerichtet.  :-)


    -- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org
    Donnerstag, 18. November 2010 11:55
  • So, mittlerweile kann ich das Problem wohl auflösen:

    • Also, unser berechnetes Feld stützt sich bei der Berechnung auf die "vorhergehende Zeile" der angeforderten Daten (da ist so eine Art Gruppenwechsel dabei)
    • Es wird sehr wohl eine eigene Sortierung in unserem Report durchgeführt: Aber in dem Fall fehlte eine bestimmte wichtige Spalte in der Sortierung
    • Der SQL Server 2000 lieferte die Daten trotz allem richtig, aber eben der 2008er nicht mehr.
    • Der Fehler lag also eindeutig bei uns und ist nun durch die neue Arbeitsweise des 2008er Servers aufgetreten.

    Gruß, Karsten.

    • Als Antwort markiert Atlan Gonozal Donnerstag, 18. November 2010 13:02
    Donnerstag, 18. November 2010 12:40