BRISBANE (CWN) - Wieder einmal hat sich ein größerer IBM-Kunde gegen eine Umstellung auf den SQL/DS-Datenbankmanager entschieden. Der Grund: Probleme mit Archivierung und Recovery.

Die australische SGIO Building Society gab jetzt den totalen Stopp aller, Pläne bekannt, ihr Online-Produktionssystem auf das IBM-Produkt umzustellen. Die bei dem Anwender eingesetzte Konfiguration basiert auf einer IBM 4381 Modell 1 unter VSE als Gastsystem von VM.

Moniert wurde von dem australischen IBM-Kunden, daß in einer SQL-Umgebung der Zeitaufwand für das Archiv-Recovery unzumutbar werde, wenn auch nur ein kleineres Subsystem einer Hauptdatenbank ausfalle. Das Problem trat bei SGIO erstmals auf, als das Unternehmen mit SQL als Reportsystem Erfahrungen sammelte.

Kommentierte ein Unternehmenssprecher: "Als eine kleine Datenbank, die zur Rechnungserstellung benötigt wird, Defekte aufwies, konnten wir die Transaktionen, die auf diese Datenbank zugriffen, stillegen und die notwendigen Reparaturen durchführen. Das restliche System ließ sich trotzdem weiterbenutzen." Allerdings habe dieser Vorfall den Verantwortlichen bei SGIO klargemacht, welches Risiko ständig droht: "Auch wenn ein Teil einer SQL-Datenbank zerstört wird", er klärte der Unternehmenssprecher, "ist alles verloren. Ein Recovery nur bei einem Teil der Datenbank ist nämlich nicht möglich sondern es muß immer das Gesamtsystem einbezogen werden." Mit solchen Schwierigkeiten habe man nicht gerechnet

In IBM-Kreisen wurde bestätigt daß SQL/DS im Gegensatz zu DL/1 nicht das Recovery eines Datenbankteils erlaubt, während Anwendungsprogramme auf die anderen Sektionen zugreifen können.

Zwar existiere das Problem prinzipiell auch unter VM. Die für das Archiv-Recovery benötigte Zeit werde jedoch minimiert, weil unter VM mehrere SQL/DS-Systeme laufen könnten. VSE verkrafte hingegen nur ein System, hieß es bei IBM.