SAP-Überwachung mit PATROL

ORDIX News Das IT-Magazin der ORDIX AG

Ausgabe 4/2003 € 2,20

SAP-Überwachung mit PATROL Monitoring eines komplexen Bankenkernsystems S. 24

Perl parst Excel Perl als betriebssystemunabhängige Schnittstelle zu Excel S. 5

Serverkonsolidierung oder: Aus „Alt“ mach „Neu“ S. 30

Oracle: Tuning I/O-intensiver Systeme

S. 14

Einladung zur NetIQ Partner Veranstaltung am 29.01.2004 in Wiesbaden

System- und Sicherheits-Management mit NetIQ

S. 33

Editorial

Paderborn, Januar 2004

Einkaufstage Da waren sie wieder, die Einkaufstage. Alle Jahre wieder ... hoffte der Handel auf das Weihnachtsgeschäft, das den bescheidenen Jahresumsatz wett machen sollte. Dieses Jahr sicher mehr denn je, denn die meisten Innenstädte gleichen inzwischen schon fast Geisterstädten. Pro Monat schließen mittlerweile mehr Geschäfte als früher im ganzen Jahr. Gereicht haben soll er aber nicht – der Weihnachtsboom, trotz Steuerreform oder vielleicht gerade deswegen! Ja, und bei Einkaufstagen fallen mir auch gleich zwei Schlagzeilen der letzten Wochen ein: Open Text kauft IXOS und Novell kauft SUSE. Novell – das ist doch die Firma, die vor allem davon profitiert, dass Microsoft bis heute kein vernünftiges Netzwerkkonzept zu bieten hat!? Oder ist das die Firma, die vor Jahren von AT&T die Unix Sourcen erwarb, um endlich auf ein vernünftiges Betriebssystem zu setzen, und die dann anscheinend nichts davon verstand und alle Rechte an SCO verkaufte?! Jedenfalls wundere ich mich, dass Novell überhaupt noch existieren kann und jetzt auch noch das Geld aufbringt, um SUSE zu kaufen. Aber die Zusage von IBM, Geld zu geben, scheint anzuspornen. Wir werden unsere Partnerschaft mit SUSE jedoch weiter aufrecht erhalten. Mit der Übernahme von IXOS durch die Kanadier Open Text verschwindet über kurz oder lang eine weitere deutsche Präsenz auf dem weltweiten IT Markt. Bleibt wieder nur SAP übrig. Schade! Natürlich bleiben auch wir übrig und haben in dieser News wieder einiges zu bieten: Von Datenbanken (Informix und Oracle) über Linux (trotz SUSE) bis hin zu System Management Lösungen für SAP Systeme. Früher blieb mir am Ende der Ausgabe 4 immer, Ihnen schöne Weihnachten zu wünschen. Das hätte dieses Mal eigentlich auch geklappt (und es war auch schon alles gedruckt), aber aufgrund technischer Probleme bekommen Sie die Zeitung quasi als nachträgliches Weihnachtsgeschenk. Für 2004 wünsche ich Ihnen, dass es so gut wird, wie das Wetter in 2003. Es sei denn, unsere Blockadereformer in Berlin treiben wieder nur Unfug und statt Reformen bleiben wieder nur die Steuererhöhungen übrig. Denn dann hat auch in 2004 niemand mehr Geld, das er ausgeben kann ... und es verschwinden noch mehr Läden. Jedoch, 2004 hat einen Tag mehr und viele Feiertage fallen auf das Wochenende. Allein das sollte reichen, um die Wirtschaft anzukurbeln. Wenn nicht, braucht sich Herr Clement nicht zu wundern, dass seiner Theorie von „weniger Urlaub = mehr Wirtschaftswachstum“ nur wenige folgen können. Mehr Wachstum entsteht nur, wenn die Menschen hier in Deutschland mehr Geld in der Tasche haben bzw. für etwas anderes als Steuern und Abgaben ausgeben können. Viel Spass beim Lesen wünscht Ihnen

Wolfgang Kögler

3

Inhaltsverzeichnis

Aus- & Weiterbildung

Standards

11 ... Seminar: PATROL Advanced 15 ... Seminar: Oracle Tuning und Monitoring 20 ... Seminarübersicht: Preise, Termine ... bis Juli 2004. 35 ... ORDIX Schulungsräume erweitert

03 ... Editorial 04 ... Inhalt 32 ... Impressum

Aktuell

Java/XML

19 ... News Ticker 22 ... Larry Ratlos Kniffel: Helfen Sie Larry bei seinem neuen Problem und lesen Sie die Lösung der letzten Aufgabe. 23 ... Sie kam, ritt und siegte: Die steile Karriere der Hannelore Brenner nimmt ihren Lauf. 26 ... Herzlichen Glückwunsch dem Schach Quiz Gewinner! 33 ... Einladung zur NetIQ Partner Veranstaltung „Systemund Sicherheits-Management mit NetIQ“ am 29.01.04 34 ... 16. Deutschen Oracle Anwender Konferenz - Review

Datenbanken 06 ... IBM IDS 9.40 (Teil II): Large Chunk Support, IBM Informix Dynamic Server „The future is wide open ...“ Die technischen Hintergründe sowie die einzelnen Phasen, die bei einer “Aktivierung” des Large Chunk Modes beachtet werden müssen. 14 ... Tuning I/O-intensiver Systeme (Teil I) In diesem zweiteiligen Beitrag beleuchten wir I/O-intensive Oracle Datenbank Systeme und stellen zahlreiche Möglichkeiten zur Performance-Verbesserung dar. 27 ... Performancetest: Ladefunktionalitäten unter Oracle 9i Mit einem Performancetest überprüf en wir, wie schnell sich mit den neuen Features große Datenmengen in eine Datenbank einpflegen lassen und vergleichen dies mit dem sql*loader und dem Verteilen über ein PL/SQL-Skript. 36 ... Standby-Datenbank: Data Guard aus Kundensicht (Teil III) Gemeinsamkeiten bzw. Unterschiede zwischen einer logischen und einer physikalischen Standby-Datenbank und wie man eine logische Standby-Datenbank aufbauen kann.

16 ... Die eSelect Suite, Teil VI: Electronic Advisor: Lösungen für problemorientierte Beratung Der letzte Teil dieser Reihe zeigt die Vielfältigkeit der Konfigurations- und Einsatzmöglichkeiten anhand zweier Beratungs-Szenarios, die auf Basis der Komponenten der eSelect Suite entworfen und ansatzmäßig als Prototypen umgesetzt wurden.

Unix/Linux/Open Source 05 ... Perl parst Excel Perl als Schnittstelle zu Excel, mit der man unabhängig vom Betriebssystem Daten extrahieren und Datenbank-Tabellen automatisiert befüllen kann. 30 ... Serverkonsolidierung oder: Aus „Alt“ mach „Neu“ Was tun, wenn IT-Projekte an ihre Ressourcen-Grenzen stoßen? Lesen Sie einen beispielhaften Werdegang von der Konzepterstellung bis zur Realisation/ Migration. 12 ... Knoppix à la Carte Am Beispiel „Morphix“, einer Knoppix Variante, stellen wir vor, wie man LiveCDs seinen „eigenen Stempel“ aufdrücken kann.

System Management 09 ... PATROL Configuration Manager macht´s möglich Die Konfiguration der PATROL-Agenten stellt eine echte Herausforderung dar. Jetzt greift Ihnen der PATROL Configuration Manager dabei unter die Arme.

4

24 ... SAP-Überwachung mit PATROL Erfahrungsbericht über das Aufsetzen einer Monitoring Lösung zur Überwachung eines komplexen Bankenkernsystems .

Unix/Linux/Open Unix/Linux/Open Source - Titelthema Source Perl

Perl parst Excel Wozu das Ganze? Dazu eine kleine Story: Herr Meier bekommt die Aufgabe, aus 100 Excel-Dateien, die im gleichen Format vorliegen, die Daten zu extrahieren, um Datenbank-Tabellen automatisiert zu befüllen. Originäre Excel-Dateien (.xls) liegen im Binärformat vor. Excel bietet von Haus aus an, die Daten im ASCII-Format abzuspeichern (Dateien mit der Endung .csv = comma separated values). Man kann sicher auch ein Makro in Excel schreiben, das die Excel-Dateien einzeln einliest und dann daraus ASCII-Dateien erstellt. Die ASCIIDateien enthalten mit Semikolon separierte Listen, deren Daten man nun manuell in eine Datenbank importieren könnte. Aber ist das nicht ein wenig zu aufwändig? Und was ist mit der Datenbank, wenn die auf einem Rechner mit einem anderen Betriebssystem läuft? Gibt es denn keine Schnittstelle zu Excel in Form einer Programmiersprache, mit der man auch unter Unix oder anderen Betriebssystemen solche Dateien einfach und automatisiert verarbeiten kann? Eine gute Anwort ist: PERL. Perl bietet eine solche Schnittstelle in Form eines Moduls. Modul-Installation. Oder: Wie fange ich an? Das Modul, welches für diese Aufgabe gebraucht wird, heißt „Spreadsheet-ParseExcelSimple“. Abhängige Module müssen möglicherweise nachinstalliert werden. Nach diesen Modulpaketen kann man sehr komfortabel unter http://search.cpan.org/ suchen und sie anschließend per perl Makefile.pl, make und make install installieren. Eine detaillierte Beschreibung, wie man Module bei welchem Betriebssystem installiert, lesen Sie unter: http://www.cpan.org/modules/INSTALL.html. OK, alle Module sind installiert. Wie geht es weiter? Zuerst baut man das Grundgerüst des PerlScripts auf (siehe Zeilen 1 - 3). So speichern wir die Datei z. B. unter „perlparstxls.pl“ und ändern die Eigenschaften der Datei so ab, dass sie ausführbar wird. Erster Funktionstest: Das Script wird direkt auf der Kommandozeile ausgeführt. Gibt es keine Fehlermeldungen, scheint das Modul richtig geladen worden zu sein. Jetzt kann das Modul in vollem Umfang genutzt werden. Schritt 1: Eine Excel-Datei wird in $xls als Referenz eingelesen (hier: „excel_file.xls“ siehe Zeilen 5 - 7). Schritt 2: Jetzt werden die Sheets (Blätter) des xls-files ermittelt und das Ergebnis (jeweils eine Referenz auf ein sheet-Objekt) in die einzelnen Felder eines Arrays (@blaetter) übergeben (siehe Zeile 9).

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

#!/usr/bin/perl –w # Pfad unter UNIX zum perl-binary use Spreadsheet::ParseExcel::Simple; $xls = Spreadsheet: :ParseExcel::Simple->read („excel_file.xls“); @blaetter = $xls->sheets; foreach $blattref (@blaetter) { # Das folgende Array wird die gewonnenen Daten aus # den xls-sheets beinhalten. Das Array soll jedoch # Für jeden Schleifendurchlauf geleert werden. @allefelder = (); # # # # #

Wenn das Blatt, welches auf $blattref (siehe Schritt3) zeigt, Daten hat, dann packe diese Daten in das Array (@zeile). Jede einzelne Zeile wird komplett als Referenz einem Feld im Array @allefelder zugewiesen.

while ($blattref->has_data) { @zeile = $blattref->next_row; push(@allefelder,[@zeile]); # # # # #

Durchlaufen wird das Array (@allefelder) mit den gewonnenen Excel-Daten. Jeder einzelne Feldwert muss dereferenziert werden, damit wir die Zeilen ausgeben können. Jede Zeile wird hier mit Zeilenumbruch auf STDOUT ausgegeben. foreach $zeile (@allefelder) { print “@$zeile\n”;

} } }

Schritt 3: Um alle sheets einer xls-Datei bearbeiten zu können, braucht man nur das Array (@blaetter) zu durchlaufen (siehe Zeilen 11 - 39). In der foreach-Schleife, hinter @allefelder = (); kann nun jedes Excel-sheet einzeln bearbeitet werden. Schritt 4: Um Daten aus dem Excel-sheet zu extrahieren, bietet sich die in den Zeilen 19 - 38 gezeigte Vorgehensweise an. Hat man diese Informationen zusammen, sind die Möglichkeiten der Weiterverarbeitung schier unbegrenzt. Um nur ein Beispiel zu nennen: Man könnte die Spaltenwerte jetzt mit Hilfe von PerlDatenbankmodulen (siehe cpan) in eine oder mehrere Datenbanktabelle(n), oder einfach nur in eine oder mehrere ASCII-Dateie(n) schreiben. Jetzt sind Sie gefragt: Probieren Sie es doch einfach mal aus! Frank Weiser ([email protected]).

5

Datenbanken

Teil II der Reihe IBM Informix Dynamic Server 9.40: Large Chunk Support

IBM Informix Dynamic Server „The future is wide open ...“ Mit der Freigabe des IBM Informix Dynamic Server (IDS) 9.40 wurde der Large Chunk Support implementiert. Ab diesem Release können Chunks bis zu einer Größe von 4 TB angelegt werden. Des Weiteren wurde die maximale Anzahl Chunks pro Instanz auf 32.767 erhöht. Somit ergibt sich eine maximale Instanz-Kapazität von 128 PB (Petabyte). Der folgende Artikel beschreibt die technischen Hintergründe sowie die einzelnen Phasen, die bei einer „Aktivierung” des Large Chunk Modes beachtet werden müssen.

Basics ... Zum besseren Verständnis betrachten wir zuerst einmal den Aufbau einer Page. Die Page ist die kleinste I/O Einheit. Je nach Betriebssystem beträgt die Größe einer Page 2 KB oder 4 KB (siehe Abbildung 1). Eine Page besteht aus einem Verwaltungsbereich, dem Page Anfang (Page-Header) und dem Page Ende. Der Freiraum zwischen Page-Header und Page Ende steht, wie in Abbildung 2 zu sehen, den „eigentlichen“ Daten zur Verfügung (Daten-, Index- und Blob-Informationen).

Abb. 1: Page-Größe.

Um die Anzahl der Pages herauszufinden, die in einem Chunk adressiert werden können, betrachten wir den Aufbau der Physical Page Address. Diese wird, bei nicht aktiviertem BIG Chunk Mode, im Page-Header gespeichert. Der Page-Header besteht aus:

Abb. 2: Aufbau einer Page.

0x004 00009 Chunk Number: Page Offset: pg_addr:

FFF FFFFF 0xFFF FFFFF

(3 Half bytes = 12 Bit) (5 Half bytes = 20 Bit) (Gesamt 4 Byte)

pg_addr pg_stamp pg_nslots pg_flags pg_frptr pg_frcnt pg_next pg_prev

4 Byte Physical Page Address 4 Byte TimeStamp 2 Byte Anzahl Slots 2 Byte Flag Bits 2 Byte Free Pointer 2 Byte Free Counter 4 Byte Next Node (Btree) 4 Byte Previous Node (Btree)

Summe:

24 Byte Page-Header

Physical Page Address (< 9.40) Abb. 3: Aufbau einer Physical Page Address (< 9.40).

0x00000009 0004 Page Offset: FFFFFFFF (8 Halfbytes = 32 Bit) Chunk Number: FFFF (4 Halfbytes = 12 Bit) pg_offset/pg_chunk: 0xFFFFFFFF FFFF (Gesamt 6 Byte) Abb. 4: Aufbau einer Physical Page Address (9.40).

6

Die Physical Page Address (pg_addr 4 Byte) besteht aus der Chunk Number und dem Page Offset (laufende Page Nummer innerhalb eines Chunks). Die ersten 3 Halfbytes (12 Bit) stellen die Chunk Number dar, die nächsten 5 Halfbytes (20 Bit) den Page Offset, also die adressierbaren Pages innerhalb eines Chunks (siehe Abbildung 3). Daraus resultieren folgende Grenzwerte für Anzahl Chunks und Anzahl Pages je Chunk:

Datenbanken

# Chunks:

3 Halfbytes je 4 Bit (12 Bit) → 2.047 Chunks Page Offset: 5 Halfbytes je 4 Bit (20 Bit) → 1.048.575 Pages x 2.048 → 2.147.481.600 Byte pg_addr: 4 Byte Gesamt (32 Bit)

ersetzt. Dadurch wurden u. a. 2 Byte zu einem neuen Feld „Chunk Number“ (pg_chunk) im Page-Header zur Verfügung gestellt.

Physical Page Address (9.40)

# Chunks:

Das Ziel war, die bisherige Page Struktur beizubehalten und den Zugriff auf „konvertierte“ und „nicht konvertierte“ Pages zu ermöglichen. Um die Anzahl der Chunks und die Anzahl der adressierbaren Pages innerhalb eines Chunks zu erhöhen, musste die Physical Page Address „vergrößert“ werden (siehe Abbildungen 4 und 5), jedoch unter der Voraussetzung, dass die bisherige Page-Header-Größe von 24 Byte unverändert bleibt.

Page Offset:

Die Lösung

Die Page-Konsistenz kann nun nicht mehr über einen Vergleich des TimeStamp im Page-Header mit dem TimeStamp am PageEnde überprüft werden. Dafür steht ein weiteres Feld pg_chksum (Page Checksumme) im Page-Header zur Verfügung.

Der Page TimeStamp (pg_stamp 4 Byte) im Page-Header wurde durch zwei neue „Felder“

Die ersten 8 Halfbytes der Physical Page Address stellen nun den Page Offset dar und die nächsten 4 Halfbytes die Chunk Number (pg_chunk). Somit ergeben sich folgende Größenverhältnisse:

pg_offset/pg_chunk:

4 Halfbytes je 4 Bit (16 Bit) → 32.767 Chunks 8 Halfbytes je 4 Bit (32 Bit) → 2.147.483.648 Pages x 2.048 → 4 TB 6 Byte Gesamt (48 Bit)

Die Änderung kann aber auch über den Vergleich der Pseudo Tabelle syspaghdr der Sysmaster-Datenbank nachvollzogen werden (siehe Abbildung 9). Page Konsistenzüberprüfung

informix@linux:~> oncheck -pP 2 86 addr stamp chksum nslots flag type frptr frcnt next prev 2:86 110221 aed8 2 1 DATA 72 1964 0 0 slot ptr len flg 1 24 24 0 2 48 24 0 slot 1: 0: 0 0 0 1 54 65 73 74 20 31 20 20 20 20 20 20 ....Test 1 16: 20 20 20 20 20 20 20 20 ........ slot 2: 0: 0 0 0 2 54 65 73 74 20 32 20 20 20 20 20 20 ....Test 2 16: 20 20 20 20 20 20 20 20 ........ Abb. 5: ONCHECK Ausgabe zur Anzeige eines Page Dumps (Chunk 2 Page 86).

informix@linux:/db/ifx> onmode -BC 1 This command will enable creation of large chunks. ** WARNING ** This action cannot be undone. ** WARNING ** A level 0 archive of Root DBSpace will need to be done. Do you wish to continue (y/n)? y

Abb. 6: Umstellung Phase 1.

informix@linux:/db/ifx> onmode -BC 2 This command will cause all chunks to be written in the new (big) format. ** WARNING ** This action cannot be undone. ** WARNING ** A level 0 archive of Root DBSpace will need to be done. Do you wish to continue (y/n)? y

Abb. 7: Umstellung Phase 2.

7

Datenbanken

update customer set customer_num = customer_num where 1=1; Abb. 8: “Dummy” Update.

{ Page Headers 2 GB angelegt werden. Die Umstellung erfolgt in zwei Phasen mit Hilfe einer neuen „onmode-Option“. Das tatsächliche Konvertieren der Page-Header erfolgt jedoch erst beim ersten, ändernden Zugriff auf die Page. Phase 1 Mit dem Befehl onmode –BC 1 bringt man den IDS 9.40 in die Phase 1 (siehe Abbildung 6). Erst jetzt können „BIG“ Chunks hinzugefügt werden. Befindet sich der DB-Server in der Phase 1, ist ein Downgrade - z. B. mittels onmode –b 9.3 - möglich, wenn: - kein “BIG” oder Large Chunk existiert. - die maximale Chunk Number nicht 2.047 überschritten hat. Alle Page-Header, die zu einem „BIG“ Chunk gehören, werden beim ersten, ändernden Zugriff konvertiert. Phase 2 Befindet sich der DB-Server in der Phase 2 ist ein „Rollback“ nur mittels Restore möglich (Einspielen eines Backups, welches vor der Umstellung erstellt wurde). Der Befehl onmode –BC 2 bringt den Server in die Phase 2 (siehe Abbildung 7). Alle Page-Header werden auch hier beim ersten, ändernden Zugriff konvertiert.

8

Um eventuellen Performance-Problemen vorzubeugen, ist ein „dummy“ Update pro Tabelle sinnvoll (siehe Abbildung 8), je nach Tabellengröße gegebenenfalls auch über mehrere Spalten. Fazit Die Konvertierung betrifft ausschließlich den Page-Header. Somit bleiben 99 Prozent der Daten innerhalb einer Page unberührt. Des Weiteren ist eine „Koexistenz“ von beiden Page-Header-Typen möglich. Es besteht also die Möglichkeit, „normale“ Chunks und sogenannte „BIG“ Chunks innerhalb einer Instanz zu betreiben. Die Konvertierung auf den Large Chunk Mode kann somit „on the fly“ erfolgen. Mit dieser Lösung hat IBM ihren Informix Kunden einen effizienten und schnellen Umstieg in die Welt der Tera- und Petabyte geschaffen. In einer der nächsten ORDIX News lesen Sie mehr zu den weiteren Neuerungen des IBM Informix Dynamic Server 9.40.

Guido Saxler ([email protected]).

System Management

PATROL Configuration Manager macht’s möglich Also alles im Griff!? Alles? Nein, nicht alles, aber immer mehr. Die Konfiguration der PATROL-Agenten stellt eine echte Herausforderung dar, wenn man sie als Möglichkeit zur Herstellung eines kontrollierten, bestmöglich definierten Zustandes versteht. Dazu waren „wpconfig“ und „xpconfig“ schon immer nützliche Helfer. Der Configuration Manager als GUI für pconfig geht aber deutlich weiter, und das kostenlos. Der Configuration Manager basiert auf Java und läuft auf Windows und Unix gleichermaßen. Auf den ersten Blick sieht die Kommandozentrale einleuchtend und aufgeräumt aus. Neben Menüleiste und Toolbar teilen das Agenten-Window und das RuleSet-Window die Oberfläche auf. Das „Drag and Drop“ und „Cut and Paste“ ist stark an den Windows Explorer angelehnt, aber nicht identisch. Irgendwie lädt das alles so richtig zum Klicken ein. Aber Vorsicht! Ein unbedachter Klick kann ein nicht unbeträchtliches Chaos anrichten. Agenten-Window Über ein Kontextmenü können Gruppen (Verzeichnisse) und Abb. 1: Kommandozentrale des PATROL Configuration Managers. Agenten angelegt werden. Den Agenten werden jeweils Hostname und Display Name sowie Portnummer res als Agentenvariablen mit einer Operation, z. B. REPLACE, und Protokoll zugewiesen. Man legt sie direkt und einem Wert. Ein RuleSetFolder besteht aus beliebig vielen innerhalb einer Gruppe an. Ein Agent kann unRuleSetFoldern und beliebig vielen RuleSets. Wie gehabt sind ter einem oder verschiedenen Namen mehrdie Zuordnungen mit Maus und Kontextmenü veränderbar. fach vorhanden sein. Die Gruppenzuordnung ist jederzeit mit Maus oder Kontextmenü verNach der Installation findet man zwei RuleSetFolder auf der obersänderbar. Die Gruppen können über mehrere ten Ebene: In „Shipped“ werden Beispiele geliefert, die erst mal Ebenen verschachtelt werden. Jede Gruppe keine besondere Bedeutung haben. Besondere Beachtung gilt enthält automatisch genau ein Symbol „Applyaber dem „ChangeSpring“ mit vier RuleSetFoldern: OnNew“. Ein ApplyOnNew kann beliebig viele RuleSets enthalten. • „backup“ beinhaltet die sogenannten „Virtual Backup Folder“, lexikographisch geordnet nach Agentennamen. Bei jedem Das Resultat wird in zwei Textfiles gespeichert, Backup werden hier die kompletten Agentenkonfigurationen „agents.ini“ und „groups.ini“. Dadurch lässt abgelegt. Man kann zwar keine eigenen Bereiche für die „Virsich die Arbeit zum Erstellen und Zuordnen tual Backup Folder“ festlegen, aber man kann deren maximaohne Schwierigkeiten automatisieren. Ein mitle Anzahl sowie die maximale Anzahl der Agenten je Folder geliefertes Tool „csmi.bat“ im Verzeichnis „util“ einstellen. Das Ganze ist eine ziemlich gute Möglichkeit, eine kann die benötigten Informationen aus den große Anzahl von Agenten übersichtlich darzustellen. Konsolenfiles generieren. Dies muss aber nicht genutzt werden. • „local“ ermöglicht es, für bestimmte Agenten lokale Einstellungen vorzunehmen. Die Konfiguration über eine Gruppe kann RuleSet-Window diese Einstellungen nicht überschreiben. Ein sehr nützliches Instrument, solange es nicht zu viele lokale Konfigurationen Ein RuleSet hat einen Namen und besteht aus gibt. Allerdings sollte man dann doch noch mal seine Gruppenbeliebig vielen Rules. Rules sind nichts andestruktur überdenken.

9

System Management

•

„queue“ verschafft einen Überblick über RuleSets, deren Versendung an die Agenten misslungen ist. Zu einem späteren Zeitpunkt kann man dann gezielt einen neuen Versuch starten. Leider müssen RuleSets dann manuell gelöscht werden. Sorgsames Nachhalten ist ein Muss!

„/AS/EVENTSPRING/PARAM_SETTINGS/ THRESHOLDS/NT_CPU/CPU__Total/ CPUprcrUserTimePercent“ = { REPLACE = „1,1 0 100 0 0 2,1 95 98 1 5 1,1 98 100 1 5 2“ },

•

„tlog“ listet alle erfolgreich verschickten RuleSets auf. Die Liste wird einmal nach Zeitpunkt der Transaktion und zusätzlich nach Agentenname sortiert. Das verschafft einen guten Überblick über das, was wirklich gelaufen ist.

Mit dem richtigen Editor wird es gleich wieder griffiger. Für diesen speziellen Fall, das Einstellen von Schwellwerten im „AS-Spring Format“, gibt es noch einen Editor. Endloses Klicken führt zum gewünschten Ergebnis. Letztendlich werden alle Rules in Konfigurationsfiles (.cfg) gespeichert. Wer mehr als nur ändern will, sollte die Erstellung automatisieren.

Zur individuellen Organisation der RuleSets erstellt man sich eine eigene Struktur von RuleSetFoldern und RuleSets. Inhalte und Struktur aller Folder werden in einem entsprechenden Verzeichnissystem auf der Festplatte gespeichert. „Virtual Backup Folder“ sucht man hier natürlich vergebens. Suchfunktionen und mehr Hinter der Oberfläche können sich durchaus mehr als eine Million Rules verbergen. Trotz einer guten Struktur ist der Überblick schnell verloren. Starke Suchfunktionen, die z. B. den Einsatz regulärer Ausdrücke erlauben, sind unabdingbare Hilfen. Das Gesuchte lässt sich schnell als Grundlage zur Generierung neuer RuleSets verwenden. Eine wirklich gute Idee ist es, die Suchergebnisse in einem Report abzuspeichern. Allerdings ist die „Reportmaschine“ immer noch verbesserungswürdig.

Abb. 4: Der Schwellwerteditor machts lesbar.

Abb. 2: Mehr Überblick durch die nützliche Reportfunktion.

Besonders nützlich ist die Vergleichsmöglichkeit von RuleSets. Alte können mit aktuellen oder RuleSets eines Agenten mit denen eines anderen verglichen werden. Unterschiede zwischen den Konfigurationen macht man hiermit schnell und einfach transparent.

Abb. 3: Hilfreich: Vergleichsfunktionen.

Rules fehlerfrei erstellen und verändern ist leichter gesagt als getan. Das folgende Beispiel macht den unübersichtlichen und nur schwer lesbaren Aufbau deutlich:

10

Zusätzlich bietet das AS_CHANGESPRING.km über KM-Menükommandos eine ganze Palette von Möglichkeiten zur Generierung von Rules, z. B. das Auslesen von KM nach Parametern. Leider funktioniert es nur über eine Developer Konsole. Apply Wie ordnet man dem Agenten seine Rules und seine Agentenvariablen zu? Mit der Maus zieht man eine oder mehrere Rules, RuleSets oder RuleSetFolder auf einen Agenten oder eine Gruppe. Dieser Vorgang kann beliebig wiederholt werden. Die Zuordnungen sind direkt am Agenten, nicht aber an der Gruppe sichtbar. Durch ein „Apply“ (Menü oder Toolbar) werden die Zuordnungen gesendet und verschwinden anschließend aus dem Agenten-Window. Die Sichtbarkeit der Zuweisung ist also nur temporär. Über eine Liste kann man genau bestimmen, welche Agenten angesprochen werden sollen. Außerdem kann man festlegen, dass vor dem eigentlichen „Apply“ ein Backup der Konfiguration angelegt wird. Ein Job Status informiert über den Verlauf der Transaktionen. Einzelheiten findet man in den RuleSetFoldern „tlog“ und „queue“.

System Management

Die dauerhafte Zuordnung von RuleSets und RuleSetFoldern erreicht man, wenn man sie auf einen oder mehrere „ApplyOnNew“ Symbole zieht. Ein einfaches „Apply“ (Menü/Toolbar) führt hier allerdings nicht zum Erfolg, es sei denn, „ApplyOnApply“ auf der jeweiligen Zuordnung ist aktiviert. Der Trick des „ApplyOnNew“ ist, dass dem Agenten oder der Agentengruppe, die neu in die Gruppe kommen, die zugeordneten Agentenvariablen automatisch zugesandt werden.

Wenn es stört, deaktiviert man „ApplyOnNew“.

Das „ApplyOnNew“ kann ebenfalls per Kontextmenü des Symbols gestartet werden. Vor dem eigentlichen „Apply“ kann man per Dialogfenster genau bestimmen, welche Konfigurationen aus welchen Gruppen zu welchen Agenten geschickt werden. Um sicher zu gehen, sollte man das vorher genau austesten.

Der Configuration Manager war/ist Bestandteil von „AgentSpring“ und nutzt systematisch das PSL Override. Eine durchaus gute Idee. Die entsprechenden Agentenvariablen beginnen alle mit „AS“. Die Syntax der Werte unterscheidet sich allerdings von der der Tuningvariablen. Wer damit gearbeitet hat, vertut sich leicht. Ein vergleichsweise harmloses Problem. Schlimmer ist die Möglichkeit des gleichzeitigen, konkurrierenden Einsatzes der verschiedenen Override Methoden. Von einem definierten Zustand kann dann keine Rede mehr sein. Entschließt man sich zu einer der Methoden, kann das Deaktivieren der nicht genutzten Methoden sinnvoll sein.

Noch ein Override Die Schwellwerte für Parameter kann man mit vier Methoden einstellen:

• • • •

Developer Override (Developer Konsole) innerhalb der KM (aus verschiedenen Gründen nicht zu empfehlen) Operator Override (Tuningvariable) External Override (External Files) PSL Override (z. B. aus einem „intelligenten“ KM heraus)

Fazit Der PATROL Configuration Manager braucht einen Manager, der genau weiß, was er tut! Äußerste Sorgfalt ist Pflicht, sonst geht der Schuss nach hinten los. Trotzdem, dieses GUI bietet schon eine ganze Menge Möglichkeiten. Von der Vision eines definierten Zustands aller Agenten bis zu ihrer Realisierung gibt es allerdings viel zu tun. Abb. 5: Dialogfenster zum automatischen konfigurieren mit „ApplyOnNew“.

Ulrich Meyer ([email protected]).

Seminarvorstellung: PATROL Advanced Der Teilnehmer vertieft in diesem Seminar seine Kenntnisse im Umgang mit dem Monitoring-Tool PATROL und dessen Administration. Neben interessanten Tuning- und Sicherheitsaspekten werden auch die Grundlagen für den effizienten Umgang mit zentralen Komponenten der PATROL Architektur, wie z. B. dem Consolen Server PATROL Central und dem Distribution Server behandelt. Das Seminar ist eine gute Vorbereitung auf das Seminar „PATROL Customizing and Development“. Voraussetzungen Die Schulung ist ausgerichtet auf Teilnehmer, die schon tiefergehende, praktische Erfahrungen im Umgang mit PATROL haben oder das Seminar “PATROL Basics” besucht haben. Kenntnisse des Betriebssystems Unix und/oder Windows. Zielgruppe Fortgeschrittene PATROL Administratoren, Entwickler von Knowledge Modulen.

Inhalte

• • • • • • • • • •

PATROL Agenten-Tuning Sicherheitsaspekte Fortgeschrittene Agentenkonfiguration Erweitertes Event Management - Benachrichtigung per E-Mail oder Pager - Filtern und Anpassen von Events - Zentrales Event Management Fehleranalyse und Debugging Einführung in Konzepte und Umgang mit dem Distribution Server Migrationstechniken und Werkzeuge PATROL Central: Installation und Administration PATROL Lizenzverwaltung mit OneKey Übungen

Dauer: 5 Tage

Kursgebühr/Teilnehmer: 2.050,00 Euro

Termine 16.02.2004 - 20.02.2004 in Wiesbaden 05.07.2004 - 09.07.2004 in Wiesbaden 11.10.2004 - 15.10.2004 in Wiesbaden

Aktuelle Termine finden Sie jederzeit auch im Internet unter http://training.ordix.de.

11

Unix/Linux/Open Source

Knoppix à la Carte Linux ist überall - egal ob auf Enterprise-Servern, Desktop-PCs oder einfach nur als CD-Beilage einer Zeitschrift. Letzteres wird aktuell gern als sogenannte Live-CD geliefert.

Basis für diese Live-CDs ist typischerweise Knoppix. Knoppix ist eine spezielle Linux Version, die direkt von der CD gestartet werden kann. Natürlich will jemand, der eine solche Knoppix CD verteilt, dieser gerne seinen eigenen Stempel z. B. in Form von Hintergründen „aufdrücken“. Wie dies möglich ist, soll dieser Artikel am Beispiel der Knoppix Variante „Morphix“ zeigen.

Das Basemodule ist für alle Morphix Varianten gleich. Es stellt den Bootloader sowie ein minimales Rootfilesystem zur Verfügung, das die Logik zum Starten des Mainmodules enthält. Es wird als CD-Abbild im Format ISO9660 zum Download angeboten.

Das Menü

Das Mainmodule stellt das Kernsystem inklusive einem gewissen Satz an Applikationen und Libraries, die für dessen Betrieb benötigt werden. Die Minimodules schließlich bieten eine Sammlung von Applikationen für jeweils ein bestimmtes Thema (security, wine, printing, ...). Mit Hilfe dieser Minimodules lässt sich das gewählte Mainmodule um Funktionalitäten erweitern.

Zu Beginn eines eigenen Knoppix Projekts muss man sich zunächst überlegen, welche Anforderungen das endgültig entstehende Linux erfüllen soll. Soll das System möglichst kompakt sein, damit es als Rescue System auf eine CD mit der Größe einer Visitenkarte passt? Oder ist ein vollwertiges Linux mit Desktop Umgebungen wie GNOME oder KDE und Office Suite das Ziel? Bevor man sich über diese Fragen den Kopf zerbricht, sollte man zunächst einen Blick auf die Liste der Knoppix-Derivate unter (http:/ /www.knoppix.net/docs/index.php/KnoppixCustomizations) werfen. Dort findet man zahlreiche Varianten, die entweder für ganz spezielle Zwecke angepasst wurden, oder aber als Basis für die eigene Knoppix Distribution dienen können. Letzteres wird meist durch Verzicht auf eines der großen Desktop Pakete oder durch Verzicht auf eine Anzahl von Applikationen erreicht. Auffällig ist vor allem die Variante mit dem Namen „Morphix“.

Main- und Minimodules werden als Dateien mit der Endung „.mod“ angeboten. Dahinter verbirgt sich ebenfalls ein ISO9660 Filesystem, das dann aber noch komprimiert wird, um Platz auf dem Medium zu sparen. Im Betrieb wird später ein „compressed Loopdevice“ benutzt, um die Dateisystemabbilder der Module in den Verzeichnisbaum einzuhängen.

Hauptgericht und Beilage

In die Küche geschaut

Morphix (http://www.morphix.org) ist eine modularisierte Version von Knoppix und besteht aus einem „Basemodule“, einem „Mainmodule“ und beliebig vielen „Minimodules“. Das Limit setzt hierbei der Platz auf dem Medium, der neben Base- und Mainmodule noch übrig ist.

Das Basemodule liefert alle benötigten Verzeichnisse bereits mit. Der Aufbau ist selbstsprechend. Neben dem Bootsektor enthält das Baseimage das Verzeichnis base, und zwei leere Verzeichnisse mainmod und minimod. Um ein Modul einzubinden, muss einfach die entsprechende „.mod“-Datei in das entsprechende Verzeichnis kopiert werden. Das Abbild des root-Filesystems in „/base/morphix“ ist nur für den reinen Systemstart und das Einbinden der Module zuständig. Es enthält nur das Nötigste, wie z. B. die fileutils (ls, cp, ...) und das cloop Paket zum Lesen der komprimierten Images. Alle weitergehenden Anwendungen werden durch das Einhängen eines Main- oder Minimodules bereitgestellt. Die Abbildung 1 soll den verschachtelten Aufbau einer Morphix CD verdeutlichen.

Abb. 1: Aufbau einer Morphix CD.

12

Damit einem ersten Test des Morphix Systems keine allzu große Hürde im Weg steht, gibt es bereits fertige ISO-Abbilder. Empfehlenswert

Unix/Linux/Open Source

ist das Image HeavyGUI, da es mit GNOME 2.2 einen komfortablen Desktop bietet und gleichzeitig aber auch noch circa 200 MB Platz für (eigene) Minimodules lässt. Das Rezept Die Funktionalität eines Minimodules ist recht schnell erklärt. Es enthält ein Shellskript mit dem vereinbarten Namen „loadmod.sh“, das nach dem Einhängen des Moduls in den Dateibaum ausgeführt wird. Für das Einfügen größerer Pakete gibt es morphixspezifische Techniken, die den Rahmen dieses Artikels sprengen würden. Daher soll hier nur ein einfaches Beispiel, nämlich das Austauschen des Desktop Hintergrunds erklärt werden. Folgende Struktur ist in einem solchen Minimodule vorhanden:

•

minimod/morphix/main_module Enthält den Namen des Mainmodules, zu dem dieses Minimodule kompatibel ist. Typischerweise enthält die Datei nur das Wort “ALL”.

•

minimod/morphix/files/neuer_bg.png Neues Hintergrundbild.

•

minimod/morphix/loadmod.sh Skript, das die eigentlichen Anpassungen zur Laufzeit vornimmt.

•

minimod/morphix/mini_module Namen und erklärender Text zu diesem Minimodule.

Den Inhalt von loadmod.sh entnehmen Sie bitte der Abbildung 2. Wichtig: Wenn mehrere Minimodules zum Einsatz kommen, kann der Mountpoint im später laufenden System variieren, je nachdem, welches Minimodule zuerst eingehängt wird. Damit der Kopiervorgang klappt, wird der aktuelle Mountpoint an „loadmod.sh“ als Argument übergeben und dann im Quell-Argument des „cp“ ausgewertet. Wie man sieht, wird die bestehende Hintergrunddatei einfach überschrieben. Zwar könnte man auch die Datei im Mainmodule austauschen, aber der Vorteil der Modules besteht gerade darin, die Hauptmodules durch Minimodules anzupassen. Bei einem Versionswechsel der „offiziellen“ Morphix-Module muss somit keine Nacharbeit geleistet werden, da man am Mainmodule direkt keine individuelle Anpassung vornehmen muss.

Abb. 2: Die verschiedenen Aufrufe, die im Laufe der Erstellung des Minimodules zum Einsatz kommen.

Es wird angerichtet Der nächste Schritt besteht darin, das erzeugte Minimodule in ein ISO9660 Image zu verpacken und dieses danach zu komprimieren. Ersteres erledigt z. B. der Aufruf in Abbildung 2. (Mkisofs ist Bestandteil des Pakets „cdrtools“. Eine Dokumentation der verwendeten Parameter befindet sich ebenfalls darin.) Die Kompression des temporären Images temp_mini.iso erledigt das Programm compressloop aus dem Paket cloop. Wenn dieses Paket nicht installiert ist, gibt es die Möglichkeit, die Binaries durch das Archiv „tools.tar.gz“ aus dem Downloadbereich von morphix.org zu beziehen. Das endgültige Minimodule wird dann, wie in Abbildung 2 gezeigt, erzeugt. Hierbei ist zu beachten, dass der Name im Format „MorphixMini-*.mod“ bindend ist. Nachdem das oben erwähnte HeavyGUI CD-Abbild in den lokalen Dateibaum eingehängt wurde, kann man nun das so erstellte Minimodule ohne weitere Anpassungen direkt in das Verzeichnis minimod kopieren (siehe Abbildung 2). Danach kann das Image mit einer beliebigen Software auf CD geschrieben werden. Beim booten von Morphix wird das abgelegte Minimodule automatisch erkannt und eingebunden. Lecker ... Dank Morphix ist es mit wenig Zeitaufwand möglich, eine eigene „customized“-Knoppix Version zu erstellen. Selbst wenn keine unternehmensspezifischen Anpassungen vorgenommen werden sollen, ist das Zusammenstellen der Applikationen für die eigene Variante mit Morphix auf Grund des Modulkonzepts sehr einfach. Wer dennoch Software vermisst, kann das System mit Hilfe einer Mastering-Installation an seine Wünsche anpassen. Ein Blick in die HowTo’s auf Morphix.org ist hierbei zu empfehlen. Michael Heß ([email protected]).

13

Datenbanken - Titelthema Tuning

Tuning I/O-intensiver Systeme (Teil I) Bei komplexen Datenbanksystemen ist es oft sehr schwierig festzustellen, welches die tatsächlichen Ursachen für schlechte Antwortzeiten sind. Welchen Anteil haben I/O-Probleme an der gesamten Datenbanklast? Wie sind diese genau zu messen und letztendlich zu beseitigen? Im Zuge dieses Artikels werden nur lesende I/O-Vorgänge detailliert betrachtet. Natürlich stellen auch immer wieder schreibende Zugriffe wie Checkpoints oder der Flush des Log Buffers signifikante I/O-Probleme dar. Wesentlichen Einfluss auf die Performance von I/O haben selbstverständlich das Betriebssystem sowie die Plattenkonfiguration. Eine hervorragende Ausarbeitung findet sich beim Oracle Technology Network unter dem Titel „S.A.M.E Stripe and Mirror Everything“ (http://otn.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf). Der vorliegende Artikel bezieht sich ausschließlich auf Oracle Mittel und ist somit weitgehend betriebssystemunabhängig. Beispiel I Eine Aussage, die in der Praxis immer wieder zu hören ist, lautet etwa wie folgt: „Unsere Batchverarbeitung schafft nur vier Sätze pro Sekunde“. Tatsächlich handelt es sich dabei in der Regel um vier logische Sätze wie Konten, Kunden oder ähnliches, deren Bearbeitung aus diversen SQL Befehlen besteht. Selbst wenn die SQL Befehle bereits optimiert sind, die Buffer Hit Ratio einen Wert von über 95 Prozent einnimmt und das Plattensystem nicht ausgelastet ist, kann es sich hierbei um ein I/O-Problem handeln. Die Analyse erfolgt typischerweise mit den Oracle Trace Facilities TKPROF oder dem Trace Analyzer. Werden für mehrere SQL Anweisungen jeweils wenige I/O ausgeführt, differiert die CPU Zeit von der Elapsed Zeit deutlich. Dies liegt ganz einfach darin begründet, dass ein I/O mit wenigen Millisekunden etwa genauso lange dauert, wie dutzende SQL Befehle, die ohne I/O auskommen. Lässt sich der I/O stark reduzieren oder komplett vermeiden, so erhöht sich der Durchsatz oft um Faktoren.

Klassifizierung von I/O-intensiven Systemen.

14

Beispiel II Eine zweite, typische Aussage lautet etwa wie folgt: „Unsere Buffer Hit Ratio liegt bei über 95 Prozent. Also können wir kein I/O-Problem haben.“ Unabhängig von Trefferquoten sind SQL Befehle zu analysieren, welche eine bestimmte Menge an I/O verursachen. Bei 720 Millionen logical Reads und 720 Tausend physical Reads in einer Stunde ergibt sich eine Trefferquote von über 99 Prozent. Dennoch werden pro Sekunde 200 I/O abgesetzt. Werden diese I/O durch z. B. 30 Benutzer verursacht, so muss jeder Benutzer bei Antwortzeiten von 7 msec pro I/O in dem Messzeitraum von einer Stunde insgesamt 168 Sekunden warten. Bei OLTP Systemen sicherlich nicht akzeptabel. Klassifizierung Allgemein formuliert, lassen sich I/O-intensive Systeme wie folgt klassifizieren. Die erste Dimension beurteilt die Antwortzeit des I/OSystems nach hoch/gering. Die zweite Dimension misst die Anzahl der Sessions auf dem Datenbanksystem. Natürlich lässt sich in der Praxis selten eine exakte Einstufung vornehmen. Dennoch finden sich eine oder mehrere Teilkomponenten in fast jeder Datenbank wieder. Die Abbildung zeigt die Klassen von I/Ointensiven Systemen. -

Geringe I/O-Zeit – wenige Sessions: Ein oder wenige Batch Prozesse sind langsam. Die Trefferquote ist gut, aber die absolute Anzahl an I/O ist für 80 Prozent der Laufzeit verantwortlich. Der Batch-Job kann um Faktor 4 verbessert werden, indem der I/O beseitigt wird.

-

Geringe I/O-Zeit – viele Sessions: Die meisten Anwender sind wahrscheinlich zufrieden. Oft existieren aber verschiedene Abfragen, die hunderte oder tausende von I/O durchführen. Bei 1.000 I/O und einer Antwortzeit von 7 msec ergeben sich 7 Sekunden für den Aufbau einer Bildschirmmaske. Durch bessere Ausführungspläne können diese Abfragen häufig deutlich verbessert werden.

Datenbanken

-

-

Hohe I/O-Zeit – wenige Sessions: Dies ist ein typisches Bild für ein sehr stark ausgelastetes Data Warehouse System. Wo immer möglich, muss I/O reduziert werden. Wahrscheinlich haben Full Table Scans einen hohen Anteil am I/O. Eventuell reduziert sich das Datenvolumen durch Partitionierung, Komprimierung oder Materialized Views. Je mehr I/O entfällt, desto besser wird die Antwortzeit des verbleibenden I/O.

Mythen „Die CPU Wait I/O zeigt an, wenn das System I/O-intensiv ist.“ Tatsache ist jedoch: Zeigt die CPU einen hohen Anteil an Wait I/O, so kann zwar häufig, aber nicht grundsätzlich von einem I/O-Problem ausgegangen werden. Der Umkehrschluss, wenig Wait I/O gleich kein I/OProblem ist nicht zulässig! Zeigt die CPU beim Wait I/O einen niedrigen Wert an, so kann es trotzdem ein I/O-Problem geben. Die CPU geht in den Status Wait I/O, wenn der aktuelle Prozess einen I/O-Auftrag abgesetzt hat und kein weiterer Prozess in der Queue des Prozessors steht. So gesehen stellt der Wait I/O eine besondere Form von Idle dar. Wait I/O könnte man wie folgt beschreiben: Die CPU hat nichts anderes zu tun, als auf I/O zu warten. Übrigens, beim Einsatz eines SAN ist die Interpretation dann noch etwas schwieriger.

Hohe I/O-Zeit – viele Sessions: Dies ist ein typisches Bild für ein stark ausgelastetes OLTP System. Wo immer möglich, muss I/O reduziert werden. Es ist zu prüfen, inwieweit Full Table Scans und Sortieren auf Platte stattfinden. Mit Partitionierung und Komprimierung können in einzelnen Fällen gute Ergebnisse erreicht werden. Die Verwendung von Multiplen Buffer Pools ist immer dann zu untersuchen, wenn sehr große Tabellen viel Platz im Block Buffer verwenden. Auch hier gilt, je mehr I/O entfällt, desto schneller wird die Antwortzeit des verbleibenden I/O.

„Eine Buffer Hit Ratio von 98 Prozent oder mehr ist super, der I/O muss nicht mehr betrachtet werden.“ Auch hier handelt es sich um einen weit verbreiteten Mythos. Tatsächlich können auch bei hohen Trefferquoten schlechte Antwortzeiten auftreten. „Bei einer Buffer Hit Ratio von 100 Prozent müssen SQL Befehle nicht verbessert werden.“ Hier können in der Regel noch reichlich SQL Befehle verbessert werden. Dies stellt aber nicht den Fokus dieses Artikels dar. „Je höher die Buffer Hit Ratio ist, um so besser“. Dies kann mit folgendem Beispiel widerlegt werden. Annahme: Werden bei einer Buffer Hit Ratio von 95 Prozent die logical Reads verringert und die physical Reads bleiben gleich, folgt daraus ein besser laufendes System und eine schlechtere Buffer Hit Ratio. Tatsache ist also: je weniger physical und/oder logical Reads, desto besser läuft das Datenbank System.

Rechtsstehend finden Sie einige Mythen, mit denen wir an dieser Stelle einmal „aufräumen“ möchten. In der kommenden Ausgabe, erfahren Sie mehr über Werkzeuge zur Analyse von I/OProblemen und Techniken zur Behebung.

Martin Hoermann ([email protected]).

Seminarvorstellung: Oracle Tuning und Monitoring Der Teilnehmer lernt anhand der vorhandenen Werkzeuge, Oracle Datenbanken zu analysieren und Performance-Maßnahmen durchzuführen. Voraussetzungen Tiefergehende Kenntnisse des Betriebssystems Unix oder Windows. Tiefergehende Kenntnisse der Oracle Verwaltung oder Teilnahme an den Seminaren „Oracle Datenbankadministration Grundlagen“ und „Oracle Datenbankadministration Aufbau“. Zielgruppe Datenbankadministratoren, Softwareentwickler, Systembetreuer. Termine 22.03.2004 10.05.2004 23.08.2004 25.10.2004 06.12.2004

-

26.03.2004 14.05.2004 27.08.2004 29.10.2004 10.12.2004

in in in in in

Wiesbaden Lippstadt Wiesbaden Wiesbaden Wiesbaden

Die Termine finden Sie auch immer aktuell im Internet unter http://training.ordix.de.

Inhalte

• • • • • • • • • • • •

Überblick: Tuning-Ziele setzen, methodisches Tunen und Analysieren Mögliche Engpässe erkennen, eventbasiertes Tunen Oracle Interna, Semaphoren, Latches, Speicherstrukturen Indexstrukturen: Indexarten, Implementierung, neue Oracle Indexfeatures SQL-Monitoring: EXPLAIN PLAN, die Struktur der PLAN_TABLE, SQL Trace, die tkprof-Ausgabedatei und ihre Interpretationen, Nutzung der v$-Tabellen Erkennen von Hot SQLs Der Optimizer: Methoden, der ANALYSE-Befehl, Paket Prozeduren Speicherbereiche optimieren, Erkennen von Hot Blocks I/O Optimierung, Platten I/O, Problem-SQLs erkennen, Wartezustände finden Datenbank-Monitoring: Virtuelle Tabellen, Statistikprozeduren, UTLBSTAT/UTLESTAT, Interpretation von Reports Wichtige Statistikparameter, Events und init.ora Parameter Sperrmechanismen: Oracle Sperrverhalten, Deadlocks, Anzeigen/ Auflösen von Sperren, Zugriffskonflikte vermeiden

Dauer: 5 Tage

Kursgebühr/Teilnehmer: 2.190,00 Euro

15

Java/XML

Die eSelect Suite, Teil VI:

Electronic Advisor: Lösungen für problemorientierte Beratung Die eSelect Suite ist ein Framework zum universellen Einsatz in eBusiness Projekten. In Vorbereitung auf die komplexer werdenden Geschäftsprozesse, die insbesondere online abgebildet werden müssen, hat die Beteiligungsfirma der ORDIX, Object Systems in Essen, Komponenten realisiert, die die Konfiguration und den Vergleich von komplexen, variantenreichen Prozessen und Produkten unterstützen bzw. abbilden. Dabei wird Konfiguration nicht nur als Zusammenstellen eines konkreten Produktwunsches (z. B. eines PCs) verstanden, sondern es wird noch einen Schritt weitergegangen und auf Basis der Konfigurationskomponenten die ziel- und problemorientierte Beratung eines Kunden ermöglicht.

EDV-gestützte Beratung eines Kunden Der Kunde sollte nicht nur in die Lage versetzt werden, ein konkretes Produkt nach seinen Präferenzen zu konfigurieren, sondern gemäß seinen Zielen und individuellen Kundendaten ein Produkt, einen Tarif oder eine Strategie auszuwählen. Die technische Abwicklung und die zugrunde liegenden Komponenten der eSelect Suite sind dabei in beiden Fällen gleich. Die Modellierung des Konfigurationsproblems bewegt sich lediglich auf einem abstrakteren Niveau. So kann das zu konfigurierende „Produkt“ eben auch eine Anlagestrategie, ein Werbemedium oder ein Wertpapierportfolio sein. Gerade im Bereich der Beratung werden meist nur sehr simple Lösungen abgebildet, bei denen die Menge der möglichen Lösungen feststeht und sehr begrenzt ist. Der Benutzer arbeitet sich durch einen vordefinierten Entscheidungsbaum. Komplexe Beratungsprozesse können jedoch auf diese Weise nicht abgebildet werden, weil die große Menge der möglichen Beratungsergebnisse nicht vorab definiert bzw. gepflegt werden kann. Der Prozess ist dynamisch und hängt z. B. von aktuellen Marktbedingungen ab. Ein System, das den komplexen und dynamischen Beratungsprozess abbilden kann, kennt „nur“ die Basiskomponenten des Beratungsprozesses: Ein Parametersystem sorgt für die effektive Aktualisierung und ein Regelsystem sorgt dafür, dass nur gültige und erfüllbare Beratungsergebnisse gebildet werden, während der Kunde seine Wünsche und Ziele formuliert. Lesen Sie zum Thema Regelsystem auch den Artikel „Die eSelect Suite, Teil V: SCSI-Festplatte nur in Verbindung mit SCSI-Controller! - Das Regelwerk der eSelect Suite“ in der ORDIX News, Ausgabe 3/2003. Im Folgenden werden Beratungs-Szenarios beschrieben, die auf Basis der Komponenten der eSelect Suite entworfen und ansatzmäßig als Prototypen umgesetzt wurden. Die Ergebnisse dienten als Evaluierungbasis in Kundenprojekten.

16

„Welche Anlageformen sind für mich die richtigen?“ Ziel dieses Systems ist z. B. die elektronische Unterstützung bei der Anlage und Optimierung von Kundendepots für Wertpapiere. Beratungsprozess Der Beratungsprozess beinhaltet die Basiskomponenten Kunde, Kundenportfolio und Aktie/Fond, deren Struktur in den Abbildungen 1 - 3 vereinfacht dargestellt ist. Kunde Tätigkeit (Ausbildung, Angestellter, Selbstständiger, Rentner u. a.) Familienstand (Ehe, Kinder, u. a.) Besitz von Wertpapieren (Depots, Aktien und Rentenpapiere) Immobilien (Art, Wert, u. a.) Verfügbares Einkommen (monatliche Einnahmen und Ausgaben, Verfügbar) Liquidität Kapitalrücklage Altersvorsorge Abb. 1: Die Struktur der Basiskomponente „Kunde“.

Kundenportfolio Depotstruktur (Verhältnis Aktien:Renten) Risikoklasse des Kunden Rentenanlage Aktienwerte Depotsumme Abb. 2: Die Struktur der Basiskomponente „Kundenportfolio“.

Java/XML

Aktie/Fond Name Branche Kurs Riskoklasse (Kursrisiko) Volumen Bewertung Abb. 3: Die Struktur der Basiskomponente „Aktie/Fond“.

Schritt 1: Finanzstatus-Analyse Der Kunde kann seine finanzielle Situation auf Basis der erfassten persönlichen und finanziellen Angaben analysieren lassen. Die Analyse seines Finanzstatus erfolgt bezüglich der Parameter Liquidität (L), Kapitalrücklage (K) und Altersvorsorge (A). Das Analyseergebnis wird anhand eines Punktesystems bezüglich der Analysebereiche L/K/ A ermittelt. Die Punktebewertung ist dabei nicht fest in der Anwendungslogik verdrahtet, sondern kann dynamisch angepasst werden. Ergebnisse werden anhand einer Punktetabelle mit Kundendaten auf der y-Achse und der Analysebereiche auf der x-Achse dargestellt. Pro Analysebereich und je nach Punktezahl können die folgenden Ergebnisse ermittelt werden:

• • •

Es besteht Handlungsbedarf (roter Bereich) Versorgung ist verbesserungswürdig (gelber Bereich) Bereich ist gut abgedeckt (grüner Bereich)

Ist Handlungsbedarf angezeigt, kann der Kunde wählen, ob er einen Einmalbetrag anlegen will oder ob er sein Depot umschichten möchte. Er gelangt zur Portfolio-Konfiguration. Schritt 2: Portfolio-Konfiguration Ausgangspunkt ist das bestehende Portfolio des Kunden. Bei der Anlage eines Portfolios wurden im Vorfeld die folgenden Grundlagen geschaffen: 1) Das System kennt die in Abbildung 4 gezeigten Anlagestrategien. Liquidität: Ertrag: Wachstum: Vorsorge:

80 – 100 % Rentenanlagen, 0 – 20 % Aktienwerte 50 – 80 % Rentenanlagen, 20 – 50 % Aktien 50 – 80 % Aktien, 20 – 50 % Renten 80 – 100 % Aktien

Abb. 4: Mögliche Anlagestrategien.

Für jede Strategie wird eine optimale Depotstruktur definiert, die dynamisch an Marktverhältnisse angepasst werden kann (z. B. Strategie Ertrag: 66 % Renten, 34 % Aktien). Es existieren Toleranzgrenzen bzw. Wertebereiche, innerhalb derer sich die Depotstruktur bewegen muss. 2) Jedem Kunden wird eine Risikoklasse zugeordnet. Sicherheitsorientiert (1) Konservativ (2) Gewinnorientiert (3) Risikobewusst (4) Abb. 5: Die Einteilung der Kunden erfolgt in mögliche Risikoklassen.

Risikoklassen legen fest, welche Aktien/Fonds gewählt werden dürfen/können. Weiterhin ergeben sich aufgrund der Risikoklassen Einschränkungen für die dem Kunden zur Verfügung stehenden Anlagestrategien. Der Kunde kann nun die aktuelle Strategie beibehalten oder eine andere wählen. Das System kann dem Kunden auch eine optimale Strategie vorschlagen bzw. der Kunde kann sich nach getätigter Konfiguration Alternativmöglichkeiten anzeigen lassen. Er kann Wertpapiere regelbasiert auswählen und abwählen. Dabei sieht er nur Wertpapiere, die seiner Risikogruppe entsprechen. Entsprechend den Änderungen werden die Auswirkungen auf die Analysebereiche L/K/A visualisiert (Finanzstatus-Tachometer). 3) Diverse Regeln (siehe Abbildung 6) garantieren die Gültigkeit und Richtigkeit einer Portfolio-Konfiguration.

• • • • • • •

Depotstruktur muss der gewählten Strategie entsprechen (in diesen Grenzen liegen). Depotstruktur sollte der optimalen Depotstruktur entsprechen. Risikoklasse des Wertpapiers (*,.02468:<

>

ORDIX auf dem BMC Forum

Wer in der IT-Welt neue Horizonte entdecken wollte, dem lieferte das diesjährige BMC Software Forum das richtige Programm, wenn es um neueste Lösungen für die IT-Branche ging. Unter dem Motto „Go Beyond Convention“ waren im passenden Ambiente des Lufthansa Flight Training Centers in Frankfurt am 25./26. November namhafte Fachreferenten und Keynote-Speaker geladen. Als erfahrener Berater im Bereich System Management hielt u. a. ORDIX einen Fachvortrag zum Thema „PATROL for SAP Solution Suite bei einer Großbank“. Herr Uwe Rübesamen erläuterte in dem Kunden-Erfahrungsbericht die Möglichkeiten und Grenzen zu diesem Thema. Hinzu kamen weitere Success-Storys und Partner-Solutions sowie ITService-Management-Umsetzungen von Remedy. Zwischen den Vorträgen fand sich immer wieder die Gelegenheit zum persönlichen, intensiven Kontakt auf der Partnerausstellung in der Simulatorenhalle. Vertreten waren neben ORDIX auch SAP Systems Integration, ITConcepts, Materna, TrilogExpert und ACT IT-Consulting & Services. Neben der unkonventionellen Location und dem wertvollen Know-how erwartete die Gäste am Abend des 25. Novembers auch ein festliches Event. Es fand sich spätestens auch hier wieder die gute Gelegenheit, neue Kontakte zu knüpfen, sich mit anderen IT-Spezialisten auszutauschen - oder ganz einfach nur den Abend zu genießen!

(

Open Source Engagement verstärkt

Seit Oktober 2003 ist ORDIX „SUSE Business Advanced Partner“ sowie „Support Partner“. ORDIX ist bereits seit Mitte des Jahres 2003 SUSE Partner. Durch diese Partnerschaft und das Sponsoring des „Linux Professional Institute German“ (LPI German) unterstützen wir zum einen unser langjähriges Open Source Engagement, zum anderen erweitern wir damit aber auch unser Produkt- und Dienstleistungsspektrum im Bereich Linux. Neu im Schulungsangebot ist z. B. der Ausbildungsgang Linux zur LPI-Zertifizierung. Interessierte Kunden können zudem alle Business Produkte der SUSE LINUX AG über ORDIX beziehen - selbstverständlich mit der zugehörigen, kompetenten Dienstleistung. Und last but not least ... sind unsere Linux-Mitarbeiter natürlich auch LPI zertifiziert!

*

Neues Web-Design für Traditionsbetrieb Dahlhoff – oder: Wie die Feinkost in den Magen kommt ...

Die Zeiten, in denen der Weg von gutem Essen direkt „von der Hand in den Mund“ führte, sind längst vorbei. Schon alleine, weil die Feinkost nicht immer im sprichwörtlichen Sinne „zum Greifen nahe“ liegt, sondern auch gerne mal aus Cuxhaven oder Haltern kommen darf. Die Dahlhoff Feinkost GmbH tat nun einen wichtigen Schritt, um diesen alten Sprichworten wieder Bedeutung zu schenken: Mit Hilfe von ORDIX hat das Unternehmen Dahlhoff seinen Internetauftritt neu konzipiert und gestaltet, um seinen Bekanntheitsgrad zu steigern. ORDIX hatte dabei eine schwierige Gratwanderung zu bewältigen. Durch einen abgestimmten Mix an Bild- und Textmaterial sollten sowohl die Endverbraucher als auch der Einzelhandel angesprochen werden. Das traditionsreiche Unternehmen mit Hauptsitz in Haltern am See und weiterem Produktionsbetrieb in Cuxhaven entschied sich dafür, seinen alten Internetauftritt moderner gestalten zu lassen und nutzte dabei den Full-Service der ORDIX AG. ORDIX erstellte ein neues Konzept unter Wahrung der Corporate Identity für eine lebendig wirkende Internetpräsentation, führte Fotosessions in den Produktionsräumen durch, vermittelte zusätzliche Fotos, entwickelte das neue Erscheinungsbild und arbeitete bei der Textgestaltung mit. Ziel des Auftritts ist eine Präsentation des Leistungsspektrums. Das Ergebnis ist nun schon seit Oktober 2003 unter http://www.dahlhoff.de zu sehen. Gerne steht unser WebServicesTeam auch Ihnen für Fragen zum Thema WebDesign zur Verfügung. Sprechen Sie uns an ([email protected])!

19

Aktuell

Datenbanken? Larry Ratlos:

Ich brauche ein SQL-Programm, welches mir die kürzeste Gesamtzeit berechnet? Nachdem sich Larry Ratlos in der letzten Ausgabe offensichtlich mit einer extrem schwierigen Thematik befasste, will er sich diesmal nach Weihnachten nicht mehr den Kopf zermartern. Stattdessen will er das neue Jahr gedanklich ganz ruhig angehen lassen. Schließlich hat er wichtigere Ziele: Es „lagern“ immer noch einige der Weihnachtskekse in seinem Bauch und um die Hüften. Und sein höchster Vorsatz für das neue Jahr war, diese wieder abzutrainieren. Also macht er sich nach einem langen Arbeitstag mit seinen Kollegen auf zu einem ausgiebigen Spaziergang. Es ist klirrend kalt und nach vier Stunden bester Wanderung möchten die vier nun den kürzesten Heimweg über den Fluss antreten. Dieser führt über einen schmalen Steg. Aufgrund der späten Stunde und ihrer verschieden starken Nachtblindheit möchte niemand unbedingt alleine über den schmalen Steg gehen müssen. Außerdem ist es so dunkel, dass man nicht mal mehr seine Hand vor Augen erkennt. Da der Steg aber nicht mehr sehr stabil ist, können sie nur mit maximal 2 Personen zugleich hinüber gehen. Hinzu kommt, dass sie nur eine Taschenlampe besitzen und deshalb eine Person immer wieder zurück muss, um jeweils einen Kollegen oder eine Kollegin abzuholen.

Können Sie Larry helfen?

Sie bitten Larry, ihnen zu verraten, wie sie am schnellsten alle vier, jeweils einzeln oder zu zweit und immer mit der Taschenlampe ausgerüstet, von der einen Seite des Steges zur anderen gelangen. Da es kalt ist, und alle gemeinsam möglichst schnell nach Hause möchten, steht Larry vor einem Rätsel.

Dann schicken Sie Ihren Lösungsvorschlag bitte bis zum 29.02.2003 an [email protected]. Die Namen und Lösungen von drei Helfern werden wir wieder veröffentlichen. Und Larry wird die Hilfe natürlich auch belohnen.

Er weiß: die flinke Sportskanone Ruth würde bereits nach 1 Minute das andere Ufer des Flusses erreichen. Und auch Ulla würde nach 2 Minuten drüben sein. Doch der dicke Hans würde 9 Minuten benötigen und der behäbige Willi gar ganze 10 Minuten.

Die Lösung des Rätsels aus 3/2003

Larry überlegt sich, diese Daten in einer Datenbank in einer Tabelle abzulegen und die Lösung per SQL zu ermitteln: Dauer 10 9 2 1

22

Wie sollen sie sich nun begleiten, sodass in der kürzestmöglichen Zeit alle vier gemeinsam am anderen Ufer stehen? Schreiben Sie ein Programm, welches die kürzeste Gesamtzeit berechnet. Da Larry ein Fan von SQL ist, sollten sie ihn mit einem kleinen SQL-Programm unterstützen! Kleiner Tipp: Die vier schaffen es schließlich, in 17 Minuten über die Brücke zu kommen.

Name Willi Hans Ulla Ruth

In der letzten Ausgabe der ORDIX News hatte Larry ein Oracle 9i Problem. Larry´s Kollege hatte diverse Buffer Pools eingerichtet. Nun wollte Larry herausfinden, wie viele Blöcke in den verschiedenen Buffer Pools lagen. Außerdem intressierte ihn, wie viel Prozent des Buffer Pools db_2k_cache_size mit Blöcken aus dem Tablespace INDEX_1 (ts# = 7) belegt waren. Die einzige Idee, die er zu dem Problem hatte, war, dass man dazu tiefer in die Instanz sehen, also x$... views verwenden muss.

Aktuell

Im Folgenden wollen wir die Musterlösung der vergangenen Ausgabe vorstellen, die Larry´s smarte Kollegin Kora Koracallis zur Verfügung gestellt hat. Offensichtlich stand diesmal nicht nur Larry vor einem Rätsel, sondern sämtliche unserer News-Leser. Es wagte sich niemand mit einem Vorschlag an dieses Thema heran und so veröffentlichen wir diesmal auch nur die Musterlösung! Die Musterlösung: SELECT b.name buffer_pool, b.buffers, k.set_id, k.blk_size, b.lo_setid, b.hi_setid, b.set_count, k.ckpt_latch, count( * ) FROM x$kcbwds k, v$buffer_pool b, x$bh bh WHERE k.set_id BETWEEN b.lo_setid AND b.hi_setid AND bh.set_ds = k.ckpt_latch AND buffers > 0 -- AND bh.ts# = 7 GROUP BY b.name, b.buffers, k.set_id, k.blk_size, b.lo_setid, b.hi_setid, b.set_count, k.ckpt_latch; Diese Aufgabe war in der Tat schon etwas schwieriger, weil die beiden Tabellen v$bh und v$buffer_pool nur über die undokumentierte Tabelle x$kcbwds zu verbinden sind. x$kcbwds stellt die Speicherstruktur der LRU Listen dar, während die Tabelle v$bh für jeden Block im Block Buffer eine Zeile enthält und die Tabelle v$buffer_pool eine Zeile für jeden Buffer Pool beinhaltet. Jeder Buffer Pool hat eigene LRU Listen (gekennzeichnet durch set_id), jeder Block verweist auf seinen Checkpoint Latch (ckpt_latch), der wiederum die LRU Struktur schützt (set_ds). Wenn man im Skript die Zeile „ -- bh.ts# = 7“ einkommentiert, so beinhaltet die Ausgabe nur Blöcke aus Tablespace 7. Jetzt stellt sich natürlich noch die Frage, wann benötige ich dies überhaupt? In der Regel sind die Statistiken aus statspack schon recht ausführlich und bieten auch zahlreiche Analysemöglichkeiten beim Einsatz von multiplen Buffer Pools. Dennoch ist es in einigen Fällen recht interessant, welche Segmente wie gut in den verschiedenen Buffer Pools gepuffert werden bzw. welche Segmente vielleicht überhand nehmen. Martin Hoermann ([email protected]).

Sie kam, ritt und siegte Sponsoring: ORDIX begleitet Hannelore Brenner bis an die Spitze. Seit mehr als 3 Jahren begleitet ORDIX die behinderte Dressurreiterin Hannelore Brenner. Die Reiterin erzielte in der Vergangenheit grandiose Erfolge bei den Paralympics und zahlreichen deutschen und Europa-Meisterschaften. Zudem ist sie amtierende Weltmeisterin im Grade II. Derzeit setzt sich Ihr Erfolgskurs steiler fort denn je. Von den Deutschen Meisterschaften ... In 2003 konnte Hannelore Brenner ihren Vorjahrestitel als Deutsche Meisterin erfolgreich verteidigen. Dabei stellte sie bei den Deutschen Meisterschaften vom 11. - 14. September 2003 in Lingen mit großem Abstand alle Ihre Mit(st)reiter in den Schatten. „Fabiola und ich sind als Team gut zusammen gewachsen. Es macht Spaß, mit ihr zu arbeiten. Sie ist gelehrig, arbeitet konzentriert und weiß, worauf es in den Prüfungen ankommt“, lobt die Reiterin ihr hochkarätiges Pferd. ... zu den Weltmeisterschaften Hannelore Brenner nimmt es nicht nur mit der nationalen Konkurrenz auf. Sie hat schon lange bewiesen, dass sie ihren Platz auch bei den Weltmeisterschaften der Dressurreiter mit Handicap überaus verdient hat. Als eine von vier Reiterinnen fuhr sie in 2003 vom 2. - 7. September in das belgische Moorsele zu den Weltmeisterschaften. Dort konnten die Reiter zum zweiten Mal in der Geschichte des Dressurreitens für behinderte Menschen auf eigenen Pferden starten. Üblich ist sonst die Zulosung von Leihpferden. Dieses trug maßgebend zu einer positiven Entwicklung der Qualität der Pferde bei. Vielleicht auch ein Grund für die überragende Mannschafts-Silbermedaille. Das deutsche Team, bestehend aus Hannelore Brenner (Grade II) auf Fabiola, Birgit Dreiszis (Grade Ib) auf Fernando, Brigitte Eistel (Grade III) auf Aaron und Cornelia Müller (Grade IV) auf L´Carpo, erreichte 428,12 Punkte. Sie mussten allerdings dem englischen Quartett den Vortritt lassen. Blick in die Zukunft „Um als Reiter in der internationalen Klasse Bestand zu haben, benötigt man stetig gutes Pferdematerial“, so Hannelore Brenner. Sie erwarb deshalb einen jungen Fuchswallach, von dem sie sich ebenso gute Leistungen wie von ihrer momentanen Erfolgs-Stute Fabiola erhofft. Jedoch müssen die beiden bis dahin noch üben, üben, üben ... Stefanie Heither ([email protected]).

23

System Management - Titelthema SAP-Überwachung

SAP-Überwachung mit PATROL Erfahrungsbericht aus einer komplexen Umgebung Im Rahmen eines IT-Projektes wird ein neuentwickeltes SAP-System als Bankenkernanwendung eingesetzt. Die ORDIX AG unterstützte in diesem Projekt bei der Aufsetzung einer Monitoring-Lösung für diese SAPLandschaft. Im folgenden Praxisbericht werden wir die Überwachungslösung mit PATROL for SAP Solutions von BMC näher beleuchten und die konkreten Erfahrungen aus diesem System Management Projekt beschreiben. Dieser Artikel befasst sich mit den definierten Anforderungen und den Überwachungswerkzeugen.

Das eigens für dieses Projekt neu entwickelte SAP-Modul bedient den Bankenkernbereich. Deshalb werden an diese Applikation hinsichtlich Verfügbarkeit und Performance besonders hohe Anforderungen gestellt. Um diesen Anforderungen zu genügen, wurde eine entsprechende Systemarchitektur gewählt und ein umfangreiches Monitoring implementiert. Das zugrunde liegende SAP System besteht aus einer DB2-Datenbank, die auf MVS unter z/OS läuft, aus dem zentralen Applikationsserver unter USS und aus mehreren Applikationsservern unter AIX. Zentraler Applikationsserver bedeutet in diesem Zusammenhang, dass auf dem Applikationsserver unter USS der Message- und der Enqueue-Server laufen. Als interne Systemautomation wird „System Automation for OS/390“ (SAfOS) eingesetzt. Abbildung 1 zeigt die Systemarchitektur noch mal in einer Übersicht. Konzeption der Überwachung Im Rahmen des Projektes wurden zuerst die zu überwachenden Parameter festgelegt, bevor man in die Diskussion über die zu verwendenden Werkzeuge eintrat. Hierzu mussten unter anderem folgende Fragen beantwortet werden: • • • • •

Welche Komponenten sollen überwacht werden? Welche Systemparameter sollen überwacht werden? Lassen sich sinnvolle Abhängigkeiten und Korrelationen definieren? Wo werden Alarme sichtbar? Welche Eskalationsmechanismen werden benötigt? Wer legt die Schwellwerte fest und wie werden sinnvolle Einstellungen ermittelt? Wer legt die Reaktionen fest und welche Maßnahmen sind sinnvoll?

•

Wer ist für Betrieb und Anpassung der Überwachung verantwortlich?

Die daraus festgelegten Anforderungen wurden wie folgt umgesetzt: Zu einem Teil werden die Möglichkeiten der einzelnen Systemkomponenten zur Überwachung genutzt, wie z. B. die Fehlermeldungen der DB2-Datenbank, des SAfOS und des Betriebssystems der AIX-Applikationsserver. Zum anderen werden für den Bereich z/OS, für die Überwachung der Applikationsserver und für das SAP System Überwachungswerkzeuge der Firma BMC zu Hilfe genommen. Für das z/OS ist dies Mainview, die Überwachung der Applikationsserver findet mit PATROL Classic statt und das SAP System wird mit der PATROL for SAP Solution Suite überwacht. Zentrale Störmeldekonsole Um eine einheitliche Bearbeitung aller Störungen zu gewährleisten, sollte eine zentrale Konsole eingesetzt werden, welche in der Lage ist, die Events aller eingesetzten MonitoringKomponenten zu verarbeiten. Für derartige Integrationsanforderungen hat das Unternehmen das Produkt „MasterCell“ im Einsatz. Alle Komponenten wurden über Schnittstellen an die zentrale Störmeldekonsole (ZSK) angeschlossen. Dort laufen die Warnungen und

MasterCell Die Firma IT Masters, die diese MasterCell-Konsole entwickelte, wurde im Verlauf des Projektes Teil der Firma BMC. Die MasterCell-Konsole wird nun als Teil der PATROL Familie unter dem Namen „PATROL Impact Manager“ angeboten. Das Projekt hat den Verantwortlichen gezeigt, wie gut sich diese beiden Komponenten ergänzen. Abb. 1: Systemarchitektur der Anwendung, die mit SAP entwickelt wurde.

24

System Management

Alarme zusammen. Abbildung 2 zeigt einen Ausschnitt der MasterCell-Konsole. Für jedes der definierten Ereignisse hat die verantwortliche Fachabteilung eine Maßnahme festgelegt, die es dem Leitstand ermöglicht, adäquat zu reagieren. Somit ist sichergestellt, dass keine unvorhergesehenen Situationen entstehen. Überwachung des SAP Systems PATROL for SAP Solutions sorgt für das Monitoring des SAP Systems. Ziel ist eine Verkürzung der Reaktionszeiten im Fehlerfall und damit eine höchstmögliche Verfügbarkeit der Applikation. Das Gesamtsystem wird kontinuierlich unter Berücksichtigung betriebsbedingter Offline-Zeiten bestimmter Komponenten überwacht.

Abb. 2: Blick auf die Events in der MasterCell-Konsole.

wachung auch in solchen Situationen stets gewährleistet. Die Vorgaben waren, die Überwachungsmeldungen unter den Gesichtspunkten der Verfügbarkeit, kritischer Systemereignisse und möglicher Fehlentwicklungen von Systemparametern darzustellen. Kritische Systemereignisse und fehleraus lösende Tendenzen werden erkannt. Der gewünschte Zustand der kritischen Systemkom ponente wird weitgehend durch automatische Aktionen wieder hergestellt. Kann oder soll eine solche Aktion nicht automatisiert ausgeführt werden, wird eine Meldung an die ZSK übermittelt. Mit Hilfe der von der Fachabteilung vorgegebenen Lösungswege beseitigt der Betrieb das aufgetretene Problem. Die Überwachungskriterien werden vom R/3Basisbetrieb kontinuierlich überprüft und bei Bedarf neu festgelegt und umgesetzt. Das bedeutet, Änderungen von Parametern oder Schwellwerten können aus dem SAP System heraus ohne notwendige Kenntnisse der anderen Komponenten der Alarmkette eingestellt werden.

Darüber hinaus gibt es einen stündlich gestarteten Job (/BMC/ TR_PME_COLLECTORS_GUARD), der prüft, ob der Kollektor noch aktiv ist und notfalls versucht, ihn wieder zu starten. Für die einzelnen Parameter wird eine Priorität festgelegt. Über diese Priorität werden bei Schwellwertüberschreitungen die daraus resultierenden Systemereignisse ausgelöst. Sie werden an die PATROL Agenten auf den Applikationsservern weitergeleitet. Die Agenten werden in Verbindung mit dem SAP Knowledge Module genutzt, um die Warnungen und Alarme an die ZSK weiterzugeben. Die PATROL Agenten laufen auf allen Applikationsservern und überwachen dort zusätzlich das Betriebssystem. Im Gegensatz zu den üblichen Knowledge Modulen von PATROL, mit denen etwa das Betriebssystem Unix überwacht wird, werden mit dem SAP Knowledge Modul nicht alle Messwerte dargestellt und historisiert, sondern nur definierte Warn- oder Alarm-Stati aus dem R/3 System weitergegeben und in der ZSK dargestellt. Zentrale Übersicht über alle Systeme Neben der Möglichkeit, Alarme an die PATROL Agenten weiterzuleiten, bietet PATROL for SAP Solutions eine Management- und Visualisierungskonsole, die als Transaktion aufgerufen und innerhalb des SAP-GUI abgearbeitet wird.

Umsetzung der SAP Überwachung BMC PATROL for SAP Solutions ist in ABAP entwickelt, die Datensammlung und deren Management finden in dem R/3 System statt. Die Datensammlung nutzt die gleichen Funktionen wie die SAP-eigene Überwachungskomponente CCMS, bietet darüber hinaus jedoch zusätzliche Parameter und systemübergreifende Überwachungsmöglichkeiten an. Als Kollektor (/BMC/TR _DATA_COLLECTOR) gestartet, belegt PATROL for SAP Solutions permanent einen Hintergrundprozess. Treten Engpässe bei den Prozessen auf, ist die Über-

Von dieser Konsole aus ist es möglich, alle vorhandenen SAP Instanzen über RFC-Verbindungen gleichzeitig zu überwachen und

Glossar SAfOS: System Automation for OS/390 MVS: Multiple Virtual Storage - IBM-Betriebssystem(teil), basierend auf OS/1 ZSK: Zentrale Störmeldekonsole RFC: Remote Function Call

25

System Management

zu bedienen. In dieser Konsole werden Messintervalle, Schwellwerte für die zu überwachenden Parameter und automatische oder Alarm-Aktionen eingestellt (siehe Abbildung 3). Auf einen Blick können hier sämtliche SAP Systeme, die überwacht werden, auf mögliche Probleme hin überprüft werden. Unterhalb der Systeme wird direkt aufgeführt, wo das mögliche Problem aufgetaucht ist: ob in der Datenbank, ob im Betriebssystem oder ob ein bestimmter Applikationsserver Probleme hat. Von dieser Konsole aus kann dann ein Drilldown stattfinden, der den Störfall genau lokalisiert (siehe Abbildung 4). Fazit Abb. 3: Management- und Visualisierungskonsole mit Sicht auf diverse SAP Systeme.

Allen drei an der Überwachung beteiligten Betriebsgruppen wird der Zustand der SAP Anwendung nun in einer ihnen vertrauten Form dargestellt: Mit der Management- und Visualisierungskonsole steht den SAP Administratoren ein vollständig in SAP integriertes Werkzeug zur Verfügung. Für den Unix Betrieb stellt die klassische PATROL Konsole alle wesentlichen Informationen dar. Hier werden kritische Ereignisse historisiert und PATROLtypisch ins Service Reporting übernommen. Last but not least werden alle kritischen Ereignisse an die ZSK weitergereicht, um eine hohe Verfügbarkeit rund um die Uhr zu gewährleisten. In einer der nächsten Ausgaben werden wir genauer auf den Einsatz der BMC-Software unter Betriebsbedingungen eingehen.

Abb. 4: Problem Screen von PATROL for SAP Solutions.

News Ticker

>

Uwe Rübesamen ([email protected]).

Hier kommt nochmal das T-Shirt als Füller rein!

Herzlichen Glückwunsch dem Schach Quiz Gewinner!

Über 10 Jahre hinweg berichtete die ORDIX News Redaktion zum „ORDIX Open“. In der letzten Ausgabe der ORDIX News stellten wir unsere Leser mit einem kleinen Quiz auf die Probe. Hier die richtigen Lösungen auf die Schach Fragen: 1 a, 2 c, 3 a, 4 b, 5 b, 6 a, 7 a, 8 c, 9 c, 10 a Richtig beantwortete als Einziger Herr Ralf Glöckner alle Fragen. Gut aufgepasst & Herzlichen Glückwunsch! Ihr Preis ist eines der limitierten ORDIX Open Jubiläums-Poloshirts sowie ein Überraschungspräsent! Wir wünschen Ihnen viel Spaß damit! Die Redaktion

26

Datenbanken

Performancetest: Ladefunktionalitäten unter Oracle 9i Unter Oracle 9i gibt es mehrere neue Features, um Daten in eine Datenbank zu laden: External Tables zum Einpflegen von Daten in eine Datenbank und Multitable Inserts zum Verteilen von Datensätzen aus einer Tabelle auf mehrere verschiedene Tabellen. Mit einem Performancetest wollen wir überprüfen, wie schnell sich mit den neuen Features große Datenmengen in eine Datenbank einpflegen lassen und das Ergebnis mit dem sql*loader und dem Verteilen über ein PL/SQL-Skript vergleichen. Auch die Kombinationen von alten und neuen Features werden auf ihre Performance hin getestet. Mit dem Test soll herausgefunden werden, mit welchen Methoden man am schnellsten große Datenmengen in eine Datenbank einpflegen kann.

Beschreibung der angewendeten Funktionalitäten Der sql*loader ist ein Tool, um Daten aus einer Betriebssystemdatei in die Oracle-Tabellen zu laden. Die erforderlichen Informationen bekommt der sql*loader aus zwei Dateien. Zum einen aus dem Data-File, in dem sich

create table daten (KUNDENNR NUMBER(10) NOT NULL, NAME VARCHAR2(40), TELEFON VARCHAR2(12), STRASSE VARCHAR2(40), PLZ VARCHAR2(12), ORT VARCHAR2(30), BESTELLNR NUMBER(10) NOT NULL, BESTELLPOSITION VARCHAR(20), ANZAHL NUMBER(5), PREIS NUMBER(5) ); Abb. 1: Skript zum Anlegen der Tabelle „daten”. create table kunden (KUNDENNR NUMBER(10) NOT NULL, NAME VARCHAR2(40), TELEFON VARCHAR2(12), STRASSE VARCHAR2(40), PLZ VARCHAR2(12), ORT VARCHAR2(30) ); create table bestellungen (KUNDENNR NUMBER(10) NOT NULL, BESTELLNR NUMBER(10) NOT NULL, ANZAHL NUMBER(5) ); create table ware (BESTELLNR NUMBER(10) NOT NULL, BESTELLPOSITION VARCHAR2(20), PREIS NUMBER(5) ); Abb. 2: Anlegen der Tabellen „kunden“, „ware“ und „bestellungen”.

die eigentlichen Daten befinden und zum anderen aus dem Control-File, in dem sich die Informationen befinden, wie die Daten in die Tabellen eingeladen werden sollen und in welcher Form die Daten im Data-File vorliegen. Die Daten werden bei der konventionellen Methode des sql*loaders über INSERT-Befehle in die Datenbank geladen. Der „direct path loader“, ein bestimmter Modus des sql*loaders, erstellt die Datenblöcke im Oracle Datenbank-Format. Diese werden dann direkt in die Datenbankdateien geschrieben. Es werden gleichzeitig mehrere Puffer gefüllt und es wird, wenn die Datenbank auf asynchrones I/O eingestellt ist, parallel in die Dateien geschrieben, während die Puffer wieder gefüllt werden. Ein neues Feature unter Oracle 9i ist das Laden von Dateien über sogenannte Externe Tabellen (external tables). Externe Tabellen sind den SQL-Tabellen sehr ähnlich, nur dass sie sich außerhalb der Datenbank befinden. Lediglich die Definition wird im Data Dictionary hinterlegt. Die Tabellen bestehen in Form von Dateien bereits außerhalb der Datenbank. Wenn sich die Metadaten im Data Dictionary befinden, können die externen Tabellen per Select abgefragt werden. Das INSERT...SELECT STATEMENT kann mit einer Anweisung Zeilen in mehrere Tabellen einfügen. Das Multitable Insert Statement fügt die Ergebnismenge einer Subquery in die Tabellen ein. Es gibt mehrere Arten von Multitable Inserts, wir haben den Conditional Insert All gewählt. Alle Sätze der Ergebnismenge werden in alle Tabellen, die über die INTO-Klausel zugewiesen sind, eingefügt. (Mehr zum Thema Multitable Inserts finden Sie im Artikel „Oracle 9i New Features Teil III: SQL in Oracle 9i“ der ORDIX News 3/2002.) Die Tests wurden auf folgender Maschine durchgeführt: • PRIMERGY 470 GE FH PIII MHz • 512 MB SDRAM • 100 MHz • 1 CPU • Betriebssystem Red Hat Linux 7.2 • Oracle Umgebung 9.2.0 Testablauf Zunächst werden die Testdaten über ein Perl-Skript erzeugt. Dem Test liegt eine Datenmenge von 500.000 Datensätzen zu Grunde.

27

Datenbanken

Die Tabellen daten, kunden, ware und bestellungen werden per Skript, wie in den Abbildungen 1 und 2 dargestellt, angelegt. Bei Test 1 - 4 werden die Daten zunächst aus der Datendatei in eine Tabelle geladen und von der Tabelle aus auf die Tabellen kunden, ware und bestellungen verteilt. Das Verteilen der Daten erfolgt über ein PL/SQL-Skript oder über Multitable Inserts.

Abb. 3: Laden über sqlldr mit Verteilung über PL/SQL bzw. Multitable Inserts.

LOAD DATA INFILE ‘daten.dat’ DISCARDFILE ‘daten.dsc’ DISCARDMAX 999 REPLACE INTO TABLE daten (kundennr TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, name TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, telefon TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, strasse TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, plz TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, ort TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, bestellnr TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, bestellposition TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, anzahl TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘, preis TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘)

Abb. 4: Sql*loader.

Bei den Tests 5 und 6 wird zunächst eine externe Tabelle erzeugt und danach werden die Daten wieder über PL/SQL bzw. Multitable Inserts auf die drei anderen Tabellen verteilt. Dabei wird jeweils die Zeit gemessen. Jeder Test wird dreimal durchgeführt und bei der Zeit der Mittelwert aus den drei Testläufen genommen, um möglichst genaue Zeiten zu erhalten. Nach jedem Test werden die Datensätze wieder aus den Tabellen herausgelöscht und die Rollbacksegmente werden wieder verkleinert. Test 1 Die Datensätze werden über sqlldr mit der konventionellen Methode in eine DatenbankTabelle eingepflegt und dann mit einem PL/ SQL-Skript auf die anderen Tabellen verteilt. Das Laden der Daten dauerte hier 70 Sekunden und das Verteilen 460 Sekunden. Somit kommen wir auf eine Gesamtdauer von 530 Sekunden. Test 2 Die Daten werden über den konventionellen Modus des sql*loader in die Datenbank-Tabelle geladen und dann mit Multitable Inserts auf die anderen Tabellen verteilt. Das Laden der Daten dauerte hier 70 Sekunden und das Verteilen 40 Sekunden. Somit kommen wir auf eine Gesamtdauer von 110 Sekunden.

DECLARE counter NUMBER; CURSOR c1 IS SELECT * FROM daten; BEGIN FOR v_c1 in c1 LOOP insert into kunden values (v_c1.kundennr,v_c1.name,v_c1.telefon, v_c1.strasse,v_c1.plz,v_c1.ort); insert into bestellungen values (v_c1.bestellnr,v_c1.kundennr,v_c1.anzahl); insert into ware values (v_c1.bestellnr,v_c1.bestellposition,v_c1.preis); END LOOP; END; /

Abb. 5: PL/SQL.

28

Test 3 Mit dem direct path loader werden die Daten in die Datenbank-Tabelle eingepflegt und dann mit einem PL/SQL-Skript auf die anderen Tabellen verteilt. Das Laden der Daten dauerte hier 17 Sekunden und das Verteilen 460 Sekunden. Die Gesamtdauer beträgt 477 Sekunden. Test 4 Mit dem direct path loader werden die Daten in die Datenbank-Tabelle geladen und dann mit Multitable Inserts auf die anderen Tabellen verteilt. Das Laden der Daten dauerte 17 Sekunden und das Verteilen 40 Sekunden. Wir kommen auf eine Gesamtdauer von 57 Sekunden.

Datenbanken

Test 5 INSERT ALL INTO kunden VALUES (kundennr, name, telefon, strasse, plz, ort) INTO bestellungen VALUES (kundennr,bestellnr,anzahl) INTO ware VALUES (bestellnr,bestellposition,preis) SELECT kundennr, name, telefon, strasse, plz, ort, bestellnr, anzahl, bestellposition, preis FROM daten;

Eine External Table wird angelegt und die Daten werden dann über ein PL/SQL-Skript auf die anderen Tabellen verteilt. Das Verteilen der Daten aus der externen Tabelle auf die anderen Tabellen dauert hier 460 Sekunden. Durch das Anlegen der externen Tabelle entfällt die Zeit für das Laden. Test 6 Eine External Table wird angelegt und die Daten werden dann mit Multitable Inserts auf die anderen Tabellen verteilt. Das Verteilen der Daten aus der externen Tabelle auf die anderen Tabellen dauert 71 Sekunden. Durch das Anlegen der externen Tabelle entfällt die Zeit für das Laden. Zusammenfassung der Testergebnisse

Abb. 6: Multitable.

Verifikationstest Fall 4 und 6

Abb. 7: Externe Tabelle mit Verteilung über PL/ SQL bzw. Multitable Inserts.

CREATE TABLE daten1_ext( kundennr NUMBER, name CHAR(40), telefon CHAR(12), strasse CHAR(40), plz CHAR(12), ort CHAR(30), bestellnr NUMBER, bestellposition CHAR(20), anzahl NUMBER, preis NUMBER) ORGANIZATION EXTERNAL( TYPE oracle_loader DEFAULT DIRECTORY ext_dat_dir ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE FIELDS TERMINATED BY ‘,’ OPTIONALLY ENCLOSED BY ‘„‘ MISSING FIELD VALUES ARE NULL) LOCATION(‘daten.dat’) ) REJECT LIMIT UNLIMITED; Abb. 8: External Table.

Da die Testergebnisse von Test 4 ( direct path loader + Verteilung über Multitable Inserts) und Test 6 (External Table + Verteilung über Multitable Insert) sehr dicht beieinander lagen, wurde noch ein Verifikationstest durchgeführt. Dabei wurden jeweils 2.000.000 Datensätze in die Tabellen eingepflegt.

Fazit Möchte man große Datenmengen möglichst schnell in eine Datenbank einpflegen, sollte man auf die Kombination von direct path loader und Multitable Inserts setzen. In unserem Test war dies die schnellste Methode, die 500.000 und auch die 2.000.000 Datensätze in die Datenbank einzupflegen. Aber auch die Kombination der beiden neuen Features External Tables und Multitable Inserts unter Oracle 9i bietet die Möglichkeit, mit einem relativ geringen Aufwand und vor allem in einer sehr kurzen Zeit eine große Datenmenge in die Datenbank zu laden.

Kathrin Hammerschmidt ([email protected]).

29

Unix/Linux/Open Source Source - Titelthema Serverkonsolidierung

Serverkonsolidierung oder: Aus „Alt” mach „Neu” Nahezu jedes größere IT-Projekt wird mit der folgenden Erfahrung „konfrontiert“: Die Ressourcen-Grenzen sind weitestgehend ausgereizt, die CPUs zu langsam, eine Erweiterung mit zusätzlichen CPUs ist auch nicht mehr möglich; von dem stetig steigenden Speicherbedarf neuer Anwendungen ganz zu schweigen. Und zu guter Letzt kann es auch noch passieren, dass der Lieferant die Wartung und Weiterentwicklung der eingesetzten Systeme für die nahe Zukunft „ab“kündigt. Als Trost bleibt nur, dass die Systeme wahrscheinlich schon lange abgeschrieben sind.

Neben den rein technischen Aspekten gibt es noch einen weiteren Grund für den Plattformwechsel, der zur Zeit vielen IT-Abteilungen „zu schaffen“ macht: Während vor ein paar Jahren Projekte noch mit einer Vielzahl von unterschiedlichen Systemen realisiert wurden, geht man heute gerne den Weg der Serverkonsolidierung. Anstatt „eigenständige“ Systeme für die einzelnen Projekte einzusetzen, liegt es im Trend, viele Projekte in einem System unterzubringen. Dies soll neben den Infrastruktur-Kosten (Stellplatz, Strom, etc.) auch die Administrationskosten senken helfen. Vor diesem Hintergrund ist es für die IT-Abteilung selbstverständlich, sich rechtzeitig nach anderen Lösungs-Plattformen umzuschauen. Die ORDIX AG hat bereits diverse Kunden in dieser Phase der Konsolidierung unterstützt - von der Ausarbeitung eines Konzeptes bis hin zu dessen späterer Realisierung. In diesem Artikel möchten wir unsere Projekterfahrung darstellen und beispielhaft den Werdegang eines Projektes von der Konzepterstellung bis zur Realisierung/Migration aufzeigen.

... wurde ein Anforderungskatalog erarbeitet Von Anfang an werden alle beteiligten Personen aus Entwicklung, Fachseite, Anwendungsbetreuung und Betrieb an der Ausarbeitung der zukünftigen Systemarchitektur beteiligt. Im ersten Schritt werden in mehreren Workshops die Anforderungen an die zukünftige Systemarchitektur erarbeitet und in einem Anforderungskonzept festgehalten. Im Vordergrund steht dabei natürlich vor allem der Kostenaspekt. Nachfolgend ein Auszug der wichtigsten Anforderungen: Standort-Faktoren: •

Reduzierung der sechs Standorte auf zwei Standorte. Das soll die Standort-Kosten senken und den Netzverkehr innerhalb der Systeme von einem kostenintensiven WAN auf eine kostengünstige LAN-Strecke verlegen.

•

Drei der bestehenden Systeme sollen zu einem neuen System zusammengeführt werden, um die Anzahl der Systeme zu minimieren. Die Reduzierung der Systeme und der damit einhergehende geringere Administrationsaufwand zielen ebenfalls darauf ab, die Kosten zu senken.

•

Es ist eine räumliche Trennung innerhalb der Standorte angestrebt. Eine Feuerschutzwand soll im Katastrophenfall das Übergreifen eines Brandes von einem Raum in den anderen verhindern und so die Verfügbarkeit sicherstellen.

Vor der Migration Dazu ein kleines Schaubild über eine mögliche Systemarchitektur vor der Migration (siehe Abbildung 1). Die Gesamtanwendung verteilt sich über sechs Standorte hinweg auf jeweils vier Cluster. Jedes Cluster besteht aus zwei Knoten mit insgesamt zwei Systemschränken und zwei Plattenschränken.

Hardware-Ressourcen: •

Abb. 1: Verteilte Infrastruktur auf 6 Standorte vor der Migration.

30

Die CPU-Leistung und der zur Verfügung stehende Speicher sollen die bisherigen Werte um 30 % übertreffen. Da der Plattform-Wechsel mit einem Release-Wechsel inklusive zusätzlicher Funktionalitäten

Unix/Linux/Open Source

einhergehen würde, war auch dieser erwartete Mehrbedarf mit einzukalkulieren. •

Die neuen Systeme sollen eine minimale Skalierbarkeitsreserve von 50 % beinhalten. Dies soll verhindern, dass die Systeme bereits nach kurzer Zeit wieder an ihre Ressourcen-Grenze stoßen und ein verfrühter Austausch nötig wird.

•

Zur Behebung von Performance-Engpässen soll es zukünftig möglich sein, dynamische Rekonfigurationen der Hardware im laufenden Betrieb durchzuführen. Somit könnte man einen kurzfristig auftretenden CPU-Engpass durch das kurzfristige Erweitern mit zusätzlichen CPUs auffangen. Dies erlaubt also den individuellen, effizienteren und kostensparenderen Einsatz der zur Verfügung stehenden Ressourcen.

Abb. 2: Infrastruktur nach der Migration.

•

Die Anforderung, dass der Cluster aus mehr als zwei Knoten bestehen soll, erlaubt eine kurzfristige und flexible Reaktion z. B. auf Last-Probleme. Je nach Last kann der Administrator eine Anwendung auf ein weniger beanspruchtes System umschalten.

•

Das System sollte den Ausfall einzelner Hardware-Komponenten erkennen und auffangen, ohne den Betrieb zu unterbrechen. Zudem soll der Ausfall der Komponente zeitnah gemeldet werden, um entsprechende Maßnahmen einzuleiten.

•

Die Komponenten sollen sich im Betrieb austauschen bzw. erweitern lassen können (Stichwort: Hot-Swap).

•

Alle Datenpfade bzw. Daten-Controller wie auch alle Netzanbindungen werden redundant vorgehalten.

Software-Faktoren: •

Die bisher benutzten Software-Komponenten wie z. B. Datenbank System, Middleware (Applikationsserver, Kommunikationssysteme, Transaktionsmonitore) und System Management (Überwachung) sollen auf der neuen Plattform ebenfalls zur Verfügung stehen. Eine kostenintensive Migration auf ein anderes Produkt ist nicht vorgesehen.

Verfügbarkeits-Faktoren: •

•

Neben der Hochverfügbarkeit der Anwendung ist das oberste Ziel die Datenkonsistenz. Undefinierte Zustände, bei denen mehrere Knoten eines Clusters die gleiche Datenbasis verändern und somit zerstören, sind unbedingt zu vermeiden. Wie bei der bisher eingesetzten HV-Lösung ist die Verteilung der einzelnen Anwendungen und Ressourcen über eine Parametrisierungsdatei zu steuern. Voraussetzung dafür ist eine Trennung von Parametern und Skripten.

•

Im Gegensatz zur bestehenden Lösung ist eine weitere Anforderung, auch einzelne Anwendungskomponenten zu überwachen und bei Ausfall zu reaktivieren.

•

Das Erkennen und die Übernahme eines ausgefallenen Systems soll in möglichst kurzer Zeit durchführbar sein. Die Umschaltzeit der bisher eingesetzten Lösung von ca. 15 Minuten darf dabei nicht überschritten werden.

... und nach entsprechenden Lösungen gesucht Auf Basis dieser Anforderungen holte man zunächst von unterschiedlichen Herstellern (HP, IBM, SUN, Fujisu Siemens) sowohl konzeptionelle als auch preisliche Angebote ein. Mehrere Arbeitsgruppen analysierten und bewerteten die verschiedenen Angebote in Bezug auf die Erfüllung der Anforderungen. Nach Berücksichtigung der Kosten und der Anforderungskriterien erwählte man die in Abbildung 2 dargestellte Lösung als Plattform. Die Lösung basiert auf einer hochverfügbaren Systemarchitektur, bei der unter anderem auf die Redundanz sämtlicher Komponenten Wert gelegt wurde. Das Gesamtsystem wird über zwei Standorte verteilt. An jedem Standort sind zwei Brandschutzabschnitte berücksichtigt. Diese Architektur beinhaltet pro Standort jeweils zwei Serversysteme und zwei Plattensubsysteme. Jedes Serversystem ist mit bis zu sechs Partitionen konfiguriert. Innerhalb des Standortes sorgt ein hochverfügbares SAN mit einer „dual fabric“-Struktur für die Anbindung der Plattensubsysteme an die Server. Das Zusammenführen von mehreren Datenbanken zu einer erzielte eine Anwendungskonsolidierung von produktiven Datenbank-Anwendungen auf ein Drittel. Jede der Anwendungen läuft nun auf einer Partition des Serversystems. Die einzelnen Partitionen erbringen die Performance von drei bisher eingesetzten Altsystemen „plus 30 %“. Zum Sizing des

31

Unix/Linux/Open Source

CPU-Bedarfs wurden die SPEC-Werte der jeweiligen Systeme herangezogen. Dadurch ergab sich für die neuen Partitionen ein Bedarf von zwölf CPUs (im Vergleich zu den bisher benötigten 3x12 CPUs). Bezüglich der Plattenanbindung hatte man darauf geachtet, die Controller über mehrere Systemboards einer Partition redundant zu verteilen. Dies erzielt eine bessere Lastverteilung und eine höhere Verfügbarkeit der Datenpfade. Ein Ausfall eines Systemboards führt somit nicht zu einem Ausfall der Plattenanbindung. Für die dynamische Lastverteilung ist der Einsatz zusätzlicher Systemboards denkbar. Mit der „Enhanced Server Capacity on Demand“ bietet sich die Möglichkeit, die Systeme mit zusätzlichen Komponenten auszurüsten, die später im laufenden Betrieb aktivierbar sind. Als „Nachfolge-Produkt“ für die bisherige 2-Knoten-HV-Software kommt nun ein acht bzw. sechs Knoten-Cluster zum Einsatz. So lassen sich bei Ausfall einer Partition die dort laufenden Anwendungen auf die restlichen, laufenden Partitionen verteilen. ... und realisiert. Für die Umstellung auf eine neue Plattform genügt es nicht, nur die eigentliche Anwendung zu portieren. Auch die bisher eingesetzten Tools (Backup, Cronjobs, Überwachungs-Skripte, etc.) müssen an die neue System-Architektur angepasst werden. Allein der Einsatz einer neuen HV-Software führt dazu, dass ein Großteil der Skripte neu entwickelt wurde.

Im ersten Schritt erfolgte der Test der „GesamtLösung“ (inklusive Datenbank, Anwendung und HV-Software) auf einem gesonderten Abnahme-System „auf Herz und Nieren“. Dann ging mit der Umstellung des Piloten das erste System der neuen „Lösung“ in den Wirkbetrieb. Nach dem erfolgreichen Pilot-Betrieb, konnten nun auch alle anderen Systeme umgestellt werden. Sowohl für den Roll Out (Anwendungs Installation/Konfiguration) als auch für die Migration der Daten entwickelte das beteiligte Projektteam entsprechende Tools, damit die Daten und die Anwendungen innerhalb von drei Wochenenden quasi per Knopfdruck auf die neuen Systeme portiert werden konnten. Nach jahrelanger Mitwirkung hatte das ORDIXTeam das Projekt auch in dieser Phase intensiv begleitet. Von der Konzeption, über die Auswahl und Einrichtung der neuen Lösung bis hin zur Migration der Anwendung unterstützen ORDIX Mitarbeiter den Kunden so, dass für ihn eine möglichst kostengünstige, hochverfügbare und effiziente Plattform realisiert werden konnte.

Antonio Salguero ([email protected]).

Impressum Herausgeber: ORDIX AG Aktiengesellschaft für Softwareentwicklung, Beratung, Schulung und Systemintegration, Paderborn Redaktion: Sascia Brinkmann, Helma Jenniches V.i.S.d.P.: Wolfgang Kögler Anschrift der Redaktion: Westernmauer 12 - 16 D-33098 Paderborn Fon: 0 52 51 / 10 63 - 0 Fax: 0 52 51 / 10 63 - 99 Gestaltung/Layout: Sascia Brinkmann Druck: Druckerei Reike GmbH, Paderborn

32

Autoren dieser Ausgabe: Sascia Brinkmann, Kathrin Hammerschmidt, Michael Heß, Stefanie Heither, Martin Hoermann, Helma Jenniches, Wolfgang Kögler, Andreas Kother, Manfred Lingk, Ulrich Meyer, Uwe Rübesamen, Antonio Salguero, Guido Saxler, Frank Weiser Copyright: ORDIX AG. Alle Rechte vorbehalten. Die Zeitschrift ORDIX News hat eine Auflage von 7.700 Exemplaren. Sie wird von der ORDIX AG an ausgesuchte Kunden verteilt und kann für 2,20 Euro bei uns bestellt werden. Außerdem finden Sie die neueste Ausgabe 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 Anregungen, Kritik und Anmerkungen zu den Themen, aber auch für interessante Ideen sind wir immer offen und dankbar. Sie erreichen die Redaktion auch per E-Mail unter [email protected]. Wir freuen uns auf Ihr Feedback.

Aktuell Einladung zur NetIQ Partner Veranstaltung am 29.01.2004 in Wiesbaden

System- und Sicherheits-Management mit NetIQ Wenn es Ihnen darum geht, Ihre Windows- und Unix/Linux-Landschaften besser zu überwachen und ein effizientes, kostengünstiges System Management und Monitoring zu gewährleisten, dürfen Sie unsere Fachveranstaltung zu NetIQ nicht verpassen ! Lernen Sie in einem Überblick Vorzüge und Einsatzgebiete von NetIQ Lösungen kennen.

NetIQ: Vortrag, Vorstellung und Live-Demo Termin: Beginn: Dauer: Ort:

Donnerstag, 29. Januar 2004 15:00 Uhr ca. 3 Stunden ORDIX AG, Raum 1 Kreuzberger Ring 13 D-65205 Wiesbaden Tel.: 06 11 / 7 78 40-00

Dieser kostenfreie Vortrag mit anschließender Live-Demo richtet sich an alle Kunden und Leser mit großer Microsoft- bzw. Unix/Linux-Umgebung, an Spezialisten und Verantwortliche für den Bereich Security. Auch wenn Sie für Monitoring Projekte verantwortlich sind, ist dieser Nachmittag ein Muss für Sie.

Ihre Anmeldung Die Teilnahme ist kostenlos. Bitte haben Sie Verständnis, dass wir nur eine begrenzte Teilnehmerzahl entgegennehmen können. Versäumen Sie deshalb nicht, sich rechtzeitig anzumelden. Anmelden können Sie sich per E-Mail an [email protected], per Post an die ORDIX AG, Westernmauer 12-16, 33098 Paderborn, oder Fax ( 0 52 51 / 10 63-99) mit dem Betreff „[email protected]“, oder einfach online im Internet unter http://www.ordix.de/netiq. Dort finden Sie auch noch mal Hinweise zur Veranstaltung sowie Informationen zu möglichen Programmänderungen etc. Programmänderungen behalten wir uns vor. Der Rechtsweg ist ausgeschlossen.

ORDIX entschied sich Anfang des Jahres 2003 für eine Partnerschaft mit NetIQ. Als System Management Spezialisten haben wir uns deshalb für diese Partnerschaft entschieden, weil NetIQ definitive Vorteile gegenüber anderen Herstellern bietet, wenn es darum geht, effiziente und kostengünstige System Management Lösungen für Microsoft, Unix und Open Source (Linux) basierte Systeme einzusetzen. Wir sind stolz darauf, Ihnen einen Spezialisten aus dem Hause Value Added Software, dem deutschen Distributor von NetIQ, zu präsentieren, der Ihnen an diesem Tag sein komplettes NetIQ Know-how zur Verfügung stellt und Ihre Fragen beantwortet. +++ Die kostengünstige System Management- und Security Management Lösungspalette für alle Windows und Unix/Linux Systemlandschaften → Überblick über die NetIQ Lösungen, Tipps und Tricks, insbesondere beim AppManager → Vorstellung ausgewählter Komponenten: Live-Demo des AppManagers, Diskussion und Fragenforum Referent: Herr Volkmar Rosenow, Value Added Software GmbH, Neuss +++ Vorstellung der Partnerschaft ORDIX / NetIQ: Bedeutung, Effizienz, Ihre Vorteile Referent: Holger Demuth, Projektmanager System Management +++ Lassen Sie sich diese Vorstellung und das anschließende „Get Together“ nicht entgehen. Für das leibliche Wohl sorgen wir im Anschluss an die Vorträge mit einem kleinen Buffet. Ihr ORDIX Team

Karl-Heinz Künneke

Michael Fey

33

Aktuell

ORDIX auf der 16. Deutschen Oracle Anwenderkonferenz Ein “Muss” für Oracl´er. Am 12. und 13. November 2003 ging die Deutsche Oracle Anwender Konferenz in die 16. Runde. ORDIX war das 4. Mal in Folge mit von der Partie: als Aussteller mit 4 Fachvorträgen im Gepäck, einem gut besuchten Schulungstag und rundum positivem Feedback! Dieter Ketterle, Organisator des wichtigsten Events der deutschen Oracle Community, ist stolz auf das stetig steigende Interesse an der Veranstaltung: „Im Vergleich zum letzten Jahr konnten wir im Congress Center in Mannheim jetzt weit über 1350 Teilnehmer zählen, bestehend aus IT Managern, Entwicklern und DB-Administratoren. Ein Beweis für die Wichtigkeit und den Stellenwert der Konferenz!“ Großer Andrang ... In über 125 Fachvorträgen und an ca. 40 Firmenständen konnten sich alle Teilnehmer über die Top-Themen der Oracle Welt informieren. Die Themenvielfalt reichte von Oracle Database 10G, Application Server und Development Tools über Business Intelligence bis hin zu IT Experience. Das ORDIX Team lud zu interessanten Fachgesprächen ein und stellte an der Infoinsel sein komplettes Oracle Know-how zur Verfügung. Einen gewohnt anspruchsvollen Beitrag zur Konferenz leistete ORDIX mit seinen drei Vorträgen:

•

Storage Parameter: Funktion, Bedeutung und Effizienz Referent: Herr Klaus Reimers

•

Tuning I/O-intensiver Systeme mit 9i Referent: Herr Martin Hoermann Anmerkung der Redaktion: Hierzu finden Sie auch einen Bericht auf Seite 14.

•

Objektorientierte Features von PL/SQL in Oracle 9i Referent: Herr Markus Fiegler

„Gib mir Musik“ ... war das Motto der Abendveranstaltung am 12. November. Nach dem Ausklang der „Question & Answer“ Runde der Konferenz konnten die Teilnehmer bei dem ein oder anderen Bierchen weiter über die wichtigen Oracle News debattieren, bevor der anstrengende Tag mit einem grandiosen Gala-Buffet belohnt wurde. Um die „angenossenen“ Pfunde erst gar nicht wirken zu lassen, hatte sich Dieter Ketterle etwas ganz Besonderes ausgedacht: Auf vielfachen Wunsch gab Rolf Stahlhofen, einer der berühmten „Söhne Mannheims“, sein musikalisches Review. Schon zwei Jahre zuvor begeisterte er die Teilnehmer auf der Konferenz mit seiner Musik. Schnell waren auch dieses Mal müde Beine und brennende Füße vergessen und selbst der letzte DBA entledigte sich der steifen Krawatte, um nach Klängen von berühmten Musikern richtig „abzurocken“.

... bei den ORDIX Vorträgen bewältigt Alle ORDIX Vorträge erfreuten sich größter Beliebtheit seitens der Oracle User. Das Orga-Team der Konferenz hatte bereits aus den vergangenen Jahren „gelernt“: Mussten die Teilnehmer in 2002 noch wegen Überfüllung auf dem Fußboden Platz nehmen, so hatte man dieses Mal sogar den riesigen Musensaal für ORDIX reserviert, damit auch alle 200 Interessierten aufmerksam und „bequem“ den Vorträgen folgen konnten.

Für Fragen zu den Vortragsthemen können Sie sich gerne per EMail über [email protected] an die Referenten wenden.

34

Die ORDIX Infoinsel: Vor allem in den Pausen zwischen den Vorträgen besuchten die Teilnehmer der Konferenz die Stände der ausstellenden Firmen.

Aktuell

Oracle Schulungen hautnah Wem das gebotene Programm der Konferenz nicht ausreichte, hatte die Möglichkeit, sich vor Ort weiterzubilden. Mehr als 450 Interessierte „bevölkerten“ die hochkarätigen ORDIX Fachvorträge.

Im Anschluss an die Konferenz fand am 14. November 2003 der DOAG Schulungstag statt - erstmalig in dieser Form. ORDIX war eine der sechs Firmen, die dort ihr Oracle Wissen im Rahmen einer Schulung präsentierten. Mit großem Erfolg, denn ORDIX konnte gleich die meisten Interessenten - knapp 30 - für sich gewinnen. Als Auszug aus dem weitreichenden ORDIX Trainingsprogramm verschaffte das Seminar „Oracle Net“ den Teilnehmern einen Einblick in neue Features, Konfiguration und Einsatz von Oracle Net Produkten. An praktischen Beispielen wurde detailliert auf die Themen Listener, Datenbanken im Dedicated Server Betrieb und im Multi Threaded Server Betrieb, auf den Connection Manager, Names Server und OID/LDAP eingegangen.

Mit über 1350 Besuchern und ca. 40 Ausstellerfirmen war das Congress Center Mannheim bei der Oracle Anwenderkonferenz gut gefüllt.

Sie möchten Ihr Oracle Know-How erweitern? Lesen Sie im Internet auf der Seite http://training.ordix.de, welche Möglichkeiten Ihnen das ORDIX Trainingsprogramm bietet!

ORDIX Schulungsräume erweitert Im November hat ORDIX in Wiesbaden einen weiteren Schulungsraum eingerichtet. Das deutlich umfangreichere Schulungsprogramm für 2004 hat diese Erweiterung erfordert. Die Erweiterung kommt vor allem den Unix- und Datenbank Schulungen zu Gute. Der neue Raum wurde mit SUN SPARC Workstations ausgestattet. Bei den Workstations handelt es sich um Sun Blade 156, die mit 1,2 GB Hauptspeicher, 2*40 GB Festplatte und einem UltraSPARC IIi Prozessor optimal ausgestattet, um Solaris Administrationskurse, Kurse im Umfeld System Management oder Datenbanken durchzuführen. Aber auch für Java- oder J2EE Seminare eignen sich diese Workstations durchaus sehr gut. Weiterhin wurden für IBM AIX- und Unix Multivendor Schulungen zusätzliche AIX Server angeschafft. Anfang 2004 wird einer der Seminarräume komplett neu mit einem Equipment ausgestattet, das das mobile Konzept unseres Trainingsangebotes optimal unterstützt. Informieren Sie sich unter http://training.ordix.de.

Der mit SUN SPARK Workstations ausgestattete ORDIX Seminarraum.

Seit Ende September haben wir darüber hinaus einen Teilnehmerabend eingeführt. Bei gutem Essen und Getränken können sich die Teilnehmer zu netten, informativen Gesprächen treffen. Dazu bekommen sie die Gelegenheit zu einem Netzwerkspiel oder sich einen spannenden Film auf DVD anzusehen. Der Teilnehmerabend findet jeden Dienstag statt.

35

Datenbanken

Erschienen in der Zeitschrift der Deutschen Oracle Anwendergruppe „DOAG News“, Ausgabe Q4/2003

Die Standby-Datenbank: Data Guard aus Kundensicht (Teil III) Die vorangegangenen Artikel dieser Reihe beschäftigten sich ausführlich mit dem Aufbau und Betrieb einer physikalischen Standby-Datenbank, bis einschließlich Oracle 9i. In dieser Ausgabe wollen wir uns nun den Aufbau einer logischen Standby-Datenbank anschauen. Auch hier werden alle Schritte zunächst mit SQL*Plus, also ohne GUI, durchgeführt. Bevor wir die logische Standby-Datenbank aufbauen, wollen wir uns zunächst anschauen, wo es innerhalb der Architektur Gemeinsamkeiten bzw. Unterschiede zur physikalischen Standby-Datenbank gibt. Transport der Redo Informationen Der Transport der Redo Informationen unterscheidet sich bei einer logischen Standby-Datenbank nicht grundsätzlich von dem bei einer physikalischen Standby-Datenbank. Auch können sowohl der ARCH oder der LGWR Prozess genutzt werden. Allerdings gibt es innerhalb der logischen Standby-Datenbank keine Standby RedoLog Dateien. Der LGWR schreibt direkt in archivierte RedoLog Dateien, und zwar in das Verzeichnis, das über den Parameter standby_archive_dest angegeben wird. Unterbrechungen der Übertragung werden auch bei der logischen Standby-Datenbank automatisch erkannt und die fehlenden RedoLog Dateien werden automatisch nachgezogen. Bei der logischen Standby-Datenbank braucht dazu jedoch kein FAL Server angegeben zu werden. Einpflegen der Informationen in die Datenbank Der Unterschied zwischen den beiden Standby Systemen liegt in der Art und Weise, wie die Informationen des Redo Stroms in die Datenbank eingepflegt werden. Bei der physikalischen Standby-

Datenbank wird ein Recovery der Datenbank vorgenommen. Währenddessen steht die Datenbank den Benutzern nicht zur Verfügung. Das Einpflegen der Informationen aus dem Redo Strom in die logische Standby-Datenbank geschieht jedoch auf einem ganz anderen Weg: Mit Hilfe des LogMiners werden die SQL Statements der Produktionsdatenbank rekonstruiert. Anschließend werden die Statements über eine sogenannte SQL ApplyEngine in der logischen Standby-Datenbank nachgefahren. Die logische Standby-Datenbank ist dabei die ganze Zeit geöffnet und steht den Benutzern zur Verfügung. Da bei der logischen Standby-Datenbank SQL Statements ausgeführt werden, werden selbstverständlich auch Redo Informationen erzeugt. Keine 1:1 Kopie Die Verwendung des LogMiners und der SQL Apply-Engine bringt jedoch eine Einschränkung in den unterstützten Datentypen mit sich. Unterstützt werden: • CHAR, NCHAR, VARCHAR2, VARCHAR • NUMBER • DATE, TIMESTAMP • INTERVAL • RAW • CLOB, BLOB Nicht unterstützt werden derzeit NCLOB, LONG (RAW), BFILE, ROWID sowie durch den Benutzer definierte Datentypen. Aus diesen Gründen ist die logische StandbyDatenbank, im Gegensatz zur physikalischen Standby-Datenbank, keine 1:1 Kopie der Produktionsdatenbank und kann somit auch nicht zu Backup Zwecken genutzt werden. Aufbau einer logischen Standby-Datenbank

Abb. 1: Installation einer logischen Standby-Datenbank.

36

Nach dieser Einführung wollen wir jetzt eine logische Standby-Datenbank aufbauen. Das

Datenbanken

grundsätzliche Vorgehen wird in Abbildung 1 dargestellt. Im Gegensatz zur physikalischen StandbyDatenbank wird hier keine Standby-Controldatei benötigt, sondern eine normale Backup-Controldatei. Doch jetzt die Schritte im Einzelnen: 1. Schritt auf der Produktionsdatenbank

Der init.ora Parameter log_parallelism steht standardmäßig auf 1. Sollte dieser Parameter bei der Produktionsdatenbank einen Wert > 1 haben, ist er auf den Standard zurückzusetzen. 3. Schritt auf der Produktionsdatenbank Der folgende Schritt ist nur erforderlich, wenn ein Switchover stattfinden soll. Eine logische Standby-Datenbank benötigt eine Reihe von Tabellen, die in den Schemata der user sys und system definiert sind.

Nach dem Entschluss, eine logische StandbyDatenbank aufzubauen, sollten wir als erstes das Skript ?/rdbms/admin/catlsby.sql laufen lassen, da es nicht von catalog bzw. catproc aufgerufen wird. Dieses Skript füllt die DataDictionary Views, die beim Betrieb einer logischen Standby-Datenbank sinnvoll sind, mit Leben. Die Namen dieser Views beginnen mit DBA_LOGSTDBY.

Einige dieser Tabellen können sehr schnell sehr groß werden, daher sollten sie in einen separaten Tablespace gelegt werden. Wir legen also einen neuen Tablespace mit beispielsweise dem Namen logminer an. Anschließend wenden wir die Prozedur DBMS_LOGMNR_D.SET_TABLESPACE an.

Zur Ermittlung eventuell vorhandener, nicht unterstützter Datentypen und Objekte wird das Kommando select * from dba_logstdby_ unsupported abgesetzt. Hier werden Eigner, Tabellennamen, Spaltenamen und Datentypen zurückgegeben. Jede hier angegebene Tabelle wird beim Log Apply auf der Standby-Datenbank automatisch ausgenommen.

Damit sind die vorbereitenden Schritte auf der Produktionsdatenbank abgeschlossen. Wir machen jetzt ein offline Backup der Datenbank und mounten diese anschließend, um eine BackupControldatei zu erzeugen. Außerdem ermitteln wir die aktuelle Checkpoint Change Nummer und können danach die Datenbank wieder öffnen. (Es geht auch mit einem online Backup.)

Anschließend untersuchen wir mit der Abfrage der View dba_logstdby_not_unique, ob unsere Datenbank Tabellen ohne Primary Key oder Not-Null Constraints besitzt. Gibt es solche Tabellen in unserer Datenbank, sollten wir für diese einen Primary Key definieren. 2. Schritt auf der Produktionsdatenbank Als nächstes überprüfen wir, ob die Produktionsdatenbank im ArchiveLog Modus läuft. Läuft die Datenbank nicht in diesem Modus, schalten wir ihn in der Mount-Phase ein. Eine logische Standby-Datenbank kann ausschließlich Daten mit supplemental logging verarbeiten. Normalerweise kommen aber im Redo Strom supplemental und nonsupplemental log Daten vor. Daher ist auf jeden Fall mit dem Kommando ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS; die Funktion „supplemental logging“ einzuschalten. Für jede vorher angelegte physikalische Standby -Datenbank unserer Konfiguration ist dieses Kommando ebenfalls abzusetzen, damit der Switchover sauber funktioniert. Danach müssen die beiden Spalten SUPPLEMENTAL_ LOG_DATA_PK und SUPPLEMENTAL_LOG_ DATA_UI der View v$database jeweils den Wert Y zurückgeben.

EXECUTE DBMS_LOGMNR_D.SET_TABLESPACE(’logminer’); Weitere Anpassungen

Die wichtigste Änderung der init.ora auf dem Standby System ist, den Parameter STANDBY_ARCHIVE_DEST hinzuzufügen. Eventuell sind noch die Pfade zu den Controldateien und der ARCHIVE_LOG_DEST_n Parameter anzupassen. Weiterhin ist die Passwortdatei auf das neue System zu kopieren. Mounten der logischen Standby-Datenbank Jetzt können wir die logische Standby-Datenbank zunächst mounten. Sollten sich die Pfade zu den Datenbank Dateien und RedoLog Dateien geändert haben, so müssen diese jetzt angepasst werden. Die von der physikalischen Standby Datenbank bekannten Parameter DB_FILE_NAME_CONVERT und LOG_FILE_NAME_ CONVERT funktionieren bei der logischen Standby-Datenbank nicht. Da wir in unserem Backup nur die Datenbank Dateien berücksichtigt haben, müssen wir die online RedoLog Dateien mit dem Kommando ALTER DATABASE CLEAR LOGFILE GROUP n; neu anlegen. Recovern Danach recovern wir unsere zukünftige logische Standby-Datenbank mit der BACKUP CONTROLFILE Option bis zur vorher gemerkten Checkpoint Change Nummer: RECOVER DATABASE UNTIL CHANGE USING BACKUP CONTROLFILE; Anschließend müssen wir die Datenbank mit der RESETLOGS Option öffnen. Damit im geöffneten Zustand keine Änderungen an den Daten vorgenommen werden können, setzen wir folgende Kommados ab:

37

Datenbanken

ALTER DATABASE GUARD ALL; ALTER DATABASE OPEN RESETLOGS; SHUTDOWN IMMEDIATE; DBID und Datenbankname Im nächsten Schritt ändern wir die DBID und den Datenbanknamen unserer logischen Standby-Datenbank. Dazu benutzen wir das Kommadozeilen-Tool nid. Zunächst ist jedoch unsere Datenbank in die Mount Phase zu versetzen. Danach gehen wir zurück auf die Shell Ebene und setzen folgendes Kommando ab: nid target=sys/change_on_install dbname=log1 Der hier angegebene Datenbankname ist der neue Name der logischen Standby-Datenbank. Unsere Datenbank hat nun eine neue DBID und einen neuen Datenbanknamen. Der neue Name bedingt natürlich auch eine entsprechende Änderung der init.ora, bzw. der spfile. Außerdem ist die Passwortdatei neu anzulegen. Auch jetzt öffnen wir die Datenbank wieder mit der RESETLOGS Option und legen ein neues Tempfile für den temporären Tablespace an. Im Weiteren gehen wir davon aus, dass die Oracle Net Konfiguration steht und die Instanzen sich gegenseitig „sehen“ können.

wir der logischen Standby-Datenbank, wo die archivierten RedoLog Dateien liegen, deren Inhalte in die Datenbank eingepflegt werden sollen. Die angegebene Sequenz Nummer ist die der ersten, archivierten RedoLog Datei nach dem offline Backup. SQL Apply Damit die logische Standby-Datenbank mit dem SQL Apply beginnen kann, muss zunächst auf der Produktionsdatenbank ein LogMiner Dictionary aufgebaut und auf die logische Standby-Datenbank übertragen werden. Dies geschieht mit dem Aufruf EXECUTE DBMS_LOGSTDBY.BUILD; auf der Produktionsdatenbank. Die LogMiner Dictionary Informationen werden in den Redo Strom eingebettet. Mit Abfragen auf die V$ARCHIVED_LOG SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN=’YES’; SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END=’YES’; können wir sehen, in welche RedoLog Dateien die Dictionary Informationen hinein gespeichert wurden.

Übertragen der Redo Informationen Wir können jetzt also mit ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=’SERVICE=log1, LGWR’; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE; dafür sorgen, dass die Redo Informationen zum Standby System übertragen werden. Dabei schreibt der LGWR direkt in die vorher in der init.ora der logischen Standby-Datenbank definierte STANDBY_ARCHIVE_DEST. Mit dem Kommando ALTER DATABASE REGISTER LOGICAL LOGFILE ‘/oracle/admin/log1/ora1_1_139.arc’ erklären

Da die Übertragung der RedoLog Dateien auf das Standby System bereits eingeschaltet ist, befinden sich die Dictionary Informationen auch auf dem Standby System. Mit dem Kommando ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL; beginnt das SQL Apply. Dieses Kommando ist auf der logischen Standby-Datenbank nur einmal abzusetzen. Soll das Nachfahren der Transaktionen gestoppt werden und anschließend wieder gestartet werden, geschieht dies wie folgt: ALTER DATABASE STOP LOGICAL STANDBY APPLY; ALTER DATABASE START LOGICAL STANDBY APPLY; Da nach einem Neustart der logischen Standby-Datenbank das Nachfahren der Transaktionen nicht automatisch gestartet wird, ist es mit ALTER DATABASE START LOGICAL STANDBY APPLY; nach dem Öffnen der Datenbank manuell zu starten. Den grundsätzlichen Ablauf zwischen Produktionsdatenbank und logischer Standby-Datenbank zeigt Abbildung 2.

Abb. 2: Ablauf zwischen Produktion und Standby.

38

Über verschiedene Views lässt sich der Erfolg und Fortschritt des SQL Apply verfolgen (siehe Abbildung 3).

Datenbanken

Abb. 3: Erfolg und Fortschritt des SQL Apply.

Abb. 4: Auszug aus DBA_LOGSTDBY_LOG.

Hier ist zu sehen, bis zu welcher SCN die Transaktionen nachgefahren wurden, und welches die letzte bekannte SCN ist. Hält man beispielsweise das SQL Apply an, so ändert sich zwar die Spalte NEWEST_SCN, nicht aber der Wert der Spalte APPLIED_SCN. Mit Hilfe der beiden oben genannten Spalten lässt sich über die View DBA_LOGSTDBY_LOG ermitteln, welches die aktuelle RedoLog Datei ist und welche noch nachgefahren werden muss. Außerdem ist hier auch zu sehen, in welchen Dateien die Dictionary-Informationen liegen (siehe Abbildung 4). In der View DBA_LOGSTDBY_EVENTS werden wichtige Ereignisse wie beispielsweise das Starten oder Anhalten des Log Apply protokolliert. Aber auch ein erfolgreiches DDL Kommando wird protokolliert. select STATUS from dba_logstdby_events; ORA-16204: DDL successfully applied Möchte man wissen, was sich dahinter verbirgt, hilft ein Blick in die alert.log Datei: LOGSTDBY event: ORA-16204: DDL successfully applied LOGSTDBY stmt: create table ak2 ( s1 number, s2 varchar2(25), constraint ak2_pk primary key (s1))

Was ist mit Logical Data Guard nun möglich? Vergleichen wir noch mal das, was wir jetzt können, mit dem, was im ersten Artikel dieser Reihe an Forderungen aufgestellt wurde.

•

Das Offline Backup über die logische Standby-Datenbank ist nicht möglich.

•

Eine zeitverzögerte Einspielung (Delay) der RedoLog-Dateien ist ohne großen Aufwand möglich.

•

Ein Tausch der Funktionalität zwischen Standby-Datenbank und Original-Datenbank (Switchover) ist möglich.

•

Es ist möglich, während des Nachfahrens der SQL Statements lesend auf die logische Standby-Datenbank zuzugreifen. Weiterhin lassen sich an der logischen Standby-Datenbank Änderungen, wie beispielsweise zusätzliche Indizes, vornehmen.

Im nächsten Teil dieser Reihe werden wir uns mit dem Package dbms_logstdby beschäftigen und den Switchover auf die logische Standby-Datenbank durchführen. Darüber hinaus schauen wir uns an, wie wir mit dem DataGuard Broker die Administration vereinfachen. Für Fragen, Anregungen und weitere Informationen steht Ihnen der Autor jederzeit gerne zur Verfügung.

Andreas Kother ([email protected]).

39