Das bibliothekarische Datenbanksystem Allegro-C

Informationen für Administratoren

==> Datenbank-Dateien    ==> Windows-Netzwerk   ==> Netware-Netzwerk   ==> Weitere Randbedingungen   ==> Datensicherung

Allgemeines

Allegro-C wurde seit 1980 von Herrn Berhard Eversberg an der TU Braunschweig entwickelt.

Es dient vorwiegend der Verwaltung bibliothekarischer Daten und ist für diesem Zweck optimiert, ist aber auch zur Erfassung beliebiger anderer strukturierbarer Daten geeignet.
Die Datenbank besteht aus Daten-und Hilfsdateien, ähnlich wie es bei dBase oder FoxPro der Fall ist.

Es gibt zur Zeit zwei Programmversionen, die mit Allegro-Datenbanken arbeiten:

Allegro-C der TU Braunschweig (WB-Version))

Das Hauptprogramm heißt hier a99.exe oder auch allegro.exe und nutzt eine Anzahl weiterer Hilfsprogramme wie index.exe, import.exe und acon.exe über einen nachgeladenen Kommandointerpreter (cmd.exe)
Bis auf den Uninstall-Eintrag wird die Registry nicht genutzt, so dass diese Allegro-C-Anwendungen direkt von einem beliebigen Server aus gestartet werden können.

Die neuesten Programmversionen sind unter allegro-b.de zu finden.
 

Allegro-OEB der Büchereizentrale Niedersachsen

Diese Version wurde auf dem Stand der Allegro-C-Datenbankversion 13.1 abgespalten und seitdem von der Büchereizentrale selbständig für öffentliche Bibliotheken in einer eigenständigen Frontend-Variante weiterentwickelt..
Hier wird über eine Microsoft-Hypertext-Application ein Menü aufgebaut, aus dem heraus die Anwendungsprogramme als .exe-Dateien oder als OCX-Controls gestartet werden.
Auch hier wird der Kommandointerpreter zur Ausführung weiterer Hilfsprogramme genutzt.
Die Anwendungsprogramme werden windows-typisch lokal installiert, können aber eine auf einem Netzwerkserver liegende Datenbank nutzen: Diese sollte vorzugsweise unter {LW}:\allegro\katalog erreichbar sein. Abweichende Verzeichnispfade für die Datenbank erfordern ggf. manuelle Nacharbeiten, um die vollständige Funktion aller Programmkomponenten sicherzustellen.

Datenbank-Dateien

Die Namen der Datenbank-Dateien sind nach einem bestimmten Schema aufgebaut, aus dem die Konfigurationsvariante ablesbar ist. Großbuchstaben stehen hier für feste, Kleinbuchstaben für variable Zeichen aus dieser Tabelle:

Hier sind die wichtigsten Dateien aufgelistet, die sich im Datenbank-Verzeichnis  befinden können:

(Tabelle entnommen und erweitert aus http://www.allegro-c.de/dateien.htm)

Netzwerkfähigkeit

Die Datenbank ist netzwerkfähig und nutzt die Adresstabellen-Datei (*.tbl) als Semaphore. Mit dem Setzen des ersten Bytes der *.tbl-Datei wird die gesamte Datenbank als exklusiv genutzt markiert. Nach Ende kritischer, exklusiver Schreiboperationen wird dieses Byte wieder auf 00 gesetzt, um anzuzeigen, dass die Datenbankdateien wieder durch mehrere Instanzen gleichzeitig genutzt (gelesen) werden können.

Windows-Netzwerk

Randbedingungen, die Im Windows-Netzwerk eingehalten werden müssen (gilt auch für Linux-Server, die das SMB-Protokoll bereitstellen):

• lokale Dateipuffer müssen abgeschaltet sein, ansonsten sind Beschädigungen an der Datenbank äußerst warscheinlich. Das liegt daran, dass der Lock-Mechanismus über die Adresstabellendatei sonst nicht richtig funktioniert
• Oplock-Mechanismen sind kontraproduktiv, da die Dateien immer gemeinsam (shared) genutzt werden und sollten abgeschaltet werden, wenn typisch von mehreren Arbeitsplätzen aus mit der Datenbank gearbeitet und auch in sie geschrieben wird.
  Sind die OpLocks aktiv, läuft die Anwendung sehr schnell,wenn sie als einzige auf die Datenbank zugreift. Sowie ein weiterer Clieent hinzu kommt, erhöhen sich die Antwortzeiten unakzeptabel stark.

Ein Hilfsprogramm zur Einstellung der diesbezüglichen Registry-Schlüssel für Windows-Clients bis Windows 7 finden Sie hier:
In neueren Versionen des SMB/CIFS-Protokolls in reinen Windows-Umgebungen  (z.B. windows 7 mit Windows Server 2008 oder Windows 10 mit Windows Server 2012) scheinen konkurrierende Zugriffe besser zu funktionieren, so dass in diesen Fällen keine diesbezüglichen Änderungen am System vorgenommen werden müssen.

Ergänzung 1.3.2019: mit aktueller Software mit gleichem Entwicklungsstand  (ab Windows 7/Windows Server 2008 oder Windows 10/Windows Server 2012 o. 2016)  braucht an den Caching- und /oder Oplock-Einstellungen nichts mehr geändert werden.

s. auch Windows Server, Windows 10 und File-Datenbanken
 

Netware-Netzwerk 

Erfahrungen mit Netware in Versionen > 6 liegen dem Autor nicht vor. Ansonsten gilt hier sinngemäß das gleiche wie für Windows-Netzwerke:
 

• lokale Dateipuffer müssen abgeschaltet sein (Netware-Client: File Cache = Aus oder File Caching=OFF)
• True Commit oder einfach Commit sollte ausgeschaltet bleiben (über Netware-Client-Einstellungen), da es zu zu großen Verzögerungen führt.
• Oplocks sollten ebefalls auf Aus gestellt werden:
• Auf Serverseite sollte, wenn für die anderen Anwendungen akzeptabel,

  SET CLIENT FILE CACHING ENABLED=OFF
  SET LEVEL 2 OPLOCKS ENABLED=OFF
  

  in der NCF stehen.
• Shared-Mode: Da das Netware-Filesystem keine gleichzeitigen Zugriffe mehrerer Prozesse auf die gleiche Datei kennt, wird dies für die DOS oder Windows-Clienten simuliert und MUSS über das Datei-Flag Sh (Shared) explizit eingestellt werden. Problematisch dabei ist, dass durch DOS- oder Windows-Clients neu angelegte Dateien dieses Attribut standardmäßig nicht gesetzt haben, so dass Programme dies selbst setzen müssen. Unter Allegro wird dazu das Netware-Dienstprogramm flag genutzt, das dazu per Kommandozeile startbar sein muss. (passiert im Brandenburger Menü für Allegro-OEB nach der Datenbank-Reorganisation)
• Die Erfahrung zeigt auch, dass die Protokolle IP und IPX nicht gleichzeitig aktiv sein sollten: Für alle Allegro-Clients sollte entweder für alle IP oder für alle IPX einheitlich genutzt werden.

Weitere Randbedingungen::

• Verzeichnispfade sollten kurz gehalten werden: Der Grund dafür ist, dass für verschiedene Aufgaben Hilfsprogramme (index.exe, srch.exe) mit mehreren Aufrufparametern aufgerufen werden, deren Gesamtlänge die max. zulässige einer Kommandozeile nicht überschreiten darf.
  Das betrifft:
  • den Programm-Installationspfad
  • den Pfad zur Datenbank
  • dem Pfad zum Temp-Verzeichnis
• In Pfadnamen dürfen keine Tiefstriche (Underscores) verwendet werden.  Einige interne Komponenten stolpern darüber. 
• Mit UNC-Pfaden können nur Teile der Anwendungskomponenten umgehen, eine vollständige Funktionalität ist nur mit klassischen Laufwerksangaben gewährleistet. Ideal ist z.B. die Ablage der Programme unter X:\allegro ('X' steht für beliebigen Laufwerksbuchstaben)
• Hinweise zur Datensicherung:
  • Zu sichern sind mindestens alle Datenbank-Verzeichnisse
    • ÖB: allegro\katalog, allegro\stat\data und weitere Unterverzeichnisse, die *.old-Dateien enthalten
    • WB: Verzeichnisse, die Dateien mit der unter Datenbank-Dateien beschriebenen Namenstruktur enthalten
  • Während der Datensicherung darf die Datenbank nicht genutzt werden.  Für alle WB-Windows-Clienten (a99.exe) könnte man das durch Setzen des ersten Bytes der tbl-Datei auf 1 erzwingen. Für den AndoLib-WebOPAC legt man einen Text-Datei xxx.sgf an, die als erstes Zeichen eine 1  enthält (31 hex). Nach Ende der Sicherung müssen manuell gesetzte Sperren wieder zurückgesetzt werden. (Das Brandenburger Menü erledigt dies im Hintergrund automatish)
  • Datenbank-Verzeichnisse sind immer komplett zu sichern, NIE Teile davon (also nicht incrementell), da sich während der normalen Nutzung der Datenbank oder nach einer Datenbank- Reorganisation die Zahl der Datenbank-Dateien verändern kann.
  • Rücksicherung von Datenbank-Verzeichnissen: nur wenn Datenbank-Dateien verlorengegangen oder beschädigt worden sind. Schritte:
    1. Log-Datei (wenn noch vohanden) sicherstellen (xxx.log)
    2. Datenbank-Verzeichnis vollständig leeren 
    3. Sicherkeitskopie des Datenbankverzeichnisses vollständig zurückspielen
    4. Sichergestellte log-Datei evtl. an Dienstleister geben, damit Datenbank-Änderungen, die nach der letzten Sicherung erfolgten, nachgeholt werden können. 
• Datenbank-Zugriffsgeschwindigkeit im lokalen Netzwerk
  Allegro erzeugt eine relativ hohe Netzwerk-Last beim Zugriff auf die Datenbank. Folgende Einstellung beeinflussen die Antwort-Zeiten beim Zugriff:
  • Netzwerk-Übertragungsmedien
    • WLAN oder zwischengeschaltete Richtfunkverbindungen sind ungeeignet, da häufig Störungen auftreten, die dann Datenbank-Fehler verursachen.
    • "PowerLine" oder ähnliches: Ist relativ zuverlässig, hat aber höhere Latenzen und kann durch Wechselwirkung mit anderen Elektronik-Komponenten (z.B. mit fremden Schaltnetzteilen) unter Umständen ähnliche Fehler verursachen wie die Nutzung von WLAN.
    • Kupfer- oder Glasfaser-Verbindungen sind einzig zu empfehlen.
  • Übertragungsrate: optimal ist >= 1 GBit/s
  • Virenscanner: folgende Dateien sollte man vom Echtzeit-Scan ausschließen:
    • *.?ld
    • *.??x
    • *.tbl
    • *.stl
    • *.res
    • *.log
  • Oplocks und File-Caching:
    Beim Einsatz gemischter Betriebssysteme auf den Client-PCs (WinXP/Win7) beim Einsatz älterer SAMBA-Versionen auf Linux-Servern  war es oft nötig, das File-Caching und das opportunistic locking abzuschalten. Beim einheitlichen Einsatz aktueller Systemsoftware auf Clients und Servern im Netzwerk ist das nicht (mehr) nötig.
    Das betrifft
    • Linux-Server: "veto oplock files" in der samba.conf deaktivieren (s.a. Samba-Konfiguration für Allegro-Shares unter Linux)
      Ausserdem sollte schon aus Sicherheitsgründen im [global]-Abschnitt der samba.conf min protocol = SMB2  oder protocol = SMB2 gesetzt werden.
    • Windows Clients: unter Win7 lassen sich die default-Einstellungen mit Hilfe des VBS-Scriptes "Caching_and_OpLocks_V7.2.vbs" herstellen
  • Virtuelle Maschinen / VM-Hosts
    • Für die Dateien der virtuellen Festplatte der VM sollten interne Festplatten des Hostsystems verwendet werden, andernfalls entstehen für den Anwender unakzeptable Verzögerungen bzw. Antwortzeiten.
    • Auf dem Host-System sollten keine Anwendungen laufen, die eine hohe Last auf dem Massenspeicher  erzeugen, auf dem auch die Dateien der Allegro-VM liegen.
    • Optimal ist Verwendung einer lokaler SSD für die Dateien der Allegro-VM (eine Linux-VM für Allegro kommt mit 32 GB Festplatten-Platz aus)
  • Switches / Firewalls
    • Unterdimensionierte Level-3-Switches,  Hardware-Firewall-/Switch-Kombinationen oder interne Gateways waren in der Vergangenheit  schon  Ursache für hohe Latenzen.
    • Der Server, auf dem sich die Allegro-Dateien befinden, sollte im gleichen Netzwerk-Segment wie die Clients liegen.

Diagnose-Möglichkeiten

Weiterführendes

• Allegro-C-Handbuch als PDF
• https://www.allegro-b.de