Firebird-Datenbankdatei wird nicht gefunden

[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 von 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

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.

[IBExpert]

Zitat von BlueStarHH:

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