Anzahl ins/upd/del eines beliebigen statements ermitteln

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Antworten
vr2
Beiträge: 214
Registriert: Fr 13. Apr 2018, 00:13

Hi alle,

angenommen, ihr habt einen Batchlauf mit allen möglichen DB-Aktionen, inserts, updates, deletes, inklusive Verwendung von Stored Procedures, die ins/upd/del machen oder Trigger, die durch die ins/upd/del ausgeführt werden, im Rahmen eines statements können natürlich auch 2 oder alle 3 Aktionen (ins/upd/del) vorkommen. Jetzt wollt ihr Performanceanalyse machen. Wie ermittelt ihr die Anzahl der inserts, updates und deletes pro einzelner Aktion? Geht ihr übers Firebird-API (isc_dsql_sql_info o.ä.) oder benutzt ihr die monitoring tables? Wie beides geht, weiß ich, und dass monitoring tables ressourcenaufwändiger sind, es geht mir mit der Frage eher darum, was ihr nutzt und warum.

Grüße, Volker
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

I.d.R. verwende ich ausschließlich die Ergebnisse "Affected Records" aus dem jeweiligen Befehl und speichere diese für spätere Auswertungen in einer eigenen Trace-Tabelle.
In PSQL z.B. gibt es die Variable ROW_COUNT, die man abfragen kann.
Auswertung von Traces ist da tatsächlich sehr aufwändig.
Benutzeravatar
martin.koeditz
Beiträge: 443
Registriert: Sa 31. Mär 2018, 14:35

Hi Volker,

ich mache das ebenfalls wie bfuerchau beschrieben hat. Eine Log-Tabelle erstellen und die Daten dort ablegen. Nur bei den Zeitstempeln NOW statt CURRENT_TIMESTAMP verwenden. Letztere nimmt nämlich immer den Zeitpunkt des Transaktionsstarts.

Gruß
Martin
Martin Köditz
it & synergy GmbH
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Ansonsten zu den Ergebnissen:
Da mir ab und an die Datenbank schon mal kaputt geht, habe ich mir einen DBReplicate entwickelt, der eine Datenbank Tabelle für Tabelle und Zeile für Zeile kopiert. Dies klappt fast immer, auch wenn der gbak schon mal scheitert da meist der Datenteil einer Tabelle heil bleibt.

Dabei werden von mir 4 Threads parallel via .Net mit dem .Net-Treiber erstellt die dann die Daten kopieren. Alle Tabellen haben dabei eine BIGINT-Identity-Column, die mit Sequence-Objekten gezählt werden.

Dabei kann ich bei einzelnen Tabellen zwischen 1000 bis 5000 Inserts je Sekunde erreichen (je nach Zeilenlänge), über alle 4 Threads bis zu 12.000 Inserts!

Da diese Threads ja sowohl lesen als auch schreiben, behandelt der Firebirdserver also 8 Connections mit 2 Datenbanken.
Die Geschwindigkeit ist zwischen Version 2.5 und 3.0 nahezu gleich.
Die CPU-Belastung steigt dabei kaum über 40%.

Eine Erhöhung der Anzahl Threads war nicht von Erfolg gekrönt da der maximale Plattendurchsatz wohl erreicht war.

Da kann sich ein SQL-Server mal eine Scheibe von abschneiden.

Hardware:
Schenker Notebook, 16GB Speicher, 1x 512MB SSD, 1x 2TB Disk.
Intel 7, 4-Cores á 2 Threads, 2,6 GHz, Turbo bis 3,2 GHz.
vr2
Beiträge: 214
Registriert: Fr 13. Apr 2018, 00:13

Hallo ihr 2,

danke für eure Antworten. Affected Records eines Befehls bekommt ihr also übers Firebird-API bzw über eure jeweilige connectivity-Schicht, richtig? Gibt die auch mehrere Anzahlen gleichzeitig zurück? Ein delete statement bspw, das in einer Tabelle löscht, die delete-Trigger hat, kann ja gleichzeitig inserts und /oder updates auslösen. Diese insert- und update-Anzahl sollen zusammen mit der delete-Anzahl auch zurückgegeben werden. So wie das in DB-Admin-Tools auf deren Statistikseiten auch ausgewiesen wird, wenn man da irgendwas komplexeres ausführt. Es muss allerdings für diesen Zweck nicht so detailliert sein, dass noch nach page reads oder indexed reads aufgeschlüsselt wird.

Grüße, Volker
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Nein, Triggeraktionen werden da nicht mitgezählt. Da ist man selber für verantwortlich.

Trace ist da manchmal weniger aussagefähig, da der Traceaufwand nicht zu vernachlässigen ist.
Wenn du Einfluss auf die Trigger hast, mach da lieber die Protokolle.
Antworten