Insert into

[Walter Landwehr]

Nur mal so zur Info.

Seit Jahren läuft dies eigentlich ohne Probleme. Am Code ist schon seit Jahren nichts geändert worden. Aber seit 2 - 3 Monaten trat dann plötzlich diese Verzögerung ein. Kann es an Firebird liegen?

[p80286]

Zitat von Walter Landwehr:

Nur mal so zur Info.

Seit Jahren läuft dies eigentlich ohne Probleme. Am Code ist schon seit Jahren nichts geändert worden. Aber seit 2 - 3 Monaten trat dann plötzlich diese Verzögerung ein. Kann es an Firebird liegen?

Die Vermutung liegt nahe. Ist irgendein Update gelaufen?

Gruß
K-H

[jobo]

Das muss nicht mal ein Update gewesen sein.

"Das skaliert nicht" ist die banale Aussage über Code, der unter Last anders arbeitet als im "idle" Betrieb.

Ein "schlampiges" Select Statement läuft jahrelang gut, bis der Order By Teil so groß ist, dass er nicht mehr ins RAM passt. Dann geht alles auf Dateiebene. Bums. Wenn man dann noch ne klassische HDD am Start hat. Doppelbums.

Ich hab kein Plan von Firebird Optimizer Funktionen, nur der Hinweis: Wenn es einen Optimizer Algorithmus gibt, der ansatzweise dynamisch ist, muss er mit Grenzwerten arbeiten, also Grenzwerten von Row Counts usw. vielleicht sogar mit Statistiken. Und dann gibt es auch diesen Effekt, jahrelang lief alles gut, bis diese eine Grenze überschritten wurde. Dann "denkt sich" der Optimizer was neues aus und Bums.
Ich kenne es hauptsächlich von Oracle. Hier gibt es bspw. eine Funktion, die Optimizer Spielregeln "einzufrieren", um solche Effekte zu vermeiden. Das macht man natürlich nur, wenn man mit dem Betrieb zufrieden ist und Größenordnungen der Datenmengen und sagen wir einen Reifegrad der Anwendung erreicht hat, wo Optimierungen eben mehr Risiken und Aufwand als Nutzen bringen.

[Neumann]

Die Trigger machen das Ganze schon komplex und schwer beurteilbar wie aufwändig die Routinen sind.

Was man immer machen kann:

Alte Firebird Versionen ersetzen 2.5.0.. macht definitiv Probleme, wenn 2.5 dann 2.5.9.

Backup Restore der Datenbank