SQL "Update or Insert" langsam

[bnreimer42]

Zitat:

Zitat von jobo (Beitrag 1357991)

Meinst Du eine Batchkomponente?
Mittels Transaktionshandling sollte es eigentlich wurscht sein, was an Spezialitäten da ist.
Wenn man eine Reihe von Befehlen absetzt, werden sie erst mit "Commit" commited.
Viele Commits, nach jedem insert bspw, bringen auch eine Verzögerung. Blockweise commit sind schneller, ist aber glaub ich marginal.

Ja, die Batchkomponenten kann ja nicht zaubern.
Firebird kann zum Beispiel nicht die "Indexpflege" erst beim Commit machen und damit nur einmal für alle Commits.

Es kann auch sein, dass viele Statements im Batch langsamer sind. Wenn eine weitere ältere Transaktion alte Versionen der Sätze noch im Fokus hat, muss der Server neue Pages allozieren um die neuen Versionen der Sätze zu speichern. Beim Insert ist es klar, dass er das immer machen muss, aber bei mehreren Updates kann er die alten Speicherbereiche recyceln.

Das wird bei größeren Satzlängen problematischer, also insbesondere beim Updaten von größeren BLOBs, die ja dann ggf. auf eigene Pages pro BLOB ausgelagert werden zusätzlich zu den Pages, die er beschreiben muss, um den Satz zu speichern.

Diese Phänomene können obigen Geschwindigkeitsvorteil wieder wett machen.

Natürlich gibt es aber Gründe für eine derartige Implementierung und das ist die Datensicherheit und den Erhalt der Konsistenz der Datenbankdatei zu jedem Zeitpunkt. Bei Datenbanken sollte immer die Datensicherheit höher bewertet werden, als die Schnelligkeit.



Gruß

Björn

[jobo]

Zitat:

Zitat von bnreimer42 (Beitrag 1358000)

Zitat:

Zitat von jobo (Beitrag 1357991)

Meinst Du eine Batchkomponente?
Mittels Transaktionshandling sollte es eigentlich wurscht sein, was an Spezialitäten da ist.
Wenn man eine Reihe von Befehlen absetzt, werden sie erst mit "Commit" commited.
Viele Commits, nach jedem insert bspw, bringen auch eine Verzögerung. Blockweise commit sind schneller, ist aber glaub ich marginal.

Ja, die Batchkomponenten kann ja nicht zaubern.
Firebird kann zum Beispiel nicht die "Indexpflege" erst beim Commit machen und damit nur einmal für alle Commits.

Es kann auch sein, dass viele Statements im Batch langsamer sind. Wenn eine weitere ältere Transaktion alte Versionen der Sätze noch im Fokus hat, muss der Server neue Pages allozieren um die neuen Versionen der Sätze zu speichern. Beim Insert ist es klar, dass er das immer machen muss, aber bei mehreren Updates kann er die alten Speicherbereiche recyceln.

Das wird bei größeren Satzlängen problematischer, also insbesondere beim Updaten von größeren BLOBs, die ja dann ggf. auf eigene Pages pro BLOB ausgelagert werden zusätzlich zu den Pages, die er beschreiben muss, um den Satz zu speichern.

Diese Phänomene können obigen Geschwindigkeitsvorteil wieder wett machen.

Natürlich gibt es aber Gründe für eine derartige Implementierung und das ist die Datensicherheit und den Erhalt der Konsistenz der Datenbankdatei zu jedem Zeitpunkt. Bei Datenbanken sollte immer die Datensicherheit höher bewertet werden, als die Schnelligkeit.

Ja, ich sprach nur davon, dass hochfrequnete Commits einen Geschwindigkeitsnachteil haben gegenüber blockweisen, also dem reinen Commit Overhead.
Indizierungseffekte bspw. sind wieder eine andere Geschichte, defferable Indices sind auch interessant, aber nicht in jedem RDBMS verfügbar.

Interessant an deinen Ausführungen auch die BLOB Thematik, die ja vielleicht das Problem des TE berührt. Aber der ist ja wohl abgetaucht.

[mkinzler]

Bei Firebird kann man Indizes temporär deaktivieren:

SQL-Code:

ALTER INDEX <Indexname> INACTIVE;

Allerdings nicht bei aktiven Constraints.

[jobo]

Ah, wie wirkt sich das aus?
Nur auf die Aktualisierung oder auch auf die Nutzung bei Abfragen?

Die Einschränkung auf "ohne aktive Constraints" ist natürlich hart, wäre dann aber immerhin für reine Suchindices möglich.

Die Einschränkung deutet auch darauf hin, dass der Index nicht nur für Aktualisierungen deaktiviert ist, sondern auch für Abfragen.

[bnreimer42]

Hallo,

das stimmt. Einen reinen Such-Index kann man mit INACTIVE von Nutzung und Aktualisierung abschalten.
Funktioniert aber nicht für Indizes, die für Fremdschlüssel erzeugt wurden oder für Indizes, die für Constraints erzeugt wurden oder für UNIQUE-Indizes, was ja auch ein Constraint ist. Somit ist die Funktion bei einer "ordentlichen" Datenbankstruktur mit Fremdschlüsseln in der Praxis eher irrelevant.

Es kann aber auch nichts passieren, wenn man versucht, einen Index auf INACTIVE zu setzen, der in einem Constraint benötigt wird. Man bekommt einen Hinweis.

Eigentlich nutze ich das umsetzen nur für die Erneuerung der Statistken der Indizes beim "Aufräumen" der Datenbank.

[hstreicher]

da hier aber ein Update or Insert durchgeführt wird ,
ist das eher kontraproduktiv,
da ohne Index die Prüfung auf das Update eine Full Table Scan auslösen wird


mfg Hannes

[bnreimer42]

Zitat:

Zitat von hstreicher (Beitrag 1358030)

da hier aber ein Update or Insert durchgeführt wird ,
ist das eher kontraproduktiv,
da ohne Index die Prüfung auf das Update eine Full Table Scan auslösen wird


mfg Hannes

Hallo,

ja, wenn man den Index deaktivieren könnte. Der Index kann nicht auf INACTIVE gesetzt werden. Primary-Key ist ein Constraint.

Gruß

Björn

[mkinzler]

Es kommt auch darauf an, ob die Daten einer gewissen Überprüfung bedürfen. Falls Daten 1:1 eingespielt werden können kann man Indizes/Contraints problemlos Deaktivieren.

[jobo]

Mmh, also in dem Fall hier wo PK betroffen sind, würde ich das Deaktivieren von Constraints mal ausschließen.

Generell ist beim Deaktivieren von Indizes oder Constraints ja auch zu berücksichtigen, wer/was sonst noch grad im System geschieht.

Ebenfalls können aber neben den PK Keys und sonstigen Constraints auch reine Suchindices vorhanden sein. Die wären dann m.E. geeignet, sie zu deaktivieren. Dann muss im Zweifel mal jemand etwas länger auf einen Report oder eine Antwort der Suchmaske warten.