ORDIX News. Der Oracle SQL Developer ist da! S. 18. Vererbung mit Hibernate Abbildung von Objekthierarchien S. 42

Transkript

1 ORDIX News Das IT-Magazin der ORDIX AG Ausgabe 2/2006 2,20 Der Oracle SQL Developer ist da! S. 18 Vererbung mit Hibernate Abbildung von Objekthierarchien S. 42 ITIL Eine Oase in der Servicewüste Teil II beschäftigt sich mit den taktischen bzw. planerischen Prozessen von ITIL S. 21 IBM IDS 10.0 Neuheiten (Teil II) Neuerungen im Bereich Backup & Recovery S. 37 JavaServer Faces Einführung in die richtungsweisende Programmierung von Web-Oberflächen S. 8

2 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 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 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? 2

3 Inhaltsverzeichnis Standards Training 02.Editorial 03.Inhalt 41.Impressum 24.Seminarübersicht: Juni bis Dezember 2006 Aktuell Java/XML 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 08.JavaServer Faces Titelthema Einführung in die Grundlagen der JavaServer Faces, die als die kommende Alternative für die Programmierung von Web- Oberflächen bezeichnet werden. Titelthema 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. 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. 18.Der Oracle SQL Developer ist da! Erste Erfahrungen beim Einsatz des neuen SQL Developers in der Entwicklung. Titelthema Titelthema 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. 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. 37.IBM Informix Dynamic Server 10.0 Neuheiten (Teil II): 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. 45.Oracle unter Mac OS X Der Artikel zeigt die Installation von Oracle 10g Release 1 auf Mac OS X. Titelthema Unix/Linux/Open Source % MySQL Wie richte ich ein Cluster ein? Beschreibung der Möglichkeiten des Clustering unter MySQL und die exemplarische Installation und Konfiguration eines MySQL-Clusters. Projektmanagement 22.ITIL Eine Oase in der Servicewüste (Teil II) 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

4 Unix/Linux/Open Datenbanken Source Titelthema MySQL 5 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. Oracle 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 Datenfluss DB B DML + DDL Datenfluss Datenfluss DB A DML + DDL Abb. 1: Beispiel einer Architektur zur Nutzung von Oracle Streams. Abbildung 1 zeigt das Beispiel einer Architektur zur Nutzung von Oracle Streams. Komponenten von Oracle Streams Die drei grundlegenden Komponenten für Oracle 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 LogMiner- Mechanismus, 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. Capture Staging Abb. 2: Die Prozesse von Oracle Streams. Consumption 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 4

5 Datenbanken Capture Process Redo Log Capture Changes Log Changes LCRs Database Objects Queue LCR LCR User Message User Message LCR User Message LCR LCR... Source Queue LCR User Message LCR LCR LCR User Message... Abb. 4: Propagation. Propagate Events Destination Queue User Message LCR User Message LCR LCR... der SGA für Streams. Dieser wird durch den init.ora Parameter streams_pool_size konfiguriert. Staging Area User Changes Abb. 3: Capture-Prozess. Queue LCR LCR User Message User Message LCR User Message LCR LCR... Abb. 5: Apply. LCRs or Messages Apply Changes Database Objects Apply Process Message Handler Procedure Messages Row LCRs DML Handler Procedure DDR LCRs DDL Handler Procedure Messages or LCRs Precommit Handler Procedure 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: 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 Exception 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 parallel arbeiten. Dazu dienen die verschiedenen Handler (siehe Abbildung 5). Konflikte können erkannt werden und werden in speziellen (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. 5

6 Datenbanken Queue Dequeue Events Database Objects Transformation During Dequeue Continue Dequeue of Transformed Events Apply Process Apply Transformed Events Directly Abb. 6: Transformation beim Apply. Oracle Database Queue Dequeue Events Apply Process Heterogenous Services Abb. 7: Heterogene Systeme. dba_propagation dba_apply dba_capture V$streams_capture V$streams_apply_reader Oracle Transparent Gateway 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 Send Transformed Events to Apply Handlers Apply Changes Apply Handlers Non-Oracle Database Database Objects Informationen über Propagation (Quell- und Ziel-Queues, Regelsets, DB-Link, ) Informationen zu Apply (Queue, Regelsets, Handler, Status, ) Informationen zu Capture (Queue, Regelsets, SCN, Source-DB, ) Statistische Informationen über Capture Statistische Informationen über Apply 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. Vorteile von Streams Durch den Einsatz von Streams kann eine Replikation einfach in beide Richtungen definiert werden. Es gibt vordefinierte Konfliktlösungsroutinen für Updates (Minimum, Maximum, Overwrite, 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 abfragen. 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.ora- Parameter 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.

7 Datenbanken AQ_TM_PROCESSES >= 1 Erlaubt das Monitoring von Queue Messages. Compatible >= Besser ist mindestens , um die 10g Funktionalitäten nutzen zu können. Job_queue_processes >= 2 Die Staging Queues werden über Jobs gefüllt. Logmnr_max_persistent_sessions Wird für das Auslesen der Redologs benötigt. (>= Anzahl der Capture-Prozesse) Open_links Wird für die Verbindungen zwischen den Datenbanken benötigt. 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 mindestens plus 10 MB Stream 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 Archivelog- Modus arbeiten, damit der LogMiner an die komplette Redo Log-Information herankommt. Zwischen den Datenbanken müssen Verbindungen durch Datenbank-Links hergestellt werden. 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 Event- Stau entstehen könnte. Es empfiehlt sich folgende Vorgehensweise: 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 Apply- User und das Einrichten von DB-Links. Capture-Prozess aufsetzen (nicht starten). Propagation-Prozess aufsetzen (nicht starten). Apply-Prozess aufsetzen und starten. Propagate-Prozess starten. Capture-Prozess starten. Das Löschen erfolgt in umgekehrter Reihenfolge. Glossar AQ DDL DML LCR Replikation Redo Log Event SGA Supplemental Logging SYS.ANYDATA PL/SQL Queue DB-Link Logminer 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 (info@ordix.de). Advanced Queuing Data Definition Language Data Manipulation Language Logical Change Record Datenverteilung in verschiedene Datenbanken Protokolldateien in der Oracle-Datenbank, die durch den Logwriter geschrieben werden. Ereignis. Hier DDL- oder DML-Änderung oder Meldung. System Global Area Erweiterte Protokollierung in den Redo Log- Dateien. Datentyp in Oracle, der einen beliebigen Typ aufnehmen kann. Prozedurale Erweiterung von SQL Speicherstruktur nach dem FIFO-Prinzip (First in First out) Datenbank-Link. Verbindung zwischen zwei Datenbanken. Package mit dem die Redolog-Dateien ausgewertet werden, um die UNDO- und DO-Information zu erhalten. Kennzeichen im Datensatz. 7

8 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: 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. 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 My- Faces-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 Deployment-Deskriptor web.xml der Anwendung zwingend weitere Einträge gemacht werden (siehe Abbildung 3). Voraussetzungen Jede JSF-Anwendung ist zunächst einmal eine ganz normale Web- Anwendung. Das bedeutet, dass man es im Wesentlichen mit ei- Abb. 1: Beispielanwendung eines Login-Dialogs. 8

9 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-Front- Controller 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 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=" prefix="h"%> <%@ taglib uri=" 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-Libraries 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

10 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. 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 Eingabefeld 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, unterschiedliche 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. 10

11 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 Java- Server Faces durch das Event Handling. Wer schon einmal bei der Entwicklung von Swing- GUIs 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 werden. Im Beispiel ist dies die ID der Komponente, die in diesem Fall identisch mit der Bezeichnung (Locale) für die einzustellende 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 Login- Seite (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 FAI- LURE (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 üblichen Form. 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-Applikationen notwendig ist. Dazu soll an dieser Stelle ein wenig hinter die Kulissen der JavaServer Faces geschaut werden. 11

12 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 Event- Verarbeitungen 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- 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 anschließ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 ausreichenden Überblick, um die Technologie der JavaServer Faces und deren Möglichkeiten einzuschätzen. Die Frage, ob JSF das Mittel der Wahl für zukünftige Web-Projekte ist, lässt sich pauschal nicht beantworten. Die Betrachtung einiger 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- 12

13 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-Mechanismus, wie man ihn z. B. mit Tiles im Struts Framework findet. 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: loginerrordetails=benutzer und/oder Kennwort falsch Abb. 12: Resource Bundle für die deutsche Spracheinstellung. 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 einzelne 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. Faces Request Faces Response Reconstitute Request Tree Render Response Apply Request Values Render Response Response Complete Invoke Application Process Events Process Events Response Complete Response Complete Process Validations Update Model Values Process Events Response Complete 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 Editoren für alle Bereiche. Visuelle Darstellung der Navigationsstrukturen oder Drag&Drop-Fähigkeiten bei der Formularerstellung sind fast selbstverstä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 (info@ordix.de). Abb. 13: JSF Request Lebenszyklus. Glossar Deployment Deskriptor Servlet Container Front Controller Model View Controller (MVC) Observer Pattern JSF-Request Conversion Errors/ Render Response Validation / Conversion Errors / Render Response Eine (XML-)Datei, die Konfigurationseinstellungen für die Laufzeitumgebung und die Applikation enthält. Laufzeitumgebung für die Ausführung von Servlets, wozu auch Java Server Pages (JSPs) und Java- Server Faces (JSFs) zählen. Software-Muster, bei dem eine zentrale Komponente externe Anfragen entgegennimmt und an interne, nach außen gekapselte Dienste delegiert. Ein Paradigma für Benutzeroberflächen, das die getrennte Behandlung von Daten, deren Darstellung und die darauf wirkenden Benutzeraktivitäten propagiert. Software-Muster, bei dem sich mehrere Komponenten (Observer) bei einer einzelnen Komponente (Subject) registrieren. Das Subject kann so beim Auftreten bestimmter Ereignisse alle Observer informieren. Die Anfrage eines Clients (meist ein Webbrowser) zur Darstellung einer Webseite, die JavaServer Faces-Komponenten enthält. 13

14 Unix/Linux/Open Datenbanken Source Titelthema MySQL 5 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 Gigabyte. 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, NC- LOB) 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. 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 gespeichert werden, d. h. innerhalb des zugeordneten Speicherbereiches innerhalb der Datenbank. Wenn der Parameter DISABLE STORAGE IN ROW nicht eingestellt ist und der interne LOB- 14

15 Datenbanken Wert kleiner als 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 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 LOB- Wertes. 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 LOB- Spalte 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, OC- CI, Pro*C/C++, Pro*COBOL, Java oder OLE) in einem internen LOB geschrieben werden kann, muss der LOB mit dem Spaltenattribut NOT NULL gebildet werden. D. h. er muss einen LOCATOR enthalten. Dies wird mit den Funktionen 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 BFILE- NAME()-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 APPEND() Hängt den Inhalt eines LOB an einen anderen LOB. COPY() Kopiert einen Teil oder alles von einem LOB in einen anderen. ERASE() Löscht einen Teil von einem LOB ab einer bestimmten Position. LOADFROMFILE() Lädt Daten von einem externen in einen internen LOB. TRIM() Verkleinert den LOB in eine bestimmte Größe. WRITE() Schreibt Daten in einen LOB an einer bestimmten Stelle. WRITEAPPEND() Schreibt Daten an das Ende eines LOB. READ 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: 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

16 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 sourcetext INTO clob_selected FROM test_clob WHERE product_id = 1; -- t2 SELECT sourcetext INTO clob_updated FROM test_clob WHERE product_id = 1 FOR UPDATE; INTEGER; CLOB; CLOB; CLOB; INTEGER; INTEGER; INTEGER; INTEGER; VARCHAR2(20); Abb. 3a: Einlesen des LOB-Wertes in die 1. Locator-Variable. 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. 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 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_IN- CREASE benutzt. Das ist Speicherplatzverschwendung und bei entsprechender Größe auch schwer zu handhaben. 16

17 Datenbanken Glossar Oracle Large Object (LOB) Binary Large Object (BLOB) Character Large Object (CLOB) National Character Large Object (NCLOB) Binary Large Object (BFILE) Eine andere Möglichkeit ist die Verwendung von locally managed Tablespaces. Der Parameter MAXEXTENTS ist möglichst auf UNLI- MITED 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 Rollback- Segmentes 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 CRE- ATE TEMPORARY TABLESPACE Statement nicht erlaubt ist. Fazit Datentyp zur Aufnahme großer Datenmengen. Datentyp zur Aufnahme binä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. 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 (info@ordix.de). -- 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 PCTVERSION 0 NOCACHE NOLOGGING STORAGE(INITIAL 100M NEXT 100M MAXEXTENTS UNLIMITED PCTINCREASE 0)); Abb. 4: Beispiel für einen Gigabyte LOB. 17

18 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-Funktionalitä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 Oracle Datenbankschema verbinden, das die Standard Oracle Authentifizierung benutzt. Benutzer können sich mit dem SQL Developer an Oracle Datenbanken ab Version und höher anmelden. Zur Datenbankanbindung 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 Darüber hinaus können Datenbankobjekte anderer Datenbankbenutzer entsprechend der vergebenen System- und Objektprivilegien genutzt werden (siehe Abbildung 2). Reports Sequenzen Materialized Views Materialized View Logs Synonyme Public Synonyme Datenbank Links Directories Papierkorb (ganz wichtig ab Oracle 10g!) Die zweite Ebene Reports beinhaltet eine Anzahl von vordefinierten Reports über die Datenbank 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 CO- PY/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. Das SQL-Worksheet unterstützt die Erstellung von SQL- und PL/SQL-Befehlen. Diese können einzeln oder 18

19 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 Plattformen für den Einsatz des SQL Developers. nacheinander als Skript ablaufen. 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 komfortableren 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 Applikationsfenster (Connections, Reports, Snippets, SQL-Worksheets) zeigt Abbildung 5. Es ist auch möglich, die einzelnen Applikationsbestandteile jeweils am Appli- Abb. 5: Übersicht der Applikationsfenster. 19

20 Datenbanken kationsrand minimiert zu positionieren und nur bei Bedarf zu öffnen. Debug Der Benutzer kann PL/SQL-Code erstellen und ändern. Er kann Code-Formatierung und Bookmarks hinzufügen und Quellcode 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 aufgerufen und durch das Kontextmenü in den Debug 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/SQL- Programmiertechniken. Support Abb. 6: Debug Kontextmenü. Für den Support ist zu beachten, dass eine Zertifizierung (Support bei Fragen) für die einzelnen Bestandteile des SQL Developers (SQL- Worksheet, Datenbank-Funktionen, PL/SQL-Support) zur Zeit nur für die Datenbanken 9i (Version ) und 10g Enterprise Edition, Standard Edition, Standard Edition One und Express Edition gilt. Die Unterstützung der einzelnen Datenbankversionen befindet sich aber in einem fortlaufenden Prozess. Die notwendige Voraussetzung für den Support des SQL Developers ist eine Oracle Datenbanklizenz. Fazit Abb. 8: Beispiel für das Debugging einer Stored Procedure. Für die erste Version ist der SQL Developer ein durchaus für SQL- und PL/SQL- Standardprogrammierung sinnvoll ein- 20