Oracle ESL aus Sicht eines Software-Herstellers (ISV)

Setzt man als Applikations-Hersteller auf Oracle-Produkte auf, steht man auch vor der Frage, welche Lizenz – z.B. Full Use oder Application Specific Full Use (ASFU) – die passende ist oder ob man besser das von Oracle angebotene integrierte Modell (Embedded Software License – ESL) nutzt. Allein unter wirtschaftlichen und konzeptionellen Gesichtspunkten empfiehlt sich zweifelsohne das Oracle Embedded Software Model (ESL). Der Teufel steckt jedoch im Detail: Die SIV.AG hat vor ca. zwei Jahren begonnen, die Technologieplattform (Oracle-Datenbank und -Middleware) in ihre neue Version des ERP-Systems kVASy einzubetten und die etwa 200 Bestandskunden auf die neue Version zu migrieren. Während die Kaufleute und IT-Strategen recht schnell die Mehrwerte sahen, waren die Administratoren zu Recht eher skeptisch. Diesen Widerspruch aufzulösen, war eine wesentliche Voraussetzung, das Embedded Model erfolgreich zu platzieren.

Als Technologie-Tochter der SIV.AG war die SIV.A&T in diese Diskussionen und die Entwicklung der Lösungen wesentlich involviert – im Folgenden möchte ich die wesentlichen Aspekte mit Fokus auf die Oracle-Datenbank dazu diskutieren.

Die Herausforderungen

Interaktive Administration

Das übliche Werkzeug für die Administration im Dialog ist die Datenbank-Konsole (Enterprise Manager bzw. Grid Control). Diese darf im Rahmen von ESL nicht durch Endkunden (dazu gehört leider auch der Administrator) genutzt werden. Über die Sinnfälligkeit dieser Restriktion mag man herzlich streiten wollen – der Lizenzvertrag sieht es aber nun einmal so vor und ist (nach unserer Erfahrung) diesbezüglich nicht verhandelbar – als ISV ist man also gezwungen, eine Alternative als Bestandteil der Anwendung zu implementieren.

Da es keine zu integrierende Lösung am Markt gab, haben wir das bereits in Anfängen vorhandene Werkzeug quasiDBA zur Reife gebracht.

Ziel der Entwicklung war es, keinen eins-zu-eins-Ersatz für den Konsole zu implementieren, sondern Best Practice verbunden mit maximaler Effizienz umzusetzen. Zugleich standen wir vor der Herausforderung, sowohl dem erfahrenen DBA als auch dem Anwendungsbetreuer, der die Datenbank quasi nebenbei betreut, eine angemessene Lösung zu liefern. Dazu haben wir möglichst viele Einzelaktionen in den Dialogen zusammengefasst und Datenbank-Features, die im Betrieb unserer Anwendung nicht relevant sind, nicht angeboten. Im Ergebnis kann der DBA nun seine Aufgaben mit wenigen Klicks schnell erledigen bzw. Fehler/Probleme einfach erkennen und in der Regel mit einem Klick abstellen. Probleme, die der DBA vor Ort nicht lösen kann, werden so dargestellt, dass er unserem Support die notwendigen Informationen mit wenig Aufwand zur Verfügung stellen kann.

Auf der anderen Seite setzt der zuverlässige Betrieb einer datenbank-zentrierten Anwendung wie kVASy voraus, dass alle Schemaobjekte gültig, mit aktuellen Optimizer-Statistiken versehen, korrekt indiziert… sind. Dies kann man mit der Datenbank-Konsole auch prüfen und abstellen, wobei man dazu wissen muss, was man wie prüft bzw. korrigiert. quasiDBA liefert diverse Ansichten, die solche Probleme anzeigen und schnell korrigieren können.

Ebenso kritisch ist die richtige Konfiguration der Datenbank (Parameter, Systemprivilegien…). Diese ändert sich zudem im Laufe der Zeit, wird beim Anwender jedoch nicht immer konsequent mit den Updates aktualisiert. quasiDBA bietet hier mit dem Konfigurator die Lösung, indem ein Konfigurationsfile, das als Bestandteil eines Updates ausgeliefert wird, interpretiert und mit der aktuellen Konfiguration verglichen wird – im Ergebnis passt der quasiDBA die Konfiguration an, wobei der DBA die Änderungen verfolgen und ggf. auch verweigern kann.

quasiDBA

Sessionmonitor quasiDBA

Diese Lösung haben die Administratoren der kVASy-Anwender sehr gut angenommen; SIV.A&T bietet quasiDBA gern anderen Oracle-Partnern sowie interessierten Administratoren an.

Administration auf der Kommandozeile

Neben der interaktiven Administration werden zumindest Teile der Administration üblicherweise automatisiert (Shell-Scripts) und/oder auf der Server-Konsole erledigt. Da der Endbenutzer die Oracle-Binaries (rman, SQL*Plus…) im Rahmen von ESL nun nicht mehr direkt benutzen darf, muss auch hier ein Ersatz als Bestandteil der Anwendung geliefert werden. Die SIV.AG liefert dazu die kVASy-Admin-Shell, welche die notwendigen Administrationsaufgaben vereinfacht und zugleich die Oracle-Werkzeuge kapselt.

Backup & Recovery

Backup & Recovery sind ein, wenn nicht gar das, wichtige Thema für den Datenbank-Administrator schlechthin. Insofern muss diesem Thema extra Aufmerksamkeit gegönnt werden. Die Kombination kVASy-Admin-Shell und quasiDBA (in Verbindung mit dem Recovery-Advisor der Datenbank) haben unseren Kunden hierfür die passende Lösung geliefert.

Interaktiver Zugriff auf die Datenbank außerhalb der Anwendung

Die kVASy-Anwender hatten im Laufe der Zeit diverse individuelle SQL-Auswertungen außerhalb der Anwendung implementiert. Dazu nutzten sie unterschiedliche SQL-Werkzeuge wie TOAD oder auch SQL*Plus. Dieses Szenario ist mit ESL nicht mehr zulässig, ein Ersatz musste zwingend geboten werden, da das Standard-Reporting oder auch die verfügbare BI-Option nicht die Anforderungen, welche damit umgesetzt wurden, erfüllen konnte. Glücklicherweise konnten wir im Rahmen unserer Oracle-Lizenzen den Discoverer als Alternative platzieren. Dies wurde jedoch durch die Möglichkeit, Abfragen innerhalb unserer Anwendung zu formulieren und wiederholbar auszuführen, ergänzt.

Schnittstellen zu Drittprodukten

Drittprodukte dürfen nur über definierte (dokumentierte) Schnittstellen, die Bestandteil der eigenen Anwendung sind, integriert werden. Ein wichtiges Kriterium dabei ist, dass diese Schnittstellen mit der eigenen Software zusammen gewartet und im Standard-Rollout enthalten sind.

Die Erfahrung zeigt, dass hier ggf. etwas Aufwand zu investieren ist, um eine Bestandsaufnahme und eventuelle Bereinigung zu realisieren.

Installation der Oracle-Software

Die ESL-Lizenzbedingungen fordern außerdem, dass auch die Installation der Oracle-Produkte Bestandteil der Anwendungsinstallation ist. Spätestens, wenn es um das Aufsetzen von Testsystemen beim Kunden geht, muss man hierzu eine Lösung anbieten. Wir haben den Oracle Installer im Silent Mode hinter einem eigenen UI versteckt – der Aufwand rechnet sich, indem wir nun standardisierte Installationen bei den Kunden vorfinden und zudem sichern, dass Anwendungskomponenten (z.B. kVASy-Admin-Shell), die auf dem Datenbankserver zu installieren sind, auch wirklich immer installiert wurden.

Technischer Support

Auch der Support der technische Oracle-Produkte ist im Zusammenhang mit ESL neu zu bewerten. Während Oracle mit http://support.oracle.com einen 24×7-Support sicherstellt, ist dies für einen ISV unter Umständen eine echte Herausforderung. Auch die Bereitstellung und Installation von Patches ist zu leisten.

Fazit

Mehrwerte produzieren!

Wir haben die Restriktionen des ESL-Modells als Chance gesehen, mit den Alternativ-Szenarien Mehrwerte für die Anwender und insbesondere für die Administratoren zu verbinden. Damit war die notwendige Akzeptanz des neuen Lizenzmodells durchgängig zu erreichen und letztlich erfolgreich umzusetzen.

Partner suchen!

Insbesondere die Administrationswerkzeuge – vor allem den quasiDBA – zu implementieren, war mit erheblichem Aufwand verbunden. Wir mussten diesen Aufwand betreiben, da es zum damaligen Zeitpunkt keine vergleichbare Lösung gab. Wenn es jedoch taugliche Lösungen wie beispielsweise den quasiDBA gibt, sollte man diese besser integrieren. Die SIV.A&T bietet Oracle-Partnern die Integration des quasiDBA in ihre Anwendung mit einem passenden Preismodell an.

Teile diesen Artikel:
Tagged with →  

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *