Firebird-Datenbankdatei wird nicht gefunden

[BlueStarHH]

Hallo,

bei einem Kunden läuft Firebird 3.0.10 auf eine Synology-NAS in einem Firebird-Docker-Container (https://github.com/jacobalberty/firebird-docker). (Ja, das reicht für den Kunden. Es sind nur zwei Arbeitsplätze, die wenig genutzt werden und hauptsächlich abwechselnd.)

Wenn ich nun mit meinem Programm mit IBDAC oder per FlameRobin auf die Datenbankdatei zugreifen möchte, erscheint die angehängte Fehlermeldung ("No such file..."). Er findet die DB-Datei also nicht.

Die Datei liegt zum Testen in JEDEM dieser Ordner:
docker/xyz.fdb
docker/firebird/xyz.fdb
docker/firebird/data/xyz.fdb

Laut Doku vom Firebird-Docker-Container soll die Datei in docker/firebird/data/ liegen. Bei mir im Büro habe ich das alles mit einer anderen Synology-NAS genau so eingerichtet und es klappt mit meinem Programm und IBExpert. Was könnte das Problem sein?

[jaenicke]

Schau doch einfach mit dem Standard-Tool für solche Zwecke nach. Mit dem Process Monitor kannst du einfach mit dem Filter "Path" "Ends with" xyz.fdb nachschauen, wo nach der Datei gesucht wird.

Solange du von Windows aus versuchst, auch die Datei zuzugreifen, kannst du das damit leicht sehen.

[BlueStarHH]

Zitat:

Zitat von jaenicke (Beitrag 1532472)

Schau doch einfach mit dem Standard-Tool für solche Zwecke nach. Mit dem Process Monitor kannst du einfach mit dem Filter "Path" "Ends with" xyz.fdb nachschauen, wo nach der Datei gesucht wird.

Auf der NAS läuft nicht Windows. Ist ein eigenes linuxartiges BS von Synology. Gibt es auch dafür ein Tool? Ich habe leider keinerlei Linux-Erfahrungen...
Das Firebird DBMS, das auf der NAS läuft, greift auf die xyz.fdb zu. Von Windows aus (sei es meine EXE oder FlameRobin oder IBExpert) wird dem DBMS nur mitgeteilt, wo es die Datei suchen soll. Windows selbst oder ein Windows-Programm greift also nicht direkt auf die DB zu.

[Lemmy]

und wie schaut dein Connectionstring denn aus? Ist per FlameRobin überhaupt der Server (also der im Docker) zu erreichen?

[BlueStarHH]

Zitat:

Zitat von Lemmy (Beitrag 1532474)

und wie schaut dein Connectionstring denn aus? Ist per FlameRobin überhaupt der Server (also der im Docker) zu erreichen?

Den Connectionstring kann man in FlameRobin nur über Eingabefelder eingeben. Siehe Anhang. FlameRobin macht dann daraus das:

Code:

SYSDBA@192.168.0.77/3050:xyz.fdb (UTF8)

Der Server ist erreichbar. Wenn er das nicht ist, gibt es eine ganz andere Fehlermeldung. Ich habs getestet, indem ich das PW geändert habe. Dann kommt die Meldung, das PW stimmt nicht.

[IBExpert]

Code:

SYSDBA@192.168.0.77/3050:xyz.fdb (UTF8)

wenn du das so unter windows machen würdest wäre der datei speicherort im windows system32 verzeichnis, also da wo man das nicht haben möchte.
keien ahnung wo das beim docker geht, aber entweder mit aliases.conf oder databases.conf eine alias anlegen der den realen pfad in eine physischen
umwandelt oder einfach im connectionstring vor xyz.fdb schreiben, wo das den im filesystem wohl sein soll

Code:

SYSDBA@192.168.0.77/3050:/dbpath/xyz.fdb

[hoika]

Hallo,
also laut der obigen Doku ist das Verzeichnis "/firebird/data".
Das Docker erreichst Du doch über die IP (?).

[BlueStarHH]

Zitat:

Zitat von hoika (Beitrag 1532511)

Hallo,
also laut der obigen Doku ist das Verzeichnis "/firebird/data".

Genau und dort ist die Datei auch drinnen, wird auf der Kunden-NAS aber nicht gefunden. Auf meiner NAS klappt das hingegen.

Zitat:

Zitat von hoika (Beitrag 1532511)

Das Docker erreichst Du doch über die IP (?).

Über die IP und den Port. Das klappt ja auch. Sonst würde eine ganz andere Meldung kommen.

[Lemmy]

und der hier klappt auch nicht?

SYSDBA@192.168.0.77/3050:/firebird/data/xyz.fdb

[BlueStarHH]

Zitat:

Zitat von Lemmy (Beitrag 1532518)

und der hier klappt auch nicht?

SYSDBA@192.168.0.77/3050:/firebird/data/xyz.fdb

Nein, das klappt auch nicht. Dann lautet die Meldung, dass tmp/firebird/data/xyz.fdb nicht gefunden wurde.

[IBExpert]

versuch doch sonst über ein geeignetes tools da einfach eine neue datenbank anzulegen über den pfad deiner wahl und lass dich dann überraschen wo die dann liegt.

[Lemmy]

und du bst sicher, dass auf dem nas an sich kein Firebird läuft sondern nur im Docker-Container?

[hoika]

Hallo,
wenn es bei dem einen geht und bei dem anderen nicht.
Stimmt denn die Dockerversion?
Vielleicht wurde ja in neueren Versionen was geändert ...

Die Synergy hat ein "Browser-Tool" (ich hab das nur einmal gesehen).
damit kann an wohl auch Daten kopieren (also "unsere" FDB).
Auch der FB-Pfad wird angezeigt.

[IBExpert]

ich frag mich meistens bei solchen diskussionen auch, ob der Kunde dich dafür bezahlt, das zusammenzufrickeln, bis das denn auf dem NAS läuft.

Leistungsmäßig sind alle NAS Varianten unterirdisch mies, mit den ich bisher zu tun hatte und jeder 08/15 110€ Nuc mini pc von amazon mit
windows 10 pro o.ä. im preis inbegriffen macht das nach 10 Sekunden firebird installation schneller und vermutlich auch noch zuverlässiger
als so ein NAS docker gedöns, der dir vermutlich eh nach dem nächsten NAS Firmware Update um die Ohren fliegen wird.
Und so ein NUC frisst 3-5 watt strom im dauerbetrieb, die Motivation einer Einsparung erschliesst sich mir da nicht.

[hoika]

Hallo,
naja, hier geht es eher darum, dass es eben keinen "Server" gibt.

Die NAS wird wohl benutzt, um:
- normale Dateien global zu speichern
- mit einer DB-Anwendung zu arbeiten

Sinn macht das, aber ja "unterirdische Geschwindigkeit" ;)

[IBExpert]

ich weiss nicht mehr welcher hersteller das war, aber dort war auch ein firebird auf dem nas
und der kunde unseres Kunden hatte sich halt extrem über die software performance beklagt.
selbst ein backup mit gbak von der db (ca 1gb) dauerte ca eine stunde, wenn man das backupfile
lokal haben wollte. lokaler restore (ohne nas) dauerte das ca 5minuten, nächster backup 2 minuten.

das meine ich mit unterirdischer geschwindigkeit auf der NAS. Ist übrigens manchmal auch mit dem filesystem
unglaublich lahm, wir haben in einem Kunden projekt ca 3 tb und ca 4millionen dateien von einem eigentlich
ziemlich teuren und angeblich auch schnellen QNAP NAS auf ein windows server verschoben, brauchte ca 2 tage.
selbst ein popeliger xcopy /D /S /C /Y dazwischen braucht 2-3 stunden, auch wenn da nichts geändert oder neu war.
Von der windows kiste zu einer anderen baugleichen war das in 20 minuten erledigt

(das das von einem zum anderen linux filesystem und den gleichen dateien mit rsync keine 20 sekunden
brauch ich hier nicht erwähnen, gehört gar nicht direkt zu thema).

ich meine nur das man die pseudo vorteile, das im nas docker irgendwo laufen zu haben, ganz klar
prüfen sollte.

Aber das muss ja jeder selbst entscheiden, wenn man als softwarehersteller
aber angemeckert wird, das die eigene software lahm ist und man weiss das der Kunde die vom NAS
startet (muss nicht mal die db da sein), dann kann alleine das schon vieles langsamer machen
als man denkt. nicht vergessen das große exe dateien und dlls und sonstiger kram oft weit häufiger
teile nachladen als man so denkt .....

[hoika]

Hallo,
volle Zustimmung.

[BlueStarHH]

Ein ganz großes Danke an alle!

Zunächst habe ich geprüft, ob Firebird wirklich nur im Docker-Container läuft. Ergebnis: Ja.

Dann habe ich mich mit vom Windows-PC aus per FlameRobin/IBExpert mit Firebrid auf der NAS verbunden und dort erfolgreich eine neue Datenbank angelegt. Doch auf der NAS war diese Datei nicht zu finden. Weil Sie *im* Firebird-Docker-Container angelegt wurde. Nicht auf der NAS im Ordner docker\firebird\data. Der Docker-Container hatte keine Verbindung nach außen in den Order docker\firebird\data. Docker+Firebird nochmal gelöscht und neu installiert und schon klappte es. Es lag wohl daran, dass der Kunde erst selbst versucht hatte, Docker zu installieren. Aber mit einem anderen Benutzer, der eingeschränkt war. Durch die Neuinstallation mit Admin-Rechten war dann alles OK.

Warum macht man das? Weil die Kunden das verlangen. Kunde hat die NAS schon als Backup-Gerät rumstehen und möchte keine neue Hardware kaufen. Man kann den Kunden erzählen, was man möchte. Sie wollen einfach keine andere Lösung haben. Viele wollen es auch nicht verstehen, wenn man sagt, eine NAS ist nicht optimal oder läuft nicht (richtig/schnell). Dann sagen die: Firebird oder die Software ist schlecht, wenn die nicht auf einer NAS richtig laufen kann, obwohl die Kunden keinerlei IT- oder Technik-Hintergrund haben. Deshalb sage ich inzwischen auch: Ich richte das nur ein, wenn das bezahlt wird. Ich hatte schon überlegt die Einrichtung auf einen Dienstleister auszulagern, weil das nicht mein Fachgebiet ist. Aber erstmal einen finden. IBExpert scheidet ja aus, wenn ich das oben so lese ;-)

[hoika]

Hallo,
also um das jetzt zu verstehen.

Firebird läuft unter Docker auf der NAS.
Und die Datenbank liegt auf dem NAS selber.
Und Firebird greift aus Docker heraus auf die DB zu?

Klingt ja furchtbar ;)

[BlueStarHH]

Zitat:

Zitat von hoika (Beitrag 1532550)

Hallo,
also um das jetzt zu verstehen.

Firebird läuft unter Docker auf der NAS.
Und die Datenbank liegt auf dem NAS selber.
Und Firebird greift aus Docker heraus auf die DB zu?

Klingt ja furchtbar ;)

Genau so sieht es aus. Habe ich mir nicht ausgedacht. Das macht die Standard-Installation so. Ob das furchtbar ist? Keine Ahnung. Kann auch sinnvoll sein. Ich kann den Docker-Container mit FB jederzeit löschen oder tauschen ohne das etwas mit den Daten passiert.

[hoika]

Hallo,
stimmt ...

[IBExpert]

Zitat:

Zitat von BlueStarHH (Beitrag 1532549)

Ich hatte schon überlegt die Einrichtung auf einen Dienstleister auszulagern, weil das nicht mein Fachgebiet ist. Aber erstmal einen finden. IBExpert scheidet ja aus, wenn ich das oben so lese ;-)

Korrekt, es gibt selten Fälle wo wir was mit Firebird nicht supporten, so was mit NAS docker geht aber ganz
schnell in die Richtung!

Und wenn der kunde, wie du schon sagst, auch noch selbst Hand angelegt hat, dann ist das ein Fass ohne boden.
Mit der minutengenauen Abrechnung per Prepaid Hotline würden wir das zwar im Einzelfall auch noch machen, aber
ob der Kunde das bezahlen will, steht auf einem anderen Blatt.

Ist übrigens auch gar nicht so selten mit Firebird auf virtuellen Hosts, auch da haben wir so manchem
VM Taliban schon gesagt, das wir ihm gerne bestätigen können, das sein 80000€ vm host
aus bestimmten Gründen (iops,latenz,direct i/o) für das I/O Profil von Firebird vollkommen
unbrauchbar ist, nicht weil Firebird da was schlecht macht, weil das ja auf passender Hardware
superschnell sein kann, sondern weil das eben eine Kiste ist, die ähnlich wie in der NAS File xcopy
story oben zwar eine große Datei von 10GB evtl sauschnell kopieren kann, das was firebird unter hoher
Schreiblast macht entspricht aber eher dem kopieren von 100000 kleinen dateien in 10000 unterschiedliche
Pfade auf schon halbvollen Platten.

Oft endet dann die Erklärung von mir nach Rückfragen von der VM Fraktion, die meint das beste zu haben was
es gibt auf der Welt, in einer Erklärung, warum trotz brauchbar hohem iops Wert des Servers mit einem leider
zu langen Kabel zur Storage und damit hoher latenz eben nicht für das I/O Profil mit relevanz "Wie lange
dauert die Antwort zur Frage?" eignet, dann auch gerne mal mit Einstein und der Lichtgeschwindigkeit endet.

Wenn ich 100000 fragen in einer Sekunde sende und dann zu jeder frage die Antwort nach einer sekunde
seriell fifo kommt, könnte man das als 100000 iops messen oder mindestens 50000, aber es bleibt dabei,
das auf jede Frage eine sekunde gewartet wird.

Warum firebird das so macht liegt darin begründet, das dadurch die datenbankdatei auf bei hardware reboot
o.ä. problem nahezu unkaputtbar ist, wenn nicht der datenträger schrott ist. und das ist das was man von
einer Datenbank erwarten kann (ich möchte nicht wissen wie viel Zeit die alten Säcke unter uns in Ihrem
Leben schon mit der Reparatur von Paradox datenbanken verplempert haben, weil irgendjemand unter schreiblast
ein bluescreen hatte .... )

ist immer lustig, wenn dann der Gegenseite irgendwann die Argumente ausgehen.

Und ganz deutlich: NAS oder auch virtuelle Hosts haben durchaus im richtigen Einsatzbereich erhebliche
Vorteile, aber eben auch gerne, wenn falsch eingesetzt, noch viel schlimmere Nachteile ....

[hoika]

Hallo,
Paradox über ISDN ...