ORDIX News Kosten senken mit VMware Tanz den

Transcrição

www.ordix.de
ORDIX News
Das IT-Magazin der ORDIX AG
Ausgabe 4/2004
€ 2,20
Tanz den REORG
Reorganisierung und Defragmentieren
mit Oracle 10g S. 8
Der Tiger
ist los
Spracherweiterungen
von Java 1.5.0. S. 20
ORDIX erweitert
Vorstand und
Aufsichtsrat
Benedikt Georgi wird neues
Vorstandsmitglied,
Wolfgang Raum Mitglied
im Aufsichtsrat S. 14
Kosten
senken mit
VMware
Virtuelle Maschinen
in der Praxis S. 14
ORDIX bei T-Systems:
System Management
mit PATROL live
S. 5
Editorial
Paderborn, Dezember 2004
Happy New Year
Über vieles hätte ich dieses Mal schreiben können: Über Bushs Wiederwahl (Uaah dieses Mal sogar tatsächlich
wieder gewählt, die Amis werden einfach nicht schlau!), über Powells Rücktritt (Warum eigentlich nicht Rumsfeld?)
oder die Gesundheitsreform der Union (Wenn man davon nur nicht krank wird ...).
Nichts von alledem. Da ich auch dieses Editorial mal wieder mitten in der Nacht schreibe, wie schon so viele zuvor,
ist für mich das wichtigste in dieser News die Erweiterung des ORDIX Vorstandes. Vielleicht schaffe ich es ja mit der
News 1/2005 einmal, diese Seite zu normalen Arbeitszeiten zu schreiben.
Ab dem 1.1.2005 (naja vermutlich 3.1.2005 :-) ) steht mir mit Herrn Benedikt Georgi ein neuer Kollege zur Seite (s.
Seite 16), der sukzessive viele meiner Tätigkeiten übernehmen wird. Keine Angst, das heißt nicht, dass ich mich zur
Ruhe setzen werde. Aber es werden Herrn Röber und mir dadurch Freiräume geschaffen, die wir weitestgehend
nutzen werden, um sie Ihnen, unseren Kunden, zu Gute kommen zu lassen.
Ich gehe davon aus, Sie werden das in den nächsten Wochen oder Monaten erfahren können. Neben Herrn Georgi
habe ich mit Herrn Wolfgang Raum ein neues Aufsichtsratsmitglied gefunden, das ebenfalls aktiv in das ORDIX
Leben eingreifen soll. Mit seiner Erfahrung ist er für uns ein guter Ratgeber. Dass ORDIX ohne ihn in dieser Form
(und zumindest in Paderborn) nicht entstanden wäre, ist vielen (darunter auch Herrn Raum selbst) sicher nicht so
bewusst gewesen.
So muss ich mich als Franke in Nordrhein Westfalen herumschlagen und Zeitungsartikel präsentieren: Dazu gehören ein paar sehr interessante Informationen zum Thema Konsolidierung Konsolidieren ist ja mit Sparen gleichzusetzen (VMware, gewachsene Serverfarm), die ITIL-Zertifizierung von ORDIX Mitarbeitern und ein Projektbericht
über den nutzbringenden Einsatz von PATROL. Daneben berichten wir viel über Oracle 10g, Reorganisation (mit IBM
Informix und Oracle 10g) und natürlich, für die Entwickler unter Ihnen, über Java und Application Server.
Unser Java Tiger auf dem Titelbild tanzt im Übrigen Jive (sagte mir unsere Grafikerin). Zwei Spuren im Schnee ...
Obwohl, bei Tigerspuren würde ich mir schon Gedanken machen: Ich hoffe, wenn ich über Weihnachten zum Skifahren entschwinde, treffe ich höchstens auf Pisten präparierende Schneekatzen!
Bleibt nur noch was über den Kanzler- und Bundespräsidenten-Konflikt zu sagen: Also der Kanzler spricht zu Neujahr, der Bundespräsident zu Weihnachten (oder umgekehrt?). Hauptsache man packt nicht wieder Helmut Kohls
zweimal gezeigte Rede aus.
In diesem Sinne wünsche ich Ihnen geschäftlich alles Gute zum Jahresendspurt, schöne Weihnachten, etwas Erholung zwischen den arbeitgeberfreundlichen Feiertagen, um dann mit Anlauf in ein hoffentlich in jeder Beziehung
gutes Jahr 2005 zu starten.
Wolfgang Kögler
3
Inhaltsverzeichnis
Aus- & Weiterbildung
Standards
15 ... Seminar: Linux Hochverfügbarkeits-Cluster
36 ... Seminar: Oracle Troubleshooting
03 ...
04 ...
23 ...
45 ...
Unix/Linux/Open Source
System Management
24 ... Seminarübersicht: Preise, Termine ... bis August 2005.
10 ... Serverkonsolidierung der etwas anderen Art
Projektbericht über die Konsolidierung einer Kunden-DMZ,
die unter bestimmten Kriterien zu einer Minimierung der administrativen Aufgaben führen soll.
Titel-
14 ... Virtuelle Maschinen in der Praxis thema
Mit dem VMware ESX Server bringen Sie mehr Effizienz in
Ihr Rechenzentrum und senken deutlich die Betriebskosten.
Aktuell
Editorial
Inhalt
Leserinformation
Impressum
05 ... System Management im Sauerland
Projektbericht zum Einsatz von Distribution Server und Configuration Manager bei der T-Systems.
Java/XML
16 ... Neue Mitglieder im Vorstand und Aufsichtsrat der
ORDIX AG: Benedikt Georgi und Wolfgang Raum
Titelthema
23 ... ORDIX Mitarbeiter ITIL-zertifiziert
Durch die Zertifizierung stellt die ORDIX AG ihre langjährige
Erfahrung jetzt auf ein offiziell anerkanntes Fundament.
26 ... Rückblick: 1. ORDIX Benefiz Golf Open
Charity Golfen für notleidende Kinder.
31 ... Larry Ratlos in Larry, Wildcards und rm
42 ... Rückblick: ORDIX auf der Linux World Expo
43 ... Einladung zum META-DOK Testday
Erarbeiten Sie am 22.02.05 Ihr individuelles Szenario für
Dokumenten- und Informationsmanagement selbst am PC.
Titel-
20 ... Der Tiger ist los thema
Die neuen Spracherweiterungen von
Java 1.5.0.
37 ... J2EE und Persistenz:
Ein heißes Eisen (Teil I)
Darstellung der Persistenzstrategie in einem größeren, auf J2EE basierenden
Softwareprojekt.
44 ... Reihe Application Server im Vergleich
(Teil II): JBoss
Mittlerweile gehört JBoss weltweit zu
den am meisten verbreiteten J2EE Application Servern.
Datenbanken
itel-
T
08 ... Oracle 10g (Teil III): Tanz den REORG th
ema
Neue Features dbms_redefinition und Segment Shrink helfen bei der Reorganisation von Tabellen und bei der Defragmentierung von Segmenten.
32 ... Oracle Internet Directory (Teil III)
Der Einsatz des OID zur zentralen Benutzer- und Rollenverwaltung für Oracle
Datenbanken.
12 ... Dokumentieren mit PLDoc
PLDoc untersucht den Programmcode und generiert daraus
eine anschauliche Dokumentation auf Basis von HTML.
40 ... Integriertes Reporting für OracleAnwendungen
Mit dem Oracle AS Discoverer können
u. a. die Berichte im Intra- oder Internet
veröffentlicht werden.
18 ... Alles neu macht 10g (Teil I)
Backup und Recovery mit Oracle 10g.
28 ... IBM IDS Reorganisation (Teil I): Interne Architektur
Mit dem Mythos Viele Extents bedeuten schlechte Performance wegen schlechterem I/O Verhalten wird aufgeräumt.
4
46 ... Oracle 10g RAC 380V
So sicher wie das Stromnetz?
Titelthema
System Management - Titelthema System
T-Systems,
Management
Meschede
Projektbericht: ORDIX unterstützt T-Systems, Meschede
System Management im Sauerland
Die Installation und die Konfiguration von PATROL Agenten stellt in größeren Umgebungen eine nicht zu
unterschätzende organisatorische und technische Herausforderung dar insbesondere in einer FirewallUmgebung.
Dieser Projektbericht beschreibt den Aufbau einer PATROL 7 Architektur bei der T-Systems und wie die beiden
BMC Produkte Distribution Server und Configuration Manager das Leben eines PATROL Administrators
erleichtern können, wenn man sie richtig einsetzt.
Großer Aufwand in einer FirewallUmgebung
Werden sehr viele Agenten und Knowledge
Module manuell installiert und konfiguriert, ist
das nicht nur sehr zeitaufwändig, sondern führt
auch sehr schnell zu einem unübersichtlichen
Durcheinander. Der Einsatz des Distribution
Servers und des Configuration Managers erleichtern das Leben des PATROL Administrators.
Der Einsatz erfordert aber auch große Vorbereitungsmaßnahmen, die in einer engen Zusammenarbeit mit den Netzwerkprofis des Unternehmens erfolgen. In einer Firewall-Umgebung sind diese Aufgaben besonders aufwändig, da diese Produkte teilweise unterschiedliche Kommunikationswege verwenden.
Eine solche Umgebung trafen wir auch bei der
T-Systems in Meschede an. Es sollten ungefähr 300 Agenten mit entsprechenden Knowledge Modulen (KMs) und PATROL 7 Konsolen zur Überwachung eingesetzt werden. In
Zusammenarbeit mit den Mitarbeitern der
T-Systems, Meschede, entwickelte die ORDIX
AG ein Konzept und setzte dieses auch um.
Eine Übersicht über die realisierte Architektur
zeigt Abbildung 1.
Eingesetzte BMC Produkte
Distribution Server
Der Distribution Server wird eingesetzt, um
Software von einer zentralen Stelle installieren
und verteilen zu können. Dies vereinfacht und
beschleunigt die Installation der PATROL Software sehr. Die Software wird von einem zentralen Rechner auf den zu überwachenden
Rechner per Mausklick installiert oder auf den
neuesten Stand gebracht. Die Verteilung erfolgt
auf beliebige Windows- und Unix-Rechner. Dort
wird die Software vom Distribution Client entgegengenommen und installiert.
Configuration Manager
Mit Hilfe des Configuration Managers werden die PATROL Agenten konfiguriert. Der Configuration Manager bietet die Möglichkeit, organisatorische Strukturen (Agentengruppen) für gleiche
oder ähnliche Agenten zu erstellen. Dies vereinfacht die Konfiguration erheblich. Ab Version 1.5.00 verfügt der Configuration Manager auch über eine Reporting-Funktionalität, welche die Dokumentation der Agentenkonfiguration unterstützt.
Notification Server
Notification Server nehmen die Alarm-Events von den Agenten
entgegen, leiten die Informationen an die entsprechenden verantwortlichen Personen per E-Mail weiter und legen die Events in
einer Datenbank ab. Das Versenden der Events per E-Mail ist an
dieser Stelle eine Zwischenlösung. Die Mitarbeiter der T-Systems
arbeiten gerade an einem Konzept für ein Benachrichtigungsverfahren. Das Ziel ist, die Benachrichtigungswege sicherer und
vor allem konfigurierbar zu machen. Zur Zeit sind zwei Notification
Server im Einsatz.
PATROL Console Server
Der PATROL Console Server hält die Verbindung zu den Agenten
und speichert die Informationen darüber ab. Beim Console Server bestand unsere Hauptaufgabe darin, die bis dato angelegten
Management Profile zu konsolidieren.
Um hier Abhilfe zu schaffen, ermittelten wir zuerst, welche unterschiedlichen Management Profile überhaupt notwendig waren und
erstellten dann wenige, allgemeingültige Profile, die den entsprechenden Mitarbeitern zugeordnet wurden.
Es wurde ein Benutzerkonzept erstellt, welches die Rechte der
einzelnen Benutzer stark einschränkte. So können Änderungen
an den Management Profilen jetzt nur noch von den PATROL Administratoren vorgenommen werden.
RT-Server
Die Real Time Server (RT-Server) übertragen die Daten zwischen
den PATROL Agenten und dem PATROL Console Server. Zur Zeit
sind 5 RT-Server im Einsatz. Die Anzahl resultiert zum einen aus
der Firewall-Umgebung und zum anderen aus der geforderten
Hochverfügbarkeit. Jeweils zwei RT-Server sind für eine Seite der
5
System Management
%DFNXSZHJ
):
):
&HQWUDO
1RWLILFDWLRQ
6HUYHU
:HE&HQWUDO
$JH QWH Q
,QWHUQHW
&RQVROH
6HUYHU
1)6
576HUYHU
&RQVROH
6HUYHU
576HUYHU
$JHQWHQ
,QWHUQHW
576HUYHU
'6&
'6&
):
1RWLILFDWLRQ
6HUYHU
6HUYLFH
5HSRUWLQJ
$JH QWH Q
,QWUDQHW
'6&
'DWD
6WRUH
):
,QWHUQHW
,QWHUQHW
,QWUDQHW
,QWUDQHW
):
$JHQWHQ
,QWUDQHW
576HUYHU
'6&
'LVWULEX WLRQ
6HU YHU
&RQILJXUDWLRQ
0DQDJ HU
576HUYHU
):
(UVWZHJ
$JHQWHQ3RU WV
576HU YHU3RUWV
'6 :DNHXS3RUW
6HUYLFH5HSR UWLQ J
Abb.1: Die PATROL 7 Architektur bei der T-Systems.
Firewall zuständig. Beim Ausfall eines RT-Servers übernimmt der
andere die Agenten, Konsolen und den Console Server des anderen PATROL Base Reporting.
Firewall
Um die oben genannten Produkte und den damit verbundenen
Dienst in einer Firewall-Umgebung einzusetzen, ist es notwendig,
eine Reihe von Netzwerkports freizuschalten.
Jeder Dienst verfügt über eine eigene, virtuelle IP-Adresse, sodass
nach der eventuellen Verlagerung des Dienstes auf einen anderen Server keine Anpassungen in der Firewallkonfiguration notwendig sind.
Agenten und Konsolen
Agenten und Konsolen kommunizieren mit dem Console Server
über RT-Server. Da die Verbindung jeweils von der Konsole, dem
Agenten und dem Console Server aufgebaut wird, ist es notwendig, dass sich alle diese Komponenten direkt mit einem RT-Server verbinden.
Um die Kommunikation durch die Firewall zu ermöglichen, muss
der von den RT-Servern verwendete Port in der Firewall freigeschaltet werden. Die RT-Server auf den verschiedenen Seiten der
Firewall müssen so konfiguriert werden, dass sie eine RT-Server-Wolke bilden.
6
Distribution Server
Die Kommunikationswege zwischen dem Distribution Server und dem Distribution Client
müssen freigegeben werden. Es handelt sich
um die Ports für:
Installation des Distribution Clients, Richtung Distribution Client
den wake up Port, Richtung Distribution
Client
den antwort Port, Richtung Distribution
Server
Configuration Manager
Der Configuration Manager benutzt den Agentenport, um die Konfigurationen auf den Agenten zu verteilen bzw. von den Agenten zu holen. Dieser Port ist in beide Richtungen freigeschaltet. Es ist also der vom PATROL Agenten verwendete Port vom Rechner mit dem
Configuration Manager zu allen Agenten frei
zu schalten.
Notification Server
Der Weg von den Agenten zum Notification
Server muss freigeschaltet werden. Ebenso
System Management
muss der Kommunikationsport zwischen den
RT-Servern und den Agenten in beide Richtungen freigeschaltet sein.
Teilweise stößt diese Vorgehensweise bei
Kunden auf Unverständnis und lässt die Frage nach dem Sinn der RT-Server aufkommen.
Zuerst installiert man die RT-Server, um die
Kommunikation zwischen den PATROL Komponenten zu vereinheitlichen. Beim Einsatz
des Notification Servers, des Configuration
Managers und des Distribution Servers müssen aber zusätzlich noch weitere Ports in der
Firewall freigeschaltet werden. Es bleibt zu
hoffen, dass BMC dieses Manko schnell beseitigt und die Kommunikation aller Komponenten auch über den RT-Server ermöglicht.
Softwareverteilung mit dem Distribution
Server
Die neue Software wird in den Distribution Server importiert und zu einer Collection zusammengefasst. Die importierten Softwarekomponenten verfügen meistens über eine Installationsroutine, die bei der Konfiguration der
Collection durchgeführt wird. So entsteht ein
so genanntes Image für die neue Software,
das später auf dem Zielrechner installiert wird.
Hauptproblem:
Installation des Distribution Clients
Das Hauptproblem beim Distribution Server
liegt in der Installation des Distribution Clients.
tigungen und Profile zugeordnet. Dann wird die Installation des
Clients gestartet. Während der Installation bekommt der Client
die Informationen mitgeteilt, bei welchem Distribution Server er
sich melden soll.
Nach der erfolgreichen Installation meldet sich der Client beim
Distribution Server und kann registriert werden.
Sind alle Distribution Clients bereit, können die zu installierenden
Rechner zu einer Gruppe zusammengefasst werden. Bei der Definition einer Distribution wird festgelegt, welche Softwarekomponenten/Images zu welcher Zeit auf die Zielrechner einer Gruppe verteilt werden. Die Verteilung kann über die Reports verfolgt
werden.
Konfigurationsverteilung mit dem Configuration Manager
Es gibt leider keinen Mechanismus, der es ermöglicht, die in den
Distribution Server eingepflegten Agenten in den Configuration
Manager zu übernehmen. Die Agenten müssen daher im Configuration Manager nochmals manuell erfasst werden. Ab Version
1.5.00 gibt es allerdings die Möglichkeit, Agenten im Netzwerk
bzw. im Subnetz suchen zu lassen und in den Configuration Manager zu übernehmen.
Gruppierung der Agenten
Die Struktur des Configuration Managers wurde analog zum Reiter Systems im Distribution Server gestaltet und verfeinert, da
spezifische Anforderungen je System für die KMs notwendig sind.
Bei der Gruppierung der Agenten im Configuration Manager wurden die im Distribution Server verwendeten Gruppen des Reiters
Systems als Basis genommen und entsprechend den Anforderungen der einzelnen Rechner verfeinert.
In der Praxis hat sich die folgende Vorgehensweise bewährt: Wenn auf dem Rechner schon
ein PATROL Agent installiert ist, wird der Distribution Client über den PATROL Agenten installiert. Ist der Distribution Server auf dem
gleichen Rechner installiert wie der Configuration Manager, sind die Ports zu den Agenten schon freigeschaltet und können auch vom
Distribution Server verwendet werden.
Verschiedene RuleSets wurden definiert:
Manuelle Installation
Die Verteilung von Agentenkonfigurationen erfolgt nur über den
Configuration Manager. Auch das Customizing der Parameter erfolgt ausschließlich über den Configuration Manager. Die Änderungen der Parameter durch Konsolen sind nicht zugelassen.
Dadurch ist sichergestellt, dass alle Konfigurationseinstellungen
und Parameteranpassungen von einer zentralen Stelle aus vorgenommen werden und somit auch dokumentiert sind.
Ist noch kein Agent installiert, muss überlegt
werden, ob eine manuelle Installation des Distribution Clients einfacher ist als eine Installation durch den Distribution Server. Für diese
Installation ist es notwendig, einige Voraussetzungen auf dem Zielrechner zu schaffen.
Es muss der Zugang mit sftp und ssh oder ftp
und telnet auf den Zielrechner möglich sein.

Liste der RT-Server
Informationen über den Notification Server
Konfiguration für den Notification Server
Grundeinstellungen für die Unix bzw. Windows Agenten
Grundeinstellungen für die Oracle Überwachung (Produktion
und Testumgebung)
Konfigurationen für BEA Weblogic usw.
Und ...
Die Softwareverteilung
nachdem diese Maßnahmen alle umgesetzt wurden, konnte die
PATROL Überwachung erfolgreich in den Produktivbetrieb gehen!
Die neu zu installierenden Agenten werden als
erstes in den Distribution Server eingepflegt.
Sie bekommen entsprechende Zugriffsberech-
Irina Hochhalter und Holger Demuth ([email protected]).
7
Datenbanken - Titelthema Oracle 10g
Oracle 10g (Teil III):
Tanz den REORG
Reorganisation ist ein immer wiederkehrendes Thema bei Datenbanken und wird aus unterschiedlichen Gründen notwendig. Wichtig beim Durchführen von Reorganisationen sind Dauer und gegebenenfalls damit verbundene Einschränkungen für den Betrieb der Datenbank. In diesem Artikel stellen wir Ihnen zwei neue
Features von Oracle 10g vor und zeigen deren Einsatzmöglichkeiten.
Die Features
Wichtigstes Merkmal beider Reorganisationspraktiken ist, dass
sie online durchgeführt werden können, ohne dass ein exklusiver
Tabellenzugriff gewährleistet sein muss.
Die Möglichkeiten 1 - 3 setzen voraus, dass
die Tabelle exklusiv für die Reorganisation zur
Verfügung steht. Sprich: Parallel im Hintergrund
laufende DML- oder DDL Statements müssen
ausgeschlossen werden. Die vierte Möglichkeit
wurde mit Oracle 9i eingeführt und hebt diese
Einschränkung auf. Während der Reorganisation kann auf der zu reorganisierenden Tabelle ohne Einschränkungen weitergearbeitet
werden. Das genaue Vorgehen hierbei führt
uns zum nächsten Schritt.
Ausgangsstellung
Step Two: Jive Viele Schritte pro Takt
Hauptgründe für die Reorganisation einer Tabelle sind meistens
schlechter Blockfüllgrad und/oder migrierte Datensätze. Die Ursachen hierfür liegen z. B. bei einer zu geringen Oracle Blockgröße
oder schlecht gewählten Storage Parametern bis hin zu stark flukturierenden Tabelleninhalten (ständige insert- und delete-Befehle).
Dies sind nur einige Beispiele für die zuvor genannten Indizien. So
wird mit der Zeit der Ruf nach Reorganisation immer lauter.
Abbildung 1 zeigt das Vorgehen bis Oracle 9i
beim Einsatz von dbms_redefinition. Zunächst wird eine leere Tabelle T1X erzeugt,
die den gleichen Aufbau wie die zu reorganisierende Tabelle T1 besitzt. Dann wird über
dbms_redefinition.start_redef_table
automatisch eine Log-Tabelle erstellt, die alle
parallel auftretenden DML Operationen auf der
Tabelle T1 protokolliert.
Während dbms_redefinition schon in Oracle 9i vorhanden war,
ist Segment Shrink ein neues Feature. dbms_redefinition
wurde für Oracle 10g erweitert und hilft dem DBA bei der Reorganisation von Tabellen. Das Feature Segment Shrink wird bei der
Reorganisation für die Defragmentierung von Segmenten genutzt.
Step One: Slow Fox Ein langsamer Schritt, zwei Schnelle
Folgende Möglichkeiten standen dem DBA für die Reorganisation
bisher zur Verfügung:
1. Ex- und Import der Tabelle mit manueller Anpassung der
Storageparameter
2. create table as select Statement
3. alter table move Statement
Seit Oracle 9i wurden diese Möglichkeiten um eine vierte erweitert:
4. Der Einsatz des Packages dbms_redefinition
Gleichzeitig wird damit begonnen, sämtliche
Daten aus der Tabelle T1 in die Tabelle T1X zu
kopieren. Hierfür muss natürlich ausreichend
Speicherplatz im Tablespace vorhanden sein.
Als nächstes greift der Administrator ein, denn
sämtliche Objekte, die von der Tabelle T1 abhängig sind, müssen nun manuell für die Tabelle T1X erstellt werden. Dies ist die größte
Stolperfalle und gleichzeitig der Grund, weshalb viele DBAs diesen Ausfallschritt nicht
setzen und stattdessen auf alte Methoden zurückgreifen. Durchaus verständlich, wenn man
bedenkt, welcher Aufwand für eine Tabelle dabei betrieben werden muss: Feststellen, welche Objekte direkt von der Tabelle T1 abhängig sind, Erstellen dieser abhängigen Objekte (Synonyme, Trigger, Indizes, Grants) und
Kontrolle der durchgeführten Arbeiten, um ja
kein Objekt zu vergessen.
Sicherlich können Skripte und der Einsatz von
dbms_metadata die Zeit verkürzen, aber der
Aufwand für n-Tabellen ist weiterhin relativ hoch.
Abb. 1: Vorgehen beim Einsatz von rdbms_redefinition bis Oracle 9i.
8
Diese Objekte müssen mit neuen Namen versehen werden, da die Namen eines Objekttyps im
Schema eindeutig sein müssen.
Datenbanken
Abschließend wird die Reorganisation über
dbms_redefinition.finish_redef_table
abgeschlossen. Hierbei werden die DML Operationen aus der Log-Tabelle nachgefahren
und die Namen der zu reorganisierenden Tabelle (T1) und der reorganisierten Tabelle (T1X)
getauscht. Hierfür wird für einen sehr kurzen
Zeitraum ein DML-Lock auf beide Tabellen gesetzt. Anschließend kann die Tabelle T1X gelöscht werden. Damit ist die Reorganisation
abgeschlossen.
Warum nicht automatisch?
Nun stellt sich berechtigterweise die Frage,
aus welchem Grund Oracle nicht automatisch
alle abhängigen Objekte erzeugt, damit der
DBA an dieser Stelle nicht manuell eingreifen
muss. Die Informationen hierfür stehen schließlich im Data Dictionary. Genau dies wird jetzt
mit Oracle 10g ermöglicht: mit der Prozedur
dbms_redefinition.copy_table_dependents
Abb. 2: Die Abfolge der aufzurufenden Prozeduren unter Oracle 10g.
Diese Prozedur erstellt alle von einer Tabelle
abhängigen Objekte und erleichtert so den Umgang mit dem Package dbms_redefinition
um ein Vielfaches. Abbildung 2 zeigt nun die
Abfolge der aufzurufenden Prozeduren unter
Oracle 10g.
Step Three: Quickstep Schnelle,
dynamische Bewegungen
Eine weitere Möglichkeit, eine Online-Reorganisation vorzunehmen, ist das Segment
Shrink. Mit Hilfe von Segment Shrink können
Daten in einer Tabelle verdichtet und die High
Water Mark zurückgesetzt werden.
Voraussetzung für den Einsatz dieser neuen
Technik ist die Verwendung von Automatischem Segment Space Management, kurz
ASSM (siehe ORDIX News 2/2003, S. 20). Da
bei dem Vorgang des Verdichtens die ROWIDs
verändert werden, muss die entsprechende
Tabelle über den Befehl ALTER TABLE tab
ENABLE ROW MOVEMENT; hierfür vorbereitet
werden. Für das Segment Shrink wurde der
ALTER TABLE Befehl in der Syntax erweitert:
ALTER TABLE tab SHRINK SPACE COMPACT;
bzw.
ALTER TABLE tab SHRINK SPACE CASCADE;
Beide Befehle führen dazu, dass die Daten in
vordere, nicht vollständig gefüllte Blöcke verdichtet werden. Im Falle von SPACE COMPACT
bleibt die High Water Mark am alten Platz. Es
werden also keine Extents freigegeben. Im
Falle CASCADE wird die High Water Mark auf
den tatsächlich letzten, belegten Block gesetzt. Frei gewordene Extents werden zurück-
Abb. 3: Unterschiede zwischen SHRINK COMPACT und SHRINK CASCADE.
gegeben. Die Funktionalität wird intern mittels Insert/Delete ohne
Auslösen von Triggern durchgeführt (siehe Abbildung 3). Dieses
wird durch ein implizites ALTER TABLE enable/disable all
triggers gewährleistet.
Was ist nun der Sinn der Funktionalität COMPACT?
Bei ASSM wird bei einem Full Table Scan nur bis zur Low High
Water Mark gelesen. Die High High Water Mark ist hier irrelevant.
Die Low High Water Mark ist der tatsächlich letzte Block, also
derselbe Block, wie im Falle CASCADE. COMPACT sollte also verwendet werden, wenn davon ausgegangen werden kann, dass
der freie Platz in kurzer Zeit wieder belegt wird.
Fazit
Die Erweiterung von dbms_redefinition war überfällig und macht
erst jetzt das Paket wirklich einsetzbar. Segment Shrink bietet eine
neue, sehr einfache Möglichkeit, eine Tabelle zu defragmentieren.
Beide Reorganisationspraktiken sind online durchführbar, um den
Anwendern beim Reorg-Tanz nicht auf die Füße zu treten.
Michael Lindermann ([email protected]).
9
Serverkonsolidierung der etwas
anderen Art
Wenn der Begriff Serverkonsolidierung fällt, denkt man in der Regel an große Systemkonfigurationen, bei
denen eine Menge von Anwendungen auf einem partitionierbaren System zusammengefasst werden. Nicht
selten findet man dann Systeme wie PRIMEPOWER 2500, Sun Fire E25K oder IBM pseries 690. Serverkonsolidierung kann aber schon in viel kleinerem Rahmen stattfinden. Der Artikel beschreibt die Konsolidierung einer Kunden-DMZ (DMZ = demilitarisierte Zone), bei der die ORDIX AG mitwirkte.
Die Ausgangssituation:
Eine schnell gewachsene Webserver-Farm

Zentraler Storage
Durch einen zentralen, externen Storage
sollen Speicherplatz-Engpässe flexibler
behoben werden können. Eine jeweils lokale Plattennachrüstung entfällt. Die zentrale Datenhaltung ist weiterhin für die
Hochverfügbarkeit der Anwendung von
großer Bedeutung.

Skalierbarkeit
Steigende Anforderungen sollen durch
Auf- oder Nachrüstung möglich sein, ohne
dass die anderen Ziele davon betroffen
sind.

Stabilität
Die Lösung sollte insbesondere für die
wichtigen, zentralen Komponenten Stabilität garantieren.

Kosten
Die bisher genannten Ziele müssen so weit
wie möglich mit geringen Kosten realisiert
werden. Daher ist der Einsatz von Open
Source Lösungen wie auch von preisgünstiger Hardware zu prüfen.
Zur Realisierung der Internetpräsenz (bestehend aus ca. 50 Internetangeboten) wurde eine Vielzahl von unterschiedlichen Systemen mit jeweiligen Datenbank- und http-Prozessen eingesetzt.
Als Plattform diente eine heterogene Rechnerlandschaft, bestehend aus ca. 25 Systemen auf Basis von Linux und Solaris.
Die Datenhaltung erfolgte ebenfalls mit unterschiedlichen Datenbank Systemen (Oracle, MySql, PostgreSql). Eine Hochverfügbarkeit der einzelnen Dienste war nicht gewährleistet.
Der Ausfall eines Internetangebots hätte nicht ohne größere Ausfallzeiten abgefangen werden können, was zu einem entsprechenden Image-Verlust geführt hätte. Wie viele Webserver-Farmen,
ist auch diese im Laufe der Jahre unkontrolliert und mit vielen Insel-Lösungen gewachsen.
Primäres Ziel war bisher die möglichst schnelle Bereitstellung eines Webdienstes. Administrationskosten, leichte Pflegbarkeit,
Backup- und Verfügbarkeit spielten bis dato eher eine untergeordnete Rolle.
Die Ziele
Aus dieser etwas unbefriedigenden Situation haben die Mitarbeiter der ORDIX AG in Zusammenarbeit mit dem Kunden folgende
Ziele festgelegt:

Hochverfügbarkeit
Der Ausfall einer Hardware-Komponente darf nicht zum Ausfall einer Internetpräsenz führen.

Lastverteilung
Bei Bedarf und erhöhter Nachfrage müssen entsprechende
Kapazitäten zur Verfügung stehen, die vom Internet-Anwender
transparent genutzt werden können. Es soll verhindert werden, dass einige Systeme unter Volllast laufen, während andere unterbeschäftigt sind.

10
Verringerung der Serveranzahl
Weniger Systeme, die wenn möglich identisch aufgebaut
sind, sollen zu einer Minimierung der administrativen Aufgaben führen.
Die Analyse erbrachte eine logische
Aufteilung
Im ersten Schritt haben die ORDIX Mitarbeiter die Struktur der einzelnen Anwendungen
analysiert, woraufhin sie dann die Internet-Angebote in zwei Basisdienste aufteilten:

http-server
Die meisten Webdienste wurden auf Basis des Apache-Servers betrieben. Die
Datenhaltung erfolgt nicht auf lokalen
Filesystemen, sondern auf einer Datenbank. Dadurch ist es möglich, die Webserver parallel zu betreiben, was das Erreichen des Ziels Loadbalancing vereinfacht.
Durch den Loadbalancer wird ebenfalls eine gewisse Hochverfügbarkeit garantiert, da dieser bei Ausfall eines Blades die Anforderungen an einen anderen, laufenden Blade mit gleicher Anwendung weiterreicht. Um trotz eines Ausfalls eines gesamten Rechenzentrums die Verfügbarkeit zu garantieren, sind die beiden Enclosures (die die Blades enthalten) in unterschiedlichen Gebäuden
aufgestellt worden.
... und Datenbankserver.
Zur einfacheren Administration werden ebenfalls alle Datenbanken zentral unter Oracle auf einem System zusammengeführt. Eine
Parallelisierung wie bei den Linux-Blades ist an dieser Stelle nicht
möglich.
Auf Grund der zentralen Funktion (und somit der Möglichkeit des
Single Point of Failure) erhöht sich die Anforderung an die Verfügbarkeit. Der Einsatz eines Clusters mit stabilen und redundanten
Komponenten ist hier unbedingt notwendig:
Abb. 1: Die Systemarchitektur beim Kunden
nach der Konsolidierung.

Datenbank
Alle veränderbaren Daten der Webdienste
werden auf jeweils eigenen Datenbanken
gehalten.
... in Webserver
Durch den Einsatz von gleich aussehenden
Linux-Blades (mit SLES 8) wird eine vereinfachte Administration der Systeme erreicht. Auf den
Blades befinden sich nur Betriebssystem-Komponenten, die für den Einsatz der Webanwendungen notwendig sind. Die Blades können
jederzeit durch einen zentralen InstallationsBlade automatisch und identisch eingerichtet bzw. vervielfältigt werden.
Die Webanwendungen selbst befinden sich
auf einem zentralen Storage (NAS) und werden von den einzelnen Linux-Blades eingebunden. Durch entsprechende Start-/StoppSkripte ist es möglich, jede Anwendung auf
jedem Blade laufen zu lassen.
Durch einen vorgeschalteten Loadbalancer
(BigIP) wird die geforderte Skalierbarkeit erreicht. Engpässe können durch das einfache
Hinzufügen eines weiteren Blades überbrückt
werden.

Zwei Sun Fire Server bilden jetzt die beiden Zwei-Knoten-Cluster. Betriebssystemmäßig ist die Entscheidung für Solaris 8
gefallen.

Die Datenbanken selbst werden in einem externen SAN-Storage abgelegt. Die eingesetzte EMC-Box ist über Fibre Optik
redundant angeschlossen.

OSL Storage Cluster: Auch bei der Auswahl des Clusters ist
von den großen und bekannten HV-Lösungen (wie z. B. VeritasCluster, Sun-Cluster, PrimeCluster, ...) Abstand gehalten worden.
Ziel war es, eine Lösung zu finden, die einerseits kostengünstig
ist (Lizenz und Wartung), anderseits aber auch die geforderte
Stabilität und Robustheit liefert. Um den Administrationsaufwand gering zu halten, sollte sich die Lösung auf die reine
Systemverfügbarkeit konzentrieren. Die Entscheidung fiel auf
den OSL Storage Cluster, der auch gleich einen Volume Manager beinhaltet.
Fazit
Die ORDIX AG hat in diesem Projekt maßgeblich sowohl in beratender als auch in ausführender Funktion mitgewirkt. Von der Konzepterstellung, über die Auswahl der einzelnen Komponenten bis
hin zur Durchführung der Konsolidierung haben die ORDIX Mitarbeiter ihren Kunden begleitet.
Bei der Realisierung der Systemarchitektur wurde eine Referenzanwendung ausgewählt, die von ORDIX komplett auf die neuen
Systeme installiert und migriert wurde. Die restlichen Anwendungen werden nun schrittweise vom Kunden selbst in die neue, konsolidierte Welt umgestellt.
Antonio Salguero ([email protected]).
11
Datenbanken
Dokumentieren mit PLDoc
Dokumentieren ist ja bekanntlich nur etwas für Warmduscher und Hotel-Fluchtplan-Leser. Für eingefleischte
Hardcore-Programmierer bietet das Open Source Werkzeug PLDoc die Möglichkeit, HTML Dokumentationen
aus PL/SQL Programmen zu generieren.
Pate für das Open Source Projekt stand das viel genutzte Javadoc.
Mit ihm ist es möglich, direkt aus dem Programmcode eine Dokumentation zu generieren. Der Programmierer muss mittels spezieller Schlüsselwörter innerhalb der Kommentare des Programmtextes eine Beschreibung von Prozeduren, Funktionen, Parametern und Variablen hinterlegen. Das Programm PLDoc untersucht
den Programmcode und generiert daraus eine anschauliche Dokumentation auf Basis von HTML.
Wie gehts
Kommentiert kann innerhalb oder außerhalb der PL/SQL Pakete
werden. Der Autor bevorzugt die Kommentierung im Programmcode selbst, so dass dieser nicht verloren gehen kann. Von den
zahlreichen Varianten und Schlüsselwörtern stellt dieser Artikel
eine exemplarische Auswahl vor.
Die Dokumentation von PL/SQL Paketen findet grundsätzlich im
Package Header statt. Der Package Body lässt sich nicht einbinden.
Das Listing 1 zeigt die Dokumentation einer Paket Spezifikation,
welche mit dem Schlüsselwort @headcom abgeschlossen wird.
Das Listing 2 zeigt die wichtigsten Schlüsselwörter zur Beschreibung von Prozeduren und
Funktionen.
Diese sind
@param zur Dokumentation von Übergabeparametern,
@return für die Beschreibung des Return
Wertes bei Funktionen und
@throws zur Bekanntmachung von Exceptions.

Besonders Vorteilhaft ist die Möglichkeit, in der
Dokumentation selbst HTML Code zu verwenden. So lassen sich einzelne, wichtige Wörter wie commit farblich markieren oder die
Änderungshistorie als Tabelle darstellen (siehe auch Listing 1).
Los gehts
Mit dem folgenden Aufruf wird die Dokumentation schließlich generiert:
CREATE OR REPLACE PACKAGE PCK_APP_PIPELINE AS
/**
* Paket zur Generierung von laufenden Werten
* <ul>
* <li> get_dates, um eine Reihe von Datumswerten zu generieren </li>
* <li> get_timestamps, um eine Reihe von Timestamps zu generieren </li>
* <li> get_numbers, um eine Reihe von numerischen Werten zu generieren </li>
* </ul>
*
* <table border>
* <tr>
* <th> Version </th><th> Datum </th><th> Autor</th><th> Beschreibung </th>
* </tr>
* <tr>
* <td> 1.0 </td>
* <td> 21.04.2004</td>
* <td><a href="mailto:[email protected]">M. Hoermann</a>
*
<a href="http://www.ordix.de">ORDIX AG</a> </td>
* <td> Initial </td>
* </tr>
* </table>
*
* @headcom
*
*/
Listing 1: Die Dokumentation einer Paket Spezifikation, die mit dem
Schlüsselwort @headcom abgeschlossen wird.
Abb. 1: Ergebnis der Dokumentation aus Listing 1.
12
Datenbanken
/** Funktion liefert eine Reihe von Datumswerten. Beim Aufruf mit
*
* <code> pck_app_pipeline.get_dates( sysdate, 5, 2 ); </code>
*
* werden 5 Datumswerte, beginnend mit Heute aufsteigend in 2 Tagesschritten generiert.
*
* @param p_start_datum Startwert
* @param p_return_werte Anzahl der zu generierenden Werte
* @param p_inkrement Anzahl Tage zwischen zwei generierten Werten
* @return type_date im Format TABLE OF DATE
* @throws pck_errnums.c_abbruch Generische Exception, siehe Fehlerstack.
*
*/
FUNCTION get_dates
( p_start_datum IN DATE,
p_return_werte IN NUMBER,
p_inkrement IN NUMBER
)
RETURN type_date PIPELINED;
Listing 2: Die wichtigsten Schlüsselwörter zur
Beschreibung von Prozeduren und Funktionen.
Abb. 2: Ergebnis der Dokumentation aus Listing 2.
pldoc -d doku -doctitle Project \
-overview main.html pipeline.sql
Die Option d legt das Verzeichnis fest, in dem
die HTML Dokumente generiert werden. Die
Option doctitle legt, wie sich leicht erraten lässt, die Überschrift der Dokumentation
fest. overview legt eine optionale Startseite
fest und der letzte Parameter gibt die Datei
oder die Dateien mit dem dokumentierten Programmcode an.
Das Listing 3 zeigt die Rückgabe des Programmaufrufs. Die Abbildungen 1 und 2 zeigen das Ergebnis der Dokumentation aus
Listing 1 und 2.
Quelle und Installation
Das Programm PLDoc liegt momentan in der
Version 0.8.2 vor. Die 2,6 MB große Installationsdatei pldoc-0.8.2.zip beinhaltet alle
notwendigen Programme und die Dokumentation.
Die jeweils aktuellste Version ist unter der
Adresse
http://pldoc.sourceforge.net/ zu
finden.
Die Installation gestaltet sich ausgesprochen
einfach. Auf dem Rechner muss die Java
Runtime Version 1.2 vorhanden sein. Anschließend ist die ZIP Datei zu entpacken und
los gehts.
Eine gute Dokumentation wird in der ZIP Datei direkt mitgeliefert.
PLDoc version: 0.8.2
Parsing file M:\changes\aktuell\pipeline.sql ...
Generating HTML files ...
Generating summary.html ...
Generating allpackages.html ...
Generating index.html ...
Generating <unit>.html ...
Done (20.484 seconds).
Listing 3: Die Rückgabe des Programmaufrufs.
Fazit
Das Programm liefert auch bei mehreren Dutzend PL/SQL Paketen und mehreren tausend Zeilen Programmcode in weniger als
einer Minute eine gut strukturierte Dokumentation. Dies allerdings
nur auf Englisch.
Daneben ermöglicht auch die Dokumentation von SQL*Plus Skripten die Verwendung eigener Style Sheets (CSS) und vieles mehr.
Schön wäre es, wenn auch der Code selbst eingebunden werden
könnte. Dies entspricht aber nicht dem Konzept von javadoc und
ist daher auch nicht Bestandteil von PLDoc.
Für den Inhalt der Dokumentation ist nach wie vor der Programmierer verantwortlich, der hoffentlich kalt geduscht hat und mit
kühlem Kopf auch schwierige Sachverhalte anschaulich zu beschreiben weiß.
Martin Hoermann ([email protected]).
13
Unix/Linux/Open Source - Titelthema VMware ESX Server
Serverkonsolidierung im Rechenzentrum mit dem VMware ESX Server Ein Erfahrungsbericht
Virtuelle Maschinen in der Praxis
In der Ausgabe 4/2002 stellten wir Ihnen die Produkte der Firma VMware vor. Anhand eines Projekterfahrungsberichts wollen wir Ihnen heute zeigen, wie Sie mit dem VMware ESX Server, der High-End Variante der
VMware Produktlinie, mehr Effizienz in Ihr Rechenzentrum bringen und damit die Betriebskosten deutlich
reduzieren können.
Ausgangslage
Eine GP7000 mit SunOS 5.7 hatte fast drei Jahre als Datei- und
Datenbankserver gedient. Jetzt aber rückte das Ende des Leasingvertrages immer näher und eine Ablösung des Systems stand
bevor. Eine Entscheidung war zu treffen.
Alternativen
Für die Ablösung der GP7000 wurden drei Alternativen in Betracht
gezogen:
1. Ein neues SPARC-System (Primepower) mit SunOS 5.9
2. Ein hochverfügbarer Linux Cluster mit zwei SUSE Linux Enterprise Servern 8
3. Ein VMware ESX Server inklusive SUSE Linux Enterprise Server 8 als virtuelle Maschine
Die reinen Anschaffungskosten für die drei Varianten waren in etwa
gleich, so dass andere Kriterien zur Entscheidungsfindung herangezogen werden konnten.
Die Entscheidung
Folgende Punkte waren ausschlaggebend bei der Entscheidung
für den ESX Server:
Der Anteil der Windows Systeme an der Serverlandschaft ist in
diesem Rechenzentrum (RZ) recht hoch (ca. 70 %). Die Entscheidung für den ESX Server sorgt dafür, dass deutlich mehr Systeme von der bevorstehenden Hardware-Investition profitieren können und nicht nur der File- und DB-Server. Das Management kann
sich somit über einen besseren Return on Investment freuen und
die Benutzer über bessere Performance, auch bei den WindowsSystemen.
Des Weiteren besteht ein hoher Bedarf an Testsystemen für unterschiedliche Einsatzgebiete. Bisher wurden zu diesem Zweck in
der Regel ausrangierte Rechner wiederbelebt. Dies ist allerdings
mit hohem Aufwand verbunden und macht den Benutzern wegen
der typischerweise nicht gerade zeitgemäßen Ausstattung auch
wenig Freude.
Die räumlichen Kapazitäten im RZ waren zudem bereits weitestgehend ausgereizt. Eine Erweiterung der Systemlandschaft bedingte somit in naher Zukunft eine Ausweitung der Räumlichkeiten, was mit erheblichem Aufwand verbunden wäre.
Nebenbei konnten auch etliche Client-Lizenzen für die Notstromversorgung eingespart werden, da die virtuellen Maschinen keine
eigene Anbindung an die USV benötigen.
14
VMware ESX Server
Der ESX Server ist das Flaggschiff der
VMware Produktlinie. Es handelt sich hierbei um ein speziell für den Einsatz als VMware Server angepasstes Linux System,
welches direkt auf der eingesetzten Hardware installiert wird.
Die Vorteile gegenüber dem GSX Server,
welcher als normale Applikation auf einem gegebenen Betriebssystem installiert
wird, sind insbesondere die bessere Performance sowie die erheblich erweiterten
Möglichkeiten zur Ressourcenkontrolle.
Realisierung
Nach der Installation und Konfiguration des
ESX Server wurde eine virtuelle Maschine als
Datei- und Datenbankserver eingerichtet und
mit dem SUSE Linux Enterprise Server 8 bespielt. Die ORDIX AG beriet und unterstützte
bei der Installation des Basissystems sowie
bei der Migration der Oracle Datenbanken und
der mittels Samba bereitgestellten Anwenderdaten. Dabei wurde nebenbei auch gleich die
Samba-Authentifizierung vom alten NT-Domain Controller auf das neue Active Directory
umgestellt.
Nur drei Wochen nach der Lieferung der neuen Hardware konnte die alte GP7000 abgeschaltet werden. Der ESX Server läuft nun seit
ca. 8 Monaten, wobei mittlerweile 9 physikalische Systeme in eine virtuelle Maschine umgewandelt wurden. Insgesamt laufen zur Zeit
13 virtuelle Maschinen auf dem Server (9 x
Windows, 4 x Linux). Weitere Migrationen sind
geplant, denn das System ist bei weitem noch
nicht am Limit.
Was hat es gebracht?
Die Entscheidung für den ESX Server wurde
zunächst nicht von allen Mitarbeitern des Rechenzentrums begrüßt. Skepsis gegenüber
der neuen Technologie war deutlich zu spü-
Mit dem ESX Server lassen sich die
Betriebskosten deutlich reduzieren,
wenn Sie ...

großen Bedarf an Test- und Entwicklungssystemen haben.
z. B. in Schulungsumgebungen viele
unterschiedliche Systeme zur Verfügung stellen müssen.
in einer heterogenen (Intel-)Systemlandschaft viele Einzelsysteme zu betreuen haben, die nur temporär ausgelastet sind.
räumliche Erweiterungen des Rechenzentrums durch die Konsolidierung vermeiden können.
ren. Die guten Erfahrungen nach der Einführung haben jedoch mittlerweile dafür gesorgt,
dass die Entscheidung sowohl vom Management als auch von den Administratoren durchweg positiv eingeschätzt wird.
Laut internem Controlling wurde eine Amortisierung der Investition bereits nach 6 Monaten bzw. nach Ablösung zehn physikalischer
Systeme durch eine virtuelle Maschine erreicht. Von den Systemverwaltern hingegen
wird insbesondere die neue Flexibilität geschätzt. Die Bereitstellung eines Testsystems reduziert sich z. B. nun auf ein paar Klicks
in der Administrationsoberfläche.
Die andere Seite der Medaille
Natürlich hat auch die VMware-Medaille zwei Seiten. Es sollte
bedacht werden, dass ein Ausfall des ESX Servers den Ausfall
aller virtuellen Maschinen zur Folge hat. Das System muss also
auf höchste Verfügbarkeit ausgelegt werden. Zum anderen muss
im Zweifelsfall geprüft werden, ob die eingesetzten Betriebssysteme und Anwendungen vom Hersteller für den Betrieb in einer
virtuellen Maschine freigegeben sind, um Supportansprüche geltend zu machen. Viele große Hard- und Softwarehersteller (z. B.
IBM, HP, Microsoft, Oracle, ...) arbeiten jedoch bereits seit einiger
Zeit mit VMware zusammen, so dass hier nur im Einzelfall Probleme auftreten sollten.
Fazit
Das vorgestellte Praxisbeispiel macht deutlich, dass durch den
Einsatz eines VMware ESX Servers sowohl Kostensenkungen als
auch erhebliche Effizienzsteigerungen realisiert werden können.
Die Voraussetzungen waren in dem Szenario allerdings auch
nahezu ideal. Ob sich diese Investition auch in Ihrem Rechenzentrum bezahlt macht, muss im Vorfeld sorgfältig analysiert werden.
Die ORDIX AG unterstützt sie dabei gerne von der Kalkulation bis
zur Realisierung.
Christof Amelunxen ([email protected]).
Seminarvorstellung: Linux Hochverfügbarkeits-Cluster
Der Teilnehmer lernt Grundlagen der Hochverfügbarkeit und der Clustertechnologie kennen sowie deren praktische Umsetzung am
Beispiel der Linux High Availability Software
(heartbeat) und dem Linux Virtual Server Project.
Zielgruppe
Systemadministratoren.
Seminarinhalte

Überblick GRID-Computing

Grundlagen der Hochverfügbarkeit

Grundlagen der Clustertechnologie

Logical Volume Management unter Linux (RAID, LVM)

Hochverfügbarkeitslösungen unter Linux

Linux High Availability Projekt
- Installation
- Konfiguration
- Failover-Szenarien
- Storage-Szenarien
- Monitoring
- Diagnose und Troubleshooting

Linux Virtual Server
- Loadbalancing allgemein
- Konzept der LVS
- Installation
- Loadbalancing für eine Webserver Farm mit LVS
- Monitoring
- Diagnose und Troubleshooting

Übungen
Voraussetzungen
Gute Unix Kenntnisse.
Dauer: 4 Tage
Kursgebühr/Teilnehmer: 1.390 € zzgl. MwSt.
Termine
21.02. - 24.02.2005 in Wiesbaden
06.06. - 09.06.2005 in Wiesbaden
05.09. - 08.09.2005 in Wiesbaden
21.11. - 24.11.2005 in Wiesbaden
15
Aktuell - Titelthema Neues von Vorstand und Aufsichtsrat
Neues Mitglied im
Vorstand der ORDIX AG:
Benedikt Georgi
Zum 1.1.2005 verstärkt Benedikt Georgi (44) den Vorstand der ORDIX AG.
Herr Georgi wird verantwortlich sein für Vertrieb, Marketing und Projektmanagement.
In seinem beruflichen Werdegang hat er jeweils zur Hälfte für IT-Dienstleister und IT-Anwender gearbeitet. Die Erfahrungen auf der Kunden- und
Lieferantenseite sind für ihn wichtig und er will sie gewinnbringend in die ORDIX AG einbringen.
Wichtige berufliche Stationen
Zukünftigen Aufgaben des Benedikt Georgi
Benedikt Georgi, in Bremen aufgewachsen, studierte Informatik
an der TU Braunschweig bis 1985. Danach startete er seine berufliche Karriere bei der ADV/ORGA Unternehmensberatung in
Wilhelmshaven als Softwareentwickler und Consultant im Bereich
Standardsoftware.
Mit der Übernahme der Vertriebs- und Marketingverantwortung bei ORDIX wird Herr Georgi
dem Unternehmen neue Impulse geben und
sicherlich auch andere Akzente setzen. Herr
Georgi trägt damit vor allem auch zur Entlastung des Vorstandsvorsitzenden Kögler bei,
der wiederum diese gewonnene Zeit in intensivere Betreuung der ORDIX Kunden und einiger ORDIX Projekte investieren kann und wird.
1988 wechselte er zur Nixdorf Computer AG nach Paderborn, um
zunächst übergreifende IT-Sonderprojekte zu leiten und dann als
Abteilungsleiter die Logistik- bzw. die Serviceprozesse zu gestalten. Insbesondere die Harmonisierung der Serviceprozesse und verfahren bei der Fusion von Nixdorf und Siemens DI war eine
besondere Herausforderung.
Von 1993 bis 1996 war Benedikt Georgi verantwortlich für die Architektur, Basistechnologie und Entwicklung bei der weltweiten
Einführung von R/3 bei Siemens Nixdorf.
Ab der Gründung von Siemens Business Services (SBS) 1996
hat er sehr erfolgreich in ständig wachsender Verantwortung die
Übertragung der internen Projekt- und Serviceerfolge auf den externen Markt betrieben.
Im Jahr 2000 wurde Benedikt Georgi zum Mitglied der Geschäftsleitung von SBS Deutschland ernannt und war zunächst verantwortlich für die gesamte Dienstleistungserbringung im Lösungsgeschäft (SAP, Siebel, I2, etc.). Hierbei gelang es ihm, die Verrechenbarkeit des Bereichs auf Rekordniveau zu steigern.
2002 übernahm er dann die ganzheitliche Geschäftsverantwortung
für den produktnahen Service (Wartung, IT-Infrastrukurservice).
In der Geschäftsleitung Deutschland verantwortete er zusätzlich
organisationsübergreifend die Themen Skillsmanagement, Assignmentmanagement, Knowledgemanagement und Projektmanagement. Die hierbei gesammelten Erfahrungen wird er erfolgreich in
die ORDIX AG einbringen.
Darüber hinaus kümmerte sich Benedikt Georgi im Beirat um die
strategische Weiterentwicklung des C-Lab und als Standortleiter
um die Positionierung der SBS am Standort Paderborn.
16
Besonders viel verspricht man sich bei ORDIX
für den seit knapp 2 1/2 Jahren existierenden
Bereich Projektmanagement, für den Georgi
ebenfalls die Verantwortung übernehmen wird.
Die Erfahrungen, die Benedikt Georgi aus der
SBS mit zu ORDIX bringt, werden die Arbeit
der ORDIX Projektmanager sicherlich positiv
beeinflussen.
Herr Georgi erhält zunächst einen 5-Jahres
Vertrag. Man geht aber bei ORDIX von einem
viel längeren Zeitraum sowie einem stetig
wachsenden Verantwortungsbereich aus. Mit
Herrn Georgi haben wir jemanden gefunden,
dessen Erfahrungen hervorragend zu uns
passen. Gerade weil er mit der SBS aus einem deutlich größeren Unternehmen kommt,
wird unser stetiger Wachstumskurs durch ihn
sicherlich optimal begleitet. erklärt Wolfgang
Kögler, Vorstandsvorsitzender.
Zeit für Freizeit
Wenn es seine beruflichen Tätigkeiten zulassen, beschäftigt sich Benedikt Georgi mit
Kunst und Design des 20./21. Jahrhunderts,
mit Malen und Zeichnen. Mit Laufen und Inlineskating hält er sich fit. Benedikt Georgi ist
Familienvater und hat 2 Söhne.
Aktuell
Neues Mitglied im
Aufsichtsrat der ORDIX AG:
Wolfgang Raum
In der Hauptversammlung am 6. August 2004 wurde Wolfgang Raum (63) in den Aufsichtsrat der ORDIX AG gewählt. Er ist seit fast 40 Jahren im IT-Bereich tätig und hat
in der Vergangenheit sowohl große Entwicklungseinheiten im Software-Bereich geleitet als auch nationale und internationale Vertriebseinheiten aufgebaut und geführt.
Wichtige berufliche Stationen
Eine wichtige berufliche Station war die ZUSE
KG in Bad Hersfeld. Hier arbeitete er in den
60er Jahren an der Systementwicklung der
Z25.
1970 kam er zu Nixdorf und war über 10 Jahre als Führungskraft im Entwicklungsbereich
und weitere 10 Jahre im internationalen Vertrieb tätig. Ein Schwerpunkt seiner Tätigkeit
war die Entwicklung und Vermarktung neuer
Bankensysteme und später die Bereitstellung
der Unix Systeme. Nach der Fusion von Siemens und Nixdorf war er für die weltweite Vermarktung der Handelssysteme verantwortlich.
1993 wechselte er zu Oracle. Gemeinsam mit
dem europäischen Management entwickelte
und implementierte er Vertriebsstrategien zur
Erschließung neuer Marktsegmente.
1995 übernahm Wolfgang Raum bei dem amerikanischen Softwareunternehmen BMC die
Geschäftsführung für die Länder Deutschland,
Österreich und Schweiz und baute in den folgenden Jahren die Organisation zum wichtigsten europäischen Umsatzträger aus.
Anfang 2000 zog es Wolfgang Raum in die
Schweiz, wo er sich an Framesoft, einem Softwareunternehmen für Bankenlösungen, beteiligte.
Engagement
Neben seiner beruflichen Verantwortung kümmerte sich Wolfgang Raum in den 80er und
90er Jahren intensiv um Standardisierungen
im IT-Bereich. Er war Gründungsmitglied der
Vorläuferorganisationen der heutigen Open
Group und hat in vielen nationalen und inter-
nationalen Standardisierungsgremien mitgewirkt.
Wolfgang Raum und ORDIX
Wolfgang Raum wird sich mit Engagement in die Aufsichtsratstätigkeit bei ORDIX einbringen, treu nach
dem Motto: Wem die Arbeit Spaß macht, der kann sich im Leben
viele schöne Stunden machen.
Neben seiner neuen Tätigkeit verbindet Herrn Raum noch mehr
mit ORDIX um nicht zu sagen, dass er indirekt verantwortlich für
die Gründung des Paderborner Unternehmens ist.
Herr Raum und der Aufsichtsratsvorsitzende Professor Dr. Hermann Johannes, damals ein Mitarbeiter von Wolfgang Raum, holten im Herbst 1987 Wolfgang Kögler, den Gründer und Vorstandsvorsitzenden der ORDIX AG, nach Paderborn zur Nixdorf Computer AG.
Die Verbindungsachse zwischen Herrn Raum und Herrn Kögler
führte auch zur Partnerbeziehung zwischen BMC und ORDIX.
ORDIX übernahm 1996 als erstes Unternehmen die Ausbildung
von BMC Partnern für das BMC Produkt PATROL. Noch heute ist
ORDIX der führende Schulungsanbieter im deutschsprachigen
Raum für PATROL.
Auch während seiner Framesoft Zeiten hielt der Kontakt zwischen
ORDIX und Herrn Raum an. Mehrere ORDIX Mitarbeiter führten
im Auftrag von Framesoft Kundenprojekte bei namhaften Banken
durch. Und eine Reihe von Framesoft Mitarbeitern erweiterten ihr
Know-how durch die ORDIX Kurse im objektorientierten Umfeld.
So ist es nicht verwunderlich, dass Herr Raum jetzt den Weg in
den ORDIX Aufsichtsrat gefunden hat.
Zeit für Freizeit
... soll Herrn Raum natürlich auch noch bleiben. Neben seinen beruflichen Tätigkeiten spielt er leidenschaftlich gerne Golf, liebt Bergtouren, favorisiert die Weine des Kaiserstuhls und lauscht gerne im
In- und Ausland den großen Interpreten der Klassischen Musik.
17
Datenbanken
Backup und Recovery mit Oracle 10g (Teil I):
Alles neu macht 10g: Backup und
Recovery mit Oracle 10g
In dieser Ausgabe der ORDIX News wollen wir uns mit allgemeinen Erweiterungen bei Backup und Recovery
mit Oracle 10g beschäftigen.
Automatisches Starten des Archive Prozesses
In den Oracle Releases bis einschließlich Oracle 9.2 waren für
das ordnungsgemäße Funktionieren des Archivelog Modes zwei
Schritte notwendig:

Den Parameter log_archive_start = true in der Parameter-Datei setzen
In der Mount Phase einmalig die Betriebsart der Datenbank
umschalten: alter database archivelog;
Mit Oracle 10g ist der Parameter log_archive_start nicht mehr
notwendig. Die ARCn Prozesse werden automatisch beim Öffnen
(alter database open) gestartet, wenn sich die Datenbank in
der Betriebsart Archivelog befindet. Wird der Parameter noch verwendet, wird eine Warnung ausgegeben (ORA-32004 - obsolete
and/or deprecated parameter(s) specified).
Full DB begin backup
Seit Oracle 9i gibt es das Kommando
alter database end backup;
Zur Vervollständigung gibt es jetzt das Kommando
alter database begin backup;
Beide Kommados zusammen erleichtern das Erstellen von Backup Skripten, mit denen über Plattenspiegelung gesichert wird
(Proxy Copies).
Alle nicht vorhandenen, read only bzw. offline gesetzten Dateien
werden übersprungen. Es wird keine Fehlermeldung ausgegeben!
In der View v$backup stehen read only Dateien auf NOT ACTIVE.
Dateien, die nicht vorhanden sind bzw. offline gesetzt sind, werden in der View v$backup nicht gelistet.
RMAN>
2>
3>
4>
Der init.ora Parameter
ARCHIVE_LOG_FORMAT
Das Format der Dateinamen für die archivierten Redo Log Dateien hat sich geändert. Bisher gab es, außer bei OPS- oder RAC Systemen, nur die Sequenznummer, die in den Namen der Archivdatei eingebaut sein sollte. Mit
Oracle 10g gibt es ein Mindest-Format für die
Dateinamen der archivierten Redo Log Dateien: log_archive_format=%t_%r_%s
Dabei haben %t und %s ihre bisherige Bedeutung behalten:

%t für den Thread (Instance-Nummer)
%s für die Sequenznummer
Der Parameter %r steht für die neu hinzugekommene Resetlognummer. Optional lässt
sich noch der Parameter %a für die jeweils
neu vergebene Activation-Id hinzufügen. Die
Verwendung von %a empfiehlt sich allerdings
nicht, wie wir noch zeigen werden. Hier stellt
sich natürlich die Frage, wozu die zusätzliche
Information benötigt wird.
Recovery durch Resetlogs
Mit den Releases vor 10g war es nach dem
Öffnen der Datenbank mit der Option resetlogs zwingend erforderlich, ein vollständiges
Backup der Datenbank zu erstellen, da eine
neue Inkarnation der Datenbank erstellt wurde. Eine Inkarnation ist eine neue (interne)
Version.
convert tablespace 'TTS'
to platform "HP-UX (64-bit)"
DB_FILE_NAME_CONVERT =
'/oracle/oradata/tts', '/tmp/transport_tts_hpux';
Starting backup at 29-APR-04
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile conversion
input datafile fno=00005 name=/oracle/oradata/tts
converted datafile=/tmp/transport_tts_hpux
channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:03
Finished backup at 29-APR-04
Abb. 1: Beispiel für die Konvertierung eines Tablespaces auf eine andere Plattform.
18
Datenbanken
SQL> select * from v$transportable_platform order by platform_id;
PLATFORM_ID PLATFORM_NAME
ENDIAN_FORMAT
1
2
3
4
5
6
7
8
9
10
11
12
13
15
16
Solaris[tm] OE (32-bit)
Solaris[tm] OE (64-bit)
HP-UX (64-bit)
HP-UX IA (64-bit)
HP Tru64 UNIX
AIX-Based Systems (64-bit)
Microsoft Windows IA (32-bit)
Microsoft Windows IA (64-bit)
IBM zSeries Based Linux
Linux IA (32-bit)
Linux IA (64-bit)
Microsoft Windows 64-bit for AMD
Linux 64-bit for AMD
HP Open VMS
Apple Mac OS
Big
Big
Big
Big
Little
Big
Little
Little
Big
Little
Little
Little
Little
Little
Big
Abb. 2: Auflistung der unterstützten Plattformen in der View V$TRANSPORTABLE_PLATFORM.
Mit Oracle 10g ist dies nicht mehr erforderlich. Hier wurde ein Mechanismus integriert,
der ein Recovery durch ein Resetlogs hindurch ermöglicht (Erweiterung des Parameters log_archive_format durch %r).
covery Area abgelegt (default $ORACLE_HOME/dbs). Mit dem
Thema Flash Recovery werden wir uns in der nächsten Ausgabe
beschäftigen.
Ein Recovery mit einem alten Backup einer
mit open resetlogs geöffneten Datenbank
stellt sich nun folgendermaßen dar:

Einspielen der defekten Datenbank-Datei
bzw. der defekten Datenbank-Dateien
recover database;
Danach kann auto eingegeben werden.
Das Recovery der Datenbank läuft automatisch bis zur current Redo Log Datei. Bei
Bedarf auch durch mehr als ein Resetlogs.
Ist allerdings im Namen der Archive %a
verwendet, so muss jede einzelne Archivdatei namentlich eingegeben werden. Der
Parameter %a wird jeweils mit 0 vorbelegt.
Transportable Tablespaces
Transportable Tablespaces können nun zwischen verschiedenen Plattformen ausgetauscht werden. Das ist auch dann möglich,
wenn Quell- und Zielsystem unterschiedliche
Byte-Ordnungen aufweisen (endian ordering).
Die Datenkonvertierung von Little-Endian in
Big-Endian und umgekehrt wird mit Hilfe vom
RMAN durchgeführt. Dazu müssen die betreffenden Tablespaces zuvor auf read only
gesetzt werden. Ein Beispiel für diesen Vorgang finden Sie in Abbildung 1.
Wird als Ziel kein absoluter Pfad angegeben,
so wird die konvertierte Datei in der Flash Re-
Einschränkungen:

Die beteiligten Datenbanken müssen über den Parameter
COMPATIBLE >=10.0 verfügen.
Die Tablespaces müssen einmal read write geöffnet worden sein.
Die View v$transportable_platform liefert eine Übersicht der
Plattformnamen und des Datenformates (siehe Abbildung 2).
Fazit
Von den hier beschriebenen Neuerungen im Backup und Recovery Umfeld erscheinen das Recovery mit einem alten Backup
durch eine Resetlogssituation und das Kopieren von Tablespaces
über unterschiedliche Betriebssysteme als interessante Optionen.
Ersteres ermöglicht eine sofortige Inbetriebnahme einer Datenbank nach einem unvollständigen Recovery ohne vorheriges Backup, welches je nach Datenmenge und Verfügbarkeitsansprüchen
eine erhebliche Verbesserung darstellt.
Der zweite Punkt vereinfacht z. B. das Zusammenführen mehrerer kleiner Datenbanken, die auf unterschiedlichen Betriebssystemen laufen, zu einer größeren Datenbank.
In den nächsten Ausgaben werden wir uns mit der Flash Recovery Area, dem Recovery Manager und den Neuigkeiten im Data
Guard Umfeld beschäftigen.
Andreas Kother ([email protected]).
19
Java/XML - Titelthema Java 1.5.0
Der Tiger ist los
Nachdem vor kurzem erst das Release Candidate von Java 1.5.0, genannt Tiger, von Sun veröffentlicht wurde, steht seit Ende September 2004 nun die endgültige Version zum Download bereit. Das fast 50 MB große
Paket ist unter Java-Entwicklern seit langem ersehnt. Und das nicht wegen der üblichen Bugfixes und Erweiterungen an der Java-Bibliothek und der JVM, sondern wegen der angekündigten Spracherweiterungen.
Diese sind Gegenstand dieses Artikels.
Ausgangsbasis
Wer schon länger in Java entwickelt, dem sind sicherlich einige
Dinge aufgefallen, die unschön sind, weil sie entweder viel Tipparbeit erfordern, einfach nicht in gutes, objektorientiertes Design
passen oder in anderen Programmiersprachen einfach eleganter
gelöst sind. Und genau hier setzen die erwähnten Spracherweiterungen an. Dazu gehören:

Generics
Enhanced for-Loop
Autoboxing/Unboxing
Typesafe Enumerations
Static Import
Im folgenden werden diese Spracherweiterungen an konkreten
Beispielen vorgestellt.
Generics
Java besaß bisher kein Sprachkonstrukt, welches mit den Templates in C++ vergleichbar wäre. Mit den Generics hat Sun dieses
Manko behoben. Dahinter verbirgt sich die Möglichkeit, Collection- und Iterator-Instanzen mit Datentypen zu parametrisieren.
Abbildung 1 zeigt als Beispiel im oberen Kasten die Nutzung einer ArrayList im herkömmlichen Sinne. Zu beachten sind die dabei
notwendigen Casts, wenn Elemente direkt aus der ArrayList bzw.
über einen Iterator entnommen werden.
Unter Nutzung der Generics entfällt in beiden Fällen der Cast, da
die Elemente automatisch in den korrekten Datentyp umgewandelt werden. Der untere Kasten der Abbildung 1 stellt den Code
mit Nutzung von Generics dar.
Das Ganze hat allerdings noch einen weiteren Vorteil. Die Typprüfung, also welche Elemente in eine Collection eingefügt werden, führt der Compiler während der Übersetzung durch. Damit
gehört die bekannte java.lang.ClassCastException zur
Laufzeit der Vergangenheit an.
Enhanced for-Loop
Die zweite Spracherweiterung befasst sich mit for-Schleifen, die
zum Iterieren über Array- und Collection-Instanzen genutzt werden. Das ist zum einen mit Hilfe eines Index, zum anderen durch
Nutzung eines Iterators möglich. Beide Fälle sind im oberen Kasten in Abbildung 2 zu sehen.
Greift man auf die neue for-Schleife zurück und kombiniert das
Ganze mit der Verwendung von Generics, kann eine Menge Code
eingespart werden. Die so optimierten for-Schleifen sind auch
20
besser lesbar, wie der Vergleich der beiden
Kästen in Abbildung 2 verdeutlicht.
Autoboxing/Unboxing
Ein Nachteil von Collections war bisher, dass
sie nur Elemente von komplexen Datentypen
aufnehmen konnten. Wollte man Elemente
einfacher Datentypen wie int, long, char etc.
einfügen, war bisher eine passende WrapperInstanz notwendig. Beim Entnehmen mussten die Elemente händisch entpackt werden,
wie im oberen Kasten in Abbildung 3 zu sehen.
Mit dem Autoboxing/Unboxing-Feature ist das
nun alles nicht mehr nötig. Das Einfügen und
Entnehmen von Elementen eines einfachen
Datentyps gestaltet sich so, als ob die Collection auch mit einfachen Datentypen umgehen
könnte. Abbildung 3 zeigt im unteren Kasten
die Vereinfachung.
Zu beachten ist allerdings, dass die verwendete Collection mit der zugehörigen WrapperKlasse, also z. B. Integer, parametrisiert wird.
Dass dann natürlich keine anderen Elemente
als int-Werte eingefügt werden können, ist
einleuchtend.
Typesafe Enumerations
In switch/case-Anweisungen können hinter
dem Schlüsselwort case nur Werte verwendet werden, die sich implizit in int-Werte
wandeln lassen. Da diese wenig aussagekräftig sind, verwenden Entwickler oft int-Werte, die als statische Konstanten unter sprechenden Namen in einer Klasse definiert sind.
Dieses Vorgehen hat jedoch einige Nachteile.
Die so definierten int-Enumerations
bieten keine Typsicherheit, da die Verwendung der Konstanten nicht überprüft wird,
bilden keinen richtigen Namensraum,
werden als int-Werte in die verwendenden Klassen kompiliert, d. h. können nur
durch die Rekompilierung der verwendenden Klassen geändert werden und
können nicht mit Collection-Instanzen verwendet werden.
Java/XML
Darüber hinaus werden bei Ausgaben die intWerte und nicht, wie eigentlich gewünscht, die
Konstantennamen ausgegeben. Diese Nachteile lassen sich durch den Einsatz des Typesafe Enum Entwurfsmusters umgehen. Dieses muss allerdings immer individuell implementiert werden. Einfacher ist es, ab Java
1.5.0 die Typesafe Enumerations einzusetzen.
Eine Typesafe Enumeration wird durch das
Schlüsselwort enum deklariert. Sie besitzt im
einfachsten Fall einen Namen und besteht aus
einer Element-Menge eben dieses Typs. Hierdurch wird die gewünschte Typsicherheit erreicht. In Abbildung 4 ist eine solche, einfache
Typesafe Enumeration zu sehen.
Da es sich bei einer Typesafe Enumeration
im Grunde um eine Klasse handelt, können
innerhalb einer Typesafe Enumeration zusätzlich Attribute, Methoden und parametrisierte
Konstruktoren definiert werden (siehe Abbildung 5). Damit ist es möglich, den Elementen
weitere Eigenschaften zu zuweisen.
Typesafe Enumerations stellen also eine Implementierung des Typesafe Enum Entwurfsmusters auf Sprachebene dar. Die zugehörigen Elemente sind Instanzen. Sie besitzen einen Namensraum, sind typsicher, können mit
Collection-Instanzen verwendet werden und
geben bei der Ausgabe ihren Namen aus.
Bei der Implementierung von Typesafe Enumerations gilt es aber auch, ein paar Regeln
zu beachten:

Ein Defaultkonstruktor darf nicht implementiert werden, da dieser implizit bereitgestellt wird.
Die Typesafe Enumeration besitzt automatisch die beiden Methoden values() und
valueOf(String) sowie die Methoden
der Klasse java.lang.Enum.
Die enum-Klasse ist implizit immer statisch.
Deklarierte Attribute und Methoden sind
automatisch statisch.
Static Import
Fast jede Java-Anwendung verwendet Konstanten. Diese sind oft zentral in einer Klasse
statisch definiert. Das hat allerdings den Nachteil, dass bei der Nutzung dieser Konstanten
der Klassenname vorangestellt werden muss
(z. B. Constants.MAXSIZE).
Um das zu umgehen, besteht die Möglichkeit,
die Konstanten innerhalb von Interfaces zu definieren, die ansonsten nichts deklarieren. Die
Klassen, die diese Konstanten nutzen wollen,
müssen anschließend das Interface imple-

List intList = new ArrayList();
intList.add(new Integer(1));
Integer value;
for (Iterator it = intList.iterator(); it.hasNext();)
{
// Cast notwendig
value = (Integer) it.next();
System.out.println("value: " + value);
}

List<Integer> intList = new ArrayList<Integer>();
Integer value;
for (Iterator<Integer> it = intList.iterator();
it.hasNext();)
{
// Zuweisung ohne einen Cast
value = it.next();
}

Abb. 1: Vergleich der Verwendung einer ArrayList und eines Iterators
vor (oben) und nach der Spracherweiterung (unten).

// for-Schleife mit Laufindex
for (int i = 0; i<intList.size(); i++)
{
Integer value = (Integer)intList.get(i);
}
// for-Schleife mit Iterator
{
Integer value = (Integer)it.next();
}

for (Integer value : intList)
{
}

Abb. 2: Vergleich einer for-Schleife mit Laufindex bzw. Iterator vor der
Spracherweiterung (oben) und einer Enhanced for-Schleife danach
(unten).
21
Java/XML
inweis:
Seminarh
RDIX ab
n bietet O
ite
s Se5.0 Neuhe
ein 2-tägige
Mit Java
uartal 2005 n.
Q
en
st
er
a
dem
hema
diesem T
minar zu
E, u. a.:
hema J2E
T
auch zum
Servlets
s
d
e
n
t
u
ib
P
g
inare
mit JS
Neue Sem
ntwicklung
plikationse
JB
Web-Ap sentwicklung mit E
tion
Applika

List intList = new ArrayList();
List tmpIntList = new ArrayList();
{
Integer value = (Integer)it.next();
int i = value.intValue();
tmpIntList.add(new Integer(i + 1));
}

intList.add(1);
intList.add(2);
intList.add(3);
List<Integer> tmpIntList = new ArrayList<Integer>();
for (Iterator<Integer> it = intList.iterator();
it.hasNext();)
{
// Zuweisung ohne Cast (siehe Generics)
Integer value = it.next();
// Unboxing [Integer->int], Addition,
// Autoboxing [int->Integer]
tmpIntList.add(value + 1);
}

Abb. 3: Vergleich des Einsatzes der Autoboxing/Unboxing-Spracherweiterung vor (oben) und nach der Spracherweiterung (unten).
public enum Farbe {
rot, gelb, weiss, violett
};
Abb. 4: Einfache Typesafe Enumeration.
public enum Blume {
Rose("Topf"), Akelei("Garten"), Mohn("Feld");
Blume(String standort) {
this.standort = standort;
}
private final String standort;
public String getStandort() {
return standort;
}
};
Abb. 5: Typesafe Enumeration mit Konstruktor, Methoden und Attributen.
Links
[1] http://java.sun.com/j2se/1.5.0/index.jsp
[2] http://www.jetbrains.com
[3] http://www.ordix.de/download/Java_1.5.0_Test.zip
22
mentieren. Dadurch können
die Konstanten ohne vorangestellten Klassennamen genutzt werden. Obwohl diese Lösung funktioniert, ist sie aus sprachtechnischer Sicht zu verwerfen. Interfaces sind dazu da, um neue Typen zu deklarieren und nicht,
um als Konstanten-Container zu dienen.
Damit solche Konstrukte nicht mehr nötig sind,
gibt es in Java 1.5.0 die Spracherweiterung
Static Import. Darunter versteht man den Import aller in der angegebenen Klasse enthaltenen Konstanten. Diese können anschließend
ohne vorangestellten Klassennamen genutzt
werden.
Um z. B. alle Konstanten, die in der Klasse
de.ordix.java15.Constants definiert
werden, zu importieren, genügt die folgende
Anweisung:
import static de.ordix.java15.Constants.*;
Zu beachten ist das Schlüsselwort static
und die Erweiterung .* hinter dem Klassennamen.
Resümee
Mit den hier vorgestellten Spracherweiterungen nimmt Java dem Entwickler einen großen Teil der immer wiederkehrenden Tipparbeit ab. Und da Entwickler, wie allgemein
bekannt, lieber weniger als mehr tippen, ist
das sicherlich ein Schritt in die richtige Richtung. Das Resultat ist ein schlanker und eleganter Code, der darüber hinaus noch weniger unerwünschtes Laufzeitverhalten (Exceptions etc.) zur Folge hat.
Wer das Ganze schon jetzt ausprobieren will
oder gar sofort umsteigen möchte, braucht die
Java 1.5.0 und eine passende Entwicklungsumgebung. Ersteres stellt Ihnen Sun unter [1]
zum Download zur Verfügung. Als Entwicklungsumgebung bietet sich IntelliJ IDEA 4.5
an. Eine 30 Tage lauffähige Testversion kann
im Internet unter [2] runtergeladen werden.
Zusätzlich finden Sie auf den ORDIX Webseiten [3] das IDEA-Projekt Java_1.5.0_Test
als zip-Datei zum Download. Nach dem Entpacken in ein beliebiges Verzeichnis, kann
das Projekt direkt aus IDEA geöffnet werden.
Zu dem Projekt gehören die beiden Klassen
NewFeatures.java und Constants.java, welche
die hier vorgestellten Spracherweiterungen demonstrieren.
Bleibt uns nur noch, Ihnen viel Spaß mit dem
Tiger zu wünschen!
Christoph Borowski ([email protected]).
Aktuell
ORDIX Mitarbeiter ITIL-zertifiziert
Einige Projektmanager der ORDIX AG haben im April 2004 die Prüfung Foundation Certificate in IT Service
Management nach den Richtlinien des Examination Institute for Information Science (EXIN) und der TÜV
Akademie erfolgreich abgelegt.
ITIL steht für Information Technologie Infrastructure Library und ist eine Sammlung von
Richtlinien, die aus Best-Practices von IT-Organisationen und deren Prozessmodellen entstanden ist.
Change Management und Release Management. Die Prozesse
des Service Delivery sind Service Level Management, Availability
Management, IT Service Continuity Management, Capacity Management, Finance Management für IT Services und Security
Management.
Ende der 80er Jahre wurde ITIL durch die englische Central Computer and Communication
Agency (CCTA) ins Leben gerufen. Bis heute
entwickelt EXIN mit Unterstützung der Mitarbeiter von Rechenzentren, Lieferanten, Beratern und Ausbildern ITIL immer weiter. Somit
werden auch aktuelle Weiterentwicklungen
berücksichtigt.
Im Rahmen eines einheitlichen, übergeordneten Prozessmodells
definiert ITIL Abhängigkeiten, Aktivitäten, Rollen und Modelle der
einzelnen Prozesse und liefert so eine Orientierungshilfe und eine
einheitliche Begriffsdefinition für das IT Service Management.
Heute gilt ITIL als öffentlich zugänglicher Defacto-Standard, um im IT Service Level Management einen hohen Qualitätsstandard zu erreichen. Weltweit haben viele Organisationen
und Unternehmen ITIL mit Erfolg angewandt.
ITIL unterscheidet zwischen Prozessen für
den Service Support und dem Service Delivery. Der Service Support besteht aus den
Prozessen Incident Management, Problem
Management, Configuration Management,
Wie die Praxis gezeigt hat, liefert die Anwendung von ITIL ein
professionelles IT Service Management, eine höhere Kundenzufriedenheit, ein besseres Qualitätsmanagement und Kostensenkungen durch standardisierte Prozesse und deren permanente Optimierung.
Durch die Zertifizierung stellt die ORDIX AG ihre langjährige Erfahrung in diesen Bereichen jetzt auf ein offiziell anerkanntes Fundament und kann Sie beim Erreichen dieser Ziele in Ihrem Unternehmen mindestens so gut wie früher unterstützen, jetzt aber eben
auch mit TÜV-Stempel.
Sollten Sie Interesse haben, Ihre Prozesse auf ITIL umzustellen
bzw. unter ITIL Aspekten zu analysieren, helfen wir Ihnen gerne.
Richten Sie Ihre Fragen einfach per E-Mail an [email protected].
Leserinformation
Und nochmal ans Türchen geklopft
Zu dem Artikel Knocking at your Backdoor (ORDIX News 3/2004) erhielten wir sehr
viel Post, so dass sich der eine oder andere Leser ein wenig gedulden musste, bis er
die gewünschten Informationen erhielt.
Bitte haben Sie an dieser Stelle etwas Verständnis, dass wir wenn schon kostenfrei
nicht immer sofort reagieren können. Manchmal müssen wir auch Geld verdienen, sonst
könnten wir Ihnen so nützliche Unterlagen wie
z. B. unsere News nicht unentgeltlich zur Verfügung stellen oder für Sie kostenlose Fachtreffs organisieren.
Von einem ehemaligen ORDIX Mitarbeiter,
jetzt bei SAP tätig, erhielten wir eine Information aus dem Hause SAP. Diese möchten wir
Ihnen nicht vorenthalten, da sie eine wichtige Ergänzung zu unserem Artikel darstellt:
Auch SAP hat die mehr oder weniger schöne Eigenart, Datenbank Benutzer anzulegen. In älteren R3 Releasen hieß der Benutzer sapr3 mit dem default password sap. Seit MCOD (Multi
Component One Database) und Release >= 610 heißen die Benutzer standardmäßig sap<SCHEMAID> und sap<SCHEMAID>db
für J2EE. Diese Benutzer haben kein Standard Passwort mehr.
Ob es sich dabei um eine offizielle SAP Aussage handelt, entzieht
sich der Kenntnis der Redaktion ;-)
23
Datenbanken
Neue Reihe IBM Informix Dynamic Server Reorganisation (Teil I):
Interne Architektur
Die Gründe, die eine Reorganisation notwendig machen, sind vielseitig. Der Hauptaspekt ist nicht ausschließlich die starke Fragmentierung der DBspaces, sondern vielmehr die interne Verwaltung der Extents.
Denn im Zeitalter von SAME (Stripe And Mirror Everything) wird die Fragmentierung bewusst unterstützt.
Mit dem Mythos Viele Extents bedeuten schlechte Performance wegen des schlechteren I/O Verhaltens
möchten wir in dem folgenden Artikel aufräumen.
Damals
Betrachten wir die Entwicklung der Festplatten in den vergangenen
Jahren. Vor einigen Jahren war die Festplattenkapazität um ein
Vielfaches kleiner und auch die Zugriffszeiten waren deutlich langsamer als bei den heutigen Plattensubsystemen. Deshalb versuchte man, Tabellen mit wenigen, dafür aber großen Extents anzulegen. Idealerweise wurden RAW Devices in der Mitte des Plattenstapels erzeugt, damit die Positionierungswege des Schreib-/Lesearms möglichst kurz waren.
Der Leitsatz lautete:
Wenige Extents pro Objekt = bessere Performance.
Heute
Heute wird der Effekt der Fragmentierung noch zusätzlich unterstützt und gewollt (Volume Manager, RAID 10 usw.). Auch die zusätzliche Fragmentierung von Daten aus der logischen Sicht (z. B.
Fragmentation by Round Robin) ist nichts anderes als ein zusätzliches Striping.
Der Leitsatz heute heißt: SAME, Stripe and Mirror everything =
viele Fragmente = bessere Performance.
DBspaces werden diese 50 Pages direkt belegt (onspaces). Jedes Tablespace hat eine
Tablespace-Nummer. In diesem Zusammenhang spricht man auch von der Partition Nummer (partnum). Das Wort Tablespace und
Partition sind gleichzusetzen.
Die Partition Nummer (partnum) hat folgenden Aufbau: 0 x DDD LLLLL
Die ersten 3 Halfbytes (1 ½ Bytes) stellen die
DBspace Nummer dar. Die letzten 5 Halfbytes
(2 ½ Bytes) die logical Page Nummer. Insgesamt belegt die Partnum 4 Bytes. Mit Hilfe der
SQL-Funktion DBINFO kann man sich den
DBspace Namen anhand einer Partnum ausgeben lassen (siehe Abbildung 2).
Die Partition Nummer einer Tabelle bzw. eines
Indizes kann man aus dem System Catalog
(Systables) der lokalen Datenbank oder aus
den SMI-Tabellen (Sysmaster Datenbank) entnehmen (siehe Abbildung 3).
Trotzdem sollte man die Anzahl der Extents je Datenbankobjekt
möglichst gering halten. IBM Informix kann pro Objekt nur eine
bestimmte Anzahl an Extents verwalten. Des Weiteren ist der
Verwaltungsaufwand umso größer, je mehr Extents ein Objekt
besitzt. Somit trifft der Leitsatz von früher Wenige Extents pro
Objekt = bessere Performance auch noch heute zu.
Das eigentliche Problem hierbei liegt jedoch nicht ausschließlich
im schlechteren I/O Verhalten, sondern in der Verwaltung der Extents, und zwar in der Struktur des Tablespace-Tablespace.
Tablespace-Tablespace
Das Tablespace-Tablespace verwaltet alle Partitionen/Tablespaces
eines DBspace. Das bedeutet, jede Tabelle belegt genau eine
Page, die Partition Page, innerhalb des Tablespace-Tablespace.
Jedes DBspace beinhaltet ein eigenes Tablespace-Tablespace
(siehe Abbildung 1). Dieses wird in den ersten Pages des initial
Chunks angelegt. Die Extent Größe des Tablespace-Tablespace
beträgt 50 Pages und ist nicht änderbar. Beim Neuanlegen eines
28
Abb. 1: Tablespace-Tablespace Struktur.
select dbinfo("DBSPACE",partnum)
from systables
where tabid = 1
Abb. 2: DBINFO Funktion.
Datenbanken
Abbildung 4 zeigt die Ausgabe des Befehls
onstat d, nachdem ein neuer DBspace
erzeugt wurde.
database UserDB;
select partnum,tabname
from systables;-- lokaler System Catalog
database sysmaster;
select partnum,dbsname,tabname
from systabnames;-- Sicht auf alle Tablespace-Tablespaces
Alle weiteren Chunks, die zu einem DBspace
hinzugefügt werden, belegen anfänglich nur
3 Pages (1 + 2 Chunk Page + Page 3, die Free
Chunk Page). Die maximale Größe eines Extents ist durch die Größe eines Chunks begrenzt. Ein Tablespace hingegen kann sich
über mehrere Chunks erstrecken, wie in Abbildung 6 zu sehen ist.
Abb. 3: Partitions-Nummer innerhalb der lokalen System- und SMITabellen.

Die Partition Page
Eine Page im Tablespace-Tablespace wird
auch Partition Page genannt.
Time Stamp (am Ende der Page) mit 4 Bytes
Slot Table Einträge mit jeweils 4 Bytes (4 Bytes * 5 Slots = 20
Bytes)
Slot 1: Partitionsstruktur
Informationen zur Partitionsstruktur (56 Bytes).
Der Aufbau einer Partition Page entspricht einer ganz normalen Daten Page. Der Unterschied besteht lediglich darin, dass die Informationen, die in dieser Page gespeichert sind,
keine Daten bzw. Indexdaten sind, sondern
Informationen zu der Tabelle, die sie beschreibt.
Des Weiteren besteht eine Partition Page ausschließlich aus 5 Slots (siehe Abbildung 7).
Slot 2: Objekt-Namen
Informationen zu DBspace Namen, Table Owner, Table Name und
NLS Collations.
Slot 3: Special Columns
Informationen über Special Columns. Dieses sind z. B. VARCHAR,
TEXT, BYTE, CLOB, BLOB Datentypen.
Der Page Header belegt immer eine feste Größe von 24 Bytes. Folgende interne Page Felder müssen noch berücksichtigt werden:
Slot 4: Index Informationen
Infomationen zu allen Indizes, die auf dieser Tabelle hinterlegt sind.
IBM Informix Dynamic Server Version 9.40.FC2
-- On-Line -- Up 02:02:06 -- 47408 Kbytes
Dbspaces
address
number
700000010180e58 1
70000001062f028 2
2 active, 2047 maximum
flags
0x20001
0x20001
fchunk
1
2
nchunks
1
2
flags
N
N
owner
informix
informix
name
rootdbs
newdbspace
Chunks
address
chunk/dbs
700000010181028 1
1
70000001062f1a8 2
2
70000001062f8c8 3
3
3 active, 2047 maximum
offset
0
0
0
size
7500
2500
2500
free
1396
2447
2497
bpages
flags
PO-PO-PO--
pathname
/informix/ifxdata/inf00/rootdbs_01
/informix/ifxdata/inf00/new_chunk_01
/informix/ifxdata/inf00/new_chunk_02
Expanded chunk capacity mode: disabled
Abb. 4: Ausgabe onstat d.
------------------------------------------Chunk - Größe :
2500 Pages
Chunk - Free :
2447 Pages
---------Belegt
:
53 Pages
1 + 2 Page im Chunk
--> Chunk Pages sind reserviert
3
Page im Chunk
--> Free Chunk Page
50
Pages
--> Tablespace - Tablespace
------------------------------------------53 Pages belegt beim Neuanlegen eines DBspaces im initial Chunk.
Abb. 5: Beispielerklärung einer onstat d Ausgabe.
29
Datenbanken
PAGE HEADER
24 Bytes
SLOT1: Tablespace Informationen
SLOT2: DBspace Name, Table Name
SLOT3: Special Columns
SLOT4: Index Informationen
SLOT5: Extent Liste
Slot 5 Slot 3 Slot 2 Slot 1 Time Stamp
4 Bytes 4 Bytes 4 Bytes 4 Bytes 4 Bytes
Abb. 6: Zusammenhang DBspaces, Chunks, Tablespace und Pages.
Abb. 7: Aufbau einer Partition Page (Page aus
dem Tablespace-Tablespace).
select
dbsname DB_Name,tabname Tab_NAME,ti_nextns Number_Extents,
ti_nrows Num_Rows, ti_nptotal Total_Pages
from systabinfo, systabnames
where partnum = ti_partnum - Verknüpfung systabinfo und systabnames
and
dbsname = "DB-NAME"-- Datenbank-Name
and
tabname not like "sys%" keine Systemtabellen (wie systables, syscolumns ...)
and
ti_npdata > 0 -- nur Tabellen, keine Indizes, ansonsten = 0
order by 3 desc
Abb. 8: SMI SQL. Sicht auf die Informationen des Tablespace-Tablespace.
Slot 5: Extent Liste
Informationen zu Anzahl, Größe sowie der Position des Extents
innerhalb des Chunks. Jeder Eintrag, also jedes Extent, belegt 8
Bytes.
Daraus resultieren folgende Größenverhältnisse:
Page Header
Slot Table
Slot 1
24 Bytes
20 Bytes (4 Bytes * 5 Slots)
56 Bytes
100 Bytes
Das bedeutet, dass bei einer angenommenen Pagesize von 4096
Bytes für die Slots 2 - 5 3996 Bytes zur Verfügung bleiben.
Wird ein neues Extent erzeugt, bedeutet das
somit auch einen weiteren 8 Byte Eintrag im
Slot 5 in der Partition Page. Der Verwaltungsaufwand wird genau an dieser Stelle sichtbar.
Besteht ein Objekt aus wenigen Extents, ist
der Verwaltungsaufwand geringer. Besteht
eine Tabelle aus vielen Extents, wirkt sich dieses nicht nur negativ auf das I/O Verhalten
aus, sondern der Verwaltungsaufwand der Extents steigt durch die längere Extent Liste
deutlich an.
Die maximale Anzahl der Extents pro Tabelle ist, wie oben ersichtlich, in besonderer Weise von folgenden Gegebenheiten abhängig:
Das SQL-Skript in Abbildung 8 gibt Auskunft
über die Anzahl der Extents einer Tabelle. Also
u. a. die Sicht auf unser Tablespace-Tablespace.

Fazit

Wie groß ist die Pagesize?
(2K oder 4K)
Gibt es Special Columns?
(Slot 3)
Wieviele Indizes sind vorhanden?
(Slot 4)
Der Rest des Speicherplatzes in der Partition Page steht somit
dem Slot 5 der Extent Liste zur Verfügung. Die maximale Anzahl
Extents je Tabelle kann somit variieren. Im Durchschnitt können
Tabellen mit einer Pagesize von 2K ca. 250 Extents und bei einer
Pagesize von 4K ca. 400 Extents belegen.
30
Extents
Mit diesem Artikel erläuterten wir Ihnen zunächst die interne Architektur des IBM Informix
Dynamic Servers bezüglich der Verwaltung
der Extents. Im 2. Teil dieser Reihe, der in einer der nächsten ORDIX News Ausgaben erscheint, lesen Sie, welche Mittel und Möglichkeiten Sie haben, um eine Reorganisation
performant durchzuführen.
Guido Saxler ([email protected]).
Unix
Aktuell
Verzeichnisse
Larry Ratlos in
Larry, Wildcards und rm
Larry möchte mal wieder eines der Unix Verzeichnisse aufräumen und findet die Situation der Abbildung 1 in seinem Verzeichnis vor.
zur Überwachung per automountd eingetragen hatte,
stellte er erschrocken fest, das sich keine Kommandos
mehr ausführen ließen.
Da er nur die Unterverzeichnisse in diesem Verzeichnis haben möchte und die Datei -rf das
Überbleibsel eines unkundigen Werksstudenten ist, kopiert er die Dateien file1 bis file7 in die richtigen Verzeichnisse.
Unsere Berater zeigten Larry den einzigen Weg, ohne reboot
aus seinem Schlamassel heraus zu kommen:
1. Auf dem System befinden sich
eine Reihe alternativer Binaries. Um sie zu verwenden, muss Larry den Pfad
entsprechend erweitern:
# PATH=/usr/xpg4/bin:/usr/
ucb:$PATH
# export PATH
Anschließend führt er das
Kommando rm * aus (siehe Abbildung 2), das Dateien löscht, Verzeichnisse aber
stehen lässt. Wie sieht das
ganze nach dem Ausführen
von rm * aus? Und warum sieht es so aus?
Wie hätte Larry das
vermeiden können?
(Die Antwort lautet nicht:
Windows einsetzen!)
Für die ersten 10 Einsender
(natürlich mit der richtigen
und vollständigen Lösung)
haben wir dieses Mal als besondere Weihnachtsaktion
einen Gutschein für eine EinTages-Schulung aus unserem Seminar Angebot bzw.
20 % Rabatt für eine 5-Tages-Schulung. Senden Sie
Ihre Lösung also bis zum
31.12.2004 per E-Mail an
[email protected].
2. Dann kann er mit dem vi-Editor die
/etc/auto_master editieren und
die Zeile mit /usr/bin wieder herausnehmen.
Abb. 1: Das Ratlos Verzeichnis.
3. Anschließend muss der Automounter die neue Konfiguration einlesen:
# /usr/lib/fs/automount -v
Der alte Zustand ist nun wieder hergestellt.
Überwachung von /usr
Etwas schwieriger wird die Lösung,
wenn er nicht /usr/bin, sondern /usr
vom Automounter überwachen lässt.
Ganz ohne Reboot kommt Larry wohl
hier nicht aus ...
Damit er beim nächsten Hochfahren
keine Schwierigkeiten bekommt, sollte er die /etc/auto_master bereinigen. Da er nun aber keinen Editor mehr
zur Verfügung hat (sie liegen ja alle unter /usr/*), muss er die
/etc/auto_master wohl oder übel löschen. Wenn er noch eine
Shell laufen hat, kann er vorher zumindest eine Kopie machen:
# while read line
> do
> echo $line
> done < /etc/auto_master > /etc/auto_master.bak
Abb. 2: Aufräumen und löschen aber wie
sieht es dann aus?
Die Lösung des Rätsels
aus der ORDIX News Ausgabe 3/2004
Das Rätsel in der letzten ORDIX News war
wohl entweder zu schwer oder so einfach,
dass sich niemand dazu entschließen konnte, unserem Larry auf die Sprünge zu helfen.
Somit musste Larry also einen ORDIX Mitarbeiter zu Rate ziehen.
Überwachung von /usr/bin
Larry hatte auf seinem Solaris-System den Automounter ausprobiert. Nachdem er /usr/bin
Anschließendes Löschen und Rebooten (erfordert Root-Berechtigung!):
# > /etc/auto_master
# /sbin/init 6
Damit bekommt er sein System wieder zum Laufen.
31
Datenbanken
Oracle Internet Directory (Teil III)
In den letzten beiden Ausgaben stellten wir die Installation und Konfiguration sowie die Nutzung des Oracle
Internet Directory (OID) als zentrale Stelle der Namensauflösung in einer Oracle Umgebung vor. In dieser Ausgabe beschreiben wir den Einsatz des OID zur zentralen Benutzer- und Rollenverwaltung für Oracle Datenbanken.
Zielsetzung
Enterprise Security Manager
Dieser Beitrag beschreibt, wie zwei Benutzer auf eine Oracle 9i
Datenbank zugreifen können, ohne sie auf der Datenbank mittels
CREATE USER anzulegen. Die Benutzer werden nur als Objekte
im OID angelegt und dort administriert. Die Benutzer werden sich
über den OID an der Datenbank identifizieren.
Die Erstellung einer eigenen Certification Authority geschieht über ein Skript, welches als
ein Wrapper für den Enterprise Security Manager (ESM) dient. Über das Wrapper-Skript
$ORACLE_HOME/bin/esm wird das grafische
Werkzeug gestartet, mit dem wir viele Schritte der nötigen Konfiguration durchführen werden. Unter anderem erstellen wir die Zertifikate
für die Datenbank und die Benutzer damit.
Die Datenbank mit dem OID läuft auf einem Linux Server. Die
Benutzer melden sich also an derselben Instanz an, in der auch
OID installiert wurde. Die beispielhafte Anmeldung geschieht über
die Kommandozeile mittels sqlplus. Wir gehen davon aus, dass
das OID eingerichtet und konfiguriert wurde, wie in den vorigen
beiden Ausgaben der ORDIX News beschrieben.
Enterprise Security
Die Verwaltung von Enterprise Benutzern und Enterprise Rollen
sowie deren Verwaltung im OID und spätere Authentifizierung der
Benutzer an der Datenbank wird mit dem Begriff Enterprise Security bezeichnet.
Enterprise Security kann nur über sichere, d. h. in diesem Fall
SSL-verschlüsselte Verbindungen realisiert werden. Die Datenbank, an der sich die Benutzer anmelden sollen, muss über einen
sicheren Listener erreichbar sein. Der Verzeichnisdienst ist ebenfalls dahingehend zu konfigurieren.
Zertifikate und Wallets
Für eine SSL-verschlüsselte Verbindung zwischen dem Listener
und der Datenbank ist ein sogenanntes X.509 Zertifikat zu erstellen. Diese Art der Zertifikate nutzt man z. B. auch bei geschützten
Webseiten (HTTPS). Damit kann eine verschlüsselte Verbindung
vom Client zum Server aufgebaut werden.
Wird dem Wrapper-Skript die Option genca
mitgegeben, so ruft dieses Skript den Befehl
$ORACLE_HOME/sysman/admin/mkRootCert
auf, welcher die für unsere CA benötigten Dateien erstellt.
Wir führen also den Befehl esm genca an
der Kommandozeile aus. Dabei wird die Eingabe eines Passwortes verlangt, welches zum
Beglaubigen der Zertifikate benötigt wird. Die
Dateien der CA werden im Dateisystem standardmäßig unter /etc/ORACLE/WALLETS/CA
abgelegt.
Nach dem Start des ESM und der Anmeldung
an der OID-Instanz muss die Datenbank, an
der sich die Benutzer anmelden wollen, in einem Oracle Kontext registriert werden. Dazu
wird unter Vorgänge Datenbank registrieren
ausgewählt.
Im folgenden Dialog (siehe Abbildung 1) werden die nötigen Informationen eingetragen,
Die Zertifikate werden von einer Certification Authority (CA, Zertifizierungsstelle) ausgestellt. Man geht davon aus, dass Client und
Server den von der CA ausgegebenen Zertifikaten bedenkenlos
vertrauen können.
Bei Oracle werden auch Zertifikate zur sicheren Kommunikation
eingesetzt. Jedes Zertifikat wird in einem sogenannten Wallet
verwaltet. Das Wallet ist durch ein Passwort geschützt. In einem
Wallet können mehrere Zertifikate für verschiedene Kommunikationspartner gespeichert und verwaltet werden. Zur Verwaltung
wird der Oracle Wallet Manager (OWM) benutzt. Dazu später mehr.
In unserem Beispielfall werden wir selbst eine CA erstellen, unsere Zertifikate signieren und in einem Wallet verwalten. In größeren Unternehmen existiert in der Regel eine CA. Bei dieser müssen die Zertifikate beglaubigt werden, bevor sie eingesetzt werden können.
32
Abb. 1: Datenbank im ESM registrieren.
Datenbanken
das Häkchen Wallet generieren gewählt und
ein Passwort vergeben. Im aufkommenden Dialog muss das Passwort der eben eingerichteten CA eingegeben werden, um das Datenbank-Zertifikat zu beglaubigen.
der sqlnet.ora werden in Abbildung 5 dargestellt. Sind Client
und Server nicht identisch, d. h. sollen sich die Benutzer von einem
anderen Computer aus mittels sqlplus anmelden, so sind die Einstellungen im Oracle Net Manager auf diesem Client zu tätigen.
Es wurde nun ein Wallet mit gültigem Zertifikat für die Datenbank erstellt. Das Wallet wurde direkt im OID abgelegt. Zum Aufbau einer verschlüsselten Verbindung über
einen sicheren Listener benötigen wir es
allerdings auch im Dateisystem des Linux
Servers, damit der Listener es zur verschlüsselten Verbindung zur Datenbank nutzen
kann.
Um das erstellte Wallet aus dem OID ins
Dateisystem herunterzuladen, starten wir
den Oracle Wallet Manager (OWM), ein grafisches Werkzeug zur Bearbeitung von Oracle Wallets (siehe Abbildung 2) und darin
enthaltenen Zertifikaten. Mit dem OWM la- Abb. 2: Walletverwaltung mit dem Oracle Wallet Manager.
den wir das eben erstellte Wallet aus dem
OID herunter. Dazu wird das Passwort benötigt, welches im Dialog aus Abbildung 1 einlistener.ora:
gegeben wurde.
SSL_LISTENER =
Nun speichern wir das Wallet im Verzeichnis
/etc/ORACLE/WALLETS/oracle. Hier kann prinzipiell jedes beliebige Verzeichnis angegeben
werden, allerdings konnte in unseren Tests der
sichere Listener nur gestartet werden, wenn
das Wallet sich im o. g. Verzeichnis befand.
Konfiguration eines SSL-DatenbankListeners
Um die Datenbank über eine sichere Verbindung anzusprechen, muss ein Listener eingerichtet werden, mit dem wir die Datenbank
über ein sicheres Protokoll erreichen können.
Mittels des Oracle Net Managers richten wir
einen Listener ein, der über das TCPS Protokoll und den Port 1575 angesprochen wird.
Die daraus resultierenden Einträge für die
listener.ora sind in Abbildung 3 zu sehen.
(DESCRIPTION =
(ADDRESS=
(PROTOCOL = TCPS)(HOST = localhost)(PORT = 1575)
)
)
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /etc/ORACLE/WALLETS/oracle)
)
)
SSL_CLIENT_AUTHENTICATION=FALSE
Abb. 3: SSL-Listener und andere Einträge des Net Managers.
Der SSL-Listener muss nun nur noch wissen,
wo das Wallet für die Datenbank liegt. Dazu
nutzen wir wieder den Oracle Net Manager.
Für die Konfiguration des Servers wird der
Pfad zu dem Datenbankwallet, welches der
Listener benutzen soll, angegeben (siehe Abbildung 4).
In unserem Beispiel sind Client und Server
identisch, so dass noch die Einstellung für den
Client erfasst werden muss. Hierzu ist der Pfad
zum Wallet wieder zu entfernen und nur der
Radiobutton Client auszuwählen. Die Konfiguration muss in beiden Fällen gespeichert
werden. Die resultierenden Änderungen an
Abb. 4: Konfiguration eines SSL-Listeners mit dem Oracle Net Manager.
33
Datenbanken
Der SSL-Listener muss für die Datenbank als local_listener
in der init.ora eingetragen werden. Damit der Name aufgelöst werden kann, ist er zudem in der tnsnames.ora einzutragen (siehe
Abbildung 6). Zudem ist in der init.ora ein Eintrag für den Parameter rdbms_server_dn hinzuzufügen.
In unserem Fall lautet der Eintrag:
rdbms_server_dn=cn=oiddb,cn=OracleContext,dc=ordix,dc=de
Dieser muss dem Distinguished Name (DN) entsprechen, auf den
das Zertifikat im Enterprise Security Manager ausgestellt wurde.
Dieser Eintrag wurde vom ESM auch im OID angelegt. Damit ist
eine Zuordnung der Datenbank zu genau diesem Eintrag im Verzeichnisdienst möglich, um dort später globale Rollen und Enterprise Rollen miteinander verknüpfen zu können.
Damit die Änderungen in der init.ora wirksam werden, müssen
die Instanz und der Listener neu gestartet werden.
sqlnet.ora:
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /etc/ORACLE/WALLETS/oracle)
)
)
SQLNET.AUTHENTICATION_SERVICES= (all)
SSL_CLIENT_AUTHENTICATION = TRUE
SSL_VERSION = 0
Abb. 5: Einträge des Net Managers in der sqlnet.ora.
init.ora:
local_listener=SSL_LISTENER
tnsnames.ora:
SSL_LISTENER =
(DESCRIPTION =
(ADDRESS=
(PROTOCOL = TCPS)(HOST = localhost)(PORT = 1575)
)
)
Konfiguration eines SSL-OID-Listeners
Für die Bereitstellung eines SSL-Zugangs zum
Verzeichnisdienst muss jetzt der OID-Listener
konfiguriert werden, um einen sicheren Kanal
zwischen Client und Datenbank bereitzustellen.
Hierzu wird der Oracle Directory Manager verwendet, in dem ein zusätzliches Configset definiert wird. Dies geschieht am besten durch
die Bearbeitung einer Kopie des bestehenden
Haupt-Configsets. Die Option SSL aktivieren
muss ausgewählt werden. Weitere Parameter wie der Pfad zum Datenbankwallet, der SSL
Port des OID-Listeners und die Berechtigungsprüfungsart müssen eingestellt werden (siehe Abbildung 7).
Zum Abschluss muss der OID-Server mit diesem Configset neu gestartet werden.
oracle@linux:~> oidctl \
connect=oiddb server=oidldapd \
instance=1 configset=1 start
Zwischenstand
Wir haben einen DB-Listener eingerichtet, mit
dem wir über das TCPS Protokoll auf eine Datenbank zugreifen können. Für diese DB haben wir ein Zertifikat erstellt, das sowohl im OID
als auch im Dateisystem in einem Wallet vorliegt. Der SSL-DB-Listener mit TCPS auf Port
1575 sowie der SSL-OID-Listener auf Port 636
benutzen dieses Wallet, um die Kommunikation mit der Datenbank zu verschlüsseln.
Alle Einstellungen für die sqlnet.ora, listener.ora
und tnsnames.ora wurden beschrieben und
die grundlegende Konfiguration ist damit abgeschlossen.
Jetzt werden nur noch die Benutzer und Rollen im OID und in der Datenbank eingerichtet.
Abb. 6: Einträge der init.ora und tnsnames.ora.
Abb. 7: Erstellung eines SSL-Configsets mit dem oidadmin.
34
Abb. 8: Hinzufügen einer Enterprise Rolle im
ESM.
Datenbanken
globale Rollen nur durch Zuordnungen mit dem OID genutzt
werden können. Sie können nicht an Datenbank Benutzer
vergeben werden.
create role g_roleA identified globally;
create role g_roleB identified globally;
grant create table to g_roleA;
grant create view to g_roleB;
Enterprise Rollen
Enterprise Rollen sind nicht in der Datenbank definiert, sondern sind Objekte im OID. Dort werden sie mit globalen
Rollen aus einer oder aus mehreren Datenbanken verknüpft.
Hier findet auch die Zuweisung von Enterprise Benutzern
an Enterprise Rollen statt.
Enterprise Benutzer
Abb. 9: Hinzufügen eines Enterprise-Benutzers im
ESM.
Zum weiteren Verständnis werden nun einige
Begriffe erläutert, die im Zusammenhang mit
Enterprise Security eine Rolle spielen:
Shared Schema
Als Shared Schema wird ein Schema in der
Datenbank bezeichnet, welches ohne einen
DN als Identifizierungskriterium angelegt wurde. Wird ein Benutzer mit einem DN angelegt, so wäre lediglich eine 1-zu-1 Beziehung
zwischen einem Zertifikat und einem Benutzer in der Datenbank möglich. Ein derartiger
Benutzer wird auch globaler Benutzer genannt und existiert direkt in der DB und nicht
als Objekt im OID. Das Shared Schema wird
mit folgendem Kommando erstellt.
CREATE USER \
s_schema identified globally as ;
Enterprise Benutzer existieren nicht in der Datenbank, sondern werden als Einträge im OID angelegt. Sie sind dort
einem Shared Schema zugeordnet und bekommen eine oder
mehreren Enterprise Rollen zugewiesen.
Enterprise Rollen und -Benutzer werden über den Enterprise Security Manager angelegt. Er erstellt dabei automatisch die entsprechenden Einträge im OID. Auf diese Weise werden nun die Enterprise Rollen e_role1 und e_role2 sowie die beiden Enterprise
Benutzer lk und ml in der OracleDefaultDomain angelegt.
Beim Anlegen der Benutzer sind Angaben, wie z. B. der vollständige Name der Person, die E-Mail-Adresse und natürlich ein Passwort für die spätere Anmeldung an der Datenbank zu machen.
Beim Anlegen des Benutzers ordnen wir ihm auch gleich eine der
eben erstellten Enterprise Rollen zu. Das geschieht über den Reiter
Enterprise-Rollen im Dialog Benutzer erstellen. Der Benutzer
lk wird der e_role1 und ml wird der e_role2 zugeordnet (siehe Abbildungen 8 und 9).
Als nächstes muss unserem benutzten Oracle Context unter
dc=ordix,dc=de eine sogenannte Benutzersuchbasis zugeordnet
Auf diese Weise besteht später die Möglichkeit, dem Shared Schema über den ESM einen oder mehrere Enterprise Benutzer zuzuweisen, die mit diesem Schema auf der Datenbank arbeiten. Dem Schema können mittels GRANT Zugriffsrechte innerhalb der Datenbank erteilt werden. Es ist sinnvoll, dieses
Schema mit einer sehr geringen Anzahl von
Rechten auszustatten und alle weiteren Rechte über die globalen Rollen zu vergeben.
grant create session to s_schema;
Globale Rollen
Globale Rollen ähneln in einer Oracle Datenbank normalen Rollen. Ihnen werden auf üblichem Weg Rechte zugewiesen. Der Unterschied zu einer herkömmlichen Rolle ist, dass
Abb. 10: Zuordnung einer Benutzersuchbasis zu einem Oracle
Context.
35
Datenbanken
werden. Unter dieser sucht der OID die Enterprise Benutzer. Unsere Enterprise Benutzer wurden unter cn=Users,dc=ordix,dc=de
(siehe Abbildung 10) angelegt. Somit ist dieser DN als Benutzersuchbasis im Reiter Allgemein unseres Oracle Contextes hinzuzufügen.
Alle unsere Enterprise Benutzer sollen auf der Datenbank mit demselben Shared Schema (s_schema) arbeiten. Die Einträge für die
Enterprise Benutzer müssen dazu dem Shared Schema zugeordnet werden. Wir wählen in unserem Context unter dem Punkt Datenbanken unsere oradb aus und wählen unter dem Reiter Datenbankschema-Zuordnung die Benutzer aus und tragen das
Schema ein.
Privilegien
Die endgültigen Privilegien, die die Benutzer später in der Datenbank haben werden, ergeben sich aus den erstellten globalen
Rollen in der Datenbank. Im ESM werden die globalen Rollen unseren Enterprise Rollen zugeordnet. Die jeweilige Enterprise Rolle wird unter der OracleDefaultDomain ausgewählt. Unter dem
Reiter Globale Datenbankrollen nehmen wir die Zuordnung zu
den globalen Rollen vor.
Auf diese Weise richten wir es ein, dass g_roleA den beiden
Rollen e_role1 und e_role2 zugeordnet wird, während g_roleB
nur der Rolle e_role2 zugeordnet wird. Daraus ergibt sich die
in Abbildung 11 gezeigte Zuordnung.
Nun sind alle Konfigurationen und Zuordnungen durchgeführt. Die
Benutzer können sich jetzt über den OID an der Datenbank anmelden, ohne darin mit einem CREATE USER Befehl angelegt
worden zu sein. Es wird das Passwort benutzt, welches beim Erstellen des Enterprise Benutzers angegeben wurde. Dies ist in
unserem Fall das Standardpasswort welcome1, welches der ESM
beim Anlegen eines Enterprise Benutzers vorgibt. Dieses kann
natürlich beliebig geändert werden kann.
Der Benutzer lk meldet sich an der Datenbank z. B. mit dem
Befehl sqlplus lk/welcome1@oradb mit dem Netservicenamen
oradb an.
Abb. 11: Zuordnungen zwischen Enterprise Benutzern, Enterprise Rollen, globalen Rollen und
einem Shared Schema.
Fazit
In dieser Artikelreihe haben wir Ihnen zwei
Haupteinsatzgebiete für das Oracle Internet
Directory beschrieben. Zum einen wurde eine
Möglichkeit aufgezeigt, die Auflösung von
Netservicenamen vom Oracle Names zu trennen, indem diese nun im OID abgelegt und
damit von einer zentralen Stelle aus im Netzwerk genutzt und gepflegt werden können.
Zum anderen haben wir Ihnen in diesem Artikel die Benutzer- und Rollenverwaltung mit
dem OID vorgestellt. Benutzer müssen nicht
mehr in einer Instanz angelegt werden, sondern liegen als Objekte im LDAP-Verzeichnisdienst. Dies erleichtert den Administrationsaufwand ungemein. Die Installation und Konfiguration des OID und die Einbindung von
SSL für die Absicherung von Verbindungen
ist mit Sicherheit nicht ganz trivial, allerdings
sind dies einmalige Schritte und die im Nachhinein gesparte Zeit ist sehr groß.
Michael Lindermann, Lars Hendrik Korte
([email protected]).
Seminarvorstellung: Oracle Troubleshooting
Dieser Workshop vermittelt die Analyse typischer, praxisnaher
Fehlersituationen im Oracle Administrationsumfeld mit integrierter Wiederholung wichtiger theoretischer Grundlagen.
Das Seminar ist als Workshop angelegt und sehr übungsorientiert.
Vor Seminarbeginn können auch eigene Themenvorschläge angemeldet werden.
Voraussetzungen
Die Teilnahme an den Seminaren Oracle SQL (DB-ORA-01) und
Oracle Datenbankadministration Grundlagen (DB-ORA-03) wird
zwingend vorausgesetzt.
36
Zielgruppe
Fortgeschrittene Datenbankadministratoren.
Dauer: 5 Tage
Kursgebühr/Teilnehmer: 1.890 € zzgl. MwSt.
Termine
17.01.
25.04.
25.07.
17.10.
-
21.01.2005
29.04.2005
29.07.2005
21.10.2005
in
in
in
in
Wiesbaden
Wiesbaden
Wiesbaden
Wiesbaden
Java/XML
J2EE und Persistenz:
Ein heißes Eisen (Teil I)
Mit dieser Artikelserie packen wir ein heißes Eisen an. Denn wir wollen die Persistenzstrategie in einem
größeren, aktuellen Softwareprojekt, das auf J2EE Technologie basiert, darstellen. Das berührt die uralte
Frage uralt in den Zeitmaßstäben der Softwarebranche gerechnet Wie kommen die Daten aus der Datenbank in die Objekte des Hauptspeichers?
Im ersten Beitrag steht die Entscheidungsfindung im Mittelpunkt. Wir sehen uns an, wie die Ausgangslage
war, welche Alternativen für eine geeignete Persistenzstrategie zur Auswahl standen und wie bzw. anhand
welcher Kriterien eine Entscheidung getroffen wurde.
Ausgangslage
sierte sich die grundlegende Schichtenarchitektur nach klassischem Muster für J2EE Anwendungen sehr schnell heraus.
In dem Softwareprojekt hat ORDIX zusammen
mit dem Kunden ein sehr ehrgeiziges Ziel
verfolgt: Das Modernisieren einer klassischen
Client Server Anwendung zur Auftragsbearbeitung für Außendienstmitarbeiter eines großen Serviceunternehmens.
In nahezu allen ernst zu nehmenden J2EE Anwendungen also
auch in unserem neu zu erstellenden System existiert in der Architektur eine Schicht oder ein abgrenzbarer Bereich für die Persistenz, der als Nahtstelle zwischen der eigentlichen Geschäftslogik
und der relationalen Datenbank fungiert (siehe Abbildung 1).
Das ließ sich nur mit einer kompletten Neuarchitektur realisieren. Aus so genannten Fat
Clients mit komplexer GUI und Geschäftslogik
auf Laptops sollten Thin Clients werden, die
auf Kleingeräten (PDA, Handheld) mit minimaler Systemausstattung ablauffähig sind.
Dafür war es notwendig, nahezu die gesamte
Geschäftslogik der alten Clients zu bündeln
und auf die Serverseite zu verschieben. Und
da, wo Geschäftslogik auf Serverseite gefragt
ist, kommt man ruckzuck zu Geschäftsobjekten Auftrag, Benutzer, Leistung, Produkt, etc. Die müssen natürlich dauerhaft
gespeichert, d. h. persistent gemacht werden.
Rahmenbedingungen und
Projektvorgaben
Zu Anfang setzten wir uns mit allen Projektmitgliedern zusammen, als da wären: Entwickler, Architekt, Projektleiter,
QS Beauftragte und wer sich sonst noch
so im Projektumfeld tummelte. Die technischen Rahmenbedingungen wurden
zügig geklärt. Durch eine Vorgabe des
Kunden hatte der Borland Enterprise Server 5.2 (BES), der im JBuilder Enterprise
Edition 9 enthalten ist, überraschenderweise als Application Server die Nase
vorn (wer dazu mehr wissen will, dem
sei unsere Reihe Application Server im
Vergleich, Seite 44 in dieser News empfohlen Anmerkung der Redaktion).
Den Datenbank Part sollte Oracle in der
Version 9.2i ausfüllen. Zudem kristalli-
Alternativen für die Persistenzlogik
Alsdann ging es an die Aufstellung der Möglichkeiten, welcher
Speicherstrategie innerhalb der Serverimplementierung der Vorzug zu geben sei. Es kristallisierten sich vier Alternativen heraus,
die prinzipiell in die engere Auswahl kamen (eine lose Aufzählung
ohne Anspruch auf Vollständigkeit):
1. Stateful Session Beans und JDBC
Stateful Session Beans (SFB) spielen in diesem Ansatz die Rolle
der datenhaltenden Objekte. Per JDBC (Java Database Connectivity) hat der Entwickler selbst dafür zu sorgen, wie die Daten
aus der Datenbank in die Java Objekte gelangen. Und er muss
definieren und entscheiden, wann das zu geschehen hat. Der
Ansatz entspricht der Philosophie Ich mache mal lieber alles
selbst, dann hab ich wenigstens alles in der Hand.
$SSOLFDWLRQ6HUYHU%(6
:HE&RQWDLQHU
(-%&RQWDLQHU
6HVVLRQ
%HDQV
-63
6HUYOHWV
&OLHQW
/D\HU
3UHVHQWDWLRQ
/D\HU
3HUVLVWHQ]ORJLN
5'%06
2UDFOHL
(QWLW\
%HDQV
%XVLQHVV
/D\HU
'DWD/D\HU
Abb. 1: Schichtenarchitektur mit Hervorhebung der Persistenzlogik, die den
Business Layer mit dem Data Layer verbindet.
37
Java/XML
Das kann aus vielerlei Gründen problematisch sein. Ein Grundsatz der Programmierung für J2EE Anwendungen lautet: Nutze
die Technologie und Standards, die dir zur Verfügung stehen und
setze sie für die Zwecke ein, für die sie gemacht wurden. Und
Session Beans sind in der J2EE Philosophie definitiv nicht für die
Datenhaltung und für Persistenzaufgaben vorgesehen.
gen bieten neben der reinen Umsetzung der
Spezifikation häufig auch noch Zusatztools an
und sprechen von einer nahtlosen Integrationsmöglichkeit in J2EE Umgebungen.
2. Entity Beans mit BMP
In mehreren, teilweise kontrovers geführten
Diskussionsrunden, und nachdem wir einem
JDO Hersteller die Möglichkeit gaben, sein
Tool vorzustellen, wurden dann die maßgeblichen Kriterien, nach denen eine Entscheidung zu treffen war, aufgestellt:
In der Architektur von großen, typischen J2EE Anwendungen sollen nach den Vorstellungen von SUN, dem Initiator und Taktgeber
der J2EE Spezifikation, die datenhaltenden Entitäten von sogenannten Entity Beans repräsentiert werden.
Das sind Java Objekte, die bestimmte Konventionen einhalten und
vorgegebene Interfaces implementieren müssen, damit der Application Server sie ordentlich verwalten kann. Das gilt im Übrigen
auch für alle anderen Arten von Software Komponenten, die im
Application Server in spezialisierten Containern residieren seien
es JSP und Servlets in Web-Containern oder Enterprise Java
Beans (Session-, Entity-, Message Driven Beans) im EJB-Container.
Der Container entscheidet bei Entity Beans in jedem Fall darüber,
wann Daten zu laden bzw. zu speichern sind. Über das wie kann
noch explizit nachgedacht werden. Bei Entity Beans mit BMP (Bean
Managed Persistence) ist der Entwickler programmatisch dafür
verantwortlich. Er hat mit Hilfe von JDBC dafür zu sorgen, dass
Datenbankinhalte in die passenden Attribute der Entity Beans geschaufelt werden. Die Entity Bean kann also einen Zustand annehmen bzw. umgekehrt den Zustand auch wieder wegschreiben.
3. Entity Beans mit CMP
Mit der Version EJB 2.0 wurde die Alternative Entity Beans mit
CMP (Container Managed Persistence) sehr stark um viele nützliche und zuvor schmerzlich vermisste Eigenschaften erweitert. Der
manchmal etwas umständlichen Benutzung von Entity Beans mit
BMP wurde damit eine echte, komfortablere Alternative zur Seite
gestellt.
Bei diesem Ansatz kümmert sich der EJB-Container auch darum,
wie die persistenten Daten von bzw. in die entsprechenden Attribute gelangen. Das Mapping von Entity Bean Attributen auf Datenbankfelder geschieht deklarativ in sogenannten DDs (Deployment Deskriptoren), die in XML Dateien abgelegt sind.
Will man die volle Bandbreite der J2EE Möglichkeiten in diesem
Bereich nutzen, kann auch CMR (Container Managed Relationships)
Verwendung finden. Bei CMR liegt auch das Management von Beziehungen (1:1, 1:n, m:n) in der Verantwortung des Containers.
4. JDO
JDO steht für Java Data Objects. Es handelt sich um eine noch
relativ neue Spezifikation von SUN, die die prinzipiellen Schwierigkeiten des Object Relational Mapping aufgreift und Lösungsvorschläge bietet.
Dabei wurde sehr viel Wert darauf gelegt, die sehr mächtigen Konzepte der Objektorientierung wie Vererbung und Polymorphie möglichst umfassend umzusetzen. Hersteller von JDO Implementierun-
38
Entscheidungskriterien
Kosten
Die Borland Produkte (BES und JBuilder)
waren von vornherein gesetzt und damit automatisch im Projekt-Budget verplant. Es hätte sehr gewichtiger Gründe bedurft, um für die
Persistenzkomponente ein separates Produkt
mit eigenen Anschaffungs- und Lizenzkosten
zu wählen. Das wäre bei der Verwendung einer JDO Implementierung nötig geworden, so
dass für diese Alternative sehr schnell die Luft
dünn wurde.
Zu erwartende Komplexität
Bei diesem Punkt halfen die Erfahrungen der
ORDIX AG weiter, die in vielen Kundenprojekten immer wieder mit dieser Thematik konfrontiert ist. Des Weiteren hielten wir uns d. h.
das Projektteam, bestehend aus Mitarbeitern
des Kunden und der ORDIX an Empfehlungen aus dem Hause Borland, die der Variante Entity Beans mit CMP ein gutes Zeugnis
ausstellten.
Im Projektvorfeld bestätigte sich in RAP (Rapid Prototyping) Versuchen der Eindruck, dass
man mit CMP und CMR zu guten Ergebnissen kommen kann. Aber auch die Eindrücke
und Stellungnahmen, die wir im Projekt zu
JDO sammelten und bekamen, ließen ordentliche Ergebnisse für dieses Kriterium erwarten. Dies spielgelte sich auch in der abschließenden Bewertungsmatrix wieder (siehe Abbildung 2).
Zu erwartende Qualität der Persistenzlösung
Dieser Punkt war am schwierigsten zu beantworten und einzuschätzen. In einem Vorprojekt,
das beim gleichen Kunden ebenfalls in Java
realisiert war, hatte sich gezeigt, dass Eigenentwicklungen in diesem zentralen Bereich ab
einer gewissen Größe sehr leicht zu Problemfällen werden können. Das hört und liest man
häufig in Erfahrungsberichten zu größeren Softwareprojekten und kann von uns auch nur be-
Java/XML
stätigt werden. Dadurch rutschte die Alternative Stateful Session Beans mit
JDBC auch aus der engeren Wahl.
Entwicklungszeiten
Kosten
Zu erwartende
Komplexität
Zu erwartende EntwicklungsQualität
zeiten
Bewertung
Stateful Session Beans
0
-1
-1
0
-2
Entity Beans, BMP
0
0
0
1
1
Entity Beans, CMP
0
2
2
1
5
JDO
-1
2
3
-1
3
Wer den Alltag in größeren SoftwareAbb 2: Entscheidungsmatrix mit Bewertungszahlen.
projekten kennt, weiß, was jetzt kommt.
Wie nicht anders zu erwarten, sahen
auch wir uns mit einem, um es milde auszueiner übersichtlichen Tabelle dar. Wie in den vorhergehenden Abdrücken, ehrgeizigen Terminplan konfrontiert.
schnitten schon angedeutet, konnte die Entscheidung nur zwiD. h. binnen eines halben Jahres musste alschen den Alternativen Entity Beans mit CMP und JDO fallen.
les fertig sein.
Sehr ungünstig für JDO wirkt sich der Faktor Kosten aus. Aber
Das bedeutete, dass die Entscheidung für die
auch die zu erwartenden, längeren Einarbeitungszeiten in diese
Persistenzfrage noch brisanter wurde, denn
für die meisten Projektmitglieder völlig neue Technologie wirkten
eine Fehlentscheidung in diesem zentralen
sich in der Bewertungsmatrix negativ aus.
Segment hätte projektgefährdenden Charakter gehabt.
So haben wir uns auf die Persistenzstrategie Entity Beans mit
CMP, CMR festgelegt und sind mit diesem Ansatz zuversichtlich
Und eine Umkehr auf halbem Weg oder ein
in die Design- und Umsetzungsphase gestartet. Die GrößenordNeuanfang in der Projektmitte hätte ebenfalls
nung des Datenmodells umfasst ca. 70 Tabellen im relationalen
katastrophale Folgen nach sich gezogen und
Schema mit etwa ebenso vielen Beziehungen untereinander.
musste unter allen Umständen vermieden
werden. Es deutete sich bei JDO ein nicht zu
Die erste Designphase und die Initialisierung des Datenmodells
unterschätzender Zeitfaktor für die reine Einerfolgte mit Together Control Center. Das ehemals eigenständige
arbeitung an, was sich in der Bewertung neAnalyse- und Designwerkzeug ist inzwischen in JBuilder Enterprise
gativ auswirkte.
Edition 9 fest integriert.
Entscheidungsmatrix
Nachdem die Alternativen und Kriterien ausgearbeitet und formuliert waren, musste eine
Entscheidung gefällt werden. Ein probates
Hilfsmittel zur transparenten und nachvollziehbaren Entscheidungsfindung stellt die Entscheidungsmatrix dar.
In die Entscheidungsmatrix trägt man nach
bestmöglichem Ermessen für die Frage: Wie
gut erfüllt die Alternative A das Kriterium K?
eine Bewertungszahl in die Zelle [K,A] ein. Dabei sollte Folgendes eingetragen werden:
eine 0, falls keine oder eine neutrale Antwort vorliegt
eine negative Zahl bei negativer Antwort
eine positive Zahl bei positiver Antwort
Bei besonders ausgeklügelten Verfahren können die Spalten zusätzlich noch unterschiedliche Gewichtungsfaktoren bekommen. Das ist
in unserem Fall aber nicht passiert. Um nun
eine Maßzahl für die Eignung einer Alternative bezüglich der Entscheidungskriterien zu
erhalten, summiert man die Bewertungszahlen einer Zeile auf und trägt sie in die Spalte
Bewertung ein.
Entscheidungsfindung
Das haben wir für unsere Problemstellung
praktiziert. Das Ergebnis stellt Abbildung 2 in
In der eigentlichen Realisierungsphase wurde dann ausschließlich mit dem JBuilder weitergearbeitet. Auch die Änderungen und
Erweiterungen am Datenmodell, d. h. an den Entity Beans, erfolgten in der Phase im EJB-Designer, einem spezialisierten Designwerkzeug der JBuilder IDE (Integrated Development Environment).
Wie nicht anders zu erwarten war, gab es während der Projektphase kritische Momente, insbesondere als die CMP Engine des
BES einen sehr hässlichen, schwer nachvollziehbaren Fehler zeigte. Der wurde nach sehr mühsamer und anstrengender Suche,
die in der Hauptsache von unserem Projektteam geleistet wurde,
dann vom Application Server Hersteller behoben.
Fazit
Obwohl sich die J2EE Anwendung, auf der dieser Artikel basiert,
beim Kunden noch nicht im realen Einsatz befindet und man daher noch nicht von absoluter Praxistauglichkeit sprechen kann,
zeichnet sich doch eine ordentliche Stabilität der gewählten Persistenzlösung Entity Beans mit CMP ab. Explizite Lasttestszenarien und -durchläufe lassen auch im Hinblick auf die Performance
zufriedenstellende Ergebnisse erwarten.
ORDIX hat während des gesamten Projektverlaufs in allen wichtigen Phasen tatkräftige Unterstützung geleistet und gerade beim
Thema Persistenz geballtes Know-how und Erfahrung eingebracht.
Ein nachfolgender Artikel in Ausgabe 2/2005 wird die Umsetzungsphase und die eigentliche Technologie noch etwas genauer in Augenschein nehmen.
Dr. Hubert Austermeier ([email protected]).
39
Datenbanken
Oracle AS Discoverer 10g:
Integriertes Reporting
für Oracle-Anwendungen
Der Oracle AS Discoverer ist eine integrierte Lösung zum Erstellen von Berichten, ad-hoc-Abfragen, Analysen über alle Arten von in Oracle erfassten und verarbeiteten Daten: OLTP-Systeme, Datawarehouses oder
die Oracle E-Business Suite. Mit dem Discoverer können die Berichte im Intra- oder Internet veröffentlicht
werden oder an die Adressaten gezielt in verschiedenen Formaten übermittelt werden.
Der Discoverer erlaubt es, schnell und komfortabel Abfragen über
Daten in Oracle Anwendungen oder anderen Datenbanken zu erstellen und die erhobenen Daten für Analysen und Berichte zu nutzen. Die zu Grunde liegenden Daten werden in einem so genannten End User Layer durch frei zu benennende Objekte repräsentiert, die die entsprechenden Metadaten und Relationen enthalten
und per drag and drop in die Berichte eingebunden werden können. Diese Berichte können Tabellen und/oder Graphen enthalten.
legenden Prozesse sind J2EE-basiert als Discoverer Services im AS integriert (siehe Abbildung 2). Neben den weiterhin verfügbaren
Client-Server Anwendungen der Version 3.1
gibt es nun als zusätzliche Werkzeuge:

Bis zur Version 3.1 bestand der Discoverer aus zwei Client-Server Anwendungen, die unter Windows liefen:

1. Dem Discoverer Administrator, in dem der Zugriff zu den Daten gestaltet und administriert wurde und wird. Hier wird ein
End User Layer (EUL) erstellt, in dem die Metadaten für den
Zugriff auf die Datenbasis festgelegt werden, auf die beim Erstellen von Berichten zugegriffen wird.
2. Dem Discoverer Desktop, in dem Berichte entwickelt und ausgeführt wurden (siehe Abbildung 1).

Die Veröffentlichung der Berichte wurde über undokumentierte
Funktionen oder selbst erstellte Web-Lösungen abgehandelt. Auch
in der aktuellen Version sind Discoverer Desktop und Administrator weiterhin verfügbar als Teil des Oracle AS Discoverer.
Oracle AS Discoverer und Oracle Application Server 10g
Der Discoverer ist in der neuesten Version in den Oracle Application
Server integriert und als three tier-Architektur ausgelegt: Die grund-

Discoverer Plus, zum Einsehen und Erstellen von Berichten. Discoverer Plus ist realisiert als thick client java applet.
Discoverer Viewer, ein HTML-basierter thin
client, dem Standardzugang für die Endkunden der Berichte.
Discoverer Administrator ist zusammen mit
dem Oracle Warehouse Builder und Oracle Reports Teil der Oracle Developer Suite.
Discoverer Portlets erlauben es, Berichte
und Arbeitsmappen im Oracle Portal einzubinden. Alle webbasierten Anwendungen werden von den Discoverer Services,
der engine des Discoverers, koordiniert.
Aufgaben und Struktur der einzelnen
Komponenten: Discoverer Plus
Discoverer Plus ist die Realisierung des Discoverer Desktops als Java Anwendung und
stellt dessen Möglichkeiten komplett zur Verfügung. Darüber hinaus enthält er gegenüber
der alten Version einige neue Funktionen. Discoverer Plus ist das Standard-Werkzeug zum
Erzeugen von Berichten. Neue Funktionen werden in Zukunft hier implementiert.
Bei der grafischen Gestaltung bietet Discoverer Plus gegenüber dem Discoverer Desktop
erheblich mehr. Er nutzt, wie Oracle Reports
und Oracle BI Beans, die BI Beans Graphic
Beans. Plus ist als Java Anwendung realisiert
und wird als HTML-Seite über das Oracle
JInitiator PlugIn aufgerufen. Dadurch wird eine
Kommunikation zwischen dem Abfrage-Werkzeug, dem Application Server als middle tier
und der Oracle Datenbank hergestellt.
Abb. 1: Discoverer Desktop.
40
Ein Vorteil dieser Lösung ist, dass auf dem
Client-PC keine Software installiert sein muss.
(Achtung: beim ersten Aufruf ist unter Windows eine Installationsberechtigung nötig!)
Datenbanken
Allerdings benötigt der entsprechende PC etwas mehr Leistung als der Desktop als ClientServer Anwendung. Beim Arbeiten an komplexen Berichten ist der Desktop als für Windows konzipierte Anwendung etwas schneller als die Java Lösung Discoverer Plus. Auch
in der Druckausgabe hat der Desktop leichte
Vorteile.
Beim Erstellen von Arbeitsmappen, die Graphen enthalten, sollte, wenn als Frontend der
Viewer genutzt wird, immer Discoverer Plus
genutzt werden, da beide im Unterschied zum
Desktop mit den BI Beans Graphic Beans
arbeiten.
Bei der Darstellung von mit dem Desktop erstellten Graphen im Viewer kann es zu Unterschieden und Problemen kommen.
Discoverer Plus
Browser
Browser
Discoverer Viewer
HTML
Browser
Browser
Discoverer
Portlet Provider
OracleAS
HTML
Browser
Browser
Discoverer Services
Services
Discoverer
OracleDS
End User
Layer
Discoverer
Discoverer
Administrator
Administrator
Discoverer
Discoverer
Desktop
Desktop
Abb. 2: Komponenten und Aufbau des Oracle AS Discoverer.
Discoverer Viewer
Der Discoverer Viewer ist als thin client realisiert und wird wie Plus als HTML-Seite aufgerufen. Mit dem Viewer können die in Plus oder
Desktop erstellten Berichte aufgerufen und
eingesehen werden.
Die Berichte können auch in Form von Arbeitsmappen (siehe Abbildung 3) zur Verfügung gestellt werden. Mit dem Viewer können keine
Berichte erstellt oder bearbeitet werden, es
können aber Parameter hinzugefügt und ein
einfaches slice and dice der Daten des Reports durchgeführt werden. Die so veränderten Berichte können allerdings nicht abgespeichert werden.
Der Viewer stellt im täglichen Einsatz für die
meisten Endbenutzer den Standardzugriff auf
die Berichte dar. Plus wird denjenigen zur Verfügung gestellt, die Berichte für andere Benutzer erstellen. Wie bei Discoverer Plus wird
auch im Viewer beim Einsehen der Berichte
eine Verbindung zur Oracle Datenbank hergestellt, so dass im Bericht der jeweils aktuelle Datenbestand zu sehen ist.
In einer Preference-Datei können das Aussehen und der Funktionsumfang des Viewers auf
dem Oracle Application Server den Vorgaben
eines Unternehmens für das Intranet angepasst werden.
Über ein einfaches View hinaus bietet der
Viewer Funktionen, die eine flexible Analyse
der Daten erlauben und zum Teil in den operativen Bereich des Discoverer Desktops hineinreichen.
Die reine View-Aufgabe nehmen im Oracle
AS Discoverer die Discoverer Portlets wahr:
Abb. 3: Arbeitsmappe als HTML exportiert.
Discoverer Portlets und Application Server
Mit den Discoverer Portlets können Berichte, die mit Discoverer
Plus erstellt wurden, im Oracle Portal angeboten und aufgerufen
werden. Die Berichte übernehmen dabei das Aussehen, das in
Plus oder Viewer festgelegt wurde. In den Kreuztabellen kann aber
kein Drilldown durchgeführt werden. Der Bericht über die Portlets
hat wirklich View-Charakter.
Zusätzlich zu den Portlets, die die Arbeitsmappen repräsentieren,
gibt es auch ein Portlet, das die Liste der verfügbaren Arbeitsmappen für eine öffentliche oder für private Discoverer-Verbindungen
anzeigt.
Während Discoverer Plus und der Viewer bei jedem Aufruf einer
Arbeitsmappe die zu Grunde liegenden Daten aktualisieren, bieten die Arbeitmappen über die Portlets einen Snapshot, der zu
bestimmten, festzulegenden Zeiten aktualisiert wird. Es kann aber
ein Link eingepflegt werden, der die entsprechende Arbeitsmappe
im Viewer startet, wenn aktuelle Daten oder die Drilldown-Funktionen benötigt werden.
41
Datenbanken
Funktion
Desktop
PLUS
Viewer
Portlets
Berichte erstellen und
bearbeiten
9
9
8
8
Berichte mit aktuellem
Datenbestand einsehen
9
9
9
8
Berichte mit Snapshot
einsehen
8
8
8
9
Erweiterte graphische
Funktionen
8
9
9
9
Export zu MS Excel
9
9
9
8
Integriert in ORACLE
Single Sign-on
9
9
9
9
8
Bedingungen erstellen
9
9
8
Kalkulationen erstellen
9
9
8
8
Arbeitsmappe speichern
9
9
8
8
Unterstützung von
Unterabfragen
9
8
8
8
Suchen in der Tabelle
9
8
8
8
Alle Zeilen zählen
9
8
8
8
Formatieren der
Darstellung von
Ausnahmen
9
8
8
8
Abb. 4: Möglichkeiten der verschiedenen Komponenten.
Anwendungsbereiche
Mit dem Discoverer bietet Oracle ein User-Interface, mit dem, wenn die Metadaten für die
Datenbasis im EUL festgelegt sind, per click
and drop Berichte erstellt werden können
ähnlich wie Business Objects oder Actuate.
Dimensionen können flexibel hinzugefügt, Drilldowns sehr schnell erstellt werden. Die Berichte greifen im Viewer immer auf die Basisdaten
zu und bieten so immer ein aktuelles Bild. In
die Berichte können verschiedene mathematische und Datenbank-Funktionen eingebaut
werden. Durch die Metadaten im EUL wird die
Datenbasis abstrahiert. Dem Endbenutzer, der
die Berichte benötigt (z. B. den Fachabteilungen), wird sie in Form von selbsterklärenden
Objekten dargeboten, aus denen der Bericht
zusammengestellt werden kann.
Uwe Rübesamen ([email protected]).
ORDIX auf der Linux World Expo
ORDIX nahm in diesem Jahr das erste Mal als Aussteller auf der 5. Linux World Conference & Expo (26. - 28.
Oktober 2004) teil. Mit 14.600 Besuchern und ca. 150 Ausstellern und Mitausstellern hat sich die Linux World
Expo als Informationsplattform für IT Entscheider und Linux Spezialisten aus Industrie, Handel und dem
öffentlichen Sektor etabliert.
Auf der ORDIX Infoinsel auf dem Novell Stand hatten die LinuxBegeisterten die Möglichkeit, ihre individuellen Linux Themen zu
diskutieren. Dabei war das Themenspektrum weit gefächert: Von
Linux Hochverfügbarkeits-Cluster, Oracle für Linux über Nagios
und Serverkonsolidierung bis hin zu Testsystemen mit VMware.
Neben dem Austausch am Stand stellte ORDIX sein Know-how
auch in einem informativen Fachvortrag zur Verfügung:
Hochverfügbarkeit mit Open Source Software unter Linux
Referent Christof Amelunxen, Berater der ORDIX AG, Paderborn,
behandelte in seinem Vortrag Grundlagen der Hochverfügbarkeit
und der Clustertechnologie. Darüber hinaus beschrieb er deren
technische Umsetzung mit Open Source Software als Alternative
zu kommerziellen HV-Lösungen. Die rund 60 Zuhörer lauschten
gespannt den Topics des Vortrags:

Hochverfügbarkeit und Cluster allgemein
Datenintegrität im Cluster / Storageszenarien
Einsatz von DRBD - Distributed Replicated Block Device
Das Linux High Availability Project
Fallbeispiel / Projektbericht
Fragen / Diskussion
Sollten Sie den Vortrag verpasst oder weiterführendes Interesse
haben, schicken Sie einfach eine E-Mail an [email protected].
Wir helfen Ihnen gern!
42
Special-Highlight waren neben dem Vortrag
die beiden attraktiven Sonder-Pakete Suse
Linux Starter Package und Suse Linux OpenExchange ready-to-run. Mit der Sonderaktion
für Teilnehmer dieser Messe zeigte das ORDIX
Team Wege auf, wie man Linux mit professioneller Unterstützung kostengünstig und effektiv im Unternehmen zum Einsatz bringt.
Verschaffen auch Sie sich Einblicke in neueste
technologische Entwicklungen. Finden Sie Entscheidungshilfen für Investitionen in linuxbasierten IT-Strukturen. Sprechen Sie uns zum Einsatz von Open Source Software in Ihrem Unternehmen an: [email protected]
Aktuell
Einladung zum
META-DOK Testday
Das entstandene Know-how Ihrer Mitarbeiter sei es durch Projekttätigkeit oder durch die tägliche Arbeit
ist die Basis für den nachhaltigen Erfolg Ihres Unternehmens.
Aus diesem Grund ist ein Wissensmanagement heutzutage unerlässlich. Möchten auch Sie in Ihrem Unternehmen ein Dokumenten- und Informationsmanagementsystem einführen? Wir zeigen Ihnen anhand des
Produkts META-DOK, wie Sie viel Zeit und somit auch Kosten bei der sinnvollen Archivierung und Verwaltung von Informationen sparen können.
META-DOK Testday
Termin:
Dienstag, 22. Februar 2005
Beginn:
15:00 Uhr
Dauer:
ca. 3 Stunden
Ort:
ORDIX AG
Trainingszentrum
Kreuzberger Ring 13
D-65205 Wiesbaden
Die Aufgabe von META-DOK ist ...
Wissen und Informationen, die in Ihrem Unternehmen existieren und deren Erlangung teuer bezahlt wurde, zu strukturieren, zu verwalten, zu archivieren und allen Mitarbeitern oder
auch Ihren Kunden punktgenau zur Verfügung zu stellen.
Die Teilnahme ist kostenlos!
Wissen ist Wissen, wo was steht
Herzlich lädt Sie die ORDIX AG am Dienstag,
den 22. Februar zum META-DOK Testday ein.
Bei dieser Gelegenheit können Sie sich selbst
von den Stärken des Dokumenten- und Informationsmanagementsystems META-DOK
überzeugen.
Ihres Unternehmens systematisch verwalten, archivieren und für
Anfragen zur Verfügung stellen können.
In Kooperation mit unserem Partner METALEVEL stellen wir Ihnen eine umfassende Lösung zu den Themen Dokumenten-, Informations- und Wissensmanagement vor und
möchten Ihnen veranschaulichen, wie Ihre
interne Organisation von dieser Lösung profitieren kann.
Genießen Sie den Vorzug, sich im Rahmen des META-DOK Testdays von unseren Spezialisten beraten zu lassen und erarbeiten
Sie selbst am PC Ihr individuelles Szenario für die Umsetzung
eines Dokumenten- und Informationsmanagements in Ihrem Unternehmen.
Wir zeigen Ihnen, wie Sie mit Hilfe dieses integrierten Systems wesentliches Know-how
Wir freuen uns darauf, Sie bei uns zu begrüßen. Für einen kleinen Imbiss haben wir gesorgt!
Ihre Anmeldung
Anmeldungen an:
Die Teilnahme ist kostenlos. Bitte haben Sie
Verständnis, dass wir nur eine begrenzte Anzahl von Anmeldungen entgegennehmen
können. Versäumen Sie deshalb nicht, sich
rechtzeitig anzumelden.
E-Mail: [email protected]
Post: ORDIX AG, Westernmauer 12-16, 33098 Paderborn
zentrales Fax: 0 180 / 1 ORDIX 0
oder: 0 180 / 1 67349 0 mit dem Betreff Meta-Dok
online: http://www.ordix.de/metadok/
Anmeldeschluss: 18.02.2005
Der Rechtsweg ist ausgeschlossen.
43
Java/XML
Reihe Application Server im Vergleich (Teil II):
JBoss
Die Open Source Software JBoss startete 1999 als offener EJB-Container. Damals waren kommerzielle
Systeme im professionellen Umfeld die erste Wahl. Mittlerweile gehört JBoss jedoch weltweit zu den am
meisten verbreiteten J2EE Application Servern. Seit Juli 2004 ist JBoss gar von SUN für J2EE 1.4 zertifiziert
worden. In unserer Reihe zum Vergleich der Application Server darf er daher auf keinen Fall fehlen.
Plattform
Da JBoss in reinem Java implementiert ist, ist er ebenso plattformunabhängig wie Java selbst.
J2EE
JBoss ist der erste Open Source Application Server, der von Sun
für J2EE 1.4 zertifiziert wurde [1].
Ein Teil der unterstützten Standards kann der Abbildung 1 entnommen werden.
Von der Konkurrenz grenzt sich JBoss auch durch das von ihm
unterstützte neue Themenfeld der aspect orientation (AO) ab.
Es verspricht den Entwicklern stark vereinfachte Entwicklungsmodelle, ohne Service-Funktionen zu opfern. Im Kern geht es
darum, auf der Stufe von Application Servern, Java-Objekte dynamisch zur Laufzeit ohne zusätzliche Codierung um Funktionalitäten
anzureichern oder vorhandene Funktionalitäten zu ändern. Dies
können zum Beispiel Funktionen wie Clustering, Persistenz, Transaction, Security oder Distributed Cash sein. Diese und weitere
Speziﬁkation/
WebSphere 5
JBoss 4.0
Borland ES
BEA
Oracle
Standard
5.2.1
Weblogic
AS
(Stand 05/04)
(Stand 11/04)
Spezifikation/Standard WebSphere 5
JBoss 4.0 Borland ES BEA Weblogic Oracle AS
CORBA
X
v2.3.1
(Stand 05.2004)
EJB
v2.0
v2.1
CORBA
X
v2.3.1
IIOP EJB
X
durch CORBA
v2.0
v2.1
J2EE IIOP
v1.3
X
JAAS J2EE
v1.0
JAF
1.2
JAAS
JAXP JAF
JAXP
JAXR
JAXR
JAX-RPC
JAX-RPC
JCA
JCA
JCE JCE
v1.4
durch
v1.3
v1.0
v1.4
v1.0
v1.0
v1.0
1.1
38018
v1.2
v1.0
X
37987
v1.0
v1.2
1.0
v1.0
X
X
1.0
v1.0
X
v1.1
v1.5
v1.5
durch
J2SE
1.4
durch
J2SE
durch
J2SE
1.4
durch
J2SE
JDBC JDBC
v2.0
v2.0
JMS
JMS
v1.0
v1.0
v1.1
JMX
JMX
X
X
v1.2
JNDI
JNDI
X
X
v1.2.1
JSP
JSSE
JSP
JSSE
JTA
JTA
LDAP
LDAP RMI
RMI
SOAP
UDDI
X
v1.0
X
Java ServletsX
Java Mail
Java Servlets
SAAJ
Java Mail
SAAJ
v1.2
SOAP
UDDI
WSDL
X.509
v1.2
X
v1.0
X
X
v.2.3
v1.0
v1.1
v2.0
X
v1.1
v1.2
v1.2.1
v2.0
X
v1.0.1B
v1.0.1B
durch jndi
durch jndiX
X
v2.4
v2.4
v1.3
v.2.3
38018
1.2
37987
v1.3
v1.2
1.1
37987
v1.2
v1.1
1.1
2.0
2.0
1.0
v1.1
v2
v1.1
WSDL XML
X.509
X
durch JAAS
v1.1
X
durch JAAS
XML
X
X
1.0
X
v2
X
Abb. 1: Überblick über unterstützte Spezifikationen und Standards
bei WebSphere 5 und JBoss. Die anderen Application Server werden
in den nächsten Teilen dieser Reihe analysiert.
44
sogenannte Aspekte stellt JBoss 4.0 dem
Entwickler bereits zur Verfügung.
EJB Container und Bean Feature
Der von JBoss genutzte EJB-Container ist
kompatibel zum EJB Standard 2.1. Da die
JBoss Group im Java Community Process
(JCP) mitwirkt und im Rahmen einer Expertengruppe (JSR 220) an der Gestaltung der neuen EJB 3.0 Spezifikation mitwirkt, ist abzusehen, dass der JBoss Community neue EJBFeatures zeitnah bereitgestellt werden.
Webservices
JBoss implementiert mit dem J2EE 1.4 Standard auch die neuen J2EE Web Services.
Dem Entwickler ermöglicht dies z. B. über Firewallgrenzen hinweg über den normalen WebPort Remote-Procedure-Calls als XML-verpackte Nachrichten aufzurufen (JAX-RPC).
Die JBoss-Implementierung (JBossWS) basiert dabei auf dem ausgereiften Apache Axis
als unterliegendes web service framework.
System Management
Bei der Administration des Systems kommt
immer wieder der Grundgedanke der einfachen Handhabung ins Blickfeld.
Der JBoss-Entwickler muss sich keine Gedanken über RMI-Stubs und -Skeletons machen,
wenn er neue Komponenten verteilen will. Die
Komponenten-Archive müssen lediglich in das
passende Deploy-Verzeichnis des laufenden
JBoss kopiert werden und schon ist die jeweilige EJB zugreifbar. Intern wird dies möglich,
da von Anfang an Features wie dynamische
Proxies und Hot Deploy/Hot Redeploy in den
Application Server integriert wurden.
Der Microkernel von JBoss ist auf dem J2EEStandard zum Management verteilter JavaApplikationen aufgebaut (JMX). Somit können
alle Komponenten von der eigenen EJB bis
zum Verhalten im Cluster über eine einheitliche Schnittstelle gesteuert werden. Einheitliche Standards wie SNMP, WBEM oder HTTP
erleichtern die Steuerung. JBoss entspricht
Java/XML
dabei auch den Anforderungen einer Serviceorientierten Architektur (SOA). Als Beispiel für
deren Akzeptanz sei erwähnt, dass Novell
seinen internen Application Server in seinen
Portallösungen ab 2005 komplett durch JBoss
ablösen will.
Link
[1] http://www.jboss.org/services/press/j2eecertfinal.pdf
[2] http://www.jboss.com/partners/jbossinside
Verfügbarkeit und Skalierung
Im Cluster lässt sich jedes Java-Objekt ausfallsicher und lastverteilt verwalten. Neben
EJBs, JMS und HTTP lassen sich sämtliche
Arten von Java-Objekten verwalten so auch
die guten alten POJOs (Plain Old Java Objects). Besondere Features sind auch die automatische Erkennung von neuen Knoten im
Cluster, oder farming bzw. distributed Deployment von JBoss-Komponenten.
Lizenzen
JBoss fällt unter die GNU Lesser General Public License (LGPL). Somit fallen für den Anwender keinerlei Lizenzkosten zur Nutzung
des Produkts an. Die JBoss Group, die das
Produkt vertreibt, erwirtschaftet ihre Umsätze
durch kommerzielles Coaching und Consulting Mailinglisten und Foren sind die preiswerte Alternative. Die Handbücher zum Server sind mit weniger als 10 $ kostenpflichtig.
Eine gute Onlinedokumentation und Tutorials erleichtern jedoch
den schnellen Einstieg. Der Support wird durch eine stetig wachsende Schar an JBoss Authorized Service Partner-Firmen ständig erweitert. Mehr als 100.000 Downloads verzeichnet die JBoss
Group jeden Monat.
Fazit
Mit dem JBoss 4.0 ist neben Linux und Apache ein weiteres Beispiel für eine gute Open Source-Alternative erwachsen. Kein anderer Application Server hat eine ähnlich hohe Zuwachsrate, gemessen an der Zahl der Produktivinstallationen. Wer sich dafür
interessiert, in welchen kommerziellen Produkten JBoss mit Erfolg eingesetzt wird, sei auf die JBoss-Webseite [2] verwiesen.
Bevor Sie die Entscheidung für einen Application Server treffen,
sollten Sie sich den JBoss einmal näher anschauen.
Lesen Sie als Entscheidungshilfe auch die nächsten Teile unserer Reihe. Wir werden uns mit Borland ES, BEA Weblogic und
natürlich auch mit dem Oracle AS beschäftigen, dessen Bedeutung in den letzten Monaten erheblich zugenommen hat.
Holger Bartnick ([email protected]).
Impressum
Herausgeber:
ORDIX AG
Aktiengesellschaft für
Softwareentwicklung, Beratung,
Schulung und Systemintegration,
Paderborn
Redaktion:
Helma Jenniches, Sascia Brinkmann
V.i.S.d.P.:
Wolfgang Kögler
Anschrift der Redaktion:
Westernmauer 12 - 16
D-33098 Paderborn
Tel.: 0 52 51 / 10 63 - 0
Fax: 0 180 / 1 ORDIX 0
oder: 0 180 / 1 67349 0
Gestaltung/Layout:
Sascia Brinkmann
Druck:
Druckerei Reike GmbH, Paderborn
Autoren dieser Ausgabe:
Christof Amelunxen, Dr. Hubert Austermeier,
Holger Bartnick, Christoph Borowski, Holger
Demuth, Stefanie Heither, Irina Hochhalter,
Martin Hoermann, Ulrike Kögler, Wolfgang
Kögler, Lars Hendrik Korte, Andreas Kother,
Michael Lindermann, Uwe Rübesamen, Antonio Salguero, Guido Saxler, Markus Schreier
Copyright:
ORDIX AG. Alle Rechte vorbehalten. Die Zeitschrift ORDIX News hat
eine Auflage von 8.800 Exemplaren. Sie wird von der ORDIX AG an
ausgesuchte Kunden verteilt und kann für 2,20 Euro bestellt werden.
Außerdem finden Sie sowohl die neueste Ausgabe als auch ältere Ausgaben im Archiv der ORDIX News im Internet unter: http://www.ordix.de.
Schauen Sie mal rein!
Der Kontakt zu unseren Lesern ist uns sehr wichtig. Für Anregungen,
Kritik und Anmerkungen zu den Themen, aber auch für interessante
Ideen sind wir immer offen und dankbar. Sie erreichen die Redaktion
auch per E-Mail unter [email protected].
Wir freuen uns auf Ihr Feedback.
45
Datenbanken
Oracle 10g RAC 380V
Ursprünglich sollte die Kampagne zur Einführung von Oracle 10g etwa wie folgt lauten: Oracle Grid so
sicher wie das Stromnetz. Nach den großen Zusammenbrüchen des Stromnetzes in den USA kurz vor der
Kampagne besann sich das Marketing auf eine andere Strategie. Sicher wie das Netz? Wir stellen Ihnen heute
einen Erfahrungsbericht von Oracle 10g RAC auf Linux vor.
Warum eigentlich RAC
Bevor die Entscheidung für oder gegen RAC fällt, sollte das Projektteam detailliert die Vorteile und die Kosten gegeneinander abwägen. Zweimal 220 Volt gibt auch bei Oracle 380 Volt, aber ob Ihre
Applikation tatsächlich einem Starkstromaggregat gleicht oder doch
einem normalen Elektromotor ähnelt, dessen Spulen bei 380 Volt
verglühen, bedarf in der Regel einer detaillierten Analyse.
Bei diesem Artikel steht die Technologie zum Einsatz von 10g auf
Linux im Mittelpunkt. Schritt für Schritt erläutern wir das Vorgehen
zum erfolgreichen Einsatz von RAC. Änderungen zu Oracle 9i
erläutern wir an gegebener Stelle.
Hardware, Betriebssystem und Oracle
Wie auch bei allen anderen Versionen, läuft 10g nur auf zertifizierten Systemen. Aufgrund der besonderen Komplexität stehen
allerdings bei weitem nicht so viele Plattformen wie etwa für Single Instance Systeme zur Verfügung. Bis Ende Oktober konnte 10g
unter Linux nur auf Redhat 2.1 Enterprise Server installiert werden. Inzwischen hat aber auch Suse Linux die Zertifizierung durchlaufen. De Facto stehen also bisher magere zwei zertifizierte
Linux Systeme zur Verfügung. Die jeweils aktuelle Zertifizierungsmatrix finden Sie unter [1].
Wie üblich bei RAC ist ein Interconnect zwischen den beiden Servern notwendig, um mittels Cache Fusion Datenblöcke und andere Ressourcen zwischen den Instanzen auszutauschen. Mit 10g
steht nun erstmalig auch die Zertifizierung von
Infiniband einer vielversprechenden Technologie an.
Ebenfalls eine Neuerung: Mit 10g steht RAC
auch in der Standard Edition zur Verfügung,
sogar ohne Aufpreis. Allerdings werden dabei
nur maximal vier Prozessoren im gesamten
Cluster zugelassen.
Voraussetzungen
Zur knotenübergreifenden Installation von
RAC setzt Oracle eine konfigurierte Secure
Shell (ssh) voraus. Abbildung 2 zeigt die hierzu
notwendigen Schritte. Die erzeugten Dateien
(authorized_keys) müssen gegenseitig auf
jedem Knoten ins Verzeichnis ~oracle/.ssh
kopiert werden, damit der sichere, gegenseitige Zugriff ohne Passwort möglich ist. Zur
Überprüfung kann man z. B. das Kommando
ssh <knoten1> date auf dem Knoten 2
ausführen, was erfolgreich ohne Ausgabe eines Passwortes laufen muss. Genauso aber
auch umgekehrt.
Kernel Parameter
Zum reibungslosen Betrieb der Datenbank ist
die Anpassung zahlreicher Kernelparameter
notwendig. Die wichtigsten sind in Abbildung
3 aufgeführt. Mit dem Linux Befehl sysctl w
(RedHat) können die Kernelparameter dynamisch geändert werden.
In der Datei /etc/sysctl.conf müssen die
o. a. Parameter eingetragen werden. Dieses
bewirkt bei jedem Reboot ein erneutes Setzen der entsprechenden Parameter.
Insbesondere falsch konfigurierte UDP Parameter können die Performance des RAC Systems dramatisch beeinflussen, ähnlich etwa
wie die Sichtverhältnisse in einem geschlossenen Raum mit einer Leuchtstoffröhre von
180 Volt.
Raw Device versus Cluster Filesystem
Abb. 1: Beispiel einer Oracle 10g RAC Architektur.
46
Auf die Oracle Datenbankdateien Online
Redo Log Files, Control Files und Data Files
muss der konkurrierende Zugriff von jeder
Instanz, also von jedem Knoten, möglich sein.
Datenbanken
Hierzu muss ein zentraler Speicher, z. B. SAN,
zur Verfügung stehen, auf dem prinzipiell folgende Zugriffsmöglichkeiten bestehen:
cd ~oracle
mkdir .ssh
chmod 700 .ssh
ssh-keygen t rsa
ssh-keygen d dsa
cat id_rsa.pub >>authorized_keys
cat id_dsa.pub >>authorized_keys
Abb. 2: Konfiguration Secure Shell (ssh) auf
beteiligten Cluster-Nodes.
# Disables packet forwarding
net.ipv4.ip_forward = 0
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1
# Disables the magic-sysrq key
kernel.sysrq = 0
# ORACLE RAC
kernel.shmmax= 3000000000
kernel.shmmni= 4096
kernel.sem= 250 32000 100 128
net.ipv4.ip_local_port_range=1024 65000
# UDP Kernelparameter Paket Größe
net.core.rmem_max = 262144
net.core.wmem_max = 262144
net.core.rmem_default = 262144
net.core.wmem_default = 262144
Abb. 3: Oracle 10g RAC Kernel-Parameter für
Linux.
à RAW Devices
à Verwendung eines Logical Volume
Managers (LVM)
à Oracle Cluster Filesystem (OCFS)
Unter Linux (Redhat 2.1 Enterprise Server) bleibt zunächst nur
die Möglichkeit der Verwendung des OCFS oder des ASM (Automated Storage Management), da mit fdisk nur maximal 15 separate Partitionen (SCSI) angelegt werden können und zur Zeit
auch die Unterstützung eines LVM nicht gegeben ist.
Die Installation des OCFS gestaltet sich recht einfach. Die notwendigen RPM Pakete stehen unter [2] für die entsprechenden
Linux- und Hardware-Plattformen zur Verfügung. Mit dem Werkzeug ocfstool lässt sich das OCFS konfigurieren (siehe Abbildung 4). Des Weiteren kann man u. a. über ocfstool die Oracle
Cluster Filesysteme mounten beziehungsweise unmounten.
Cluster Ready Service
Der Oracle Cluster Ready Service (CRS) ist die eigentliche Clusterware. Als Oberbegriff enthält dieser Dienst verschiedene Funktionalitäten. Hierzu gehören unter anderem die schon in 9i bekannten Dienste Global Service Daemon (GSD) und Oracle Cluster
Manager.
Neu ist, dass Oracle mit dem CRS auch eine Clusterware für alle
zertifizierten Plattformen liefert und sich hiermit unabhängig von
proprietären Cluster Diensten (Service Guard, HACMP, RMS usw.)
macht. Wird eine proprietäre Cluster Software verwendet, so kann
diese optional auch verwendet werden.
Das Starten des CRS wird durch die inittab initiiert, das Herunterfahren durch ein entsprechendes rc-Skript.
Oracle Installation und Anlegen der Datenbank
Die weiteren Schritte erfolgen nahezu identisch wie schon unter
Oracle 9i. Die Oracle Software wird mit der RAC Option installiert.
Anschließend erfolgt die Konfiguration und Installation der Datenbank mit der entsprechenden Berücksichtigung von RAC.
Fazit
Wie schon unter Oracle 9i besteht die größte Herausforderung in
der sorgfältigen Umsetzung der zahlreichen Installationsschritte.
Vorab ist die gesamte Hard- und Softwarekonfiguration mit der
Kompatibilitätsmatrix zu überprüfen. Die Dokumentation lässt an
einigen Stellen Wünsche offen. Insbesondere der neue Komplex
Cluster Ready Service ist nur sehr spärlich beschrieben.
Abb. 4: OCFS-Tool zur Konfiguration des Oracle
Cluster Filesystems.
Beim Hantieren mit Starkstrom empfehlen wir eine gute Ausbildung. Besuchen Sie unsere RAC Schulung, damit Ihre Motoren
mit 380 Volt ihre volle Leistung entfalten. Infos zu dem Seminar
finden Sie in unserem Trainingsshop unter http://training.ordix.de.
Link
[1] http://metalink.oracle.com
[2] http://otn.oracle.com
Martin Hoermann, Guido Saxler ([email protected]).
47