ORDIX News

www.ordix.de
ORDIX News
Das IT-Magazin der ORDIX AG
Ausgabe 3/2006
€ 2,20
Datenkompression unter Oracle
XEN – ein neuer Stern am Himmel?
S. 24
Lucene unter Last
Open Source Virtualisierungslösung S. 13
beim Deutschen Rundfunkarchiv S. 30
EJB 3.0: Annotations versus XDoclet
Oracle Objekttypen
Teil I dieser Artikelserie stellt EJB 3.0 aus
konzeptioneller Sicht vor. S. 5
Die neue Reihe bringt Licht in die zahlreichen
von Oracle unterstützten Objekttypen S. 28
Besuchen Sie ORDIX auf der
19. Deutschen Oracle Anwenderkonferenz
am 15./16.11.2006 in Mannheim ...
Auf der Konferenz präsentieren wir Oracle Know-how an der
ORDIX Infoinsel und in diversen Vorträgen:
• Umstieg auf RMAN mit Oracle Secure Backup
Rechnet sich das?
Herr Andreas Kother, ORDIX AG, Paderborn
• Tracing - Im Geheimdienst Ihrer Majestät
Herr Martin Hoermann, ORDIX AG, Münster
• PL/SQL-Debugging und Tuning
Frau Beate Künneke, ORDIX AG, Paderborn
• Auditing - Sinn, Einsatzmöglichkeiten & Performance
Herr Klaus Reimers, ORDIX AG, Köln
... und auf dem DOAG Schulungstag
am 17.11.2006
http://training.ordix.de
Schnuppern Sie das ORDIX Know-how in dem Workshop
„Advanced PL/SQL“ im Rahmen des DOAG Schulungstags.
Advanced PL/SQL Workshop
PL/SQL wird als Sprache im „Datenbank-Kern“ immer wich­
tiger. Die Verarbeitung und Bereitstellung der Daten an zen­
traler Stelle ermöglicht damit den Zugriff von unterschiedlichen Anwendungen aus verschiedenen Systemen auf eine
gemeinsame Basis. Große Bedeutung hat nach wie vor eine
sehr gute Performance, die in der Datenbank optimal erzielt
werden kann.
Wir gehen in diesem Workshop auf wichtige Erweiterungen
ein und zeigen Möglichkeiten zum Tracen auf. Darüber hinaus
behandeln wir das Thema Performance.
Zielgruppe:
Dieser Workshop richtet sich an fortgeschrittene Entwickler
und Datenbankprogrammierer, die ihre PL/SQL-Kenntnisse
erweitern möchten.
Inhalte:
• PL/SQL-Designkonstrukte:
Cursor Variablen, Subtypen, Objekttypen
• Kollektionen (SQL, PL/SQL):
Assoziative Arrays, Nested Tables, Varrays,
Vorteile von Kollektionen
• Fine Grained Access Control (FGAC):
Prozessbetrachtung, Anwendungskontexte
einrichten, Policies implementieren
• Externe Prozeduren:
Vorteile, Komponenten, Aufruf
• PL/SQL Server Pages:
Verwendungszweck, Aufbau und Aufruf
• LOBs:
Definition von Datentypen, LOB in der Datenbank, die Nutzung des DBMS_LOB Packages,
Vorteile von LOBs
• Analyse und Performance Tricks
Infos zu den ORDIX Vorträgen und zur Anmeldung finden Sie unter http://www.doag.org.
Infos zum kompletten ORDIX Trainingsprogramm finden Sie unter http://training.ordix.de.
Wir freuen uns auf Ihren Besuch!
Editorial
Paderborn, September 2006
An dieser Stelle ...
... erwarten Sie normalerweise offene, kritische und manchmal auch amüsante Worte von mir. Als ich das letzte Editorial geschrieben hatte und noch nicht einmal die Drucklegung der Zeitung beendet war, erreichte die Eltern zweier
junger Männer und unser Unternehmen eine unbegreifliche Nachricht. Ein Schicksalsschlag, von dem ich mir immer,
seitdem ich dieses Unternehmen gegründet hatte, wünschte, dass er uns nie treffen würde.
Daniel Hellinge und Christoph Voss
Im Mai 2006 erlagen unsere beiden Auszubildenden Daniel Hellinge
und Christoph Voss ihren schweren Verletzungen, die sie sich bei einem unverschuldeten Autounfall zugezogen hatten. Diese Seite ist
deshalb ihnen und ihrem leider viel zu kurzen Schaffen innerhalb der
ORDIX gewidmet. Wir werden sie nicht vergessen.
Daniel Hellinge
Christoph Voss
* 22.01.1986
† 26.05.2006
* 11.05.1986
† 31.05.2006
Diese abrupte Trennung hat uns schwer getroffen. Und dennoch haben in alter Tradition am 1. August zwei neue Auszubildende ihre Arbeit in unseren Reihen aufgenommen. Wir wünschen uns und ihnen,
dass sie würdige Nachfolger von Christoph und Daniel werden.
Trotz dieser sehr ernsten und traurigen Einleitung lassen Sie sich nicht davon abhalten, auch in dieser ORDIX News
unsere interessanten Artikel rund um Java, Oracle, Informix, Linux ... zu lesen. Ich wünsche Ihnen nach der WM-Euphorie viel Erfolg für die restlichen Monate des Jahres.
Wolfgang Kögler
ORDIX News 3/2006
Inhaltsverzeichnis
Training
Standards
09 ....Seminar EJB Programmierung
03 ....Editorial
12 ....Seminar Informix Backup & Recovery mit ON-Bar
04 ....Inhalt
22 ....Seminarübersicht: Oktober 2006 bis März 2007
34 ....Impressum
Unix/Linux/Open Source
Aktuell
Titel-
13 ....XEN – Ein neuer Stern am Himmel? thema
Überblick über die Open Source Lösung „XEN“ im Vergleich
zu den Produkten Virtual Server und VMware.
02 ....DOAG Konferenz 2006
ORDIX auf der Anwenderkonferenz
und dem Schulungstag
15 ....Betty, Tina, Lilli und Rosi sind pensioniert
Bericht über die Planung und Migration eines (Betriebs-)­ Systems inklusive untersc
21 ....Rückblick ORDIX Open
Neue Rekord-Teilnehmerzahlen
27 ....Larry Ratlos
Zugriffsrechte unter Unix
40 ....Tiefe Einblicke in Solaris 10 mit Dtrace (Teil III):
Geisterhafte Technik oder Technik, die begeistert?
Betrachtung von Dtrace auf der Grundlage des Skriptes
dexplorer aus dem DtraceToolkit.
43 ....Messe-Rückblick
ORDIX diesjährig erstmals auf der JAX
Java/XML
Titel-
05 ....EJB 3.0 (Teil I):
Titelema
Annotations versus XDoclet th
Der Artikel stellt EJB 3.0 aus konzeptioneller Sicht vor. Es wird
ein kurzer Quellcodevergleich zu EJB 2.x mit XDoclet auf Ebene von Auszeichnungen und EJB-Artefakten durchgeführt.
30 ....Lucene unter Last
thema
beim Deutschen Rundfunkarchiv
Durch einen Lasttest werden Einflussgrößen für die Antwortzeiten der Suchmaschine Lucene ermittelt.
18 ....Web-Entwicklung mit den Ajax-Tags
Kurze Einführung in die Ajax-Programmierung und Verwendung der Ajax Tag Library an einem konkreten Beispiel.
37 ....Hibernate (Teil III):
Caching in Hibernate
Einführung in die Grundlagen und die
Konfiguration des Caching von Objekten
in Hibernate.
Datenbanken
10 ....IBM IDS 10.0 Neuheiten (Teil III):
Informix 10 Table Level Restore
Mit dem Table Level Restore kann man einzelne Tabellen
aus einem Backup extrahieren und in der Datenbank wieder
herstellen.
Titela
24 ....Datenkompression unter Oracle them
Wir stellen die Komprimierung von Tabellen unter Oracle mit
Hilfe von Data Segment Compression vor.
Titel28 ....Oracle Objekttypen (Teil I):
thema
Von Cluster bis XML
Mehrteilige Übersicht zu den von Ora­cle
unterstützten Objekttypen.
35 ....Auditing für die Datenbank
Die Möglichkeiten des Auditing unter
Oracle bieten eine erhöhte Sicherheit für
die Datenbankadministration.
ORDIX News 3/2006
Java/XML - Titelthema
Java/XML
Neue Reihe EJB 3.0 (Teil I):
Annotations versus XDoclet
Der EJB-Entwickler musste bislang für eine einzelne Enterprise Java Bean sieben Dateien und mehr erstellen und pflegen, um seine Businesslogik an den Server zu bringen. Eine große Arbeitserleichterung war da
die Einführung von XDoclet als Hilfsmittel zur Code-Erzeugung. Mit EJB 3.0 Annotationen wird nun alles anders ... oder doch nicht?!
EJB-Entwicklung und ihre Tücken
Kritiker von Enterprise Java Beans (EJB) gibt
es viele - wohl manchmal auch zu recht. Dabei ist einer der erstgenannten Kritikpunkte,
dass für die Implementierung einer simplen
EJB 2.0 Anwendung sieben Dateien und mehr
erstellt und gepflegt werden müssen (siehe
Abbildung 1).
Neben der eigentlichen Bean verlangen bis zu
vier Java-Interfaces sowie zwei DeploymentDeskriptoren die Aufmerksamkeit des Program­
mierers. Diese Artefakte der EJB-Spezifikati­on
sind anfällig für Fehler und Unachtsamkei­ten.
Zudem treten viele damit verbundenen Feh­ler
erst beim Deployment in den Applikationsser­
ver auf.
Für den Java-Compiler ist es zudem noch kein
Grund, beim Übersetzungsvorgang einen Fehler anzuzeigen, wenn sich die throws-Klauseln
einer Methode der eigentlichen Bean von denen
des EJB Remote Interfaces unterscheiden.
Wurde hier in der eigentlichen Bean ein Ex­
cep­tion-Wurf verzeichnet, jedoch nicht im EJB
Re­mote Interface, wird dieser Verstoß ge­gen
die J2EE-Spezifikation meist erst beim De­
ploy­ment in den Applikationsserver als Fehler erkannt.
Eine neu implementierte Methode, zu der in
den Deployment-Deskriptoren die Angaben
für das Verhalten zu Datenbanktransaktionen
nicht korrekt definiert sind, zeigt meist erst bei
kontrollierten Fehlerfällen ihre fatalen Auswir-
•
•
•
•
•
•
•
Home Interface
Remote Interface
Local Interface
Local Home Interface
Deployment-Deskriptor ejb-jar.xml
Container-abhängiger DeploymentDeskriptor (z. B. jboss.xml)
Anwendungs-Deskriptor des EARs
(application.xml)
Abb. 1: Mögliche Artefakte von EJB 2.0.
ORDIX News 3/2006
Der Artikel richtet sich vor allem an Java-Entwickler, die bereits
mit EJB Erfahrung haben.
kungen auf die Konsistenz der Datenbestände. Eine halb durchgeführte Kontobuchung wäre sicher ein mögliches Worst-CaseSzenario.
Gerne wird bei der Implementierung von neuer Geschäftslogik
auch die korrekte Definition der JAAS-Einstellungen der EJB vergessen.
Auswirkungen können sein, dass z. B. ein in der Software abgebildeter Geschäftsvorfall nicht für alle beteiligten Nutzer zur Verfügung steht und der Container das Ansprechen der Schnittstelle mit
einer java.lang.SecurityException verweigert.
Für den Programmierer sind die EJB-Artefakte einer einzigen, zu
implementierenden EJB-Methode (z. B. einer Stateless Session
Bean) nicht alle auf einen Blick verfügbar. Sie müssen an diversen
Stellen in XML und in separatem Java-Code gepflegt werden.
In den letzten Jahren haben sich in der Softwareentwicklung diverse Verfahren herausgebildet, um diese Hindernisse bei der EJB
2.0 Entwicklung zu reduzieren. Alle modernen, integrierten Entwicklungsumgebungen unterstützen den Entwickler bereits bei der Einhaltung diverser J2EE-Spezifikationen.
So werden mit Eclipse oder IDEA IntelliJ bei Refactorings der EJBMethoden auch die jeweiligen Stellen in den EJB-Interfaces angepasst, obwohl diese nicht in direkter Implementierungsbeziehung
zu dieser Bean stehen. Anstatt die Einstellungen der DeploymentDeskriptoren umständlich über XML zu regeln, lassen sie sich zudem auch zentral über eine GUI steuern.
Jenseits einer IDE hat sich im Open Source Bereich XDoclet als
ungeschriebener Standard zur Pflege von EJB-Artefakten durchgesetzt.
XDoclet als Wegbegleiter
XDoclet ist ein Code-Generierungstool, das als Plugin für JavaDoc mit Hilfe von ant ausgeführt werden kann.
Mit XDoclet hatte man ursprünglich genau jene EJB-Artefakte
im Visier, die eine EJB-Entwicklung bislang unnötig erschwerte:
XDoclet generiert die oben erwähnten, ungeliebten Artefakte (in
Form von Text, XML- und Java-Quellcode) mit Hilfe von Auszeichnungen (Tags) innerhalb von Java-Kommentaren zu Klassen und
Methoden.
Java/XML
Annotationen / Anmerkungen / Auszeichnungen / Tags
Die Anwendung von XDoclet folgt dabei dem gleichen Prinzip, wie
es zur Erstellung einer aussagekräftigen API-Dokumentation notwendig ist: Es werden im Java-Kommentar von Klassen, Methoden und Attributen spezielle Anmerkungen (Tags) vorgenommen,
die das jeweilige Element speziell auszeichnen.
Soll in der API-Dokumentation beispielsweise für eine Klasse ein
Autor benannt sein, lässt sich im Java-Kommentar der Klasse das
Tag @author Autorname einfügen, um die Information über einen Autor der Klasse in die Dokumentation einfließen zu lassen.
Auf XDoclet übertragen fügt man so im Kommentar einer Klasse
z. B. die Anmerkung @ejb.bean type="Stateless" ein, um
XDoclet mitzuteilen, dass bei der javaDoc-Prozessierung dieser
Klasse die EJB-Artefakte einer Stateless Session EJB generiert
werden sollen.
Über Tags lassen sich so alle benötigten Zusatzinformationen angeben, die zur Erstellung von gültigen EJB-Artefakten notwendig
sind.
Innerhalb der Steuerskripte für die Laufzeitumgebung ant oder über
die Java-Umgebungsvariablen lassen sich zusätzlich Einstellungen für den Generierungsvorgang von XDoclet vorgeben. Sie definieren, was alles von XDoclet generiert werden soll. Hier lässt sich
festlegen, ob definierte XDoclet-Tags ausgewertet und wo z. B. generierte Quellen abgelegt werden sollen.
XDoclet folgt den Ansprüchen zur Generierung von Quellen und
Metadaten unterschiedlichen Typs. So können neben dem EJBUmfeld auch Quellen und Metadaten für JMX, Spring, Tapestry,
Hibernate oder JDO erzeugt werden.
Selbst in komplexeren Code-Generierungsszenarien, die einem
modellzentrierten Software-Entwicklungsansatz folgen, findet XDoc­
let seinen Einsatz. Mit Tools wie AndroMDA oder Middlegen lassen sich auf der Grundlage eines Datenmodells Quelldateien erzeugen, die um XDoclet-Tags angereichert sind. Mit XDoclet lassen sich über diese Quelldateien fertige Software-Bausteine generieren [1].
Zu XDoclet gibt es auch eine alternative, erweiterte Implementierung: XDoclet2. Im Wesentlichen unterscheidet sie sich von der
Vorversion durch diverse Verbesserungen bei der Unterstützung
von Hibernate. Es gibt aber auch Verschlechterungen: In einigen
Bereichen fehlen XDoclet2 einige Funktionalitäten der früheren
Version. Zudem unterstützt auch XDoclet2 noch nicht die neuen
Features von Java 5.
JSR 175 Metadata Annotationen
Mit Java 5 wird das Prinzip der Auszeichnungen von Xdoclet im Standard „JSR 175 Metadata Annotations“ auf die elementare Sprach­
ebene von Java gebracht. Annotationen liegen nicht mehr innerhalb von Kommentaren als Bestandteil der Dokumentation, sondern sind nun echte Metadaten als Bestandteil des Quelltextes.
Im Gegensatz zu den rein textbasierten JavaDoc-Kommentaren,
deren Verhalten in den JavaDoc-Plugins bzw. in XDoclet implementiert ist, kommt mit den JSR-175-Annotationen ein stark typisiertes
Verfahren daher. Jede Annotation wird durch ein
eigenes Sprachelement, den Annotation-Typ,
beschrieben. Dieser steht auf einer sprachli­
chen Stufe mit den anderen, syntaktischen Ele­
menten, wie Interface, Klasse etc.
Damit einher gehen der Vorteil der Syntaxprüfung beim Übersetzungsvorgang und die Möglichkeit der Erweiterbarkeit um eigene, z. B.
projektspezifische, Annotationen. Im Gegensatz zu XDoclet-Annotationen können JavaAnnotationen direkt in die Java-Klasse mit einkompiliert werden. Sie sind anschließend derart mit der Klasse verbunden, dass sie auch
noch zur Laufzeit per Reflection abgefragt wer­
den können.
EJB 3.0 Annotationen – was ist neu?
Im (künftigen) Standard EJB 3.0 (JSR-220) wird
von den Java-Annotationen rege Gebrauch
gemacht. Alle Metadaten lassen sich mit Hilfe
der neu eingeführten Java-Annotationen beschreiben. Wurde ein bestimmter Wert nicht
definiert, greift ein Standard. Bei der Entwicklung kann nun prinzipiell komplett auf XMLDeployment-Deskriptoren verzichtet werden.
Der Verzicht ist jedoch nicht zwingend erforderlich. Jede EJB 3.0-Metainformation kann
immer noch in gesonderten Deployment-Deskriptoren definiert werden und überschreibt
somit die am Quellcode vorgenommene Auszeichnung.
Die althergebrachten, von Sun definierten, EJBZuständigkeitsbereiche wie z. B. „Application Component Provider“, „Application Assembler“ und „Application Deployer“ sind damit immer noch gültig. Gerade dies wurde ja vor einigen Jahren als großer Vorteil der EJB-Komponentenentwicklung gefeiert. Eine SoftwareKompo­nente, die eigene JAAS-Rollen verwendet, kann nun z. B. immer noch über die Anpassung der Deployment-Deskriptoren in die
JAAS-Umgebung einer bestehenden EJB-Anwendung integriert werden.
Es sollte gut überlegt sein, welche Metainformationen direkt mit dem Quellcode verbunden
werden. Von der Laufzeitumgebung abhängige Eigenschaften, wie der JNDI-Name einer
Datenbank-Ressource, werden sicher besser
immer in einem XML-Deployment-Deskriptor
definiert. Hierzu siehe auch den empfehlenswerten Artikel unter [2].
Dem Entwickler wird die hohe Ähnlichkeit von
EJB 3.0 Annotationen mit XDoclet Annota­
tionen für Hibernate auffallen. Kein Wunder,
denn die Entwickler von Hibernate sind doch
an der Definition des Standards beteiligt und
die Erfahrungen aus den Open Source Tools
ORDIX News 3/2006
Java/XML
Hibernate und XDoclet in die Spezifikation ein­
geflossen.
sowie auf den Artefakten, die in den unterschiedlichen EJB-Versionen benötigt werden.
So ist ein Vergleich dieser Tools mit dem neuen Standard nicht abwegig. Im Folgenden sei
ein näherer Blick auf die Implementierungsunterschiede der beiden Technologien im Quellcode gewagt.
Im Folgenden wird dazu der Quellcode einer einfachen Stateless
Session EJB gezeigt, die die beiden im EJB-Interface zu veröffentlichenden Methoden String doSomeAction() und int getCount() enthält. Die Implementierung dieser Methoden enthält
keine Logik. Für den Vergleich mit Blick auf Annotationen und Artefakte ist dies auch nicht nötig. Für das Beispiel wird die Bean
um die jeweiligen Metainformationen zu Transaktions- und Sicherheitseinstellungen erweitert.
Ein kleiner Vergleich
Auf Grundlage der aktuellen JBoss-Version
(4.0.4.GA) und der dafür verfügbaren, vorläufi­
gen EJB 3.0 Implementierung soll ein kleiner
Ver­gleich mit einer einfachen Stateless Session Bean unter EJB 2.x mit XDoclet und EJB
3.0 gezeigt werden. Das Augenmerk liegt hier
besonders auf dem Prinzip der Annotationen
Es fallen die großen Ähnlichkeiten der beiden Auszeichnungsvarianten auf (siehe Abbildung 2), wenngleich die zugrundeliegenden, technischen Unterschiede immens sind. Der EJB 2.x Entwickler bemerkt, dass die SessionBean des XDoclet-Beispiels abstrakt
deklariert ist und nicht die für EJB 2.x obligatorischen Methoden
des SessionBean Interfaces implementiert.
Um XDoclet-Tags angereicherter Quellcode
Um EJB 3.0 Annotationen angereicherter Quellcode
(in aktueller JBoss EJB 3.0 Implementierung)
package ordix.xdoclet.ejb;
package ordix.EJB 3.0.ejb;
import
import
import
import
import
import org.jboss.aspects.security.Unchecked;
import org.jboss.annotation.security.SecurityDomain;
javax.ejb.SessionBean;
javax.ejb.SessionContext;
javax.ejb.CreateException;
javax.ejb.EJBException;
java.rmi.RemoteException;
/**
* Diese Klasse ist ein Beispiel für die
* XDoclet-Nutzung
*
* @ejb.bean
*
name="FooFacadeBean"
*
type="Stateless"
*
view-type="both"
*
transaction-type="Container"
*/
public abstract class FooFacadeBean
implements SessionBean {
/**
* @ejb.interface-method
* @ejb.permission unchecked="true"
* @ejb.transaction type="Required"
*/
public String doSomeAction() {
return "I made it.";
}
import java.rmi.RemoteException;
import javax.ejb.*;
import javax.annotation.security.RolesAllowed;
/**
* Diese Klasse ist ein Beispiel für die EJB 3.0-Nutzung
*/
@Stateless
public class FooFacadeBean implements FooFacade {
@TransactionAttribute(TransactionAttributeType.REQUIRED)
@Unchecked
public String doSomeAction() {
return "I made it.";
}
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
@RolesAllowed({"Administrator"})
public int getCount() {
return 68;
}
}
/**
* @ejb.interface-method
* @ejb.transaction
*
type="RequiresNew"
* @ejb.permission
*
role-name="Administrator"
*/
public int getCount() {
return 68;
}
}
Abb. 2: Die Implementierungsunterschiede im Quellcode der beiden Technologien im Vergleich.
ORDIX News 3/2006
Java/XML
Erst beim Generierungsvorgang von XDoclet wird eine konkrete
Implementierung erzeugt, die auch die Servicemethoden wie ejbStart(), ejbStop() oder setSessionContext() enthält. Auf
die erzeugte Bean-Implementierung wird dann in den generierten
Deployment-Deskriptoren verwiesen.
Betrachtet man die verwendeten Auszeichnungen, fallen Ähnlich­
keiten auf. XDoclet erwartet als Auszeichnung einer zu prozessierenden EJB das Tag @ejb.bean, bei dem als Attribut definiert ist, um welchen Typ von EJB (hier Stateless Session Bean)
es sich handelt.
|
+---META_INF
|
ejb-jar.xml
|
jboss.xml
|
\---ordix
\---xdoclet
+---ejb
|
FooFacadeBean.java
|
FooFacadeSession.java
|
+---interfaces
|
FooFacade.java
|
FooFacadeHome.java
|
FooFacadeLocal.java
|
FooFacadeLocalHome.java
\---util
FooFacadeUtil.java
Unter EJB 3.0 wird das Gleiche durch die Anno­
tation @Stateless erreicht. Sofern hier nichts
weiter definiert wurde, greifen Standardwerte,
die im JBoss z. B. die EJB unter dem JNDIPfad mit dem Namen der Klasse ablegt. In unserem Vergleich in Abbildung 2 lautet der JNDI-Pfad /FooFacadeBean.
Unter XDoclet muss jede Methode, die in den
EJB-Interfaces publiziert werden soll, durch
das Tag @ejb.interface-method ausgezeichnet werden. In EJB 3.0 passiert das Gleiche durch die Deklaration in dem implementier­
ten Interface. Hier werden standardmäßig alle Methoden-Interfaces als zu veröffentlichen­
de EJB-Methoden verwendet.
Auch bei den Sicherheitseinstellungen und bei
der Transaktionssteuerung entdeckt man Ähnlichkeiten. Verwendet XDoclet das Tag @ejb.
permission mit dem Attribut unchecked,
um eine Methode als ungeprüft im Sicherheitskontext zu kennzeichnen, macht es in EJB 3.0
die Annotation @Unchecked. Das EJB 3.0
Äquiva­lent zum XDoclet Tag @ejb.transaction type="Required" ist in der Annotation
@Trans­actionAttribute (Transaction­
Attri­buteType.REQUIRED) zu finden.
Vereinfachungen
Abb. 3: Verzeichnisbaum mit Quelldateien nach der Generierung
durch XDoclet.
Überblick über die Neuerungen von EJB 3.0
•
•
•
•
•
•
•
•
•
•
Deployment-Deskriptoren sind nicht nötig, können aber StandardVerhalten überschreiben.
Viele vordefinierte Einstellungen. Man spezifiziert nur die Ausnahmen von den Regeln.
Es sind keine Schnittstellen wie Remote, EntityBean, SessionBean sowie Callback Interfaces nötig, die oft gar nicht benötigt
werden. (Etwa bei Stateless Session Beans und Passivierung.)
Falls es zum Beispiel eine remove-Methode geben muss, wird
diese annotiert. Für eine Methode wie setSessionContext()
wird setter injection genutzt.
Exceptions müssen nicht mehr deklariert werden. (Ein Ärgernis mit Business Interfaces für den lokalen und remote Fall). Die
Objekte sind viel leichter zu testen und ein First-Test-Ansatz ist
damit viel leichter.
Home Interfaces sind nicht mehr nötig.
Es lassen sich EntityBeans objektorientiert modellieren, denn
Vererbung ist möglich.
EntityBeans müssen nicht mehr abstrakt sein und lassen sich
so besser testen.
Während EJBs unter der 2.x Spezifikation diverse Schnittstellen
implementieren, sind sie unter EJB 3.0 viel mehr „Plain Old Java Objects“ (POJOs).
EJB-QL wird mit Projektion, Inner und Outer Join, Bulk Updates,
Bulk-Deletes, Sub-Queries und GROUP BY vervollständigt.
Nutzt die in Java 5 eingeführten Annotationen, um Metadaten
zu beschreiben.
Abb. 4: Zusammenfassung der Neuerungen von EJB 3.0.
(Quelle: http://www.java-tutor.com/java/ejb-3.0-links.htm)
Betrachtet man die beiden Technologien nach
der XDoclet-Generierung, werden die großen
Vereinfachungen deutlich, die EJB 3.0 mit sich
bringt. In EJB 3.0 reicht es aus, die Klassen in
einen JAR zu verpacken und dann dem Applikationsserver bereitzustellen.
Bei EJB 2.x gibt es eine Reihe von Artefakten, die XDoclet generiert hat (siehe Abbildung 3). Neben den Deployment-Deskriptoren
ejb-jar.xml und jboss.xml werden alle
EJB-Interfaces generiert. Ebenso werden die
konkrete Implementierung von javax.ejb.
SessionBean und die Erweiterung von FooFacadeBean mit dem Namen FooFacadeSession generiert. Die ebenfalls generierte
Util-Klasse stellt eine Implementierung eines
J2EE-Patterns zum Caching der EJB Home
Interfaces zur Verfügung, die dem Client unnötige JNDI-Lookups erspart.
Ausblicke
Auch wenn sich die Technologien EJB 2.x und
EJB 3.0 in der Praxis in den Grundsätzen stark
unterscheiden, dürfte für den XDoclet-erfahrenen Entwickler ein Umstieg auf EJB 3.0 relativ einfach sein. Die verschiedenen Auszeichnungen sind in beiden Fällen ähnlich und lassen ein Gefühl der Vertrautheit mit dem Verfahren aufkommen.
ORDIX News 3/2006
Java/XML
Glossar
Literaturhinweise
Java
Specification
Request
(JSR)
JSR kennzeichnet eine Anforderung
für eine Änderung der Programmiersprache Java, die vom Standardisierungskomitee, dem Java Community Process, eingebracht wird.
Doclet
Als Doclet bezeichnet man - in Anlehnung an Applet - Module, die von
Dokumentationswerk­zeugen zur
Verarbeitung und automatischen
Erzeugung von Dokumentationen
und eventuell auch Code eingesetzt
werden. Bekannt sind Doclets insbesondere im Umfeld der Program­
mier­sprache Java, wo sie als Mo­
dule im Dokumentationswerk­zeug
Java­Doc eingesetzt wer­den.
► [1] Fertige Software-Bausteine generieren
http://www.codegeneration.net/tiki-read_article.php
?articleId=35 (engl.)
► [2] Wann setzt man Java-/Xdoclet-Annotationen ein und wann
besser nicht?!
http://www-128.ibm.com/developerworks/java/library/jcwt08025.html (engl.)
► [3] Was ist MDA und wie steht das im Zusammenhang zu
Code-Generatoren wie XDoclet?
http://de.wikipedia.org/wiki/Model_Driven_Architecture (dt.)
► [4] Wo finde ich Generalkritik an EJB?
http://c2.com/cgi/wiki?WhatsWrongWithEjb (engl.)
► [5] Was bezeichnet Annotation in der Programmierung?
http://de.wikipedia.org/wiki/Annotation_(Programmierung) (dt.)
► [6] Wo finde ich eine Zusammenfassung der Neuerungen von
EJB 3.0 und begleitende Web-Verweise?
http://www.java-tutor.com/java/ejb-3.0-links.htm (dt.)
Mit XDoclet und EJB 2.x hat sich in der Entwick­
lergemeinde bereits ein hohes Erfahrungspotential aufgebaut, das in Grundzügen dem
Verständnis von EJB 3.0 dienlich sein kann.
Nichtsdestotrotz ist EJB 3.0 eine komplexe,
neue Technologie, die weit über die Fähigkeiten von XDoclet/EJB 2.x hinausgeht (siehe Abbildung 4).
► [7] Was versteht man unter Java-Annotationen?
http://de.wikipedia.org/wiki/Annotation_%28Java%29 (dt.)
► [8] Wo finde ich eine Einführung zu Java-Annotationen von Sun?
http://java.sun.com/j2se/1.5.0/docs/guide/language
/annotations.html (engl.)
► [9] Wo finde ich die eigentliche Spezifikation der Java-Annotationen (JSR 175)? http://jcp.org/en/jsr/detail?id=175 (engl.)
► [10] Wo bekomme ich XDoclet her?
http://xdoclet.sourceforge.net (engl.)
Lassen Sie sich überraschen und begeistern
von den neuen Möglichkeiten, die sich mit
EJB 3.0 bieten. Mit den Artikeln aus den Lite­
raturhinweisen kommen Sie vielleicht auf den
Geschmack.
► [11] Wo finde ich XDoclet2? http://xdoclet.codehaus.org/ (engl.)
► [12] Wo bekomme ich eine praktische XDoclet-Einführung mit
Vergleichen zu MDA? http://www.oio.de/xdoclet.htm (dt.)
► [13] Kurze EJB 3.0 Einführung von Oracle
http://www.oracle.com/technology/tech/java/newsletter/articles
/simplifying_ejb3.html (engl.)
Holger Bartnick ([email protected]).
Seminar: EJB Programmierung
Der Teilnehmer erlernt die Programmierung
von fort­geschrittenen Java-Enterprise-Anwendungen mittels Enterprise Java Beans (EJB).
Mit Hilfe ausführlicher Übungen kann das Erlernte sofort in die Praxis umgesetzt werden.
Voraussetzungen
Gute Java-Kenntnisse oder Teilnahme am Seminar „Java Programmierung Grundlagen“.
Grundkenntnis­se der J(2)EE-Architektur oder
Teilnahme am Seminar „Einführung in J(2)EE“.
Zielgruppe
Software-Ingenieure, Internet- und Intranet-Entwickler, die effizient J(2)EE-Anwendungen mit
Java (insbesondere EJB) entwickeln möchten.
Java-Enterprise-Entwickler, die Geschäftsobjekte auf der Serverseite entwickeln wollen.
ORDIX News 3/2006
Seminarinhalte
• J(2)EE-Architektur im Überblick
• Übersicht Enterprise Java Beans Container:
Session Beans, Entity Beans, Message Driven Beans
• Session Bean Details: Stateful/-less Session Beans
• Persistenz und Entity Bean Details:
CMP, BMP, Benutzung von Transaktionen
• Message Driven Beans
• Ausführliche Übungen zu allen Themen
Kursgebühr/Teilnehmer: 1590,00 Euro zzgl. MwSt. Dauer: 5 Tage
Termine
06.11.2006 - 10.11.2006 in Wiesbaden
12.02.2007 - 16.02.2007 in Wiesbaden
07.05.2007 - 11.05.2007 in Wiesbaden
27.08.2007 - 31.08.2007 in Wiesbaden
05.11.2007 - 09.11.2007 in Wiesbaden
Datenbanken
IBM Informix Dynamic Server 10.0 Neuheiten (Teil III):
Informix 10 Table Level Restore Problemlose Wiederherstellung
auf Tabellenebene
In Ausgabe 2/2006 stellten wir die Features „Renamed Restore“ und „ONTAPE auf STDIO“ vor. Neben diesen
beiden Neuerungen gibt es ein weiteres Feature aus dem Bereich Backup und Recovery, dessen Vorzüge wir
Ihnen gerne aufzeigen möchten. Es handelt sich um den Table Level Restore.
Dieser Artikel richtet sich an Datenbankadministratoren, System­
administratoren und Entscheider.
Was ist „Table Level Restore“?
Bisher war es so, dass im Falle einer inkonsistenten Datenbanktabelle oder beim Verlust von Daten eine komplette Datenbanksicherung zurückgespielt werden musste.
Eine Alternativlösung bestand darin, die komplette Datenbanksicherung auf einem anderen Referenzsystem zurückzuspielen und
die entsprechenden Daten von diesem System aus auf das Produktionssystem zu übertragen.
Diese Maßnahme konnte, je nach Größe der Datenbank, unter Umständen sehr lange dauern. Der Table Level Restore (TLR) kann
an dieser Stelle Abhilfe schaffen.
Durch den TLR können einzelne Tabellen aus einem Backup extrahiert und in der Datenbank wieder hergestellt werden. Es ist also kein kompletter Restore des ganzen Datenbanksystems mehr
notwendig, um an die Daten einer einzelnen Tabelle zu gelangen.
Die Grundlage des TLR bildet das Informix Tool archecker.
Das Tool archecker
Mit dem Tool archecker können Datenbanksicherungen, die mit
Hilfe von ONTAPE oder ONBAR erstellt wurden, auf ihre Konsistenz und Vollständigkeit überprüft werden.
Jedoch sollte trotz dieses Tools auf einen Testrestore nicht verzichtet werden, um zum einen die Abläufe zu trainieren und zum
anderen die 100%ige Sicherheit zu haben, dass ein Restore fehlerfrei funktioniert.
Ab Informix Release 10.0 kann das Tool archecker zusätzlich für
den TLR genutzt werden. Dabei kann auch hier sowohl auf ONBARals auch auf ONTAPE-Sicherungen zurückgegriffen werden.
1. Es muss eine Sicherung (ONTAPE oder
ONBAR) existieren, die auch die ent­spre­
chen­de(n) Tabelle(n) beinhaltet, die herausgezogen und wieder hergestellt werden soll(en).
2. Von den wieder herzustellenden Tabellen
muss eine so genannte Schemadatei vorhanden sein, die das Data Definition Language (DDL)-Statement für die Tabelle enthält. Mit dem Tool dbschema existiert eine
komfortable Möglichkeit, eine solche Schemadatei zu erstellen (siehe Abbildung 1).
Natürlich kann diese auch „von Hand“ geschrieben werden.
3. Zusätzlich muss in dieser Schemadatei eine Verbindung zur Datenbank hergestellt
werden, in welche die Tabelle zurück geschrieben werden soll. Weiterhin muss sie
das entsprechende Insert-Statement enthalten, um die Datensätze der Tabelle hinzuzufügen (siehe Abbildung 2).
4. In der SQLHOSTS-Datei muss mindestens
ein Eintrag für eine TCP/IP Verbindung zum
Online Server vorhanden sein, über die
der TLR durchgeführt werden kann. Während des Restores werden über eine Verbindung mehrere Sessions innerhalb der
Datenbank geöffnet. Eine Shared Memory-Verbindung kann im Gegensatz zu einer
TCP/IP-Verbindung immer nur eine Session pro Verbindung bereitstellen und ist
deshalb für den TLR ungeeignet.
Befehlssyntax
Syntaktisch sieht der Befehl für einen TLR folgendermaßen aus:
archecker { -t | -b } –X –f <Schema-Datei>
Voraussetzungen
Um einen TLR durchzuführen, müssen folgende Voraussetzungen erfüllt sein:
10
Die Optionen –t oder -b legen fest, um welchen Archive-Typ es sich handelt. Für die Benutzung einer ONTAPE-Sicherung wird direkt
ORDIX News 3/2006
Datenbanken
nach dem Kommando die Option –t angege­
ben. Für eine ONBAR-Sicherung wird die Option –b angegeben.
$ dbschema –t kunde –d DB1 kunde.sql
$ cat kunde.sql
Die Option –X teilt dem Kommando mit, dass
ein TLR durchgeführt werden soll. Alle weiteren Informationen werden anhand der zuvor
konfigurierten Schemadatei ermittelt, die über
die Option –f angegeben wird.
create table "informix".kunde
(
kundennr serial not null,
kundenname char(15),
kundenanschrift char(45),
primary key(kundennr)
);
Beispiel
Für eine Schemadatei einer Tabelle kunde
würden die Befehle für ONTAPE bzw. ONBAR
Sicherungen folgendermaßen aussehen:
ONTAPE-Sicherung:
archecker –t –X –f kunde.sql
ONBAR-Sicherung:
archecker –b –X –f kunde.sql
Die Schemadatei
Die Schemadatei ist ein wichtiger Bestandteil
des TLRs. Mit ihr kann der Datenbankadministrator (DBA) einen direkten Einfluss auf den
Namen der Tabelle und auf die Datenbank,
in der die Tabelle wieder hergestellt werden
soll, nehmen.
Folgende Informationen und Befehle sind in
der Schemadatei anzugeben:
• Datenbankname der Quelldatenbank
• DDL Statements der Tabelle(n)
• DML Befehle
Ein Beispiel zeigt Abbildung 2.
Der TLR bietet somit auch die Möglichkeit, eine Tabelle aus einer Sicherung zu extrahieren und unter einem anderen Tabellennamen
in einer anderen Datenbank wieder herzustellen (siehe Abbildung 3).
Point-In-Time
Durch die Ergänzung restore to ... kann
eine Tabelle auch bis zu einem bestimmten
Zeitpunkt (Point-In-Time) wieder hergestellt
werden. Das Kommando erwartet dazu die Angabe eines Zeitstempels, der sich aus dem Datum und der Uhrzeit zusammensetzt. Die Syntax eines Table Level Point in Time Restores
(TLPITR) ist in Abbildung 4 dargestellt.
External Table
Neben der Wiederherstellung einer Tabelle in
einer Datenbank bietet der TLR auch die Möglichkeit, die Daten direkt in eine Datei im File-
ORDIX News 3/2006
Abb. 1: Beispiel zur Erstellung einer Schemadatei mit Hilfe des Befehls dbschema.
database DB1;
create table "informix".kunde
(
kundennr serial not null,
kundenname char(15),
kundenanschrift char(45),
primary key(kundennr)
);
insert into kunde
select * from "informix".kunde;
Abb. 2: Beispiel einer einfachen Schemadatei für den Table Level Restore.
database DB1;
create table "informix".kunde
(
kundennr serial not null,
kundenname char(15),
kundenanschrift char(45),
primary key(kundennr)
);
database DB2;
create table "informix".kunde_newDB
(
kundennr serial not null,
kundenname char(15),
kundenanschrift char(45),
primary key(kundennr)
);
insert into DB2:kunde_newDB
select * from DB1:kunde;
Abb. 3: Beispiel eines datenbankübergreifenden Table Level Restores.
database DB1;
create table "informix".kunde
(
kundennr serial not null,
kundenname char(15),
kundenanschrift char(45),
primary key(kundennr)
);
insert into kunde
select * from "informix".kunde;
restore to "2006-06-23 18:43:29"
Abb. 4: Beispiel eines Table Level Point in Time Restores (TLPITR).
11
Datenbanken
database DB1;
create table "informix".kunde
(
kundennr serial not null,
kundenname char(15),
kundenanschrift char(45),
primary key(kundennr)
);
create external table external_kunde
(
kundennr serial not null,
kundenname char(15),
kundenanschrift char(45),
primary key(kundennr)
)
USING ('external_table.unl','DELIMITED');
insert into external_kunde
select * from "informix".kunde;
Abb. 5: Verwendung von externen Tabellen mit Hilfe des Table Level
Restores.
System zu schreiben. Hierbei nimmt jeder Datensatz der Tabelle
eine Zeile in der Datei ein. Die einzelnen Spalten werden durch
ein Trennzeichen voneinander abgegrenzt, welches bei Informix
standardmäßig das Pipe-Zeichen ( | ) ist. Über die Umgebungsvariable DBDELIMITER kann dieser Wert jedoch nach Belieben
verändert werden.
Die Steuerung erfolgt auch hier anhand der Schemadatei. Im oberen Teil werden die Datenbank und die Tabelle ausgewählt, von der
die Daten ermittelt werden sollen. Im unteren Teil wird dann zusätzlich eine externe Tabelle angelegt, durch die mittels der USING-Anweisung die Datei deklariert wird (siehe Abbildung 5).
Abschließend folgt das insert-Statement,
das die Daten der Quelltabelle in die externe
Tabelle und somit in die Datei schreibt.
Fazit
Der Table Level Restore kann im Bereich des
Backup und Recovery von sehr großem Nutzen sein. Insbesondere dann, wenn von einer
Datenbank nur einzelne Tabellen inkonsistente Daten aufweisen oder durch Anwenderfehler verloren gegangen sind und somit wieder
hergestellt werden müssen.
Für den DBA kann der TLR eine enorme Zeitersparnis bedeuten, da nicht erst eine komplette Datenbank wieder hergestellt werden
muss, aus der dann die benötigten Daten der
betroffenen Tabellen zusammengesucht werden müssen.
Jedoch sollte man nicht nur den Bereich der
Wiederherstellung der Daten nach einem Datenverlust betrachten. Auch bei der Erstellung
einer Testumgebung zum Beispiel, in der nur
bestimmte Tabellen benötigten werden, kann
man mit diesem Feature viel Zeit und Ressour­
cen sparen. Somit stellt TLR auch eine Alternative zu den bestehenden Import- und Export
Tools dar.
Haben Sie Fragen? Dann fordern Sie uns!
Thorsten Schuhmacher ([email protected]).
Seminar: Informix Backup & Recovery mit ON-Bar
Der Teilnehmer lernt, Sicherungen und Restaurierungen des Informix Dynamic Servers (IDS) mit ON-Bar und einem Storage Manager zu erstellen.
Seminarinhalte
Voraussetzungen
• Restaurierung unter Vermeidung von
Tiefgehende Kenntnisse des Betriebssystems Unix oder Windows.
Tiefgehende Kenntnisse des Datenbanksystems Informix Dynamic
Server oder Teilnahme am Seminar „Informix Dynamic Server Administration“. Kenntnisse über Storage Manager.
• Sicherung von IDS mit ON-Bar
• Erstellung von Sicherungsplänen für den
Zielgruppe
•
•
• Informix Werkzeuge zum Sichern des IDS
• Sicherungskonzepte: Vollsicherung, Log­
sicherung, Online-/Offline Sicherung
Datenbankadministratoren, Softwareentwickler, Systembetreuer.
Datenverlust (Was tue ich, wenn ...?)
IDS mit Storage Manager Systemen (z. B.
NetWorker, Hiback, ISM)
Restaurierung eines IDS
Ausführliche Übungen zu allen Punkten
Termine
Kursgebühr/Teilnehmer:
1090,00 Euro zzgl. MwSt.
Dauer: 3 Tage
12
04.10.2006 - 06.10.2006in Wiesbaden
19.03.2007 - 21.03.2007in Wiesbaden
30.07.2007 - 01.08.2007in Wiesbaden
05.11.2007 - 07.11.2007 in Wiesbaden
ORDIX News 3/2006
Unix/Linux/Open
Unix/Linux/Open
Source - Titelthema
Source
Vergleich der Open Souce Lösung XEN mit anderen Virtualisierungslösungen
XEN – Ein neuer Stern am Himmel?
In früheren ORDIX News berichteten wir des Öfteren über die Virtualisierungslösung ESX-Server von VMware. Das Thema Virtualisierung wird aber nicht nur durch VMware bedient. Mittlerweile gibt es auch von anderen, kommerziellen Anbietern vergleichbare Lösungen sowie auch Lösungen aus dem Open Source Umfeld. Wir geben Ihnen einen Überblick über die Open Source Lösung XEN im Vergleich zu anderen Virtualisierungslösungen.
Virtualisierung in aller Munde
Die Firma VMware [1] bietet Produkte aus dem
Virtualisierungsbereich an, die für verschie­de­ne
Bereiche eingesetzt und genutzt werden können. Diese Art der gleichzeitigen Nutzung einer Hardware durch mehrere Betriebssys­teme
ist erst in den letzten Jahren ak­tuell geworden.
Grund hierfür ist unter anderem, dass die aktuell zur Verfügung stehenden Prozessoren wesentlich leistungsfähiger und Arbeitsspeicher
deutlich günstiger gewor­den sind.
Dieser Artikel richtet sich an Berater, Systemadministratoren
und Entscheider, die sich mit dem Thema Virtualisierung auseinandersetzen.
Was bietet XEN in der aktuellen Version?
• Unterstützung virtualisierender Intel- und AMD-Prozessoren
• Unterstützung von Symmetric Multiprocessing (SMP) im Gastbetriebssystem
• Unterstützung von 64 Bit CPUs
• Dynamische Verteilung der Gastsysteme auf die vorhandenen CPUs
Verwaltung von bis zu 100 Betriebssystemen
Sichere Trennung der Gastsysteme untereinander
Online-Ressourcenzuweisungen (RAM, Prozessoren, etc.)
Online-Migration von Gastsystemen auf andere XEN-Server
Neben VMware hat auch Microsoft mit dem
Virtual PC 2004 und Virtual Server 2005 [2] Produkte für den Heim- und Enterprise-Bereich ins
Rennen geschickt.
•
•
•
•
Auch im Open Source Bereich verschläft man
die Aktualität dieses Themas nicht und schickt
mit XEN [3] Kernelpatch und Verwaltungstools
in Richtung Zielgerade.
Was fehlt XEN momentan (noch)?
• XEN arbeitet in der aktuellen Version kommandozeilenorientiert. Es fehlen die GUIs zur Administration.
• Die Emulation ist noch auf bestimmte Betriebssysteme als
Kann XEN den kommerziellen Produkten Paroli
bieten? Ein tabel­larischer Vergleich zu anderen
Virtualisierungs­lösungen gibt Abbildung 2.
Hallo!
Mein Name ist XEN, der Neue im Bunde
XEN ist eine Open Source Virtualisierungslö­
sung, die unter der General Public License (GPL)
steht und von der Universität Cambrid­ge entwickelt wird. XEN läuft auf 32 und 64 Bit Intelund AMD-Prozessoren (siehe Abbildung 1).
Die­se werden für die darauf laufenden Gastsysteme paravirtualisiert.
Gast beschränkt.
• XEN ist standardmäßig noch nicht im Linux-Kernel enthalten.
Der Kernel erfordert einen entsprechenden Patch.
Das wahrscheinlich größte Manko
Da XEN nicht mit kommerziellem Hintergrund entwickelt wird, fehlen aktuell noch Tools, die die administrative Arbeit erleichtern.
Dabei wird eine sehr hohe Performance erzielt,
weil die Hardware nicht emuliert werden muss.
Diese wird den Gastsystemen mit einem sehr
kleinen Overhead zur Verfügung gestellt.
Als Gastsysteme (Domains) können momentan Linux, FreeBSD, NetBSD und OpenSolaris eingesetzt werden. Im Zuge der neuen Prozessorgenerationen Vanderpool (Intel) und Pacifica (AMD) werden auch Microsoft Windows
Betriebssysteme in den Genuss des Gastes
kommen.
ORDIX News 3/2006
Abb. 1: Vier virtuelle Maschinen in Aktion.
13
Unix/Linux/Open Source
Produkt
Hersteller / Version
Wirtsbetriebssystem
Gastsystem
Virtuelle Hardware
Leistungsverlust Gast
Support für Vanderpool, Pacifica
Kommandozeilenunterstützung
GUI Administration
Sicherung der Gäste
Snapshots
Max. Anzahl Prozessoren
Max. virtuelle Prozessoren / Gast
Max. virtueller RAM
NICs / Gast
Installation Gast
Onlinemigration auf andere
Wirtsbetriebssysteme
Vervielfältigung der Gastbetriebs­systeme
(Cloning)
Ressourcenüberwachung der Gäste
Lizensierung
ESX-Server
VMware / 3
Redhat Linux
Wirtsbetriebssystem ist im
ESX Server enthalten.
Windows, Linux, Novell,
Solaris
NIC, SCSI, IDE, Parallel,
Seriell
3 – 18 %
Ja
Ja
Ja
Imagebasiert
Ja
16
4
Virtual Server
Microsoft / 2005 R2
Windows
XEN
www.xen.org / 3.0
Linux
Windows (Linux inoffiziell)
Windows, Linux, BSD,
OpenSolaris
NIC, SCSI, IDE, Parallel,
Seriell, USB
bis 5 %
Ja
Ja
Nein / in Entwicklung
Imagebasiert
Nein
32
max. 32
16 GB
4
CDrom
Ja
NIC, SCSI, IDE, Parallel,
Seriell
12 – 25 %
Nein
Ja
Ja
Imagebasiert
Ja
32
1 / momentan kein SMP
der Gäste möglich
3 GB
4
CDrom
Nein
Manuell,
Drittanbieter­produkte
Ja
Pro CPU
Manuell,
Drittanbieterprodukte
Ja
199 $ / je Virtual Server
Wie Host-OS
>4
CDrom, Templates
Ja
Manuell
Ja
GPL / Open Source
Abb. 2: Übersicht über die aktuellen Virtualisierungslösungen.
XEN wird ohne grafisches Managementtool ausgeliefert, so dass
die Verwaltung und Installation der Gastbetriebssysteme auf die
Kommandozeilenebene beschränkt ist. Zum Beispiel kann man
mit dem Befehl xentop Informationen über die verwendeten Ressourcen anzeigen lassen (siehe Abbildung 3).
Die Open Source Gemeinde ist dabei, Lösungen zu entwickeln,
die eine grafische Administration und Überwachung der virtuellen
Gäste ermöglichen. Auch der Distributor Novell liefert in der aktuellen SUSE Linux Version eine Möglichkeit, XEN-Gäste mit Hilfe
von YaST zu installieren.
Einstiegsschwierigkeiten
Momentan befindet sich XEN noch nicht im Vanillakernel. Dadurch
ist man auf die Hilfe der Distributoren oder auf eigenes Geschick
angewiesen. Der Kernel muss „gepatcht“ und kompiliert werden.
Abb. 3: Ressourcenmanagement mit XEN.
Links
► [1] http://www.vmware.com
► [2] http://www.microsoft.com/windowsserversystem
Es ist aber in naher Zukunft abzusehen, dass
XEN Teil des stabilen Kernels wird.
Auch die Installation eines Gastbetriebssystems ist nicht trivial und benötigt tiefgreifende
Linux-Kenntnisse. Ein Linux muss beispielsweise entweder in einer Chroot-Umgebung ins­
talliert oder ein vorhandenes Linux geclont und
verändert werden.
Fazit
XEN muss sich im Vergleich zu den kommerziellen Produkten nicht verstecken. Dafür, dass
es im Vergleich zu den bekannten Produkten
noch ein recht junges Produkt ist, leistet es Erstaunliches. Viele Internetanbieter stellen momentan auf XEN um, um so genannte RootServer anzubieten. Und die ersten Distributo­
ren bringen Linux-Komplettpakete mit XENUnterstützung heraus.
Auch die kommerziellen Hersteller sind durch
den Neuling „alarmiert“ und reagieren mit kostenlosen Download-Varianten ihrer Produkte
auf die Open Source Lösung XEN. Viel wird davon abhängen, wie sich die Qualität und Flexibilität der Lösung zukünftig entwickelt. In einer
der nächsten Ausgaben werden wir die Lösung
XEN näher beleuchten.
/virtualserver/default.mspx
► [3] http://www.cl.cam.ac.uk/Research/­SRG/netos/xen/
14
Christian Fertsch ([email protected]).
ORDIX News 3/2006
Java/XML
Vorstellung der Ajax JSP Tag Library
Web-Entwicklung mit den Ajax-Tags
Mit Hilfe von Ajax können Web-Anwendungen so programmiert werden, dass die Bedienbarkeit ähnlich komfortabel wie bei klassischen Desktop-Anwendungen wird. Dies liegt daran, dass der Browser in der Lage ist,
mit dem Server zu kommunizieren, ohne dass die Web-Seite vollständig neu geladen werden muss. Das Ergebnis kann eine in der Handhabung beschleunigte und intuitivere Web-Anwendung sein.
Dieser Artikel richtet sich an Java-Entwickler, die ihre Web-Anwendungen mit Ajax-Funktionalität ausstatten möchten.
bei Verwendung von JSP 1.x der Tag Library
Descriptor in der web.xml der Anwendung bekannt gegeben werden.
Wo finde ich Ajax-Anwendungen im Web?
Schließlich werden noch (mindestens) zwei
JavaScript-Dateien benötigt:
Eines der bekanntesten und umfangreichsten Beispiele einer AjaxAnwendung ist wohl Google Maps [1]. Weitere Google-Beispiele,
wie z. B. Google Suggest, lassen sich über [2] aufrufen. Aber auch
in kleinerem Rahmen lässt sich Ajax einsetzen, um die Bedienung
von Webseiten komfortabler zu gestalten. Einige solcher Beispiele
sind unter [3] oder auf der Ajax-Tags-Seite [4] zu finden.
1. prototype.js, da die Ajax-Tags auf dem Prototype Framework [7] basieren.
2. ajaxtags.js, die eine Reihe von Ajax-Funktionalitäten bereitstellt.
Ajax in Form von Tags
Im Folgenden wird beispielhaft gezeigt, wie
die Ajax-Tags in eine JSP-Seite integriert werden, um eine automatische Vervollständigung
zu realisieren.
Um Web-Anwendungen mit Ajax umzusetzen, benötigt man ein
fundiertes JavaScript-Wissen. Möchte der Entwickler die clientseitige JavaScript-Programmierung vermeiden und seine Webseiten
trotzdem mit Hilfe von Ajax dynamisieren, lohnt sich ein Blick auf
das AjaxTags-Projekt [5].
Ein Beispiel:
Automatische Vervollständigung
Mit Hilfe der dort bereitgestellten Tag Library lassen sich Java Server Pages um einige interessante Ajax-Funktionalitäten erweitern.
Dieser Artikel zeigt beispielhaft die Verwendung der Ajax-Tags und
macht auf Probleme bei der Umsetzung aufmerksam.
Welche Vorbereitungen muss ich treffen?
Sämtliche Dateien, die zur Verwendung der Ajax-Tags benötigt
werden, sind unter [6] erhältlich. Die eigentliche Taglib muss in
Form eines jar-Archivs eingebunden werden. Des Weiteren muss
Was ist Ajax?
Oft ist es wünschenswert, dass auf Basis einer Eingabe, z. B. in ein Textfeld, verschiedene
Auswahlmöglichkeiten angezeigt werden. Folgender Ablauf findet in diesem Fall bei Implementierung mit Hilfe von Ajax statt:
Der Benutzer gibt die gewünschten Buchstaben ein. Anschließend wird ein XMLHTTP-Request an den Server geschickt. Der Server verarbeitet den Request, ermittelt die notwendigen
Daten und schickt diese an den Client zurück.
Anschließend bekommt der Benutzer die Aus­
wahl­mög­lich­kei­ten vom Server zu Gesicht, ohne
dass die Web­seite neu geladen werden muss.
Ajax steht für Asynchronous JavaScript and XML. Kern von
Ajax ist das XMLHTTP-Request Objekt (beziehungsweise das
XMLHTTP-Objekt beim Internet Explorer), welches von aktuellen Browsern unterstützt wird. XMLHTTP-Requests können gesendet werden, ohne dass die Webseite neu aufgebaut werden muss.
Die Daten werden üblicherweise in Form von XML übermittelt. Auf der Clientseite wird JavaScript benötigt, um zu entscheiden, wann und mit welchen Daten ein XMLHTTP-Request abgeschickt wird und auf welche Weise die angeforderten Daten aus dem Response dann in die Webseite eingebaut werden.
18
Abb. 1: Automatische Vervollständigung mit Hilfe der Ajax-Tags.
ORDIX News 3/2006
Java/XML
Als Beispiel soll nun ein Textfeld dienen, welches in einem HTML-Formular platziert wird.
Gibt der Benutzer in das Textfeld einen Buchstaben ein, z. B. ein „J“ (siehe Abbildung 1),
werden alle Seminare angezeigt, die mit diesem Buchstaben beginnen.
Über „minimumCharacters=1“ (Zeile 7) wird festgelegt, dass die
Auswahlliste schon bei Eingabe eines Buchstabens aufgebaut wird.
Schließlich wird noch mitgeteilt, dass der Response des Servers
im XML-Format vorliegt (Zeile 8).
Das HTML-Formular wird, wie in Abbildung 2
zu sehen ist, definiert.
Nachdem die JSP auf diese Weise mit Ajax-Funktionalität ausgestattet wurde, muss sich der Entwickler um die serverseitige Komponente kümmern. Welche Technologie er dort einsetzt, ist ihm
überlassen. Abbildung 4 zeigt kurz auf, wie ein Servlet aussehen
kann, das die Verarbeitung auf dem Server vornimmt.
Um die automatische Vervollständigung mit
Hilfe der Ajax-Tags zu realisieren, wird das
Tag <ajax:autocomplete> verwendet (siehe Abbildung 3).
Bedeutung der einzelnen Attribute
In dem Beispiel in Abbildung 3, Zeilen 2 und
3, sind das „source“- und „target“-Attribut auf
dasselbe Textfeld innerhalb des HTML-Formulars gesetzt. D. h. der Benutzer bekommt
die Auswahl und das Ergebnis im selben Feld
angezeigt.
Das Attribut „baseUrl“ (Zeile 4) definiert, welche URL zur serverseitigen Verarbeitung des
Requests aufgerufen wird. In diesem Fall küm­
mert sich das AjaxServlet um die Verarbeitung. Über „className“ (Zeile 5) wird eine
CSS-Klasse zur Generierung der Auswahlliste angegeben.
In der mitgelieferten Datei „ajaxtags.css“ befindet sich neben einer Reihe weiterer Stylesheets die entsprechende Klasse „autocomplete“. Mit Hilfe von „indicator“ (Zeile 6) kann
optional ein Bild festgelegt werden.
Dieses sig­nalisiert dem Benutzer, dass die
Auswahlliste aufgebaut wird, bzw. der Response vom Server erwartet wird.
Solche Hinweise sollten dem Benutzer generell gegeben werden, da – Ajax wie der Name
schon sagt – asynchron arbeitet. Der Anwender würde sonst nicht mitbekommen, dass eine Verarbeitung stattfindet.
Die Verarbeitung auf dem Server
Die Klasse erbt von der Klasse BaseAjaxServlet, welche Teil der
Ajax Tag Bibliothek ist (Zeile 1). Die Methode getXMLContent()
(Zeile 3) ermittelt zunächst den übergebenen Parameter. In unserem Beispiel das vom Benutzer eingegebene „J“.
Dann werden alle Seminare, die mit dem Buchstaben „J“ beginnen,
in einer Liste gespeichert. Schließlich wird aus dieser Liste ein XMLkonformer String generiert und zurückgegeben (Zeile 7).
1 <form action=".">
2 <fieldset>
3 <legend>Seminarauswahl</legend>
4 <p>Bitte wählen Sie ein Seminar aus</p>
5 <label for="seminar">Seminar:</label>
6 <input id="seminar" name="seminar" type="text" size="30" />
7 <span id="indicator" style="display:none;">
8 <img src="${contextPath}/img/indicator.gif" />
9 </span>
10 </fieldset>
11</form>
Abb. 2: Definition des HTML-Formulars.
1 <ajax:autocomplete
2
source="seminar"
3
target="seminar"
4
baseUrl="${contextPath}/AjaxServlet"
5
className="autocomplete"
6
indicator="indicator"
7
minimumCharacters="1"
8
parser="new ResponseXmlParser()" />
Abb. 3: Verwendung des Ajax-Tags <ajax:autocomplete> zur automatischen Vervollständigung.
1 public class AjaxServlet extends BaseAjaxServlet {
2
3
public String getXmlContent(HttpServletRequest request, HttpServletResponse response)
4
throws Exception {
5
6
String seminar = request.getParameter("seminar");
7
Service service = new Service();
8
List list = service.getSeminareByName(seminar);
8
10
return new AjaxXmlBuilder().addItems(list, "seminar", "result").toString();
11 }
12}
Abb. 4: Beispiel eines Servlets, das die Verarbeitung des Requests auf dem Server vornimmt.
ORDIX News 3/2006
19
Java/XML
Die zweite Möglichkeit besteht darin, eine Version bereitzustellen, die auch ohne JavaScript
und damit auch ohne Ajax auskommt.
Links
►
►
►
►
►
►
[1] http://maps.google.com
[2] http://labs.google.de/
[3] http://wiki.script.aculo.us/scriptaculous/show/Demos
[4] http://ajaxtags.no-ip.info/
[5] http://ajaxtags.sourceforge.net/
[6] http://sourceforge.net/project
/showfiles.php?group_id=140499
► [7] http://prototype.conio.net/
► [8] http://www.mozilla.org/projects/venkman/
Glossar
Ajax
Asynchronous JavaScript and XML. Ajax ist ein Konzept, das den asynchronen Austausch von XMLNachrichten zwischen Client und Server erlaubt, ohne dass eine Webseite komplett neu geladen werden muss.
Tag Library Bestandteil der JSP-Spezifikation zur Erstellung dynamischer Webseiten.
JSP
Java Server Pages; Technologie von Sun Microsystems zur Erstellung dynamischer Webseiten.
XML
JavaScript
Extensible Markup Language; Standard zur Gliederung von Daten in einer Baumstruktur.
Clientseitig vom Browser interpretierte Skriptsprache.
Grenzen und Möglichkeiten der Ajax-Tags
Das Beispiel zeigt, dass eine Funktion wie die Autovervollständigung mit wenig Aufwand zu erstellen ist.
Problematisch kann jedoch die Fehlersuche werden. Ist zum Beispiel das Attribut „baseUrl“ falsch gesetzt und die Serverkomponente kann nicht gefunden werden, wird kein JavaScript-Fehler
generiert. Da bleibt dann nur die Möglichkeit, sich dem Fehler mit
entsprechenden „alert()“-Ausgaben in der Prototype-Bibliothek zu
nähern oder einen JavaScript-Debugger zu verwenden.
Für den Mozilla und Firefox gibt es z. B. den Venkman JavaScriptDebugger. [8]
Des Weiteren ist es schwierig, die Funktionalitäten der Tags auf
spezielle Bedürfnisse anzupassen. So lässt sich z. B. das <ajax:
callout> Tag dazu verwenden, ein Pop-Up zu generieren, welches
mit Daten vom Server versorgt wird.
Zusätzlich ist zu bedenken, dass JavaScript
unter Umständen von unterschiedlichen Browsern verschieden interpretiert wird. Deshalb
sollte die Web-Anwendung auf mehreren Brow­
sern getestet werden.
Performance
Ein Entscheidungskriterium zum Einsatz von
Ajax können auch Performance-Überlegungen
sein. Generell lässt sich festhalten, dass bei
der Verwendung von Ajax eine größere Anzahl
von (XMLHTTP)-Requests an den Server gesendet werden als bei klassischen Web-An­
wen­dungen.
Dies führt zu einer höheren Beanspruchung
des Servers. Andererseits können über XML­
HTTP-Requests Daten gezielter angefordert
werden, sodass sich das zu übertragene Datenvolumen unter Umständen deutlich reduzieren lässt.
Fazit
Hat man sich einmal mit den Ajax-Tags vertraut
gemacht, lassen sich diese zügig auf andere Anwendungsfälle übertragen. An den passenden Stellen eingesetzt, führt die asynchrone, im Hintergrund ablaufende Kommunikation mit dem Server zu mehr Komfort bei der
Bedienung.
Das zu übertragende Datenvolumen lässt sich
in bestimmten Fällen stark reduzieren, was zu
schnelleren Antwortzeiten führt. Ob dies die
höhere Last durch eine größere Anzahl von
Server-Requests wert ist, muss sicher im Einzelfall entschieden werden.
Die Dokumentation der Tags ist – wie häufig
bei Open Source Projekten – sehr knapp gehalten. Es lohnt sich ein Blick auf die vorhandenen Beispiele der Ajax-Tags-Seite, da diese
gut nachvollziehbar und umzusetzen sind.
Ein Blick in die ajaxtags.js Bibliothek verrät, dass dieses Pop-Up
über den JavaScript Eventhandler OnMouseOver erstellt wird. Soll
dieses Verhalten geändert werden und das Pop-Up z. B. bei einem
OnClick erscheinen, muss die Bibliothek verändert werden. Das
hat zur Folge, dass sie bei jedem Update auf eine neue Version
neu angepasst werden muss.
Ein weiterer Aspekt, den der Entwickler bedenken sollte, ist, dass
JavaScript im Browser abgeschaltet werden kann. In diesem Fall
wäre es vorteilhaft, dem Benutzer mitzuteilen, dass die Webseite JavaScript benötigt.
20
Jens Stahl ([email protected]).
ORDIX News 3/2006
Aktuell
Rekorde, Rekorde, Rekorde:
ORDIX Open mit
neuen Höchstleistungen
„Rekorde sind zum Brechen da …“ so Organisator Hans-Walter Schmitt
zufrieden zu dem ORDIX Open, „dem“ offenen Turnier im Rahmen des
diesjährigen Schnellschach-Festivals in Mainz. Vom 15. - 20.08.2006 fanden in der Rheingoldhalle in Mainz
die so genannten „Chess Classic“ statt – ein Schachturnier der ungewöhnlichen Art, das von Jahr zu Jahr
eine größere Pilgerschaft anzieht.
„ORDIX Open: Hol dir den Titel!“
Das ORDIX Open hat sich als Meltingpott von Deutschlands viel­
seitigstem und teilnehmerstärksten Schachfestival auch in diesem
Jahr hervorgetan. Neben dem traditionellen Stelldichein der Spit­
zengrößen des Weltschachs fanden sich zahlreiche Nach­wuchs­
schachspieler ein.
Abb. 1: Tilo Knott (2. v. l.) im Simultan gegen Welt­
ranglistendritten Levon Aronjan. Im Vordergrund
Prof. Eckhard Freise, der durch die Günter Jauch
Show als erster Millionengewinner Bekanntheit
erlangte.
Damit avanciert das ORDIX Open als tra­diti­o­nelles, offenes Schnell­
schachturnier zum Schmelztiegel der Be­gegnungen in der Schach­
welt. Die Teilnehmerzahl klet­terte auf 632 Personen, davon 58 Groß­
meister, 10 Großmeisterinnen, 44 Internationale Meis­ter und 9 weib­
liche Internationale Meis­ter.
Unter dem Motto „Hol dir den Titel!“ verloste ORDIX zwei Plätze gegen
den Weltranglistenzweiten Anand und den Weltranglistendritten
Aron­jan (Armenien).
Wir gratulieren den Gewinnern der ORDIX Ver­­­lo­sungen, Herrn Tilo
Knott (Schachclub Brett vor‘m Kopp, Frank­furt) und Herrn Andreas
Maatz aus Frankfurt, die sich kühn ihren Gegnern stellten.
11 Runden dominierend
Abb. 2: „Jung und Alt“ boten sich Paroli, hier Dr.
Doris Lübbers gegen Vlada Boyarchenko.
Foto: Harald Fietz, Berlin
Als Gewinner des ORDIX Open ging letztlich kein geringerer als der
Ex-Weltmeister Rustam Kasimdschanow hervor. In elf Runden gab
der gebürtige Usbeke nur drei Remis ab. Summa Summarum fand
sich eine illustre Gesellschaft zusammen. Weitere Informationen
und Links finden Sie im Internet unter http://www.ordix.de/ordixopen/
Die Redaktion ([email protected]).
Abb. 3: Siegerehrung des ORDIX Open (v. l.): Chef-Organisator Hans-Walter Schmitt und ORDIX Marketingleiterin Helma
Jenniches gratulierten dem ORDIX Open Gewinner und Ex-Weltmeister Rustam Kasimdschanow, der den Weltranglistenzwölften Schachrijar Mamedjarow hauchdünn besiegte. Die Plätze 3, 4 und 5 gingen an den favorisierten Weltranglistenneunten GM Alexander Morosewitsch, GM Pentela Harikrishna und GM Mikhail Mchedlishvili. Foto: Harald Fietz, Berlin
ORDIX News 3/2006
21
- herausnehmbare Übersicht -
Datenbanken
Oracle SQL
Oracle SQL für Experten
Oracle SQL für Umsteiger
Oracle Datenbankprogrammierung mit PL/SQL
Oracle PL/SQL Aufbau mit LOB Programmierung
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 Security Workshop
Oracle Data Guard Workshop
Oracle RMAN Workshop
Oracle Grid Control Workshop
Oracle Replikation Workshop
Oracle Advanced Queuing 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
IBM DB2 UDB für Unix/Windows Version 9.1 Neuheiten
MySQL Administration
Microsoft SQL Server Administration
Microsoft SQL Server 2005 Neuheiten
Microsoft SQL Server Hochverfügbarkeits-Workshop
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
PHP Programmierung Grundlagen
PHP Programmierung Aufbau
Shell, Awk und Sed
Java-J2EE
Java Programmierung Grundlagen
Java Programmierung Aufbau
Java GUI Entwicklung mit Swing
J2EE für Entscheider
Einführung in J2EE
JSP und Servlet Programmierung
EJB Programmierung
Webanwendungen mit Java Server Faces (JSF)
Java Web Services
Entwicklung mit Hibernate
Systemmanagement
BMC PATROL/Performance Manager Basics
BMC PATROL/Performance Manager Customizing and Development
Web- und Applikations-Server
Apache Web-Server Installation und Administration
Tomcat Konfiguration und Administration
WebSphere Application Server Installation und Administration
Administration und Konfiguration für JBoss
Betriebssysteme
Unix/Linux Grundlagen für Einsteiger
Linux Systemadministration
Linux Netzwerkadministration
Server-Virtualisierung mit XEN
Linux Hochverfügbarkeits-Cluster
Unix/Linux Security
Solaris Systemadministration Grundlagen
Solaris Systemadministration Aufbau
Solaris 10 für erfahrene Systemadministratoren
Solaris Containers
Solaris für Unix Umsteiger
Multivendor-Systemadministration
Projektmanagement
IT-Projektmanagement
Grundlagen des IT-Controlling
Wiesbaden
Saarbrücken
1790,00
1190,00
790,00
1790,00
1190,00
1890,00
1890,00
1890,00
1890,00
1890,00
1490,00
1890,00
1190,00
1490,00
1490,00
1090,00
790,00
1090,00
1590,00
1790,00
1890,00
1090,00
1790,00
1890,00
790,00
1090,00
1790,00
790,00
790,00
1090,00
1590,00
1590,00
1090,00
790,00
1590,00
1090,00
1590,00
1590,00
1590,00
1590,00
450,00
1090,00
1590,00
1590,00
1590,00
1090,00
1090,00
1890,00
1490,00
1090,00
1090,00
1290,00
1090,00
1590,00
1590,00
1590,00
1090,00
1190,00
1590,00
1890,00
1890,00
1890,00
790,00
1890,00
1890,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.
22
ORDIX
ORDIX News
News 3/2006
3/2006
KW 52
KW 51
KW 50
KW 49
KW 48
Dezember
KW 47
KW 45
KW 44
November
KW 43
KW 42
KW 41
KW 40
Oktober
Preis in
EURO*)**)
KW 46
Aus- & Weiterbildung
Seminartermine
http://training.ordix.de
Online-Anmeldung und stets aktuelle
Seminarinhalte und Termine!
KW 13
KW 12
KW 11
KW 10
KW 9
März
KW 8
KW 7
KW 6
KW 5
Februar
KW 4
KW 3
KW 2
KW 1
Januar
Aus-Oktober
& Weiterbildung
2006 - März 2007
Preis in
EURO*)**)
1790,00
1190,00
790,00
1790,00
1190,00
1890,00
1890,00
1890,00
1890,00
1890,00
1490,00
1890,00
1190,00
1490,00
1490,00
1090,00
790,00
1090,00
1590,00
1790,00
1890,00
1090,00
1790,00
1890,00
790,00
1090,00
1790,00
790,00
790,00
1090,00
1590,00
1590,00
1090,00
790,00
1590,00
1090,00
1590,00
1590,00
1590,00
1590,00
450,00
1090,00
1590,00
1590,00
1590,00
1090,00
1090,00
1890,00
1490,00
1090,00
1090,00
1290,00
1090,00
1590,00
1590,00
1590,00
1090,00
1190,00
1590,00
1890,00
1890,00
1890,00
790,00
1890,00
1890,00
1890,00
1190,00
Datenbanken
Oracle SQL
Oracle SQL für Experten
Oracle SQL für Umsteiger
Oracle Datenbankprogrammierung mit PL/SQL
Oracle PL/SQL Aufbau mit LOB Programmierung
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 Security Workshop
Oracle Data Guard Workshop
Oracle RMAN Workshop
Oracle Grid Control Workshop
Oracle Replikation Workshop
Oracle Advanced Queuing 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
IBM DB2 UDB für Unix/Windows Version 9.1 Neuheiten
MySQL Administration
Microsoft SQL Server Administration
Microsoft SQL Server 2005 Neuheiten
Microsoft SQL Server Hochverfügbarkeits-Workshop
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
PHP Programmierung Grundlagen
PHP Programmierung Aufbau
Shell, Awk und Sed
Java-J2EE
Java Programmierung Grundlagen
Java Programmierung Aufbau
Java GUI Entwicklung mit Swing
J2EE für Entscheider
Einführung in J2EE
JSP und Servlet Programmierung
EJB Programmierung
Webanwendungen mit Java Server Faces (JSF)
Java Web Services
Entwicklung mit Hibernate
Systemmanagement
BMC PATROL/Performance Manager Basics
BMC PATROL/Performance Manager Customizing and Development
Web- und Applikations-Server
Apache Web-Server Installation und Administration
Tomcat Konfiguration und Administration
WebSphere Application Server Installation und Administration
Administration und Konfiguration für JBoss
Betriebssysteme
Unix/Linux Grundlagen für Einsteiger
Linux Systemadministration
Linux Netzwerkadministration
Server-Virtualisierung mit XEN
Linux Hochverfügbarkeits-Cluster
Unix/Linux Security
Solaris Systemadministration Grundlagen
Solaris Systemadministration Aufbau
Solaris 10 für erfahrene Systemadministratoren
Solaris Containers
Solaris für Unix Umsteiger
Multivendor-Systemadministration
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 3/2006
3/2006
zentrales Fax: 0180 1 ORDIX 0
bzw. 0180 1 67349 0
E-Mail: [email protected]
Online-Anmeldung: http://training.ordix.de
23
Datenbanken - Titelthema
Datenkompression unter Oracle
Mit der Oracle 9i R2 Enterprise-Version wurde die Möglichkeit der Tabellenkompression, genauer DATA SEGMENT COMPRESSION, eingeführt. Dieser Artikel gibt einen Überblick zum Einsatz dieser Option.
bol-Tabelle. Mehrfach auftretende Datenwerte werden ausschließlich in der Symboltabelle gespeichert.
Dieser Artikel wendet sich an Datenbankadministratoren und
-entwickler, die sich in Data-Warehouse-Umgebungen mit der
komprimierten Speicherung von Daten beschäftigen.
Data-Warehouse-Umgebungen bestehen sehr häufig aus wenigen
großen Tabellen, die teilweise redundante Informationen enthalten. Mit Blick auf Speicherkapazitäten und Zugriffszeiten kommt
der Wunsch auf, die Daten in komprimierter Form abzulegen.
Mit der Oracle 9i R2 Enterprise-Version wurde die DATA SEGMENT COMPRESSION eingeführt. Um einen Überblick über den
Einsatz dieser Option zu bekommen, möchten wir zunächst die
Arbeitsweise, die Konfigurationsmöglichkeiten und die Verwendung darstellen.
Anschließend geben einige Beispiele aus einem aktuellen Projekt
einen ersten Eindruck zu der möglichen, zu realisierenden Platzersparnis und zeigen die Auswirkungen auf die Performance auf. Eine weitere Möglichkeit zur Komprimierung von Daten ist die KEY
COMPRESSION. Sie kann bei Indizes bzw. indexorganisierten Tabellen (IOT) verwendet werden. Dieses Feature werden wir in diesem Artikel jedoch nicht behandeln.
Im restlichen Platz innerhalb des Blocks werden die eigentlichen Datensätze gespeichert.
Diese enthalten für die komprimierten Datenwerte Zeiger auf die Symboltabelle.
Die Platz­ersparnis ergibt sich aus der Verwendung der Zeiger, die weniger Speicherplatz als
die Datenwerte erfordern. Abbildung 1 zeigt
das Prinzip der Datenspeicherung innerhalb
eines Blocks einer normalen beziehungsweise einer komprimierten Tabelle.
Die dargestellten Datensätze würden in komprimierter Form 291 Byte und unkomprimiert
379 Byte belegen. In einem Block einer komprimierten Tabelle existieren komprimierte und
unveränderte Datenwerte und Datensätze nebeneinander.
Die wesentlichen Eigenschaften dieser Kompression auf Blockebene sind Folgende:
Wie wird komprimiert?
• Ein Datenblock enthält die vollständige In­
Die Datenkompression erfolgt auf Blockebene. Beim Einfügen in
die Tabelle wird nach mehrfach auftretenden Datenwerten innerhalb
eines Blocks gesucht. Für diese wird in jedem Block ein eigener
Bereich reserviert. In diesem Bereich liegt die so genannte Sym-
Tabelle PODIUM_LE_TOUR
Tabelle PODIUM_LE_TOUR_COMP
02
02
02
01
01
01
00
00
00
2005
2005
2005
2004
2004
2004
2003
2003
2003
Jan ULLRICH
3 T-MOBILE TEAM
Ivan Basso
2 TEAM CSC
1 DISCOVERY CHANNEL TEAM
Lance ARMSTRONG
Ivan Basso
3 TEAM CSC
2 T-MOBILE TEAM
Andreas KLÖDEN
US POSTAL-BERRY FLOOR
Lance ARMSTRONG
1
Alexandre VINOKOUROV
3 TEAM TELEKOM
Jan ULLRICH
2 TEAM BIANCHI
Lance ARMSTRONG
1
US POSTAL-BERRY FLOOR
formation über alle Datensätze innerhalb
des Blocks. Für einen Zugriff auf die Daten sind keine weiteren Informationen notwendig.
04 08 0A
05 07 0B
03 06 DISCOVERY CHANNEL TEAM
05 08 0B
Andreas KLÖDEN 07 0A
03 06 09
Alexandre VINOKOUROV 08 TEAM TELEKOM
04 07 TEAM BIANCHI
03 06 09
S 0B
S 0A
S 09
S 08
S 07
S 06
S 05
S 04
S 03
S 02
S 01
S 00
TEAM CSC
T-MOBILE TEAM
US POSTAL-BERRY FLOOR
3
2
1
Ivan Basso
Jan ULLRICH
Lance ARMSTRONG
2005
2004
2003
DatenTabelle
SymbolTabelle
Abb. 1: Prinzip der Speicherung von Daten in einer normalen und in einer komprimierten Tabelle.
24
ORDIX News 3/2006
Datenbanken
• Für den Anwender ändert sich beim Zugriff
•
•
auf die Daten nichts. Die Kompression ist
vollständig unsichtbar.
In komprimierter Form enthalten die Blöcke mehr Datensätze. Dadurch sinkt die
I/O-Last.
Die Daten werden in komprimierter Form
im Database-Buffer gehalten. Es können
also mehr Datensätze im zur Verfügung
stehenden Puffer gehalten werden.
-- Anlegen einer komprimierten Tabelle
CREATE TABLE podium_le_tour_comp
( jahr
DATE,
name
VARCHAR2(100),
platz
Number,
team
VARCHAR2(100) )
COMPRESS;
Abb. 2: Anlegen einer komprimierten Tabelle.
Wie wird die Datenkompression
eingerichtet?
Um eine komprimierte Tabelle zu erstellen,
wird beim Anlegen die Option COMPRESS
angegeben (siehe Abbildung 2). Damit wird
die Eigenschaft COMPRESSION der Tabelle
auf „ENABLED“ gesetzt. Beim Einfügen von
Daten werden dann zunächst die Möglichkeiten einer Komprimierung getestet.
Sehr wichtig ist auch, dass der Speicherparameter PCTFREE automatisch den Wert „0“
erhält. Es wird also kein Puffer für eventuelle
Updates gelassen. Dies ist jedoch auch nicht
notwendig, da Updates dem Konzept der Komprimierung widersprechen.
Nachträgliche Änderungen der Daten einer
kom­primierten Tabelle führen zunächst zu einer Dekomprimierung. Nach der Änderung wer­
den die Datensätze dann in unkomprimierter
Form wieder eingefügt. Dadurch geht die angestrebte Platzersparnis also verloren.
Weitere Möglichkeiten der Verwendung der
Eigenschaft COMPRESSION sind
• die Definition auf TABLESPACE-Ebene.
Dann erben alle Tabellen diese Eigenschaft.
• die Definition für eine partitionierte Tabel-
•
le. Die Kompression kann entweder für die
gesamte Tabelle oder für einzelne Partitionen eingerichtet werden.
die Definition für eine MATERIALIZED VIEW.
Diese kann direkt beim Anlegen mit „CREATE MATERIALIZED VIEW ... COMPRESS
AS ...;“ erfolgen. Mit „ALTER MATERIALIZED VIEW ... COMPRESS;“ werden die
Daten beim nächsten Aktualisieren in komprimierter Form abgelegt.
Wann wird die Datenkompression
verwendet?
Die Datenkompression erfolgt ausschließlich
beim Einfügen von Daten in die Tabelle. Das
beschriebene Verfahren wird jedoch nur angewandt, wenn mehrere Datensätze in einer Aktion eingefügt werden. Bei Datenmengen, die
kleiner als ein Block sind, wird keine Kompres­
ORDIX News 3/2006
-- Umwandeln einer bestehenden Tabelle
-- normal
-> komprimiert
ALTER TABLE tab_name MOVE COMPRESS;
-- komprimiert -> normal
ALTER TABLE tab_name MOVE NOCOMPRESS;
Abb. 3: Befehle zum Umwandeln einer bestehenden Tabelle.
sion durchgeführt. Zum Einfügen muss eine der folgenden Blockoperationen (BULK LOAD oder BULK INSERT) verwendet werden:
• Verwendung des SQL*Loader mit der Option „direct = true“
• Verwendung des Befehls
„CREATE TABLE . . . AS SELECT . . . “
• Einfügen von Daten mit „INSERT /*+ APPEND */ . . . “
• Einfügen von Daten mit
„INSERT /*+ PARALLEL( tab_name, n) */ . . . “
Wird keine der hier aufgeführten Möglichkeiten benutzt, werden
die Datensätze in normaler Form, also ohne Kompression, eingefügt.
Bei der Umwandlung einer bestehenden Tabelle in eine komprimierte mit „ALTER TABLE ... COMPRESS;“ wird nur die Eigenschaft umgeschaltet. Die bestehenden Datensätze werden nicht
geändert. Dies erfolgt erst mit den in Abbildung 3 aufgeführten Befehlen mit dem Zusatz „MOVE“.
Bei der Ausführung wird eine neue Tabelle mit der Eigenschaft
COMPRESSION angelegt. Danach erfolgt das Einfügen der Daten in komprimierter Form, das Löschen der alten Tabelle und das
Umbenennen der neuen Tabelle.
Was bringt die Datenkompression?
Die Auswirkungen der Datenkompression hängen stark von der jeweiligen Tabelle ab. Wir wollen hier beispielhaft mit den Daten aus
DBA_OBJECTS allgemeine Trends aufzeigen.
In Abbildung 4 sind die Unterschiede beim Anlegen mit „CREATE
TABLE ... AS SELECT * FROM dba_objects;“ dargestellt. Die
komprimierte Tabelle belegt nur noch 43 Prozent des ursprünglichen Platzes. Daraus ergeben sich weniger Schreiboperationen
bei den Daten und beim Redo-LOG. Auf der anderen Seite sind
die CPU-Belastung und der PGA-Speicherverbrauch deutlich angestiegen.
25
Datenbanken
Wie sieht das nun beim Zugriff auf die Daten aus? Diese Frage ist
quantitativ noch schwieriger zu beantworten, da sie entscheidend
durch die jeweilige Abfrage beeinflusst wird. Bei einem FULL TABLE SCAN spielt das geringere Datenvolumen eine entscheidende Rolle. Bei wiederholten Zugriffen auf die Daten einer komprimierten Tabelle wird es die Tatsache sein, dass mehr Datensätze
im Puffer gehalten werden können. Es ist auf jeden Fall mit einer
höheren CPU-Belastung zu rechnen, da die Daten für die Verwendung entkomprimiert werden müssen.
Typ
CPU
used
pga
memory
Physical
writes
redo
size
NOCOMPRESS
101
1.123.272
1407
11.649.765
COMPRESS
360
4.203.464
604
4.995.936
Abb. 4: Ergebnisse für das Anlegen einer Tabelle mit NOCOMPRESS
bzw. COMPRESS.
Anzahl Zeilen
Anzahl Blöcke
Tabelle T_NO_COMP
Tabelle T_COMP
5897468
5897468
64094
13782
CREATE TABLE ...
38 Sekunden
117 Sekunden
1. SELECT Anzahl
(alle)
22 Sekunden
5 Sekunden
2. SELECT Anzahl
(alle)
9 Sekunden
3 Sekunden
1. SELECT Anzahl
(unterschiedliche)
47 Sekunden
35 Sekunden
2. SELECT Anzahl
(unterschiedliche)
40 Sekunden
33 Sekunden
Abb. 5: Beispiel für die Auswirkungen der Kompression auf die Größe,
das Erstellen und typische Abfragen.
Die Auswirkungen am Beispiel
Die möglichen Auswirkungen der Kompression lassen sich am Besten an einem praktischen Beispiel aus einem aktuellen Projekt
verdeutlichen. In Abbildung 5 sind dazu Informationen zu einer Tabelle dargestellt, die sich
gut für eine Kompression eignet.
Die komprimierte Tabelle belegt nur noch ca.
22 Prozent des ursprünglichen Platzes. Für typische Abfragen sind dann Ausführungszeiten
angegeben und zwar
1. für den Fall, dass die Daten vollständig
von der Platte geladen werden müssen
und
2. für den Fall, dass sich die Daten schon
im Puffer befinden. In diesem Fall sind die
beiden Ziele „Platzersparnis“ und „Performance-Gewinn“ erfüllt.
Kann ich Datenkompression einsetzen?
Jetzt kommen wir zu der entscheidenden Frage: Wann eignet sich eine Tabelle für den Einsatz der Datenkompression?
Absolut nicht geeignet sind Tabellen, wenn die
Daten mit Einzeloperationen eingefügt und/
oder durch UPDATEs verändert werden. Dann
bewirkt die Kompression im günstigsten Fall
nichts. Bei regelmäßigen UPDATEs wirkt sie
sich sogar negativ auf Platzbedarf und Performance aus.
Sehr gut geeignet sind Tabellen, die folgende
Bedingungen erfüllen:
• Die Tabelle enthält redundante Informatio­
nen.
• Die Daten werden mit Blockoperationen
Glossar
Block
PCTFREE
IOT
DBA_OBJECTS
PGA-Speicher
eingefügt.
Physikalische Speichereinheit von Oracle
Datenbanken.
Freier Bereich im Block für spätere Änderungen.
• Die Daten werden einmal geschrieben und
Index Organized Tables; Tabellen, die in der Regel nur noch aus einem Index bestehen.
Oracle-interne Tabelle mit Data Dictionary Einträgen.
Prozessspeicher für Sortierungen.
Fazit
Links
► [1] Sanjay Mishra: „Compressing Data for Space and Speed“,
Oracle Magazine March/April 2004, www.oracle.com/technology/oramag/oracle/04-mar/o24tech_data.html
danach nur gelesen.
Die Datenkompression ist keine Allzweckwaffe. Sie führt jedoch, wie das Beispiel aus der
Praxis gezeigt hat, in Einzelfällen zu enormer
Platzersparnis und bringt auch einen Performancegewinn. Vor der Anwendung der Kompression für eine Tabelle ist jedoch eine genaue Analyse der Auswirkungen auf das Einfügen der Daten und die Ausführungszeiten
von typischen Abfragen notwendig.
► [2] Meikel Poess, Hermann Baer: „Decision Speed: Table Compression In Action“, www.oracle.com/technology/oramag/webcolumns/2003/techarticles/poess_tablecomp.html
Dr. Klaus Uebelgünn ([email protected]).
26
ORDIX News 3/2006
Aktuell
Larry Ratlos:
Zugriffsrechte unter
Unix
Frisch aus den Sommerferien zurück, geht Larry frohen Mutes wieder an
seine Arbeit. Doch lange bleibt er nicht so entspannt, wie er es von seinem
Urlaub auf Mallorca war.
Larry hat für einen Kollegen aus dem Marketing das Webserver-Verzeichnis /usr/local/cgi-bin freigegeben, so dass dort nun
jeder Kollege seine eigenen Daten ablegen
und verwalten kann.
Daher erlaubt Larry nun auch der entsprechenden Benutzergruppe Vollzugriff auf das Verzeichnis.
Zunächst ist alles in Ordnung und die Mitarbeiter sind auch soweit zufrieden. Doch bereits nach einigen Stunden klingelt das Telefon heiß.
Es ist der Kollege Peter Paranoia. „Larry, ich
bin schockiert!!!“, brüllt er in die Leitung. „Meine Daten, die ich heute morgen mit Mühe und
Sorgfalt auf den Webserver geladen habe,
sind plötzlich verschwunden. Ein Skandal!“
Larry versucht Kollege Paranoia zu beruhigen
und verspricht ihm, sich sofort um die Lösung
des Problems zu kümmern.
Zunächst sieht er in die Logdateien, um Aufschlüsse über den Datenverlust zu erhalten.
Lösung der Aufgabe 2/2006
Das Rätsel, was Larry in der letzten Ausgabe zu lösen hatte, war
die Suche nach einem Paket, mit
dem man Daten zu einem System
sammeln kann, um diese später
auszuwerten.
Leider hat Larry aus der ORDIX
News Leserschaft dieses Mal keinen Lösungshinweis erhalten. Wahrscheinlich waren die Leser
auch alle im Sommerurlaub. Daher hat er kurzerhand einen ORDIX Kollegen gefragt, der ihm freudestrahlend die Lösung präsentierte:
Gesucht war das Paket sysstat. Es stellt u. a. die Werkzeuge
sadc und sar zur Verfügung. Diese ermöglichen es, verschiedene
Messwerte, wie z. B. CPU-Last oder I/O-Werte, zu erfassen und
in einen Report zu überführen. Des Weiteren installiert es unter
/usr/lib/sa einige Skripte, die eine Überwachung beziehungsweise Auswertung des Systems durchführen.
Die Aktivierung des Monitorings kann durch das Kommando
rcsysstat start
oder aber durch Verlinkung von
/etc/init.d/sysstat
Die Logdateien zeigen, dass die von Peter Paranoia eingegebenen Daten von Lutz Löscher
versehentlich gelöscht wurden. Daraus schließt
Larry, dass es sich hier um ein Benutzerrechteproblem handelt.
in den Defaultrunlevel erfolgen. Beides erzeugt einen systemweiten Crontab-Eintrag unter /etc/cron.d/sysstat.
Larry steht vor einem Rätsel
Dieser bewirkt alle zehn Minuten indirekt über das Skript sa1 einen Aufruf von sar. Da die Standardeinstellung von sa1 lediglich
eine Momentaufnahme der Systemlast erstellt, empfiehlt sich die
Erweiterung des o. g. Crontab-Eintrags um die Messdauer und
Häufigkeit, z. B. 10-mal für jeweils 60 Sekunden.
Wie kann er es nun erreichen, dass der Vollzugriff weiterhin für alle Kollegen möglich bleibt,
aber dass sich die Mitarbeiter nicht gegenseitig die Dateien löschen können?
#activity reports every 10 minutes everyday
-*/10 * * * * root /usr/lib/sa/sa1
-*/10 * * * * root
Können Sie Larry helfen? Dann senden Sie
Ihren Lösungsvorschlag bis zum 27.10.2006
an [email protected]. Die drei pfiffigsten Lösungsvorschläge werden wir in der nächsten
Ausgabe veröffentlichen.
ORDIX News 3/2006
/usr/lib/sa/sa1 60 10
Die Messergebnisse werden binär unter /var/log/sa abgelegt.
Mit dem Skript /usr/lib/sa/sa2 (oder direkt mit dem Kommando sar) können die Daten für ein Reporting weiter verarbeitet werden.
27
Datenbanken - Titelthema
Reihe Oracle Objekttypen von A - Z (Teil I):
Oracle Objekttypen –
Von Cluster bis XML
Wer eine Oracle Datenbank in der aktuellen Version installiert, findet in der View dba_objects schnell vierzig
und mehr unterschiedliche Objekttypen. Für den Datenbankadministrator ist es unabdingbar, einen Überblick über diese unterschiedlichen Typen zu haben, um bei Ex- und Imports, im Fehlerfall oder bei Analysen
richtig reagieren zu können.
Dieser Artikel wendet sich an Datenbankadministratoren und
-entwickler, die einen Überblick über die Objekttypen von Ora­
cle bekommen möchten.
• CLUSTER
• CONSUMERGROUP
• CONTEXT
Cluster
Ziel der Artikelreihe
Diese Reihe erklärt anhand kleiner Beispiele die Verwendung und
Funktion der von Oracle zur Verfügung gestellten Objekttypen.
Ziel ist es, einen schnellen Überblick über den jeweiligen Typ zu
bekommen. Eine tiefgehende Ausarbeitung diverser Objekttypen
bleibt anderen ORDIX News Artikeln vorbehalten. Die unterschiedlichen Typen und deren Anzahl in einer Datenbank lassen sich wie
folgt ermitteln:
SELECT
FROM
GROUP BY
ORDER BY
object_type, count(*) AS anzahl
dba_objects
object_type
object_type;
Auf Los geht’s los
Im ersten Teil dieser Reihe besprechen wir die Objekttypen, die mit
dem Buchstaben „C“ beginnen:
CREATE CLUSTER geldautomat_clu
( automat_id NUMBER(6)
)
SIZE 512;
CREATE TABLE geldautomat
( automat_id NUMBER(6),
standort
VARCHAR2(64)
)
CLUSTER geldautomat_clu( automat_id );
CREATE TABLE geldautomat_inhalt
( automat_id
NUMBER(6),
fach_id
NUMBER(2),
fach_inhalt NUMBER(6),
fach_anzahl NUMBER(4)
)
CLUSTER geldautomat_clu( automat_id );
CREATE INDEX geldautomat_idx
ON CLUSTER geldautomat_clu;
Abb. 1: Befehlssequenz für zwei Tabellen zum Anlegen eines Clusters.
28
Ein Cluster ist ein Objekt, welches die Daten
von einer oder mehreren Tabellen in einem
Segment speichert.
Alle Tabellen eines Clusters müssen eine oder
mehrere gemeinsame Spalten enthalten, diese
gemeinsamen Spalten heißen Cluster-Schlüssel. Auf dem Cluster-Schlüssel muss zwin­gend
ein Index angelegt werden. Dieser Index heißt
Cluster-Index und ist vom Objekttyp Index. Der
Cluster sorgt dafür, dass Daten aller Tabellen
mit gleichem Cluster-Schlüssel in denselben
phy­sikalischen Blöcken liegen.
Ein Cluster ist besonders dann interessant,
wenn die Tabellen im Cluster häufig verknüpft
(JOIN) und über den Cluster-Schlüssel angesprochen werden. Technisch gesehen findet
also eine Optimierung des Join auf physikalischer Ebene statt, ohne das logische Datenmodell zu ändern.
Besonders vorteilhaft ist es, wenn die Größe
aller Zeilen zu einem Cluster-Schlüssel bekannt ist, dann kann beim Erstellen des Clusters der entsprechende Speicherplatz reserviert
werden. Dies geschieht mit dem Schlüsselwort
SIZE. Aus Sicht der Anwendung ist der Cluster
also dann interessant, wenn bei der 1:n-Bezie­
hung die Zahl n eine Konstante ist. Im folgen­den
Beispiel gehören z. B. zu jedem Geldauto­maten
eine feste Anzahl an Fächern für Geld­scheine.
Beim Anlegen der Cluster-Tabellen wird nun
die Zuordnung zum Cluster und der ClusterSchlüssel der jeweiligen Tabelle angegeben.
Die Tabellen sind – ähnlich wie bei einer Index Organized Table – keine Segmente mehr,
der Speicherplatz ist dem Cluster zugeordnet.
In Abbildung 1 sind die SQL-Kommandos zu
finden mit denen ein Cluster angelegt wird. Da-
ORDIX News 3/2006
Datenbanken
mit können alle Tabellen vollkommen transparent verwendet werden. Die Abbildung 2 zeigt
die Tabellen GELDAUTOMAT und AUTOMAT_
INHALT, welche zu einem Cluster zusammengeführt werden.
Wie bereits erwähnt, spielt der Cluster ins­be­­
sondere bei ganz bestimmten Performance-Anforderungen seine Stärke aus. Dafür ist die Verwaltung im Detail oft schwieriger. So kommen
Cluster-Tabellen beispielsweise beim Löschen
nicht in den Recycle Bin. Auch die Komprimierung lässt sich auf Cluster-Tabellen nicht anwenden. Lesen Sie dazu auch den Artikel zum
Titelthema „Datenkompression unter Oracle“
auf Seite 24 in dieser Ausgabe.
Eine sehr spezielle Form des Clusters ist der
Sorted Hash Cluster, dessen Zugriff noch schnel­
ler ist, da dessen interne Struktur sortiert ist.
Cluster finden sich in der Praxis ausgesprochen selten. Lediglich im Data Dictionary ist
ein halbes Dutzend von ihnen vorhanden.
GELDAUTOMAT
1 Kaiserstr.
2 Hauptbahnhof
3 Königsallee
....
1 Kaiserstr.
1 1 200,1 2 50,1 3 10,-
50
73
85
2 Hauptbahnhof
2 1 200,2 2 50,2 3 10,-
GELDAUTOMAT
3 Königsallee
AUTOMAT_INHALT
1 1 200,1 2 50,1 3 10,2 1 200,2 2 50,....
30
13
55
...
...
...
50
73
85
12
88
4 ...
Oracle Blöcke
...
GELDAUTOMA_CLU
AUTOMAT_INHALT
Abb. 2: Darstellung eines Clusters mit zwei Tabellen.
Consumer Group
Eine Consumer Group wird im Zusammenhang
mit Ressourcenplänen erstellt. Die Gruppe besteht aus einem Namen, einem Kommen­tar
und einem Algorithmus zur CPU-Zuteilung. Der
Gruppe können Sessions zugeordnet werden
und die Gruppe selbst wird einem Ressourcenplan zugeordnet. Zur Erstellung und Verwaltung dient das Paket dbms_resource_manager. Etwas detaillierter wird dieser Objekttyp zusammen mit dem Objekttyp RESOURCE PLAN besprochen.
Context
Wer kennt sie nicht, die SYS_CONTEXT Funktion, die als Nachfolger der Funktion USERENV
zahlreiche Informationen über die Session zurückgibt.
Der erste Parameter der Funktion stellt dabei
einen so genannten CONTEXT dar, der zweite Parameter ein Attribut dieses CONTEXT.
So gibt z. B. sys_context( 'userenv',
'service_name' ) den Service zurück, über
den die Session mit der Datenbank verbunden
ist. Was allerdings nicht so viele Administratoren wissen, ist, dass ein CONTEXT auch mit
Hilfe von SQL und PL/SQL angelegt werden
kann. Dies geschieht im ersten Schritt durch
Anlegen des CONTEXT.
Hinweis
In der Oracle Dokumentation gibt es keine Auflistung aller Objekttypen. Die Informationen zu den diversen Ojekttypen müssen an verschiedenen Stellen nachgelesen werden.
Der Oracle Database Administrator‘s Guide gibt im Part IV „Schema
Objects“, Kapitel 13 „Managing Schema Objects“ eine Einführung in
die wichtigsten Objekte.
Im Database Reference Guide werden die verschiedenen Data Dictionary Views erläutert. Dabei gibt dba_objects einen Überblick und
meist findet sich auch eine View dba_<object_type>.
Für spezielle Objekttypen ist meist eine gesonderte Dokumentation
zu verwenden. So findet sich im Application Developer‘s Guide eine
gute Einführung in Large Objects und im Data Warehousing Guide
eine Einführung in Dimensions und Materialized Views.
DBMS_SESSION.SET_CONTEXT initialisieren. Die Prozeduren
müssen dabei durch die Applikation aufgerufen werden. Über die
Funktion SYS_CONTEXT ('mycontext', 'param1') kann
dann der aktuelle Wert ermittelt werden.
Ein CONTEXT wird häufig verwendet, um Fine Grained Access
Control zu implementieren. Ein interessantes Sicherheitsmerkmal im Zusammenhang mit der so genannten Virtual Private Database.
CREATE CONTEXT mycontext USING mypackage;
In der nächsten Ausgabe geht es weiter mit „D“ wie Database
Link.
Das Paket mypackage enthält nur eine oder
meh­rere Prozeduren, welche die Parameter
des neuen CONTEXT mit Hilfe des Befehles
Martin Hoermann ([email protected]).
ORDIX News 3/2006
29
Java/XML - Titelthema
Lucene unter Last beim
Deutschen Rundfunkarchiv
Für Recherchen von Medien aus Rundfunk und Fernsehen verwendet das Deutsche Rundfunkarchiv Lucene als Suchmaschine. Wir zeigen die Möglichkeiten der Integration und Grenzen der Leistungsfähigkeit
der Suchmaschine Lucene auf.
Dieser Artikel richtet sich an Entwickler und Software-Architekten, die sich für das Thema Lucene interessieren.
Das Internet zeigt, wie es geht: Suchbegriff eingeben und Suche
starten. Wieso sollte also der Anwender von Individualsoftware aufwändige Eingabemasken ausfüllen? Tut es nicht auch eine Eingabezeile für den Suchbegriff? Braucht der Java-Entwickler eine
Suchmaschine, so nimmt er einfach Lucene.
Braucht die Anwendung eine Suchmaschine?
Suchmaschinen werden im Internet verwendet, um Dokumente, die
bestimmte Suchbegriffe enthalten, aufzufinden. Aber auch bei datenbankbasierten Anwendungen kann der Wunsch nach einer Suchmaschine aufkommen. Überall dort, wo nicht nur atomare Informationen
wie etwa Name, Geburtsjahr oder Personalnummer abgespeichert
werden, ist möglicherweise eine Suchmaschine von Nutzen.
In dieser Situation ist auch das Deutsche Rundfunkarchiv, das
Me­dien aus Rundfunk und Fernsehen archiviert. Ein wesentlicher
Schlüs­sel zu diesen Medien stellt der beschreibende Text dar. Über
diesen lassen sich Medien in Zusammenhang mit Personen, Orten oder Themen finden.
So ist der Einsatz einer Suchmaschine für die Anwendungen des
Deutschen Rundfunkarchivs kein Neuland: Seit Jahren wird diese
Aufgabe mit Hilfe einer Großrechneranwendung erledigt.
In Zusammenhang mit der bevorstehenden Ab­lösung des Großrechners wurde für eine Anwendung Lucene als Suchmaschine ein-
gesetzt. Das Projekt wurde beim Hessischen
Rund­funk unter Beteiligung der ORDIX AG
durchgeführt.
Technische Details der Anwendungs­
architektur
Die Archivanwendung zur Recherche von Bildmaterial ist als reine Web-Anwendung realisiert worden. Die eingesetzten Komponenten
sind der Abbildung 1 zu entnehmen.
Tomcat wird als Web-Container verwendet. Das
Struts-Framework unterstützt die Ver­arbeitung
eingehender HTTP-Requests und die Erzeugung der Response. In dieses Framework sind
die Controller- und Anzeigelogik eingebettet.
Suchanfragen werden in erster Linie an die Lu­
cene-Komponente weitergeleitet. Diese greift
auf ein Verzeichnis mit Index-Dateien zu, das
in der Abbildung als Lucene-Index dargestellt
ist.
Dabei wurden neben Volltextsuchen auch so
ge­nannte Filter implementiert: Das Suchergebnis wird aufgrund von Feldinhalten einge­
schränkt.
Das Ergebnis der Suche sind einerseits Schlüs­
sel für die gesuchten Medien. Darüber hinaus
sind im Lucene-Index andererseits aber auch
Daten zu den Medien abgelegt, die bei der
Über­­sicht der Suchergebnisse dargestellt wer­
den.
Media-Server
Datenbank
Tomcat
: Hibernate
: HttpClient
: Inverter
: Lucene
Lucene-Index
Abb. 1: Architektur der Archivanwendung.
30
: Struts
Detailinformationen zu einzelnen Medien werden aus der Datenbank ermittelt. Als Persistenz­
schicht kommt Hibernate zum Einsatz. Ein Web­
Server liefert die Mediendaten. Der Zu­griff wird
über die Anwendung autorisiert und erfolgt über
die Komponente HttpClient des Jakarta Commons-Projektes.
Eine eigenständige Anwendung, die als Komponente „Inverter“ in der Abbildung 1 auftaucht,
sorgt für die Aktualität des Lucene-Index. In
festgelegten Intervallen wird diese Anwendung
gestartet. Sie aktualisiert den Lucene-Index
anhand der protokollierten Veränderungen in
der Datenbank.
ORDIX News 3/2006
Java/XML
: JCAClient
1: ConnectionSpecLucene()
2: getConnection()
: ConnectionSpecLucene
3.1: ConnectionRequestInfoLucene()
: ConnectionFactoryLucene
: ConnectionRequestInfoLucene
3.2: allocateConnection()
: ConnectionManagerLucene
3.2.1a: matchManagedConnection()
Kontrolle über
• Ressourcen-Verbrauch
• Timeout
3.2.1b: createManagedConnection()
: ManagedConnectionFactoryLucene
3.2.1a.1: isConnectionRequestForMe()
3.2.1b.1: AbstractManagedConnectionLucene()
: AbstractManagedConnectionLucene
3.2.1b.2.1: ConnectionLuceneQuery()
: ConnectionLuceneQuery
Abb. 2: Kollaborationsdiagramm für den Zugriff auf eine Lucene Connection.
Erste Erfahrungen
JCA: Gute Connections zu Managern mit Factories
In der vorgestellten Archivanwendung erweist
sich Lucene als zuverlässig. Sowohl parallel
durchgeführte Suchen als auch die gleichzeitig
ablaufende Indexierung sind unproblematisch.
Die Performance ist zufriedenstellend.
Zur Kapselung des Suchdienstes wird das von Sun vorgeschlagene Architekturmodell JEE Connector Architecture eingesetzt. Diese
Architektur wird von Sun empfohlen, um Dienste an einen Application Server anzubinden. Auch wenn diese Architektur nicht gerade
als übersichtlich zu bezeichnen ist, gibt es doch einige überzeugende Gründe. Zunächst handelt es sich um einen Standard:
Die Erfahrungen während der Entwicklung zeig­
ten aber auch, dass Lucene in einem instabilen Umfeld problematisch sein kann:
Kommt es zu Ausnahmesituationen, so muss
be­rücksichtigt werden, dass Lucene File Hand­
ler Betriebssystem-Ressourcen beanspruchen.
Werden diese nicht freigegeben, so führt dieser Mangel zu einem zeitweiligen Stillstand der
Anwendung.
Dabei ist es nicht ausreichend, dass in Zusammenhang mit der Garbage Collection die Ressourcen automatisch wieder freigegeben werden. Eine Garbage Collection findet nämlich
nur dann statt, wenn die Ressource „verfügbarer Hauptspeicher“ (Heap) knapp wird.
Dann kann es aber bereits zu spät sein und die
Ressource File-Handler ist aufgebraucht. Die
ge­samte Anwendung kommt zum Stillstand. Da­­
mit ist trotz aller Hilfestellung durch Java der
Entwickler gefordert. Sorgfältig muss dieser
mit den Ressourcen umgehen.
Um die weitere Entwicklung zu unterstützen, ist
das nächste Ziel, die Suche mit Lucene so zu kapseln, dass eine zentrale Kontrolle über den Ressourcen-Verbrauch durchgeführt werden kann.
ORDIX News 3/2006
Es ist davon auszugehen, dass diese Architektur mehrfach erprobt
wurde. Eine Dokumentation für die Implementierung und Verwendung ist dadurch verfügbar. Aber auch die Perspektive, die Suchfunktionalität zukünftig durch einen JEE Application Server zur Verfügung zu stellen, spricht für diesen Ansatz.
Für die Implementierung werden die Schnittstellen, die zu diesem
Architekturmodell gehören, in Form des Pakets connector.jar heruntergeladen. Abbildung 2 zeigt in einem Kollaborationsdiagramm
die wesentlichen Klassen im Einsatz.
Auf den ersten Blick wimmelt es nur so von Managern und Factories. Alle haben jedoch – genau wie in einer gut organisierten Behörde – ihre abgesteckten Verantwortlichkeiten. Da ist die Schnittstelle zum JCA-Client, die ConnectionFactory. Nur über sie kommt
ein Client an die begehrte Connection heran.
Die ConnectionFactory nimmt nur Anträge für die Ausgabe einer
Connection über ein Antragsformular, die ConnectionSpec, entgegen. Hier trägt der Antragsteller sein Begehren ein und spezifiziert damit den Suchdienst.
Beauftragt wird dann der ConnectionManager, eine Connection
zu organsieren. Dieser nimmt aber nur Formulare vom Typ ConnectionRequestInfo an. Diese werden „freundlicherweise“ von der
ConnectionFactory erstellt. Der ConnectionManager prüft, ob er
eine Connection aus einem Pool herausgeben kann oder ob eine
neue Connection zu erstellen ist.
31
Java/XML
wird diese Aufgabe von einer Connection­Fac­
tory erledigt, die eine ManagedConnection er­
stellt.
1.1: getRecordFactory()
: ConnectionFactoryLucene
: RecordFactory
1: getRecordFactory()
: Interaction
2: createMappedRecord()
: JCAClient
: InputRecord
5: execute()
3: put()
5.1: IndexedRecord()
: IndexedRecord
4: createInteraction()
Bei der ausgeführten Implementierung werden
Connections nur einmalig verwendet. D. h.,
dass sie nach ihrer Erzeugung, Verwendung
und Freigabe unmittelbar zerstört werden.
: Connection
6: get()
Der ConnectionManager wird intern informiert,
wenn eine Connection freigegeben oder ungültig wird. Dazu ist der ConnectionManager direkt
als ConnectionEventListener imple­mentiert.
Abb. 3: Kollaborationsdiagramm für die Suche.
Das Erstellen einer neuen Connection ist mit
geringem Aufwand möglich und eine neue
Connection hat unmittelbar auch Zugriff auf die
aktuellsten Daten. Der Gebrauch einer Connec­
tion ist der Abbildung 3 zu entnehmen.
600
500
Zeit (ms)
400
1
2
2
1
2
300
200
Suchbegriff
Suchbegriffe
Suchbegriffe mit AND
Suchbegriff Fuzzy
Suchbegriffe, proximity
100
0
1
10
100
1000
10000
100000
Treffer
Abb. 4: Antwortzeiten der Suche bei unterschiedlichen Suchanfragen.
25000
20000
Antwortzeit [ms]
Zur Ausführung einer Suche fordert ein JCAClient eine Interaction von der Connection an.
Über die Methode execute wird die Suche
ausgeführt. Durch eine Interaction­Spec und
durch Records werden die Parameter zur Spezifikation der Art der Suche angegeben.
Die InteractionSpec definiert dabei die auszuführende Funktion, die übergebenen Records
enthalten die erforderlichen Argumente. Das
Ergebnis der Suche sind Records, im konkreten Fall als List implementiert.
Nichts als Suchen
15000
Mittelwert
Maximalwert
10000
5000
Durch die Kapselung des Suchdienstes ist es
nun möglich, die Suche allein hinsichtlich ihres
Lastverhaltens zu untersuchen. Selbstverständlich hängen die konkreten Ergebnisse eines solchen Lasttests wesentlich von der eingesetzten
Hardware und dem Betriebssys­tem ab.
0
0
10
20
30
40
50
60
Anzahl Benutzer
Abb. 5: Antwortzeiten der Suche bei parallelen Suchanfragen.
Der ConnectionManager ist Herr über die Ressourcen. Einerseits
wird die Anzahl der herausgegebenen Connections von ihm beschränkt. Andererseits wird ihm die wichtige Aufgabe zugeteilt, zu
prüfen, ob herausgegebene Connections vom Benutzer vergessen wurden. Diese werden aktiv beseitigt. Der ConnectionManager
kann damit eventuell auftretende Ressourcen-Lecks stopfen.
Ein ConnectionManager wird oftmals mit dem Application Server
mitgeliefert. Er kann aber auch ohne großen Aufwand selbst implementiert und dann auch auf einem Application Server eingesetzt werden.
Faktisch hält der ConnectionManager eine Liste von Connections
in einem Pool vor. Muss eine neue Connection erstellt werden, so
32
Darüber hinaus wird die eingesetzte Java Virtual Machine die Ausführungsgeschwindigkeit
beeinflussen.
Die Lasttests werden auf einem Entwicklungs­
rechner unter dem Betriebssystem Micro­soft
Windows XP durchgeführt.
Ziel des hier durchgeführten Lasttests ist in erster Linie, die Einflussgrößen zu ermitteln, die
bei der Auslegung der Suchmaschine berücksichtigt werden müssen:
• Hat die Anzahl der Treffer einen Einfluss?
• Spielt die Komplexität der Suchanfrage ei­
ne Rolle?
• Wie wirken sich parallel ausgeführte Such­
anfragen aus?
• Welchen Einfluss hat die Größe des Index?
ORDIX News 3/2006
Java/XML
Zielgröße ist die Antwortzeit. Wie lange muss
ein Benutzer auf die Suchergebnisse warten?
200
einfache
Suche
In einem ersten Versuch werden die Parameter
„Anzahl der Treffer“ und „Komplexität der Suchanfrage“ untersucht. Dazu werden Suchanfragen gestellt, die zu einer unterschiedlichen Ergebnismenge führen (siehe Abbildung 4).
Antwortzeit [ms]
180
160
140
120
100
80
60
40
20
Die Versuchsreihen unterscheiden sich in diesem Fall nur durch die Suchanfragen. In der
ersten Reihe wird nach einem ein­zelnen Suchbegriff gefragt. Durch die Variation des Suchbegriffs werden unterschiedlich viele Treffer
gefunden. In diesem Fall 10, 1000 und 10000.
Auch wenn sich die Trefferzahlen um Größenordnungen unterscheiden, hat dieses keinen
Einfluss auf die Antwortzeit. Diese schwankt
zwischen 0,15 und 0,25 Sekunden.
Die Anzahl der Treffer stellt damit keinen Parameter dar, der die Antwortzeit beeinflusst.
Auch die Komplexität der Anfrage spielt in der
Regel keine Rolle.
Untersucht wurde dabei die Angabe von 2 Such­
begriffen, die logische Verknüpfung von Suchanfragen und die durch Lucene angebotene Pro­
xi­mity-Bedingung. Bei dieser Bedingung kann
angegeben werden, wie weit zwei Suchbegriffe voneinander entfernt vorkommen müssen.
Nur die Fuzzy-Suche erhöht die Antwortzeit sig­
nifikant. Bei dieser Suche wird nach dem Suchbegriff und nach ähnlichen Begriffen gesucht.
Dabei werden ähnliche Begriffe mit einem Fuzzy-Algorithmus gesucht. Diese Art der Suche
führt ungefähr zu einer Verdoppelung der Antwortzeiten.
Einen unbestreitbaren Einfluss auf die Antwort­
zeit hat die Anzahl der parallel durchgeführten
Suchen. Dadurch, dass bei der Implementierung des Suchdienstes für jede Suche neue
Ressourcen verwendet werden, ist nicht zu erwarten, dass parallele Suchen zu einer Verringerung der Antwortzeit führen.
Im günstigsten Fall kann mit einem linearen Ver­
lauf der Antwortzeit gerechnet werden: Dop­pelt
so viele parallele Suchanfragen führen zu einer doppelt so langen Antwortzeit für jede einzelne Suchanfrage. Die Antwortzeiten (siehe
Ab­bildung 5) kommen diesem Idealverhalten
sehr nahe.
In der Untersuchung wird die Anzahl der gleich­
zeitigen Suchanfragen von 1 bis 50 variiert. Auf­
getragen sind einerseits die Mittelwerte und
die zugehörige Standardabweichung. Zusätzlich sind die Maximalwerte angegeben.
ORDIX News 3/2006
0
5.000
10.000
15.000
20.000
25.000
30.000
35.000
Anzahl Dokumente
Abb. 6: Einfluss der Dokumentenanzahl.
Dem Diagramm ist zu entnehmen, dass die Ant­wortzeiten leicht überproportional ansteigen. Die Ursachen für diesen Anstieg lassen sich
möglicherweise durch den Verwaltungs­aufwand der Threads erklären. Auffällig ist das Verhalten bei 30 parallelen Such­anfragen. Hier
kommt es zu einem erheblichen Anstieg der Antwortzeiten. Dieser
Anstieg ist auf das Speichermanagement der Virtuellen Maschine
zurückzuführen.
Hier findet parallel zur Suche mit großer Sicher­heit eine Garbage
Collection statt. Für die weiteren Versuche musste der verfügbare
Hauptspeicher vergrößert werden. Als letzter Parameter wird die
Anzahl der zu durchsuchenden Dokumente von 30.000 auf 10.000
reduziert. Die Abbildung 6 zeigt, dass dieser Parameter einen erheblichen Einfluss auf die Antwortzeiten hat.
Die Abbildung verdeutlicht, dass sich ausgehend von einem linearen Verhalten pro Dokument die Antwortzeit um 0,002 Millisekunden verlängert. Dieser Wert wirkt zunächst einmal klein. Muss jedoch davon ausgegangen werden, dass die Anzahl der Dokumente
vielleicht die Millionengrenze überschreitet, so wird die Antwortzeit
für eine einzelne Abfrage bereits um die 2 Sekunden betragen!
Fazit
Die Lasttests bestätigen zunächst den ersten Eindruck, dass Lucene eine zuverlässige und robuste Suchmaschine ist. Die Kapselung von Lucene in eine Java-Connector-Architektur vereinfacht den
programmiertechnischen Umgang mit der Suchmaschine.
Die Ergebnisse zeigen, dass für den gegebenen Anwendungsfall
die Antwortzeiten ausreichend sind. Zur Einordnung der Ergebnisse ist zu berücksichtigen, dass 50 gleichzeitige Suchprozesse in
der Realität durch ungefähr 200 Benutzer (concurrent user) verursacht werden.
Dennoch dürfen die wesentlichen Parameter, die Einfluss auf die Antwortzeiten nehmen, nicht vernachlässigt werden: „Anzahl der parallelen Suchprozesse“ und „Anzahl der Dokumente“. Beide Parameter gehen linear in die Berechnung der Antwortzeiten ein.
Für Anwendungen mit einer großen Datenmen­ge (einige 100.000
Datensätze) oder mit einer sehr großen Zahl an Benutzern sind die
Grenzen durch die Geduld der Benutzer definiert. Um den Einsatzbereich von Lucene zu erweitern, sollten neben der Universalstrategie, leistungsfähigere Hardware einzusetzen, noch die folgenden
Strategien geprüft werden:
33
Java/XML
Links
►
►
►
►
►
►
►
[1] Hibernate: http://www.hibernate.org/
[2] JCA: http://developers.sun.com/sw/building/codesamples/integration_jca.html
[3] JCA: http://java.sun.com/j2ee/connector/
[4] HttpClient: http://jakarta.apache.org/commons/httpclient/
[5] Lucene: http://lucene.apache.org/
[6] Struts: http://struts.apache.org
[7] Tomcat: http://tomcat.apache.org/
Glossar
Concurrent Benutzer, die gleichzeitig mit einer Web-Anwendung
user
arbeiten.
DBMS
Datenbank Management System. Programme für den
Umgang mit Datenbanken (z. B. Oracle, Informix, DBS).
Garbage
Vorgang der Java Virtual Machine, bei dem nicht mehr
Collection benötigte Objekte zerstört werden, um ihren Speicherplatz erneut nutzen zu können.
Heap
Speicherbereich eines Programms, der vom Programm
selbst verwaltet werden kann.
JCA
Java Connector Architecture. Standardisiertes
Entwurfs­muster zur Einbindung von Informationssystemen in eine JEE-Umgebung.
JEE
Java Enterprise Edition. Erweiterung von Java für
Server-Anwendungen.
Thread
Teilprozess eines Programms. Mehrere Teilprozesse
können parallel ausgeführt werden.
Durch eine Verteilung der Last auf mehrere WebContainer, die jeweils ihren eigenen Index haben, skaliert die Antwortzeit mit der Anzahl der
Web-Container-Instanzen.
Bei Unix/Linux-Servern steht die Möglichkeit
zur Verfügung, den Index auf ein RAM-basiertes Dateisystem zu legen. Damit kann die Ausführungszeit erheblich beschleunigt werden.
Der Lucene-Index kann auch in einer Datenbank abgelegt werden. Hierdurch ist ein Vorteil durch Caching-Mechanismen des DBMS
zu erwarten.
Braucht auch Ihre Anwendung eine Volltextfunktionalität? ORDIX berät Sie gern.
Dr. Stefan Koch ([email protected]).
Impressum
Herausgeber:
ORDIX AG
Aktiengesellschaft für Software­ent­wick­lung,
Beratung, Schulung und Systemintegration,
Paderborn
Redaktion: Helma Jenniches, Sascia Brinkmann
V.i.S.d.P.: Wolfgang Kögler
Anschrift der Redaktion:
ORDIX AG
Westernmauer 12 - 16
33098 Paderborn
Tel.: 05251 1063-0
Fax: 0180 1673490
Gestaltung/Layout: Sascia Brinkmann, Stefanie Heither
Auflage: 8.600
Druck: Druckerei Reike GmbH, Paderborn
Autoren dieser Ausgabe:
Holger Bartnick, Christian Fertsch, Klaus Günther, Stefanie Heither,
Michael Heß, Martin Hoermann, Helma Jenniches, Dr. Stefan Koch,
Wolfgang Kögler, Roger Niemeyer, Markus Schreier, Thorsten Schuhmacher, Jens Stahl, Dr. Klaus Uebelgünn
34
Copyright:
ORDIX AG. Alle Rechte
vorbehalten. Eine Haftung für die Richtigkeit
der Veröffentlichungen
kann trotz sorgfältiger
Prüfung durch die Redaktion vom Herausgeber nicht übernommen
werden.
Die Zeitschrift ORDIX News wird von der ORDIX AG an ausgesuchte Kunden verteilt und
kann für 2,20 Euro bestellt werden. Sie finden
sowohl die neueste Ausgabe als auch ältere
Ausgaben im Archiv der ORDIX News im Internet unter: http://www.ordix.de.
Schauen Sie mal rein!
Der Kontakt zu unseren Lesern ist uns sehr
wichtig. Für An­regungen, Kritik und Anmerkungen zu den Themen, aber auch für interessante Ideen sind wir immer offen und dankbar.
Sie erreichen die Redaktion auch per E-Mail
unter [email protected].
Wir freuen uns auf Ihr Feedback.
ORDIX News 3/2006
Datenbanken
Auditing für die Datenbank
Die Sicherheit der Datenbank soll durch die Nutzung von AUDITING-Optionen erhöht werden. Der Artikel zeigt
einen Überblick über die bisher zur Verfügung stehenden Auditing-Möglichkeiten. Darüber hinaus werden
auch die Neuigkeiten des Oracle 10g Release 2 in diesem Umfeld diskutiert.
Häufig ist es nicht nur wichtig zu wissen, wie
eine Zugriffskontrolle auf firmensensitive Daten zu gestalten ist, sondern auch, wie eine sinn­
volle Protokollierung von Zugriffen und Aktio­
nen innerhalb der Datenbank erfolgt. Hierbei
hilft das Auditing. Das klassische Auditing unterscheidet vier Formen:
• Mandatory Auditing
• SYS Auditing (Das sind alle Aktionen, die
vom User SYS durchgeführt werden.)
• Standard Auditing
• Fine Grained Auditing (FGA)
Auf die beiden letztgenannten Formen, das
Standard Auditing und das FineGrained Auditing (FGA), kann man einen besonderen, programmiertechnischen Einfluss nehmen.
Mandatory Auditing
Das Mandatory Auditing wird vom System au­
tomatisch ausgeführt. Es kann nicht vom Ad­­mi­
nistrator unterdrückt werden. Unter Unix werden
die Informationen per Default in das Verzeich­nis $ORACLE_HOME/rdbms/audit geschrieben. Microsoft zeigt diese Information in seiner
Ereignis-Anzeige an. Dabei werden sämtliche
Startup- und Shutdown Aktionen bei Benutzern
mit SYSDBA- oder SYSOPER-Privilegien mit­
pro­tokolliert.
Unter Unix kann ein anderes Verzeichnis als
Aufbewahrungsort dieser Informationen genutzt werden, sobald der Datenbankparameter AUDIT_FILE_DEST verändert wird. Ebenso kann nun durch das Setzen von AUDIT_
TRAIL=XML die Ausgabe als XML-Datei in das
Betriebssystem erfolgen. Mit der neuen View
V$XML_AUDIT_TRAIL können die DBAs diese Informationen mit einer Abfrage lesen.
SYS Auditing
Bei dieser Form des Auditing werden alle Aktionen des Users SYS und der Benutzer mit
SYSDBA- und/oder SYSOPER-Privilegien mitprotokolliert. Die Aktivierung erfolgt durch das
Setzen des statischen init.ora Parameters
AUDIT_SYS_OPERATIONS. Die Speicherung
erfolgt analog zu der beim Mandatory Auditing.
Für diese Form ist das Setzen des Parameters
AUDIT_TRAIL nicht erforderlich!
ORDIX News 3/2006
Der Artikel richtet sich an Datenbankadministratoren, die sich
besonders mit den Schutz beziehungsweise der Kontrolle des
Zugriffs auf firmensensitive Daten beschäftigen.
Bei diesen beiden Formen des Auditing besteht die Gefahr darin,
dass geeignete Vorkehrungen für die Vermeidung des Plattenüber­
laufs getroffen werden müssen.
Ebenfalls besteht die Möglichkeit, dass Benutzer mit entsprechen­
den DBA-Rechten auf Betriebssystemseite die gesammelten Informationen verändern oder löschen. Zur Behebung dieser Möglichkeit der Manipulation dient nun bei Unix-basierten Systemen die
Nutzung der SYSLOG() Funktionalität als neues Feature.
Das Besondere daran ist, dass diese Information beliebig (z. B.
auf einem Remote Server) in einer syslog.conf Datei abgelegt
werden kann, ohne dass die DBAs eine Zugriffsmöglichkeit besitzen. Der Informationsfluss erfolgt hier über die Zuweisung zu
einem Daemonprozess.
Standard Auditing
Das Einschalten des Standard Auditing erfolgt über den Parameter AUDIT_TRAIL.
Das Standard Auditing zielt dabei auf die Protokollierung von:
• Privilegien: Auditing von Systemprivilegien
• Schemaobjekte: SELECT, DML-Statement, GRANT, REVOKE auf
•
Tabellen, Views, Sequenzen, Standalone Stored Procedures
oder Functions und Packages
Statements: DDL- oder DML-Statements
Für das Standard Auditing mittels Statements, Privilegien und Schemaobjekten kann eine Klausel über erfolgreiches Ausführen (WHEN­
EVER SUCCESSFUL), nicht erfolgreiches Ausführen (WHENEVER
NOT SUCCESSFUL) oder für beide Auditing Zustände (both) gesetzt werden. Hinzu kommt beim Statement Auditing noch die Option, ob das gleiche Statement innerhalb einer Session nur einmal
(BY SESSION) oder jedesmal bei Ausführung in derselben Session (BY ACCESS) einen Audit-Eintrag erzeugen soll.
Es ist dabei zu beachten, dass das Auditing über die Privilegien
da­bei etwas detaillierter ist als ein Auditing über Schemaobjekte.
Zum Beispiel wird beim Statement Auditing mit der TABLE Klausel auf CREATE TABLE, DROP TABLE und ALTER TABLE Bezug
genommen. Beim Privileg Auditing (z. B. DROP TABLE) wird nur
auf eines von diesen drei Privilegien abgezielt.
Die Speicherung der hiermit generierten Informationen kann entweder im Betriebssystem stattfinden oder innerhalb der Datenbank.
35
Datenbanken
Das Standard Auditing arbeitet bei der Speicherung der Informationen innerhalb der Datenbank mit der Tabelle SYS.AUD$ und die
Abfrage der dort gespeicherten Informatio­nen wird mit der View
DBA_AUDIT_TRAIL durchgeführt.
Fine Grained Auditing (FGA)
Im Gegensatz dazu beruht das Fine Grained Auditing (FGA) auf
der Protokollierung von Transaktionen, die auf einer Tabelle oder
View ausgeführt werden und eine entsprechende Policy besitzen.
Die Informationen für ein Auditing mit FGA werden aus der Tabelle SYS.FGA_LOG$ mittels der Data Dictionary View DBA_FGA_
AUDIT_TRAIL gewonnen. Darüber hinaus kann ab Oracle 10g
Release 2 nun auch die View DBA_COMMON_AUDIT_TRAIL genutzt werden, die Informationen aus dem Standard Auditing und
aus dem FGA aufnimmt.
Das FGA kann im Gegensatz zum Standard Auditing ohne das Setzen der Oracle Datenbankparameter AUDIT_TRAIL und AUDIT_
SYS_OPERATIONS initialisiert werden: Es ist besonders beim FGA
zu beachten, dass es in früheren Releases nur dann funktionierte,
wenn der Optimizer auf cost-based und nicht auf rule-based
eingestellt war. Bei der rule-based Methode kann ein unnötiger
Audit Event Trigger ausgelöst werden und die Audit-Informationen
unnötig anwachsen lassen.
FGA und Trigger
Im Gegensatz zum Einsatz von Triggern ermöglicht das FGA, neben den DML- auch abgesetzte SELECT-Statements gegen die zugrunde liegende Tabelle oder View mitzuprotokollieren. Vorteile von FGAs gegenüber Triggern sind:
• Trigger lösen bei jedem DML-Statement
•
•
•
aus. Das FGA veranlasst nur ein einmaliges Audit bei einer Policy.
Durch die nur einmalige Auslösung kommt
es zu einem Performancevorteil!
Das FGA ist auch für SELECT-Statements
möglich; bei Triggern sind SELECT-Statements nicht möglich.
Trigger können keinen weiteren Insteadof-Trigger beobachten, der an demselben
Objekt feuert. Das FGA beobachtet alle
Policies einer Basistabelle.
FGA und Standard Auditing
Das FGA bietet folgende Vorteile gegenüber
dem Standard Auditing:
DBMS_FGA Package
• Es werden feiner granulierte Informatio­nen
Mit dem DBMS_FGA-Package können die FGA-Einträge sehr einfach verwaltet werden. Hierbei wird zuerst eine Audit Policy erstellt, mit der dann weiter gearbeitet werden kann. Diese Policy
sammelt Audit-Informationen. Die mit Oracle 10g Release 2 eingeführte Neuerung der spaltenbasierten Beschränkung bei Tabellen
und Views lässt das FGA für einzelne, sicherheitsrelevante Spalten zu. Hierdurch werden nun weniger Auditing-Informationen generiert als in den vorhergehenden Releases.
generiert.
• Ausschluss unnützer oder sogar falscher
Informationen.
• Das FGA ist jederzeit zu implementieren.
•
Es ist kein Ändern von Datenbankparametern wie z. B. AUDIT_TRAIL nötig.
Durch die innerhalb der Datenbank integrierte Funktionalität ist ein Umgehen des
Auditings unmöglich.
Auslösemechanismen
Für das Auslösen einer Policy reicht es aus, wenn die Audit-Bedingung auf NULL gesetzt wird bzw. ganz fehlt. Dadurch wird gewährleistet, dass auf jeden Fall ein Audit-Eintrag erzeugt wird, sobald die entsprechende Aktion (Statement-Typ) auf einer Spalte durchgeführt wird. Die Audit-Funktion wird immer als autonome
Transaktion ausgeführt, die damit keinerlei Einfluss auf das eigentliche Statement hat. Das bedeutet, dass auch die eigentliche
Policy immer einen Audit-Datensatz generiert. Auch das Protokollieren eines Merge-Kommandos ist damit möglich. Dazu müssen nur die entsprechenden Update und Insert Statements in einer Policy vorhanden sein. Für das Auditing wird dann hierbei nur
ein Satz gebildet.
Glossar
FGA
DML
Fine Grained Auditing. Fein granuliertes Auditing.
Data Manipulation Language. Über DML-Kommandos werden Daten (Zeilen) eingefügt, gelöscht oder geändert.
DDL
Data Defnition Language. Über DDL-Kommandos werden Datenstrukturen gepflegt (z. B. Tabellen anlegen oder löschen).
Policy Sicherheitsregel
Durch die feiner zu granulierende Informations­
generierung wird es dem DBA durch das FGA
erleichtert, auf Zugriffe von sensitiven Daten
entsprechend zu reagieren. Er kann sich zum
Beispiel sofort informieren lassen, wenn ein
Zugriff erfolgt. Des Weiteren werden Informationen nicht unnötig gesammelt, sondern es
kann ganz gezielt protokolliert werden, wie und
von wem die sensitiven Informationen innerhalb der Datenbank genutzt werden.
Fazit
Die dargestellten Möglichkeiten helfen, die Zugriffe und Aktionen auf eine Datenbank und
auf firmensensitive Daten gezielt zu protokollieren. Sie sind nicht zur Schaffung von „Datenfriedhöfen“ gedacht! Deshalb ist ein sehr
sorgsamer Umgang mit diesen Funktionalitäten notwendig. Denn eine übertriebene Datensammlung geht immer mit einem Performanceverlust einher.
Klaus Günther ([email protected]).
36
ORDIX News 3/2006
Java/XML
Gut gepuffert ist halb gewonnen – Reihe Hibernate (Teil III)
Caching in Hibernate
Im dritten Artikel unserer Reihe zum Hibernate-Framework widmen wir uns dem Thema Caching. Neben einem
theoretischen Einstieg liefert dieser Artikel auch praktische Tipps für den Gebrauch und die Anpassung des
Hibernate-Caches an die eigenen Bedürfnisse.
Warum puffern?
Das Puffern (engl.: Caching) von Daten ist in
der EDV ein „alter Hut“. Die Vorgehensweise
basiert darauf, dass häufig benötigte Daten
von einem langsamen Medium (z. B. Festplatte) in den Hauptspeicher kopiert werden.
Dieser Artikel richtet sich an Softwareentwickler und -architekten, die Hibernate in ihren Projekten einsetzen (wollen).
Gleichzeitig werden Zugriffe auf diese Daten
über eine Zwischenschicht geleitet. Diese prüft
zunächst immer den Puffer auf die angeforderten Daten.
Der 1st Level Cache ist kurzlebig und mehrfach vorhanden. Er wird
von der aktuellen Hibernate-Session selbst implementiert und ist
immer aktiv. Alle Objekte, die eine Session geladen hat, werden bis
zum Ende der Session auch von dieser in ihrem 1st Level Cache
abgelegt. Mit dem Schließen der Session werden auch die Referenzen aus dem zugehörigen 1st Level Cache entfernt.
Sind diese dort vorhanden, so werden die Daten aus dem schnellen Puffer geliefert und nicht
vom langsamen Quellmedium geladen. Man
spricht von „Cache-Hits“ im positiven Fall und
„Cache-Misses“, wenn die Daten erst in den
Puffer eingelesen werden müssen.
Der 2nd Level Cache ist optional, langlebiger und nur einmal pro
Applikation vorhanden. Er wird durch die SessionFactory über die
Schnittstelle „CacheProvider“ lediglich gesteuert, aber nicht direkt durch Hibernate implementiert. Hibernate liefert das Interface
„CacheProvider“, welches die Schnittstelle zwischen der SessionFactory und einer Cache-Implementierung definiert.
Diese Art von Caching ist allgegenwärtig: egal,
ob es der Inhalt eines BIOS-Bausteins im PC
ist, oder ob es die Bilder einer häufig besuchten Website sind – sie alle werden gepuffert.
Von letzterer gibt es verschiedene Ausprägungen, insbesondere
wird zwischen JVM-Level und Cluster-wide unterschieden. Clusterweite Cache-Implementierungen können über JVM-Grenzen hinaus auch Verbunde mit einem gemeinsamen Cache versorgen.
In Hibernate dient das Puffern dazu, die Anzahl
an benötigten Datenbankzugriffen zu reduzieren. Ohne Puffer müsste Hibernate bei jedem
Laden eines Objekts durch eine Session oder
Query auf die Datenbank zugreifen.
Hebel hier, ...
Generell erfolgt die Konfiguration des 2nd Level Caches zweigleisig. Hibernate selbst hat keinen direkten Einfluss auf die Konfiguration des Puffers, also z. B. auf dessen Größe. Dies erfolgt spezifisch für die jeweilige CacheProvider-Implementierung. Ein Bei-
Dies würde unweigerlich zu einer starken Belastung der Datenbank und einer spürbar langsameren Ausführungszeit der auf Hibernate
basierenden Anwendung führen.
Um diese K.O.-Kriterien zu umgehen, legt Hibernate-Objekte, die initial von einer Session
geladen werden, im Puffer ab. Bei einem erneuten Zugriff wird das Objekt dann bei aktuellem Pufferstatus aus diesem geliefert und
die zeitaufwändige Datenbankabfrage entfällt.
Andernfalls wird das Objekt neu aus der Datenbank abgefragt, und dabei auch der Puffer aktualisiert.
Und das auch noch gleich doppelt!
Intern verwendet Hibernate zum Puffern ein
zweistufiges Verfahren in Form von 1st und 2nd
Level Caches (siehe Abbildung 1).
ORDIX News 3/2006
Abb. 1: Aufbau des Hibernate-Caches.
37
Java/XML
Cache Mode
Beschreibung
read only
Für Objekte, deren Attribute niemals verändert wer­
den.
nonstrict
read/write
Sollte verwendet werden, wenn eine parallele Ände­
rung eines Datensatzes unwahrscheinlich ist. In diesem Modus ist nicht garantiert, dass die vom Cache
gelieferte Version des Objekts auch die aktuell in der
Datenbank vorhandene ist.
read/write
Sichert die Konsistenz zwischen dem Puffer und den
Sätzen in der Datenbank zu („read committed“).
transactional
Sichert für den gesamten Lauf einer Transaktion zu,
dass die darin enthaltenen Daten gültig sind („repeat­
able read“).
Abb. 2: Konfigurationsparameter für den Cache Mode.
<class name="de.ordix.Fixwert" mutable="false">
<cache usage="read-only"/>
....
</class>
Abb. 3: Konfiguration des Cachings für eine Klasse.
<ehcache>
<diskStore path="java.io.tmpdir"/>
<defaultCache
maxElementsInMemory="5000"
eternal="true"
overflowToDisk="true"
/>
<cache name="de.ordix.BigObject"
maxElementsInMemory="10"
eternal="false"
timeToIdleSeconds="300"
timeToLiveSeconds="600"
/>
</ehcache>
Abb. 4: Konfigurationseinstellungen aus ehcache.xml.
spiel für den CacheProvider Easy Hibernate Cache (EHCache)
zeigen wir im weiteren Verlauf des Artikels.
Auf der Hibernate-Seite wird lediglich definiert, dass und wie der
2nd Level Cache genutzt werden soll. In der Standardeinstellung
ist der 2nd Level Cache selbst bereits aktiv, so dass lediglich das
Caching für einzelne Klassen aktiviert werden muss.
Innerhalb der Mapping-Dateien (*.hbm.xml) wird pro Klasse die zu
verwendende Art des Caching definiert. Hibernate steuert damit das
Verhalten bei konkurrierenden Zugriffen und kennt die in Abbildung
2 gezeigten Ausprägungen. Die Einstellung wird im Mapping unterhalb von <class> mit dem Element <cache> vorgenommen.
Das in Abbildung 3 gezeigte Beispiel definiert, dass alle Instanzen
des Typs Fixwert über einen read-only 2nd Level Cache vorgehalten werden. Andere Cache-Modi würden analog eingetragen, indem man das Attribut usage mit einem anderen Wert als readonly versieht.
38
... Stellschrauben dort
Wenn Hibernate auf die Zusammenarbeit mit
dem 2nd Level Cache vorbereitet wurde, gilt es
noch, den Cache selbst zu konfigurieren.
Der EHCache ist der bekannteste Vertreter der
JVM-Level Cache­Provider, weil dieser zusammen mit Hibernate ausgeliefert wird und auch
in der Standardeinstellung bereits aktiv ist. Abbildung 4 zeigt eine einfache Beispielkonfiguration für EHCache.
Damit die Konfiguration beim Start automatisch eingelesen wird, muss sie lediglich unter dem Namen ehcache.xml im Klassenpfad der Anwendung liegen. Die Datei definiert
Default-Einstellungen für alle Puffer und konfiguriert spezifische Pufferregionen.
Hibernate bedient EHCache so, dass es zu
puf­fernde Klassen jeweils in eine Pufferregion
legt, die dem voll qualifizierten Namen der Klas­
se entspricht.
Sollte eine solche Pufferregion nicht konfiguriert sein, wird beim Start eine Warnung ausgegeben und die Standardwerte aus dem Default-Cache kommen zur Anwendung.
Das Beispiel aus Abbildung 4 legt für den DefaultCache fest, dass maximal 5000 Objekte in einer
Puf­ferregion im Speicher gehalten werden sollen (max­ElementsInMemory).
Bei Überschreiten dieser Grenze werden – je
nach erforderlichem Platzbedarf – Objekte auf
die Disk in das temporäre Verzeichnis der JVM
ausgelagert (overflowToDisk, diskstore
path).
Außerdem werden Objekte niemals automatisch aus dem Cache entfernt (eternal). Für
die Klasse BigObject wird die Pufferregion
so eingestellt, dass maximal 10 Instanzen gepuffert werden.
Die Instanzen werden, sofern sie unbenutzt
sind, nach 300 Sekunden, spätestens jedoch
nach 600 Sekunden aus dem Cache entfernt.
Für den Default-Cache sind im Gegensatz dazu keine Zeitwerte angegeben.
„Dieselbe Anfrage nochmal?“ ;-)
Neben dem gezielten Einlesen von ganzen Ob­
jektgraphen werden oft auch Objektmengen mit
Hilfe von Queries ermittelt.
Wird eine bestimmte Query wiederholt durchgeführt und verändert sich die Ergebnismenge
nur selten, ist sie ein Kandidat für den Query
ORDIX News 3/2006
Java/XML
Cache. Dieser verhindert die wiederholte Ausführung einer Datenbankabfrage, indem er
sich die Ergebnismenge für eine bestimmte
Query intern merkt.
Der Query Cache selbst speichert nur die IDs
der Objekte innerhalb der Ergebnismenge. Die
Instanzen selbst werden dann, wie bei einem
Session.get(), über den 2nd Level Cache
bezogen. Der Query Cache bedingt also folglich den Einsatz eines 2nd Level Caches.
Ob die Ergebnismengen innerhalb des Query Caches noch aktuell sind, prüft Hibernate
intern anhand eines Zeitstempels.
Ist die letzte Änderung an einer Tabelle älter
als das aktuell im Cache vorhandene Abfrageergebnis, so wird die Ergebnismenge aus dem
Puffer geliefert. Andernfalls wird eine neue Abfrage gegen die Datenbank durchgeführt und
der Query Cache aktualisiert.
Der Query Cache ist standardmäßig abgeschaltet und muss daher über den Schalter
hibernate.cache.use_query_cache
true in der Hibernate-Konfiguration aktiviert
werden.
Dies erstellt zwei neue Pufferregionen für die
Abfrageergebnisse (org.hibernate.cache.
StandardQueryCache) und die Zeitstempel
(org.hibernate.cache.UpdateTimestampsCache), die innerhalb der Datei ehcache.xml konfiguriert werden (zur Syntax
siehe Abbildung 4).
Da ein Puffern der Ergebnismenge nur für bestimmte Abfragen Sinn macht, muss dies explizit im Code angefordert werden.
Dazu bietet die Klasse Query die Methode
setCacheable(). Wenn vor der Ausführung
der Query [z. B. mit .list()] das cacheableAttribut auf true gesetzt wird, veranlasst
dies die Nutzung des Query Caches für diese Abfrage.
Glossar
Cache
Erhöht die Leistung einer Anwendung, indem wiederholte
Zugriffe auf langsame Datenstrukturen durch Zwischenspeicherung im Hauptspeicher beschleunigt werden.
JVM
Java Virtual Machine. Programm, in dem Java-Programme
ausgeführt werden. Eine JVM ist vom Betriebssystem abhängig, während das Java-Programm unabhängig vom Betriebssystem ist.
Wer Zahlenmaterial benötigt (z. B. Cache Hit / Miss Ratio), sei auf
die Methode SessionFactory.getStatistics() verwiesen.
Alternativ kann man die Zahlen auch via JMX über ein MBean beziehen.
Darum prüfe, wer sich ewig bindet
So schön das Puffern auch ist, so sollte eines nie außer Acht gelassen werden: Ein Puffer erkennt niemals von selbst Veränderungen in der darunterliegenden Datenschicht. Wenn neben Hibernate eine weitere Anwendung schreibend auf der gleichen Datenbank arbeitet, ist es nicht ohne weiteres möglich, die Konsistenz
des Puffers zu gewährleisten.
Achtung auch bei manuellen Eingriffen! Im Zweifel sollte zumindest im direkten Anschluss an ein externes Update der 2nd Level
Cache geleert werden.
Eine Garantie, dass man mit dieser Methode wirklich alle Instanzen
erwischt (insbesondere die in 1st Level Caches), gibt es nicht.
Im Zweifel sollte daher die Anwendung angehalten und neu gestartet werden, da man sonst Gefahr läuft, dass die gerade geänderten Daten direkt wieder durch einen alten Hibernate-Stand
überschrieben werden.
Nun ist das Anhalten und Starten einer Anwendung vielleicht in Ausnahmefällen ein probates Mittel, dieser Gefahr zu entgehen.
Bei einem alltäglichen, parallelen, schreibenden Zugriff einer anderen Anwendung ist aber eine andere Lösung notwendig. Auch
dafür kann Hibernate etwas aus dem Hut zaubern: „Optimistic concurrency control“ ist hier das Schlagwort, über das wir in einer der
nächsten Ausgaben berichten werden.
Weitere Möglichkeiten
Hibernate bietet noch einiges mehr an Möglichkeiten im Bereich Caching. Über die SessionFactory lässt sich z. B. das gezielte Entleeren bestimmter oder aller Pufferregionen
anstoßen.
Die Beschreibung der Methode Session­
Factory.evict() erklärt, wie es funktioniert.
Über Query.setCacheMode(CacheMode.
REFRESH) lässt sich auch für eine Query gezielt das erneute Laden der Ergebnismenge
anfordern.
ORDIX News 3/2006
Dies ist aber auch der einzige Nachteil. Ansonsten gilt: Wenn die
Puffer gut auf die Applikation abgestimmt sind, verhelfen der Object Cache und der Query Cache zu einer enormen Leistungssteigerung. Fazit: Sehr empfehlenswert.
Michael Heß ([email protected]).
39
Unix/Linux/Open Source
Tiefe Einblicke in Solaris 10 mit Dtrace (Teil III):
Geisterhafte Technik oder
Technik, die begeistert?
Teil II der Serie zeigte auf, welche Dinge sich mit Dtrace ausleuchten lassen. Diesmal betrachten wir Dtrace
selbst - auf der Grundlage des Skriptes dexplorer aus dem DtraceToolkit.
dexplorer
Dieser Artikel richtet sich an erfahrene Systemadministratoren
und Entwickler, die umfassende Analysetechniken unter Solaris
10 nutzen möchten.
Aus dem ersten Teil der Reihe in Ausgabe 4/2005, S. 12, kennen
wir die prinzipielle Funktionsweise von DTrace und den rudimentären Aufbau eines D-Skriptes. So wurde unter anderem truss
nachgebildet.
In Teil II (Ausgabe 1/2006, S. 36) haben wir die vorhandenen Mess­
punkte kategorisiert und somit einen Überblick über mögliche Messungen erlangt. Im Folgenden wollen wir uns der Sprache D genauer widmen und dabei das DtraceToolkit kennenlernen.
Take the easy way
Dtrace bietet unzählige Analysemöglichkeiten, sofern entsprechen­
de Skripte vorhanden sind. Der Aufwand, ein eigenes Analyseskript
zu schreiben, lässt sich vermeiden, indem vorgefertigte Skripte ge­
nutzt werden.
Als wichtige Skriptsammlung ist das DtraceToolkit von Brendan
Gregg zu nennen [1] . Es bietet etwa 70 verschiedene Skripte, womit Fragestellungen zu den unterschiedlichen Themen (Netzwerk,
Prozesse, CPU, IO, ...) analysiert werden können.
170 header='dtrace:::BEGIN {
171 printf("%Y, ", walltimestamp);
172 printf("%s %s %s %s %s, ", `utsname.sysname,
`utsname.nodename,
173
`utsname.release, `utsname.version,
`utsname.machine);
174 printf("%d secs\n",'$interval');
175 }
176 profile:::tick-'$interval'sec { exit(0); }
177 '
Abb. 1: Der Programmcode für die Überschrift in dexplorer nutzt
externe Variablen.
2006 May 18 23:48:56, SunOS jupiter 5.10 Generic_
118844-26 i86pc, 5 secs
Abb. 2: Die Ausgabe der Überschrift in dexplorer.
40
Das Skript dexplorer sammelt die unterschiedlichen Messdaten. Jede Fragestellung
wird in einer separaten Datei beantwortet und
alle zusammen werden in ein Tar-Archiv gepackt. Tatsächlich ist dexplorer ein Shell­
skript, das nacheinander unterschiedliche DSkripte zur Ausführung bringt. Diese einzelnen
Skripte bie­ten sich an, um daran Dtrace-spezifische Einzelheiten aus dexplorer kennenzulernen. Das gesamte Skript und alle weiteren
DtraceToolkit-Skripte finden sich unter [1] .
Externe Variablen
Um die Ausgaben der unterschiedlichen DSkripte innerhalb von dexplorer mit einer
einheit­lichen Überschrift zu versehen, wird
in der Shell-Variable header der Beginn der
dtrace-Skripte inklusive Ausgabe der Überschrift definiert.
Abbildung 1 zeigt den Programmcode, während
Abbildung 2 die dadurch entstehende Überschrift darstellt. Es wird deutlich, dass neben
dem Datum (walltimestamp), der Betriebssys­
temname, der Rechnername, die Kernelversion und die Prozessorarchitektur dargestellt
werden. Das Skript greift dazu auf Externe Va­
riablen zu.
Externe Variablen sind Variablen des zu analysierenden Programms (z. B. des Kernels). Sie
erhalten im Skript den Accent grave (`) als Präfix. Häufig kann in Header-Dateien die Defini­
tion der Variablen ermittelt werden. Der Aufbau
der Struktur utsname ist z. B. in der Datei /
usr/include//sys/utsname.h definiert.
Durch die Zeile 176 wird nach einem vordefinierten Messzeitraum das Programm beendet.
Ist die Shellvariable $interval z. B mit dem
Wert 5 belegt, so wird der Messpunkt profile:::tick-5sec nach 5 Sekunden exit
0 ausführen. Dies führt zur Beendigung der
Messung, wobei ein möglicher dtrace:::
END Messpunkt noch ausgeführt wird.
ORDIX News 3/2006
Unix/Linux/Open Source
Aggregate
Dtrace kennt assoziative Arrays, worin, ähnlich wie bei AWK, Werte gespeichert werden
können. Weitaus häufiger als Arrays werden
so genannte Aggregate verwendet. Im Unterschied zu den Arrays, wird in einem Aggregat
nicht ein einmalig aufgetretener Wert zu einem
speziellen Index dargestellt, sondern meist eine
Zusammenfassung häufig aufgetretener Wer­te
zu einem bestimmten Index (z. B. der Mit­telwert
oder die Anzahl).
Gleich das erste Dtrace-Skript „Interrupts by
CPU...“ innerhalb dexplorer greift zu Aggre­
gaten und ermittelt die Anzahl aufgetretener Interrupts pro CPU (Aggregat: Anzahl pro CPU).
242 dstatus "Interrupts by CPU..."
243 $dtrace -qn "$header"'
244 sdt:::interrupt-start { @num[cpu] = count();}
245 dtrace:::END
246 {
247
printf("%-16s %16s\n", "CPU", "INTERRUPTS");
248
printa("%-16d %@16d\n", @num);
249 }
250 ' | $clean > Cpu/interrupt_by_cpu
Abb. 3: Um die Interrupts pro CPU zu ermitteln, werden Aggregate
genutzt.
Funktionsname
Argument
Ergebnis
Count
keines
Anzahl Aufrufe
In Abbildung 3 Zeile 244 wird das Aggregat
@num[cpu] mit Hilfe der Aggregatsfunktion
count() gefüllt. Das Aggregat wird durch das
Präfix @ als solches kenntlich. Rechts vom Zuweisungszeichen = darf nur eine Aggregatsfunktion stehen. Einfache Aggregatsfunktionen sind in Abbildung 4 dargestellt.
Sum
Zahl
Gesamtsumme der angegebenen
Zahlen.
Avg
Zahl
Arithmetisches Mittel der angegebenen
Zahlen.
min
Zahl
Kleinster Wert unter den angegebenen
Zahlen.
Die Ausgabe eines Aggregats erfolgt implizit
am Ende des Skriptes, ohne dafür eine Zeile
Programmcode investieren zu müssen. Will
der Skriptentwickler die Ausgabe bzw. das Aus­
gabeformat beeinflussen, so kann er dies mit
der Funktion printa tun.
max
Zahl
Größter Wert unter den angegebenen
Zahlen.
In Abbildung 3 wird in Zeile 248 das gesamte
Aggregat mit allen gesammelten Werten ausgegeben. Die dadurch entstehende Ausgabe ist auf dem hier dargestellten Einprozessorsystem nicht sonderlich spektakulär. Sie
ist in Abbildung 5 dargestellt und zeigt, wie
erwähnt, die Anzahl der aufgetretenen Interrupts pro CPU.
Lokale Variablen und bedingte Zuweisung
Schon das nächste Skript „Interrupt times ...“
nutzt alle bisher kennengelernten Techniken
und noch weitere. Da Interrupts durch Geräte
verursacht werden, soll pro Gerät die Dauer
der Interrupt-Behandlung ermittelt werden.
In Zeile 254 wird die Zeit zu Be­ginn der Interrupt-Bearbeitung mittels vtimestamp ermittelt (Abbildung 6). In Zeile 262 wird die verstrichene Zeit der Interrupt-Bearbeitung durch
Subtraktion ermittelt und in einem Aggregat
festgehalten.
Damit die Interrupt-Bearbeitung unterschiedlicher Threads unabhängig voneinander analysiert werden kann, wird die Startzeit durch
Angabe des Präfixes self-> als Thread-lokaler Wert, und damit unabhängig von allen
ORDIX News 3/2006
Abb. 4: Einfache Aggregatsfunktionen.
CPU
0
INTERRUPTS
516
Abb. 5: Die Ausgabe des Aggregats gibt an, wie viele Interrupts pro
CPU eintraten.
252 dstatus "Interrupt times..."
253 $dtrace -qn "$header"'
254 sdt:::interrupt-start { self->ts = vtimestamp; }
255 sdt:::interrupt-complete
256 /self->ts && arg0 != 0/
257 {
258
this->devi = (struct dev_info *)arg0;
259
self->name = this->devi != 0 ?
260
stringof('devnamesp[this->devi->devi_major]
.dn_name) : "?";
261
this->inst = this->devi != 0 ? this->devi
->devi_instance : 0;
262
@num[self->name, this->inst] = sum
(vtimestamp - self->ts);
263
self->name = 0;
264 }
265 sdt:::interrupt-complete { self->ts = 0; }
266 dtrace:::END
267 {
268
printf("%11s %16s\n", "DEVICE", "TIME (ns)");
269
printa("%10s%-3d %@16d\n", @num);
270 }
271 ' | $clean > Cpu/interrupt_time
Abb. 6: Zur Ermittlung der Interrupt-Dauer werden Thread-lokale Variablen verwendet.
41
Unix/Linux/Open Source
anderen Threads, gespeichert. Die Messwerte sind somit eindeutig getrennt.
Über das Argument arg0 in Zeile 258, welches durch den Mess­
punkt sdt:::interrupt-complete bereitgestellt wird, wird auf
eine externe Struktur zugegriffen und in der Variablen this->­devi
hinterlegt. In Zeile 260 wird die Majornumber des Interrupt-auslösenden Gerätes genutzt, um letztlich den Treibernamen zu ermitteln. Dieser wird in der Variablen self->name hinterlegt.
DEVICE
ata1
ata0
TIME (ns)
1342875
9300243
Abb. 7: Die Interrupt-Dauer wird aufgelistet nach Geräten ausgegeben.
273 dstatus "Dispatcher queue length by CPU..."
274 $dtrace -qn "$header"'
275 profile:::profile-1000
276
{
277 this->num = curthread->t_cpu->cpu_disp
->disp_nrunnable;
278 @length[cpu] = lquantize(this->num, 0,
100, 1);
279
}
280 dtrace:::END { printa(" CPU %d%@d\n", @length); }
281 ' | $clean > Cpu/dispqlen_by_cpu
Abb. 8: Die Aggregatsfunktion lquantize ermöglicht die Ausgabe von
His­togrammen.
CPU 0
value ------- Distribution ------- count
< 0 |
0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 4829
1 |
54
2 |
8
3 |
1
4 |
1
5 |
1
6 |
0
Abb. 9: Das Histogramm gibt Aufschluss über die Verteilung der
Messwerte.
Funktionsname
Argument
Ergebnis
Quantize
Zahl
Liefert ein logarithmisches Verteilungsdiagramm der angegebenen Ausdrücke. Alle Werte, die kleiner oder gleich
dem in der Zeile angegebenen, aber
größer als der eine Zeile darüber angegebene Wert sind, wurden bei der
Anzahl beachtet.
Lquantize
Zahl, untere Grenze,
obere Grenze, Schrittweite
Liefert ein lineares Verteilungsdiagramm der angegebenen Ausdrücke.
Die Staffelung erfolgt entsprechend
der Schrittweite von der Ober- bis zur
Untergrenze.
Abb. 10: Aggregatsfunktionen zur Erzeugung von Histogrammen.
42
Für den genauen Aufbau der hier verwendeten Strukturen müssen wiederum die entsprechenden Header-Dateien ermittelt und analysiert werden.
Bitte beachten Sie, dass die Zuweisungen in
Zeile 259, 260 und in Zeile 261 bedingte Zuweisungen sind. Zeile 261 meint: Wenn die
Variable this->devi nicht den Wert 0 hat,
dann nutze den Wert this->devi->devi_
instance, sonst nutze den Wert 0. Auf diese
Weise werden Treibername und Instanzname
als 0 angenommen, wenn die entsprechenden
Parameter nicht vorhanden sind.
Nun sind alle Parameter bekannt, um sich der
Zeile 262 zu widmen. Die verstrichene Zeit
wird berechnet und in einem Aggregat festgehalten, welches die Gesamtzeit der InterruptBearbeitung in Abhängigkeit vom Treibernamen (self->name) und vom Instanznamen
(this->inst) ermittelt.
Durch die Zuordnung des Wertes 0 in Zeile 263
wird in der Sprache D der Speicher für die Variable self->name deallockiert. Die Ausgabe wird durch die Zeilen 268 und 269 erzeugt
und ist in Abbildung 7 dargestellt.
Histogramme
Das nächste Skript „Dispatcher queue length
by CPU ...“ ist wieder etwas kürzer, bietet jedoch ein Highlight. In Zeile 277 (Abbildung
8) wird über die Dtrace-Built-In Struktur cur­
thread die Anzahl wartender Threads für eine
CPU ermittelt. Das Aggregat @length[cpu]
wird in Zeile 278 mit diesem Wert durch die
Ag­gregatsfunktion lquantize gefüllt. Dadurch wird bei der Ausgabe pro CPU ein His­
to­gramm erstellt.
In Abbildung 9 sehen wir, dass während des
Messzeitraums 4829 mal 0 Threads auf CPUZeit gewartet haben. 54 mal war genau ein
Thread in der Warteschlange des Prozessors
0. 8 mal warteten 2 Threads. Einmal warteten 3, einmal 4 und einmal 5 Threads. 6 oder
mehr Threads und weniger als 0 Threads warteten nie auf die CPU 0. Da es sich bei dem
fraglichen System um eine Einprozessormaschine handelt, werden keine weiteren Histogramme angezeigt.
Beim Aufruf der Funktion lquantize() in Zei­
le 278 wurde neben dem zu messenden Wert
noch der Bereich (0 bis 100) und die Stufenweite (1) angegeben. Die Funktion quantize
liefert demgegenüber ein logarithmisches His­
togramm. Die Angabe der Schrittweite beziehungsweise der Bereichsgrenzen ist dabei
nicht notwendig (siehe Abbildung 10).
ORDIX News 3/2006
Unix/Linux/Open Source
Link
Glossar
► [1] http://www.opensolaris.org/os/
com­munity/dtrace/dtracetoolkit/
Die weiteren D-Skripte
Die weiteren D-Skripte innerhalb von dexplorer sind ähnlich aufgebaut und bieten uns keine grundlegend neuen Erkenntnisse. Für die
detaillierte Analyse der verwendeten KernelStrukturen müssen häufig der „Solaris Dynamic Tracing Guide“ und die Header-Dateien
im Verzeichnis /usr/include als Informa­
tionsquelle herangezogen werden.
Aggregat
Eine Einheit, die durch Zusammensetzung ein­
zelner, relativ selbstständiger Teile zustande
kommt. Hier: Statistische Größen, die sich durch
einzelne Messwerte ergeben.
Assoziatives Array Sonderform eines Arrays. Statt eines numerischen Indexes wird ein Schlüssel zur Indizierung und damit zur Adressierung eines Elementes verwendet.
AWK
Programmiersprache zur Bearbeitung und Aus­
wertung von Textdateien. Sie ist benannt nach
den Initialen ihrer Programmierer: Alfred V. Aho,
Peter J. Weinberger und Brian W. Kernighan.
dexplorer
Skript aus der DtraceToolkits Skriptsammlung.
Externe Variablen
Variable, die extern, also außerhalb des fraglichen Programms definiert wurde.
Fazit
Header-Datei
C-Quellcode, der typischerweise Definitionen
von Variablen und Strukturen enthält.
Es wird deutlich, wie mächtig Dtrace ist und
welche Techniken zur Analyse angewendet
werden können. Ein Blick auf das DtraceToolkit lohnt sich, denn auch die weiteren Skripte sind lesenswert und ermöglichen Erkenntnisse über das System, die sich ohne Dtrace
wahrscheinlich nur vermuten ließen.
Histogramm
Graphische Darstellung der Häufigkeitsverteilung von Messwerten.
Thread
Elementaraufgabe. Die Befehle eines Threads
sind in sich so abgeschlossen, dass sie auf einer CPU zusammenhängend ausgeführt werden können. Um Programme mehrprozessorfähig zu gestalten, müssen die Abläufe in Threads
untergliedert sein.
Threadlocal
zu einem Thread gehörend
Markus Schreier ([email protected]).
Messe-Rückblick: JAX 2006
„Lucene unter Last“
auf der JAX 2006 in Wiesbaden
ORDIX war in diesem Jahr zum ersten Mal aktiv mit einem Vortrag und einer Infoinsel auf
der JAX Konferenz vertreten. Die JAX ist die führende IT-Konferenz für Enterprise Technologien (Java, XML, WebServices) in Europa. Die fünftägige Messe fand in den Rhein-MainHallen in Wiesbaden statt.
Die JAX Ausstellung
1.600 Teilnehmer konnten sich im Mai in den
über 150 Vorträgen rund um die Themen Java, XML und WebServices informieren. In den
Pausen bot sich die Gelegenheit, die paral­le­
le Ausstellung zu besuchen und sich direkt
mit Fachleuten der mehr als 50 Firmen auszutauschen.
Dr. Stefan Koch, Senior Consultant der ORDIX
AG (Foto oben), präsentierte in seinem Vortrag
das Thema „Lucene unter Last“. Lucene ist eine Open Source Java-Bibliothek, die eine Vollt-
ORDIX News 3/2006
extrecherche unterstützt. Die Recherche ist dateibasiert und ersetzt
eine entsprechende Datenbankrecherche. In einer Tomcat Web-Anwendung für das Intranet wurde das Lastverhalten von Lucene bei
parallelem Zugriff untersucht.
Die Inhalte des Vortrags finden Sie in dem gleich­namigen Artikel
(Seite 30). Allgemeine Informationen zur JAX Konferenz finden Sie
im Internet unter http://www.jax.de.
Sie haben weiterführendes Interesse am Thema „Lucene“? Sprechen Sie uns an. Wir beraten Sie gern!
Stefanie Heither ([email protected]).
43
Halten Sie Schritt mit dem Puls der Zeit!
Neue ORDIX Seminare 2007
Datenbanken
Java/J2EE
•
•
•
•
•
•
•
•
• Java GUI Entwicklung mit Swing
• Java 5.0 Neuheiten
• Webanwendungen mit Java Server
Oracle SQL für Umsteiger
Oracle PL/SQL Aufbau mit LOB Programmierung
Oracle Grid Control Workshop
Oracle Advanced Queuing Workshop
Oracle Replikation Workshop
IBM DB2 UDB für Unix/Windows 9.1 Neuheiten
Microsoft SQL Server 2005 Neuheiten
Microsoft SQL Server HochverfügbarkeitsWorkshop
System Management
Faces (JSF)
• Java Web Services
• Entwicklung mit Hibernate
Betriebssysteme
• Server-Virtualisierung mit XEN
• Solaris 10 für erfahrene System­
administratoren
• BMC PATROL/Performance Manager
Base Reporting
• Solaris Containers
• Multivendor Systemadministration
Weitere Informationen finden Sie im ORDIX Trainingsshop unter http://training.ordix.de
oder in unserem Seminarprogramm, was ab Oktober druckfrisch zur Verfügung steht.