Insert into

[jobo]

So nützt die Proc nichts.
Du musst den gesamten Triggercode für das Insert dort aus den Triggern ausbauen (ggf ganze Trigger weglassen) und in die Proc packen.
Die Schleife gehört nicht in die Proc rein.

Die Proc soll das Insert selbst ausführen und alle nachgelagerten Updates und Summenbildung.

Triggercode für update, delete muss erhalten bleiben, solange das nicht ähnlich umgebaut wird.

Also alle betroffenen Trigger disablen und Code "umschichten", in Anführungszeichen, weil es sicher keine 100% Copy/Paste Aktion ist. Mindestens fallen Fallunterscheidungen für den Mutation Typ weg, es geht in der Proc ja nur noch ums Insert.
Außerdem muss Before / After entsprechend in den Flow der Proc einfließen.

Mit disabled Triggern solange die Proc entwickeln/testen, bis ein sauberes insert per Proc gelingt.
Diese Proc kann dann natürlich wie zuvor das Insert in Schleife aufgerufen werden.
Der Test der Proc, also Aufruf und Prüfung des Ergebnis am besten direkt in der SQL Console bis alles stimmt.

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

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