15 Jahre - ORDIX AG

www.ordix.de
ORDIX News
Ausgabe 1/2007
€ 2,20
Das IT-Magazin der ORDIX AG
e
r
h
a
J
5
1
D
R
O
N
IX
s
w
e
Jubiläum: 15 Jahre ORDIX News
S. 10
ZFS – Das ultimative Dateisystem
DB2 UDB 9.1 (Teil I): Codename „Viper“
EJB 3.0 (Teil II): Keep it Simple
IBM IDS 10.0 (Teil IV): A Success Story
Vorstellung des neuen Solaris 10 Features S. 34
Implementierungsdetails von Session Beans
unter Nutzung von EJB 3.0 Annotations S. 48
Neuerungen des IBM DB2 Datenbankservers S. 37
Verwendung und Umgang mit den Neuerungen
für den IDS 10.0 S. 30
ORDIX News 4/2006
ORDIX
gratuli
DOAG
ert der
ganz h
e
rzlich
20-jäh
zum
rigen J
u
b
iläum
bedan
und
kt sich
für die
Zusam
gute
menar
beit!
Die Highlights 2007 bei der DOAG
März
Oracle CeBIT Community auf den
Partnerständen der DOAG
Mai
European Oracle User Conference in
Amsterdam
Ab August
Jubiläumsjahr: 20 Jahre DOAG
November
20. Deutsche ORACLE-Anwenderkonferenz
5. Deutsche ORACLE Business-Software
Anwenderkonferenz
Und unsere erfolgreichen Veranstaltungen
Regionaltreffen, SIG-Treffen und SID
�Alle Informationen unter www.doag.org
ORDIX News 4/2006
Editorial
Paderborn, Januar 2007
Vergangenheit
15 Jahre ORDIX News
15 Jahre Editorial
15 Jahre Artikel korrekturlesen
15 Jahre mit drei Bundeskanzlern.
Man stelle sich das vor: Es gab mal 16 Jahre mit nur einem.
Mit diesem Editorial gebe ich die Verantwortung für das Lesen der Artikel ab. Auch das ist wieder ein Schritt, mich
noch mehr auf andere Bereiche meiner Arbeit in unserem stetig wachsenden Unternehmen zu konzentrieren.
An dieser Stelle – im Editorial – bleibe ich Ihnen aber erhalten, egal was Microsoft plant oder wer der nächste Bun­
deskanzler wird.
2007 hat gerade begonnen, wenn Sie diese Zeilen lesen. Außer der neuen Mehrwertsteuer, mit der wir alle wieder
einmal mehr für die Negativleistungen unserer Politiker bezahlen müssen, wissen wir noch nicht, was es bringen
wird. Deshalb kann ich Ihnen und uns nur alles Gute, viel Gesundheit, so wenig Katastrophen wie möglich und viel
Erfolg wünschen.
Natürlich weiß ich noch einiges, was Ihnen 2007 bringen wird: Einige ORDIX News mit unterschiedlichsten Artikeln.
Dieses Mal erfahren Sie unter anderem etwas über die „Java Bohnen“ 3.0, über das neue Filesystem ZFS von SUN,
über Neuerungen (letzter Teil) beim Datenbanksystem Informix mit Aussicht auf Revival und über XEN, die VMware
Alternative.
Wir informieren Sie über Entwicklungen bei JSF, Ajax, XML und landen damit schon bei einigen sehr interessanten
Artikeln zum Thema Oracle. Wir berichten über weitere Oracle Objekttypen, über die diesjährige DOAG Konferenz,
über Datenkompression und über das beliebte Thema Large Objects (LOB).
Abgerundet wird der Cocktail Mix mit einem Artikel zum Thema ITIL. Damit zeigen wir auch in 2007 wieder viel Infor­
matives aus unserem Portfolio.
Teile der ORDIX News sind etwas nostalgisch aufgemacht und auch unseren Mitarbeitern hat es Spaß gemacht,
sich mal Bilder aus der Vergangenheit wieder in Erinnerung zu rufen. Der Inhalt ist aber wie immer auch im 16. Jahr
top­aktuell.
Ich wünsche Ihnen viel Spaß beim Lesen und für 2007 nochmal alles Gute!
Wolfgang Kögler
P.S.: Kennen Sie die Citroen C6 Reklame mit Sean Connery? Scheint zu funktionieren, wenn Sie mein Foto betrachten .
ORDIX News 1/2007
Inhalt
Training
Standards
25 ....Seminar Server-Virtualisierung mit XEN
28 ....Seminarübersicht: Januar bis Juni 2007
33.....Seminar Informix Dynamic Server Administration
36 ....Seminar Solaris 10 für erfahrene Systemadministratoren
03 ....Editorial
Aktuell
Projektmanagement
04 ....Inhalt
19 ....Impressum
Titel-
10 ....Jubiläum: 15 Jahre ORDIX News thema
Die ORDIX News feiert Geburtstag: 15 Jahre interessante
Fachartikel, Praxisberichte und Produkttestberichte.
11 . ...Larry Ratlos: Datenbankblöcke optimal füllen
15 ....ORDIX Ausbildung: Dem Nachwuchs eine Chance
16 ....ITIL: Einführung des
Incident Managements
Incident Management als Grundstein für
die Einführung eines kompletten IT-Ser­
vice Managements.
47 ....007 erobert das DOAG Casino Royal
Rückblick DOAG Konferenz und Schulungstag 2006.
Betriebssysteme
23 ....Virtualisieren mit XEN
Vertiefende Einblicke in die Open Source Virtualisierungslö­
sung XEN und die Möglichkeiten von XEN im Vergleich zu
kommerziellen Produkten.
34 ....ZFS – Das ultimative Dateisystem
Jetzt steht unter Solaris 10 das neue Fea­
ture ZFS zur Verfügung, das sowohl ein
Dateisystem als auch ein Volumemanager
mit völlig neuartigem Ansatz ist.
Datenbanken
Java/J(2)EE
12 ....Komprimierung von Index Organized Tables
Das Komprimieren von indexorganisierten Tabellen unter
Oracle mit Hilfe der KEY COMPRESSION.
05 ....MyFaces Tomahawk – Gut gerüstet
Bei­spiele zeigen, wie die Open Source
Imple­mentierung Tomahawk die Entwick­
lung von Web-Anwendungen unterstützt
und wo noch Schwächen zu finden sind.
26 ....Oracle Objekttypen von A - Z (Teil II): Typen mit „D“
In diesem Teil der Reihe stellen wir Ihnen die Objekttypen
DATABASE LINK, DIMENSION und DIRECTORY vor.
Titelthema
30 ....IBM IDS 10.0 Neuheiten (Teil IV): A Success Story ...
Anhand von Beispielen werden die Verwendung und der Um­
gang mit den Neuerungen für den IDS ab 10.0 erklärt.
Titel-
37 ....IBM DB2 UDB 9.1 (Teil I): Codename „Viper“ thema
Dieser Artikel beschreibt die Neuerungen des IBM DB2 Da­
tenbankservers mit Release 9.
44 ....Migration von Oracle LONG- zu LOB-Datentypen
Vorstellung verschiedener Aspekte der Migration von LONGzu LOB-Datentypen bei Datenbanktabellen und Erläuterung
einiger Besonderheiten in PL/SQL.
52 ....XMLType
Der Artikel beleuchtet Möglichkeiten und Grenzen des Oracle
Datentyps XMLType.
Titelthema
20 ....Code Coverage mit Clover:
Java unterm Kleeblatt
Das kommerzielle Code Coverage Plug­
in Clover deckt ungetestete Programm­
zeilen im Java Sourcecode auf. Hier be­­trachten wir die Imple­mentierung für die
Eclip­se-Entwicklungs­umgebung.
40 ....Ajax mit dem Google Web Toolkit
Vorstellung des Google Web Toolkits zur
Programmierung von Ajax-Anwendungen.
48 ....EJB 3.0 (Teil II): Keep it Simple
Implementierungsdetails von Session
Beans unter Nutzung von EJB 3.0 Anno­
tations.
ORDIX News 1/2007
Titelthema
Java/J(2)EE
MyFaces Tomahawk – Gut gerüstet
Als standardisiertes Framework hat JavaServer Faces (JSF) gute Chancen, den defacto Standard Struts bei
der Entwicklung von Web-Anwendungen abzulösen. Neben der konzeptionellen Qualität entscheiden letztlich Qualität und Umfang der Implementierungen darüber, ob der Standard von den Entwicklern angenommen wird. Anhand der Open Source Implementierung Tomahawk aus dem MyFaces-Projekt wird vorgestellt,
wie die Entwicklung von Web-Anwendungen durch JSF unterstützt wird.
Die Erweiterung machts
MyFaces [1] ist eine freie Standardimplemen­
tierung von JavaServer Faces. Die Bedienele­
mente, die eine Standardimplementierung zur
Verfügung stellt, befriedigen aber in den sel­
tensten Fällen die Anforderungen an eine Be­
nutzeroberfläche.
Selbstverständlich ist JavaServer Faces er­
wei­terbar, doch sollte es nicht Aufgabe der An­
wendungsentwick­lung sein, neue Bedienele­
mente zu entwerfen. Im Gegenteil: Als Grund­
lage der Anwendungsentwicklung sollte ei­
ne Implementierung ausgesucht werden. Die
Bedienelemente dieser Implementierung soll­
ten ausreichen, um die Anforderungen an die
Benutzer­oberfläche zu erfüllen.
In dem Open Source Projekt MyFaces wird To­
mahawk als eine Erweiterung von JavaServer
Faces angeboten. Die Möglichkeiten der Be­
dienelemente können in [2] ausprobiert werden.
In diesem Artikel wird beispielhaft der Umgang
mit einigen Tomahawk-Bedienelementen dar­
gestellt. Beispiele und Quellcode stammen in
wesentlichen Teilen aus den Open Source Pro­
jekten Tomahawk und MyFaces.
Und immer wieder Tabellen
Oftmals werden Web-Anwendungen als Intra­
net-Anwendungen dafür verwendet, Ergebnis­
Dieser Artikel richtet sich an Entwickler, Architekten und Ent­
scheidungsträger, die im Bereich der Entwicklung von Web-An­
wendungen tätig sind.
se von Datenbank-Abfragen darzustellen. Das führt zu wiederkeh­
renden Anforderungen: Die Ergebnisse sollen - das liegt nahe - als
Tabellen dargestellt werden.
Zur Verbesserung der Übersicht werden die Daten seitenweise dar­
gestellt: Bei größeren Datenmengen wird der Benutzer blättern, um
mehr Information zu bekommen. Neben dem Blättern steht häu­
fig die Sortierung der Ergebnisse nach Spalten ganz oben auf der
Wunschliste.
Manchmal reicht das aber noch nicht: In manchen Fällen müssen
die Ergebnisse veränderbar sein. Die Zellen der Tabelle bestehen
dann aus Eingabefeldern.
Für diese Standard-Anforderung werden von Tomahawk die Elemen­
te dataTable und dataScroller zur Verfügung gestellt. Ein Er­
gebnis könnte beispielsweise wie in Abbildung 1 aussehen.
Hier werden einige Eigenschaften eines Autos ausgegeben. Die
Spaltenüberschriften sind teilweise als Link ausgeführt: Wird der
Link betätigt, findet eine Sortierung der Tabelle nach dieser Spalte
statt. Wird nochmals auf die Spaltenüberschrift geklickt, so kehrt
sich die Sortierreihenfolge um.
Die Spalte „Farbe“ besteht aus Eingabefeldern. Hier kann der Be­
nutzer die Werte beliebig verändern. Unterhalb der Tabelle finden
sich die üblichen Elemente zum Blättern.
Um so eine Tabelle zu erstellen, muss der Entwickler einerseits
eine Java Server Page und andererseits passende Managed
Beans programmieren. Grundlagen zu JavaServer Faces werden
in [4] dargestellt. Die folgenden Ausführungen skizzieren die er­
forderlichen Schritte der Entwicklung.
Erstellung der Tabellenseite
Die Darstellung wird durch eine Java Server Page realisiert. Der
Code ist in Abbildung 2 abgedruckt.
Für die Nutzung der Tag-Bibliotheken von Tomahawk wird der Na­
mensraum „t“ verwendet:
<%@ taglib uri="http://myfaces.apache.org/tomahawk"
prefix="t"%>
Abb. 1: Typische Tabelle mit Sortier- und Editier­
möglichkeit.
ORDIX News 1/2007
Die Darstellung der Tabelle erfolgt durch das Element dataTable.
Die Formatierung der Tabelle wird weitgehend durch Cascading
Java/J(2)EE
<f:view>
<h:form>
<t:dataTable id="data" styleClass="scrollerTable" headerClass="standardTable_Header"
footerClass="standardTable_Header" rowClasses="standardTable_Row1,standardTable_Row2"
columnClasses="standardTable_Column,standardTable_ColumnCentered,standardTable_Column"
var="car" value="#{pagedSort.cars}" rows="10" sortColumn="#{pagedSort.sort}"
sortAscending="#{pagedSort.ascending}" preserveSort="true">
<h:column>
<f:facet name="header"></f:facet>
<h:outputText value="#{car.id}" />
</h:column>
<h:column>
<f:facet name="header">
<t:commandSortHeader columnName="type" arrow="true" >
<h:outputText value="Typ" />
</t:commandSortHeader>
</f:facet>
<h:outputText value="#{car.type}" />
</h:column>
<h:column>
<f:facet name="header">
<t:commandSortHeader columnName="color" arrow="true" >
<h:outputText value="Farbe" />
</t:commandSortHeader>
</f:facet>
<h:inputText value="#{car.color}" >
<f:validateLength maximum="10"/>
</h:inputText>
</h:column>
</t:dataTable>
<h:panelGrid columns="1" styleClass="scrollerTable2"
columnClasses="standardTable_ColumnCentered" >
<t:dataScroller id="scroll_1" for="data" fastStep="10" pageCountVar="pageCount"
pageIndexVar="pageIndex" styleClass="scroller" paginator="true"
paginatorMaxPages="9" paginatorTableClass="paginator"
paginatorActiveColumnStyle="font-weight:bold;"
actionListener="#{pagedSort.scrollerAction}">
<f:facet name="first" >
<t:graphicImage url="images/arrow-first.gif" border="1" /></f:facet>
<f:facet name="last">
<t:graphicImage url="images/arrow-last.gif" border="1" /></f:facet>
<f:facet name="previous">
<t:graphicImage url="images/arrow-previous.gif" border="1" /></f:facet>
<f:facet name="next">
<t:graphicImage url="images/arrow-next.gif" border="1" /></f:facet>
<f:facet name="fastforward">
<t:graphicImage url="images/arrow-ff.gif" border="1" /></f:facet>
<f:facet name="fastrewind">
<t:graphicImage url="images/arrow-fr.gif" border="1" /></f:facet>
</t:dataScroller>
</h:panelGrid>
</h:form>
</f:view>
Abb. 2: Java Server Page zur Darstellung einer sortierbaren Tabelle mit Eingabefeldern.
Stylesheets durchgeführt, die durch styleClass, headerClass,
footerClass etc. referenziert werden. Die äußere Gestaltung
lässt sich dadurch erheblich beeinflussen.
Wesentliche Attribute des Elements dataTable sind:
•
•
•
•
•
id: Name der Tabelle
var: Name der Zeilenvariable
value: Ausdruck zur Ermittlung der gesamten Liste
sortColumn:Ausdruck zum Setzen der Spalte, nach der sortiert werden soll
sortAscending: Ausdruck zum Setzen der Sortierreihenfolge
Im Folgenden werden die Spaltenüberschriften sowie die anzuzei­
genden Felder definiert. Für sortierbare Spalten werden die Spal­
tenüberschriften in das Element commandSortHeader eingebet­
tet. Wichtig ist dabei das Attribut columnName. Dieses Attribut gibt
den Namen an, der für die Sortierspalte angezeigt wird.
Die Eingabefelder in der Tabelle werden ein­
fach durch ein inputText-Element definiert.
Die Funktionalität des Blätterns stellt das Ele­
ment dataScroller zur Verfügung. Die Ab­
hängigkeit zwischen diesem dataScrollerElement und der Tabelle wird durch das Attri­
but for definiert.
Die erforderlichen Elemente lassen sich in der
Java Server Page schnell definieren. Aus der
Perspektive der Entwicklung ist eine solche
Seite schnell erstellt.
Es darf jedoch nicht verkannt werden, dass der
wesentliche Teil der Aufwände einer solchen
Seite nicht bei der Entwicklung sondern bei
der Gestaltung liegt. Diese ist glücklicherwei­
se durch die Verwendung von Stylesheets gut
ORDIX News 1/2007
Java/J(2)EE
gekapselt. So kann die Gestaltung unabhängig
von der Entwicklung durchgeführt werden.
Entwicklung der Managed Bean
Die Managed Bean ist die Schnittstelle zur Java
Server Page. Im Beispiel in Abbildung 2 heißt
sie pagedSort. Aufgabe der Managed Bean
ist es, die Daten für die Darstellung zu liefern.
In einer realen Anwendung würde die View die
Daten aus dem Domain Model holen. In dem
Beispiel werden die Daten stattdessen im Kon­
struktor erzeugt.
Im Folgenden sollen die erforderlichen Metho­
den der Managed Bean betrachtet werden, die
für das Verhalten der sortierbaren Tabelle im­
plementiert werden müssen. Die „schlechte
Nachricht“ dabei ist, dass das Sortieren in der
Managed Bean zu implementieren ist. Die „gu­
te Nachricht“: die Aufgabe ist nicht so schwie­
rig zu lösen.
Die Parameter der Sortierung sind die Spal­
te, nach der die Sortierung erfolgen soll, und
die Sortierreihenfolge. Die Spalteninforma­tion
ist in dem Attribut sort, die Reihenfolge der
Sortierung in dem Attribut ascending abge­
legt. Die eigentliche Sortierung erfolgt immer
dann, wenn die Liste der Autos herausgege­
ben wird.
package de.ordix.myfaces.examples.example1;
import
import
import
import
import
java.io.Serializable;
java.util.ArrayList;
java.util.Collections;
java.util.Comparator;
java.util.List;
import javax.faces.event.ActionEvent;
public class PagedSort implements Serializable{
private List<Car> cars= null;
private boolean ascending;
private String sort; public List<Car> getCars() {
Comparator comparator
= new PagedSortComparator(sort, ascending);
Collections.sort(cars, comparator);
return cars;
}
public void setCars(List<Car> list) {
for(Car car : list) {
if (this.cars.contains(car)) {
cars.remove(car);
cars.add(car);
}
}
}
public void setAscending(boolean ascending) {
this.ascending = ascending;
}
}
public void setSort(String sort) {
if (this.sort.equals(sort)) {
this.ascending = !this.ascending;
}
this.sort = sort;
}
Abb. 3: Schnittstellen-Methoden der Managed Bean zur Java Server Page.
In Abbildung 3 sind die Schnittstellen-Metho­
den zur Java Server Page abgedruckt.
Die Verarbeitung der eingegebenen Daten er­
folgt über die Methode setCars. Diese Me­
thode wird nach jedem Request aufgerufen.
Die übergebene Liste enthält den Ausschnitt
der Daten, der auf der Seite dargestellt und ge­
gebenenfalls editiert wurde. Ob die Daten vom
Benutzer verändert wurden, kann in der Metho­
de setCars durch einen Vergleich der Objek­
te ermittelt werden. Im Listing werden die über­
gebenen Informationen einfach als neue Ob­
jekte in die Bestandsliste eingefügt. Die alten
Elemente werden gelöscht.
Dieser Komfort bei der Programmierung edi­
tierbarer Listen ist in JavaServer Faces Im­
plementierungen verbreitet. Zu diesem Zweck
werden Objekte, die für die interne Repräsen­
tation des Dialogs verwendet werden, serveroder client-seitig gespeichert, um nach dem
Request wieder rekonstruiert zu werden.
Da die Programmierung einer sortierbaren Ta­
belle mit Eingabefeldern zum Standardreper­
toire einer Web-Anwendung gehört, ist die Fra­
ge nach dem Realisierungsaufwand berechtigt.
Innerhalb von wenigen Personenstunden ist so
eine Tabelle zu erstellen und mit Leben zu fül­
ORDIX News 1/2007
Abb. 4: Ein Baum als Menü.
len. Aufgrund der klaren Struktur ist der Wartungsaufwand bedeu­
tend geringer als bei einer typischen Web-Anwendung mit Struts.
Die Professionelle Auswahl – der Baum
Neben den vielen Bedienelementen, die Tomahawk anbietet, ist
die Darstellung der Baumstruktur, wie man sie beispielsweise aus
dem Explorer kennt, besonders gelungen (siehe Abbildung 4). Der
Baum verfügt über die übliche Funktionalität: Äste können aus- und
eingeklappt werden. In der Regel wird durch das Anklicken eines
„Blattes“ die Auswahl getroffen.
Java/J(2)EE
<f:view>
<span style="font-family:verdana">
<b>Tree2 w/client-side (default) toggle</b><br/>
</span>
<br/>
<h:form id="foo">
<t:tree2 id="clientTree" value="#{treeBacker.treeData}" var="node" varNodeToggler="t">
<f:facet name="person">
<h:panelGroup>
<f:facet name="expand">
<t:graphicImagevalue="images/yellow-folder-open.png"
rendered="#{t.nodeExpanded}" border="0"/>
</f:facet>
<f:facet name="collapse">
<t:graphicImagevalue="images/yellow-folder-closed.png"
rendered="#{!t.nodeExpanded}" border="0"/>
</f:facet>
<h:outputText value="#{node.description}" styleClass="nodeFolder"/>
</h:panelGroup>
</f:facet>
...
<f:facet name="document">
<h:panelGroup>
<h:commandLink
immediate="true"
styleClass="#{t.nodeSelected ? 'documentSelected':'document'}"
actionListener="#{node.selected}">
<t:graphicImage value="images/document.png" border="0"/>
<h:outputText value="#{node.description}"/>
<f:param name="docNum" value="#{node.identifier}"/>
</h:commandLink>
</h:panelGroup>
</f:facet>
</t:tree2>
</f:view>
Abb. 5: Java Server Page zur Darstellung eines Baums.
Bei der Realisierung kann die Grundfunktionalität des Auf- und Zu­
klappens der Äste entweder mit JavaScript oder durch den Server er­
folgen. Reizvoll an der JavaScript-Möglichkeit ist, dass nach der Be­
nutzeraktivität kein Request ausgelöst wird: Beim Auf- oder Zuklap­
pen wird das Bild nicht neu aufgebaut. Die JavaScript-Variante wird
daher auch standardmäßig verwendet.
Die Realisierung des Baums sollte mit dem Element tree2 erfol­
gen. Dieses bietet die Möglichkeit, unterschiedliche Knotentypen in
unterschiedlicher Darstellung zu definieren. Ein Ausschnitt der Ja­
va Server Page ist in Abbildung 5 dargestellt.
Zur Darstellung wird dem Element tree2 durch das value-Attri­
but die Methode mitgeteilt, die eine Baumstruktur zurückliefert. Die
Variable, über die der einzelne Knoten verfügbar gemacht wird, ist
als Attribut var mit node definiert worden.
Beim tree2-Element erfolgt darauf für jeden Knotentyp die Defini­
tion der Darstellung. Als Typ sind in Abbildung 5 person und document dargestellt. Der Knotentyp document ist in dem Beispiel
ein Blatt. An ihm hängen keine weiteren Knoten. Wird dieser Kno­
tentyp ausgewählt, so erfolgt normalerweise eine Aktion. Die Aktion
wird mit einfachen JSF-Mitteln getriggert. Um die Darstellung wird
ein commandLink-Element gelegt. Das Attribut actionListener
definiert die auszuführende Methode.
Definition des Baums
Der Baum wird durch eine Managed Bean erstellt. Abbildung 6 zeigt
Ausschnitte aus der Methode getTreeData, die in der Java Ser­
ver Page zur Ermittlung der Baumstruktur aufgerufen wird.
Wesentlich dabei ist, dass diese Methode ein
Objekt vom Typ TreeNode zurückgibt. Ver­
wendet werden für die einzelnen Knoten Ob­
jekte vom Typ MyTreeNodeBase. Diese in­
dividualisierten Knoten haben den einzigen
Zweck, auf die Auswahl des Benutzers zu rea­
gieren. Die Methode selected kann als ActionListener verwendet werden. Auf diese
Weise kann direkt bei einem Knoten Funktio­
nalität hinterlegt werden.
Die Implementierung eines Baumes in eine
Web-Anwendung mit Tomahawk stellt somit
eine komfortable Lösung dar. Die Trennung
von Darstellung und Funktionalität ist gelun­
gen. Die Entwicklung wird gut unterstützt und
der Code ist nachvollziehbar.
Es ist nicht alles Gold, was glänzt
Die Liste der Bedienelemente, über die der Ent­
wickler dank Tomahawk verfügt, ist beachtlich.
Aufgrund des Umfangs sei hier nochmals auf
[2] verwiesen, wo man sich über Aussehen und
Handhabung unmittelbar informieren kann.
Neben der beeindruckenden Präsentation der
Möglichkeiten darf jedoch nicht unerwähnt blei­
ben, was zunächst nicht offensichtlich ist. Be­
reits nach kurzer Zeit wird der potentielle Toma­
hawk-Anwender feststellen, dass Informationen
ORDIX News 1/2007
Java/J(2)EE
public TreeNode getTreeData()
{
TreeNode treeData = new MyTreeNodeBase("foo-folder", "Inbox", false);
// construct a set of fake data (normally your data would come from a database)
// populate Frank‘s portion of the tree
MyTreeNodeBase personNode = new MyTreeNodeBase("person", "Frank Foo", false);
personNode.getChildren().add(new MyTreeNodeBase("foo-folder", "Requires Foo", false));
...
folderNode.getChildren().add(new MyTreeNodeBase("document", "J010002", true));
folderNode.getChildren().add(new MyTreeNodeBase("document", "J030047", true));
folderNode.getChildren().add(new MyTreeNodeBase("document", "F030112", true));
personNode.getChildren().add(folderNode);
treeData.getChildren().add(personNode);
}
return treeData;
package de.ordix.myfaces.examples.example1;
import javax.faces.event.ActionEvent;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.myfaces.custom.tree2.TreeNodeBase;
public class MyTreeNodeBase extends TreeNodeBase {
private static Log logger = LogFactory.getLog(MyTreeNodeBase.class);
public MyTreeNodeBase(String arg0, String arg1, boolean arg2) {
super(arg0, arg1, arg2);
}
public void selected(ActionEvent actionEvent) {
logger.info(super.getIdentifier() + " wurde ausgewaehlt");
logger.info(super.getDescription() + " wurde ausgewaehlt");
logger.info(super.getType() + " wurde ausgewaehlt");
}
}
Abb. 6: Definition der Baumstruktur in der Managed Bean.
rar sind. Der Informationsmangel ist bereits auf
der Homepage von MyFaces [1] unübersehbar:
Beschreibungen sind nur in Ansätzen verfüg­
bar, Verweise zum Download des Beispiel-Pa­
kets [5] oder zu den zugehörigen Quellen [6]
fehlen gänzlich.
Das wäre zu verschmerzen, wenn instruktive
Informationen im JavaDoc oder gar ein Tu­torial
zur Verfügung stünden. Da beides nicht der
Fall ist, ist der Quellcode unverzichtbar. Die Ent­
wicklergemeinde ist nicht so groß, dass konkre­
te Fragen durch eine Internet-Recherche be­
antwortet würden.
Quellenverzeichnis
► [1] MyFaces HomePage: http://myfaces.apache.org/
► [2] Beispielsammlung der Möglichkeiten von MyFaces
Tomahawk: http://www.irian.at/myfaces.jsf
► [3] Quellcode der Beispiele zu MyFaces Tomahawk:
►
►
►
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/examp­
les/simple/src/main/java/org/apache/myfaces/examples/
[4] Einführungsartikel zu JavaServer Faces in der ORDIX News
2/2006: http://www.ordix.de/ORDIXNews/2_2006/JavaXML/Java­
ServerFaces.html
[5] Download des binary Example-Pakets:
http://www.apache.org/dyn/closer.cgi/myfaces/binaries/myfaces1.1.1-examples.tar.gz
[6] Sourcen der Beispiele in ganzer Länge: http://www.ordix.de/
ORDIXNews/1_2007/Java_J2EE/jsf_myfaces_tomahawk.html
[7] Deutschsprachiges Wikipedia von MyFaces:
http://de.wikipedia.org/wiki/Apache_MyFaces
Dennoch ist der Reiz der Möglichkeiten durch
Tomahawk und JavaServer Faces groß: Der
Produktivitätsschub gegenüber dem Frame­
work Struts ist leicht ersichtlich. Der Aufwand
für die Einarbeitung in JavaServer Faces und
Tomahawk ist bei der Planung zu berücksich­
tigen.
►
Den Einstieg in die Entwicklung von Web-An­
wendungen können wir Ihnen erleichtern: Zum
Thema JavaServer Faces bietet ORDIX einen
5-tägigen Workshop an. Die Inhalte des Work­
shops finden Sie online im ORDIX Trainings­
shop unter http://training.ordix.de.
JavaSer- Java-Komponente einer Web-Anwendung, die durch den
ver Pages J2EE-Standard definiert ist. Eine JSP ähnelt vom Aufbau
einer HTML-Seite mit integriertem Java-Code. Sie wird
zuerst vom Web-Container in ein Servlet kompiliert. An­
schließend nimmt das Servlet Client-Anfragen in Form
eines HTTP-Requests entgegen und generiert dynamisch
eine Antwort, die es über einen HTTP-Response an den
Client zurückschickt.
Dr. Stefan Koch ([email protected]).
ORDIX News 1/2007
Glossar
JSF
JavaServer Faces ist ein standardisiertes Framework zur
Entwicklung von Web-Anwendungen.
Aktuelles – Titelthema
Happy Birthday to You, Happy Birthday to You ...
Jubiläum: 15 Jahre ORDIX News
Seit 15 Jahren und 245.000 Exemplaren leistet ORDIX konsequenten Wissenstransfer – analog zur Unternehmensphilosophie geben wir unser Know-how über das IT-Kundenmagazin „ORDIX News“ an die Leser weiter.
„Ich fand das Larry Paket eine nette
Idee. Außerdem habe ich mich riesig gefreut, dass ich irgendwie auf Ihrem Verteiler für die Ordix News gelandet bin. Bisher musste ich immer eine Kopie von den Kollegen „klauen“.
Jetzt habe ich meine eigene. Irgendwie trifft das Magazin genau meine
Interessen.“
Stephan Neuhäuser, Mewa Textil Service
AG & Co. Management OHG, Wiesbaden
Know-how-Transfer hausgemacht – die Geburtsstunde der ORDIX News
„Wissen ist nicht um des Wissens Willen wertvoll. Es wird immer erst dann wert­
voll, wenn man es an andere weitergibt und anwenden kann. Auf dieser Philosophie
fußt das Unternehmenskonzept der ORDIX AG als IT-Dienstleister. Dieses Konzept
war der Grundstein für das heutige IT-Magazin ORDIX News“, so Wolfgang Kögler,
Gründer des Unternehmens.
Mit diesem Anliegen wurde die allererste ORDIX News „geboren“. Sie war damals
noch als Lose-Blatt-Sammlung konzipiert und erschien in einer Auflage von 50 - 150
Stück, je nach Bedarf. Die ersten Exemplare wurden vom Firmengründer Kögler und
seinem Team noch eigenhändig zusammengetackert, kuvertiert und verschickt.
Die Resonanz auf das IT-Magazin
war nach seiner Einführung in den
Markt so überwältigend, dass man im Hause ORDIX sehr bald be­
schloss, die ORDIX News zu einem eigen­ständigen Projekt zu de­
klarieren und mit höchs­tem Engagement weiterzuentwickeln.
Längst ist die ORDIX News ihren Kinderschu­hen entwachsen: Von
den ersten Druck­ex­em­plaren mit einer Auflage von 500 Stück hat
sich der Verteiler inzwischen vervielfacht – das sind heute über 9.000
Exemplare pro Ausgabe (siehe Ab­bildung 2)! Dabei wurde nicht nur
die Auflage erhöht: Auch Optik und Qualität wandelten sich im Laufe
der Zeit, um immer höheren Maßstäben gerecht zu werden.
Mai/93
► Auflage:
500 (1993)
ORDIX SOFTWARE GMBH
► Aufmachung:
Neue Mitarbeiter
GUUG '94
www.ordix.de
Seite 32
Seite
DB-Administration
f. ORACLE & INFORMIX
YARD-SQL
Seite 11
ORDIX News
„Lose-BlattSammlung“.
Seite 13
Ausgabe 1/2007
` 2,20
Das IT-Magazin der ORDIX AG
► Auflage:
9.000 (2007)
► Aufmachung:
re
Jah ws
15 DIX Ne
OR
Jubiläum: 15 Jahre ORDIX News
ZFS – das ultimative Dateisystem
DB2 UDB 9.1 (Teil I): Codename „Viper“
Vorstellung des neuen Solaris 10 Features S. 34
Neuerungen des IBM DB2 Datenbankservers S. 37
EJB 3.0 (Teil II): Keep it simple
IBM IDS 10.0 (Teil IV): A Success Story
Implementierungsdetails von Session Beans
unter Nutzung von EJB 3.0 Annotations S. 48
10
S. 1
10
Verwendung und Umgang mit den Neuerungen
für den IDS 10.0 S. 30
ORDIX News 4/2006
„Vierfarbdruck“.
ORDIX News Top-Stars
Die Hitliste der beliebtesten
ORDIX News Ar­tikel wird heu­
te von dem viel gelesenen Edi­
torial von Wolfgang Kögler an­
geführt. Dicht gefolgt von „Kol­
lege“ Larry Rat­los, der immer
wie­der bei kniffeligen IT-Pro­
blemen um Ihre Hilfe bittet.
„Bei der Zusammenstellung der
Fachbeiträge achten wir beson­
ders auf die Praxisrelevanz. Da­
rüber hinaus möchten wir nicht
nur die techni­sche Leserschaft be­dienen, son­
dern bringen mit der Aufnahme des Geschäfts­
feldes Projektmanagement nun zunehmend
auch Artikel, die die Management-Ebene ad­
ressieren,“ so Helma Jenniches, ORDIX News
Redaktion.
Kleine „Helferlein“
Die Redaktion achtet natürlich darauf, den Le­
sern in jeder Ausgabe einen ausgewogenen
Mix aus den verschiedenen Rubriken zu prä­
sentieren.
Um den Nutzen des Magazins weiter zu opti­
mieren, wurden Navigationshilfen eingebaut,
damit der Leser sein Interessensgebiet mög­
lichst schnell und zielgenau findet (siehe Ab­
bildung 1).
Zukunftsmusik
Die ORDIX News Redaktion wird selbstverständ­
lich weiterhin an dem über die Jahre bewährten
Grundprinzip des Wissenstransfers festhalten.
Das heißt für Sie: Auch in Zukunft präsentieren
wir Ihnen informative und praxisrelevante Arti­
kel aus der IT-Welt.
ORDIX News 1/2007
Aktuelles
Titelthemen
Die Artikel der Titelseite sind im Inhaltsverzeichnis und in der Kopfzeile jeweils als „Titelthema“ gekennzeichnet.
Dadurch muss der Leser nicht lange suchen.
Zielgruppe
Anhand der Zielgruppen-Angabe kann der Leser nun bereits nach wenigen Zeilen entscheiden, ob der Artikel von
Interesse ist oder nicht.
Farbliche
Um beim Durchblättern schneller die für den Leser relevanten Themen zu finden, sind die verschiedenen Rubriken
Abgrenzung farbig gekennzeichnet und mit verschiedenfarbigen Icons versehen, was die Navigation vereinfacht. So sind alle
Datenbank-Artikel z. B. in den Abbildungen und Tabellen grün markiert.
und Icons
Glossar
Das Glossar erklärt Fachbegriffe für die, denen der Fachjargon nicht so geläufig ist. Das Glossar finden Sie auch im In­
ternet unter http://www.ordix.de, wo es ständig erweitert wird und somit zu einem IT-„Fachlexikon“ heranwächst.
Links
Die Links geben Hinweise auf Zusatzinformationen von anderen Webseiten oder additive Literatur. Dort lässt sich
das Wissen dann nochmals vertiefen.
Über Ihre neuen Ideen, Anregungen, Kritik und
Lob freut sich das Redaktionsteam weiterhin
unter [email protected].
Wir danken Ihnen für 15 Jahre Lesertreue!
Auflage
Abb. 1: Komfortable Navigations- und
Orientierungshilfen in der ORDIX News.
10000
9000
8000
7000
6000
5000
4000
3000
2000
1000
0
1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007
Die Redaktion
Jahre
Abb. 2: Auflagenentwicklung der ORDIX News von 1996 bis 2006.
Larry Ratlos
Datenbankblöcke optimal füllen
Nach der Völlerei, die Weihnachten immer so mit sich bringt, kommt jetzt die Zeit, die guten Vorsätze für
das neue Jahr einzuhalten. Privat hat Larry sich vorgenommen, beim Essen auf die Bremse zu treten. Beruflich hat er sich auch vorgenommen, an einigen Stellen zu sparen: Beim Thema Speicherplatz gilt bei Larry
ab sofort und verstärkt das Motto „Geiz ist geil“! Natürlich darf unter diesem Vorsatz niemals die Qualität leiden. Diese beiden Vorhaben miteinander zu verknüpfen, ist die Herausforderung beim Datenbank-Layout.
Larry hat in seiner Oracle Datenbank eine In­
dex Organized Table angelegt. Diese befüllt er
mit einem SELECT. Um sofort eine optimale
Befüllung zu erreichen und Speicherplatz zu
sparen, füllt er die Tabelle mit
INSERT INTO iot
SELECT ...
FROM basis
ORDER BY <primary key>
Leider stellt er fest, dass die Befüllung der Blö­
cke nicht optimal ist. Er könnte die Tabelle reor­
ganisieren, aber es müsste doch auch einen
einfacheren Weg geben?!
Können Sie Larry helfen?
Was muss Larry tun, um die Befüllung der Blö­
cke optimal zu gestalten? Hat er vielleicht schon
ORDIX News 1/2007
beim Befüllen einen Fehler gemacht? Eine Reorganisation der
Tabelle möchte er jedenfalls gerne vermeiden.
Kennen Sie des Rätsels Lösung? Dann senden Sie Ihren Vorschlag
bis zum 24. Februar 2007 an [email protected]. Selbstverständlich
werden die schnellsten und besten „Sparfüchse“ wieder belohnt.
Lösung der Aufgabe 3/2006
Im Herbst hatte Larry seine liebe Mühe mit einem Verzeichnis, auf
das zwar alle Kollegen Vollzugriff bekommen sollten, bei dem aber
verhindert werden sollte, dass ein Kollege Daten von einem ande­
ren Kollegen löschen kann.
Bei den Vorschlägen waren unsere Leser sich im Wesentlichen ei­
nig. Darum hat Larry für dieses Verzeichnis mit ‚chmod 1777 /usr/
local/cgi-bin‘ jetzt das Sticky-Bit gesetzt. Das bewirkt, dass zwar
alle Kollegen dort Dateien anlegen, aber nicht versehentlich die
Dateien anderer überschreiben bzw. löschen können.
11
Datenbanken
Datenkompression unter Oracle (Teil II):
Komprimierung von
Index Organized Tables
Indexorganisierte Tabellen stehen seit der Oracle Version 8 zur Verfügung. Auch diese Tabellen können komprimiert werden. Jedoch kann bei den indexorganisierten Tabellen das im Teil I dieser Reihe (siehe ORDIX
News 3/2006, Seite 24) vorgestellte Verfahren der DATA SEGMENT COMPRESSION nicht verwendet werden.
Dieser Artikel gibt einen Überblick über den Einsatz der indexorganisierten Tabellen und darüber, wie sie
durch KEY COMPRESSION dennoch komprimiert werden können.
Zielgruppe dieses Artikels sind Datenbankadministratoren und
Entwickler, die sich in Data Warehouse Umgebungen mit der
komprimierten Speicherung von Daten beschäftigen.
In Oracle Umgebungen werden überwiegend normale Tabellen
(ORGANIZATION HEAP) mit Indizes zur Zugriffsoptimierung ver­
wendet. Aus Gründen der Speicherkapazitäten und Zugriffszeiten
kann aber auch der Einsatz von indexorganisierten Tabellen (IOT)
in normaler bzw. komprimierter Form in Betracht gezogen werden.
Dies ist nichts völlig neues, denn schon mit Oracle Version 8 wur­
den Indizes, IOT und KEY COMPRESSION eingeführt.
Um einen Überblick über den Einsatz der indexorganisierten Tabel­
len zu bekommen, stellen wir zunächst den Aufbau und die Kon­
figurationsmöglichkeiten einer IOT vor.
In einer IOT gibt es kein Datensegment. Der
verwendete Platz liegt also ausschließlich in
Form eines Indizes vor. Im Unterschied zu ei­
nem Index gibt es in den Leaf-Blöcken jedoch
keine Zeiger, sondern dort werden die Daten­
sätze selbst gespeichert und zwar sortiert nach
den Kriterien des PRIMARY KEY.
Weiterhin erläutern wir die Kompression unter Verwendung der
Option COMPRESS. Anschließend vermitteln einige Beispiele aus
einem aktuellen Projekt einen ersten Eindruck von der möglichen,
zu realisierenden Platzersparnis und zeigen die Auswirkungen auf
die Performance auf.
Eine IOT bietet sich immer dann an, wenn die
Spalten des PRIMARY KEY einen wesentlichen
Anteil am gesamten Datensatz ausmachen.
Dann ist in vielen Fällen schon alleine durch
die Verwendung einer IOT eine Platz­ersparnis
gegenüber der Verwendung einer normalen Ta­
belle mit Index zu erwarten.
Was unterscheidet eine IOT von einer normalen Tabelle?
Wie wird eine IOT angelegt?
In Abbildung 1 sind die wesentlichen Unterschiede zwischen einer
normalen Tabelle mit Index - das kann z. B. der PRIMARY KEY
sein - und einer IOT dargestellt. Die normale Tabelle besteht zu­
nächst einmal aus dem Datensegment, in dem die Datensätze nor­
malerweise in unsortierter Reihenfolge vorliegen.
Das Anlegen einer IOT unterscheidet sich in
zwei Punkten von einer normalen Tabelle.
Normale Tabelle mit Index
Indexorganisierte Tabelle
Index-Segment
Index-Segment
Root
Branch
L ROWID
L ROWID
L ROWID
Daten
Daten
Daten
L ROWID
L ROWID
L ROWID
Branch
L ROWID
L ROWID
L ROWID
Daten-Segment
Daten
Daten
Daten
Root
Daten
Daten
Daten
L ROWID
L ROWID
L ROWID
Branch
Daten
Daten
Daten
Daten
Daten
Daten
Branch
Daten
Daten
Daten
Daten
Daten
Daten
Daten
Daten
Daten
Abb. 1: Vergleich des Aufbaus einer normalen Tabelle mit Index und
dem einer IOT.
12
Im dazugehörigen Index-Segment liegen die In­
dex-Blöcke. Auf der untersten Ebene enthalten
die Leaf-Blöcke zu allen Datensätzen je einen
Index-Eintrag zusammen mit der ROWID als
Zeiger auf den entsprechenden Datensatz (in
Abbildung 1 mit „L ROWID“ gekennzeichnet).
1. Die Option ORGANIZATION INDEX muss
angegeben werden.
2. Ein PRIMARY KEY ist zwingend notwen­
dig, da er das Ordnungskriterium für die
Datensätze ist.
Der PRIMARY KEY einer IOT sollte aus Grün­
den der Übersichtlichkeit, wie in Abbildung 2
dargestellt, einen Namen erhalten, der die Zu­
gehörigkeit zu der entsprechenden Tabelle
kennzeichnet.
Wie arbeitet die KEY COMPRESSION?
Die KEY COMPRESSION ist das Kompressi­
onsverfahren für Indizes. Sie kann somit auch
ORDIX News 1/2007
Datenbanken
bei indexorganisierten Tabellen eingesetzt wer­
den und findet ausschließlich in den Leaf-Blöc­
ken statt. Die Arbeitsweise soll am Beispiel ei­
nes zusammengesetzten Indizes, der hier der
PRIMARY KEY einer IOT ist, näher beleuch­
tet werden (siehe Abbildung 3).
In der normalen Form, wie auf der linken Sei­
te dargestellt, werden die vollständigen Daten­
sätze gespeichert. Bei Verwendung der KEY
COMPRESSION werden die Spalten des In­
dizes (in Abbildung 3 grün dargestellt) aufge­
teilt in PREFIX und SUFFIX.
Zum PREFIX zählen im dargestellten Beispiel
die ersten beiden Spalten. Das sind die Teile
des Indizes, die nicht eindeutig sind. Das SUF­
FIX bilden die restlichen Spalten des Indizes
bzw. im Fall der IOT alle restlichen Spalten.
In der komprimierten Form, dargestellt auf der
rechten Seite, werden PREFIX und SUFFIX
getrennt behandelt. In einem Block werden die
SUFFIX-Einträge zu allen Datensätzen, aber
nur alle unterschiedlichen PREFIX-Einträge
gespeichert. Daraus ergibt sich die Platzer­
sparnis. In dem Beispiel sind also die 1. und
6. Zeile von unten die PREFIX-Einträge und
die restlichen sind SUFFIX-Einträge. In kom­
primierter Form werden somit ca. 30 Prozent
des Speicherplatzes eingespart.
Folgende Eigenschaften der Verwendung einer
IOT mit KEY COMPRESSION sind identisch
mit der DATA SEGMENT COMPRESSION bei
normalen Tabellen:
• In einem Leaf-Block einer IOT steckt die
vollständige Information über alle in die­
sem Block enthaltenen Datensätze. Für
einen Zugriff auf die Daten sind keine wei­
teren Informationen notwendig.
• 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 werden insge­
samt weniger Blöcke benötigt und die I/OLast sinkt.
• 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.
Bei der KEY COMPRESSION gibt es jedoch
nicht die Einschränkung auf Blockoperationen
wie bei der DATA SEGMENT COMPRESSION.
Sie wird also bei jeder einzelnen Einfügeope­
ration angewendet.
ORDIX News 1/2007
Wesentlichen Eigenschaften einer IOT
• Die IOT besteht nur aus einem Index-Segment. Das Da­
•
•
•
•
tensegment einer normalen Tabelle entfällt.
Ein PRIMARY KEY ist zwingend notwendig, da die Datensät­
ze physikalisch nach dem PRIMARY KEY sortiert werden.
Es können zusätzliche Indizes angelegt werden.
Eine IOT kann partitioniert werden, wobei das Partitionie­
rungskriterium Bestandteil des PRIMARY KEY sein muss.
Eine IOT kann mit der KEY COMPRESSION komprimiert
werden.
-- Anlegen einer IOT
CREATE TABLE io_tab
( Stadt
VARCHAR2(50),
Strasse
VARCHAR2(100),
Hausnr
VARCHAR2(10),
Eigentuemer VARCHAR2(50),
CONSTRAINT PK_IO_TAB PRIMARY KEY( Stadt, Strasse, Hausnr )
)
ORGANIZATION INDEX
;
Abb. 2: Anlegen einer IOT.
Indexorganisierte Tabelle
12
Duisburg
10
Duisburg
21
Dortmund
11
Dortmund
1b
Dortmund
1a
Dortmund
Leaf-Block
Komprimierte
indexorganisierte Tabelle
Leaf-Block
Kubilick
Brueckstrasse
Hansmann
Brueckstrasse
Zwiekala
Auf dem Toren
Oberhoff
Auf dem Toren
Huelshof
Auf dem Toren
Beckmann
Auf dem Toren
12
10
Duisburg
21
11
1b
1a
Dortmund
Kubilick
Hansmann
Brueckstrasse
Zwiekala
Oberhoff
Huelshof
Beckmann
Auf dem Toren
Abb. 3: Prinzip der Speicherung von Daten in einer IOT links ohne
und rechts mit KEY COMPRESSION.
-- Anlegen einer komprimierten IOT
CREATE TABLE io_tab_co
( Stadt
VARCHAR2(50),
Strasse
VARCHAR2(100),
Hausnr
VARCHAR2(10),
Eigentuemer VARCHAR2(50),
CONSTRAINT PK_IO_TAB PRIMARY KEY( Stadt, Strasse, Hausnr )
)
ORGANIZATION INDEX
COMPRESS 2
;
Abb. 4: Anlegen einer komprimierten IOT.
-- Umwandeln einer bestehenden IOT
-- normal
-> komprimiert
ALTER TABLE tab_name MOVE COMPRESS 2;
-- komprimiert -> normal
ALTER TABLE tab_name MOVE NOCOMPRESS;
Abb. 5: Befehle zum Umwandeln einer bestehenden IOT.
13
Datenbanken
ANALYZE INDEX pk_iot_no_comp VALIDATE STRUCTURE;
SELECT name
opt_cmpr_count,
opt_cmpr_pctsave,
FROM index_stats;
NAME OPT_CMPR_COUNT OPT_CMPR_PCTSAVE -------------- -------------- -----------------PK_IOT_NO_COMP 2 59 Abb. 6: Befehle zur Ermittlung der Platzersparnis bei der Kompres­
sion einer bestehenden IOT.
IOT_NO_COMP
IOT_COMP
Anzahl Zeilen
6573215
6573215
Anzahl Blöcke
67072
26624
INSERT INTO ...
234 Sekunden
219 Sekunden
1. SELECT Anzahl (alle)
28 Sekunden
13 Sekunden
2. SELECT Anzahl (alle)
6 Sekunden
4 Sekunden
1. SELECT doppelte Gruppierung
62 Sekunden
31 Sekunden
2. SELECT doppelte Gruppierung
16 Sekunden
15 Sekunden
Abb. 7: Beispiel für die Auswirkungen der KEY COMPRESSION auf
die Größe, das Einfügen von Daten und typische Abfragen.
Wie wird die KEY COMPRESSION eingerichtet?
Um eine komprimierte IOT zu erstellen, wird beim Anlegen die Op­
tion COMPRESS angegeben (siehe Abbildung 4). Zusätzlich kann
die Anzahl der PREFIX-Spalten (im Beispiel „2“) mitgegeben wer­
den. Die Standardeinstellung für diesen Parameter ist: Anzahl der
PRIMARY KEY Spalten – 1.
Die Eigenschaft COMPRESS ist bei einer IOT im Gegensatz zu
einer normalen Tabelle direkt mit der physikalischen Organisation
der Daten verknüpft. Daher ist eine Umschaltung der Eigenschaft
mit dem Befehl „ALTER TABLE ... COMPRESS;“ nicht möglich.
Die Umwandlung einer bestehenden IOT erfolgt mit dem Befehl
„ALTER TABLE ... MOVE;“ (siehe Abbildung 5).
Bei der Ausführung wird eine neue IOT mit der angegebenen Ei­
genschaft COMPRESS bzw. NOCOMPRESS angelegt. Danach
erfolgt das Einfügen der Daten, das Löschen der alten IOT und
das Umbenennen der neuen IOT.
Was bringt die KEY COMPRESSION?
Die Auswirkungen der KEY COMPRESSION bei einer IOT hän­
gen natürlich stark von der jeweiligen Tabelle ab. Allerdings kann
man im Allgemeinen schon sagen, dass sich bei einem zusammen­
gesetzten PRIMARY KEY der Einsatz einer Kompression wahr­
scheinlich lohnen wird.
Im Einzelfall kann man vorab mit den in Abbildung 6 aufgeführten
Befehlen ermitteln, wie groß die Platzersparnis in % (OPT_CMPR_
PCTSAVE) sein wird und welches der optimale Parameter (OPT_
CMPR_COUNT) für die Kompression wäre.
14
Die ermittelten Werte für die Platzersparnis
sind in der Regel sehr zuverlässig. Eine Aus­
nahme ist die Version 9.2.0.4: Durch einen
Fehler werden für die Platzersparnis bei Ta­
bellen mit mehr als ca. 500.000 Zeilen unsin­
nige Werte angezeigt. Hier kann man sich nur
mit einer Teilkopie behelfen, die eine geringe­
re Anzahl beinhaltet.
Beispiel aus einem aktuellen Kundenprojekt
Abbildung 7 zeigt einige Analyseergebnisse
aus einem aktuellen Projekt. Die Analyse zeigt,
dass sich die im Beispiel verwendete Tabelle
gut für eine KEY COMPRESSION eignet. Die
ersten Spalten des zusammengesetzten PRI­
MARY KEY sind nicht eindeutig und machen
über 50 Prozent der Zeilenlänge aus.
Welche Auswirkungen hat die
Kompression der Beispieltabelle?
Das Einfügen von Daten in eine komprimier­
te IOT unterscheidet sich nur wenig von den
Vorgängen ohne Kompression. Es bringt kei­
ne wesentliche, zusätzliche CPU-Last mit sich.
Beim Einfügen von Massendaten kann durch
die Platzersparnis durchaus eine Verkürzung
der Zeiten erzielt werden.
Für typische Abfragen sind in der Tabelle Aus­
führungszeiten für folgende Fälle angegeben:
1. für den Fall, dass die Daten vollständig
von der Platte geladen werden müssen
2. für den Fall, dass sich die Daten schon
im Puffer befinden.
Bei den ersten Zugriffen spielt das geringere Da­
tenvolumen durch die Kompression die entschei­
dende Rolle. Wenn die Daten schon im Puffer lie­
gen, sind die Unterschiede deutlich geringer.
Kleiner Knigge zum Umgang mit
indexorganisierten Tabellen
Bei der Verwendung einer IOT sollte man im­
mer im Hinterkopf behalten, dass es sich bei
diesem Objekt unabhängig von der Verwen­
dung der Kompression um einen Index han­
delt. Im Folgenden sind einige Punkte zusam­
mengetragen, die im Umgang mit indexorga­
nisierten Tabellen zu beachten sind:
• Informationen über die physikalischen Ei­
genschaften einer IOT (Größe, Partitionen
usw.) findet man im Data Dictionary über
den Namen des PRIMARY KEY. Daher ist
es sinnvoll einen aussagekräftigen Namen
zu vergeben.
ORDIX News 1/2007
Datenbanken
Links
► Präsentationen zu verschiedenen Themen, wie z. B. Index und IOT:
http://julian.dyke.users.btopenworld.com/com/Presentations/Presentations.html
► Index Organized Tables, Oracle Whitepaper 2001:
http://www.oracle.com/technology/products/oracle9i/pdf/iot_twp.pdf
• Die Änderung der physikalischen Eigen­
schaften einer IOT erfolgt immer über die
Tabelle. Ein REBUILD des PRIMARY KEY
ist nicht möglich. Aber mit dem Befehl „AL­
TER TABLE ... MOVE;“, der auch mit der
Option ONLINE ausgeführt werden kann,
wird die Tabelle und damit auch der PRI­
MARY KEY neu aufgebaut.
• Beim Einfügen von Massendaten sollte man
auf die richtige Sortierung der Daten achten.
In sortierter Form (NLS_SORT = BINARY)
werden alle Blöcke praktisch vollständig ge­
füllt. Bei nicht sortierten Daten erhält man
sehr viele, nur halbgefüllte Blöcke.
• Beim nachträglichen Einfügen von einzel­
nen Datensätzen in eine optimal organisier­
te IOT entstehen halbgefüllte Blöcke. Wie
bei einem Index führt das mit der Zeit zu ei­
ner schlechten Speicherplatzausnutzung.
Fazit
Die KEY COMPRESSION ist gegenüber der
DATA SEGMENT COMPRESSION wesent­
Glossar
Block
Physikalische Speichereinheit von Oracle Datenbanken.
PRIMARY
KEY
Eindeutiger Schlüssel für die Datensätze einer Tabelle.
Index
organized
Tables
(IOT)
„Normale“ Tabellen speichern Daten und Index Informa­
tionen in unterschiedlichen Segmenten. Dabei werden in
den Indexsegmenten Zeiger auf die eigentlichen Daten
gehalten. Bei IOT gibt es keine Datensegmente, die In­
dizes beinhalten auch die Dateninformationen.
Segment
Bezeichnung für die logische Struk­tur in Oracle Da­ten­
banken für alle Datenblöcke eines Objekts (Tabelle, In­
dex, ...).
lich einfacher zu handhaben. Ob man sie bei einer indexorganisier­
ten Tabelle einsetzt, hängt eigentlich ausschließlich von dem Platz­
gewinn ab, den man durch eine Kompression erzielen kann. Über
den Platzgewinn kann man sich vorab durch eine Analyse der Da­
ten informieren. Die Verwendung einer IOT mit Kompression un­
terscheidet sich praktisch nicht von der Verwendung einer IOT oh­
ne Kompression.
Dr. Klaus Uebelgünn ([email protected]).
ORDIX Ausbildung
Dem Nachwuchs eine Chance
Die ORDIX AG übernimmt 80 Prozent ihrer Auszubildenden und Praktikanten.
Eine Ausbildungsquote von knapp elf Prozent?
Ein Anteil, der Bundeskanzlerin Angela Merkel
Freudentränen in die Augen zaubern würde.
Die ORDIX AG hat schon seit Jahren eine ho­
he Quote an Auszubildenden. Derzeit sind es
in Paderborn acht Praktikanten und Auszubil­
dende bei insgesamt 73 Mitarbeitern.
„ORDIX nutzt die Chance, so früh wie möglich
Einfluss auf die Kompetenz seiner Mitarbei­
ter zu nehmen,“ erläutert die Ausbildungsleite­
rin Ulrike Kögler das Personalkonzept, „denn
nur so können wir die sehr hohen Qualitätsstan­
dards gewährleisten, die unsere Kunden verlan­
gen.“
In den vergangenen 16 Jahren hat ORDIX mehr
als 40 Praktikanten und Auszubildende fit für ih­
ren Job gemacht.
ORDIX News 1/2007
Auszubildende und Praktikanten der Paderborner ORDIX AG (v. l.):
Philipp Miegel, Christian Wiesing, Lars Heger, Vanessa Prior, Tobias
Wink, Alexander Keil und Ulf Papenfuß mit ihrer Ausbildungsleiterin
Ulrike Kögler (3. v. l.). Sie haben gute Chancen auf einen Job.
15
Projektmanagement
ITIL: Einführung des
Incident Managements
Die Einführung von IT-Service Management auf Basis von ITIL beginnt in der Regel mit der Einführung einzelner Prozesse, mit denen der Grundstein für die Einführung weiterer Prozesse gelegt werden soll. Heute
setzen wir uns mit dem Prozess Incident Management auseinander, der sich besonders dafür eignet, als erstes eingeführt zu werden.
Dieser Artikel richtet sich an DV-Leiter, IT-Projektmanager, Orga­
ni­satoren und Entscheider.
erreicht. Die Rolle wird von einer Person wahr­
genommen, die auch weitere Aufgaben im Un­
ternehmen übernehmen kann.
Projekt „Einführung Incident Management“
Entscheidung
Wenn ein Unternehmen die Entscheidung fällt, ITIL-Prozesse ein­
zuführen, gibt es in der Regel handfeste Probleme mit der IT. Klas­
sische Kritikpunkte sind: „Die IT ist zu teuer“ oder „Die IT funktio­
niert nie, wenn man sie braucht“. Schnell wird klar, dass man nicht
alle Prozesse auf einmal einführen kann. Es stellt sich daher die
Frage: „Wo fangen wir an?“
Die Entscheidung wird relativ schnell getroffen, da der Kunde in der
Regel die Qualität der Services, die Häufigkeit von Störungen (In­
cidents) oder die zu langsame Behebung von Störungen bemän­
gelt. Insofern startet man sehr oft mit dem Incident Mana­ge­ment
Prozess.
Zielsetzung des Incident Managements
ITIL verfolgt mit dem Prozess Incident Management das Ziel „Er­
höhung der Kundenzufriedenheit durch schnellstmögliche Wieder­
herstellung des vereinbarten Services“. Eine Störung oder Unter­
brechung des Services wird als Incident bezeichnet. In dem Ziel
selbst tauchen mehrere Begriffe auf, die näher betrachtet werden
müssen, da sie wesentliche Anforderungen an den Prozess be­
schreiben:
• Kunde: Der Kunde ist der Nutzer des IT-Services. Sein Primär­
ziel ist sein Business. Die IT ist für ihn lediglich ein Hilfsmittel.
Der Kunde kann auch eine Abteilung der eigenen Firma sein.
• Service: ITIL definiert Service als Kombination von Produkt
und Leistung.
• Vereinbart: Die Services mit ihrer Qualität müssen in Abstim­
1.
2.
3.
4.
5.
Initialisierung
Prozessdesign
Detailausarbeitung
Einführung
Abschluss
Bei der Durchführung gibt es einige Iterations­
punkte, die ein Review enthalten und einen
Rück­sprung zu vorhergehenden Schritten er­
möglichen. Es empfiehlt sich, die Anzahl der
Iterationen direkt beim Projektstart zu begren­
zen, um eine Abgrenzung zum kontinuierlichen
Verbesserungsprozess zu erhalten. Dieser wird
innerhalb von ITIL mit Hilfe des Deming Cycles
(siehe Abbildung 1) verdeutlicht.
Phase 1: Initialisierung
In der ersten Phase werden die Projektleitung
und das Team benannt. Die Projektleitung
selbst sollte der zukünftige Incident Manager
übernehmen. Hiermit wird verhindert, dass so­
fort nach Projektende wesentliche Änderun­
gen am Prozess durchgeführt werden. Danach
wird festgelegt, für welche Kunden der Prozess
eingeführt werden soll. Man sollte hier am An­
fang lieber etwas zurückhaltender sein.
• Schnellstmögliche Wiederherstellung des Services setzt
voraus, dass man einen guten Überblick über das System mit
seinen Services und Abhängigkeiten hat, um im Incident-Fall
die richtigen Maßnahmen einzuleiten.
Für die weiteren Kunden sollte der zeitliche
Rahmen und die Art der Umsetzung definiert
werden. Neben dem Umfang sollten auch die
Ziele und die Anzahl der Iterationen bis zum
Projektende abgestimmt werden. Für die Pha­
se 2 sollten zwei bis drei Iterationen und für die
Phase 4 eine Iteration eingeplant werden.
ITIL definiert für verschiedene Aufgaben innerhalb der Prozesse
verschiedene Rollen. Eine wesentliche Rolle ist die des Incident
Managers. Er ist dafür verantwortlich, dass der Prozess das Ziel
Zu diesem Zeitpunkt muss auch der Kunde in­
formiert werden. Anforderungen des Kunden
an den Prozess sollten gegebenenfalls zusätz­
mung mit dem Kunden definiert sein.
16
Die Einführung des Prozesses sollte als Pro­
jekt mit den folgenden Phasen durchgeführt
werden:
ORDIX News 1/2007
Projektmanagement
lich aufgenommen werden. Eine gemeinsame
Planung sollte erstellt werden. Je nach Anpas­
sung der Altabläufe muss auch der Kunde sei­
ne internen Prozesse anpassen.
Reifegrad
Bevor die eigentliche Arbeit beginnt, werden
für die Detailpunkte die Bestätigung und die
Unterstützung der Geschäftsleitung benötigt.
Kontinuierlicher Verbesserungsprozess
P U
Phase 2: Prozessdesign
Im ersten Schritt dieser Phase werden die An­
forderungen des Prozesses ermittelt. Hierzu
sollten die vorhandenen Abläufe analysiert und
Hinweise der Mitarbeiter berücksichtigt wer­
den. In dieser sehr frühen Phase wird schon
die Akzeptanz des neuen Prozesses zu we­
sentlichen Teilen festgelegt. Betroffene müs­
sen zu Beteiligten werden.
Auf Basis dieser Ergebnisse und des ITIL-Pro­
zesses (siehe Abbildung 2) wird der individu­
elle Prozess gestaltet. Dazu müssen die Ein­
gangsquellen, der Ablauf, die Rollen, die Kom­
munikationswege, die Kennzahlen und die
Schnittstellen zu anderen ITIL-Prozessen de­
finiert werden. Technische und fachliche An­
forderungen an ein einzusetzendes Tool wer­
den definiert.
Eine wesentliche Eigenschaft von ITIL ist, dass
jeder Prozess seine eigene Aufgabe hat und
zur Zielerreichung und Abgrenzung Schnittstel­
len zu anderen Prozessen besitzt. Hier kom­
men wir zu einer wesentlichen Anpassung un­
seres Ziels, „EINEN einheitlichen ITIL-Prozess
einzuführen“.
Zur Realisierung der Schnittstellen müssen wei­
tere Prozesse zumindest rudimentär eingeführt
werden. Details hierzu werden wir später im Ar­
tikel betrachten.
•
•
•
•
•
Service Desk
Problem Management
Service Level Management
Change Management
Configuration Management
Am Ende dieser Phase sollte der Prozessent­
wurf mit den beteiligten Kunden und der Abtei­
lung einem Review unterzogen werden. Ge­
gebenenfalls muss diese Phase erneut durch­
laufen werden.
Phase 3: Detailausarbeitung
Die Einführung des Prozesses wird vorberei­
tet. Hierzu werden die Rollen in der eigentli­
chen Organisation vorbereitet und zum Ein­
führungsstart implementiert. Technische Vor­
ORDIX News 1/2007
P
U
R
A
A R
Planung
Umsetzung
Review
Ausführung
Zeit
Abb. 1: Deming Cycle.
First-LevelSupport
Second-LevelSupport
Third- & n-LevelSupport
Annahme und
Aufzeichnung
Erste Hilfe
gelöst ?
Störung
beseitigen
N
FehlerBearbeitung
gelöst ?
Störung
beseitigen
gelöst
N
FehlerBearbeitung
gelöst ?
N
etc.
Störung
beseitigen
Abb. 2: Incident Management Prozess.
aussetzungen werden geschaffen und die notwendigen Arbeits­
anweisungen und Checklisten erstellt. Neben den prozesseige­
nen Punkten fließen jetzt auch die initialen Informationen der an­
deren Prozesse ein. Die gesammelten Ergebnisse werden erneut
mit den beteiligten Kunden abgestimmt.
Parallel hierzu wird ein Tool beschafft, das den Anforderungen des
Prozesses gerecht wird. Falls schon ein Tool vorhanden ist und es
halbwegs den Anforderungen gerecht wird, sollte dies erst einmal
genutzt werden. Kleinere Einschränkungen sind für die ersten Mo­
nate nach der Einführung akzeptabel.
Nach Abschluss der Vorbereitungen werden die betroffenen Mitar­
beiter geschult. Die Schulung der Mitarbeiter sollte gründlich vor­
bereitet werden und nicht nur die fachlichen Aspekte betrachten,
17
Projektmanagement
Motivation
Kritische
Phase
Schnittstelle: Service Desk
Benefit
Der Service Desk stellt an sich keinen ITIL-Pro­
zess dar. Er ist aber eine unverzichtbare Funk­
tion des Incident Managements. Hierbei nimmt
er zwei wesentliche Funktionen ein:
Zeit
Abb. 3: Einführungsverlaufskurve.
sondern auch die persönlichen Belange. Mit der Einführung von
ITIL wird in der Regel ein Umdenken der Mitarbeiter notwendig:
Vom Fachmann mit einer sehr technischen Ausprägung hin zum
kundenorientierten Servicemitarbeiter. Hier müssen die Mitarbei­
ter „mitgenommen“ werden.
Phase 4: Einführung
Nachdem die Vorbereitungen abgeschlossen sind, kann die eigent­
liche Einführung des ITIL Incident Managements gestartet werden.
Mit dem Kunden wird noch einmal abgestimmt, dass er in seiner
Organisation auch den neuen Prozess vorbereitet hat. Dann steht
der Einführung nichts mehr entgegen. Hier muss man sich aber
genau über die Auswirkungen der Einführung im Klaren sein (siehe
Abbildung 3). Am Anfang wird die eigentliche Incident-Bearbeitung
schlechter laufen und aufwändiger sein als vorher. Der neue Pro­
zess muss sich noch einschwingen. Zuerst werden diese Probleme
durch den Enthusiasmus aller Beteiligten kaschiert.
Doch nach kurzer Zeit wird der Druck des Kunden größer, was sich
negativ auswirkt. Hier ist es besonders wichtig, dass die beteilig­
ten Mitarbeiter positiv von der Geschäftsführung begleitet werden.
Parallel hierzu muss der Kunde durch ein gemeinsames Review
und die Definition von Maßnahmen und Prozessanpassungen be­
teiligt werden.
Phase 5: Abschluss
Nachdem die ersten Review-Maßnahmen erfolgreich umgesetzt
sind, sollte der Prozess sich eingeschwungen haben. Das Ein­
führungsprojekt wird abgeschlossen und der Prozess an den In­
cident Manager übergeben. Der Projektverlauf wird nun bezüg­
lich des Verlaufs an sich betrachtet, um firmenspezifische Ver­
besserungspotentiale für die Einführung weiterer ITIL-Prozesse
abzuleiten. Zum Abschluss bietet es sich an, den Projekterfolg
mit der Projektgruppe und den Mitarbeitern des Incident Manage­
ments zu feiern.
Schnittstellen
In der Design-Phase haben wir gesehen, dass verschiedene Schnitt­
stellen zu weiteren Prozessen benötigt werden. Wie schon ange­
kündigt, muss man an vielen Punkten nicht sofort den kompletten
Prozess einführen. Es reicht teilweise schon aus, wenn die Pro­
zesse pro forma mit den Schnittstellen zum Incident Management
aufgesetzt werden.
18
1. Kundenschnittstelle: Der Service Desk stellt
den zentralen Anlaufpunkt des Kunden dar.
Er alleine nimmt alle Störungsmeldungen
und Anfragen entgegen. Alle Informationen
in Richtung des Kunden laufen über ihn.
2. Incident Besitzer: Alle Incidents gehören
dem Service Desk. Er stellt sicher, dass sie
gemäß den Vorgaben bearbeitet werden
und keiner vergessen wird. Gegebenen­
falls werden die notwendigen Eskalationen
angestoßen.
Wesentlicher Vorteil dieser Entkopplung ist
einerseits der Zentralismus: Mehrere gleich­
artige Störungsmeldungen werden frühzeitig
erkannt und können schneller gelöst werden.
Darüber hinaus werden die anderen Abteilun­
gen entlastet und können sich auf ihre Basis­
aufgaben konzentrieren.
Schnittstelle: Problem Management
Das Problem Management übernimmt vom In­
cident Management die Ursachenforschung
und stellt Workarounds bis zur endgültigen Be­
hebung zur Verfügung. Diese nennt man in ITIL
„Known Errors“. Die Trennung bewirkt, dass man
sich beim Incident Management primär um die
Beseitigung kümmert, damit die schnellstmög­
liche Wiederherstellung des Services gewähr­
leistet ist.
Diesen Prozess muss man nicht direkt mit ein­
führen. Es ist allerdings wichtig, dass die Bear­
beiter sich der unterschiedlichen Ziele bewusst
sind und diese aktiv unterstützen. Die Known
Errors können im ersten Schritt auch z. B. in
einer Excel-Tabelle gepflegt werden.
Schnittstelle: Service Level Management
Die Schnittstelle zum Service Level Manage­
ment ist eine der wichtigsten Schnittstellen. Sie
liefert dem Incident Management die benötigten
Basisinformationen zu den Anforderungen des
Services wie Priorität, Verfügbarkeit, Reaktions­
zeit, Backup-Klassen usw. Anhand dieser Infor­
mationen kann beurteilt werden, welcher Ser­
vice mit dem Kunden vereinbart wurde.
Dieser Prozess muss nicht in ganzer Breite in­
stalliert werden. Es sollte aber zumindest ein
Mitarbeiter beauftragt werden, die benötigten
Informationen zur Verfügung zu stellen. Hier
sollten auch Standard Service Level für die
ORDIX News 1/2007
Projektmanagement
Services definiert werden, für die noch kein
spezifischer Service Level vereinbart wurde.
Diese Vorgaben sind wichtig, da anhand die­
ser Informationen wichtige Entscheidungen be­
züglich der Reihenfolge der Incident-Beseiti­
gung getroffen werden können. Die Verantwor­
tung hierfür darf nicht auf die Mitarbeiter im In­
cident Management abgewälzt werden.
Schnittstellen:
Change und Configuration Management
Beide Prozesse stellen dem Incident Manage­
ment aktuelle Informationen zur Verfügung. Das
Configuration Management über die Konfigu­
ration der Systeme. Das Change Management
über die letzten Änderungen.
Beide sollen helfen, Störungen so schnell wie
möglich zu lösen. Beide Prozesse muss man
allerdings nicht zwingend einführen, um Inci­
dent Management zu betreiben.
Glossar
Change
Abgestimmte Änderung eines Konfigurationselemen­
tes. Diese kann Hardware, Software, Dokumentation
oder Service Level betreffen.
Incident
Eine Störung des Betriebes, die eine Unterbrechung
oder eine Verschlechterung des vereinbarten Servi­
ces bewirkt.
Known Error Eine bekannte Störung, deren Ursache noch nicht ab­
gestellt ist. Es ist aber ein Workaround bekannt, mit
dem die Auswirkungen gemindert werden.
Problem
Unbekannte Ursache eines Incidents.
Rolle
Die verschiedenen Aufgaben innerhalb eines Prozes­
ses werden von verschiedenen Rollen übernommen.
Jeder Mitarbeiter kann verschiedene Rollen anneh­
men. Je nach Aufgabe nimmt er gleichzeitig immer
nur eine Rolle wahr.
Service
Ein Service ist eine Mischung aus einem oder mehre­
ren Produkten (Servern, Software, ...) und dazu pas­
senden Dienstleistungen.
Workaround Umgehungslösung - Darunter versteht man die Um­
gehung eines bekannten Problems in einem System
durch eine Hilfskonstruktion.
Resümee
Die Einführung des Incident Management Pro­
zesses bringt viel Aufwand, Anpassungspro­
bleme und temporäre Unzufriedenheit des
Kunden mit sich. Mittelfristig trägt er aber da­
zu bei, dass der Kunde seine Services, für die
er ja auch bezahlt, so erhält, wie er sie verein­
bart hat. Durch einen funktionierenden Incident Management Pro­
zess kann man seine internen Kosten senken und gleichzeitig die
Kundenzufriedenheit erhöhen.
Christian Ramm ([email protected]).
Impressum
Herausgeber:
ORDIX AG
Aktiengesellschaft für Software­ent­wick­lung,
Beratung, Schulung und Systemintegration,
Paderborn
Autoren dieser Ausgabe: Christoph Borowski, Andre Dirr, Chris­
tian Fertsch, Klaus Günther, Kathrin Hammerschmidt, Stefanie Heit­
her, Martin Hoermann, Helma Jenniches, Dr. Stefan Koch, Wolfgang
Kögler, Roger Niemeyer, Christian Ramm, Guido Saxler, Thorsten
Schuhmacher, Jens Stahl, Dr. Klaus Uebelgünn
Redaktion:
Helma Jenniches, Sascia Brinkmann
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.
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
Auflage: 9.000
Druck:
Druckerei Reike GmbH, Paderborn
ORDIX News 1/2007
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­re­
gungen, 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.
19
Java/J(2)EE
Code Coverage mit Clover
Java unterm Kleeblatt
In nahezu keinem Projekt fehlt heutzutage die Überprüfung des Source Code auf korrekte Funktionsweise.
Dies geschieht zum Beispiel mit dem Testingtool JUnit. Mittels Code Coverage und Werkzeugen, wie dem
hier vorgestellten Clover, kann anschließend der Java-Programmcode auf vollständige Testabdeckung überprüft werden.
Dieser Artikel richtet sich an Anwendungsentwickler und Projekt­
manager, die den Grad der Testabdeckung ihres Codes mes­
sen möchten.
Clover
Mit dem Clover Plugin für Eclipse ist es möglich, innerhalb der IDE
Java-Projekte zu kompilieren, mit JUnit zu testen und den Grad
der Testabdeckung der Unit-Tests sofort in einer separaten View
zu sichten, ohne dabei die Entwicklungsumgebung zu verlassen.
Das kommerzielle Tool ist eines der ältesten Vertreter aus dem
Bereich Code Coverage. Der Name „Clover“ ist übrigens die Kurz­
form des Kosenamens des Autors „Mr. Clover Lover“ und bedeu­
tet übersetzt „Kleeblatt“.
Code Coverage
Unter dem Begriff Code Coverage versteht man die Messung des
von Unit-Tests abgedeckten Source Code. Noch nicht getestete
Programmzeilen lassen sich dadurch schnell aufspüren.
Beim Code Coverage gibt es unterschiedliche Coverage Metriken,
wie zum Beispiel Branch-, Decision-, Line- oder Path-Coverage.
Die verschiedenen Ansätze sollen hier aber im Einzelnen nicht
näher betrachtet werden. Festzuhalten ist nur, dass es verschie­
dene Herangehensweisen und Messmethoden gibt, um das Ver­
hältnis von getestetem Quellcode zum gesamten Projekt zu er­
rechnen und (grafisch) darzustellen.
Installation
Über die Homepage unter [1] kann die aktuelle
Version des Programms in verschiedenen Aus­
führungen bezogen werden. Neben der Stand­
alone-Version für das Buildtool ANT existieren
Versionen für die Integration in verschiedene
IDEs. Derzeit werden die folgenden Entwick­
lungsumgebungen unterstützt:
•
•
•
•
•
Eclipse
Borland JBuilder
Oracle JDeveloper
JetBrains IntelliJ IDEA
Sun Microsystems Netbeans
In diesem Artikel wird die Version Clover für
Eclipse in der Version 1.2.9 näher betrachtet.
Die heruntergeladene Version ist eine ZIP-Da­
tei und wird in das Verzeichnis {ECLIPSE_
HOME}/plugins entpackt. Ältere Versionen
des Plugins sollten vorher entfernt werden.
Um das Tool zu aktivieren, wird eine gültige Li­
zenzdatei benötigt, die ebenfalls über die Her­
stellerseite zu beziehen ist.
Zur Evaluierung steht auch eine 30-Tage-TestLizenz zur Verfügung. Diese Datei wird im Clo­
ver-Verzeichnis abgelegt.
Nach einem Neustart von Eclipse ist das Plug­
in aktiviert und einsatzbereit.
Erste Schritte
Anhand einer kleinen Hilfsklasse, die eine Me­
thode subtract() zum Subtrahieren zwei­
er Long-Werte beinhaltet, soll der Einsatz des
Code Coverage Tools demonstriert werden.
Dafür wird ein neues Projekt in Eclipse ange­
legt. Anschließend wird Clover über die ProjektProperties aktiviert.
Abb. 1: Eclipse Projekteinstellungen für Clover.
20
Der Screenshot in Abbildung 1 zeigt die Einstel­
lungsmöglichkeiten auf dem neu hinzugekom­
menen Clover-Menüpunkt. Für unsere Zwecke
reicht ein Setzen des Hakens „Enable Clover
plugin in this Project“.
ORDIX News 1/2007
Java/J(2)EE
public class CalculatorUtil {
public static Long subtract(Long minuend, Long subtrahend) {
}
}
if (minuend == null) {
return (-subtrahend);
} else if (subtrahend == null) {
return minuend;
} else {
return (minuend.longValue() - subtrahend.longValue());
}
Abb. 2: Die Klasse CalculatorUtil.
import junit.framework.TestCase;
public class CalculatorUtilTest extends TestCase {
Long number1 = null;
Long number2 = new Long(1);
Long number3 = new Long(2);
public void testSubtract() {
}
}
assertEquals(new Long(-1), CalculatorUtil.subtract(number1, number2));
assertEquals(new Long(1), CalculatorUtil.subtract(number3, number2));
assertEquals(new Long(2), CalculatorUtil.subtract(number3, number1));
Abb. 3: Die Testklasse CalculatorUtilTest.
Einsatz
Clover Einstellungen
Grundlage für einen JUnit-Test bildet die Klas­
se CalculatorUtil, die nur eine Methode
subtract() besitzt. Diese ist in Abbildung
2 zu sehen.
Im ersten Schritt haben wir Clover für das Projekt aktiviert. Aller­
dings wird die Überprüfung auf Code-Abdeckung noch nicht durch­
geführt. Dafür muss die Clover-View über Window->Show View
eingeblendet werden.
Die Methode erhält als Übergabeparameter
zwei Zahlen. Zurückgegeben wird die Diffe­
renz der beiden Zahlen. Ist der Minuend null,
so wird der negierte Subtrahend als Ergebnis
geliefert. Ist der Subtrahend null, so wird der
Minuend zurückgegeben. Sind beide Zahlen
ungleich null, ist die Differenz das Resultat.
Ob diese Routine Sinn macht, sei dahinge­
stellt. Wichtig ist lediglich:
In dieser Ansicht gilt es, noch zwei Schalter zu setzen. Schalter Nr.
1 „Toggle compiling with Clover“ übersetzt das ausgewählte Pro­
jekt mit dem Clover-eigenen Compiler. Damit wird die Messung
der Code-Abdeckung überhaupt erst möglich.
• Wie ruft JUnit diese Methode mit verschie­
denen Parametern auf?
• Welche Codezeilen werden durchlaufen?
• Wie macht Clover diese Codezeilen sicht­
bar?
• Wie bestimmt Clover schließlich den Grad
der Testabdeckung?
Das Listing in Abbildung 3 zeigt die Testklas­
se CalculatorUtilTest mit der Methode
testSubtract(), die die drei oben beschrie­
benen Szenarien durchspielt und die zu testen­
de Klasse zu 100 Prozent abdeckt.
ORDIX News 1/2007
Ergebnisanzeige in der Clover View
Mit Schalter Nr. 2 „Show coverage data ...“ wird die fehlende Test­
abdeckung im Quellcode am linken Rand der Clover View inner­
halb von Eclipse durch rote Ausrufezeichen sichtbar gemacht. Ein
zusätzlicher Tool-Tipp auf dem Symbol gibt an, dass diese Zeile
noch nicht aufgerufen wurde oder welche Bedingungen noch nicht
erfüllt bzw. getestet sind.
Des Weiteren zeigt die View im unteren Teil grafisch an, zu wie viel
Prozent eine Klasse von den Unit-Tests durchlaufen wurde. Zu ei­
ner konkret selektierten Klasse im Baum werden diese Angaben auf
Methoden, Statements und Bedingungen heruntergebrochen.
In Abbildung 4 ist die Codeabdeckung für die Klasse CalculatorUtil zu sehen. Im Quellcode darüber sind die noch nicht getes­
teten Zeilen markiert. Bewusst wurde eine Zeile im Unit-Test aus­
kommentiert, um nicht abgedeckte Blöcke sichtbar zu machen.
21
Java/J(2)EE
Abb. 4: Clover View mit Report zur Code Coverage.
Reports
Neben der Anzeige innerhalb der Clover View ist es aber auch
möglich, Reports aus den gesammelten Daten zu generieren. Bei
der Ausgabe können verschiedene Formate gewählt werden. Da­
zu gehören die Erzeugung von HTML-Seiten und PDF-Dateien so­
Links
► [1] http://www.cenqua.com/clover
Glossar
ant
22
ant ist ein in Java geschriebenes Werkzeug zur automa­
tisierten Abarbeitung von Aufgaben (Dateien kopieren,
Sourcen kompilieren, Archive packen etc.). Welche Aufga­
ben in welcher Reihenfolge mit welchen Parametern aus­
geführt werden, wird in so genannten ant-Skripten abge­
legt, die XML als Format verwenden. ant ist vor allem in
der Softwareentwicklung weit verbreitet und wird von fast
allen IDEs unterstützt.
Eclipse
Eine Open Source Entwicklungsumgebung unter der Ver­
waltung der Eclipse Foundation. Entstanden aus dem
kommerziellen „Visual Age for Java“ von IBM.
JUnit
Ein Open Source Framework zur Durchführung von au­
tomatisierten Tests von Java-Programmen.
wie die Generierung von XML-Dateien für ei­
ne eventuelle Weiterverarbeitung.
Fazit
Wie das Beispiel zeigt, lassen sich mit Clover
noch nicht getestete Source-Zeilen zuverläs­
sig und vor allem frühzeitig aufdecken.
Dem Projektmanager gibt es eine gute Über­
sicht über den aktuellen Grad der Testabde­
ckung. In größeren Projekten ist es ein unver­
zicht­bares Tool, das durch die zusätzliche
Funk­tion der Reporterstellung in unterschied­
lichen Formaten besticht.
Der Einsatz von Clover darf aber nicht darüber
hinwegtäuschen, dass trotz alledem selbst auf
die Richtigkeit und Vollständigkeit der program­
mierten Tests zu achten ist.
Andre Dirr ([email protected]).
ORDIX News 1/2007
Betriebssysteme
Vergleich der Open Source Lösung XEN mit anderen Virtualisierungslösungen (Teil II)
Virtualisieren mit XEN
In der ORDIX News 3/2006, Seite 13, haben wir bereits über die Virtualisierungslösung XEN berichtet, indem
wir diese in einem Überblick mit den kommerziellen Produkten von Microsoft und VMware verglichen haben.
Mit diesem Artikel und weiteren Artikeln möchten wir Sie mit XEN vertrauter machen und dabei dem Produkt
etwas tiefer unter „die Haube“ schauen.
Auswahl eines geeigneten Wirts
Bevor mit der eigentlichen Virtualisierung be­
gonnen werden kann, wird ein geeignetes
Wirts­betriebssystem benötigt. Hierzu eignet
sich prinzipiell jedes Linux-System. Doch wer
eine aktuelle Distribution (SUSE Linux 10.X,
Debian Testing oder Fedora Core 5) nutzt, hat
den Vorteil, die Installation ohne Kernelpatch
und Kompilierung durchführen zu können.
Hier liegen in der Regel auch schon die Ver­
waltungstools im entsprechenden Paketfor­
mat vor, so dass eine Kompilierung aus dem
Quellcode entfallen kann. So liefert z. B. die
SUSE Linux Distribution 10.X ein YaST Mo­
dul mit, welches das Gastbetriebssystem per
GUI automatisch erstellen kann. Bei anderen
Distributionen ist mehr Handarbeit gefragt, die
Kenntnisse des Paketmanagement-Systems
voraussetzt.
Der Gastgeber bereitet sich auf die Gäste vor
Um das Wirtbetriebsystem für XEN vorzube­
reiten, müssen einige Pakete installiert wer­
den. Das wird mit Hilfe von YaST (siehe Ab­
bildung 1) oder auch auf der Kommandozeile
mit dem RPM-Paketmanager erledigt.
Der mit dem Paketmanager installierte XENKernel bringt die XEN-Unterstützung und Ker­
nelpatches mit. Alternativ müsste vom vorhan­
Dieser Artikel richtet sich an Berater, Systemadministratoren
und Entscheider, die sich mit dem Thema Virtualisierung aus­
einandersetzen möchten.
denen Kernel der Quellcode mit zusätzlichen Patches versehen
und kompiliert werden. Für den ersten Versuch ist der Weg über
die RPM-Dateien einfacher und schneller.
Der XEN-Kernel bootet
Nun ist es an der Zeit, den XEN-Kernel zu boo­ten. Hierzu muss in
der Konfigurationsdatei des Bootmanagers ein Eintrag erstellt wer­
den, welcher den XEN-Kernel bootet.
In Abbildung 2 ist ein Beispieleintrag für den Bootmanager GRUB
zu sehen. Empfehlenswert ist es, einen zusätzlichen Eintrag zum
normalen Kernel zu machen. So kann jederzeit mit oder ohne XEN
gebootet werden.
In der Regel verläuft das unspektakulär: Der Bootvorgang sieht
ganz normal aus und auf den ersten Blick startet das Linux-Sy­
stem unverändert. Auffällig erscheint, dass der XEN-Kernel im
VGA-Textmodus (siehe Abbildung 3) bootet, und nicht, wie viel­
leicht gewohnt, ein Splash Screen erscheint. Der Grund hierfür ist,
dass XEN nicht das Frame Buffer Device der Grafikkarte nutzen
kann und deshalb den VGA-Modus verwendet.
Die Gäste kommen an
Nach erfolgreichem Start des XEN-Kernels können nun die Gäs­
te installiert oder bestehende per Image- bzw. Cloning-Verfahren
Abb. 1: Paketinstallation mit YaST.
ORDIX News 1/2007
23
Betriebssysteme
auf den Wirt übertragen werden. Insgesamt gibt es drei Möglich­
keiten, ein Gastbetriebssystem zu installieren:
1. Clonen eines bestehenden Rechners mit Unix Bordmitteln,
z. B. dd, tar, cpio
2. Installation mit YaST-Modul: Virtual Machine Management
(XEN)
3. Installation mit rpm-Befehl auf der Kommandozeile in einer
Chroot-Umgebung
title Xen 3.0 / XENLinux 2.6
kernel/boot/xen-3.0.gz dom0_mem=65536
module/boot/vmlinuz-2.6-xen root=/dev/hda1 ro console=tty0
Abb. 2: Bootmanager-Eintrag für den XEN-Kernel.
Bei allen Installationsarten werden die
Gäste in eine Verzeichnisstruktur inner­
halb des Wirtes, z. B. /xen/xen1/sda1,
oder auf eine Festplattenpartition instal­
liert. Aus Gründen der Sicherheit, Perfor­
mance und Flexibilität ist es ratsam, die
Gäste auf eine separate Partition/Fest­
platte oder ein Logical Volume (LVM) zu
legen.
Einstellungssache
Um nun endlich einen Gast ins Ren­
nen zu schicken, ist es notwendig, ei­
ne Konfigurationsdatei zur Verfügung
zu stellen.
Im Prinzip müssen folgende Angaben
gemacht werden:
• Verzeichnispfad
• Memory
• Anzahl der zugeordneten Prozesso­
ren
• Emulierte Netzwerkkarte
• Wird die IP-Addresse dynamisch oder
statisch zugewiesen?
Abbildung 4 zeigt ein Beispiel für eine
Konfigurationsdatei. Die Konfigurations­
dateien werden von XEN im Verzeichnis
/etc/xen erwartet und tragen norma­
lerweise den Namen des Gastes.
Abb. 3: Boot-Vorgang des XEN-Wirtes.
kernel = "/boot/vmlinuz-xen"
ramdisk = "/boot/initrd-xen"
memory = 128
vcpus = 1
name = "xen1"
disk = ['file:/xen/xen1/sda1,sda1,w', 'file:/xen/xen1/sda2,sda2,w']
root = "/dev/sda1 ro"
extra = ""
nics = 1
vif = ['mac=aa:bb:cc:dd:ee:ff, bridge=xen-br0']
dhcp = "dhcp"
Die Sache spitzt sich zu
Ist die Konfigurationsdatei erstellt, kann
der Gast ins Rennen geschickt werden.
Der Befehl xm create –c /Pfad/zur/
Konfigurationsdatei startet die virtu­
elle Maschine. Man sieht sofort das Er­
gebnis, denn das Gastbetriebs­system,
in diesem Fall Linux, bootet und begrüßt
uns am Ende des Bootvorgangs mit dem
Abb. 4: Konfigurationsdatei für einen Gast.
xm list
xm console <domID>
xm mem-set <domID> 256M
xm save <domID> <Datei>
xm restore <Datei>
xm <domID> shutdown
xm vcpu-set <domID> <VCPUs>
xm –help
Auflistung aller virtueller Maschinen
Konsolensitzung am Gast übernehmen
Einem Gast Memory zuordnen, zur Laufzeit möglich
Sichert den aktuellen Stand des Gastes in die angegebene Datei
Stellt den Zustand aus der angegebenen Datei wieder her
Herunterfahren eines Gastes
Zuordnung von CPUs zum Gast, zur Laufzeit möglich
Übersichtliche Hilfe zu allen Befehlen
Abb. 5: Beispiel für häufig benutzte xm-Befehle.
chkconfig –list xend
chkconfig xend on
chkconfig xend off
Aktuellen Status des Dienstes auflisten
Dienst auf automatisches Starten stellen
Dienst wird nicht automatisch gestartet
Abb. 6: Der chkconfig-Befehl zum Ändern des Startverhaltens der Dienste beim Booten.
24
ORDIX News 1/2007
Betriebssysteme
Loginprompt. Die virtuelle Maschine ist sofort
mit dem Befehl xm console <Name der virtuellen Maschine> oder über die eingestell­
te IP-Adresse über das Netzwerk erreichbar.
Glossar
Virtualisierung Möglichkeit, mehrere Betriebssysteme gleichzeitig
auf derselben Hardware auszuführen. Es wird ein
kompletter PC mit Hardware und Bios emuliert.
Ein Kommando für Alles
Host (Wirt)
Der eben verwendete Befehl xm ist der zen­
trale Verwaltungsbefehl für XEN. Im Prinzip
kann alles, was mit XEN administrierbar ist,
mit diesem Befehl erledigt werden. Beispie­
le für häufig genutzte Befehle finden Sie in
Abbildung 5.
Gast (Domain) Emulierte Betriebssysteme, die zusätzlich zum Host
auf derselben Hardware laufen.
Splash Screen Bild, das anstelle der textbasierten Ausgabe wäh­
rend des Bootens angezeigt wird.
Der xm-Befehl kennt noch viele weitere Op­
tionen zur Verwaltung von XEN. Mit xm –help
können diese aufgelistet werden.
Bei den meis­­ten Optionen lässt sich schon an­
hand des Namens auf die Funktionalität schlie­
ßen. Und wenn nicht, gibt es auch hierzu ei­
ne Manual Page, die über den Befehl man xm
aufrufbar ist.
Die Gäste kommen wieder
Der xm create-Befehl startet einen Gast ma­
nuell. Um ein automatisches Starten der Gäste
beim Booten des Wirtes zu erreichen, müssen
zwei Startskripte aktiviert werden. Dies kann
entweder von Hand mit symbolischen Links
oder unter SUSE und RedHAT (Fedora) mit
chkconfig xend on und chkconfig xendomains on erreicht werden. chkconfig ist ein
Linux-Befehl unter SuSE- und RedHAT-basier­
ten Distributionen. Mit ihm kann das Startver­
Betriebssystem, das die physische Hardware verwal­
tet und die Ressourcen verteilt.
Imaging,
Cloning
Verfahren, bei dem ein bestehendes Betriebssystem
1:1 auf ein anderes System übertragen wird.
GUI
Graphical User Interface. Grafische Benutzeroberflä­
che, die die Arbeit/Administration per Maus ermög­
licht.
Framebuffer
Zusätzlicher Chipsatz auf modernen Grafikkarten, der
immer mit denselben Befehlssätzen angesprochen
werden kann. Dadurch können ohne den „richtigen
Treiber“ hohe Auflösungen dargestellt werden.
halten der Dienste beim Booten sehr einfach geändert werden
(siehe Abbildung 6).
XEN kann mehr - wir berichten weiter
In diesem Artikel haben wir Ihnen die grundlegenden Funktionalitä­
ten von XEN gezeigt. In einer der nächsten ORDIX News möchten
wir Ihnen noch mehr zu diesem aktuellen Thema berichten, z. B.
wie ein OpenSolaris in den Genuss des Gastes kommt. Außerdem
möchten wir Ihnen ein grafisches Frontend für XEN vorstellen und
eine Live-Migration von einem System auf ein anderes aufzeigen.
Christian Fertsch ([email protected]).
Seminar: Server-Virtualisierung mit XEN
Server-Virtualisierung - ein Konzept der Mainframes
- wird auch auf PC- bzw. Unix-Architekturen zuneh­
mend populärer. Der Teilnehmer bekommt einen Über­
blick über die Funktionsweise und Administration von
XEN basierten Systemen.
Zielgruppe
Programmierer, Systemadministratoren, System­
betreuer.
Voraussetzungen
Unix/Linux Systemadministrationskenntnisse oder
Teilnahme am Seminar „Linux Systemadministra­
tion“ (BS-02).
Dauer:3 Tage
Preis: 1090,00 € zzgl. ges. MwSt.
ORDIX News 1/2007
Termine:
14.05.2007-16.05.2007in Wiesbaden
27.08.2007-29.08.2007in Wiesbaden
12.11.2007-14.11.2007 in Wiesbaden
Inhalte
•
•
•
•
•
•
•
•
•
•
•
•
•
Aufbau und Architektur von XEN
Systemvoraussetzungen von Hard- und Software
Installation und Konfiguration von XEN
Erstellung eines eigenen XEN-Kernels
Konfiguration des Bootmanagers und XEN Parameters
für verschiedene Einsatzszenarien
Wichtige Dateien und Verzeichnisse von XEN
Installation von Linux Gastsystemen
Netzwerkkonfiguration und der XEN-Switch
Routing und Subnetzbildung virtueller Gäste
Live-Migration von virtuellen Gästen
XEN-Troubleshooting
Andere XEN-Gäste
Übungen
25
Datenbanken
Reihe Oracle Objekttypen von A - Z (Teil II):
Oracle Objekttypen mit „D”
Im ersten Teil der Reihe haben wir die Objekttypen CLUSTER, CONSUMER GROUP und CONTEXT kennen­
gelernt. Heute geht es weiter mit dem Buchstaben „D“: vom Datenbank-Link über Dimensionen bis hin zum
Directory.
Dieser Artikel wendet sich an Datenbankadministratoren und
Entwickler, die einen Überblick über die Objekttypen von Ora­
cle bekommen möchten.
DATABASE LINK
Ein Datenbank-Link (DB-Link) ermöglicht den Zugriff aus einer Da­
tenbank heraus über Oracle Net auf eine beliebige, andere Da­
tenbank.
Zunächst wird in unserem Beispiel ein DB-Link „ordix“ angelegt
(siehe Abbildung 1). Anschließend kann der Zugriff auf die entfern­
te Datenbank einfach mit dem Suffix „@ordix“ hinter dem Tabellen­
namen im SQL-Befehl erfolgen. Auf der Zieldatenbank bezieht sich
alles auf das Schema, das in der Connect-Klausel angegeben ist
– hier scott.
Wichtig für die korrekte Auflösung des DB-Links ist die Konfigura­
tionsdatei tnsnames.ora auf dem Datenbankserver, auf dem der
DB-Link angelegt wurde. Diese Datei muss einen entsprechenden
Eintrag für den TNS-Connect-String james beinhalten, welcher auf
die Zieldatenbank verweist (siehe Abbildung 2).
Oracle unterscheidet öffentliche (public) DB-Links, die für alle be­
kannt sind, und private DB-Links, welche nur für den Ersteller sicht­
bar sind. In der Syntax sorgt das Schlüsselwort PUBLIC für den
Typ. Wird die Connect-Klausel nicht mit angegeben, so wird auf
der Zieldatenbank ein Schema gleichen Namens wie auf der Ur­
sprungsdatenbank angenommen.
Das eigentlich Interessante am DB-Link ist, dass mit ihm ein trans­
parenter Zugriff auf mehrere Datenbanken gleichzeitig möglich
wird. Dies ist eine so genannte „verteilte Datenbank“. Damit kön­
nen innerhalb einer Transaktion auf mehreren Datenbanken Än­
derungen vorgenommen werden. Mit dem Befehl commit werden
diese auf allen Systemen aktiv.
Kommt es zu einem Fehler auf einem System, werden die Ände­
rungen auf allen Systemen zurückgerollt. Kann ein System nicht
erreicht werden, werden alle Änderungen angehalten.
Diese Änderungen müssen dann vom Systemadministrator per
commit manuell bestätigt oder zurückgerollt werden. Der Befehl
commit wird implizit mit dem Protokoll „Two Phase Commit“ be­
handelt.
Achtung: Bis einschließlich zur Version 10g Release 1 werden die
Passwörter von DB-Links unverschlüsselt im Data Dictionary in den
Views user_links und link$ dargestellt, d. h. sie sind sichtbar!
26
DIMENSION
Eine Dimension ist ein Metadatenobjekt. Es
beschreibt hierarchische Abhängigkeiten zwi­
schen Spalten. Diese Hierarchien nennt Ora­
cle Dimensionen. Eine Anwendung, wie im Fol­
genden kurz erläutert, findet sich typischerwei­
se in Data Warehouse Projekten.
Beispiel: Eine häufig verwendete Dimension ist
die Zeit. Sie besteht beispielsweise aus Tagen
und den Aggregationen Monate und Jahre. Mit
Hilfe einer Referenztabelle lässt sich zu jedem
Tag jede der entsprechenden Aggregationen
zuordnen. Diese Referenztabelle zeit_ref
hätte dann folgende Spalten:
• tag
• monat
• jahr
Die Spalte tag stellt den Primary Key der Ta­
belle dar. Die Tabelle muss von der Anwen­
dung gepflegt werden und enthält für jeden
relevanten Tag den Monat und das Jahr. Die
Referenztabelle kann mit einer Basistabelle,
z. B. Verkäufe, nach Belieben verknüpft wer­
den. Oracle kennt aber – bisher – keinen ei­
genständigen Mechanismus, um die Abhän­
gigkeiten der Aggregationen zu beschreiben,
darzustellen oder in Ausführungsplänen zu
ver­wenden.
An dieser Stelle setzt die Dimension an. Für
das oben genannte Beispiel kann der Anwen­
dungsentwickler jetzt eine Dimension erstellen
(siehe Abbildung 3).
Wird jetzt zusätzlich eine Materialized View auf
die Verkaufstabelle auf dem Aggregat monat
angelegt, so kann der Optimizer mit Hilfe der
Hierarchie und der Referenztabelle auch Er­
gebnisse für Jahre aggregieren. Dies bedeutet
letztendlich, dass für eine Vielzahl von Auswer­
tungen von Basistabellen nach verschiedenen
Dimensionen und unterschiedlichen Aggrega­
tionen nur einige wenige Materialized Views
benötigt werden.
Natürlich können mit Hilfe gut formulierter SQLBefehle diese Aggregationen ebenfalls vor­
ORDIX News 1/2007
Datenbanken
genommen werden. Der Clou beim Thema DI­
MEN­SION ist aber, dass Oracle diese Aggre­
gationen automatisch erkennt und ein Query
Re­write eines einfachen SQL-Befehls für den
Anwen­der erledigt.
Den Objekttyp Materialized View werden wir in
einer der nächsten Ausgaben vorstellen.
DIRECTORY
Bis zur Version 8 konnte man ausschließlich
auf Verzeichnisse zugreifen, die über den Ini­
tialisierungsparameter utl_file_dir konfigu­
riert waren. Der Zugriff war dann grundsätz­
lich lesend und schreibend möglich. Der Ob­
jekttyp DIRECTORY ermöglicht einen deutlich
besseren Zugriffsschutz.
Nach dem Anlegen eines Directories (siehe
Abbildung 4) kann das Recht für den lesen­
den und schreibenden Zugriff differenziert er­
teilt werden (siehe Abbildung 5).
Dies setzt allerdings voraus, dass das Ver­
zeichnis (hier /oracle/daten) existiert und
der Betriebssystembenutzer, unter dem die
Datenbank läuft, Lese- und Schreibberechti­
gung auf dem Verzeichnis besitzt. Unterver­
zeichnisse können in einem Directory nicht an­
gelegt werden.
Das in Abbildung 4 benannte Directory kann
nun mit verschiedenen Werkzeugen und Me­
thoden unter Verwendung seines logischen
Namens – hier datenverzeichnis – ver­
wendet werden. Hierzu zählen beispielsweise:
• externe Tabellen
• Paket utl_file
• BFILEs
Liegt in diesem Directory beispielsweise die
Datei geheim.dat, so kann, wie in Abbildung
6 gezeigt, über eine externe Tabelle darauf zu­
gegriffen werden.
Für den Aufruf externer Programme aus dem
Paket dbms_schedule verwendet Oracle
den Objekttyp DIRECTORY zur Referenzie­
rung der Programmverzeichnisse leider nicht.
Sehr konsequent wird dagegen die zugehöri­
ge View dba_directories im korrekt ge­
schriebenen Plural verwendet.
In der nächsten Ausgabe setzen wir die Rei­
he Oracle Objekttypen von A - Z mit „E“ wie
Evaluation Context fort.
Martin Hoermann ([email protected]).
ORDIX News 1/2007
CREATE [PUBLIC] DATABASE LINK ordix
CONNECT TO scott IDENTIFIED BY tiger
USING 'james';
Abb. 1: Kommando zum Anlegen eines DB-Links.
james =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = lebaron)
(PORT = 1521)
)
)
(CONNECT_DATA =
(SERVICE_NAME = bond)
)
)
Abb. 2: Eintrag des TNS-Connect-Strings james in der tnsnames.
ora.
CREATE DIMENSION ZEIT_HIERARCHIE
level tag
is zeit_ref.tag
level monat
is zeit_ref.monat
level jahr
is zeit_ref.jahr
hierarchy ZEIT_ROLLUP
( tag
child of
monat child of
jahr
);
Abb. 3: Erstellung einer Dimension.
CREATE OR REPLACE DIRECTORY datenverzeichnis
AS '/oracle/daten';
Abb. 4: Kommando zum Anlegen eines Directories.
GRANT READ ON DIRECTORY datenverzeichnis TO scott;
GRANT WRITE ON DIRECTORY datenverzeichnis TO scott;
Abb. 5: Vergabe von Lese- und Schreibrechten.
CREATE TABLE geheim ( geheimnis VARCHAR2(100))
ORGANIZATION EXTERNAL
( TYPE oracle_loader
DEFAULT DIRECTORY datenverzeichnis
LOCATION ('geheim.dat')
)
REJECT LIMIT UNLIMITED;
Abb. 6: Zugriff auf eine Datei im zuvor angelegten Directory mit Hilfe
einer externen Tabelle.
27
Seminartermine Datenbanken
Oracle SQL
Oracle SQL für Umsteiger
Oracle SQL für Experten
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 Advanced Queuing Workshop
Oracle Replikation 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
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
Shell, Awk und Sed
Einführung in XML
XML Programmierung unter Java mit DOM und SAX
PHP Programmierung Grundlagen
PHP Programmierung Aufbau
Java-J2EE
Java Programmierung Grundlagen
Java Programmierung Aufbau
Java GUI Entwicklung mit Swing
J2EE/JEE für Entscheider
Einführung in J2EE/JEE
JSP und Servlet Programmierung
EJB Programmierung
Web­Anwendungen mit JavaServer Faces (JSF)
Java Web Services
Entwicklung mit Hibernate
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
Systemmanagement
BMC PATROL/Performance Manager Basics
Projektmanagement
IT­Projektmanagement
Grundlagen des IT­Controlling
Wiesbaden
Saarbrücken*
Lippstadt*
1790,00
790,00
1190,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
1090,00
790,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
1590,00
1090,00
790,00
1590,00
1090,00
1590,00
1590,00
1590,00
450,00
1090,00
1590,00
1590,00
1590,00
1090,00
1090,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
1890,00
1190,00
*) Preise pro Seminar pro Teilnehmer in Euro. Alle Preise gelten zzgl. ges. MwSt.
**) Inhousepreise auf Anfrage.
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.
28
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
Januar
KW 1
Preis in
EURO*)**)
- heraustrennbare Übersicht -
ORDIX News 1/2007
http://training.ordix.de
Online-Anmeldung und stets aktuelle
Seminarinhalte und Termine!
KW 26
KW 25
KW 24
KW 23
KW 22
Juni
KW 21
KW 20
KW 19
KW 18
Mai
KW 17
KW 16
KW 15
KW 14
April
Januar - Juni 2007
Preis in
EURO*)**)
1790,00
790,00
1190,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
1090,00
790,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
1590,00
1090,00
790,00
1590,00
1090,00
1590,00
1590,00
1590,00
450,00
1090,00
1590,00
1590,00
1590,00
1090,00
1090,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
1890,00
1190,00
Datenbanken
Oracle SQL
Oracle SQL für Umsteiger
Oracle SQL für Experten
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 Advanced Queuing Workshop
Oracle Replikation 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
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
Shell, Awk und Sed
Einführung in XML
XML Programmierung unter Java mit DOM und SAX
PHP Programmierung Grundlagen
PHP Programmierung Aufbau
Java-J2EE
Java Programmierung Grundlagen
Java Programmierung Aufbau
Java GUI Entwicklung mit Swing
J2EE/JEE für Entscheider
Einführung in J2EE/JEE
JSP und Servlet Programmierung
EJB Programmierung
Web­Anwendungen mit JavaServer Faces (JSF)
Java Web Services
Entwicklung mit Hibernate
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
Systemmanagement
BMC PATROL/Performance Manager Basics
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 News 1/2007
zentrales Fax:
bzw.
E-Mail:
Online-Anmeldung:
0180 1 ORDIX 0
0180 1 67349 0
[email protected]
http://training.ordix.de
29
Datenbanken – Titelthema
IBM Informix Dynamic Server 10.0 Neuheiten (Teil IV):
Informix 10.0 - A Success Story ...
In der letzten ORDIX News Ausgabe (3/2006, Seite 10) haben wir den „Table Level Restore“ erläutert und damit auch die Vorstellung der Neuerungen aus dem Bereich Backup & Recovery abgeschlossen. In diesem
Artikel werden die noch ausstehenden Neuerungen beschrieben. Gleichzeitig endet mit diesem Artikel dann
auch unsere Reihe zum Thema „IBM Informix Dynamic Server 10.0 Neuheiten“.
Dieser Artikel richtet sich an Datenbankadministratoren, System­
administratoren und Entscheider.
Überblick
Die Neuerungen, die in diesem Artikel vorgestellt werden, bezie­
hen sich im Wesentlichen auf die folgenden Bereiche:
• SQL-Erweiterungen
• Administration
• Skalierbarkeit/Performance
SQL-Erweiterungen
TRUNCATE TABLE
Mit dem IBM Informix Release 10.00UC4 ist die SQL-Anweisung
TRUNCATE TABLE neu hinzugekommen. Sie dient dazu, alle Da­
tensätze einer Tabelle zu löschen. Im Gegensatz zur DELETE FROM
TABLE-Anweisung handelt es sich hierbei um eine DDL-Anweisung.
Somit werden keinerlei Informationen ins Transaktionslog geschrie­
ben.
Durch TRUNCATE TABLE wird die Tabellenstruktur nicht verän­
dert, was bedeutet, dass die eigentliche Tabelle nicht gelöscht wird.
Alle abhängigen Tabellenobjekte (Indizes, Trigger, Views und Con­
straints) bleiben bestehen.
Der TRUNCATE TABLE-Befehl kann mit zwei Optionen ausgeführt
werden:
1. DROP STORAGE (DEFAULT): Alle Extents des Objektes (auch
abhängiger Objekte) werden gelöscht.
2. REUSE STORAGE: Extents bleiben be­
stehen.
Die REUSE STORAGE-Option eignet sich vor
allem für Anwendungen, bei denen die gelösch­
te Tabelle immer wieder schnell gefüllt wird,
z. B. bei typischen Datawarehouse-Anwendun­
gen (Löschen + Laden von Daten). Damit wird
eine Allokation der neuen Extents vermie­den.
RAW Tables
Eine weitere, sehr interessante SQL-Funktion
wurde mit dem Release 10.00UC5 implemen­
tiert. Indizes können nun ebenfalls auf NonLogging-Tabellen (RAW Tables) bestehen blei­
ben bzw. angelegt werden. Durch diese Neue­
rung können nun besonders große Massenver­
arbeitungen deutlich beschleunigt werden (z. B.
ETL- bzw. Datawarehouse-Anwendungen).
Administration
Rename DBSpace
Mit dem neuesten Release besteht nun die Mög­
lichkeit, DBSpaces umzubenennen. Hierzu wur­
de das onspaces-Kommando um die Option
„ren“ erweitert. Wie Abbildung 1 zeigt, muss die
Datenbank im „Quiescent“-Mode sein.
Nach dem erfolgten Rename sollte auf jeden
Fall eine Level 0 Sicherung durchgeführt wer­
informix@linux:~> onmode -s
This will perform a GRACEFUL SHUTDOWN Do you wish to continue (y/n)? y
informix@linux:~>
informix@linux:~>onstat –
Informix Dynamic Server Version 10.00.UC4 -- Quiescent -- Up 17:28:11 -- 105920 Kbytes
informix@linux:~> onspaces -ren datadbs -n datadbs_rename
Rename of Space completed successfully.
** WARNING ** A level 0 archive of Root DBSpace and the renamed
Space need to be done.
informix@linux:~>
Abb. 1: Umbenennung eines DBSpaces.
30
ORDIX News 1/2007
Datenbanken
den, damit ein Restore des Systems wieder
möglich wird!
tablespace - tablespace
Ab dem Informix Release 10.0 kann die Grö­
ße von Extents für den tablespacetablespacetablespace bestimmt werden. Möglich ist dies
allerdings nur beim Erstellen eines DBSpaces,
das nicht vom Typ BLOB, SBLOB oder TEMP
ist.
Für das Root DBSpace wurden dazu zwei neue
ONCONFIG-Parameter eingeführt, die vor der
Erst­initialisierung gesetzt werden können:
• TBLTBLFIRST:
Größe des ersten Extents in KB
• TBLTBLNEXT:
Größe aller weiteren Extents in KB
Da alle nachträglichen DBSpaces dem Daten­
banksystem mit dem Befehl onspaces hin­
zugefügt werden, wurde auch dieser Befehl
um entsprechende Optionen erweitert:
• -ef <KB>:
Größe des ersten Extents in KB
• -en <KB>:
Größe aller weiteren Extents in KB
Dadurch wird erreicht, dass alle Extents des
tablespacetablespace-tablespace im initialen
Chunk allokiert werden können. Somit wird das
tablespace-tablespace über mehrere Chunks
„verteilt“ und die Anzahl der Extents wird ver­
mindert.
Beide Vorteile, die Möglichkeit des Umbenen­
nens von DBSpaces und des Festlegens von
Extent-Größen, wirken sich positiv auf die Per­
formance aus, da der Overhead bei der Table­
space-Verwaltung geringer wird.
Skalierbarkeit & Performance
Externe Optimizer-Direktiven
Während der Ausführungsplan den Weg des
Optimizers lediglich anzeigen kann, kann die­
ser Weg durch so genannte „Externe OptimizerDirektiven“ schon vorab beeinflusst werden.
In früheren Informix Versionen konnten Direk­
tiven ausschließlich im Statement durch einen
Optimizer Hint ( --+ Direktive) explizit angege­
ben werden. Mit der Version 10.0 besteht jetzt
die Möglichkeit der Speicherung von externen
Optimizer-Direktiven für ein SQL-Statement.
Mittels des neuen SQL-Befehls save external wird ein Ausführungsplan für das nachfol­
ORDIX News 1/2007
SAVE EXTERNAL DIRECTIVES
/*+ AVOID_INDEX(customer num_idx)*/
ACTIVE FOR SELECT * FROM CUSTOMER
WHERE CUSTOMER_NUM > 10;
SELECT * FROM CUSTOMER WHERE CUSTOMER_NUM > 11;
Abb. 2: SQL-Statements unterscheiden sich in der WHERE-Bedingung
und ziehen somit KEINE Nutzung der externen Direktiven nach sich.
SAVE EXTERNAL DIRECTIVES
/*+ AVOID_INDEX(customer num_idx)*/
ACTIVE FOR SELECT * __ FROM CUSTOMER
WHERE CUSTOMER_NUM > 10;
SELECT * FROM CUSTOMER WHERE CUSTOMER_NUM > 10;
Abb. 3: SQL-Statements unterscheiden sich (zusätzliche Leerzeichen)
und ziehen somit KEINE Nutzung der externen Direktiven nach sich.
gende Statement in der Datenbank gespeichert (siehe lokale Sys­
temtabelle der Datenbank → Tabelle sysdirectives).
Bei jeder Ausführung eines SQL-Statements überprüft nun der
Op­timizer, ob eine entsprechende externe Direktive vorhanden
ist. Dieser Vergleich wird mittels eines einfachen Quellcode-Ver­
gleichs durchgeführt.
Die Statements in Abbildung 2 wären unterschiedlich, weil die „Li­
terale“ (siehe WHERE-Klausel) unterschiedlich sind. Die externe
Direktive würde somit nicht genutzt.
Auch unterschiedliche Anzahlen von Leerzeichen im SQL-Statement
verhindern die Nutzung von externen Direktiven (siehe Abbildung
3). Somit würde der Optimizer die externe Direktive auch hier nicht
nutzen, obwohl die „Literale“ nun gleich sind. (Zwischen SELECT *
und der FROM-Klausel befinden sich zwei Leerzeichen „__“)
Um externe Optimizer Direktiven speichern zu können, wird aller­
dings vorausgesetzt, dass die Beeinflussung durch Direktiven er­
laubt ist. Dazu gibt es den ONCONFIG-Parameter EXT_DIREC­
TIVES bzw. die Umgebungsvariable IFX_EXTDIRECTIVES.
OPTCOMPIND
Der OPTCOMPIND-Parameter ist ein ONCONFIG-Parameter, mit
dem man das „Grundverhalten“ des Optimizers steuern kann. Ab­
bildung 4 zeigt die Einstellungsmöglichkeiten.
Mit dem neuesten Release ist der OPTCOMPIND-Parameter nun
je nach Anwendungslast (OLTP/Batch) mit dem Befehl SET EN­
VIRONMENT OPTCOMPIND für die aktuelle Datenbank-Session
änderbar.
Der dadurch geänderte Wert ist für den Zeitraum der Session gül­
tig und geht in dem Moment verloren, in dem diese Session be­
endet wird. Auf Abfragen von anderen Sessions hat der geänderte
Wert allerdings keinen Einfluss.
Durch die dynamische Änderung dieses Parameters ergeben sich
Performance-Vorteile, da man je nach Anwendungsverhalten den
OPTCOMPIND-Parameter in der ONCONFIG „übersteuern“ kann.
31
Datenbanken
# OPTCOMPIND
# 0 => Nested loop joins will be preferred (where
#
possible) over sortmerge joins and hash joins.
# 1 => If the transaction isolation mode is not
#
"repeatable read", optimizer behaves as in (2)
# below. Otherwise it behaves as in (0) above.
# 2 => Use costs regardless of the transaction isolation
#
mode. Nested loop joins are not necessarily
# preferred. Optimizer bases its decision purely
#
on costs.
Abb. 4: OPTCOMPIND – ONCONFIG – Parameter.
informix@trainix:/informix/ifx10/etc> onmode -wf DS_NONPDQ_QUERY_MEM=5000
Value of DS_NONPDQ_QUERY_MEM has been changed to 5000.
Abb. 5: Änderung des ONCONFIG-Parameters mittels onmode.
BUFFERPOOL size=2K,buffers=200000,lrus=4,lru_min_dirty=5.000000,lru_max_dirty=6.000000
BUFFERPOOL size=8K,buffers=50000,lrus=4,lru_min_dirty=5.000000,lru_max_dirty=6.000000
Abb. 6: Anlegen zweier BUFFER Pools.
NONPDQ-Queries
Für nicht parallele Datenbankabfragen (NONPDQ-Queries) ste­
hen standardmäßig lediglich 128 KB (bis 9.4 ausschließlich) an
Speicher für eine Sortierung zur Verfügung. Bei komplexeren Ab­
fragen (ORDER BY, GROUP BY, HASH JOIN) ist dies je nach Da­
tenmenge nicht ausreichend, die Daten werden dann auf ein Temp
DBSpace „ausgelagert“. Das bedeutet zusätzlichen I/O, der mit
dem neuen Parameter nun umgangen werden kann.
Um NONPDQ-Queries mehr Speicherplatz zuweisen zu können,
wurde der ONCONFIG-Parameter DS_NONPDQ_QUERY_MEM
eingeführt. Dieser ermöglicht eine explizite Speicherallokierung,
um oben beschriebenen Engpässen aus dem Weg zu gehen. Zu­
griffe auf das TEMP DBSpace werden dann nur noch notwendig,
wenn der angegebene Wert von DS_NONPDQ_QUERY_MEM
wiederum nicht ausreicht.
Genutzt wird hier der über DS_TOTAL_MEMORY (virtueller Spei­
cherbereich) zur Verfügung stehende Bereich im Shared Memory.
Daher kann der maximale Wert 25 Prozent des Parameters DS_
TOTAL_MEMORY nicht überschreiten. Als Minimum können nur
die bisher verwendeten 128 KB angegeben werden!
Auch der NONPDQ-Parameter kann dynamisch geändert werden.
Hierzu wird die ebenfalls neue Option des onmode-Kommandos
(-wm/-wf) genutzt (siehe Abbildung 5).
Shared Memory Verwaltung
Mit Informix 10 wird die änderbare PAGE Size für DBSPACES
und Shared Memory Pages eingeführt. Hierdurch ergeben sich
eini­ge Vorteile hinsichtlich der Performance und der maximalen
In­stanzkapazität.
Standardmäßig hat die Informix-Page eine Größe von 2 KB, bei AIX
und Windows sind es 4 KB. Ab dem Release 10.0 ist diese Page-Grö­
32
ße änderbar und kann somit auch für „norma­
le“ Daten-DBSpaces und temporäre DBSpaces
genutzt werden (Die Page-Größe von BLOBDBSpaces war schon immer änderbar!)
Zu beachten gilt allerdings, dass die Größe
immer ein Vielfaches des Default-Wertes sein
muss und 16 KB nicht überschreiten darf. An­
gegeben wird der Wert nach der Option –k,
die zusätzlich für den Befehl onspaces im­
plementiert wurde.
Voraussetzung für das Anlegen eines DB­Spa­
ces mit einer vom Default-Wert abweichenden
Page-Größe ist ein entsprechender BUFFER
Pool. Daher wurde in der ONCONFIG ein neu­
er Parameter BUFFERPOOL eingeführt. Mit­
tels diesem können ab dem IBM Informix Re­
lease 10 nun mehrere BUFFER Pools ange­
legt werden.
Weitere Features im Überblick
Weitere Neuerungen für die Bereiche Adminis­
tration und Hochverfügbarkeit sind:
• Konfigurierbare LISTENER VP
• LISTEN_TIMEOUT / MAX_INCOMPLETE_
CONNECTION
• Diverse Neuerungen und Anpassungen an
der Enterprise Replication u. a.:
• Möglichkeit der Veränderung von re­pli­
zier­ten Tabellen innerhalb einer Master
Repli­ka­tion (z. B. add/drop fragments,
add/drop columns)
• Möglichkeit der Nutzung von Replica­
tion Templates
ORDIX News 1/2007
Datenbanken
Fazit
Glossar
Mit dem IBM Informix Dynamic Server 10.0
hat IBM sehr viele neue Funktionen implemen­
tiert, die in der Praxis schnell Anwendung fin­
den werden. Unsere Erfahrungen mit dem Re­
lease sowie auch das Feedback unserer Kun­
den ist sehr positiv.
Hervorzuheben ist die von Informix bekannte
Implementierungsweise (easy to admin)!
Die folgenden Neuerungen sind die Highlights,
die uns und unsere Kunden überzeugt haben:
• Diverse SQL-Erweiterungen
• Security (Column Level Encryption, Netz­
•
•
•
•
•
werk Encryption)
Konfigurierbare Page Size (2 KB – 16 KB)
Shared Memory > 4 GB
NONPDQ-Queries
Backup & Restore (Table Level Restore,
Renamed Restore, ontape auf STDIO)
Erweiterung der Enterprise Replikation
Mit diesem durchweg positiven Fazit schlie­
ßen wir nun die Reihe „IBM Informix Dynamic
Server 10.0 Neuheiten“ ab.
Allerdings können Sie hier schon bald weite­
re, wichtige Informationen zum Thema IBM In­
formix lesen, denn im kommenden Jahr wird be­
reits das nächste Release, Codename „Chee­
tah“ (engl.: Gepard), des IBM Informix Dyna­
mic Server auf den Markt kommen.
Data Definition
Language (DDL)
Über DDL-Kommandos werden Datenstrukturen
gepflegt (z. B. Tabellen anlegen oder löschen).
ETL
ETL steht für Extract, Transform, Load und be­
zeichnet einen Prozess in einer Data-Ware­
house Umgebung.
Quiescent Mode
Informix Wartungsmodus. Für Verwaltungsauf­
gaben kann nur noch der Benutzer Informix auf
den Datenbankserver zugreifen. Allerdings er­
folgt kein Zugriff auf Datenbanken, d. h. es kön­
nen keine SQL-Befehle abgesetzt werden.
Binary Large
Object (BLOB)
Datentyp zur Aufnahme binä­rer Daten inner­
halb der Datenbank (z. B. Programme, Grafi­
ken etc.).
Smart Large
Object (SBLOB)
SBLOB ist ein Typ für Speicherbereiche, die ne­
ben BLOBs auch CLOBs aufnehmen können.
Online Transaction Processing
(OLTP)
Oft handelt es sich hierbei um Multiuser-Anwen­
dungen zur Datenerfassung oder Datenaktuali­
sierung, die eine Antwortzeit in Bruchteilen von
Sekunden verlangen.
Batch
Abarbeitung vieler kleiner Einzeloperationen
(Stapelverarbeitung).
Enterprise Replikation (ER)
Spezielle Informix Funktion, die der Daten­repli­
kation dient.
Fordern Sie uns! Wir unterstützen Sie gerne bei der Umsetzung
der neuen Funktion bzw. bei der Migration auf das neue IBM Infor­
mix Release 10.0.
Guido Saxler und Thorsten Schuhmacher ([email protected]).
Seminar: Informix Dynamic Server Administration
Termine:
Der Teilnehmer lernt, Informix Dynamic Server (IDS)
Datenbanksysteme zu konfigurieren und zu admi­
nistrieren. Darüber hinaus erlernt er den Einsatz der
IDS-Werk­zeuge und Basis-Tuningmaßnahmen durch­
zuführen.
19.02.2007-23.02.2007in Wiesbaden
11.06.2007-15.06.2007in Wiesbaden
17.09.2007-21.09.2007in Wiesbaden
03.12.2007-07.12.2007in Wiesbaden
Zielgruppe
Inhalte
Datenbankadministratoren, Programmierer und Soft­
wareentwickler, die ihre Kenntnisse aus dem Einfüh­
rungsseminar „Informix SQL“ (DB-INF-01) vertiefen
und ein IDS-System administrieren möchten.
Voraussetzungen
IT-Grundkenntnisse und tiefergehende Kenntnisse
des Betriebssystems Unix oder Windows. SQLGrundkenntnisse oder Teilnahme am Seminar „In­
formix SQL“ (DB-INF-01).
Dauer:5 Tage
Preis: 1790,00 € zzgl. ges. MwSt.
ORDIX News 1/2007
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Produktübersicht, allgemeine Begriffsdefinitionen
Software-Installation, Initialisierung eines IDS-Systems
Die Multi-Threaded-Server Architektur
Tuning-Möglichkeiten
Sperrmechanismen, Logging- und Recovery-Mechanismen
Der Optimizer
Das System Monitoring Interface (SMI)
Funktionen des Tools Onmonitor
IDS-Werkzeuge: onstat, oncheck, onunload etc.
Global Language Support
Datenreplikation: Einführung und Konzept
Parallel Server Architecture
Grundlagen Backup und Recovery
Übungen
33
Betriebssysteme – Titelthema
Solaris 10 New Features:
ZFS – Das ultimative Dateisystem
An dieser Stelle wurden bereits einige Neuerungen von Solaris 10 vorgestellt, z. B. Trace (ORDIX News 4/2005
Seite 12 und 1/2006 Seite 36). Seit einiger Zeit ist das lang angekündigte Dateisystem ZFS bereits als Open
Source in der freien OpenSolaris-Version enthalten. Ab dem Release 10 06/06 ist es nun auch Bestandteil der
offiziellen Betriebssystem-Version.
Dieser Artikel richtet sich an Solaris Administratoren, die sich mit
den Neuigkeiten von Solaris 10 beschäftigen möchten und diese
Themen schnell in der Produktion einsetzen wollen.
Höher, schneller, weiter ...
Das neue Dateisystem ist in vielerlei Hinsicht außergewöhnlich.
Zunächst einmal ist der Dimensionsvorstoß zu nennen. ZFS soll
ein Symbol für bisher unerreichte Größenordnungen sein. Der Na­
me ZFS leitet sich von der Vorsilbe Zetta (1021) ab; dies entspricht
ca. 270 Byte und markiert damit noch keineswegs das „Ende der
Fahnenstange“ dieses 128-Bit Dateisystems.
ZFS arbeitet, wie andere moderne Dateisysteme, transaktions­
orientiert. Bereits beim UFS wurde im Laufe der Zeit ein LoggingMechanismus implementiert, der anfangs durch die Mount-Op­tion
„logging“ aktiviert wurde.
Bei Solaris 10 ist der Logging-Mechanismus standardmäßig akti­
viert und muss somit nicht mehr explizit angegeben werden. Bei
einem Systemabsturz wird damit eine ansonsten zeitaufwändige
Konsistenzprüfung überflüssig.
Die Bezeichnung des beim ZFS verwendeten Transaktionsmodells
von Sun Solaris lautet „copy-on-write“ (COW). Das COW-Prinzip
soll darüber hinaus auch deutliche Performance-Gewinne gegen­
über herkömmlichen Unix-Dateisystemen bringen. Hierzu gibt es
bisher aber noch zu wenig Praxiserfahrungen, als dass genaue,
zuverlässige Aussagen getroffen werden könnten.
Moderne Administration
Mit dem neuen ZFS soll der administrative Aufwand bezüglich der Ar­
beit mit Plattenspeichern verringert werden. Zum einen ist der Aspekt
der Dateisysteme zu nennen. Waren bisher eine Reihe von Arbeits­
schritten und entsprechend viele Kommandos
nötig, um den Benutzern Plattenplatz zur Ver­
fügung zu stellen (format(1m), mkfs(1m),
newfs(1m), mount(1m), quota(1m),
chkfs(1m) etc.), so genügen bei ZFS zwei
Befehle: zfs(1m) und zpool(1m).
Dieser Vorteil bei der Übersichtlichkeit wird al­
lerdings durch die Vielzahl der Subkomman­
dos, die verwendet werden können/müssen,
wieder wettgemacht.
Als echter Vorteil kann aber gewertet werden,
dass man die ZFS-Dateisysteme nicht mehr
in klassischen Konfigurationsdateien, wie z. B.
/etc/vfstab pflegen muss. Allerdings kann
man auf diese dennoch nicht ganz verzich­
ten, da bisher noch nicht von ZFS gebootet
werden kann.
Integrierter Volume Manager
Des Weiteren beinhaltet ZFS einen Volume
Manager, mit dem sehr flexibel und auf einfa­
che Weise die Verwaltung des Plattenplatzes
gehandhabt werden kann. Als Redundanz­
level werden Mirroring und RAID-Z angeboten.
RAID-Z ist dem klassischen RAID-5 ähnlich, ar­
beitet aber mit variablen Stripe-Größen.
Erste Schritte
Am Beispiel in Abbildung 1 wird die Admini­
stration von ZFS kurz angedeutet: Zunächst
wird definiert, welcher Plattenplatz für ZFS zur
Verfügung gestellt werden soll. Dies kann ent­
weder eine ganze Platte, eine Partition, oder –
(a) root@sol11:/# zpool create bollog /dev/dsk/c0d0s7
(b) root@sol11:/# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
bollog 1.18G 51.5K 1.18G 0% ONLINE (c) root@sol11:/# df -h /bollog
Filesystem
size
used avail capacity Mounted on
bollog 1.1G 24K 1.1G 1% /bollog
(d) root@sol11:/# zfs create bollog/otto
(e) root@sol11:/# zfs set mountpoint=/export/home/otto bollog/otto
(f) root@sol11:/# zfs destroy bollog
Abb. 1: Mit einem Kommando wird ein Storage-Pool erzeugt, ein Filesystem angelegt und eingehängt.
34
ORDIX News 1/2007
Betriebssysteme
nur zu Testzwecken zu empfehlen – eine Da­
tei sein (a). Mit dem list-Kommando kann
man sich das Ergebnis ansehen (b).
Gleichzeitig wird implizit ein Dateisystem auf
diesem Pool angelegt und dieses ohne wei­
tere Aktionen auch direkt (standardmäßig mit
gleichem Namen) im Root-Verzeichnis ein­
gehängt (c). In diesem Pool können weitere
Dateisysteme erzeugt werden (d), die aber
auch an anderer Stelle eingehängt werden
können (e).
Enthält ein Verzeichnisbaum Z-FileSysteme,
lassen sie sich wie gewohnt mit dem Komman­
do df(1M) darstellen (Abbildung 3).
Interessant ist hierbei aber Folgendes: Ähn­
lich wie beim tmpfs, wo die einzelnen RAMDisks den gesamten freien Speicher „sehen“,
sind bei den Dateisystemen aus dem Z-Pool
die Obergrenzen des Plattenplatzes zunächst
nur durch das Gesamtvolumen des gemein­
samen Pools vorgegeben.
Ebenso muss man beim RAID-Z auf der Hut
sein: Ein unbenutzter Pool zeigt als Kapazität
die Summe der darunter liegenden Platten an.
Aber erst, wenn tatsächlich Platz verbraucht
wird, sieht man den für RAID5 typischen – und
auch beim RAID-Z zu Buche schlagenden –
Verschnitt von 1/n Plattenanteilen (siehe Ab­
bildung 4).
Achtung: Durch Auflösen des zugrunde lie­
genden Pools werden ohne weitere Nachfra­
ge (!) alle darauf aufbauenden Strukturen zer­
stört (f). Bleibt zu hoffen, dass hier in Zukunft
ein Sicherheitsmechanismus eingebaut wird,
der arglos abgesetzte Kommandos nicht zur
Katastrophe ausarten lässt.
Mit den gleichen Kommandos lässt sich auch
ein Spiegel einrichten (siehe Abbildung 2).
Snapshot und Rollback
Neben den oben genannten Eigenschaften ist
auch die Snapshot- und Clone-Funktionalität
hervorzuheben. Dadurch wird es nun sehr leicht
möglich, in kurzer Zeit Dateisysteme zu duplizieren und read-only
zu öffnen oder als Clone read-write bereitzustellen.
Ein Snapshot belegt zum Zeitpunkt des Anlegens keinen Platten­
platz, sondern wächst erst dann, wenn Änderungen an dem zugrun­
de liegenden Dateisystem vorgenommen werden. Ebenso können
Snapshots dazu verwendet werden, ein Dateisystem zu bestimm­
ten Zeitpunkten zurückzusetzen. Auch in diesem Punkt überstei­
gen die Möglichkeiten von Solaris 10 deutlich die Möglichkeiten,
die bisher zur Verfügung standen (fssnap(1m)).
Weitere Neuigkeiten
Natürlich werden auch klassische Eigenschaften wie Quota unter­
stützt, um den Verbrauch an Plattenplatz nach oben zu beschrän­
ken, aber auch andere Eigenschaften, wie z. B. die Zusicherung
von Mindestplatz in einem Dateisystem, sind hier vorhanden.
Auch die Handhabung von NFS-Freigaben sind nun direkt im ZFS
integriert. Außerdem ist eine Erweiterung der ACLs für NFS und
# zpool create bollog mirror c1t1d0 c2t1d0 \
spare c1t2d0 c2t2d0
# zpool status bollog
pool: bollog
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
bollog ONLINE 0 0 0
mirror ONLINE 0 0 0
c1t1d0 ONLINE 0 0 0
c2t1d0 ONLINE 0 0 0
spares
c1t2d0 AVAIL
c2t2d0 AVAIL
Abb. 2: Anlegen eines Spiegels mit zwei zusätzlichen Spare-Platten.
root@sol11:/# df -hF zfs
Filesystem size
used avail capacity Mounted on
bollog 4,2G 28K 4,2G 1% /bollog
bollog/fs1 4,2G 24K 4,2G 1% /bollog/fs1
bollog/fs2 4,2G 24K 4,2G 1% /bollog/fs2
bollog/fs3 4,2G 24K 4,2G 1% /bollog/fs3
Abb. 3: Die Summe des verfügbaren Speicherplatzes ist nicht gleich
der Summe der Einzelteile.
root@sol11:/# zpool create -f bollogz raidz c0d0s3 c0d0s4 c0d0s5
root@sol11:/# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
bollogz 1.16G 141K 1.16G 0% ONLINE root@sol11:/# mkfile 200m /bollogz/200mfile
root@sol11:/# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
bollogz 1.16G 300M 884M 25% ONLINE -
Abb. 4: Ein Z-Pool wird aus drei Slices à 400 MB erzeugt. Erst wenn Daten im Pool abgelegt werden, wird der Redundanz
Tribut gezollt; der Platzverbrauch ist 50 Prozent höher als erwartet!
ORDIX News 1/2007
35
Betriebssysteme
ZFS vorgenommen worden. Und statt, wie bisher, mit Spezialkom­
mandos zu arbeiten (getfacl(1), setfacl(1)), ist die Funk­
tionalität der generischen Kommandos ls(1) und chmod(1) zu
diesem Zweck erweitert worden. Sehr praktisch!
Ein Web-basiertes Management Tool kann bei der Administration
unterstützend eingesetzt werden und rundet das Gesamtbild einer
Glossar
ACL
Access Control List. Eine über die übliche UnixBe­rechtigung hinausgehende Spezifizierung von
Zugriffsrechten auf Dateiobjekte.
Clone
Duplikat eines Filesystems. Kann lesend und schrei­
bend geöffnet werden.
Volume Manager Software, die eine logische Sicht auf physikalische
Speicherbereiche ermöglicht.
Stripes
Unter Striping versteht man die zyklische Vertei­
lung von Daten auf mehreren Platten. Die Einhei­
ten, mit denen die Daten abgelegt werden, werden
als Stripe-Größe oder kurz Stripes bezeichnet.
Snapshot
Abbild eines Dateisystems zu einem bestimmten
Zeitpunkt. Kann nur lesend verwendet werden.
Spare-Platten
Platten, die bei Ausfall von Komponenten als Er­
satz vorgesehen sind und dann automatisch ein­
konfiguriert werden.
Tmpfs
Ein Dateisystem das auf virtuellem Speicher ba­
siert und damit besonders performant ist. Bei an­
deren Betriebssystemen ist dies auch als RAMDisk bekannt.
RAM-Disk
Virtueller und temporärer Datenträger im Arbeits­
speicher eines Computers. Bei Solaris wird das zu­
grunde liegende Dateisystem als tmpfs bezeichnet.
zentralen und einfachen Administration ab. Er­
wähnenswert ist an dieser Stelle die Tatsache,
dass bei der Verwendung der GUI auch gleich
immer das entsprechende CLI-Kommando mit
ausgegeben wird, das dann direkt als Skript
abgespeichert werden kann.
Fazit
Mit dem ZFS ist Sun Microsystems ein großer
Wurf gelungen. Viele Ansätze sind sehr viel­
versprechend, müssen aber in der Tat noch
weiter vorangetrieben werden, um wirklich pro­
duktiv eingesetzt werden zu können.
Die etwas gewöhnungsbedürftige, aber einfa­
che und dem Solaris10-Stil konsequent ange­
passte Handhabung von ZFS überzeugt eben­
so wie die erweiterte Snapshot-Funktionalität
und die Integration eines Volume Managers in
einem Werkzeug.
Der schöne Ansatz wird aber leider noch durch
einige ungelöste, technische Hürden getrübt:
Zum einen kann das Solaris-System bisher
nicht von ZFS gebootet werden. Dadurch ist
man momentan noch gezwungen, zweigleisig
zu fahren und auch weiterhin mit klassischen
Dateisystemen zu arbeiten.
Andererseits ist auch das Zusammenspiel von
ZFS mit Zonen noch sehr unbefriedigend, so
dass man abwarten muss, was das nächste
Release an Verbesserungen bringen wird.
Roger Niemeyer ([email protected]).
Seminar: Solaris 10 für erfahrene Systemadministratoren
Dieses Seminar vermittelt den Teilnehmern sämtliche Kenntnisse über die
Funktionalitäten des Solaris 10 OS bezüglich Installation, System Manage­
ment, DTrace und Netzwerkfähigkeiten.
Zielgruppe
Systemadministratoren, die mit wichtigen administrativen Aufgaben im So­
laris-Umfeld betraut sind und insbesondere die zusätzlichen Funktionen
der Solaris 10 Architektur kennen lernen wollen.
Voraussetzungen
•
•
•
•
Gute Kenntnisse der Solaris 8 oder 9 Architektur.
•
•
Dauer:5 Tage
Preis: 1890,00 € zzgl. ges. MwSt.
•
Termine:
•
12.02.2007-16.02.2007in Wiesbaden
23.07.2007-27.07.2007in Wiesbaden
17.09.2007-21.09.2007in Wiesbaden
26.11.2007-30.11.2007 in Wiesbaden
36
Inhalte
•
•
Neuerungen bei der Installation von Solaris 10
inklusive Flasharchive
Zonenkonzept zur Kapselung von Anwendun­
gen: Konzept, Befehle, Nutzung und Adminis­
tration von Zonen
DTrace zur Fehler- und Performance-Analyse:
Funktionsweise, sinnvolle Anwendungen
Neuerungen im Netzwerkumfeld inklusive
NFS-4, Sicherheitsthemen und Paketfilter
Authentifizierungsmethoden, insbes. LDAP
Neuerungen bei File-Systemen und deren
Eigenschaften
Neuerungen bei Befehlen, Konfiguration, Admi­
nistration und Administrationswerkzeugen z. B.
auch Angabe von möglichen Grenzwerten
Service Management Facility als Ablösung her­
kömmlicher Resource-Control-Skripte:
Konzepte, Befehle, Hinzufügen neuer Dienste
und Administration bestehender Dienste
ZFS (Zetabyte Filesystem) bei Verfügbarkeit
Übungen
ORDIX News 1/2007
Titelthema – Datenbanken
IBM DB2 UDB Version 9.1 – New Features (Teil I)
Codename „Viper”
Im Juli 2006 war es endlich soweit: DB2 Version 9, von IBM liebevoll auf den Codenamen „Viper“ getauft,
wurde zum Download angeboten. So stand einer ersten Erkundungstour nichts mehr im Wege. Um die vielen
Neuerungen überhaupt erstmal kennenzulernen, gibt dieser Artikel zunächst nur einen allgemeinen Überblick
über die aktuellste DB2 UDB Version 9.1. Technische Einzelheiten und Details zur Verwendung und zum Umgang mit den neuen Features erfahren Sie in einer der folgenden Ausgaben der ORDIX News.
Überblick
Die interessanten Neuerungen des Datenbank­
servers betreffen die Bereiche:
•
•
•
•
•
Installation
Performance
Sicherheit
Datenbankverwaltung
Architektur/Datenmodell
Installation
Allgemein
Ab der Version 9.1 können mehrere DB2-Ins­
tallationen und Fix Packs der gleichen Version
auf einem System installiert werden. Biswei­len
war an eine Koexistenz nicht zu denken, da der
Installationspfad des Datenbanksystems fest
vorgegeben war.
Im Installationsprozess der neuen Version hin­
gegen kann der DBA das Verzeichnis selbst
auswählen.
In der Vergangenheit war es lediglich möglich,
verschiedene DB2-Versionen (7, 8, ...) auf ei­
nem System zu installieren. Probleme gab es
bei den älteren Versionen aber, wenn Unter­
versionen oder Fix Packs installiert werden
sollten.
Um diese zu umgehen, musste man sich so ge­
nannter „Alternate Fix Packs“ bedienen, die in
andere Verzeichnisse installiert werden konn­
ten. Mit den Standard CDs und Fix Packs war
dies allerdings nicht erlaubt.
Unix
Für Unix-Systeme wurde das DB2-Imagefor­
mat auf .tar.gz geändert. Das hat zur Fol­
Dieser Artikel richtet sich an Datenbank-, Systemadministrato­
ren und Softwareentwickler.
ge, dass Dienstprogramme wie pkgadd oder rpm nicht mehr ge­
nutzt werden können, um sich installierte DB2-Produkte anzeigen
zu lassen. Stattdessen wurde der DB2-Befehl db2ls eingeführt.
Ab der Version 9.1 ist dies die einzige Möglichkeit, um installierte
DB2-Produkte abfragen zu können (siehe Abbildung 1).
Windows
Auf Windows-Systemen ist eine Installation nun auch ohne die Ad­
ministrator-Berechtigung möglich. Hierzu kann man die Windows
XP Betriebssystem-Funktion für die „erweiterten Zugriffsrechte“ nut­
zen und die Installation einem „Hauptbenutzer“ oder einem „ein­
geschränkten Benutzer“ erlauben.
Performance
ROW COMPRESSION
Die interessanteste Neuerung im Bereich Performance ist die so
genannte ROW COMPRESSION. Sie erlaubt es, einzelne Zeilen
einer Datenbanktabelle zu komprimieren.
Diese neue Komprimierungsmethode ist Wörterbuch-basiert. Für
die Komprimierung bzw. Dekomprimierung von Daten werden intern
symbolische Tabellen verwendet, die gemeinsame Sequenzen von
aufeinander folgenden Bytes von Zeilen speichern. Dadurch muss
ein mehrmals vorkommender Wert nur einmal gespeichert werden
(siehe Abbildung 2).
Sicherheit
RESTRICTIVE
Mit der Version 9.1 wurde die Option RESTRICTIVE für die CREATE
DATABASE-Anweisung eingeführt. Durch diesen Schalter kann ver­
hindert werden, dass die Standard Zugriffsrechte createtab,
bindadd, connect und implicitschema für die Gruppe public
beim Anlegen einer Datenbank automatisch vergeben werden.
CREATE DATABASE DBV91 RESTRICTIVE;
inst91@admiral:/home/inst91 # db2ls
Install Path Level Fix Pack Special Install Number Install Date
----------------------------------------------------------------------------------/opt/db2/V9.0 9.0.0.0 0 Tue Aug 1 02:51:31 2006
/opt/db2/V9.1 9.1.0.0 0 Tue Aug 1 03:07:05 2006
Abb. 1: Der Befehl db2ls zum Abfragen von installierten DB2-Produkten.
ORDIX News 1/2007
37
Datenbanken
Der einzige, der dann Zugriff auf die Datenbank hat, ist der Erstel­
ler selbst. Alle weiteren, gewünschten Berechtigungen und Zugriffs­
rechte müssen vom Eigentümer explizit vergeben werden.
SETSESSIONUSER-Berechtigung
Bei der Version 8 konnten Benutzer mit DBADM- oder SYSADMBerechtigung unter Verwendung des SET SESSION AUTHORIZATION-Kommandos beliebig Identitäten wechseln und unter ei­
ner anderen Benutzer-ID arbeiten. Durch die neue SETSESSION­
USER-Berechtigung wird diese Freiheit genommen.
Nun dürfen nur noch Benutzer, die über eine SETSESSIONUSERBerechtigung verfügen, einen solchen „Identitätswechsel“ zur ihnen
freigegebenen User-ID durchführen.
Um allerdings die Abwärtskompatibilität zu gewährleisten, bekom­
men Benutzer mit DBADM-Berechtigung nach der Migration auf
die neue Version automatisch die SETSESSIONUSER-Berechti­
gung für die Gruppe public erteilt.
Zeitz, Abt.12,
15000, Projekt A
Zeitz,(01),15000,(02)
Datensätze in
der Tabelle
Datensatz 2
Gruber, Abt.12,
01
Abt.12
02
Projekt A
03
Gruber,(01),18000,(02)
...
Interne
symbolische
Tabelle
18000, Projekt A
Abb. 2: ROW COMPRESSION zum Komprimieren einzelner Zeilen in
einer Datenbanktabelle.
Name
...
...
... DB2SECURITYLABEL
1
Label A
2
Label A
3
Label C
Die SECADM-Berechtigung selbst kann nur
vom Eigentümer einer Datenbank vergeben
werden. Auch Benutzer, die anderen adminis­
trativen Gruppen (DBADM, SYSADM) zugeord­
net sind, dürfen dieses Recht nicht vergeben.
LBAC
LBAC steht für „Label Based Access Control“
und ermöglicht die Vergabe von Lese- und
Schreibzugriffsrechten für einzelne Zeilen oder
Spalten einer Datenbanktabelle.
4
Label B
5
Label A
Möchte ein Benutzer dann auf Datensätze zu­
greifen, so wird sein „security label“ mit dem
der Datensätze verglichen und er bekommt nur
solche angezeigt, bei denen eine Übereinstim­
mung vorhanden ist. Bei allen anderen Daten­
sätzen sieht es für den Benutzer so aus, als ob
diese nicht vorhanden wären.
Die einzelnen „security labels“ werden einer
so genannten „security policy“ zugewiesen, die
wiederum Bestandteil einer Tabelle ist. Dabei
gilt es zu beachten, dass eine Tabelle immer
nur eine „security policy“ besitzen kann. Abbil­
dung 3 zeigt eine vereinfachte Darstellung.
Datenbankverwaltung
Automatisierung
Automatisierung bedeutet für den DBA weni­
ger Administrationsaufwand. Mit DB2-Version
9.1 soll das mit zusätzlichen Erweiterungen zu
den bereits bestehenden Automatismen er­
reicht werden.
Tabelle
Label A
Label B
User 1 - Label A
Label C
User 2 - Label C
Label D
security policy
Abb. 3: LBAC-Security ermöglicht den Zugriff.
38
Zusätzlich erlaubt diese Qualifikation, die Ei­
gentumsrechte von Datenbankobjekten zu
ändern und die SETSESSIONUSER-Berech­
tigung zu vergeben.
Dabei werden sowohl Zeilen und Spalten als
auch Benutzern so genannte „security labels“
zugewiesen.
Datensatz 1
Nr.
SECADM-Berechtigung
Die SECADM-Berechtigung zählt ebenfalls zu
den Neuerungen und steht sehr eng im Zu­
sammenhang mit der LBAC-Funktion (s. u.).
Zur Konfiguration von LBAC ist diese Berech­
tigung nämlich zwingend erforderlich.
So nimmt der Datenbankserver zum Beispiel
selbstständig Konfigurationsanpassungen im
Bereich der Speicherverwaltung und des Buf­
ferpools vor oder aber erstellt automatisch Sta­
tistiken über das Datenbanksystem, auf die der
DBA dann zugreifen kann.
Tabellenpartitionierung
Hinter der Tabellenpartitionierung verbirgt sich
die Speicherung von Tabellendaten in mehr als
ORDIX News 1/2007
Datenbanken
einem Speicherobjekt (Partition). Aufgrund des
Inhaltes einer Spalte erfolgt dann die Zuwei­
sung des Datensatzes zu einer Partition.
Dem DBA soll somit die Verwaltung von be­
sonders großen Datenbanken erleichtert wer­
den. Eine Tabelle mit Umsatzzahlen kann so
zum Beispiel in vier Partitionen unterteilt wer­
den, so dass jede der Partitionen logischer­
weise die Umsatzzahlen eines Quartals auf­
nehmen würde.
Der Vorteil von partitionierten Tabellen besteht
in der Regel darin, bei Datenbankabfragen ein
schnelleres Ergebnis zu liefern, da nicht ge­
wünschte Daten eventuell erst gar nicht durch­
sucht werden. Abhängig ist dies natürlich von
der where-Bedingung des SQL-Statements.
Zusätzlich kann die Tabellenpartitionierung
auch mit bereits bestehenden Datenorgani­
sationsschemata, z. B. mit der Datenpartitio­
nierungsfunktion (DPF) oder mit mehrdimen­
Datenbank
sionalem Clustering (MDC) kombiniert werden, um eine noch bes­
sere Leistung der Datenbank zu erzielen.
Architektur/Datenmodell
XML als Datentyp
In Sachen Architektur hat sich in der neuen Version einiges geändert.
Neben dem relationalen Datenmodell existiert nun ein zusätzliches
XML-Datenmodell, das die Speicherung von XML-Daten innerhalb
einer Datenbank auf eine neue Art und Weise ermöglicht.
Bislang gab es zwei Optionen zum Speichern von XML-Daten:
• als Dokument (.xml-Datei) in einer Tabellenspalte vom Typ BLOB
• durch Zerlegung in das relationale Datenmodell
Das XML-Datenmodell basiert auf dem neuen Datentyp XML. DB2
bietet die Möglichkeit, eine Tabellenspalte von eben diesem XMLTyp zu deklarieren. Innerhalb einer solchen Spalte werden XMLDaten dann nicht als .xml-Datei, sondern in „geparster“ Form in
einer Baumstruktur abgelegt (siehe Abbildung 4).
XQuery & SQL/XML
Bei XQuery handelt es sich um eine Abfragesprache für XML-Da­
ten, die vom W3C entwickelt worden ist. IBM verwendet diese Ab­
fragesprache in DB2 9.1, um Daten, die vom Datentyp XML gespei­
chert wurden, aus der Datenbank ermitteln zu können.
Neben der enormen Flexibilität bietet XQuery zusätzlich den Vor­
teil, dass diese Sprache zusammen mit bzw. parallel zu SQL ver­
wendet werden kann. Dadurch kann zum einen auf die ebenfalls
flexible XML-Struktur zugegriffen werden. Zum anderen besteht die
Möglichkeit, relationale Daten mit XML-Daten zu mischen.
Relationales
Datenmodell
XML
Datenmodell
Abb. 4: Datenmodelle im Vergleich.
•
•
•
•
Fix Packs ermöglichen eine Installation
von DB2.
db2_deinstall ist Bestandteil der Ins­
tallation (war bisher nur auf der ProduktCD vorhanden).
Anweisung transfer ownership ändert
das Eigentumsrecht von Objekten.
Unterbrochene Recoveries können wieder
gestartet werden.
Abb. 5: Diverse, weitere Neuerungen.
Glossar
XQuery Steht für „XML Query Language“ und
ist eine Abfragesprache für XML-Da­
ten aus einer Datenbank.
W3C
Auch „World Wide Web Consortium“
genannt. W3C ist ein Gremium zur
Standardisierung für World Wide Web
betreffende Techniken, wie zum Bei­
spiel HTML und XML.
ORDIX News 1/2007
Während der Abfrage selbst nimmt eine Sprache die Position der
Primärsprache ein, die andere wird Sekundärsprache. Die Reihen­
folge, ob zuerst XQuery oder SQL, ist jedem selbst überlassen. Zu
beachten gilt es allerdings, dass XQuery im Gegensatz zu SQL
case-sensitive ist.
Fazit
Neben den vielen kleineren Erweiterungen sind der Datentyp XML
und die damit verbundenen, neuen Abfragemethoden „XQuery“
und „SQLX“ mit Sicherheit die Bereiche, die das meiste Interes­
se auf sich ziehen werden. Ob sich XML als Format für die Daten­
speicherung innerhalb von Datenbanken behaupten kann, bleibt
jedoch abzuwarten.
Wie bereits erwähnt, war dieses nur ein erster Überblick über die
Neuerungen in DB2. Es gibt noch zahlreiche weitere, interessante
Implementierungen (siehe Abbildung 5). Hierzu jedoch mehr in einer
der kommenden Ausgaben. Dann erfahren Sie Details zu den Neue­
rungen sowie technische Hintergründe zu den neuen Funktionen.
Sie wünschen vorab weitere Informationen zur IBM DB2 Version 9.1?
Sprechen Sie uns an!
Thorsten Schuhmacher ([email protected]).
39
Java/J(2)EE
Vorstellung des Google Web Toolkits zur Programmierung von Ajax-Anwendungen
Ajax mit dem Google Web Toolkit
Google macht seit einiger Zeit mit schnellen und mächtigen Web-Anwendungen, wie Google Maps [1] und
Google Mail [2], Furore. Viele weitere Anwendungen sind noch in der Entwicklung. Interessierte können erste Eindrücke dieser Anwendungen in den Google Labs [3] gewinnen. Die meisten dieser Web-Anwendungen
und Services basieren auf der Ajax-Technologie, die in der letzten ORDIX News in Zusammenhang mit den
Ajax Tags vorgestellt wurde (siehe ORDIX News 3/2006, Seite 18).
Nun hat Google im Frühjahr ein Web Toolkit veröffentlicht, mit dem Ajax-Anwendungen programmiert werden können. Der Clou dabei ist, dass ausschließlich in Java programmiert wird. Die JavaScript Generierung
übernimmt der Compiler des Toolkits.
Dieser Artikel richtet sich an Java-Entwickler, die Web-Anwen­
dungen mit Ajax-Funktionalität ausstatten möchten.
Installation
Das Google Web Toolkit zur Entwicklung von Ajax-Anwendungen
ist auf den Google Web-Seiten [4] erhältlich: Als zip-File für Win­
dows oder als tar.gz-File für Linux. Nach dem Extrahieren des Ar­
chivs kann die Entwicklung beginnen.
Bestandteile des Toolkits
Das SDK besteht aus dem GWT Compiler, der JavaScript aus üb­
lichem Java Code erzeugt. Dazu greift er auf eine Klassenbibliothek
zurück, die ebenfalls mitgeliefert wird. Zusätzlich beinhaltet das Pa­
ket eine Laufzeitumgebung zum Testen der Anwendung und eine
Reihe von Beispielen zur Demonstration der Funktionalitäten.
Der GWT Compiler zum Generieren von JavaScript
Der GWT Compiler ist das Kernstück des Toolkits und generiert
JavaScript aus Java Code. Dazu muss der implementierte Java
Source Code kompatibel mit J2SE 1.4.2 sein. Das heißt, dass Ja­
va 5 Features nicht unterstützt werden.
Die GWT-Laufzeitumgebung zum Testen
von Anwendungen
Die GWT-Laufzeitumgebung besteht aus ei­
ner kleinen Untermenge der Standard Java
Laufzeitumgebung mit den Paketen java.lang
und java.util. Dies liegt daran, dass die über­
setzten Anwendungen im Browser lauffähig
sein müssen und Google nicht die komplette
JRE Runtime-Bibliothek in JavaScript nach­
bauen wollte bzw. konnte.
Der Entwickler sollte sich deshalb frühzeitig
anhand der mitgelieferten API-Referenz da­
rüber informieren, welche Funktionalitäten der
Standard VM genutzt werden können.
Web Mode und Hosted Mode
Das Google Web Toolkit stellt dem Entwick­
ler außerdem die folgenden zwei Skripte zur
Verfügung:
• MyApplication-compile.cmd
• MyApplication-shell.cmd
Einige Besonderheiten ergeben sich außerdem durch Einschrän­
kungen der Sprache JavaScript. Z. B. sind JavaScript-Anwen­
dungen „Single Threaded“, so dass das Java-Schlüsselwort „syn­
chronized“ keinen Effekt hat. Es gibt auch einige Einschränkungen
bezüglich der Datentypen.
So wird z. B. ein Java „long“ in eine JavaScript-Gleitkommazahl mit
zwei Stellen Präzision umgewandelt. Das Java Exception Hand­
ling kann verwendet werden, jedoch lässt sich kein Stacktrace aus
einer Exception extrahieren.
Abb. 1: Beispiel zur automatischen Vervollständigung mit dem GWT.
<module>
<inherits name="com.google.gwt.user.User"/>
<entry-point class="de.ordix.client.AutoCompleteTextBoxAsync"/>
<servlet path="/AutoCompletionServlet" class="de.ordix.server.AutoCompletionServlet"/>
</module>
Abb. 2: Konfiguration eines Moduls.
40
ORDIX News 1/2007
Java/J(2)EE
Mit dem ersten Skript wird die JavaScript-Über­
setzung durchgeführt. Es werden Dateien er­
stellt, die die Ausführung der Anwendung clientseitig im Browser ohne eine JVM ermöglichen.
Anwendungen laufen dann im so genannten
„Web Mode“.
Das zweite Skript sorgt für die Ausführung der
Anwendung in einer (eingeschränkten) JVM. Der
Java Code wird also nicht in JavaScript über­
setzt, sondern als gewöhnlicher Byte Code aus­
geführt. Dieser Modus ist sinnvoll bei der Ent­
wicklung, da das Debugging erleichtert wird und
die Zeit zum Übersetzen wegfällt.
Client- und server-seitiger Source Code
GWT-Anwendungen sind in client- und serverseitigen Code unterteilt. Der Client Code wird
von dem GWT Compiler in JavaScript über­
setzt und unterliegt deshalb den bereits be­
schriebenen Einschränkungen. Die zu über­
setzenden Sourcen werden in dem Paket my_
package.client abgelegt.
Des Weiteren gibt es die serverseitige Kom­
ponente. Sie unterliegt keinen Einschränkun­
gen und kann auf sämtliche Java Bibliotheken
zugreifen. Serverseitig kommen Servlets zum
Einsatz, die die Ajax Requests des Clients be­
arbeiten. Sie werden im my_package.serverPaket abgelegt.
Beispielanwendung mit automatischer
Vervollständigung
Im Folgenden wird beispielhaft auf die wich­
tigsten Komponenten einer GWT-Anwendung
eingegangen. Erstellt wird eine HTML-Seite mit
einer Text-Box.
Gibt der Benutzer in diese einen Buchstaben
ein, wird - asynchron - eine Liste von Auswahl­
mög­lichkeiten vom Browser geladen (siehe Ab­
bildung 1).
Erstellung des Grundgerüsts
Um das Grundgerüst einer GWT-Anwendung zu erstellen, liefert
das Framework ein Tool namens „Application Creator“ mit. Durch
den Aufruf des Befehls applicationCreator com.mycompany.
client.MyApplication werden sämtliche Dateien erstellt, die
zur Ausführung eines „Hello World“-ähnlichen Programms benö­
tigt werden. Auf diese Weise erhält man schnell die Basis für wei­
tere, individuelle Implementierungen.
Hilfreich ist dabei die Option -eclipse, über die ein Eclip­se-Pro­
jekt mit entsprechenden Launch- und Debug-Konfigurationen er­
stellt werden kann.
Konfiguration des Moduls
Jedes Modul (bzw. Projekt in der Eclipse IDE) verfügt über eine
zen­trale Konfigurationsdatei. Abbildung 2 zeigt eine einfache Kon­
figuration. Die Klasse User muss eingebunden werden, da sie
die Basisfunktionalität des Toolkits beinhaltet. Über das Element
<en­try-point> wird die Klasse angegeben, die beim Starten
des Moduls ausgeführt wird. Schließlich wird noch das Servlet de­
klariert, das die Requests des Clients beantwortet.
Die HTML-Seite
Um eine HTML-Datei mit Ajax-Funktionalität auszustatten, muss
das mit dem GWT erstellte Modul bekannt gegeben werden:
<meta name="gwt:module" content="mein_paket.MyApplication">
Zusätzlich wird die GWT JavaScript-Bibliothek benötigt:
<script language="javascript" src="gwt.js"></script>
Schließlich muss noch ein Platzhalter angegeben werden, in dem
die mit Ajax ausgestattete, grafische Komponente eingefügt wer­
den soll. Google nennt diese Komponenten „Widgets“. Eine Mög­
<table>
<tr>
<td id="slot"></td>
</tr>
</table>
Abb. 3: Platzhalter für Widgets setzen.
//Methode, die beim Starten des Moduls ausgeführt wird.
public void onModuleLoad() {
//Instanziierung eines Widgets
final AutoCompleteTextBoxAsync box = new AutoCompleteTextBoxAsync();
//Widget platzieren
RootPanel.get("slot").add(box); }
Abb. 4: Einstiegspunkt des Moduls.
public interface AutoCompletionDataService extends RemoteService {
public String[] getData(String match);
}
Abb. 5: Implementierung des RemoteService.
ORDIX News 1/2007
41
Java/J(2)EE
public interface AutoCompletionDataServiceAsync {
void getData(String match,AsyncCallback callback);
}
Abb. 6: Implementierung der asynchronen Schnittstelle.
public class TextBox implements KeyboardListener {}
Abb. 7: Verwendung eines KeyboardListeners.
//Wenn die Taste losgelassen wird:
public void onKeyUp(Widget widget, char key, int modifier) {
}
if (this.getText().length() > 0 ) {
//Hole die Auswahlliste auf Basis des eingegebenen Textes
getCompletionItems(this.getText());
Abb. 8: Reaktion auf Events.
lichkeit zur Definition eines Platzhalters ist die Vergabe einer ID,
wie in Abbildung 3 zu sehen ist.
Client-seitiger Source Code
Das Modul wird gestartet, sobald die HTML-Seite samt JavaScript
Code vom Browser geladen ist. Zunächst wird die Methode onModuleLoad ausgeführt (siehe Abbildung 4). In dieser Methode wird
ein neues Widget instanziiert und in die HTML-Seite eingebunden.
Das RootPanel repräsentiert hierbei die HTML-Seite.
Kommunikation mit dem Server
Damit der Client mit dem Server kommunizieren kann, wird von
Google ein „Remote Procedure Call“-Mechanismus bereitgestellt.
Dazu muss clientseitig das Interface RemoteService mit der De­
klaration der gewünschten Methode implementiert werden (sie­
he Abbildung 5).
Die Methode getData soll auf Basis der Benutzereingabe ein
Array an Auswahlmöglichkeiten zurückliefern. Die Benutzereingabe
wird als Argument String match übergeben. Diese Auswahl wird
dann im Zuge der automatischen Vervollständigung angezeigt.
Zusätzlich muss clientseitig noch ein weiteres Interface implemen­
tiert werden, das über Namenskonvention (hier AutoCompletion­
DataService mit Suffix Async) mit dem RemoteService in Bezieh­
ung steht. Dieses Interface signalisiert, dass es sich um einen asyn­
chronen Aufruf handelt. Deshalb hat die Methode getData in die­
sem Interface auch keinen Rückgabewert, sondern das Argument
AsyncCallback (siehe Abbildung 6).
Dieses Argument wird zu einem späteren Zeitpunkt mit dem Ergeb­
nis des Methodenaufrufs gefüllt.
Serverseitig wird dann die Methode getData implementiert. Dies
geschieht durch ein Servlet, das von der GWT-Klasse Remote­
ServiceServlet erbt. Remote­ServiceServlet ist ein übliches
HttpServlet, das auf den RPC-Mechanismus abgestimmt wurde.
42
Events und Listener
Grafische Komponenten werden im Google
Web Toolkit als „Widgets“ bezeichnet. Dem
Entwickler werden eine Reihe von Widgets
zur Verfügung gestellt. Es gibt unter anderem
Textboxen, Checkboxen, Textareas, Tabellen
usw. Auch eigene Widgets können implemen­
tiert werden. Ein Widget kann einen Listener
implementieren, der auf Events horcht (siehe
Abbildung 7).
Die Events werden durch den Benutzer aus­
gelöst, z. B. durch einen Mausklick oder einen
Tastendruck. Hat der Entwickler bereits Erfah­
rung mit Swing gesammelt, wird er sich mit den
Google Widgets schnell zurechtfinden.
Diverse Methoden können implementiert wer­
den, um auf die ausgelösten Ereignisse zu re­
agieren. Abbildung 8 zeigt die Methode, die
beim Loslassen einer Taste ausgeführt wird.
Sie überprüft, ob sich mindestens ein Buch­
stabe im Textfeld befindet und baut dann die
Auswahlliste neu auf. Dazu wird ein asynchro­
ner XMLHTTP Request durchgeführt, der in
der Methode getCompletionItems durch­
geführt wird.
Hier „geschieht“ Ajax:
Der XMLHTTP Request
Abbildung 9 zeigt die Schritte zur Durchfüh­
rung eines asynchronen XMLHTTP Request.
Entscheidend ist der Aufruf der Methode getData, die vom Remote­ServiceServlet im­
plementiert wurde. Als Argument wird einmal
das Suchmuster übergeben und ein Objekt der
Klasse AsyncCallback. AsyncCallback
beinhaltet zwei Methoden:
1. onSuccess: Was geschieht, falls der Re­
quest erfolgreich war?
2. onFailure: Was geschieht im Fehlerfall?
Diese beiden Methoden dürfen keinen Rück­
ga­bewert haben, da es sich um einen asyn­
chronen Request handelt und der Rückgabe­
wert erst zu einem späteren Zeitpunkt zur Ver­
fügung steht. Das Ergebnis des Requests wird
deshalb in Form des Arguments result vom
Framework übergeben. Die Methode update­
Choices sorgt schließlich für den Neuaufbau
der Auswahlliste.
Bewertung
Die generellen Vor- und Nachteile von Ajax-An­
wendungen wurden bereits in der letzten Aus­
gabe der ORDIX News dargelegt. Im Folgen­
den führen wir nun die Vor- und Nachteile des
Google Web Toolkits für Sie auf.
ORDIX News 1/2007
Java/J(2)EE
public void getCompletionItems(final String match) {
AutoCompletionDataServiceAsync dataService = (AutoCompletionDataServiceAsync)
GWT.create(AutoCompletionDataService.class);
ServiceDefTarget endpoint = (ServiceDefTarget) dataService;
String moduleRelativeURL = GWT.getModuleBaseURL() + “/AutoCompletionServlet”;
endpoint.setServiceEntryPoint(moduleRelativeURL);
dataService.getData(match,new AsyncCallback(){
public void onSuccess(Object result){
updateChoices((String[])result,match);
}
public void onFailure (Throwable caught){
Window.alert(“Unable to get data from server: “+caught.toString());
}
});
}
Abb. 9: Durchführung des XMLHTTP-Requests.
Nachteile
• Die Integration der GWT-Anwendungen in
eine bestehende Infrastruktur (z. B. Struts)
gestaltet sich schwierig, da die Servlets, die
die Requests serverseitig bearbeiten, eng in
den Google-RPC Mechanismus eingebun­
den sind. Die Servlets erben vom Remote­
ServiceServlet, was zu einer direkten Kolli­
sion mit Struts führt, da die Struts Servlets
die Action-Klasse erweitern.
• Die Klassenbibliothek des Google Web Tool­
kits ist freie Software und steht unter der Apa­
che Lizenz. Der Compiler, der JavaScript
aus den Java Sourcen erzeugt, wird binär
unter den „Google Web Toolkit Terms and
Conditions“ geliefert und ist somit eine Black
Box. Dies könnte sich als Nachteil heraus­
stellen, falls Google das Toolkit zukünftig
nur noch kostenpflichtig zur Verfügung stel­
len würde. Laut Google ist dies allerdings
nicht geplant.
Vorteile
• Das Toolkit stellt eine Reihe von Skripten
und Klassen zur Verfügung, die dem Ent­
wickler das Leben erheblich erleichtern. Ge­
rade die Kompatibilität des generierten Ja­
vaScripts mit unterschiedlichen Browsern
dürfte viele Tests ersparen. Laut Google
sollen GWT-Anwendungen in neueren Ver­
sionen des Internet Explorers, Firefox und
Safari identische Ergebnisse bringen.
• Ein weiterer Vorteil ist das komfortable De­
buggen. JavaScript Debugging ist zwar
möglich, jedoch nicht so ausgereift und
umfangreich wie das Debugging von Java
Code, z. B. in der Eclipse IDE.
ORDIX News 1/2007
Links
►
►
►
►
[1] http://maps.google.com
[2] http://mail.google.com
[3] http://labs.google.com
[4] http://code.google.com/webtoolkit/download.html
Glossar
Ajax
Asynchronous JavaScript and XML. Ajax ist ein Konzept,
das den asynchronen Austausch von XML-Nachrichten zwi­
schen Client und Server erlaubt, ohne dass eine Web-Seite
komplett neu geladen werden muss.
GWT
Google Web Toolkit. Eine Java-Entwicklungsumgebung zur
Erstellung von Web-Anwendungen auf Basis von Ajax.
Widgets Grafische (Software-)Komponenten wie z. B. Buttons, Text­
felder und Checkboxen.
RPC
Remote Procedure Call. Mechanismus zur Kommunika­tion
mit einem Server über ein Netzwerk.
JVM
Java Virtual Machine. Programm, in dem Java-Program­
me ausgeführt werden. Eine JVM ist vom Betriebssystem
abhängig, während das Java-Programm unabhängig vom
Betriebssystem ist.
• Typische Ajax-Probleme, wie Bookmarks und Browser-Back,
können auf einfache Weise gelöst werden. Über die GWT-Klasse
History können Tokens gesetzt und beim Browser-Back aus­
gelesen und entsprechend verarbeitet werden.
Fazit
Das Google Web Toolkit ermöglicht es, schnell und komfortabel
Ajax-Anwendungen zu programmieren und zu debuggen. Es gibt
viele Hilfestellungen und Bibliotheken, auf die der Entwickler zu­
rückgreifen kann. Trotz des Beta Stadiums macht das Toolkit einen
guten Eindruck. Es gibt bereits eine Reihe von Dokumenta­tionen
und Tipps im Internet. Problematisch ist die Integration der erstell­
ten Servlets in andere Frameworks wie z. B. Struts. Man darf ge­
spannt sein, wie sich die Akzeptanz des Toolkits entwickelt und wel­
chen Einfluss es auf die Web-Programmierung nehmen wird.
Jens Stahl ([email protected]).
43
Datenbanken
Migration von Oracle
LONG- zu LOB-Datentypen
Immer häufiger kommt es zu einer Vergrößerung des Datenvolumens innerhalb einzelner Tabellenspalten.
Bisher reichte für die Speicherung großer Volumen in der Datenbank der LONG- bzw. LONG RAW-Datentyp
aus. Durch ihre Beschränkung auf die Größe von zwei Gigabyte und ihre maximale Anzahl von einer LONGDatentypspalte pro Tabelle, ist es nun häufiger notwendig, zu einem größeren Datentypformat zu migrieren.
Hier bietet sich der LOB-Datentyp an, den wir in der ORDIX News 2/2006, Seite 14, bereits in Grundzügen vorgestellt haben. Im Folgenden wird dargestellt, wie eine Umstellung der Datentypen innerhalb der Datenbank
durchgeführt werden kann. Ebenso wird auf die Bedeutung der Konvertierung für PL/SQL eingegangen.
Der Artikel richtet sich an Datenbankadministratoren, die sich mit
der Migration von LONG- und LONG RAW-Datentypen zu den
LOB-Datentypen CLOB/NCLOB und BLOB beschäftigen.
Vorteile des LOB gegenüber dem LONG-Datentyp
Für eine Migration sprechen die folgenden Vorteile des LOB-Da­
tentyps gegenüber dem LONG-Datentyp:
• Die Anzahl der LOB-Spalten pro Tabelle ist unbegrenzt.
• Die Größe des zu speichernden Datenvolumens ist nicht auf
•
zwei Gigabyte, wie beim LONG-Datentyp, beschränkt.
LOB-Datentypen können bei Replikation eingesetzt werden.
Das Einfachste: Die ALTER TABLE Anweisung
Mit der ALTER TABLE Anweisung kann eine LONG-Spalte in eine
CLOB/NCLOB-Spalte geändert werden. Ebenso kann eine BLOBSpalte aus einer LONG_RAW-Spalte generiert werden (siehe Ab­
bildung 1).
• Dabei ist es möglich, ein DEFAULT-Constraint explizit anzu­
geben. Auch das Setzen der STORAGE-Klausel für die neue
LOB-Spalte ist erlaubt. Bereits vorhandene Constraints auf ei­
ner LONG-Spalte werden bei der Migration übernommen.
Einschränkungen des LOB-Datentyps
Bei der Migration ist zu beachten, dass LOB-Spalten im Gegensatz
zu LONG-Datentypen nicht in „geclusterten“ Tabellen enthalten sein
dürfen. Ebenso gilt, dass in der Auswahlliste
eines UPDATE OF Trigger keine LOB-Spalten
vorhanden sein dürfen. Es muss also vorher
geprüft werden, ob die zu migrierende Tabelle
diesen Triggertyp besitzt und in der UPDATE
OF-Klausel Bezug auf LONG- bzw. LONG RAWSpalten genommen wird.
Darüber hinaus ist zu beachten, dass bei der
Migration von LONG- zu LOB-Datentypen die
Indizes manuell neu aufgebaut werden müssen.
Besonders problematisch kann dies bei funk­
tionsbasierten Indizes sein. Wenn eine Applika­
tion damit arbeitet, muss sie nach der Migration
nicht angepasst werden.
Für einen DOMAIN-Index gilt, dass dieser vor
der Migration erst gelöscht werden muss! Für
die entsprechende Erweiterung ist dann der Neu­
eintrag vorzunehmen.
Re-Migration von LOB zu LONG
Es ist zu beachten, dass eine Konvertierung
über Alter Table wieder zurück von LOB zu
LONG nicht möglich ist. Ein Workaround bie­
tet dabei allerdings die Möglichkeit, die Daten
aus der LOB-Spalte über eine OCI-Applikation
in eine neu generierte LONG-Spalte einzule­
sen. Danach kann die LOB-Spalte wieder ge­
löscht werden.
Allgemeine Syntax:
ALTER TABLE [<schema>.]<table_name>
MODIFY ( <long_column_name> { CLOB | BLOB | NCLOB }
[DEFAULT <default_value>]) [LOB_storage_clause];
Beispiel:
CREATE TABLE mitarbeiter_lob (mitarbeiternr NUMBER, lob_foto LONG RAW);
ALTER TABLE mitarbeiter_lob MODIFY (lob_foto BLOB);
Abb. 1: Allgemeine Syntax und ein Anwendungsbeispiel für die Wandlung des Datentyps.
44
ORDIX News 1/2007
Datenbanken
Verwendung von utldtree.sql
Für die Prüfung einer Anwendung (z. B. Pa­
ckages), die sich auf LONG-Spalten bezieht,
ist der Einsatz des Skriptes utldtree.sql
sehr hilfreich. Damit wird geprüft, ob Teile der
Anwendung möglicherweise neu geschrieben
werden müssen. Zu finden ist das Skript im
Verzeichnis $ORACLE_HOME/- rdbms/admin.
Das Skript erlaubt, alle Datenbankobjekte zu
sehen, die rekursiv abhängig sind von einem
anderen Datenbankobjekt. Es werden dabei nur
diejenigen Datenbankobjekte angezeigt, für die
auch eine Zugriffsberechtigung besteht.
Die Dokumentation ist im Skript selbst hinter­
legt. Die Prüfung sollte immer vor der Migrati­
on der Tabellenspalten stattfinden. Das utldtree.sql Skript ist nur für PL/SQL erforder­
lich. Für SQL und OCI müssen die Bestand­
teile der entsprechenden Anwendung nicht ge­
ändert werden.
PL/SQL-Schnittstelle
Mit PL/SQL ist es möglich, die folgenden SQLStatements abzusetzen:
• SELECT INTO-Statement mit einer CLOB
•
Tabellenspalte in eine alphanumerische
Variable, wie z. B. CHAR, LONG, oder
VAR­CHAR2
SELECT INTO-Statement mit einer BLOB
Tabellenspalte in eine binäre Variable, wie
z. B. eine RAW und LONG RAW Variable
Ebenso ist es möglich, die folgenden Zuwei­
sungen vorzunehmen:
• CLOB-Variable zu einer VARCHAR2Variablen
• BLOB-Variable zu einer RAW-Variablen
• VARCHAR2-Variable zu einer CLOB•
Variablen
RAW-Variable zu einer BLOB-Variablen
Dadurch können Zuweisungen als aktuelle Pa­
rameterwerte mit einem LOB (CLOB, BLOB)
Datentyp zu einem formalen Parameter eines
anderen Datentyps (VARCHAR2, RAW) einer
Datenbankfunktion durchgeführt werden.
Ebenso ist der Aufruf von PL/SQL Built-In-Funk­
tionen mit LOB möglich. Die PL/SQL Built-InFunktionen, die den Datentyp CLOB als Ein­
gabeparameter und Rückgabewert benut­
zen, sind in Abbildung 2 dargestellt. In dieser
Übersicht der Funktionen bedeutet die An­
gabe „CNV“, dass erst implizit eine Konver­
tierung in einen alphanumerischen Datentyp
vorgenommen wird. Die Angabe „N/A“ bedeu­
ORDIX News 1/2007
Operator/Funktion
Unterstützt in SQL
Unterstützt in PL/SQL
||, CONCAT()
Ja
Ja
IS [NOT] NULL
Ja
Ja
BETWEEN
SUBSTR
ASCII
REGEXP_REPLACE
TO_DATE
TO_NUMBER
Nein
Ja
CNV
Ja
CNV
CNV
TO_TIMESTAMP
Nein
TO_LOB
N/A
COUNT
Nein
DECODE
CNV
NVL
Ja
DUMP
Nein
Ja
Ja
CNV
Ja
CNV
CNV
CNV
N/A
N/A
CNV
Ja
N/A
Abb. 2: Auszug aus den Konvertierungsfunktionen in SQL und PL/
SQL. Weitere Funktionen finden Sie im Internet unter [1].
TO_CLOB()
von VARCHAR2, NVARCHAR2 oder NCLOB nach
CLOB
TO_NCLOB()
von VARCHAR2, NVARCHAR2 oder CLOB nach
NCLOB
TO_BLOB()
von RAW nach BLOB
TO_CHAR()
TO_NCHAR()
CAST
von CLOB nach CHAR.
von NCLOB nach NCHAR
Unterstützt nicht direkt die Konvertierung. Es wird erst
implizit in einen alphanumerischen Wert oder RAW-Da­
tentyp konvertiert und erst dann in den entsprechenden
Zieldatentyp.
Abb. 3: Konvertierungsfunktionen für die explizite Datentypkonvertierung in PL/SQL.
tet, dass bisher keinerlei Angaben vorhanden sind. Zu beachten
ist dabei, dass im SQL-Umfeld nur bis 4 KB und im PL/SQL bis zu
32 KB dargestellt werden können.
Implizite Datentypkonvertierung
Besonders zu beachten ist, dass die implizite Datentypkonvertie­
rung auch in PL/SQL erlaubt ist:
• CLOB-Variablen nach VARCHAR2, CHAR oder LONG-Varia­
blen und umgekehrt.
• BLOB-Variablen nach RAW und LONG RAW-Variablen und
umgekehrt.
Die Konvertierung von NUMBER, ROW_ID, BINARY_INTEGER,
DATE und PLS_INTEGER nach LONG ist ebenfalls erlaubt. Aller­
dings gibt es nicht die Möglichkeit der impliziten Konvertierung zu
einem LOB-Datentyp. Hierzu ist es erforderlich, mit der Konvertie­
rungsfunktion TO_CHAR zu arbeiten. Erst dadurch wird erreicht,
dass eine Konvertierung innerhalb eines Programms fehlerfrei er­
folgt. Somit ist insbesondere der Quellcode von gespeicherten Da­
tenbankobjekten, wie Packages, Prozeduren, Funktionen und Trig­
gern, auf implizite Konvertierungen zu überprüfen.
45
Datenbanken
CREATE TABLE test_long (long_sp LONG); -- Wechsel von LONG nach LOB
DECLARE
var_1
VARCHAR2(100);
var_2 test_long.long_sp%type; -- Diese Variable wechselt von LONG nach CLOB
BEGIN
SELECT *
INTO var_2
FROM test_long;
var_1 := var_2; -- Wechsel von VARCHAR2 := LONG nach VARCHAR2 := CLOB
var_2 := var_1; -- Wechsel von LONG := VARCHAR2 nach CLOB := VARCHAR2
END;
/
Abb. 4: Verwendung von %TYPE und %ROWTYPE.
Glossar
LOB
Oracle Large Object. Oracle Datentyp zur Aufnah­
me großer Datenmengen (bis zu 128 Terabytes).
BLOB
Binary Large Object. Oracle Datentyp zur Aufnah­
me binärer Daten innerhalb der Datenbank (z. B.
Programme, Grafiken etc.).
Character Large Object. Oracle Datentyp für ein
Datenbankfeld zur Speicherung von großen Text­
daten (bis zu 4 GB).
National Character Large Object. Oracle Datentyp
zum Speichern langer alphanumerischer Felder
mit dem National Characterset der Oracle-Daten­
bank. Bis 4000 Byte werden inline gespeichert, bei
größeren Datenmengen wird außerhalb der Tabel­
lenstruktur in einem eigenen Segment gespeichert.
Oracle Datentyp zum Abspeichern langer Felder
mit alphanumerischem Inhalt. Die Speicherung
der Daten findet inline, also innerhalb der Tabel­
lenstruktur statt; maximal 2 GB Größe.
Oracle Datentyp zum Abspeichern von binären In­
formationen; bei Oracle maximal 2 GB Größe. Seit
Oracle 8 durch BLOB abgelöst.
CLOB
NCLOB
LONG
LONG RAW
OVERLOADING Speicherung von gleich benannten Funktionen oder
Prozeduren innerhalb der Datenbank, die sich nur
in Anzahl, Reihenfolge und/oder Datentyp unter­
scheiden.
BUILT-IN
Eingebaute Verarbeitungsfunktionalitäten inner­
halb von PL/SQL.
Link
► [1] Konvertierungsfunktionen: http://www.ordix.de/ORDIXNews/1_
2007/Datenbanken/oracle_lob_migration.html.
Overloading
Generell darf ein Overloading existieren, so­
lange ein Unterschied zweier Prozeduren be­
züglich Anzahl, Namen, Reihenfolge und/oder
Datentyp der formalen Parameter existiert.
Wir nehmen einmal an, es existierten vor der
Migration zwei Prozeduren mit gleichem Na­
men und nur mit der Differenzierung durch
LOB- und LONG-Datentyp. Nach einer Konver­
tierung von LONG zu LOB würden dann inner­
halb des Programms zwei Prozeduren mit glei­
cher Anzahl, Namen, Reihenfolge und Datentyp
der formalen Parameter existieren. Dies würde
einen Oracle-Fehler auslösen und somit dem
Konzept des Overloading widersprechen.
Verwendung von %TYPE und %ROWTYPE
Eine Besonderheit stellt die Parameterüberga­
be durch %TYPE und %ROWTYPE dar. Hier­
durch ist es möglich, nach einer Konvertierung
einer Tabellenspalte zu einem LOB-Datentyp
mit den neuen Werten zu arbeiten (siehe Ab­
bildung 4). Die schon oben erwähnten Konver­
tierungsrichtungen sind dabei möglich.
Fazit
Eine Übersicht über die explizit zu verwendenden Konvertierungs­
funktionen in PL/SQL finden Sie in Abbildung 3.
Das Entscheidende an der Migration von LONGzu LOB-Datentypen sind die entsprechenden
Vorüberlegungen, die angestellt werden müs­
sen. Die Migration selbst ist relativ simpel, aber
die Auswirkung („Einmal LOB, immer LOB“) ist
relativ schwerwiegend.
Die Fehlerbehandlung bei der Konvertierung gestaltet sich wie
folgt: Wenn mit einer dieser Funktionen versucht wird, in den ent­
sprechenden Zeichensatz der Datenbank zu konvertieren und der
Klaus Günther ([email protected]).
Explizite Datentypkonvertierung
46
konvertierte Wert größer ist als der maximal zu
speichernde Wert, so wird eine Fehlermeldung
ausgegeben. Das gleiche gilt auch für die im­
plizite Datentypkonvertierung.
ORDIX News 1/2007
Aktuelles
Rückblick DOAG-Konferenz 2006:
007 erobert das DOAG Casino Royal
Im 6. Jahr in Folge war ORDIX auf der DOAG Anwenderkonferenz sowie auf dem DOAG Schulungs­tag vertreten. Auf der Konferenz am 15./16.11.2006 in Mannheim präsentierte ORDIX Oracle Know-how in spannenden
Vorträgen und an der ORDIX Infoinsel.
ORDIX Vorträge
Mein Name ist
„Hoermann – Martin Hoermann“
Mit diesen Worten eröffnete der ORDIX-007, ali­
as Martin Hoermann, seinen Vortrag „Tracing –
Im Geheimdienst Ihrer Majestät“. Der Vortrag
erläuterte wichtige Tracing-Techniken, Analy­
sestrategien für Oracle-Datenbanken und die
Interpretation von Trace-Dateien. Schwerpunkt
des Vortrags war es, die Anwendungsmöglich­
keiten bei konkreten Performanceproblemen
und Analysen herauszuarbeiten.
Oracle Real Application Cluster
In einem zweiten Vortrag im Rahmen der SIG
Database nahm er zusätzlich das Thema „Ora­
cle Real Application Cluster (RAC) Servi­ces“
unter die Lupe. Dieser zeigte, wie mit Hilfe von
Links
► [1] DOAG Infos: http://www.doag.org/konferenz/doag2006/
► [2] ORDIX Trainingsshop: http://training.ordix.de
Services und den Werkzeugen Cluster Ready Services, Server
Control und dbms_service das Server Side Load Balancing konfigu­
riert werden kann. Insbesondere die wenig dokumentierten, unter­
schiedlichen Varianten des Load Balancing wurden beleuchtet.
Oracle Secure Backup
Ob sich der Umstieg auf RMAN mit Oracle Secure Backup rech­
net, erörterte Herr Andreas Kother in seinem Vortrag. Er stellte
die technischen, organisatorischen und wirtschaftlichen Kriterien
dar, die beim Umstieg auf eine neue Backup Lösung zu betrach­
ten sind. Er erklärte die Begriffe und die Funktionsweise von Ora­
cle Secure Backup und lieferte diverse Rechenbeispiele für klei­
ne, mittlere und große Rechenzentren.
Auditing im Oracle-Umfeld
Herr Klaus Reimers nahm in seinem Vortrag Auditing vornehmlich
den Sinn des Auditing, dessen Einsatzmöglichkeiten und die Per­
formance unter die Lupe. Die verschiedenen Auditing-Formen „Man­
datory Auditing, SYS Auditing, Standard Auditing und Fine Grained
Auditing (FGA) wurden vorgestellt. Anschauliche Demos gaben zu­
dem vertiefende Einblicke in die Thematik.
Alle vier Vorträge erhielten seitens des Fachpub­likums sehr gutes
Feedback. Begleitend konnten sich die Teilnehmer an der ORDIX Info­insel eine CD mit den Vorträgen mitnehmen.
Abb. 1: Ansturm auf die ORDIX Infoinsel, wo es
Vortrags-CDs für das Fachpublikum gab.
DOAG Schulungstag
Zusätzlich zu den Vorträgen gaben die ORDIX Berater ihr Wissen
auch in dem Workshop „Advanced PL/SQL“ im Rahmen des DO­
AG Schulungstags weiter. Dieser Workshop richtete sich an fort­
geschrittene Entwickler und Datenbankprogrammierer, die ihre PL/
SQL-Kenntnisse erweitern möchten.
Dieser Workshop behandelte speziell wichtige Erweiterungen und
Möglichkeiten zum Tracen. Darüber hinaus wurde auf das Thema
Performance eingegangen.
Sie konnten an den genannten Veranstaltungen nicht teilnehmen,
interessieren sich aber für die vorgestellten Themen? Dann spre­
chen Sie uns an!
Abb. 2: ORDIX-007 Martin Hoermann präsentiert
den Vortrag „Tracing – Im Geheimdienst Ihrer
Majestät“.
ORDIX News 1/2007
Stefanie Heither ([email protected]).
47
Java/J(2)EE – Titelthema
Reihe EJB 3.0 (Teil II):
Keep it Simple
1+1
=2
An dieses Motto haben wohl die Entwickler der EJB-Spezifikation gedacht, als sie die Version EJB 3.0
ins Leben gerufen haben. Wer sich mit EJB 2.x befasst hat, kennt die große Anzahl der EJB-Artefakte und
den damit verbundenen Implementierungsaufwand, der für eine lauffähige EJB notwendig war. Und genau
das ändert sich in EJB 3.0 - nicht zuletzt durch den massiven Einsatz von Annotations.
Dieser Artikel richtet sich an Entwickler, die einen Überblick über
die Implementierung von Session Beans im Kontext der EJB 3.0
Spezifikation unter Nutzung von Annotations erhalten möchten.
Im ersten Teil der EJB 3.0 Reihe haben wir uns die konzeptionellen
Unterschiede zwischen Annotations und XDoclet angeschaut. Die­
ser Teil geht nun genauer auf die Annotations im Kontext von EJB
3.0 ein. Um den Rahmen nicht zu sprengen, werden hier nur die
wichtigsten Annotations einer Session Bean vorgestellt.
Damit die Annotation-Vorstellung nicht zu einer zu trockenen Aufzäh­
lung ausufert, wird in Abbildung 1 und 2 fast jede Annotation auch in
ihrem „natürlichen Lebensraum“, dem Source Code, gezeigt.
Das Beispiel stellt eine abstrakte Implementierung einer Adress­
buch Stateful Session Bean vor. Weil der Schwerpunkt dieses Ar­
tikels auf den Annotations liegt, sind die Methoden nicht ausimple­
mentiert.
In Abbildung 3 ist jede hier vorgestellte Annotation mit ihrem voll
qualifizierten Namen aufgeführt, da der Artikeltext aus Gründen der
Lesbarkeit darauf verzichtet und jeweils den reinen Annotation-Na­
men verwendet.
Business Interface
Session Beans beinhalten nach der EJB-Spezifikation die Geschäfts­
logik einer EJB-Anwendung. Über welche Methoden auf diese Ge­
schäftslogik zugegriffen wird, deklariert die Geschäftsschnittstelle,
in EJB 2.x auch Component Interface genannt.
package de.ordix.ejb.examples;
@javax.ejb.Remote
public interface Addressbook {
public java.util.List searchContactByName(String name);
public Contact changeContact(Contact c);
public Contact insertContact(Contact c);
public void removeContact(int cPK);
public void clearAllContacts();
public void logout();
}
Abb. 1: Beispiel eines Business Interface.
48
Diese wird in EJB 3.0 als einfaches Plain Old
Java Interface (POJI) implementiert und nennt
sich Business Interface.
Ob die Geschäftsschnittstelle lokal oder entfernt
zugreifbar sein soll, gibt die Annotation @Local
bzw. @Remote auf Klassenebene an. Wird kei­
ne Annotation verwendet, so ist die Geschäfts­
schnittstelle gemäß der Spezifikation lokal.
Unter EJB 3.0 ist es nicht mehr notwendig,
dass die Geschäftsschnittstelle von javax.
ejb.EJBObject oder javax.ejb.EJBLocalObject erbt. Damit müssen die Ge­
­
schäftsmethoden auch keine java.rmi.
Remote­Exception mehr deklarieren und die
oft kritisierte, technische „Verschmutzung“ ver­
schwindet aus dieser rein fachlichen Schnitt­
stelle.
Session Bean
Eine Session Bean ist in EJB 3.0 ein norma­
les Plain Old Java Object (POJO), das nicht
von javax.ejb.SessionBean erben muss.
Dieses ist nicht automatisch eine Session
Bean, sondern muss erst mit den Annotations
@State­less oder @Stateful auf Klassen­
ebene annotiert werden.
Wie an den Annotation-Namen leicht erkenn­
bar ist, definiert @Stateless eine Stateless
Session Bean und @Stateful eine Stateful
Session Bean. Der Annotation können optio­
nal zwei Parameter übergeben werden: ein
eindeutiger Name und eine Beschreibung der
Session Bean.
Wird kein Name angegeben, so wird als DefaultWert stattdessen der nicht voll qualifizier­te Klas­
senname verwendet. Die Session Bean Klasse
muss natürlich die weiter oben be­schriebene(n)
Geschäftsschnittstelle(n) imple­mentieren.
Home sweet home …
Home Interfaces (lokal oder entfernt), wie aus
EJB 2.x bekannt, sind in EJB 3.0 nicht mehr
ORDIX News 1/2007
Java/J(2)EE
zwingend vorgeschrieben. Es stellt sich daher
die Frage, wo in EJB 3.0 die sonst im Home
Interface deklarierten Lebenszyklus-Metho­
den deklariert werden?
Des Rätsels Lösung: Anstelle der Lebenszy­
klus-Methoden werden jetzt beliebige Geschäfts­
methoden mit entsprechenden Annotations ver­
sehen. Eine Ausnahme bilden hier die aus frü­
heren EJB-Versionen bekannten create-Me­
thoden, zu denen es keine entsprechenden An­
notations gibt.
Zur Initialisierung einer Session Bean in EJB
3.0 muss der Client entsprechende Geschäfts­
methoden aufrufen, nachdem der EJB-Contai­
ner eine Bean-Instanz erzeugt hat. Diese Ge­
schäftsmethoden müssen auch nicht mit dem
Präfix „create“ beginnen, sondern können be­
liebige Namen besitzen.
Anstelle der remove-Methode werden eine
oder mehrere Geschäftsmethoden mit der An­
notation @Remove versehen. Ruft der Client
eine dieser Methoden auf, so wird die Verbin­
dung zwischen dem Client und der ihm zuge­
ordneten Stateful Session Bean vom EJB-Con­
tainer aufgehoben.
Für Stateless Session Beans ist das nicht not­
wendig, da keine explizite Bindung zwischen
einem Client und der Bean über einen Metho­
denaufruf hinweg existiert.
Die restlichen Lebenszyklus-Methoden aus dem
Home Interface werden auf die Annota­tions
@PostConstruct, @PreDestroy, @Post­
Activate und @PrePassivate abgebildet
und sind auf der Methodenebene angesiedelt.
Dabei darf jede Annotation maximal einmal pro
Session Bean benutzt werden.
Die annotierten Methoden werden nach bzw.
vor der jeweiligen Aktion (Erzeugung, Passi­
vierung und Zerstörung) aufgerufen. Die bei­
den letzten Annotations können nur bei State­
ful Session Beans verwendet werden, da Sta­
teless Session Beans nicht passiviert werden.
package de.ordix.ejb.examples;
import
import
import
import
javax.annotation.*;
javax.annotation.security.*;
javax.ejb.*;
javax.sql.DataSource;
@Stateful
@DeclareRoles ({"userA", "userB", "admin"})
@TransactionManagement (TransactionManagementType.CONTAINER)
@TransactionAttribute (TransactionAttributeType.REQUIRED)
public class AddressbookBean implements Addressbook {
@Resource
SessionContext ctx;
@Resource (name="myDB")
DataSource contactDB;
@EJB
ContactChecker checker;
@PostConstruct
@PostActivate
public void initRemoteConnection() {
// initialisiert die Remote Verbindung
}
@PreDestroy
@PrePassivate
public void closeRemoteConnection() {
// schließt die Remote Verbindung
}
@PermitAll
@TransactionAttribute (TransactionAttributeType.NEVER)
public java.util.List searchContactByName(String name) {
// sucht alle Kontakte gemäß dem übergebenen Namen
}
@RolesAllowed({"userA", "admin"})
public Contact changeContact(Contact c) {
// ändert einen Kontakt
}
@RolesAllowed ({"userA", "admin"})
public Contact insertContact(Contact c) {
// fügt einen neuen Kontakt hinzu
}
@RolesAllowed ({"userA", "admin"})
public void removeContact(int cPK) {
// löscht einen Kontakt
}
@RolesAllowed ({"admin"})
public void clearAllContacts() {
// löscht alle Kontakte
}
@Remove
public void logout() {
// Ausloggen
}
} // class AddressbookBean
Transaktionsmanagement
Abb. 2: Beispiel einer Stateless Session Bean.
Auch das Transaktionsmanagement kann per
Annotations direkt in der Session Bean Klas­
se angegeben werden. Hierfür sind die beiden
Anno­tations @TransactionManagement und
@Trans­actionAttribute zuständig.
• @TransactionManagement
Die erste Annotation gibt an, ob Container Ma­
naged Transactions (CMT) oder Bean Managed
Transactions (BMT) eingesetzt werden. Sie ist
auf Klassenebene anzugeben und kann fol­
gende Formen haben:
ORDIX News 1/2007
(TransactionManagementType.BEAN)
• @TransactionManagement
(TransactionManagementType.CONTAINER)
Der Parameter vom Typ TransactionManagement ist nicht zwin­
gend anzugeben. In diesem Fall gilt der Default-Wert TransactionManagementType.CONTAINER.
49
Java/J(2)EE
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
@javax.ejb.Local
@javax.ejb.Remote
@javax.ejb.Stateless
@javax.ejb.Stateful
@javax.ejb.Remove
@javax.annotation.PostConstruct
@javax.annotation.PreDestroy
@javax.ejb.PostActivate
@javax.ejb.PrePassivate
@javax.ejb.TransactionManagement
@javax.ejb.TransactionAttribute
@javax.annotation.security.DeclareRoles
@javax.annotation.security.DenyAll
@javax.annotation.security.PermitAll
@javax.annotation.security.RolesAllowed
@javax.annotation.security.RunAs
@javax.ejb.EJB
@javax.annotation.Resource
Abb. 3: Voll qualifizierte Annotation-Namen.
Die @TransactionAttribute Annotation kann sowohl auf Klas­
sen- als auch auf Methodenebene angegeben werden. Auf Klassen­
ebene gilt die Einstellung für alle Geschäftsmethoden der Ses­sion
Bean. Bei Anwendung auf der Methodenebene hat die Einstellung
nur Auswirkungen auf die jeweilige Methode.
Als Parameter erwartet die Annotation einen Parameter vom Typ
TransactionAttributeType. Die Enumeration TransactionAttributeType definiert hierfür die folgenden Konstanten:
•
•
•
•
•
•
MANDATORY
NEVER
NOT_SUPPORTED
REQUIRED
REQUIRES_NEW
SUPPORTS
Wird kein Parameter angegeben, so gilt der Default-Wert TransactionAttributeType.REQUIRED.
Sicherheitseinstellungen
Für Sicherheitseinstellungen basierend auf JAAS definiert EJB 3.0
die fünf Annotations
•
•
•
•
•
@DeclareRoles
@PermitAll
@RolesAllowed
@DenyAll
@RunAs
@DeclareRoles ist auf Klassenebene angesiedelt und ermög­
licht es, die für die Session Bean relevanten Rollen zu definieren.
Als Parameter erwartet die Annotation ein String Array von Rollen­
namen.
Die Annotation @PermitAll gibt an, dass eine Methode von al­
len Rollen ausgeführt werden darf. Wird diese Annotation auf Klas­
senebene eingesetzt, so gilt die Einstellung für alle Methoden der
Session Bean. Auf Methodenebene verwendet, gilt sie nur für die
jeweilige Methode.
50
Ähnlich wie @PermitAll ist die Annotation
@RolesAllowed. Diese Annotation erwartet
eine Liste von Rollennamen, für die der Me­
thodenzugriff seitens des Containers erlaubt
wird. Auch diese Annotation ist auf Klassenund Methodenebene anwendbar.
Die Annotation @DenyAll bewirkt das Gegen­
teil zu @PermitAll. Keiner Rolle ist es er­
laubt, eine mit @DenyAll annotierte Metho­
de aufzurufen.
Praktisch hat das zur Folge, dass eine solche
Methode nicht innerhalb des EJB-Containers
aufgerufen werden kann. Diese Annotation ist
nur auf Methodenebene zulässig.
Die letzte Annotation @RunAs kann ebenfalls
nur auf Methodenebene verwendet werden.
Mit ihr wird angegeben, unter welcher Rolle ei­
ne Methode ausgeführt werden soll. D. h. die
Annotation erwartet als Parameter einen Rol­
lennamen, der dem EJB-Container bekannt
sein muss.
Dependency Injection
Eine wirklich neue Funktion von EJB 3.0 ist
der Einsatz des Entwurfsmusters Dependen­
cy Injection. Hierbei geht es um die Minimie­
rung der Abhängigkeiten zwischen Kompo­
nenten oder Objekten. In unserem Fall zwi­
schen einer EJB und den zur Laufzeit benötig­
ten Ressourcen wie z. B. anderen EJBs oder
DB-Verbindungen.
Die Idee ist, dass nicht die EJB dafür verant­
wortlich ist, sich entsprechende Ressourcen
zu erzeugen und zu verwalten, sondern das
umgebende Framework. D. h. der EJB-Con­
tainer muss einer EJB die benötigten Ressour­
cen „injizieren“.
Damit der EJB-Container weiß, welche Res­
sourcen eine EJB zur Laufzeit braucht, muss
die EJB diese mit Hilfe der Annotation @Resource bzw. @EJB im Falle von anderen
EJBs angeben.
Beide Annotations können auf Klassen-, Attri­
but- und Methodenebene angewendet werden.
Die Annotation @EJB spezifiziert die Referenz
zu einem EJB Business oder Home Interface.
Auf Attributebene versucht der EJB-Container,
das versehene Attribut mit der Referenz der
benötigten EJB zu belegen. Das geschieht
nach dem Setzen des EJB-Kontextes und vor
dem Aufruf von Geschäftsmethoden.
Als Alternative kann eine setter-Methode mit
der Annotation @EJB versehen werden. In die­
ORDIX News 1/2007
Java/J(2)EE
sem Fall injiziert der EJB-Container die EJBReferenz durch Aufruf der setter-Methode.
Überblick über die Neuerungen von EJB 3.0
•
Etwas anders gestaltet sich die Verwendung
der Annotation auf Klassenebene. Hierdurch
erzeugt der EJB-Container die referenzierte
EJB und legt diese im JNDI ab.
•
•
Die referenzierende EJB muss durch einen
vereinfachten JNDI-Lookup die Referenz auf
diese EJB selbst holen.
•
Die Annotation @Resource ähnelt stark der
Annotation @EJB. Mit dem Unterschied, dass
sie die Abhängigkeit von externen Ressourcen
wie JDBC Data Sourcen, JMS Queues/Topics
oder Connection Factories spezifiziert.
Angewandt auf Methoden- oder Attributebe­
ne versucht der EJB-Container, die benötig­
te Ressource direkt zu injizieren. Auf Klassen­
ebene wird die Ressource im JNDI abgelegt
und muss von der EJB per JNDI-Lookup ge­
holt werden.
Beide Annotations können bzw. müssen in be­
stimmten Fällen durch diverse Angaben para­
metrisiert werden, um die benötigte Ressource
eindeutig zu spezifizieren. Das ist aber nicht
immer notwendig.
Hält sich der Entwickler an bestimmte Konven­
tionen, so kann der EJB-Container z. B. auf At­
tributebene durch Auswertung des Attributna­
mens und -typs die benötigte Ressource ein­
deutig identifizieren.
•
•
•
•
•
•
Deployment-Deskriptoren sind nicht nötig, können aber StandardVerhalten überschreiben.
Viele vordefinierte Einstellungen. Man spezifiziert nur die Aus­
nahmen von den Regeln.
Es sind keine Schnittstellen wie Remote, EntityBean, Session­
Bean 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 Ärger­
nis 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 Ja­
va 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)
Glossar
Annotations
Was bringts?
Obwohl, wie eingangs angekündigt, bewusst
nur eine Auswahl an Annotations vorgestellt
wurde, hat Ihnen der Artikel einen Eindruck
von der Verwendung und den Vorteilen der
EJB 3.0 Annotations vermittelt.
Weniger EJB-Artefakte und ein geringerer Im­
plementierungsaufwand sind ein großer Schritt
in Richtung der Ziele, denen sich die EJB-Spe­
zifikation schon vor langer Zeit verschrieben
hat. Im nächsten Teil geht es um die EJB 3.0
Persistence API, die den Umgang mit der Per­
sistenz erheblich vereinfacht.
EJB
Session Bean
POJI
POJO
Home Interface
Component
Interface
Christoph Borowski ([email protected]).
ORDIX News 1/2007
Anmerkungen im Java Source Code, die zur Lauf­
zeit des Programms ausgewertet werden können.
Annotations sind seit Java 5 Bestandteil von Java.
Als geistigen Vater dieser Annotations kann man
das Open Source Projekt XDoclet ansehen. XDoc­
let erlaubte es, auch schon in früheren Java Ver­
sionen mit Annotations zu programmieren.
Enterprise Java Beans (EJB) sind standardisier­
te Komponenten, aus denen J2EE-konforme An­
wendungen erstellt werden, die auf einem J2EEApplication Server laufen. Für unterschiedliche
Zwecke definiert der J2EE-Standard verschiedene
Arten von EJBs wie z. B. Session Beans, Entity
Beans und Message-driven Beans.
Session Beans sind EJBs, die insbesondere Vor­
gänge abbilden, die der Nutzer mit dem System
durchführt.
Abkürzung für Plain Old Java Interface. Dabei han­
delt es sich um ein normales Interface in der Pro­
grammiersprache Java.
Abkürzung für Plain Old Java Object. Dabei han­
delt es sich um ein normales Objekt in der Pro­
grammiersprache Java.
Deklariert die Lebenszyklusmethoden einer EJB.
D. h. Methoden zur Erzeugung, Löschung usw. von
EJBs. Bis EJB 2.x vorgeschrieben und in zwei Aus­
prägungen (remote, local) vorhanden.
Deklariert die fachlichen Geschäftsmethoden einer
EJB. Bis EJB 2.x vorgeschrieben und in zwei Aus­
prägungen (remote, local) vorhanden.
51
Datenbanken
Oracle und XML – Ein besonderer Cocktail (Teil II):
XMLType
In der ORDIX News 1/2006, Seite 40, haben wir einige XML-Funktionen von Oracle vorgestellt. Dieser Artikel
stellt den Datentyp XMLType vor. Mit ihm lassen sich XML-Dokumente nahtlos in die Datenbank einfügen.
Dieser Artikel richtet sich an Datenbankentwickler und SoftwareArchitekten, die XML im Zusammenspiel mit Oracle-Datenbanken
einsetzen möchten.
Seit Oracle 9i steht XMLType als neuer Datentyp in der Datenbank
zur Verfügung. Dieser Datentyp kann wie alle bisher bekannten
Oracle-Datentypen verwendet werden. Oracle stellt spezielle Funk­
tionen zum Erzeugen, Extrahieren und Indizieren von XML-Daten
zur Verfügung.
Speichermethoden
XMLType-Daten können auf zwei verschiedene Arten gespeichert
werden:
1. Unstrukturierte Speicherung als CLOB.
2. Strukturierte Speicherung in objektrelationalen Tabellen.
Bei der unstrukturierten Speicherung werden die XML-Daten intern
als Text im CLOB abgelegt. Dazu wird zu jeder XMLType-Spalte
intern eine CLOB-Spalte angelegt, die für den Benutzer allerdings
nicht sichtbar ist. Die XMLType-Spalte enthält intern also nur eine
Referenz auf diese CLOB-Spalte.
Um XML-Dokumente strukturiert in objektrelationalen Tabellen zu
speichern, ist eine XML-Schemadefinition erforderlich. Diese be­
schreibt Struktur und Inhalt des XML-Dokuments. Das XML-Sche­
ma wird für die XMLType-Spalte registriert. Durch die Registrie­
rung werden nach festgelegten Regeln Oracle-Objekte erzeugt, in
die die Daten der XML-Dokumente abgelegt werden können. So­
mit können nicht mehr beliebige XML-Dokumente in der XMLTypeSpalte abgelegt werden, sondern nur noch solche XML-Dokumen­
te, die der XML-Schema-Definition entsprechen.
Diese Art der Speicherung hat viele Vorteile gegenüber der un­
strukturierten Speicherung als CLOB. So ist der Zugriff auf einzelne
Elemente des XML-Dokuments performanter,
da nicht mehr das komplette XML-Dokument
gelesen bzw. geschrieben werden muss. Des
Weiteren wird weniger Speicherplatz benötigt,
da Tag- und Attribut-Namen nicht mehr gespei­
chert werden müssen.
Create mit XMLType
Beim Anlegen von Tabellen mit XMLType-Spal­
ten wird festgelegt, welche Speichermethode zu
verwenden ist. Wenn, wie in Abbildung 1, nur
der Datentyp XMLType angegeben wird, wird
intern ein CLOB erzeugt. Die objektrelationale
Speicherung wird im Absatz „Create Table bei
strukturierter Speicherung“ dargestellt.
Der Datentyp XMLType lässt sich genauso wie
andere Oracle-Datentypen verwenden. Beim
Anlegen von Constraints ist aber zu be­achten,
dass XMLType-Spalten nur auf NOT NULL ge­
setzt werden können. Andere Constraints, z. B.
Default-Werte, werden nicht unterstützt.
Insert
Um Daten in eine XMLType-Spalte einzufü­
gen, muss, wie in Abbildung 2 dargestellt, der
CREATE TABLE ta_colxmltype(
autoid NUMBER,
autotyp VARCHAR2(100),
herstellerliste XMLTYPE)
XMLTYPE COLUMN herstellerliste
STORE AS CLOB;
Abb. 1: Anlegen einer Tabelle mit XMLType-Spalte.
INSERT INTO ta_colxmltype
VALUES (1,'Alfa 156', XMLType(
'<?xml version="1.0" encoding="UTF-8"?>
<Auto xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance" xsd:noNamespaceSchemaLocation="Auto.xsd">
<Herstellerliste>
<Hersteller id="1">
<Name>Motorenwerke Rüdesheim</Name>
</Hersteller>
<Hersteller id="2">
<Name>Best-Blech</Name>
</Hersteller>
</Herstellerliste>
</Auto>')
);
Abb. 2: Einfügen eines Datensatzes in eine XMLType-Spalte.
52
ORDIX News 1/2007
Datenbanken
DELETE FROM ta_colxmltype
WHERE extractValue(herstellerliste, '/Auto/Herstellerliste/Hersteller[2]/Name')
LIKE '%Best-Blech%';
Abb. 3: Löschen eines mit Hilfe von Xpath ermittelten Datensatzes.
UPDATE ta_colxmltype SET
Herstellerliste = updateXML(Herstellerliste, '/Auto/Herstellerliste/Hersteller[@id="1"]/Name/text()',
'Motorenwerke');
Abb. 4: Update mit updateXML.
ExtractValue
Extract
ExistsNode
GetRootElement
Liefert anhand eines Xpath-Ausdrucks den Wert eines Knotens.
Extrahiert einen oder mehrere Äste eines XMLType-Objekts.
Prüft, ob in einem XMLType-Objekt ein entsprechender Knoten vorliegt.
Gibt das Root-Element der XMLType-Instanz zurück.
GetSchemaURL
Gibt die URL der registrierten XML-Schema-Definition zurück. Wurde kein XML-Schema registriert, so wird
NULL zurück gegeben.
Transform
Transformiert die übergebene XMLType-Instanz unter Einsatz einer XSLT-Datei als XMLType-Instanz in HTML,
Text etc.
UpdateXML
Ändert Werte in einem XMLType-Objekt.
XMLSequence
Ermöglicht die Verarbeitung mehrerer Knoten eines XMLType-Objekts.
Abb. 5: Wichtige XMLType-Funktionen.
Konstruktor XMLType() verwendet werden.
Es können nur „wohlgeformte“ XML-Daten ein­
gefügt werden.
Where-Bedingungen mit XPath-Ausdruck
Auf den Inhalt von XMLType-Objekten kann di­
rekt mit SQL zugegriffen werden. In Abbildung 3
wird gezeigt, wie der Wert eines XML-Knotens
ermittelt wird, um diesen mit einer Zeichenket­
te zu vergleichen. Zur Ermittlung des KnotenWertes wird die mächtige Syntax von XPath
verwendet.
Wenn extractValue Bestandteil einer WhereKlausel ist, muss darauf geachtet werden, dass
für den Vergleich immer der LIKE-Operator ver­
wendet wird.
Update von XMLType-Spalten
Werden XML-Dokumente nicht objektrelational
abgespeichert, ist zu beachten, dass beim Up­
date das gesamte XML-Dokument innerhalb der
Datenbank ersetzt wird. Dies kann unter Um­
ständen zu Performance-Problemen führen. Im
Updatestatement muss, wie auch schon beim In­
sert beschrieben, der XMLType()-Konstruktor
verwendet werden.
Soll in einem XML-Dokument nur der Wert eines
Knotens verändert werden, so kann dafür die
Funktion updateXML verwendet werden. In Ab­
bildung 4 wird die Verwendung dieser Funktion
ORDIX News 1/2007
Abb. 6: Eigenschaften der Objekttypen im Enterprise Manager.
anhand eines Beispiels dargestellt. Im zuvor eingefügten XML-Doku­
ment soll der Name des Herstellers mit der ID 1 von „Motorenwerke
Rüdesheim“ in „Motorenwerke“ umbenannt werden. Der entspre­
chende Knoten wird durch einen XPath-Ausdruck angesteuert.
Wenn durch den XPath-Ausdruck mehrere Knoten angesteuert wer­
den, werden alle Knoten ersetzt.
XMLType-Funktionen
Neben den oben bereits beschriebenen Funktionen gibt es noch ei­
nige weitere, die wir in der Übersicht in Abbildung 5 kurz vorstellen.
53
Datenbanken
DECLARE
xml_schema VARCHAR2(1000) := '<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="Auto">
<xs:complexType>
<xs:sequence>
<xs:element name="Herstellerliste">
<xs:complexType>
<xs:sequence>
<xs:element name="Hersteller" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="Name"/>
</xs:sequence>
<xs:attribute name="id"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>';
BEGIN
DBMS_XMLSchema.registerSchema('http://www.ordix.de/auto.xsd',xml_schema);
END;
Abb. 7: Registrierung eines XML-Schemas.
CREATE TABLE ta_colxmltype2(
autoid NUMBER,
autotyp VARCHAR2(100),
herstellerliste XMLTYPE)
XMLTYPE COLUMN herstellerliste
XMLSCHEMA "http://www.ordix.de/auto.xsd"
ELEMENT "Auto";
Abb. 8: Anlegen von Tabellen mit XML-Schema.
Wird ein XML-Schema registriert, werden die
zur Speicherung der zugehörigen XML-Doku­
mente benötigten Objekttypen automatisch ge­
neriert. Die Eigenschaften dieser Objekttypen
kann man sich im Enterprise Manager ansehen
(siehe Abbildung 6).
Einsatz von XML-Schema
Mapping zwischen XML und OracleObjekt­typen
In einer XMLType-Spalte, die als CLOB gespeichert wird, können be­
liebige XML-Daten abgelegt werden. Dies ist so lange kein Problem,
wie die Daten nicht in einem semantischen Zusammenhang stehen
müssen und die Datenbanktabelle einfach nur als Ablage für XMLDokumente genutzt wird.
Die Umwandlung von der XPath-Datenabfrage
in eine relationale Abfrage ist vollständig trans­
parent: Der Anwender muss und kann keinen
direkten Zugriff auf die zugrunde liegenden Ta­
bellen nehmen.
Wenn die Dokumente aber syntaktischen und semantischen Regeln
folgen müssen, reicht die interne Speicherung in einem CLOB nicht
aus. Die Datenkonsistenz muss durch eine strukturierte Speicherung
gewährleistet werden. Die Grundlage für das strukturierte Speichern
ist die Registrierung einer XML-Schema-Definition.
Die Daten aus dem XML-Schema sind die Grund­
lage für das Mapping zwischen der XML- und
der Datenbankwelt. Für das Mapping von XMLSchema-Datentypen und die Namensgebung
gibt es in der XMLDB Default-Regeln. Im XMLSchema können die Default-Regeln durch ex­
plizite Angaben in der XML-Schema-Definition
überschrieben werden.
Zur strukturierten Speicherung von XML-Dokumenten sind objekt­
relationale Konstrukte erforderlich, die zur Struktur des XML-Doku­
ments passen.
So kann bereits beim Eintragen des XML-Dokuments die Aufteilung
der Daten auf Oracle-Objekte erfolgen. Bei der Datenabfrage muss
Oracle die Struktur des XML-Doku­ments wieder rekonstruieren kön­
nen. Die Speicherung der Daten muss für den Anwender transpa­
rent bleiben.
54
Strukturierte Speicherung in
objektrelationalen Tabellen
XML-Schema registrieren
Bei der Arbeit mit XML-Schema-basierten Da­
ten ist zunächst das XML-Schema in der Daten­
bank zu registrieren. Für das Registrieren wird
die Funktion registerSchema() des Pakets
ORDIX News 1/2007
Datenbanken
compileSchema
Das Schema wird erneut kompiliert. Dies wird u. a. dann erforderlich, wenn das Schema ungültig geworden
ist. Durch das Kompilieren eines Schemas werden alle abhängigen Schemata ungültig und müssen auch er­
neut kompiliert werden.
deleteSchema
Löschen eines XML-Schemas. Hierbei ist zu beachten, dass standardmäßig nur Schemata gelöscht werden
können, die keine abhängigen Objekte mehr haben.
generateSchema
Erzeugen eines XML-Schemas aus einem Objekttyp
registerSchema
Registrieren eines XML-Schemas
Abb. 9: Vorstellung einiger wichtiger DBMS_XMLSchema-Funktionen.
DBMS_XMLSchema verwendet. Dieser Funk­
tion werden zwei Parameter übergeben:
1. Eine URL, unter der das Schema registriert
wird.
2. Das Schema als VARCHAR.
Wichtig ist dabei, dass die URL nicht tatsäch­
lich existieren muss. Die URL ist nur als Name
zu verstehen, unter dem das Schema registriert
wird. In Abbildung 7 finden Sie ein Beispiel für
die Registrierung einer XML-Schema-Definition
an der Datenbank.
Glossar
CLOB
Character Large Object. Datentyp für ein Datenbankfeld
zur Speicherung von großen Textdaten (bis zu 4 GB).
XML
Extensible Markup Language (XML). XML ist eine so ge­
nannte META-Sprache zur Beschreibung von Dokumenten.
Ein Vorteil von XML ist der vereinfachte Austausch von Da­
ten, da XML-Formate in einer strengen Grammatik definiert
werden können, und so die Implementierung von zuverläs­
sigen Schnittstellen erlaubt.
Ein XML-Schema beschreibt die Struktur von XML-Doku­
XMLSchema menten und erlaubt ihre inhaltliche Überprüfung.
Xpath
Create Table bei strukturierter Speicherung
Die erfolgreich registrierte XML-Schema-Defi­
nition kann beim Anlegen von Tabellen verwen­
det werden. In diesem Fall muss die Referenz
auf das registrierte Schema angegeben wer­
den. Dadurch wird automatisch die strukturierte
Speicherung verwendet. Abbildung 8 zeigt an­
hand eines Beispiels, wie eine Tabelle angelegt
werden kann, die das in Abbildung 7 registrier­
te Schema verwendet.
DBMS_XMLSchema
Im Paket DBMS_XMLSchema werden eine Rei­
he von Funktionen zur Verarbeitung von XMLSchema-basierten Dokumenten zur Verfügung
gestellt. Einige von ihnen werden in Abbildung
9 kurz vorgestellt.
Query Rewrite
Beim Zugriff über XPath werden die XPath-Ab­
fragen bei der strukturierten Speicherung auto­
matisch in SQL-Abfragen umgewandelt. Dieser
Vorgang wird Query Rewriting genannt. Unter
Oracle 9i wird das Query Rewriting leider noch
nicht bei allen XPath-Ausdrücken unterstützt.
Die XPath-Ausdrücke, die die automatische Um­
wandlung nicht unterstützen, können trotzdem
verwendet werden. Allerdings werden die Funk­
tionen dann, wie bei der Speicherung als CLOB,
durch Parsing und Aufbau eines DOM-Baums im
Hauptspeicher ausgeführt. Deshalb ist die Per­
formance hier schlechter als bei der Verwendung
ORDIX News 1/2007
XPath stellt Funktionen und Ausdrücke zur Verfügung, um
Knoten innerhalb von XML-Dokumenten zu lokalisieren. Mit
XPath können auch Ausdrücke ausgewertet und Berech­
nungen durchgeführt werden.
von Query Rewriting. Ohne Query Rewriting ist ein Indizieren der XML­
Type-Daten wirkungslos.
Ob ein Query Rewrite für eine XPath-Abfrage stattfinden kann, lässt
sich aus einem Ausführungsplan ableiten. Mehr zum Thema Query
Rewriting und Indizierung von XMLType-Daten erfahren Sie in einer
der nächsten Ausgaben der ORDIX News. Folgende XPath-Kons­
trukte können u. a. ein Query Rewrite verhindern:
• Wildcards, die zu mehr als einem XML-Knoten führen
• XPath-Achsen (außer child und attribute)
• XPath-Variablen
Fazit
Der Einsatz des Datentyps XMLType ist für das Abspeichern von
XML-Daten in der Datenbank auf jeden Fall zu empfehlen, denn durch
die Realisierung des Datentyps und aller zugehörigen vordefinierten
Funktionen wird der schnelle Zugriff auf XML-Dokumente sicherge­
stellt. Zudem kann XMLType zusammen mit anderen Datentypen in
SQL-Befehlen verwendet werden.
Gerade bei der strukturierten Speicherung hat das Ablegen von XMLDokumenten in einer XMLType-Spalte große Vorteile. So ist das Ab­
speichern der XML-Dokumente und der Zugriff auf die Dokumente
wesentlich performanter als der Zugriff auf ein XML-Dokument, das
als CLOB gespeichert wird. Zudem können Indizes bei der struktu­
rierten Speicherung für eine bessere Performance sorgen. Außer­
dem wird weniger Speicherplatz benötigt, da nicht zu jedem in der
XMLType-Spalte abgelegten XML-Dokument jeder Tag-Name abge­
speichert werden muss.
Kathrin Hammerschmidt ([email protected]).
55
Halten Sie Schritt mit dem Puls der Zeit!
Neue ORDIX Seminare 2007
Datenbanken
Java/J(2)EE
•
•
•
•
•
•
•
•
• Java GUI Entwicklung mit Swing
• Java 5.0 Neuheiten
• Webanwendungen mit
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
Java Server Faces (JSF)
• Java Web Services
• Entwicklung mit Hibernate
Betriebssysteme
• Server-Virtualisierung mit XEN
• Solaris 10 für erfahrene System­
administratoren
• Solaris Containers
• Multivendor Systemadministration
Weitere Informationen finden Sie im ORDIX Trainingsshop
unter http://training.ordix.de oder in unserem Seminarprogramm.