Announcement

Collapse
No announcement yet.

Batchmove Komponente verschenkt Performance (z.B. 40%) bei Aktualisierung von Text-Feldern.

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Batchmove Komponente verschenkt Performance (z.B. 40%) bei Aktualisierung von Text-Feldern.

    Ich verwende die Batchmove-Komponente im Modus batAppendUpdate, um Datensätze in einer Zieltabelle zu aktualisieren. Diesen Vorgang lasse mehrmals hintereinander durchführen und beobachte dabei die Ausführung im SQL-Monitor. Hierbei habe ich festgestellt, dass Textfelder (allerdings nicht alle, abhängig von den Daten des aktuellen Satzes) wiederholt aktualisiert werden.

    Eine Systematik dafür, in welchen Fällen die entsprechenden Felder aktualisiert werden, konnte ich nicht ermitteln. Eine Auffälligkeiten gibt es aber doch:

    a) Wenn das Textfeld maximal gefüllt ist (also 25 Zeichen in einem ALPHA(25) – Feld) findet die wiederholte Aktualisierung in der Regel nicht statt.
    b) Die Anomalien sind haarsträubend, zwei Beispiele:
    - Textfeld komplett füllen, mehrfaches Update >> Wiederholung bleibt aus.
    Sukzessive ein Zeichen aus diesem Feld in Quelltabelle entfernen, Update >> Wiederholung bleibt aus.
    - Textfeld komplett füllen, mehrfaches Update >> Wiederholung bleibt aus.
    Sofort 20 Zeichen aus diesem Feld in Quelltabelle entfernen, Update >> Wiederholung findet statt !
    c) Memo-Felder werden ebenfalls unnötig oft aktualisiert.

    Das Verhalten wird durch den ODBC-Treiber und oder verschiedene Quell-/Zieldatenbanken nicht beeinflusst. Selbst wenn man z.B. Paradox-Tabellen miteinander abgleicht, werden die entsprechenden Aktualisierungen mehrfach ausgeführt. Dies erkennt man leicht, wenn man sich parallel eine Protokolltabelle mit den Ausgangsdaten erzeugen lässt.

    Durchführung:
    Zwei strukturgleiche Tabellen anlegen (mit Textfeldern) und diese mit einigen Demo-Daten füllen. Batchmove wiederholt aufrufen und die Ereignisse im SQL-Monitor beobachten.

    In meinem Fall entsteht durch die wiederholte Ausführung ein Performanceverlust von etwa 40%.
    Denn auch beim ersten Abgleich wird natürlich zu viel Unnötiges auf dem Server aktualisiert.
    Wer kann mir da helfen ???

  • #2
    Hallo,

    tritt dieser Effekt auch auf, wenn alle beteiligten Tabellen einen "guten" Primärschlüssel (INTEGER) haben

    Comment


    • #3
      in unserem Test hatten wir als Primärschlüssel in der Paradox-Quelltabelle ein Feld vom Typ NUMBER. Das Gegenstück im Falle von Access war vom Typ DOUBLE.

      Ich denke, dass entspricht einem INTEGER weitgehend, oder sollte ich sicherheitshalber nochmals andere Typen testen ?

      Besonders auffällig war eben auch, dass das Verhalten beim Abgleich von Text-Feldern nicht exakt reproduzierbar war. Es war nicht vorhersehbar, wann der Textvergleich zu einem Update-Statement führte und wann nicht. Dies war jeweils vom vorherigen Wert des Textfeldes abhängig

      Comment


      • #4
        Das Gegenstück für NUMBER ist nicht immer DOUBLE sondern INTEGER bzw. LONG INTEGER wenn man mit natürlichen Zahlen arbeitet. Und für Primärschlüssel ist INTEGER bzw. LONG INTEGER der geeignetere Datentyp als DOUBLE

        Comment

        Working...
        X