AW: Insert into
Zitat:
Gruß K-H |
AW: Insert into
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. |
AW: Insert into
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 |
AW: Insert into
1 Sekunde für 1 Insert in IBExpert ist eigentlich auch langsam, aber na ja...
43 Sekunden füe 1 Insert aus dem Code - da stimmt was nicht Wenn du IBExpert hast, dann geht duch mal ins Databas Monitoring und schau dir vor allem die Oldest Active Transaction etc. an. Die Werte sollten nah beieinader liegen, eigentlich um 1 differieren. Da du IBO benutzt, solte es eigentlich OK sein... Wenn man wissen will, ob die DB einen weg hat, dann Backup und Restore... Wie sind die Einstellungen in IBO und was verwendest du? (TIBOTransaction oder TIB_Transaction etc., TIBOQuery oder ...) Am schnellsten ist IMO TIB_DSQL. Warum durchläufst du in PatblattQry alle Datensatze unf machst dann ein
Code:
Warum nicht gleich im SQL von PatblattQry ein
if (PatblattQry.FieldByName('TYP').AsString <> 'Z') then
Code:
Dann kannst du das if weglassen.
where typ <> 'Z'
|
AW: Insert into
Zitat:
|
AW: Insert into
Wie so oft: Du musst schauen, wo die Zeit liegen bleibt.
- nimm mal die trigger weg - nimm die indices weg - was sagen die performance counter - platte, speicher, CPU - schau dir an was firebird wirklich macht (Stichwort trace) Wie andere auch schon gesagt haben, Datenbanken leben und sollten laufen beobachtet werden. In der Regel kündigen sich so Eskalationen an. |
AW: Insert into
Walter,
mit Firebird 2.5 bist du in der glücklichen Lage, die Firebird Trace API zur Verfügung zu haben. D.h. wie schon von anderen erwähnt, eine Trace Session anwerfen und sehen, was deine Client-Anwendung tatsächlich auslöst. - Ev. Locking - Ev. Background (Trigger etc.) Overhead, auch abhängig von bestimmten Spaltenwerten, die durch das INSERT gesetzt werden - Vielleicht passiert irgendwo in IBO im Hintergrund ein FetchAll - etc. Solltest Du IBExpert verwenden, dann bist du dort (Trace API) bereits gut aufgehoben. Standalone wäre auch unser FBTraceManager eine Option: https://www.upscene.com/fb_tracemanager/ LG |
AW: Insert into
So habe lange herumgetestet aber keine Lösung gefunden. Mach ich einen Insert in einer Tabelle wo nur ca. 34000 Datensätze vorhanden sind, geht es sehr schnell aus der Anwendung heraus.
Meine Frage gibt es einen Experten der mir hier weiterhelfen kann. Natürlich gegen Bezahlung. |
AW: Insert into
Hallo,
schon mal Backup/Restore gemacht? |
AW: Insert into
Ja habe ich aber ohne Erfolg. Kann es doch mit den großen Datenmengen in der Tabelle zu tun haben?
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:06 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz