AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken SQL "Update or Insert" langsam

SQL "Update or Insert" langsam

Ein Thema von BlueStarHH · begonnen am 2. Jan 2017 · letzter Beitrag vom 4. Jan 2017
Antwort Antwort
Seite 3 von 3     123
bnreimer42

Registriert seit: 26. Mai 2013
Ort: Erlangen, Franken
122 Beiträge
 
Delphi 12 Athens
 
#21

AW: SQL "Update or Insert" langsam

  Alt 3. Jan 2017, 23:10
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
Björn Reimer
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#22

AW: SQL "Update or Insert" langsam

  Alt 4. Jan 2017, 08:01
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.
Gruß, Jo
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.851 Beiträge
 
Delphi 11 Alexandria
 
#23

AW: SQL "Update or Insert" langsam

  Alt 4. Jan 2017, 08:19
Bei Firebird kann man Indizes temporär deaktivieren:

ALTER INDEX <Indexname> INACTIVE; Allerdings nicht bei aktiven Constraints.
Markus Kinzler
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#24

AW: SQL "Update or Insert" langsam

  Alt 4. Jan 2017, 11:30
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.
Gruß, Jo
  Mit Zitat antworten Zitat
bnreimer42

Registriert seit: 26. Mai 2013
Ort: Erlangen, Franken
122 Beiträge
 
Delphi 12 Athens
 
#25

AW: SQL "Update or Insert" langsam

  Alt 4. Jan 2017, 11:43
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.
Björn Reimer
  Mit Zitat antworten Zitat
hstreicher

Registriert seit: 21. Nov 2009
220 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#26

AW: SQL "Update or Insert" langsam

  Alt 4. Jan 2017, 12:23
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
  Mit Zitat antworten Zitat
bnreimer42

Registriert seit: 26. Mai 2013
Ort: Erlangen, Franken
122 Beiträge
 
Delphi 12 Athens
 
#27

AW: SQL "Update or Insert" langsam

  Alt 4. Jan 2017, 12:51
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
Björn Reimer
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.851 Beiträge
 
Delphi 11 Alexandria
 
#28

AW: SQL "Update or Insert" langsam

  Alt 4. Jan 2017, 13:20
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.
Markus Kinzler
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#29

AW: SQL "Update or Insert" langsam

  Alt 4. Jan 2017, 15:05
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.
Gruß, Jo
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:46 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