Array in SQL

[Jasocul]

Hi roldi,

es werden alle Datensätze aller genutzten Tabellen sequentiell durchlaufen und für den Test habe ich alles deaktiviert, was die Daten verändert. Ein fehlender Index ist ganz sicher nicht das Problem.

Ich habe aber jetzt zur Sicherheit noch einen Test-Durchlauf gemacht.
- Durchlauf der kann 500.000 Datensätze ohne einen Änderungs-Cursor dauert ca. 15 Sekunden
- Mit Aktivierung eines Änderungs-Cursor (ohne irgendwelche weiteren Aktionen) knapp 3 Minuten

[rokli]

Du durchläufst 500' Sätze und gehst bei jedem Satz die kleinen (Cursor-) Tabellen durch?

Kannst Du das evtl. anders miteinander verbinden?

[Jasocul]

Leider nicht.
Ich muss in 2-3 Feldern ein Wort-Splitting machen, dabei verschiedene Neben-Bedingungen beachten, bestimmte Wörter ignorieren/ersetzen. Teilweise betrifft das auch nur einzelne Buchstaben. Joins oder ähnliches sind auf diese Weise nicht zu realisieren, da die Inhalte durch die Operationen ja variabel sind.

Gebraucht wird das für:
Pro Datensatz wird dann je zulässigem Wort in eine neue Tabelle geschrieben/aktualisiert. Diese dient dann der Überprüfung, ob neue, ähnliche oder gleiche Daten bei der nächsten Daten-Lieferung kommen.

[rokli]

puh

[Aviator]

Zitat von Jasocul:

Leider nicht.
Ich muss in 2-3 Feldern ein Wort-Splitting machen, dabei verschiedene Neben-Bedingungen beachten, bestimmte Wörter ignorieren/ersetzen. Teilweise betrifft das auch nur einzelne Buchstaben. Joins oder ähnliches sind auf diese Weise nicht zu realisieren, da die Inhalte durch die Operationen ja variabel sind.

Gebraucht wird das für:
Pro Datensatz wird dann je zulässigem Wort in eine neue Tabelle geschrieben/aktualisiert. Diese dient dann der Überprüfung, ob neue, ähnliche oder gleiche Daten bei der nächsten Daten-Lieferung kommen.

Kann man diese Bearbeitung der Wörter evtl. in dem anderen DBMS machen indem ein OnInsert/OnUpdate Event eingebaut wird? Keine Ahnung ob das an der Geschwindigkeit was ausmacht, aber vielleicht kannst du es ja mal probieren.

[TRomano]

Wenn ich das richtig verstanden habe läuft diese Stored Procedure einmal täglich mit einer Dauer von 15 sec. ? Lohnt sich da wirklich der Aufwand stundenlang zu Forschen, zu Proggen und zu Testen ? Oder ist das eine Fingerübung ?
Hat der DB-Server deine volle Aufmerksamkeit (keine anderen Jobs), sind die Parameter der DB so eingestellt, dass er bei bestimmten Operationen (z.B. ORDER BY) keinen Speichermangel hat und kann man vielleicht die Verarbeitung der Daten auf dem Client machen, um den Server zu entlasten. Alles Fragen, die gestellt werden sollten ...

[Jasocul]

Hallo Aviator,
das wäre nur eine sehr theoretische Möglichkeit, da ich selbst keinen Zugriff auf die anderen DB-Systeme habe.
So muss ich mit dem leben, was ich bekomme.

Zitat von Aviator:

OnInsert/OnUpdate Event eingebaut wird? Keine Ahnung ob das an der Geschwindigkeit was ausmacht, aber vielleicht kannst du es ja mal probieren.

Delphi ist da komplett außen vor. So ein Event gibt es also nicht. Die Überlegung das über Datenbank-Trigger zu machen, habe ich praktisch sofort verworfen, da die Daten im ersten Schritt über ein Bulk-Insert eingelesen werden. Die Trigger sind da meines Wissens nicht aktiv. Selbst wenn doch, würde dann der Cursor für die kleinen Tabellen jedesmal pro Datensatz neu erstellt werden, was die Performance noch weiter verschlechtert würde.

@TRomano:
Die 15 Sekunden erreiche ich nur, wenn ich die beiden Cursor zum Abgleich nicht verwende. Sobald die aktiviert werden, dauert es ca. 10 Minuten.
Wenn ich es vom Server auslagere, habe ich ja auch noch eine Schicht mehr.
Der Server hat zu dem Zeitpunkt nichts anderes zu tun, außer weitere Jobs durchzuführen, die aber sowieso sequentiell abgearbeitet werden müssen. Allerdings ist das auch der Grund, warum die Performance besser werden sollte.
Speicher ist genug da.
Im Moment habe ich einen Test-Server, der sehr ähnlich ausgestattet ist, aber wirklich sonst nichts zu tun hat.

[Aviator]

Zitat von Jasocul:

Delphi ist da komplett außen vor.

Das hatte ich mir gedacht. War nur dummerweise nicht mehr auf die Trigger Bezeichnung gekommen. Deshalb Event.

[MichaelT]

Ich kenne mich am SQL Server nicht aus und auch dein Programm nicht. Somit kann ich nur raten.

Bitte nicht prügeln wenn die Idee Unsinn ist. Rechnest du die Statistiken und machst du Zugriffsoptimierung über Statistiken. So ich mich ganz düster erinnere war da mal was. Welche Ausführungspläne bei welchem Cursor wie gezogen werden und wie man die traced weiß ich ehrlich nichts mehr.

Meine Grundsätzliche Überlegung wäre. 15 Sekunden auf 10 Minuten sind Faktor 40. Das wären so im Mittel 2 Tabellen bei denen die Hälfte der Datensätze durchkämmt wird pro Zugriff. Hat der Cursor zu wenig Einträge oder sind eventuell Statistiken nicht aktuell oder so ähnlich. Scrollable Cursor ist gut für viele Rows, wenn man nachschlagen muss.

Kennst du die Anzahl der Zeilen in den Nachschlagetabellen und hilft es wenn man diese fixiert ala static. Das Nachschlagen geht auf die tempdb & KEYSET (musste kurz nachschauen) oder STATIC.

Die Frage die sich mir stellt, ob sich die gewonnene Flexibilität durch SCROLL tatsächlich im Mittel auszahlt und ob man nicht auf ReadOnly und ForwardOnly nimmt. Ob diese Variante schneller ist kann ich so nicht beurteilen. Zumal diese Cursor keine echten in memory buffer sind scheint mir die variante einen Stand aus der tempdb zu lesen noch eher die 'beste' Annährung oder eben ein KEYSET usw..

Stellt sich die Frage ob du die tempdb nicht auf ein RAMDRIVE kannst legen. Aber das ist schon etwas gewagt. Die tempdb wird an sich von alle benutzt. Wäre allein interessant zu sehen, ob es einen Unterschied macht zur tempdb auf Platte. Vermute die Datenbankseiten sollten sowieso gepuffert sein.

[Jasocul]

@Aviator:
Kein Problem. Manchmal sind es die einfachen Dinge, die zur Lösung führen, weil man zu kompliziert denkt.

@MichaelT:
Alle Daten werden sequentiell verarbeitet (alles ohne order by, joins, ...). Die Aktualisierungen natürlich nicht, aber die sind im Test auch nicht aktiviert. Die Statistiken können somit keine Rolle spielen.

Aber der Hinweis auf Static hat mich ein bisschen weiter gebracht. Allerdings war es read_only, was mir 2 Minuten Verbesserung gebracht hat. Danke für den Anstoß. Static bringt in diesem Zusammenhang nur ein paar Sekunden.

Ich bewege mich also jetzt zwischen 7 und 8 Minuten, was schon deutlich besser ist, aber immer noch relativ lange ist. Weitere Tipps sind willkommen.