[Firebird 2.1] Statement zu einer offenen Transaktion finden

[alzaimar]

Ich habe hier eine Firebird-DB, die mit der Zeit immer langsamer wird. Nach und nach kristallisiert sich heraus, das offene Transaktionen dafür verantwortlich sind. Nun gibt es seit FB 2.1 diese tollen MON$-Tabellen, mit denen man ziemlich viel über den aktuellen Zustand von FB heraus bekommt.

Frage: Wie bekomme ich alle Statements zu einer bestimmten Transaktion heraus? Geht das mit den MON$-Tabellen?

[IBExpert]

mit IBExpert den Menüpunkt services-database monitoring öffnen und nachschauen (leider nur in der vollversion :-)

wenn du MON$ATTACHEMNTS, MON$STATEMENTS und MON$ATTACHEMENTS öffnest sind die aber auch so relativ selbsterklärend, jedenfalls ide wichtigen Teile.
und ein Blick in die Firebird 2.1 Releasenotes klärt auch den Rest auf :-)

[alzaimar]

Toll, danke... Falls ich nicht weiterkomme, trudelt ne Bestellung für die VV ein.

[Elvis]

Um solche Schlawiner rauszufinden setze ich ab & zu das unten ab.
Die "Abfrage" gibt dir oben die älteste aktive Transaktion und zu jeder Transaktion den host, prozessname, user, etc.
Alles schön untereinander, so dass man nicht wie blöde nach links und rechts scrollen muss. ;-)

SQL-Code:

execute block 
returns
(
  Kind varchar(30),
  ID bigint,
  Time_Stamp timestamp,
  Data blob sub_type text,
  State integer  
)
as 
  declare userName varchar(256);
  declare dbName   varchar(256);
  declare tid bigint;  
  declare aid bigint;
begin
  for select 
    mon$timestamp, 
    mon$state, 
    mon$transaction_id,
    mon$attachment_id
  from 
    mon$transactions t 
--  where 
--    mon$transaction_id = t.mon$oldest_active
  order by
    case when mon$transaction_id = t.mon$oldest_active then
      0
    else
      1
    end,
    mon$transaction_id
  into 
    :Time_Stamp, :State, :ID, :AID 
  do
  begin
    Data = null;
    Kind = 'Transaction';
    suspend;
    TID = ID;

    for select 
      trim(mon$remote_address)
      ||' -> '|| trim(mon$remote_process), 
      mon$remote_pid, 
      mon$user, 
      mon$attachment_name    
    from 
      MON$ATTACHMENTS
    where
      mon$attachment_id = :AID
    into 
      :Data, :ID, :userName, :dbName
    do
    begin
      State = null;
      Kind = 'Process';
      suspend;
      
      ID   = null;
      Kind = 'Database';
      Data = dbName;
      suspend;
      
      Kind = 'User';
      Data = userName;
      suspend;
      
      Kind = 'Statement';
      
      for select 
        mon$statement_id,
        mon$timestamp,
        mon$sql_text,
        mon$state
      from 
        MON$STATEMENTS
      where 
        mon$transaction_id = :tid
        and mon$attachment_id = :aid
      into 
        :ID, :Time_Stamp, :Data, :State 
      do
        suspend;
    end
  end
end

[Chemiker]

Hallo,

irgendwie kann ich den Menüpunkt: service-Database monotoring nicht finden. Ich besitze eine gekaufte Version, oder ist dieser Menüpunkt erst in einer neuern IBExpert-Version vorhanden?

Bis bald Chemiker

[IBExpert]

Zitat:

Zitat von Chemiker

Hallo,

irgendwie kann ich den Menüpunkt: service-Database monotoring nicht finden. Ich besitze eine gekaufte Version, oder ist dieser Menüpunkt erst in einer neuern IBExpert-Version vorhanden?

Bis bald Chemiker

wichtig: in der Datenbankregistrierung muss als Typ FB21 gewählt sein

[Chemiker]

Hallo IBExpert,

ist damit gemeint die Serverversion: Firebird 2.1?

Bis bald Chemiker

[IBExpert]

Zitat:

Zitat von Chemiker

Hallo IBExpert,

ist damit gemeint die Serverversion: Firebird 2.1?

Bis bald Chemiker

ja

[Chemiker]

Hallo IBExpert,

danke, hat funktioniert Menü-Punkt gefunden.

Bis bald Chemiker

[alzaimar]

Hi,

Erfolgsmeldung :dancer2:

Die Tipps aller und speziell die Query von Elvis haben mir geholfen. Ich verwende dbExpress und habe einige TSQLQuerys offen gehalten. Die habe ich durch TSimpleDataset ersetzt, wobei ich noch nach dem Einlesen der Daten die interne Connection wieder geschlossen habe.

Anschließend hatte ich 0-2 aktive Transaktionen, anstatt 6 (und einem Uralt-Übeltäter)

Hintergrund: Zwischengespeicherte Messwerte müssen an einen Client übertragen werden. Manchmal isser da, manchmal eben nicht. Wenn er nicht da ist, werden die Daten in einer FB-DB gepuffert. Nun teste ich den Extremfall, das der Client nach einigen Tagen erst wieder online und die DB in der Zwischen auf 500MB angeschwollen ist.

Ich lese also jeweils 10000 Messwerte aus der DB ein und schicke diese in Häppchen à 70 Stück (Limitierung des Clients) mit XML an den Client. Diese 10000er TSQLQuery war aber die ganze Zeit offen (klar, ich muss ja alle Daten verschicken).

Die Messapplikation hat aber in der Zwischenzeit kräftig neue Messergebnisse fabriziert und diese in die DB geschrieben. Und genau diese Schreiboperation wurde immer langsamer, da obige (TSQLQuery)-Transaktion offen war.

So erkläre ich mir das jedenfalls. Was ich allerdings 'gewöhnungsbedürftig' finde, ist die Tatsache, das eine Query offensichtlich eine Transaktion öffnet. Aber gut, wenn das so ist.

PS: Ein sehr hübsches Monitoring-Tool ist von 'Sinática'. Ich mach da jetzt keine Werbung, weil das Tool nicht sonderlich viele Features hat, aber schön anzusehen ist es allemal. Es lohnt -aus rein ästhetischen Gesichtspunkten- sich das Teil mal anzuschauen.

[mkinzler]

Zitat:

So erkläre ich mir das jedenfalls. Was ich allerdings 'gewöhnungsbedürftig' finde, ist die Tatsache, das eine Query offensichtlich eine Transaktion öffnet. Aber gut, wenn das so ist.

Das ist halt das Tribut was man der Transaktionssteuerung von FB zollen muss

[Elvis]

Zitat:

Zitat von alzaimar

Die Tipps aller und speziell die Query von Elvis haben mir geholfen...

:-)
btw: diese Art von anonymen Fire-and-Forget Code-Block, der eine Ergebnismenge liefert, meinte ich im anderen Thread als einer der Vorteile von FB.

Zitat:

So erkläre ich mir das jedenfalls. Was ich allerdings 'gewöhnungsbedürftig' finde, ist die Tatsache, das eine Query offensichtlich eine Transaktion öffnet. Aber gut, wenn das so ist.

Naja, innerhalb eines Webrequest, würdest du doch gerne alle Infos atomisch haben, oder? Also nicht dass eine Hälfte der Antwort mit anderen Werten generiert wird.
Firebird nimmt Transaktionen halt absolut wörtlich. Kann nervig sein. Aber unterm Strich wäre ich oft froh wenn andere (teure!) DBMS' auch nur halbwegs so viel von Record-Versionierung verstehen würden.

Zitat:

PS: Ein sehr hübsches Monitoring-Tool ist von 'Sinática'. Ich mach da jetzt keine Werbung, weil das Tool nicht sonderlich viele Features hat, aber schön anzusehen ist es allemal. Es lohnt -aus rein ästhetischen Gesichtspunkten- sich das Teil mal anzuschauen.

Für genau den Fall reicht mir so eine Query wie weiter oben.

Wer mehr, präzises Monitoring will muss eben die Maschine untendrunter wegnehmen:
Wir haben (fast) alle unsere in-house Server virtualisiert. Und die Software von VMWare erlaubt es auch wunderschön zu sehen welcher Server wann wie welche Peaks in Disk I/O, Speicher, aktiver Thread-Zahl, CPU Auslastung etc hat.

[alzaimar]

Bleibt festzuhalten, das man die (Transaktions-)Philosophie von Firebird verstehen muss, um damit gut und performant zu arbeiten. Wenn man sich an die Regeln hält, scheint es ja Spass zu machen.

Allerdings ist der eigentliche Hammer der hier:

Nachdem ich also diese blöde Pufferung endlich stabil und performant hinbekommen habe....

... wurde sie vom Kunden gekickt.

:wall:

[mkinzler]

Zitat:

Nachdem ich also diese blöde Pufferung endlich stabil und performant hinbekommen habe....

... wurde sie vom Kunden gekickt.

Wegen den Performence-Problemen oder hatte das andere Gründe?

[alzaimar]

Es gab ja keine Performanceprobleme mehr: Das System hat selbst einen simulierten Ausfall von einer Woche mit Nonstop-Befeuerung des Clients und gleichzeitigem Puffern der Daten anstandslos hingenommen. Nach meinem Redesign des kompletten Apparates (aus Zeitgründen habe ich keine bessere Pufferung On-Demand gebaut, sondern das existierende System verwendet) ist die Performance um den Faktor 2 gestiegen...

Allerdings ist denen klar geworden, das ihr Client in die Knie geht, wenn er derart massiv mit Daten befeuert wird *MitderFaustaufdenTischTrommelundLachendAmBodenLie g*.

An sich ist das schon peinlich (für meinen Auftraggeber, dessen Kunde den Rückzieher gemacht hat), aber es ist nicht wild: Ich werde nach Aufwand bezahlt und nicht, ob der Kunde das abnimmt...

[mquadrat]

Insofern kannst du das unter dem Punkt "bezahltes Lernen" abhaken ;)

[mschaefer]

In dem Zusammenhang stellt sich mir die Frage: Wie kann ich noch offene Transaktionen serverseitig löschen ?

Grüße in die Runde // Martin