Insert into

[Walter Landwehr]

OK habe ich mir schon gedacht, werde das ganz umbauen und auf die trigger verzichten.

[TigerLilly]

Schau doch, was der Server wirklich macht! Stichwort Trace. Du rätst jetzt herum + weißt nicht, wo du hingreifen sollst.

1) Was macht die Hardware? Rödelt die Platte herum? Kocht der Prozessor?
2) Was macht die Datenbank? Werden triggers ohne Ende gefeuert? Was genau braucht wie lange?

Nur wenn du weißt, was das Problem ist, kannst du es verlässlich lösen + beim nächsten Mal vermeiden!

[Delphi.Narium]

Bei allen SQLs, egal ob Select, Insert, Update, Delete mal den Ausführungsplan anschauen.

Bei Statements, die nur einen Satz "anpacken", sollte ein entsprechender Index genutzt werden. Fehlt der, wird jedesmal die gesamte Datenbank "durchgegraben" (Full Table Scan). Und sowas (schlimmstenfalls mehrfach) in einem Trigger pro Datensatz: Jo, das kann dann schonmal dauern, da wären die von Dir beobachteten Zeiten schon fast kurz zu nennen

Hat die Tabelle tbl_Artikel einen Index auf ArtikelNr?
Hat die Tabelle tbl_PatDiagnose einen Index auf (ReferenzTabelle, ReferenzNr)?
Hat die Tabelle TBL_PATDIAGNOSE einen Index auf (ReferenzTabelle, ReferenzNr, Dauerdiagnose)?
Hat die Tabelle TBL_PATIENT einen Index auf PATIENTENNUMMER?
Hat die Tabelle TBL_RECHNUNG einen Index auf rechnungNr?

Hat die Tabelle TBL_RECHNUNGSPOSITIONEN einen Index auf (RechnungNr, Steuercode)?
(Laut Createscript von oben nicht, aber pro Insert ein Select sum(Steuerbetrag) from TBL_RECHNUNGSPOSITIONEN where RechnungNr = :RechnungNrInt and Steuercode = 1 Into :Steuer1; Das schreit so nach 'nem Full Table Scan!!! Oder auch: Hilf mir, ich rödel mir hier 'nen Wolf.)

Das sind jetzt nur mal so "Indexideen". Was Du genau benötigst, was eher kontraproduktiv ist, muss Du wohl oder übel ausprobieren. Jedenfalls gibt es für alles, was ich da vorgeschlagen habe, entsprechende Selects, Updates, ... in den Triggern. Auch wenn die Trigger durch 'ne Prozedur ersetzt werden und sich eventuell die Geschäftslogik dadurch vereinfachen lässt: Solange die Datenbank für viele, einige oder alle Statements 'nen Full Table Scan pro Insert machen muss, wird es nicht wirklich schnell werden.

[TigerLilly]

Das würde ich gern ergänzen: Beim Insert müssen Indices aktualisiert werden, dh da kosten sie eher Zeit. Bei einem Update und Delete helfen sie, den Satz schneller zu finden + bringen eher Zeit.

Aber die Dosis macht das Gift, viele und große und vielleicht sogar redundante Indices kosten uU mehr Zeit als sie bringen.

[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.

[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.

[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.