Konzept zur Datenbanktrennung.

[Pro_RJ]

Hallo,
Ich hab die Aufgabe bekommen, aus einer großen FirebirdDatenbank 2 kleine Datenbanken zu machen.
Der Grund dafür ist, das in einer Tabelle sich in 2.5 Jahren etwar 95 Mio. Datensätze angesammelt haben.
Die Aufgabe besteht darin, alle Datensätze die älter als z.B. 30 Tage sind in eine 2. Datenbank auszulagern und sie aus der OrginalDB zu löschen.

Jetzt die Frage wie könnte man sowas einfach und PFLEGBAR realisieren?
Das Hauptproblem liegt darin, das diese ausgelagerten Daten auch für Auswertungen benötigt werden.
1.
Gibt es die möglichkeit in einem Select Statement zu sagen

SQL-Code:

Select 
DatenbankA.Feld_1,DatenbankA.Feld_2,DatenbankA.Feld_3,DatenbankA.Feld_4,
DatenbankB.Feld_1,DatenbankB.Feld_1,DatenbankB.Feld_1
from DatenbankA,DatenbankB
where .....

2.
Besteht die möglichkeit in einem Trigger zu sagen Kopiere Datensatz von DatenbankA nach DatenbankB?

3. Wie kann man das in den Anzeigen im Programm steuern. Das mal daten aus DatenbankA angezeigt werden und mal aus DatenbankB?

Ich hoffe ich konnte mein Vorhaben einigermaßen verständlich darlegen.
Eventuell hat ja jemand schon ein paar Erfahrungen mit einem solchen system bzw. einer solchen Umstellung.
Für Gedankenanstöße,Ideen,Tip wäre ich sehr dankbar.

[Elvis]

Das mag sich jetzt ziemlich blöd anhören, aber eigentlich sollte diese Maßnahme nicht notwendig sein.

Wenn du die DB abfragst, sollten die Felde, die zum Filtern nötig sind, indiziert sein.
Indizierte Suchen bedeuten, dass die Größe der Tabelle nur noch eine sehr, sehr kleine Rolle spielt.

Magst du vielleicht mal die Abfragen zeigen, die euch Sorgen machen? Und vllt auch die Table DDLs dazu?
Eigentlich sollten wir einen Weg findne können wie du alles in einer DB halten kannst, ohne dass es langsam wird.

[s.h.a.r.k]

den grund verstehe ich auch nicht ganz? du wirst dir schon nicht jedes mal die komplette datenbank per SELECT ausgeben lassen? sondern eben nur die letzten paar tage, oder? selbst wenn du dann die tabelle aufsplittest wird es ja dadurch nicht besser, da dann ja auch wieder die riesen datenmengen bekommst, in so fern dein SELECT nicht wirklich eingeschränkt ist.

eine datenbank selbst *muss* mit solchen großen datenmengen umgehen können.

interessant wäre es wirklich so wissen, was ihr damit bewecken wollt und eben dafür einen, ich sag mal salop, besseren weg finden.

[Pro_RJ]

ja das ist absolut richtig, ich selber bin auch kein Freund von einer solchen Aufteilung. Dafür hat man ja ein ein-Dateien-system.
Das Problem ist die DB ist ca 30gb groß.
Jede Datensicherung dauert dem Kunden zu lange. Er brauch für Backup/Restore mittlerweile über 10 Stunden.
Bei dieser Datenbankaufteilung geht es um das Handling der DatenbankDatei an sich und weniger und das Reduzieren der Daten.
Das Daten suchen an sich dauert ja auch nicht lange da in dieser Tabelle nur über den PrimärIndex gelesen wird.
Bei dem Auslagern geht es darum die Hauptdatenbank um ca 20-25 GB zu verkleinern. Sodas das sichern und Backup/Restore der HauptDB an sich schneller geht.

[mkinzler]

Ab FB2.5 sind Abfragen auf andere Datenbanken bedingt möglich. Du könntest also per SP Daten aus 2 DBs zusammenfügen.

[Pro_RJ]

Zitat:

Zitat von mkinzler

Ab FB2.5 sind Abfragen auf andere Datenbanken bedingt möglich. Du könntest also per SP Daten aus 2 DBs zusammenfügen.

Geht der Zugriff auf 2 DBs schon im FB 2.1 oder erst ab 2.5?
oder hättest du da einen anderen Lösungsansatz für mein Problem?

Es geht darum, die Datenbankgröße zu reduzieren.Und daten auszulagern, die nicht ständig benötigt werden.

[mkinzler]

Ab 2.5 heisst ab 2.5

[s.h.a.r.k]

mal ganz dumm gefragt? was kann daran 10 stunden lang dauern :gruebel:

[Pro_RJ]

Zitat:

Zitat von s.h.a.r.k

mal ganz dumm gefragt? was kann daran 10 stunden lang dauern :gruebel:

Keine ahnung was daran so lange dauert. Wir machen das Backup Restore über TIBBackupservice/TIBRestoreservice Komponenten. Das sind die die im BDS2006 Standardmäßig drinne sind. Was jetzt genau an dem Vorgang lange dauert weis ich leider nicht?Aber ich schaue mal ob ich genaue Zeiten bekomme

[s.h.a.r.k]

weil ich die zeiten für sehr unrealistisch erachten, außer die sichtern auf disketten und müssen eben sehr viele davon immer reinschieben :D

jedenfalls bevor du die datenbank teilst würde ich mir auf jeden fall mal gedanken drüber machen, wie du das bisherige problem angehen kannst, denn deine software umzubauen, wegen sowas? erachte ich als ein bisschen fehl am platz. ich baue an ein auto auch keinen fünften oder sechsten reifen hin, nur weil andere platt sind. ich hoffe du verstehst was ich damit meine. denn es kann nicht normal sein, dass man 10 stunden oder auch nur 2 für ein 30gb backup braucht. oder sehe ich das falsch? :gruebel:

[Pro_RJ]

Das Problem ist, was will ich in der Software optimieren?
So wird ein Backup ausgeführt:

Delphi-Quellcode:

Function Backup_Ausfuerhen(BackSer : TIBBackupservice;DBFile,BackupFile1 : String; Memo1 : TMemo;ProtocolGes1 : TProtocol;ServName : String;Pan : TPanel;MSG,Garb : Boolean) : Boolean;
Var i   : Integer;
    ok  : Boolean;
    //Anz : String;
    //Fo : TForm;
Begin
  //Fo := NIL;
  if Memo1 <> NIL then
  Begin
    //if Memo1.Owner IS TFOrm then Fo := TForm(Memo1.Owner);
    Memo1.Font.Size := 8;
  end;


  BackupFile1 := Copy(DBFile,1,Length(DBFile)-4)+'_Backup.gbk';
  i := 0;
  with BackSer do
  begin
    if Pan <> NIL then
    Begin
      Pan.Visible := true;
      Pan.caption := 'Backup wird ausgeführt';
      Pan.Refresh;
    end;
    Params.Clear;
    Params.Add('user_name='+G_DB_user);
    Params.Add('password='+G_DB_kw);
    Protocol       := ProtocolGes1;
    ServerName     := ServName;
    Verbose        := True;


    if Garb = true
    then Options        := []
    else Options        := [NoGarbageCollection];

    //Options        := [NoGarbageCollection];

    DatabaseName   := DBFile;   // ersetzen
    LoginPrompt    := False;
    Active         := True;
    BackupFile.Clear;
    BackupFile.Add(BackupFile1);

    if Memo1 <> nil then Memo1.Lines.Clear;
    try
      ServiceStart;
      ok := True;
    except
      on E:exception do
      Begin
        if MSG then  Showmessage(e.Message);
        FehlerProtokollSchreiben(13,[e.Message],[],[]); // Fehler beim Backup
        ok := False;
      end;
    end;
    if ok = true then
    begin
      try
        While not Eof do
        Begin
          INC(i);
          if Memo1 <> nil then Memo1.Lines.Add(AuffuellenAufN(X(i),4)+': '+GetNextLine);
          Application.ProcessMessages;
        end;
        ok := True;
      except
        on E:exception do
        Begin
          if MSG then  Showmessage(e.Message);
          FehlerProtokollSchreiben(13,[e.Message],[],[]); // Fehler beim Backup
          ok := False;
        end;
      end;
    end;
    try
      PfadPruefUAnleg(G_Path + Log_Datei_BackUp_Restore(1));
      if Memo1 <> nil then Memo1.Lines.SaveToFile(G_Path + Log_Datei_BackUp_Restore(1));
    except
    end;
    if Memo1 <> nil then Memo1.Lines.clear;
    Active := False;

    if Pan <> nil then
    Begin
      Pan.caption := 'Backup wurde ausgeführt';
      Pan.Refresh;
    end;
  end;
  result := ok;
end;

Sicherlich könnte man durch bessere Hardware nochmal Zeit rausholen aber an der Grundsätzlichen Programierung kann ich nicht viel ändern. oder Seht ihr in den Text noch was was ich anderes machen könnete?

Das Problem ist halt, das das Handling besser werden soll --> und das geht nur mit ner Kleineren DB.
Sicherlich ist aber der Ansatz, das ich die Daten die ich nicht immer brauche archiviere ganz ok.
Ich hab auf meinem Schreibtisch ja auch nicht die Akten der letzten 10 Jahre.

[mikhal]

Sichert der Kunde seine Datenbank über eine Leitung von einem anderen Standort?. Bei uns wird eine Sicherung zweier Datenserver über eine 2 MBit Leitung realisiert, dabei dauert die Sicherung einer Oracle-Datenbank mit etwa 2,5 GByte Tablespace tatsächlich etwa 5 Stunden.

Grüße
Mikhal

[Pro_RJ]

der sichert einmal über eine Normale WindoofKopie im Explorer und auf USBPlatte was aber "Normal" schnell geht.

[Billa]

Muß die Sicherung wirklich innerhalb des Programms laufen? Was ist mit gbak? Das hat den Charme, daß man nicht auf das Backup warten muß, es läuft transaktionsgesteuert und erzeugt einen schönen Schnappschuss ... im übrigen gebe ich s.h.a.r.k. und elvis Recht: Ich würde das Konzept überdenken.

[mkinzler]

Die Komponente verwendet m.W. gbak

[Pro_RJ]

Ich hab gerade nochmal mit meinem Cheff gesprochen.
Die Aufgabenstellung lautet: das Backup/Restore soll in 1.5-2.5 Stunden fertig sein.
Wie ich das anstelle hat er mir eben frei gestellt.
Das Backup/Restore wird zu einer Zeit gemacht, wo niemand auf der Datenbank arbeitet.
Welchen Lösungsansatz könntet ihr mir ür diese Aufgabenstellung geben?

[eddy]

Wie wäre es denn mit der Version:
2. PC hinstellen (muß auch nicht der neueste sein), Datenbank packen und auf Festplatte des Sicherungs-PC speichern.
Beim Packen werden die meisten Datenbanken auf 10 % zusammengeschrumpft.

mfg
eddy

[Pro_RJ]

Zitat:

Zitat von eddy

Wie wäre es denn mit der Version:
2. PC hinstellen (muß auch nicht der neueste sein), Datenbank packen und auf Festplatte des Sicherungs-PC speichern.
Beim Packen werden die meisten Datenbanken auf 10 % zusammengeschrumpft.

mfg
eddy

:gruebel:
und wo liegt die Zeitersparniss beim Backup/Restore?

[Elvis]

Teste mal ein Backup auf eine andere Platte auf dem gleichen System wie der FB Server.
Oder eine andere Maschine, die dann aber mindestens mit GBit LAN mit dem FB Server verbunden ist. (gbak läuft dann auf der anderen Maschine)

Woher wisst ihr überhaupt, dass ein Backup/Restore(B&R) so lange dauert? :zwinker:
Kann es sein, dass ihr das öfters macht? Normal sollte das nur notwendig sein, wenn irgendetwas Schlimmes passiert ist...

Viele machen den Fehler und verwenden B&R um die DB files kleiner zu kriegen, oder ganz schlimm: offene Transaktionen zu schließen.
Firebird wird ein DB file niemals von sich aus schrumpfen lassen, und das macht auch Sinn:
Denn wenn die Datei einmal so groß wurde, wird sie wieder so groß werden. Wenn FB den Platz vorreserviert muss keine Kopie der Datei angefertigt werden (denn genau das passiert wenn Dateien wachsen) und die Dateifragmentierung bleibt auch noch im grünen Bereich.

@Pro_RJ
Die Erssparnis liegt darin, dass du den DB Server in der Zeit im Readonly Modus weiterlaufen lassen könntest.
Allerdings riecht das ein wenig "fishy" nach einer VB'ler-Lösung. ;-)

[Der Jan]

Nur so als Gedanke... Setz mal Verbose := false
Oder brauchst du die detaillierten Ausgaben? Das kann ganz schön bremsen, wenn die Leitung vlt belastet oder nicht so dick ist...

[eddy]

Hallo Pro_RJ,

dann verpaß Euren Datensätzen ein Feld vom Typ TDateTime und vermerke darin das Datum der letzten Änderung.

Anschließend nur noch die geänderten Datensätze kopieren. Ihr werdet ja wohl recht selten zwischen 2 Sicherungen alle 95 Mio Datensätze ändern.

mfg
eddy

[mkinzler]

man könnte es auch mal das neue nbak (inkrementell) Testen

[Pro_RJ]

Um das Kopieren der Datensätze mache ich mir wenig sorgen :) Es werden nur am anfang einmal rüber kopiert.
Danach sind es vieleicht noch 1 Mio Daten aber das ist nicht das problem.

Das Backup/Restore machen wir eigentlcih nur, da auf grund des hohen Datendurchsatz pro Tag (ca. 100.000 - 150.000) die Datenbank immer langsamer wird.

Wie würde ein solches NBak funtzen?

[hoika]

Hallo,

ich würde auf jeden Fall mal gbak testen,
um die "tatsächliche" Zeit eines Backup/Restore zu prüfen.

gbak -b data.fdb data.fbk -user bla -pass bla


Auf jeden Fall kein -g (garbage)


Heiko

[grenzgaenger]

denke, das erste was du machen solltest ist nicht so viel output zu schreiben.. und wenn, dann vorher den update disables (memo.beginupdate, .endupdate), das bremst ungemein.

wie list denn die verfügbarkeit der DB? kann man die mal abhängen und da einfach ein Offlinebackup (kopie) ziehen? ggf. noch über ein RAD0, die eine platte bei minimalen unterbruch abhängen und von der shadowdisc das offline backup ziehen...

[mkinzler]

Zitat:

Wie würde ein solches NBak funtzen?

nbak ist eine neuere Version von gbak, welche auch inkrementielles Backup beherrscht.

[Pro_RJ]

ok das mit dem Memo kann ich mal testen.Zu der Zeit wo das B/R gemacht wird ist auf der Hdd nichts los.da zu dieser zeit niemand in der Firma ist bzw. niemand auf dem server arbeitet.


edit: Ab wann/ab welcher version vom FB ist dieses Verfügbar

[grenzgaenger]

dann probier mal ein offline backup ...

sollte deutlich schneller sein. wenn das dann immer noch zu langsam ist, mal die datenbank reorganisieren.. resp. backup --> platte initialiseren oder gleich austauschen --> datenbank zurückspielen... so, dass sie nicht mehr fragmentiert ist. alleine das sollte schon beträchtliches an geschwindigkeit bringen...

[Pro_RJ]

wie kann man ein solches Offline Backup machen?

Kann man eine solche fragmenierung der DB nich auch mit einem gute DefargTool beheben?

[grenzgaenger]

datenbank runterfahren ... und dann "Copy" oder "XCopy" oder "Backup" oder... verwenden ...

[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