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 <9.40}
create table syspaghdr
(
pg_partnum integer,
pg_pagenum integer,
pg_physaddr integer,
pg_stamp
integer,
pg_stamp2
integer,
pg_nslots
pg_flags
pg_frptr
pg_frcnt
pg_next
pg_prev
);
smallint,
smallint,
smallint,
smallint,
integer,
integer
{ Page Headers 9.40}
create table syspaghdr
(
pg_partnum integer,
pg_pagenum integer,
{ partition number of page
}
{ logical page number in partn }
{ physische Adresse}
{ TimeStamp 1
}
{ TimeStamp 2
}
{
{
{
{
{
{
{
{
{
{
pg_nslots
pg_flags
pg_frptr
pg_frcnt
pg_pgnext
pg_pgprev
Chunk
Offset
TimeStamp
Checksumme
}
}
}
}
}
}
}
}
}
}
pg_chunk
pg_offset
pg_stamp
pg_chksum
integer,
integer,
integer,
smallint,
pg_nslots
pg_flags
pg_frptr
pg_frcnt
pg_next
pg_prev
);
smallint,
smallint,
smallint,
smallint,
integer,
integer
Abb. 9: Vergleich der Pseudo Tabelle syspaghdr aus der Sysmaster Datenbank.
Der BIG Chunk Mode
Nach einer Migration bzw. einer Erst-Initialisierung befindet sich
die Instanz im „Legacy Mode“. In diesem Zustand können keine
Chunks > 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 <= Risikoklasse des Kunden.
Wenn eine Risikoklasse des Kunden <= 2, dann darf ein
Einzelwert nicht mehr als 20 % des Gesamtvolumens
ausmachen.
Wenn eine Risikoklasse des Kunden > 2, dann darf ein
Einzelwert nicht mehr als 35 % des Gesamtvolumens
ausmachen.
Fondsinkompatibilitäten (z. B. X-FondS nicht mit Y-Fonds).
Papiere mit der höchsten Bewertung werden zum Verkauf
vorgeschlagen.
Abb. 6: Mögliche Regeln für die Portfolio-Konfiguration.
„Welches Werbemedium ist für mein Vorhaben das
geeignete?“
Ziel ist in diesem Beispiel die Schaffung eines virtuellen Marktplatzes, auf dem Medien aller Gattungen (Zeitschriften, Zeitungen, Außenwerbung, Hörfunk, TV, Online, Kino) geplant, gebucht
und bezahlt werden können.
Beratungsprozess
Der Beratungsprozess beinhaltet als Basiskomponenten die
Werbemedien und die Werbeprodukte. Die heterogene Struktur
der Werbemedien ist in Abbildung 8 vereinfacht dargestellt.
17
Java/XML
Abb. 7: Konfiguration von Werbeprodukten am Beispiel einer Tageszeitung.
Ein Werbeprodukt ist eine Werbefläche, die in den Werbemedien
gebucht werden kann. Auf Basis der Attribute und Preise eines
Werbemediums kann ein Werbeprodukt konfiguriert werden:
z. B. eine ganzseitige, farbige Anzeige am Freitag in der Süddeutschen Zeitung.
Die Auswahl der Werbemedien erfolgt über einen Kategorie-Editor. Die Kategorien entsprechen den vorgegebenen Medienstrukturen. Oberkategorien wären also Fachzeitschriften, Tageszeitungen usw. Darunter fände man dann die einzelnen Produkte
(z. B. unter Tageszeitungen: FAZ, WAZ, SZ usw.). Hier wählt der
Nachfrager die Medien aus, bei denen er Werbung schalten möchte. Nach der Auswahl gelangt der Benutzer zur Konfiguration der
Werbeprodukte.
Ein Nachfrager kann sich beliebig viele Werbeprodukte konfigurieren, diese für seinen Account persistent machen und die Vorund Nachteile abwägen. In Abbildung 7 ist dies am Beispiel einer
Tageszeitung vereinfacht dargestellt.
Weiterhin werden konkrete Werbeprodukte (Konfigurationen) vom
System vorgegeben. Damit können z. B. Restposten und Sonderangebote abgebildet werden, die vom Anwender nicht weiter konfiguriert werden können.
•
Mediengattungen
• Fachzeitschriften
• Formatangaben
• Schaltungszeiträume
• Buchungszeiten
• Preislisten
• Zeitungen
• Formatangaben
• Diverse Attribute
• Preislisten
•
•
Plakate
• Formatangaben
• Soziodemographische Daten
• Preislisten
Kino
• Formatangaben
• Verfügbarkeitstermine
• Preislisten
Abb. 8: Die heterogene Struktur der Werbemedien.
18
Hat der Nachfrager sich entschieden, kann er
über das Portal die gewählten Werbemedien
(bzw. Werbeprodukte) buchen.
Ein Nachfrager kann im Anbieterkreis von
Werbemedien über das Portal eine Ausschreibung nach individuell gestaltetem Werbemedium bzw. Werbeprodukt starten. Ein Anbieter kann Ausschreibungen im Portal durchsehen und hat die Möglichkeit, über das Portal
ein spezielles Angebot an den Kunden zu versenden.
Über die erfasste Struktur der Werbemedien
können Regeln und Preisformeln gelegt werden. Der Nachfrager wird bei der Konfiguration auf diverse Sachverhalte hingewiesen und
die Regeln garantieren, dass nur gültige Werbeprodukte konfiguriert werden. Abbildung 9
enthält eine kleine Auswahl von möglichen Regeln zum Thema 4-Farbdruck.
•
Ganzseitige Anzeigen sind nur in 4Farbdruck möglich.
•
•
Samstags kein 4-Farbdruck möglich.
Der Aufpreis für einen 4-Farbdruck ergibt sich aus dem doppelten Preis für
das gewählte Format.
Abb. 9: Mögliche Regeln zum 4-Farbdruck.
Mit dieser Ausgabe der ORDIX News endet
die Artikelserie zur eSelect Suite. Wir hoffen,
Ihnen einen umfassenden Überblick über die
Funktionalitäten der eSelect Suite und ihre
vielfältigen Einsatzmöglichkeiten gegeben zu
haben.
Bei Fragen zur eSelect Suite wenden Sie sich
bitte an [email protected]. Wir beraten Sie
gerne!
Manfred Lingk, Object Systems GmbH
([email protected]).
>(*,.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<SID>.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<SID>.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 <SCN> 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<SID>.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<SID>.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<SID>.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