Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

15.01.1999 - 

Von BMC zu IBM und dann zu IDI

Von BMC zu IBM und dann zu IDIRechenzentrale spart mehrere Millionen ein

MÜNCHEN (ua) - Spannender als jeder Krimi wars. Dabei wechselte die Rechenzentrale Bayerischer Genossenschaften EG (RBG) nur ihre Datenbank-Utilities: weg mit den BMC-Werkzeugen, her mit den IBM-Tools. Seither spart das Rechenzentrum bei der IMS- Reorganisation Millionen Mark sowie Lauf- und CPU-Zeit. Nun ist es Zeit, die IBM-Produkte durch IDI-Tools zu ersetzen.

"Der erste Termin ging voll in die Hosen", erinnert sich Rudolf Raab, Leiter der Abteilung Informationssysteme bei der RBG, an die Kontaktaufnahme zu Innovative Designs (IDI). Der Vertriebsbeauftragte erschien nicht. Dabei hatte er am Telefon "dick aufgetragen" und behauptet, die IMS-Werkzeuge des kalifornischen Softwareherstellers aus Napa leisteten soviel wie vergleichbare BMC-Tools. Das war im August 1998, als beinahe schon eine Entscheidung für Produkte eines Mitbewerbers gefallen war. "Ich mußte dem Vorstand die Entscheidungsvorlage tatsächlich aus der Hand nehmen", erzählt Raab. Denn IDI bekam eine zweite Chance. Dieser Kontakt endete mit einem Testvertrag.

Es gehört nicht zu den täglichen Aufgaben eines Rechenzentrums, bewährte Tools auszutauschen. Die RBG wechselt nun schon das zweite Mal innerhalb eines Jahres die Pferde, und zwar aus Kostengründen. Das erste Mal musterte das Rechenzentrum die IMS- Werkzeuge "Load Plus" und "Secondary Index Utitility" (Siu) der BMC Software Inc., Houston, aus.

Den Anlaß lieferte die im Herbst 1997 fällige Steigerung der Rechenleistung um rund 240 Million Instructions per Second (MIPS). Außerdem lief ein Wartungsvertrag mit BMC aus. Bei diesem wurden die Pflege und die Software-Upgrades für fünf Jahre im voraus bezahlt, berechnet nach von der RBG kalkulierten MIPS-Aufrüstungen (siehe Grafik). Der Vorteil solcher Verträge liegt darin, daß die Softwarelizenz- und -pflegekosten überschaubar bleiben. Das steigende Aufkommen von Online-Transaktionen und Batch-Jobs, zusammen rund zehn bis 15 Prozent jährlich, ließ die MIPS-Zahl bei der RBG 1997 von rund 720 auf 964 anwachsen. "Damit hatten wir rund 240 MIPS mehr an Bord als geplant, und mußten dafür nachzahlen", erläutert Raab. Allein die Upgrades der beiden BMC- Produkte hätten aber bereits 500000 Mark gekostet. Bis zum Jahr 2001 wären für die IMS-Tools mehr als drei Millionen Mark an BMC gegangen, bei 40 Prozent Rabatt auf den Listenpreis. Das erschien der Rechenzentrale zuviel. Sie sah sich nach Alternativen um, obwohl den RBG-Spezialisten dafür nur sechs Wochen blieben, und kündigte den Vertrag.

Die beiden BMC-Tools die 1997 zur Disposition standen, dienen dem schnellen Laden, dem Reorganisieren und Indizieren. Eine IMS- Datenbank, wie sie die RBG einsetzt - nach der Hierarchical Data Access Method (Hadam) -, ist vereinfacht dargestellt in zwei Bereiche aufgeteilt: den Root- und dem Overflow-Bereich. Der strukturierte Root-Bereich nimmt die Schlüsselfelder des Datensatzes sowie die Satzinhalte auf. Es entsteht eine Baumstruktur. Zeiger (Pointer) weisen von der Wurzel aus auf die Plätze, auf denen die restlichen Daten des Satzes gespeichert sind. Dabei kann ein Zeiger auf den nächsten verweisen. Ist der Root-Bereich voll, sichert die Datenbank die Sätze im Overflow- Bereich. 16 solche Erweiterungen, sogenannte Extends, der strukturierten Ablage sind möglich. Bis diese mittels Pointer durchsucht sind, kann geraume Zeit verstreichen.

Um das zu verhindern, muß die Datenbank reorganisiert werden. Dazu wird der komplette Inhalt in eine sequentielle Datei geschrieben und die Datenbank physisch gelöscht. Es entsteht eine Tabula rasa, die sich mit Hilfe des Dateiinhalts neu füllen und strukturieren läßt.

Aus den Satzschlüsseln bildet das jeweils verwendete Utility neue Indices; so entsteht der Primary Index. Soll nach Feldern gesucht werden können, die keine Schlüsselfelder sind, müssen auch andere Daten indiziert werden, man spricht hier vom Secondary Index.

Das Reorganisieren der Datenbank kann nur offline erfolgen, im Batch-Fenster. In der Regel müssen die betroffenen IMS-Datenbanken der RBG einmal pro Woche dieser Prozedur unterworfen werden. Den Tools, die die BMC-Werkzeuge Load Plus und Siu ersetzen sollten, räumten die RBG-Spezialisten nur eine zehnprozentige Überschreitung der von den BMC-Werkzeugen benötigten Zeit ein.

Zunächst fiel das Augenmerk bei der Suche auf das Produkt "Partition Database Facility" (PDF) der texanischen Neon Systems Inc., Sugar Land, das hierzulande die IBM vermarktet. Der Einsatz dieses Tools hätte aufgrund der Einteilung in Partitions allerdings Veränderungen der Datenbankbeschreibung mit sich gebracht. Das aber war zu diesem Zeitpunkt nicht gewollt.

Die IBM-Standard-Utilities, die es zu IMS gibt, waren der RBG zu langsam und ein Online-Reorganisations-Tool nicht in Sicht. Ein solches Werkzeug werde seit Jahren von den Anwendern gefordert, führt Raab aus, und stehe ganz oben auf den Requirement-Listen der IBM-Anwendervereinigung Guide. Auch die RGB wünscht sich eine solche Lösung, doch zum Entscheidungszeitpunkt war keine verfügbar.

Schließlich wurde das Raab-Team bei den "IBM-Database-Tools" fündig. Diese Werkzeugsammlung enthält Lösungen, die IBM-Kunden geschrieben haben und dem Hersteller zum Verkauf überlassen. "Fast Reorganisation Reload" (FRR) und "IMS Index Builder" (IIB) sollten nun die BMC-Tools ersetzen. Doch die ersten Tests verliefen enttäuschend.

Für den Test mußte zunächst die Kundendatenbank "FS 01" herhalten. Dieser komprimierte Datenpool umfaßt 6,7 Millionen Segmente, verteilt auf 1000 Zylinder. Der erste Durchlauf mit FRR dauerte mit 28 Minuten mehr als dreimal so lange wie mit dem BMC-Tool Load Plus, mit dem das Laden neun Minuten brauchte. Dann trimmte das RBG-Team die Ein- und Ausgabe so, daß jeweils immer ein Zylinder im Buffer gespeichert war. Damit reduzierte sich die Laufzeit immer noch unbefriedigende 14 Minuten.

Da kam es der RBG zupaß, daß die IBM ein "Refresh" ihres "High Speed Sequential Retrieve" (HSSR), das dem schnellen Entladen von IMS-Datenbanken dient, zur Verfügung stellen konnte. Darin waren bekannte Fehler des Tools beseitigt. Außerdem bietet dieses Utility-Update eine Funktion, mit der die Datenbank bei den Entladevorgängen nicht mehr entkomprimiert werden muß. Demzufolge entfiel auch das Komprimieren beim Laden, so daß die FRR-Laufzeit nun nur noch sieben Minuten betrug.

Die CPU-Zeiten sind noch beeindruckender. Während beim Einsatz des BMC-Werkzeugs acht Minuten gemessen wurden, war der Prozessor beim FRR-Lauf ohne Entkomprimieren nur noch drei Minuten lang ausgelastet.

Die Testläufe bei der "kleinen" Datenbank "FS 37", die nicht komprimiert ist, waren von vornherein ermutigender. Die Load-Plus- Zeit betrug 120 Sekunden, die FRR-Zeit 80 Sekunden.

"Der interessanteste Test war der mit unserer Historiendatenbank FS 24", so Raab. FS 24 ist ebenfalls komprimiert, weist aber 44 Millionen Segmente und 3500 Zylinder auf. Die Load-Plus-Werte betrugen 49 Minuten Laufzeit und die FRR-Werte bei 27 Minuten; die CPU-Zeit mit dem BMC-Tool lag bei 28 Minuten, die CPU-Ergebnisse des FRR bei acht Minuten.

Auch das zweite Werkzeug IIB überraschte Raab mit guten Laufzeiten - und zwar auf Anhieb. Der Sekundärindex der Kundendatenbank mit 422000 Segmenten war mit dem BMC-Produkt innerhalb von 47 Sekunden aufgebaut, mit IIB in 31 Sekunden. Diese Laufzeiten gelten, wenn für die Indizierung eine spezielle Hilfsdatei erstellt wird. Steht dieses Workfile nicht zur Verfügung, muß die sequentielle Datei, in die die Datenbank beim Entladen geschrieben wird, mit einem Scan-Lauf durchsucht werden. Das Scannen dauerte mit dem BMC- Werkzeug 15 Minuten, mit IIB zwölf Minuten.

Überdies lagen die Investitionskosten erheblich niedriger als für die BMC-Produkte. Lediglich 68000 Mark mußte die bayerischen Rechenzentrale im Jahr 1998 für die Tools ausgeben: für IIB 54936 Mark und für FRR 13959 Mark.

Doch die RBG hatte Blut geleckt: Sie hatte erfahren, daß sich lang eingeführte Rechenzentrumswerkzeuge ersetzen lassen und der Ersatz befriedigender und billiger arbeitet. So war das Ende der IBM- Tools-Ära bald beschlossene Sache, zumal die IBM-Tool Anlaß zum Ärgern gaben (siehe Kasten "Flecken trüben den Glanz").

Im Sommer 1998 stellte der bereits einmal favorisierte Anbieter Neon Produkte zur Datenbankreorganisation in Aussicht, denen Anfang 1999 Tools für die Online-Reorganisation folgen sollten. Die Betaversion der Neon-Werkzeuge wurde getestet und schließlich der Vertrag vorbereitet.

Dann rief der Vertriebsbeauftragte von IDI an. Die Ergebnisse der Testläufe mit den Reorganisations-Tools überzeugten: Das Laden der Kundendatenbank nahm beim Einsatz von FRR sieben Minuten und zehn Sekunden in Anspruch, mit dem vergleichbaren Neon-Tool sieben Minuten und eine Sekunde, mit dem IDI-Utility drei Minuten und 20 Sekunden. Beim Entladen zeigte IDI, was seine Produkte sonst noch konnten. Der Lauf mit dem Neon-Produkt dauerte drei Minuten und 44 Sekunden, mit dem IDI-Tool zwei Minuten 18 Sekunden. Das Anlegen der Sekundär-Indices im Scan-Lauf schließlich benötigte mit IIB zwölf Minuten, mit Neon zwei Minuten und 48 Sekunden und mit dem IDI-Produkt zwei Minuten und 18 Sekunden. Ein Tuning der IDI- Werkzeuge war für diese Ergebnisse nicht notwendig.

Bezahlt hat die RBG für die IDI-Produkte 576000 Mark. Im Preis enthalten sind die Utilities für das Entladen, das Laden und für den Aufbau der Sekundärindices. Die Einsparungen gegenüber den Kosten für die IBM-Database-Tools belaufen sich damit im Zeitraum von 1999 bis 2003 auf rund 1,3 Millionen Mark.

Drei Millionen Mark hätte die RBG in fünf Jahren gespart, wenn sie statt der BMC-Werkzeuge die IBM-Database-Tools eingesetzt hätte. Der Berechnung zugrunde liegt der Erkenntnisstand zum Entscheidungszeitpunkt. Damals hätte die RBG 40 Prozent Rabatt auf den Listenpreis erhalten. Das Rechenzentrum kalkulierte allerdings mit MIPS-Zahlen, die schon im Jahr 1998 überschritten wurden; statt 910 hatten die Rechner im November eine Leistung von 1432 MIPS. Damit hätten sich die tatsächlichen Wartungskosten erhöht. Beim Einsatz der IDI-Werkzeuge, die seit Oktober 1998 produktiv laufen, anstelle von IBM-Produkten spart die RBG im Zeitraum von 1999 bis 2003 zusätzlich 1,3 Millionen Mark ein. Quelle: RBG

Der Sparer

Rudolf Raab (43) ist bereits seit 1985 bei der Rechenzentrale Bayerischer Genossenschaften EG (RBG), München. Er kam als selbständiger Unternehmensberater ins Haus, um den TP-Monitor "Cosmos" von der Großrechnerplattform BS/2000 auf BS/3000 umzuschreiben. Seit zehn Jahren ist er Abteilungsleiter Informationssysteme und als stellvertretender Bereichsleiter Systemtechnik zuständig für Datenbank- und Data-Communication- Monitore. Raab hat beim DV-Bildungszentrum München eine Ausbildung zum DV-Assistenten gemacht, war dann bei Siemens und anschließend in der Anwendungsentwicklung für die Bundesvermögensverwaltung tätig.

Zentrale Hausnummern

Heute verfügt das Rechenzentrum über eine Leistung von 1451 MIPS. Davon entfallen 546 MIPS auf den Großrechner Amdahl GS 795, 640 MIPS auf den Host IBM 9672-R66 und 265 MIPS auf den Mainframe Amdahl GS 575. Die kleinere Maschine dient der Applikationsentwicklung und der Netzadministration. Die beiden anderen Rechner beherbergen die Buchungsapplikationen. Auf ihnen ist jeweils ein IMS-System installiert, zu dem jeweils 1000 IMS- Datenbanken gehören. Die Anzahl der Buchungsposten beläuft sich auf rund 760 Millionen bei etwa 17 Millionen Konten. Mit Hilfe des "Emc2"-Features "SRDF" spiegelt die RBG ihre Platten synchron, so daß sich der Plattenplatz auf 12000 GB summiert. Die Anzahl der IMS-Transaktionen beläuft sich auf rund 1,2 Milliarden jährlich.

Die Kontenbewegungen wie Überweisungen, Ein- und Auszahlungen erfolgen in der Regel als Batch-Messaging Processing (BMP). Während "normale" Batch-Jobs, bei denen sequentielle Dateien verarbeitet werden, nur offline ausgeführt werden können, erlauben IMS-Datenbanken einen zu Online-Transaktionen konkurrierenden Betrieb. "Wir haben keine Offline-Zeiten", sagt Raab.

Neben IMS-Datenbanken, seit Herbst dieses Jahres mit den Management-Werkzeugen Release 6 verwaltet, setzt die RBG auf den Großrechnern auch relationale Datenbanktechnik ein: DB/2 von der IBM. Doch ist laut Raab der intensive Einsatz des hierarchischen Systems, das vor 30 Jahren geboren wurde, gewollt. So schrieben die Entwickler zwar neue Anwendungen für DB/2, aber es gebe kein Migrationsvorhaben, bei dem aus IMS- DB/2-Daten würden. DB/2 sei in der Regel CPU-intensiver und setze zudem bei jedem Entwickler die Kenntnis des kompletten Relationenmodells voraus.

Flecken trüben den Glanz

Die Erfahrungen der RBG mit den IBM-Database-Tools "FRR" und "IIB" waren glänzend. Trotzdem gibt es ein paar blinde Flecken. So konnte der IIB zunächst keinen Primärindex aufbauen. Die IBM lieferte diese Funktion erst im Sommer 1998.

Sehr ärgerlich waren kryptische IIB-Fehlermeldungen. Zum Beispiel standen in der Datenbankbibliothek veraltete, ungültige Beschreibungen. Statt diesen Fehler kundzutun, spuckte das System drei rätselhafte Zeilen in der Beschreibungssprache Rexx aus. Das verursachte der RBG unnötigen Suchaufwand.

Für Raab "am schlimmsten" stellte sich jedoch ein sporadisch auftretender Fehler dar: Ein Job brach ab, beim Neustart aber war der Fehler verschwunden. Was wie eine Fehlfunktion von IIB aussah, stellte sich schließlich als Problem der Zugriffsmethode Virtual Sequential Access Meethod (VSAM) heraus. IIB und dieses Verfahren harmonierten nicht. "Wir haben der IBM dazu Unterlagen ohne Ende geliefert", sagt Raab, "aber keine Lösung bekommen."

17 Millionen Konten

Die Rechenzentrale Bayerischer Genossenschaften e.G. (RBG) entstand im März 1966. Damals tat sich die Datenverarbeitung des Bayerischen Raiffeisenverbands mit der Zentralkasse Bayerischer Volksbanken zusammen. Heute verwaltet die RBG rund 17 Millionen Konten von knapp 600 Mitgliedern. Dazu zählen neben den 581 Partnerbanken, die 1997 eine Bilanzsumme von rund 179 Milliarden auswiesen, auch Lagerhäuser, Elektrizitätsversorgungsunternehmen, Wasserzweckverbände, Brauereien und Privatpersonen sowie Vereine. Das macht 760 Millionen Buchungsposten und 1,2 Milliarden Dialog- Transaktionen im vergangenen Jahr. Das Rechenzentrum der RBG war ursprünglich auf zwei Standorte verteilt: München und Nürnberg. Seit April 1997 befindet es sich ausschließlich in Nürnberg.

Abb: Drei Millionen Mark hätte die RBG in fünf Jahren gespart, wenn sie statt der BMC-Werkzeuge die IBM-Database-Tools eingesetzt hätte. Der Berechnung zugrunde liegt der Erkenntnisstand zum Entscheidungszeitpunkt. Damals hätte die RBG 40 Prozent Rabatt auf den Listenpreis erhalten. Das Rechenzentrum kalkulierte allerdings mit MIPS-Zahlen, die schon im Jahr 1998 überschritten wurden; statt 910 hatten die Rechner im November eine Leistung von 1432 MIPS. Damit hätten sich die tatsächlichen Wartungskosten erhöht. Beim Einsatz der IDI-Werkzeuge, die seit Oktober 1998 produktiv laufen, anstelle von IBM-Produkten spart die RBG im Zeitraum von 1999 bis 2003 zusätzlich 1,3 Millionen Mark ein. Quelle: RBG