Änderungsprotokoll

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

Moderator: thorben.braun

Antworten
dirk.schaefer
Beiträge: 3
Registriert: Mi 6. Feb 2019, 12:13

Mi 6. Feb 2019, 12:25

Hallo,

ich möchte auf einem Firebird 2.5 ein Änderungsprotokoll realisieren (in eine andere Db auf einer anderen Partition), welches Änderungen an allen Feldern in allen Tabellen mit Ursprungswert und neuem Wert enthalten soll (Einige Tabellen wird man sicherlich ausklammern müssen ).

Gibt es einen eleganteren Weg als auf die "AFTER INSERT", "..DELETE" und "..UPDATE" Trigger jeder Tabelle zurückzugreifen ? Ist ja sicherlich keine neue oder ungewöhnliche Anforderung ..

Wäre für jeden Tipp dankbar. Möchte allerdings auf 3rd Party Produkte verzichten und das direkt auf dem Firebird umsetzten.

Danke
bfuerchau
Beiträge: 88
Registriert: Mo 7. Mai 2018, 18:09

Mi 6. Feb 2019, 16:46

Nein, den gibt es nicht.
vr2
Beiträge: 46
Registriert: Fr 13. Apr 2018, 00:13

Do 7. Feb 2019, 00:09

Hallo Dirk,

wenn Du nur ein Änderungsprotokoll brauchst :
- hast Du ein Zeitfenster, in dem Du zwei Datenbanken vergleichen kannst?
- reichen die Abweichungen bspw tagesgenau?
- hat jeder Satz eine eindeutige ID oder eindeutige keyfeld-Kombination?

Dann könntest Du zb nachts die aktuelle DB mit dem backup des Vortages vergleichen und die Differenz bilden. Das lässt sich automatisieren, sofern sich nicht auch noch ständig die Tabellenstruktur oder die Schlüsselsystematik ändert.

Musst Du auch protokollieren, wer geändert hat?
Welches Volumen an Daten hast Du?

Wie lange zurück muss das log reichen und musst Du es jederzeit vollständig abrufbar haben? Wenn nur wenige Tage, kannst Du auch bspw die letzten 7 Tage Daten auf Halde legen und erst bei Bedarf gezielt die Differenz ermitteln.

Grüße, Volker
dirk.schaefer
Beiträge: 3
Registriert: Mi 6. Feb 2019, 12:13

Do 7. Feb 2019, 09:47

Hallo und Danke für die schnellen Antworten.

Ich benötige auch den Benutzer und den Zeitpunkt der Änderung.. sehe schon werde es wohl über die Trigger machen müssen..

Wenn jemand noch eine Idee hat, gerne her damit ..

Danke
bfuerchau
Beiträge: 88
Registriert: Mo 7. Mai 2018, 18:09

Fr 8. Feb 2019, 09:33

Ein Datenbankabgleich ist technisch zwar durchaus denkbar, performancemäßig aber absolut unverträglich.
Erst mal benötige ich eine Kopie der Datenbank (Platz?) und entsprechende Logik der Vergleiche für Insert/Update/Delete (klassische "Mehrwegeeingabe").
Laufzeit? Ich benötige z.B. für die Kopie einer 40GB Datenbank Tabelle für Tabelle und Zeile für Zeile bei 4 Threads parallel ca. 8 Stunden. Dabei werden z.T. bis zu 12.000 Inserts/Sekunde erreicht.
Diese Kopie muss ich immer mal dann machen lassen, wenn der Backup wieder mal streikt. Die zeilenweise Kopie funktioniert allerdings bisher immer.

Ich denke, ein Datenbankvergleich wird da noch erheblich länger benötigen.

Triggerbasierte Aktionen sind da erheblich effektiver. Zumal ich mich auf die relevanten Informationen stürzen kann. Nicht jede Tabelle benötigt ein Log, nicht jede Feldänderung ist relevant. Somit kann ich je Tabelle individuell entscheiden, was tatsächlich benötigt wird.

Allerdings könnte hier durchaus Version 3.0 besser geeignet sein, da ich hier z.B. .NET-Programme, also externe Trigger aufrufen kann. Somit kann ich u.U. bei verschiedenen Tabellen die selben Trigger aufrufen und aus Performancegründen das Schreiben in die 2. Datenbank asynchron über Threads weiterleiten.
vr2
Beiträge: 46
Registriert: Fr 13. Apr 2018, 00:13

Fr 8. Feb 2019, 14:06

bfuerchau hat geschrieben:
Fr 8. Feb 2019, 09:33
Allerdings könnte hier durchaus Version 3.0 besser geeignet sein, da ich hier z.B. .NET-Programme, also externe Trigger aufrufen kann. Somit kann ich u.U. bei verschiedenen Tabellen die selben Trigger aufrufen und aus Performancegründen das Schreiben in die 2. Datenbank asynchron über Threads weiterleiten.
Hast Du das mal gemacht? Von innen, übers neue OO-API oder klassisch von außen? In jedem Fall muss mit mehreren Connections und Threads hantiert werden.
dirk.schaefer
Beiträge: 3
Registriert: Mi 6. Feb 2019, 12:13

Fr 8. Feb 2019, 14:56

Bin für mein vorhaben an die 2.5er Version gebunden, werde wohl eine Prozedur schreiben, die mir die Trigger mit Leben füllt.. aber erst nach dem Wochenende ..
bfuerchau
Beiträge: 88
Registriert: Mo 7. Mai 2018, 18:09

Fr 8. Feb 2019, 18:42

Bisher habe ich mit 3.0 noch gar nichts genacht.
Da ich Trigger, Prozeduren und Funktionen gar nicht benötige um BI-Auswertungen zu machen, beschränkt sich alles auf Performance via Classic-Engine (Prozess je Connection).
Dabei werden die Userabfragen analysiert, ggf. Indizes erstellt in der Hoffnung, Firebird nimmt diese dann auch. Nach Analyse mit IB-Expert Personal (die letzte kostenlose Version) habe ich eine Trefferquote von ca. 90%. Das ist so in Ordnung.
Beim Laden von Daten werden die Indizes wieder deaktiviert (was so keine andere DB kann). Dies gibt beim Insert einen Performanceboost (wie schon mal geschrieben, durchaus 12.000 Inserts/Sekunde).

Meine größte Kunden-DB ist zur Zeit ca. 80GB mit über 500 Tabellen und sie läuft und wächst und läuft und wächst...
Mit 2.5.3 derzeit sehr stabil.

Von 3.0 verspreche ich mir daher nicht so viel da ich die OLAP-Funktionen wirklich nicht brauche. Das Einzige was interessant klingt ist die SMP-Unterstüzung per Thread und nicht per Prozess.
Aber da warten wir noch ein wenig ab.
Antworten