Seite 1 von 1

Änderungsprotokoll

Verfasst: Mi 6. Feb 2019, 12:25
von dirk.schaefer
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

Re: Änderungsprotokoll

Verfasst: Mi 6. Feb 2019, 16:46
von bfuerchau
Nein, den gibt es nicht.

Re: Änderungsprotokoll

Verfasst: Do 7. Feb 2019, 00:09
von vr2
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

Re: Änderungsprotokoll

Verfasst: Do 7. Feb 2019, 09:47
von dirk.schaefer
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

Re: Änderungsprotokoll

Verfasst: Fr 8. Feb 2019, 09:33
von bfuerchau
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.

Re: Änderungsprotokoll

Verfasst: Fr 8. Feb 2019, 14:06
von vr2
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.

Re: Änderungsprotokoll

Verfasst: Fr 8. Feb 2019, 14:56
von dirk.schaefer
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 ..

Re: Änderungsprotokoll

Verfasst: Fr 8. Feb 2019, 18:42
von bfuerchau
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.