ORDIX News
Werbung
www.ordix.de ORDIX News Das IT-Magazin der ORDIX AG Ausgabe 2/2006 € 2,20 Der Oracle SQL Developer ist da! Vererbung mit Hibernate S. 18 IBM IDS 10.0 Neuheiten (Teil II) Abbildung von Objekthierarchien S. 42 Neuerungen im Bereich Backup & Recovery S. 37 ITIL – Eine Oase in der Servicewüste JavaServer Faces Teil II beschäftigt sich mit den taktischen bzw. planerischen Prozessen von ITIL S. 21 Einführung in die richtungsweisende Programmierung von Web-Oberflächen S. 8 Editorial Paderborn, Juni 2006 Mit Sicherheit Sicherheit Bisher habe ich es mir verkniffen, an dieser Stelle etwas zum Thema WM zu schreiben. Man tritt dabei ja zu schnell in Fettnäpfchen. Als ich aber von dem „Sicherheitstreffen“ zwischen Schäuble, Ballmer und Ricke las, konnte ich nicht anders. Hier meine ganz private Meinung zum Thema WM und Sicherheit ☺. Im Vorfeld möchte ich mitteilen, dass ich in meiner Jugend selbst gerne und viel Fußball gespielt habe, aber mit diesem Thema dann 1982 abgeschlossen habe. Nicht wegen des erbärmlichen Gekickes zwischen Deutschland und Österreich, auch der deutsch-österreichische Nicht-Angriffs-Pakt genannt. Nein, mir reichte schon der Vorläufer Deutschland gegen Algerien. Seitdem habe ich festgestellt, dass alle interessanten Szenen eines Fußballspiels problemlos in die 90-Sekunden-Berichte der Tagesschau passen. Und seither habe ich auch kein einziges Fußballspiel mehr in voller Länge angesehen. Die gesparte Zeit konnte ich durchaus nutzbringend verwenden – soviel als Nachtrag zum Thema „Sparen“ aus dem letzten Editorial. Jetzt zu den Sicherheitsweltmeistern Schäuble und Ballmer: Ballmer könnte mindestens genauso viel über Sicherheitslücken erzählen, wie der Trainer des 1. FC Köln nach dem Spiel gegen Bremen (0:6) über Lücken in der Abwehr. Beide, Ballmer und der Kölner Trainer Latour, weisen dies jedoch weit von sich. Und Schäuble ist derjenige Politiker, der noch nicht einmal mit Sicherheit sagen konnte, ob und wieviel Geld er in Koffern oder Umschlägen erhalten hat. Zumindest behaupteten andere, dass er das nicht sagen konnte. Damit die WM sicher wird (aha!), wollte Schäuble mal schnell das Grundgesetz ändern. Das geht Gott sei Dank nicht ganz so leicht, wie ein neues Sicherheitsloch bei Microsoft zu entdecken. Aber erstaunlich ist es schon, dass man für die ordnungsgemäße Durchführung von Fußballspielen neben mehreren Hundertschaften von Polizisten jetzt auch noch die Bundeswehr, deren ursprüngliche Aufgabe die Verteidigung der bundesdeutschen Grenzen war, benötigt. Das lässt zwei Schlüsse zu: Entweder die deutsche Verteidigung ist so löchrig oder die WM stellt einen Notstand dar. Ich hoffe nicht, dass der ausgerufen wird, wenn Horden von Hooligans mit den SICHERHEITskräften ihre Scharmützel austragen. Obwohl sie das leider mit ziemlicher Sicherheit tun werden (siehe Frankreich 1998). Hoffentlich bleibt die WM auch die einzige Auseinandersetzung mit dem Iran und die Amerikaner wollen keine späte Revanche für die Niederlage von 1998. Bei der WM würde das frühestens im Halbfinale passieren, was ich für sehr unwahrscheinlich halte. Allerdings hat mein absoluter Lieblingspolitiker, George W. Bush, jetzt ja eine neue Freundin, mit der er/man Hand in Hand gegen den Iran vorgehen will. – Wie immer bei den Amerikanern: Notfalls auch ohne die UN. Weltpolitik wird im Übrigen demnächst in Stralsund gemacht. Also Achtung: Die Gullideckel werden wieder festgeschweißt und Mülltonnen vorübergehend als gefährliches Gut beschlagnahmt. Wir wissen ja schon aus dem Editorial 1/2005: Georgie ist sehr auf Sicherheit bedacht. Bei uns gibt es natürlich auch was zum Thema Sicherheit zu lesen: Neue Backup und Recovery Features bei Informix und höhere Sicherheit (Verfügbarkeit) durch RMAN (Convert Database). Den Bezug zu JavaServer Faces (JSF) bekomme ich nur darüber hin, dass JSF mit Sicherheit eines der kommenden Themen in Bezug auf neue Java Technologien ist ☺. Interessant, auch wenn sie weniger mit Sicherheit zu tun haben, sind ebenfalls die Themen Hibernate (wir erläutern ein weiteres Feature bezüglich Vererbung), die Fortsetzung der ITIL-Artikelreihe und einige Neuigkeiten rund um Oracle (Behandlung von Large Objects, SQL Developer, Web-Services im Zusammenspiel mit PL/SQL). Ich wünsche Ihnen eine entspannte WM-Zeit. Hoffentlich tappen Sie in keine Sicherheitskontrolle. Und wenn Sie Karteninhaber sind, sind Sie ja auch schon sicherheitsüberprüft. Wolfgang Kögler PS: Letzte Verbindung zu einem Editorial (3/2003): In Paderborn Elsen fiel am 12.5. der Strom für etwa eine halbe Stunde aus. Also Sorry USA! – Oder war das ein gezielter Anschlag der Familienministerin, der sogenannte von der Leyensche Blackout, um endlich einen Baby-Boom zu erzeugen? ORDIX News 2/2006 Inhaltsverzeichnis Standards Training 02 ....Editorial 03 ....Inhalt 41 ....Impressum 24 ....Seminarübersicht: Juni bis Dezember 2006 Aktuell Java/XML Titel- 21 ....Larry Ratlos: System Monitoring 29 ....Chess Classic 2006: Hol dir den Titel! Gewinnen Sie eine Teilnahme am weltgrößten Schnellschachturnier und mehr. 44 ....Rätsel zum Relaunch von www.ordix.de thema 08 ....JavaServer Faces Einführung in die Grundlagen der JavaServer Faces, die als die kommende Alternative für die Programmierung von WebOberflächen bezeichnet werden. Titel- thema 42 ....Vererbung mit Hibernate Hibernate ist ein Framework zur Speicherung von Daten. Wir beschäftigen uns mit der Abbildung von Objekthierarchien (Stichwort Vererbung) in einer relationalen Datenbank mit Hilfe von Hibernate. Datenbanken 04 ....Information Sharing mit Oracle Streams Die Verwendung von Daten in einer verteilten Oracle-Umgebung wurde bisher meist mit Hilfe der Replikation durchgeführt. Ein mächtigeres Werkzeug ist Oracle Streams. Insbesondere mit der Version 10g wurde die Handhabung erleichtert. 34 ....PL/SQL Web-Services (Teil II) Vorstellung mehrerer Alternativen, wie mit PL/SQL Web-Services aufgerufen werden können. Zur Verdeutlichung zeigen wir entsprechende Beispiele. 14 ....LOB - Oracle Large Object Die Verwendung von Large Objects in Anwendungen nimmt stetig zu. Wir stellen die Oracle LOB und einzelne Funktionen des Pakets DBMS_LOB vor. 37 ....IBM Informix Dynamic Server 10.0 Neuheiten (Teil II): thema Das Administrieren wird einfacher für den Informix DBA Dieser Artikel beschreibt Neuerungen für den IDS im Bereich Backup & Recovery. Verwendung und Umgang mit den neuen Features werden anhand von Beispielen erklärt. Titela 18 ....Der Oracle SQL Developer ist da! them Erste Erfahrungen beim Einsatz des neuen SQL Developers in der Entwicklung. Unix/Linux/Open Source 30 ....100 % MySQL – Wie richte ich ein Cluster ein? Beschreibung der Möglichkeiten des Clustering unter MySQL und die exemplarische Installation und Konfiguration eines MySQL-Clusters. ORDIX News 2/2006 26 ....Neues bei Oracle 10gR2 (Teil III): RMAN Convert Database Überblick über die RMAN-Funktionalität, eine Datenbank von einer Plattform auf eine andere zu konvertieren. Titel- 45 ....Oracle unter Mac OS X Der Artikel zeigt die Installation von Oracle 10g Release 1 auf Mac OS X. Projektmanagement Titel- 22 ....ITIL – Eine Oase in der Servicewüste (Teil II) thema In der letzten Ausgabe behandelten wir den Themenkomplex „Service-Support“. In diesem Teil beschäftigen wir uns mit den taktischen Prozessen von ITIL. 40 ....Projektmanagement Coaching: Lernen ohne zu scheitern! Projektmanagement (PM) ist eine Kompetenz, die auf Erfahrung beruht. Damit der Lernprozess nicht durch gescheiterte Projekte zu teuer wird, empfiehlt es sich, PM-Coaching als Instrument einzusetzen. 3 Unix/Linux/Open Source – Titelthema MySQL 5 Datenbanken Information Sharing mit Oracle Streams Das neue Verfahren des Information Sharing beruht auf Advanced Queuing und ermöglicht die Weitergabe von Informationen, Transaktionsdaten und Events innerhalb eines einzigen Datenstroms. Mit der Version Oracle 10g wurden die Funktionalitäten von Oracle Streams erweitert und damit vereinfacht. Der Artikel richtet sich an Datenbankentwickler und -administratoren, die Daten aus verschiedenen Datenbanken nutzen bzw. den Zugriff verwalten müssen. Datenbanksysteme sind darauf ausgelegt, Informationen für andere Datenbanken und Anwendungen zugänglich zu machen. Ora­ cle bietet ab Oracle9i Version 2 ein neues Verfahren des Information Sharing an: Oracle Streams. Datenweitergabe innerhalb eines Datenstroms Oracle Streams ermöglicht die Weitergabe von Informationen, Transaktionsdaten und Events innerhalb eines einzigen Datenstroms. Dieser Datenstrom kann in der gleichen Datenbank genutzt werden oder von einer Datenbank an andere Datenbanken weitergeleitet werden. Streams werden beispielsweise zur Replikation von Daten, zum Message Queuing und Message Management, zum Laden von aufbereiteten Daten in ein Data Warehouse, zum Versenden von datenbankinternen Informationen an Datenbankadministratoren und zur Datensicherung im Bereich von Hochverfügbarkeitslösungen eingesetzt. Das Konzept von Oracle Streams beruht auf Advanced Queuing (AQ). In der Version 10g wurden die Funktionalitäten von Oracle Streams erweitert und damit vereinfacht. Mit der Version 10g und dem damit beabsichtigten Grid Computing bekommt Oracle eine noch größere Bedeutung. Streams sind in der Enterprise Edition enthalten. DB C DB B Datenfluss DB A Datenfluss DML + DDL Datenfluss DML + DDL Abb. 1: Beispiel einer Architektur zur Nutzung von Oracle Streams. Capture Staging Abb. 2: Die Prozesse von Oracle Streams. Consumption Abbildung 1 zeigt das Beispiel einer Architektur zur Nutzung von Oracle Streams. Komponenten von Oracle Streams Die drei grundlegenden Komponenten für Ora­ cle Streams sind Capture, Staging und Consumption (Apply), siehe Abbildung 2. Die Anwendungen stellen mittels dieser Elemente Informationen in einen Stream. Es kann sich dabei um beliebige Informationen handeln, die durch den Aufruf mitgelieferter Prozeduren lediglich in ein vorgegebenes Format gebracht werden. Automatisierung über den LogMiner-Mechanismus Handelt es sich um Informationen, die durch DML-Befehle (Änderung des Datenbestands) oder DDL-Befehle (Änderung der Datenstruktur) entstehen, ist dieser Vorgang sogar nahezu vollständig automatisiert. Er erfolgt per Zugriff auf die Redo Log Dateien (Protokolldateien der Datenbank) durch den LogMinerMechanismus, ohne die Datenbank dabei zu belasten. Der Fluss sämtlicher Daten von Anwendung zu Anwendung und von Knoten zu Knoten ist dann vollständig zu steuern. Selbstverständlich können die Daten des Informationsflusses an jeder Stelle bearbeitet oder transformiert werden. Ebenfalls ist jederzeit kontrollierbar, wer Zugriff auf die Informationen hat und wann die Daten des Datenstroms schließlich gelöscht werden. Der Capture-Prozess (siehe Abbildung 3) kann eine ganze Datenbank, ein Schema sowie eine oder mehrere Tabellen betreffen. Die erfassten Events werden in die Queue/Staging Area geschrieben. Das log-basierte Change Capture erzeugt nur geringen Overhead. Zwischengespeichert werden die Daten in der System Global Area (SGA). Seit Version 10 gibt es einen Bereich ORDIX News 2/2006 Datenbanken Capture Process LCRs Capture Changes Redo Log Log Changes Queue ---------------------------LCR LCR User Message User Message LCR User Message LCR LCR . . . Database Objects Source Queue ---------------------------LCR User Message LCR LCR LCR User Message . . . Propagate Events Destination Queue ---------------------------User Message LCR User Message LCR LCR . . . Abb. 4: Propagation. LCRs or Messages Queue Apply ----------------------Process LCR LCR Apply Messages Row User Message Changes LCRs User Message LCR Message DML User Message Handler Handler LCR Procedure Procedure LCR DDR . LCRs . . DDL Handler Database Objects Procedure User Changes Abb. 3: Capture-Prozess. der SGA für Streams. Dieser wird durch den init.ora Parameter streams_pool_size konfiguriert. Messages or LCRs Precommit Handler Procedure Abb. 5: Apply. Staging Area Die Staging Area ist als Queue implementiert. Staging basiert auf einem Datenbank-Job. Die Daten werden in Logical Change Records (LCR) in den Datentyp SYS.Anydata gepackt. Verarbeitet werden alle gültigen LCRs, falls sie nicht durch ein Ruleset (siehe „Transformation und Regeln“) ausgefiltert werden und sie nicht schon verarbeitet wurden. Erkennbar ist dies durch ein Tag im LCR. Dabei werden alle SQL-Befehle in der richtigen Reihenfolge verarbeitet. DML-Handler können die eigentliche Verarbeitung übernehmen. LCRs können vor der Verarbeitung oder Weiterleitung verändert werden (Transformation). Eventuell werden LCRs auch nur weitergeleitet. Ein Propagate-Prozess verarbeitet die vom Capture-Prozess eingestellten Events und die über AQ/Streams eingestellten Meldungen. Mit DB-Jobs wird der Inhalt der Queue der Quelldatenbank in die Queue der Zieldatenbank übertragen (siehe Abbildung 4). Die Steuerung der Daten erfolgt über ein Regelwerk oder PL/SQL-Handler. Andere Staging Areas können Events anfordern. Events können über mehrere Staging Areas geroutet werden: ORDIX News 2/2006 • Alle Events, LCRs und benutzerdefinierte Messages können in eine Queue übertragen werden. • Events bleiben so lange in der Staging Queue, bis sie durch alle interessierten Prozesse und Applikationen konsumiert sind. • Queues können angelegt, verändert, gestartet, gestoppt und gelöscht werden. • Falls ein Event einen Konflikt erzeugt, so kommt es zu einer • • Konfliktlösung oder der Event wird alternativ in eine Excep­tion Queue gestellt. Die Staging Area benötigt Speicherplatz in der SGA im Streams Pool. Queues werden in DB-Tabellen gespeichert. Ein Apply Prozess verarbeitet alles, was die Propagate-Prozesse in seine Queue einstellen. Z. B. ein Ausführen der Aktion (DDL oder DML) in oder an einer lokalen Oracle Tabelle oder das Ausführen der Aktion über einen DB-Link. Apply-Prozesse können pa­ rallel arbeiten. Dazu dienen die verschiedenen Handler (siehe Abbildung 5). Konflikte können erkannt werden und werden in spe­ ziellen (Exception-)Queues gehalten. Transformation und Regeln Mit Oracle Streams können Transformationen (siehe Abbildung 6) und Evaluierungen von Regeln vorgenommen werden. Das gilt für Einträge, • die in die Queue gemacht werden • die aus der Queue ausgelesen werden • die von Queue zu Queue propagiert werden Dazu gehören ebenfalls Änderungen des Spaltentyps, der Formatierung oder der Tabellen- oder Spaltennamen. Datenbanken Dequeue Events Queue ----------------------____________ ____________ ____________ ____________ ____________ ____________ Transformation During Dequeue Continue Dequeue of Transformed Events Send Transformed Events to Apply Handlers Apply Process Apply Handlers Apply Transformed Events Directly Vorteile von Streams Database Objects Abb. 6: Transformation beim Apply. Non-Oracle Database Non-Oracle Database Oracle Database Queue ----------------_________ _________ _________ _________ Dequeue Events Heterogenous Services Apply Changes Apply Process Database Objects Oracle Transparent Gateway Abb. 7: Heterogene Systeme. dba_propagation Informationen über Propagation (Quell- und Ziel-Queues, Regelsets, DB-Link, ...) dba_apply Informationen zu Apply (Queue, Regel­sets, Handler, Status, ...) dba_capture Informationen zu Capture (Queue, Regelsets, SCN, Source-DB, ...) V$streams_capture Statistische Informa­tionen über Capture V$streams_apply_reader Statistische Informa­tionen über Apply Abb. 8: Views im Data Dictionary. Als Regel wird ein Datenbank-Objekt bezeichnet, das für einen Client entscheidet, ob ein Event eine Aktion auslöst. Diese Regel muss formal stets in einem Regelset enthalten sein und besteht aus einer Bedingung, die wiederum über eine Rule Engine ausgewertet wird. Eine Bedingung kombiniert einen oder mehrere Ausdrücke und Operatoren. Sie gibt als Bool’schen Wert True, False oder Null zurück. Der Client ruft das Package dbms_rule auf. Die Administration der Regeln erfolgt über das Package dbms_rule_adm. Automatische Konflikterkennung Es erfolgt eine automatische Konflikterkennung mit wählbaren Routinen zur Konfliktlösung. Dazu kann der niedrigste oder der höchste Wert, der älteste oder der jüngste Wert oder auch ein neuer Wert als endgültiger Wert festgelegt werden. Zur Konfliktlösung wird der aktuelle Wert am Bestimmungsort mit dem alten Wert der veränderten Zeile am Quellort verglichen. Sind beide Werte identisch, so werden die neuen Werte übernommen. Sind sie es nicht, dann wird die Konfliktlösungsroutine aufgerufen. Ist der Konflikt nicht lösbar, kommt der LCR in die Exception Queue. Durch den Einsatz von Streams kann eine Replikation einfach in beide Richtungen definiert werden. Es gibt vordefinierte Konfliktlösungsroutinen für Updates (Minimum, Maximum, Over­ write, Discard). Mit Streams kann auch in Nicht-Oracle-Datenbanken repliziert werden (siehe Abbildung 7). Der umgekehrte und viel wichtigere Weg, aus Nicht-Oracle-Datenbanken in Oracle-Datenbanken zu replizieren, funktioniert auch. Verwaltung von Streams Streams können über den Oracle Enterprise Manager überwacht und administriert werden. Man kann allerdings auch mit SQL die in Abbildung 8 erläuterten Views aus dem Data Dictionary ab­fragen. Des Weiteren gibt es eine Reihe von Hintergrundprozessen für die Verarbeitung der folgenden Events: • • • • a0xx => apply q0xx => Datenbank_Jobs p0xx => propagation cjqxx => capture Voraussetzungen für Streams Die in Abbildung 9 vorgestellten init.oraParameter sind für den Einsatz von Streams von Bedeutung. Weitergehende Erläuterungen können gegebenenfalls der Literatur entnommen werden. Eine weitere Voraussetzung ist die Einstellung des „Supplemental Logging“ auf Datenbankoder Tabellen-Ebene. Dies sorgt für die Übermittlung eines Identifikationsschlüssels und für weitere zusätzliche Spalteninformationen. Grundsätzlich sollten alle Tabellen über einen Primary Key verfügen. Über den Streams Administrator werden administrative Aufgaben durchgeführt. Dieser muss auf allen betroffenen Datenbanken angelegt sein. Zur Verwaltung von Streams müssen ihm mit dem Package DBMS_STREAMS_ AUTH Rechte zugewiesen werden. ORDIX News 2/2006 Datenbanken AQ_TM_PROCESSES >= 1 Compatible >= 9.2.0 Erlaubt das Monitoring von Queue Messages. Besser ist mindestens 10.1.0, um die 10g Funktionalitäten nutzen zu können. Job_queue_processes >= 2 Die Staging Queues werden über Jobs gefüllt. Open_links Wird für die Verbindungen zwischen den Datenbanken benötigt. Logmnr_max_persistent_sessions Wird für das Auslesen der Redologs benötigt. (>= Anzahl der Capture-Prozesse) Parallel_max_servers ++2 Spezifiziert die maximale Anzahl paralleler Prozesse. Processes Es ist zu beachten, dass für Capture, Propagation und Apply verschiedene Prozesse notwendig sind. Shared_pool_size +10 % pro Stream mindestens plus 10 MB Streams_pool_size Neu in 10g. Für den Speicherbereich in der SGA zum Zwischenspeichern der Events, mindestens mit 100 MB. Global_names = TRUE Ganz wichtig (!!!), da die Datenströme sich in der Regel zwischen verschiedenen Datenbanken bewegen sollen. Abb. 9: Wichtige init.ora-Parameter für den Einsatz von Streams. Die Quelldatenbanken müssen im ArchivelogModus arbeiten, damit der LogMiner an die komplette Redo Log-Information herankommt. Zwischen den Datenbanken müssen Verbindungen durch Datenbank-Links hergestellt wer­ den. Zum Speichern der Events müssen AQ Queues erstellt werden. Dazu dienen das Package DBMS_STREAMS_ADM und die darin enthaltene Prozedur SET_UP_QUEUE. Die Data Dictionary Information von der Quelldatenbankseite muss zur Zieldatenbank übertragen werden. Dazu dient die Prozedur DBMS_CAPTURE_ADM. PREPARE_SCHEMA_INSTANTIATION. Einrichtung von Streams Die Einrichtung von Streams muss in der richtigen Reihenfolge erfolgen, da sonst ein EventStau entstehen könnte. Es empfiehlt sich folgende Vorgehensweise: 1. Quell- und Zieldatenbank konfigurieren. Dazu gehören init-Parameter, das Einrichten von Tablespaces, das Einrichten spezieller User DBMS_STREAM_ADM, Secure Queue User, Capture- oder ApplyUser und das Einrichten von DB-Links. 2. Capture-Prozess aufsetzen (nicht starten). 3. Propagation-Prozess aufsetzen (nicht starten). 4. Apply-Prozess aufsetzen und starten. 5. Propagate-Prozess starten. 6. Capture-Prozess starten. Das Löschen erfolgt in umgekehrter Reihenfolge. ORDIX News 2/2006 Glossar AQ DDL DML Advanced Queuing LCR Replikation Logical Change Record Redo Log Data Definition Language Data Manipulation Language Datenverteilung in verschiedene Datenbanken Protokolldateien in der Oracle-Datenbank, die durch den Logwriter geschrieben werden. Event Ereignis. Hier DDL- oder DML-Änderung oder Meldung. SGA System Global Area Supplemental Logging Erweiterte Protokollierung in den Redo LogDateien. SYS.ANYDATA Datentyp in Oracle, der einen beliebigen Typ aufnehmen kann. PL/SQL Prozedurale Erweiterung von SQL Queue Speicherstruktur nach dem FIFO-Prinzip (First in First out) DB-Link Datenbank-Link. Verbindung zwischen zwei Datenbanken. Logminer Package mit dem die Redolog-Dateien ausgewertet werden, um die UNDO- und DO-Information zu erhalten. Kennzeichen im Datensatz. Tag Fazit Für den Administrator bedeutet das Aufsetzen von Oracle Streams in einer verteilten Umgebung nach wie vor einen erheblichen Aufwand. Da verteilte Umgebungen in der Praxis jedoch zunehmend an Bedeutung gewinnen und auch die Notwendigkeit des Informationsaustauschs mehr denn je besteht, wird auch der Einsatz von Oracle Streams zunehmend bedeutender. Beate Künneke ([email protected]). Java/XML – Titelthema JavaServer Faces Der zukünftige Web-Standard für die Entwicklung von Benutzeroberflächen JavaServer Faces Aus dem Struts-Lager lassen sich eindeutige Stimmen vernehmen, dass die Zukunft der Web-Benutzeroberflächen den JavaServer Faces (JSF) gehört. Da Struts nicht mehr aktiv weiterentwickelt wird und die JSF-Spezifikation demnächst in eine weitere Runde geht (JSF 1.2), lohnt sich ein genauerer Blick auf die Technologie. Der Artikel richtet sich an Entwickler mit Erfahrungen im Bereich Web-Anwendungen, Benutzeroberflächen und jene, die eine Alternative bzw. Ergänzung zum Struts Framework suchen. Spezifikation eines Standards Die JavaServer Faces basieren auf dem JSR-127 (Java Specification Request), der im Mai 2001 dem Java Community Process hinzugefügt wurde. Ziel war die Erstellung einer Spezifikation und die Entwicklung einer Referenzimplementierung für ein Benutzerschnittstellen-Framework, das die Entwicklung von Web-Applikationen vereinfachen sollte. Großen Wert legte man dabei schon früh auf eine Etablierung als Standard, der mit einer breiten Tool-Unterstützung einher gehen sollte. Folgerichtig setzte sich die beratende Expertengruppe aus namhaften Mitgliedern der J2EE- und Toolhersteller-Szene zusammen. Darunter befanden sich u. a. BEA, Oracle, Sun, Borland und Macromedia sowie Craig McClanahan, der Initiator des bis dato wohl populärsten Frameworks für Web-Applikationen: Struts. Erst im Jahr 2004 war man so weit, den Standard in der Version 1.0 zu verabschieden und eine erste Referenzimplementierung zur Verfügung zu stellen. Diese Referenzimplementierung von Sun ist heute, neben der MyFaces-Implementierung des Apache-Projekts, die meist verwendete. Beide Implementierungen entsprechen der heute aktuellen JSF 1.1 Spezifikation. Beispielapplikation Um die Features sowie die Vorgehensweise beim Entwickeln einer JSF-Anwendung besser darstellen zu können, dient ein kleiner Login-Dialog. An diesem Beispiel (siehe Abbildung 1) sollen die wichtigsten Elemente von JavaServer Faces demonstriert werden: ► ► ► ► ► ► ► ner Sammlung von HTML/JSP-Seiten, Java-Archiven und Deployment-Deskriptoren in Form von XML-Dateien zu tun hat. Die Installation von Tomcat, der unter Windows-Betriebssystemen für Entwicklungszwecke nicht als Dienst betrieben werden sollte, hat keine Besonderheiten. Das gleiche gilt für Eclipse. Mit dem Eclipse Wizard wird anschließend ein neues Dynamic Web Project angelegt. Was jetzt noch fehlt, sind die JSF-Bibliotheken myfaces-api. jar und myfaces-impl.jar aus dem MyFaces-Paket. Die MyFaces-Implementierung benötigt zusätzlich noch einige Bibliotheken (siehe Abbildung 2) aus dem Apache Commons Projekt. Die genannten JAR-Dateien werden unterhalb von WEB-INF in ein lib-Verzeichnis kopiert und in den Build-Pfad des Projektes übernommen. Die Struktur des fertigen Projektes wird später wie in Abbildung 2 aussehen. Konfiguration Um eine JSF-Applikation im Tomcat-Webcontainer ausführen zu können, müssen im De­ ployment-Deskriptor web.xml der Anwendung zwingend weitere Einträge gemacht werden (siehe Abbildung 3). die JSF Tag-Bibliotheken das Datenmodell die Validierung die Konvertierung das Event-Handling die Navigation die Lokalisierung Bei der Erstellung der Anwendung kommt der Tomcat-Servletcontainer, die JSF-Implementierung MyFaces und Eclipse inklusive der Webtools als Entwicklungsumgebung zum Einsatz. Voraussetzungen Jede JSF-Anwendung ist zunächst einmal eine ganz normale WebAnwendung. Das bedeutet, dass man es im Wesentlichen mit ei- Abb. 1: Beispielanwendung eines Login-Dialogs. ORDIX News 2/2006 Java/XML <servlet> <servlet-name> JavaServer Faces Servlet </servlet-name> <servlet-class> org.apache.myfaces.webapp.MyFacesServlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name> JavaServer Faces Servlet </servlet-name> <url-pattern>/faces/*</url-pattern> </servlet-mapping> Abb. 3: Einbindung von JavaServer Faces im Deployment-Descriptor (web.xml). dies die html_basic Library, die Tags für die Darstellung der bekannten HTML-Elemente enthält. Zum anderen werden Tags benötigt, die Elemente beschreiben, die unabhängig von der jeweiligen Darstellungssprache (HTML, WML, ...) sind. Dazu zählen Tags, die einen Komponentenbaum definieren oder einer Komponente einen ActionListener zuordnen. Diese Tags befinden sich in der jsf_core Library. Abb. 2: Projektstruktur. Dies sorgt dafür, dass das zentrale JSF-FrontController Servlet registriert wird und alle Requests der Form /faces/* an dieses weitergeleitet werden. Es können hier noch eine Vielzahl anderer JSF-Konfigurationselemente eingetragen werden, die im Einzelfall der Dokumentation der Implementierung entnommen werden können. Model-View-Controller Paradigma Im Bereich der Benutzeroberflächen-Frameworks hat sich, unabhängig davon, ob es sich um Desktop- oder Web-Applikationen handelt, die Umsetzung des MVC-Paradigmas bewährt. Das bedeutet, dass auch bei den Java Server Faces auf die strikte Trennung der Daten von deren Darstellung geachtet wird. Während die JSP-Seiten die Darstellung (View) übernehmen, werden die Daten (Model) in so genannten Managed Beans gehalten. Genauso wie bei Struts übernimmt ein zentrales Servlet (FacesServlet) nach dem Front Controller Pattern die Rolle des Controllers, der die beiden anderen Teile koordiniert und die Verbindung zur Geschäftslogik herstellt. JavaServer Faces Tag Libraries Standardmäßig sind die JavaServer Faces mit zwei Tag Libraries ausgestattet. Zum einen ist ORDIX News 2/2006 Damit diese Tags in einer JSP-Seite verwendet werden können, müssen die Libraries an deren Anfang mittels einer Direktive wie folgt eingebunden werden: <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> Damit ist klar, dass alle Tags, die mit <h: beginnen zur html_ basic Library gehören, während alle Tags mit <f: Teil der jsf_ core Library sind. Der Login-Dialog stellt sich mit der Kenntnis über die Tag-Libra­ries dann wie in Abbildung 4 gezeigt dar. Das <f:view> Tag umschließt alle Elemente, die Teil des Komponentenbaums der View werden. Die <h:-Elemente beschreiben die einzelnen Komponenten. Die JavaServer Faces verfügen über eine sehr flexible Expression Languange, mit deren Hilfe auf verschiedene andere Daten zugegriffen werden kann. So wird mittels value="#{messages.username}" auf einen Text verwiesen, der unter dem Schlüssel username in einer Resource-Datei registriert ist. Managed Beans als Datenmodell Als Datenmodell werden bei den JavaServer Faces einfache JavaBeans verwendet. Eine solche Bean muss jedoch zuvor in einer Konfigurationsdatei (normalerweise faces-config.xml) bekannt gemacht werden. Im Beispiel (siehe Abbildung 5) wird die Bean loginBean verwendet. Damit ist die Bean der Klasse test.LoginBean unter dem Namen loginBean aus der JSP-Loginseite zugreifbar. Die JSF-Implementierung kümmert sich um die Instanziierung genauso wie um die Java/XML ... <f:loadBundle basename="test.resources" var="messages" /> <f:view> ... <h:commandLink id="de" action="#{loginBean.dummy}" actionListener="#{loginBean.switchLanguage}"> <h:outputText value="#{messages.german}" /> </h:commandLink> <h:commandLink id="en" action="#{loginBean.dummy}" actionListener="#{loginBean.switchLanguage}"> <h:outputText value="#{messages.english}" /> </h:commandLink> ... <h:form> <h:outputText value="#{messages.title}" /> ... <h:outputText value="#{messages.username}" /> <h:inputText id="username" value="#{loginBean.username}" required="true" /> ... <h:outputText value="#{messages.password}" /> <h:inputSecret id="password" value="#{loginBean.password}" /> ... <h:outputText value="#{messages.code}" /> <h:inputText id="int" value="#{loginBean.code}" required="true"> <f:validateLongRange minimum="1000" maximum="9999" /> </h:inputText> ... <h:commandButton action="#{loginBean.login}" value="Login" /> ... <h:messages layout="table" showDetail="true" style="color: red;" /> </h:form> </f:view> ... Abb. 4: Die Hauptelemente der View. <managed-bean> <description> A simple bean for managing the login </description> <managed-bean-name>loginBean</managed-bean-name> <managed-bean-class>test.LoginBean</managed-bean-class> <managed-bean-scope>session</managed-bean-scope> </managed-bean> Abb. 5: Registrierung der LoginBean als Managed Bean. Zugriffe und die Speicherung der Bean im richtigen Scope. Ähnlich wie Struts, kennen auch die JavaServer Faces die Scopes Application, Request und Session. Hinzu kommt der Scope none, der eine Sonderposition einnimmt. Hier wird die Bean also in der Session abgelegt und ist so auf anderen Seiten der Applikation weiter verfügbar. Im Beispiel bewirkt das Tag <h:inputText id="username" value="#{loginBean.username}" required="true" />, dass der über die Form im Feld Benutzername eingegebene Text im Attribut username der Bean loginBean gespeichert wird. Eine Managed Bean kann jedoch nicht nur Daten aufnehmen. Wie das Beispiel in Abbildung 5 zeigt, kann auch die Ausführung von Methoden erreicht werden. Das Tag <h:commandButton action="#{loginBean.login}" value="Login" /> bewirkt, dass beim Drücken des Login-Buttons der Form die Methode login der Bean loginBean aufgerufen wird. Damit stellen die Managed Beans ebenfalls eine Schnittstelle zur Geschäftslogik zur Verfügung. 10 Validierung Die JSF-Implementierung enthält auch ein umfangreiches Instrumentarium zur Validierung von Eingaben, die bei Bedarf durch eigene Methoden ergänzt werden können. Das Beispiel zeigt die Validierung anhand eines Feldes, das einen Code aufnehmen kann, der aus einer Zahl zwischen 1000 und 9999 bestehen darf (siehe Abbildung 6). Das required Attribut verhindert, dass das Ein­ gabefeld leer gelassen werden kann, während das folgende <f:validateLongRange>-Tag den Wertebereich bestimmt. Konvertierung An dem gezeigten Fall der Validierung lässt sich auch ein weiteres Feature der JavaServer Faces verdeutlichen. Das Attribut des Codes ist in der Bean als Integer deklariert (siehe Abbildung 7). Die JSF-Implementierung ist in der Lage, un­ terschiedliche Datentypen zu konvertieren. Selbst für benutzerdefinierte Datentypen, lassen sich solche Konverter nachträglich entwickeln und einbinden. Wie auch für die Validierung werden bei der Konvertierung im Falle von Fehlern Mechanismen in Gang gesetzt, die entsprechende Fehlermeldungen generieren und anzeigen. ORDIX News 2/2006 Java/XML <h:inputText id="int" value="#{loginBean.code}" required="true"> <f:validateLongRange minimum="1000" maximum="9999" /> </h:inputText> Abb. 6: Validierung der Eingabe. Event Handling Eine Menge ihrer Flexibilität erlangen die JavaServer Faces durch das Event Handling. Wer schon einmal bei der Entwicklung von SwingGUIs mit dem Observer Pattern in Berührung gekommen ist, wird sich hier sofort heimisch fühlen. Bei einer Kommandokomponente lässt sich z. B. eine ActionListener-Methode registrieren, die bei jedem Klick (in diesem Fall ein normaler Link) ausgeführt wird (siehe Abbildung 8). Hier wird dies dazu genutzt, die Spracheinstellung für die Applikation zu verändern. Die Methode switchLanguage ist dabei wie in Abbildung 9 implementiert. Jede Methode, die als ActionListener fungiert, muss die gezeigte Signatur besitzen. Aus den Daten des Events können dann Informationen über die auslösende Komponente ermittelt wer­den. Im Beispiel ist dies die ID der Kom­ po­­nente, die in diesem Fall identisch mit der Bezeichnung (Locale) für die einzustellen­de Sprache ist. Navigation Für den Standardfall der Navigation innerhalb von JSF-Anwendungen ist ein so genannter NavigationHandler verantwortlich. Er wird über die faces-config.xml Datei mit einem Satz von Regeln initialisiert, nach denen er entscheidet, welche Aktion oder Seite als nächstes ausgeführt bzw. aufgerufen wird. Im Beispiel soll bei einer erfolgreichen Identifizierung die Seite main.jsp angezeigt werden, während bei einem Fehler auf der LoginSeite (mit einer entsprechenden Meldung) verblieben werden soll. Die Navigationsregel finden Sie in Abbildung 10. Der NavigationHandler entscheidet im Normalfall anhand so genannter Outcomes, hier SUCCESS und FAILURE (siehe Abbildung 11). Dabei handelt es sich um symbolische Werte, die von einer Action-Methode zurückgegeben werden. Internationalisierung Die Internationalisierung von Web-Applikationen ist ein sehr facettenreiches Thema. Es betrifft die Ausgabe von einfachen Labeln in Formularen genauso, wie die Eingabe von Datums- und Zeitwerten in ihrer regional übli­ chen Form. ORDIX News 2/2006 public class LoginBean { ... private String username = null; private String password = null; private Integer code = null; ... public Integer getCode() { return code; } public void setCode(Integer code) { this.code = code; } ... } Abb. 7: Attribute der LoginBean. <h:commandLink id="de" action="#{loginBean.dummy}" actionListener="#{loginBean.switchLanguage}"> <h:outputText value="#{messages.german}" /> </h:commandLink> Abb. 8: Registrierung einer Listener-Methode. Im vorgestellten Login-Dialog gibt es zwei Links, mit denen die Sprache zwischen Englisch und Deutsch gewechselt werden kann. Als Basis dafür dienen so genannte Resource Bundles. Dabei handelt es sich um einen Satz von Dateien, in denen zu jeweils einem Schlüsselwert der Text in der jeweiligen Sprache hinterlegt ist. Das Bundle für die deutsche Spracheinstellung finden Sie in Abbildung 12. Im Beispiel gibt es die beiden Dateien resources_en.properties und resources_de.properties, die im Source-Baum im Paket test abgelegt sind. Das Tag <f:loadBundle basename="test. resources" var="messages" /> auf einer JSF-Seite sorgt dafür, dass eines dieser Resource-Bundles geladen wird. Welches genau, hängt von der aktuellen Locale-Einstellung ab. Für Deutschland ist dieser Wert de, für englische Spracheinstellungen entsprechend en. Diese Kürzel werden dem jeweiligen Dateinamen inklusive des Unterstrichs angehängt. Damit sind die lokalisierten Texte unter dem Prefix messages mittels eines Ausdrucks der Expression Language zugreifbar. So sorgt das Tag <h:outputText value="#{messages.username}" /> für die Ausgabe des Labels username in der aktuellen Sprache. Lebenszyklus Jeder JSF-Request wird nach einem einheitlichen Schema abgewickelt, dessen Kenntnis für die Entwicklung von JSF-Applikatio­ nen notwendig ist. Dazu soll an dieser Stelle ein wenig hinter die Kulissen der JavaServer Faces geschaut werden. 11 Java/XML public void switchLanguage(ActionEvent event) { Locale locale = new Locale(event.getComponent().getId()); FacesContext.getCurrentInstance().getViewRoot().setLocale(locale); } Abb. 9: Implementierung der Methode switchLanguage. <navigation-rule> <from-view-id>/login.jsp</from-view-id> <navigation-case> <from-outcome>SUCCESS</from-outcome> <to-view-id>/main.jsp</to-view-id> </navigation-case> <navigation-case> <from-outcome>FAILURE</from-outcome> <to-view-id>/login.jsp</to-view-id> </navigation-case> </navigation-rule> Abb. 10: Die Navigationsregel. Der Lebenszyklus eines Requests besteht aus sechs verschiedenen Phasen. Es müssen nicht zwangsweise alle sechs Phasen durchlaufen werden. Unter bestimmten Umständen, wie etwa das Auftreten eines Fehlers während der Validierung oder Konvertierung von Werten, können einzelne Phasen auch übersprungen werden. Die zwischen den Phasen auftretenden EventVerarbeitungen werden im Folgenden nicht erläutert. Sie sind im Ablauf-Diagramm (Abbildung 13) aber deutlich (in blauer Farbe) gekennzeichnet. Phase 1: Reconstitute Request Tree Wird von einer JSF-Seite durch Drücken eines Buttons oder Anwählen eines Links ein Request ausgelöst, so besteht die erste Aufgabe der JSF-Implementierung darin, den Komponentenbaum aufzubauen und im FacesContext abzulegen. Existiert dort schon ein zugehöriger Komponentenbaum, so wird dieser aus dem Kontext übernommen. Phase 2: Apply Request Values In dieser Phase füllt das JSF-Framework den Komponentenbaum mit den neuen Werten aus dem Request. Diese Werte überschreiben noch nicht den aktuellen Wert im Datenmodell. Vielmehr werden sie lokal in der Komponente abgelegt, um sie in der nächsten Phase validieren zu können. Schlägt eine Konvertierung dabei fehl, so wird eine der entsprechenden Komponente zugeordnete Fehlermeldung generiert und direkt in die Render Response Phase gewechselt. Befindet sich im Request ein Kommando, beispielsweise durch einen gedrückten Button, so generiert die entsprechende Komponente einen Event. Dieser ermöglicht während einer späteren Verarbeitung, über die bei der Komponente registrierten Listener, die Ausführung spezifischer Geschäftslogik. Phase 3: Process Validations Die mit den einzelnen Komponenten registrierten Validatoren werden in dieser Phase angewendet. Die JSF-Implementierung durchläuft alle Komponenten und überprüft, ob deren in der vorigen Phase lokal gespeicherten Werte mit den hinterlegten Regeln vereinbar sind. Bei einer Regelverletzung wird die entsprechende Kom- 12 ponente als invalid markiert und analog zu Phase 2 in die Render Response Phase gesprungen. Phase 4: Update Model Values In dieser Phase gelten die lokal gespeicherten Werte in der Komponente als gültig. Damit können sie jetzt ins Datenmodell übertragen werden und dort die alten Werte ersetzen. Sollten an dieser Stelle Probleme mit der Konvertierung in die Typen des Datenmodells auftreten, wird wiederum in die Render Response Phase gesprungen. Phase 5: Invoke Application Auf Basis des aktualisierten Datenmodells wird mit der Abarbeitung der aufgetretenen Events begonnen. Das bedeutet typischerweise, dass hier Methoden aufgerufen werden, die als Action an Kommando-Elemente wie Buttons gebunden sind. Dies ist die Stelle, an der die Geschäftslogik ausgeführt wird. Phase 6: Render Response Diese Phase liefert einen symbolischen Wert, der als Outcome bezeichnet wird. Ein Outcome definiert die nächste View, die durch die Navigationsregeln der Applikation festgelegt wurde. Der Komponentenbaum der neuen View wird an­schließend aufgebaut und im FacesContext abgelegt. Trat in einer der vorigen Phasen ein Validierungs- oder Konvertierungsfehler auf, so wurde die Invoke Application Phase übersprungen und keine Geschäftslogik ausgeführt. In diesem Fall ist die neue View gleich der alten. Es wird die gleiche View noch einmal zurückgegeben, was die Möglichkeit zur Darstellung von Fehlermeldungen bietet. Fazit Diese Ausführungen bieten einen ausreichen­ den Überblick, um die Technologie der JavaSer­ ver Faces und deren Möglichkeiten einzuschät­ zen. Die Frage, ob JSF das Mittel der Wahl für zukünftige Web-Projekte ist, lässt sich pauschal nicht beantworten. Die Betrachtung eini­ ger Aspekte kann aber eine Hilfe für die Entscheidung bieten. Klar scheint zu sein, dass Struts für zukünftige Projekte immer weniger Berücksichtigung fin- ORDIX News 2/2006 Java/XML public String login() { if("demo".equals(getUsername()) && "demo".equals(getPassword())) { return SUCCESS; } ... return FAILURE; } Abb. 11: Festlegen der Rückgabewerte (Outcomes) anhand derer der NavigationHandler aus Abbildung 10 entscheidet. den wird. Struts-Shale stellt keine wirkliche Alternative dar, da es oft nur als Studie betrachtet wird, um die kommende JSF 2.0 Spezifikation zu bereichern. Andererseits wird aber auch die Migration bestehender Struts-Applikationen nach JSF eher die Ausnahme bleiben. Dafür ist der Aufwand doch relativ hoch. Außerdem darf man nicht verschweigen, dass JSF auch noch einige Funktionen fehlen. So gibt es noch immer keinen Template-Mecha­ nis­mus, wie man ihn z. B. mit Tiles im Struts Framework findet. Eindeutig für JSF spricht die Tatsache, dass es sich um einen Standard handelt, der sehr viel Flexibilität in sich birgt. So können einzel­ ne Komponenten durch eigene Entwicklungen oder denen von Drittanbietern ausgetauscht oder erweitert werden. JavaServer Faces sind nicht auf HTML-Oberflächen festgelegt, die Erstellung von Anwendungen für z. B. mobile Anwendungen (WAP, etc.) wird ebenfalls unterstützt. Insgesamt hat die JSF-Architektur eine sehr klare Struktur. Die Erstellung der Konfigurationsdateien ist recht einfach und die Beans und Controller unterliegen nicht so starken Restriktionen wie z. B. bei Struts (Form, Action, execute-Methode, ...). Zudem ist die JSF-Spezifikation von Anfang an auf eine breite Tool-Unterstützung ausgelegt worden. Die meisten kommerziellen Entwicklungsumgebungen bieten komfortable Edito­ ren für alle Bereiche. Visuelle Darstellung der Na­vigationsstrukturen oder Drag&Drop-Fä­hig­­­­ keiten bei der Formularerstellung sind fast selbst­ verständlich. In Eclipse wird mit dem Milestone 1.5 der Webtools die JSF-Unterstützung integriert. Die JavaServer Faces werden die Entwicklung vielleicht nicht revolutionieren, aber doch – und das nicht zuletzt wegen des zuletzt angeführten Aspekts der Tool-Unterstützung – um einiges vereinfachen und vereinheitlichen. Andreas Flügge ([email protected]). ORDIX News 2/2006 apptitle=JSF Test title=Bitte melden Sie sich an username=Benutzername password=Kennwort code=Ihr Code login=Anmelden welcome=Herzlich willkommen zu unserem kleinen Test german=Deutsch english=Englisch loginerror=Zugriff verweigert:&nbsp; loginerrordetails=Benutzer und/oder Kennwort falsch Abb. 12: Resource Bundle für die deutsche Spracheinstellung. Response Complete Faces Request Reconstitute Request Tree Apply Request Values Process Events Response Complete Process Validations Process Events Render Response Response Complete Faces Response Render Response Invoke Application Response Complete Process Events Update Model Values Conversion Errors/ Render Response Validation / Conversion Errors / Render Response Abb. 13: JSF Request Lebenszyklus. Glossar Deployment Deskriptor Eine (XML-)Datei, die Konfigurationseinstellungen für die Laufzeitumgebung und die Applikation enthält. Servlet Container Laufzeitumgebung für die Ausführung von Servlets, wo­­zu auch Java Server Pa­ges (JSPs) und JavaServer Faces (JSFs) zählen. Front Controller Software-Muster, bei dem eine zentrale Komponente externe Anfragen entgegennimmt und an interne, nach außen gekapselte Dienste delegiert. Model View Controller (MVC) Ein Paradigma für Benutzer­oberflächen, das die ge­ trenn­te Behandlung von Daten, de­ren Darstellung und die darauf wirkenden Benutzeraktivitäten propagiert. Observer Pattern Software-Muster, bei dem sich mehrere Kom­­ponenten (Observer) bei einer einzelnen Kom­ponente (Subject) registrieren. Das Subject kann so beim Auftreten bestimmter Ereignis­se alle Observer informieren. JSF-Request Die Anfrage eines Clients (meist ein Webbrow­ser) zur Darstellung einer Webseite, die JavaServer Faces-Komponenten enthält. 13 Unix/Linux/Open Source – Titelthema MySQL 5 Datenbanken LOB - Oracle Large Object Die Oracle Large Objects, kurz LOB, sind die Nachfolger für die LONG und RAW Datentypen in Oracle. Dieser Artikel stellt sie vor und gibt den aktuellen Stand der Datenbankversion 10g wieder. Ein Schwerpunkt bildet dabei die Berücksichtigung von LOB in dem PL/SQL Package DBMS_LOB. Der Artikel richtet sich an Entwickler, die sich mit der Verarbeitung von Oracle Large Objects (LOB) beschäftigen. Definition von LOB (Large Objects) Mit den Datentypen BFILE, BLOB, CLOB und NCLOB lassen sich unstrukturierte Daten, z. B. Text, Grafiken/Bilder, Videoclips und Musikdateien, mit bis zu 128 Terabytes speichern. Früher wurden LONG und RAW als Datentypen benutzt. Diese besitzen eine geringere Speicherkapazität von maximal 2 Giga­­byte. Oracle operiert mit LOB durch einen so genannten „Locator“. Dabei handelt es sich um einen Zeiger auf den aktuellen Speicherort des LOB. Jeder Datensatz bekommt seinen eigenen „Locator“. Dieser Zeiger ist nichts anderes als eine Variable mit einem bestimmten Wert, die einen einzelnen LOB-Wert im Datenbankrechner abbildet. LOB-Zeiger wurden entwickelt, um Benutzer mit einem Mechanismus auszustatten, durch den sie sehr große Objekte in den Anwendungsprogrammen leicht verändern können, ohne dass es erforderlich ist, das tatsächliche LOB ständig zwischen Datenbankserver und Client, auf dem das Anwendungsprogramm läuft, zu kopieren. Der Zweck von LOB • Speicherung unstrukturierter Daten • Optimiert für große Datenbestände • Unterstützt einen definierten Zugriff auf große, unstrukturierte Datenmengen innerhalb und außerhalb der Datenbank. Warum sollte man LONG Datentypen nicht mehr verwenden? • Sie können nur maximal 2 Gigabyte groß sein. • Es ist nur eine LONG-/LONG RAW Spalte pro Tabelle erlaubt. • LOB unterstützen den wahlfreien Zugriff, bei LONGs ist nur ein sequentieller Zugriff möglich. LOB-Datentypunterscheidungen im Überblick Es wird einmal unterschieden in interne LOB (BLOB, CLOB, NCLOB) und externe LOB (BFILE). Eine weitere Möglichkeit der Unterscheidung ist die Einteilung in persistente LOB und temporäre LOB. Dieser Unterschied wird im Folgenden näher beschrieben. Interne LOB-Datentypen Interne LOB werden innerhalb der Datenbank in Tablespaces gespeichert, wobei Platz und Zugriff optimiert sind. Interne LOB können im Falle des Transaktions-/Systemabbruchs zurückgewonnen werden. 14 Sie fallen unter das Transaktionskonzept. Das heißt COMMIT und ROLLBACK können durchgeführt werden. Ebenfalls ist ein RECOVERY bei Systemfehlern möglich. Der BLOB dient der Aufnahme von binären, unstrukturierten, großen Objekten. Der CLOB wird für die Speicherung von großen Textdaten sinnvoll eingesetzt. Der NCLOB nimmt die Textdaten im nationalen Zeichensatz auf. Externe LOB-Datentypen Der externe LOB wird durch das BFILE abgebildet. Dieser Datentyp ist im Dateisystem des Betriebsystems gespeichert. Eine BFILE-Spalte/-Variable speichert eine BFILE-„Rechnervariable“, die als Zeiger auf eine binäre Datei auf dem Server dient. Die BFILEs sind nur lesbar. Sie können also (über die Datenbank) nicht geändert werden. Die Größe eines BFILEs ist vom Betriebssystem abhängig. Der Datenbankadministrator muss sicherstellen, dass die Datei existiert und dass die Oracle-Prozesse im Betriebssystem Leserechte besitzen. Die Höchstzahl an geöffneten BFILEs wird über den Parameter SESSION_MAX_OPEN_FILES eingestellt und ist systemabhängig. Sie unterliegen nicht dem Transaktionsprinzip und damit können COMMIT, ROLLBACK und RECOVER nicht genutzt werden. Abgesehen von herkömmlichen Fremdspeichern wie Festplatten, können sich BFILEs auf Speichermedien wie CD-ROMs, Photo CDs und DVDs befinden. Oracle greift auf solche BFILEs auch über das zugrunde liegende Zugriffssystem des Betriebssystems (OS) zu. Die Speicherung der LOB-Werte Die Daten, die in einem LOB gespeichert sind, werden auch als „Wert“ des LOB bezeichnet. Der Wert eines internen LOB kann (!) mit den anderen Werten des Datensatzes „in-line“ ge­ speichert werden, d. h. innerhalb des zugeord­ neten Speicherbereiches innerhalb der Daten­ bank. Wenn der Parameter DISABLE STORAGE IN ROW nicht eingestellt ist und der interne LOB- ORDIX News 2/2006 Datenbanken Wert kleiner als 4.000 Bytes ist, dann wird der Wert „in-line“ gespeichert. Andernfalls wird er außerhalb des Datensatzes („out-of-line“) im LOB-Tablespace gespeichert. Da LOB große Objekte sein sollen, ist eine inline-Ablage nur sinnvoll, wenn die Anwendung kleine und große LOB mischt. Der LOB-Wert wird automatisch aus dem Datensatz verschoben („out-of-line“), sobald er die 4.000 Byte Größe überschreitet. Die Speicherung der LOB-Verzeichnisse (LOB-Locator) Unabhängig davon, wo der Wert des internen LOB gespeichert ist, wird ein Locator in dem Datensatz gespeichert. Der LOB-Locator ist ein Zeiger zur tatsächlichen Position des LOBWertes. Ein LOB-Locator ist ein Zeiger zu einem internen LOB, während ein BFILE-Locator ein Zeiger zu einem externen LOB ist. Für interne LOB speichert die LOB-Spalte einen eindeutigen Locator zum Wert des LOB, der in einem Datenbank Tablespace abgelegt ist. Jede LOB-Spalte/Attribut hat für einen gegebenen Datensatz seinen eigenen eindeutigen LOB-Locator. Externe LOB (BFILEs) speichern die LOBSpalte in einem BFILE-Locator zur externen Datei. Jede BFILE-Spalte/Attribut besitzt für einen gegebenen Datensatz seinen eigenen BFILE-Locator. Jedoch können zwei unterschiedliche Datensätze einen BFILE-Locator besitzen, der auf die gleiche Datei verweist. Setzen von LOB-Spalten/Attributen Bevor aus einem Programm (PL/SQL, OCI, OCCI, Pro*C/C++, Pro*COBOL, Java oder OLE) in einem internen LOB geschrieben werden kann, muss der LOB mit dem Spal­tenattribut NOT NULL gebildet werden. D. h. er muss einen LOCATOR enthalten. Dies wird mit den Funk­ tionen EMPTY_BLOB() für BLOB oder EMPTY_ CLOB() für CLOB und NCLOB erreicht. Bevor in einen externen LOB-Wert (BFILE) mit den programmgestützten Schnittstellen geschrieben werden kann, muss das BFILE ebenfalls mit dem Spaltenattribut NOT NULL gebildet werden. Die BFILE-Spalte kann mit der BFILENAME()-Funktion initialisiert werden, um auf eine Datei im Betriebssystem zu verweisen. Temporäre LOB-Datentypen Temporäre LOB (BLOB, CLOB, NCLOB) werden nicht, wie andere Daten, dauerhaft in der Datenbank gespeichert. Sie werden in den ORDIX News 2/2006 APPEND() COPY() ERASE() LOADFROMFILE() TRIM() WRITE() WRITEAPPEND() READ Hängt den Inhalt eines LOB an einen anderen LOB. Kopiert einen Teil oder alles von einem LOB in einen anderen. Löscht einen Teil von einem LOB ab einer bestimmten Position. Lädt Daten von einem externen in einen internen LOB. Verkleinert den LOB in eine bestimmte Größe. Schreibt Daten in einen LOB an einer bestimmten Stelle. Schreibt Daten an das Ende eines LOB. Lesen der Werte eines LOB. Abb. 1: Funktionen zum Manipulieren von LOB-Typen. CREATE TABLE test_clob ( product_id NUMBER(6), id NUMBER(6), sourcetext CLOB, fltextn NCLOB, foto BLOB ); INSERT INTO test_clob VALUES (1,1,'abcd',EMPTY_CLOB(),EMPTY_BLOB()); COMMIT; Abb. 2: Erstellen einer Tabelle mit den Datentypen BLOB und CLOB und deren Befüllen. temporären Tablespaces gespeichert und nicht in Tabellen abgelegt. Das heißt, dass ein interner, temporärer LOB auf dem Server erstellt (CREATE) werden kann. Allerdings ist er von jeder Tabelle unabhängig und kann somit auch nicht gespeichert werden. Durch die Verwendung von temporären LOB werden die Systemressourcen geschont. Die temporären LOB sind nicht mit einer Tabelle verbunden und somit gibt es auch keinerlei Entsprechung zu den Bezeichnungen „in-line“ und „out-of-line“, wie dies für die anderen LOB-Typen üblich ist. Ausgewählte Funktionen des DBMS_LOB Packages für LOB-Manipulationen Mit diversen Funktionen lassen sich Manipulationen an den einzelnen LOB-Typen vornehmen (siehe Abbildung 1). Es ist dabei zu beachten, dass nicht alle Funktionen für die externen LOB gültig sind, weil sie teilweise nur lesbar und nicht veränderbar sind. Detaillierte Beispiele finden Sie dazu in der Online-Version der ORDIX News im Web: http://www.ordix.de/ORDIXNews. Die besondere Lesekonsistenz bei LOB In Abbildung 2 und 3 a - f wird die Beziehung zwischen der Lesekonsistenz des Locators und der Aktualisierung des LOB-Wertes durch einen zweiten Locator in einem Beispiel dargestellt. Ebenso wird ein Teil der oben aufgeführten Funktionen integriert. 15 Datenbanken Mit der Tabelle test_clob werden drei CLOB als mögliche Locatoren betrachtet: • clob_selected • clob_update • clob_copied Im Zeitpunkt t1 (siehe Abbildung 3a) ist das SELECT INTO (t1) über den Wert der Variablen sourcetext mit dem Locator clob_ selected verknüpft. Im Zeitpunkt t2 (siehe Abbildung 3b) ist der Wert der Variablen sourcetext mit dem Locator clob_updated verbunden. DECLARE num_var clob_selected clob_updated clob_copied read_amount read_offset write_amount write_offset buffer BEGIN -- t1 SELECT INTO FROM WHERE INTEGER; CLOB; CLOB; CLOB; INTEGER; INTEGER; INTEGER; INTEGER; VARCHAR2(20); sourcetext clob_selected test_clob product_id = 1; Abb. 3a: Einlesen des LOB-Wertes in die 1. Locator-Variable. -- t2 SELECT INTO FROM WHERE FOR sourcetext clob_updated test_clob product_id = 1 UPDATE; Abb. 3b: Einlesen des LOB-Wertes in die 2. Locator-Variable. -- t3 clob_copied := clob_selected; -- Ausgabe der einzelnen Locator Inhalte. read_amount := 10; read_offset := 1; dbms_lob.read(clob_selected, read_amount, read_offset,buffer); dbms_output.put_line('t3 - clob_selected value: ' || buffer); -- Ausgabe: 'abcd' dbms_lob.read(clob_copied, read_amount, read_offset, buffer); dbms_output.put_line('t3 - clob_copied value: ' || buffer); -- Ausgabe 'abcd': dbms_lob.read(clob_updated, read_amount, read_offset, buffer); dbms_output.put_line('t3 - clob_updated value: ' || buffer); -- Ausgabe :'abcd' Abb. 3c: Kopieren des Wertes des 1. Locators in eine 3. Locator-Variable. 16 Da es keine Änderungen im Wert der Variablen gegeben hat, ist die Lesekonsistenz in den Zeipunkten t1 und t2 für clob_selected und clob_updated gewahrt. Im Zeitpunkt t3 (siehe Abbildung 3c) wird der Wert von clob_selected nach clob_copied übertragen. In diesem Zeitpunkt besitzen alle drei Locatoren den gleichen Wert. Das Beispiel zeigt dieses mit einer Reihe von DBMS_ LOB.READ() Aufrufen. Im Zeitpunkt t4 (siehe Abbildung 3d) verwendet das Programm DBMS_LOB.WRITE(), um den Wert von clob_updated zu ändern und durch DBMS_LOB.READ() wird der neue Wert angezeigt. Jedoch zeigt ein DBMS_LOB.READ() auf clob_selected den gleichen Wert im Zeitpunkt t5 (siehe Abbildung 3e) an, so dass erkennbar ist, dass der Locator weiterhin so existiert, wie er beim SELECT eingelesen wurde. Ebenso zeigt ein DBMS_LOB.READ() auf clob_copied den gleichen Wert im Zeitpunkt t6 (siehe Abbildung 3f) an, wie er in clob_selected steht. Erstellung von Terabyte LOB Seit der Oracle Datenbankversion 10g spricht Oracle ab einer Größe von mehr als vier Gigabyte von den so genannten „Terabyte LOB“. Die maximale Dateigröße wird dabei einerseits durch das Betriebssystem vorgegeben. Andererseits ist für BFILEs das Maximum grundsätzlich auf 264 – 1 Bytes beschränkt! Zur Zeit werden folgende Umgebungen von Oracle unterstützt: • Java mit JDBC (Java Database Connectivity) • PL/SQL mit dem DBMS_LOB Package • C mit OCI (Oracle Call Interface) Nicht unterstützt werden: • COBOL mit Pro*COBOL Precompiler • C or C++ mit Pro*C/C++ Precompiler • Visual Basic mit OO4O (Oracle Objects for OLE) Hinweise für die Erstellung von „Terabyte“ LOB Operiert man mit sehr großen LOB sollte der Parameter PCT_INCREASE möglichst auf 0 gesetzt werden. Bei der schrittweisen Erweiterung des LOB wird sonst jedes Mal ein Extent entsprechend des Parameters PCT_INCREASE benutzt. Das ist Speicherplatzverschwendung und bei entsprechender Größe auch schwer zu handhaben. ORDIX News 2/2006 Datenbanken Glossar Oracle Large Object (LOB) Binary Large Object (BLOB) Character Large Object (CLOB) National Character Large Object (NCLOB) Binary Large Object (BFILE) Datentyp zur Aufnahme großer Datenmengen. Datentyp zur Aufnahme bi­närer Daten innerhalb der Datenbank (z. B. Programme, Grafiken etc.). Datentyp zur Aufnahme von Textdaten innerhalb der Datenbank. Datentyp zur Aufnahme von Textdaten im nationalen Zeichensatz innerhalb der Datenbank. Datentyp für ein LOB, das nicht in der Datenbank gespeichert wird. Eine andere Möglichkeit ist die Verwendung von locally managed Tablespaces. Der Parameter MAXEXTENTS ist möglichst auf UNLIMITED zu setzen: Hierdurch erfolgt dann keine Beschränkung beim Befüllen der LOB-Spalte durch die Anzahl der Extents. Es sollten möglichst große Extentgrößen verwendet werden. Oracle generiert beim Erstellen eines Extents jedes Mal UNDO-Informationen und weitere Metadaten. Dies kann dazu führen, dass das Maximum des RollbackSegmentes erreicht wird. Eine Extentgröße von zur Zeit 100 Megabyte oder das häufigere Absetzen eines COMMIT Kommandos zum Beenden der Transaktion kann Abhilfe schaffen (siehe Abbildung 4). Die Storage Klausel in diesem Beispiel ist im CREATE TABLESPACE Statement eingebettet. Alternativ kann sie auch in der CREATE TABLE Klausel erfolgen. Dabei ist zu beachten, dass die Storage Klausel in einem CREATE TEMPORARY TABLESPACE Statement nicht erlaubt ist. Fazit Der LOB ist inzwischen ein würdiger Nachfolger der alten LONG und RAW Datentypen geworden. Mit jedem neuen Release seit Oracle 8 wurden die Einsatzmöglichkeiten erweitert. Für die Zukunft empfiehlt sich, auf die Datentypen LONG und RAW generell zu verzichten, da diese im Gegensatz zu LOB-Datentypen nur eingeschränkt nutzbar sind. Somit empfiehlt es sich auch, wenn möglich, eine Migration auf die LOB-Datentypen vorzunehmen. Mit diesem Thema beschäftigen wir uns in einer der nächsten Ausgaben. Klaus Günther ([email protected]). ORDIX News 2/2006 -- t4 write_amount := 3; write_offset := 5; buffer := 'efg'; dbms_lob.write(clob_updated, write_amount, write_offset,buffer); read_amount := 10; dbms_lob.read(clob_updated, read_amount, read_offset, buffer); dbms_output.put_line('t4 - clob_updated value: ' || buffer); -- Ausgabe : 'abcdefg' Abb. 3d: Ändern des LOB-Wertes und anschließendes Auslesen. -- t5 -- trotz Änderung des LOB-Wertes. dbms_lob.read(clob_selected, read_amount, read_offset,buffer); dbms_output.put_line('t5 - clob_selected value: ' || buffer); -- Ausgabe: 'abcd' Abb. 3e: Ausgangswert des ersten Locators ist erhalten geblieben. -- t6 -- trotz Änderung des LOB-Wertes. dbms_lob.read(clob_copied, read_amount, read_offset, buffer); dbms_output.put_line('t6 - clob_copied value: ' || buffer); -- Ausgabe: 'abcd' END; / Abb. 3f: Ausgangswert des kopierten Locators ist erhalten geblieben. CREATE TABLESPACE lobtbs1 DATAFILE '/eigenes/verzeichnis/lobtbs_1.dbf' SIZE 3000M REUSE ONLINE NOLOGGING DEFAULT STORAGE( MAXEXTENTS UNLIMITED); ALTER TABLESPACE lobtbs1 ADD DATAFILE '/eigenes/verzeichnis/lobtbs_2.dbf' SIZE 2000M REUSE; CREATE TABLE test_clob ( product_id NUMBER(6), id NUMBER(6), sourcetext CLOB, ad_fltextn NCLOB, foto BLOB ) LOB(sourcetext) STORE AS ( TABLESPACE lobtbs1 CHUNK 32768 PCTVERSION 0 NOCACHE NOLOGGING STORAGE(INITIAL 100M NEXT 100M MAXEXTENTS UNLIMITED PCTINCREASE 0)); Abb. 4: Beispiel für einen Gigabyte LOB. 17 Unix/Linux/Open Datenbanken – Titelthema Source – Titelthema SQL Developer MySQL 5 Der Oracle SQL Developer ist da! Das einfache Werkzeug mit grafischer Oberfläche zur Bearbeitung von Quellcode innerhalb der Oracle Datenbank ist nun endlich da. Das besondere an diesem Oracle Tool ist, dass es zum freien Download zur Verfügung steht. Noch zu Jahresbeginn firmierte es als nicht unterstützte Version unter dem Namen „Raptor“. Dieser Artikel stellt den SQL Developer vor und gibt die ersten Erfahrungen wieder. Der Artikel richtet sich an Oracle Entwickler und DBAs, die den SQL Developer bei der Entwicklung von Datenbankskripten und -applikationen einsetzen und sich zudem einen schnellen Überblick über die Datenbank verschaffen wollen. Der Sinn des SQL Developers ist, die Entwicklungsaufgaben zu vereinfachen und so eine erhöhte Entwicklungsproduktivität zu gewährleisten. Somit richtet sich der SQL Developer in erster Linie an Datenbankentwickler. Für den klassischen Datenbankadministrator kann er nur ein Hilfsmittel sein. Hardware Oracle empfiehlt zur Zeit, den in Java entwickelten SQL Developer auf den in Abbildung 1 aufgelisteten Plattformen einzusetzen. SQL Developer Funktionalitäten Mit dem SQL Developer können Benutzer Datenbankobjekte anzeigen, bearbeiten, erstellen und löschen. Innerhalb des integrierten SQL Worksheets lassen sich SQL- und PL-/SQL-Statements ausführen und überprüfen (Debug-Funktio­ nalität). Es besteht ebenso die Möglichkeit, vordefinierte oder selbst erstellte Reports zu erstellen. Connections Der SQL Developer besitzt zwei Navigationsebenen, so genannte „Tabs“. Die erste Ebene ist der Verbindungsnavigator „Connections“. Hiermit kann sich der Benutzer mit jedem möglichen Ora­ cle Datenbankschema verbinden, das die Standard Oracle Authen­ tifizierung benutzt. Benutzer können sich mit dem SQL Developer an Oracle Datenbanken ab Version 9.2.0.1 und höher anmelden. Zur Datenbankan- bindung benötigt man den Schemanamen, das Kennwort, den Rechnernamen und die Datenbank SID bzw. den Servicenamen. Sobald der Benutzer verbunden ist, können Datenbankobjekte erstellt, geändert, gelöscht und entsprechend ihrer Funktionalität manipuliert werden. Dies beinhaltet den Zugriff auf folgende Objekttypen: • • • • • • • • Tabellen Views Indizes Packages Prozeduren Funktionen Trigger Typen • • • • • • • • Sequenzen Materialized Views Materialized View Logs Synonyme Public Synonyme Datenbank Links Directories Papierkorb (ganz wichtig ab Oracle 10g!) Darüber hinaus können Datenbankobjekte anderer Datenbankbenutzer entsprechend der vergebenen System- und Objektprivilegien genutzt werden (siehe Abbildung 2). Reports Die zweite Ebene „Reports“ beinhaltet eine An­zahl von vordefinierten Reports über die Da­tenbank und ihre Objekte. Ebenfalls lassen sich selbstdefinierte Reports erstellen. Bei den vordefinierten Reports handelt es sich um Auszüge aus dem Data Dictionary (siehe Abbildung 3). Die Syntax kann angezeigt und durch ein COPY/PASTE in das SQL-Worksheet übertragen werden. Dort wird der Quellcode an die persönlichen Anforderungen angepasst und dann als selbstdefinierter Report gespeichert. Die durch die Reports gewonnenen Daten können auch exportiert werden. SQL-Worksheet und PL/SQL Abb. 2: Datenbankobjekte. 18 Das SQL-Worksheet unter­ stützt die Erstellung von SQL- und PL/SQL-Befehlen. Diese können einzeln oder ORDIX News 2/2006 Datenbanken Windows Windows 2000-Service Pack 4 Windows XP-Service Pack 1 Linux Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Fedora Core 4 SuSE SLES8 Mac-OS X Apple Mac OS X Version 10.3 Abb. 1: Von Oracle empfohlene Plattfor­ men für den Einsatz des SQL Developers. nacheinander als Skript ablau­fen. Eine Befehlshistorie beinhaltet die vorhergehenden Befehle. Zusätzlich existiert die Möglichkeit, sich den Ausführungsplan für ausgewählte Statements anzusehen. Etwas lästig ist die permanente Aufforderung zur Auswahl der entsprechenden Datenbank bei jedem Öffnen des SQL-Worksheets. Hier existieren Tools mit einer komforta­ ble­ren Lösung. Abb. 3: Report Ergebnisse. Ein weiteres Manko ist zur Zeit, dass die SQL*Plus Session Parameter nicht genutzt werden können. Die Darstellung der Ergebnisse durch DBMS_OUTPUT wird dadurch aber nicht beeinträchtigt! Exportieren von Abfrageergebnissen Die zum Beispiel mit SQL gewonnenen Ergebnisse lassen sich in die Formate INSERT-Statements, SQL-Loader, CVS, Text und XML exportieren. Dies geschieht einfach über die Auswahl aus dem Kontextmenü, das per Mausklick aufgerufen werden kann (siehe Abbildung 4). Abb. 4: Export gewonnener Daten durch einen SELECT. Im Anschluss kann bestimmt werden, ob die Daten in einer Datei oder im Clipboard gespeichert werden. Ebenso kann über den Tab Reiter „Columns“ die Auswahl auf einzelne Spalten beschränkt werden. Darüber hinaus kann auch noch eine WHERE-Klausel implementiert werden. Applikationsfenster Eine Gesamtansicht einzelner Applika­ tions­fenster (Connections, Reports, Snip­ pets, SQL-Worksheets) zeigt Abbil­dung 5. Es ist auch möglich, die ein­zel­nen Ap­ plikations­bestandteile jeweils am Appli- ORDIX News 2/2006 Abb. 5: Übersicht der Applikationsfenster. 19 Datenbanken kationsrand minimiert zu positionieren und nur bei Bedarf zu öffnen. Debug Der Benutzer kann PL/SQL-Code erstellen und ändern. Er kann Code-Formatie­rung und Bookmarks hinzufügen und Quell­­code verwenden. Das Prüfen (Debug) von Stored Procedures ist möglich. Diese Eigenschaft erlaubt dem Benutzer, den Code laufen zu lassen, zu prüfen und alternative Daten während des Debug-Vorgangs einzugeben. Dazu wird die entsprechende Stored Procedure aufgeru­fen und durch das Kontextmenü in den De­bug Status versetzt (siehe Abbildung 6). Im Anschluss erscheint ein Fenster, das der Auswahl der zu prüfenden Stored Procedure dient (siehe Abbildung 7). Nach dem Bestätigen der ausgewählten Stored Procedure mit „OK“ wird dies im Debug-Modus angezeigt. Nun stehen alle Debug-Funktionalitäten zur Verfügung. Abbildung 8 gibt ein Beispiel. Snippets Eine weitere, nützliche Implementierung sind die so genannten „Snippets“. Das Bearbeiten von SQL- bzw. PL/SQL-Code im Worksheet wird durch ihre Verwendung vereinfacht. Es handelt sich dabei um vordefinierte Quellcodefragmente, wie z. B. SQL-Funktionen, Optimizer hints oder verschiedene PL/SQLProgrammiertechniken. Support Abb. 6: Debug Kontextmenü. Für den Support ist zu beachten, dass eine Zer­tifizierung (Support bei Fragen) für die einzelnen Bestandteile des SQL Developers (SQLWorksheet, Datenbank-Funktionen, PL/SQL-Support) zur Zeit nur für die Datenbanken 9i (Version 9.2.0.4) und 10g Enterprise Edition, Standard Edition, Standard Edition One und Express Edition gilt. Die Unterstützung der einzelnen Daten­ bankversionen befindet sich aber in ei­ nem fortlaufenden Prozess. Die notwendige Voraussetzung für den Support des SQL Developers ist eine Oracle Datenbank­lizenz. Fazit Abb. 8: Beispiel für das Debugging einer Stored Procedure. 20 Für die erste Version ist der SQL Developer ein durchaus für SQL- und PL/SQLStandardprogrammierung sinnvoll ein- ORDIX News 2/2006 Datenbanken Glossar Debug Prüfung des Quellcodes auf Funktionalität und aktuelle Parameterwerte. GUI Graphical User Interface. Dies ist die grafische Benutzeroberfläche. Stored Innerhalb der Datenbank gespeicherte Prozeduren, Procedures Funktionen und Paketelemente. SQL Structured Query Language. Sie dient als Kommunikationsinstrument mit der Datenbank. PL/SQL Procedural Language/SQL. Erweiterung von SQL um prozedurale Programmierelemente. Abb. 7: Auswahlfenster. zusetzendes Werkzeug, um schnell und ohne großen Konfigurationsaufwand mit der Da tenbank zu kommunizieren. Vor allem das Debug Tool bietet dem Entwickler einen unschätzbaren Vorteil bei seiner täglichen Arbeit. Ein weiterer Pluspunkt dieses Tools besteht dar- in, dass es von Oracle unterstützt wird und dass zur Zeit keine Lizenzgebühren anfallen. Letzteres ist, wie wir wissen, keine Garantie auf Lebenszeit und könnte zunächst nur ein Lockmittel sein. Klaus Günther ([email protected]). Aktuell Larry Ratlos: System Monitoring Larry steht wieder einmal vor einem größeren Problem: Ein neuer Batchjob wurde auf seinem Linuxsystem installiert. Da der betroffene Rechner auch weitere Aufgaben wahrnimmt, soll er nun überprüfen, ob die bereits vorhandenen Jobs negativ beeinflusst werden. Deshalb möchte Larry wis sen, wie hoch die Systemlast bei laufendem Job ist, und ob er gegebenenfalls auf ein dediziertes System ausweichen muss. Leider ist der neue Job ein klassischer Langläufer und natürlich muss auch der Tagesbetrieb, wie üblich, sichergestellt werden. Den Job über die ganze Laufzeit hinweg selbst zu beobachten, ist für Larry also nicht möglich. Sein Kollege aus dem Operating, Beo Bachter, schlägt vor, das System in das zentrale Monitoring aufzunehmen. Aber Larry muss das ablehnen: Langwierige Installationen oder kostenintensive Anschaffungen von Softwarelizenzen zwecks Monitoring sind zunächst einmal keine Option. Larry ist ratlos, dabei möchte er doch nur Daten zu seinem System sammeln, um diese später auszuwerten. „Da gabs doch ein bestimmtes Paket ...?! ...“ denkt sich Larry. Doch es fällt ihm leider nicht mehr ein. Können Sie Larry helfen? Wissen Sie, an welches Paket er sich zu erinnern versucht? ORDIX News 2/2006 Und wenn das Paket installiert wurde, wie ermittelt Larry dann die von ihm benötigten Daten? Senden Sie Ihren Lösungsvorschlag bis zum 24.07.2006 an [email protected]. Lösung der Aufgabe aus 1/2006 In der letzten ORDIX News hatte Larry mit der Bekämpfung übervoller Tabellen zu tun. Er wollte gerne eine quartalsweise Partitionierung der Tabellen vornehmen. Das Statement, mit dem er es letztendlich geschafft hat, ist folgendes: select max(partition_name) "ALT", substr(max(partition_name),1,instr(max(partition_name),'_',1,1)) || to_char(add_months(to_date (substr (max(partition_name),instr(max(partition_name),'_',1,1)+1,4) || decode (substr(max(partition_name),-1,1), '1', '-01-01', '2', '-04-01', '3', '-07-01', '4', '-10-01'),'yyyy-mm-dd'),3),'yyyy_q') "NEU" from user_tab_partitions where table_name = 'BEST_PART'; 21 Projektmanagement – Titelthema ITIL IT-Service Management mit ITIL (Teil II): Service Delivery ITIL - Eine Oase in der Servicewüste Die Philosophie von ITIL basiert auf der Erkenntnis, dass IT noch stärker als bisher Unternehmensziele und geschäftliche Anforderungen unterstützen soll. Das hat zur Folge, dass die Anforderungen an die Qualität und Stabilität immer höher werden und der Kostendruck ebenfalls steigt. Daher muss das Optimierungspotenzial der gesamten IT-Infrastruktur ausgeschöpft werden. In der letzten Ausgabe stellten wir die operativen Prozesse des „Service-Support“ dar, heute betrachten wir die taktischen bzw. planerischen Prozesse von ITIL. Der Artikel richtet sich an diejenigen, die sich als Führungskraft oder Fachverantwortliche im IT-Betrieb und in Querschnittsabteilungen mit IT-Service Management beschäftigen. Zuviel Verwaltung in der IT? Zunächst sei die Frage gestattet, ob Planung und Strategie die notwendige Innovation in der IT zu sehr einschränken? Oder schaffen sie sogar Freiräume? In Zeiten, in denen bei jedem IT-Vorhaben zunächst der Blick auf die Wirtschaftlichkeit gerichtet wird, könnte man Angst um die Innovation bekommen, die gerade in der IT eine so wichtige Rolle spielt. Den Ansprüchen gerecht werden Wie wird man dem wachsenden Anspruch gerecht, eine zuverlässige IT-Infrastruktur für Geschäftsprozesse zur Verfügung zu stellen? 7x24 Stundenbetrieb, Hochverfügbarkeitslösungen, schnelle Netze, verteilte Systeme. Ein bunter Mix aus Anforderungen und Maßnahmen. ITIL bietet mit den Prozess-Sets im Bereich Service Delivery klare Strukturen, definiert Rol len und Verantwortlichkeiten für die Planung im Service Management. Service-Delivery besteht aus: In der jüngeren Vergangenheit wurden in der Praxis sehr viele neue Anwendungen geschaffen, die durch Innovation getrieben waren – technologisch wie geschäftlich. Insbesondere durch den Einsatz moderner Web-Technologie und J2EE-Plattformen versucht man den Kunden direkter zu erreichen, Stichwort Multikanal-Banking, Direkt-Versicherung u. v. m. • • • • • • Dies hat jedoch auch erhebliche Implikationen auf die Komplexität der dahinter liegenden IT-Infrastruktur. Nur wer den Überblick behält, erkennt auch alle Chancen Availability Management Capacity Management Financial Management IT-Security Business Continuity Service Level Management Availability Management Service Delivery Application Management Operative Ebene Abb. 1: ITIL-Serviceprozesse. 22 ITSecurity Technologische Plattform Service Support IT Infrastructure Management IT Service Management Service Level Management Geschäftliche Anforderungen Planung, Strategie Kurz gesagt: hier geht es um Verfügbarkeit. Doch was bedeutet das im Detail? Nicht in erster Linie, dass ein System beispielsweise zu 95 Prozent im Monat „verfügbar“ ist, sondern es geht um die Summe der Maßnahmen, die dafür sorgen, dass eine IT-Infrastruktur zur Verfügung gestellt wird. Also „wie“ stelle ich eine hohe Verfügbarkeit sicher? Wobei die eigentliche Implementierung Aufgabe des Release Managements ist. Availability Management schafft Voraussetzungen, plant und macht Vorgaben. So ist z. B. das Thema Backup & Recovery bzw. Restore in diesem Bereich eine wichtige Disziplin. ORDIX News 2/2006 Projektmanagement Links ► [1] IT-Grundschutzhandbuch des Bun­ desamtes für Sicherheit in der Informa­ tionstechnik: www.bsi.de Angesiedelt sind hier weiterhin Themen wie Hochverfügbarkeitslösungen, Maßnahmen zur Vermeidung von Ausfällen, Maßnahmen zur Performance-Steigerung u. v. m. Zur Qualitätssicherung und Überwachung gehört dann das Monitoring der Systeme. Hier werden Schwellwerte analysiert und prophylaktische Maßnahmen eingeleitet. Das Avail­ ability Management liefert diese Daten dann an das Capacity Management. Capacity Management Niemand plant zu versagen, aber die meisten versagen beim Planen. In diesem Fall sprechen wir von dem Kapazitätsplan. Dieser bildet die Basis für eine ausreichend dimensionierte IT-Infrastruktur. Wie oft haben wir schon die Erfahrung gemacht, dass Funktion und Performance nicht immer harmonieren. Man erinnere sich an die frühen Zeiten des Internets. Hier ein Bild, da ein Applet und schon war die Leitung dicht. Bandbreiten sind auch heute noch ein wichtiges Thema bei der Anbindung von Außenstellen eines Unternehmens, Versicherungsvertretern oder bei Energieversorgern, wenn mal wieder der Gaszähler abgelesen wird. Kapazitätsplanung greift aber auch bei zentralen Systemen. Wir brauchen ausreichende Storage-Systeme, CPUs und vieles mehr. Hier ist eine enge Zusammenarbeit, insbesondere mit dem Change Management, Availability Management und Financial Management gefordert. Was brauchen wir? Eine mittel- bis langfristige Planung, eine richtige Auslegung der Infrastruktur und die richtige Auswertung und Analyse der Inputs aus dem Availability Management. Letztlich müssen alle Prozess-Sets im Service Delivery harmonisch zusam­men­arbeiten. Financial Management Das Financial Management ist mit seinem Controlling die monetäre Steuerungsinstanz im ITIL-Umfeld. Financial Management führt das Controlling durch und liefert die finanziellen Planungswerte, um vor allem im Change Management fundierte Kosten/Nutzen-Entscheidungen treffen zu können. ORDIX News 2/2006 Financial Management hat nicht so sehr mit Kontrolle zu tun, sondern liefert vielmehr die notwendige Kostentransparenz, die den Nutzen bestimmter Maßnahmen sichtbar macht. IT-Security Das Spektrum der IT-Security erstreckt sich vom baulichen bis hin zur systemtechnischen Absicherung der Software und Zurverfügungstellung entsprechender Verfahren. Dies können Berechtigungsverfahren (Stichwort Single Sign On) sein oder auch systemtechnische Maßnahmen zur Absicherung von Vorgaben der IT-Sicherheit, z. B. Design und Implementierung einer Verwaltungsdatenbank für die Vergabe von Zertifikaten. ITIL selbst weist hier auch einige Aktivitäten in seinen ProzessSets aus, jedoch gibt es gerade im deutschen Bereich verschiedene Besonderheiten und Vorschriften. Das zentrale Dokument hierzu ist das IT-Grundschutzhandbuch des Bundesamtes für Sicherheit in der Informationstechnik [1]. Business Continuity Quasi als „Nachbarbereich“ gilt das Business Continuity Management. Hierbei geht es vor allem um Themen der Katastrophenvorsorge, Ausweicharbeitsplätze und -systeme, also um alle Verfahren und Techniken, die dafür sorgen, dass im Falle eines größeren Ausfalls der IT-Infrastruktur die Mindestanforderungen an die Kontinuität des Geschäftsbetriebs erfüllt sind. Fragen Sie doch mal in Ihrem Rechenzen­trum, ob dort ein Notstromaggregat vorhanden ist und ob die Dieseltanks von der Unteren Wasserbehörde genehmigt wurden. Business Continuity hat eben nicht nur mit IT zu tun. Vom Request zum Agreement – Service Level Management Letztendlich oder noch besser zu Beginn ist zu klären, was der Kunde wirklich will und was die Informationstechnologie hierfür zu leisten im Stande ist. Der IT-Dienstleister, sei es ein externer oder ein unternehmensinterner, muss gemeinsam mit seinem Leistungsempfänger definieren, welche Leistungen zu erbringen sind. Hier stehen sich zunächst Service Level Requests (SLRs) als Anforderungen und Service Levels als mögliche Leistungen mit bestimmter Qualität gegenüber: Dies können Servicezeiten und Lösungszeiten für auftretende Störungen oder System­verfügbarkei­ ten sein. Alle Leistungen stellt der Leistungsanbieter in einem Service- oder Leistungskatalog zusammen. Auf dieser Basis wird dann ein Service Level Agreement (SLA) zwischen Leistungs­anbieter und -empfänger abgeschlossen. Das Service Level Management kümmert sich aber nicht nur um dessen Erstellung, sondern auch um die Weiterentwicklung der SLAs und um die Überwachung der Qualität und des Reporting. Service Level Management bildet somit ein wichtiges Bindeglied für die oben genannten ITIL-Prozesse, die nur gemeinsam gut funktionieren können. Denn auch hier gilt: Das Ganze ist mehr als nur die Summe seiner Einzelteile. Rainer Restat ([email protected]). 23 Datenbanken Oracle SQL Oracle SQL für Experten Oracle Datenbankprogrammierung mit PL/SQL Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Aufbau Oracle Backup und Recovery Oracle Tuning und Monitoring Oracle Troubleshooting Workshop Oracle Real Application Cluster RAC Oracle 10g Neuheiten Oracle Net Oracle Security Workshop Oracle Data Guard Workshop Oracle RMAN Workshop Informix SQL Informix Dynamic Server Administration Informix Tuning und Monitoring Informix Backup und Recovery mit ON-Bar IBM DB2 UDB für Unix/Windows SQL Grundlagen IBM DB2 UDB für Unix/Windows Administration Grundlagen MySQL Administration Microsoft SQL Server Administration Programmierung Einführung in die objektorientierte Programmierung Perl Programmierung Grundlagen Perl Programmierung Aufbau Einführung in XML XML Programmierung unter Java mit DOM und SAX Oracle und XML PHP Programmierung Grundlagen E-Commerce Lösungen mit PHP (Workshop) PHP Programmierung Aufbau Shell, Awk und Sed Java-J2EE Java Programmierung Grundlagen Java Programmierung Aufbau Java 5.0 Neuheiten J2EE für Entscheider Einführung in J2EE JSP und Servlet Programmierung EJB Programmierung Administration und Konfiguration für JBoss Java Web Services Systemmanagement BMC PATROL/Performance Manager Basics BMC PATROL/Performance Manager Customizing and Development BMC PATROL/Performance Manager Advanced Web- und Applikations-Server Apache Web-Server Installation und Administration Tomcat Konfiguration und Administration WebSphere Application Server Installation und Administration Betriebssysteme Unix/Linux Grundlagen für Einsteiger Linux Systemadministration Linux Hochverfügbarkeits-Cluster Solaris Systemadministration Grundlagen Solaris Systemadministration Aufbau Solaris 10 Neuheiten Solaris für Unix Umsteiger Netzwerke Linux Netzwerkadministration Security Unix/Linux Security im Internet Projektmanagement IT-Projektmanagement Grundlagen des IT-Controlling Wiesbaden Saarbrücken 1790,00 1190,00 1790,00 1890,00 1890,00 1890,00 1890,00 1890,00 1490,00 1890,00 790,00 1190,00 1190,00 1490,00 1590,00 1790,00 1890,00 1090,00 1790,00 1890,00 1090,00 1790,00 1090,00 1590,00 1590,00 1090,00 790,00 790,00 1590,00 1090,00 1090,00 1590,00 1590,00 1590,00 1090,00 450,00 1090,00 1590,00 1590,00 1090,00 1090,00 1890,00 1490,00 1890,00 1090,00 1090,00 1290,00 1590,00 1590,00 1190,00 1890,00 1890,00 1890,00 1890,00 1590,00 1590,00 1890,00 1190,00 *) Preise pro Seminar pro Teilnehmer in Euro. Alle Preise gelten zzgl. ges. MwSt. **) Inhousepreise auf Anfrage. Lippstadt Einige der hier aufgeführten Bezeichnungen sind eingetragene Warenzeichen ihrer jeweiligen Inhaber. Irrtümer vorbehalten. Für weitere Informationen und Fragen zu individuell zugeschnittenen Seminaren, Ausbildungsreihen oder Inhouse Schulungen stehen wir jederzeit gerne zur Verfügung. Auf Wunsch senden wir Ihnen auch unser komplettes Seminarprogramm zu. 24 ORDIX ORDIX News News 2/2006 2/2006 KW 36 KW 35 KW 34 KW 33 KW 32 KW 31 August KW 30 KW 28 KW 27 Juli KW 26 KW 25 Juni KW 24 Preis in EURO*)**) - herausnehmbare Übersicht - KW 29 Aus- & Weiterbildung Seminartermine http://training.ordix.de Online-Anmeldung und stets aktuelle Seminarinhalte und Termine! KW 49 KW 48 Dez. KW 47 KW 46 KW 45 KW 44 November KW 43 KW 42 KW 41 KW 40 Oktober KW 39 KW 38 KW 37 September Aus- & Weiterbildung Juni - Dezember 2006 Preis in EURO*)**) 1790,00 1190,00 1790,00 1890,00 1890,00 1890,00 1890,00 1890,00 1490,00 1890,00 790,00 1190,00 1190,00 1490,00 1590,00 1790,00 1890,00 1090,00 1790,00 1890,00 1090,00 1790,00 1090,00 1590,00 1590,00 1090,00 790,00 790,00 1590,00 1090,00 1090,00 1590,00 1590,00 1590,00 1090,00 450,00 1090,00 1590,00 1590,00 1090,00 1090,00 1890,00 1490,00 1890,00 1090,00 1090,00 1290,00 1590,00 1590,00 1190,00 1890,00 1890,00 1890,00 1890,00 1590,00 1590,00 1890,00 1190,00 Datenbanken Oracle SQL Oracle SQL für Experten Oracle Datenbankprogrammierung mit PL/SQL Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Aufbau Oracle Backup und Recovery Oracle Tuning und Monitoring Oracle Troubleshooting Workshop Oracle Real Application Cluster RAC Oracle 10g Neuheiten Oracle Net Oracle Security Workshop Oracle Data Guard Workshop Oracle RMAN Workshop Informix SQL Informix Dynamic Server Administration Informix Tuning und Monitoring Informix Backup und Recovery mit ON-Bar IBM DB2 UDB für Unix/Windows SQL Grundlagen IBM DB2 UDB für Unix/Windows Administration Grundlagen MySQL Administration Microsoft SQL Server Administration Programmierung Einführung in die objektorientierte Programmierung Perl Programmierung Grundlagen Perl Programmierung Aufbau Einführung in XML XML Programmierung unter Java mit DOM und SAX Oracle und XML PHP Programmierung Grundlagen E-Commerce Lösungen mit PHP (Workshop) PHP Programmierung Aufbau Shell, Awk und Sed Java-J2EE Java Programmierung Grundlagen Java Programmierung Aufbau Java 5.0 Neuheiten J2EE für Entscheider Einführung in J2EE JSP und Servlet Programmierung EJB Programmierung Administration und Konfiguration für JBoss Java Web Services Systemmanagement BMC PATROL/Performance Manager Basics BMC PATROL/Performance Manager Customizing and Development BMC PATROL/Performance Manager Advanced Web- und Applikations-Server Apache Web-Server Installation und Administration Tomcat Konfiguration und Administration WebSphere Application Server Installation und Administration Betriebssysteme Unix/Linux Grundlagen für Einsteiger Linux Systemadministration Linux Hochverfügbarkeits-Cluster Solaris Systemadministration Grundlagen Solaris Systemadministration Aufbau Solaris 10 Neuheiten Solaris für Unix Umsteiger Netzwerke Linux Netzwerkadministration Security Unix/Linux Security im Internet Projektmanagement IT-Projektmanagement Grundlagen des IT-Controlling Informationen und Anmeldung: ORDIX AG Westernmauer 12-16 33098 Paderborn Tel.: 05251 1063-0 ORDIX AG Kreuzberger Ring 13 65205 Wiesbaden Tel.: 0611 77840-00 ORDIX ORDIX News News 2/2006 2/2006 zentrales Fax: 0180 1 ORDIX 0 bzw. 0180 1 67349 0 E-Mail: [email protected] Online-Anmeldung: http://training.ordix.de 25 Datenbanken Neues bei Oracle: 10gR2 (Teil III) RMAN Convert Database In der ORDIX News 1/2006, Seite 4, beschäftigten wir uns mit den neuen Data Guard Möglichkeiten von Ora­ cle 10gR2. In dieser Ausgabe werden wir weitere Features näher betrachten. Der Artikel richtet sich an Datenbankadministratoren und Entscheider, die sich über weitere neue Features der Version 10.2 informieren wollen. Cross-Platform Database Transport Wie sieht der übliche Weg aus, den wir bei einer Migration von einer Serverplattform zu einer anderen, z. B. von Sun zu HP, beschreiten? Wir exportieren (exp/Datapump) die Daten aus der aktuellen Plattform und importieren (imp/Datapump) sie auf der neuen Plattform. Meist geht damit auch eine Migration auf ein neueres Oracle Release einher. Insgesamt ein sehr aufwändiges Verfahren. Ab Oracle 10gR2 steht uns dafür ein neuer Weg zur Verfügung. Dieser Weg heißt Cross-Platform Database Transport. Das passende Recovery Manager (RMAN) Kommando heißt CONVERT DATABASE. Rückblick Zur Erinnerung: Seit Oracle 10gR1 besteht die Möglichkeit, mit dem Recovery Manager transportable Tablespaces zwischen beliebigen Platt­formen zu verschieben. Einen Überblick über die unterstützten Plattformen sowie das zugrunde liegende SQL-Statement, das diese Liste liefert, finden Sie in Abbildung 1. Nun wollen wir betrachten, wie das Ganze funktioniert. Voruntersuchung Teil 1 Bevor wir mit dem Transport der Datenbank beginnen, untersuchen wir, ob der von uns gewünschte Pfad unterstützt wird. SQL> select * from v$transportable_platform order by platform_id; PLATFORM_ID 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 PLATFORM_NAME ENDIAN_FORMAT 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. 1: Unterstützte Zielplattformen für einen transportablen Tablespace auf einer beliebigen Plattform. PLATFORM_ID 7 10 5 11 15 8 13 12 17 PLATFORM_NAME ENDIAN_FORMAT Microsoft Windows IA (32-bit) Linux IA (32-bit) HP Tru64 UNIX Linux IA (64-bit) HP Open VMS Microsoft Windows IA (64-bit) Linux 64-bit for AMD Microsoft Windows 64-bit for AMD Solaris Operating System (x86) Little Little Little Little Little Little Little Little Little Abb. 2: Unterstützte Plattformen auf einem Linux Server. 26 Ein select * from v$DB_TRANSPORTABLE_PLATFORM auf einem Linux Server gibt einen ersten Überblick über die unterstützten Plattformen (siehe Abbildung 2). Zusätzlich hilft die Funktion DBMS_TDB. CHECK_DB bei der Voranalyse. Schauen wir uns das Ganze an einem Beispiel an. Dabei wollen wir von Linux IA (32-bit) nach Linux 64-bit for AMD wechseln. Den passenden String für den Plattformnamen erhalten wir aus dem Ergebnis der vorherigen Abfrage. Vor dem Ausführen dieses Packages und für die weiteren Schritte muss die Datenbank read-only geöffnet werden, da es ansonsten zu einer entsprechenden Feh­ lermeldung kommt. Das kleine Skript in Abbildung 3 hilft uns dabei. Damit ist endgültig klar, dass einer „direkten“ Migration nichts im Weg steht. Voruntersuchung Teil 2 Vor der Konvertierung müssen wir noch untersuchen, ob unsere Datenbank externe Tabellen, BFILEs oder directories enthält. Diese können von CONVERT DATABASE nicht bearbeitet werden und ORDIX News 2/2006 Datenbanken müssen separat behandelt, d. h. mit Betriebssystemmitteln kopiert werden. Zur Ermittlung gibt es die DBMS_TDB.CHECK_EXTERNAL Funktion. Auch hier hilft uns ein kleines Skript (siehe Abbildung 4). Konvertierung Nach diesen Vorarbeiten ist unsere Datenbank fertig für das Konvertieren auf die neue Plattform. Das RMAN Kommando CONVERT DATABASE erzeugt dabei die drei notwendigen Bestandteile: 1. Eine vollständige Kopie aller Datenbankdateien 2. Ein Transport Skript zum Anlegen der Datenbank auf dem neuen Server 3. Ein pfile für die neue Datenbank Ein Beispiel mit der entsprechenden Ausgabe liefert Abbildung 5. Die hier entstandenen Dateien werden nun auf den neuen Server kopiert. handelt, da beim CONVERT DATABASE zwar die Datenbank Dateien gesichert wurden, aber kein Backup der Control-Datei angelegt wurde. Dadurch werden wir automatisch dazu gebracht, die Pfade zu den Dateien auf den gewünschten Stand zu bringen. Das von CONVERT DATABASE angelegte pfile ist selbstverständlich vorher den Gegebenheiten anzupassen (siehe Abbildung 7). set serveroutput on declare db_ready boolean; begin db_ready := dbms_tdb.check_db( 'Linux 64-bit for AMD', dbms_tdb.skip_none); end; / PL/SQL procedure successfully completed. Abb. 3: Skript zum Aufruf der Funktion DBMS_TDB.CHECK_DB. set serveroutput on declare external boolean; begin external := dbms_tdb.check_external; end; Transport Skript The following directories exist in the database: SYS.DATA_PUMP_DIR, SYS.ADMIN_DIR, SYS.WORK_DIR Nun schauen wir uns das Transport Skript näher an, das RMAN für uns gebaut hat (siehe Abbildung 6). Wir stellen fest, dass es sich um ein ganz normales create controlfile Skript PL/SQL procedure successfully completed. Abb. 4: Skript zur Ermittlung von externen Tabellen, BFILEs und directories. CONVERT DATABASE NEW DATABASE 'newdb' transport script '/tmp/transport/transportskript' to platform 'Linux 64-bit for AMD' db_file_name_convert '/oradata/ak102' '/tmp/transport'; ------------------------------------------------------------Starting convert at 05.04.06 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=42 devtype=DISK Directory SYS.DATA_PUMP_DIR found in the database Directory SYS.ADMIN_DIR found in the database Directory SYS.WORK_DIR found in the database User SYS with SYSDBA and SYSOPER privilege found in password file channel ORA_DISK_1: starting datafile conversion input datafile fno=00001 name=/oradata/ak102/system01.dbf converted datafile=/tmp/transport/system01.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:35 channel ORA_DISK_1: starting datafile conversion ... Run SQL script /tmp/transport/transportskript on the target platform to create database Edit init.ora file /oracle/product/10.2/dbs/init_00hfpe8c_1_0.ora. This PFILE will be used to create the database on the target platform To recompile all PL/SQL modules, run utlirp.sql and utlrp.sql on the target platform To change the internal database identifier, use DBNEWID Utility Finished backup at 05.04.06 Abb. 5: Kommando und Ergebnis für die Konvertierung einer Datenbank mit CONVERT DATABASE . ORDIX News 2/2006 27 Datenbanken STARTUP NOMOUNT PFILE='/oracle/product/10.2/dbs/init_00hfpe8c_1_0.ora' CREATE CONTROLFILE REUSE SET DATABASE "NEWDB" RESETLOGS ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 1168 LOGFILE GROUP 1 ( '/oracle/product/10.2/dbs/arch_D-NEWDB_id-3659488684_S-145_T-1_A-565987116_00hfpe8c', '/oracle/product/10.2/dbs/arch_D-NEWDB_id-3659488684_S-145_T-1_A-565987116_01hfpe8c' ) SIZE 10M, ... DATAFILE '/tmp/transport/system01.dbf', '/tmp/transport/undotbs01.dbf', '/tmp/transport/sysaux01.dbf', '/tmp/transport/users01.dbf' CHARACTER SET WE8ISO8859P1; ALTER DATABASE OPEN RESETLOGS; ALTER TABLESPACE TEMP ADD TEMPFILE '/oracle/product/10.2/dbs/data_D-NEWDB_I-3659488684_TS-TEMP_FNO-1_00hfpe8c' SIZE 20971520 AUTOEXTEND ON NEXT 655360 MAXSIZE 536870912 ; set echo off prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ prompt * Your database has been created successfully! prompt * There are many things to think about for the new database. Here prompt * is a checklist to help you stay on track: prompt * 1. You may want to redefine the location of the directory objects. prompt * 2. You may want to change the internal database identifier (DBID) prompt * or the global database name for this database. Use the prompt * NEWDBID Utility (nid). prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SHUTDOWN IMMEDIATE STARTUP UPGRADE PFILE='/oracle/product/10.2/dbs/init_00hfpe8c_1_0.ora' @@ ?/rdbms/admin/utlirp.sql SHUTDOWN IMMEDIATE STARTUP PFILE='/oracle/product/10.2/dbs/init_00hfpe8c_1_0.ora' -- The following step will recompile all PL/SQL modules. -- It may take serveral hours to complete. @@ ?/rdbms/admin/utlrp.sql set feedback 6; Abb. 6: Transport Skript. # Please change the values of control_files db_recovery_file_dest db_recovery_file_dest_size background_dump_dest user_dump_dest core_dump_dest audit_file_dest db_name the following parameters: = "/oracle/product/10.2/dbs/cf_D-NEWDB_id-3659488684_00hfpe8c" = "/oracle/product/10.2/dbs/flash_recovery_area" = 2147483648 = "/oracle/product/10.2/dbs/bdump" = "/oracle/product/10.2/dbs/udump" = "/oracle/product/10.2/dbs/cdump" = "/oracle/product/10.2/dbs/adump" = "NEWDB" # Please review the values of __shared_pool_size __large_pool_size __java_pool_size __streams_pool_size __db_cache_size remote_login_passwordfile db_domain the following parameters: = 54525952 = 4194304 = 4194304 = 0 = 37748736 = "SHARED" = "" # The values of the following parameters are from source database: processes = 50 sessions = 60 sga_max_size = 104857600 nls_territory = "GERMANY" sga_target = 104857600 db_block_size = 8192 compatible = "10.2.0.1.0" db_file_multiblock_read_count= 16 db_flashback_retention_target= 120 undo_management = "AUTO" undo_tablespace = "UNDOTBS1" job_queue_processes = 10 open_cursors = 300 pga_aggregate_target = 16777216 Abb. 7: Das von CONVERT DATABASE angelegte pfile. 28 ORDIX News 2/2006 Datenbanken Fazit Glossar Recovery Manager (RMAN) Transportable Tablespace Externe Tabellen BFILE Directory Oracles Tool zur Sicherung von Oracle Datenbanken. Ein Verfahren, um sehr einfach und schnell Table­spaces von einer Oracle Datenbank in eine andere zu übertragen. Tabellen, die in der Datenbank definiert, deren Daten aber außerhalb gespeichert sind. Binäre Daten, die im Filesystem gespeichert werden, aber auf die mit Datenbankmitteln zugegriffen werden kann. Ein directory definiert einen Alias für ein Verzeichnis im Filesystem. Sind alle Dateien auf das neue System gespielt, das „Transport Skript“ und das Pfile angepasst, so steht – letztlich mit vergleichsweise wenig Aufwand – die Datenbank auf einem neuen Server zur Verfügung. Allerdings funktioniert das in dieser Form nur für ei­ne „endian Variante“. Oracle hat uns jedoch bereits mit 10g R1 gezeigt, dass es möglich ist, Tablespaces von einer Plattform auf eine beliebige andere Plattform zu migrieren. Von daher ist CONVERT DATABASE zwar eine gute Idee, aber vollständig ist das Ganze erst, wenn man damit Datenbanken beispielweise von Windows nach Solaris Sparc konvertieren kann. Sie wollen mehr über Oracles Recovery Manager (RMAN) erfahren? Besuchen Sie den 4-tägigen ORDIX Recovery Manager Workshop. Weitere Informationen zu diesem Workshop finden Sie in unserem Online-Trainingsshop unter http://training.ordix.de. Andreas Kother ([email protected]). Verlosung Chess Classic Mainz 2006 ORDIX Open: Hol dir den Titel! Pony auf E7 ! Pünktlich zum Sommer erwartet die Rheingoldhalle in Mainz wieder die Schachprominenz. Vom 15. - 20. August 2006 wird u. a. wieder heiß um den Sieg im ORDIX Open, dem höchstdotierten und weltgrößten Schnellschachturnier gerungen. Das ORDIX Open und die Chess Classic sind mittlerweile eng verwachsen. Seit nunmehr 13 Jahren ist ORDIX als Sponsor mit von der Partie. So hat das Turnier auch in diesem Jahr wieder einen festen Stammplatz im Programm – das Wochendende 19./20.08.2006. Haben Sie Ausdauer? 13 Jahre ORDIX Open und 11 Runden spannende Spielstrategien. Halten Sie diese geistige Anspannung 11 Runden lang aus? Wollen Sie sich der Herausforderung stellen und die gigantischen Momente genießen? Wollen Sie einer von rund 500 Spielern sein, die Runde für Runde schwitzen und einem weiteren Sieg entgegenfiebern, um dem Titel „ORDIX Open Gewinner 2006“ etwas näher zu kommen? ORDIX News 2/2006 Wir geben Ihnen die Chance, dabei zu sein Werden Sie Teilnehmer im ORDIX Open oder spielen Sie im Simultan an einem der 40 Bretter gegen die Anführer der Weltrangliste. Senden Sie einfach eine E-Mail mit dem Stichwort: „Chess Classic 2006“ bis zum 14.07.2006 an [email protected]. Unter den ersten 50 Einsendern verlosen wir • 2 Plätze für das ORDIX Open am 19. und 20.08.2006 • 1 Platz im Simultan gegen Viswanathan Anand am 15.08.2006 • 1 Platz im Simultan am 16.08.2006 (Gegner noch offen) Der Rechtsweg sowie die Teilnahme von ORDIX Mitarbeitern und deren Angehörigen sind ausgeschlossen. Stefanie Heither ([email protected]). 29 Unix/Linux/Open Source Spieglein, Spieglein ... 100 % MySQL – Wie richte ich ein Cluster ein? Bereits in der letzten Ausgabe haben wir in dem Artikel „MySQL 5 - The Next Generation“ (siehe ORDIX News 1/2006, Seite 30) beschrieben, dass es ein erklärtes Ziel der Firma MySQL AB ist, den etablierten Datenbankherstellern das Leben ein wenig schwerer zu machen. Höchste Zeit also, um sich einmal mit dem aktuellen Entwicklungsstand der Clusterlösung von MySQL zu beschäftigen. Der Artikel beschreibt die exemplarische Installation eines MySQL-Clusters. Der Artikel richtet sich an MySQL-Datenbankadministratoren, die ein Interesse an der Hochverfügbarkeit ihrer MySQL-Applikationen haben. Vorabinformation Die MySQL Architektur besteht aus zwei „Bereichen“. Auf der einen Seite sorgt der mysqld-Prozess für die Verarbeitung der Zugriffe inklusive der Koordination der notwendigen Prozesse und der Organisation der Hauptspeicherbereiche. Auf der anderen Seite stehen die Storage-Engines. Sie sind für das Schreiben und Lesen der eigentlichen Daten zuständig. Derzeit stehen circa 10 unterschiedliche Storage-Engines für unterschiedliche Anforderungsbereiche zur Verfügung [1]. NDB – Network Database Der Einfachheit halber gibt es für den Cluster-Betrieb auch eine eigene Storage-Engine: Network Database (NDB). Es ist allerdings darauf zu achten, dass diese Storage-Engine nur in den Download­ paketen [2] enthalten ist, welche in ihrem Namen die Erweiterung Anwender / Applikationen User Web-Shop JBoss mysqld ManagementServer ManagementClient ManagementNode mysqld SQL-Nodes ndb (Master) ndb Storage-Nodes Abb. 1: Die SQL- und Storage-Nodes werden vom Management-Server koordiniert. 30 „-max“ tragen. Einschränkungen gibt es aktuell leider noch hinsichtlich der Datenbankgröße und der Fremdschlüsselunterstützung. Sämtliche Daten einer Cluster-Datenbank werden momentan im Hauptspeicher der „StorageNodes“ gehalten, so dass die Größe des Hauptspeichers gleichzeitig die Größe der Datenbank limitiert. Dieses Verhalten wird mit der nächsten MySQL Version 5.1 jedoch hinfällig sein. Weitere aktuelle Einschränkungen der Storage-Engine NBD und deren geplante Weiterentwicklung finden Sie im Internet auf verschiedenen Webseiten [3, 4]. Unteilbar Der MySQL-Cluster bzw. die NDB-StorageEngine setzt auf eine Share-Nothing-Strategie. Dies bedeutet, dass die an dem Cluster betei­ligten Rechner keinerlei Hardware gemeinsam verwenden. Dies hat zwei Vorteile: 1. Es ermöglicht den Einsatz von preiswer­ ter Hardware. 2. Damit wird automatisch ein „Single Point of Failure“ (zumindest, was die Rechnerkomponenten betrifft) vermieden, da jeder Rechner seine eigenen Platten, seinen eigenen Speicher und seine eigene(n) CPU(s) besitzt. Dieser Ansatz muss natürlich auch auf alle anderen Elemente im Cluster übertragen werden. So sollten z. B. redundante Netzwerkkarten, redundante Stromversorgungen usw. Verwendung finden, um nicht an einer anderen Stelle einen Engpass zu generieren. Funktionsweise Um einen Cluster aufzusetzen braucht es mindestens drei Rechner: ORDIX News 2/2006 Unix/Linux/Open Source Zwei Rechner sollten dabei die Verwaltung der Daten übernehmen, also die NDB StorageEngines betreiben (Storage-Nodes). Zusätzlich können diese Rechner auch die mysqldProzesse (SQL-Nodes) betreiben, über welche die Applikationen bzw. Anwender ihre Anfragen absetzen. Der dritte Rechner sorgt für die Organisation der Storage- und SQL-Nodes und übernimmt deren Überwachung (Management-Node). Für unser Installationsbeispiel haben wir jedoch ein erweitertes Szenario gewählt. Hier übernehmen zwei separate Rechner die Rolle der SQLNodes, so dass insgesamt fünf Rechner (siehe Abbildung 1) an dem Cluster beteiligt sind: • 1 Management-Node • 2 Storage-Nodes • 2 SQL-Nodes Storage- und SQL-Nodes Die Installation eines Clusters sollte mit den Storage-Nodes beginnen. Dazu wird, wie gewohnt, die MySQL-Software installiert. Wahlweise kann man sich die Quell- oder Binärpakete herunterladen [5]. Beim Installieren eines Quellpaketes sollte unbedingt darauf geachtet werden, dass die Option –with-db-cluster aktiviert sein muss. Die Konfiguration der Storageknoten im Anschluss an die Installation ist unproblematisch. In der entsprechenden Konfigurationsdatei (unter Linux z. B. /etc/my.cnf) muss lediglich hinterlegt werden, dass diese My­SQL-Installation Teil eines Clusters ist. Zusätzlich muss definiert werden, wo sich der dazugehörige Management-Node befindet. Die Installation der SQL-Nodes vollzieht sich genau nach demselben Muster (siehe Beispiel einer Konfigurationsdatei in Abbildung 2). Die unterschiedlichen Aufgaben der Storageund SQL-Nodes ergeben sich – trotz einer iden­ tischen Konfiguration – später durch den Start unterschiedlicher Dienstprogramme auf den Nodes. Management-Node Für die Installation des Management-Nodes sind aus dem MySQL-Paket eigentlich nur zwei Programme notwendig. Aus dem Binärpaket können diese direkt extrahiert und auf dem Server abgelegt werden: .../bin/ndb_mgm (Management-Client) .../bin/ndb_mgmd (Management-Server) ORDIX News 2/2006 [mysqld] ndbcluster [mysql_cluster] ndb-connectstring = 172.17.30.100 # IP of Management Server Abb. 2: Zwei Zeilen reichen aus, um einen Storage-Node zu konfigu­ rieren. [NDBD DEFAULT] NoOfReplicas =2 # Anzahl der beteiligten Storage-Nodes [MYSQLD DEFAULT] [NDB_MGMD DEFAULT] [TCP DEFAULT] [NDB_MGMD] HostName = 172.17.30.100 # IP des Management-Node [NDBD] HostName = 172.17.30.101 # 1. Storage-Node DataDir = /var/lib/mysql-cluster # Datenverzeichnis vom 1. Storage-Node [NDBD] HostName = 172.17.30.102 # 2. Storage-Node DataDir = /var/lib/mysql-cluster # Datenverzeichnis vom 2. Storage-Node [MYSQLD] HostName = 172.17.30.103 # 1. SQL-Node [MYSQLD] HostName = 172.17.30.104 # 2. SQL-Node Abb. 3: Der Management-Node kennt die beteiligten Rechner und ihre spezifischen Aufgaben. Der Management-Server stellt im Cluster die zentrale Kommunikationsplattform dar und regelt die Verteilung der Aufgaben zwischen den beteiligten Systemen. Über den Management-Client können aktuelle Statusinformationen über die Systeme bezogen, sowie einige „Verwaltungsaktionen“ für die Clusterkomponenten veranlasst werden. Darüber hinaus sollte für den Management-Server ein eigenes Arbeitsverzeichnis angelegt werden, welches die Konfigurationsdatei des Management-Nodes und später die erzeugten Logfiles des Clusters aufnehmen kann (unter Linux z. B. /var/lib/mysql-cluster). Die Konfiguration ist im Gegensatz zu den Storage- und SQL-Nodes etwas umfangreicher, da der Management-Node alle am Cluster beteiligten Rechner und Aufgaben kennen muss (siehe Abbildung 3). Startup Nachdem alle Komponenten installiert und konfiguriert sind, kann der Cluster gestartet werden. Als erste Komponente sollte der Management-Server hochgefahren werden, da dieser den anderen Nodes ihre Rolle im Cluster zuweist. Dies geschieht über den Start des entsprechenden Dienstes: ndb_mgmd 31 Unix/Linux/Open Source Connected to Management Server at: localhost:1186 Cluster Configuration --------------------[ndbd(NDB)]2 node(s) [email protected] (Version: 5.0.18, Nodegroup: 0, Master) [email protected] (Version: 5.0.18, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) [email protected] (Version: 5.0.18) [mysqld(API)] 2 node(s) [email protected] (Version: 5.0.18) [email protected] (Version: 5.0.18) StorageNode1 (Master) 03) Weiter 3) Weiter arbeiten!!! arbeiten!!! 2) Soll ich übernehmen? StorageNode2 ManagementServer Abschließend werden die SQL-Nodes aktiviert. Auf diesen startet man, wie bei „gewöhnlichen“ MySQL-Servern, den mysqld-Prozess mit den betriebssystemspezifischen Startskripten (unter Linux: /etc/init.d/mysql.server start). Damit ist der Cluster einsatzbereit. Kontrolle Abb. 4: Über den Management-Client erfahren wir die Rollenverteilung im Cluster. Zunächst werden die Storage-Nodes, dann der Management-Node und anschließend die SQL-Nodes ausgegeben (vgl. Abb. 3). 1) Ausfall der redundanten Heartbeat-Verbindung Anschließend werden die Storage-Nodes eingebunden. Dies erfolgt über den Start des MySQL-Dienstes „ndb“, welchem beim allerersten Start die Option - -initial spendiert werden muss: ndb (--inital) 03) Nicht 3) Nicht übernehmen!!! übernehmen!!! Abb. 5: Split-Brain-Problem: Bei einem Ausfall der direkten Leitung zwischen zwei Storage-Nodes muss eine dritte Instanz entscheiden, wer weiterhin als Master fungiert. Ansonsten würden in diesem Fall beide Storage-Nodes die Rolle des Masters übernehmen. Nach dem Start der Komponenten sollte überprüft werden, ob die Nodes ihre Aufgaben auch zuverlässig übernommen haben. Dazu kann auf dem Management-Node (oder auf allen an­deren im Cluster befindlichen Rechnern) der entsprechende Client (ndb_mgm) genutzt werden. Über das Kommando ndb_mgm –e show werden alle aktiven Nodes mit ihren entsprechen­ den Aufgaben und Stati ausgegeben (siehe Ab­bildung 4). Im Prinzip könnte der Management Node nun wieder heruntergefahren werden, da alle beteiligten Rechner ihre Aufgaben und „Partner“ kennen. Die reine Überwachung der Verfügbarkeit wird auch von den Storage-Nodes alleine gewährleistet. Es gibt aber gute Gründe, warum der Management-Node weiter aktiv bleiben sollte. Über ihn können einzelne Nodes z. B. ab- oder dazugeschaltet werden oder es können auf den einzelnen Nodes Backups gestartet und auch wieder eingespielt werden. Schizophrenie [t1] ... [ndbd(NDB)]2 node(s) id=2 (not connected, accepting connect from 172.17.30.101) [email protected] (Version: 5.0.18, Nodegroup: 0, Master) ... [t2] ... [mysqld(API)] 3 node(s) id=4 (not connected, accepting connect from 172.17.30.103) [email protected] (Version: 5.0.18) Abb. 6: [t1] Ausfall des ersten Storage-Nodes. Der zweite StorageNode wird im Bruchteil einer Sekunde zum neuen Master und übernimmt alle eingehenden Verbindungen. [t2] Ausfall des ersten SQL-Nodes. Die Applikationen und Anwender müssen jetzt über den zweiten SQL-Node auf ihre Daten zugreifen. 32 Wie eben bereits beschrieben, sind die Storage-Nodes auch ohne den Management-Server in der Lage, den Ausfall eines Systems zu erkennen. Allerdings gibt es einen Problemfall, bei dem die zusätzliche Überwachungsfunktionalität des Management-Nodes benötigt wird. Sind die Storage-Nodes an zwei unterschiedlichen Standorten positioniert und kommt es zu einem Ausfall der Kommunikationsleitung (Heartbeat-Überwachung), so weiß keiner der beteiligten Storage-Nodes, ob der Partner ausgefallen oder derzeit aufgrund eines Netzwerk­ ausfalls nur nicht zu erreichen ist (Split Brain Problem). ORDIX News 2/2006 Unix/Linux/Open Source Links: ► ► ► ► ► [1] http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html [2] http://mysql.speedbone.de/downloads/mysql/5.0.html [3] http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-limitations.html [4] http://dev.mysql.com/doc/refman/5.0/en/mysql-5-1-cluster-roadmap.html [5] http://dev.mysql.com/downloads/ Es bedarf also einer Kontrollinstanz (Management-Node), die entscheidet, welcher StorageNode weiter als Master fungiert. Dazu ist es natürlich notwendig, dass der ManagementNode über eine separate Anbindung an die betroffenen Storage-Nodes verfügt (siehe Abbidung 5). Crash & Failover Jetzt ist es an der Zeit, einige Crash-Szenarien zu simulieren und die Ausgabe des Management-Client (auf dem Management-Node) zu beobachten. Im ersten Schritt wird der 1. Storage-Node physikalisch ausgeschaltet (siehe Abbildung 6, [t1]). Ohne Probleme übernimmt der 2. Storage-Node seine neue Rolle als Master. Zusätzlich wird danach ein SQL-Node „beseitigt“. Die Applikationen und Anwender müssen nun über den anderen, verbliebenen SQL-Node auf ihre Daten zugreifen (siehe Abbildung 6, [t2]). Für den Zugriff auf den richtigen SQL-Node ist in unserem Fall die Applikation selbst verantwortlich. Sie muss selbst erkennen, dass der SQL-Node 1 nicht mehr verfügbar ist und auf den 2. SQL-Node umschwenken. Dieses Problem kann natürlich auch anders gelöst werden. Denkbar wäre z. B. der Einsatz eines Load Balancers, der im Normalfall (wenn alle SQL-Nodes arbeiten) die Anfragen gleichmäßig auf die verfügbaren Dienste verteilt. Glossar Cluster Eine Gruppe von vernetzten Computern, die von außen in vielen Fällen als ein Computer gesehen werden kann. Ziel des „Clustering“ besteht meistens in der Erhöhung der Rechengeschwindigkeit und/oder der Verfügbarkeit gegenüber einem einzelnen Computer. Node Der Begriff Node (Knoten) bezeichnet einen einzelnen Rechner in einem Cluster. Oftmals ist ein Node mit einer bestimmten Aufgabe betraut. Storage Node Node zum Schreiben und Lesen von Daten. SQL-Node Node für die Annahme und Verarbeitung der Anfragen von Applikationen und Usern Management Node Node zur Verwaltung und Kontrolle der anderen Knoten Single Point of Failure Unter einem Single Point of Failure oder kurz SPoF versteht man eine Komponente im Cluster, deren Ausfall den Komplettausfall des Clusters nach sich zieht. Split Brain Ein Zustand in einem Cluster, in dem sich mehrere (Storage-)Nodes im aktiven Modus befinden. ter für viele Anwendungsbereiche eine interessante Alternative werden. Besonders die Verarbeitung von größeren Datenmengen, unabhängig von der Hauptspeichergröße, muss schnellstmöglich gelöst werden. Beim Verlust eines SQL-Nodes verteilt der Load Balancer die Anfragen dann auf die verbleiben­ den Systeme. Fazit Im Portfolio der Firma MySQL AB ist der Cluster noch ein relativ neues Produkt. Die Einschränkungen der NDB-Engine sind derzeit deutlich spürbar. Wenn diese Beschränkungen, wie in der Roadmap [4] versprochen, in der nächsten Version beseitigt werden, dürfte der MySQL-Clus- ORDIX News 2/2006 Matthias Jung ([email protected]). 33 Datenbanken PL/SQL Web-Services (Teil II) Oracle stellt verschiedene Möglichkeiten zur Verfügung, um mit Web-Services zu kommunizieren. Im ersten Teil (siehe ORDIX News 4/2005, Seite 30) zeigten wir auf, wie existierende PL/SQL-Programme ohne großen Aufwand als Web-Services zur Verfügung gestellt werden können. Dieser Teil skizziert, wie mit der Datenbankprogrammiersprache PL/SQL Web-Services aufgerufen werden können. Es werden einige Alternativen anhand von Beispielen vorgestellt. Dieser Artikel richtet sich an Software-Entwickler, die mit der Datenbankprogrammiersprache PL/SQL Web-Services aufrufen wollen. SQL-Package UTL_HTTP kann also unter anderem auch dazu verwendet werden, WebServices aus einem PL/SQL-Programm aufzurufen. Einführung und Motivation Anwendungsbeispiel mit UTL_HTTP In einer Serviceorientierten Architektur (SOA) ist die Anbindung der einzelnen Systemkomponenten an Web-Services von besonderer Bedeutung. Damit auch eine Datenbank die vielen Vorteile von Web-Services (siehe Teil 1) nutzen kann, stellt Oracle mehrere Möglichkeiten zur Verfügung, um direkt aus der Datenbank heraus Web-Services aufzurufen (siehe Abbildung 1). Grundsätzlich stehen folgende drei Alternativen zur Verfügung, die wir anhand von Programmbeispielen erläutern: A) UTL_HTTP PL/SQL-Package B) Java Stored Procedure C) UTL_DBWS PL/SQL-Package A) Alternative mit UTL_HTTP PL/SQL-Package Die Kommunikation zwischen Client und Server findet bei WebServices über das HTTP-Standardprotokoll statt. Das HTTP-Standardprotokoll wird in Oracle mit Hilfe des PL/SQL-Packages UTL_ HTTP unterstützt. Dabei besteht die Möglichkeit, aus einem SQL- oder PL/SQL-Programm Daten über das HTTP-Protokoll auszutauschen. Das PL/ Oracle-DB PL/SQL HTTP SOAP/XML Internet HTTP SOAP/XML Web-Services Abb. 1: Web-Services Call-Out – Die Datenbank als Web-Services Konsument. Ein Beispielprogramm, das zeigt, wie aus ei­ nem PL/SQL-Programm ein Web-Service zur Ermittlung der ORDIX Seminarpreise gestartet wird, finden Sie unter http://www.ordix.de/ ORDIXNews. Dort wird zuerst mit Hilfe der Prozedur ER­ STELLE_ENVELOPE eine SOAP-Nachricht zum Aufruf des Web-Services zusammengestellt. Abbildung 2 zeigt ein Beispiel einer solchen SOAP-Nachricht. Anschließend wird mit der Funktion STARTEHTTP die mit ERSTELLE_ ENVELOPE erstellte SOAP-Nachricht über das PL/SQL-Package UTL_HTTP aufgerufen. Web-Service Response wird im XMLTYPE abgelegt Das Ergebnis des Web-Services „ORDIX Seminarpreise“ (siehe Abbildung 3) wird in einem Datentyp XMLTYPE abgespeichert. Der Datentyp XMLTYPE steht ab Oracle9i zur Verfügung und ermöglicht die Speicherung von XML-Daten in der Datenbank (siehe „Oracle und XML: Ein besonderer Cocktail“ in der ORDIX News 1/2006, Seite 40). Das besondere an dem Datentyp XMLTYPE ist, dass durch diesen SQL-Operationen auf XML-Inhalte und XML-Operationen auf SQLInhalte möglich sind. XML­TYPE liefert außerdem spezielle Funktionen zum Erzeugen, Ex- <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <holePreis xmlns="urn:pck_seminar" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <OrdixSeminar xsi:type="xsd:string">Java Grundlagen</OrdixSeminar> </holePreis> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Abb. 2: Die SOAP-Nachricht zum Aufruf eines Web-Services. 34 ORDIX News 2/2006 Datenbanken trahieren und Indizieren von XML-Daten in einer Datenbank. Anschließend wird der Rückgabewert des WebServices – hier der ORDIX Seminarpreis – mit Hilfe der XMLTYPE-Funktion EXTRACT aus der XML-Struktur herausgelöst und ausgege­ ben. B) Alternative mit Java Stored Procedure Eine Java Stored Procedure ist eine mit der Programmiersprache Java erstellte StoredProcedure. Innerhalb einer Java Stored Procedure besteht die Möglichkeit, einen WebService direkt aufzurufen. Voraussetzungen für einen Web-ServiceZugriff aus einer Java Stored Procedure Soll aus einer Java Stored Procedure, die sich innerhalb einer Oracle Datenbank befindet, ein Web-Service aufgerufen werden, so müssen zuerst die SOAP-Klassen, die in der Datei ORACLE_HOME\oc4j\soap\lib\soap.jar vorhanden sind, in eine Datenbank unter dem Datenbankbenutzer SYS geladen werden (siehe Abbildung 4). Um das SOAP-Protokoll in der Datenbank nutzen zu können, müssen dem entsprechenden Datenbankbenutzer, der den Web-Service auf­ rufen soll, die PropertyPermission- und Socket­ Permission-Rechte vergeben werden (siehe Abbildung 5). Java-Stub-Klasse Außerdem wird eine so genannte Java-StubKlasse zum Aufruf des Web-Services benötigt. Eine Java-Stub-Klasse dient als Web-ServiceClient und kann z. B. mit Hilfe von JDeveloper (in der „New Gallery“ unter „Web Services“ und „Web Service Stub/Skeleton“) erstellt werden. Auch ein Beispiel für eine solche Java-StubKlasse finden Sie im Internet unter http://www. ordix.de/ORDIXNews. Die Java-Stub-Klasse muss ebenfalls in die Da­ tenbank geladen werden (siehe Abbildung 6). Hierbei ist darauf zu achten, dass die Methoden in der Java-Stub-Klasse, die den Web-Service aufrufen, mit der Eigenschaft STATIC deklariert sind. Denn innerhalb einer Datenbank können nur STATIC Methoden aufgerufen werden. PL/SQL-Wrapper Um den Zugriff aus der Datenbankprogrammiersprache PL/SQL auf die Java-Stub-Klasse zu ermöglichen, muss ein so genannter PL/SQLWrapper für die innerhalb der Datenbank vor- ORDIX News 2/2006 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <holePreisResponse xmlns="urn:pck_seminar" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <return xsi:type="xsd:decimal">1800</return> </holePreisResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Abb. 3: Der Web-Service liefert das Ergebnis als SOAP-Nachricht zurück. loadjava -u sys/passwd@orcl10 -r -v -s -grant PUBLIC soap.jar Abb. 4: Verschiedene SOAP-Klassen in eine Datenbank laden. exec dbms_java.grant_permission ('USER1', 'SYS:java.util.PropertyPermission', '*', 'read,write'); exec dbms_java.grant_permission ('USER1', 'SYS:java.net.SocketPermission', 'localhost', 'resolve'); Abb. 5: Privilegien für den Java Stored Procedure Eigentümer vergeben. loadjava -user user1/passwd@orcl10 -resolve -verbose Pck_seminarStub.java Abb. 6: Die Java-Stub-Klasse in die Datenbank laden. CREATE OR REPLACE FUNCTION holePreis(kurs VARCHAR2) RETURN NUMBER AS LANGUAGE JAVA NAME 'Pck_seminarStub.holePreisWebService(java.lang.String) return java.lang.BigDecimal'; / show errors Abb. 7: Einen PL/SQL-Wrapper für eine Java-Stub-Klasse erstellen. SQL> SELECT holePreis('Java Grundlagen') Seminar_Preis FROM dual; SEMINAR_PREIS ------------1600 Abb. 8: Die Java Stored Procedure holePreis starten. handenen Java-Stub-Klassen erstellt werden (siehe Abbildung 7). Ein PL/SQL-Wrapper kann wiederum wie eine herkömmliche PL/SQLStored Function gestartet werden (siehe Abbildung 8). C) Alternative mit UTL_DBWS PL/SQL-Package Ab der Oracle Version 10g stellt Oracle für die Kommunikation mit Web-Services ein neues PL/SQL-Package UTL_DBWS zur Verfügung. Mit diesem Package ist es ebenfalls möglich, aus der Datenbankprogrammiersprache PL/SQL Web-Services aufzurufen. Voraussetzungen für das PL/SQL-Package UTL_DBWS Um das PL/SQL-Package UTL_DBWS verwenden zu können, muss die Datei utl_dbws_jserver.jar in die Datenbank geladen wer­ den. 35 Datenbanken Die aktuelle utl_dbws_jserver.jar Datei kann auf der Ora­cle Internet­seite [1] heruntergeladen werden und z. B. mit dem Programm LOADJAVA in eine Datenbank unter dem Datenbankbenutzer SYS geladen werden (siehe Abbildung 9). Außerdem muss für das Package UTL_DBWS ein PUBLIC SYNONYM erstellt werden (siehe Abbildung 10). Beispielprogramm mit PL/SQL-Package UTL_DBWS Der Zugriff auf einen Web-Service erfolgt mit Hilfe des Packages UTL_DBWS. Auch hierzu finden Sie ein Beispielprogramm im Internet unter http://www.ordix.de/ORDIXNews. Zuerst werden eine Service-Instanz und eine Call-Instanz erzeugt. Diese beiden Instanzen werden benötigt, um Eigenschaften wie unter anderem URL-Adresse, Operationen oder Encodingstyle-URI zu definieren und anschließend den Web-Service aufzurufen. Außerdem werden Parameter hinzugefügt und der Datentyp des Rückgabewertes definiert. Schließlich werden mit der Funktion UTL_DBWS.INVOKE der vorher definierte Web-Service aufgerufen und die Rückgabewerte ausgegeben. loadjava -u sys/passwd@orcl10 -r -v -f -s -grant public -noverify -genmissing utl_dbws_jserver.jar Abb. 9: Die Datei utl_dbws_jserver.jar in eine Datenbank laden. CREATE PUBLIC SYNONYM UTL_DBWS FOR SYS.UTL_DBWS; Abb. 10: Ein Public Synonym für das PL/SQL-Package UTL_DBWS erstellen. Links ► http://www.oracle.com/technology/sample_code/tech/java/jsp/ dbwebservices.htm Glossar XML Extensible Markup Language. XML ist eine so genannte Meta-Sprache zur Beschreibung von Dokumenten. Ein Vorteil von XML ist der vereinfachte Austausch von Daten, da XML-Formate in einer strengen Grammatik defi­niert werden können und so die Implementierung von zuverlässigen Schnittstellen erlaubt. SOAP Simple Object Access Protocol ist ein Protokoll, mit dem Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. JDeveloper JDeveloper ist eine grafische Entwicklungsumgebung von Oracle für die Programmiersprache Java und die Datenbankprogrammiersprache PL/SQL. STATIC Mit dem Schlüsselwort STATIC kann eine Methode in der Program­miersprache Java als eine Klassenmethode deklariert werden. Das besondere an einer Klassen­ methode ist, dass diese zu einer Klasse und nicht zu einem Objekt gehört. Außerdem ist im Speicher immer nur eine Kopie einer Klassenmethode vorhanden. 36 Vergleich der Alternativen Bei der Alternative A) mit dem PL/SQL-Package UTL_HTTP handelt es sich um eine reine PL/SQL-Lösung, die mit dem her­kömmlichen HTTP-Protokoll realisiert wurde. Diese Alternative sendet demnach einen HTTPRequest und bekommt als Antwort einen HTTPResponse. Der HTTP-Request und der HTTPResponse beinhalten jeweils eine SOAP-Nachricht im XML-Format. Dagegen verwenden die beiden anderen Alternativen B) und C) direkt das SOAP-Protokoll, das auf dem HTTP-Protokoll basiert. Performancetest Zum Vergleich der hier vorgestellten Alternativen wurde eine Messung der Zugriffszeiten auf den Web-Service „SeminarPreiseService“ vorgenommen. Die folgende Übersicht stellt die durchschnittlichen Zugriffszeiten auf den Web-Service dar. Die Messung zeigt, dass die Alternative A) (mittels UTL_HTTP) den schnellsten Zugriff auf den Web-Service ermöglicht: Alternative: A) UTL_HTTP B) Java Stored Procedures C) UTL_DBWS Durchschnittliche Zugriffszeit auf einen Web-Service in Sekunden: 0,04 0,07 0,23 Resümee In diesem Beitrag wurde aufgezeigt, wie mit der Datenbankprogrammiersprache PL/SQL auf Web-Services zugegriffen werden kann. Es wurden drei Alternativen vorgestellt, die alle zum Aufruf eines Web-Services aus einer Ora­ cle Datenbank verwendet werden können. Die Alternative A) ermöglicht dabei den schnellsten Zugriff auf einen Web-Service. Da das PL/SQL-Package UTL_DBWS noch über viele undokumentierte Funktionen verfügt und erst ab der Oracle Version 10g vorhanden ist, sollte es mit Vorsicht eingesetzt werden. Vor allem bei den Performancetests benötigt UTL_ DBWS die längsten Zugriffszeiten auf den WebService. Die beiden Varianten UTL_HTTP und Java Stored Procedure können zudem bereits in den Vorversionen von Oracle10g eingesetzt werden. Markus Fiegler ([email protected]). ORDIX News 2/2006 Datenbanken – TitelthemaDatenbanken IBM IDS 10.0 IBM Informix Dynamic Server 10.0 Neuheiten (Teil II): Das Administrieren wird einfacher für den Informix DBA Neben den neuen Sicherheits Features – wir berichteten in ORDIX News 4/2005, Seite 26 – sind mit IBM Infor­ mix 10.0 (und 9.4) einige sehr interessante Neuerungen für die beiden Backup Tools ontape und onbar hinzugekommen. Dieser Artikel stellt zunächst den Renamed Restore vor, der mit beiden Sicherungstools angewendet werden kann. Im Weiteren erfahren Sie, wie Sie eine Sicherung auf die Unix Standardausgabe über ontape umlenken und welche Vorteile sich daraus ergeben. Den ebenfalls im Release 10.0 neu eingeführten Table Level Restore stellen wir in der kommenden Ausgabe vor. Renamed Restore Der Renamed Restore wurde bereits im Release 9.4 implementiert. Seine Vorzüge möchten wir nochmals erwähnen, da sich gerade für den Bereich des Restores völlig neue Möglichkeiten gegenüber älteren Informix Versionen eröffnen. Genutzt werden kann das Feature mit den beiden Backup Tools ontape und onbar. Beide verfügen über entsprechende Optionen. Mit dem Renamed Restore kann man seit der Version IDS 9.4 Chunks in einer anderen Destination wiederherstellen. Muss eine Datenbank z. B. auf Grund einer fehlerhaften Festplatte zurückgespielt werden, so kann durch die Rename Option direkt ein anderes Device genutzt werden. Das ist besonders dann von Vorteil, wenn keine symbolischen Links verwendet wurden beziehungsweise wenn kein weiteres System zur Verfügung steht und die wiederherzustellende Datenbank nicht allein im Online-System liegt. Dieser Artikel richtet sich an Datenbankadministratoren, System­ administratoren und Entscheider. den. Über diese Funktion lassen sich ebenfalls die Offset-Adressen ändern. Anwendungsbeispiel ontape Das folgende Beispiel zeigt die Optionen des Tools ontape beim Full Restore einer Datenbank, bei dem das Root-Dbspace in eine andere Destination zurückgespielt wird. In diesem Fall werden die entsprechenden Parameter und Chunk-Namen dem Befehl direkt mitgegeben. Nach der Option –p folgt die absolute Pfadangabe des alten Chunks, nach der Option –n die absolute Pfadangabe des neuen Chunks. Die Option –o beschreibt den jeweiligen Offset. Beispiel für einen Renamed Restore mit dem Tool ontape: ontape –r –rename –p /opt/informix/dev/rootdbs_old –o 0 –n /opt/informix/dev/rootdbs_new –o 0 In der ONCONFIG-Datei, die für den Restore benutzt wird, muss der Parameter ROOTPATH identisch mit dem des Backups sein. Wird kein Rename des „Initial Chunks“ des ROOTDBS vorgenommen, so wird dieser überschrieben. Andernfalls wird die Änderung auf den neuen ROOTPATH vom Backup Tool (ontape/onbar) vor der Initialisierung des Datenbank-Servers in der ONCONFIG-Datei durchgeführt. Im Verzeichnis $INFORMIXDIR/etc wird eine Sicherheitskopie mit entsprechendem Zeitstempel der alten ONCONFIG-Datei angelegt. Im Weiteren ist somit das einfache Duplizieren von Informix Datenbankinstanzen auf dem gleichen Server System möglich, z. B. für das Duplikat der Produktivinstanz auf eine Testin­stanz. Für den Fall, dass mehrere Chunks während eines Restores umbenannt werden sollen, kann zur Vereinfachung eine ASCII-Datei verwendet werden. Diese beinhaltet die Gegenüberstellung der alten und neuen Chunk-Namen, einschließlich der Offsets (siehe Abbildung 1). Hierbei muss der Datenbankadministrator die neue Chunk-Liste jedoch sehr sorgfältig zusammenstellen, damit keine Datenbereiche der originalen Instanz überschrieben wer- Dem Restore Kommando wird dann mit der Option –f die Datei renamed_restore als Argument übergeben: ORDIX News 2/2006 ontape –r –rename –f /opt/informix/renamed_restore 37 Datenbanken /opt/informix/dev/rootdbs_old 0 /opt/informix/dev/rootdbs_new 0 /opt/informix/dev/llogdbs_old 0 /opt/informix/dev/llogdbs_new 0 /opt/informix/dev/datadbs_old 0 /opt/informix/dev/datadbs_new 0 Abb. 1: Der Aufbau der Datei renamed_restore mit altem und neuem Pfad. Die 0 beschreibt jeweils den alten bzw. neuen Offset des Chunks. Als Trennzeichen dient ein Leerzeichen (Blank). Anwendungsbeispiel onbar Einfache Umlenkung Für die Wiederherstellung mit dem Tool onbar gelten die gleichen Optionen wie in den oberen Beispielen für das ontape-Kommando. Beispiel für einen Renamed Restore mit dem Tool onbar: Möchte man einmalig eine Sicherung auf ein anderes Device schreiben, als in der ONCONFIG-Datei spezifiziert wurde (TAPEDEV), so musste man bei früheren Informix Versionen zunächst den Parameter in der Konfigurationsdatei ändern. Durch die Umlenkung der Ausgabe erspart man sich nun diesen Schritt. onbar –r –rename –p /opt/informix/dev/rootdbs_old –o 0 –n /opt/informix/dev/rootdbs_new –o 0 Für einen Renamed Restore mehrerer Chunks kann man dem Befehl onbar ebenfalls mit der Option -f eine ASCII Datei als Argument mitgeben: onbar –r –rename –f /opt/informix/renamed_restore Der Renamed Restore kann nur durchgeführt werden, wenn sich der Datenbankserver im Offline-Modus befindet. Dies gilt auch für die Wiederherstellung nicht kritischer Datenbankbereiche. Ein teilweiser Restore des Online-Systems (kritische DBSPACES und nur die nicht kritischen DBSPACES, die wirklich benötigt werden) ist ebenfalls möglich. ontape auf die Standardausgabe sichern Ab dem Release 10.00 kann man mit ontape Sicherungen auf die Standardausgabe (STDIO) umlenken, bzw. den Input beim Re­ store von der Standardeingabe lesen. Gerade für den Datenbankadministrator ergeben sich dadurch einige sehr interessante Vorteile unter Unix, da er somit den PipeMechanismus voll nutzen kann. Wir wollen das im Folgenden aufzeigen: $ ontape -s -L 0 -v -t STDIO > \ /home/informix/sicherung_01 10 percent done. 20 percent done. 30 percent done. 100 percent done. Please label this tape as number 1 in the arc tape sequence. This tape contains the following logical logs: 35 Programm over. Abb. 2: Eine Vollsicherung des Datenbanksystems wird auf die Standardausgabe (–t STDIO Option) und in der Shell für den ontapeBefehl die Standardausgabe in eine Datei umgelenkt. 38 Mit ontape –s –L 0 wird eine Vollsicherung (Level 0) des Datenbanksystems erstellt. Das Ergebnis dieses Befehls wird mit –t STDIO auf die Standardausgabe geleitet. Über eine einfache Umlenkung kann nun das Ziel des Backups angegeben werden. Abbildung 2 zeigt einen solchen Backup-Befehl. Auch beim Restore einer ontape Sicherung besteht die Möglichkeit, z. B. mittels Umlenkung von der Standardeingabe eine Sicherung zu lesen und z. B. über eine Pipe an den Re­ store-Befehl zu übergeben. In Abbildung 3 ist das ent­sprechende Kommando zu sehen. Direkte Komprimierung Sehr nützlich ist auch, z. B. die Sicherung direkt zu komprimieren, was früher nur kompliziert über Named Pipes gelöst werden konnte. Wie oben beschrieben, wird wieder eine Vollsicherung angestoßen und das Ergebnis auf die Standardausgabe umgeleitet. Über den normalen Unix Pipe-Mechanismus erfolgt dann die Komprimierung des Backups. Beispiel für die mögliche Komprimierung: ontape –s –L 0 –t STDIO | gzip > \ /home/informix/sicherung_01.gz Remoteverarbeitung Eine ontape Sicherung auf die Standardausgabe kann auch sofort remote, z. B. mittels rsh oder auch ssh weiterverarbeitet werden. Auf Server A wird eine Sicherung erstellt und remote auf Server B mit dem gleichen Befehl wiederhergestellt. Dafür wird eine fertig konfigurierte Informix Installation auf Server B vorausgesetzt. Sollte sich die Struktur der Chunks unterscheiden, ORDIX News 2/2006 Datenbanken so kann an dieser Stelle auch zusätzlich das Feature des Renamed Restores angewendet werden, um eine Wiederherstellung dennoch zu ermöglichen. Es ist allerdings wichtig, vor dem eigentlichen Restore-Befehl die nötige Informix Umgebung (Shellvariable) gesetzt zu haben, damit die Wiederherstellung auf Server B durch­geführt werden kann. Beispiel für eine Remoteverarbeitung: ontape –s –L 0 –t STDIO | rsh Server B " export INFORMIXDIR=/opt/informix/; export INFORMIXSERVER=informix; export ONCONFIG=onconfig.informix; export PATH=$INFORMIXDIR/bin:$PATH; ontape –r –t STDIO" Dieses Feature bringt dem Datenbankadministrator eine große Zeitersparnis z. B. beim Aufbau eines Produktionsabbildes für Testund Entwicklungszwecke oder auch beim Auf­ bau einer Informix HDR Hochverfügbarkeitslösung. Weitere Neuerungen im Überblick Die Konfigurationsparameter TAPESIZE und LTAPESIZE dürfen den Wert 0 annehmen. Dadurch wird die Bandkapazität der Sicherungsmedien automatisch ermittelt und komplett ausgenutzt. Für Sicherungen, die mit ontape erstellt worden sind, gibt es schon seit längerem das Kom­ mando onlog. Mit diesem Kommando kann man die gesicherten logischen Logs analysieren. Für eine Point-in-time- (onbar) bzw. Point-inLog-Wiederherstellung ist dieses Feature wichtig, um den genauen Zeitpunkt von Transaktionen zu ermitteln, die Daten zerstört haben (beispielsweise einem Anwenderfehler). Ab dem Release 10.00 steht nun auch dem Back­ up Tool onbar ein „Logical Log Display“ für archivierte logische Logs zur Verfügung. Auch im Backup- und Recovery-Umfeld wird die Integration weiterer IBM Produkte in den Informix Dynamic Server deutlich. So wird mit dem neuesten Release auch ein Tivoli Data Protector für Informix (TDPI) ausgeliefert. $ cat /home/informix/sicherung_01 | ontape \ -r -v -t STDIO Archive Tape Information Tape type: Online version: Archive date: User id: Terminal id: Archive level: Tape device: Tape blocksize (in k): Tape size (in k): Tape number in series: Archive Backup Tape IBM Informix Dynamic Server Version 10.00.UC4 Thu Mar 23 11:40:30 2006 informix /dev/pts/2 0 STDIO 32 0 1 Spaces to restore:1 [rootdbs 2 [llogdbs 3 [physdbs 4 [datadbs Abb. 3: Restore unter Verwendung von STDIO. Die Abbildung zeigt nur die ersten Zeilen. Glossar Chunk Offset ONCONFIG-Datei ROOTPATH High Data Replication (HDR) Eine Datei im Filesystem oder eine unformatierte Partition einer Festplatte, die von Informix zur Datenspeicherung genutzt wird. Bereich am Anfang eines Chunks, der nicht mit Daten beschrieben werden soll, um nicht eventuell Systeminformationen einer Festplatte zu überschreiben. Informix Konfigurationsdatei Parameter in der Informix Konfigurationsdatei Replikationsart unter Informix zur Duplizierung von Daten eines Datenbankservers auf einen weiteren. ist und eine Wiederherstellung der Struktur aufgrund eines Festplattendefektes durchgeführt werden muss. Dies kann dem Datenbankadministrator eine enorme Zeitersparnis und dem Unternehmen erhebliche Kosteneinsparungen bringen. Die Erweiterungen für das ontape Kommando, die Sicherung auf STDIO umzulenken, sind im täglichen Administratorenleben sehr hilfreich. Zusammen mit der Rename-Option besteht je nach Datenvolumen eine schnelle und einfache Möglichkeit, ein Produktionsabbild aufzubauen (auch auf demselben Server). Auch für einmalige Sicherungen auf andere Medien ist diese Funktion sehr hilfreich. Fazit In der nächsten ORDIX News berichten wir über die Neuerungen im onbar/archecker Umfeld und die Wiederherstellung einzelner Tabellen über den Table Level Restore. Der Renamed Restore ist die optimale Lösung für Informix Datenbanksysteme, auf denen nicht mit symbolischen Links gearbeitet worden Thorsten Schuhmacher ([email protected]). ORDIX News 2/2006 39 Projektmanagement Projektmanagement Coaching: Lernen ohne zu scheitern! Das erste Projekt eines angehenden Projektleiters kann durchaus ein teures Experiment werden. Erst sehr spät – meist zu spät – lässt sich erkennen, ob der Projektleiter erfolgreich war und die richtigen Entscheidungen getroffen hat. Um die Risiken im Projekt zu minimieren, bietet es sich an, dem angehenden Projektleiter einen erfahrenen Coach zur Seite zu stellen. Dieser Artikel richtet sich an angehende Projektleiter, für die aufgrund nicht ausreichender Erfahrung ein Coaching sinnvoll ist. Und er richtet sich an Entscheider, die ein Projekt an einen noch nicht ausreichend erfahrenen Projektleiter übertragen wollen oder müssen. Wie wird man Manager? In der ORDIX News 4/2005, Seite 20, haben wir deutlich gemacht, dass ein Projektmanager alle Fähigkeiten, Kompetenzen und Erfahrungen eines Managers benötigt. Umso größer ein Projekt ist, desto wichtiger wird das „Management“ in dem Wort Projektmanagement (PM). Doch die Fragen, die bleiben, sind: Wie wird man Manager? Wie lernt man Projektmanagement, ohne gleich das erste Projekt zum Scheitern zu bringen? Training ist notwendig, aber nicht hinreichend Um in der Analogie zu bleiben, gibt es inzwischen genauso, wie es Managementschulungen für Führungskräfte gibt, ein großes Angebot an Trainings im Bereich Projektmanagement. Es empfiehlt sich grundsätzlich, eine Einführungsschulung zu besuchen, bevor man sich an sein erstes Projekt wagt. Hierbei bekommt man einen Überblick über alle Phasen eines Projektes und über die wesentlichen Erfolgsfaktoren. Später sollte man begleitend zur praktischen Projektarbeit insbesondere folgende Schwerpunkte vertiefen: • Projektplanung • Change Request Management • Kommunikation im Projekt Solche Schulungsmaßnahmen sind sehr sinnvoll, aber in der Regel nicht ausreichend, um einen Projekterfolg ohne teuere Lernkurven sicherzustellen. Coaching ist gerade am Anfang wichtig In den letzten Jahren hat sich in der Managemententwicklung das professionelle Coaching durchgesetzt, um den angehenden Manager in den ersten Phasen in seiner neuen Funktion zu unterstützen. Dieses Vorgehen setzt sich immer mehr auch in dem Bereich Projektmanagement durch. Ein erfahrener (Senior-)Projektmanager wird dem neuen Projektleiter zur Seite gestellt. Er hilft ihm, sein 40 Projekt professionell aufzusetzen und durchzuführen. Gerade am Anfang eines Projektes werden die wesentlichen Entscheidungen getroffen, die den Erfolg beziehungsweise Misserfolg des Projektes entscheidend prägen. Daher ist ein Coaching gerade am Projektstart am effektivsten. Empfehlenswert ist es hier, insbesondere für die folgenden Phasen einen Coach einzusetzen: • Initiation (Zielvereinbarung, Vertrag) • Planung (Inhalt und Umfang, Arbeitspakete, Meilensteine, Terminplan, Kostenplan, Risikomanagement Planung, Ressourcenplanung etc.) Wenn das Coaching in diesen Phasen erfolgreich war, reicht es häufig in den folgenden Projektphasen aus, einen festen „Jour Fixe“ pro Woche durchzuführen, um aktuelle Fragen aus dem Projekt zu klären und den Projekterfolg insgesamt zu überwachen. Coaching in kritischen Phasen Aber auch in späteren Phasen kann ein Coaching im Projekt sinnvoll sein, z. B. dann, wenn ein Projekt in eine kritische Phase gerät: • • • • • Probleme bei der Meilensteineinhaltung Ressourcen-Engpässe Qualitätsprobleme Konflikte im Projekt Eskalationen u. ä. Auch wenn dem Projektleiter eine bestimmte, dringend benötigte Kompetenz beziehungsweise Erfahrung im Laufe des Projektes fehlt, ist das Einschalten eines PM-Coaches sinnvoll, z. B. für • das Change Request Management bei • ständigen Änderungswünschen des Auftraggebers das Change Management bei absehbar großen Veränderungen für die Nutzer des neuen Systems ORDIX News 2/2006 Projektmanagement • das PM-Controlling bei fehlender Kosten• • • und Leistungstransparenz die Team-Entwicklung bei heterogener Pro­ jektorganisation das Konfliktmanagement bei wachsenden Konflikten im Projekt das Risikomanagement bei drohenden Gefahren im Projekt Die Grundregel beim Coaching Projekt übernehmen. Ansonsten hätte das genauso fatale Auswirkungen, wie wenn sich ein Fußballtrainer selbst einwechseln würde. Der PM-Coach soll coachen und keine Tore schießen. Hindernisse überwinden Manchmal gibt es Hindernisse zu überwinden, wenn angehende Projektleiter sich fehlende Kompetenzen nicht eingestehen können oder glauben, das bisschen Projektmanagement nebenher schon leisten zu können. Eine Grundregel muss der Coach stets be­­­ach­ ten: Er arbeitet grundsätzlich und ausschließ­ lich nur mit dem Projektleiter zusammen. Gegen­ über dem Projektteam und der restlichen Projektorganisation tritt er nicht in Erscheinung und überlässt dem Projektleiter das Feld. In solchen Fällen kommt die Einsicht einer Überforderung meistens zu spät. Hier ist der Vorgesetzte gefordert, den Mitarbeiter zu überzeugen, dass es keine Form von Schwäche ist, sich professio­ nell unterstützen zu lassen. Andernfalls wird der PM-Coach schnell zum heimlichen Projektmanager und untergräbt die Entscheidungskompetenz und Autorität des offiziellen Projektleiters. Projektmanagement ist eine Kompetenz, die letztlich nur durch Praxis und Erfahrung erreichbar ist. Damit der Lernprozess nicht durch gescheiterte Projekte zu teuer wird, empfiehlt es sich, PMCoaching als risikominderndes Instrument einzusetzen. Insofern ist es insbesondere wichtig, gleich zu Beginn des Coachings die Art der Zusammenarbeit zwischen Coach und Projektleiter eindeutig zu regeln. Wichtig ist, dass beidseitig die Erwartungen, Kompetenzen und die Organisation der Zusammenarbeit geklärt sind. Grundsätzlich legt ORDIX großen Wert darauf, das Wissen schrittweise auf die Mitarbeiter des Kunden zu übertragen. Coaching ist hierfür – nicht nur im Projektmanagement – ein hervorragendes Mittel. Auch wenn die Versuchung sehr groß ist, darf der Coach niemals direkte PM-Aufgaben im Fazit Fordern Sie uns! Benedikt Georgi ([email protected]). Impressum Autoren dieser Ausgabe: Herausgeber: Sascia Brinkmann, Markus Fiegler, Andreas ORDIX AG Flügge, Benedikt Georgi, Klaus Günther, Aktiengesellschaft für Software­ent­wick­lung, Informationen zu den Chess Classic Mainz Sie unter www.chesstigers.de. Stefanie Hei­2005 ther, finden Michael Heß, Matthias Jung, Beratung,Weitere Schulung und Systemintegration, Wolf­gang Kög­ler, Andreas Kother, Beate Paderborn Stefanie Heither ([email protected]). Künneke, Michael Lindermann, Rainer Restat, Redaktion: Thorsten Schumacher Helma Jenniches, Sascia Brinkmann Copyright: V.i.S.d.P.: Wolfgang Kögler ORDIX AG. Alle Rechte vorbehalten. Eine Haftung für die Richtigkeit der Veröffentlichungen kann trotz sorgfältiger Prüfung durch die Redaktion Anschrift der Redaktion: vom Herausgeber nicht übernommen werden. ORDIX AG Westernmauer 12 - 16 Die Zeitschrift ORDIX News wird von der ORDIX AG an ausgesuchte 33098 Paderborn Kunden verteilt und kann für 2,20 Euro bestellt werden. Sie finden sowohl Tel.: 05251 1063-0 die neueste Ausgabe als auch ältere Ausgaben im Archiv der ORDIX Fax: 0180 1673490 News im Internet unter: http://www.ordix.de. Schauen Sie mal rein! Gestaltung/Layout: Sascia Brinkmann Der Kontakt zu unseren Lesern ist uns sehr wichtig. Für An­regungen, Kritik und Anmerkungen zu den Themen, aber auch für interessante Auflage: 8.900 Ideen sind wir immer offen und dankbar. Sie erreichen die Redaktion Druck: auch per E-Mail unter [email protected]. Druckerei Reike GmbH, Wir freuen uns auf Ihr Feedback. Paderborn ORDIX News 2/2006 41 Java/XML – Titelthema Hibernate Wenn der Vater mit dem Sohne ... Vererbung mit Hibernate Dass Hibernate die Persistierung von Java-Objekten in einer relationalen Datenbank wie im (Winter-)Schlaf beherrscht, zeigte der einführende Artikel in der ORDIX News 4/2005. Dass Hibernate aber nicht nur einfache Objekte, sondern auch ganze Objekthierarchien abbilden kann, zeigen wir in diesem Artikel. Der Artikel richtet sich an Softwarearchitekten und Java-Entwickler, die sich mit Vererbung und Hibernate beschäftigen. Die Klassen innerhalb einer objektorientierten Programmiersprache sind nicht nur die Summe ihrer Attribute. Die Objekte stehen auch in Beziehung zueinander, so dass es Basisklassen und davon abgeleitete Subklassen gibt. Und so ist eine Klasse nicht nur durch ihre eigenen Attribute, sondern auch durch die der Elternklasse definiert. Hibernate unterstützt als vollwertiger O/R-Mapper natürlich auch bei der Abbildung dieser Beziehungen. Die drei folgenden Ansätze werden von Hibernate zur Verfügung gestellt. • Eine Tabelle pro Klassenhierarchie • Eine Tabelle pro Subklasse • Eine Tabelle pro konkreter Klasse Für welchen Weg man sich entscheidet, hängt davon ab, wie komplex die abzubildenden Hierarchien sind. Des Weiteren bringen die verschiedenen Vorgehensweisen auch gewisse Einschränkungen mit sich, die man bei seiner Entscheidung in Betracht ziehen muss. Für die weitere Vorstellung sei die in Abbildung 1 gezeigte Hierarchie von Zahlungsarten gegeben. Zunächst gibt es eine Basisklasse Zahlung (siehe Abbildung 2), die Zahlungen im Allgemeinen beschreibt. Da ein Betrag in allen Zahlungsformen vorhanden ist, ist das Attribut Betrag innerhalb der Basisklasse zu finden. Ferner gibt es noch zwei Subklassen KreditkartenZahlung (siehe Abbildung 3) und BarZahlung (siehe Abbildung 4). In einer objektorientierten Welt erscheint dies trivial. In der Welt relationaler Datenbanken ist es grundsätzlich nicht vorgesehen. Jeder auf seine Art In diesem Zusammenhang sind daher drei beispielhafte Szenarien interessant: • Eine einfache Verknüpfung zwischen ei­nem Auftrag und einer Zahlung. • Eine Liste von Zahlungen für eine Rechnung; d. h. eine Rechnung wird nicht einmalig, sondern z. B. in Raten beglichen. public class Zahlung { protected int id; protected int betrag; protected int getId ( ) { return id; } protected void setId (int value) { id=value; } } protected int getBetrag ( ) { return betrag; } protected void setBetrag (int value) { betrag=value; } Abb. 2: Die Basisklasse Zahlung. 42 Abb. 1: Beispiel einer einfachen Vererbungshierarchie. • Eine Suche nach Zahlungen, die einen bestimmten Wert übersteigen. Wichtig ist dabei das polymorphe Verhalten einer Zahlung, wenn wir auf sie zugreifen. D. h. wenn eine Zahlung eine Kreditkartenzahlung ist, möchten wir auch direkt den Zugriff auf die Kreditkartenart haben, während bei einer Barzahlung aufgrund des Geldwäschegesetzes ab einer gewissen Höhe der Einzahler von Bedeutung ist. In den oben beschriebenen Szenarien bedeutet das, dass beim Erzeugen der Verknüpfung, der Liste und der Ergebnismenge polymorphe Objekte verwendet werden. D. h. es handelt sich dabei zwar grundsätzlich immer um Zahlungen, aber entsprechend der noch zu beschreibenden Vererbungsdefinition legt Hibernate Instanzen der entsprechenden Subklassen an. In einem Auftrag kann also hinter der Zahlung eine Kreditkarten- oder eine Barzahlung stecken. In der Liste von Zahlungen einer Rechnung und in der Ergebnismenge der Suche können dann sogar Objekte aller möglichen Ausprägungen kombiniert sein: Es finden sich in der Liste bzw. in der Ergebnismenge Objekte vom Typ KreditkartenZahlung genauso wieder wie Objekte vom Typ BarZahlung. Eine für Alle Die einfachste Art, eine Vererbungshierarchie abzubilden, ist der Ansatz der „Tabelle pro Klassenhierarchie“. Hierbei werden alle Attribute (gemeinsame, wie individuelle) innerhalb der Hierarchie in einer einzigen Tabelle gespeichert. Wie Abbildung 5 zeigt, erfolgt die Unterscheidung der Subklassen an Hand einer Discrimina- ORDIX News 2/2006 Java/XML tor-Spalte (engl. „Unterscheider“). Die Subclass-Elemente definieren dann den für sie spezifischen Wert des Discriminators. Auch wenn dies wenig administrativen Auf­wand innerhalb der Datenbank bedeutet, sollte man doch einiges beachten. So steht dieses Modell im Gegensatz zur Normalisierung, welche in relationalen Datenbanken angestrebt wird. Statt dessen werden hierbei unter Umständen sogar bewusst Daten redundant gehalten. Des Weiteren erzwingt dieser Ansatz, dass alle Attribute der Subklassen „nullable“ sind. Eine Prüfung der Datenkonsistenz für die Pflichtfelder durch einen entsprechenden „not null“-Constraint auf Datenbankebene ist also nicht möglich. Ein Vorteil ist die Tatsache, dass beim Einlesen von Daten aus der Persistenzschicht keine Tabellen miteinander verknüpft werden müssen. Fair geteilt Auch wenn der zuvor gezeigte Ansatz sehr einfach zu implementieren ist, hat er doch einige Nachteile. Insbesondere die Verletzung des Normalisierungsgrundsatzes ist ein gutes Gegenargument. Um dem Anspruch einer korrekten Normalisierung auf Datenbankseite gerecht zu werden, kann Hibernate auch individuelle Tabellen pro Subklasse einsetzen. Das Datenbankmodell entspricht dabei dann den javaseitigen Klassen. Gemeinsame Attribute der Vaterklasse liegen in der ihr zugeordneten Tabelle, die individuellen Eigenschaften der Subklassen liegen in jeweils eigenen Tabellen. Es werden insgesamt <Anzahl-Subklassen+1> Tabellen benötigt. Bei der Instanziierung lädt Hibernate dann die Daten aus der gemeinsamen wie auch aus der jeweils individuellen Tabelle. Abbildung 6 zeigt ein solches Beispiel. Innerhalb der „joined-subclass“-Elemente gibt es jeweils einen Verweis auf die Tabellen der Subklassen. Das Key-Element der Subklassen verweist jeweils auf die Spalte in der die Vaterklasse ihre ID ablegt. Innerhalb der Datenbank haben die Einträge für Subklassen jeweils immer den gleichen Primärschlüssel wie die Einträge für die Vaterklasse. Es handelt sich um 1:1-Relationen. ORDIX News 2/2006 import Zahlung; public class KreditkartenZahlung extends Zahlung { protected String kartennummer; protected String getKartennummer ( ) { return kartennummer; } protected void setKartennummer ( String value ) { kartennummer = value; } } Abb. 3: Die Subklasse KreditkartenZahlung. import Zahlung; public class BarZahlung extends Zahlung { protected String einzahler; protected String getEinzahler ( ) { return einzahler; } protected void setEinzahler ( String value ) { einzahler = value; } } Abb. 4: Die Subklasse BarZahlung. <class name="Zahlung" table="ZAHLUNG"> <id name="id" type="long" column="ZAHLUNGS_ID"> <generator class="native"/> </id> <discriminator column="ZAHLUNGS_TYP" type="string"/> <property name="betrag" column="BETRAG"/> ... <subclass name="KreditkartenZahlung" discriminator-value="KREDIT"> <property name="kartennummer" column="KARTENNUMMER"/> ... </subclass> <subclass name="BarZahlung" discriminator-value="BAR"> ... </subclass> </class> Abb. 5: Auszug aus der Zahlung.hbm.xml bei dem gewählten Ansatz „Tabelle pro Klassenhierarchie“. <class name="Zahlung" table="ZAHLUNG"> <id name="id" type="long" column="ZAHLUNGS_ID"> <generator class="native"/> </id> <property name="betrag" column="BETRAG"/> ... <joined-subclass name="KreditkartenZahlung" table="KREDITKARTENZAHLUNG"> <key column="ZAHLUNGS_ID"/> <property name="kartennummer" column="KARTENNUMMER"/> ... </joined-subclass> <joined-subclass name="BarZahlung" table="BARZAHLUNG"> <key column="ZAHLUNGS_ID"/> ... </joined-subclass> </class> Abb. 6: Auszug aus der Zahlung.hbm.xml bei dem gewählten Ansatz „Tabelle pro Subklasse“. <class name="Zahlung"> <id name="id" type="long" column="ZAHLUNGS_ID"> <generator class="sequence"/> </id> <property name="betrag" column="BETRAG"/> ... <union-subclass name="KREDITKARTENZAHLUNG" table="KREDITKARTENZAHLUNG"> <property name="kartennummer" column="KARTENNUMMER"/> ... </union-subclass> <union-subclass name="BarZahlung" table="BARZAHLUNG"> ... </union-subclass> </class> Abb. 7: Auszug aus der Zahlung.hbm.xml bei dem gewählten Ansatz „Tabelle pro konkreter Klasse“. 43 Java/XML Jeder bekommt Alles Der Ansatz „Tabelle pro konkreter Klasse“ stellt die Umkehr des eingangs vorgestellten Ansatzes „Tabelle pro Klassenhierarchie“ dar. Hierbei werden so viele Tabellen benötigt, wie es konkrete (Sub-)Klassen gibt (siehe Abbildung 7). Die vererbten Attribute werden jeweils mit in der Tabelle der Subklasse gespeichert. Wenn die Vaterklasse nicht abstrakt ist, und es folglich von ihr auch eigenständige Instanzen geben kann, wird für diese ebenfalls eine Tabelle benötigt. Glossar Hibernate Framework zur Speicherung von Daten. Als Backend-System dient eine Datenbank (siehe ORDIX News 04/2005). null Beschreibt eine Datenbank Spalte die „nichts“, also den Wert „null“ annehmen kann. Nicht zu verwechseln mit dem numerischen Wert Null (0). not-null Gegenteil von null, d. h. es muss immer ein konkreter Wert abgespeichert werden. Constraint Beschreibt Bedingungen für den Inhalt von Tabellenspalten. Wird typischerweise verwendet, um eine Prüfung auf „notnull“ oder eine korrekte Fremdschlüsselbeziehung durchzuführen. Da die Bedingungen in der Datenbank formuliert sind, verhindern sie das Einpflegen „ungültiger“ Daten. NormaliVermeidet das mehrfache Speichern von konkreten Datensätzen. Anstatt z. B. einen Ortsnamen mehrfach zu sierung speichern, wird dieser nur einmalig unter einem Schlüssel abgelegt. Ebenso wie der erste Ansatz erzeugt auch dieser Ansatz Redundanzen auf der Datenbankseite und widerspricht somit dem Normalisierungsgedanken. Eine Einschränkung ist, dass die Spaltennamen der gemeinsamen Attribu­ te in allen Subklassentabellen identisch sein müssen. Ein weiterer Nachteil dieses Ansatzes ist, dass Hibernate in diesem Fall nur eingeschränkte polymorphe Abfragen unterstützt. Wer sich nach dem Sinn eines solchen Mappings fragt, sollte immer an die unterschiedlichen Einsatzmöglichkeiten von Hibernate denken. Die meisten Projekte fangen nicht auf der Grünen Wiese an. Und wer noch nie – aus welchen Gründen auch immer, insbesondere in seinem vorherigen Leben als nicht-objekt­ orientierer Entwickler – beim Datenbankde­ sign die Normalisierungsregeln verletzt hat, der werfe den ersten Stein. Den weiteren Möglichkeiten von Hibernate werden wir uns in einer der kommenden Ausgaben der ORDIX News widmen. Wer seine Neugier eher stillen möchte, wird im ORDIX Seminarprogramm fündig. Dort gibt es ab sofort auch ein Seminar zum Thema Hibernate. Michael Heß ([email protected]). Rätsel Alles neu macht der Mai ... Das ORDIX Web wurden neu gestaltet, um Sie noch besser zu informieren! Der Relaunch gibt den Seiten ein frisches Gesicht. – Und Sie profitieren von noch mehr Übersichtlichkeit und einem vielfältigen, vernetzten Informationsangebot. Machen Sie sich selbst ein Bild! Und lösen Sie ganz nebenbei unser kleines Interneträtsel*. Dem Gewinner winkt ein „frisches“ Überraschungspaket. Senden Sie das Lösungswort bis zum 24.07.2006 mit dem Stichwort „Klickfrisch“ an [email protected]. 1. Welches Fachthema stellen wir als erstes auf der 1. ORDIX Homepage vor? 2. 2. Erklärtes Unternehmensziel ist, Kundenmehrwert zu schaffen. Welchen Grund für eine Zusammenarbeit 3. führen wir als zweites auf? 4. 3. Von wem (Nachname) stammt der Kundenkommentar 5. auf der Portfolio-Seite „Beratung“? 4. Der nördlichste ORDIX Standort 6. 5. Wir stellen einige ausgewählte Referenzen genauer vor. 7. Von welchem Kunden, dessen Logo einen gelben 8. Hintergrund hat, stammt das Projekt ZEM? 6. Wo können Sie unsere Seminare direkt online buchen? 9. 7. Wo werden viele Fachbegriffe/Abkürzungen aus 10. der ORDIX News erklärt? 8. Wie hieß der Vortrag, den ORDIX im Mai auf 11. der Jax gehalten hat? 12. 9. Wofür steht das „E“ in BEST-Practice? 10. Für welchen Ausbildungsberuf sucht ORDIX Azubis? 11. Welcher Produktpartner steht an 6. Stelle der alphabetischen Liste? 12. Wie viele Kunden im Bereich Training werden symbolisch durch Kundenlogos dargestellt? 44 * Der Rechtsweg sowie die Teilnahme von ORDIX Mitarbeitern und deren Angehörigen sind ausgeschlossen. ORDIX News 2/2006 Datenbanken Larry E. auf der Apfelplantage Oracle unter Mac OS X Wer den Begriff Apple hört, denkt entweder an iPods und iTunes oder an Golden Delicious, Boskop und Cox Orange. Dieser Artikel wird allerdings weder eine Reise zu den unterschiedlichen Apfelplantagen in dieser Welt, noch eine Abhandlung über Apples kleines „Kultobjekt“. Vielmehr soll die produktive Seite des Apfels gezeigt werden, der Einsatz von Mac OS X als Oracle Datenbankserver. Mac OS X und Datenbanken Schon seit der Oracle Version 9i existiert ein Release für das Betriebssystem Mac OS X, das jedoch nie den Entwicklungsstatus verlassen hat. Erst mit Version 10 schaffte Oracle den kompletten Sprung auf den Mac. Zuvor hatten Anwender nur die Wahl zwischen den beiden „Datenbanksystemen“: FileMaker Pro und Sybase. Um der Konkurrenz das Feld nicht kampflos zu überlassen, fiel bei Or acle Anfang 2000 die Entscheidung, auch Mac OS X in das Portfolio der zu unterstützenden Architekturen aufzunehmen. Ob Larry Ellison schon damals von Steve Jobs Plänen wusste, zur Intel Plattform zu wechseln, bleibt wohl ein Geheimnis der beiden Freunde und Geschäftspartner. StartService() ( if [ -a /etc/com.apple.named.conf.proxy ] then echo "Starting Internet address sharing" /usr/libexec/InternetSharing fi ulimit -Hu 2068 ulimit -Su 2068 ulimit -Hn 65536 ulimit -Sn 65536 } Abb. 1: Das Setzen der Shell Limits. Die Erweiterungen sind farblich hinterlegt. Der Artikel richtet sich an Oracle Datenbankadministratoren, die den Mac für ihre Oracle Datenbanken nutzen. Vorbereitungen für die Installation Zur Zeit ist ausschließlich Oracle 10g Release 1 für Mac OS Server 10.3 verfügbar. Doch auch die Installation unter der Standard Mac OS 10.4 Version ist möglich, wenngleich diese nicht vom Oracle Support abgedeckt wird. Vorausgesetzt wird die Installation der Apple Developer Tools [1]. Die Installation von Oracle auf Mac OS X unterscheidet sich nicht fundamental von der bisherigen Herangehensweise. Vielmehr gibt es kleine Unterschiede, vergleichbar mit einer Installation unter Windows zu einer Installation unter Solaris. Dies fängt beim Einrichten der Benutzer gleich an. Mac OS X verwaltet die lokalen Benutzer-Accounts und Gruppen nicht, wie üblich, in der /etc/passwd bzw. der /etc/group. Diese werden bei Mac OS zentral in einem Verzeichnis (NetInfo Directory) hinterlegt, vergleichbar mit einem LDAP3-Dienst. Zum Erstellen des Benutzers „oracle“ und der beiden Gruppen „oinstall“ und „dba“ kann die grafische Oberfläche „NetInfo Manager“ her angezogen werden. Effizienter geschieht dies über das Terminal. Anlegen der Gruppen „oinstall“ und „dba“: sudo sudo sudo sudo sudo sudo nicl nicl nicl nicl nicl nicl . . . . . . -create -append -append -create -append -append /groups/oinstall /groups/oinstall gid 600 /groups/oinstall passwd "*" /groups/dba /groups/dba gid 600 /groups/dba passwd "*" Anlegen des Benutzers Oracle: sudo sudo sudo sudo sudo nicl nicl nicl nicl nicl . . . . . -create -append -append -append -append /users/oracle /users/oracle /users/oracle /users/oracle /users/oracle uid 500 gid 600 shell /bin/bash home /Users/oracle Dem Benutzer Oracle die Gruppe „dba“ zuteilen: sudo nicl . -append /groups/dba users oracle Im Anschluss erfolgt das Erstellen des Home-Verzeichnisses unter /Users/oracle und die Zuweisung eines Passworts in gewohnter Unix-Manier. Abb. 2: Der bekannte Oracle Installer. ORDIX News 2/2006 sudo mkdir /Users/oracle sudo chown oracle:oinstall /Users/oracle sudo passwd oracle 45 Datenbanken Wurm im Apfel - Mögliche Fehler während der Installation Bei der Installation von Oracle, insbesondere beim Erstellen der Datenbank mit Hilfe des Database Configuration Assistants, kann es unter Mac OS X 10.4 zu Problemen kommen. Bricht der Installer mit einer Fehlermeldung ab, so kann dies über die Wahl des richtigen CCompilers „gefixt“ werden. Hierfür ist vor der Installation von Oracle der folgende Befehl abzusetzen: sudo gcc_select 3.3 Da Oracle die Version 10g offiziell nur bis Mac OS Server 10.3.4 unterstützt, kommt es beim Linken zu Problemen mit der gcc Version 4, die den Mac OS X Versionen > 10.4.x beiliegt. Danach sollte die Installation sauber verlaufen. Treten dann beim Erstellen der Datenbank folgende charakteristische Fehler auf, dyld: Symbol not found: _SSL_ALG_CLIENT_AUTH_MODE_RSA_SIGN_CLIENTSIDE_BS Referenced from: /oracle/product/10g/lib/libnnz10.dylib Expected in: flat namespace ORA-12547: TNS: lost contact error so kann dies durch einen kleinen Workaround behoben werden: mv $ORACLE_HOME/lib/libnnzLC.dylib $ORACLE_HOME/lib/ libnnzLC.dylib.bak cd $ORACLE_HOME/bin relink all mv $ORACLE_HOME/lib/libnnzLC.dylib.bak $ORACLE_HOME/lib/ libnnzLC.dylib Dieses Problem taucht jedoch nur bei Mac OS X Version 10.4.x auf und wird hoffentlich durch das nächste Oracle Release behoben. Ein bekannter Fehler schlägt beim Stoppen des Listeners zu. Der Befehl wird abgesetzt, bleibt jedoch hängen. Der Listener ist anschließend in einem unbrauchbaren Zustand. Er lässt sich weder Stoppen noch Starten. Auch hierfür gibt es einen Workaround: onsctl start lsnrctl stop onsctl stop Links ► [1] http://developer.apple.com/tools/ ► [2] http://www.oracle.com/technology/software/htdocs/devlic.html ?http://otn.oracle.com/software/products/database/oracle10g/htdocs/macsoft.html Zu den weiteren Vorbereitungen zählen das Anlegen der OFA-Verzeichnisstruktur und das Überprüfen von Kernel-Parametern. Vorgaben für letztere können dem Dokument „Oracle Installation Guide for Mac OS X“ entnommen werden, welches im Installationsarchiv liegt und unter [2] heruntergeladen werden kann. Die Kernel-Parameter können mit dem Kommando sysctl abgefragt und gesetzt werden, wie auf den meisten Unix-Systemen. Auf unserem Testrechner mussten nur zwei Parameter erhöht werden: sudo sysctl -a | grep maxproc sudo sysctl -w kern.maxproc=2048 sudo sysctl -w kern.macprocperuid=2048 Damit die Änderungen auch nach einem Reboot gesetzt bleiben, ist es ratsam, diese unter /etc/sysctl.conf zu hinterlegen. Das Setzen der Shell Limits ist wiederum Mac OS spezifisch. Die Limits werden in der Datei /System/Library/StartupItems/IPServices eingetragen. Abbildung 1 zeigt diese Datei. Die eingetragenen Erweiterun­gen sind rot markiert. Damit ist der größte Teil der Vorbereitungen getroffen. Als nächstes sollte nach Möglichkeit die Benutzerumgebung des Benutzers Ora­cle definiert werden, indem die folgenden Variabeln in der Konfigurationsdatei .bash_profile gesetzt werden: umask 022 export ORACLE_BASE=/Users/oracle/install export ORACLE_HOME=/oracle/product/10g export ORACLE_SID=BOSKOP export PATH=$PATH:$ORACLE_HOME/bin Installation der Software Nun kann die Installation der Software unter dem Benutzer Oracle erfolgen. Dazu muss man das heruntergeladene cpio-Archiv entpacken und den Installer starten. Die nachfolgenden Java Dialoge dürften nun jedem DBA vertraut sein (siehe Abbildung 2). Abb. 3: Nach der Installation: Oracle unter Mac OS X in Aktion. 46 Die einzelnen Schritte der Installation sind identisch mit denen unter Unix bzw. Windows. Ist die Software erfolgreich installiert, kann anschließend mit Hilfe des Database Configuration Assistant (dbca) die Datenbank erstellt werden. Das Einrichten von Oracle Net wird vom Net Configuration Assistant (netca) im Anschluss übernommen. Abbildung 3 zeigt Oracle unter Mac OS X im Einsatz. ORDIX News 2/2006 Datenbanken Glossar NetInfo Directory Interner Verzeichnisdienst, der unter Mac OS unter anderem zur Verwaltung der lokalen Benutzer und Gruppen dient. LDAP3 Verzeichnisdienst unter Unix, ähnlich NetInfo Directory unter Mac OS. Open Flexible Genormte VerzeichnisstrukArchitecture tur für den Aufbau eines (OFA) Oracle DB Servers. SystemStarter Daemon unter Mac OS zum Star­ten von Diensten, vergleichbar mit inetd unter Unix. SystemStarter statt inet Daemon Mac OS X nutzt für das Starten und Stoppen von Diensten den SystemStarter und nicht, wie auf anderen Unix Systemen, den inet Daemon. Der SystemStarter sucht die Start-/Stoppskripte unter den folgenden Verzeichnissen: • /Library/Startup­Items • /System/Library/Startup­Items. Um eine Oracle Instanz nun automatisch beim Booten hochzufahren, können die in Abbildung 4 und 5 abgedruckten Beispielskripte verwendet werden. Hierfür müssen diese im Verzeichnis /Library/StartupItems/Oracle/ abgelegt werden. Fazit Während ich diesen Artikel schreibe, läuft die Datenbank nun schon seit drei Wochen unter Mac OS X. Bis auf die Schwierigkeiten bei der Installation (siehe Kasten „Wurm im Apfel“), läuft das System stabil. Zu wünschen wäre, dass Oracle die Weiterentwicklung vorantreibt, so dass auch das zweite Release von Oracle 10g für die Mac Plattform erscheint – ohne die Kinderkrankheiten eines ersten Releases. Die Zahlen sprechen dafür: Apple konnte nicht nur im Konsumentenbereich bei Desktop-Systemen und iPods einen Zuwachs verzeichnen, sondern auch im Storage- und Server-Markt. Wie Gartner berichtete, hat Apple den Umsatz mit Speichersystemen im letzten Jahr verdoppeln können und liegt damit auf Platz 10 der Rangliste. Der Umstieg von Apple zur Intel Architektur könnte weitere Portierungen bei Oracle vereinfachen und gleichzeitig die Kosten hierfür senken. Michael Lindermann ([email protected]). ORDIX News 2/2006 #!/bin/bash # Globale Variabeln ORACLE_HOME=/oracle/product/10g PATH=$PATH:$ORACLE_HOME/bin ORACLE_OWNER=oracle ORACLE_OWNER_PATH=/Users/oracle ORACLE_SID=BOSKOP LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH export ORACLE_HOME PATH ORACLE_SID LD_LIBRARY_PATH StartService() { ConsoleMessage 'Starting Oracle listener...' su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/lsnrctl start" ConsoleMessage 'Started Listener.' ConsoleMessage 'Starting Oracle databases...' su - $ORACLE_OWNER -c $ORACLE_HOME/bin/dbstart ConsoleMessage 'Started Oracle database.' } StopService() { ConsoleMessage 'Stopping Oracle databases...' su - $ORACLE_OWNER -c $ORACLE_HOME/bin/dbshut ConsoleMessage 'Stopped Oracle database.' ConsoleMessage 'Stopping Oracle listener...' su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/onsctl start" su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/lsnrctl stop" su - $ORACLE_OWNER -c "$ORACLE_HOME/bin/onsctl stop" ConsoleMessage 'Stopped Listener.' } RestartService() { StopService StartService } RunService "$1" Abb. 4: Ein Beispielskript zum automatischen Starten und Stoppen von Oracle (/Library/StartupItems/Oracle/Oracle). <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList1.0.dtd"> <plist version="1.0"> <dict> <key>Description</key> <string>Oracle 10g Database Server</string> <key>Provides</key> <array> <string>Oracle 10g Database</string> </array> <key>Requires</key> <array> <string>Disks</string> </array> <key>Uses</key> <array> <string>Disks</string> <string>Network</string> <string>NFS</string> </array> <key>OrderPreference</key> <string>Late</string> </dict> </plist> Abb. 5: Die zum Start- und Stoppskript dazugehörige plist Datei (/Library/StartupItems/Oracle/StartupParameter.plist). 47 Ohne Taktik ... Die ORDIX Taktik ... ... mit System ans Ziel! • Optimales Zusammenspiel in einem hochmotivierten Team • 600 Personenjahre Spielpraxis auch in „torgefährlichen“ Situationen • Hohe Flexibilität auch „abseits“ der 90 Minuten Wir machen Sie zum Matchwinner! Fordern Sie uns!
