Die Wolke beginnt zu schweben
Werbung
www.ordix.de € 3,20 03|2012 ne ws Die Wolke beginnt zu schweben 44| Enterprise Manager Oracle Cloud Control 12c 6 | Projektmanagement - Project Management Offices im Wandel der Zeit 12 | Neue Reihe: NoSQL vs. SQL - Hype oder echte Alternative? 16 | Neue Reihe: DB2 V10.1 – Codename „Galileo“ - alles neu? 26 | Wie mit der MySQL Sandbox Datenbankinstallationen ein Kinderspiel werden g 20. – 22. November 2012 | Nürnberg Die DOAG-Community begeistert! Die ORDIX AG auf der Konferenz + Ausstellung 2012 Memory – Ein Drilldown von der SGA über die PGA bis zum Database Buffer Advisor Referent: Klaus Reimers, ORDIX AG 25 Jahre DOAG Konferenz + Ausstellung, das ORDIX Team ist mit 4 Vorträgen und einem Schulungstag dabei ! Space – the final frontier: Speicher- und PerformanceAspekte in Oracle Tablespaces Referent: Martin Hoermann, ORDIX AG Anmeldungen unter: http://www.doag.org/konferenz/doag/2012/ DOAG Schulungstag am 23.11.2012 Der Schulungstag bietet all den Personen, die bislang keine Gelegenheit hatten sich mit Oracle Application Express auseinanderzusetzen, einen pragmatischen Einstieg in die Welt von APEX. Hands-On Oracle Application Express Tuning the Mobile Server Referent: Matthias Jung, ORDIX AG Referent: Phillip Loer, ORDIX AG Seminarinhalte Active-DataGuard bei Autoscout24: eine Lesefarm im Praxiseinsatz Referentin: Sabine Langer, AutoScout24 Co-Referent: Michael Skowasch, ORDIX AG Wir freuen uns auf Sie bei der DOAG 2012 Unseren Messestand finden Sie auf Etage 3, Stand 322. ■■ Erstellung und Verwaltung von Applikationen ■■ Verwendung der unterschiedlichen Seitenelemente (Page Items) ■■ Erstellen von Reporting-Tabellen und Diagrammen ■■ Verwendung von Formularen zur Datenerfassung ■■ Verwaltung von Usern ■■ Möglichkeiten zur User-Authentifizierung Zweierlei Maß Paderborn, September 2012 Am Wochenende wird sie eröffnet, die Wies’n, Münchens größtes Spektakel neben der CSU. Dann gibt es für gut zwei Wochen wieder zweierlei Maß: Einmal die Maß (ein Liter Bier) und die Oktoberfestmaß (ca. 0,7-0,8 Liter Bier). Mit zweierlei Maß misst auch Apple1) : Während die Nachahmung des iPhone durch Samsung Diebstahl ist, handelte es sich beim Klau des Mac Betriebssystems von Rank Xerox in den 80er Jahren um Kunst. So zumindest ist Steve Jobs in einem Interview zu verstehen, welches momentan als „Steve Jobs: The Lost Interview“ im Kino zu sehen ist. „Gute Künstler kopieren, großartige Künstler stehlen“, sagte Jobs im Jahr 1994. „Und wir haben immer schamlos gute Ideen geklaut.“ Das passt gut zu den jüngsten Meldungen über Patentrechtsverletzungen von Samsung wie von Apple. Aber genauso gut zu den jüngsten Verkaufszahlen des iPhone 5. Knapp 1.400 Geräte pro Minute werden verkauft. Vermutlich ist auch wieder einiges geklaut. Samsung probiert es jetzt auch und will Apple verklagen, da das Gerät ver­ botenerweise Samsung-Patente für die superschnelle Funktechnologie LTE nutze. Diese Verkaufszahlen werden Apple sicher noch eine zeitlang als weltweit teuerstes Unternehmen im Rennen halten. Beim Vorgänger konnte man zu Höchstzeiten gerade mal 1.000 Stück pro Minute verkaufen. Dass man mit Klauen weiterkommt, hatten wir ja schon bei unserem ehemaligen Verteidigungsminister. Eine schöne Zukunft offenbart sich da. Nun hoffe ich, dass unsere Autoren weder gut noch großartig sind, sondern einfach informative Artikel schreiben . In dieser Ausgabe sind wir Datenbank-lastig. Das beginnt mit einem ab­ soluten Hype-Thema: NoSQL Datenbanken. Schon Ende des letzten Jahrhunderts sprachen viele vom Sterben der relationalen Datenbanksysteme, objektorientierte oder Internet-Datenbanken sollten relationale Datenbanken verdrängen. Vermutlich war aber die Idee nicht großartig genug. Viel Oracle finden Sie in dieser Ausgabe. In der Reihe der Oracle-Artikel starten wir eine Serie zum Thema Oracle Spatial, über Geodaten und ihre Nutzung geht es dabei. Ein neues Kapitel zur physikalische Speicherverwaltung in Oracle befasst sich mit der größten Tabelle im Universum, eine Abhandlung aus dem Land der unbegrenzten (Klau-) Möglichkeiten, wo gerne vom „biggest, largest …“ gesprochen wird. Ebenfalls den zweiten Teil zum anderen Hype neben NoSQL, der Cloud, finden Sie im Artikel „Oracle Cloud Control 12c“. Leider werden wir damit auch weiterhin das Wetter nicht beeinflussen können. Ob sich die neue DB2-Version 10.1 auch in die Reihe „größer, mehr und schneller“ einordnen lässt, werden wir mit unserer neuen Reihe beleuchten. Und noch mal Oracle allerdings unter dem Label MySQL in zwei weiteren Artikeln (MySQL Sandbox und MySQL Cluster vs. Replikation). Wenn wir schon beim Thema Cluster sind, passt unser dritter Teil der Reihe zum Pacemaker Cluster richtig gut dazu. Nicht zuletzt versuchen wir Ihnen mit Tipps zu Hibernate bei Performance­ Probleme unter die Arme zu greifen. Applikationssupporter sollten natürlich auch Performance­ Probleme beherrschen, welche Skills für sie/ihn zusätzlich nützlich sind, offenbart Ihnen unser Artikel. Last but not least klären wir Sie über die Entwicklung des PMO auf. Ein großartiger Mitarbeiter im PMO nach der Definiton von Steve Jobs ist dann der, der vor allem gut im schamlosen Kopieren von Powerpoint-Folien ist . Jetzt wünsche ich Ihnen viel Spaß bei den zahllosen Oktoberfesten (im September), die sich quer durch ganz Deutschland ziehen und natürlich, dass sich der Flüßigkeitsspiegel Ihrer Maß immer maximal einen kleinen Finger breit unter dem Eichstrich befindet. Ihr Wolfgang Kögler 1) Frankfurter Allgemeine Sonntagszeitung vom 16.09.2012 ORDIX News 3/2012 3 Inhaltsverzeichnis 12 26 NoSQL vs. SQL ─ Was sind NoSQL-Datenbanken? MySQL Sandbox ─ Sandkastenspiele Datenbanken 9����������� Physikalische Speicherverwaltung in Oracle (Teil II): Wer hat die größte Tabelle im Universum? Dieser Artikel zeigt, wie die internen Speicherstrukturen von Tabellen in einer Oracle-Datenbank aussehen und wie man den Füllgrad von Tabellen bestimmen und beeinflussen kann. 12��������� NoSQL vs. SQL - Hype oder echte Alternative? (Teil I): Was sind NoSQL-Datenbanken? NoSQL-Datenbanken sind momentan ein Hype-Thema, aber bieten diese eine echte Alternative zu relationalen Produkten? Im ersten Teil dieser Reihe klären wir zunächst, was NoSQL eigentlich bedeutet. 16��������� Die neue Version V10.1 von IBM DB2 (Teil I): Codename „Galileo“ - alles neu? Seit April ist die neue Datenbankversion verfügbar. Im ersten Artikel dieser Reihe geben wir Ihnen einen Überblick über die wichtigsten Änderungen im DB2-Umfeld. 26��������� MySQL Sandbox: Sandkastenspiele MySQL ist ein sehr wirksames Framework für die Bereitstellung und Verwaltung von vielen MySQLInstallationen. Wie dieses Framework arbeitet erläutern wir in diesem Artikel. 29��������� Räumliche Daten mit Oracle Spatial (Teil I): Mehr Raum für die Datenbank Geodaten werden heutzutage an fast jeder Supermarktkasse abgefragt. Was macht diese Informationen für die Unternehmen so interessant und wie können sie verwaltet werden? Dieser Artikel gibt einen ersten Überblick. 4 ORDIX news 3/2012 37��������� Oracle entwickelt MySQL: Cluster vs. Replikation von MySQL - individuell universell einsetzbar? Die Geschichte von MySQL ist lang und seit 2010 schreibt Oracle diese weiter. Welche Auswirkung hat das auf den Cluster und die Replikation von MySQL? 44��������� Oracle Cloud Control 12c (Teil II): Die Wolke beginnt zu schweben In diesem Artikel erläutern wir die Grundvoraus­ setzungen und die Installation des neuen OracleWerkzeugs. Projektmanagement 6����������� Projektmanagement in der Praxis (Teil VI): Project Management Offices im Wandel der Zeit Früher gab es eine Assistenz, die Besprechungen orga­ nisierte und Protokolle schrieb. Heute gehen die Auf­ gaben eines Project Management Office deutlich weiter. OpenSource 18��������� OpenSource Cluster mit Pacemaker (Teil III): Kleine Features für große Cluster Rollenkonzepte gab es in Pacemaker bisher nicht. Seit der Version 1.1.5 können nun jedem Administrator eigene Rechte zugwiesen werden. Die Möglichkeiten dieser neuen Funktionalität stellen wir in diesem Artikel vor. Inhaltsverzeichnis 34 44 Hibernate ─ Was ist die optimale BatchSize? Oracle Cloud Control ─ Die Wolke beginnt zu schweben Java/JEE Impressum 21��������� Java Best Practice: Systeme modellieren mit UML Anforderungen an ein System strukturiert und standard­ isiert festzuhalten und diese schnell wiederzufinden ist in einem Entwicklungsprozess sehr wichtig. Hierfür ist die Unified Modeling Language (UML) sehr nützlich. Herausgeber: Redaktion: V.i.S.d.P.: Anschrift der Redaktion: Gestaltung/Layout: Auflage: Druck: 34��������� Hibernate für Fortgeschrittene (Teil III): Was ist die optimale BatchSize? Wie kann mit der BatchSize-Strategie die Performance gesteigert werden? Was muss bei der Einrichtung einer BatchSize beachtet werden? Dieser Artikel gibt Ihnen Antworten. Betriebssysteme 42��������� Skills für den Applikationssupport: Applikationsmanagement ist Management Die Mischung machts! Wo früher „nur“ technisches Know-how nötig war, werden heute von den Adminis­ tratoren Managementfähigkeiten erwartet. Heute sind Adminis­tratoren nicht nur Techniker, sondern auch im Bereich der Kommunikation und Organisation gefordert. Aktuell | Standards 24��������� Seminarübersicht: September bis Dezember 2012 47��������� Larry Ratlos ORDIX AG Aktiengesellschaft für Software­ent­wick­lung, Beratung, Schulung und Systemintegration, Paderborn Jens Pothmann, Evelyn Ernst Benedikt Georgi, Wolfgang Kögler ORDIX AG | Westernmauer 12 - 16 | 33098 Paderborn Tel.: 05251 1063-0 | Fax: 0180 1673490 Jens Pothmann 9.200 Exemplare Druckerei Bösmann, Detmold Bildnachweis: © webdesignhot.com | Vector Abstract Blue Background 2 |Vector Graphics ©dryicons |Arrow Template |Vector Graphic ©istockphoto.com | Blank 3d Cubes | teekid ©istockphoto.com | Computer Geek | sdominik ©istockphoto.com | Tree in a green field | da-kuk © freepik.com | gestures psd material | zcool.com.cn © deviantart.com | Clouds Set icons PSD | JackieTran © sxc.hu | Nienke 2 | Kverhees © sxc.hu | Nienke 1 | Kverhees © sxc.hu | Graffiti | ralev_com © sxc.hu | Graffiti | jrdurao © sxc.hu | texture-brickwall | nickobec © freepik.com | tools icon psd | Psd blast © freepik.com | facebook user icon | Psd blast Autoren: Christof Amelunxen, Christian Fertsch, Carsten Griese, Martin Hoermann, Carsten Hummel, Matthias Jung, Steffen Kanne, Dr. Stefan Koch, Wolfgang Kögler, Andreas Maßmann, Dominic Oberländer, Jens Pothmann, Matthias Schneider, Michael Spoden Copyright: Warenzeichen: Haftung: Die ORDIX news erscheint vierteljährlich. Alle Eigentumsund Nachdruckrechte, auch die der Übersetzung, der Vervielfältigung der Artikel oder von Teilen daraus, sind nur mit schriftlicher Zustimmung der ORDIX AG ge­stattet. ORDIX® ist ein eingetragenes Markenzeichen der ORDIX AG. Einige der aufgeführten Bezeichnungen sind eingetragene Warenzeichen ihrer jeweiligen Inhaber. ORDIX® ist eine registrierte Marke der ORDIX AG. Eine Haftung für die Richtigkeit der Veröffentlichungen kann trotz sorgfältiger Prüfung durch die Redaktion vom Herausgeber nicht übernommen werden. Sie können die Zusendung der ORDIX news jederzeit ohne Angabe von Gründen schriftlich (z.B. Brief, Fax, E-Mail) abbestellen. ORDIX news 3/2012 5 Projektmanagement Projektmanagement in der Praxis (Teil VI) Project Management Offices im Wandel der Zeit „Frau Schellenberg, ich bitte zum Diktat!“ – so stelle ich es mir vor. So stelle ich mir vor, wie Projektleiter vor vielen Jahren durch eine Assistentin unterstützt wurden. Die Welt hat sich seitdem gedreht – mehrmals. Die veränderten Rahmenbedingungen, wie die Einführung von Vorgehensmodellen zur Projektabwicklung, eine wachsende Tendenz zur Fremdvergabe und die hohe Anzahl an organisationsbezogenen Schnittstellen stellen neue Anforderungen an die Projekt­ organisation. Projektleiter sehen sich – je nach Beschaffenheit eines Projektes – gezwungen, die ihnen zur Verfügung stehende Zeit stark zu priorisieren und ausgewählte Aufgaben zu delegieren. IT-Lösungen sind heute ein maßgeblicher Faktor für den Geschäftserfolg von Unternehmen und ein wesentlicher Innovationstreiber zur Eroberung neuer Märkte. Gleichzeitig stellen IT-Vorhaben aufgrund des hohen Investitionsvolumens und der Unsicherheiten immer auch Risiken im Portfolio von Unternehmen dar. Durch die Einführung von Vorgehensmodellen, die die Standardisierung von Prozessen und den Einsatz von Qualitätssicherungs- und Optimierungsmethoden im Projektmanagementumfeld vorantreiben, wird versucht, diese Risiken zu reduzieren bzw. beherrschbar zu machen. Häufig ist der Erfolg dieser Maßnahmen unbefriedigend. Es entsteht ein Zusatzaufwand, welcher durch die Projekt­ organisation abgefedert werden muss. Zusätzlich fehlt die Zeit, eine reelle Datenbasis durch eine gründliche Projektdokumentation auf Projekt­ ebene zu schaffen, um diese dann auch für Optimierungsmaßnahmen einzusetzen. Es stellt sich die Frage, ob Projektorganisationen und damit auch die zugehörigen Projektleiter überhaupt noch in der Lage sind, die vorgesehene Steigerung von Qualität und Produktivität zu erreichen. PMO – Project Management Office Seinen Ursprung hat das PMO im Sekretariat bzw. in der Assistenz. Bei der Evolution von funktionalen 6 ORDIX news 3/2012 Orga­ nisationen zu projekt­ orientierte Organisationen sind die typischen adminis­trativen Aufgaben, wie zum Beispiel „Terminvereinbarungen treffen“, „Vorbereitung und Mitschrift von Besprechungen“ usw., vom Sekretariat in das PMO übergegangen. Im Laufe der Zeit hat sich das Auf­gabengebiet stark gewandelt, nicht zuletzt durch die sich verändernden Rahmenbedingungen im Projektgeschäft. Heute wird die Definition des Begriffs Project Management Office in der Praxis weit gefasst. PMO werden Aufgaben von der Unterstützung des Projekt­leiters bei administrativen Tätigkeiten bis hin zur Prozessoptimierung und Innovation im Projekt selbst oder in der Projektorganisation anvertraut. Ein PMO kann deshalb für verschiedene Einsatzgebiete und auf unterschiedlichen Ebenen einer Organisa­tion etabliert werden (siehe Abbildung 1): • Ein PMO wird einem Projekt zugeordnet. • Ein PMO wird einem Programm zugeordnet. • Ein PMO wird dem Portfoliomanagement angegliedert. Aufgabengebiete eines PMO auf Projektebene Ein PMO auf der Projektebene ist ein integrativer Bestandteil des Projektes. Wesentliche Aufgaben auf Projektebene sind: Projektmanagement • Administrative Tätigkeiten: Vorbereitung von Meetings, Protokoll­erstellung, Ressourcenbuchung etc. • Erstellung Projektdokumentation auf Projektleitungsebene Portfolio PMO Projekt-Portfolio • Erarbeitung von Entscheidungsvorlagen • Statusvorbereitung • Sicherstellung einer dem Vorgehensmodell konformen Projektabwicklung Programm PMO Programm • Übernahme von Schnittstellenfunktionen zu anderen Einheiten im Unternehmen wie z.B. zentrales Controlling • Definition und Optimierung Projekt A Projekt B Projekt N Projekt PMO N Projekt F Projekt PMO F interner Projektprozesse Die Aufgabengebiete auf Projektebene beziehen sich direkt auf ein konkretes Projekt. Ziel ist nicht nur die Entlastung des Projektleiters, sondern die Unter­stützung des gesamten Projektes. Die PMO-Mit­arbeiter üben aber nicht nur administrative Tätigkeiten aus, sondern nehmen auch erfolgssichernde Aufgaben im Anforderungsmanagement oder Risikomanagement in Ab­ stimmung mit der Projekt­leitung wahr. Abb. 1: PMO auf unterschiedlichen Ebenen einer Organisation. • Unterstützung bei der Projektinitiierung • Definition von Rahmenbedingungen/Regeln und Überwachung deren Einhaltung Dabei besitzen sie einen wesentlichen Vorteil im internen Projekt­geschehen. Im Gegensatz zu einem Projektleiter besitzen sie keine Gesamt­ verantwortung. Dadurch können sich PMO-Mit­ arbeiter freier be­ wegen und werden als Vermittler zwischen der operativen Ebene und der Projektleitung wahrgenommen. Ein PMO auf Projektebene ist temporär und wird nach Beendigung des Projektes aufgelöst. Aufgabengebiete eines PMO auf Programmebene In einem Programm werden zueinander in Beziehung stehende Projekte, wie z.B. „Umsetzung aller regulatorischen Anforderungen“ zusammengefasst. Das Programmmanagement ist somit oberhalb eines einzelnen Projektes angesiedelt. Damit ändert sich das Aufgabenspektrum dahingehend, dass nun viele Projekte gleichzeitig unterstützt werden müssen: • Administrative Tätigkeiten für das • Schnittstellenfunktionen zu verschiedenen Einheiten im Unternehmen, wie z.B. zum zentralem Controlling oder Portfolio-Board • Aggregation von Informationen und Weitergabe an das Programm-Management • Budgetverwaltung auf Programmebene • Bewertung der Leistbarkeit von neuen Vorhaben Eine Einarbeitung in Projektdetails ist aufgrund der Vielzahl an Projekten in der Regel nicht möglich. Ähnlich wie auf der Projektebene ist ein Ziel die Entlastung von Projektleitern in Regeltätigkeiten, allerdings immer unter dem Aspekt, alle dem Programm zugehörigen Projekte zu unterstützen. Hinzu kommt die Koordination von Aufgaben, welche zeitgleich für alle Projekte des Programms anfallen, bspw. die Statusweitergabe an das Portfolio-Board. Ein PMO auf Programmebene ist i.d.R. temporär und wird somit nach Beendigung des Programms aufgelöst. Programm, wie z.B. Ressourcenverwaltung • Infrastrukturbereitstellung für das Programm • Unterstützung bei der Planung der Programmumsetzung Aufgabengebiete eines PMO auf Portfolioebene Das Projektportfoliomanagement dient der Bewertung und Auswahl von IT-Investitionen, welche über ORDIX news 3/2012 7 Projektmanagement Ein PMO auf Ebene des Portfoliomanagements ist fester Bestandteil der Unternehmensorganisation. Link ►► [1] Webseite der coniatos AG: http://www.coniatos.de Quellen ►► P3O For Successful Portfolio, Programm and Projekt Offices: Think P3O®, ISBN 9780113311255, Published by TSO and on behalf of the Office of Government Commerce, 2008 Projekte abgewickelt werden. Das Portfoliomanagement ist verantwortlich für die Aufnahme, Priorisierung und Steuerung aller gestellten Anforderungen und legt die zeitliche Umsetzung fest. Ein PMO, welches auf dieser Ebene angesiedelt ist, nimmt folgende Aufgaben wahr: Vorteile für die Organisation Heute werden Project Management Offices in vielen Unternehmen eingesetzt. Das Ziel ist nicht nur die Entlastung auf den jeweiligen Projektmanagement­ ebenen, sondern vor allem auch die Durchdringung der gesamten Projekt­organisation hinsichtlich des Einsatzes von Projekt­management-Methoden. Gleichzeitig werden mit ihrem Einsatz, wertvolle Erkenntnisse über die Güte der ablaufenden Projektprozesse gewonnen. Durch die zuverlässige und standardisierte Erfassung von Informationen und deren Verdichtung, kann eine Auswertung des Verlaufs von Projekten erfolgen. Auf dieser Basis können Optimierungsmaßnahmen definiert und in den Projekten eingeführt werden. • Unterstützung bei der Portfolioplanung/-steuerung • Kommunikation in die einzelnen Projekte/Programme • Aggregation von Informationen und Bericht an das Senior Management • Festlegung von Projektmanagement-Prozessen und deren Optimierung im Vorgehensmodell • Definition, Pflege und Überwachung der Einhaltung der Rahmenbedingungen Matthias Schneider ([email protected]) • Methodenentwicklung für die Projektorganisation Seminarempfehlung: IT-Projektmanagement - Methoden und Techniken ►► Informationen/Online-Anmeldung: http://training.ordix.de/siteengine/action/load/kategorie/Projektmanagement/nr/223/index.html In diesem Seminar erhalten Sie einen umfassenden und systematischen Überblick über alle Begriffe, Methoden und Arbeitstechniken zum Management von IT-Projekten. Sie lernen, IT-Projekte zu planen und zu steuern sowie verfügbare Arbeitshilfen projektspezifisch anzupassen. Seminarinhalte Grundlagen Projektdefinition Projektplanung Projektdurchführung Projekt-Controlling Qualitäts- und Risikomanagement Arbeits- und Hilfsmittel Fallbeispiele, Übungen • • • • • • • • 8 ORDIX news 3/2012 Termine 19.11.- 23.11.2012in Wiesbaden Seminar-ID: PM-01 Dauer: 5 Tage Preis pro Teilnehmer: 1.990,00 € (zzgl. MwSt.) Frühbucherpreis: 1.791,00 € (zzgl. MwSt.) Datenbanken Space, the final frontier - die physikalische Speicherverwaltung in Oracle (Teil II) Wer hat die größte Tabelle im Universum? Im ersten Teil dieser Reihe [1] haben wir gezeigt, wie sich der Füllgrad von Tablespaces ermitteln lässt. Der Füllgrad summiert sich aus der Menge der belegten Extents. Die belegten Extents sind die Bestandteile von Segmenten, also beispielsweise Tabellen und Indizes. In diesem Artikel untersuchen wir die internen Strukturen von Tabellen und zeigen, wie sich der Füllgrad einer Tabelle bestimmen und beeinflussen lässt. Dieses Wissen ist wesentlich, um den Sinn und Unsinn von terrabyte-großen Tabellen zu hinterfragen. Wie ein Segment entsteht Ein Segment entsteht in der Regel durch das Erstellen eines Objektes, welches eigenen Speicherplatz benötigt. Die Erstellung einer View beispielsweise führt nicht zur Erstellung eines Segments, da lediglich die Definition im Data Dictionary abgelegt wird. Eine Materialized View „materialisiert“ die Ergebnis­menge, benötigt daher eigenen Speicherplatz und führt zu der Erstellung eines Segments. Genauso ist es mit Tabellen, Indizes, Cluster, Undo und temporären Segmenten. Ist ein Objekt partitioniert, so bildet jede Partition bzw. Subpartition ein einzelnes Segment. Mit Oracle 11g ist es möglich, Objekte mit der Option „Deferred Segment Creation“ zu erstellen. So wird das Segment, welches immer aus einem initialen Extent (i.d.R. 8 Blöcke) besteht, erst erzeugt, wenn der erste Datensatz eingefügt wird. Dies hat übrigens den interessanten Begleiteffekt, dass bei Sequenzen die erste Sequenznummer „verloren“ geht. Extent Map Zur Reduzierung der Verwaltungsinformationen und aus Performance-Gründen wird eine Menge von hintereinander liegenden Blöcken in so genannten Extents zusammengefasst. In Locally Managed Tablespaces (LMT) sind in der Regel die ersten 16 Extents 8 Blöcke groß, die nächsten Gruppen von Extents sind 128, 1024 usw. Blöcke groß. In einem LMT Tablespace mit Uniform Extent Size sind alle Extent-Größen identisch. Wird nun neuer Platz benötigt, wird ein neues Extent im Tablespace angelegt und dem Segment zuge­ ordnet. Die Extents bilden die äußere Struktur des Segments. In den nächsten Abschnitten beleuchten wir nun die innere Struktur. Aufbau des Segments Ein Segment besteht im Wesentlichen aus den folgen­ den Typen. Dabei ist jeder Oracle-Block von genau einem Typ: • Segment Header: Dieser enthält beispielsweise Informationen zur High Water Mark (HWM) und zu den Freispeicherlisten. • Freispeicherlisten: In Tablespaces mit Automatic Segment Space Management (ASSM) sind dies so genannte Bitmap Freelists. Wird der Tablespace manuell verwaltet sind es Freelists und Freelist Groups. • Data Blocks: In diesen Blöcken befinden sich die eigentlichen Daten. Daten können in diesem Fall auch Index- oder Undo-Daten sein. • Unformatted Blocks: Am Ende des Segments kann es noch nicht formatierte Blöcke geben. Diese werden erst bei Bedarf zu Daten- oder Freispeicher­ listen-Blöcken formatiert. ORDIX news 3/2012 9 Datenbanken • ITL-Slots: Ändert eine Transaktion Daten im Block, Datentyp Größe DATE 7 Bytes TIMESTAMP 7 oder 11 Bytes TIMESTAMP WITH TIME ZONE 13 Bytes CHAR abhängig von der Definition NCHAR abhängig von der Definition INTERVAL YEAR TO MONTH 5 Bytes INTERVAL DAY TO SECOND 11 Bytes BINARY_FLOAT 4 Bytes BINARY_DOUBLE 4 Bytes Abb. 1: Ausgewählte Datentypen mit fixer Länge. Werden neue Daten mittels INSERT in eine Tabelle eingefügt, so wird über die Freispeicherlisten ein passender Block ausgewählt. Mit dem heute üblichen ASSM wird die freie Kapazität je Block in 25 %-Schritten verwaltet. Steht kein freier Platz mehr zur Verfügung, so wird hinter der HWM neuer Platz geschaffen, in dem unformatierte Blöcke formatiert werden. Stehen keine unformatierten Blöcke zur Verfügung, so wird ein neues Extent allokiert. Die Freispeicherlisten können mit dem so genannten APPEND-Hint umgangen werden. Bei daraus folgenden Direct Path Inserts werden die Daten­ sätze direkt hinter der High Water Mark eingefügt. Dies ist für große Datenmengen einerseits per­ formanter, führt jedoch anderseits möglicherweise zu nicht genutztem Platz innerhalb des Segments. Aufbau eines Datenblocks vom Typ Data Ein Datenblock besteht aus den folgenden Bereichen: • Block Header: Hier finden sich allgemeine Verwaltungsinformationen, wie beispielsweise das zugehörige Segment, die Speicherplatzadresse und die aktuelle SCN-Nummer. • Row Directory: Hier wird jede Zeile und jedes Feld des Datenbereichs adressiert. An dieser Stelle entscheidet sich durch die Längenangabe des benötigten Speicherplatzes, ob ein Feld den Wert NULL enthält. Darüber hinaus benötigt der Wert NULL keinen weiteren Speicherplatz. Mehrere NULL-Werte am Ende einer Zeile benötigen lediglich ein Byte im Row Directory. 10 ORDIX news 3/2012 so belegt sie einen ITL-Slot. Im Row Directory wird für jede geänderte Zeile eine Referenz auf den Slot eingetragen. Weiterhin enthält der ITL-Slot Verweise zu den Undo-Informationen der Transaktion. • Daten: Hinter den Verwaltungsinformationen kommen die Daten als Byte-Strom. Feldtrenner werden nicht benötigt, da die Adressierung durch das Row Directory jedes Feld eindeutig bestimmen kann. • Block Footer: Hier befindet sich erneut die SCNNummer. Unterscheiden sich die SCN-Nummern im Header und im Footer, so ist der Block inkon­ sistent. Dies kann beispielsweise bei OnlineBackups passieren. Der Recovery Manager liest den Block in diesem Fall einfach erneut. Der belegte Platz im Datenbereich bestimmt sich erstens durch die gewählten Datentypen und zweitens durch die Dateninhalte. Der Wert NULL benötigt bis auf den Verweis im Row Directory keinen Speicherplatz. Dies gilt für alle Datentypen, insbesondere auch für CHAR, der ansonsten immer eine fixe Länge hat. Bei einigen Datentypen ist die Anzahl benötigter Bytes immer gleich, z.B. DATE, TIMESTAMP, CHAR, bei anderen Datentypen ist die Anzahl der Bytes abhängig von deren Inhalt, z.B. NUMBER, VARCHAR2. Die Abbildung 1 gibt einen Überblick über Datentypen mit fixem Speicherplatzverbrauch. Eine sorgfältige Wahl der Datentypen und der Dateninhalte beinflusst also ganz wesentlich den Platzverbrauch einer Tabelle. Werden Datensätze in einem Block aktualisiert (UPDATE), so kann der Speicherplatz steigen oder sinken. Damit es bei einer Vergrößerung nicht sofort zu Speicherengpässen und daraus resultierenden Chained Rows kommt, gibt es in jedem Block einen reservierten Speicherplatz (PCT_USED). Der DefaultWert von 10 % ist insbesondere für große Tabellen sorgfältig zu prüfen. Werden beispielsweise keine Änderungen auf der Tabelle durchgeführt, so sind 10 % des Platzes verschwendet. Wird der Wert dagegen zu klein gewählt, besteht die Gefahr von Chained Rows. Für detaillierte Analysen kann ein Block mit Hilfe des folgenden Kommandos in das Diagnostic-Verzeichnis (user_dump_dest) geschrieben werden: ALTER SYSTEM DUMP DATAFILE 4 BLOCK 259; Die Dateinummer und die Block-ID lassen sich mit Hilfe der View dba_extents ermitteln. In der Regel sind die ersten beiden Blöcke des ersten Extent Freispeicherlisten und der dritte Block bein­haltet den Segment Header. Datenbanken Platzverbrauch messen Der Platzverbrauch eines Blocks lässt sich mit dem Paket dbms_space ermitteln. Um eine korrekte Ausgabe sowohl für unterschiedliche TablespaceVerwaltungen (Locally vs. Manual Managed) als auch für unterschiedliche Speicherverwaltungen (Automatic vs. Manual Segment Space Management) zu erhalten, sei an dieser Stelle auf den Blog von Tom Kyte verwiesen [2]. Um den Inhalt einzelner Felder genauer zu untersuchen, bietet Oracle die Funktion dump an. Mit ihr wird sowohl der Datentyp (Typ) als auch die Länge in Bytes (Len) ausgegeben. So hat beispielsweise ein gefülltes Feld vom Typ Timestamp(6) vier Byte mehr als ein date-Feld mit sieben Bytes. Das entspricht immerhin 57 % mehr Datenvolumen. dump( <date> ) : Typ=12 Len=7: 120,11... dump( <timestamp>): Typ=180 Len=11: 120,1.... Wer sich tiefergehend mit den hier diskutierten Themen beschäftigen will, sei auf den Concept Guide in der Oracle-Dokumentation oder auf Tom Kytes Expert Oracle Database Architecture verwiesen [3]. Von Riesen und Zwergen - ein Fazit Tabellengrößen von einem Terabyte und mehr sind heute Realität. Inwiefern das immer notwendig ist, hängt maßgeblich vom logischen und physikalischen Tabellendesign ab. Steht das Layout einer Tabelle fest, so lässt sich der Speicherverbrauch auf den einzelnen Ebenen analysieren. Die einzelnen Schritte wurden in diesem Artikel aufgeführt: Glossar LMT Locally Managed Tablespace - Speicherverwaltung in Tablespaces, bei der der Tablespace die Größe der Extents vorgibt. ASSM Automatic Segment Space Management - Speicherverwaltung von Segmenten, bei denen die Segmente die Werte für Freispeicherlisten und assoziierten Einstellungen übernehmen. ITL Interested Transaction List - Liste von Slots, in denen Transaktionen Änderungen in Blöcken referenzieren. Links ►► [1] ORDIX news Artikel 02/2012 „Space, the final frontier die physikalische Speicherverwaltung in Oracle (Teil I) Tablespaces und schwarze Löcher“: http://www.ordix.de/images/ordix/onews_archiv/2_2012/tablespaces_oracle.html ►► [2] dbms_space auf asktom: http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ ID:231414051079 ►► [3] Leseempfehlung: Tom Kyte, Expert Oracle Database Architecture: Oracle Database Programming 9i, 10g, and 11g Techniques and Solutions http://www.amazon.de/Expert-Oracle-Database-Architecture-Programming/dp/1430229462/ref=pd_cp_eb_0 Ob sich Ihre Tabelle zu der größten im Universum entwickelt oder klein und handlich bleibt, hängt von vielen Faktoren ab. Inwiefern sich beispielsweise mit Hilfe von Reorganisationen oder der Kompression sich teure Gigabyte sparen lassen, untersuchen wir im nächsten Artikel dieser Serie. • Größe einzelner Datenfelder mit der SQL-Funktion dump • der Füllgrad eine Datenblocks mit dbms_space • das Layout des Segments über dba_segments und dba_extents Martin Hoermann ([email protected]) ORDIX news 3/2012 11 Datenbanken Neue Reihe: NoSQL vs. SQL - Hype oder echte Alternative? (Teil I) Was sind NoSQL-Datenbanken? Hersteller von relationalen Datenbanken beherrschten die letzten drei Jahrzehnte der Datenspeicherung und werden wohl auch die kommenden Jahre dominieren. Es stellt sich bei relationalen Datenbanken die Frage, ob sie ihre Vormacht­stellung gegen die nicht standardisierten Abfragesprachen behaupten kann und ob diese nicht für einige Anwendungen veraltet sind. Welche Anwendungen das sein können, was NoSQL in diesen Fällen „besser“ macht und was NoSQL eigentlich bedeutet, werden wir in dieser Artikelreihe genauer erläutern. SQL kenne ich ... Die Abfragesprache SQL gibt es mittlerweile seit über 30 Jahren. Sie ist aus SEQUEL entstanden, welche auf den Erkenntnissen von Edgar F. Codd beruht. Dieser hat, indem er die mathematischen Relationen auf den Computer übertragen hat, zwischen 1960 und 1970 den Grundstein für die Entwicklung der relationalen Datenbanken gelegt. Mit der Standardisierung von SQL hat das heutige Datenbankzeitalter Einzug gehalten. Durch SQL haben Entwickler die Möglichkeit erhalten, Abfragen dann zu stellen, wenn es ihnen passt. Diese Art von Abfragen werden auch AdHoc-Queries genannt. Dass dieses etwas Besonderes sind, ist den 12 ORDIX news 3/2012 meisten heutzutage gar nicht mehr bewusst, da sie so alltäglich geworden sind. Auch die Verknüpfung von Tabellen über Fremdschlüsselbeziehungen ist für Datenbankentwickler ein alter Hut und nicht mehr wegzudenken. Die SQL-Abfragesprache lässt sich in drei Kategorien unterteilen, mit denen sich Befehle zu Schemaopera­ tionen (DDL), Datensatz­­ manipulationen (DML) und zur Rechteverwaltung (DCL) absetzen lassen. ... aber was ist NoSQL? Zu aller erst ist die Namensgebung sehr interpreta­ tionsanfällig. Sie bedeutet in erster Linie „alles außer Datenbanken SQL“. Die NoSQL-Community allerdings bezeichnet sich als „Not only SQL“-Community und weicht damit die strikte Abgrenzung zu SQL auf. Um den Grundsatz von NoSQL zu ergründen, muss man einen Blick auf die Internetpräsenz der NoSQL-Community werfen. Demnach ist eine Datenbank dann eine NoSQL-Datenbank, wenn bestimmte Kriterien erfüllt werden. Beispielsweise soll sie OpenSource sein, eine einfache API beinhalten und in der Lage sein horizontal zu skalieren. Wenn diese Kriterien erfüllt sind, lassen sich die NoSQL-Datenbanken weiter in vier Kategorien unterteilen. Diese sind graphenorientierte, dokumenten­ orientierte, key/value-basierende und spaltenorientierte Datenbanken [1]. Eigenschaften und Garanten des Erfolgs Datenbankmanagementsysteme garantieren, dass das Transaktionskonzept während einer Transaktion eingehalten wird. Das Transaktionskonzept umfasst dabei die vier Charakteristika Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (ACID). Atomarität besagt, dass eine Transaktion aus Benutzersicht ununterbrochen verlaufen muss. Im Falle eines Fehlers wird die Transaktion abgebrochen und zurückgerollt. Daher wird diese Eigenschaft auch die „alles oder nichts“-Eigenschaft genannt. Konsistenz bedeutet im Zusammenhang mit Transaktionen, dass die Datenbank von einem konsistenten Zustand in einen weiteren konsistenten Zustand überführt werden muss. Während der Transaktion muss die Konsis­tenz nicht gewährleistet werden. Isolation meint hier, dass dem Benutzer mithilfe eines Serialisierungsverfahrens ein logischer Einbenutzerbetrieb vorgegaukelt wird. Dadurch werden konkurrierende Operationen nacheinander und isoliert von­ einander behandelt. Dauerhaftigkeit bedeutet, dass erfolgreiche Transaktionen alle nachfolgenden Systemfehler überleben. Des Weiteren können Datenbankoperationen nur durch weitere Transaktionen verändert werden. Dank dieser Charakteristika wird gewährleistet, dass eine Transaktion logisch nach der anderen abge­ arbeitet wird und dabei immer einen konsistenten Datenbestand hinterlässt. Weiterhin werden einmal getätigte Transaktionen dauerhaft gespeichert. Dieses Verhalten wird vor allem bei Stammdaten und sicherheitskritischen Daten vorausgesetzt. Leider geht ein striktes Transaktionsmodell immer zulas- ten der Performance, da Sperrverfahren eingerichtet werden müssen, um die Datenkonsistenz gewährleisten zu können [2]. Alte Besen kehren gut? Somit ist es nicht weiter verwunderlich, dass die Umsetzung des relationalen Datenbankmodells in einem DBMS nicht für alle Anwendungen das optimale Mittel ist. Dies zeichnete sich spätestens seit dem Auf­ kommen des Web 2.0 und den damit verbundenen geänderten Anforderungen ab. Als Beispiele können hier Web-Blogs, soziale Netzwerke oder ähnliche Anwendungen genommen werden. Diese haben alle gemein, dass sie sehr viele Daten verarbeiten und global vorhalten müssen. Dies hat wiederum zur Folge, dass man um eine Verteilung der Daten nicht umher kommt, will man den Kunden akzeptable Antwortzeiten bieten. Unter­ nehmen wie Google, Amazon und Twitter haben dies frühzeitig erkannt und eigene Datenbankmodelle entworfen. Darüber hinaus sind relationale Datenbanken an ihr Schema gebunden, welches im Datenmodell verankert ist und verschiedene Datentypen umfasst. Eine Änderung des Schemas hat immer zur Folge, dass die Verfügbarkeit der Datenbank eingeschränkt wird. Weiter ist die Abbildung von komplexen Datentypen, wie sie in objektorientierten Programmiersprachen vorkommen, nicht vorgesehen [3]. Eine weitere Anforderung im Rahmen des Web 2.0 ist das Verarbeiten von sehr großen, semi-strukturierten Daten. Hier stoßen relationale Datenbanken insofern an ihre Grenzen, dass sie nicht in der Lage sind, horizontal zu skalieren. Sie skalieren vertikal und sind somit auf die Hardwarehersteller angewiesen. Sie benötigen immer schnellere, größere und somit leistungsstärkere Maschinen. Dieser Problematik begegnen sie mit den verschiedenen Cluster-Techniken. Der auf einer shared-all-Architektur beruhende Oracle Real Application Cluster ist nur ein Beispiel. Die Tatsache, dass relationale Datenbanken lediglich in der Lage sind vertikal zu skalieren, begründet sich in dem von Eric Brewer aufgestelltem CAP-Theorem. Ideale Systeme gibt es nicht! Das ideale System wäre ein System, das immer verfügbar ist, eine konsistente Datenhaltung bewahrt und ohne Einschränkungen skaliert. Leider ist solch ein System reine Fiktion, da diese drei Eigenschaften nicht gleichzeitig erreicht werden können. Dies hat nicht zuletzt Eric Brewer mit seinem CAP-Theorem ORDIX news 3/2012 13 Datenbanken Eine Leseoperation, die nach einer Schreiboperation beginnt, muss als Ergebnis die Schreiboperation zurückliefern. Availability CA RDBMSs (MySQL, Postgres, etc.) Aster Data, Greenplum, Vertica CA Consistency AP Dynamo, Valdemort Tokyo Cabinet KAI, Casandra, Simple DB Couch DB Riak AP CP Partitioning CP Big Table, Hypertable, Hbase, MongoDB, Terrastore, Scalaris, Berkeley DB Memcache DB, Redis Datenbankenmodelle Relationale Datenbanken Key-Value Spalten-/Zeilenorientiert Dokumentenorient Verfügbarkeit (Availability): Verfügbarkeit nach Brewer bedeutet, dass ein System oder ein Service nur dann verfügbar ist, wenn es in der Lage ist, Anfragen zu bearbeiten, wenn sie benötigt werden. Ergo ist ein System oder ein Service dann nicht verfügbar, wenn Anfragen nicht zu dem Zeitpunkt bearbeitet werden können, wenn es gefordert wird. Partitionstoleranz (Partition Tolerance): Diese besagt, dass in einem verteilten, partitionierten Netzwerk ein Service auch dann noch erreichbar sein muss, wenn ein Teil des partitionierten Netzwerkes nicht erreichbar ist. Wenn eine Datenbank mit 100 Tabellen in zwei Netzwerksegmente zu je 50 Tabellen partitioniert wird und eine Partition ausfällt, muss die Datenbank dennoch Schreib- und Leseoperationen durchführen können. Abb. 1: Zuordnung von Datenbanken zum CAP-Theorem. Die Annäherung dank Kompromissen Links Die gewählte Aussage von Eric Brewer, „[...] You can have at most two of these three properties for any shared-­data system [...]” [4] hat für reichlich Diskussionen gesorgt ─ nicht zuletzt im Lager der NoSQL-Community. ►► [1] NoSQL Guide: http://www.nosql-database.org ►► [2] Literaturnachweis: Härder, Theo; Rahm, Erhard: Datenbanksysteme - Konzepte und Techniken der Implementierung. 2. überarb. Aufl., Berlin : Springer, 2001. – ISBN 3540421335 ►► [3] Literaturnachweis: Ireland, Christopher; Bowers, David; Newton, Michael; Waugh, Kevin: A Classification of Object-Relational Impedance Mismatch. In: Proceedings of the 2009 First International Conference on Advances in Databases, Knowledge, and Data Applications. Washington, DC, USA : IEEE Computer Society, 2009. – ISBN 978–0–7695–3550–0, S. 36–43 ►► [4] [Brewer 2000] Brewer, Eric A.: Towards robust distributed systems. In: Proceedings of the nineteenth annual ACM symposium on Principles of distributedcomputing. New York, USA : ACM, 2000 (PODC ’00), S. 1–12 ►► [5] http://www.oreilly.de/artikel/web20.html bewiesen, auf dessen Grundlage wir diese drei Eigenschaften näher betrachten wollen (siehe Abbildung 1). Konsistenz (Consistency): Anders als bei dem ACIDParadigma, bei dem es für die Einhaltung der Transaktionsregeln steht, bedeutet es hier das konsistente Lesen und Schreiben auf demselben Datenstand bei konkurrierendem Zugriff. Demnach kann ein System nur dann konsistent sein, wenn Aktualisierungen von Datensätzen von allen relevanten Knoten in derselben logischen Zeit akzeptiert werden. Daraus ergibt sich: 14 ORDIX news 3/2012 Die Kritiker sind mit dieser strikten Trennung nicht einverstanden und konnten Eric Brewer einen Anreiz geben, sein 2001 definiertes CAP-Theorem anders zu beleuchten. Unterdessen hat er auf die Arbeiten von Gylbert und Lynch aus dem Jahr 2002 verwiesen, die sein Theorem grundsätzlich bewiesen haben. Jedoch haben sie auch aufgezeigt, dass man Kompromisse eingehen kann. Diese Kompromisse sehen wie folgt aus: • Kompromisse in der Konsistenz (AP): Konsistenzkompromisse müssen überall dort in Kauf genommen werden, wo die Verfügbarkeit und die Partitionstoleranz oberste Priorität haben. Ein beispielhaftes Szenario kann eine Online-Plattform sein, die Inhalte (Videos, Bilder, etc.) an Benutzer auf der ganzen Welt ausliefert. Die einzelnen Daten werden dabei von einem Knoten auf einen anderen repliziert und dort vorgehalten. Die ständige Verfügbarkeit einer solchen Plattform geht über die Konsistenz der Inhalte. • Kompromisse in der Verfügbarkeit (CP): In solch einem Szenario wird die Verfügbarkeit vernachlässigt und ein größerer Fokus auf die Kon­sistenz der Daten gelegt. Schaut man sich den Chubby Lock Service von Google an, findet man genau solch ein Szenario. Dieser Service hält Metadaten vor und ist ebenfalls für die Sperrver­fahren verantwortlich. Datenbanken • Kompromisse in der Partitionstoleranz (CA): In diesem Spektrum finden wir die klassischen relationalen Datenbanken wieder und einige der bekanntesten NoSQL-Daten­b anken, Googles BigTable beispielsweise. Diese Datenbank ist hochverfügbar und unterstützt ein striktes Konsistenzmodell. Es kann zwar den Ausfall von einigen Knoten problemlos verkraften, doch gilt es nicht als partitionstolerant. Werden die beschriebenen Kompromisse näher betrachtet, kann man jeder dieser drei Kategorien Sys­ teme zuordnen. CP: BigTable, HBase, BerkeleyBD, MongoDB, etc. AP: CouchDB, Dynamo, Voldemort, MySQL (InnoDB), etc. CA: Oracle, MySQL (MyISAM), DB2, Informix, etc. Fazit Die NoSQL-Datenbanklösungen sind für spezielle Fälle konzipiert und entwickelt worden. Es lässt sich nicht erkennen, dass die NoSQL-Community den Anspruch hat, die SQL-Datenbanken mit ihren neuen Technologien zu verdrängen. Sie wollen und brauchen auch nicht als Bedrohung angesehen werden. Vielmehr sollten sie als Spezialisten und als Ergänzung zu den relationalen Datenbanksystemen wahrgenommen werden. Im weiteren Verlauf dieser Artikelreihe werden wir die vier NoSQL-Datenbanktypen anhand jeweils eines konkreten Beispiels untersuchen. Dabei werden ihre Stärken, Schwächen und Einsatzgebiete im Fokus stehen. Glossar API Application Programming Interface ─ Sammlung von Klassen, welche eine Schnittstelle zu einer Hardware oder Anwendung definieren. BigData So werden Datenmengen bezeichnet die >= 1TB sind. Chubby Lock Service Verteilter Sperrmechanismus für lose gekoppelte verteilte Systeme. Wird zur Transaktionssteuerung eingesetzt und vermeidet dabei „Deadlocks“. DCL Data Control Language ─ Datenüberwachungssprache zur Vergabe von Rechten in einer Datenbank DDL Data Defnition Language ─ Über DDL-Kommandos werden Datenstrukturen gepflegt (z. B. Tabellen anlegen oder löschen). DML Data Modification Language. Über DML-Kommandos werden Daten (Zeilen) in Tabellen eingefügt, gelöscht oder geändert. RDB Relationale Datenbanken beruhen auf den mathematischen Relationen und dienen der Datenverarbeitung in Computersystemen. SEQUEL Structured English Query Language ─ Vorläufer von SQL, wurde für das Projekt System R von IBM entwickelt (ca. 1975). SQL Die Structured Query Language ist die Standardabfragesprache in relationalen Datenbanken. Transaktion Die Abstraktion eines fachlichen (logischen) Verarbeitungsvorganges und überführt einen Zustand Z in einen anderen Zustand Z'. Web 2.0 Das Web 2.0 wird auch häufig als das „Mitmach-Web“ bezeichnet, hierbei konsumiert der Nutzer nicht nur den Inhalt, er stellt als Prosument selbst Inhalte zur Verfügung. Dieses wurde u.a. von Tim O'Reilly beschrieben. [5] Bild: Dominic Oberländer ([email protected]) © sxc.hu | Graffiti | ralev_com © sxc.hu | Graffiti | jrdurao © sxc.hu | texture-brickwall | nickobec Treffpunkt RheinMainIT: NoSQL-Datenbanksysteme - Hype und Realität treff RheinMain IT NoSQL-Datenbanksysteme sind derzeit das Daten­banken-Hype-Thema. Aber was genau sind NoSQL-Datenbanksysteme und was können diese Systeme wirklich (und was nicht)? Für welche Anwendungen sind sie eine Alternative (und für welche nicht)? Dieser Vortrag gibt die Antworten. Datum | Uhrzeit : 30.10.2012 | 18.00 Uhr Ort: ORDIX Seminarzentrum Wiesbaden Referent: Prof. Dr. Uta Störl, Hochschule Darmstadt ORDIX news 3/2012 15 Datenbanken Neue Reihe: Die neue Version 10.1 von IBM DB2 (Teil I) Codename „Galileo“ - alles neu? Das letzte DB2 Release 9.7 vom Frühjahr 2009 ist nun schon über drei Jahre alt und man wartete schon gespannt auf die Version 10. Seit Ende April diesen Jahres ist die neue Datenbankversion DB2 V10.1 von IBM verfügbar. Im ersten Teil unserer neuen Reihe stellen wir die wichtigsten Neuerungen im Überblick vor. Nachdem in der letzten Version der Schwerpunkt auf der Kompatibilität zu Oracle SQL bzw. PL/SQL lag, wurde in diesem Release an vielen Ecken geschraubt und verbessert. Die Highlights sind sicherlich die folgenden Funktionen: nur auf die Datensätze seiner eigenen Abteilung zugreifen darf. • adaptive Komprimierung Wie wäre es, wenn man sehen könnte wie bestimmte Daten z.B. gestern oder vor dem letzten Monats­ abschluß ausgesehen haben? Möglich ist das nun mit der sog. Time Travel Query. Mit dieser Neuerung werden Datenänderungen in den Tabellen mit Hilfe von temporalen Tabellen festgehalten. Unterschieden wird dabei zwischen Tabellen mit dem Systemzeitraum und Tabellen für einen Anwendungszeitraum bzw. der Kombination aus beiden, der bitemporalen Tabelle. • Row and Column Access Control • Time Travel Queries • Multi Temperature Storage Neuer Komprimierungsalgorithmus Mit der Version 10.1 wurde ein neuer Kompri­mierungs­ algorithmus eingeführt, die sogenannte adaptive Kompri­mierung. Wurde die Komprimierung früher auf Tabellenebene anhand eines Wörterverzeichnisses für die komplette Tabelle durchgeführt, so wird nun auf zwei Ebenen, nämlich Tabellen- und Seitenebene, das Wörterverzeichnis für die Komprimierung verwendet. Dadurch können die Wörterverzeichnisse für die einzelnen Seiten klein gehalten und bei Datenänderungen ggf. auch schnell geändert und aktualisiert werden. Dies hat eine effektivere Komprimierung zur Folge, wodurch letztlich auch der Durchsatz bei Abfragen steigt. Zeitsensitive Abfragen Während bei Tabellen mit dem Systemzeitraum alle Änderungen, die während der normalen Systemzeit anfallen, archiviert werden, werden bei temporalen Tabellen Zeitspannen definiert, für welche bestimmte Daten gültig sein sollen. Denkbar wäre dies z.B. bei der Historisierung von Daten in Data-WarehouseSystemen. Historien müssten hier nicht mehr nach komplexen Regeln in ETL-Werkzeugen erstellt werden, sondern sind automatisch durch die Definition der entsprechenden Anwendungszeiträume in den tempo­ ralen Tabellen vorhanden. Speicherung der Daten nach der Zugriffshäufigkeit Zeilen- und Spaltenzugriffssteuerung Mit Row and Column Access Control (RCAC) wird eine neue Sicherheitserweiterung eingeführt. Mit ihr kann der Zugriff auf sensible Daten gesteuert und verwaltet werden. Im Gegensatz zur klassischen Zugriffssteuerung auf Tabellen können mit RCAC auch die Zugriffe auf einzelne Zeilen und/oder Spalten gesteuert werden. In der Datenbank werden verschiedene Regeln definiert, in welchen hinterlegt ist, wer auf welche Daten zugreifen darf. Denkbar ist z.B. ein Szenario, in welchem eine Führungskraft in einer Mitarbeiter­tabelle 16 ORDIX news 3/2012 In der Regel ist es wünschenswert, auf häufig be­nötigte Daten – meist aktuelle Daten – so performant wie möglich zugreifen zu können. Weniger häufig benötigte Daten – oftmals historische Daten – sind hingegen meist nicht so zeitkritisch beim Selektieren der Tabellen. Dies wird nun mit dem Multi Temperature Storage unterstützt. Hierbei werden Speicherbereiche (Storagegroups) definiert, welche auf schnellen – meist auch teuren - Platten, wie z.B. Solid Stade Drives (SDD) bzw. auf mittelschnellen oder langsameren Platten liegen. In diesen unterschiedlichen Speicherbereichen liegen dann, je nach Wichtigkeit und Zugriffshäufigkeit, Datenbanken die einzelnen Daten. Der Begriff Multi Temperature Storage wird verwendet, da IBM hier die Daten nach „hot“ für heiße und häufig genutzte Daten, „warm“ für warme und gelegentlich genutzte Daten sowie „cold“ für kalte und wenig genutzte Daten unterscheidet. Selbstverständlich können je nach Bedarf auch weniger oder mehr Storagegroups definiert werden. Dies war zwar prinzipiell schon immer möglich, indem die Daten in entsprechenden Tablespaces abgelegt wurden, welche wiederum auf schnellen oder langsameren Platten lagen. Jedoch ist es nun auch möglich, die Daten dynamisch zwischen den schnelleren und langsameren Festplattensystemen hin- und herzuschieben, wenn die Daten wichtiger oder eben weniger wichtig werden. Hochverfübarkeit Das High Availability Disaster Recovery (HADR) ist schon seit Version 8.2 Bestandteil von DB2. Neu ab Version 10.1 ist, dass nun mehrere Bereitschafts-datenbanken (bis zu drei) unterstützt werden. Bisher musste man immer zwischen Hochverfügbarkeit oder naher Standort entscheiden, eines der geforderten Kriterien kam zu kurz. Mit HADR 10.1 können nun beide Forderungen parallel erfüllt werden. Glossar SDD Solid State Drive ─ Nichtflüchtiger, durch Halbleiterbausteine realisierter Speicher, welcher im Gegensatz zu herkömmlichen Laufwerken sehr kurze Zugriffszeiten aufweist, sowie aufgrund der Bauweise eine wesentlich bessere mechanische Robustheit besitzt. ETL Extract, Transform, Load (ETL) ─ Ein Prozess, bei dem Daten aus mehreren ggf. unterschiedlich strukturierten Datenquellen in einer Zieldatenbank vereinigt werden. HADR High Availability Disaster Recovery ─ eine Datenbankreplikation von DB2, die vor dem Ausfall eines Datenbankservers schützt. Die veränderten Daten in der Datenbank werden dabei kontinuierlich vom Primärsystem auf ein Sekundärsystem repliziert. Beim Ausfall des Primärsystems wird den Clients innerhalb sehr kurzer Zeit das Sekundärsystem zur Verfügung gestellt, womit eine hohe Verfügbarkeit der Datenbank gewährleistet ist. Links ►► [1] DB2 V10.1 Information Center: http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/index.jsp Eine weitere Neuerung ist, dass nun eine Zeitver­ zögerung bei den Datenbankänderungen auf der Standby-Datenbank eingerichtet werden kann. Damit können z.B. Anwendungsfehler korrigiert werden, wenn sie erkannt werden bevor die Änderungen auf der Bereitschaftsdatenbank durchgeführt wurden. Alles wird schneller Michael Spoden ([email protected]) Wie immer wird natürlich mit jeder Version auch alles schneller und performanter. In erster Linie sind hier Erweiterungen beim Sammeln von Statistiken (Runstats), bessere Vorablesezugriffe auf Daten und Indizes (Smart Data Prefetching / Smart Index Prefetching) und ein besserer Zugriff bei zusammengesetzten Indizes (Jump Scan) zu nennen. Ausblick Nachdem dieser Artikel zunächst einen Überblick über die Funktionalitäten der neuen Datenbank­ version ge­ geben hat, werden wir uns die wichtigsten Neue­r­ungen in den nächsten Ausgaben etwas genauer ansehen. Beginnen werden wir mit den Funk­tionen „Multi Temperature Storage“ sowie „Time Travel Queries“. ORDIX news 3/2012 17 OpenSource OpenSource Cluster mit Pacemaker (Teil III) Kleine Features für große Cluster Pacemaker Cluster erfreuen sich einer immer größeren Beliebtheit und halten weiter Einzug in die Unternehmen. Bei vielen Kunden konnten wir durch Migra­ tion der alten Heartbeat 2 Cluster und den neuen Funktionen von Pacemaker überzeugen. Mit diesem Artikel möchten wir die Reihe [1] zum Pacemaker Cluster wieder aufgreifen und über weitere neue Funktionen berichten. Jeder Administrator mit seinen eigenen Rechten • Die Pacemaker-Version 1.1.5 oder neuer Die unterschiedlichen im Pacemaker Cluster eingesetzten Kommandos, wie beispielsweise crm_mon, CRM-Shell, cibadmin, Python-GUI, Hawk, etc. konnten bisher entweder als Benutzer root, hacluster oder über die Mitgliedschaft in der Gruppe haclient genutzt werden [2]. Jeder dieser Benutzer hatte automatisch vollen Zugriff auf den Cluster. Ein Rollen­ konzept gab es bisher nicht. Seit der Version 1.1.5 wurde die Funktion Access Control Lists (ACL) eingeführt, mit der für unterschiedliche Benutzer verschiedene Zugriffsrechte auf den Cluster vergeben werden können. Beispielsweise kann hier der Anwendungsbetreuer einer Ressource das Recht bekommen, seine Ressource zu starten oder zu stoppen oder auch nur das Monitoring der Ressource zu aktivieren und zu deaktivieren. Um die Funktion Access Control Lists in Pacemaker nutzen zu können, gilt es einige Regeln zu beachten: • Das Pacemaker-Schema muss • Die Benutzer sind normale Benutzer, sie müssen also in der /etc/passwd auf allen Knoten angelegt sein. Der Einsatz eines Verzeichnisdienstes wie LDAP ist hierbei sinnvoll. • Die Benutzer müssen Mitglied in der Gruppe haclient sein. # crm configure role operator \ write xpath:"//crm_config//nvpair[@name='maintenance-mode']" \ write xpath:"//op_defaults//nvpair[@name='record-pending']" \ write xpath:"//nodes/node//nvpair[@name='standby']" \ write xpath:"//resources//nvpair[@name='target-role']" \ write xpath:"//resources//nvpair[@name='is-managed']" \ write xpath:"//constraints/rsc_location" \ read xpath:"/cib" Abb. 1: Beispiel für eine typische Operator-Rolle mit den notwendigen Rechten. 18 ORDIX news 3/2012 muss auf allen Knoten installiert sein. in der Version 1.1 oder 1.2 vorliegen. • Die Access Control Lists müssen in Pacemaker aktiviert sein. • Die Benutzer root oder hacluster haben weiterhin Vollzugriff. • Die Verwaltungsbefehle des Cluster liegen im Normalfall unter /usr/sbin. Für die Nutzung als normaler Benutzer sollten diese mit vollem Pfad aufgerufen werden. Erstellen von Einträgen in der Access Control List Access Control Lists bestehen aus einer geordneten Zusammenfassung von Zugriffsregeln (rules). Jede Regel beinhaltet hierbei die Schlüsselwörter read, write oder deny, um den Zugriff auf Teile der Cluster Information Base zu steuern. Eine oder mehrere Regeln werden üblicherweise zu einer Rolle (role) zusammengefasst. Anschließend werden die Rollen den Benutzern zugeordnet. Alternativ besteht auch die Möglichkeit, Zugriffsregeln direkt mit den Benutzern zu verknüpfen. Dies ist aber aus Gründen der Übersichtlichkeit und Wiederverwertbarkeit der Regeln nicht zu empfehlen. Die Beschreibung der Objekte, auf die der Zugriff innerhalb der Cluster Informa­tion Base gewährt wird, erfolgt mittels der Xpath Syntax. Access Control Lists können entweder mit der Python-GUI oder der CRM-Shell erstellt werden. Die Abbildung 1 zeigt ein Beispiel für eine typische Operatorrolle. Die Zugriffsregeln werden der Reihenfolge nach, von oben nach unten abgearbeitet. Die erste zutreffende Regel für ein Objekt wird angewendet. Soll ein Benutzer Schreibrechte auf ein bestimmtes Objekt bekom- OpenSource men, ist es demnach notwendig das write-Recht vor einem eventuellen read-Recht auf dasselbe Objekt zu de­finieren. Da die Schreibberechtigung automatisch die Leseberechtigung beinhaltet, ist hier eine doppelte Vergabe der Rechte im Normalfall nicht notwendig. Werden keine Rechte auf ein Objekt vergeben, ist die Standardeinstellung automatisch deny. Damit die meisten Cluster-Befehle korrekt arbeiten, ist es notwendig, Leserechte auf bestimmte Daten der Cluster Information Base zu besitzen. Im Allgemeinen ist es hierbei am einfachsten, allen Benutzern Lesezugriff auf die komplette Cluster Information Base zu geben. Wurden Regeln vom Administrator für den Zugriff auf die Cluster Information Base erstellt, müssen diese noch mit den jeweiligen Benutzern verknüpft werden. In Abbildung 2 wird aufgezeigt, wie die Operatorrolle dem Benutzer „ordix“ zugeordnet wird. Die Vergabe von Zugriffregeln mittels der Variante Xpath hat einen Nachteil: Die genaue XML-Struktur der Cluster Information Base muss der Administrator wieder kennen. Da man beim Pacemaker Cluster nur selten mit XML konfrontiert wird, haben die Entwickler auch hierfür eine Lösung bereitgestellt. Die Angabe stellt bei der alternativen Schreibweise eine Kombination aus einem Tag und/oder einer Reference dar. Angenommen der XPath einer primitiven Ressource mit der Reference resource_IP1 wäre: /cib/resources/primitive[@id='resource_IP1'], dann ist die abgekürzte Schreibweise hierfür: tag: "primitive" ref:"rsc1". Die gekürzte Schreibweise kann auch für Constraints genutzt werden. Für den Xpath: /cib/constraint/rsc_location wäre die Kurzschreibweise: tag: "rsc_location". Der CIB Daemon weiß hierbei von selbst, wie er die ACL-Regeln auf die passenden Objekte anwenden muss. Die verkürzte Schreibweise kann entweder in der CRM-Shell oder der Python-GUI verwendet werden. Ressourcen erstellen mit Vorlagen Die größte Schwierigkeit beim Aufbau eines Cluster ist meistens die Namensgebung der Cluster-Ressourcen. Sieht man sich in Unternehmen mit mehreren Administratoren um, stellt man häufig fest, dass jeder Admini­ strator sein eigenes Namensschema für die Ressourcen verwendet. Zudem sind häufig die Beziehungen zwischen den Ressourcen unein­ heitlich oder haben verschiedene oder keine Monitorintervalle. Als Lösung gibt es in Pacemaker Templates, die der Vereinfachung und Vereinheitlichung der Konfiguration von Cluster-Ressourcen dienen. Mit ihnen ist es leicht möglich, Standards bei der Konfiguration auf allen Clustern des Unternehmens zu etablieren. Das Design ist so implementiert, dass mit mini­malem Aufwand schnell eine gültige Cluster-Konfiguration # crm configure user ordix role:operator Abb. 2: Zuweisung einer Rolle zu einem Benutzer. %name virtual-ip %required %% ip %optional %% netmask %% lvs_support %generate primitive %_ ocf:heartbeat:IPaddr params ip=%_:ip opt cidr_netmask=%_:netmask opt lvs_support=%_:lvs_support Abb. 3: Mitgeliefertes virtual-ip-Template von Pacemaker. crm(live)configure template# show ERROR: 27: required parameter ip not set Abb. 4: Ausgabe des Befehls show bei fehlenden Parametern. crm(live)configure template# show primitive virtual-ip ocf:heartbeat:IPaddr \ params ip="192.168.14.101" Abb. 5: Ausgabe des Befehls show mit gesetzten notwendigen Parametern ohne die darin enthaltenen Kommentare. erreicht werden kann. Auch für Neueinsteiger in Pacemaker sind die Templates ein guter Einstieg in die Handhabung und Erstellung von Cluster-Ressourcen. Die Templates sind Textdateien und werden im Verzeichnis /usr/share/crmsh/templates abgelegt. Von den Entwicklern wurden bereits einige Templates mitgeliefert, die als Vorlage für ein eigenes Template genutzt werden können. Werden Anpassungen an den Templates vorgenommen oder eigene erstellt, müssen diese auf alle Cluster-Knoten kopiert werden. Die Abbildung 3 zeigt das mitgelieferte Template virtual-ip. Das dargestellte Template besteht nur aus einer Ressource ohne Abhängigkeiten. %name legt den Namen der Ressource fest. Die nach %required ge­listeten Attribute mit %% müssen vom Administrator angegeben werden, hinter %optional angegebene sind entsprechend optional. Alles was nach %generate kommt, wird abschließend mit Hilfe der angegebenen Attribute gefüllt. Mit Hilfe eines Templates können auch mehrere Ressourcen mit Gruppen und entsprechenden Abhängigkeiten erstellt werden. Die Nutzung der Templates und das Befüllen der Attribute wird wiederum mit der Phython-GUI oder der CRM-Shell ORDIX news 3/2012 19 OpenSource durchgeführt. In der CRM-Shell befindet sich im Untermenu crm configure template alles was zur Verwendung der Templates benötigt wird. Folgende Funktionalitäten stehen zur Verfügung: • new • load • • • • • Erstellen einer neuen Konfiguration aus einem oder mehreren Templates Laden einer bereits genutzten Template-Konfi­ guration. Wurde eine Ressource mit einem Template erstellt, kann diese auch mit Hilfe des Templates verändert werden edit Befüllen einer Konfiguration mit Pflichtund optionalen Attributen delete Löschen einer Konfiguration list Anzeigen der verfügbaren Konfigurationen und Templates apply Übernahme einer Konfiguration in den Cluster show Anzeige der zu befüllenden Attribute Glossar ACL Access Control List ─ Zugriffssteuerungsliste, mit der Betriebssysteme und Anwendungsprogramme Zugriffe auf Daten und Funktionen eingrenzen können. Cluster Information Base XML-basierte Datei, in der die gesamte Cluster-Konfiguration enthalten ist. CRM-Shell In der Programmiersprache Python geschriebenes Kommandozeilenwerkzeug zu Verwaltung und Konfiguration des Pacemaker Cluster. Hawk (HA Webkonsole) Webbasierte Lösung zur Verwaltung und zum Monitoring von Pacemaker Clustern. Python-GUI In der Programmiersprache Python geschriebene grafische Anwendung zur Verwaltung und Konfiguration des Pacemaker Cluster. XPath Die XML Path Language ist eine vom W3-Konsortium entwickelte Abfragesprache, um Teile eines XML-Dokumentes zu adressieren. Links ►► [1] ORDIX news Artikel 3/2010 „OpenSource Cluster mit Pacemaker (Teil I) - Erstellen einer Ressource mit Hilfe eines Templates Sollen Ressourcen mit Hilfe von Templates erstellt werden, muss mit dem Befehl new eine neue Kon­ figuration erstellt werden. Hierbei sind ein Name, unter dem die Konfiguration gespeichert werden soll, und ein oder mehrere Templates anzugeben. Zum Beispiel lädt der Befehl new res_ip1 virtual-ip das Template virtual-ip und speichert es in der Konfi­ guration res_ip1. Vom Administrator müssen nun die Attribute befüllt werden. Mittels dem Befehl show werden alle fehlenden Pflichtattribute angezeigt. Die Abbildung 4 zeigt die Ausgabe des Befehls. Die Ausgabe hierbei gibt an, dass der Parameter ip nicht ange­geben wurde und die Zahl 27 gibt die Zeilenummer an, in der der Parameter innerhalb des Templates steht. Die notwendigen Parameter können nun einfach mit dem Befehl edit bearbeitet werden. Wurden alle Pflichtparameter angegeben, kann mit einem erneuten Befehl show das Resultat begutachtet werden. Als Ausgabe werden hierbei die fertigen CRM-Shell-Befehle ausgegeben. Die Abbildung 5 zeigt die Ausgabe des show-Befehls. Sollen Ressourcen, die mit Hilfe eines Templates erstellt wurden nachträglich verändert werden, so kann hier einfach die gespeicherte Konfiguration mittels des Befehls load geladen, mit dem Befehl edit verändert und einem abschließenden apply in den Cluster übernommen werden. Fazit Die hier beschriebenen Funktionen erleichtern die Administration von Pacemaker Clustern, wenn mehr als nur ein Administrator für die Konfiguration verantwortlich ist. Mit Hilfe der ACL ist eine Einschränkung auf die notwendigsten Befehle möglich, so dass kein kompletter Vollzugriff auf den Cluster mehr vergeben werden muss. Den Administratoren der „geclusterten“ Anwendungen können hier einfache Rechte zum Starten und Stoppen ihrer Anwendungen mit Hilfe von ClusterBefehlen eingerichtet werden. Mit den vorgestellten Templates kann bei mehreren Clustern schnell und einfach ein einheitliches Design geschaffen werden. Fehler in den Abhängigkeiten der Ressourcen oder ein fehlendes Monitoring gehören damit schnell der Vergangenheit an. Auch in künftigen ORDIX news werden wir weiter über das Thema Pacemaker und Cluster berichten und über weitere nützliche Funk­tionen informieren. Pacemaker – Schrittmacher für heartbeat?“: http://www.ordix.de/images/ordix/onews_archiv/3_2010/open_source_pacemaker.html ►► [2] ORDIX news Artikel 4/2011 „OpenSource Cluster mit Pacemaker (Teil II) Elegante Cluster-Administration mit der crm-Shell“: http://www.ordix.de/images/ordix/onews_archiv/4_2011/cluster_pacemaker.html ►► [3] Projektseite Hawk: http://www.clusterlabs.org/wiki/Hawk 20 ORDIX news 3/2012 Christian Fertsch ([email protected]) Java/JEE Java Best Practice Systeme modellieren mit UML Anforderungen sollten im Softwareentwicklungsprozess in Form einer Fachspezifika­ tion festgehalten werden. Mit Hilfe der Unified Modeling Language (UML) lässt sich ein Modell entwickeln, das umfangreiche Textdokumente ersetzen kann. Informationen können strukturiert und standardisiert festgehalten werden und lassen sich schnell wieder auffinden. Spezifikationslücken können einfacher erkannt und die Vollständigkeit der Spezifikation leichter überprüft werden. Zentrale Bedeutung der Fachspezifikation Die Fachspezifikation ist für die Softwareentwicklung von zentraler Bedeutung: Sie ist Bestandteil eines (manchmal auch juristisch wirksamen) Vertrages zwischen dem Anforderer und der Softwareent­wicklung. Kriterien der Abnahme und Diskussionen zu Change Requests basieren auf dieser Spezifikation. Auch für Testfälle ist die Fachspezifikation die wesentliche Informationsquelle. Die wichtigsten Anforderungen an eine Fachspezifikation fasst Abbildung 1 zusammen. Ein zunehmender Anteil der Projektaufwände muss für die Konzeptionsphase eingeplant werden. Im Gegensatz zur Realisierung, deren Produktivität aufgrund von intelligenten Entwicklungsumgebungen und mächtigen Frameworks stetig steigt, verwendet die Konzeption häufig die Textverarbeitung als wichtigstes Werkzeug. Hier wird die Geschwindigkeit vielfach durch die Anschläge pro Sekunde oder die Frequenz der neuronalen Impulse des Autors bestimmt. Bedeutungslosigkeit der Fachspezifikation Unter dem Erwartungsdruck entstehen oftmals viele hundert Seiten Text, die nicht selten noch während der Realisierungsphase an Bedeutung verlieren. Die Akzeptanz gegenüber einer umfangreichen Dokumentation ist oftmals nicht groß und die gesuchten Details sind schwer zu finden. Nur wenige Entwickler lesen die komplette Spezifika­ tion, wodurch sich häufig Nachfragen bei Kollegen oder der Fachseite ergeben. Die Entwickler bauen dadurch eigenes Know-how auf, das möglicherweise von den Anforderungen abweicht. Die Versuchung ist groß, dass auch die Tester sich Systeminformationen eher von den Entwicklern als aus der Fachspezifikation holen. In diesem Fall liegt die Wahrheit im Code – oder besser in dem, was die Entwicklung realisieren wollte. Vollständigkeit, Konsistenz und Übersichtlichkeit sind im Quellcode häufig eher gegeben als in der Spezifikation. So kommt der Entwicklung eine zunehmende Bedeutung zu, wenn es um die Klärung geht, wie sich das System verhält. Das Modell Die Dokumentation der fachlichen Anforderungen in Form eines UML-Modells kann Defizite der rein textbasierten Fachspezifikation beheben. Ziel ist es, die Spezifikation für den gesamten Lebenszyklus der Software einzusetzen. Damit kann erreicht werden, dass fachliche Aussagen und Entscheidungen von denjenigen getroffen werden, die auch die fachliche Expertise haben. Vollständigkeit: Alle für die Entwicklung erforderlichen Informationen müssen verfügbar sein. Konsistenz: Die Anforderungen dürfen sich nicht widersprechen. Übersichtlichkeit: Informationen sollen klar dargestellt und leicht gefunden werden. Rückverfolgbarkeit (Traceability): Die Auswirkungen von Anforderungen müssen nachvollziehbar sein. Abb. 1: Anforderungen an eine Fachspezifikation. ORDIX news 3/2012 21 Java/JEE grammen (siehe Abbildung 4), die das Verhalten des Systems für diesen Fall beschreiben. Vollständig ist das Aktivitätsdiagramm erst dann, wenn darin alle Informationen der Datenverarbeitung enthalten sind. Prinzipiell beschreibt auch heute noch das klassische EVA-Konzept die Daten­verarbeitung: Eingabe, Ver­arbeitung und Ausgabe. Die notwendigen Eingabedaten sind an­zugeben, wie diese verarbeitet werden sollen, sowie die Ausgabedaten. Zusätzlich zu EVA ist noch der Zustand des Systems zu berücksichtigen. Dieser wird durch die Daten dargestellt, die in der Datenbank abgelegt werden. Daher enthält das Aktivitätsdiagramm neben den Aktivitäten auch den Objektfluss. Dadurch wird deutlich, welche Daten benötigt werden. Im Beispiel „Benutzer anmelden“ werden Anmeldedaten und Daten zur Authentifizierung benötigt. Als Ergebnis wird ein Objekt vom Typ LoginResponse erzeugt. Beim Design der Aktivitätsdiagramme ergibt sich – beinahe zwangsläufig – die Beschreibung der erforderlichen Datenstrukturen. In Form von Klassendiagrammen werden zu persistierende Daten als Systemdaten, die ein- und ausgegebenen Daten im Paket Systemaußenkante und die übrigen als Systemprozessbegriffe verwaltet. Bilder allein reichen nicht Anwendungsfall-, Aktivitäts- und Klassendiagramm allein sind allerdings nicht ausreichend, um das Systemver­halten zu spezifizieren. Abb. 2: Aufbau des Modells. Modellstruktur 22 Die Klassendiagramme sind erst dann vollständig, wenn Datentypen und Gültigkeitsbereiche angegeben sind. Bei den Systemprozessbegriffen sollte zudem eine fachliche Definition der Klassen nicht fehlen. Vollständigkeit, Konsistenz und Übersichtlichkeit werden durch eine festzulegende Struktur des Modells sichergestellt. Im Folgenden wird exemplarisch eine von vielen möglichen Modellstrukturen (siehe Abbildung 2) näher beschrieben. Die Aktivitäten müssen die Datenverarbeitung vollständig, das heißt bis auf die Ebene der Attribute, beschreiben. Findet zum Beispiel eine Umwandlung der Daten in der Schnittstelle statt, so sind die Umwandlungsregeln zu spezifizieren. Diese Informationen finden sich in der Dokumentation zu den Aktivitäten. Generell sinnvoll ist eine anwendungsfallorientierte Anforderungsanalyse. Einstiegspunkt des Modells ist das Paket „Fachliche Systemanalyse“. In diesem findet die funktionale Beschreibung des Systemver­ haltens statt. Ausgehend vom Anwendungsfalldiagramm, z.B. „Seminar buchen“ (siehe Abbildung 3), gibt es im selben Paket für jeden Anwendungsfall ein gleich­namiges Verzeichnis mit den Aktivitätsdia­ Die Spezifikation ist eine mühsame Arbeit: jede Information, die nicht recherchiert und im Modell festgehalten wird, ist im günstigen Fall Gegenstand einer Nachfrage. Im ungünstigen Fall führt eine Lücke zu einer Interpretation – die kann bekanntlich zu falschen Annahmen und folglich zu ungewünschten Ergeb­ nissen führen können. ORDIX news 3/2012 Java/JEE Die Entscheidung Die Entscheidung, Anforderungen in Form eines UMLModells festzuhalten, löst allein noch keine Probleme. Ein geeignetes Werkzeug muss ausgesucht werden (z.B. Innovator, Enterprise Architect, magicdraw oder ArgoUML), die Möglichkeit des Teamwork muss gegeben sein und die Akzeptanz der Mitarbeiter und Abnehmer muss gewonnen werden. Das Modell ist dabei nur ein Medium. Die Qualität wird durch die fachliche und technische Ausbildung der Mitarbeiter geschaffen, die mit diesem Medium arbeiten. Die Qualität kann nur erhalten bleiben, wenn es während des gesamten Lebenszyklus einer Software kontinuierlich gepflegt wird. UML ist eine sehr mächtige Sprache, mit der sich sehr umfangreiche und detaillierte Modelle und Dia­ gramme erstellen lassen. Hier gilt es die Balance zwischen Aufwand und Nutzen nicht aus dem Auge zu verlieren: „Dokumentiere so viel wie nötig und so wenig wie möglich“. Abb. 3: Anwendungsfall „Seminar buchen“. Fazit Dieser Artikel hat einen ersten Einblick in die Struktur eines UML-Modells gewährt. Es wurde ein Eindruck vermittelt, wie das Modell bei der Dokumentation von Anforderungen genutzt werden kann und welchen Nutzen es für die Softwareentwicklung haben kann. Gern unterstützen wir Sie bei der Anforderungs­ analyse und -dokumentation in einer für Ihr Projekt geeigneten Form. Oder besuchen Sie unser Seminar zum Thema „Anforderungsanalyse mit UML‟. Abb. 4: Aktivitätsdiagramm „Benutzer anmelden“. Glossar Change Request Wenn sich Anforderungen nach Abschluss der Anforderungsdefinition für eine Software neu ergeben oder ändern. UML Dr. Stefan Koch ([email protected]) Unified Modeling Language - Modellierungssprache, mit der Geschäfts­ prozesse, Anforderungen und Softwaredesign beschrieben werden können. ORDIX news 3/2012 23 Seminare Datenbanken September - Dezember 2012 DB-DB-02 Datenbank-Hochverfügbarkeitslösungen für Entscheider 1 Tag 550,00 € 29.10.2012 | 10.12.2012 DB-DB-03 Datawarehouse Grundlagen 3 Tage 1.290,00 € DB-DB-01 Datenbank-Modellierung 2 Tage 890,00 € DB-ORA-01 Oracle SQL 5 Tage 1.890,00 € 24.09.2012 | 05.11.2012 | 03.12.2012 DB-ORA-01A Oracle SQL für Experten 3 Tage 1.290,00 € 29.10.2012 | 17.12.2012 DB-ORA-02 Oracle Datenbankprogrammierung mit PL/SQL Grundlagen 5 Tage 1.890,00 € 15.10.2012 | 19.11.2012 | 17.12.2012 DB-ORA-34 Oracle Datenbankprogrammierung mit PL/SQL Aufbau 5 Tage 1.890,00 € 24.09.2012 | 12.11.2012 DB-ORA-42 Oracle PL/SQL Tuning 3 Tage 1.890,00 € 03.09.2012 | 19.11.2012 DB-ORA-44 Entwicklung von Web-Anwendungen mit Oracle PL/SQL 2 Tage 1.090,00 € 27.09.2012 | 06.12.2012 DB-ORA-43 Oracle APEX Programmierung 3 Tage 1.890,00 € 17.09.2012 | 15.10.2012 | 17.12.2012 DB-ORA-38 Objektorientierung in Oracle 5 Tage 1.990,00 € 12.11.2012 DB-ORA-03 Oracle Datenbankadministration Grundlagen 5 Tage 1.990,00 € 10.09.2012 | 22.10.2012 | 10.12.2012 DB-ORA-04 Oracle Datenbankadministration Aufbau 5 Tage 1.990,00 € 03.09.2012 | 26.11.2012 DB-ORA-06 Manuelles Oracle Backup und Recovery & weitere Konzepte 5 Tage 1.990,00 € auf Anfrage DB-ORA-32 Oracle Backup und Recovery mit RMAN 5 Tage 1.990,00 € 24.09.2012 | 12.11.2012 | 03.12.2012 DB-ORA-07 Oracle Tuning und Monitoring 5 Tage 1.990,00 € 10.09.2012 | 05.11.2012 DB-ORA-41 Oracle AWR und ASH Analyse und Interpretation 3 Tage 1.290,00 € 29.10.2012 | 12.12.2012 DB-ORA-11 Oracle Troubleshooting Workshop 5 Tage 1.990,00 € 10.09.2012 | 03.12.2012 DB-ORA-08 Oracle 11gR2 RAC und Grid Infrastructure 5 Tage 1.990,00 € 22.10.2012 | 26.11.2012 | 17.12.2012 DB-ORA-15 Oracle 11g Neuheiten 5 Tage 1.990,00 € 03.09.2012 | 19.11.2012 DB-ORA-33A Oracle Security 4 Tage 1.590,00 € 17.09.2012 | 03.12.2012 DB-ORA-31 Oracle Data Guard 4 Tage 1.590,00 € 24.09.2012 | 22.10.2012 | 26.11.2012 DB-ORA-35 Oracle Grid Control 3 Tage 1.290,00 € 08.10.2012 | 10.12.2012 DB-ORA-36 Oracle Replikation 3 Tage 1.290,00 € auf Anfrage DB-ORA-37 Oracle Streams Advanced Queuing 3 Tage 1.290,00 € 19.11.2012 DB-ORA-39 Oracle Migration und Patching 3 Tage 1.290,00 € 05.11.2012 DB-ORA-40 Oracle Capacity Planning 3 Tage 1.290,00 € 26.11.2012 | 17.12.2012 DB-INF-01 IBM Informix SQL 5 Tage 1.790,00 € 08.10.2012 17.09.2012 | 29.10.2012 | 10.12.2012 22.10.2012 | 13.12.2012 DB-INF-02 IBM Informix Administration 5 Tage 1.990,00 € 22.10.2012 DB-INF-04 IBM Informix Dynamic Server Backup und Recovery 3 Tage 1.290,00 € 03.09.2012 | 19.11.2012 DB-INF-03 IBM Informix Tuning und Monitoring 5 Tage 1.990,00 € 24.09.2012 DB-INF-07 IBM Informix Hochverfügbarkeits-Technologien unter Unix 4 Tage 1.590,00 € 15.10.2012 DB-DB2-01 IBM DB2 für Linux/Unix/Windows SQL Grundlagen 5 Tage 1.890,00 € 10.09.2012 | 05.11.2012 DB-DB2-02 IBM DB2 für Linux/Unix/Windows Administration 5 Tage 1.990,00 € 12.11.2012 DB-DB2-05 IBM DB2 für Linux/Unix/Windows Monitoring und Tuning 3 Tage 1.290,00 € 08.10.2012 DB-MY-01 MySQL Administration 3 Tage 1.190,00 € 24.09.2012 | 26.11.2012 DB-MSSQL-1 Microsoft SQL Server Administration 5 Tage 1.790,00 € auf Anfrage P-PHP-01 PHP Programmierung Grundlagen 5 Tage 1.690,00 € 26.11.2012 P-PHP-02 PHP Programmierung Aufbau 3 Tage 1.190,00 € 03.12.2012 P-PERL-01 Perl Programmierung Grundlagen 5 Tage 1.690,00 € 15.10.2012 P-PERL-02 Perl Programmierung Aufbau 5 Tage 1.690,00 € 05.11.2012 P-UNIX-01 Shell | Awk und Sed 5 Tage 1.690,00 € 03.09.2012 | 12.11.2012 P-UNIX-01A Awk Intensiv-Workshop 3 Tage 1.190,00 € 29.10.2012 P-XML-01 Einführung in XML 3 Tage 1.190,00 € 17.09.2012 | 26.11.2012 P-XML-02 XML Programmierung unter Java mit DOM und SAX 2 Tage 890,00 € auf Anfrage P-XML-03 Oracle und XML 3 Tage 1.190,00 € auf Anfrage September - Dezember 2012 Entwicklung Web- und Applikations-Server September - Dezember 2012 INT-04 Apache Web-Server Installation und Administration 3 Tage 1.190,00 € 03.09.2012 | 15.10.2012 | 10.12.2012 INT-07 Tomcat Konfiguration und Administration 3 Tage 1.190,00 € 24.09.2012 | 19.11.2012 INT-08 WebSphere Application Server Installation und Administration 3 Tage 1.390,00 € 03.09.2012 | 03.12.2012 INT-11 Administration und Konfiguration für JBoss 3 Tage 1.190,00 € 17.09.2012 | 26.11.2012 Informationen und Anmeldung Für Informationen und Fragen zu individuell zugeschnittenen Seminaren, Ausbildungsreihen oder Inhouse-Schulungen stehen wir Ihnen gerne zur Verfügung. Auf Wunsch senden wir Ihnen auch unser komplettes Seminarprogramm zu. 24 ORDIX news 3/2012 Online-Anmeldung, aktuelle Seminarinhalte und Termine unter: http://training.ordix.de Seminare September - Dezember 2012 Systemmanagement SM-NAG-01 Systemüberwachung mit Nagios Grundlagen 3 Tage 1.190,00 € 22.10.2012 SM-NAG-02 Systemüberwachung mit Nagios Aufbau 2 Tage 890,00 € 25.10.2012 Anforderungsanalyse mit UML 3 Tage 1.190,00 € 15.10.2012 | 19.11.2012 Java-JEE E-UML-01 September - Dezember 2012 E-SWA-01 Softwarearchitekturen 5 Tage 1.890,00 € 24.09.2012 | 22.10.2012 | 03.12.2012 OO-01 Einführung in die Objektorientierte Programmierung 3 Tage 1.190,00 € 17.09.2012 | 12.12.2012 P-JAVA-01 Java Programmierung Grundlagen 5 Tage 1.690,00 € 08.10.2012 | 17.12.2012 P-JAVA-03 Java Programmierung Aufbau 5 Tage 1.690,00 € 05.11.2012 P-JAVA-02 Java GUI Entwicklung mit Swing 5 Tage 1.690,00 € 10.09.2012 | 10.12.2012 P-JEE-01 JEE für Entscheider 1 Tag 590,00 € 15.10.2012 P-JEE-02 Einführung in JEE 3 Tage 1.290,00 € 16.10.2012 P-JEE-03A JSP und Servlet Programmierung 5 Tage 1.590,00 € 03.12.2012 P-JEE-04 EJB Programmierung 5 Tage 1.590,00 € 22.10.2012 P-JEE-05 Web-Anwendungen mit JavaServer Faces (JSF) 5 Tage 1.590,00 € 12.11.2012 P-JEE-06 Entwickeln mit dem Spring-Framework 3 Tage 1.190,00 € 26.11.2012 INT-05 Java Web Services 3 Tage 1.190,00 € 08.10.2012 | 17.12.2012 J-HIB-01 Hibernate und die Java Persistence API 5 Tage 1.690,00 € 10.09.2012 | 19.11.2012 P-JEE-08 Java Performance Tuning 3 Tage 1.290,00 € 10.09.2012 | 29.10.2012 Betriebssysteme September - Dezember 2012 BS-01 Unix/Linux Grundlagen für Einsteiger 5 Tage 1.690,00 € 03.09.2012 | 05.11.2012 | 10.12.2012 BS-25 Unix Aufbauseminar für Datenbank- und Applikationsbetreuer 5 Tage 1.790,00 € 05.11.2012 | 19.11.2012 BS-02 Linux Systemadministration 5 Tage 1.690,00 € 10.09.2012 | 08.10.2012 | 19.11.2012 BS-09 Linux Hochverfügbarkeits-Cluster 3 Tage 1.290,00 € 08.10.2012 BS-19 Linux Cluster mit Pacemaker und Heartbeat 3 3 Tage 1.190,00 € 29.10.2012 | 12.11.2012 BS-16 OpenLDAP - Praxiseinsatz im Netzwerk 4 Tage 1.490,00 € 22.10.2012 BS-03 Solaris Systemadministration Teil I 5 Tage 1.990,00 € 24.09.2012 | 03.12.2012 BS-04 Solaris Systemadministration Teil II 5 Tage 1.990,00 € 08.10.2012 | 10.12.2012 BS-06 Solaris kompakt für erfahrene Unix/Linux-Umsteiger 5 Tage 1.990,00 € 17.09.2012 | 17.12.2012 BS-24 Solaris 11 Administration Neuheiten 5 Tage 1.990,00 € 08.10.2012 | 03.12.2012 BS-18 Solaris Virtualisierung mit ZFS und Container (Zonen) 5 Tage 1.990,00 € 10.09.2012 | 12.11.2012 BS-23 Solaris Virtualisierung mit LDOM 3 Tage 1.290,00 € 15.10.2012 AIX-01 IBM AIX Systemadministration Grundlagen 5 Tage 1.990,00 € 22.10.2012 AIX-02 IBM AIX Installation, Backup und Recovery mit NIM 3 Tage 1.290,00 € 17.09.2012 | 03.12.2012 AIX-03 Analyse v. komplexen AIX Performance Problemen 5 Tage 2.300,00 € 10.12.2012 September - Dezember 2012 Projektmanagement PM-01 IT-Projektmanagement - Methoden und Techniken 5 Tage 1.990,00 € 19.11.2012 PM-06 System. Projektmanagement - Projektteams souverän führen 4 Tage 1.850,00 € 08.10.2012 PM-08 Agiles Projektmanagement mit SCRUM 2 Tage 1.100,00 € 10.09.2012 | 06.12.2012 PM-09 Capability Maturity Model Integration (CMMI) 2 Tage 1.100,00 € 13.09.2012 | 26.11.2012 PM-10 Kennzahlen der IT 2 Tage 1.100,00 € 13.12.2012 | 18.10.2012 PM-07 Krisenmanagement in Projekten 2 Tage 1.100,00 € 03.09.2012 | 12.11.2012 PM-05 IT-Projektcontrolling 3 Tage 1.290,00 € 29.10.2012 PM-11 Konfliktmanagement 2 Tage 1.100,00 € 06.09.2012 | 15.11.2012 September - Dezember 2012 IT-Management MGM-02 IT-Architekturen 3 Tage 1.650,00 € 05.11.2012 MGM-01 E-Business 2 Tage 1.100,00 € 08.11.2012 MGM-07 IT-Strategien 2 Tage 1.100,00 € 24.09.2012 | 10.12.2012 MGM-08 Strategien effizient entwickeln 3 Tage 1.650,00 € 17.12.2012 MGM-03 IT-Management 5 Tage 1.990,00 € 17.09.2012 | 03.12.2012 MGM-05 IT-Risikomanagement 3 Tage 1.650,00 € 26.09.2012 | 28.11.2012 MGM-04 IT-Prozessmanagement 3 Tage 1.650,00 € 15.10.2012 Zentrale: ORDIX AG Westernmauer 12 - 16 33098 Paderborn Tel.: 05251 1063-0 Seminarzentrum: ORDIX AG Kreuzberger Ring 13 65205 Wiesbaden Tel.: 0611 77840-00 Unsere Seminarstandorte sind: Wiesbaden, Bielefeld und Hannover. Die Preise gelten pro Seminar pro Teilnehmer in Euro zzgl. ges. MwSt., Inhouse-Preise auf Anfrage. ORDIX news 3/2012 25 Datenbanken Wie mit der MySQL Sandbox Datenbankinstallationen ein Kinderspiel werden Sandkastenspiele Nach wie vor sind MySQL-Datenbanken meist eher kleinere Gebilde. Daher ist es üblich, dass oftmals mehrere Datenbankserver – auch in unterschiedlichen – Versionen auf einem Betriebssystem installiert werden. Giuseppe Maxia (siehe Glossar) hat mit „MySQL Sandbox“ ein hochwirksames Framework für die Bereitstellung und Verwaltung von eben solchen MySQL-Datenbanken entwickelt. Spielbeschreibung An und für sich ist die Bereitstellung von MySQLSys­temen auf einem Server kein großes Hexenwerk. MySQL selbst liefert zahlreiche Möglichkeiten (bis hin zu den eigenen Diensten mysqld_multi), um den Betrieb von mehreren Instanzen auf einem Server zu realisieren. Sofern der Administrator beim Aufbau der Systeme genügend Sorgfalt walten lässt und nicht aus Ver­sehen gemeinsame Ressourcen (z.B. Datenbankpfade, TCP/IP Ports o.ä.) verwendet, laufen solche Server problemlos. Spielteilnehmer Müssen jedoch eine Vielzahl von Systemen (z.B. in Entwicklungsumgebungen) bereitgestellt werden, 26 ORDIX news 3/2012 kann es unübersichtlich und damit fehleranfällig werden. Da­rüber hinaus ist die Bereitstellung und Konfiguration von solchen Systemen nicht unbedingt eine spannende Aufgabe. Eine zusätzliche Hürde kann die Verwendung von unterschiedlichen BetriebssystemAccounts für den Betrieb der DB-Server darstellen. So soll unter Umständen sichergestellt werden, dass ein konkurrierender Zugriff auf Daten nicht möglich ist. Spielaufbau Schnell sind die Vorbereitungen zum Einsatz von MySQL Sandbox [1] erledigt. Zunächst müssen die entsprechenden Perl-Module bei CPAN [2] herunter­ ge­ laden und installiert werden. Zusätzlich werden MySQL Binaries (gerne auch in mehreren auswählbaren Versionen) benötigt. Hier hat man die Wahl, ob man vorgefertigte Binary-TAR-Pakete extrahieren oder Datenbanken ob man selbst MySQL-Quellcode kompilieren möchte. Es empfiehlt sich, die entsprechenden Binaries gemäß ihrer Versions­nummer unterhalb des konfigurier­baren Pfades $SANDBOX_BINARY (default /opt/mysql) abzulegen (siehe Abbildung 1). Spielbeginn Nun kann mit dem Rollout von MySQL-Installationen begonnen werden. MySQL Sandbox bietet dafür mehrere Binaries, die für unterschiedlich komplexe Installationsszenarien geeignet sind. Die wichtigsten Binaries sind: • make_sandbox eignet sich für einzelne Installationen • make_multiple_sandbox kommt zur Anwendung, wenn auf einen Schlag mehrere Installationen (z.B. verschiedene Ver­sionen) installiert werden sollen • make_replication_sandbox wird zum Aufbau von – komplexen – Replikations­topologien verwendet Sofern kein Pfad über die Umgebungsvariabale SANDBOX_HOME oder per Parameter angegeben wird, erfolgt die Installation der jeweiligen Datenbankserver in das Home-Verzeichnis des User (siehe Abbildung 2). Spielverlauf Die entsprechenden Installationen sind in den definierten Verzeichnissen (z.B. im $HOME eines User) gekapselt, installiert und völlig autark von den anderen Installationen. Im Installationsverzeichnis befinden sich neben der physikalischen Datenbankdatei (Datenbankdateien, Konfigurationsdateien usw.) auch einige Werkzeuge für die Anwender und Administratoren des Datenbanksystems (siehe Ab­bildung 3). So gibt es beispielsweise Skripte, mit denen das System konsolidiert gestartet und gestoppt (start_all / stop_all) oder Kommandos über die gesamte Landschaft abgesetzt werden können (use_all). Spielkontrolle Zusätzlich gibt es für das Framework ein eigenes Kontrollinstrument: sbtool. Dieses Werkzeug ermöglicht es u.a.: • Die durch MySQL belegten oder noch freien bash> export SANDBOX_BINARY=/opt/mysql bash> cd $SANDBOX_BINARY bash> ls -la insgesamt 20 drwxr-xr-x 4 root root 4096 19. Jun 16:37 drwxr-xr-x 4 root root 4096 19. Jun 15:04 drwxr-xr-x 8 root root 4096 20. Apr 2009 drwxr-xr-x 9 root root 4096 19. Jun 16:40 . .. 5.1.32 5.5.3 Abb. 1: MySQL Binaries. Auf diesem Testsystem wurden zwei unter­ schiedliche MySQL-Versionen bereitgestellt (5.1.32 MariaDB & 5.5.3 MySQL). bash> time make_replication_sandbox --verbose --how_many_slaves=3 --check_base_port 5.1.32 … ....... sandbox server started Your sandbox server was installed in $HOME/sandboxes/rsandbox_5_1_32/master … starting slave 1 ... sandbox server started starting slave 2 ... sandbox server started starting slave 3 ... sandbox server started initializing slave 1 initializing slave 2 initializing slave 3 replication directory installed in $HOME/sandboxes/rsandbox_5_1_32 real user sys 0m37.024s 0m4.273s 0m7.488s Abb. 2: In nur 37 Sek. (in einer VM auf einem Notebook) wurden vier Systeme in einer Master-Slave-Topologie aufgebaut und gestartet. ls -la insgesamt 76 drwxrwxr-x 6 cst_ABC drwxrwxr-x 5 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC drwxrwxr-x 4 cst_ABC drwxrwxr-x 4 cst_ABC drwxrwxr-x 4 cst_ABC drwxrwxr-x 4 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC -rwxr-xr-x 1 cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC cst_ABC 4096 4096 303 554 1077 170 4096 4096 4096 4096 218 55 55 55 518 699 287 478 405 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. 20. Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun 13:44 13:44 13:44 13:44 13:44 13:44 13:43 13:44 13:44 13:44 13:44 13:44 13:44 13:44 13:44 13:44 13:44 13:44 13:44 . .. check_slaves clear_all initialize_slaves m master node1 node2 node3 restart_all s1 s2 s3 send_kill_all start_all status_all stop_all use_all Abb. 3: Diverse Shell-Skripte erleichtern dem Anwender den Umgang mit den installierten Systemen. Ports zu ermitteln. ORDIX news 3/2012 27 Datenbanken • Replikations-Baumstrukturen aufzubauen bash> make_multiple_sandbox 5.5.3 installing node 1 installing node 2 installing node 3 group directory installed in $HOME/sandboxes/multi_ msb_5_5_3 bash> sbtool --operation tree --tree_dir=/home/cst_ABC/ sandboxes/multi_msb_5_5_3 --master=1 --mid_nodes='2' --leaf_nodes='3' --verbose /home/cst_ABC/sandboxes/multi_msb_5_5_3/stop_all executing "stop" on node 1 executing "stop" on node 2 executing "stop" on node 3 node 1 is master ..... sandbox server started ...... sandbox server started enabling node 2 to relay updates ... sandbox server started node 2 is slave of node 1 .... sandbox server started ...... sandbox server started node 3 is slave of node 2 Abb. 4: In weniger als 1 Minute und mit nur zwei Befehlen wurden zunächst drei Systeme erzeugt und dann in einer Kettentopologie (Master → Slave → Slave) als Replikation aufgesetzt. (Master Node → Mid Nodes → Leaf Nodes). • Installationen zu löschen oder vor einem versehentlichen Löschen zu schützen. • Konfigurationsänderungen durchzuführen. • Datenbanken zu clonen. Die Anwendung dieses Werkzeugs ist in Abbildung 4 dargestellt. Spielbewertung MySQL Sandbox ist ein kleines, aber sehr hilfreiches Framework zum Aufbau und zur Verwaltung von vielen kleinen MySQL-Installationen. Die Software arbeitet zuverlässig, transparent (entsprechendes Shell-, Perlund MySQL-Know-how vorausgesetzt) und effektiv. Die Syntax der Kommandos ist einfach und gut dokumentiert. Kurz gesagt: Es macht Spaß mit diesem Framework zu arbeiten. Links ►► [1] Installationsanweisung von MySQL Sandbox: http://mysqlsandbox.net/ ►► [2] Downloadseite der Zusatzmodule: http://search.cpan.org/~gmax/MySQL-Sandbox-3.0.25/lib/MySQL/Sandbox.pm Matthias Jung ([email protected]) Glossar CPAN Comprehensive Perl Archive Network ─ offenes Online-Archiv für Perl-Module und -Anwendungen Guiseppe Maxia Systemanalyst, Datenbank-Designer und Programmierer mit dem Fokus auf die Etablierung neuer Systeme und die Migration/Optimierung alter Systeme. Bild: © sxc.hu | Nienke 2 | Kverhees © sxc.hu | Nienke 1 | Kverhees 28 ORDIX news 3/2012 Datenbanken Neue Reihe: Räumliche Daten mit Oracle Spatial (Teil I) Mehr Raum für die Datenbank Sind Sie schon einmal an der Kasse eines Elektromarktes nach Ihrer Postleitzahl gefragt worden? Was macht diese Information für das Unternehmen so interessant? Sie gibt Auskunft darüber, wo seine Kunden wohnen. Daraus kann wiederum ermittelt werden, wie groß das Einzugsgebiet dieser Filiale ist und wo dessen räumlicher Schwerpunkt liegt. Diese Informationen können nun als wichtige Unterstützung für unternehmerische Entscheidungen dienen, wie z.B. „Wo eröffnen wir eine neue Filiale?“ oder auch bloß „Wo platzieren wir die nächste Plakatwerbung?“. Ein großer Teil vor allem strategischer Fragestellungen beginnt mit „wo“ und zur Beantwortung dieser Fragen werden räumliche Daten (Geodaten) benötigt. Was diese Daten aus technischer Sicht so besonders macht und wie sie in einem Oracle Datenbanksystem verwaltet werden, stellen wir Ihnen in dieser neuen Reihe vor. Was sind räumliche Daten? Räumliche Daten beantworten die Frage, wo sich ein Objekt befindet (seine Lage im Raum) bzw. wie seine physische Struktur (Geometrie) beschaffen ist. Zu diesem Zweck werden die Daten in einem geo­gra­ phischen Referenzsystem mittels Koordinaten verortet bzw. gespeichert. Soll die Struktur und Lage eines Objekts auf der Erde beschrieben werden, dient hierzu meist das bekannte Koordinatensystem aus Längenund Breitengraden, welche den Erdball umspannen (geographische Länge/Breite). Je nach ihrer physischen Struktur können diese Daten bei zweidimensionaler Darstellung als Punkte (ein einzelnes Koordinatenpaar), Linien (Verbindung zwischen zwei oder mehreren Punkten), Flächen (geschlossener Linienzug bzw. Polygon) sowie Kombinationen aus diesen Datentypen beschrieben werden. Warum sind räumliche Daten anders? Die typischen Daten, welche normalerweise in einer Datenbank gespeichert werden, sind Zahlen und Zeichenketten. Diese Datentypen haben gemein, dass sie sich relativ leicht kategorisieren und vergleichen lassen. Ein numerischer Wert kann z.B. daraufhin untersucht werden, ob er kleiner, größer oder gleich einem anderen numerischen Wert ist. Zeichenketten können ebenfalls daraufhin geprüft werden ob sie identisch sind, ob ein bestimmtes Suchmuster in ihnen enthalten ist oder ob sie in einer vorgegebenen Menge von Begriffen vorkommen. Zudem können diese Daten leicht sortiert werden. Mit räumlichen Daten ist dies hingegen ungleich komplexer. Eine Liste von Städten lässt sich beispielsweise zwar leicht nach ihren Namen oder Einwohnerzahlen sortieren, jedoch nicht nach ihrer Lage. Allerdings könnten sie z.B. daraufhin untersucht werden, • ob sie sich in einer bestimmten Entfernung zueinander befinden. • welche der Städte näher zu einer anderen liegt. • ob sie sich innerhalb der Fläche des gleichen Bundeslandes befinden. CREATE TYPE sdo_geometry AS OBJECT ( SDO_GTYPE NUMBER, SDO_SRID NUMBER, SDO_POINT MDSYS.SDO_POINT_TYPE, SDO_ELEM_INFO MDSYS.SDO_ELEM_INFO_ARRAY, SDO_ORDINATES MDSYS.SDO_ORDINATE_ARRAY); Abb. 1.: Der Objekttyp SDO_GEOMETRY. ORDIX news 3/2012 29 Datenbanken create table vereine ( idnumber primary key, name varchar2(30), stadt varchar2(30), location SDO_GEOMETRY ); Abb. 2: Tabelle mit Spalte SDO_GEOMETRY anlegen. insert into vereine values ( 1, 'Werder Bremen', 'Bremen', SDO_GEOMETRY ( 2001, -- zweidimensionaler Punkt 8307, -- Koordinatensystem ist „geograhische Länge/Breite“ SDO_POINT_TYPE(8.8375890,53.0663953,NULL), NULL, NULL ) ); Abb. 3: INSERT für Punktdatensätze vom Typ SDO_GEOMETRY. insert into vereine values ( 1, 'Werder Bremen', 'Bremen', SDO_GEOMETRY (' POINT(8.8375890 53.0663953) ', 8307 ) ); Abb. 4: INSERT für Punktdatensätze im Well-Known-Text Format (WKT). select from where and ; ROUND( SDO_GEOM.SDO_DISTANCE( v1.location, -- Ort A v2.location, -- Ort B 1, -- Toleranz: 1 Meter 'UNIT=KM' -- Angabe in Kilometern ) ) as distanz_in_km vereine v1,vereine v2 v1.name = 'Werder Bremen' v2.name = 'Borussia Dortmund' DISTANZ_IN_KM ------------199 Abb. 5: Abfrage von Distanzen mit der Funktion SDO_DISTANCE. Der Typ SDO_GEOMETRY in Oracle Zur Verwaltung räumlicher Daten in einer OracleDatenbank dient die Funktion Oracle Locator, welche Bestandteil der Standard Edition ist. Sie liefert im Wesentlichen den Objekttyp SDO_GEOMETRY zur Speicherung der Daten, diverse Operatoren und Funktionen zur Verarbeitung sowie eine spezielle Indizierung für räumliche Daten. Das separat zu lizensierende „Oracle Spatial“ wird für zusätzliche Funktionen und Datentypen benötigt. Die detaillierten Unterschiede zwischen den beiden Paketen werden in einem der nächsten Artikel dieser Reihe behandelt. Die räumliche Information eines Datensatzes wird in einer Spalte vom Typ SDO_GEOMETRY gespeichert, welcher, wie in Abbildung 1 zu sehen, definiert ist. Die einzelnen Attribute haben folgende Bedeutung: • SDO_GTYPE: Datentyp des Objekts (Punkt, Linie, Polygon oder Kombinationen daraus) sowie die Anzahl der Dimensionen (2-4) • SDO_SRID: geographisches Referenzsystem (Koordinatensystem) • SDO_POINT: Koordinaten des Objekts, falls es sich um einen einfachen Punkt handelt • SDO_ELEM_INFO: Beschreibt, wie die nachfolgenden Koordinaten in SDO_ORDINATES zu interpretieren sind (bei Linien und Polygonen sowie zusammen­ gesetzten Objekten). • SDO_ORDINATES: Koordinaten des Objekts, falls es sich um eine Linie, ein Polygon oder eine Kombination handelt. Wir werden uns in diesem Artikel zunächst mit dem einfachsten Datentyp beschäftigen, dem Punkt. Die Arbeit mit Linien und Polygonen werden in den nächsten Artikeln der Reihe beschrieben. Geodaten anlegen Für diese Art von Prüfungen werden jedoch zusätzlich räumliche Operatoren und Funktionen benötigt, denn mit den bekannten „größer, kleiner, gleich“ kommen wir an dieser Stelle nicht weiter. 30 ORDIX news 3/2012 Im folgenden Beispiel sollen die 18 Vereine der Fußball Bundesliga sowie der jeweilige Ort ihres Stadions in Form eines Punktes in der Datenbank ge- Datenbanken speichert werden. Zu diesem Zweck wurde die Tabelle vereine angelegt, wie in Abbildung 2 zu sehen. Die Vereine sowie der Ort ihres Stadions werden nun als Punktdatensatz mit seinen Koordinaten in die Spalte location eingefügt (siehe Abbildung 3). Alternativ liefert der SDO_GEOMETRY einen Konstruktor, mit dem sich die Daten im WKT-Format (Well-Known-Text) auch auf einfachere Weise importieren lassen (siehe Abbildung 4). Räumliche Funktion: SDO_DISTANCE() Mit den so erzeugten Daten lassen sich nun räumliche Abfragen definieren. Eine der einfachsten Möglichkeiten ist die Funktion SDO_DISTANCE aus dem Paket SDO_GEOM, welche die Distanz zwischen zwei Objekten ermittelt (siehe Abbildung 5). Die Spielstätten der ausgewählten Vereine liegen also ca. 199 Kilometer auseinander. Bei den meisten räumlichen Funktionen und Operatoren muss ein Toleranzwert angegeben werden, welcher bestimmt, ab welcher Dis­ tanz zwei Punkte als identisch angesehen werden sollen. Diese Information ist insbesondere dann interessant, wenn geprüft werden soll, ob sich zwei Flächen berühren. Bei der o.a. Distanzberechnung ist er hingegen zu vernachlässigen, muss aber dennoch angegeben werden. Im nächsten Beispiel soll nun mit Hilfe der Funktion SDO_DISTANCE ermittelt werden, welcher Verein den höchsten Reiseaufwand im Laufe einer Bundesliga­ saison hat. Dazu berechnen wir pro Verein die Summe der Distanzen zu jedem anderen Verein in der Bundes­liga (siehe Abbildung 6). Räumliche Funktion: SDO_DISTANCE_WITHIN() Als nächstes möchten wir gerne ermitteln, für welche Großstadt in Deutschland die meisten Bundesliga-Vereine im Umkreis von 200 km erreichbar sind. Eine Liste der deutschen Großstädte wurde dazu analog zu den Vereinen in die Tabelle „staedte“ geschrieben (siehe Abbildung 7). Die Anzahl der Vereine, welche sich im Umkreis von 200 km um die jeweilige Stadt befinden lässt sich nun wie in Abbildung 8 dargestellt ermitteln. Problematisch bei dieser Abfrage ist jedoch, dass in diesem Fall zunächst die Distanz jeder Stadt zu jedem Verein ermittelt werden muss (karthesisches Produkt). Um dies zu vermeiden kann stattdessen der Operator select v1.name as VEREIN, ROUND(SUM( SDO_GEOM.SDO_DISTANCE( v2.location, v1.location, 1, 'UNIT=KM' ) )) as KM from vereine v1,vereine v2 where v1.id <> v2.id group by v1.name order by KM desc ; VEREIN KM ------------------------------ ---------Hamburger SV 6608 Bayern München 6207 SC Freiburg 5954 ... Bayer Leverkusen 4077 FSV Mainz 05 3763 Eintracht Frankfurt 3670 Abb. 6: Reiseaufwand der Bundesliga-Vereine berechnet mit SDO_DISTANCE. create table staedte ( id int primary key, name varchar2(30), location SDO_GEOMETRY ); insert into staedte values ( 1,'Berlin',SDO_GEOMETRY ( ' POINT( 13.3888548 52.5170397 ) ', 8307 ) ); insert into staedte values ( 2,'Paderborn',SDO_GEOMETRY ( ' POINT( 8.752653 51.7177044 ) ', 8307 ) ); ... Abb. 7: Anlegen der Tabelle „staedte“. select * from ( select s.name, ( select count(id) from vereine where SDO_GEOM.SDO_DISTANCE( location, s.location,1, 'UNIT=KM') < 200 ) as vereine_naeher_als_200km from staedte s order by 2 desc ) where rownum <= 10 ; NAME VEREINE_NAEHER_ALS_200KM ------------------------------ -----------------------Frankfurt 11 Paderborn 10 Recklinghausen9 Offenbach am Main9 Osnabrück 9 Bielefeld 9 Wiesbaden 9 Dortmund 9 Stuttgart 9 Reutlingen 9 Abb. 8: Suche nach Bundesliga-Spielstätten im Umkreis von 200 km. ORDIX news 3/2012 31 Datenbanken select * from ( select s.name, ( select count(id) from vereine where SDO_WITHIN_DISTANCE( location, s.location, 'distance=200 UNIT=KM') = 'TRUE' ) as vereine_naeher_als_200km from staedte s order by 2 desc ) where rownum <= 10 ; Abb. 9: Optimierung der Abfrage mit SDO_WITHIN_DISTANCE(). SDO_WITHIN_DISTANCE() als WHERE-Bedingung eingesetzt werden, wie in Abbildung 9 gezeigt. Um diesen Operator nutzen zu können, muss jedoch zunächst ein räumlicher Index für die beteiligten Tabellen vorhanden sein (Spatial-Index). Ausblick Wie ein räumlicher Index angelegt wird und wie er im Gegensatz zu einem „normalen“ Index arbeitet, zeigen wir im nächsten Teil dieser Artikelreihe. Ebenso werden wir Ihnen weitere räumliche Funktionen und Operatoren vorstellen. Link ►► [1] Oracle Spatial http://www.oracle.com/de/products/database/options/spatial/index.html Christof Amelunxen ([email protected]) Seminarempfehlung: Oracle Datenbankadministration Grundlagen ►► Informationen/Online-Anmeldung: http://training.ordix.de/siteengine/action/load/kategorie/Datenbanken/nr/35/index.html In diesem Seminar werden Sie mit der Verwaltung und Analyse von Oracle-Datenbanken vertraut gemacht. Da die Grundlage aller administrativen Tätigkeiten das Verständnis der Oracle-Architektur ist, werden Sie intensiv in den Aufbau und die Struktur eingeführt. Somit sind Sie in der Lage, grundlegende Administrationen der Datenbank vorzunehmen. Das Seminar wird sowohl unter Windows als auch unter Unix gehalten. Seminarinhalte Grundlagen: die Oracle-Architektur, das Data Dictionary Installation eines Datenbanksystems Datenbankverwaltung Instancehandling: Startup/Shutdown Grundlagen Backup und Recovery Benutzerverwaltung, Rechtekonzept, Zugriffsschutz, Password-File, Profile • Verteilte Datenbanken: Database Links • Einführung in die Konfiguration von Oracle Net • Tools: DataPump, Export, Import, SQL*Loader • National Language Support (NLS) • Vertiefung der Theorie durch praktische Übungen und Beispiele • • • • • • 32 ORDIX news 3/2012 Termine 10.09.- 14.09.2012in Bielefeld 22.10.- 26.10.2012in Wiesbaden 10.12.- 14.12.2012in Wiesbaden Seminar-ID: DB-ORA-03 Dauer: 5 Tage Preis pro Teilnehmer: 1.990,00 € (zzgl. MwSt.) Frühbucherpreis: 1.791,00 € (zzgl. MwSt.) NACHHALTIGKEIT ist UNS wichtig! Wussten Sie, dass wir in Deutschland ca. 250 Kilogramm Papier pro Kopf im Jahr verbrauchen? Im Zuge des wachsenden Umweltbewußtseins haben wir uns entschlossen Sie, liebe Leser anzusprechen. Helfen Sie uns die Umwelt zu schonen und abonieren Sie die ORDIX news in digitaler Form. Besuchen Sie unsere ORDIX news Anmeldung unter: http://news.ordix.de Internet­seite und ändern Sie Ihr Abonnement auf ein Online-Abonnement. Natürlich werden wir die ORDIX news auch weiterhin in Papierform anbieten. Möchten Sie die ORDIX news wie bisher erhalten, ändert sich für Sie nichts. Java/JEE Hibernate für Fortgeschrittene (Teil III) Was ist die optimale BatchSize? In den beiden vorangegangenen Artikeln dieser Reihe [2,3] haben wir zwei Opti­mierungsmöglichkeiten beschrieben, mit denen das N+1-Select-Problem gelöst werden kann. Eine der beiden Möglichkeiten ist die Verwendung einer BatchSize. Was bei der Wahl der BatchSIze zu beachten ist, fasst dieser Artikel zusammen. Die grundsätzliche Strategie Ist bei einer Relation zwischen den Klassen A und B die BatchSize-Strategie definiert, so wird bei der Navigation von A nach B nicht nur die Menge der B-Objekte geladen, die zu dem aktuellen A-Objekt gehört. Stattdessen lädt Hibernate gleich mehrere A-B-Relationen. Hierdurch kann meistens eine wesentlich bessere Performance erreicht werden, da die Anzahl der Select-Befehle reduziert wird. Wie viele Relationen gleichzeitig aus der Datenbank geladen werden, definiert die BatchSize. Unter- und Obergrenze Wenn also eine Relation noch nicht initialisiert ist und ein Zugriff auf diese erfolgt, so bestimmt Hibernate 34 ORDIX news 3/2012 alle A-Objekte, deren Relationen ebenfalls noch nicht initialisiert sind und initialisiert so viele Relationen, wie die BatchSize angibt. Hier ergibt sich dann natürlich die Frage, wie diese BatchSize am besten eingestellt wird, um eine optimale Performance zu erreichen. Der Wert 1 als Untergrenze ist keine sinnvolle Wahl, da dies dem normalen, nicht optimierten Verhalten von Hibernate entspricht. Bei der Obergrenze müssen die Beschränkungen des Datenbanksystems beachtet werden. Die Verwendung einer BatchSize führt zu einem Statement der Form SELECT * FROM <TABLE> WHERE <ID> IN (ID-1, …, ID-N). Bei Oracle z.B. darf N maximal 1000 sein. Ist für die BatchSize ein größerer Wert definiert, so wird dies diverse Fehlermeldungen zur Folge haben, denn Hibernate gleicht die BatchSize nicht mit den Grenzen der Datenbank ab. Java/JEE Kosten und SubSelect Mit der BatchSize wird die Anzahl der Statements verringert, mit dem Ziel, insgesamt die Performance zu verbessern. Deshalb müssen in diesem Zusammenhang auch die Kosten bzw. Ausführungszeiten be­ rücksichtigt werden. Denn je größer die BatchSize gewählt wird, desto größer sind die Kosten für das Statement. Diese kann man mit den Kosten für ein Statement vergleichen, das bei der Verwendung der alternativen SubSelect-Strategie von Hibernate generiert wird. Bei diesen Messungen sollte aber eine Datenbank vorliegen, die eine realistische Größe und Verteilung der Daten aufweist. Bei den von mir durchgeführten Vergleichen war fast immer festzustellen, dass die Ausführungszeiten bei beiden Strategien bis zu einer Ergebnisgröße von ca. 10 fast konstant bleiben. Darüber hinaus führt eine Verdoppelung der Ergebnisgröße nicht zu einer Verdoppelung der Laufzeit. Erfolgen die Abfragen nur über den Primärschlüssel, so kann sogar die SubSelect-Strategie schon bei kleinen Ergebnismengen zu besseren Laufzeiten führen als die BatchSize-Strategie. Ist die Komplexität der SubSelect-Statements zu hoch, so sind die Laufzeiten sehr wahrscheinlich immer schlechter. Manchmal hingegen lässt sich beobachten, dass bei kleinen Er­gebnismengen die BatchSize-Strategie die besseren Laufzeiten aufweist und bei größeren Ergebnismengen die SubSelect-Strategie. Hier muss also von Fall zu Fall abgewogen werden, welche Strategie zum Einsatz kommen soll. Tatsächliche Anzahl der Statements Wenn eine BatchSize von N für eine Relation eingestellt ist und M nicht-initialisierte Relationen vorliegen, so ist natürlich interessant, wie viele Statements letztendlich von Hibernate erzeugt werden, bis alle Initialisierungen durchgeführt wurden: Nicht überraschend ist der Fall N = M, denn hier wird genau ein Statement erzeugt. Ist N < M, so wird ein Statement generiert, um die ersten N Relationen zu initialisieren. Für die verbleibenden M-N Relationen gilt dann rekursiv das hier Beschriebene. Das Ergebnis für den letzten Fall N > M ist ver­blüffend, denn hier würde man normalerweise ebenfalls genau ein Statement erwarten. Doch die Antwort ist etwas komplizierter. Hibernate generiert nämlich schon im Vorfeld die Select-Anweisungen für die BatchSize- SELECT SELECT … SELECT SELECT SELECT SELECT SELECT SELECT SELECT * FROM <TABLE> WHERE <ID> = ID-1 * FROM <TABLE> WHERE <ID> IN (ID-1, ID-2) * * * * * * * FROM FROM FROM FROM FROM FROM FROM <TABLE> <TABLE> <TABLE> <TABLE> <TABLE> <TABLE> <TABLE> WHERE WHERE WHERE WHERE WHERE WHERE WHERE <ID> <ID> <ID> <ID> <ID> <ID> <ID> IN IN IN IN IN IN IN (ID-1, (ID-1, (ID-1, (ID-1, (ID-1, (ID-1, (ID-1, …, …, …, …, …, …, …, ID-10) ID-15) ID-31) ID-62) ID-125) ID-250) ID-500) Abb. 1: Erzeugte Statements bei einer BatchSize mit N=500. for (C c : cList) { System.out.println("C: " + c.getId()); for (A a : c.getA()) { System.out.println(" A: " + a.getId()); for (B b : a.getB()) { System.out.println(" B: " + b.getId()); } } } for (D d : dList) { System.out.println("D: " + d.getId()); for (A a : d.getA()) { System.out.println(" A: " + a.getId()); for (B b : a.getB()) { System.out.println(" B: " + b.getId()); } } } Abb. 2: Das Ausgabeprogramm für die Relationen A-B, C-A und D-A. for (D d : dList) { d.getA().size(); } Abb. 3: Initialisierung der D-A-Relation. Strategie und wählt dann zur Laufzeit das entsprechende Statement aus. Um die Anzahl der generierten Statements gering zu halten, werden nicht alle Statements SELECT * FROM <TABLE> WHERE <ID> IN (ID-1, … ID-I) für 1<=I<=N generiert, sondern nur für I aus N, N/2, N/4, N/16, …, 10, 9, 8, …, 1. Ist also beispielsweise die BatchSize N auf 500 eingestellt, so werden im Vorfeld die in Abbildung 1 dargestellten Statements erzeugt. Dies führt dazu, dass bei N=500 und M=497 7 Statements an die Datenbank geschickt werden (und zwar mit 250, 125, 62, 31, 15, 10 und 4 IDs). Fazit: Selbst bei einer optimalen BatchSize wird nur im Ausnahmefall genau ein Statement erzeugt! ORDIX news 3/2012 35 Java/JEE Links ►► [1] ORDIX news Artikel 03/2009 „Performance-Tests mit Hibernate (Teil III): Lazy und Eager Loading - ein guter Cache lädt nicht mehr als er muss“: http://www.ordix.de/images/ordix/onews_archiv/pdf/news0903.pdf ►► [2] ORDIX news Artikel 01/2012 „Hibernate für Fortgeschrittene (Teil I): Die Batch-Fetching-Strategie für Relationen richtig anwenden“: http://www.ordix.de/images/ordix/onews_archiv/1_2012/hibernate_batch_fetching_ strategie.html ►► [3] ORDIX news Artikel 02/2012 „Hibernate für Fortgeschrittene (Teil II): SubSelect oder BatchSize? Das ist hier die Frage“: http://www.ordix.de/images/ordix/onews_archiv/2_2012/hibernate_subselect.html ►► [4] Leseempfehlung: Java Persistence mit Hibernate von Gaving King, Christian Bauer, Jürgen Dubau haben und diese nacheinander ausgeben wollen (siehe Abbildung 2), so werden 4 Statements ge­ neriert, da zunächst die Relationen C-A, A-B, D-A und schließlich erneut A-B initialisiert werden. Wird hingegen zunächst die Relation D-A initialisiert (siehe Abbildung 3), so sind insgesamt nur noch 3 Statements nötig, um das gesamte Objektgeflecht zu laden. Mit dem ersten Statement wird D-A initialisiert, mit dem zweiten C-A und mit dem dritten Statement kann Hibernate alle A-B-Relationen initialisieren, unabhängig davon, ob das A-Objekt von C oder D referenziert wird. In einem aktuellen Projekt wurde zur Initialisierung der unterschiedlichen Relationen ein recht komplexes Verfahren implementiert, mit dessen Hilfe ein Objekt­ geflecht durchlaufen wird. Es nutzt den oben beschrieben Effekt aus und die Ergebnisse sind sehr zufriedenstellend, auch wenn die Konfiguration sehr kompliziert und aufwendig ist. Bild: © istockphoto.com | Blank 3d Cubes | teekid Unnötige Initialisierungen Wie in den vorangegangen Artikeln dieser Reihe bereits beschrieben, ist ein Nachteil dieser Vor­ gehensweise die Initialisierung zu vieler Relationen, die für die anstehenden Arbeiten überhaupt nicht benötigt werden. Insgesamt kann dies dann sogar zu einer Verschlechterung der Performance führen. Deshalb sollte diese Optimierungsstrategie mit Bedacht eingesetzt werden. Um den Fehler gering zu halten, kann natürlich die BatchSize auf einen kleineren Wert eingestellt werden. Es werden dann vielleicht zu viele Objekte geladen, doch bei einer kleinen BatchSize fällt das nicht zu sehr ins Gewicht. Eine andere Möglichkeit besteht darin, die A-Objekte, deren Relationen zu B nicht initialisiert werden sollen, mittels des Befehls evict aus der Session zu entfernen. Hierdurch bleiben sie unberücksichtigt, wenn die nicht ini­ tialisierten Relationen von Hibernate ermittelt werden, um das IN-Statement mit den entsprechenden IDs aufzufüllen. Wichtig ist aber auch die Reihenfolge, in der das Objektgeflecht durchlaufen wird Denn diese kann einen erheblichen Einfluss auf die Anzahl der generierten Statements haben. Das möchte ich an einem Beispiel mit drei One-To-Many-Relationen A-B, C-A und D-A verdeutlichen. Nehmen wir an, dass wir eine Liste mit C- und eine Liste mit D-Objekten geladen 36 ORDIX news 3/2012 Fazit In vielen Fällen kann das Setzen einer beliebigen BatchSize die Performance ausreichend verbessern. Aber wenn diese Maßnahme nicht den erhofften Erfolg gebracht hat, so muss genauer analysiert und müssen eventuell genauere Justierungen vorgenommen werden. Hierbei können die Informationen aus diesem Artikel helfen. Aber auch dann kann es ein recht langes Unterfangen sein, um die gewünschte Performance zu erzielen und können die dabei verwendeten Algorithmen relativ kompliziert werden. Andreas Maßmann ([email protected]) Datenbanken Zuckerbrot oder Peitsche, Oracle entwickelt MySQL weiter Cluster vs. Replikation von MySQL Wenn man heute von MySQL spricht, ist die Oracle Corporation meist der erste Gedanke. Was hat der IT-Gigant mit dem ehemaligen Konkurrenzprodukt vor? Hat MySQL das Potenzial konkurrenzfähig zu sein? Welche Möglichkeiten bietet MySQL für die Hochverfügbarkeit? Welche Einschränkungen müssen dabei beachtet werden? Antworten auf diese Fragen gibt der nachfolgende Artikel. Lebensgeschichte eines DBMS MySQL hat eine belebte Geschichte in den ersten zwanzig Jahren hinter sich. Ursprünglich wurde das RDBMS von der Firma MySQL AB im Jahre 1994 entwickelt. Ziel war es, das bereits vorhandene Datenbanksystem mSQL mit einer neuen, effektiveren Zugriffsmethode ISAM (Index Sequential Access Method) zu kombinieren. Nach den ersten Tests mussten die Entwickler allerdings feststellen, dass mSQL zu inperformant war und eine zu geringe Flexibilität aufwies. Aus diesem Grund wurde auf Basis der mSQL API eine neue SQL-Schnittstelle entwickelt und MySQL genannt. Meiner Meinung nach sprechen viele Fakten eher für den Erhalt von MySQL als OpenSource-Produkt. Sicher­ lich will Oracle MySQL nicht als Konkurrenz zum eigenen Oracle DBMS entwickeln. Allerdings war das auch noch nie das angestrebte Ziel von MySQL. Zudem hat Oracle durch die Übernahme, aus wirtschaftlicher Sicht, das eigene Kundenportfolio um zwei zusätzliche Marktsegmente ausgeweitet. Dazu zählen Web- und Nischendatenbanken. Es gibt immer einen größeren Fisch So stelle ich den Kunden oft eine Gegenfrage: Aus welchem Grund sollte Oracle die neugewonnenen Kunden durch Kommerzialisierung oder Einstellung des Projektes „MySQL“ verscheuchen? Besonders vor dem Hintergrund, dass MySQL als Konkurrenzprodukt zum Microsoft SQL Server für Oracle um Kunden kämpft. Im Jahr 2010, nur zwei Jahre nachdem die MySQL AB von Sun Microsystems übernommen wurde, kam es zu der Übernahme von Sun durch die Oracle Corporation. Durch beide Übernahmen hat sich für MySQL viel verändert. Die Community wurde gespalten und viele Kunden sind über die Zukunft des OpenSource-Produktes verunsichert. Durch diese Irrita­ tionen haben besonders die Anbieter anderer Distributionen profitiert. Sie entwickeln unabhängig auf Basis des MySQL-Codes das DBMS weiter. Zu den größten Vertretern zählen MariaDB und Percona. Nach der zweiten Übernahme dienten die ersten Maß­ nahmen sicherlich der Kosteneinsparung und Eingliederung von MySQL in das Oracle-„Universum“. So wurden umgehend nach der Übernahme einige Produkte und Entwicklungen eingestellt. Zu diesen zählte z.B. die vielversprechende Storage Engine Falcon. Diese wurde als direktes Konkurrenzprodukt zu der Storage Engine InnoDB konzipiert, welche schon damals zum Produktportfolio von Oracle gehörte. Zusätzlich wurde der Support neu konzipiert, so vervielfachte sich der Preis für den günstigsten Support von $ 600 auf $ 2.000 [4]. Die ungleichen Geschwister Hat Oracle mit dem Erwerb von MySQL einen Fehler gemacht? Hat das OpenSource-Produkt eine Zukunft in einem kommerziell orientierten Großkonzern? Diese Fragen bekommt man oft von MySQL-Stammkunden und Interessenten zu hören. Doch wie berechtigt sind solche Befürchtungen? Danach folgte die weitere Positionierung von MySQL durch die zuletzt veröffentlichten Versionen, diverse Ankündigungen und Pressemitteilungen. Die Community erwartete Neuerungen und Oracle lieferte sie. So verhalf der Konzern MySQL z.B. zu: • einem neuen Replikationsmechanismus (semi-synchron) • Thread Pooling, Optimierung für Mehrkernsysteme ORDIX news 3/2012 37 Datenbanken Das Verfahren benötigt mindestens zwei Systeme, ein produktives (Master) und ein nachgelagertes System (Slave). Auf dem Master wird gearbeitet und alle Änderungen werden in das sogenannte Binary-Log protokolliert. Der Slave liest (Relay-Thread) aus dem Binary-Log in ein eigenes Relay-Log. Aus dieser Protokollkopie werden die Transaktionen in die nachgelagerte Datenbank eingepflegt (SQL-Thread, siehe Abbildung 1). Abb. 1: Architekturen einer Replikation. • Neupositionierung und Weiterentwicklung des MySQL Cluster • Performance-Schema • Multi-Threaded-Slaves • Replikationsdelay Des Weiteren wurden in der neuesten Beta-Version Failover-Automatismen und die Global Transaction ID (GTID) implementiert. Beide Neuerungen er­ möglichen zusätzliche Architekturen und schaffen eine Unabhängigkeit zu externen Anwendungen. Das Zeichen, welches Oracle mit diesen und weiteren Neuerungen sendet, ist klar. MySQL bleibt und wird weiterentwickelt. Dies bedeutet also, dass in den kommenden Versionen auch Oracle-Know-how zur Konkurrenzfähigkeit von MySQL beiträgt. Stellenwert der Replikation Kommen wir nun zu den MySQL-internen Kontrahenten. Erfahrene Datenbankadministratoren ohne MySQL-Hintergrundwissen werden mit dem Begriff der Hochverfügbarkeit direkt an Cluster-Lösungen (z.B. Oracle RAC oder Informix Cluster) denken. Vielen MySQL-Administratoren hingegen kommt als erster Gedanke die Replikation in den Sinn. Hier ist zur Steigerung der Verfügbarkeit der bewährte MySQL-Replikationsmechanismus meist die erste Wahl. Auch betriebssystembasierte Ansätze erhalten in der Praxis oft den Vorzug vor dem MySQL Cluster. Dies liegt vor allem an dem einfachen und erprobten Mechanismus. 38 ORDIX news 3/2012 Dieser Mechanismus schafft eine Redundanz. Dadurch wird einem Datenverlust, bei einem Systemausfall, vorgebeugt. Weiterhin kann der nachgelagerte Server dazu verwendet werden um ein Backup zu erstellen. Der Vorteil liegt auf der Hand. Performancelastige Prozesse werden auf ein weiteres System verlagert, wodurch der Master nicht zusätzlich beeinträchtigt wird. Alternativ können die nachgelagerten Sys­ teme für Testzwecke verwendet werden. Erweiterung der MySQL-Replikation Schon immer zeichnete sich die MySQL-Replikation durch einen einfachen Aufbau, die flexiblen Einsatzmöglichkeiten und die hohe Transparenz des Verfahrens aus. Dennoch muss bei der Konzeptionierung einer hochverfügbaren Architektur mittels Replika­ tion unbedingt berücksichtigt werden, dass diese auf einem asynchronen Mechanismus aufbaut. Dies bedeutet, dass nicht sichergestellt werden kann, dass alle Transaktionen im Fehlerfall bereits repliziert wurden. Folglich ist ein Datenverlust nicht ausgeschlossen. Exakt diese Problematik wird durch die gerade aktuelle MySQL-Version 5.5 entschärft. Mittels der als Plug-In implementierbaren semi-synchronen Replikation. In Abbildung 2 ist das veränderte CommitVerhalten illustriert. Es wird deutlich, dass das führende System die Transaktion erst dann als erfolgreich bestätigt, wenn diese auch auf dem nachgelagerten System gespeichert wurde. Bei mehreren nachge­ lagerten Servern wird auf das erfolgreiche Eintragen von mindestens einem gewartet. Zwar erhöht die semi-synchrone Replikation die Sicherheit, eine 100%ige Garantie kann aber auch nicht gewährleistet werden. Dies liegt an dem konfigurierbaren automatischen Wechsel zur asynchronen Replikation, sodass im Fehlerfall möglicherweise nicht alle Transaktionen repliziert wurden. An dieser Stelle sei erwähnt, dass mit der Global Transaction ID, die für die kommende Ver­sion (5.6) angekündigt ist, der Mechanismus optimal ergänzt wird. Konflikte bei der Transaktionsverarbeitung wer- Datenbanken den gemindert. Die gewonnene Eindeutigkeit von Transaktionen ermöglicht dem Administrator zugleich gezielter fehlerhafte Transaktionen zu lokalisieren und ggf. zu korrigieren. Als Pünktchen auf dem „i“ sind weitere Architekturen, z.B. die Multi-Master-Topologie, einfacher realisierbar. Diese sind bisher nur über individuelle Implementierungen oder externe Anwendungen wie den Tungsten Replicator [3] möglich. /Client /InnoDB /Master /Slave Transaktion Speichern Commit Speichern Stellenwert des MySQL Cluster Commit Mit der Oracle-Übernahme hat sich auch für den MySQL Cluster einiges verändert. Trotzdem fällt insgesamt die Wahl eher selten auf die MySQL-eigene Cluster-Variante. Zwar ist der MySQL Cluster nun ein eigenständiges Produkt und wird von Oracle mit einer Hochverfügbarkeit von 99,999 % beworben. Doch inwieweit kann man diesen Marketingaussagen trauen? Und wieso ist die Verbreitung vergleichsweise gering? Commit Commit ►► rote Linie = wird definiert durch GLOBAL rpl_semi_sync_master_timeout Eine weitere Änderung ist der Verlauf der Linie, der wie in der Abbildung dargestellt, geändert werden muss. Abb. 2: Commit-Verhalten der semi-synchrone Replikation. Die Antworten auf diese Fragen können nur individuell gegeben werden. Dennoch lassen sich ein paar allgemeine Aussagen treffen. Um die MySQL-Cluster-Technologie zu verwenden müssen viele Faktoren stimmen. Zum einen muss den Administratoren klar sein, dass durch die Shared-Nothing-Methode, auf welche die MySQLCluster-Technologie setzt, Nachteile und Einschränkungen entstehen. Zum Einen bewirkt die Partitionierung der Daten­knoten zunächst eine Reduktion der Hochverfügbarkeit. Da einfach betrachtet, die Daten auf den Datenknoten verteilt werden. Zum Anderen ergeben sich in der Storage Engine NDB gewisse Einschränkungen, die im Folgen­ den erläutert werden. Dies alles sind Punkte, die Adminis­tratoren oft vor der Verwendung des MySQL Cluster abschrecken. Doch was bedeuten diese Einschränkungen genau? Anforderungen an das System Abb. 3: Architektur des MySQL Cluster. Einer der größten Unterschiede zu anderen Datenbank-Cluster-Lösungen ist, dass MySQL auf einer Shared-Nothing-Architektur aufbaut. Anders als beim Oracle RAC setzt MySQL auch bei den Storage Nodes auf eine getrennte Struktur (siehe Abbildung 3). Aus dieser Architektur resultiert der große Vorteil der Lastverteilung, allerdings steigt hierdurch auch der Verwaltungsaufwand. Vor dem Hintergrund des CAPTheorems wird dies deutlicher (siehe Abbildung 1 des Artikels „Was sind NoSQL-Datenbanken?”, Seite 12). Zuerst betrachten wir die Konsistenz am Beispiel einer modifizierten Transaktion. Diese hat die Anforderung exklusiv auf den Datenbeständen zu arbeiten, was in der Regel durch Sperren realisiert wird. Da beim MySQL Cluster kein gemeinsamer Speicher vorhanden ist (Shared Nothing), resultiert daraus ein höherer Kommunikationsaufwand zur Koordination der Zugriffe. Eine verteilte Datenhaltung wirkt konkurrierend in einem Spannungsdreieck aus Konsistenz, Verfügbarkeit und Partitionen. Ein weiterer Aspekt ist die Partitionierung oder auch Partitionstoleranz. Bei MySQL muss auf das richtige Gleichgewicht zwischen Knotengruppen und Storage ORDIX news 3/2012 39 Datenbanken root> SOURCE /usr/local/mysql/share/ndb_dist_priv.sql; root> CALL mysql.mysql_cluster_move_privileges(); Abb. 4: Übernahme von Systemtabellen in den Cluster. Glossar CAP-Theorem Beschreibt das Spannungsverhältnis zwischen den drei Systemeigenschaften Konsistenz (C), Verfügbarkeit (A) und Partitionierung (P). DRBD Distributed Replicated Block Device ─ Ein Festplattenreplikationssystem unter Linux. Die Replikation erfolgt über das Netzwerk. Knotengruppe Eine Knotengruppe bezeichnet einen Verbund von Storage Nodes. Innerhalb dieser Gruppe werden die Daten durch Replizierung redundant vorgehalten. Management Node Node zur Verwaltung und Kontrolle der anderen Knoten. Node Der Begriff Node (Knoten) bezeichnet einen einzelnen Rechner in einem Cluster. Oftmals ist ein Node mit einer bestimmten Aufgabe betraut. NoSQL-Datenbanken Datenbanken, die einen nicht-relationalen Ansatz verfolgen und damit mit der langen Geschichte von relationalen Datenbanken brechen. Shared Nothing Jeder Knoten verfügt über eigene Ressourcen. Zu diesen zählen der Arbeitsspeicher, Datenträger aber auch der Prozessor. Storage Node Node zum Schreiben und Lesen von Daten. SQL-Node Node für die Annahme und Verarbeitung der Anfragen von Applikationen und Usern. Nodes geachtet werden. Oberhalb der Knotengruppen werden die Tabellen durch Partitionierung auf die Knotengruppen verteilt. Innerhalb der Knotengruppen werden die Daten redundant auf den zugehörigen Storage Nodes vorgehalten. Erst der richtige Mix gewährleistet die geforderte Verfügbarkeit. Bei der Erweiterung des Cluster um neue Knotengruppen tut sich MySQL derzeit noch etwas schwer. So müssen bestehende Tabellen reorganisiert werden, damit sie verwendet werden können. Leider entsteht durch eine Reorganisation auf jeden Fall Ausfallzeit, die sich allerdings nicht vermeiden lässt. Was sind die Stärken und Schwächen Die größten Vor- und Nachteile von MySQL Cluster resultieren aus der Storage Engine. Zu den Vorteilen zählen unter anderem die performanten Schreib- und 40 ORDIX news 3/2012 Lesezugriffe. Aber auch die direkte Verwendung des Cluster über eine NoSQL-Schnittstelle (MemcachedAPI) zählt zu den Vorzügen. Die gravierendste Schwäche ist die Anforderung sämtliche Indexdaten im Hauptspeicher halten zu müssen (RAM >= Summe der Indexdateien). Darüber hinaus sind im aktuellen Release immer noch keine ForeignKey-Beziehungen darstellbar. Diese beiden Nachteile zählen in der Regel zu den Hauptgründen, wieso die Entscheidung gegen den MySQL Cluster getroffen wird. Erweiterungen des MySQL Cluster Neuerungen des MySQL Cluster beheben leider nicht die angesprochenen Begrenzungen und Eigenarten, trotzdem lohnt sich ein Blick auf das neue Release. Ein besonders großes Augenmerk legt Oracle auf die Performance von umfangreichen tabellenüber­ greifenden Statements. Bisher musste ein SQL Node die Ergebnismengen zusammenführen und identische Anfragen mehrmals versenden. Durch die Neuerung Adaptive Query Localization (AQL) wurde dieser Ablauf komplett überarbeitet. Mit AQL wird die Abfrage an den Storage Node gesendet, dieser fügt die parti­ tionsübergreifenden Informationen zusammen und liefert sie gebündelt zurück. Dadurch wird die Kom­munikation verlagert und die Storage Nodes koordinieren sich untereinander. Eine weitere Neuerung ist die angesprochene NoSQLAPI, die schon länger für den MySQL Cluster existiert, bisher aber nie in das Produkt integriert wurde. Neu ist auch, dass es durch ein Skript ermöglicht wird, die Zugriffsrechte zentral pflegen zu können. Dies ist durch die Übernahme von mysql-Systemtabellen in den Cluster möglich (user, db, tables_priv, colums_priv & prcos_priv). Das Skript, welches eine zentrale Account-Verwaltung ermöglicht, konvertiert die angegebenen Tabellen der System­ datenbank in die Engine NDB. Dadurch werden die Tabellen nicht mehr lokal sondern im Cluster ge­speichert (siehe Abbildung 4). Abschließend sei an dieser Stelle noch auf eine wichtige Neuerung hingewiesen: Neue Knotengruppen können nun im laufendem Betrieb hinzugefügt werden! Dies ist durch einen Rolling-Restart ohne Ausfallzeit möglich. Achtung: Eine Reorganisation ist trotzdem notwendig. Dieser Entwicklungstrend macht deutlich, dass Oracle an dem MySQL Cluster ein hohes Interesse hat. Datenbanken Oracle stärkt somit das Produkt und versucht auf die Bedürfnisse der bestehenden Cluster-Kunden einzugehen. Um die Einsatzmöglichkeiten zu erweitern wird derzeit an der Erweiterung für Foreign-KeyBe­ziehungen gearbeitet. Diese Neuerung soll mit dem kommenden Release des Cluster verfügbar sein [5]. Links ►► [1] ORDIX news Artikel 03/2005 „Nimm zwei - Replikation unter MySQL“: http://www.ordix.de/images/ordix/onews_archiv/3_2005/mysql_replikation.html ►► [2] ORDIX news Artikel 02/2006 „Spieglein, Spieglein... - 100 % MySQL - Wie richte ich ein Cluster ein?“: http://www.ordix.de/images/ordix/onews_archiv/2_2006/mysql_cluster.html Fazit Der MySQL Cluster hat seine Vorzüge und besonders die Erweiterungen machen die Verwendung für Unternehmen interessant. Vorausgesetzt, das System ist mit den Einschränkungen des Cluster kompatibel. Somit ist der Cluster auch aktuell noch mehr für individuelle Anwendungen geeignet. Aufgrund der höheren Flexibilität und der einfacheren Handhabbarkeit werden sich wahrscheinlich auch in Zukunft viele Kunden für die Replikation entscheiden. Für andere Kunden, die alternative HV-Lösungen suchen, besteht zudem die Möglichkeit auf der Betriebssystemebene Lösungen (DRBD) zu finden. ►► [3] ORDIX news Artikel 01/2012 „OpenSource Tungsten Replicator - Replication for Free“: http://www.ordix.de/images/ordix/onews_archiv/1_2012/opensource_tungsten_ replicator.html ►► [4] Artikel bei Computerworld: http://www.computerworld.com/s/article/9196219/Oracle_defends_MySQL_ support_pricing_changes ►► [5] Oracle's MySQL Blog: https://blogs.oracle.com/MySQL/entry/mysql_cluster_7_3_labs Besonders positiv ist zu erwähnen, dass sich beide Produkte gegenseitig bereichern. Dies bedeutet, dass beide voneinander lernen und Weiterentwicklungen in beiden Produkten stattfinden. So wird derzeit das NoSQL-Schnittstellenkonzept auch für InnoDB-Tabellen entwickelt und steht damit auch in der Replikation zur Verfügung. Steffen Kanne ([email protected]) Seminarempfehlung: MySQL Administration ►► Informationen/Online-Anmeldung: http://training.ordix.de/siteengine/action/load/kategorie/Datenbanken/nr/350/index.html In diesem Seminar lernen Sie, die Open Source Datenbank MySQL unter Unix/Linux zu installieren und zu verwalten sowie Daten zu selektieren und zu manipulieren. Sie erhalten einen Überblick über die Datenbankadministration und SQL-Besonderheiten, die durch praktische Übungen vermittelt werden. Das Seminar wird standardmäßig mit einem Linux System durchgeführt. Seminarinhalte MySQL: Support und Lizenzierung, Informationsquellen Installation und Einführung MySQL-Datenbankadministration Client/Server-seitige Skripte und Dienstprogramme MySQL-Log-Dateien • Backup & Recovery-Konzepte • Replikation bei MySQL • Optimierung • SQL-Besonderheiten, Transaktionen und Sperren, Anfragen-Cache • MySQL Proxy • Vertiefung der Theorie durch praktische Übungen und Beispiele • • • • Termine 24.09.- 26.09.2012in Wiesbaden 26.11.- 28.11.2012in Wiesbaden Seminar-ID: DB-MY-01 Dauer: 3 Tage Preis pro Teilnehmer: 1.190,00 € (zzgl. MwSt.) Frühbucherpreis: 1.071,00 € (zzgl. MwSt.) ORDIX news 3/2012 41 Betriebssysteme Skills für den Applikationssupport Applikationsmanagement ist Management Neben den klassischen Aufgaben des System- oder Datenbankadministrators haben sich in den letzten Jahren weitere vielfältige Aufgaben im Applikationsbetrieb aufgetan. Dieser Artikel zeigt die Aufgabenstellungen und die benötigten Skills der Mitarbeiter auf, die in diesem Bereich tätig sind. Technikerwissen bis ins Detail Früher wurden von dem Administrator nur Kenntnisse im Bereich des installierten Servers gefordert. Die Dienste und Applikationen wurden direkt vom Adminis­ trator mit aufgesetzt und verwaltet. Dies hat sich jedoch inzwischen geändert. Viele Appli­ kationen sind heute wesentlich komplexer und auf großen Serverfarmen installiert. Nur selten bestehen Anwendungen aus einer Komponente (z.B. Webserver), vielmehr werden viele spezialisierte Dienste auf einem oder mehreren Servern zur Verfügung gestellt. In so einer Umgebung ist eher ein Generalist als ein Spezialist gefragt. Eine typische Umgebung könnte folgendermaßen aus­sehen: • Betriebssysteme wie Solaris, AIX oder Linux, Hierdurch wird schnell deutlich, dass sich ein Mit­ arbeiter im Applikationsbetrieb nicht nur mit der An­ wendung an sich auskennen muss, sondern auch entsprechend Know-how in verschiedenen Diensten haben muss. Speziell die Beziehungen und die Kommunikation zwischen diesen Komponenten sind beim Betrieb zu berücksichtigen. Neben den fachlichen Skills ist also ein guter Überblick über die komplette Anwendungslandschaft notwendig. Alle Anwendungen und deren Schnittstellen müssen bekannt sein. Deshalb sind auch grundlegende Kenntnisse zu Java/JEE oder XML vorteilhaft. Nicht zuletzt ist auf jeden Fall auch eine gute Kenntnis des zugrunde­ liegenden Betriebssystems (Unix-Derivate, Windows Server oder auch noch Host-Systeme) notwendig. aber natürlich auch Windows Server • Datenbanken wie Oracle, Informix, DB2 und MSSQL • Applikationsserver wie WebSphere, JBoss oder Tomcat, um einen Container für die Applikationslogik zu liefern. Je nach Architektur (n-Tier) sogar mehrere. • MessageQueues wie MQSeries, um Daten zwischen verschiedenen Diensten oder Partnern auszutauschen. Dies geschieht z.B. per XMLDateien. • Jobsteuerung wie UC4, um Aufgaben anhand verschiedener Ereignisse zu starten und zu über­wachen. • Virtualisierungssoftware wie VMWare ESX, Solaris Container, LDOM, LPAR und Hyper-V, um mehrere Server zu konsolidieren. 42 ORDIX news 3/2012 Rhetoriker - die richtige Ansprache treffen Bereits die Ausbildung dieser technischen Skills bedeutet für den Mitarbeiter im Betrieb eine hohe Anforderung. Aber das ist ja erst die halbe Wahrheit. Im Applikations­betrieb ist man auch direkter Ansprechpartner für die Endanwender und Kunden. Bei Problemen mit den Applikationen muss somit auch im Bereich Help Desk gearbeitet werden. Dies erfordert wiederum rhetorische Fähigkeiten. Auch wegen der engen Zusammenarbeit mit den beteiligten technischen Abteilungen wie Netzwerk, Datenbanken oder Systembetreuung ist sicherlich eine hohe Kommunikations­fähigkeit wichtig. Dabei muss oft zwischen den Anwendern und den Spezialisten vermittelt werden. Eine hohe Kundenorientierung ist deshalb unabdingbar. Betriebssysteme Manager - Aufgaben richtig koordinieren Gerade in größeren Umgebungen lässt sich die Zusammenarbeit nicht mehr direkt nur „über den Schreibtisch“ bewerkstelligen. Hier bieten sich natürlich die Methoden und Vorgehensweisen im Bereich ITIL an. Konkret handelt es sich um folgende Aufgaben: • Bearbeitung von Störungen (Incidents) • Analyse von fachlichen Störungen (Problems) • Behebung der Störungen durch Anpassungen des Systems (Changes) • Aufbau neuer Systeme für die Produktion oder im Testumfeld (Deployment) • Beauftragungen von Firewall-Freischaltungen in Richtung Netzwerkservice • Beauftragungen von Storage-Erweiterungen, Benutzereinträgen und Konfigurationsan­ passungen in Richtung Systemadministration • Beauftragungen von Tablespace-Erweiterungen, Rollenanpassungen oder Exporte in Richtung Datenbankadministration • Beauftragungen von Backup/Restore • Unterstützung von Analysen seitens der Entwicklung Glossar ITIL IT Infrastructure Library ─ Sammlung von Best Practices in einer Reihe von Publikationen, die eine mögliche Umsetzung eines IT-ServiceManagements (ITSM) beschreiben. Fazit Oft werden die Mitarbeiter im Applikationssupport als „Mädchen für alles“ bezeichnet. Tatsächlich sind sie in den meisten Unternehmen eher Manager der komplexen Anwendungslandschaft. Daher sollte auch eher von Applikationsmanagement als von Applikationssupport gesprochen werden. Durch die vielfältigen Aufgaben und Kommunikationswege werden die Softskills somit zu einem entscheidenden Erfolgsfaktor bei den Mitarbeitern. Unsere Berater aus dem Bereich Applikations­ management sind genau für die beschriebenen Aufgabenbereiche ausgebildet. Lassen Sie sich von uns unterstützen oder beraten. Oder geben Sie Ihren eigenen Mitarbeitern mit unserem Seminar „Unix Aufbau­seminar für Datenbank- und Applikationsbetreuer“ eine gute Basis für die effektive Betreuung Ihrer Dienste. Aus diesen Aufgaben ergibt sich, dass die Mitarbeiter oftmals mehr mit der Koordination und der Kommunikation beschäftigt sind, als mit der Applikation an sich. Der Anteil an organisatorischen und koordinativen Aufgaben ist meist deutlich höher als bei anderen Betriebsgruppen. Die breite Fächerung der Aufgaben erfordert eine hohe Flexibilität bei jedem Mitarbeiter und ein professionelles Zeitmanagement. Carsten Griese ([email protected]) Seminarempfehlung: Unix Aufbauseminar für Datenbank- und Applikationsbetreuer ►► Informationen/Online-Anmeldung: http://training.ordix.de/siteengine/action/load/kategorie/Betriebssysteme/nr/1115/index.html In diesem Seminar vermitteln wir Ihnen vertiefende Kenntnisse aus dem Unix-Umfeld. Aufbauend auf den Grundlagen werden hier Techniken gezeigt, um Log-Dateien auszuwerten und das System zu monitoren. Außerdem werden Themen besprochen, die für die Einbindung von Applika­tionen und Datenbanken in ein Unix-System relevant sind. Seminarinhalte Wiederholung Analyse-Tools Einführung Shell-Programmierung Report-Erstellung aus Logfiles mit awk Automatisierung von Wartungsarbeiten mit cron Aufbau (Raw)-Devices/Aufbau File-Systeme Grundlagen Netzwerk Sicherheitsrelevante Themen Grundlagen Storage Diagnose-Tools zur Analyse des Systems Systemparameter (ipcs) Vertiefung der Theorie durch praktische Übungen und Beispiele • • • • • • • • • • • Termine 05.11.- 09.11.2012in Bielefeld 19.11.- 23.11.2012in Wiesbaden Seminar-ID: BS-25 Dauer: 5 Tage Preis pro Teilnehmer: 1.790,00 € (zzgl. MwSt.) Frühbucherpreis: 1.611,00 € (zzgl. MwSt.) ORDIX news 3/2012 43 Datenbanken Enterprise Manager Oracle Cloud Control 12c (Teil II) Die Wolke beginnt zu schweben Nach der Vorstellung der neuen Funktionen in der letzten ORDIX news [1] be­ schäftigt sich der zweite Teil dieser Reihe mit der Einrichtung des Oracle Cloud Control 12c. Hierfür wird der Installa­tionsprozess betrachtet und die Varianten der neuen Installation aufgezeigt. Vorarbeiten für die Installation Grundlegende Voraussetzung für die Nutzung von Cloud Control sind für alle Komponenten (OMS / Agent / Repository-Datenbank) zusammen mindestens 6 GB Arbeitsspeicher und 65 GB Speicherplatz. Der Bedarf an Arbeitsspeicher und Speicherplatz variiert zusätzlich mit der Anzahl der zu verwalteten Zielsys­ teme in Cloud Control. Für eine erfolgreiche Installation des Oracle Cloud Control Servers wird die aktuelle Version 12.1.0.1 mit dem Bundle Patch 1 benötigt. In dieser Ver­sion sind bereits einige Bugs der ersten Oracle Cloud Control Version gefixt. Die aktuelle Version kann im Technetwork von Oracle heruntergeladen werden [2]. Zur Zeit (Stand August 2012) steht diese Version für Linux (32/64-Bit), Windows (64-Bit), Solaris SPARC/x86-64 44 ORDIX news 3/2012 und IBM AIX on POWER Systems (64-bit) zur Ver­ fügung Ohne Repository geht nichts Die Abbildung 1 zeigt die Gesamtstruktur von Cloud Control. Das benötigte Repository für den Oracle Cloud Control Server muss im Vorfeld angelegt und über definierte Ports zugänglich sein. Folgende Datenbankversionen sind von Oracle als Repository zertifiziert: • 1 0.2.0.5.0 Enterprise Edition • 11.1.0.7.0 Enterprise Edition oder höher • 11.2.0.1.0 Enterprise Edition oder höher Hier empfiehlt es sich immer die aktuellste Version zu nehmen. Bei älteren Versionen wie 11.1.0.7 müssen zwingend Patches für vorhandene Bugs eingespielt werden. Sämtliche Detaileinstellungen bei der Er­ stellung können unbeachtet bleiben. Datenbanken Der Installer kontrolliert bei der Installation die Verbindung zu der Datenbank und erstellt Skripte, um Einstellungen im System für die Benutzung des Oracle Cloud Control zu optimieren. Für die Ausführung dieser Skripte werden zwingend root-Rechte benötigt. Plug-Ins für die Wolke Die Bedeutung von Plug-Ins haben sich mit Oracle Cloud Control 12c grundlegend geändert. Alle Neuerungen, welche im Rahmen der Self-Update-Funktion bereitgestellt werden, stellen Plug-Ins dar. Im Rahmen der Installation bietet Oracle Cloud Control von sich aus verschiedene Plug-Ins zur Auswahl. Es werden per Default die Plug-Ins für Database, Exadata, Fusion Middleware und MOS installiert. Folgende Plug-Ins stehen bei der Installation zusätzlich zur Verfügung: • • • • • • • • Exalogic Elastic Cloud Infrastructure IBM DB2 Database Oracle Chargeback and Capacity Planning Oracle Cloud Application Abb. 1: Struktur von Cloud Control. Oracle Fusion Applications Oracle Siebel Oracle Virtualization Sybase ASE Database Weitere Plug-Ins können aus dem Oracle Technetwork heruntergeladen werden [3]. Außerdem gibt es eine große Menge an Drittanbietern, die Plug-Ins entwickeln und zur Verfügung stellen. So gibt es z.B. Möglichkeiten Plug-Ins für IBM WebSphere, Apache oder auch diverse Hardware-Plug-Ins zu installieren. Die Installation von Plug-Ins für Oracle Cloud Control kann im Online-Modus mit einer direkten Anbindung an das Internet erfolgen oder alternativ im OfflineModus. Dabei muss ein separater Client die entsprechenden, von Cloud Control vorgegebenen, Plug-Ins herunterladen und per Kommando einspielen. Installationsarten der Wolke Mit Oracle Cloud Control 12c gibt es die Möglichkeit zwischen einer einfachen und einer erweiterten Installation zu wählen (siehe Abbildung 2). Bei der einfachen Installation werden nur grund­ legende Passwörter für den Benutzer Weblogic, Nodemanager, SYSMAN und die OMS-Anmeldung Abb. 2: Einfache Installation. ver­geben. Außerdem werden Details für die Anmeldung am Enterprise Manager Repository erwartet. Auch ein Hauptverzeichnis für das Cloud Control und für die Fusion Middleware, welche Cloud Control be- ORDIX news 3/2012 45 Datenbanken Die Alternative zur einfachen ist die erweiterte Installation. Bei dieser Variante besteht die Möglichkeit, jede Komponente im Detail zu konfigurieren. Bei der erweiterten Installation erfolgt zunächst eine Auswahl der Plug-Ins. Diese Auswahl kann kontrolliert und im Vorfeld auf die eigenen Be­dürfnisse angepasst werden. Danach wird der Weblogic-Server mit den Benutzern „weblogic“ und „nodemanager“ konfiguriert. Nach der erfolgreichen Vergabe von Passwörtern werden die Verbindungsinformationen für die als Repository vorgesehene Datenbank eingegeben. Der Verbindungsaufbau zu der Datenbank muss zwingend funktionieren, sonst wird die Installationsroutine an dieser Stelle nicht weiter fortfahren. Nach dem erfolgreichen Verbindungsaufbau müssen Speicherorte zu den von Cloud Control benötigten Tablespaces angegeben werden. Port-Konfiguration Abb. 3: Port-Konfiguration. Glossar MOS My Oracle Support ─ Wissen- und Supportdatenbank für Oracle Produkte Repository Benötigte Oracle-Datenbank, in die das Cloud Control seine Daten ablegt. Nach erfolgreicher Konfiguration der Komponenten des Cloud Control müssen am Ende der Installation bestimmte Ports für eine reibungslose Kommunikation nach außen freigegeben werden. In der jeweiligen Umgebung muss dann gezielt geprüft werden, welche Ports für den Oracle Cloud Control frei verfügbar sind. In der Abbildung 3 sehen Sie ein Beispiel für alle benötigen Ports. Diese können an die jeweiligen Anforderungen im Unternehmen angepasst werden. SYSMAN Der Benutzer SYSMAN ist der Hauptadministrator des Cloud Control. Links ►► [1] ORDIX news Artikel 02/2012 „Enterprise Manager Oracle Cloud Control 12c (Teil I) - Über den Wolken...”: http://www.ordix.de/images/ordix/onews_archiv/2_2012/oracle_cloud_control.html ►► [2] Download-Seite des Oracle Technetwork: http://www.oracle.com/technetwork/oem/enterprise-manager/downloads/index.html ►► [3] Download-Seite der Plug-Ins und Conectors auf Oracle Technetwork: Fazit Die Installation ist im Vergleich zu den älteren Ver­ sionen einfacher geworden. Die Routine installiert wesentliche Komponenten, die in den Vorgänger­­ver­ sionen manuell vorinstalliert sein mussten. Dadurch werden dem Administrator Vorarbeiten abgenommen und die Installation gestaltet sich daher erheblich einfacher. Im nächsten Artikel dieser Reihe werden wir Ihnen die Möglichkeiten für einen Upgrade eines 10er bzw. 11er Grid Control auf Cloud Control vorstellen. http://www.oracle.com/technetwork/oem/extensions/index.html#OEM12c Bild: © freepik.com | gestures psd material | zcool.com.cn © deviantart.com | Clouds Set icons PSD | JackieTran nötigt, muss angegeben werden. Das Patchen des Weblogic-Server, wie in früheren Versionen, entfällt hier komplett. Die weitere Konfiguration der Komponenten übernimmt Cloud Control selbst. 46 ORDIX news 3/2012 Carsten Hummel ([email protected]) Aktuell ? Rätsel Larry im Knobelfieber Im Urlaub ist Larry auf den Geschmack gekommen: Knobeln macht richtig Spaß! Um seine Kollegen auch davon zu überzeugen, hat er sich einen kleinen Wettbewerb ausgedacht. Drei seiner Kollegen sollen sich hintereinander in einer Reihe aufstellen. Dann klebt Larry ihnen jeweils einen farbigen Zettel auf den Rücken. Larry sagt nun folgendes: "Der Vordere von euch sieht keinen Zettel, der Mittlere sieht nur den Zettel des Vorderen und der Hintere kann nur die Zettel der anderen beiden sehen. Ich hatte fünf Zettel zur Auswahl: zwei rote und drei weiße. Derjenige von euch, der mir die Farbe seines Zettels sagen kann, dem kaufe ich ein Stück Kuchen. Sollte er allerdings falsch liegen, bezahlt er mir ein Stück Kuchen." Seine Kollegen knobeln. Fünf Minuten vergehen. Dann ruft der vordere Kollege, der keinen Zettel sehen kann: "Mein Zettel ist weiß!" Können Sie Larry helfen? Larry freut sich auf Ihren Lösungsvorschlag. Senden Sie bis zum 15. Oktober 2012 Ihre Antwort an [email protected]. Larry's Urlaub ist vorbei und er hat auch noch etwas gelernt! Larry bedankt sich bei den vielen Einsendern für die richtige Lösung aus der letzten Ausgabe. Den entsprechenden Lösungsweg für Larry´s Aufgabe finden sie unten. Larry belohnte die schnellsten Einsender: Joachim Hellriegel, Thomas Oguntke, Christian Krone, Andreas Denke Wer muss den Kuchen bezahlen und warum? Lösung Larry Rätsel 2/2012: Der Fluss ist 200 Meter breit. Beim ersten Zusammentreffen haben die Schwimmer 80 bzw. (B-80) Meter (mit B = Breite des Flusses) zurück­ gelegt; beim zweiten Zusammentreffen sind es (B+40) bzw. (2B-40) Meter. Aus der Summe der jeweiligen Werte pro Zeitpunkt (B bzw. 3B) ergibt sich, dass die Strecke zwischen Start und zweiten Zusammentreffen dreimal so lang sein muss wie die Strecke bis zum ersten Zusammentreffen. Somit gilt also für jeden Schwimmer dreimal die erste Strecke ist gleich der zweiten ... und so erhält man eine Gleichung mit einer Unbekannten, etwa für den ersten Schwimmer 3*80=B+40, und am Ende B=200 Meter. ORDIX news 3/2012 47 Projekt-/IT- Management Eine Frage der technischen & sozialen Kompetenz TECHNISCHE KOMPETENZ SOZIALE KOMPETENZ Das Wissen über bewährte Methoden, Vorgehensweisen und Systematiken ist in allen Bereichen des Projekt- und IT-Managements eine wichtige Basis für den Erfolg. In allen Vorhaben im Bereich des Projekt- und IT-Managements spielt der Faktor „Mensch“ eine Schlüsselrolle. Daher ist eine hohe Sozialkompetenz ein immer wichtiger werdender Erfolgsfaktor. Egal, ob Sie ein Projekt zielgerichtet umsetzen wollen, eine IT-Strategie entwickeln möchten, eine IT-Architektur gestalten müssen oder IT-Prozesse etabliert werden müssen, immer geht es um das „gewusst wie?“. Egal, ob Sie Krisen bewältigen müssen, Konflikte lösen oder Teams führen wollen, immer sind „Social Skills“ gefordert. UNSERE SEMINARE: UNSERE SEMINARE: ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ ■■ IT-Projektmanagement Agiles Projektmanagement mit SCRUM E-Business IT-Architekturen IT-Strategie IT-Risikomanagement IT-Prozessmanagement IT-Management IT-Projektcontrolling IT-MANAGEMENT IT-PROJEKTMANAGEMENT SOZIALE KOMPETENZ Krisenmanagement in Projekten Verhandlungstechniken Konfliktmanagement Social Skills für IT-Berater | IT-Manager Projekte souverän führen Strategien effizient entwickeln Systemische Führung IT-Management Soft Skills TECHNISCHE KOMPETENZ IT-SEMINARE Aktiengesellschaft für IT-Consulting, IT-Management, IT-Services und Software-Entwicklung Kreuzberger Ring 13 | 65205 Wiesbaden | Tel.: 0 611 / 77840-00 | Fax: 0180 / 1 67 34 90 Aktiengesellschaft für Software-Entwicklung, Schulung, Beratung und Systemintegration Kreuzberger Ring 13 | 65205 Wiesbaden | Tel.: 0 611 / 77840-00 | Fax: 0180 / 1 67 34 90 WWW.CONIATOS.DE WWW.ORDIX.DE
