Teil III - ORDIX AG
Werbung
www.ordix.de 04 ORDIX news 2008 € 2,20 Das IT-Magazin der ORDIX AG SOA-Governance Reihe SOA (Teil II): Braucht SOA eine neue Regierung? Datenbank-Backup mit RMAN Die Zeit ist reif für eine neue Art der IT-Managementberatung Bericht über ein Backup-Projekt bei einer großen deutschen Bank S. 24 Neue Funktionen in DRBD 8.0 OCFS und DRDB: Keine Angst vor Split-Brain!S. 48 Interview mit Lars Eisenblatt, coniatos AG MS SQL Server 2008 New Features S. 34 S. 40 Datenhistorie mit Change Data Capture S. 51 IUG-Veranstaltungen 2009 • 50. IUG-Workshop • Technischer Workshop • 3 IUG-Seminare • Mitgliederversammlung Warum lohnt es sich IUG-Mitglied zu werden? ► Sie bekommen direkten Kontakt mit den Hauptverantwortlichen Mitarbeitern aus der Branche ► Workshops und Stammtische kostenlos für drei Mitarbeiter pro Mitgliedsfirma ► Steigerung Ihres Bekanntheitsgrades und Erweiterung Ihrer Zielgruppe ► Seminare und Veranstaltungen zum Sonderpreis ► 15 % Rabatt auf Informix-Schulungen von IBM und anderen Schulungsanbietern ► Gemeinsam Problemlösungen finden Zusammen sind wir stärker und können mehr erreichen. Experten-Vorträge Kontakt- und Netzwerkbildung Hohe Besucherzahlen Wir würden Sie gerne in unserer Gemeinschaft begrüßen. Melden Sie sich bitte bei: [email protected]. www.iug.de Editorial Rettungspakete Paderborn, Dezember 2008 Dieses Mal hat es nichts mit Weihnachten zu tun: Das Schnüren von Rettungspaketen ist wieder in Mode. Gerhard Schröder hat 1999 zum ersten Mal ein Rettungspaket geschnürt (damals sollte der Holzmann Bauriese ein Darlehen der KfW über 150 Millionen erhalten). Kurzfristig hat das auch für erhöhte Popularitätswerte gesorgt, was sicher von Schröder und der SPD auch bezweckt war. Jetzt kommen die Nachahmer: Im Portfolio sind das Bankenpaket (Eltern Peer Steinbrück und Angela Merkel) und eventuell die Opelrolle (Eltern Frank Steinmeier und Angela Merkel), über die just an dem Tag, an dem ich das hier schreibe, verhandelt wird. Frau Merkel, wie immer einen Tick zu spät, versucht aber gerade, bei der General Motors ..., pardon, Opel Rettungsaktion durch einen genialen Trick („lege meinen Termin einfach vor den von Steinmeier“) auf die Überholspur zu kommen. Aber wozu? Nur um eine marode amerikanische Wirtschaft und die dort üblichen Praktiken zu retten. Die Fehler, die gemacht wurden, oder die katastrophale (Wirtschafts-)Politik der Bush-Administration macht man dadurch leider nicht ungeschehen. Im Gegenteil: Durch eine Opel (oder Ford) „Rettung“ wird mit hoher Wahrscheinlichkeit nur Geld in die völlig maroden US-Mutterkonzerne gepulvert, das innerhalb weniger Wochen wirkungslos verpufft sein wird. Da erscheint doch der Vorschlag von Nikolaus Bollmann*), 46, Gelsenkirchen, drei Kinder, geschieden und von mehreren Banken als nicht kreditwürdig eingestuft (so wie sich die Banken momentan untereinander auch einstufen) wesentlich sinnvoller: Man verteile die 480 Milliarden € an ca. 20 Millionen Bundesbürger. Das sind dann rund 24.000 € pro Bundesbürger. Und zwar unter der Maßgabe (Bedingung des Rettungspaketes), sich dafür einen Opel Astra (Ford Fiesta, VW Polo ...) für 18.000 € zu kaufen, auf den man ja derzeit mindestens 3.000 € Nachlass erhält. Bei 20 Millionen Neufahrzeugen ist die deutsche Autoindustrie mindestens für 6 ½ Jahre gerettet und die Opelrolle überflüssig. Mit dem restlichen Geld (9.000 €) wird durch Darlehen an Banken (3.000 €) bedürftigen Banken Bargeld zur Verfügung gestellt und anderen Branchen ein individuelles Rettungspaket geschnürt. Nutznießer ist in jedem Fall der Staat, dem dadurch immense Steuereinnahmen zur Verfügung stehen und der sich deshalb auch den Top-Katalysator für die Krise in der Automobilindustrie spart: Das Schenken der KFZ Steuer für 2009. Die macht im Übrigen bei einem Fahrzeug der o. g. Klasse ungeheure 80 - 100 € aus. Bei diesem unglaublichen Anreiz habe ich sofort überlegt, 6 Autos zu kaufen, weil ich dann über die Nachlässe noch ein siebtes geschenkt bekomme und für die Steuerersparnis jedes einmal volltanken kann. Leider kann man Kurt Tucholsky nicht in die Beratermannschaft der Regierung aufnehmen (statt Herrn Tietmeyer ). Tucholsky hat schon 1930(!) Weitblick gezeigt („Wenn die Börsenkurse fallen“ veröffentlicht in „Die Weltbühne“). Wem Tucholsky nicht als Weihnachtslektüre reicht, dem empfehle ich jetzt die Artikel dieser ORDIX News: Auch hier viele Anregungen für Politiker (Keine Angst vor Split-Brain, Neues zu DRBD, Mit Kennzahlen zum Projekterfolg, Braucht SOA eine neue Regierung? (SOA vielleicht nicht, aber ...)). Und daneben noch viele andere nützliche Dinge zum Thema Datenbanken (MySQL, Oracle, DB2 und MS SQL Server), Betriebssystemen und Java Best Practice. Bevor ich es vergesse, natürlich erfüllt Herr Bollmann auch die 500.000 € Sperrklausel für den Bezug des Rettungspaketes (mit seinen 4.120 € Bruttogehalt auch über 10 Jahre hinweg kein Problem). In diesem Sinne ein vergnügtes Weihnachtsfest und schauen wir mal, welche Branchen im Superwahljahr 2009 von Super-Merkel und Kollegen gerettet werden. Wolfgang Kögler PS: Vielen Dank an meinen Aufsichtsrat Herrn Raum für den Tucholsky Tipp. Sicher mit Abstand das Beste, was hier steht und auch im Vergleich zu dem, was in den letzten Monaten von unseren Politikern zum Besten gegeben wurde. *) Name völlig frei erfunden ORDIX News 4/2008 3 Inhalt Aktuell Standards 23����Larry Ratlos: Dateisystem­erweiterung in Solaris 10 03����Editorial 55����Einladung zum IT-Symposium Risikomanagement mit Oracle am 17.02.2009 04����Inhalt 28����Seminarübersicht: Januar bis August 2009 45����Impressum Betriebssysteme 48����OCFS und DRDB (Teil I): Keine Angst vor Split-Brain! Neue und hilfreiche Funktionen von DRBD, Version 8.0: Die elegante Open-Source-Lösung hilft, kostengünstig Shared Storage zur Verfügung zu stellen. Open Source 20����Codename Indiana: OpenSolaris - Kleider machen Leute Überblick über OpenSolaris und damit die potentiellen Weiterentwicklungen des Betriebssystems Solaris. 43����System-Logging unter Linux und Unix – syslog-ng (Teil II): Zentrale Speicherung von Logfiles Vorstellung der Vorteile und Risiken der zentralen Speicherung von Logfiles sowie deren Verschlüsselung mit Stunnel. Projektmanagement 5������IT-Projektcontrolling (Teil II): Mit Kennzahlen zum Projekterfolg Überblick über Kennzahlen und Kennzahlensysteme im Bereich IT-Projektcontrolling. IT-Strategie 4 Java/JEE 14����Java Best Practice (Teil III): Java-Projekte bauen mit ANT ANT ist ein Build Tool in und für Java, vergleichbar mit MAKE unter Unix. Anhand der Aufgaben eines Projekts werden Aufbau und einzelne Elemente von ANT beschrieben. Datenbanken 10����MySQL Falcon (Teil II): PerformanceVergleich Falcon vs. InnoDB Lasttests mit Super Smack zeigen Unterschiede bei der Performance der beiden bekann­testen transaktionsfähigen Storage Engines auf. 17����Oracle Objekttypen von A - Z (Teil VIII): Queue – Advanced Queuing Im 8. Teil fahren wir mit „Q“ wie Queue - mit Fokus auf Advanced Queuing - fort. 24����Projektbericht: Datenbank-Backup mit RMAN in komplexen Umgebungen Bericht über die Entwicklung und Implementierung eines Backup-Verfahrens mit Oracle RMAN bei einer großen deutschen Bank. 30����Oracle EM Grid Control (Teil V): Die Wartungsfunktion imp/exp Überblick über Assistenten und Optionen beim Import und Export von Daten aus einer bzw. in eine Oracle Datenbank. 38����Oracle Database 11g Release 1 (Teil V) Neue Data Pump Funktionen in Oracle 11g 34����Reihe SOA (Teil II): SOA-Governance Braucht SOA eine neue Regierung? Wesentliche Merkmale einer SOA-Governance werden skizziert. Dabei werden u. a. Begriffe wie ServiceLifecycle-Management, Service-Portfoliomanagement und Service-Designprozess vorgestellt. 46����DB2 HADR: Automatic Failover mit TSA Die in DB2 Version 9.5 integrierte Tivoli System Automation ermöglicht den automatischen Failover bei HADR. 40����Die Zeit ist reif für eine neue Art der IT-Managementberatung Interview mit Lars Eisenblatt, Mitbegründer und Vorstand der coniatos AG. 51����MS SQL Server 2008 New Features (Teil I): Blick in die Datenvergangenheit mit CDC Mit Change Data Capture werden Änderun­ gen an Tabelleninhalten nachverfolgt. ORDIX News 4/2008 Projektmanagement IT-Projektcontrolling (Teil II): Mit Kennzahlen zum Projekterfolg Während wir uns im ersten Teil [1] mit den Grundlagen des Projektcontrollings beschäftigt haben, erörtern wir im vorliegenden Artikel Kennzahlen und Kennzahlensys­teme. Dabei gehen wir auf die Frage ein, wie mit Hilfe von Controlling-Methoden aus Zahlen Dieser Artikel richtet sich an IT-Manager, IT-Controller und Projektmanager. aussagekräftige Informationen gewonnen werden. Hürden im Projektcontrolling Im ersten Teil dieser Reihe wurde bereits deutlich, dass es beim Controlling nicht um kontrollieren, sondern um regeln geht. Dabei wurden auch die Ziele und Aufgaben des strategischen Controlling, des Multiprojektcontrolling und des Einzelprojektcontrolling beleuchtet. Im Rahmen des IT-Projektcontrolling stehen folgende Fragen im Vordergrund: • • • • • • Wie misst man den Fertigstellungsgrad? Wieviel Aufwand ist sinnvollerweise für die IST-Datenerhebung und die Auswertung zu betreiben? Herrscht Verständlichkeit, Transparenz und Akzeptanz für die gewählten Kennzahlen? Wie werden Kennzahlen in (Status-)Berichten genutzt? Wie fließen nicht messbare Größen ein? Was sind sinnvolle Kennzahlen? Dabei wird der Projektleiter meist durch einen Projektcontroller auf der Abteilungs- oder Bereichsebene im Unternehmen unterstützt. Was sind eigentlich Kennzahlen? Eine Kennzahl ist ein Indikator, der einen bestimmten Sachverhalt beschreibt. Üblicherweise eine absolute Zahl, ein Prozentwert oder ein Symbol wie z. B. der Ampelstatus in einem Projektstatusbericht. Dabei werden direkte und indirekte bzw. abgeleitete Kennzahlen unterschieden. Kennzahlen sind die Messstellen eines Projekts und unterstützen das Controlling bei der Steuerung. Beispiele für direkte Kennzahlen sind: • • • Budgetstand Anzahl Mitarbeiter Anzahl Change Requests Beispiele für abgeleitete Kennzahlen, also Ver­­hältniszahlen, die als Prozentwert dargestellt werden, sind: • • • Budgetquote (Istwert/Planwert) Fachlicher Fertigstellungsgrad (Anzahl fertiggestellter Arbeitspakete/geplante Arbeitspakete) Zeitlicher Fertigstellungsgrad (abgelaufene Zeit/geplante Zeit) Darüber hinaus kennt man noch zeitbezoge­ ne Kennzahlen, z. B.: • • • Budgetreichweite (abhängig von den Terminen des Projekts) Anzahl Tests pro Woche Anzahl Change Requests pro Woche Aus Zahlen werden Steuerungssysteme Ein Kennzahlensystem ist eine konkrete, dem Steuerungsziel dienende Zusammenstellung von Kennzahlen. Abbildung 1 zeigt ein Beispiel für ein Kennzahlensystem. Was konkret in einem Projekt mit Kennzahlen gesteuert werden soll, hängt vom Projekttyp und von der Zieldefinition ab. Für kleinere Vorhaben reicht meist ein einfaches Kennzahlensystem mit maximal fünf ORDIX News 4/2008 5 Projektmanagement Kennzahlen, für größere Projekte werden komplexere Kennzahlensysteme benötigt. Pareto lässt grüßen Sofern sich direkte Kennzahlen exakt bestimmen lassen, stimmen auch die von ihnen abgeleiteten Kennzahlen. Aber nicht alle Kennzahlen lassen sich messen oder genau bestimmen. Die ersten 80 % erhält man mit vertretbarem Aufwand. Anschließend noch viel Aufwand in die letzten 20 % zu investieren, bringt kaum Zugewinn - ganz nach dem Pareto-Prinzip. Kennzahl-Gruppe Kennzahl Code/Abk. Budget Ausschöpfung BA Reichweite BR Anzahl Mitarbeiter MAZ Auslastungsgrad MAA Verfügbarkeit (Urlaub/Krankheit) MAV Bisherige Projektdauer (verbrauchte Zeit) PVZ Noch erforderliche Projektdauer (Zeit) PEZ Meilensteintermine M Anzahl Risiken RALL Noch offene Risiken ROF Ressourcen Termine Risiko-Management Fertigstellungsgrad Fachlicher Fertigstellungsgrad FFG Kostenmäßiger Fertigstellungsgrad KFG Zeitlicher Fertigstellungsgrad ZFG Verbrauch des Projektbudgets Soll 100 % aktuelle Abweichung Trend 60 % 40% Ist 20% Start Abb. 2: Trend im Projekt. 6 ORDIX News 4/2008 Viele Kennzahlen lassen sich messen, doch eine wichtige lässt sich meistens nur schätzen: der fachliche Fertigstellungsgrad. Wie ist der inhaltliche Projektfortschritt? Für die Ermittlung des fachlichen Fertigstellungsgrads gibt es folgende Lösungsansätze: • • Subjektive Schätzung des Verantwortli­ chen eines Arbeitspakets in Prozent Ampelmethode auf Arbeitspaketebene („noch nicht begonnen“, „in Arbeit“, „fertig“). Wobei eine Abstufung in fünf statt drei Schritten meist die Transparenz und Genauigkeit erhöht. Auf Projektebene werden diese Einzelermittlungen kummmuliert und gewichtet. Zusätzlich oder auch alternativ lässt sich der Fertigstellungsgrad durch weitere Methoden ermitteln. In der Praxis verbreitete Methoden sind: • • • • „Cost to Complete“: Istkosten/(Istkosten + geschätzte Restkosten) „Cost to Cost“: Istkosten/Plankosten Erreichung von Meilensteinen „hours to hours“: Zeit(Ist)/Zeit(geplant), berücksichtigt jedoch nicht die Effizienz im Umgang mit der Arbeitszeit Wie aus Zahlen Informationen werden Die Semantik einer Kennzahl ergibt sich aus dem Kontext. Der verantwortliche Projektcontroller muss wissen, wie er den Wert einer Kennzahl zu interpretieren hat. Daher sind Regeln und Definitionen für die Erhebung und Darstellung der Kennzahlen erforderlich. Abb. 1: Beispiel für ein Kennzahlensystem. 80 % Was ist messbar? Projektverlauf Durch die Auswertung der Kennzahlensys­ teme im Projekt erhält man zu jedem Berichtszeitpunkt die Information zum Status des Projekts. Mindestens genauso wichtig ist jedoch die Betrachtung des Trends. Hier spielt nicht nur die äußere Form des Berichtswesens eine wichtige Rolle, sondern auch die systematische Aufbereitung und Darstellung. Zum Berichtszeitpunkt verwendet man üblicherweise eine tabellarische Darstellung der aktuellen Kennzahlen wie im o. g. Beispiel. Für die prognostische Darstellung werden z. B. die Fertigstellungsgrade oder der Budget­ stand über die Zeit, wie in Abbildung 2 gezeigt, graphisch dargestellt. Eine Tabellenkalkulation, z. B. Excel liefert hier gute Dienste. Projektmanagement Earned Value Analysis Obwohl schon seit den sechziger Jahren verwendet - vornehmlich in militärischen Projekten und bei der NASA - erlebt die Earned Value Analysis (EVA) in den letzten Jahren eine gewisse Renaissance. Seit einiger Zeit ist dieses Controlling-Instrument auch im „Guide to the Project Management Body of Knowledge“ [2] fest verankert. Basis dieses Controlling-Werkzeugs ist die monetäre Bewertung des Fertigstellungsgrads (Earned Value). Die deutsche Übersetzung laut DIN 69903 ist der „Fertigstellungswert“. Oft findet man auch den Begriff des „Leistungswerts“. Mit anderen Worten: Wie viel Leistung habe ich für mein Geld bekommen? PC AC EV CPI SPI SV CV BAC EAC ETC VAC PAC TAC DAC Planned Cost Actual Cost Earned Value Cost Performance Index Schedule Performance Index Schedule Variance Cost Variance Budget at Completion Estimated Cost at Completion Estimate to Complete Variance of Completion Plan At Completion Time At Completion Delay At Completion Abb. 3: Abkürzungen aus der Earned Value Analysis (EVA). Mathematisch ausgedrückt ist der Earned Value die Multiplikation des Werts des gesamten (geplanten) Projektbudgets (BAC – Budget at Completion) mit dem Fertigstellungsgrad (FFG in Prozent) zum Berichtszeitpunkt. EV = BAC*FFG. Eine Übersicht über die in einer EVA verwendeten Kennzahlen zeigt Abbildung 3. Earned Value Analysis Cockpit Eingabewerte Berichtszeitpunkt EVA kann helfen Was ist überhaupt anders als bei der „klassischen“ Betrachtung von Budgetverlauf und Ist­kosten? Der entscheidende Unterschied ist die monetäre Bewertung des Projektfortschritts. Erst dadurch wird der Wert mit den Plan- und Istkosten direkt vergleichbar, da die­ se beiden auf Währungseinheiten beruhen. Die Earned Value Analysis hilft vor allem bei: • • • • Der Bewertung des Projektfortschritts Der Schafffung einer Basis für fundierte Berichte Der Erhaltung der Trenderkennung zum Projektverlauf (monetär und zeitlich) Der Schaffung von Vergleichbarkeit verschiedener Projekte und damit Lieferung von Hinweisen für das Multiprojektmana­ ge­ment Dazu stellt die Earned Value Analysis zum Berichtszeitpunkt folgende Kennzahlen gegenüber: • • • Plankosten (PC – Planned Cost) Istkosten (AC - Actual Cost) Fertigstellungswert (EV - Earned Value) Der Nutzen dieses Kennzahlensystems ist, dass sich allein durch Eingabe des Projektbudgets (BAC), dem Start-/Endetermin, des 1. April 2008 Projektstart Projektende 3. März 2008 31. August 2008 Fachlicher Fertigstellungsgrad AC (Istkosten) BAC (Projektbudget) (Planbasis) 17% 20.000 100.000 Abgeleitete/errechnete Earned Value Kennzahlen Gesamtstatus EV (Fertigstellungs­ wert) 17.000 zeitbezogene Kennzahlen PC (Plankosten zum Berichtszeitp.) 16.022 Budget-Kennzahlen und Indizes PAC (geplante Projektlaufzeit in Wochen) 25,9 EAC (erwarteter Budget­umfang zum Projektende) 117.647 TAC (benötigte Projektlaufzeit in Wochen) 24,4 VAC (erwartete Budget­ab­weichung zum Projektende) -17.647 DAC (ProjektVerzögerung in Wochen) 1,5 ETC (ggf. noch erfor­der­liches Budget) EAC-AC 97.647 VAC (erwartete Budget­abweichung ggü. Plan) -17,6% Performance-Kennzahlen SV (Planbweichung in EUR) 978 SPI (TerminPerformance) 1,06 CV (Kosten­ abweichung in EUR) -3.000 CPI (KostenPerformance) 0,85 Abb. 4: Earned Value Cockpit – EVA-Kennzahlen im Überblick. ORDIX News 4/2008 7 Projektmanagement Fertigsstellungsgrads und der Istkosten (AC) alle weiteren Kennzahlen des Projekts zeitlicher und monetärer Art ableiten lassen. Sie geben Aufschluss über den Fortschritt des Projekts (siehe Abbildung 4). Die EVA-Kennzahlen im Überblick Ausgangswert in diesem Beispiel ist zum einen das geplante Projektbudget (BAC) von 100.000 Euro und eine Projektdauer von 6 Monaten. Unter der Annahme, dass nach einem Monat, zum ersten Berichtszeitpunkt, 20.000 Euro ausgegeben wurden und ein 140000 120000 Euro 100000 Fertigstellungsgrad von 17 % erreicht wurde, ergeben sich dadurch alle weiteren Kennzahlen der EVA. Trägt man die Daten des jeweiligen Berichtszeitpunkts über eine zeitliche Periode hinweg in ein Diagramm ein, ergibt sich dadurch die in Abbildung 5 dargestellte „Fieberkurve“ des Projekts. In diesem Beispiel erkennt man deutlich, dass die Kurve für das zu erwartende Projektbudget schon zum Datum des ersten Berichtszeitpunkts über dem geplanten (100.000 Euro) liegt. Der Anstieg der Kurve weist darauf hin, dass zu schnell Geld ausgegeben wird. Dies sieht man auch daran, dass die Kurve für die Istkosten permanent über der Kurve der Plankosten und des Fertigstellungswerts liegt. Wobei letztere die Plankosten bereits früh schneidet und dauerhaft drunter bleibt. D. h. der Arbeitsfortschritt hinkt ständig hinterher. Neben dem o. g. Kostenverlauf existieren noch zwei andere Kennzahlen, die weiteren Aufschluss über den Verlauf des Projekts geben: 80000 60000 40000 AC EV PC EAC 20000 0 M1 M2 M3 M4 Projektdauer M5 • M6 Abb. 5: EVA-Verlauf „Fieberkurve“. • 1,50 1,40 1,30 1,20 1,10 1,00 0,90 0,80 0,70 SPI CPI 0,60 0,50 M1 M2 M3 M4 Projektdauer Abb. 6: SPI/CPI-Verlauf. 8 ORDIX News 4/2008 M5 M6 SPI, der Schedule Performance Index beschreibt, inwieweit das Projekt zeitlich im Plan ist. SPI = EV / PC. Man spricht hier auch von „Termin-Performance“. Auf dem SPI basiert dann auch die Ableitung der erwarteten Projektlaufzeit (TAC). • SPI > 1 Der Projektfortschritt ist schneller als geplant. • SPI < 1 Es gibt einen zeitlichen Verzug im Projekt. Der CPI (Cost Performance Index) beschreibt, inwieweit das Projekt aus Kostensicht im Plan ist. CPI = EV / AC. Man spricht hier auch von „Kosten-Performance“. • CPI > 1 Das Projekt verläuft kosten­günstiger als geplant. • CPI < 1 Das Projekt wird vermutlich teurer als geplant. Idealerweise liegen beide Indizes bei 1. Dadurch weiß ein Controller, dass die geplanten Mittel und Ressourcen auch benötigt werden. Im Hinblick auf das Multiprojektcontrolling ist das IT-Management auf diese Information angewiesen, wenn zusätzliche Mittel (CPI < 1) erforderlich sind oder freiwerdende Mittel (CPI > 1) bzw. Ressourcen (SPI > 1) zur Disposition stehen. Trägt man auch hier wiederum beide Werte über eine zeitliche Periode in ein Diagramm ein, ergibt sich für das o. g. Beispiel der in Abbildung 6 dargestellte SPI/CPI-Verlauf des Projekts. Projektmanagement Die blaue Kurve (SPI) beinhaltet die Information, dass das Projekt zunächst rasch voran geht. Dann verzögert es sich, SPI schneidet die 1 zwischen M2 und M3. Und letztlich, wenn auch knapp, bleibt es nicht im Terminrahmen. Die rote Kurve (CPI) sagt aus, dass das Projekt schon zu Beginn zu viele Kosten verschlingt. Dieser Trend setzt sich während des gesamten Projekts so fort. (CPI pendelt um 0,8), sodass es am Ende insgesamt teurer wird als geplant. Glossar Pareto- Das Pareto-Prinzip, auch „80-zu-20-Regel“, „80-20-Verteilung“ oder „ParetoPrinzip Effekt“ genannt, beschreibt das statistische Phänomen, wenn eine kleine Anzahl (20 %) von hohen Werten einer Wertemenge mehr zu deren Gesamtwert beiträgt, als die hohe Anzahl (80 %) der kleinen Werte dieser Menge. Davon lässt sich auch ableiten, dass sich viele Aufgaben mit einem Mitteleinsatz von ca. 20 % so erledigen lassen, dass 80 % aller Probleme gelöst werden. Links ►► [1] IT-Projektcontrolling (Teil I): Service statt Kontrolle: http://www.ordix.de/ ORDIXNews/3_2008/Projektmanagement/Einfuehrung_IT_Projektcontrolling.html Fazit ►► [2] „Guide to the Project Management Body of Knowledge“ (PMBOK), Werden Kennzahlenwerte professionell aufbereitet, z. B. nach anerkannten Methoden wie Earned Value Analysis, so entstehen Berichte für das Management, die auf einer nachvollziehbaren und damit verständlichen Systematik basieren. Projektcontrolling leidet oft zu Unrecht unter dem Vorurteil, bürokratischer Ballast zu sein. Dabei hilft der Projektcontroller durch pragmatische Anwendung von Kennzahlen und dem Einsatz von Controlling-Werk- Project Management Institutes (PMI), ISBN-13: 978-1930699724 ►► Seminarempfehlungen: ►► [3] IT-Projektmanagement: http://training.ordix.de/seminar.php?nr=223 ►► [4] IT-Controlling Grundlagen: http://training.ordix.de/seminar.php?nr=224 zeugen dem Projektleiter bei der Navigation, wie ein Lotse dem Kapitän eines Schiffes. Rainer Restat ([email protected]). Seminarempfehlung: IT-Projektcontrolling in der Praxis ►► Informationen und Online-Anmeldung im Internet: http://training.ordix.de/seminar.php?nr=787 Sie erhalten einen umfassenden und systematischen Überblick über Begriffe, Methoden und Arbeitstechniken für das operative Einzelprojekt-Controlling und lernen die verschiedenen Aufgaben kennen. Über die Grundlagen hinaus werden schrittweise Themen wie Kennzahlen, Steuerungs­maßnahmen, Schnittstellen zum Projektmanagement sowie der Umgang mit Controlling-Methoden vermittelt. Zielgruppe Projektmanager und angehende Projektleiter sowie erfahrene Entwickler, Systemspezialisten und IT-Führungskräfte. Voraussetzungen IT-Kenntnisse und erste praktische Erfahrungen in der Projektarbeit. Seminarinhalte • • • • • • Grundlagen: Spektrum des IT-Projektcontrollings, Einzel- und Multiprojektcontrolling, Portfolio-Management Herausforderungen und Ziele des operativen Einzelprojektcontrollings, Steuerungsmaßnahmen, Kennzahlen, Datenerfassung, Auswertung, Fertigstellungsgrade Methoden und deren Anwendung, Wirtschaftlichkeitsrechnungen, Nutzwertanalyse, Earned Value Analysis, Prognosen Integration des IT-Projektcontrollings in die Organisation des Unternehmens Dynamik der Projekte und Konsequenzen für das Controlling, Schnittstellen zum IT-Projektmanagement Fallbeispiele, Übungen Termine 29.06.- 01.07.2009 in Wiesbaden 21.09.- 23.09.2009 in Wiesbaden Seminar-ID: PM-05 Dauer: 3 Tage Preis pro Teilnehmer: 1.290,00 € (zzgl. MwSt.) Frühbucherpreis: 1.161,00 € (zzgl. MwSt.) Wir führen unsere Seminare auch jederzeit an einem geeigneten Ort Ihrer Wahl durch und bringen, wenn nötig, auch das entsprechende Equipment mit. Informieren Sie sich am besten im Internet über unsere Inhouse-Seminare und die mobilen Schulungen: http://training.ordix.de. ORDIX News 4/2008 9 Datenbanken MySQL Falcon (Teil II): Transaktionspower: Performance-Vergleich Falcon vs. InnoDB Der Artikel richtet sich an MySQL-Anwender und -Administratoren. In Ausgabe 2/2008 [1] stellten wir Ihnen die neue Storage Engine Falcon vor. Nun möchten wir diesen neuen Tabellentyp genauer untersuchen und einen Vergleichstest mit InnoDB, dem heutigen „Marktführer“ unter den transaktionsfähigen MySQL-Engines, vornehmen. Wer von beiden bietet die bessere Performance? Wer, Wie, Was? Das Werkzeug: Super Smack Performance-Messungen bzw. Benchmarktests sind schwierige Aufgaben im Leben eines Datenbankadministrators. Vor der eigent­lichen Messung sind zunächst einige wichtige Fragen zu klären: Beginnen wir zunächst mit der letzten Frage. Auf dem Open Source Markt sind viele kleine Skripte und Programme verfügbar, mit denen Performance- und/oder Lasttests gegen My­SQL gefahren werden können. • • • • 10 ORDIX News 4/2008 Gibt es ein Datenmodell inklusive Daten, das für die Messung verwendet werden kann? Handelt es sich um reale Daten oder müssen Testdaten generiert werden (und wenn ja, wie)? Sollen mehrere Anwender simuliert werden (Lasttest-Szenario)? Gibt es ein geeignetes Tool, welches für die Mes­sung verwendet werden kann, bzw. wie kann ein Anwenderverhalten sinnvoll simuliert werden? Ein wirklich brauchbares Werkzeug ist das von Sacha Pachev entwickelte und von Jeremy Zawodny geförderte Super Smack [2]. Zwar wurde dieses Werkzeug seit längerem nicht weiterentwickelt (zumindest ist dem Autor nichts bekannt), allerdings hat dies keine negativen Auswirkungen auf die Anwendung. Die aktuelle Version 1.2 vom Stand September 2003 ist auch mit den neuesten MySQLVersionen voll kompatibel. Super Smack kann übrigens auch für Oracle und PostgreSQL verwendet werden. Datenbanken Negativ stößt lediglich die Tatsache auf, dass die Dokumentation zu Super Smack nicht sehr umfangreich ist. Der geneigte Anwender muss sich mit einem 83-zeiligen Tutorial begnügen. In Kombinationen mit den beiden mitgelieferten Beispielszenarien sollte aber jeder erfahrene MySQL-Datenbankadministrator in der Lage sein, sich seine eigene Teststellung aufzubauen. Darüber hinaus lohnt sich eventuell auch ein Blick in das Buch „High Performance MySQL“ [3] von Jeremy Zawodny, in dem das Tool ebenfalls beschrieben wird. Bedienungsanleitung Das Tool Super Smack bedient sich so genannter „smacks“, frei definierbarer Testszenarien, die gegen die Datenbank ausgeführt werden können. Im Wesentlichen bestehen diese „smacks“ aus Query Barrels, die wiederum aus einzelnen, frei wählbaren SQL-Statements zusammengesetzt sind. Ein Query Barrel sollte dabei einen typischen Nutzerzugriff simulieren. Die Teilkomponenten eines Barrel (also die einzelnen SQL-Statements) können unterschiedlich gewichtet werden. Hierzu kann einfach die Anzahl der Ausführungen der Teilkomponenten festgelegt werden. Abbildung 1 zeigt Auszüge aus einem Benchmark-Szenario. Rot hervorgehoben sind die Teilkomponenten des Barrel – in diesem Fall ein SELECT- und ein DELETE-Statement – sowie die Gewichtung der Teilkomponenten im Barrel. Da für eine sinnvolle Messung auch Testdaten benötigt werden, liefert Super Smack ein weiteres Tool gleich mit: GEN-DATA. Mit Hilfe dieses Werkzeuges können im Bedarfsfall schnell Testdaten generiert und in die Datenbank geladen werden. Testszenario Für unseren Vergleichstest wählen wir ein recht einfaches Datenmodell, welches lediglich aus einer einzigen Tabelle besteht (siehe Abbildung 2). Neben der Tabelle wurde ein Primärschlüssel (und damit ein unique Index) auf die Spalte mitarbeiternr gelegt. Die Tabelle repräsentiert Mitarbeiterstammdaten einer fiktiven Firma. Durch eine Protokollierung des Anwenderverhaltens - z. B. über den Parameter bin-log [4] – wird das aktuelle Nutzerverhalten direkt über die Datenbank aufgezeichnet. Für unseren Testfall wurde das Nutzungsmuster aus Abbildung 3 ermittelt. //define a query query "select_by_number" { query "select * from fmitarbeiter where mitarbeiternr = '$word'"; // $word will be substitute with the read from the 'word' dictionary type "select"; // query stats will be grouped by type has_result_set "y"; // the query is expected to return a result set parsed "y"; // the query string should be first processed by super-smack to do // dictionary substitution } ... //define a query query "delete_by_number" { query "delete from fmitarbeiter where mitarbeiternr = '$word'"; // $word will be substitute with the read from the 'word' dictionary type "delete"; // query stats will be grouped by type has_result_set "y"; // the query is expected to return a result set parsed "y"; // the query string should be first processed by super-smack to do // dictionary substitution } // define database client type client "smacker1" { user "test"; // connect as this user pass ""; // use this password host "localhost"; // connect to this host db "test"; // switch to this database socket "/tmp/mysql.sock"; // this only applies to MySQL and is // ignored for PostgreSQL query_barrel "14 select_by_number 4 update_by_number 1 delete_by_number 1 insert"; // on each round, // run select_by_username query 2 times } ... Abb. 1: SMACK: Auszüge aus einem Benchmark-Szenario. CREATE TABLE 'mitarbeiter' ( 'mitarbeiternr' int(11) DEFAULT NULL, 'nachname' varchar(40) DEFAULT NULL, 'vorname' varchar(40) DEFAULT NULL, 'gehalt' int(11) DEFAULT NULL, 'beruf' varchar(40) DEFAULT NULL, 'mail' varchar(40) DEFAULT NULL, 'eintrittsdatum' int(11) DEFAULT NULL, 'abteilungsnr' int(11) DEFAULT NULL, KEY 'i_pk' (`mitarbeiternr`) ) ENGINE=InnoDB DEFAULT CHARSET=latin Abb. 2: Das Datenmodell des Performance-Tests. 70 % 20 % SELECT UPDATE 5% INSERT 5% DELETE Abb. 3: Nutzungsmuster inklusive der dahinterstehenden SQL-Befehle. ORDIX News 4/2008 11 Datenbanken shell> super-smack szenario.smack 5 100 Query Barrel Report for client smacker1 connect: max=48ms min=6ms avg= 26ms from 5 clients Query_type num_queries max_time min_time q_per_s delete 500 0 0 321.70 insert 500 8 0 321.70 select 7000 0 0 4503.84 update 2000 0 0 1286.81 Abb. 4: Performance-Testergebnis: Gemessen wurden die einzelnen Teilkomponenten des Barrel, wenn 5 Clients das Query Barrel jeweils 100x ausführen. Teststellung Falcon Parameter InnoDB Parameter -–falcon_min_record_memory=500M -–falcon_max_record_memory=500M -–falcon_page_cache_size=500M -–key-buffer-size=500M -–innodb-buffer-pool-size=500M -–innodb-log-file-size25M -–innodb-thread-concurrency=8 Abb. 5: Parameter zur Einstellung der spezifischen Cache-Bereiche. 8000 6000 5000 Falcon InnoDB Falcon InnoDB Falcon InnoDB Falcon 1000 InnoDB 2000 Falcon 4000 InnoDB Statements / Sek. 7000 3000 0 1 10 25 50 100 Anzahl Clients Abb. 6: Auswertung SELECT: Anzahl der möglichen SELECT-Statements pro Sekunde in Abhängigkeit von der jeweiligen Storage Engine. Links ►► [1] ORDIX News Artikel „MySQL Falcon“ Teil I: http://www.ordix.de/ORDIXNews/2_2008/Datenbanken/mysql_falcon.html ►► [2] MySQL Super Smack: http://jeremy.zawodny.com/mysql/super-smack ►► [3] Literaturtipp: „High Performance MySQL - Optimierung, Datensicherung, Replikation & Lastverteilung“ von Jeremy Zawodny & Derek J. Balling: http://www.oreilly.de/catalog/hpmysqlger/toc.html ►► [4] ORDIX News Artikel “Nimm zwei - Replikation unter MySQL”: http://www.ordix.de/ORDIXNews/3_2005/mysql_replikation.html ►► [5] MySQL Performance Blog: http://www.mysqlperformanceblog.com/ 2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/ 12 ORDIX News 4/2008 Die ermittelten SQL-Statements gehen mit ihrer Gewichtung direkt in das Query Barrel ein und gewährleisten damit eine aussagekräftige Teststellung (siehe Abbildung 4). Für unseren Performance-Vergleich werden wir unterschiedliche Lasttestszenarien unterstellen (Anzahl paralleler Anwender). Die SELECTStatements werden parallel von jeweils 1, 10, 25, 50 und 100 Clients ausgeführt. Bei den DML-Statements begnügen wir uns aufgrund der längeren Ausführungszeit mit 1, 5, 10, 15, 25 und 50 Clients. Zur Durchführung unserer kleinen Messreihe bedienen wir uns der aktuellen MySQL-Ver­sion 6.0.6-alpha. Beide Storage Engines werden mit vergleichbaren Speicherbereichen ausgestattet und gestartet (siehe Abbildung 5). Alle weiteren Parameter werden auf den MySQL-Defaultwerten belassen. Als Datenbasis werden mit Hilfe von GEN-DATA vor Testbeginn 500.000 Datensätze generiert und in die jewei­ ligen Testtabellen geladen. Um eine saubere Analyse der Storage Engines in den Teilberei­ chen der SELECT-, UPDATE-, INSERT- und DELETE-Statements zu erhalten, erfolgte die Messung dieser Statements initial separat. Abschließend wurde das gewichtete und kombinierte Testszenario gegen die Datenbank ausgeführt. Alle Teststellungen wurden mehrfach (10x) gegen die Datenbank ausgeführt und die Mess­ergebnisse über die Testreihe gemittelt. Die einzelnen Statements (mit Ausnahme der INSERT-Statements) enthalten jeweils eine WHERE-Klausel, die auf eine indizierte Spalte (Primärschlüssel mitarbeiternr) zugreift. Bei dem eingesetzten Rechner handelt es sich um einen handelsüblichen Desktop PC mit einer 2 GHz Intel CPU und 2 GB RAM. Als Betriebssystem wurde ein OpenSuSe 10.1 eingesetzt. Falcon versus InnoDB Bei den indexbasierten SELECT-Statements ist zu erkennen, dass die Engine Falcon einen deutlich höheren Durchsatz an Statements pro Sekunde abarbeiten kann (ca. +50 % gegen­ über InnoDB). Erstaunlich ist die Tatsache, dass beide Engines mit einer zunehmenden Anzahl von parallel arbeitenden Clients nicht skalieren (siehe Abbildung 6). Der limitierende Faktor dürfte in diesem Fall eindeutig in der CPU des verwendeten Systems liegen. Für einen höheren Durchsatz stehen hier einfach keine weiteren Ressourcen zur Verfügung. Datenbanken Falcon InnoDB Falcon InnoDB Falcon InnoDB Falcon InnoDB Falcon InnoDB 500 Falcon 1000 InnoDB Statements / Sek. 1500 0 1 10 25 50 100 Anzahl Clients Abb. 7: Auswertung UPDATE: Anzahl der möglichen UPDATE-Statements pro Sekunde in Abhängigkeit von der jeweiligen Storage Engine. 9000 8000 7000 6000 Falcon InnoDB Falcon InnoDB Falcon InnoDB Falcon 2000 InnoDB 3000 Falcon 4000 InnoDB 5000 Falcon Bei den Teilergebnissen lag Falcon in den meis­ten Bereichen vorne. Beim kombinierten Szenario gab es ebenfalls keine Überraschungen. Falcon bietet im Schnitt gegenüber InnoDB einen Performance-Vorteil von 50 - 60 % (sie­ he Abbildung 8). Wenig überraschend ist, dass durch die wachsende Zahl der Clients der Durchsatz nicht wirklich steigt, da das Testszenario zu 70 % aus SELECT-Anweisungen besteht. Gerade in diesem Bereich konnten ja bereits zuvor keine Zuwächse durch parallele Client-Anfragen generiert werden. 2000 InnoDB Im Vergleich zu InnoDB schneidet Falcon im Parallelbetrieb deutlich besser ab. Dies dürfte an dem in Falcon neu implementierten MVCC-Konzept liegen, das auch im Vorfeld als Performance Feature mehrfach angekündigt wurde. 2500 Statements / Sek. Das Verhalten bei den DML-Statements weicht von diesem konstanten Ergebnis ab. Hier ist ein deutlicher Anstieg des Durchsatzes bei einer steigenden Anzahl von Clients zu verzeichnen (siehe Abbildung 7). Erstaunlich ist das Verhalten von Falcon im SingleUser Betrieb. Die Durchsatzrate ist für diesen Fall extrem hoch und wird selbst durch eine hohe Anzahl paralleler Sessions nicht wieder erreicht. Falcon bestätigt diese Eigenart über alle in diesem Benchmarking getesteten DMLStatements (INSERT, UPDATE, DELETE). 1000 0 1 Fazit In dem von uns unterstellten Szenario kann Falcon ohne Weiteres mit InnoDB mithalten. In Teilbereichen bietet es sogar die bessere Performance. Ob dieses Verhalten konsequent auch für andere Szenarien und Datenmodelle gilt, muss im Einzelfall geprüft werden. Zu vielfältig sind die unterschiedlichen Anwendungsfälle und Konfigurationsmöglich­keiten von MySQL und seinen Storage Engines. Bei einem im Internet veröffentlichten Benchmarktest [5] wurden so z. B. andere Ergebnisse für das SELECT-Verhalten der beiden hier betrachteten Storage Engines ge­messen. Allerdings wurden in diesem Benchmarking auch andere Rahmenbedingun­gen gesetzt. Vielleicht haben Sie ja nun ebenfalls Lust bekommen, ein kleines Benchmarking gegen Ihre MySQL-Datenbanken durchzuführen, um zu überprüfen, ob Sie die für Ihre Zwecke optimale Storage Engine einsetzen. Wir unterstützen Sie gerne dabei! 5 10 15 25 50 Anzahl Clients Abb. 8: Auswertung Testszenario: Auch beim kombinierten Test gibt es keine Überraschungen. Falcon ist in diesem(!) Szenario InnoDB deutlich überlegen. Glossar Storage Engine MySQL unterstützt verschiedene Speicher-Engines. Die Engines kümmern sich um den Zugriff und die physikalische Verwaltung eines MySQL-Datenbankservers. Am bekanntesten sind die Engines MyISAM und InnoDB. Query Barrel Eine Sammlung von einzelnen SQL-Statements die aus Datenbanksicht von einem einzigen Client ausgeführt werden. Durch ein Barrel soll ein typischer Anwender simuliert werden. MVCC Multi Version Concurrency Control. Ein Konzept zur optimierten Verarbeitung von parallel laufenden DML-Statements. Benchmark Beim Benchmarking handel es sich um eine vergleichende Analyse mit einem festgelegten Referenzwert. Ziel ist die Ermittlung (Messung) und Optimierung der Leistung eines IT-Systems. Lasttest Ein Lasttest dient der Ermittlung der Leistungsgrenze eines Sys­ tems. Zu diesem Zweck wird in aller Regel eine extrem hohe (Nutzer-)Last simuliert. Neben der Ermittlung der Leistungsgrenze erfolgen Lasttests, um Fehler in Systemen aufzudecken. Matthias Jung ([email protected]). ORDIX News 4/2008 13 Java/JEE Java Best Practice (Teil III): Java-Projekte bauen mit ANT Dieser Artikel richtet sich an Java-Entwickler und Projekt­ leiter, die den Einsatz eines Build Tools in Erwägung ziehen. Build Tools automatisieren den Weg vom Quellcode zum auslieferbaren Programm. Für Java ist ANT das Werkezug der Wahl. In diesem Artikel gehen wir auf die Installation, den Aufbau der Projektdatei und die Modularisierung von ANT ein. Darüber hinaus zeigen wir, wie man ANT auf der Konsole ausführt und wie das Zusammenspiel mit anderen Entwicklungsumgebungen – hier am Beispiel Eclipse – funktioniert. Java Best Practice ANT ANT ist ein auf der Programmiersprache Java basierendes Build Tool, vergleichbar mit MAKE unter Unix. Das Tool gibt es seit 2000. Es wurde ursprünglich von James Duncan Davidson entwickelt und steht unter der Apache License. ANT ist ein Akronym und steht für „Another Neat Tool“, was sich in etwa mit „noch ein hübsches Werkzeug“ übersetzen lässt. Gleichzeitig soll mit dem englischen Wort für „Ameise“ zum Ausdruck gebracht werden, dass kleine Dinge in der Lage sind, Großes zu vollbringen. Installation Die aktuelle Version der Software ist 1.7.1 und kann auf der Homepage des Projekts [1] heruntergeladen werden. Nach dem Entpacken der Zip-Datei muss die Umgebungsvariable ANT_HOME auf das Installationsverzeichnis von ANT gesetzt und das darin enthaltene /bin-Verzeichnis in den Pfad mit aufgenommen werden. Optional kann die Variable JAVA_HOME auf das Installationsverzeichnis von Java gesetzt werden. Anschließend kann auf der Kommandozeile mit dem Befehl ant -version die korrekte Installation überprüft werden. Aufbau einer Projekt-Datei Die Ausführung von ANT wird durch eine XML-Datei mit dem Namen build.xml ge- 14 ORDIX News 4/2008 steuert. Diese wird als Projektdatei bezeichnet. Das Root-Element heißt demzufolge auch project. Innerhalb des Projektes kann die Arbeit in mehrere Aufgaben strukturiert werden. Eingeleitet werden diese durch das Element target. ANT bringt einen Werkzeugkasten mit. Dieser enthält Tasks für elementare Operationen, wie kompilieren, kopieren, löschen etc. Dieser Werkzeugkasten kann erweitert werden: Für die Enterprise-Entwicklung werden oftmals Tasks für das Deployment mit der Application Server Software ausgeliefert. Im Folgenden behandeln wir die wichtigsten Aufgaben, die in einem Java-Projekt anfallen. Als Vorlage dient die XML-Datei aus Abbildung 1. Ein kompletter Überblick über alle Tasks von ANT befindet sich in der Anleitung, die Sie online auf der Internetseite des Projekts finden und die sich zusätzlich im Installationsverzeichnis auf der lokalen Platte befindet. Globale Variablen In jeder Datei können mit Hilfe des Elements property globale Variablen definiert werden, die in allen Targets benutzt werden können (siehe Abbildung 1, Zeile 10). Nützlich sind sie vor allem für die Definition von Pfadangaben. So kann die Property mit den Namen src den Ort der Java-Quelldateien festlegen. Auf die Definition kann dann über ${src} zugegriffen werden. Java/JEE Löschen Bevor Java-Programme kompiliert werden, müssen die alten Build-Verzeichnisse aufgeräumt bzw. gelöscht werden. Dies lässt sich mit dem clean-Target in Abbildung 1 ab Zeile 17 bewerkstelligen, das mittels deleteTasks das angegebene Verzeichnis löscht. Kompilieren Im Target mit dem Namen compile wird der Task javac benutzt, um alle Sourcen aus dem src-Verzeichnis in Bytecode zu wandeln und im build-Ordner abzulegen (siehe Abbildung 1, Zeile 21). Voraussetzung ist ein installiertes JDK und die Definition der Variablen JAVA_HOME. Optionale Attribute für dieses Element sind unter anderem der Class­path, in dem sich zusätzliche Bibliotheken befinden, die für die Übersetzung benötigt werden. Alle zu kompilierenden Quelldateien werden in einem include-Element angegeben. Dabei kann auch mit Wildcards gearbeitet werden. Eine Alternative ist die Benutzung eines Filesets, wobei ein Verzeichnis angegeben wird, in dem sich alle relevanten Dateien befinden. Als Filter können hier mittels include bzw. exclude die zu verwendenden Files eingeschränkt werden. Verpacken Nach dem Kompilieren kann alles in einem Java-Archiv (JAR-File) zusammengepackt werden. Dies übernimmt das hier genannte Target jar in Abbildung 1, ab Zeile 29. Neben dem Archivnamen meeting.jar wird in Filesets die Liste der zu packenden Dateien angegeben. (1) <project name="Meetings" default="deploy" (2) basedir="."> (3) <description> (4) Dieses Build-File kompiliert die Java-Sourcen, erstellt (5) die Deploy Descriptoren,packt das JAR-File zusammen und (6) deployt das ganze auf dem JBoss-Server. (7) </description> (8) (9) <!-- Setze globale Properties fuer dieses Build-File --> (10) <property name="src" location="src"/> (11) <property name="build" location="bin"/> (12) <property name="j2eedir" location="C:/jboss(13) 4.0.5GA/server/default/lib"/> (14) <property name="deploydir" location="C:/jboss(15) 4.0.5GA/server/default/deploy"/> (16) (17) <target name="clean" depends=""> (18) <delete dir=“${build}“/> (19) </target> (20) (21) <target name="compile" description="Compiliere die Sourcen"> (22) (23) <javac srcdir="${src}" destdir="${build}" (24) classpath="${j2eedir}/jboss-j2ee.jar"> (25) <include name="**/*.java" /> (26) </javac> (27) </target> (28) (29) <target name="jar" depends="compile" (30) description="Baut das JAR-File"> (31) <jar destfile="meetings.jar"> (32) <fileset dir="${build}"> (33) <include (34) name="de/ordix/meetings/entities/*.class"/> (35) <include (36) name="de/ordix/meetings/sessions/*.class"/> (37) <include name="META-INF/*"/> (38) </fileset> (39) </jar> (40) </target> (41) (42) <target name="deploy" depends="jar" (43) description="Deployt das JAR-File im JBoss"> (44) <copy file="meetings.jar" todir="${deploydir}"/> (45) </target> (46) (47)</project> Entsprechend gibt es Tasks für die Erzeugung von Web- und Enterprise-Archiven (WAR- bzw. EAR-Files). Dort ist es dann auch möglich, die von der JEE-Spezifikation geforderten Verwaltungsverzeichnisse für die Deployment Descriptoren META-INF und WEB-INF anzulegen und zu befüllen. mit Include- bzw. Exclude-Listen angegeben werden. Verteilen Ausführung auf der Konsole Nach erfolgreichem Zusammenpacken wird das Archiv - oder auch mehrere - auf dem Application Server „deployed“, was im einfachsten Fall einem Kopiervorgang gleichkommt (siehe Abbildung 1, Zeile 42). Dafür existiert der Task copy. Auch hier können einzelne Dateien oder aber ganze Filesets Ist die Projektdatei erstellt, kann ANT an die Arbeit gehen. Befindet man sich in einem Verzeichnis, in dem eine build.xml liegt, so reicht ein simples ant auf der Kommandozeile, um die Arbeit mit dem Default Target zu beginnen. Einzelne Targets hingegen lassen sich mittels ant targetname explizit starten. Abb. 1: Beispiel für eine build.xml-Datei. ORDIX News 4/2008 15 Java/JEE Auch Listen mehrerer Targets sind möglich. Um alle Optionen des Tools auf einen Blick zu bekommen, wird das Kommando ant-help verwendet. ANT modularisieren Wenn sich die Java-Projekte häufen und jedes von ihnen eine eigene build.xml besitzt, von denen man gegebenenfalls nur jeweils einzelne Targets ausführen möchte, so besteht die Möglichkeit, ein Buildfile ohne eigene Logik zu schreiben, von dem aus die jeweiligen Ziele der einzelnen Dateien aufgeru- (1) <target name="targetName1"> (2) <ant antfile="${basedir}/projekt2/build.xml" (3) inheritAll="false" target="targetName2"> (5) </ant> (6) </target> Abb. 2: Aufruf eines externen Targets. Glossar Java EE/JEE Java Enterprise Edition. Erweiterung von Java für Server-Anwendungen. XML Extensible Markup Language (XML). XML ist eine so genannte MetaSprache zur Beschreibung von Dokumenten. Ein Vorteil von XML ist der vereinfachte Austausch von Daten, da XML-Formate in einer strengen Grammatik definiert werden können, und so die Implementierung von zuverlässigen Schnittstellen erlaubt. IDE Integrated Development Environment. Eine IDE ist eine graphische Oberfläche für eine komfortable Software-Entwicklung. Z. B. Eclipse ist eine Java-IDE. Links ►► [1] ANT Dokumentationen und kostenloser Download http://ant.apache.org/ ►► [2] Eclipse Webseite: http://www.eclipse.org/ ►► [4] ORDIX News Artikel „Build Management mit Maven“: http://www.ordix.de /ORDIXNews/4_2007/Java_J2EE_JEE/maven_build_management.html 16 Java-Objekte in der Identitätskrise Eclipse Feinjustage Java-Projekte bauen mit ANT Exception Handling ORDIX News 4/2008 Auf diese Weise können komplexe Teile in separaten Build-Dateien ausgelagert und gegebenenfalls wiederverwendet werden. Großer Vorteil des zentralen Skripts ist, dass alle für das Projekt essentiell wichtigen Aufgaben in einer Datei zusammengefasst vorliegen, unabhängig von den tief in den Verzeichnishierarchien versteckten Build-Dateien. Zusammenspiel mit Eclipse Neben der klassischen Variante, ANT auf der Kommandozeile zu starten, existieren für eine Reihe von Entwicklungsumgebungen Plugins, um das Werkzeug komfortabel von dort aus zu starten. Dies soll hier exemplarisch an der weit verbreiteten IDE Eclipse [2] demonstriert werden. Eclipse bietet die Möglichkeit, über das Menü Windows Show view ANT ein zusätzliches Fenster zu öffnen. Dort können build.xmlDateien per Drag&Drop importiert oder aber über das Kontextmenü „Add Buildfiles…“ ausgewählt und hinzugefügt werden. Jede BuildDatei in der angezeigten Baumstruktur lässt sich auf-/zuklappen, um so die vorhandenen Targets übersichtlich darzustellen. Durch einen Doppelklick auf das jeweilige Target wird dieses sofort ausgeführt. Ein Klick auf die Build-Datei selbst startet das als Default eingestellte Target. Alle bei Ablauf produzierten Ausgaben erscheinen in der Consolen-View von Eclipse, die gegebenenfalls extra eingeschaltet werden muss. Fazit ►► [3] Maven Webseite: http://maven.apache.org/ Teil I: Teil II: Teil III: Teil IV: ... fen werden. Das Code-Beispiel in Abbildung 2 zeigt einen Ausschnitt aus einem solchen zentralen Build-Skript. Mit Hilfe des Tasks ant wird das Target targetName2 aus der Projektdatei, die im Attibut antfile angegeben ist, ausgeführt. Java Best Practice Mit ANT steht dem Entwickler ein mächtiges Build Tool zur Verfügung, das etabliert ist und als Quasi-Standard in der Java-Entwicklung eine große Anhängerschaft besitzt. Es ist erweiterbar und in vielen Entwicklungsumge­ bun­gen integriert. Einmal erstellte Build-Dateien können durch geringe Anpassungen in fast jedem Folgeprojekt wiederverwendet werden. Dennoch lohnt sich ein Blick auf das als „Nachfolger“ gehandelte Werkzeug Maven [3], das auch von Apache stammt [4]. Andre Dirr ([email protected]). Datenbanken Reihe Oracle Objekttypen von A - Z (Teil VIII): Queue – Advanced Queuing Im achten Teil der Reihe Objekttypen fahren wir mit dem Buchstaben „Q“ wie Queue fort. Augenmerk legen wir hier auf das Advanced Queuing. Eine vollständige Beschreibung aller Möglichkeiten würde den Rahmen dieses Artikels sprengen. Deshalb wird hier lediglich das Prinzip der Implementierung vorgestellt. Oracle Advanced Queuing Advanced Queuing (AQ) ist ein MessagingSystem in Oracle Datenbanken. Es ermöglicht den Datenaustausch zwischen verschiedenen Applikationen. Die Vorteile der Datenbankunterstützung zeichnen sich durch Hochverfügbarkeit, Sicherheit, Flexibilität und der Möglichkeit zur Datenrettung aus. Nachrichten werden in einer so genannten Warteschlange (= Queue) abgelegt. Die Datenbasis dieser Warteschlange ist eine Tabelle, in der jede Zeile eine Nachricht repräsentiert. Queue-Tabellen können mit verschiedenen Datentypen und somit Dateninhalten angelegt und dadurch an den Nachrichtenaustausch von Applikationen angepasst werden. Zu jeder Queue-Tabelle wird automatisch eine Exception Queue angelegt. Treten bei Weiterleitungen von Nachrichten Probleme auf oder ist die benutzerdefinierte Gültigkeitsdauer der Nachrichten überschritten, werden diese in die Exception Queue verschoben. Arten von Queues • • Dieser Artikel wendet sich an Datenbankadministratoren und Entwickler, die einen Überblick über die Objekttypen von Oracle bekommen möchten. Broadcast: Der Sender hat keine Kenntnis über den Empfänger. Point-to-Multipoint: Der Sender bestimmt die Empfänger der Nachricht. Datenbankumgebung einstellen Um Advanced Queuing in der Datenbank zu nutzen, muss mindestens ein Queue-MonitorProzess aktiv sein. Dieser Queue-Monitor-Prozess prüft beispielsweise nach, ob Nachrichten bereits an alle Empfänger gesendet worden sind und ob und wie lange diese nach vollständiger Bearbeitung aus der Queue entfernt werden (= rentention time). Hierzu sollte der Initialisierungsparameter AQ_TM_PROCESSES auf einen Wert > 0 eingestellt werden (bis Oracle 10g). Bei einem Wert von beispielsweise 10, werden mindes­ tens ein und maximal zehn Prozesse gestartet. Die Anzahl der aktiven Prozesse richtet sich nach dem Arbeitsaufkommen zum Abarbeiten der Queues. ALTER SYSTEM SET AQ_TM_PROCESSES=1 SCOPE=BOTH; Abb. 1: Initialisierungsparameter AQ_TM_PROCESSES. Es gibt zwei Arten von Queues: • Singleconsumer Queues (Point-to-Point) Es gibt genau einen Sender und genau einen Empfänger. • Multiconsumer Queues Eine Nachricht kann von mehreren Empfängern gelesen werden. CREATE TYPE my_aq_type AS OBJECT( no NUMBER, title VARCHAR2(30), text VARCHAR2(200)); Abb. 2: Estellen eines Payload-Objekts. ORDIX News 4/2008 17 Datenbanken DBMS_AQADM.CREATE_QUEUE_TABLE( queue_table => 'MY_AQ_TABLE', queue_payload_type => 'MY_AQ_TYPE' ); Abb. 3: Erstellen einer Queue-Tabelle. DBMS_AQADM.CREATE_QUEUE( queue_name => 'MY_AQ_QUEUE', queue_table => 'MY_AQ_TABLE' ); Abb. 4: Erstellen einer Queue. DBMS_AQADM.START_QUEUE( queue_name => 'MY_AQ_QUEUE' ); Abb. 5: Starten einer Queue. DECLARE enqueue_options dbms_aq.enqueue_options_t; dequeue_options dbms_aq.dequeue_options_t; message_properties dbms_aq.message_properties_t; message_id RAW(16); my_message my_aq_type; BEGIN my_message := my_aq_type ( 1, 'First run', 'Date: '||TO_CHAR(SYSDATE, 'DD.MM.YYYY') ); Berechtigungen Die Implementierung von Advanced Queuing setzt bestimmte Berechtigungen voraus. In der Regel wird ein AQ-Administrator mit den benötigten Rechten angelegt. Dieser Administrator dient gleichzeitig als Eigentümer aller erstellten AQ-Objekte. Weiterhin können AQ-Nutzer angelegt oder bestehende mit den benötigten Rechten ausgestattet werden. Um das Vergeben der Rechte an andere AQNutzer zu erleichtern, ist es sinnvoll, eigene Rollen für die Nutzung bzw. Verwaltung der AQ-Architektur anzulegen. Oracle bietet bereits zwei vorgefertigte Rollen zum Advanced Queuing an: • • AQ_ADMINISTRATOR_ROLE AQ_USER_ROLE Implementierung Um Nachrichten über Advanced Queuing austauschen zu können, sind folgende Schritte notwendig: • • • • Erstellung eines Nachrichtentyps Erstellung einer Queue-Tabelle Erstellung einer Queue Starten der Queue dbms_aq.enqueue( queue_name => 'MY_AQ_QUEUE', enqueue_options => enqueue_options, message_properties => message_properties, payload => my_message, msgid => message_id); Eine Queue-Tabelle wird mit Hilfe des Packages DBMS_AQADM angelegt. Standardmäßig sind alle Queues Singleconsumer, sprich: genau ein Empfänger kann eine Nachricht verarbeiten. Der Empfänger braucht sich hierbei nicht auszuweisen. dbms_aq.dequeue( queue_name => 'MY_AQ_QUEUE', dequeue_options => dequeue_options, message_properties => message_properties, payload => my_message, msgid => message_id); Über den Parameter MULTIPLE_CONSUMERS der Prozedur CREATE_QUEUE_TABLE kann eine Multiconsumer Queue angelegt werden. COMMIT; dbms_output.put_line('Number: '||my_message.no); dbms_output.put_line('Title: '||my_message.title); dbms_output.put_line('Text: '||my_message.text); END; Abb. 6: Beispiel von Enqueue und Dequeue einer Singleconsumer Queue. 18 Die Änderung des Parameters kann auch im laufenden Betrieb vorgenommen werden (siehe Abbildung 1). ORDIX News 4/2008 Hier können die Empfänger implizit als so genannte Teilnehmer (= Subscriber) ausgewiesen, oder explizit beim dem Versenden einer Nachricht als Empfänger (= Recipient) angegeben werden. In diesem Fall können einige Subscriber die Nachricht nicht erhalten. Jede Nachricht trägt Nutzdaten (= Payload) mit sich. Diese Nutzdaten können sowohl Basisdatentypen wie NUMBER und VARCHAR2 Datenbanken als auch Objekttypen sein. In Abbildung 2 wird für die Nutzlast ein Objekttyp verwendet. Mit Hilfe dieses Objekttyps wird eine QueueTabelle erstellt. Hierzu wird die Prozedur CREATE_QUEUE_TABLE aus dem Package DBMS_AQADM mit den nötigen Parametern aufgerufen. Der Parameter QUEUE_TABLE gibt den Namen der zu erstellenden QueueTabelle an. QUEUE_PAYLOAD_TYPE erwartet die Angabe eines Typs für die Nutzdaten, in dem Fall MY_AQ_TYPE (siehe Abbildung 3). Wurde die Queue-Tabelle erstellt, kann nun eine Queue erzeugt werden. Der Prozedur CREATE_QUEUE werden die Parameter QUEUE_NAME und QUEUE_TABLE übergeben (siehe Abbildung 4). Um die Queue nutzen zu können, wird sie mit Hilfe der Prozedur START_QUEUE in Betrieb genommen. Hier reicht die Angabe der zu startenden Queue im Parameter QUEUE_ NAME (siehe Abbildung 5). Sind alle Schritte erfolgreich verlaufen, kann die Queue nun genutzt werden. Das Beispiel in Abbildung 6 zeigt eine einfache Verwendung von Nachrichten Einreihung (= Enqueue) und die Entnahme von Nachrichten (= Dequeue). Für Enqueue und Dequeue wird kein implizites COMMIT gesetzt. Dies muss explizit in der Programmierung beachtet werden. SELECT FROM WHERE OBJECT_NAME -----------------------------MY_AQ_TYPE MY_AQ_TABLE AQ$_MY_AQ_TABLE_T AQ$_MY_AQ_TABLE_I AQ$_MY_AQ_TABLE_E AQ$_MY_AQ_TABLE_F AQ$MY_AQ_TABLE MY_AQ_QUEUE Fazit Oracle Advanced Queuing ist ein mächtiges Werkzeug für den Umgang mit Queues. Bei komplexen Projekten oder sei es allein nur für die Kommunikation zwischen zwei Applikationen, gewinnt Advanced Queuing immer mehr an Bedeutung. Hier kann die gesamte Bandbreite der Funktionalität von Advanced Queuing in Betracht gezogen werden. Die von Oracle zur Verfügung gestellte Java-Bibliothek zum Advanced Queuing gibt zusätzliche Freiheit zur unabhängigen Applikationsentwicklung. OBJECT_TYPE ------------------TYPE TABLE INDEX INDEX QUEUE VIEW VIEW QUEUE Abb. 7: Selektion von erstellten AQ-Objekten. Glossar Advanced Queuing (AQ) AQ ist ein Messaging-Mechanismus in einer Datenbank. Enqueue Einstellen von Nachrichten in eine Queue. Dequeue Entnahme einer Nachricht aus einer Queue. Links ►► ►► ►► [1] Oracle Dokumentation „Oracle Streams Advanced Queuing“: http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/integrat.htm#sthref3346 [2] ORDIX News Artikel: „Oracle Advanced Queuing und Java“: http://www.ordix.de/ORDIXNews/4_2007/Datenbanken/oracle_adv_queuing_java.html [3] ORDIX News Artikel: „Information Sharing mit Oracle Streams“: http://www.ordix.de/ORDIXNews/2_2006/Datenbanken/oracle_streams.html Seminarempfehlung: Oracle Streams Advanced Queuing Datenbankobjekte Eine einfache Selektion (siehe Abbildung 7) auf den Data-Dictionary View ALL_OBJECTS, gibt einen Überblick der erstellten Datenbankobjekte. object_name, object_type all_objects object_name LIKE '%MY_AQ%'; ►► Informationen/Online-Anmeldung: http://training.ordix.de/seminar.php?nr=574 In diesem Seminar werden Sie mit der Funktionsweise von Advanced Queuing (AQ) vertraut gemacht, welches der Kommunikation beispielsweise zwischen verschiedenen Applikationen dient. Dabei werden die zu verschickenden Meldungen permanent in der Datenbank gespeichert. Sie erlernen die Theorie und Praxis der Konfiguration und Administration sowie der Einsatzmöglichkeiten des AQ. Seminarinhalte • • • • • • • • Überblick Architektur Einsatzmöglichkeiten Konfiguration/Initialisierung Administration Programmierung/Interfaces Sicherheit und Zugriffskontrolle Fehlerbehandlung Termine 02.03.- 04.03.2009 in Wiesbaden 22.06.- 24.06.2009 in Wiesbaden 14.09.- 16.09.2009 in Wiesbaden 23.11. - 25.11.2009 in Wiesbaden • • • • • • • Export/Import Performance und Skalierung Internet-Zugriff Data Dictionary Views Oracle JMS and Oracle Streams AQ Messaging Gateway Vertiefung der Theorie durch praktische Übungen und Beispiele Seminar-ID: DB-ORA-37 Dauer: 3 Tage Preis pro Teilnehmer: 1.290,00 € (zzgl. MwSt.) Karsten Fiedler ([email protected]). ORDIX News 4/2008 19 Open Source Codename Indiana: OpenSolaris - Kleider machen Leute Der Artikel richtet sich an UnixSystemadministratoren, die sich speziell mit Solaris beschäftigen, aber auch an Personen, die sich für alternative DesktopSysteme interessieren. 20 ORDIX News 4/2008 Wer frühzeitig wissen möchte, wie sich das aktuelle Betriebssystem Solaris weiterentwickeln wird, der sollte sich einmal im OpenSolaris-Umfeld umsehen. In dieser quell­ offenen Variante des professionellen Betriebssystems von Sun Microsystems fließen aktuelle Entwicklungen ein, die später – vielleicht – den Weg ins Rechenzentrum finden werden. Open Source Test OpenSolaris ist der offene Zweig von Solaris, der sowohl für Entwickler als auch für DesktopAnwender zugeschnitten ist. Hier werden technische Neuerungen ausprobiert, die dann bei Marktreife in das nächste Solaris-Release einfließen. In diesem Artikel werden wir uns das OpenSolaris Release 2008.05 („Indiana“) näher ansehen und hierbei besonders die neuen technischen Errungenschaften beleuchten. Das Betriebssystem lässt sich damit ohne Installation und somit recht gefahrlos erkunden. Nach dem Booten muss nur die Tastaturbelegung und Sprachauswahl getroffen werden. Anschließend wird (beim graphischen Login) der X-Server gestartet und man kann loslegen. Die Anmeldung erfolgt automatisch als User jack, eine direkte Root-Anmeldung ist nicht möglich. Download Installation Die aktuelle Version 2008.05 von OpenSolaris ist nur für Intel-Plattformen zu haben. Es bietet aber vollständigen Zugang zu den bereits etablierten Funktionen von Solaris 10, wie Zonen, ZFS, DTrace, SMF etc. Unter [1] kann man sich gewissermaßen das Starterkit herunterladen. Es besteht schlichtweg aus einem ISO-Abbild, das eine Live-CD enthält. Die Installation verläuft sehr übersichtlich. Zuerst bestimmt man die Plattenbereiche, die für Solaris zur Verfügung stehen sollen. Dann wählt man Zeitzone, Sprachumgebung, RootPasswort und Initialbenutzer aus. Der Umfang der Erstinstallation ist durch das Medium CD deutlich geringer als bei Solaris. Open Source Weitere notwendige Software sowie Updates und Patches können aus dem Internet mit dem neuen IPS (Image Packaging System) nachinstalliert werden. Darauf gehen wir später noch näher ein. Der erste Eindruck Das neu installierte System macht einen frischen, modernen Eindruck (siehe Abbildung 1). Trotz des verhältnismäßig geringen Installationsumfangs - letztendlich ist das Dateisystem dann doch mit gut 2,3 GB belegt werden viele Applikationen mitgeliefert, die speziell für den Desktop-Anwender interessant sind (GIMP, Spiele, Multimedia-, Mailund Chat-Clients etc). Sun möchte dadurch die Attraktivität und damit die Popularität und Akzeptanz seines Betriebssystems steigern und Solaris als konkurrenzfähiges DesktopSystem präsentieren – zumindest Letzteres ist durchaus gelungen! Wir möchten in diesem Artikel hierauf aber nicht weiter eingehen, sondern uns mehr mit den Solaris-spezifischen Merkmalen und deren Neuigkeiten auseinandersetzen. Innere Werte Die Einbindung in ein bestehendes Netzwerk findet automatisch statt. Hierzu dient eine neue Instanz des Dienstes „physical network interface“ (svc:/network/physical:nwam, sie­he Abbildung 2). Dieser startet den nwamd (network auto-magic daemon) und den DHCPClient. Diese Vorgehensweise gilt übrigens auch für die Live-CD. Auffallend ist zunächst die Umsetzung des Superusers als eine Rolle (im Sinne von RBAC). Eine Konsequenz ist, dass man sich nicht direkt als root am System anmelden kann. Daher muss bei der Installation ein weiterer Benutzer angelegt werden. Wie sich herausstellt, wird dieser initiale Benutzer von der Installationsroutine mit weitreichenden Sonderrechten ausgestattet. Durch die Zuweisung des unter Solaris vordefinierten Profils „Primary Administrator“ und der Rolle root (siehe /etc/user_attr) ist er in der Lage, das System vollständig über die Kommandozeile zu administrieren! Dazu muss er entweder eine Profil-Shell starten oder dem gewünschten Kommando das Schlüsselwort pfexec voranstellen, um es dann im Kontext der zugeordneten Berechtigungen auszuführen. Alternativ kann man auch ganz klassisch per su in die Administratorrolle schlüpfen. Abb. 1: Indiana „live“. rn@sol11u5:~$ svcs -p network/physical STATE STIME FMRI disabled 20:44:15 svc:/network/physical:default online 20:44:28 svc:/network/physical:nwam 20:44:28 23 nwamd 20:44:47 102 dhcpagent Abb. 2: Standardmäßig wird per DHCP der Weg ins Netzwerk gefunden. rn@sol11u5:~$ pfexec pkg set-authority \ -O http://pkg.sunfreeware.com:9000 Sunfreeware rn@sol11u5:~$ pkg authority AUTHORITY URL opensolaris.org (preferred) http://pkg.opensolaris.org:80/ SunFreeware http://pkg.sunfreeware.com:9000/ Abb. 3: Zugriff auf externe Paketserver. # pkg refresh # pkg image-update Abb. 4: Systemaktualisierung in zwei Schritten. IPS Mit dem neuen Installationsverfahren können (SVR4)-Pakete bequem und einfach über das Internet installiert werden. Hierzu gibt es ein graphisches bzw. ein kommando-orientiertes Werkzeug. Über so genannte „Authorities“ wer- ORDIX News 4/2008 21 Open Source ­ en (vertrauenswürdige) Paketserver gehandd habt. Um z. B. direkt vom bekannten Server Sunfreeware.com installieren zu können, muss der entsprechende Rechner konfiguriert werden (siehe Abbildung 3). Ebenso lässt sich auf einfache Weise ein komplettes System aktualisieren (siehe Abbildung 4). Schwachpunkte sind hier allerdings die mäßige Performance und eine bei anderen Systemen sonst übliche, root@sol11u5:~# zoneadm -z z1 install Image: Preparing at /export/zones/z1/root ... done. Catalog: Retrieving from http://pkg.opensolaris.org:80/ ... done. Installing: (output follows) DOWNLOAD PKGS FILES XFER (MB) Completed 52/52 7830/7830 209.30/209.30 PHASE Install Phase Note: Postinstall: Postinstall: Postinstall: Done: ACTIONS 12880/12880 Man pages can be obtained by installing SUNWman Copying SMF seed repository ... done. Working around http://defect.opensolaris.org/bz/show_bug.cgi?id=681 Working around http://defect.opensolaris.org/bz/show_bug.cgi?id=741 Installation completed in 580,155 seconds. Next Steps: Boot the zone, then log into the zone console (zlogin -C) to complete the configuration process Abb. 5: Zoneninstallation per Netzwerk-Repository. hier aber leider fehlende Speicherplatzüberprüfung vor Installationsbeginn. Über IPS werden wir sicherlich noch einmal ausführlich berichten, wenn sich abzeichnet, dass sich das System etabliert. Zonen Beim Thema Zonen [3] stehen einige Grundsatzentscheidungen zur Diskussion, so dass hier noch nicht feststeht, wie es weitergeht. Z. B. wird als Standard-Branding einer Zone der Typ ipkg vorgegeben, deren Installation per IPS vorgenommen wird. Daher ist es erforderlich, während der Installation mit dem Internet verbunden zu sein (siehe Abbildung 5). Da die Zonen nicht mehr wie früher über die Globale Zone mit Software versorgt werden, treten Konzepte wie sparse- bzw. root-Zone in den Hintergrund. Die Installation der Zone ist damit unabhängiger von der globalen Zone. Sonstiges Hinter den Kulissen wird auch an den Feinheiten des Systems gearbeitet. Dazu gehört der weitere Ausbau der Dtrace-Provider sowie des Privilegienkonzepts und des RessourcenManagements. Glossar IPS Image Packaging System. Neues Paketverwaltungssystem, das unter anderem erlaubt, Software direkt über das Internet zu installieren. Live-CD Bootfähige CD, von der aus ohne sonstige Installation ein Betriebssystem gefahren werden kann. RBAC Role Based Access Control. RBAC ist ein Verfahren, womit definiert wird, welche Befehle mit zusätzlichen Rechten (z. B. Privilegien oder unter bestimmter Benutzerkennung) ausgeführt werden dürfen. Profil Zusammenfassung von administrativen Kompetenzen, die dann einer Rolle oder einem Benutzer zugewiesen werden kann. Rolle (RBAC) Pseudo-Identität, die mit Sonderrechten und -fähigkeiten im RBAC-Sinne ausgestattet ist. Profil-Shell Spezielle Shell, in der die Sonderrechte einer Rolle berücksichtigt werden. Slice Bezeichnet im Solaris-Jargon eine Partition einer Festplatte. Branding Beim Anlegen von Solaris-Zonen kann zwischen verschiedenen Typen („Brands“) gewählt werden. Links ►► ►► ►► ►► ►► [1] Download der aktuellen OpenSolaris Distribution: http://www.opensolaris.com [2] Alles zum Thema OpenSolaris: http://opensolaris.org [3] Zonen unter OpenSolaris 2008.05 uvm.: http://blogs.sun.com/dp [4] Interview mit Ian Murdock: http://www.itjungle.com/tug/tug080207-story01.html [5] Seminarempfehlung: „Solaris 10 für erfahrene Systemadministratoren“: http://training.ordix.de/seminar.php?nr=478 ZFS ist zum Standard-Dateisystem geworden. Das heißt auch, dass das root-Filesystem vom Typ ZFS ist. Swap-Bereiche werden weiterhin direkt auf einem Slice abgelegt. Eine Annäherung in Richtung Linux ist neben der offensichtlichen Desktop-Gestaltung und der Applikationsauswahl auch im Detail zu finden: so ist für root als Login-Shell die Bash voreingestellt und das Home-Verzeichnis ist nun (endlich!) /root. Fazit In Solaris 11 wird es wohl nicht so viele Innovationen geben, wie es noch bei Solaris 10 der Fall war. Aber vielleicht ist es ja auch erst einmal an der Zeit, die letzten technischen Neuerungen auszubauen und zu stabilisieren. Insgesamt ist ein deutlicher „Ruck“ in Richtung Linux spürbar. Das liegt sicherlich nicht zuletzt am Mitwirken von Ian Murdock, dem Mitbegründer von Debian [4]. Für weiterführende Infos empfehlen wir Ihnen unser Seminar „Solaris 10 für erfahrene Systemadministratoren“ [5]. Roger Niemeyer ([email protected]). 22 ORDIX News 4/2008 Aktuell Larry Ratlos: Problem bei Dateisystem­erweiterung in Solaris 10 Larry möchte auf einem Solaris 10 Datenbankserver ein ufs-Dateisystem vergrößern, auf dem sich vorwiegend Datenbankdateien befinden. Das bestehende Dateisystem mit 984 Gigabyte befindet sich auf einem Metadevice des Solaris Volume Manager. Es soll nun um zusätzliche 400 Gigabyte erweitert werden. Die Vergrößerung des Volumes funktioniert ohne Probleme. Als er aber das Dateisystem vergrößern will, bekommt Larry folgende Fehlermeldung: root@larry1 # growfs -M /oracle/data /dev/md/rdsk/d220 mkfs: bad value for nbpi: must be at least 1048576 for multi-terabyte, nbpi reset to default 1048576 Können Sie Larry helfen? Larry ist ratlos. Bisher konnte er das Dateisystem immer problemlos vergrößern. Aber warum schlägt es heute fehl? Wenn Sie die Erklärung kennen, schicken Sie sie bis zum 20.01.2009 an [email protected]. Für diejenigen unserer Leser, denen Perl mit ihren gerade einmal 21 Jahren Existenz noch zu jung ist und auch als Ehrenrettung für eine oft zu Unrecht vernachlässigte Unix-Skriptsprache, stellen wir hier jedoch eine Lösung mit der Programmiersprache awk vor, welche selbst mit ihren 31 Jahren noch lange nicht zum alten Eisen gehört: #!/bin/sh DBNAME="LOGTEST01" awk ' # Startzeile gefunden? /^[ \t]*'"$DBNAME"'[ \t\n=]/{ # Solange noch offene Klammern (bo) uebrig sind # oder die erste Klammer (fstb) noch nicht gefunden # wurde, Schleife durchlaufen while(bo>0||!fstb){ Lösung der Aufgabe aus 3/2008 # Wenn offene Klammer gefunden fstb=1 if(index($0,"(")){fstb=1} Im letzten Rätsel ging es darum, auf 20 Datenbank-Servern per Skript den Eintrag für die Testdatenbank „LOGTEST01“ aus der tnsnames.ora zu entfernen. Larry hat viele sehr gute Lösungsvorschläge der Leser erhalten, die bemerkenswerterweise alle eine Gemeinsamkeit hatten: es wurde die Programmiersprache Perl eingesetzt! # Addiere Differenz oeffnende/schliessende Klammern # zur Anzahl geoeffneter Klammern bo+=(gsub("[(]","")-gsub("[)]","")) Perl eignet sich in der Tat hervorragend für diese Aufgabe und daher konnte Larry diese Entscheidung sehr gut verstehen. # Naechste Zeile einlesen, wenn nicht EOF erreicht if(!getline){exit} } } # Alle Zeilen ausgeben, die vorher nicht uebersprungen wurden // ' $ORACLE_HOME/network/admin/tnsnames.ora > /tmp/tnsnames.ora.$$ mv /tmp/tnsnames.ora.$$ $ORACLE_HOME/network/admin/tnsnames.ora ORDIX News 4/2008 23 Datenbanken Projektbericht zum Einsatz von Oracle RMAN Datenbank-Backup mit RMAN in komplexen Umgebungen Der Artikel richtet sich an Entscheider, die ein DatenbankBackup-Verfahren auswählen sowie an Datenbankadministratoren, die komplexe Datenbank-Umgebungen sichern müssen. Die ORDIX AG hat im Rahmen eines Projektes für eine große deutsche Bank ein Verfahren für das Backup von Oracle Datenbanken mit dem Oracle Recovery Manager (RMAN) entwickelt und implementiert. Im Folgenden geben wir einen Überblick über das Projekt. Zielsetzung Ziel des Projektes war es, ein bestehendes, kom­ plexes Sicherungsverfahren durch eine einfache, effiziente und leicht administrierbare Lösung zu ersetzen. Ausgangssituation Serverlandschaft Beim Kunden befanden sich ca. 120 Oracle Datenbanken im Einsatz, die sich alle am selben Standort befanden. Dabei handelte es sich um Produktions-, Integrations- und Entwicklungsdatenbanken. Benutzt wurden die Releases 8.1.7.x (10 Datenbanken), 9.2.0.x (90 Datenbanken) und 10.1.0.x bzw. 10.2.0.x (20 Datenbanken). Als Betriebssystem wurde Sun Sparc Solaris 5.9 (64-bit) eingesetzt. Die Datenbanken liefen teilweise im Oracle RAC 9i und im Sun Cluster 3.1. Ausgangssituation Backup Das bisherige Backup erfolgte mit Oracle RMAN auf eine EMC Clarion als Backup Storage unter Nutzung eines zentralen Skripts, das folgende, schwerwiegende Nachteile aufwies: • • • • • • • Unübersichtlichkeit (über 3300 Zeilen Code) Hohe Komplexität Schwere Verständlichkeit Schlechte Wartbarkeit Schwierige Fehlersuche Viele Aufrufparameter Schlechte Dokumentation Weiterhin erfolgte das Backup ohne Katalogdatenbank. Dadurch fehlte eine zentrale Informa- 24 ORDIX News 4/2008 tionsquelle und eine redundante Haltung der RMAN-Metadaten. Die größten zu sichernden Datenbanken beweg­ ten sich im Terabyte-Bereich. Level-0-Backups dieser Datenbanken liefen teilweise über 12 Stunden. Für ein Restore/Recovery war mit einer 1,5- bis 2-fachen Dauer zu rechnen. Service Level Agreements (SLA) für diese Datenbanken existierten nicht. Sicherheitsrisiken Die RMAN-Policy-Einstellung lautete Recovery Window 7 Days; Sicherungen wurden also 7 Tage auf dem Backup Storage gehalten. Level0-Backups erfolgten einmal wöchentlich, Level1-Backups täglich. Außerdem wurden mehrmals täglich die archivierten Redo-Logdateien der im Archivelog-Modus laufenden Datenbanken gesichert. Vor der Erstellung eines Level-0-Backups wurden vorhandene Backups immer gelöscht, da sonst der Platz auf dem Backup-Server nicht ausgereicht hätte. Dies stellte ein erhebliches Sicherheitsrisiko dar, weil kein Backup mehr vorhanden war, wenn das aktuelle Level-0-Backup auf einen Fehler lief. Ein weiteres Sicherheitsrisiko bestand darin, dass die implementierte Lösung eine Exklusivität der Backups vorsah. Dies bedeutete, dass je Datenbankserver immer nur ein Backup-Job laufen durfte. Wenn ein Backup gestartet wurde und bereits ein anderer Backup-Prozess auf dem Datenbankserver lief, wartete das zentrale Skript 5 Minuten und versuchte dann, das Backup erneut zu starten. Lief immer noch ein anderer BackupJob, brach das Skript endgültig ab. Dadurch kam Datenbanken es vor, dass für Datenbanken keine Backups vorhanden waren. Recovery Manager RMAN Einsatz einer Katalogdatenbank Im Rahmen der Neustrukturierung wurde als zentrales Repository eine Katalogdatenbank aufgesetzt (siehe Abbildung 1). Dazu wurde die Oracle Software mit dem seinerzeit aktuellsten Patch Level (Release 10.2.0.2.0 ) installiert. Dies war nötig, da die Katalogdatenbank grundsätzlich in der zu sichernden Datenbanklandschaft die höchste Release-Nummer haben sollte. Der Oracle Doku­ mentation kann stets im jeweiligen Recovery Manager Reference Guide eine entsprechende Kompatibilitätsmatrix entnommen werden. Für diese Datenbank wurden initial 10 GB Plattenplatz vorgesehen und der Archivelog-Modus aktiviert. Außerdem wurde der RMAN-Katalog erzeugt. Selbstverständlich muss auch die Katalogdatenbank gesichert werden. Dafür gibt es zwei Ansätze: • • Sicherung mit RMAN ohne weitere Katalogdatenbank Aufbau einer weiteren Katalogdatenbank und gegenseitiges Backup der beiden Daten­ banken. Im Projekt wurde die erste Möglichkeit gewählt. Um die Sicherheit zu erhöhen, wurde die Katalogdatenbank so konfiguriert, dass ihre archivierten Redo-Logdateien in zwei Archivierungsziele in voneinander unabhängigen Storage-Systemen geschrieben werden. Veränderung der Retention Policy Um die beschriebenen Sicherheitsrisiken zu minimieren, wurde die Aufbewahrungszeit der Backups nicht mehr an eine Tageszahl (Recovery Window 7 Days) sondern an die Anzahl an Backups (retention policy to redundancy 3) gebunden. Damit werden nun 3 Level-0-Siche­ rungen sowie alle seit der ältesten vollständigen Sicherung angefallenen und gesicherten ar­chi­vierten Redo-Logdateien und Level-1-Si­ cherungen auf dem Backup Storage vor­gehalten. Für diese Policy reichte der verfügbare Plattenplatz allerdings nicht aus. Deshalb wurde auf Basis von Hochrechnungen weiterer Festplattenspeicher bereitgestellt. Veränderte Steuerung Die Neustrukturierung brachte auch einen Verzicht auf die bisherige, zentrale Steuerung der Backups mit sich. Stattdessen erfolgt der Start nun lokal über die Crontab des jeweiligen Da- DB Repository Ziel-Datenbank DB Abb. 1: Funktionsprinzip einer Katalogdatenbank als Repository in Verbindung mit dem Recovery Manager und einer Zieldatenbank. tenbankservers. Dabei werden von ORDIX entwickelte, versionsabhängige Skripte eingesetzt, die klein, verständlich und gut wartbar sind. Diese sichern eine Datenbank auch, falls die Katalogdatenbank nicht verfügbar sein sollte und verhindern, dass für eine Datenbank gleichzeitig mehrere Backup-Jobs laufen. Dieser Ansatz erforderte eine zentrale Planung der Datenbanksicherungen, da der Durchsatz des Backup Storage sowie die Bandbreite des Backup-Netzwerkes berücksichtigt werden mussten und deren möglichst gleichmäßige Auslastung erreicht werden sollte. Um die in den Crontabs der Datenbankserver zu den geschedulten Backups enthaltenen Informationen zentral verfügbar zu haben, wurde in der Katalogdatenbank ein zusätzliches Reporting-Schema angelegt, in dem diese Daten redundant gehalten und regelmäßig automatisch aktualisiert werden. Bei dieser Lösung muss jetzt aber die Katalogdatenbank lizensiert werden, was vorher nicht der Fall war. Eine zentrale Steuerung der Backups wäre grundsätzlich auch über Oracle Enterprise Manager (EM) Grid Control möglich. Dieser wird beim Kunden jedoch nicht eingesetzt. Implementierung Für die Implementierung standen zwei BackupTypen zur Wahl: inkrementell differentiell und inkrementell kummulativ. Bei inkrementell differentiellen Backups gibt es aufgrund der relativ kleinen Backup-Volumen bei Level-1-Sicherungen verhältnismäßig kurze Laufzeiten für die Backupvorgänge. Die Recovery-Zeit ist dagegen entsprechend länger, da mehr inkrementell diffe- ORDIX News 4/2008 25 Datenbanken rentielle Backups für ein Recovery angewendet werden müssen. Da Recovery-Zeiten im Projekt teilweise als kritisch eingestuft wurden, entschied man sich für die Implementierung inkrementell kummu­lativer Sicherungen. Diese haben zwar grundsätzlich höhere Volumen als inkrementell dif­fe­rentielle Backups, was die Laufzeit der Si­che­rungs­vor­ gänge erhöht. Jedoch bieten sie den Vorteil, dass die für ein Recovery erforderliche Zeit relativ kurz ist, weil vergleichsweise wenige Backups angewendet werden müssen. Der Unterschied in den Laufzeiten der Sicherungsvorgänge ergibt sich dadurch, dass bei inkrementell differentiellen Backups nur die Datenbankblöcke gesichert werden, die seit der letzten Level-1-Sicherung verändert wurden, während eine inkrementell kummulative Sicherung alle Blöcke erfasst, die seit der letzten vollständigen Sicherung (Level 0) verändert wurden. Einfaches Deployment Das Deployment wurde so konzipiert, dass es in wenigen, einfachen Arbeitsschritten erfolgen kann. Dazu wurden parametrisierte Skripte für jedes eingesetzte Datenbank-Release zentral abgelegt. Vorarbeiten für das Deployment Um auf den Backup-Speicher sichern zu können, benötigt der User oracle die entsprechende Schreibberechtigung. Des Weiteren mussten im Backup Storage die Mountpoints für die jeweiligen Datenbankserver eingerichtet und auf den Datenbankservern gemountet werden. Für die Kommunikation der Datenbankserver mit der Katalogdatenbank war zudem der Listener für die Katalogdatenbank zu konfigurieren und auf jedem Datenbankserver ein Eintrag für die Katalogdatenbank in der tnsnames.ora vorzunehmen. Durchführung des Deployment Das eigentliche Deployment besteht dann nur noch in der Registrierung der zu sichernden Daten­bank (register database) im RMANKa­talog sowie darin, alle für das Backup und Restore/Recovery benötigten Skripte durch Aufruf nur eines einzigen der zentral abgelegten Skripte zu erzeugen. Durch diesen Aufruf werden unter anderem auch Verzeichnisse für die jeweilige Datenbank im Backup Storage angelegt sowie ein Skript zur automatischen Befüllung des Reporting-Schemas in der Katalogdatenbank mit den Backup Schedules erzeugt. 26 ORDIX News 4/2008 Nacharbeiten zum Deployment Damit die Sicherungen der Datenbanken sowie die automatisierte Befüllung des ReportingSchemas in der Katalogdatenbank auch laufen können, sind abschließend noch folgende Arbeitsschritte erforderlich: • • Konfiguration des RMAN durch Ausführung eines der beim Deployment erzeugten Skripte (nicht bei Release 8i möglich). Scheduling der Backups sowie der automatischen Befüllung des Reporting-Schemas in der Katalogdatenbank in der Crontab des jeweiligen Datenbankservers. Neue Funktionalitäten Oracle bietet seit Release 10g die neue Funktion „Block Change Tracking“. Aktiviert man diese, liest RMAN bei einem Sicherungsvorgang nicht mehr sämtliche Oracle Blöcke der Datenbankdateien, um festzustellen, welche Blöcke geändert wurden und somit in das Backup aufzunehmen sind. Stattdessen schreibt die Datenbank Informationen über geänderte Blöcke in ein so genanntes „Block Change Tracking File“, das bei der Sicherung ausgelesen wird. Bei Nutzung dieser Funktion lässt sich für größere Datenbanken ein messbarer Performance-Gewinn in Form kürzerer Backup-Zeiten erzielen. Da während der Projektlaufzeit noch keine ausreichenden Erfahrungen mit „Block Change Tracking“ vorlagen, wurde dieses zunächst nicht benutzt. Inzwischen wird es beim Kunden aber erfolgreich eingesetzt. Herausforderungen Wie so oft in Projekten, gab es auch hier technische Herausforderungen: Die im Rahmen jeder Sicherung automatisch durchgeführte Resynchronisation des RMAN-Kataloges mit der Kontrolldatei der jeweiligen Datenbank benötigte mehrere Stunden, wenn die Kontrolldatei eine Größe im zweistelligen MB-Bereich hatte. Dieses Verhalten führte zu extremen, inakzeptablen Performance-Einbußen der Katalogdatenbank bzw. des Servers, auf dem diese betrieben wurde. Wie der Oracle Support nach langwierigen und umfangreichen, von ORDIX massiv vorangetrie­ benen Analysen schließlich feststellte, waren die vom RMAN intern durchgeführten Prozedur­auf­ rufe des Packages DBMS_BACKUP_RESTORE nicht optimal programmiert und somit für die einbrechende Performace verantwortlich. Einen Patch für dieses Problem konnte Oracle bis heute nicht liefern. Als Workaround wurde in den Backup-Skripten der regelbasierte Optimizer aktiviert /*+ rule */. Außerdem sind zur PerformanceVerbesserung die Kontrolldateien der betroffenen Datenbanken mit kleineren Größen neu angelegt worden. Datenbanken Bugs und andere Fehler Nach der Registrierung einer Datenbank im RMAN-Katalog kann es bei der anschließenden automatischen Resynchronisation des Kataloges mit der Kontrolldatei der Datenbank aufgrund des Bugs 3657899 zu dem Fehler ORA-01400 (cannot insert NULL into (%s)) kommen, wenn die Datenbank von Release 9i auf Release 10g migriert wurde. Dieses Problem kann durch die Neuanlage der Kontrolldatei beseitigt werden. Da dieses nicht immer ohne weiteres möglich ist, bietet Oracle in seiner Metalink-Note 283357.1 [1] als Workaround ein Reset des entsprechenden Teils der Kontrolldatei an, welches bei geöffneter Datenbank, also ohne Downtime, durchgeführt werden kann. Dazu ist in SQL*Plus der Befehl execute dbms_backup_restore. resetCfileSection(21); abzusetzen. Anschließend muss der zuvor mit dem Fehler abgebrochene Resynchronisierungsvorgang manuell gestartet werden. Schließlich kann es bei der Resynchronisa­tion noch zu einem Segmentation Fault kommen. Dieser lässt sich beseitigen, indem man den Wert der Umgebungsvariable NLS_LANG auf dem entsprechenden Datenbankserver auf den Wert setzt, den diese auf dem Server hat, auf dem die Katalogdatenbank betrieben wird. Glossar Oracle RAC Oracle Real Application Cluster; Verbund von Applikation und Services, die in einem Cluster betrieben werden. RAC wurde mit Release 9i eingeführt und stellt eine Weiterentwicklung des Oracle Parallel Server dar. Cluster Eine Gruppe von vernetzten Rechnern, die von außen in vielen Fällen als ein Rechner gesehen werden kann. Ziel des „Clustering“ besteht in der Regel in der Erhöhung der Rechengeschwindigkeit und/oder der Verfügbarkeit gegenüber einem einzelnen Rechner. Level-0-Backup Entspricht einem vollständigen Backup und ist Bestandteil einer inkrementellen Backup-Strategie. Level-1-Backup Nur geänderte und neue Daten werden gesichert. Level 1 Backups sind ebenfalls Bestandteil einer inkrementellen Backup-Strategie. Listener Oracle Prozess, der für die Herstellung von Verbindungen zur Instanz zuständig ist. Tnsnames.ora Oracle Konfigurationsdatei für Verbindungen zu Instanzen. Links ►► [1] http://metalink.oracle.com ►► Metalink-Note 283357.1 – Resync Catalog fails with Ora-1400 ►► Metalink-Note 305809.1 – RMAN Whitepapers and Technical Documents on Oracle Technet (OTN) ►► [2] Oracle Recovery Manager Dokumentation zu den Releases 8i, 9i und 10g: http://otn.oracle.com Restore und Recovery Auch für Restore und Recovery hat ORDIX entsprechende Skripte bereitgestellt. Diese erfordern aus Sicherheitsgründen jedoch bei Anwendung immer ein Eingreifen des Datenbankadministrators. Die im Fehlerfall zu treffenden Maßnahmen können sehr unterschiedlich sein und sollten daher nicht automatisiert ablaufen. Ausblick Die durch ORDIX geschaffene Lösung soll in Zukunft wie folgt ausgebaut werden: • • • • Erweiterung des Reporting-Schemas in der Katalogdatenbank um Informationen über er­folgreich durchgeführte und fehlgeschlage­ ne Backups sowie automatische Befüllung desselben Automatisiertes Protokollieren der RMANFehlermeldungen sowie der Backup-Laufzeiten und -Volumen im Reporting-Schema Erstellen einer graphischen Benutzeroberfläche zur übersichtlichen Darstellung der Informationen Entwicklung eines Abrechnungssystems auf Basis der im Reporting-Schema vorgehalte­ nen Daten Aufwand Der Aufwand für Entwicklung, Test und Implementierung der hier vorgestellten Lösung belief sich auf ca. 35 Personentage. Fazit Mit dem von ORDIX entwickelten Verfahren lassen sich Datenbanksicherungen selbst in gro­ ßen und komplexen Umgebungen leicht durchführen. Durch eine zentrale Datenhaltung im zusätzlichen Reporting-Schema sind Informationen über die Backups der gesamten Datenbanklandschaft einfach und schnell verfügbar. Der bei diesem Projekt von ORDIX verfolgte Ansatz, die Komplexität einer Aufgabenstellung durch ein Herunterbrechen auf die Ebene der Datenbank deutlich zu reduzieren, ließe sich sicher auch in anderen Umgebungen anwenden. Profitieren Sie von unserer Erfahrung und steigern auch Sie die Performance und Zuverlässigkeit Ihrer Backups. Fordern Sie uns! Klaus Reimers ([email protected]). ORDIX News 4/2008 27 Seminartermine - heraustrennbare Übersicht - Datenbanken Datenbank-Hochverfügbarkeitslösungen für Entscheider Datenbank-Modellierung Oracle SQL Oracle SQL für Umsteiger Oracle SQL für Experten Oracle Datenbankprogrammierung mit PL/SQL Grundlagen Oracle Datenbankprogrammierung mit PL/SQL Aufbau Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Aufbau Oracle Backup und Recovery Oracle Tuning und Monitoring Oracle Troubleshooting Workshop Oracle Real Application Cluster (RAC) Oracle 11g Neuheiten Oracle Security Oracle Data Guard Oracle RMAN Oracle Grid Control Oracle Streams Advanced Queuing Oracle Replikation IBM Informix SQL IBM Informix Dynamic Server Administration IBM Informix Dynamic Server Tuning und Monitoring IBM Informix Dynamic Server Backup und Recovery IBM Informix Dynamic Server 11 Neuheiten IBM Informix Dynamic Server Hochverfügbarkeits-Technologien unter Unix IBM DB2 für Linux/Unix/Windows SQL Grundlagen IBM DB2 für Linux/Unix/Windows Administration IBM DB2 für Linux/Unix/Windows Monitoring, Tuning und Hochverfügbarkeit MySQL Administration Microsoft SQL Server Administration Microsoft SQL Server Hochverfügbarkeits-Workshop Programmierung PHP Programmierung Grundlagen PHP Programmierung Aufbau Perl Programmierung Grundlagen Perl Programmierung Aufbau Shell, Awk und Sed Awk Intensiv-Workshop Einführung in XML XML Programmierung unter Java mit DOM und SAX Oracle und XML Java-JEE Einführung in die objektorientierte Programmierung Java Programmierung Grundlagen Java Programmierung Aufbau Java GUI Entwicklung mit Swing JEE für Entscheider Einführung in JEE JSP und Servlet Programmierung EJB Programmierung Web-Anwendungen mit JavaServer Faces (JSF) Entwickeln mit dem Spring-Framework Java Web Services Hibernate und die Java Persistence API Java Performance Tuning Web- und Applikations-Server Apache Web-Server Installation und Administration Tomcat Konfiguration und Administration WebSphere Application Server Installation und Administration Administration und Konfiguration für JBoss Betriebssysteme Unix/Linux Grundlagen für Einsteiger Linux Systemadministration Networking für Unix-Systemadministratoren Server-Virtualisierung mit XEN Linux Hochverfügbarkeits-Cluster OpenLDAP - Praxiseinsatz im Netzwerk Solaris Systemadministration Grundlagen Solaris Systemadministration Aufbau Solaris kompakt für erfahrene Unix-Administratoren Solaris 10 für erfahrene Systemadministratoren Solaris Containers Zettabyte Filesystem (ZFS) Workshop AIX Systemadministration Grundlagen IPv6 für Entscheider IPv6 für Systemadministratoren Systemmanagement Systemüberwachung mit Nagios Grundlagen Systemüberwachung mit Nagios Aufbau Projektmanagement IT-Projektmanagement IT-Controlling Grundlagen IT-Projektcontrolling in der Praxis Wiesbaden 550,00 890,00 1890,00 890,00 1290,00 1890,00 1890,00 1990,00 1990,00 1990,00 1990,00 1990,00 1990,00 1990,00 1290,00 1590,00 1590,00 1290,00 1290,00 1290,00 1790,00 1990,00 1990,00 1290,00 590,00 1590,00 1890,00 1990,00 1290,00 1190,00 1890,00 790,00 1690,00 1190,00 1690,00 1690,00 1690,00 1190,00 1190,00 890,00 1190,00 1190,00 1690,00 1690,00 1690,00 590,00 1290,00 1590,00 1590,00 1590,00 1190,00 1190,00 1690,00 1290,00 1190,00 1190,00 1390,00 1190,00 1690,00 1690,00 1690,00 1190,00 1290,00 1490,00 1990,00 1990,00 1990,00 1990,00 1290,00 890,00 1990,00 590,00 1190,00 1190,00 890,00 1990,00 1290,00 1290,00 *) Preise pro Seminar pro Teilnehmer in Euro. Alle Preise gelten zzgl. ges. MwSt. **) Inhousepreise auf Anfrage. Für Informationen und Fragen zu individuell zugeschnittenen Seminaren, Ausbildungsreihen oder Inhouse-Schulungen stehen wir jederzeit gerne zur Verfügung. Auf Wunsch senden wir Ihnen auch unser komplettes Seminarprogramm zu. 28 ORDIX News 4/2008 KW 17 KW 16 KW 15 KW 14 April KW 13 KW 12 KW 11 KW 10 März KW 9 KW 8 KW 7 KW 6 Februar KW 5 KW 4 KW 3 Januar KW 2 Preis in EURO*)**) http://training.ordix.de Online-Anmeldung und stets aktuelle Seminarinhalte und Termine! KW 33 KW 32 KW 31 Aug. KW 30 KW 29 KW 28 KW 27 Juli KW 26 KW 25 KW 24 KW 23 Juni KW 22 KW 21 KW 20 KW 19 KW 18 Mai Januar - August 2009 Preis in EURO*)**) 550,00 890,00 1890,00 890,00 1290,00 1890,00 1890,00 1990,00 1990,00 1990,00 1990,00 1990,00 1990,00 1990,00 1290,00 1590,00 1590,00 1290,00 1290,00 1290,00 1790,00 1990,00 1990,00 1290,00 590,00 1590,00 1890,00 1990,00 1290,00 1190,00 1890,00 790,00 1690,00 1190,00 1690,00 1690,00 1690,00 1190,00 1190,00 890,00 1190,00 1190,00 1690,00 1690,00 1690,00 590,00 1290,00 1590,00 1590,00 1590,00 1190,00 1190,00 1690,00 1290,00 1190,00 1190,00 1390,00 1190,00 1690,00 1690,00 1690,00 1190,00 1290,00 1490,00 1990,00 1990,00 1990,00 1990,00 1290,00 890,00 1990,00 590,00 1190,00 1190,00 890,00 1990,00 1290,00 1290,00 Datenbanken Datenbank-Hochverfügbarkeitslösungen für Entscheider Datenbank-Modellierung Oracle SQL Oracle SQL für Umsteiger Oracle SQL für Experten Oracle Datenbankprogrammierung mit PL/SQL Grundlagen Oracle Datenbankprogrammierung mit PL/SQL Aufbau Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Aufbau Oracle Backup und Recovery Oracle Tuning und Monitoring Oracle Troubleshooting Workshop Oracle Real Application Cluster (RAC) Oracle 11g Neuheiten Oracle Security Oracle Data Guard Oracle RMAN Oracle Grid Control Oracle Streams Advanced Queuing Oracle Replikation IBM Informix SQL IBM Informix Dynamic Server Administration IBM Informix Dynamic Server Tuning und Monitoring IBM Informix Dynamic Server Backup und Recovery IBM Informix Dynamic Server 11 Neuheiten IBM Informix Dynamic Server Hochverfügbarkeits-Technologien unter Unix IBM DB2 für Linux/Unix/Windows SQL Grundlagen IBM DB2 für Linux/Unix/Windows Administration IBM DB2 für Linux/Unix/Windows Monitoring, Tuning und Hochverfügbarkeit MySQL Administration Microsoft SQL Server Administration Microsoft SQL Server Hochverfügbarkeits-Workshop Programmierung PHP Programmierung Grundlagen PHP Programmierung Aufbau Perl Programmierung Grundlagen Perl Programmierung Aufbau Shell, Awk und Sed Awk Intensiv-Workshop Einführung in XML XML Programmierung unter Java mit DOM und SAX Oracle und XML Java-JEE Einführung in die objektorientierte Programmierung Java Programmierung Grundlagen Java Programmierung Aufbau Java GUI Entwicklung mit Swing JEE für Entscheider Einführung in JEE JSP und Servlet Programmierung EJB Programmierung Web-Anwendungen mit JavaServer Faces (JSF) Entwickeln mit dem Spring-Framework Java Web Services Hibernate und die Java Persistence API Java Performance Tuning Web- und Applikations-Server Apache Web-Server Installation und Administration Tomcat Konfiguration und Administration WebSphere Application Server Installation und Administration Administration und Konfiguration für JBoss Betriebssysteme Unix/Linux Grundlagen für Einsteiger Linux Systemadministration Networking für Unix-Systemadministratoren Server-Virtualisierung mit XEN Linux Hochverfügbarkeits-Cluster OpenLDAP - Praxiseinsatz im Netzwerk Solaris Systemadministration Grundlagen Solaris Systemadministration Aufbau Solaris kompakt für erfahrene Unix-Administratoren Solaris 10 für erfahrene Systemadministratoren Solaris Containers Zettabyte Filesystem (ZFS) Workshop AIX Systemadministration Grundlagen IPv6 für Entscheider IPv6 für Systemadministratoren Systemmanagement Systemüberwachung mit Nagios Grundlagen Systemüberwachung mit Nagios Aufbau Projektmanagement IT-Projektmanagement IT-Controlling Grundlagen IT-Projektcontrolling in der Praxis Informationen und Anmeldung: ORDIX AG Westernmauer 12 - 16 33098 Paderborn Tel.: 05251 1063-0 ORDIX AG Kreuzberger Ring 13 65205 Wiesbaden Tel.: 0611 77840-00 zentrales Fax: bzw. E-Mail: Online-Anmeldung: 0180 1 ORDIX 0 0180 1 67349 0 [email protected] http://training.ordix.de ORDIX News 4/2008 29 Datenbanken Oracle Enterprise Manager Grid Control (Teil V): Die Wartungsfunktion imp/exp in Grid Control Dieser Artikel wendet sich an Datenbankadministratoren, die mehrere Oracle Datenbanken über eine zentrale Schnittstelle warten wollen. Nachdem der Teil 4 dieser Reihe [1] sich eingehend mit den Möglichkeiten der Admi­ nis­tration unter Verwendung des Oracle Enterprise Managers Grid Control auseinandergesetzt hat, sollen in dieser Ausgabe die Funktionen zur Wartung von Oracle Datenbanken im Enterprise Manager beleuchtet werden. Den Schwerpunkt legen wir hierbei auf die Funktionen zum Im- und Export von Daten. Übersicht Um zur Wartungsseite für Oracle Datenbanken im EM Grid Control zu gelangen, muss zunächst unter „Ziele Datenbanken“ die gewünschte Zieldatenbank ausgewählt werden. Nachdem man so auf die Übersichtsseite (im EM als Standardverzeichnis bezeichnet) des Zielsystems gelangt ist, findet sich neben den Reitern „Standardverzeichnis“, „Performance“ und „Administration“ auch die „Wartung“. Die Wartungsseite des EM Grid Control (siehe Abbildung 1) gliedert sich auf den ersten Blick in die drei Bereiche • • • High Availability Verschieben von Daten Software-Deployments Alle drei Bereiche haben jeweils eine Reihe von Unterpunkten. High Availability 30 ORDIX News 4/2008 Kunden steuern die Backups fast ausschließlich über die zentralen Backup Tools, wie TSM, Networker, Data Protector etc. Die­se Vorgehensweise halten wir in größeren Umgebungen auch für absolut richtig. Lediglich in kleineren Umgebungen, in denen ohne zentrales Werkzeug gearbeitet wird, kann über das Aufsetzen eines Backup über EM Grid Control nachgedacht werden. Software Deployment Die Funktionen für Software Deployment unterstützen den Administrator beim Vergleich von Konfigurationen verschiedener Zielsys­ teme und beim Einspielen von DatenbankPatches. Alle hier angebotenen Funktionen finden sich allerdings auch unter dem übergeordneten Menüpunkt „Deployments“ wieder. Dieser Menüpunkt wird Thema eines eigenen Artikels dieser Serie sein. Aus diesem Grund werden wir an dieser Stelle den Bereich „Software Deployment“ nicht weiter betrachten. Hinter High Availability verbergen sich im Wesentlichen Funktionen zum Erzeugen und Einspielen eines Backup per RMAN und Oracle Secure Backup, aber auch ein Assistent zur Einrichtung und Verwaltung von Standby-Datenbanken mit Data Guard. Verschieben von Daten Diese Funktionalitäten werden in der Praxis über Grid Control nicht häufig genutzt. Unsere Die unter diesem Punkt vorhandenen Optionen ermöglichen das Importieren und Exportieren Da der Themenbereich „Verschieben von Daten“ den Schwerpunkt dieses Artikels bildet, werden wir im Folgenden detailliert auf die unterschiedlichen Optionen eingehen. Datenbanken von Daten aus der bzw. in die ausgewählte Zieldatenbank. Dabei können unterschiedliche Techniken wie SQL*Loader, Data Pump, Import/Export, Transportable Tablespaces, Oracle Streams, oder das Klonen von ganzen Datenbanken mittels RMAN zum Einsatz kommen. Versionsabhängigkeit Da nicht alle diese Techniken auf jedem Zielsystem verfügbar sind, kann die Anzahl der an dieser Stelle angebotenen Optionen bzw. deren Funktionsumfang mit dem Versionsstand der angesprochenen Zieldatenbank schwanken. So wurde zum Beispiel Data Pump erst mit Oracle 10g eingeführt. Die Funktion „aus Datenbank importieren“, die Daten mittels Data Pump über einen Datenbank-Link zwischen zwei Systemen kopiert, kann auf einer Zieldatenbank der Version 9i nicht funktionieren und wird daher im EM Grid Control bei einer Datenbank in der Verion 9 auch nicht angeboten. In den folgenden Beschreibungen gehen wir daher von einer Zieldatenbank in der Version 10g oder höher aus. Export in Dateien Abb. 1: Die Wartungsseite des EM Grid Control mit den drei Bereichen „High Availability“, „Verschieben von Daten“ und „Software-Deployments“. Die Funktion „In Exportdateien exportieren“ ermöglicht es, die Daten einer Datenbank in Dateien zu schreiben, um diese zu archivieren oder in einer anderen Datenbank weiterzuverwenden. Dies geschieht mit Hilfe von Data Pump. Wie bei einem manuellen Aufruf von Data Pump kann auch hier zwischen den Exportmodi full, schema, table und tablespace gewählt werden. Der Modus transportable steht an dieser Stelle nicht zur Auswahl, da die Erzeugung von transportablen Tablespaces im EM in einen eigenen Menüpunkt auf der Wartungsseite ausgelagert wurde. Je nachdem, welchen Modus man ausgewählt hat, können in weiteren Schritten die zu exportierenden Objekte gewählt werden, die maximale Anzahl von Threads für den ExportJob sowie gegebenenfalls der Pfad für die Logdatei gesetzt werden. Nachdem das Zielverzeichnis für den Export bestimmt wurde, kann der soeben erstellte Export-Job entweder sofort gestartet oder als Job für einen späteren Zeitpunkt geplant werden. Import aus Dateien Der Link „Aus Exportdateien importieren“ führt zu der zum eben beschriebenen Export Abb. 2: Import-Jobs können sofort oder per dbms_scheduler zu einem späteren Zeitpunkt ausgeführt werden. ORDIX News 4/2008 31 Datenbanken passenden Importfunktion. Auch hier kann im ersten Schritt der Umfang des Imports bestimmt werden. Zur Auswahl stehen die Modi „ganze Dateien“, „Schemas“, „Tabellen“ und „Tablespace“. Nachdem der Nutzer sich für einen Modus entschieden und die zu lesende Exportdatei angegeben hat, wird diese zunächst gelesen und analysiert. hinzugefügt werden und in welchen Tablespace sie geschrieben werden sollen. Wie beim Export kann auch der erstellte ImportJob entweder sofort oder später per Job ausgeführt werden. Anschließend besteht in Abhängigkeit vom zuvor gewählten Importmodus die Möglichkeit, auszuwählen, welche Objekte aus der angegebenen Datei importiert werden sollen. Im Modus „Schema“ kann der Anwender wählen, ob er die gewünschten Schemata direkt in die Datenbank importieren möchte, oder ob die Objekte eines zu importierenden Schemas in ein bereits bestehendes Schema der Datenbank eingefügt werden sollen. Beim direkten Import muss darauf geachtet werden, dass in der Datenbank bisher kein gleichnamiges Schema vorhanden ist, da ansonsten eine Fehlermeldung erfolgt. Der Unterschied zwischen den beiden Funktionen „Import aus Dateien“ und „Import aus einer Datenbank“ besteht darin, dass die Daten beim Import aus einer Datenbank nicht in einer Datei zwischen zwei Systemen transferiert werden, sondern über einen DatenbankLink direkt aus der Quelldatenbank gelesen werden. Hierzu kann ein bestehender Datenbank-Link verwendet oder direkt aus dem Auswahlprozess heraus ein neuer Link erstellt werden. Als Technologie für den Transfer kommt auch hier Data Pump zum Einsatz. Daher sind die Auswahlmöglichkeiten für den Anwender prinzipiell die gleichen wie bei dem bereits beschriebenen Import aus Dateien (sie­he Abbildung 2). Ähnlich verhält es sich im Modus „Tabellen“. Auch hier kann man entscheiden, welchem Zielschema in der Datenbank die Tabellen Import per Datenbank-Link SQL*Loader Neben dem Import über die eigenen Exportformate von Oracle darf an dieser Stelle natürlich auch nicht eine Importmöglichkeit z. B. für csv-Dateien fehlen. Diese verbirgt sich hinter dem Link „Daten aus Benutzerdateien laden“. Der erste Schritt beim csv-Import besteht darin, zu wählen, ob die Daten mit Hilfe einer bestehenden Kontrolldatei geladen werden sollen oder ob die benötigte Kontrolldatei vom EM erzeugt werden soll. Entscheidet man sich für eine bestehende Datei, so ist als nächstes der Pfad dorthin anzugeben und zu bestimmen, ob die Datendatei durch die Kontrolldatei bestimmt oder explizit angegeben werden soll. Überlässt man die Erstellung der Kontrolldatei dem EM, so muss zunächst der Pfad zur Datendatei angegeben werden. Diese kann entweder auf dem Datenbankserver oder auf dem Rechner des Anwenders, von dem aus Grid Control bedient wird, liegen. Ziel des Imports kann sowohl eine bestehende als auch eine per Assistent neu zu erstellende Tabelle sein. Abb. 3: Erstellung einer Kontrolldatei für dem Import von csv-Dateien mit Hilfe des EM Grid Control. 32 ORDIX News 4/2008 Für die Erstellung der Kontrolldatei zeigt der EM eine Beschreibung der Zieltabelle und eine Vorschau auf die befüllte Tabelle. Nun kann der Anwender unter anderem festlegen, welche Spalten der Tabelle zu befüllen sind, Datenbanken durch welches Zeichen die Daten in der csvDatei getrennt sind und ob Spalten mit einem Default-Wert gefüllt werden sollen, falls in der Datei kein passender Datensatz vorhanden ist. Durch einen Klick auf „Dateiformatattribute anwenden“ kann jederzeit überprüft werden, wie sich die vorgenommenen Änderungen auf den Ladevorgang auswirken, da mit jedem Klick die Vorschau auf die befüllte Zieltabelle aktualisiert wird (siehe Abbildung 3). Als Lademethoden stehen „conventional path“, „direct path“ und „parallel direct path“ zur Verfügung. Die Einschränkungen der beiden letztgenannten Methoden werden auf der Seite erklärt, so dass der Anwender sich gezielt entscheiden kann. Abschließend können Optionen, wie das Überspringen von anfänglichen Zeilen oder ein Jobabbruch nach einer bestimmten Anzahl von Fehlern, festgelegt werden. Turbo für große Objekte Für den Fall, dass nicht nur einzelne Datenbankobjekte, sondern ganze Tablespaces oder gar komplette Datenbanken repliziert werden sollen, bietet der EM zwei Alternativen zu den bereits beschriebenen Methoden, die bei großen Datenmengen deutliche Zeitgewinne versprechen: • • Transportable Tablespaces Soll ein einzelner Tablespace kopiert werden, ermöglicht Grid Control dies über die Verwendung von transportablen Tablespaces. Dazu wird der betroffene Tablespace zunächst in den schreibgeschützten Modus versetzt. Anschließend werden die Metadaten des Tablespaces aus dem Data Dictionary in eine Datei geschrieben und die Datendateien des Tablespaces per Data Pump mit der Option „transportable tablespace“ kopiert. Danach kann der originale Tablespace wieder für Schreibvorgänge geöffnet werden. Klone erstellen Klone ganzer Datenbanken mittels RMAN können mit dem Assistenten „Datenbank clonen“ erstellt werden. Dieser führt automatisiert folgende Schritte aus: 1. Kopieren der Datenbankdateien mittels RMAN 2. Übertragen der Dateien auf das Zielsystem 3. Wiederherstellen des Klons mittels gespeicherter Archivelogs 4. Öffnen des Klons mit der Option Resetlogs Glossar Oracle EM Grid Control Oracle Enterprise Manager Grid Control. Nachfolger des Oracle Management Server mit erweitertem Funktionsumfang. Ermöglicht über Plug-In auch das Monitoring und die Administration von Produkten anderer Hersteller. Oracle Streams Funktionalitäten, mit denen Daten zwischen Datenbanken verteilt werden können. RMAN Recovery Das Werkzeug von Oracle zur Sicherung und Wiederherstellung von Manager Datenbanken (Backup, Restore, Recovery und Konvertierung). Transportable Tablespace Ein Verfahren, um sehr einfach und schnell Tablespaces von einer Oracle Datenbank in eine andere zu übertragen. Links ►► [1] Oracle EM Grid Control (Teil IV): Datenbankadministration mit Grid Control: http://www.ordix.de/ORDIXNews/3_2008/Datenbanken/DB_Administration_ Grid_Control.html ►► [2] Oracle Enterprise Manager Grid Control (Teil III): SQL Tuning mit Grid Control: http://www.ordix.de/ORDIXNews/2_2008/Datenbanken/wib_grid_t3.html ►► [3] Oracle Enterprise Manager Grid Control (Teil II): Installation und Konfiguration: http://www.ordix.de/ORDIXNews/4_2007/Datenbanken/Grid_Control_teil2.html ►► [4] ORDIX News Artikel „Überblick über Oracle Grid Control“: http://www.ordix.de/ORDIXNews/2_2007/Datenbanken/oracle_grid_control.html ►► [5] Seminarempfehlung „Oracle Grid Control“: http://training.ordix.de/seminar.php?nr=552 ►► [6] Informationen zum EM Grid Control von Oracle: http://www.oracle.com/enterprise_manager/index.html ►► [7] Dokumentation zum EM Grid Control: http://www.oracle.com/technology/documentation/oem.html Streams Auch die Replikation von Daten zwischen zwei Systemen mittels Streams Replication und Advanced Queuing wird von EM Grid Control unterstützt. Dieses Thema wird hier aber aufgrund seines Umfangs nicht weiter behandelt. Fazit Der Enterprise Manager Grid Control bietet eine Menge von Optionen für den Import und Export von Daten aus einer bzw. in eine Oracle Datenbank. Die Assistenten für diese Funktionalitäten wirken übersichtlich und durchdacht. Sie vereinfachen dem Adminis­ trator die Arbeit im Vergleich zur Kommandozeile an vielen Stellen. Roman Peters ([email protected]). ORDIX News 4/2008 33 IT-Strategie Reihe SOA (Teil II): SOA-Governance Braucht SOA eine neue Regierung? Dieser Artikel richtet sich an Entscheider, SoftwareArchitekten und Entwickler, die sich mit SOA vertraut machen wollen. Stellen Sie sich ein Fußballspiel ohne einen Schiedsrichter vor. Meinen Sie, es könnte funktionieren? Genau wie ein Fußballspiel ohne einen Schiedsrichter im Chaos enden würde, ist auch eine serviceorientierte Architektur (SOA) ohne SOA-Governance zum Scheitern verurteilt. Demzufolge ist eine Governance für SOA von entscheidender Bedeutung. Nachdem im Teil 1 dieser Reihe [1] die Grundlagen von SOA beleuchtet wurden, beschäftigt sich dieser Artikel mit der serviceorientierten Organisation. Wozu SOA-Governance? Wird eine SOA in einem Unternehmen ohne eine zentrale Steuerungseinheit eingeführt, so können sehr schnell redundante Implementierungen von Services mit geringer Wiederverwendung entstehen. Damit SOA in der Praxis nicht im Chaos endet, sollten schon am Anfang eines SOA-Vorhabens unter anderem folgende Fragen be- 34 ORDIX News 4/2008 antwortet und entsprechende Maßnahmen ergriffen werden: • • • Wie stelle ich einen neuen Service zur Verfügung? Wie können andere diesen Service finden? Welche Services gibt es im Unternehmen? Werden diese Fragen vernachlässigt, so ist das SOA-Projekt von vornherein zum Scheitern verurteilt. IT-Strategie Motivation Da in heutigen Unternehmen die IT meist vertikal, entsprechend der Geschäftsbereiche, organisiert ist, wird die Verantwortung der Unternehmensanwendungen ebenfalls vertikal an den Geschäftsbereichen ausgerichtet (siehe Abbildung 1). Warum sind Änderungen am Gesamtprozess sehr teuer? Applikation 1 Applikation 2 Applikation 3 1. Geschäftsprozess wird geändert GUI Prozess Die Grundidee der SOA, die am Geschäftsprozess ausgerichteten Services über verschiedene Bereiche hinweg mehrfach zu verwenden, steht somit konträr zur klassischen Verantwortung von IT-Anwendungen (siehe Abbildung 2). An dieser Stelle stellt sich die Frage, welche Interessen ein Geschäftsbereich an der Bereitstellung von Services hat, die durch andere Bereiche genutzt werden können? Diese Frage lässt sich mit ausschließlichem Fokus auf einen Geschäftsbereich nicht beantworten. Da SOA insbesondere dann Mehrwert schafft, wenn bereichsübergreifende Unternehmens­ interessen verfolgt werden, ist ein zentrales Management der Services im Unternehmen unabdingbar. Funktionen (Dienste) Daten 2. Funktionalität wird doppelt implementiert 3. Daten werden (mehrmals) ausgetauscht Abb. 1: Säulen einer gewachsenen IT-Landschaft. GUI Prozess Was ist SOA-Governance? Mit dem Begriff SOA-Governance ist, vereinfacht gesagt, ein Steuerungsmechanismus gemeint, mit dem Rollen und Zuständigkeiten zur Regulierung und Kontrolle einer SOA festgelegt werden. Demzufolge kann SOA auch als ein Managementkonzept bezeichnet werden. Vergleicht man SOA-Governance mit der klassischen IT-Governance, so kann man sagen, dass SOA-Governance eine Spezialform bzw. eine Weiterentwicklung der IT-Governance darstellt. Deshalb verfolgt SOA-Governance dieselben Ziele wie eine IT-Governance - mit der Erweiterung um serviceorientierte Aspek­te. Abbildung 3 zeigt die Einordnung von SOA-Governance in eine unternehmensweite Governance-Hierarchie. Die wesentlichen Aufgaben einer SOA-Gover­ nance sind: • • • Service-Lifecycle-Management Service-Portfoliomanagement Service-Designprozess und Standards Funktionen (Dienste) Daten System A System B System C Abb. 2: SOA als Balken in der IT-Landschaft. Service-Lifecycle-Management Vergleicht man den Lebenszyklus einer herkömmlichen Anwendung mit einem ServiceLifecycle, so stellt man einen wesentlichen Unterschied fest: Im klassischen Fall handelt es sich in der Regel um eine Anwendung mit nur einem so genannten Software-Lebenszyklus. Bei einer SOA werden Services mit einer geringen Größe und Granularität zu einer Anwendung zusammengeschlossen. Dabei verfügen die Services dann auch jeweils über einen eigenen Software-Lebenszyklus (siehe Abbildungen 4 und 5). ORDIX News 4/2008 35 IT-Strategie Da die einzelnen Services in der Regel von mehreren Servicekonsumenten aufgerufen wer­den, wird oft die Anforderung nach einer Versionierung und dem parallelen Betrieb von mehreren Serviceversionen gestellt. Auch die­ se Anforderung stellt einen Unterschied zum Lebenszyklus klassischer Anwendungen dar, wo in der Regel immer nur eine Version der Anwendung im Betrieb ist. Service-Portfoliomanagement Mit Service-Portfoliomanagement ist eine struk­turierte Verwaltung der Meta-Informatio­ Corporate Governance Technologie-Governance nen (Servicebeschreibung) der einzelnen Services in einer so genannten Service-Registry/ Repository gemeint. Dabei werden auch die Abhängigkeiten der Services untereinander gepflegt. Das Ziel ist hierbei eine zentrale Erfassung und Veröffentlichung von Services, damit die­ se anschließend von Service-Konsumenten gefunden und genutzt werden können. Service-Designprozess und Standards Eine weitere, wesentliche Aufgabe von SOAGovernance ist das Festlegen von Designprozessen und -standards für Services. Nur mit einem eindeutig definierten Designprozess für Services kann ein reibungsloser Verlauf bei der Entwicklung ermöglicht werden. Zusätzlich müssen bereits in den ersten Phasen bei der Einführung von SOA so genannte Service-Designstandards und Technologiestandards eingeführt werden. IT-Governance SOA-Governance Rollen in einer SOA Da SOA in einem Unternehmen nicht nur definiert sondern auch aktiv gelebt werden muss, müssen zwingend einige neue Rollen definiert werden. Eine Rolle ist dabei nicht mit einer Stelle gleichzusetzen. Die Ausgestaltung eines Rollenmodells ist in der Regel sehr unternehmensspezifisch. Die in einem Unternehmen bereits vorhandenen Rollen sollten dabei unbedingt berücksichtigt werden. Abb. 3: Governance-Hierarchie. Application-Lifecycle Service-Lifecycle Zu einem SOA-Rollenmodell gehören unter anderen folgende Rollen: • • • • • SOA-Governance Application Service 1 Service 2 Abb. 4: Unterschied zwischen dem Lebenszyklus klassischer Anwendungen und dem von Services. 36 ORDIX News 4/2008 Domänenverantwortlicher SOA-Architekt Geschäftsprozess-Designer Service-Modellierer Service-Entwickler Der Domänenverantworliche (Domain Owner) ist verantwortlich für eine oder mehrere Geschäftsdomänen. Unter einer Geschäftsdomäne ist hierbei eine logische Zusammenfassung fachlicher Services und Daten zu verstehen, die in einer engen Beziehung zueinander stehen. Das Besondere an dieser Rolle ist, dass diese einen großen Einfluss auf die strategische Weiterentwicklung der Domänen und eine enge Verbindung zu den Geschäftsebenen hat. IT-Strategie Bedarf Betrieb e D Die Aufgabe eines Geschäftsprozess-De­ signers besteht hauptsächlich in der konkreten modelltechnischen Umsetzung der von den SOA-Architekten vorgegebenen Geschäftsprozesse. Dabei werden die Prozesse durch eine geeignete Komposition atomarer Services realisiert. Schließlich ist der Service-Modellierer für die ausführliche Dokumentation der Dienstschnittstelle verantwortlich. Werden die Services z. B. mit Web-Services realisiert, so erstellt der Service-Modellierer die WSDL-Beschreibung (Web Services Description Languages). Anschließend wird der so modellierte Service durch den Service-Entwickler implementiert. Abb. 5: Service-Lifecycle-Management. Glossar SOAGovernance Als SOA-Governance (auch Service Governance genannt) werden die Aktivitäten, Entscheidungen, Rollen und Verantwortlichkeiten zur Regulierung und Kontrolle einer serviceorientierten Architektur (SOA) bezeichnet. Konflikte sollen dabei nicht vermieden werden, sondern durch standardisierte und akzeptierte Prozesse ausgetragen werden. Toolchain Toolchain bezeichnet eine Kette von Software-Werkzeugen, bei denen das Ergebnis (Output) von einem Werkzeug als Quelle (Input) für ein weiteres Werkzeug verwendet wird. Somit kann eine lückenlose Entwicklung von Software von der Design- bis zur Implementierungsphase ermöglicht werden. Domain Mit einer Domain (Domäne) ist die Kapselung von logisch zusammengehörenden Services in einer diskreten Einheit gemeint, die eine Schnittstelle zum Zugriff von Außen anbietet. Corporate Governance Mit diesem Begriff sind Methoden, Strukturen und Instrumente zur Leitung und Überwachung von Organisationen gemeint. Resümee Zusammenfassend kann gesagt werden, dass SOA-Governance eine grundlegende Voraussetzung zu einer langfristig erfolgreichen SOA darstellt. Dabei dürfen Herausforderungen auf der organisatorischen Ebene nicht unterschätzt werden. Durch die Verlagerung und Änderung von Verantwortlichkeiten in einem Unternehmen kann sehr schnell Konfliktpotenzial entstehen. Test Grundsätzlich kann gesagt werden, dass die Rolle des SOA-Architekten eine Schlüsselposition bei der Entwicklung neuer Services für eine SOA darstellt. En e ym plo nt SOA Governance Design Der technische SOA-Architekt dagegen hat primär einen technologischen Schwerpunkt. Zusätzlich modelliert der technische Architekt zusammen mit dem Geschäftsprozessdesigner die Geschäftsprozesse auf der technischen Ebene unter Berücksichtigung der Vorgaben des fachlichen SOA-Architekten. n e & tio ys ifika A Idenal nt Außerbetriebnahme g lun ick tw Die Rolle eines SOA-Architekten wird in der Regel in technische und fachliche Aspekte aufgeteilt. Der so genannte fachliche SOAArchitekt führt in der Regel die Anforderungsanalyse durch und hat eher einen fachlichen Fokus. IT-Governance IT-Governance liegt in der Verantwortung des Managements und ist ein wesentlicher Bestandteil der Unternehmensführung. IT-Governance stellt Methoden, Strukturen und Instrumente bereit, mit denen gewährleistet wird, dass die IT die Unternehmensstrategie und -ziele unterstützt. Eine erfolgreiche SOA-Governance muss alle Artefakte des SOA-Lebenszyklus nicht nur umfassen, sondern diese im wahrsten Sinne des Wortes regieren. Links ►► [1] ORDIX News Artikel „Was ist SOA?“: http://www.ordix.de/ORDIXNews/3_2008/IT-Strategie/Ueberblick_SOA.html ►► [2] Seminarempfehlung „Java Web Services“: http://training.ordix.de/seminar.php?nr=266 Markus Fiegler ([email protected]). ORDIX News 4/2008 37 Datenbanken Oracle Database 11g Release 1 (Teil V): Neuerungen Data Pump in Oracle 11g Der Artikel richtet sich an Datenbankadministratoren und -entwickler, die Daten in die Datenbank exportieren bzw. importieren wollen. In Oracle 10g wurde Data Pump als Nachfolger für die Tools Export/Import eingeführt. Mit Oracle 11g wurden neue Funktionen im Bereich Data Pump hinzugefügt, auf die im Folgenden näher eingegangen wird. Komprimierung von Dump File Sets Die von Data Pump erzeugten Datenfiles (Dumpfiles) können nun auch komprimiert werden. Dafür wird beim Export-Kommando expdp ein Parameter COMPRESSION angegeben. Dadurch kann man bestimmen, was man komprimieren möchte. Es gibt drei Möglichkeiten: 1. Nur die Metadaten (DDL-Statements) 2. Die Dateninhalte 3. Alle Export-Daten (Metadaten + Daten) Ein Dumpfile ohne Komprimierung zu erzeugen, ist natürlich auch weiterhin möglich und nach wie vor die Standardeinstellung. Die Art der Komprimierung ist mit dem gzip-Algorithmus vergleichbar. Dadurch ist die Stärke der erreichten Komprimierung, wie bei anderen Komprimierungsalgorithmen auch, stark von den Dateninhalten und Datentypen abhängig. Die Komprimierungsalgorithmen gehen bei der Komprimierung so vor, dass Zeichenfolgen, die mehrfach vorkommen, ersetzt werden. Somit werden Daten, in denen gleiche Zeichenfolgen enthalten sind, stärker komprimiert, als Daten, in denen das nicht der Fall ist. Um Data Pump Files komprimieren zu können, wird eine Lizenzierung der Option Advanced Compression benötigt. Data Pump Encryption Auch wenn die von Data Pump erzeugten Dumpfiles nur von Data Pump verarbeitet werden können, sind sie noch lange nicht sicher. In 38 ORDIX News 4/2008 Oracle 10g war es bereits möglich, verschlüsselte Spalten auch als solche zu exportieren bzw. zu importieren. Damit die Daten nun auch vollständig gesichert im Dateisystem abgelegt werden, können nun die kompletten Dumpfiles verschlüsselt werden. Dabei lässt sich die Verschlüsselung wahlweise nur für den Dateninhalt, nur für die Metadaten oder für das gesamte Dumpfile aktivieren. Die Verschlüsselung kann entweder durch ein Passwort, über ein Datenbank-Wallet (Advanced Security Option) oder beides in Kombination erfolgen. Durch die eingesetzte Verschlüsselung oder auch durch die Kompression kann eine höhere CPU-Last auftreten. Auf CPU-schwachen Sys­ temen können sich dadurch längere Exportzeiten ergeben. Data Pump Data Remapping Mit Hilfe von Data Remap ist man nun in der Lage, Daten während des Ex- oder Imports zu verändern. Interessant ist, dass z. B. Produktionsdaten, die für eine Testumgebung genutzt werden, anonym bleiben müssen. Dies kann über den Parameter REMAP_DATA bei expdp oder impdp erreicht werden. Um Remap nutzen zu können, müssen bestimmte Voraussetzungen erfüllt werden. Als erstes benötigt man eine PL/SQL-Funktion für die Spalte, die gemappt werden soll. Dieser wird der aktuelle Wert der Spalte übergeben, als Rückgabe erhält man einen neuen Wert. Damit das ohne Probleme funktionieren kann, müssen sowohl Eingabe- als auch Ausgabewerte der zu anonymisierenden Spalte vom Datenbanken gleichen Datentyp sein. Abbildung 1 zeigt ein Beispiel für die Anonymisierung von Daten. Gegeben ist eine Tabelle mit drei Spalten. Die erste Spalte enthält den Namen, die zweite eine Kreditkartennummer und die dritte einen Betrag, über den die Kreditkarteninhaber verfügen können. Nun wird ein Package erstellt, in dem eine Funktion enthalten ist. Dieser Funktion wird die Kreditkartennummer aus unserer Tabelle übergeben. Innerhalb der Funktion wird das Paket dbms_random genutzt, um aus der übergebenen Kreditkartennummer eine neue Zufallszahl zu generieren, die als neue Kreditkartennummer fungiert. Damit der Spalte Kreditkartennummer auch die Funktion zugeordnet werden kann, wird die in Abbildung 2 dargestellte Syntax benötigt. Name Kreditkartennr Betrag Müller 12345678 2000 Meier 99997777 5000 Schulze 56567878 3000 v_nummer:=12345678 Funktion aendere_Kreitkartennummer v_neu:=dbms_random.random(v_nummer); return v_neu; v_neu:=16162727 Name Kreditkartennr Betrag Müller 16162727 2000 Meier 90908080 5000 Schulze 43218765 3000 Somit wird beim Export der Daten in unserer Tabelle pro Datensatz eine neue Kreditkarten­ nummer generiert. Abb. 1: Anonymisierung von Daten. Export/Import von AQ-Tabellen mit Data Pump remap_data=<schema>.<tabelle>.<spalte>:<schema>.<package>.<function> Eine Queue-Tabelle ist eine Warteschlange, in der Nachrichten vom System abgelegt werden. Jede Zeile dieser Tabelle repräsentiert eine Nachricht. Queue-Tabellen werden dazu genutzt, um Nachrichten zwischen Applikatio­ nen auszutauschen. Mit Oracle 11g wird der Export einzelner Queue-Tabellen vollständig unterstützt. Dies hat den Vorteil, dass nur noch die Queue-Tabelle als exportierendes Objekt angegeben werden muss. Alle zugehörigen Objekte wie Indexe, Tabellen usw. werden nun automatisch mit ex- oder importiert. Um Queues zu exportieren und zu importieren, war es in Oracle 10g noch notwendig, ein Full Database Backup durchzuführen. Eine Übertragung nur einer ausgewählten Queue-Tabelle und somit ausgewählter Queues war nicht möglich bzw. wurde von Oracle nicht unterstützt. Folgende Export-Modi werden nun unterstützt: • • REPLACE: Eine vorhandene Queue-Tabelle wird gelöscht und durch die importierte ersetzt. SKIP: Eine vorhandene Queue-Tabelle wird nicht importiert. Truncate und Append werden dabei als Export-Modi nicht unterstützt. Abb. 2: Syntax für die Zuordnung der Funktion zur Spalte Kreditkartennummer. Glossar Data Pump Werkzeug zum Extrahieren und Importieren von Strukturen und Daten einer Oracle Datenbank ab der Version Oracle Database 10g. Queue-Tabelle Eine Warteschlange, in der Nachrichten vom Datenbanksystem abgelegt werden. Link ►► [1] Oracle 11g Dokumentation: http://www.oracle.com/pls/db111/homepage Fazit Durch die Neuerungen in 11g wurden die Möglichkeiten zum Im- und Export mit Data Pump weiter ausgebaut. Die Sicherheit im Umgang mit Daten wurde verbessert. Auch wurde durch die neuen Funktionen der Arbeitsaufwand verringert, da nun einige Aktionen automatisch mit ausgeführt werden. Alles in allem sind dies Neuerungen, die sicher schnell von „Oraclern“ angenommen werden. David Bottländer ([email protected]). ORDIX News 4/2008 39 Open Source System-Logging unter Linux und Unix – syslog-ng (Teil II): Zentrale Speicherung von Logfiles ... aber bitte verschlüsselt! Im ersten Teil dieser Reihe sind wir auf die grundlegende Konfiguration von syslog-ng eingegangen. Dieser Artikel knüpft an dieser Stelle an und erläutert unter anderem die Vorteile und Risiken der zentralen Speicherung von Logfiles. Hierdurch wird es z. B. möglich, Auswertungen über die Vorkommnisse auf allen Hosts durchzuführen und Dieser Artikel richtet sich an Systemadministratoren, die ihre Log-Meldungen zentral speichern und verschlüsselt übertragen wollen. gegebenenfalls Schwachstellen leichter zu erkennen, um sie dann auszumerzen. Da die Meldungen aber standardmäßig unverschlüsselt über das Netzwerk übertragen werden, sollte zumindest über die Möglichkeiten einer Verschlüsselung der unter Umständen sensiblen Daten nachgedacht werden. Eine Frage des Protokolls Syslog-ng bietet im Gegensatz zum alten Syslog die Möglichkeit, die Daten auch mittels TCP über das Netzwerk zu übertragen. Bevor man sich also über die Verschlüsselung der Daten Gedanken macht, ist es notwendig, die Frage nach dem richtigen Protokoll zu klären. TCP arbeitet verbindungsorientiert und garantiert, dass die Pakete in der richtigen Reihenfolge ankommen. Dies prädestiniert es für den Einsatz als Übertragungsprotokoll für LogMeldungen. Es sollte jedoch nicht unterschlagen werden, dass nicht wie bei UDP ein Port für Syslog reserviert ist. Die Firma BalaBit, die syslog-ng entwickelt hat, schlägt in ihrer Dokumentation wie schon bei UDP die Nutzung von Port 514 vor. Dieser ist aber eigentlich für rsh bzw. rcp reserviert. Man sollte sich vorher sicher sein, dass man diese Dienste nicht mehr benötigt. Falls dies der Fall ist, ist TCP die erste Wahl. Die Zentrale Damit syslog-ng Meldungen empfangen kann, ist die Konfiguration des Daemons, so wie in ORDIX News 4/2008 43 Open Source Abbildung 1 gezeigt, auf der Serverseite notwendig. Wie im ersten Teil des Artikels [1] be­schrieben, muss ein Source-Objekt eingerichtet werden, über das die Meldungen empfangen werden können. source s_tcp { tcp(ip("192.168.1.20") port(514) max-connections(100)); }; Abb. 1: Konfiguration des Daemons (auf der Serverseite), um syslog-ng Meldungen zu empfangen. destination remote { tcp("192.168.1.20" port(514)); }; log { source(src); destination(remote); }; Auf dem Client muss eine Destination eingerichtet werden. Zusätzlich wird in einer LogAnweisung festgelegt, welche Meldungen an dieses neu eingerichtete Ziel geschickt werden sollen (siehe Abbildung 2). Client Server syslog-ng syslog-ng 5140 Stunnel gesicherte Verbindung über SSL 514 Abb. 3: Die Funktionsweise von Stunnel. client = yes cert = /etc/stunnel/syslog-ng-client.pem CAfile = /etc/stunnel/syslog-ng-server.pem verify = 3 [514] accept = 127.0.0.1:5140 connect = 192.168.1.20:514 Abb. 4: Die Konfiguration von Stunnel auf dem Client. 44 Standardmäßig existiert eine Beschränkung auf zehn Verbindungen gleichzeitig. Um Meldungen von mehr als zehn Clients empfangen zu können, muss dieser Wert erhöht werden. Es sollte aber darauf geachtet werden, dass man ihn nicht zu hoch einstellt, da der Server sonst unter Umständen anfällig gegen DoSAttacken wird. Die empfangenen Meldungen müssen nun nur noch gespeichert werden z. B. in Dateien. Der Client Abb. 2: Auszug aus der Client-Konfiguration. 5140 Dieses Objekt muss festlegen, dass der Server auf dem Interface mit der IP-Adresse 192.168.1.20 und dem Port 514 Meldungen empfangen soll. Stunnel Diese beiden Zeilen führen dazu, dass alle Meldungen aus dem Source-Objekt src an das neu definierte Ziel remote geschickt werden. Dies wäre schon ein Beispiel für eine einfache Konfiguration, die dafür sorgen würde, dass der Client seine Meldungen an den Server schickt und dieser sie auch empfangen kann. SSL-Verschlüsselung mittels Stunnel In der Open Source Edition bietet syslog-ng keine eigene Möglichkeit, die Meldungen, die über das Netzwerk übertragen werden, zu verschlüsseln. An dieser Stelle kommt Stunnel ins Spiel. Stunnel ist ein universeller SSL-Wrapper, der es ermöglicht, beliebige TCP-Verbindungen mit­tels SSL zu verschlüsseln. Dafür ist es notwendig, auf dem Client und auf dem Server einen Stunnel-Daemon zu starten, der die Meldungen auf dem Client entgegennimmt und an den Server weiterleitet. cert = /etc/stunnel/syslog-ng-server.pem CAfile = /etc/stunnel/syslog-ng-client.pem verify = 3 [514] accept = 192.168.1.20:514 connect = 127.0.0.1:5140 Damit die in den Abbildungen 2 und 3 eingerichtete Verbindung durch Stunnel verschlüsselt werden kann, ist nur ein geringer Konfigurationsaufwand notwendig. Abb. 5: Die Konfiguration von Stunnel auf dem Server. Die Ports auf den Systemen werden in unserem Beispiel, wie in Abbildung 3 beschrieben, kon- ORDIX News 4/2008 Konfiguration des Daemons Open Source figuriert. Dort ist auch die generelle Funktionsweise von Stunnel erläutert. Der Client schickt die Meldungen nicht, wie oben beschrieben, direkt an den Server, sondern erst an einen lokalen Port, auf dem Stunnel lauscht. Stunnel nimmt die Meldungen an und schickt sie an das in der /etc/stunnel/stunnel.conf angegebene Ziel. Auf dem Ziel muss auch ein Stunnel-Daemon lauschen, der das passende Zertifikat besitzt, die Nachrichten entschlüsselt und sie dann an den syslog-ng weiterreicht. Die Konfiguration des Clients bzw. des Servers kann in den Abbildungen 4 und 5 nachvollzogen werden. Glossar DoS-Attacke DoS steht für Denial of Service. Das Ziel einer DoS-Attacke ist es, einen oder mehrere Dienste auf einem Server arbeitsunfähig zu machen. In der Regel wird dies durch die Überlastung des Dienstes erreicht. Stunnel Stunnel ist ein universeller SSL-Wrapper für TCP-Verbindungen (POP, IMAP, LDAP etc). Das bedeutet, Stunnel stellt SSL-verschlüsselte Verbindung für beliebige TCP-Protokolle bereit, wenn diese selbst SSL nicht oder nur fehlerhaft beherrschen. Das Programm ist kein komplettes Projekt, sondern versteht sich als Teil zu einer erfolgreichen SSL-Verschlüsselung. Deshalb wird immer auch eine SSL-Bibliothek wie z. B. OpenSSL benötigt. Link Fazit ►► [1] ORDIX News Artikel „System-Logging unter Linux und Unix“: Die zentrale Speicherung von Log-Meldungen bietet viele Vorteile und ist ohne wesentlich höheren Konfigurationsaufwand realisierbar. Wenn man jedoch einen zentralen SyslogServer plant, muss man sich auch über die Risiken im Klaren sein. Alle Daten, die unverschlüsselt über das Netzwerk übertragen werden, können brisante Informationen enthalten. Auch wenn sie verschlüsselt zum Server übertragen wurden, muss dieser so http://www.ordix.de/ORDIXNews/3_2008/Open_Source/Syslog_ng.html abgesichert sein, dass die Meldungen vor unbefugten Zugriffen geschützt sind. Dies sollte aber nicht nur bei einem zentralen SyslogServer der Grundsatz sein. Marius Dorlöchter ([email protected]). Impressum Herausgeber: ORDIX AG Aktiengesellschaft für Software­ent­wick­lung, Beratung, Schulung und Systemintegration, Paderborn Redaktion: Sascia Brinkmann V.i.S.d.P.: Benedikt Georgi, Wolfgang Kögler Anschrift der Redaktion: ORDIX AG Westernmauer 12 - 16 33098 Paderborn Tel.: 05251 1063-0 Fax: 0180 1673490 Gestaltung/Layout: Sascia Brinkmann Auflage: 9.600 Druck: Druckerei Reike GmbH, Paderborn Bildnachweis: flickr.com © Son of Groucho; flickr.com © joka2000; flickr.com©FedericoFoschini;flickr.com©GaetanLee; photocase.de © Timo Gaik; photocase.de © hardedge Autoren dieser Ausgabe: David Bottländer, Holger Demuth, Andre Dirr, Marius Dorlöchter, Lars Eisenblatt, Christian Fertsch, Karsten Fiedler, Markus Fiegler, Stefanie Heither, Andreas Jordan, Matthias Jung, Wolfgang Kögler, Roger Niemeyer, Roman Peters, Klaus Reimers, Rainer Restat Copyright: ORDIX AG. Alle Rechte, auch die der Übersetzung, des Nachdrucks und der Vervielfältigung der Artikel oder von Teilen daraus, bleiben uns vorbehalten. Kein Teil der Artikel darf ohne unsere schriftliche Genehmigung in irgendeiner Form reproduziert, insbesondere unter Verwendung elektronischer Systeme verarbeitet, verbreitet, vervielfältigt oder zu öffentlichen Wiedergaben benutzt werden. Haftung: Eine Haftung für die Richtigkeit der Veröffentlichungen kann trotz sorgfältiger Prüfung durch die Redaktion vom Herausgeber nicht übernommen werden. Warenzeichen: Einige der aufgeführten Bezeichnungen sind eingetragene Warenzeichen ihrer jeweiligen Inhaber. ORDIX® ist registrierte Marke der ORDIX AG. Die Zeitschrift ORDIX News wird von der ORDIX AG an ausgewählte Kunden verteilt und kann für 2,20 Euro bestellt werden. Sie finden sowohl die neueste Ausgabe als auch ältere Ausgaben im Archiv der ORDIX News im Internet unter: http://www.ordix.de. Schauen Sie mal rein! Der Kontakt zu unseren Lesern ist uns sehr wichtig. Für An­re­gungen, Kritik und Anmerkungen zu den Themen, aber auch für interessante Ideen sind wir immer offen und dankbar. Wir freuen uns auf Ihr Feedback an [email protected]. ORDIX News 4/2008 45 Datenbanken DB2 HADR: Automatischer Failover mit TSA Der Artikel richtet sich an DB2-Administratoren, die durch den Einsatz von TSA den Failover bei HADR automatisieren wollen. DB2 beinhaltet das High Availability Disaster Recovery (HADR) schon seit der Version 8.2. Dabei wurde beim praktischen Einsatz immer bemängelt, dass es kein DB2-eigenes Verfahren für einen automatischen Failover von der primären Datenbank auf die Standby-Datenbank gab. Schon in den letzten Versionen bot IBM hierzu eine Verknüpfung mit dem IBM Tivoli System Automation (TSA) an. In der DB2 Version 9.5 ist TSA jetzt integriert und mit einem Konfigurationswerkzeug ausgestattet. Das Konzept von Tivoli System Automation Die meisten Cluster-Software Produkte arbei­ ten nach einem ähnlichen Prinzip. Tivoli System Automation bildet da keine Ausnahme. Auf jedem am Cluster beteiligten Rechner (Knoten) muss TSA installiert sein. In der Konfiguration wird vorgegeben, welche Knoten an dem Cluster beteiligt sind. Die von der TSA verwalte­ ten Ressourcen werden in so genannten Resource Groups zusammengefasst. Zusätzlich gibt es Skripte, mit denen die Ressourcen auf einem Knoten deaktiviert und auf einem anderen Knoten aktiviert werden können. Die TSA-Komponenten auf jedem Knoten prüfen regelmäßig über das Netzwerk, ob die anderen Knoten des Clusters noch vorhanden sind. Stellt ein Knoten dabei fest, dass der andere Knoten ausgefallen ist, führt er die Skripte zur Aktivierung der Resource Groups aus. Dabei übernimmt er die Ressourcen des anderen Knotens und bietet somit die Dienste des ausgefallenen Knotens an. Quorum Device Um zu verhindern, dass bei einem Netzwerk­ ausfall alle Knoten versuchen, die Ressourcen gleichzeitig zu starten, wird zusätzlich ein Quorum Device definiert. Dahinter verbirgt sich eine Netzwerkadresse, die, wenn das Netzwerk zur Verfügung steht, von allen Knoten „angepingt“ werden kann. Stellt TSA auf 46 ORDIX News 4/2008 einem Knoten fest, dass der andere Knoten und das Quorum Device nicht zu erreichen sind, werden keine Aktionen ausgeführt. TSA geht dann davon aus, dass der Knoten selbst ein Problem hat. Installation Unter den Betriebssystemen AIX und Linux bietet der DB2-Installer die zusätzliche Option „Installation SA MP Base Component“ an. Ist diese Option bei der Installation von DB2 aktiviert, wird neben DB2 auch TSA installiert und so konfiguriert, dass die Grundkomponenten von TSA aktiviert sind. Soll TSA nachträglich installiert bzw. deinstalliert werden, stehen dafür die beiden Skripte installSAM und uninstallSAM zur Verfügung. Sie sind auf dem Installationsmedium im Verzeichnis db2/<Platform>/tsamp zu finden. DB2 High Availability Instance Configuration Utility In der Version 9.1 war TSA zwar auch schon Bestandteil von DB2, musste aber mit den üblichen TSA-Kommandos konfiguriert werden. Einige Konfigurationseinstellungen mussten daher bei TSA und DB2 konfiguriert werden. Dies hat IBM ab der DB2 Version 9.5 mit dem DB2 High Availability Instance Configuration Datenbanken Utility sehr vereinfacht. Die komplette Konfiguration wird mit dem Skript db2haicu vorgenommen. Das textbasierte Werkzeug für die Konfiguration und Administration führt alle notwendigen Anpassungen an der Datenbank­ manager- und der Cluster-Konfiguration durch. Dabei müssen keine TSA- oder DB2-Kommandos verwendet werden. Vorbereitung Voraussetzung für den Einsatz von TSA ist eine funktionsfähige HADR-Umgebung und die Installation von TSA auf den beiden Datenbank-Servern. Die Primär- und die Standby-Datenbank müssen sich im Peer-Status befinden. Bevor das Tool db2haicu genutzt werden kann, muss es initialisiert werden. Dazu muss der Benutzer root auf beiden Datenbankservern das Kommando preprpnode aufrufen (siehe Abbildung 1). Dadurch wird eine TSA Domain angelegt. # preprpnode <Rechner1> <Rechner2> Abb. 1: Initialisieren von db2haicu. Do you want to validate and automate HADR failover for the HADR database SAMPLE? [1] 1. Yes 2. No 2 Abb. 2: Beenden von db2haicu auf dem Standby-System. Glossar TSA IBM Tivoli System Automation HADR High Availability Disaster Recovery Weiterhin ist es wichtig, dass der DB2-Verwaltungsserver angelegt und gestartet ist. Links Konfigurieren der Cluster-Umgebung mit db2haicu auf dem Standby-Rechner Die Konfiguration des Clusters mit dem Skript db2haicu ist auf beiden Rechnern des Clusters vorzunehmen. Der erste Schritt ist auf dem Rechner mit der Standby-Datenbank auszuführen: Hierzu ruft der Instanz-Owner das Script db2haicu auf. Der Reihe nach werden die Fragen zum Anlegen der Domain, dem Domain-Namen, der Anzahl der Knoten im Cluster, die Namen der Rechner im Cluster, IP-Adresse und Subnetz des Quorum Device und optional zur virtuel­ len IP-Adresse beantwortet. Danach ist das Skript auf dem Standby-Sys­ tem abzubrechen und auf dem Primärsystem fortzusetzen. Dies erfolgt durch Eingabe von 2 (No) auf die Frage, ob der automatisierte Failover für die Datenbank eingerichtet werden soll (siehe Abbildung 2). Konfigurieren der Cluster-Umgebung mit db2haicu auf dem Primärrechner Die Konfiguration wird fortgesetzt, indem der Instanz-Owner auf dem Primärrechner das Skript db2haicu startet. Im Dialog werden ►► [1] http://publib.boulder.ibm.com/tividd/td/IBMTivoliSystemAutomationforMultipla tforms2.2.html ►► [2] ORDIX News Artikel „High Availability Disaster Recovery“: http://www.ordix.de/ORDIXNews/2_2005/db2_hadr.html ►► [3] ORDIX News Artikel „Installation und Konfiguration von DB2 High Availability Disaster Recovery“: http://www.ordix.de/ORDIXNews/3_2005/db2_hadr_t2.html hier nur die Fragen nach dem Cluster-Mana­ ger beantwortet und danach das automatische Failover für die Datenbank eingerichtet. Damit ist die Konfiguration abgeschlossen. Die angelegten Ressourcen lassen sich mit dem Kommando lssam von der Kommandozeile anzeigen. Fazit Die Ergänzung von HADR durch TSA ermöglichte schon ab der Version 9.1 einen automatischen Failover. Mit dem DB2 High Availability Instance Configuration Utility ist es jetzt auch möglich, die Konfiguration auf einfache Art und Weise vorzunehmen, ohne sich tief mit TSA beschäftigen zu müssen. Holger Demuth ([email protected]). ORDIX News 4/2008 47 Betriebssysteme OCFS und DRDB (Teil I) - Neue Funktionen in DRBD 8.0: Keine Angst vor Split-Brain! Dieser Artikel richtet sich an Entscheider, Administratoren und Berater, die bereits Erfahrung mit DRBD gesammelt haben oder aber Alternativen zu teuren Lösungen wie SAN etc. suchen. Die elegante Open Source Lösung DRBD hilft, kostengünstig Shared Storage zur Verfügung zu stellen. In diesem Artikel stellen wir einige neue und nützliche Funktionen der aktuellen Version 8.0 vor. In vielen Netzwerkumgebungen stellt sich die Frage nach gemeinsam genutz­tem Storage. Implementiert man die Speicherhaltung lokal auf einem System, hat man bei einem Sys­ tem­ausfall das Problem, die Daten erst mühselig aus dem Backup auf ein anderes Sys­ tem zu übertragen. Nutzt man Lösungen wie SAN oder InfiniBand, muss man ziemlich tief in den Geldbeutel greifen. Die Open Source Lösung DRBD hilft, kostengünstig gemeinsam genutzten Speicher zur Verfügung zu stellen. In diesem Artikel stellen wir Ihnen einige neue und nützliche Funktionen der aktuellen Version 8.0 vor. In einer der kommenden Ausgaben wird dann die Funktion des „Dual Primary Mode“ in Verbindung mit Cluster-Dateisys­temen weiter vertieft. Abbildung 1 gibt einen Überblick darüber, was sich eigentlich hinter DRBD verbirgt. 48 ORDIX News 4/2008 DRBD – Quantensprung und der Weg in den Kernel Um DRBD nutzen zu können, werden ein Kernel-Modul und Verwaltungsbefehle benötigt. DRBD ist aktuell noch nicht im VanillaLinux-Kernel enthalten, aber einige Hersteller liefern ihre Distribution mit DRBD-Implementierung aus. Nutzt man ein SuSE Linux, ist DRBD schon enthalten, unter einem Red Hat Enterprise Server ist DRBD noch nicht enthalten. DRBD, ursprünglich als Diplomarbeit des Österreichers Philipp Reisner entwickelt, wird mittlerweile von seiner Firma LINBIT [1] weiterentwickelt. Auch eine kommerzielle Variante namens DRBD+ mit speziellen Funktionen ist verfügbar. Die DRBD-Entwickler baten vor kurzem um die Aufnahme in den offiziellen Linux-Kernel und wurden, sofern einige Ände- Betriebssysteme rungen am Programmierstil gemacht würden, auf später vertröstet. Etwas gewöhnungsbe­ dürftig ist auch die Versionsbezeichnung: Auf Version 0.7 folgte die Version 8.0, in der vor allem Administratoren der alten Versionen mit geänderten Einstellungen zu kämpfen haben, gleichzeitig aber auch mit sinnvollen neuen Funktionen belohnt werden. Usage – Wir wissen Bescheid Eines der ersten, auffälligen Funktionen der Version 8.0 ist der Eintrag usage-count yes (siehe Abbildung 2) in den globalen Einstellungen der Konfigurationsdatei von DRBD /etc/drbd.conf. Dieser Eintrag kann die Einstellungen yes, no oder ask annehmen. Legt man ein neues DRBD an, wird je nach Einstellung dieses Eintrags gefragt, ob Informationen über dieses Blockdevice bei LINBIT registriert werden sollen. Hiermit möchten die Entwickler die Anzahl der Benutzer, die DRBD nutzen, erfassen. Auf der Inter­ netseite des Projekts [2] kann man sich die Statistiken ansehen. Aktuell werden pro Tag über 100 DRBD-Installationen vorgenommen und registriert. Auch ist zu sehen, dass die Größe der DRBD-Devices zunimmt. Aktuell gibt es schon Größenordnungen zwischen 10 und 20 Terabyte. Unbekannt ist die Dunkelziffer der nicht registrierten Installationen. Was ist Distributed Replicated Block Device (DRBD)? Als Linux Kernel-Modul kombiniert mit einer Verwaltungssoftware auf Befehlszeilen­ ebene und einem Skript dient es dazu, ein Blockgerät auf einem produktiven (Primary) Server in Echtzeit auf einen anderen (Secondary) Server zu spiegeln. Dieses Verfahren wird verwendet, um Hochverfügbarkeit im Linux-Umfeld zu realisieren und somit eine gute Verfügbarkeit verschiedener Dienste zu erreichen. Dabei werden alle Schreibzugriffe über das Netzwerk an den zweiten Server übermittelt. Erst wenn der zweite Server den erfolgreichen Schreibvorgang an den ersten Server zurückgemeldet hat, meldet dieser der Applikation das Ende des Schreibvorgangs (vergleichbar mit einem RAID1, aber im Netzwerk). Falls der erste Server ausfällt, wird dieser als inaktiv gemeldet. Durch eine Cluster Software wie Heartbeat kann der zweite Server die Funktion des ersten Servers übernehmen und mit denselben Daten ohne Verzögerung weiterarbeiten. Abb. 1: Was ist DRBD? – Ein Überblick für Einsteiger. global { usage-count yes; } resource data1 { net { allow-two-primaries; cram-hmac-alg "sha1"; shared-secret "SuperStrengGeheim"; after-sb-0pri disconnect; } Auf „Nummer sicher“ DRBD nutzt nur eine einzige Leitung für die Replikation der Daten und die Datenkommunikation. In der Praxis wird hier eine private Leitung (Crossover-Kabel) zwischen den beiden Knoten genutzt. Da der Weg dieser Leitung oft über mehrere Switches und Router geht, besteht Gefahr durch ein Eindringen von Außen in das private DRBD-Netzwerk. Durch Emulieren des DRBD-Netzwerkprotokolls könnte nun der Datenverkehr zwischen den DRBD-Knoten gestört oder sogar verändert werden. Abhilfe schafft hier der neue Eintrag sharedsecret (siehe Abbildung 2), der bis zu 64 Zeichen lang sein kann. Hier kann eine Pass­ phrase eingestellt werden, mit der die übertragenen Pakete zwischen den DRBD-Knoten authentifiziert werden. Mit dem Schalter cram-hmac-alg kann der Hash-Algorithmus gewählt werden. Mögliche Werte sind z. B. md5, sha1, sha256, sha512, wp256, wp384, wp512. Will man nicht nur gegenseitige Authentifizierung, sondern auch eine Verschlüsselung der übertragenen Daten, muss dies } } } on suse1 { device disk address meta-disk on suse2 { device disk address meta-disk /dev/drbd0; /dev/xvdb2; 10.1.1.1:7788; /dev/xvdb1[0]; /dev/drbd0; /dev/xvdb2; 10.1.1.2:7788; /dev/xvdb1[0]; Befehle, Quellcode Abb. 2: Konfigurationsdatei /etc/drbd.conf mit neuen Einstellungen. weiterhin mit Linux-Bordmitteln, wie IPSEC oder OpenVPN, implementiert werden. Split-Brain – Schizophrenie des Clusters Eine der am meisten gefürchteten Situationen bei DRBD ist eine Split-Brain-Situation. Diese kommt zustande, wenn die private Leitung zwischen den beiden DRBD-Knoten unter- ORDIX News 4/2008 49 Betriebssysteme brochen ist, diese den jeweiligen Status des anderen nicht mehr erfragen und auch keine Daten mehr schreiben können. Nun besteht die Gefahr, plötzlich zwei primäre DRBD-Devices zu haben und diese entweder manuell oder per Cluster-Software zu mounten. Wenn jetzt die private Leitung wieder verfügbar ist, stellt sich die Frage, wie DRBD die Situation auflöst. Unter der Version 0.7 gab es die Funktion „Automatic split brain recovery“. Hierbei wurden automatisch alle Daten des jüngeren DRBD-Devices verworfen. Dieses disconnect Keine automatische Resynchronisation. Auf beiden Knoten die Verbindung zum DRBD-Blockdevice lösen. discard-younger-primary Die Änderungen des jüngeren Primären verwerfen. discard-older–primary Die Änderungen des älteren Primären verwerfen. discard-least-changes Von dem Primären synchronisieren, auf dem mehr Änderungen durchgeführt wurden. discard-node-Knotenname Auf einem bestimmten Knoten die Änderungen verwerfen. Abb. 3: Mögliche Werte für den Eintrag after-sb-0pri. Glossar Verhalten konnte auch nicht geändert werden. In der Version 8.0 kann jetzt ganz individuell entschieden werden, was nun passieren soll. Hierzu gibt es den neuen Eintrag aftersb-0pri (siehe Abbildung 2). Die möglichen Werte hierfür finden Sie in Abbildung 3. Dual Primary Mode Bei DRBD hatte man in den alten Versionen die Problematik, dass das DRBD-Device immer nur auf einem der beiden Knoten eingebunden werden konnte, nämlich auf der Primärseite. Auf dem Secondary schlug jeder Versuch fehl. Noch nicht einmal ein Read Only Mount war möglich. Gerade wenn man DRBD in Verbindung mit einem Active/Active-Cluster einsetzen will, ist dies ein Problem, da nicht auf beiden Clusterhälften auf die Dateisysteme zugegriffen werden kann. Dies ändert nun in der Version 8.0 der neue Eintrag allow-two-primaries in der Konfigurationsdatei (siehe Abbildung 2). Ist dieser Eintrag in der Konfigurationsdatei der beiden DRBD-Knoten enthalten, kann nun auf beiden Knoten die Ressource data1 mit dem Befehl drbdadm primary data1 zum Primary gemacht werden. Zu beachten ist hierbei, dass man nicht einfach irgendein beliebiges Dateisystem auf dem DRBD erstellt. Wichtig ist, dass dieses Dateisystem auch clusterfähig ist. Mögliche Dateisysteme wären hier OCFS2 oder GFS2. Vanilla Kernel Der offizielle Linux Kernel, der von Linus Torvalds gepflegt und koordiniert wird. Active/Active Cluster Ein Cluster, auf dem auf beiden Knoten gleichzeitig derselbe Dienst angeboten wird. OCFS2 Bei Oracle Cluster File System 2 (OCFS2) handelt es sich um ein Open-Source-Cluster-Dateisystem von der Firma Oracle für Linux, welches in einem Cluster mehrerer Rechner konkurrierenden Zugriff auf einen gemeinsamen Speicherplatz ermöglicht. GFS Das Global File System (GFS) ist ein Cluster-Dateisystem, das es Rechnern ermöglicht, gleichzeitig auf das Dateisystem eines Storage Area Network zuzugreifen und zugleich die Konsistenz der enthaltenen Daten gewährleistet. GFS ist Teil des Linux-Kernels und wird in dessen Rahmen entwickelt. Treibende Kraft dabei ist die Firma Red Hat. Links ►► [1] Firma hinter DRBD: www.linbit.com ►► [2] Webseite des Projektes: www.drbd.org Fazit In diesem Artikel haben wir einige der neuen Funktionen der Version 8.0 vorgestellt. Schaut man auf der Projekt-Webseite [2] oder in die aktuellen Manual Pages, wird man feststellen, dass sich in der Version 8.0 noch einiges mehr verändert hat. Die Aufnahme in den offiziellen Linux-Kernel lässt erwarten, dass sich DRBD vor allem auch über die Teichgrenzen hinweg weiter verbreiten wird. Für die Version 9 von DRBD ist die Unterstützung von mehr als zwei Knoten geplant. Auch der Blick auf die kommerzielle Version lohnt sich allemal, da hier noch einige zusätzliche Funktionen implementiert wurden, die vor allem für große Firmenumgebungen nützlich sind, wie z. B. das Backup auf einen dritten Knoten. In einer der nächsten ORDIX News berichten wir über die Nutzung von Cluster-Dateisystemen in Verbindung mit dem Dual Primary Mode. ►► [3] DRBD in SLES: http://www.novell.com/documentation/sles10/stor_evms/index. html?page=/documentation/sles10/stor_evms/data/drdb.html Christian Fertsch ([email protected]). 50 ORDIX News 4/2008 Datenbanken MS SQL Server 2008 New Features (Teil I): Der Blick in die Datenvergangenheit mit Change Data Capture Applikationen nutzen Datenbanken, um Informationen zu speichern, zum Beispiel zu den Fragestellungen „Wie lautet die Adresse des Kunden?“ oder „Welchen Wert hat ein Konfigurationsparameter?“ Gespeichert werden jedoch vielfach nur die aktuellen Daten. Datenänderungen können so nicht nachverfolgt werden. Historische Daten, wie z. B. „Wo hat der Kunde vorher gewohnt?“ stehen nicht mehr zur Verfügung. Dieser Artikel richtet sich an Administratoren von Microsoft SQL Servern sowie an Datenbankentwickler, die sich einen Überblick über die zusätzlichen Funktionalitäten der neuen Version verschaffen möchten. Solche Informationen liefert Change Data Capture - eine neue Funktion des MS SQL Server 2008. Voraussetzungen und Einsatzszenarien Wie viele andere neue Funktionen ist auch Change Data Capture (CDC) nur in der Enterprise Edition des SQL Servers enthalten. Zudem muss der SQL Server Agent aktiviert werden, da Aufträge eine zentrale Rolle spielen. Ein mögliches Szenario ist der in der Einleitung angesprochene Zugriff auf historische Daten. Aber auch die möglichst zeitnahe Synchronisation eines Data Warehouse kann mit CDC umgesetzt werden. Denkbar ist auch die Einführung eines nachgelagerten Prozesses bei Datenänderungen, ohne die eigentliche Applikation ändern zu müssen, wie z. B. die automatische Weiterleitung einer Adressänderung an ein anderes System. Bisher konnten diese Anforderungen meist nur mit Hilfe von Triggern umgesetzt werden. Allerdings werden Trigger synchron abgearbeitet; sie beeinträchtigen also die Performance unter Umständen erheblich. Datenänderungen stehen nicht nur während der Verarbeitung, sondern auch noch danach im Transaktionsprotokoll zur Verfügung. Damit ist eine asynchrone Verarbeitung möglich, bei der ein von der eigentlichen Da­ten­­än­derung unabhängiger Prozess das Trans­ ak­tionsprotokoll auswertet und die Än­de­rungs­ informationen in eigenen Tabellen ablegt. Die Änderungsverfolgung wird dabei für jede einzelne Tabelle ein- oder ausgeschaltet. Auch die Änderungsinformationen stehen in separaten Tabellen zur Verfügung, um den Zugriff auf diese Daten individuell steuern zu können. In Abbildung 1 wird das Verfahren dargestellt. Jede Datenänderung wird im Transaktionsprotokoll der Datenbank vermerkt. Ein Auftrag im SQL Server Agenten liest regelmäßig die neu in das Transaktionsprotokoll geschriebenen Einträge und bearbeitet diejenigen, die sich auf zu überwachende Tabellen beziehen. Das Konzept von CDC Die Einträge werden ausgewertet und die Datenänderung wird in die zugehörige Änderungstabelle eingetragen. Change Data Capture geht einen anderen Weg. Denn alle Informationen über erfolgte Da dieser Vorgang asynchron, also unabhängig von der eigentlichen Datenänderung ab- ORDIX News 4/2008 51 Datenbanken läuft, wirkt er sich nicht auf die Performance der Applikation aus. Lediglich durch das Einlesen und Verarbeiten des Transaktionsprotokolls entsteht eine geringe Last auf dem Server. Allerdings bedeutet diese asynchrone Verarbeitung auch, dass es eine gewisse Zeit dauert, bis die Datenänderungen in der Änderungstabelle abrufbar sind. Damit die Änderungstabelle nicht grenzenlos wächst, löscht ein zweiter Auftrag im SQL Server Agenten in regelmäßigen Abständen veraltete Einträge aus der Änderungstabelle. Standardmäßig werden nur Änderungen von drei Tagen gespeichert. Dies kann jedoch in der Tabelle msdb.dbo.cdc_jobs individuell konfiguriert werden. CDC einrichten Kommen wir nun zur Einrichtung von CDC. In Abbildung 2 ist eine kleine Beispieltabelle mit Beispieldaten angegeben, deren Veränderung aufgezeichnet werden soll. CDC muss zunächst für die Datenbank aktiviert werden. Dazu wird innerhalb der Datenbank der Befehl exec sp_cdc_enable_db; ausgeführt. In welchen Datenbanken CDC bereits aktiviert wurde, kann man der Spalte is_cdc_enabled in der Systemsicht sys.databases entnehmen. Anschließend DatenÄnderung Datenbank Datentabellen Transaktionsprotokoll Auftrag im SQL Server Agenten Änderungstabellen Abb. 1: Die Funktionsweise von CDC im Überblick. 52 ORDIX News 4/2008 ist für jede zu überwachende Tabelle einzeln die Prozedur sp_cdc_en­ able_table auszuführen. Der in Abbildung 3 dargestellte Befehl schaltet z. B. die Überwachung für die Tabelle dbo.kontakte ein. Die angegebene Rolle cdc_admin wird für den Zugriff auf die gesammelten Daten verwendet und automatisch angelegt, sollte sie noch nicht existieren. In welchen Tabellen CDC bereits aktiviert wurde, kann der Spalte is_tracked_by_cdc der Systemsicht sys.tables entnommen werden. Neue Datenbankobjekte Mit der Einrichtung von CDC wird in der Datenbank ein neues Schema cdc mit einer ganzen Reihe von Datenbankobjekten angelegt. Zudem werden zwei neue Jobs im SQL Server Agenten angelegt. Die wichtigsten Tabellen sind die Änderungstabellen, in denen die Datenänderungen protokolliert werden. Die Namen der Tabellen lauten cdc.<Schemaname>_<Tabellenname>_CT, also cdc.dbo_kontakte_CT in unserem Beispiel. Diese Tabellen enthalten zum einen Metadatenspalten mit Angaben zu den durchgeführten Operationen, zum anderen alle Spalten der überwachten Tabellen. Dabei identifiziert die Metadatenspalte __$start_lsn die LSN, die der Änderung zugewiesen wurde und __$seqval die Reihenfolge der Änderungen innerhalb einer Transaktion. In der Spalte __$operation wird der mit der Änderung verbundene Vorgang aufgezeichnet: 1 = Löschung, 2 = Einfügung, 3 = Aktualisierung (Anfangsabbild) und 4 = Aktualisierung (Endabbild). Die Spalte __$update_mask ist eine variable Bitmaske mit einem definierten Bit für jede aufgezeichnete Spalte. Bei Einträgen für Einfüge- und Löschvorgänge werden alle Bits in der Update-Maske gesetzt. Bei Einträgen für Aktualisierungsvorgänge sind dagegen nur jene Bits gesetzt, die den geänderten Spalten entsprechen. Die weiteren Spalten entsprechen den Spalten der überwachten Tabelle. Die Namen der beiden neuen Aufträge im SQL Server Agenten lauten cdc.<DB-Name>_ capture und cdc.<DB-Name>_cleanup, die Aufträge werden also für jede Datenbank separat angelegt und können daher auch separat konfiguriert werden. Datenbanken Daneben existieren einige Tabellen mit generellen Informationen zur Überwachung, so enthält z. B. cdc.change_tables Informationen über die mit CDC konfigurierten Tabellen und cdc.captured_columns eine Liste der überwachten Spalten. Änderungsdaten abfragen Die protokollierten Datenänderungen können direkt aus der Änderungstabelle ausgelesen und weiterverarbeitet werden. Abbildung 5 zeigt den Inhalt der Änderungstabelle nach der Durchführung der in Abbildung 4 angegebenen SQL-Anweisungen. Um die dort angegebenen Protokollfolgenummern in die zugehörigen Zeitpunkte umzurechnen, stehen einerseits die Tabelle cdc.lsn_time_mapping und andererseits die beiden darauf basierenden Funktionen sys.fn_cdc_map_time_to_lsn und sys. fn_cdc_map_lsn_to_time zur Verfügung. Zur Anzeige der Datenänderungen kann man darüber hinaus die Tabellenwertfunktion cdc.fn_cdc_get_all_changes_<Schema­ name>_<Tabellenname> nutzen, die als Parameter die untere und obere Grenze der Protokollfolgenummern sowie die Angabe, ob bei Update-Vorgängen nur die neuen oder auch die alten Daten angezeigt werden sollen, über­ nimmt. Was CDC nicht kann Generell werden nur die Datenänderungen selbst und nicht die ausgeführte SQL-Anweisung oder Informationen über den ausführenden Benutzer gespeichert. Somit ist diese Funktion nur begrenzt für Audit-Zwecke geeignet. create table kontakte ( id integer primary key , name varchar(50) , adresse varchar(500) ); go insert values , , go into kontakte (1,'Jordan','Taunusstraße') (2,'Meier' ,'Bergstraße' ) (3,'Müller','Schlossallee'); Abb. 2: Beispieltabelle mit Beispieldaten. exec sp_cdc_enable_table @source_schema = 'dbo', @source_name = 'kontakte', @role_name = 'cdc_admin'; Abb. 3: CDC für die Tabelle „kontakte“ einschalten. insert into kontakte values (4,'Schulze','Meisenweg'); update kontakte set adresse = 'Birkenallee' where name = 'Jordan'; delete kontakte where name = 'Meier'; update kontakte set id = 33 where id = 3; Abb. 4: Beispielhafte Datenänderungen. Darüber hinaus sollte sich die Struktur der überwachten Tabelle nicht ändern, da die er- __$start_lsn name adresse 0x0000001C000000750003 NULL __$end_lsn __$seqval 0x0000001C000000750002 2 0x07 4 Schulze Meisenweg 0x0000001C0000007A0004 0x0000001C0000007A0004 0x0000001C0000007B0005 0x0000001C0000007E0004 0x0000001C0000007E0004 0x0000001C0000007A0002 0x0000001C0000007A0002 0x0000001C0000007B0002 0x0000001C0000007E0002 0x0000001C0000007E0002 0x04 0x04 0x07 0x07 0x07 1 1 2 3 33 Jordan Jordan Meier Müller Müller Taunusstraße Birkenallee Bergstraße Schlossallee Schlossallee NULL NULL NULL NULL NULL __$operation __$update_mask id 3 4 1 1 2 Abb. 5: Inhalt der Tabelle cdc.dbo_kontakte_CT nach Durchführung der Datenänderungen. ORDIX News 4/2008 53 Datenbanken zeugten CDC-Tabellen später nicht mehr angepasst werden können. Zusätzliche Spalten werden also nicht überwacht. Die einzige Möglichkeit ist die Deaktivierung und erneute Aktivierung von Change Data Capture für diese Tabelle, was allerdings zum Verlust der bisher gesammelten Daten führt. Glossar LSN Log Sequence Number (oder Protokollfolgenummer). Die LSN ist eine für jede Datenbanktransaktion eindeutig und aufsteigend vergebene Nummer. Fazit Change Data Capture kann in vielen Fällen bisher notwendige Trigger ablösen und so einen performanten Zugriff auf Datenänderungen bieten. Die Einrichtung und Konfiguration ist sehr einfach durchzuführen. Im Rahmen dieses Artikels wurden jedoch nur Teilaspekte von Change Data Capture behandelt. Sollten Sie zusätzliche Anforderungen an die Verfolgung von Änderungen haben, dann sprechen Sie uns an. Andreas Jordan ([email protected]). Change Data Capture des SQL Server 2008 im Expertencheck 1. Verfügbarkeit in den verschiedenen Editionen 2. Einrichtung 3. Konfiguration 4. Flexibilität bei Änderung der überwachten Tabellen 5. Funktionsumfang 6. Performance 7. Dokumentation positiv: negativ: 54 ORDIX News 4/2008 „Change Data Capture ist eine neue, leis­tungs­fähige Funktion des MS SQL Server 2008, mit der eine performan­te Nachverfolgung von Datenänderun­gen ohne den Einsatz von Triggern möglich ist. Die Einrichtung und Konfiguration ist einfach. Schwächen zeigt die Funktion lediglich bei der nachträglichen Änderung von Tabellenstrukturen.“ Andreas Jordan, ORDIX AG, Wiesbaden Aktuell Mit freu ndl ich er U nte rstü tzu Einladung zum ORDIX IT-Symposium am 17.02.9 in Hamburg ng von Risikomanagement mit Oracle Im Bereich IT-Management müssen sich die Verantwortlichen heute zunehmend neuen Herausforderungen stellen. Insbesondere die Themen Risikomanagement, IT-Security und Hochverfügbarkeit rücken immer mehr in den Fokus der IT-Entscheider. Um diese Themen für Sie zu beleuchten, laden ORDIX und coniatos Sie herzlich zum ITSymposium in die Hamburger Geschäftsstelle des ORDIX Partners Oracle ein. Neue Herausforderungen an das IT-Management Im Rahmen des Symposiums gibt Ihnen Lars Eisenblatt, Vorstand der coniatos AG, einen Überblick über die neuen Herausforderungen des IT-Managements. Eine der Kernaufgaben ist das Erkennen und Beherrschen von IT-Risiken, wie z. B. Fehlfunktionen von Prozessen und Systemen oder der unberechtigte Zugriff und Diebstahl sensibler Daten. Datenbank Security mit Oracle Auditing Viele Kunden müssen immer größeren Wert auf das Thema Security legen. Ein wichtiger Teilaspekt ist dabei das Auditing. So müssen Banken beispielsweise nachweisen können, wann und wer relevante Daten geändert hat. Teilweise ist es sogar notwendig, lesenden Zugriff zu protokollieren. Klaus Reimers, Datenbankexperte der ORDIX AG, zeigt Ihnen in seinem Vortrag die technischen Möglichkeiten von Oracle Auditing auf: • • • • mandatory Auditing SYS Auditing Standard Auditing FGA Neben der Erklärung und Live-Demo der einzelnen Funktionen schildert Reimers Einsatzbeispiele aus der Praxis. Zudem vergleicht und bewertet er die verschiedenen AuditingMöglichkeiten hinsichtlich der Performance. Oracle Hochverfügbarkeit im Überblick Geschäftskritische Daten müssen 7x24 Stunden verfügbar sein. Oracle bietet hierfür verschiedene Ansätze an: • • • • • Oracle Real Application Cluster (RAC) Oracle Data Guard Replikation Automatic Storage Management (ASM) Flashback Lars Eisenblatt stellt Ihnen die grundlegenden Konzepte vor und vergleicht die Hochverfügbarkeitslösungen von Oracle hinsichtlich Technologie und Kosten. Für Sie beleuchtet er Vor- und Nachteile und demonstriert den Einsatz anhand von Praxisbeispielen. Anmeldung und weitere Infos Lassen Sie sich dieses Symposium nicht entgehen und melden Sie sich gleich online an: http://www.ordix.de/symposium ... übrigens: Wenn Sie die Themen Oracle Security und Hochverfügbarkeit weiter vertiefen möchten, lohnt sich ein Blick auf unser Seminarangebot im Online-Trainingsshop unter http://training.ordix.de. Klaus Reimers, ORDIX AG. Agenda 09:30 Begrüßung 09:50 Neue Herausforderungen an das IT-Management Referent: Lars Eisenblatt, coniatos AG, Wiesbaden 10:30 Pause 10:45 Datenbank Security mit Oracle Auditing Referent: Klaus Reimers, ORDIX AG, Köln 11:30 Pause 11:45 Oracle Hochverfügbarkeit im Überblick Referent: Lars Eisenblatt, coniatos AG, Wiesbaden 12:45 Mittagsimbiss und Ausklang Veranstaltungsort Fragen zu den Inhalten beantwortet Ihnen gerne Ihre persönliche Ansprechpartnerin: Jana Kreschel ORDIX AG, Wiesbaden Tel.: 0611 77840-23 E-Mail: [email protected] ORACLE Deutschland GmbH Kühnehöfe 5 / Ecke Kohlentwiete 22761 Hamburg Online-Anmeldung ►► http://www.ordix.de/symposium ORDIX News 4/2008 55 IT-Management & Consulting Ganzheitliches IT-Management löst IT-Aufgaben über und unter der Oberfläche! Meist geht es in IT-Landschaften in erster Linie darum, technische Probleme zu lösen. Doch die technischen Probleme sind häufig nur die Spitze des Eisbergs. Und die erfolgreiche und termintreue Umsetzung scheitert auch nicht an Technologien – häufig ist ein Blick unter die Oberfläche nötig. Wir unterstützen Sie dabei mit Beratung, Schulung, Coaching und coniatos™ Checks zu den Themen: • IT-Strategie Entwicklung und Umsetzung • IT-Management Aufgaben und Frameworks (COBIT, ITIL, PRINCE2) • Krisenmanagement in IT-Projekten • Effizientes Projektmanagement • Entwicklung starker Teams • Optimierte Durchführung von Meetings Coniatos hilft Ihnen, Ihre IT ganzheitlich zu optimieren: auf der fachlichen Ebene bei IT-Architektur und Technik, auf der Prozessebene z. B. im Projektmanagement und auf der sozialen Ebene z. B. bei der Verbesserung der Kommunikation und des Konfliktmanagements. coniatos AG Kreuzberger Ring 13 65205 Wiesbaden Tel: 0611 77840-00 E-Mail: [email protected] Internet: www.coniatos.de
