Konzept zur Datenbanktrennung.

[Pro_RJ]

Das B/R wir zur zeit so gemacht:
Datenbank Shutdown --> Datenbank in einem Neuen Verzeichniss sichern --> Backup auf die Datenbank --> Restore auf die Datenbank.

[pixfreak]

Moin zusammen,

nur mal eine Frage: Wenn die Datenbank nach 100.000 Einträgen langsamer wird, könnte es vielleicht an einer großen Summe offener Transaktionen liegen?

Versuch doch mal die Statistik der Datenbank abzurufen und vergleiche mal die Werte von Next Transaction und Oldesd active Transaction. Wie groß ist dort der Unterschied, nachdem die Datenbank langsamer geworden ist? Ein sehr großes Delta würde auf eine Menge offener, nicht beendeter Transaktionen liegen. Kannst Du die Werte mal posten?

VG Pixfreak

[mjustin]

Zitat:

Zitat von pixfreak

Moin zusammen,

nur mal eine Frage: Wenn die Datenbank nach 100.000 Einträgen langsamer wird, könnte es vielleicht an einer großen Summe offener Transaktionen liegen?

Versuch doch mal die Statistik der Datenbank abzurufen und vergleiche mal die Werte von Next Transaction und Oldesd active Transaction. Wie groß ist dort der Unterschied, nachdem die Datenbank langsamer geworden ist? Ein sehr großes Delta würde auf eine Menge offener, nicht beendeter Transaktionen liegen. Kannst Du die Werte mal posten?

VG Pixfreak

Genau, lange laufende Transaktionen sind die wahrscheinlichste Ursache für solche zunehmenden Performanceprobleme, die sich statt durch Backup & Restore genausogut durch einen Neustart (aber nur vorübergehend) beheben lassen.

Backup & Restore braucht man vielleicht alle paar Monate mal. In der Regel sichert man nur (wenn die Datenbank sehr gross ist, z.B. jede Nacht). 'Fragmentierungsprobleme' der Datenbank kann man eigentlich ausschliessen.

Man kann durch Abfragen der Performancetabellen auch anzeigen lassen, welche Connections die lang laufenden Transaktionen verursachen. Die dahinterstehenden Programme bei Performanceproblemen neu zu starten kann dann eine 'erste Hilfe'-Massnahme sein.

[Pro_RJ]

Kann ich die Anzahl der "offenen" Transactionen auslesen? bzw. einen vergleich erzeugen, wieviele geöffnet sind und viele wieder geschlossen worden sind?

Zum einlesen:
Es sind ca 840 Textdateien empfangen und eingelesen.Das ganze läuft in 5 Seperaten Threads ab die Paralel arbeiten.
Jede Datei wird dabei von einem Eigenen Thread bearbeitet.
Diese Thread haben eine eigene Datenbankverbindung und eine Transaction.Der FBServer ist als Classicserver installiert (ein Prozess pro DBVerbindung)

Rein ProgrammTechnisch kann ich die Transactionen rellativ einfach überwachen.
Das Gurndkonzept sieht volgendermaßen aus

Delphi-Quellcode:

....
Ok := False;
Try
  StartTransaction;
  ArbeiteWasZuTunIst; 
  ok := True
except
  ok := False
end
if OK 
then Commit 
else Rollback;
....

in "ArbeiteWasZuTunIst" wird keinerleit Transsteuerung gemacht.
hier wird ausschließlich Insert,Update oder Select gemacht aber alles ohne die Trans zu bestätigen.
Alle Componenten haben zu 100,00% diese Transaktion drin.
Also rein Programmtechnisch kann da keine Trans offen bleiben


PS: es ist nicht so das die DB schon nach einer nacht deutlich langsamer wird.
Das ist ein schleichender Prozess der sich nach 2-3Wochen spührbare Auswirklungen zeigt.
Kann es eventuell auch sein, das diese Verlangsamung garnicht von dieser großen eingelesenen Datenmenge zusammen hängt?

[Elvis]

Zitat:

Zitat von Pro_RJ

in "ArbeiteWasZuTunIst" wird keinerleit Transsteuerung gemacht.
hier wird ausschließlich Insert,Update oder Select gemacht aber alles ohne die Trans zu bestätigen.
Alle Componenten haben zu 100,00% diese Transaktion drin.
Also rein Programmtechnisch kann da keine Trans offen bleiben

Dadurch werden implizite Transaktionen gestartet.
Firebirds großer Vorteil ist nämclh gleichzeitig auch seine Achillesferse: Versionierung von Datensätzen und wirklich Snapshottransaktionen.
In den Moment, in dem du ein Select ohne eine Transaktion ausführst, wirst du implizit eine Snapshot-Transaktion der egsamten DB bekommen.
Solange du diese nicht beendet hast, muss der DB Server für JEDE Änderung ab dem Moment zusätzliche Versionen dieses Datensatzes und der Metadaten aller Tabellen, SProcs, ... erzeugen.
Bei den Firebird-Komponent für Delphi musst du IMMER eine explizite Transaktion mitschleifen und selbst im beeenden um das zu verhindern.

btw, Snapshots sind oft auch etwas sehr cooles, da du auf die Art konsitent auch mal 3 Statements hintereinander ausführen kannst. Egal ob mittendrin jemand eine Zeile geändert hat.

[alzaimar]

Ich habe mir die drei Seiten nicht durchgelesen, aber ich glaube, Du solltest dich mit den Begriffen 'Datawarehouse' und 'Business intelligence' vertraut machen.

Es ist ein Märchen, das heute Datenbanksysteme, und seien sie noch so potent, immer sowohl transaktionale Datensammler als auch potente Statistikerzeuger sein können (bei entsprechendem Datenaufkommen, wohlgemerkt). In der einschlägigen Literatur wird als Standardvorgehensweise eine Trennung von operationalen Daten und sog. dispositiven Daten vorschlagen.

Operative Daten sind die Daten, die für die tägliche Arbeit benötigt werden. Bei einem Großhandel wären das z.B. Kundenstamm, Produkte, Aufträge, Lager, aktuelle Inventur.
Dispositive Daten sind die Daten, die aus den operativen Daten im Laufe der Zeit anfallen (History), oder speziell aufbereitete Daten (z.B. tägliche Zusammenfassungen oder eine Inventurhistory als periodischer Snapshot) und für Statistiken für das Managament herangezogen werden. Diese Daten werden aus dem laufenden Betrieb extrahiert, teilweise zusammengefasst, harmonisiert und fehlerbereinigt (über "ETL-Prozesse").

Gut, wir haben dann also zwei Datenbanken, das ODS (Operational Data Store), mit dem man täglich arbeitet, das aber Daten vergisst (wenn sie nicht mehr benötigt werden), und ein Datawarehouse (bestehend aus mehreren Datamarts) die bestimmte Daten in mehrdimensionalen Datenwürfeln bereithalten. aus diesen Würfeln (Datacubes) können dann geschäftsentscheidende Statistiken extrahiert werden.

Das ODS ist i.d.R. in der 3NF ('Snowflag-Design'), wohingehend ein DWH/DM hochgradig redundant und nur auf performance hin ausgelegt ist ('Star-Design').

Im ODS sollten laufend die ETL-Prozesse (transaktional oder periodisch) Daten in die einzelnen Datamarts überführen und das ODS schlank halten.

So das mal als Überblick. Hoffe, das ich nicht am Thema vorbeigeredet habe.

[Elvis]

Zitat:

Zitat von alzaimar

Ich habe mir die drei Seiten nicht durchgelesen, aber ich glaube, Du solltest dich mit den Begriffen 'Datawarehouse' und 'Business intelligence' vertraut machen.

Ich denke nur nicht, dass das hier wirklich notwendig ist. Eine Firebird DB kann durch die hunderte bis 10-Tausenden an Recordversionen, die durch offenstehende Transaktionen generiert werden, um Größenordnungen größer werden als sie wirkich ist.
Eine klassische DW-Lösung nicht-operativer Daten ist immer möglich. Aber sein Problem wäre damit nicht gelöst. Nur die Symptome für die Transaktionsbugs wären gemildert.

Da er keinen Middle-Tier einsetzt dürfte ein Union-Select aus 2 Firebird Datenbanken für seine bestehende Software ein wenig interessant werden.
IMO basieren die Delphi-Reporting tools doch alle auf Datasets, oder? :gruebel: (bin hier ganz schön lange raus...)

[pixfreak]

Zitat:

Zitat von Pro_RJ

Kann ich die Anzahl der "offenen" Transactionen auslesen? bzw. einen vergleich erzeugen, wieviele geöffnet sind und viele wieder geschlossen worden sind?

Moin,

ja da gibt es mehrere Wege. Der einfachste ist, meld dich doch mit dem mitgeliefertem isql an deiner Datenbank an.
Danach kannst Du mit show database; eine einfache Statistik bekommen. (Vielleicht dann mal posten?)

Programme wie z.B. IBExpert in der personellen Version kann dir die Statisik auch bereits anzeigen.

VG Pixfreak

[alzaimar]

Zitat:

Zitat von Elvis

Aber sein Problem wäre damit nicht gelöst. Nur die Symptome für die Transaktionsbugs wären gemildert.

Oh, Bugs.. Hätte vielleicht doch richtig lesen sollen :oops:

[mjustin]

Zitat:

Zitat von Pro_RJ

Kann ich die Anzahl der "offenen" Transactionen auslesen? bzw. einen vergleich erzeugen, wieviele geöffnet sind und viele wieder geschlossen worden sind?

Monitoring in FireBird 2.1:

http://www.firebirdsql.org/rlsnotesh...ml#rnfb210-mon

Beispiele:

Select * from MON$DATABASE

Wichtige Daten zu den Transaktionen stehen in

MON$OLDEST_TRANSACTION (OIT number)
MON$NEXT_TRANSACTION (next transaction number)

Alle aktiven Transaktionen (ausser eigene)

SELECT MON$ISOLATION_MODE
FROM MON$TRANSACTIONS
WHERE MON$TRANSACTION_ID <> CURRENT_TRANSACTION

Abfrage der aktuell aktiven Statements

SELECT ATT.MON$USER,
ATT.MON$REMOTE_ADDRESS,
STMT.MON$SQL_TEXT,
STMT.MON$TIMESTAMP
FROM MON$ATTACHMENTS ATT
JOIN MON$STATEMENTS STMT
ON ATT.MON$ATTACHMENT_ID = STMT.MON$ATTACHMENT_ID
WHERE ATT.MON$ATTACHMENT_ID <> CURRENT_CONNECTION
AND STMT.MON$STATE = 1


Eventuell ist es aber auch eine stetig steigende Anzahl der geöffneten Verbindungen? Wenn der Server im Classic Mode läuft, müsste man die Prozesse auf Systemebene sehen können. Oder über die MON$ATTACHMENTS (connected attachments) Tabelle, je Connection ist darin ein Datensatz.

Viele Grüße

Michael Justin