CachedUpdates - Performance Einbußen

[Tobias Frost]

Hi !

Bei der Aktualisierung von ca 2600 Datensätzen einer Tabelle benutze ich den CachedUpdates.Modus des TTable-Objects, um die Änderungen im Fehlerfall verwerfen zu können. Das Problem ist, daß das Durchlaufen der Datensätze recht zügig beginnt, dann aber immer langsamer wird. Unzumutbar. Es scheint, als würde die BDE für jede neue Änderung Speicher anfordern, was, je mehr Änderungen durchgeführt werden, immer mehr Zeit erfordert. Ich habe die Tabelle lokal auf meinem PC, der sehr großzügig mit RAM ausgerüstet ist.

Gib es eine Funktion, über man die Cache-Größe von vorneherein beeinflussen kann ? Oder liegt das Problem an anderer Stelle ?

Danke für Hinweise,
T.Frost

[Falk Prüfer]

Hallo Tobias,

es ist immer mit Performanceeinbußen verbunden wenn eine große Anzahl an Datensätzen geändert wird und die Änderungen erstmal temporär zwischengpuffert werden. Auch größere SQL-C/S-Systeme bekommen dort irgendwann Probleme mit Ihren RedoLogs. Wenn es also nicht zwingend notwendig ist alle Änderungen zu verwerfen nur weil der 2599 ste fehlgeschlagen ist, dann würde ich das Update in mehrere "Häppchen" verpacken und eben schon allle 100, 500 oder 1000 Datensätze commiten.

Gruß Fal

[Tobias Frost]

Hi Falk !

Ich habe es leider mit einer sehr redundanten Datenbank zu tun. Sie ist über ein Jahrzent in diesem Unternehmen gewachsen und sieh dementsprechend chaotisch aus. Es leider Fakt, daß die Änderung eines Datensatzes in einer Tabelle (speziell in den Stammdaten diese Unternehmens) einen Abgleich in einer Reihen von anderen Tabelle zur Folge hat. Sollte dieser Abgleich fehlschlagen und die Datenbank damit inkonsistent werden, hat das gravierende Folgen ! Daher kann ich nicht einen schrittweisen Abgleich machen, sondern muß den Abgleich bis zum Ende durchführen um sicher gehen zu können, daß die Änderung akzeptiert werden kann.

Mit diesem Problem an sich kann ich leben. Das die Performance aber bei eingeschaltetem BDE-Cache schon nach der Änderung weniger hundert Datensätze in nur einer Tabelle so wahnsinnig in die Knie geht, ist mir unverständlich. Es sieht aus, als würde die BDE den Cache lediglich um die Größe des neuen geänderten Datensatzes erweitern, bzw. Speicher in der neuen Größe anfordern, den alten Speicherbereich kopieren und den neuen Satz hinzufügen. Anders kann ich mir es nicht erklären. Scheint mir nicht sehr effektiv. Allerdings trau ich der BDE mehr zu. Nur wie ich diese Problem nun umgehen kann oder meistern kann - ich habe bis jetzt keine Hinweise in jeglicher Literatur zur BDE oder DEPLHI gefunden ...

Gruß, Tobia

[Andreas Kosch]

Hallo,

welche Datenbank wird verwendet? Falls es sich dabei um Paradox handelt, ist vom Update auch der Primärschlüsselwert betroffen

[Tobias Frost]

Moin Herr Kosch,

es handel sich um eine Paradox-Datenbank in der Version 4.0, der Primärschlüsselwert ist jedoch nicht betroffen