Ich hatte mich letzte Woche bei einer Anwendung mit der Geschwindigkeit bei Datenbankoperationen beschäftigt. Die Anwendung schreibt etwa 100 Datensätze in einer große Tabelle mit ca. 60 Mio Datensätzen. Beim einfügen der Daten musste ich leider 20s warten, was für mein Verständnis für Datenbankzugriffe einfach nichz akzeptabel ist. Demzufolge habe ich die Gründe untersucht.
- Werden alle Daten in einer Transaktion geschrieben. In dem Thema verbirgt sich eine etwas heßliche Problemstellung. Die Oracle-Clientversion ist so eine seltsame Version, dass ich kein ODP.NET Treiber bekomme, der ohne Client-Neuinstallation arbeitet. Ich habe keine Möglichkeit die Ora-Client-Installation auf den Zielsystemen zu verändern. Um meine Absichten deutlich zu machen, habe ich trotz des Bewußtseins, dass es nicht funktioniert den TransactionScope benutzt. Im Anschluss die manuelle “old-style” Transaction geöffnet, IDbConnection.BeginTransaction.
- Trigger auf der Tabelle prüfen. Trigger verlangsamen die Ausführung der Änderungsoptionen und könnten schon einen negativen Effekt erklären.
- Indizes beeinflußen die Geschwindigkeit von Änderungsoperationen ebenso, so dass diese auch geprüft werden sollten.
- Andere Abhängige Datenbankobjekte prüfen, z. B. Materialized views (Snapshots).
Nunja, da ich mich mit der Anwendungsprogrammierung deutlich besser auskenne als in der DB-Programmierung, habe ich mich mit dem ersten Punkt beschäftigt. Meine Transaktionen waren vorhanden, aber die Geschwindigkeit war immer noch nicht befriedigend. Also die Idee eines Kollegen aufgegriffen, einen PL/SQL aus meinen Operationen zu erstellen. Bei der Ausführung eines PL/SQL-statements wird dieses durch die DB optimiert und als ein Block übergeben, evtl. greifen auch einige zusätzliche Optimierungen. PL/SQL-Blöcke beginnen mit “BEGIN” und Enden mit “END”. Um den Befehl aus dem .NET-Framework über den ODP-Provider zu übergeben, müssen alle Anweisungen in einer Zeile aufgeführt werden. Zum Beispiel: BEGIN Stmt1; Stmt2; … END; Nach all der Mühe war ich von dem Ergebnis enttäucht. Es gab eine Verbesserung, allerdings nur maginal. Es gab auch nix an Triggern, die ich hätte verantwortlich machen können.
Allerdings gabe es 3 Indizes, 1 PK und 2 Indizes, bei einer 4 Spalten-Tabelle. Die Wahrscheinlichkeit ist sehr hoch, dass bei den Abfragen die definierten Indizes genutzt werden, so dass ich mich nicht daran zu schaffen machen wollte. Ein Kollege meinte zu dem, dass die Berechnung der Indizes nicht die Operation merklich beeinflußt.
Blieb nur noch der Punkt 4., es gibt 4 MVs, 2 werden OnDemand aktualisiert, 2 werden OnCommit (fast) aktualisiert. Also der Versuch alle Views mittels Demand von Operationen auf der Tabelle abzuklemmen. Oh Wunder, von 20s auf unter 1s, dass sind schon Zahlen, die ich für 100 einfüge Operationen in eine große Tabelle erträglich finde. Das Aktualisieren der Views wird durch einen seperaten Aufruf am Ende der Verarbeitung angetriggert und dauert einige Sekunden, allerdings weniger, als 100 Inserts mit Daueraktualisierng. MVs haben viele Vorteile, gerade beim Abfragen der Daten und könen die Performance von Abfragen um ein vielfaches Steigern. Wie aber auch geschehen, können andere Operationen verlangsamt werden.
Keine Kommentare:
Kommentar veröffentlichen