Oppolzer - Informatik / Blog


Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

Historie - Probleme mit Oracle bei der SSB in den 1990er Jahren

Subject:

Probleme mit Oracle auf VM/ESA

From:

Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>

Reply-To:

Date:

2015.01.15 19:15:00


Zu den Problemen, die wir seinerzeit hatten:

es ging um ein Projekt bei der Stuttgarter Straßenbahnen AG.

Wir hatten auf den dezentralen Systemen (OS/2 und Unix) auch Oracle im
Einsatz und dort auch kein Problem damit. Auf dem Mainframe (den die SSB damals
noch hatte), hatten wir SQL/DS bzw. (neuer Name) DB2/VM. Das lief auch gut; wir hatten
Schnittstellen zu SAP R/2 gebaut und zu PASCAL, um es auch im technischen Vorstandsbereich
einsetzen zu können. Eigentlich war alles gut. Die meiste Last lief mit COBOL unter VSE.

Dann kam aber die Idee auf, ein einheitliches DB-System auf allen Plattformen zu haben,
und dafür bot sich eben Oracle an, weil es auch auf dem IBM-Mainframe (unter VM) verfügbar
war. Also haben wir das für damals 250.000 DM bestellt und installiert.

Oracle auf VM war aber - im Unterschied zu SQL/DS usw. - dermaßen lieblos auf VM portiert
worden, dass die Performance völlig indiskutabel war. Jeder ORACLE-Prozess war eine
separate VM-Maschine. Wir konnten auf dieser Architektur unsere Service-Levels
unmöglich erreichen. Ich habe externe Unterstützung geholt (von BMW z.B.), aber es
war sehr schnell klar, dass wir die Investition abschreiben müssen. Bzw: wir haben es
immerhin erreicht, dass Oracle die Lizenz wieder zurückgenommen hat und das Geld
auf spätere Lizenzen auf den anderen Plattformen angerechnet hat.

Ein weiteres Thema war:

bei DB2-Zugriffen über das Netzwerk (Client-Server)
geschieht das Zusammenfassen verschiedener Fetch-Aufrufe zu größeren Blöcken
innerhalb der Netzwerkkomponente automatisch (BIND-Parameter BLOCK bzw. BLOCKING
in den DB2-Clients); bei ORACLE muss dazu ein Array Fetch in der Anwendung codiert
werden. Wenn der Softwareanbieter das nicht macht, haben Sie ein Problem. Wir hatten
z.B. eine Fahrplan-Konstruktions-Software, die 10fach überhöhte I/O-Zeiten gebraucht hat,
weil der Array Fetch in der Anwendung gefehlt hat ... d.h.: Sie sind bei Oracle darauf
angewiesen, dass die Anwendung speziell für Oracle optimiert ist ... mit Hilfe von
Nicht-Standard-Erweiterungen ... um akzeptable Performance zu erhalten, und Sie müssen
im Zweifel mit Ihren Software-Anbietern darüber Diskussionen anzetteln.

Das war Mitte der 90er Jahre ... ich weiß nicht, ob das inzwischen besser ist.

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie