FirebirdSQL: Unterschied zwischen den Versionen
Root (Diskussion | Beiträge) |
Root (Diskussion | Beiträge) |
||
(107 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Firebird ist ein SQL-Datenbankserver. Firebird is a registered trademark of the Firebird Foundation [[ | Firebird ist ein SQL-Datenbankserver. Firebird is a registered trademark of the Firebird Foundation [[https://firebirdsql.org]] | ||
Zur Datenhaltung verwendet OrgaMon den freien Datenbank Server Firebird-SQL ( | Zur Datenhaltung verwendet OrgaMon den freien Datenbank Server Firebird-SQL (https://firebirdsql.org/). <br> | ||
== Installation == | == Installation == | ||
Im Moment setze ich immer den SuperServer der Version 3 ein. | |||
=== OpenSuSE 15.1 / 15.2 === | |||
zypper install firebird-server firebird-examples telnet | |||
# | |||
# Sorge für angepasste Einstellungen | |||
# | |||
mv /etc/firebird/firebird.conf /etc/firebird/_firebird.conf | |||
joe /etc/firebird/firebird.conf | |||
==== firebird.conf ==== | |||
# | |||
# <b>/etc/firebird/firebird.conf</b> | |||
# | |||
# Einstellungen für erfolgreiches Konnektieren von 2.5 Clients | |||
# | |||
AuthServer = Legacy_Auth | |||
AuthClient = Legacy_Auth | |||
UserManager = Legacy_UserManager | |||
AllowEncryptedSecurityDatabase = false | |||
WireCrypt = Enabled | |||
WireCompression = false | |||
RemoteAuxPort = 3051 | |||
DatabaseAccess = Restrict /srv/firebird | |||
# | |||
# Start the server | |||
# | |||
systemctl enable firebird.service | |||
systemctl start firebird.service | |||
# | |||
# test if server is running | |||
# | |||
telnet localhost 3050 | |||
# | |||
# set the SYSDBA Password, MUST replace *********** | |||
# | |||
gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~ | |||
# | |||
# Alternativ, aber unklar | |||
# | |||
isql-fb employee; | |||
SQL> create or alter user SYSDBA password '***********'; | |||
SQL> commit; | |||
SQL> quit; | |||
==== /etc/crontab ==== | |||
* damit bei einem freigegebenen Share firebird-Datenbanken löschbar sind | |||
# | |||
# Firebird | |||
# | |||
00 10 * * * root chmod -R 777 /srv/firebird | |||
==== /etc/samba/smb.conf ==== | |||
* Nehme die Freigabe des Datenbankverzeichnisses zu deinen Samba-Shares hinzu | |||
* Die Arbeitsstationen müssen keinesfalls dieses Share mit einem Laufwerk verbinden | |||
* OrgaMon wird bei der Datensicherung auf \\host\firebird zugreifen | |||
... | |||
[firebird] | |||
comment = Firebird | |||
path = /srv/firebird | |||
guest ok = yes | |||
writeable = yes | |||
create mode = 0777 | |||
directory mode = 0777 | |||
force create mode = 0777 | |||
force directory mode = 0777 | |||
=== selbst compilieren 3.0.5 === | |||
zypper install libicu-devel libtommath-devel libtomcrypt-devel | |||
wget http://web.firebirdsql.org/download/snapshot_builds/linux/fb3.0/Firebird-3.0.5.33221-0.tar.bz2 | |||
bunzip2 Firebird-3.0.5.33221-0.tar.bz2 | |||
tar -xf Firebird-3.0.5.33221-0.tar | |||
cd Firebird-3.0.5.33221-0/ | |||
./configure | |||
make | |||
make install | |||
* firebird.conf ist in /usr/local/firebird | |||
* gbak: /usr/local/firebird/bin/gbak | |||
* service ist: systemctl status firebird-superserver.service | |||
=== selbst compilieren 3.0.7 === | |||
* gilt analog auch für firebird 3.0.8, 3.0.9, | |||
* gilt nicht für 3.0.10 auf openSUSE 15.4, hier meint er "icu" hätte die falsche Versionsnummer | |||
zypper install telnet libicu-devel libtommath-devel libtomcrypt-devel | |||
wget https://github.com/FirebirdSQL/firebird/releases/download/R3_0_7/Firebird-3.0.7.33374-0.tar.bz2 | |||
# wget https://github.com/FirebirdSQL/firebird/releases/download/v3.0.10/Firebird-3.0.10.33601-0.tar.bz2 | |||
bunzip2 Firebird-3.0.7.33374-0.tar.bz2 | |||
tar -xf Firebird-3.0.7.33374-0.tar | |||
cd Firebird-3.0.7.33374-0/ | |||
./configure | |||
make | |||
make install | |||
* firebird.conf ist in /usr/local/firebird | |||
* gbak: /usr/local/firebird/bin/gbak | |||
* service ist: systemctl status firebird-superserver.service | |||
# | |||
# SYSDBA Passwort setzten | |||
# | |||
/usr/local/firebird/bin/gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~ | |||
=== selbst compilieren 3.0.10 === | |||
zypper install telnet libicu-devel libicu69 libtommath-devel libtomcrypt-devel | |||
#wget https://github.com/FirebirdSQL/firebird/releases/download/v3.0.10/Firebird-3.0.10.33601-0.tar.bz2 | |||
wget https://github.com/FirebirdSQL/firebird/releases/download/v3.0.11/Firebird-3.0.11.33703-0.amd64.tar.gz | |||
bunzip2 Firebird-___ .tar.bz2 | |||
tar -xf Firebird-___.tar | |||
cd Firebird-___/ | |||
./configure | |||
make | |||
make install | |||
* firebird.conf, databases.conf ist in /usr/local/firebird | |||
* gbak: /usr/local/firebird/bin/gbak | |||
* service ist: systemctl status firebird-superserver.service | |||
# | |||
# SYSDBA Passwort setzten | |||
# | |||
/usr/local/firebird/bin/gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~ | |||
=== selbst compilieren 3.0.11 === | |||
* openSUSE 15.5 | |||
wget https://github.com/FirebirdSQL/firebird/releases/download/v3.0.11/Firebird-3.0.11.33703-0.tar.bz2 | |||
zypper install telnet libicu-devel libicu69 libtommath-devel libtomcrypt-devel | |||
zypper install gcc gcc-c++ make automake ncurses-devel zlib-devel | |||
bunzip2 Firebird-___ .tar.bz2 | |||
tar -xf Firebird-___.tar | |||
cd Firebird-___/ | |||
./configure | |||
make | |||
make install | |||
* Bei make install soll man ein Passwort eingeben, das ist jedoch sinnlos, das eingegebene Passwort wird nicht verwendet | |||
* Wie immer also: | |||
# | |||
# SYSDBA Passwort setzten | |||
# | |||
/usr/local/firebird/bin/gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~ | |||
==== systemd ==== | |||
* Es gibt scheinbar bestrebungen /var/run/ abzuschaffen, neu ist /run, das müsste auch im firebird geändert werden | |||
(15/43) Installing: systemd-246.16-7.21.1.x86_64 .........................................................................................................[done] | |||
Additional rpm output: | |||
/usr/lib/tmpfiles.d/firebird.conf:1: Line references path below legacy directory /var/run/, updating /var/run/firebird → /run/firebird; please update the tmpfiles.d/ drop-in file accordingly. | |||
/usr/lib/tmpfiles.d/net-snmp.conf:1: Line references path below legacy directory /var/run/, updating /var/run/net-snmp → /run/net-snmp; please update the tmpfiles.d/ drop-in file accordingly. | |||
Too few arguments. | |||
raib80:/usr/lib/tmpfiles.d # cat firebird.conf | |||
d /var/run/firebird 0775 firebird firebird - | |||
=== selbst compilieren 5.0.0 === | |||
zypper install telnet libicu-devel libicu69 libtommath-devel libtomcrypt-devel | |||
zypper install gcc gcc-c++ make automake cmake ncurses-devel zlib-devel | |||
wget https://github.com/FirebirdSQL/firebird/releases/download/v5.0.0/Firebird-5.0.0.1306-0-source.tar.xz | |||
tar -xf Firebird-5.0.0.1306-0-source.tar.xz | |||
=== Raspberry Pi / Debian === | |||
apt install firebird3.0-server firebird3.0-examples telnet | |||
isql-fb security.db | |||
=== 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.). | |||
* Nehme im Yast das Build-Repository hinzu: http://download.opensuse.org/repositories/server:/database/openSUSE_13.1/ | |||
* Suche und Installiere nun den "firebird-classic" | |||
* Gehe weg vom "default" Passwort für den SYSDBA: gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~ | |||
* das wars ... | |||
=== OpenSuSE 13.1 === | |||
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 | 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 | ||
Zeile 13: | Zeile 237: | ||
# | # | ||
* Es funktioniert nur FirebirdCS-2.5.3.26780-0.i686.rpm, also die Classic 32 Bit Version. | * Es funktioniert nur FirebirdCS-2.5.3.26780-0.i686.rpm, also die Classic 32 Bit Version. | ||
Zeile 80: | Zeile 303: | ||
telnet localhost 3050 | telnet localhost 3050 | ||
=== | === Windows 7/8/10/Server === | ||
* 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 Defender Firewall muss man die eingehenden Ports 3050 und 3051 öffnen | |||
** Die "Firebird.conf" sollte so aussehen | |||
# | # | ||
Zeile 116: | Zeile 321: | ||
RemoteAuxPort = 3051 | RemoteAuxPort = 3051 | ||
=== Windows XP SP 2 === | |||
== | |||
<b></b> | <b></b> | ||
Zeile 271: | Zeile 379: | ||
siehe [[Installation.Arbeitsplatz]]<br> | siehe [[Installation.Arbeitsplatz]]<br> | ||
== Shell Befehle == | |||
<syntaxhighlight lang="shell"> | |||
# | |||
# Anzeigen aller offenen Firebird Verbindungen | |||
# | |||
ss | grep gds-db | |||
ss -n | grep :3051 | sort | |||
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. | |||
</syntaxhighlight> | |||
== Verwendung als Embedded == | |||
* Dies bezeiht sich nur noch auf die freepascal win64 Programmierung | |||
* die "fbclient.dll" der Version 3.0.7 ist automatisch eine embedded Version, einfach die .zip Distribution in das Anwendungsverzeichnis entpacken | |||
* mit gbak kann man eine .fbak auf einem Netzwerk-share wieder in eine .fdb verwandeln, aber nur auf ein lokales Drive, also C:\ oder ein USB Stick F:\ | |||
* mit freepascal win64 ist mir das noch nicht gelungen, da ist noch ein problem | |||
* man kann auf keine .fdb auf einem Netzwerk Share verbinden | |||
** auch wenn man mit gfix die Datenbank in eine read-only Datenbank verwandelt hat | |||
== Verwendung mit http://drbd.org == | == Verwendung mit http://drbd.org == | ||
Zeile 365: | Zeile 500: | ||
disk:x:6:firebird | disk:x:6:firebird | ||
# | # | ||
== Usage with ZNS (a concept) == | |||
* a firebird database is stored to a single file, all the data, tables and indexes share the same file | |||
* this concept is so clean, that you can even use a partition to store a database | |||
* Data is organized by fixed size Pages, there are different Page-types - for Row-Data, Index-Tables, or Metadata | |||
* firebird storage is optimized for typical blockdevice, open the file, read, append to the end, and update Pages | |||
* a firebird file can only grow, but there are unused pages within a firebird file, the more the older is the file | |||
=== why ZNS for NVMe === | |||
* NVMes are perfect Blockdevices for firebird? Yes, they seem to be, but internal they do a lot of work to keep expectations | |||
* They only emulate a perfect Blockdevice by the Housholding Algos of their internal Controller Software | |||
* Under the hood, there is dramatic action going on: | |||
** Reading Data ist not the problem, just works like reading Bits from a RAM Chip | |||
** Writing "new" Data to prior unused space is no Problem | |||
** Updating, or overwriting data is a Problem, internally this is not possible | |||
** Updating is done by erasing a Zone an writing it new from left to right | |||
** Updating n-Bytes can result in writing n*2*y-Bytes | |||
=== Give NVMe more Info === | |||
* If the OS would give more Information to the NVMe, Live for it could be much easier | |||
* The NVMe could avoid internal housholding writes, this is prelonging livetime | |||
* What Information is helpfull: | |||
** What data belongs to a file | |||
** When you start writing a file, please tell me its size (if known) | |||
* What breaks the "blockdevice" game | |||
** We must understand the "zone" Ecosystem | |||
** We must arrange data in Zones | |||
** forget random writes to files | |||
** remember the "artefacts", let the nvme do the garbage collect (by "simple copy") | |||
=== The new Firebird Storagemode === | |||
==== Pages ==== | |||
* Pages, from nowone can only be saved to the end of the file | |||
* Page Number 0 is not nessesarly on position 0 of the file | |||
* You must ask a "bitmap" layer to get the real position | |||
==== Bitmap ==== | |||
* We must implement a new "translating" level for PageNumbers | |||
* This persistent Datastructure maps Pagenumbers to the real world | |||
* It grows from 0.. , but data is interpreted from EOF..0 | |||
type | |||
BitmapElement = record | |||
PageNumber: int64; | |||
Zone: int64; | |||
Seek: int64; | |||
StopLookingBack: boolean; | |||
end; | |||
Bitmap = array of BitmapElement; | |||
* If you ask for a PageNumber you get a Zone and a Seek back | |||
* If you get no answer, you can assume Zone=0 and Seek=PageNumber | |||
* if StopLookingBack is true, do not trust older BitmapElements with this PageNumber | |||
=== Page-Zones === | |||
* In my Picture i will only look at the "Write"- Aspect of an NVMe, reading is done by magic! | |||
* Imagine a Data-Storage Room with hundreds of Tape-Recorders | |||
* One Tape is one Zone, the storage Controller can | |||
** erase an entire single tape by sending the command resulting in a "magnetic flash" | |||
** write data from 0..EOF the Tape, no update, no overwrite, only appending data until the tape is at its end | |||
* firebird should ask how big the Zone-Size is and use now Zones for writing the Pages of all kind | |||
* If a Page must be updated, do not write to the original file position of the page (no, dont use seek+write), append it to the actual End of the Database-file, this is in the highest | |||
* So we have an Old representation and a new in our Page-File - wich is the correct one? | |||
* | |||
=== Bitmap-Zones === | |||
* With the help of a Bitmap-Datastructure firebird can calculate the true Position of Pages | |||
* With a "perfect" ordered Database-File the Bitmap is empty | |||
* If new or recently updated Pages grow the file the Bitmap grows. | |||
* firebird has to calculate PageNo+Bitmap -> ZoneNumber, SeekPosition | |||
* Even the Bitmap can only grow, there is no "updated" Bitmap-Data | |||
* A persistent Bitmap must be read from right to the left (from newly saved Data to older ones) | |||
* A newer Information about a Page-Position makes all the old-Data about Pages obsolet | |||
=== simple copy === | |||
* use NVMe "simple copy" to "garbage collect" bitmap and Page File | |||
==== The Page-Storage ==== | |||
DDXXDXDDDDDXXXXX | |||
* D=actual real Page | |||
* X=artefact of an old now unused page | |||
* By reading old Parts of the Bitmap, firebird knows where artefacts live | |||
* with the NVMe simple copy command you can ... | |||
** move all the "D" to the append position | |||
** send the info that the hole zone is now free! | |||
** after such a "simple copy" the bitmap must mark the X Position as censored, that means a reserach and use of Position Data in old Bitmap Data is forbidden | |||
==== The Bitmap-Storage ==== | |||
XXXBXBBBBBBXBBBBB | |||
* if you parse the entire Bitmap from rigth to left, before reaching "0", there is a Point P where you have all the information you need for the hole Picture | |||
* this is because some Information is "censored" and so, has no Information Content any more | |||
* so you can free 0..P, in our sample you can free XXX | |||
=== this causes more corruption? === | |||
* appending a new Pages? No risk | |||
* updating a page means | |||
** A: appending the page to the higest Page-Zone | |||
** B: appending Bitmap-Info about this page writing a Page to the and add this Information to the Bitmap | |||
** C (optional):a Page-Zones gets free, because the updated page was the last living object on that zone | |||
** D (optional):a Bitmap-Zone gets free, because a zone is complete censored know (by Step C) | |||
-> if you ensure A+B+C+D inside an atomic transaction, if a file system can help, this is save | |||
== Verwendung mit PHP == | == Verwendung mit PHP == | ||
Zeile 381: | Zeile 633: | ||
* Vorbereitung | * Vorbereitung | ||
zypper install libxml2-devel | zypper install libxml2-devel | ||
zypper install FirebirdCS-2.5.0.26054-ReleaseCandidate3.i686.rpm | zypper install FirebirdCS-2.5.0.26054-ReleaseCandidate3.i686.rpm | ||
* Ermittle die PHP Versionsnummer, damit du weist welchen Source-Tar-Ball du ziehen must | * Ermittle die PHP Versionsnummer, damit du weist welchen Source-Tar-Ball du ziehen must | ||
php -v | php -v | ||
* Lade vom Museum die Source-Code Distribution des PHP, in diesem Beispiel hat die Versionsprüfung 5.1.0 ergeben | * 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 | wget http://museum.php.net/php5/php-5.1.0.tar.gz | ||
gzip -d php-5.1.0.tar.gz | gzip -d php-5.1.0.tar.gz | ||
tar -xf php-5.1.0.tar | tar -xf php-5.1.0.tar | ||
cd php-5.1.0 | 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 | * 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 | ./configure --with-interbase=shared,/opt/firebird | ||
make | make | ||
* so, jetzt das Compilat noch PHP zur Verfügung stellen | * so, jetzt das Compilat noch PHP zur Verfügung stellen | ||
cp modules/interbase.so /usr/lib/php5/extensions | cp modules/interbase.so /usr/lib/php5/extensions | ||
* Nun reicht es, im Verzeichnis <code>/etc/php5/conf.d</code> die Datei <code>interbase.ini</code> anzulegen: | * Nun reicht es, im Verzeichnis <code>/etc/php5/conf.d</code> die Datei <code>interbase.ini</code> anzulegen: | ||
extension=interbase.so | extension=interbase.so | ||
[Interbase] | [Interbase] | ||
ibase.timestampformat=%m-%d-%Y %H:%M:%S | ibase.timestampformat=%m-%d-%Y %H:%M:%S | ||
den Apache 2 neu starten | den Apache 2 neu starten | ||
Zeile 466: | Zeile 718: | ||
<u>Achtung</u>: Nach einer Änderung muss der Apache-Webserver mit "Startmenü\Alle Programme\Apache HTTP Server\Control Apache Server\Restart" neu gestartet werden. | <u>Achtung</u>: Nach einer Änderung muss der Apache-Webserver mit "Startmenü\Alle Programme\Apache HTTP Server\Control Apache Server\Restart" neu gestartet werden. | ||
== Datensicherung == | == Datensicherung == | ||
Zeile 651: | Zeile 897: | ||
* OLAP Skript: "System.Tagwache.Verbindungen_trennen.OLAP.txt" | * OLAP Skript: "System.Tagwache.Verbindungen_trennen.OLAP.txt" | ||
-- | -- | ||
-- Skript zum Anzeigen / Beenden all zu langer Datenbankverbindungen | -- Skript zum Anzeigen / Beenden all zu langer Datenbankverbindungen | ||
Zeile 685: | Zeile 930: | ||
delete from MON$$ATTACHMENTS where (MON$$ATTACHMENT_ID=$RID) | delete from MON$$ATTACHMENTS where (MON$$ATTACHMENT_ID=$RID) | ||
- | - | ||
==== 28.01.2014 ==== | ==== 28.01.2014 ==== | ||
Zeile 702: | Zeile 946: | ||
* Es steht immer noch im Raum ev. auf Postgresql umzustellen | * Es steht immer noch im Raum ev. auf Postgresql umzustellen | ||
* Als Zwischenlösung konnektiere ich erfolgreich mit dem OrgaMon in Verbindung mit einer firebird Client DLL 2.5.x auf einen Firebird 3.0 Server | * Als Zwischenlösung konnektiere ich erfolgreich mit dem OrgaMon in Verbindung mit einer firebird Client DLL 2.5.x auf einen Firebird 3.0 Server | ||
# | |||
# Einstellungen für erfolgreiches Konnektieren von 2.5 Clients | |||
# | |||
AuthServer = Legacy_Auth | |||
AuthClient = Legacy_Auth | |||
UserManager = Legacy_UserManager | |||
AllowEncryptedSecurityDatabase = false | |||
WireCrypt = Enabled | |||
WireCompression = false | |||
RemoteAuxPort = 3051 | |||
DatabaseAccess = Restrict /srv/firebird | |||
== SYSDBA Passwort abändern == | == SYSDBA Passwort abändern == | ||
Zeile 844: | Zeile 1.100: | ||
4) Es folgt dann das befüllen der fdb durch IBAid | 4) Es folgt dann das befüllen der fdb durch IBAid | ||
dieser Vorgang hat in meinem Fall 7 Stunden gedauert | dieser Vorgang hat in meinem Fall 7 Stunden gedauert | ||
== table id n is not defined (invalid service handle) == | |||
* Kommt beim Backup einer Datenbank "table id * is not defined gds_$compile_request failed" so blockiert eine Verbindung, die Zugriff auf die $CLUB Tabellen hatte, dass firebird wieder in einen konsistenten Zustand kommt. | |||
** Die $CLUB Tabellen sind temporäre Tabellen, die bei der Geolokalisierung verwendet werden um die aktuellen "Geolokalisierungs-Punkte" zu einer Gruppe/Club zusammenzufassen. | |||
** Die Verbindung/Transaktion ensteht am Tag durch Arbeiten am Geo-Arbeitsplatz. Der Tagesabschluss löscht dann "alte" $CLUB Tabellen, dadurch ensteht ein Konflikt. | |||
* In der Folge zeigt das Backup-Programm in einer Endlosschleife an: <code>invalid service handle</code> | |||
* Vorbeugend sollten "solche" langen Laufzeiten von Verbindungen vermieden werden (lang laufende Transaktionen) | |||
[[Datei:Fehlermeldung invalid service handle.png]] | |||
Lösung: | |||
Neustart den Datenbank-Servers: | |||
=============================== | |||
<b>systemctl stop firebird-superserver.service</b> | |||
<b>systemctl start firebird-superserver.service</b> | |||
== Scrub & Reboot == | |||
* Nach 3 wöchiger extensiver Nutzung hilft es, die Datenbank neu zu erzeugen und den DB-Server neu zu starten | |||
* Es konnte nachgewiesen werden, dass sich unerklärbare Instabilitäten dadurch verringern lassen | |||
* Das folgende Script wird wöchentlich (z.B. Mittwochs 02:00 Uhr) ausgeführt | |||
* Die Schritte sind | |||
** Ausschalten aller "Gateways" zur Datenbank die Änderungen an der Datenbank auslösen könnten (z.B. php-Scripte via Webserver) | |||
** Ausschalten aller VMs, die eine Datenbankverbindung aufbauen (10 Sek. warten bis die VM runtergefahren ist) | |||
** Ausschalten des Datenbank-Dienstes an sich, nun stürzen alle laufenden OrgaMon-Anwendungen ab, nun werden alle Ghost-Attachements an die Datenbank gekappt, nun werden alle hängenden Transaktionen und Locks beendet | |||
** Verschieben der Datenbank-Datei, mit neuem Namen, sodass nicht reconnected werden kann | |||
** Backup der DB danach Restore der DB aus dem frischen Backup in eine nagelneue Datei mit "bekanntem", "alten" Namen (vollständiger Scrub) | |||
** Anpassung der Zugriffsrechte | |||
** Dateisystem-Sync und Reboot des ganzen Servers | |||
#!/bin/bash | |||
# | |||
# /root/full-server-restart.sh | |||
# | |||
# (c) 2022 Andreas Filsinger | |||
# | |||
# | |||
systemctl stop vsftpd | |||
systemctl stop nginx | |||
systemctl stop VirtualBox@WIN7 | |||
sleep 10 | |||
systemctl stop firebird-superserver | |||
PROD=firma.fdb | |||
BAND=$(date +"%Y%m%d-%H%M%S") | |||
# | |||
# move the productive .fdb , so nobody can connect | |||
# | |||
mv /srv/firebird/$PROD /srv/firebird/$BAND.fdb | |||
# | |||
# backup | |||
# | |||
/usr/local/firebird/bin/gbak -V -USER SYSDBA -PASSWORD * /srv/firebird/$BAND.fdb /srv/firebird/$BAND.fbak | |||
# | |||
# restore to prod | |||
# | |||
/usr/local/firebird/bin/gbak -R -V -P 16384 -USER SYSDBA -PASSWORD * /srv/firebird/$BAND.fbak /srv/firebird/$PROD | |||
chmod 777 /srv/firebird/$PROD | |||
chgrp firebird /srv/firebird/$PROD | |||
chown firebird /srv/firebird/$PROD | |||
# | |||
# backup is not longer needed | |||
# | |||
rm /srv/firebird/$BAND.fbak | |||
sync | |||
reboot | |||
* ACHTUNG: Um eine Situation zu vermeiden, dass Backup und Restore nicht gelingen und man dann ohne eine Datei dasteht wird die Original .fdb Datei NICHT gelöscht | |||
** Pro Woche entsteht hier eine zurückbleibende .fdb Datenbank-Datei, die manuell gelöscht werden muss | |||
== Backup / Restore == | == Backup / Restore == | ||
Zeile 891: | Zeile 1.225: | ||
set | set | ||
RDB$$CHARACTER_SET_NAME='ISO8859_1' | RDB$$CHARACTER_SET_NAME='ISO8859_1' | ||
== FileCreate 660 == | |||
* fdb Dateien werden mit den Recht 660 angelegt, manchmal kann ein Client die Datenbank-Datei dann nicht löschen | |||
* auf dem Server, der das Share /srv/firebird freigibt | |||
# | |||
# "nobody" wird in die Gruppe "firebird" verbracht | |||
# | |||
usermod -a -G firebird nobody | |||
=== Prüfen === | |||
joe /etc/group | |||
# | |||
# Es muss eine Zeile geben | |||
# | |||
firebird:x:495:nobody | |||
== UTF8-Migration == | |||
create database 'orgamon.fdb' default character set UTF8 collation de_de; | |||
create table PERSON ( | |||
RID int64 not null primary key, | |||
last_name varchar (50), | |||
first_name varchar (50)); | |||
== Links == | |||
* https://ib-aid.com/articles/firebird-gbak-backup-tips-and-tricks |
Aktuelle Version vom 1. März 2024, 12:16 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 (https://firebirdsql.org/).
Installation
Im Moment setze ich immer den SuperServer der Version 3 ein.
OpenSuSE 15.1 / 15.2
zypper install firebird-server firebird-examples telnet
# # Sorge für angepasste Einstellungen # mv /etc/firebird/firebird.conf /etc/firebird/_firebird.conf joe /etc/firebird/firebird.conf
firebird.conf
# # /etc/firebird/firebird.conf # # Einstellungen für erfolgreiches Konnektieren von 2.5 Clients # AuthServer = Legacy_Auth AuthClient = Legacy_Auth UserManager = Legacy_UserManager AllowEncryptedSecurityDatabase = false WireCrypt = Enabled WireCompression = false RemoteAuxPort = 3051 DatabaseAccess = Restrict /srv/firebird
# # Start the server # systemctl enable firebird.service systemctl start firebird.service # # test if server is running # telnet localhost 3050 # # set the SYSDBA Password, MUST replace *********** # gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~ # # Alternativ, aber unklar # isql-fb employee; SQL> create or alter user SYSDBA password '***********'; SQL> commit; SQL> quit;
/etc/crontab
- damit bei einem freigegebenen Share firebird-Datenbanken löschbar sind
# # Firebird # 00 10 * * * root chmod -R 777 /srv/firebird
/etc/samba/smb.conf
- Nehme die Freigabe des Datenbankverzeichnisses zu deinen Samba-Shares hinzu
- Die Arbeitsstationen müssen keinesfalls dieses Share mit einem Laufwerk verbinden
- OrgaMon wird bei der Datensicherung auf \\host\firebird zugreifen
... [firebird] comment = Firebird path = /srv/firebird guest ok = yes writeable = yes create mode = 0777 directory mode = 0777 force create mode = 0777 force directory mode = 0777
selbst compilieren 3.0.5
zypper install libicu-devel libtommath-devel libtomcrypt-devel wget http://web.firebirdsql.org/download/snapshot_builds/linux/fb3.0/Firebird-3.0.5.33221-0.tar.bz2 bunzip2 Firebird-3.0.5.33221-0.tar.bz2 tar -xf Firebird-3.0.5.33221-0.tar cd Firebird-3.0.5.33221-0/ ./configure make make install
- firebird.conf ist in /usr/local/firebird
- gbak: /usr/local/firebird/bin/gbak
- service ist: systemctl status firebird-superserver.service
selbst compilieren 3.0.7
- gilt analog auch für firebird 3.0.8, 3.0.9,
- gilt nicht für 3.0.10 auf openSUSE 15.4, hier meint er "icu" hätte die falsche Versionsnummer
zypper install telnet libicu-devel libtommath-devel libtomcrypt-devel wget https://github.com/FirebirdSQL/firebird/releases/download/R3_0_7/Firebird-3.0.7.33374-0.tar.bz2 # wget https://github.com/FirebirdSQL/firebird/releases/download/v3.0.10/Firebird-3.0.10.33601-0.tar.bz2 bunzip2 Firebird-3.0.7.33374-0.tar.bz2 tar -xf Firebird-3.0.7.33374-0.tar cd Firebird-3.0.7.33374-0/ ./configure make make install
- firebird.conf ist in /usr/local/firebird
- gbak: /usr/local/firebird/bin/gbak
- service ist: systemctl status firebird-superserver.service
# # SYSDBA Passwort setzten # /usr/local/firebird/bin/gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~
selbst compilieren 3.0.10
zypper install telnet libicu-devel libicu69 libtommath-devel libtomcrypt-devel #wget https://github.com/FirebirdSQL/firebird/releases/download/v3.0.10/Firebird-3.0.10.33601-0.tar.bz2 wget https://github.com/FirebirdSQL/firebird/releases/download/v3.0.11/Firebird-3.0.11.33703-0.amd64.tar.gz bunzip2 Firebird-___ .tar.bz2 tar -xf Firebird-___.tar cd Firebird-___/ ./configure make make install
- firebird.conf, databases.conf ist in /usr/local/firebird
- gbak: /usr/local/firebird/bin/gbak
- service ist: systemctl status firebird-superserver.service
# # SYSDBA Passwort setzten # /usr/local/firebird/bin/gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~
selbst compilieren 3.0.11
- openSUSE 15.5
wget https://github.com/FirebirdSQL/firebird/releases/download/v3.0.11/Firebird-3.0.11.33703-0.tar.bz2 zypper install telnet libicu-devel libicu69 libtommath-devel libtomcrypt-devel zypper install gcc gcc-c++ make automake ncurses-devel zlib-devel bunzip2 Firebird-___ .tar.bz2 tar -xf Firebird-___.tar cd Firebird-___/ ./configure make make install
- Bei make install soll man ein Passwort eingeben, das ist jedoch sinnlos, das eingegebene Passwort wird nicht verwendet
- Wie immer also:
# # SYSDBA Passwort setzten # /usr/local/firebird/bin/gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~
systemd
- Es gibt scheinbar bestrebungen /var/run/ abzuschaffen, neu ist /run, das müsste auch im firebird geändert werden
(15/43) Installing: systemd-246.16-7.21.1.x86_64 .........................................................................................................[done] Additional rpm output: /usr/lib/tmpfiles.d/firebird.conf:1: Line references path below legacy directory /var/run/, updating /var/run/firebird → /run/firebird; please update the tmpfiles.d/ drop-in file accordingly. /usr/lib/tmpfiles.d/net-snmp.conf:1: Line references path below legacy directory /var/run/, updating /var/run/net-snmp → /run/net-snmp; please update the tmpfiles.d/ drop-in file accordingly. Too few arguments.
raib80:/usr/lib/tmpfiles.d # cat firebird.conf d /var/run/firebird 0775 firebird firebird -
selbst compilieren 5.0.0
zypper install telnet libicu-devel libicu69 libtommath-devel libtomcrypt-devel zypper install gcc gcc-c++ make automake cmake ncurses-devel zlib-devel wget https://github.com/FirebirdSQL/firebird/releases/download/v5.0.0/Firebird-5.0.0.1306-0-source.tar.xz tar -xf Firebird-5.0.0.1306-0-source.tar.xz
Raspberry Pi / Debian
apt install firebird3.0-server firebird3.0-examples telnet
isql-fb security.db
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.).
- Nehme im Yast das Build-Repository hinzu: http://download.opensuse.org/repositories/server:/database/openSUSE_13.1/
- Suche und Installiere nun den "firebird-classic"
- Gehe weg vom "default" Passwort für den SYSDBA: gsec -user sysdba -password masterkey -modify sysdba -pw ~DeinNeuesPasswortHier~
- das wars ...
OpenSuSE 13.1
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
- verwende den Classic Server
- stelle die DefaultDbCachePages auf eine KLEINE Zahl (=75)
- 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
Windows 7/8/10/Server
- 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 Defender Firewall muss man die eingehenden Ports 3050 und 3051 öffnen
- Die "Firebird.conf" sollte so aussehen
# # Einstellungen für erfolgreiches Konnektieren von 2.5 Clients # AuthServer = Legacy_Auth AuthClient = Legacy_Auth UserManager = Legacy_UserManager AllowEncryptedSecurityDatabase = false WireCrypt = Enabled WireCompression = false RemoteAuxPort = 3051
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
Shell Befehle
#
# Anzeigen aller offenen Firebird Verbindungen
#
ss | grep gds-db
ss -n | grep :3051 | sort
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.
Verwendung als Embedded
- Dies bezeiht sich nur noch auf die freepascal win64 Programmierung
- die "fbclient.dll" der Version 3.0.7 ist automatisch eine embedded Version, einfach die .zip Distribution in das Anwendungsverzeichnis entpacken
- mit gbak kann man eine .fbak auf einem Netzwerk-share wieder in eine .fdb verwandeln, aber nur auf ein lokales Drive, also C:\ oder ein USB Stick F:\
- mit freepascal win64 ist mir das noch nicht gelungen, da ist noch ein problem
- man kann auf keine .fdb auf einem Netzwerk Share verbinden
- auch wenn man mit gfix die Datenbank in eine read-only Datenbank verwandelt hat
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 #
Usage with ZNS (a concept)
- a firebird database is stored to a single file, all the data, tables and indexes share the same file
- this concept is so clean, that you can even use a partition to store a database
- Data is organized by fixed size Pages, there are different Page-types - for Row-Data, Index-Tables, or Metadata
- firebird storage is optimized for typical blockdevice, open the file, read, append to the end, and update Pages
- a firebird file can only grow, but there are unused pages within a firebird file, the more the older is the file
why ZNS for NVMe
- NVMes are perfect Blockdevices for firebird? Yes, they seem to be, but internal they do a lot of work to keep expectations
- They only emulate a perfect Blockdevice by the Housholding Algos of their internal Controller Software
- Under the hood, there is dramatic action going on:
- Reading Data ist not the problem, just works like reading Bits from a RAM Chip
- Writing "new" Data to prior unused space is no Problem
- Updating, or overwriting data is a Problem, internally this is not possible
- Updating is done by erasing a Zone an writing it new from left to right
- Updating n-Bytes can result in writing n*2*y-Bytes
Give NVMe more Info
- If the OS would give more Information to the NVMe, Live for it could be much easier
- The NVMe could avoid internal housholding writes, this is prelonging livetime
- What Information is helpfull:
- What data belongs to a file
- When you start writing a file, please tell me its size (if known)
- What breaks the "blockdevice" game
- We must understand the "zone" Ecosystem
- We must arrange data in Zones
- forget random writes to files
- remember the "artefacts", let the nvme do the garbage collect (by "simple copy")
The new Firebird Storagemode
Pages
- Pages, from nowone can only be saved to the end of the file
- Page Number 0 is not nessesarly on position 0 of the file
- You must ask a "bitmap" layer to get the real position
Bitmap
- We must implement a new "translating" level for PageNumbers
- This persistent Datastructure maps Pagenumbers to the real world
- It grows from 0.. , but data is interpreted from EOF..0
type BitmapElement = record PageNumber: int64; Zone: int64; Seek: int64; StopLookingBack: boolean; end; Bitmap = array of BitmapElement;
- If you ask for a PageNumber you get a Zone and a Seek back
- If you get no answer, you can assume Zone=0 and Seek=PageNumber
- if StopLookingBack is true, do not trust older BitmapElements with this PageNumber
Page-Zones
- In my Picture i will only look at the "Write"- Aspect of an NVMe, reading is done by magic!
- Imagine a Data-Storage Room with hundreds of Tape-Recorders
- One Tape is one Zone, the storage Controller can
- erase an entire single tape by sending the command resulting in a "magnetic flash"
- write data from 0..EOF the Tape, no update, no overwrite, only appending data until the tape is at its end
- firebird should ask how big the Zone-Size is and use now Zones for writing the Pages of all kind
- If a Page must be updated, do not write to the original file position of the page (no, dont use seek+write), append it to the actual End of the Database-file, this is in the highest
- So we have an Old representation and a new in our Page-File - wich is the correct one?
Bitmap-Zones
- With the help of a Bitmap-Datastructure firebird can calculate the true Position of Pages
- With a "perfect" ordered Database-File the Bitmap is empty
- If new or recently updated Pages grow the file the Bitmap grows.
- firebird has to calculate PageNo+Bitmap -> ZoneNumber, SeekPosition
- Even the Bitmap can only grow, there is no "updated" Bitmap-Data
- A persistent Bitmap must be read from right to the left (from newly saved Data to older ones)
- A newer Information about a Page-Position makes all the old-Data about Pages obsolet
simple copy
- use NVMe "simple copy" to "garbage collect" bitmap and Page File
The Page-Storage
DDXXDXDDDDDXXXXX
- D=actual real Page
- X=artefact of an old now unused page
- By reading old Parts of the Bitmap, firebird knows where artefacts live
- with the NVMe simple copy command you can ...
- move all the "D" to the append position
- send the info that the hole zone is now free!
- after such a "simple copy" the bitmap must mark the X Position as censored, that means a reserach and use of Position Data in old Bitmap Data is forbidden
The Bitmap-Storage
XXXBXBBBBBBXBBBBB
- if you parse the entire Bitmap from rigth to left, before reaching "0", there is a Point P where you have all the information you need for the hole Picture
- this is because some Information is "censored" and so, has no Information Content any more
- so you can free 0..P, in our sample you can free XXX
this causes more corruption?
- appending a new Pages? No risk
- updating a page means
- A: appending the page to the higest Page-Zone
- B: appending Bitmap-Info about this page writing a Page to the and add this Information to the Bitmap
- C (optional):a Page-Zones gets free, because the updated page was the last living object on that zone
- D (optional):a Bitmap-Zone gets free, because a zone is complete censored know (by Step C)
-> if you ensure A+B+C+D inside an atomic transaction, if a file system can help, this is save
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 Dateiinterbase.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.
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 prod.fdb | grep versions Average version length: 11.50, total versions: 313751, max versions: 25 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.50, total versions: 313751, max versions: 25 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.50, total versions: 313751, max versions: 25 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.41, total versions: 200754, max versions: 22 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.41, total versions: 195344, max versions: 22 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.41, total versions: 190157, max versions: 22 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.42, total versions: 153594, max versions: 22 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.77, total versions: 48805, max versions: 21 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.84, total versions: 38239, max versions: 21 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 11.97, total versions: 26478, max versions: 21 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.fdb | grep versions Average version length: 12.00, total versions: 19429, max versions: 21 newyork:~ # /opt/firebird/bin/gstat -r -t ARTIKEL prod.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
- Für die Zukunft ist ungewiss ob die Quellen des OrgaMon auf nativ Firebird 3.0 umgestellt werden
- Es steht immer noch im Raum ev. auf Postgresql umzustellen
- Als Zwischenlösung konnektiere ich erfolgreich mit dem OrgaMon in Verbindung mit einer firebird Client DLL 2.5.x auf einen Firebird 3.0 Server
# # Einstellungen für erfolgreiches Konnektieren von 2.5 Clients # AuthServer = Legacy_Auth AuthClient = Legacy_Auth UserManager = Legacy_UserManager AllowEncryptedSecurityDatabase = false WireCrypt = Enabled WireCompression = false RemoteAuxPort = 3051 DatabaseAccess = Restrict /srv/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. damit der OrgaMon 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-prod.fdb k-prod.fbak gbak: ERROR:database file appears corrupt (/srv/smb/fdb/k-prod.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-prod.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/prod # gfix -v -full -user sysdba -password **** /srv/firebird/prod/k-prod.fdb Summary of validation errors Number of pointer page errors : 1 Number of database page errors : 28
server:/srv/firebird/prod # gfix -mend -ig -user sysdba -password **** /srv/firebird/prod/k-prod.fdb Summary of validation errors Number of pointer page errors : 1 Number of database page errors : 28
server:/srv/firebird/prod # gbak -b -g -ig -user sysdba -password **** /srv/firebird/prod/k-prod.fdb k-prod.fbak gbak: ERROR:database file appears corrupt (/srv/firebird/prod/k-prod.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/prod/2/l-prod.fdb l-prod.fbak gbak -v -r -p 16384 -user sysdba -password ****** l-prod.fbak empty-prod.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
table id n is not defined (invalid service handle)
- Kommt beim Backup einer Datenbank "table id * is not defined gds_$compile_request failed" so blockiert eine Verbindung, die Zugriff auf die $CLUB Tabellen hatte, dass firebird wieder in einen konsistenten Zustand kommt.
- Die $CLUB Tabellen sind temporäre Tabellen, die bei der Geolokalisierung verwendet werden um die aktuellen "Geolokalisierungs-Punkte" zu einer Gruppe/Club zusammenzufassen.
- Die Verbindung/Transaktion ensteht am Tag durch Arbeiten am Geo-Arbeitsplatz. Der Tagesabschluss löscht dann "alte" $CLUB Tabellen, dadurch ensteht ein Konflikt.
- In der Folge zeigt das Backup-Programm in einer Endlosschleife an:
invalid service handle
- Vorbeugend sollten "solche" langen Laufzeiten von Verbindungen vermieden werden (lang laufende Transaktionen)
Lösung: Neustart den Datenbank-Servers: =============================== systemctl stop firebird-superserver.service systemctl start firebird-superserver.service
Scrub & Reboot
- Nach 3 wöchiger extensiver Nutzung hilft es, die Datenbank neu zu erzeugen und den DB-Server neu zu starten
- Es konnte nachgewiesen werden, dass sich unerklärbare Instabilitäten dadurch verringern lassen
- Das folgende Script wird wöchentlich (z.B. Mittwochs 02:00 Uhr) ausgeführt
- Die Schritte sind
- Ausschalten aller "Gateways" zur Datenbank die Änderungen an der Datenbank auslösen könnten (z.B. php-Scripte via Webserver)
- Ausschalten aller VMs, die eine Datenbankverbindung aufbauen (10 Sek. warten bis die VM runtergefahren ist)
- Ausschalten des Datenbank-Dienstes an sich, nun stürzen alle laufenden OrgaMon-Anwendungen ab, nun werden alle Ghost-Attachements an die Datenbank gekappt, nun werden alle hängenden Transaktionen und Locks beendet
- Verschieben der Datenbank-Datei, mit neuem Namen, sodass nicht reconnected werden kann
- Backup der DB danach Restore der DB aus dem frischen Backup in eine nagelneue Datei mit "bekanntem", "alten" Namen (vollständiger Scrub)
- Anpassung der Zugriffsrechte
- Dateisystem-Sync und Reboot des ganzen Servers
#!/bin/bash # # /root/full-server-restart.sh # # (c) 2022 Andreas Filsinger # # systemctl stop vsftpd systemctl stop nginx systemctl stop VirtualBox@WIN7 sleep 10 systemctl stop firebird-superserver PROD=firma.fdb BAND=$(date +"%Y%m%d-%H%M%S") # # move the productive .fdb , so nobody can connect # mv /srv/firebird/$PROD /srv/firebird/$BAND.fdb # # backup # /usr/local/firebird/bin/gbak -V -USER SYSDBA -PASSWORD * /srv/firebird/$BAND.fdb /srv/firebird/$BAND.fbak # # restore to prod # /usr/local/firebird/bin/gbak -R -V -P 16384 -USER SYSDBA -PASSWORD * /srv/firebird/$BAND.fbak /srv/firebird/$PROD chmod 777 /srv/firebird/$PROD chgrp firebird /srv/firebird/$PROD chown firebird /srv/firebird/$PROD # # backup is not longer needed # rm /srv/firebird/$BAND.fbak sync reboot
- ACHTUNG: Um eine Situation zu vermeiden, dass Backup und Restore nicht gelingen und man dann ohne eine Datei dasteht wird die Original .fdb Datei NICHT gelöscht
- Pro Woche entsteht hier eine zurückbleibende .fdb Datenbank-Datei, die manuell gelöscht werden muss
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"
update RDB$$DATABASE set RDB$$CHARACTER_SET_NAME='ISO8859_1'
FileCreate 660
- fdb Dateien werden mit den Recht 660 angelegt, manchmal kann ein Client die Datenbank-Datei dann nicht löschen
- auf dem Server, der das Share /srv/firebird freigibt
# # "nobody" wird in die Gruppe "firebird" verbracht # usermod -a -G firebird nobody
Prüfen
joe /etc/group # # Es muss eine Zeile geben # firebird:x:495:nobody
UTF8-Migration
create database 'orgamon.fdb' default character set UTF8 collation de_de; create table PERSON ( RID int64 not null primary key, last_name varchar (50), first_name varchar (50));