FirebirdSQL: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Zeile 871: Zeile 871:
  #
  #
  #
  #
== Charset ==
* der Charset ist im Moment noch "NONE", ist implizit aber eigentlich "ISO8859_1"

Version vom 27. Dezember 2018, 19:19 Uhr

Firebird ist ein SQL-Datenbankserver. Firebird is a registered trademark of the Firebird Foundation [[1]] Zur Datenhaltung verwendet OrgaMon den freien Datenbank Server Firebird-SQL (http://firebirdsql.org/).

Installation

Im Moment setze ich auf SMP Systemen den "Classic Server (CS)" ein. Es bedeutet, es läuft kein einzelner Dämon, 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

  1. verwende den Classic Server
  2. stelle die DefaultDbCachePages auf eine KLEINE Zahl (=75)

OpenSuSE 13.1

  • Es funktioniert nur FirebirdCS-2.5.3.26780-0.i686.rpm, also die Classic 32 Bit Version.
  • Nicht vergessen die firewall zu deaktivieren, oder zumindest Post 3050 öffnen
  • firebird läuft noch über xinetd, also systemctl enable xinetd, systemctl start xinetd


joe /etc/xinet.d/firebird

# default: on
# description: FirebirdSQL server
#
# Be careful when commenting out entries in this file. Active key entry should
# be the first as some scripts (CSchangeRunUser.sh in particular) use sed
# scripting to modify it.

service gds_db
{
       disable         = no
       flags           = REUSE
       socket_type     = stream
       wait            = no
       user            = firebird
       bind            = 192.168.115.224
       server          = /opt/firebird/bin/fb_inet_server
}

OpenSuSE 42

zypper install firebird-classic
systemctl enable firebird
systemctl start firebird
#
# Sicherheitsrelevant!
# 
# Ändere nun das SYSDBA Passwort von "masterkey" auf was ordentliches
#
/usr/lib64/firebird/utils/changeDBAPassword.sh
  • Konfiguration /etc/firebird/firebird.conf
  • Benutzerdatenbank /var/lib/firebird/
  • SYSDBA Passwort ändern: changeDBApassword.sh


openSUSE 42.3

#
# Installation
#
zypper addrepo http://download.opensuse.org/repositories/server:/database/openSUSE_Tumbleweed/server:database.repo
zypper refresh
zypper install firebird-server

# 
# zukünftiger Autostart
#
systemctl enable firebird

#
# Start
#
systemctl start firebird

#
# Test
#
telnet localhost 3050

opensuse 15

zypper install firebird firebird-examples telnet
systemctl enable firebird
systemctl start firebird
# 
# test if server is running
#
telnet localhost 3050
#
# set the SYSDBA Password
#
isql-fb employee;
SQL> create or alter user SYSDBA password 'masterkey';
SQL> commit;
SQL> quit;

Unter Linux

(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

rpm direkt von firebirdsql

## xinetd muss laufen!
chkconfig --add xinetd
rcxinetd start

## Dies installiert firebird und startet es (für immer!) 
rpm -i FirebirdCS-2.0.0.12748-0.nptl.i686.rpm

## man muss noch das passwort notieren
 
cat /opt/firebird/SYSDBA.passwd

## man kann noch definieren, wo die firebird Datenbanken liegen dürfen
## auf alle Fälle muss man verhindern, dass von aussen die security.fdb
## geöffnet werden kann.

joe /opt/firebird/firebird.conf
 
DatabaseAccess = Restrict /srv

rpm direkt vom Buildservice OpenSuse

ein manuelles Installieren mit rpm -i firebird- usw. war mir nicht möglich, da ich die Referenz auf "firebird-arch" nicht auflösen konnte (grrr.).

Windows 10

Ich rate von der Verwendung des Firebird Servers unter Windows allgemein ab, es sollte immer wenn möglich ein Linux Server verwendet werden. Wenn es nicht anders geht muss man - wie immer bei Windows - etwas schrauben dass es funktioniert

  • Das PAsswort ist nach der Installation immer masterkey
  • In der Firebird.conf den AuxPort fest auf 3051 setzen
  • In der Defender Firewall die eingehenden Ports 3050 und 3051 öffnen

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

Verwendung unter Windows

Installation

bei der Server-Installtion müssen 3 Dinge manuell gemacht werden:

  1. Öffnen des TCP-Ports 3050 für den Server Dienst
  2. Öffnen des TCP-Ports 3051 für den Event Notyfier
  3. In der firebird.conf den Event-Port auf 3051 legen


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 http://drbd.org

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
resource r0 {

  protocol A;
  meta-disk internal;
  device /dev/drbd1;

  on raib24 {
    disk /dev/sdb2;
    address 192.168.115.24:7789;
  }

  on raib30 {
    disk /dev/sdb1;
    address 192.168.115.30:7789;
  }

  syncer {
    rate 10M;
  }

}
  • Erstellen des /dev/drbd1
# 
# Ich hatte das Problem, dass die Partitionen leicht unterschiedlich gross waren.
# Irgendwie hat die, in der Doku angesprochene "size determination method" versagt,
# oder ich hatte die Aushandlungsphase versehentlich verhindert, da ich zunächst auf dem Primary
# ohne Kopplung auf den Secondary die Metadata bereits geschrieben habe. 
# Hier sollte noch eine Step by Step anleitung kommen, die die VErbindung
# VOR erzeugen der Metadaten setzt. Das wär' mir lieber!
# Ansonsten könnte man sagen
# Ich erstelle 2 PArtitionen, die einfach nur >=Size sind, danach setzte ich die Ursprünglich gedachte Size:
# -d, --disk-size size
# You can override DRBD's size determination method with this option. If you need to use the device before it was ever connected to its peer, use this option to pass the size of the DRBD device to the driver. Default unit is sectors (1s = 512 bytes). 
# If you use the size parameter in drbd.conf, we strongly recommend to add an explicit unit postfix. drbdadm and drbdsetup used to have mismatching default units. 


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. Hier wird nämlich das Dateisystem (in dem Fall das Blockdevice System) in der Rolle des
# User "firebird" angesprochen. Gute Infos zu dieser Thematik gibt es hier:
# http://fghaas.wordpress.com/2007/06/04/using-drbd-directly-without-a-file-system/
# Versuch 1) ich habe die Rechte von /dev/drbd1 entsprechend angepasst!
#            @primary> chmod o+rw /dev/drbd1
#            das ging genau 1mal, 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? Über die ganzen Befehle kam ich nicht zu Ziel.
#            Ich habe einfach die Datei /etc/group editiert:
# 
@primary> joe /etc/group

# Bei "disk" muss hinten der User "firebird" angehängt werden
#
disk:x:6:firebird
#

Verwendung mit PHP

Die Verwendung unter PHP ist möglich indem man die Extension "interbase" bereitstellt.

64-bit

Bekomme ich bei mir nicht zum laufen. Nach der Compilierung eines Mini-Programmes zur Abprüfung der existenz von libfbclient kann das Programm die Bibliothek nicht laden: "not compatible version of" ...

  • Traurig: Nach so vielen Jahren 64-Bit läuft das immer noch nicht!

32-bit

  • Vorbereitung

zypper install libxml2-devel
zypper install FirebirdCS-2.5.0.26054-ReleaseCandidate3.i686.rpm


  • Ermittle die PHP Versionsnummer, damit du weist welchen Source-Tar-Ball du ziehen must

php -v

  • Lade vom Museum die Source-Code Distribution des PHP, in diesem Beispiel hat die Versionsprüfung 5.1.0 ergeben

wget http://museum.php.net/php5/php-5.1.0.tar.gz
gzip -d php-5.1.0.tar.gz
tar -xf php-5.1.0.tar
cd php-5.1.0

  • Compiliere Dir selbst die Extension "interbase.so", ermittle zuvor den Installationspfad von firebirdsql, ab 2.5 heisst er z.B. nicht mehr "/opt/firebird" wie hier angegeben

./configure --with-interbase=shared,/opt/firebird
make

  • so, jetzt das Compilat noch PHP zur Verfügung stellen

cp modules/interbase.so /usr/lib/php5/extensions

  • Nun reicht es, im Verzeichnis /etc/php5/conf.d die Datei interbase.ini anzulegen:

extension=interbase.so

[Interbase]
ibase.timestampformat=%m-%d-%Y %H:%M:%S

den Apache 2 neu starten 

rcapache2 restart

Diagnose, ob jetzt das interbase Module geladen ist: 

php --modules

auf Fehler in der folgenden Datei achten: 

/var/log/apache2/error_log

Win32

Damit PHP auf Interbase/Firebird Datenbanken zugreifen kann, müssen die Routinen, die das ermöglichen, beim Start von PHP als Erweiterung geladen werden. Dies geschieht mit Hilfe zweier Einträge in der "php.ini". Erstens muss der Eintrag "extension_dir= " auf das Verzeichnis mit den Extension-Dlls gesetzt werden. Diese befinden sich standardmäßig im Verzeichnis "extensions". Falls PHP zum Beispiel in "C:\Programme\Php" installiert wurde, liegen die Erweiterungs-Dlls im Verzeichnis "C:\Programme\Php\extensions". Der Eintrag in der "php.ini" lautet dann: 

  Win32
  extension_dir = "C:\Programme\Php\ext"
  Linux
  extension_dir = "/usr/lib/php/extension"

Zweitens gibt es in der "php.ini" einen Abschnitt, der sich "Dynamic Extensions" nennt. Dort sind alle Erweiterungen in der Form ";extension=php_....dll" aufgeführt. Da ein Semikolon am Anfang steht, beachtet PHP diese Zeile nicht als Eintrag sondern als Kommentar. In der Zeile ";extension=php_interbase.dll" muss dieses Semikolon nun entfernt werden. 

  Win32
  extension=php_interbase.dll
  extension=php_gd2.dll
  Linux
  extension=interbase.so

Der WebShop erfordert, dass Timestamps im richtigen Format übernommen werden. Dies geschieht durch folgende zwei Zeilen, die am besten ans Ende der "php.ini" gestellt werden: 

  [Interbase]
  ibase.timestampformat=%m-%d-%Y %H:%M:%S

Jetzt sollten die PHP-Routinen für die Interbase-Anbindung zur Verfügung stehen. Falls dies nicht so ist, liegt es vielleicht daran, das die "php.ini" im falschen Verzeichnis liegt (siehe Ende vorletztes Kapitel) oder der Pfad im Eintrag "extension_dir=" falsch gesetzt ist.

Achtung: Nach einer Änderung muss der Apache-Webserver mit "Startmenü\Alle Programme\Apache HTTP Server\Control Apache Server\Restart" neu gestartet werden.

Verwendung mit Java Server Pages

Client Install

C:\WINDOWS\system32, GDS32.dll MSVC8.0 Manifest usw.

Datensicherung

Unter Linux setzt firebird die Dateizugriffsrechte bei der erstellung der Datenbank-Datei auf 

-rw-rw--- firebird firebird

das ist eher unpassend, da ich mit rsync die Dateien nun nicht lesen also auch nicht sichern kann. Die Maske müsste eher 

chmod 664 sicherung_00000006.fdb

"664" lauten. Bisher hab ich noch nicht rausgefunden wie und wo man das ändern kann. Hat man alle firebird Datenbanken in einem Unterverzeichnis vereint, so kann man mit einem Befehl alle *.fdb Dateien korrekt anpassen. 

cd /your-firebirdsql-database-root-path
chmod 664 `find -name *.fdb`

Parallele Dienstverarbeitung

Fragestellung: Im Mehrbenutzerbetrieb fallen Aufgabenstellungen an (Jobs). Wie kann man mehrere Arbeiter-Prozesse einsetzen, und deren Arbeit über eine Datenbank koordinieren? Insbesondere ist zu vermeiden, dass sich 2 Arbeiter den gleichen Job holen und abarbeiten.

Beispiele: eMail Versenden, oder an einem ARTIKEL-Datensatz eine Datenzelle 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 sein eigener eindeutiger ~Kontext~ (in ARBEITER) und das Reservierungsdatum (in ZUGETEILT) eingetragen. Für jede Arbeit 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 (atomaren) 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" mitgegeben werden, z. B. von "oben nach unten", oder "immer das Mittlere Element", oder von "unten nach oben" oder "RID DIV 5 = 3" usw. Ziel wäre es dass nicht unbedingt im an den aktuellen Anforderungen gearbeitet wird, sondern immer auch an ganz alten.

Ist die Arbeit erledigt so wird ein gewisser "Erledigt"-Status verbucht, der Datensatz ist dadurch nicht mehr "offen", so dass die "offene"-Selektion diesen Datensatz nicht mehr sieht. Auch für die verlorengegangenen Arbeiter ist dies dann unsichtbar.

Lösung

Von einem einzelnen Arbeiter-Thread werden immer folgende Arbeiten ausgeführt

  • Gibt es "offene" Sätze mit "ARBEITER=~Kontext~" -> arbeite diese ab bis leer
select RID from TICKET where
 (ART = 22) and
 (ARBEITER='V97XWY2Q6') and
 (BEENDET is null)

# 
# Ergibt sich hier ein Ergebnis wird dieser Job abgearbeitet
#


  • Ist die Arbeitsliste fertig: Gewisse Anzahl von Arbeiten für mich reservieren (atomar, multithread fest!)
update TICKET set
 ARBEITER = 'V97XWY2Q6',
 ZUGETEILT = CURRENT_TIMESTAMP
where
 RID= 
(
 select first 1
 RID 
from 
 TICKET 
where
 (ART = 22) and
 (ARBEITER is NULL)
)
  • Von einem Service-Thread werden ab und an folgende Arbeiten ausgeführt
    • Arbeiter-Punzen (in diesem Fall ARBEITER='V97XWY2Q6') deren Zuteilung zu lange her ist, und die noch nicht BEENDET sind: Feld ARBEITER leeren. Dadurch werden diese Jobs frisch zugeteilt.
    • Vollständig erledigte Vorgänge die weit zurückliegen löschen

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)
-

28.01.2014

will den Fehler mal reproduzieren. recht aktueller Linux-Server 2.5.2 wird bereits genutzt.

  • OrgaMon öffen
  • die delikate Aktion im Tagesabschluss
  • prüfung mit Anzeige der Record-Versions
  • OrgaMon schliessen
  • prüfung der langsamen Abnahme der Record-Versions

firebird 3.0

Es ist mir noch nie gelungen auf einen Firebird 3.0 Server zu konnektieren. (stand 01.04.2015)

Für systemd gibt es ein "firebird-superserver.service".


Erste Tests

  • http://libtom.org/ compilieren
  • danach libtommath.a in eigenes verzeichnis kopieren
  • ar x libtommath.a
  • gcc -shared -o libtommath.so.1 *.o

firebird30 Repository

zypper ar --refresh http://download.opensuse.org/repositories/home:/mkubecek:/firebird30/openSUSE_13.1 fb
zypper install firebird

SYSDBA Passwort abändern

gsec -user SYSDBA -password masterkey -modify sysdba -pw MyKey37

Firebird Datenbank Crash?

   konkrete Verwendung einzelner Befehle für backup und restore.
   siehe ibreorg.bat in der Anlage. (der ist leider für 32-DOS-Box!)
   die Befehle müssen auch unter linux so gehen. der Pfad ist aber

   /opt/interbase/bin/gbak ....

   --- snip
   @echo off
   REM -------------------------------------------------
   REM Reparatur einer inkonsistenten FireBird Datenbank
   REM
   REM (c) Andreas Filsinger, www.orgamon.org
   REM -------------------------------------------------
   REM
   REM Usage
   REM
   REM reorg <Pfad und Name der Datenbank OHNE ".gdb">
   REM
   REM --------------------------------------------
   REM
   REM ACHTUNG: richtigen Pfad ermitteln, indem Sie nach der
   REM          Datei gbak.exe suchen lassen. Und hier eintragen:
   REM
   SET IBBIN=D:\programme\borland\interbase\bin\
   REM
   REM --------------------------------------------
   REM 1) fix erros
   REM
   %IBBIN%gfix -mend -full -ignore -user "SYSDBA" -password "masterkey" %1.fdb
   REM --------------------------------------------
   REM 2) backup fixed base
   REM
   %IBBIN%gbak -backup -v -ignore -garbage -user "SYSDBA" -password "masterkey" %1.fdb %1_neu.fbak
   REM --------------------------------------------
   REM 3) restore base
   REM
   REM zusätzlich noch "-i" wenn Indizes deaktiviert werden sollen
   REM
   %IBBIN%gbak -r -v -p 16384 -user "SYSDBA" -password "masterkey" %1_neu.fbak %1_neu.fdb
   REM --------------------------------------------
   REM 4) check new one
   REM
   %IBBIN%gfix -v -f -user "SYSDBA" -password "masterkey" %1_neu.fdb
   REM --------------------------------------------
   --- snap

   Bemerkungen
   ===========

   a) Backup-möglich aber fail beim Restore: wegen inkonsistenter Indizes
   ich habe mal erlebt, das foreign Key nicht mehr konsistent waren, und deshalb
   der restore abgebrochen hat. Alle Indizes kann man jedoch als inaktiv restoren,
   (Option -i )
   nach löschen /clearen der "Schuldigen" kann man alle indizes wieder aktivieren,
   wieder ein backup, wieder ein restore -> alles wieder gut.
   (Sourcecode dazu im HeBuAdmin Projekt)
   damit der HebuAdmin alle indizes sehen kann braucht er "out.txt". Das ist die
   Ausgabe eines erfolgreichen restores, der alle indizes enthält.
   Unter linux gibt man die Ausgabe von gbak mit 2>/freigabe/out.txt in eine Datei
   aus.

   firebird-Erkenntnis
   ===================

   internal gds software consistency check (partner index description not found (175))

   dieser Fehler tritt beim löschen eines Datensatzes auf, der eventuell durch einen
   foreign key einer anderen Tabelle referenziert werden könnte. Ist dieser key
   deaktiviert so kann keine Aussage getroffen werden, ob das löschen ok ist, dieser
   interne Fehler ist die Folge!!

Page Type Error

Behebung des Fehlers "Wrong page type":

Backup ist nicht mehr möglich

Beobachtung:

tokio:/srv/smb/fdb # gbak -b -g -ig -user sysdba -password **** /srv/smb/fdb/k-hebu.fdb k-hebu.fbak
gbak: ERROR:database file appears corrupt (/srv/smb/fdb/k-hebu.fdb)
gbak: ERROR:    wrong page type
gbak: ERROR:    page 136509 is of wrong type (expected 4, found 5)
gbak: ERROR:gds_$compile_request failed
gbak:Exiting before completion due to errors

Auch mit der Option -mend : kein Erfolg

GFix ist nicht mehr möglich

Beobachtung:

tokio:/srv/smb/fdb # gfix -v -f -user sysdba -password * /srv/smb/fdb/k-hebu.fdb
Summary of validation errors
       Number of pointer page errors   : 1
       Number of database page errors  : 28

IBAid "Repair" hat keine Wirkung

  • der Direct Fix läuft durch und erweckt den Eindruck dass er das Problem gelöst hätte
  • After the "fix", i did the suggested final steps: There were the known, old errors, finally gbak fails!


server:/srv/firebird/HeBu # gfix -v -full -user sysdba -password **** /srv/firebird/HeBu/k-hebu.fdb
Summary of validation errors
       Number of pointer page errors   : 1
       Number of database page errors  : 28

server:/srv/firebird/HeBu # gfix -mend -ig -user sysdba -password **** /srv/firebird/HeBu/k-hebu.fdb
Summary of validation errors
       Number of pointer page errors   : 1
       Number of database page errors  : 28

server:/srv/firebird/HeBu # gbak -b -g -ig -user sysdba -password **** /srv/firebird/HeBu/k-hebu.fdb k-hebu.fbak
gbak: ERROR:database file appears corrupt (/srv/firebird/HeBu/k-hebu.fdb)
gbak: ERROR:    wrong page type
gbak: ERROR:    page 136509 is of wrong type (expected 4, found 5)
gbak: ERROR:gds_$compile_request failed
gbak:Exiting before completion due to errors

IBAid "Exract" bringt die Lösung

1) Beende alle Datenbank-Dienste und stelle die fdb bereit
2) Erstelle aus dieser defekten fdb eine leere fdb gleicher Metadatenstruktur

gbak -b -m -user sysdba -password ***** /srv/firebird/HeBu/2/l-hebu.fdb l-hebu.fbak
gbak -v -r -p 16384 -user sysdba -password ****** l-hebu.fbak empty-hebu.fdb

3) Starte IBAid und gehe direkt über den Wizzard
 "Extract" <Next>
 danach im Wesentlichen die Standard-Optionen
 lege die empty-.fdb auf deinen firebird server und geben die Connect Daten an
 
4) Es folgt dann das befüllen der fdb durch IBAid
dieser Vorgang hat in meinem Fall 7 Stunden gedauert

Backup / Restore

#!/bin/sh 

#
# parameter customize
#
NAMESPACE=yourname
DBPWD=********
 
#
# JJJJ-MM-DD
#
BAND=$(date +%Y-%m-%d)

#
# backup
#
rm $NAMESPACE-$BAND.fbak
/opt/firebird/bin/gbak -V -B -USER SYSDBA -PASSWORD $DBPWD $NAMESPACE.fdb $NAMESPACE-$BAND.fbak

#
# restore
#
rm $NAMESPACE-$BAND.fdb
/opt/firebird/bin/gbak -V -R -P 16384 -USER SYSDBA -PASSWORD $DBPWD $NAMESPACE-$BAND.fbak $NAMESPACE-$BAND.fdb
chown firebird $NAMESPACE-$BAND.fdb
chgrp firebird $NAMESPACE-$BAND.fdb

#
# clean-up
#
rm $NAMESPACE-$BAND.fbak

#
#
#

Charset

  • der Charset ist im Moment noch "NONE", ist implizit aber eigentlich "ISO8859_1"
Abgerufen von „https://wiki.orgamon.org/index.php?title=FirebirdSQL&oldid=27361“