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.
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:
| xxx |
Kürzel, auch Datenbankname, 1 - 4 alpha-Zeichen |
| _ |
Trennzeichen (Tiefstrich, Underscore) |
| nnn |
Zählnummer der Datenbankdatei (1 ... 255) |
| c |
Kennung für das Schema oder die Konfiguration; z.B.:
- a = sog. konsolidiertes Format für den Einsatz im wissenschaftlichen Bereich
- o = Format, das in Allegro-OEB für öffentliche Bibliotheken verwendet wird
|
| i |
Kennung der Indexdatei: 'd' für Hauptindexdatei (In der ÖB-Version gibt es nur eine Indexdatei mit der Kennung d) |
Hier sind die wichtigsten Dateien aufgelistet, die sich im Datenbank-Verzeichnis befinden können:
| Datei |
Name.Typ |
Inhalt und Funktion : Wozu ist sie gut, was steht drin? |
Wichtigkeit |
| Datendateien |
xxx_nnn.cLD |
Enthalten die eingegebenen Daten. Es kann mehrere solcher Dateien geben. Diese haben dann Nummern von 1 bis 255. Diese Dateien muß man unbedingt sichern, die anderen sind reparabel.
Beispiel für A-Schema (TU Braunschweig): cat_1.ald ... cat_255.ald
für O-Schema (BZ Niedersachsen): kat_1.old ... kat_255.old
|
Essentiell |
| Indexdatei |
xxx.ciX |
beinhaltet die alphabetischen Register (Index-Dateien)
|
wiederherstellbar |
| Kurztiteldatei |
xxx.STL |
Die Kurzzeilen, die man sieht, wenn man eine Ergebnismenge betrachtet |
wiederherstellbar |
| Adressentabelle |
xxx.TBL |
Die Adressen (= Positionen) der Datensätze in den Datendateien |
wiederherstellbar |
| Restriktionendatei |
xxx.RES |
Hilfsdatei zur Einschränkung von Erg.Mengen (nicht bei jeder Datenbank, auch nicht in der ÖB-Version) |
wiederherstellbar |
| LOG-Datei |
xxx.LOG |
Zur Datensicherung: Kopien der neuen und veränderten Datensätze
Diese Dateien sollten von Zeit zu Zeit archiviert und dann gelöscht werden. Im Brandenburger Menü für Allegro-OEB passiert das beim Reorganisieren (Neuaufbau der Hilfsdateien) automatisch.
Im Fall eines GAUs läßt sich im schlimmsten Fall nur aus den Log-Dateien die gesamte Datenbank wiederherstellen. |
Wichtig!
|
| Konfiguration |
$c.CFG |
Darin steht, welche Datenfelder es geben kann und andere Einstellungen
Das $-Zeichen wird nur in WB-Versionen ab V14 (?) verwendet |
sollte mindestens einmalig gesichert weren |
| c.cfl |
enthält ausführliche Feld- und Teilfeld-Namen (nur WB-Version) |
wenn selbst angepasst, sichern
(mindestens einmalig) |
| Indexparameter |
xxx.cPI |
Vorschriften für die Bildung der Index-Einträge aus den Daten |
| Exportparameter |
*.cPR, *.cPT |
Vorschriften für den Aufbau der Anzeige oder des Exportes eines Datensatzes |
selbsterstellte Parameter sollten mindestens einmal gesichert werden |
| Importparameter |
*.cim |
Vorschriften für den Datenimport |
| INI-Datei |
xxx.INI |
Einstellungen für die Benutzung der Datenbank unter a99 (nur WB-Version) |
wiederherstellbar |
(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:
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:
- Log-Datei (wenn noch vohanden) sicherstellen (xxx.log)
- Datenbank-Verzeichnis vollständig leeren
- Sicherkeitskopie des Datenbankverzeichnisses vollständig zurückspielen
- 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
Um die aktuelle Situation in einer für Allegro genutzten Netzwerkumgebung zu beurteilen, ist das Script
Allegro-C-Stresstest geeinet.
Weiterführendes
Artikel zuletzt bearbeitet am: 07.06.2022 12:50