externe HSQLDB findet auf gemountetem Fritzbox-NAS Netzwerkspfad nur einen Datensatz

[JensR]

Hallo Aubergino,

die 6850 hat unter den Fritzboxen mit den schlechtesten Datendurchsatz auf der USB Schnittstelle, >30 MB/s. Bei Messungen kam man auf rund 26 MB/s. Hinzu kommt wie von Freischreiber schon richtig vermutet, wenn verwendet, ein Overhead durch NTFS und SMB Protokoll. Nebenbei bemerkt, SMB 1 kannst Du abschalten. Wird aus Sicherheitsgründen nicht mehr verwendet. Man ist hier inzwischen bei SMB 4. Zum Vergleich AVM gibt für die 7590 (Zitat AVM: bis zu 95 MB/s (FAT32, FTP) und 35 MB/s (NTFS, SMB)) an. Wobei man davon ausgehen sollte, dass diese Werte werbewirksam optimiert sind. Von dem obigen von mir genannten Wert (deutlich >30 MB/s) muss dieser Overhead (NTFS,SMB) noch abgezogen werden. Das ganze beruht auf einem relativ schwachen Prozessor in der 6850.

Ein weiterer Faktor ist die Indexierung in der Fritzbox. Ich weiss nicht in wie weit die hier dazwischen funkt, oder ob sie sich nur auf Mediendateien im Fritz.NAS bezieht.

Besteht die Möglichkeit, unter Umgehung der Fritzbox, die auf die Festplatte kopierten Tabellen, z.B. durch Zugriff direkt an einem Rechner zu überprüfen. D.h. Festplatte an einem Rechner befüllen dann Tabellen prüfen. Hier wäre auch der Wechsel nach Ext4 interessant. Damit umgeht man den NTFS Overhead. Da die Fritzbox mit ihrem Linux Betriebssystem dieses (Ext4) direkt unterstützt.

Freischreiber.
Welche Fritzbox setzt du ein? Für einen Vergleich ist es hilfreich da die Fritzen hier stark streuen. Ich z. B. benutze eine 5590 Fibre. Sie gilt zur Zeit als schnellste Fritzbox. Datendurchstz lt. AVM bis zu 160 MB/s. Realistisch sind um 90 MB/s. Damit bewegt man sich im Bereich einiger NAS Systeme. Erreicht wurde dies durch einen potenteren Prozessor.

Das sind meiner Ansicht nach Probleme welche unabhängig von LO sind, aber natürlich gelöst werden müssn.

Nebenbei bemerkt: Die Anregung von Robert bzgl. MariaDB solltest Du ins Auge fassen.

Jens

[Freischreiber]

Übrigens, Aubergino,

du solltest wirklich das Makro ausprobieren. Der Link in deinem Screenshot enthält viel zu wenige Schrägstriche.

Der Link, den das Makro bei mir generiert hat, sieht so aus:

Code: Alles auswählen

hsqldb:file:///N:\usb\basetest\dbname;default_schema=true;shutdown=true;hsqldb.default_table_type=memory;get_column_name=false

N ist der Laufwerksbuchstabe für meinen USB-Stick an der Fritzbox. Da sind vor dem Laufwerksbuchstaben drei Slashes zu sehen, und der Link funktioniert. Und übrigens sind es an dieser Stelle rechtsgeneigte Schrägstriche (/), nicht Backslashes!

@JensR:
Ich habe eine Fritzbox 7590 mit USB3-Stick daran, der ext4-formatiert ist. Die Datenrate habe ich noch nicht gemessen, und ich glaube gar nicht, daß der Overhead und die langsamere Geschwindigkeit von NTFS das Problem ist. Irgendwann müßte auch bei langsamer Verbindung ein zweiter Datensatz kommen. Vielleicht hat NTFS ein anderes Problem an der Fritzbox oder es liegt an den fehlenden Slashes, s. o.

Ext4 ist natürlich super und auch schneller. Es ist sehr zuverlässig und die Box unterstützt es von sich aus, wie du schreibst.

Gruß
Freischreiber

[Aubergino]

Hallo Jens und Freischreiber, danke auch für diese rege Diskussion!

Das mit dem Skript werde ich in den nächsten Tagen auf jeden Fall ausprobieren. Bin gespannt!

Wenn das ganze primär ein Geschwindigkeitsproblem ist, verstehe ich nicht, warum es mit der internen HSQLDB klappt, auch wenn sie auf der Festplatte liegt. Bezüglich der Schrägstriche gelobe ich Besserung und werde das testen, verstehe aber nicht, warum LO dann überhaupt was findet.

Bei dem Script fällt mir auf, dass darin ein Tabellentyp "Memory" angegeben wird. Hier viewtopic.php?f=10&t=39527&p=106719&hil ... ed#p106719 hieß es ja, dass die LO-Tables standardmäßig cached sind.

Kann man das jetzt einfach so umstellen? Oder hätte das irgendwelche Folgen? Oder hat das damit gar nichts zu tun?

[Freischreiber]

Bei dem Script fällt mir auf, dass darin ein Tabellentyp "Memory" angegeben wird. Hier viewtopic.php?f=10&t=39527&p=106719&hil ... ed#p106719 hieß es ja, dass die LO-Tables standardmäßig cached sind.

Kann man das jetzt einfach so umstellen? Oder hätte das irgendwelche Folgen? Oder hat das damit gar nichts zu tun?

Das kann man einfach so umstellen. Im Original-Makro heißt es stattdessen "hsqldb.default_table_type=cached". Die Änderung habe ich gemacht. Es stimmt, was ich unter dem Link geschrieben hatte: LO selbst, in der eingebetteten Datenbank, erstellt standardmäßig cached tables. Diese Angabe betrifft nur neue Tabellen bei ihrer Erstellung. Jede schon bestehende Tabelle kann per SQL von cached auf memory oder umgekehrt gestellt werden.

Gruß
Freischreiber

[Aubergino]

Hallo Freischreiber, Jens, Robert,

die Korrektur der Striche hat nichts verändert.

Nun habe ich das Makro angewendet.
Ich lasse mir die gebildete URL noch per msgbox anzeigen:

Code: Alles auswählen

jdbc:hsqldb:file:///Z:\Elements\Orga\Daten_extern\Bestand_extern;default_schema=true;shutdown=true

Sieht richtig aus, oder?
Auf die Sub folgt dann wie auch bisher bei der embedded HSQLDB der Code zur Herstellung der Verbindung

Code: Alles auswählen

 
  oDoc = ThisComponent
  sUrl_Start = oDoc.URL
  if FileExists(sUrl_Start & ".lck") Then
    Msgbox("Datei bereits an anderem Arbeitplatz geöffnet")
    Exit Sub
  End if
  oController = ThisDatabaseDocument.CurrentController
  If not (oController.isConnected()) Then oController.connect() ' Connect to the database, if necessary 

und ich erhalte die Fehlermeldung "com.sun.star.sdbc.SQLException Message: Die Verbindung zur Datenquelle
"Bestand_extern" konnte nicht hergestellt werden".

Im Verzeichnis ...Daten_Extern stehen:
Bestand_extern.backup, ..data, ..log, ..odb, ..properties, ..script und die hsqldb.jar.

Seht Ihr, was da falsch läuft? Oder ist es wiederum eine Folge des Problems mit der Fritz!NAS?

(Die Einstellung des "Memory-Defaults" hatte ich dann nochherausgenommen, und auch das getcolumn_name,
das ändert aber wie zu erwarten nichts an der Fehlermeldung.)

[Freischreiber]

Nun habe ich das Makro angewendet.
Ich lasse mir die gebildete URL noch per msgbox anzeigen:

Code: Alles auswählen

jdbc:hsqldb:file:///Z:\Elements\Orga\Daten_extern\Bestand_extern;default_schema=true;shutdown=true

Sieht richtig aus, oder?
Auf die Sub folgt dann wie auch bisher bei der embedded HSQLDB der Code zur Herstellung der Verbindung

Code: Alles auswählen

 
  oDoc = ThisComponent
  sUrl_Start = oDoc.URL
  if FileExists(sUrl_Start & ".lck") Then
    Msgbox("Datei bereits an anderem Arbeitplatz geöffnet")
    Exit Sub
  End if
  oController = ThisDatabaseDocument.CurrentController
  If not (oController.isConnected()) Then oController.connect() ' Connect to the database, if necessary 

und ich erhalte die Fehlermeldung "com.sun.star.sdbc.SQLException Message: Die Verbindung zur Datenquelle
"Bestand_extern" konnte nicht hergestellt werden".

Im Verzeichnis ...Daten_Extern stehen:
Bestand_extern.backup, ..data, ..log, ..odb, ..properties, ..script und die hsqldb.jar.

Seht Ihr, was da falsch läuft? Oder ist es wiederum eine Folge des Problems mit der Fritz!NAS?

(Die Einstellung des "Memory-Defaults" hatte ich dann nochherausgenommen, und auch das getcolumn_name,
das ändert aber wie zu erwarten nichts an der Fehlermeldung.)

Was das mit dem connect ist, weiß ich nicht, das steht bei mir nicht drin. Das Makro soll nur einen Pfad setzen, connecten tut die Datenbank dann selbst, wenn man die Tabellen anklickt.

Warum stellst du nicht einfach mal möglichst genau meine - funktionierende - Kombination nach, bis es läuft?

Was für eine jar-Datei hast du da übrigens stehen? Noch die alte 1.8.0 oder die aktuelle 2.7.2?

Und welches Dateisystem ist es denn jetzt? Probier doch mal einen anderen USB-Stick, mit Ext4 oder wenigstens mit FAT aus...

Gruß
Freischreiber

[JensR]

Moin zusammen,

ich glaube es wäre vorab einmal hilfreich wenn Aubergino einmal detailliert aufzeigt mit welcher Kombination er arbeitet.

1. Betriebssystem (32 bzw. 64 bit für 1. - 4.)
2. DBMS intern und extern (welche Version(en)). Hier habe ich ein Problem, weil einmal von embeded und externer Datenbank gesprochen wird. DBMS und Datenbank sind zwei unterschiedliche Dinge.
3. Verwendete Datenbanktreiber (Versionen)
4. Java Version(en)
5. LO Version (en)

Es ist für eine weiter Analyse einfach hilfreich.
Ich hoffe ersteinmal nichts vergessen zu haben.

Aubergino:
Zu Deiner Aussage, dass Du aus Sicherheitsgründen, die Datenbank extern hinter der Fritzbox betreibst, kann ich nur anmerken, dass ich hier eine 7590 liegen habe, welche das zeitliche gesegnet hat. Undzwar hat sich durch einen Verarbeitungsmangel (sichtbar) und Designfehler (aus meiner technischen Sicht) die Halterung des Kühlkörpers gelöst, welches als erstes zu einem nicht erklärbaren Verhalten der Box bei Anrufen führt und dann narürlich zu einem Totalausfall.
Da ich früher mit ältern Modellen schon ab und an Probleme hatte, betreibe ich nur einen Stick für den Anrufbeantworter an der Bock. Für alles andere habe ich einen Raidserver (Raid 5)laufen. Ich hatte letzlich einen Festplattenausfall und konnte durch Austausch der defekten Platte das System wieder hochfahren. Das nur einmal zur Überlegung NAS Ja oder Nein.

Ich habe es erst jetzt gesehen, dass Freischreiber auch schon nach den DBMS Versionen fragte.

Jens

[Freischreiber]

3. Verwendete Datenbanktreiber (Versionen)

Gibt es noch irgendwo separate Treiber bei HSQL? Ich dachte, das wäre alles in der hsqldb.jar-Datei enthalten.

[Aubergino]

Hallo wieder,
oh je, ich bin doch sehr überrascht, wie schwierig das in LO ist! (Ich habe dereinst ein umfangreiches Access-Projekt erstellt und im Handumdrehen das Backend auf so ein externes Laufwerk verlegt.)

Zu den Versionen:
Als Java-Laufzeitumgebung wird mir ausgewiesen 1.8.0_231.
Die LO-Version ist die 7.6.5.2
Wie finde ich die Version der hsqldb.jar, der Datenbanktreiber und der DBMS heraus?
Das Betriebssystem ist Windows 11 64 Bit bei mir zu Hause, wo ich derzeit teste, und Windows 10 64 Bit im Museum.
Das Dateisytem ist, wie Ihr richtig vermutet habt, NTFS.
Ein anderes Dateisystem könnte ich erst morgen ausprobieren, ich habe keinen freien USB-Stick herumliegen, da muss ich erst einen besorgen.

@Freischreiber: Ich habe Deinen Code ja übernommen, war aber davon ausgegangen, dass ich danach, also nach dem vom Code geleisteten Setzen der Pfade, dann auch den Code für das Verbinden folgen lassen muss, um mit der Datenbank arbeiten zu können. Jetzt habe ich verstanden, dass ich das erst brauche, wenn ich dann auch mit gleich ein Formular öffnen will. Ich habe das Connect also weggelassen und nur noch Deinen Code stehen. Damit ergab sich folgender Ablauf:

Das Datenbankfenster öffnet sich normal. Wenn ich dann aber auf "Tabellen" klicke, kommt die Fehlermeldung über die nicht gelungene Verbindung zur Datenbank, mit dem Zusatz:

Code: Alles auswählen

Die Treiberklasse "" konnte nicht geladen werden. Der Pfad für zusätzliche Treiberklassen ist "file://F:/Orga/Daten_extern/hsqldb.jar"

. Der Pfad dorthin wird aber doch von Deinem Code erzeugt und unter "Extras" - "Optionen" - "LibreOffice" - "Erweitert" - "Klassenpfad" auch richtig angezeigt, und die hsqldb.jar-Datei steht genau da auch wirklich drin.

Aber warum heißt es "Die Treiberklasse "" ", also KEINE Klasse angegeben??? Sie wurde doch in der content.xml wie im Handbuch beschrieben definiert?

Nun habe ich, um das Problem weiter zu isolieren, die Festplatte von der Fritzbox abgenommen und direkt an den Rechner angeschlossen. -> gleiche Fehlermeldung.

Gehe ich zu "Bearbeiten" - "Datenbank" - "Eigenschaften" steht dort unter den JDBC-Eigenschaften aber auch KEINE Treiberklasse eingetragen, was mit der Fehlermeldung ja übereinstimmt. Trage ich aber händisch die im Handbuch angegebene Klasse "org.hsqldb.jdbcDriver" dort ein, ist der Klassentest erfolgreich, der Verbindungstest dann auch, und ich kann die Datenbank normal öffnen.

Warum aber war der Eintrag leer?

Ich habe dann die "Bestand_extern.odb" wieder entpackt und in die content.xml geschaut: Dort sehe ich die eingetragene Klasse nicht, wie im Handbuch, unter "db:driver-settings", sondern weiter unten:

Code: Alles auswählen

<db:data-source-setting db:data-source-setting-is-list="false" db:data-source-setting-name="JavaDriverClass" db:data-source-setting-type="string">
<db:data-source-setting-value>org.hsqldb.jdbcDriver</db:data-source-setting-value>
</db:data-source-setting>
<db:data-source-setting db:data-source-setting-is-list="false" db:data-source-setting-name="JavaDriverClassPath" db:data-source-setting-type="string">
<db:data-source-setting-value>file:///F:/Orga/Daten_extern/hsqldb.jar</db:data-source-setting-value>

Irrt hier das Handbuch und der genannte Eintragungsort ist falsch? Schwer vorstellbar... Und was hat es mit den zwei verschiedenen Einträgen für den gleichen Wert auf sich? Aber immerhin: Es funktioniert so!

Nun habe ich die Festplatte wieder an die Fritz!Box geklemmt.

Jetzt ist es wieder wie am Anfang dieses Threads - es kommt keine Fehlermeldung mehr, aber nach dem Klick auf "Tabellen" ist LO wieder für mehrere Minuten blockiert, der Wartekreisel im Windows-Explorer kreist die ersten Minuten, und schließlich kann ich die Tabellen öffnen, bekomme aber nur einen Datensatz.

Auch der Vergindungstest unter den Datenbank-Eigenschaften braucht einige Minuten und antwortet dann mit der Meldung "org/hsqldb/jdbc/Util". Beim Klick auf "mehr" kommt "Fehlercode: -1". Klicke ich danach wieder auf "Tabellen", kommt dort sofort wieder die Fehlermeldung "Die Verbindung zur Datenquelle konnte nicht hergestellt werden", ergänzt um "org/hsqlsb/jdbc/util".

Ich glaube, es lohnt sich nicht, noch mehr Stunden in die Fehlersuche in der Anordung mit der Fritz-NAS zu investieren, sondern neige dazu, die Anschaffung der NAS zu machen. Wenn es nun auf der externen Festplatte rund läuft, sollte es doch auch auf einem NAS-Laufwerk klappen? Oder erwartet Ihr da die gleichen Probleme wie an der Fritz-NAS?

[Freischreiber]

Ja, auf ein neues.

Wie gesagt: ich bin kein Fachmann, ich kann dir nur genau erklären, was bei mir funktioniert. Und es ist durchaus möglich, daß der Weg, den Robert in seinem Libreoffice-Base-Handbuch beschreibt, ein anderer ist und die beiden Wege sich ausschließen.

Mein Vorschlag: starte mit einer komplett unveränderten Kopie deiner bisherigen embedded-Datenbank und entscheide dich für EINEN der Wege.

Meiner (und das von mir benutzte Makro) stammt von hier:
https://forum.openoffice.org/en/forum/v ... 80#p293026

Auch dort stehen wieder mehrere Alternativen. Meine ist die unter "Option 1 - 3x. Alternatively", wo du das Makro findest. Lesen solltest du allerdings den ganzen Artikel.

Ich weiß heute nicht mehr, weil es fast 10 Jahre her ist, an welcher Stelle ich die alte durch die neue Datenbank ersetzt habe, aber das würde ich an deiner Stelle auf jeden Fall auch tun. Die aktuelle HSQLDB findest du hier:

https://sourceforge.net/projects/hsqldb ... t/download

Aus der zip-Datei brauchst du nur die hsqldb.jar im Unterverzeichnis lib. Die kopierst du einfach über die alte 1.8.0-jar-Datei, die nach dem Splitten neben deinen Datenbankdateien steht. Alles, was ich dir in verschiedenen Threads über die HSQLDB vorgeschwärmt habe, bezieht sich auf die aktuelle Version, nicht auf die fast 20 Jahre alte eingebettete aus Libreoffice. Nach dem Splitten ist es vollständig sinnlos, das alte Ding zu behalten.

Viel Glück!

Freischreiber