FirebirdSQL
Zur Datenhaltung verwendet OrgaMon den freien Datenbank Server firebird SQL.
Installation
(für Mehrprozessor-Systeme:) CS- Classic Server unter Linux
rpm -vv -i Firebird..CS.rpm chkconfig --add xinetd rcxinetd restart
(für Einprozessor-Systeme) SS- Super Server unter Linux
rpm -vv -i Firebird..SS.rpm chkconfig --add firebird rcfirebird restart
- Sicherheitseinstellungen
Zunächst muss dem firebird SQL Server erlaubt werden auf die typischen Dienstbereiche der Platte zuzugreifen: /srv Dort können dann auch verschiedene Volumes eingehängt werden. Dazu muss jedoch der schreibende Zugriff erst mal ermöglicht werden:
joe /opt/firebird/firebird.conf DatabaseAccess = Restrict /srv
Bedeutung: dem FirebirdSQL Server ist der Datenbankzugriff nur in /srv und allen weiteren Unterverzeichnissen möglich.
- SYSDBA Passwort
die Zeiten, dass masterkey das Out-off-the-box Passwort für firebird war sind lange vorbei. Vielmehr befindet sich das im Rahmen der Installation frisch erzuegte Passwort des Datenbank Administrator in der Datei
/opt/firebird/SYSDBA.password
Shell Befehle
netstat --numeric -p | grep fb_inet // anzeigen aller an firebird connectierten
// (eigentlich fb_inet_server, jedoch wird der volle Name oft durch
// netstat abgeschnitten)
ps -A | grep fb // anzeigen aller firebird - Prozesse
lsof <firebirddatenbankdatei> // anzeigen aller User auf einer firebird Datenbank
lsof -p <PID eines fb_inet_servers> // anzeigen der Dateien, die der Prozess offen hat
// es wird auch angegeben wer (welcher remote) connectiert ist.
/opt/interbase/bin/ibmgr -shut -user "SYSDBA" -password "masterkey" /opt/interbase/bin/ibmgr -start -forever
Hintergrundinfo
Im Moment setze ich auf SMP Systemen den "Classic Server (CS)" ein. Es bedeutet, es läuft kein einzelner Dämmon, sondern pro Verbindung wird ein Server-Prozess neu gestartet (fb_inet_server). Die Synchronisation erfolgt über Datei-Locks der jeweiligen Datenbank-Datei mit Hilfe eines monolitischen Prozesses (fb_lock_mgr). Bei dem Hochstarten der einzelnen Server-Prozesse hilft xinetd (ehemals inetd). Dies ist ein Programm, das dabei Hilft auf einzelnen Ports eines Linux-Systems Dienste anzubieten. Man beschreibt seinen Dienst in einer config-Datei, wenn dann ein Verbindungsversuch auf dem angegebenen (und von xinetd angebotenen) Port stattfindet startet xinetd das angegebene Programm und leitet die Anfrage an dieses Programm weiter.
SMP Regeln
- verwende den Classic Server
- stelle die DefaultDbCachePages auf eine KLEINE Zahl (=75)
Probleme mit Windows XP SP 2
Langsamer Applikationsstart seit Installation des Windows XP Service Pack 2
Voraussetzung: (Ursächlich ist das Service Pack 2 von Windows XP)
Problem:
Bis zu 10 Sekunden längerer Verbindungsaufbau bei Konnektierung auf den Linux Firebird Classic Server.
Lösung:
Die Firewall des Service-Pack 2 blockiert alle eingehenden Verbindungsversuche von aussen. xinetd versucht bei aktiviertem log_on_success = USERID den erfolgreichen Verbindungsaufbau zum firebird-dienst zu protokollieren. Dazu läuft ein Protokoll ab zur Verifizierung der Benutzer Identiät auf Port 113.
mehr Info auf http://grc.com/port_113.htm RFC auf http://www.faqs.org/rfcs/rfc1413.html
Dieser ist geblockt, xinetd gibt nach 3 maligem Versuch auf. log_on_success und log_on_fail sollte entfernt werden, oder auf HOST umgestellt werden:
joe /etc/xinetd.d/firebird // // Folgende beide Zeile so verändern oder ganz auskommentieren // log_on_success = HOST log_on_fail = HOST // ps -A | grep xinetd // merke Dir den PID des xinetd kill -SIGUSR2 <PID des xinetd> // // dadurch wird xinetd gezwungen seine konfiguration neu einzulesen. //
Alternative: öffnen des Port 113 auf den Windows XP Clients (von mir nicht empfohlen)
sollten Sie schon Windows XP Serivce Pack 2 erhalten haben, so deaktivieren Sie bitte die Anti-Virus Warnung:
Deaktivieren der Virenschutz-Warnmeldung
Start->Systemsteuerung->Sicherheitscenter->Empfehlungen->unteren Haken ankreuzen
es sollte sich folgendes Bild ergeben:
Firewall: aktiv. Automatische Updates: aktiv. Virenschutz: nicht überwacht.
OrgaMon wird geblockt: (wegen Webshop XML-RPC-Port)
siehe Installation.Arbeitsplatz
Firebird : Linux-Server
siehe Installation.Arbeitsplatz
Verwendung mit Delphi
Verwendung mit drbd
Um mit Firebird eine gewisse Ausfallsicherheit zu erreichen können 2 Massnahmen getroffen werden.
Operation auf einer Partition / Blockdevice
normalerweise ist eine FirebirdSQL-Datenbank eine Datei, die mit wachsendem Inhalt der Datenbank immer grösser wird. Man kann aber einfach firebirdSQL anweisen eine ganze Partition für die Ablage der Datenbank zu verwenden. Die Datenbank-Grösse kann dann nur bis zur Partitions-Grösse anwachsen. Auf den Backup und Restore Prozess hat dies keinen Einfluss.
Eine Performance-Messung ergab praktisch identische Zugriffszeiten bei der Operation auf einer Partition im Vergelich zu einer Datei auf der selben Platte. Der Restore in die Partition hinein wurde mit 16 K Page Size durchgeführt.
Operation auf DRBD
DRkann eine Partition auf einen anderen REchner spiegeln. Host A wird zum Master, wenn ein Prozess auf Host A schreibend auf das Block-Device zugreift wird diese Änderung auf Host B per Netzwerk übertragen. Auch Host B ändert nun sein Abbild und beide Partitionen sind wieder gleich. Wir gewinnen einen gewissen Schutz beim Ausfall des Host A, dann können wir firebird auf Host B auf der Partition B starten.
Die Konfiguration
chkconfig --add drbd cat /proc/drbd
resouce in /etc/drbd.conf auf beiden Systemen definieren
drbdadm create-md all drbdadm -- --overwrite-data-of-peer primary all
# Ab hier kam ich in Probleme da ich beide Partitionen nicht genau gleicg gemacht hatte # Egal was ich eingetragen hatte, irgend eine Rundung verwarf mir meine Angaben # Es sind auch auf beiden Systemen nicht baugleiche Platten, so dass ich mir # dieses Problem mit der Unterschiedlichen Partitions-Geometrie erkläre # Es ging aber als ich die Sekundäre Partition etwas grösser machte, als die # bereits "metadata" initialisierte primäre Partition. Es scheint so dass dann # klaglos der Rest der Sekundären Partition unbenutzt bleibt. # @Secundary> drbdadm secundary all # Beim Restore einer DB mit gbak als root gab es kein Problem # aber der Zugriff auf die Partition war dann Firebird in der Rolle als Remote-Prozess nicht # möglich. # Versuch 1) ich habe die Rechte entsprechend angepasst! # @primary> chmod o+rw /dev/drbd1 # das ging, aber nach den "close" durch firebird waren die Rechte wieder auf # Original-Zustand zurückgesetzt. # Versuch 2) ich habe den owner von root auf "firebird" gesetzt, das ging wieder nicht lange gut # Versuch 3) ich wollte "firebird" zur Gruppe "disk" hinzufügen, das klingt eigentlich toll, # aber wie geht das? #
systemctl enable orgamon.service systemctl start orgamon.service
Verwendung mit PHP
Verwendung mit Java Server Pages
Client Install
C:\WINDOWS\system32, GDS32.dll MSVC8.0 Manifest usw.
Parallele Dienstverarbeitung
Beispiele: eMail VErsenden, oder an einem ARTIKEL Datensatz eine Zelle Updaten! Dazu muss eine Abfrage das Arbeitsvolumen ausgeben können, dieses wird pollend ausgeführt. Es sollten schon die "in Arbeit befindlichen" ausgeklammert werden. Entscheidet sich ein Arbeiter für einen Datensatz muss er diesen Datensatz für sich verlässlich exclusiv reservieren können, dabei wird seine eindeutige Arbeiter-ID UND ein Reservierungsdatum eingetragen. Für jede Arbeits wird ein verfallsdatum angegeben an der diese Reservierung wieder verfällt, die Aufhebung von Reservierungen macht ein globaler Arbeiter. Nach dem ERFOLGREICHEN setzen des Exclusiven Abstecken des Claim kann die Arbeit beginnen. Um den Streit (der immer eindeutig entschieden werden muss) zwischen den Arbeitern zu vermeinden soll jedem Arbeiter eine "Prämisse" mitgegeebn werden, z.B. von "oben nach unten", oder "immer das Mittlere Element", oder von "unten nach oben" oder "RID DIV 5 = 3" usw. Ist die Arbeit erledigt so wird ja eh ein gewisser "Erledigt" Status verbucht, so dass die "offene" Selektion diesen Datensatz nicht mehr sieht. Als aller letzter Schritt wird die REservierung entfernt.
Lösung
# reserviere einen oder mehrere JOBS für dich update first 1 from JOBS set WORKER = ~ME~, ARBEITS_BEGINN = CURRENT_TIMESTAMP where WORKER is null # Sehe nun nach JOBs für Dich und arbeitet im Fall, # dass etwas da ist select RID from JOBS where (WORKER=ME) and (ARBEITS_BEGINN<TIME_OUT)
GHOST - Attachements
Ich habe offene Verbindungen beobachtet (in MON$ATTACHEMENTS), die auch Transaktionen offen halten, und ich denke dadurch werden zahlreiche Record-Versions generiert. Dem Rechner wurde sogar inzwischen eine neue IP-Adresse zugewiesen und die Verbindung war immer noch offen. Problemlos war jedoch die Löschung der entsprechenden zeile in MON$ATTACHEMENT!
Ein Sweep blockiert dann die ARTIKEL Tabelle. Der Sweep ist sehr langsam.
Entwicklung dieses Fehlers
27.01.2012
heute hatten wir wieder die Störung der Art, dass ein Zugriff auf die ARTIKEL Tabelle langsam bzw. "ewig" dauert. Leider war diesmal kein schneller backup / restore Lauf mit der aktuellen Datenbank möglich. Wir hatten somit einen Blackout von gestern 15:03 bis 13:00 Uhr.
Ich habe etwas geforscht und nun herausgefunden, woran es NICHT liegt:
- der Webshop hält in diesem Moment keine Verbindung offen
- es besteht in diesem Moment keine offene Transaktion die alles andere blockiert
- es liegt nicht an einer einzelnen Verbindung, so dass man nach Trennung dieser Verbindung sagen kann die Störung sei behoben
- von der Festplatte kam keine Störungsignal, auch das Dateisystem ist OK
Ergebnis: Zugriff auf die ARTIKEL Tabelle ist möglich aber sehr sehr langsam, irgendein Problem scheint es hier zu geben. Ich ziehe den Datenbank Server auf Paris um, mit der firebird Version 2.1.4.
-> Nun meine Frage: Wer hat eine Idee / eine Vermutung was ursächlich sein könnte: Also war zwischen 11:20 und 12:00 Uhr irgend etwas ungewöhnlich? Jede Idee ist willkommen!
Hallo zusammen,
also die Datenbank läuft nun auf Paris (der Rechner in der Garage). Sie wird jede Stunde gesichert. Leider konnte ich meinen Plan nicht 100% durchsetzen: Anstelle der 2.1.4 Version MUSS ich 2.5.2 einsetzen, da es keine Weg zurück gibt. Mit Geldud und Spucke habe ich unsere "Crash" Datenbank doch noch sichern können: Das bedeutet wir verfügen auf Anfrage über einen Funktionierenden Spare, d.h. auch die ARTIKEL Tabelle ist beim Spare funktionsfähig - ich denke die Warenbewegungen müssen im Spare auch geprüft werden und in der aktuelle Datenbank nachgezogen werden ...
-> bis Montag!
07.02.2012
Hallo zusammen,
heute nacht ist beim geplanten Backup- Restore- Lauf das ARTIKEL-Problem aufgetreten. Wie beim letzten Mal funktionierte das Backup jedoch, aber nur gaaanz langsam. Wir haben keinen Datenverlust aber waren 23:00 - bis 2 Uhr offline. Wir wissen jetzt also dass "newyork" als Server in Ordnung ist. Das Problem tritt somit bei 2.5.1 und beim Snapshot (kommende 2.5.2 Version) auf und wurde also bisher nicht gelöst. Die Haltbarkeit einer Datenbank ist also im Moment so ca. 10 Tage, wir machen als Massnahme immer Montags einen Backup- Restore- Lauf. Ich versuche das zu automatisieren:
Webshop ausschalten. Alle OrgaMons rausschmeissen BAckup- Restore- newyork: xmlrpc starten Wien Starten London starten Webshop einschalten.
Hallo zusammen,
wie der Betreff schon ankündigt bin ich mir noch nicht 100% sicher. Es liegt am Transaktionsmodell des firebird Servers, in Verbindung mit einem "sweep" VErhalten das ich im Moment als Bug in firebird einstufe. Also die Ursache ist:
Ein von ARTIKEL abhängige Transaktion T1 startet, wird aber nicht beendet. In meinem Fall war dies *NICHT* der Shop sondern eine Arbeitsstation. Der Tagesabschluss hämmert auf ARTIKEL ein, Grund "Rang" Berechnung UND Lieferzeitberechung. Da T1 noch in der Luft hängt baut firebird eine künstliche Welt auf die für T1 so aussieht wie zum Startzeitpunkt von T1. Das resultiert in 180.000 "alten" Versionen der Records in ARTIKEL. Und das pro Tagesabschluss! Läuft nun dieser OrgaMom mehrere Tage *UND* wird dann beendet, wird es richtig Stressig für firebird: Alle Record-Versionen werden jetzt aufgeräumt -> Die Tabelle ARTIKEL hängt. Warum das aufräumen einerseits alle anderen Blockiert, andererseits mit 1% CPU Last durchgeführt wird ist für mich en Rätsel ...
-> ich leite Schritt für Schritt Massnahmen ein ...
15.02.2012
Ich habe heute ein Geister-Attachement gekillt (2 offene Transaktionen), dann sichergestellt dass alle OrgaMons frisch gestartet sind. Danach habe ich einen Sweep ausgeführt. Während des Sweeps (ca. 15 min) habe ich parallel immer mal wieder die Record-Versions geprüft. Die gingen im Verlauf "schnell" runter auf fast 0!
newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.50, total versions: 313751, max versions: 25 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.50, total versions: 313751, max versions: 25 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.50, total versions: 313751, max versions: 25 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.41, total versions: 200754, max versions: 22 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.41, total versions: 195344, max versions: 22 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.41, total versions: 190157, max versions: 22 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.42, total versions: 153594, max versions: 22 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.77, total versions: 48805, max versions: 21 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.84, total versions: 38239, max versions: 21 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 11.97, total versions: 26478, max versions: 21 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 12.00, total versions: 19429, max versions: 21 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL hebu.fdb | grep versions Average version length: 15.33, total versions: 6, max versions: 2
Bleibt zu klären, wer oder was offene Transaktionen hält!
16.02.2012
Ich versuche über das Produkt FB Trace-Manager von Thomas Steinmaurer zu ergründen wo offene Transaktion verbleiben. Ich hab' einige Zeit gebraucht zuerst mal zu verstehen was der Trace Manager überhaupt ist. Hier mal eine grundsätzliche Info:
- ab firebird 2.5 kann ein Client über das Netzwerk zum firebird Datenbank-Server ein Text-Verbindung öffnen und sich Infos aus verschiedenen Bereichen wünschen. Also man wünscht sich Infos wenn eine neue Verbindung zustande kommt, oder wenn eine Transaktion gestartet oder beendet wird. Tritt auf dem Server dieses Ereignis ein, sendet er einen entsprechenden Text an den Client. Das Trace API ist also so eine Art remote logging Mechanismus, in den man sich einklinken kann, den man steuern kann. Das Trace-Interface ist Multi-User fähig!
- Der FB-Trace-Manager bereitet den Roh-Text ordentlich auf und stellt ihn tabelarisch dar. Unnötige Infos lassen sich rausfiltern. Ob der Trace-Manager ein Tracking bestizt weis ich noch nicht ...
17.02.2012
i did not find the guilty left open statement by now, but we nearly can reproduce the error by now! We let OrgaMon be active after some work with it, after 24 h we had again 330.000 "versions" in the ARTIKEL Table (gstat -r). Then - I just closed this OrgaMon, firebird started clean up immediatly down to 14 versions! This took 12 Minutes.
At Monday we make the next test: I have now a Button in OrgaMon "commit W Transaction", where the User can do a "IBO.Transaction_W.CommitRetaining" manually to my gultiy W-Transaction, i give you feedback what happened ... (we have the situation under control! It is not any more in an emergency state yet! Thanks yery much for your help!)
20.02.2012
- it is all clear now: On Form Opens a IB_Query because a Grid is linked. This form *never* makes a change. It it just like "select * from ARTIKEL", this is done inside my default transaction (the W-Transaktion!) This OrgaMon is now left open for a long time ...
- Another OrgaMon makes "Tagesabschluss" and update ARTIKEL in the sense of "update ARTIKEL set LIEFERZEIT=null". This generates a lot of record versions because the long running orgamon did not make a commit ...
29.02.2012
Until Jason has a "silent commit and reopen on demand"- fix ready: Here is my workaround. it is a automatic cut-connection script wich is executed by OrgaMon automatically at noon.
- OLAP Skript: "System.Tagwache.Verbindungen_trennen.OLAP.txt"
--
-- Skript zum Anzeigen / Beenden all zu langer Datenbankverbindungen
--
$SERVERS=('192.168.100.90','192.168.100.91','192.168.100.182')
$STUNDEN=8
select
MON$$ATTACHMENT_ID,
MON$$TIMESTAMP,
MON$$REMOTE_ADDRESS
from
MON$$ATTACHMENTS
where
(MON$$STATE=1) and
((CURRENT_TIMESTAMP - MON$$TIMESTAMP) > ($STUNDEN.0 / 24.0) ) and
(MON$$REMOTE_ADDRESS not in $SERVERS)
save
numeric MON$ATTACHMENT_ID
-
excel
save as html
-
nop
-
repeat
delete from MON$$ATTACHMENTS where (MON$$ATTACHMENT_ID=$RID)
-
firebird 3.0
Erste Tests
- http://libtom.org/ compilieren
- danach libtommath.a in eigenes verzeichnis kopieren
- ar x libtommath.a
- gcc -shared -o libtommath.so.1 *.o