ORDIX News Kosten senken mit VMware Tanz den REORG System
Werbung
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 Unix/Linux/Open Source 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. Unix/Linux/Open Source 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ü- Unix/Linux/Open Source 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)); intList.add(new Integer(2)); intList.add(new Integer(3)); 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>(); intList.add(new Integer(1)); intList.add(new Integer(2)); intList.add(new Integer(3)); Integer value; for (Iterator<Integer> it = intList.iterator(); it.hasNext();) { // Zuweisung ohne einen Cast value = it.next(); System.out.println("value: " + value); } Abb. 1: Vergleich der Verwendung einer ArrayList und eines Iterators vor (oben) und nach der Spracherweiterung (unten). List<Integer> intList = new ArrayList<Integer>(); intList.add(new Integer(1)); intList.add(new Integer(2)); intList.add(new Integer(3)); // for-Schleife mit Laufindex for (int i = 0; i<intList.size(); i++) { Integer value = (Integer)intList.get(i); System.out.println("value: " + value); } // for-Schleife mit Iterator for (Iterator it = intList.iterator(); it.hasNext();) { Integer value = (Integer)it.next(); System.out.println("value: " + value); } List<Integer> intList = new ArrayList<Integer>(); intList.add(new Integer(1)); intList.add(new Integer(2)); intList.add(new Integer(3)); for (Integer value : intList) { System.out.println("value: " + value); } 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(); intList.add(new Integer(1)); intList.add(new Integer(2)); intList.add(new Integer(3)); List tmpIntList = new ArrayList(); for (Iterator it = intList.iterator(); it.hasNext();) { Integer value = (Integer)it.next(); int i = value.intValue(); tmpIntList.add(new Integer(i + 1)); } List<Integer> intList = new ArrayList<Integer>(); 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 Spezifikation/ 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
