Insert into

[Delphi.Narium]

Wenn man große Datenmengen in 'ne Tabelle einfügt, kann es durchaus hilfreich sein, alle für das Insert nicht benötigten Indices zu löschen und nachher neu zu erstellen. Auch wenn die Neuerstellung sicherlich etliches an Zeit benötigt, so kann es duchaus passieren, dass diese Zeit deutlich kürzer ist, als die permanente Indexpflege während der Inserts.

Erfahrungsgemäß reden wir hier nicht von Laufzeitunterschieden im Bereich von Sekunden oder Minuten, sondern eher von Stunden bis Tagen. Sehr grob gesagt: Je größer die Datenmenge insgesamt, um so größer der Laufzeitunterschied.

[Jumpy]

Aber macht das alles den Insert eines Datensatzes so langsam, dass das 72 Sekunden dauert?
Gibt es nicht auch DBs die den Datensatz annehmen und den Index später in ihrer Freizeit aktualisieren?

[Delphi.Narium]

Kommt wohl drauf an, quasi so 'ne Art "Entschiedenes sowohl als auch".

Der Index muss sofort aktuallisiert werden (jedenfalls bei der Vorgehensweise, wie sie hier genutzt wird), damit im Trigger eine entsprechende Abfrage den gerade eingefügten Wert auch wiederfinden kann. Hier wird er sofort für eine Summenbildung in 'ner anderen Tabelle benötigt (select sum(spalte) from tabelle where ..., wobei der gerade eingefügte Satz eine Teilmenge, der durch die Wherebedingung selektierten Sätze, ausmacht). Würde der Index nicht sofort aktuallisiert, hätte es hier im konkreten Fall jedenfalls (mit an Sicherheit grenzender Wahrscheinlichkeit) negative Auswirkungen.

Wie es sich bei 'nem Bulk-Insert verhält, weiß ich nicht, aber das liefe dann vermutlich ohne den Aufruf der Trigger, was wiederum die dort abgebildete Geschäftslogik ruinieren würde.

Und je nach Datenmenge kann ein fehlender Index schon 'ne massive Auswirkung auf die 72 Sekunden haben. Wenn ein Full Table Scan über 'ne Minute zum Summieren von Werten braucht, dann braucht er halt pro Datensatz über 'ne Minute.

Entweder ins Datenbankdesign investieren oder die Hardware massiv aufrüsten, so dass die DB komplett im Arbeitsspeicher landet, die CPU exorbitant schnell ist, Festplatten mit Zugriffszeiten, die gegen 0 tendieren, ...

Bei 'ner handelsüblichen Hardware kann man in Situationen geraten, in denen es sich eben genau so verhält, wie es hier gerade vorliegt.

[jobo]

Es ist ja bekannt, dass das Verhalten plötzlich gekippt ist. Insofern würde ich Fragen nach Indizes usw. nicht im Vordergrund sehen.
Umgekehrt ist das Aufräumen der Trigger und die Umstellung auf eine Prozedur sicher ein recht kleiner Aufwand, denn eigentlich ist alles da, was benötigt wird.
Eine Analyse wie von einigen angesprochen, wäre sicher auch nicht verkehrt, aber es gilt ähnlich wie zuvor, die Zeit kann ich direkt in das Refaktoring stecken.
Und etwas Analyse gibt es ja auch, das Verhalten bei direkter Nutzung einer SQL Console. Hardware Schäden und viele andere Dinge kann man also schon mal ausschließen und es geht nicht vollkommen planlos daher.

Hardwareerneuerung ist ja auch immer ein verlockender Vorschlag und mit dem Monatslohn eines Entwicklers kann man sicher einen guten Server bekommen. Dann muss aber noch die Umstellung gemacht werden und am Ende bleibt die Frage, ob man für den Aufwand einen Faktor 72 oder mehr (grobe Annahme: vorher hat das Insert nur eine Sekunde gedauert) hinbekommt. Mein Tipp wäre eher: nein.

[IBExpert]

Wenn es eine einigermaßen aktuelle Firebird Version ist und man einie einigermaßen aktuelle IBExpert Version haben sollte, dann sollte sich durch das Ansehen dieses Videos https://www.youtube.com/watch?v=MOuCeKTNpOk innerhalb kurzer Zeit mit der Traceapi finden lassen, was der grund ist oder mit dem Benchmark aus anderen Videos prüfen, ob der eingesetzte Rechner zB wegen treiberprobleme langsamer ist als erwartet.

Man kann aber auch alternativ hier immer wieder nach göttlicher Hilfe Fragen um die eigenen Probleme von dritten kostenlos gelöst zu bekommen

Ist halt immer eine Frage der Einschätzung, was die verschwendete eigene Arbeitszeit oder die fehlende Zufriedenheit der eigenen Kunden an externen Beratungsaufwand rechtfertigen. Muss ja jeder selber wissen, die erste Problemschilderung war ja auch erst am 1.Mai dieses Jahres .....

[jobo]

Zitat von IBExpert:

Wenn es eine einigermaßen aktuelle Firebird Version ist und man einie einigermaßen aktuelle IBExpert Version haben sollte, dann sollte sich durch das Ansehen dieses Videos https://www.youtube.com/watch?v=MOuCeKTNpOk innerhalb kurzer Zeit mit der Traceapi finden lassen, was der grund ist ..

Man kann aber auch alternativ hier immer wieder nach göttlicher Hilfe Fragen um die eigenen Probleme von dritten kostenlos gelöst zu bekommen
.....

Ja, eine Analyse ist möglich und sicher nicht unsinnig.

Über den Punkt "kostenlos" war der TE allerdings schon hinaus, er hat explizit nach bezahlter Hilfe gefragt. Ich hab leider keine Zeit für sowas.

[himitsu]

Zitat von Delphi.Narium:

Wenn man große Datenmengen in 'ne Tabelle einfügt, kann es durchaus hilfreich sein, alle für das Insert nicht benötigten Indices zu löschen

Wieso muß man immer gleich löschen?

Viele DBMS bieten es an Indize umd vor allem Constraint zu deaktivieren
und anschließend mit oder ohne Prüfung wieder anzuschalten.

Ohne = falsche Constraint werden erlaubt und werden erst beim nächsen EDIT des jeweiligen Datensatzes wieder geprüft.

Es ist zwar speziell für Backup/Restore ganz praktisch, um nicht die Reihenfolge der Tabellen beachten zu müssen, aber auch für Massen-Bearbeitungen (Insert/Edit/Delete), wenn man selbst die Daten geprüft hat, oder die Prüfungen erst auch "Einmal" erledigen lassen will, wenn man alles drin hat (vor Abschluss der Session).

[Delphi.Narium]

Also "löschen" ist etwas "hart" formuliert.

Sagen wir so: Es könnte eventuell hilfreich sein, die für das entsprechende Datenbanksystem sinnvollste und am wenigsten aufwendige Möglichkeit der vorübergehenden Nichtnutzung der für die konkrete Aufgabe entbehrlichen Indizes zu wählen.

Hängen an Indizes irgendwelche Abhängigkeiten, die für die korrekte Speicherung von Daten erforderlich sind, darf man die natürlich weder löschen noch deaktivieren, noch ...

Mit somaleben machen wir da mal was, Hauptsache ein bestimmter Job wird dadurch schneller, ist es nichts. Man muss sich da schon jeden Eingriff in die Datenbank sehr genau überlegen und sicherstellen, dass der Eingriff nicht irgendwelche "Spätfolgen" verursacht, die erst Sekunden, Minuten, Tage, Wochen, Monate, ... später unter Umständen eventuell vielleicht auftreten könnten oder sofort zu Inkonsistenzen ... führen können.

Die Mutter ist die Vorsicht der Porzellankiste (oder so ähnlich)

Oder Anders: Aus den hier vorliegenden Informationen kann man keine sinnvolle und garantiert hilfreiche und korrekte Lösung des Problems entwickeln, es ist allenfalls möglich ein paar Lösungsansätze, die eventuell zielführend sein könnten, zu geben. Die Lösung könnte auch aus 'ner Kombination der bisher gemachten Vorschläge aller Threadteilnehmer bestehen. Aber selbst das kann man nicht mit Sicherheit sagen.

[hoika]

Hallo,
ich würde mir erst mal das Video von Holger reinziehen (bin etwa bei 50%, puh viel Know-How ...).
Und genau ein Insert per Trace-API verfolgen.

[jobo]

Zitat von himitsu:

Zitat von Delphi.Narium:

Wenn man große Datenmengen in 'ne Tabelle einfügt, kann es durchaus hilfreich sein, alle für das Insert nicht benötigten Indices zu löschen

Wieso muß man immer gleich löschen?

Viele DBMS bieten es an Indize umd vor allem Constraint zu deaktivieren
und anschließend mit oder ohne Prüfung wieder anzuschalten.

Ohne = falsche Constraint werden erlaubt und werden erst beim nächsen EDIT des jeweiligen Datensatzes wieder geprüft.
..

Das ist glaub ich nicht ganz richtig. Ein Constraint existiert ganz allgemein erstmal ohne Index, nur seine Prüfung ist mit Index oft viel schneller. Das kommt darauf an, ob
1. überhaupt ein xy Key Constraint (primär oder fk) genutzt wird oder ein bloßer Value Constraint (im gleichen Datensatz)
2. das RDBMS die Handhabung von Key Constraints und Indizierung sauber trennt

Gerade 2. ist leider nicht immer gegeben und sehr unterschiedlich "komfortabel" realisiert, je nach Hersteller. Das Löschen eines Constraints löscht also den Index und vielleicht auch umgekehrt(?). Auch (deffered) Aktivierung / Deaktivierung ist meines Wissens nicht überall verfügbar.
Gute Systeme können bspw. (alte) bestehende Indizes nutzen, um neue (oder sich selbst) neu aufzubauen, den Aufbau parallelisieren, ...

Aber das geht schon etwas weit vom Thema ab.