Hochverfügbarkeit

Ausgewählte Themen zur ORACLEDatenbankadministration in der Praxis
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 1
Leistungsspektrum der GISA GmbH
Zahlen und Fakten auf einem
Blick:
Geschäftsführer:
Michael Krüger
Dr. Bernd Tigges
Umsatz 2006: 64,3 Mio. €
Mitarbeiter 2007: 383
Gründungsjahr: 1993
Gesellschafter:
• envia Mitteldeutsche Energie AG
(64,9%)
• Stadtwerke Halle GmbH (25,1%)
• Mitteldeutsche Gasversorgung
GmbH (10 %)
Beteiligungen:
• ICS adminservice GmbH (100%)
• SASKIA Informationssysteme
GmbH (90%)
Mehr als Standard. Überzeugen Sie sich!
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 2
Kunden der GISA
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 3
Agenda
Oracle Datensicherung
Hochverfügbarkeit
Sichere Konfiguration von Oracle-Datenbanken
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 4
ORACLE Datensicherung
Grundlagen und Vorüberlegungen
Backup-Methoden
Sicherungsstrategie
Verwendung von OSL-Storagecluster
Einsatz von Oracle RMAN
ASM (Automatic Storage Management)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 5
Grundlagen und Vorüberlegungen
Ziele der Datensicherung
 Hauptziel: „Keep the system running“
Schutz der Datenbank vor verschiedenen Fehlertypen
Mean-Time-Between-Failures (MTBF) erhöhen
Mean-Time-To –Recover (MTTR) vermindern
Datenverluste minimieren
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 6
Grundlagen und Vorüberlegungen
ORACLE Überblick (1)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 7
Grundlagen und Vorüberlegungen
ORACLE Überblick (2)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 8
Grundlagen und Vorüberlegungen
Konzept der Archive-Logs
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 9
Grundlagen und Vorüberlegungen
Fehlerkategorien (1)
 Anweisungsfehler (Statement Failure)
 Benutzer-Prozess-Fehler (User Process Failure)
 Benutzer-Fehler (User Error)
 Instanz-Fehler (Instance Failure)
 Media-Fehler (Media Failure)
 Netzwerk-Fehler (Network Failure)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 10
Grundlagen und Vorüberlegungen
Fehlerkategorien (2)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 11
Grundlagen und Vorüberlegungen
Tägliche Aufgaben
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 12
Grundlagen und Vorüberlegungen
Logische vs. Physikalische Datenstruktur
Logische Datenstruktur

Extent
Jedes Segment besteht aus einer Reihe von einem oder
mehreren Extents. Kommt ein Segment an seine
Kapazitätsgrenze, erzeugt die Datenbank einen neuen Extent.
Ein Extent ist die kleinste Einheit bei der Reservierung von
Speicherplatz

Segment
Reservierter Bereich für Tabellen.
Jede Tabelle besitzt genau 1 Daten-Segment und jeder Index
besitzt ein Index-Segment. Desweiteren gibt es
Rollbacksegmente und temporäre Segmente

Tablespace
Alle Segmente werden in Tablespaces zusammengefaßt. Ein
Tablespace ist die logische Einheit zur Speicherzuteilung. Ein
Tablespace umfaßt mindestens eine Datenbankdatei.

Datenbank
Eine Datenbank besteht aus einem oder mehreren
Tablespaces. Ein DBMS kann mehrere Datenbanken
(Instanzen) verwalten.
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 13
Physikalische Datenstruktur

Blöcke
Jede Datei besteht aus einer Anzahl von Oracle-Blöcken.
Jeder Oracle Block besteht aus einem oder mehreren
Plattenblöcken.

Datenbankdateien
In einer Datenbankdatei sind z.B. Tabellen der Datenbank
abgelegt.
Darüberhinaus gibt es Dateien mit speziellen Aufgaben (z.B.
Tracefile, Controlfile)
Backup-Methoden
Logische Sicherung
 Export der Datenbank ist ein „Schnappschuss“ des aktuellen Zustandes
 bei einer logischen Sicherung werden keine Dateien kopiert, sondern die Daten
aus der Datenbank ausgelesen und in einer speziellen binären DUMP-Datei
abgelegt
 für einen Export wird das Kommandozeilenprogramm exp benutzt
 das Programm kann sowohl interaktiv als auch mit Parametern gesteuert
werden. Zum Sichern einer gesamten Datenbank eignet sich z.B. die folgende
Vorgehensweise:
exp userid=system/manager file=full_export.dmp full=yes
rows=y consistent=yes
 der Datenbestand in der Export-Datei umfasst ausschliesslich die Daten zum
Zeitpunkt zu Beginn des Exports
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 14
Backup-Methoden
Physikalische Sicherung (Cold Backup)
 einfachstes Verfahren für Sicherung einer Datenbank
 nach Herunterfahren der Datenbank werden alle Dateien der
Tablespaces (ausser TEMP-Tablespace), Controlfiles, OnlineRedologs und weitere (z.B. INIT.ORA) kopiert
 Nachteil: Datenbank ist Offline
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 15
Backup-Methoden
Physikalische Sicherung (Hot Backup) - Überblick
 ARCHIVELOG-Modus wird verwendet, wenn es nicht akzeptabel
ist, Daten zu verlieren (z.B. Ausfall einer Festplatte)
 Controlfiles, Online-Redos und Archivelogs sollten gespiegelt
sein
 Unvollständiges Recovery möglich (PITR)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 16
Backup-Methoden
Physikalische Sicherung (Hot Backup) - Schritte
1. Strukturen bestimmen:
aus Oracle die Liste aller Tablespaces und Datenfiles herausbekommen (v$datafile)
die Ablage der Archived Redologs herausfinden (z.B. v$archived_log, Parameter:
log_archive_dest)
den Speicherort der Controlfiles herausfinden (Parameter: control_files)
2. in einer Schleife Tablespaces in Backup-Modus bringen und Daten kopieren: jeden
Tablespace seriell:
in den Backup- Modus versetzen (alter tablespace [name] begin backup) und
die Daten an einen anderen Platz kopieren und
Backup-Modus für Tablespace wieder ausschalten (alter tablespace [name] end
backup).
3. Nacharbeiten (Sicherung zusätzlicher Dateien)
einen Switch der Online-Redologs auslösen (alter system switch logfile)
Controlfile mit dem Befehl sichern (alter database backup controlfile to …)
Controlfile kopieren
aktuelle Online-Redologs kopieren (v$logfile)
alle Archivelogs sichern, die bis zu diesem Backupvorgang nicht gesichert wurden
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 17
Backup-Methoden
Physikalische Sicherung (Hot Backup) – Ergebnis = Redundanz-Set
 den kompletten Satz aus Dateien, die man nach einem Oracle-Ausfall
besitzten sollte, nennt man ein Redundanz-Set
 ein Redundanz-Set besteht aus:
dem letzten Backup aller Datenbankdateien
allen archivierten Redologs nach dem letzten Backup
einer Kopie der Online Redologs
einer Kopie des aktuellen Controlfiles
den aktuellen Konfigurationsdateien wie Initialisierungsdatei (INIT.ORA),
eventuell auch LISTENER.ORA, SQLNET.ORA, und Exportdumps
 Speicherort des Redundanz-Set
auf Band sichern
mindestens eine Kopie auf der Platte behalten
wenn die Datenbank auf einem RAID-System sitzt, sollte das RedundanzSet nicht auf demselben RAID sitzen
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 18
Sicherungsstrategie
Überlegungen zur Sicherungshäufigkeit und der Backup-Methode
 Warum, wie oft und wie soll meine Datenbank gesichert
werden?
 Ist es akzeptabel, Daten zu verlieren, wenn eine Festplatte
versagt und dadurch Datenbankdateien beschädigt werden?
 Muss man vielleicht irgendwann einmal einen vorherigen
Zustand wiederherstellen können?
 Muss die Datenbank rund um die Uhr verfügbar sein?
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 19
Sicherungsstrategie
Sicherungshäufigkeit und Sicherungsobjekte
 Vollständiges Datenbankbackup
nach Erstellung einer Datenbank als Basis für weitere Backups
nach Datenbankoperationen, für die nologging eingeschaltet wird
nach einem Öffnen der Datenbank mit der RESETLOGS-Option

Backups nach strukturellen Änderungen der Datenbank
Tablespaces werden angelegt oder gelöscht
Datendateien werden zu Tablespace hinzugefügt oder entfernt
Änderungen der Online-Redologs (Anzahl Member, Gruppen)
 die Backuphäufigkeit
hängt von folgenden Änderungen in der Datenbank ab
Menge der hinzugefügten oder gelöschten Tabellen
(Daten-) Menge der hinzugefügten oder gelöschten Tabellenzeilen
Updatehäufigkeit der Tabellen
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 20
Sicherungsstrategie
Wahl der Sicherungsstrategie (1)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 21
Sicherungsstrategie
Wahl der Sicherungsstrategie (2) - Verfügbarkeit
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 22
Sicherungsstrategie
Wahl der Sicherungsstrategie (3) – Bedeutung der Archivelogs
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 23
Sicherungsstrategie
Wahl der Sicherungsstrategie (4) – Empfehlungen (SAP)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 24
Sicherungsstrategie
Wahl der Sicherungsstrategie (3) - Bestimmung Bandkapazität
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 25
Sicherungsstrategie
Crontab eines DB-Servers
oracle@host1:/export/home/oracle>crontab -l
0 20 * * 6
/var/opt/oracle/scripts/export.sh ORCL1
0 21 * * 1,3,5 /var/opt/oracle/scripts/backup.sh SID=ORCL1 MODE=H
0 22 * * 1,3,5 /var/opt/oracle/scripts/backup.sh SID=ORCL2 MODE=H
0 23 * * 1,3,5 /var/opt/oracle/scripts/backup.sh SID=ORCL3 MODE=H
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 26
Verwendung von OSL Storage Cluster
Was ist OSL
 Integration verschiedenster RAIDSysteme in den Storage Pool
 keine zusätzliche Hardware nötig
 Storage kann online erweitert werden
(bzw. SAN-Umbau während Dialogzeit)
 Anwendungssteuerung und
Hochverfügbarkeit
 Konzept der Universen
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 27
Verwendung von OSL Storage Cluster
Datensicherung mit OSL Mitteln
Server A
Oracle DB
ORCL1
Speichersystem 1
Datanbank ORCL1
/var/opt/oradata/ORCL1/
Gerät /dev/dsk/av0/orcl1data
O
S
L
Datenbank ORCL2
/var/opt/oradata/ORCL2/
Gerät /dev/dsk/av0/orcl2data
Speichersystem 2
Server B
Oracle DB
ORCL2
Datenbank ORCL1
/var/opt/oradata/ORCL1/
Gerät /dev/dsk/av1/orcl1data
O
S
L
Datenbank ORCL2
/var/opt/oradata/ORCL2/
Gerät /dev/dsk/av1/orcl2data
Datenbank ORCL3
/var/opt/oradata/ORCL3/
Gerät /dev/dsk/av0/orcl3data
Server C
Oracle DB
ORCL2 (TEST)
Oracle DB
ORCL3 (TEST)
Backup Server
O
S
L
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 28
O
S
L
Tape-Library
Verwendung von OSL Storage Cluster
Steuerung der OSL-Software (Beispiel)
oracle@host1:/var/opt/oracle>df –k
Filesystem
kbytes
used
/dev/dsk/av0/orcldata 122891472
avail
95704285 25958273
capacity
79%
Mounted on
/var/opt/oradata/ORCL1
root@host1 # avmirror -q |grep orcldata
0 orcldata (simple, 1 piece) MASTER SOURCE s---- synchronized
1 orcldata (simple, 1 piece) image target s---- synchronized
root@host1 # avmirror -u1 -d orcldata -L
INFO (avmirror): "1 orcldata" disconnected from mirror (io logging).
root@host1 # avmirror -q |grep orcldata
0 orcldata (simple, 1 piece) MASTER SOURCE s-1-- synchronized
1 orcldata (simple, 1 piece) image s0123 disconnected
root@host1 # avmirror -u1 -c orcldata
INFO (avmirror): "1 orcldata" connected as mirror instance, starting sync.
root@host1 # avmirror -q |grep orcldata
0 orcldata (simple, 1 piece) MASTER SOURCE s-1-- synchronized
1 orcldata (simple, 1 piece) image target s0123 synchronizing (1.0%)
root@host1 #
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 29
Einsatz von Oracle RMAN
Überblick
Recovery Manager
RMAN>
Recovery
KatalogDatenbank
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 30
Ziel-Datenbank
Einsatz von Oracle RMAN
Backup-Typen

Image Kopie (auf Platte)
ImageKopie

Backup Set (auf Platte oder Tape)
Datenbankdateien

Full Backup
sichert alle benutzten Datenbankblöcke

Datei
Inkrementelles Backup
sichert alle seit der letzten Sicherung
geänderten Datenbankblöcke
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 31
Backup Set
Einsatz von Oracle RMAN
Vor- und Nachteile
Vorteile:
 vollständige Integration in Oracle (kein begin|end backup)






Integration in OEM
nur benutzte Oracle Blöcke werden gesichert
höhere Flexibilität (z.B. Read Only Tablespaces überspringen)
Erkennung korrupter Blöcke
einfacheres TSPITR
arbeitet (angeblich) mit jeder Backup Software
Nachteile:
 Kompatibilitätsprobleme (eventuell mehrere KatalogDatenbanken notwendig)
 Oracle Kenntnisse und initialer Administrationsaufwand nötig
 „Information Hiding“
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 32
Automatic Storage Management
Problematik beim physischen Layout einer Datenbank
 Abschätzung des benötigten Plattenplatzes (einschliesslich der
Schätzung des Wachstumsrate)
 Verteilung der Datenbankdateien (Datafiles, Redologs, usw.) auf
Devices
 Layout des Storagesubsystems (RAID-Sets, LUNs) – in der
Verantwortung der Storageadministratoren
 Anlegen von Logical Volumes und Filesystemen – in der
Verantwortung der Systemadministratoren
 Anlegen von Datenbanken (und all ihren Dateien)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 33
Automatic Storage Management
Eigenschaften
 ab Oracle 10g verfügbar (kostenlos)
 Oracle-Funktionen zur Unterstützung der Festplatten und TablespaceAdministration (autom. Rebalancing, Redundanzdefinitionen/Spiegelungen)
 ASM verbindet die Funktionalität eines Filesystems und eines Volume-Managers
im Oracle-Kernel (die Administration wird so vom Systemadministrator zum DBA
verlagert)
 Speicherung folgender Oracle-Dateien: Controlfiles, Online-Redologs und
Archivelogs, Datenfiles
 Gruppierung von physischen Festplatten zu logischen Diskgruppen
 zusätzliche Funktionen zur Verwaltung und Administration von OracleDatenbanken
 wird über zusätzliche Instanz (+ASM) verwaltet
 Oracle-DBs, die mit ASM arbeiten, können nur mit RMAN gesichert werden
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 34
Automatic Storage Management
Anlegen einer Diskgroup
SQL> CREATE DISKGROUP prod_01 NORMAL REDUNDANCY
2
FAILGROUP disk_set_01 DISK ´/dev/md/dsk/d0´ NAME asm_disk_01,
3
4
´/dev/md/dsk/d1´ NAME asm_disk_02
FAILGROUP disk_set_02 DISK ´/dev/md/dsk/d2´ NAME asm_disk_03,
5
6
´/dev/md/dsk/d3´ NAME asm_disk_04
/
Diskgroup created.
SQL> SELECT name, state, type, total_mb, free_mb from v$asm_diskgroup;
NAME
STATE
TYPE
TOTAL_MB
FREE_MB
------------------- ---------- -------- ------------ -----------PROD_01
MOUNTED
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 35
NORMAL
3072
2968
Automatic Storage Management
Anlegen eines ASM-Tablespaces
 ASM übernimmt die Verwaltung für alle Datenbankinstanzen
 der Oracle Datenbankkern kann die ASM-Filesystemstruktur direkt benutzen
SQL> CREATE TABLESPACE data01
2
DATAFILE ´+prod_01/data01.dbf´ SIZE 500 MB
3
/
Tablespace created.
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 36
Agenda
Oracle Datensicherung
Hochverfügbarkeit
Sichere Konfiguration von Oracle-Datenbanken
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 37
Hochverfügbarkeit
Begriffsbestimmung
Hochverfügbarkeit mit Oracle
Zusammenfassung
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 38
Begriffsbestimmung
Definition
Ein System gilt als hochverfügbar, wenn eine Anwendung auch im
Fehlerfall weiterhin verfügbar ist und ohne unmittelbaren
menschlichen Eingriff weiter genutzt werden kann. In der
Konsequenz heißt dies, dass der Anwender keine oder nur eine
kurze Unterbrechung wahrnimmt. Hochverfügbarkeit (abgekürzt
auch HA, abgeleitet von engl. High Availability) bezeichnet also
die Fähigkeit eines Systems, bei Ausfall einer seiner
Komponenten einen uneingeschränkten Betrieb zu
gewährleisten.“
Quelle: Held, Andrea: Oracle 10g Hochverfügbarkeit, AddisonWesley 2004
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 39
Begriffsbestimmung
Definition
Die Verfügbarkeit eines Systems oder einer Systemkomponente ist
definiert als prozentualer Zeitanteil, in dem dieses System bzw. die
Komponente fehlerfrei funktioniert.
Downtime
Verfügbarkeit  1 
Uptime
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 40
Begriffsbestimmung
Einteilung in Verfügbarkeitsklassen (1)
 mit dieser Formel wird die Verfügbarkeit im Zeitraum eines
Jahres berechnet
 anhand der Anzahl der Neunen teilt man die Verfügbarkeitswerte
in Verfügbarkeitsklassen ein
 die Nummer der Klasse ist dabei die Anzahl der Neunen
 ein System mit weniger als 53 Minuten Downtime pro Jahr ist
damit mindestens in der Verfügbarkeitsklasse 4
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 41
Begriffsbestimmung
Einteilung in Verfügbarkeitsklassen (2)
Verfügbarkeit
Downtime [Jahr]
Verfügbarkeitsklasse
95 %
18 Tage, 6 Stunden
1
99 %
3 Tage, 15 Stunden, 36 Minuten
2
99,9 %
8 Stunden, 46 Minuten
3
99,99 %
53 Minuten
4
99,999 %
5 Minuten
5
99,9999 %
< 1 Minute
6
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 42
Begriffsbestimmung
Einteilung der HV durch die Harvard Research Group (HRG) in 6 Klassen
(Availability Environment Classification)
HRGKlasse
Bezeichnung Erklärung
AEC-0
Conventional
Funktion kann unterbrochen werden, Datenintegrität ist nicht
essentiell.
AEC-1
Highly Reliable
Funktion kann unterbrochen werden, Datenintegrität muss
jedoch gewährleistet sein.
AEC-2
High Availability
Funktion darf nur innerhalb festgelegter Zeiten oder zur
Hauptbetriebszeit minimal unterbrochen werden.
AEC-3
Fault Resilient
Funktion muss innerhalb festgelegter Zeiten oder während
der Hauptbetriebszeit ununterbrochen aufrechterhalten
werden.
AEC-4
Fault Tolerant
Funktion muss ununterbrochen aufrechterhalten werden, 24*7
Betrieb (24 Stunden, 7 Tage die Woche) muss gewährleistet
sein.
AEC-5
Disaster Tolerant
Funktion muss unter allen Umständen verfügbar sein.
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 43
Begriffsbestimmung
Ungeplante Ausfälle
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 44
Begriffsbestimmung
Wie erreicht man Hochverfügbarkeit?
 Hochverfügbare Hardware (Clustersystem z.B. RAC, Mirroring)
 Redundantes Netzwerk (Router, Switches, mehrere Anschlusspunkte an
öffentliches Netz, redundantes öffentliches Netz)
 Redundante Datenhaltung (Spiegelung, Oracle Advanced Replikation,
Oracle Streams, Standby-Datenbank)
 Messung der Verfügbarkeit (SLA, Application Performance Monitoring)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 45
Hochverfügbarkeit mit ORACLE
Übersicht
 Flashback (ab Oracle 9i, einige Funktionen ab 10g)
 Oracle Data Guard Physical Standby (Data Guard ab Oracle 8.1.7)
 Oracle Data Guard Logical Standy (ab Oracle 9i)
 Oracle Streams (ab Oracle 9i) (nur zur Info)
Oracle Advanced Replication (ab Oracle 7) (nur zur Info)
 Virtualisierung der ORACLE-Datenbankinstanz mittels OSLStorage-Cluster
 Oracle Fail Safe
 RAC (nur zur Info)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 46
Hochverfügbarkeit mit ORACLE
Flashback
 Flashback Query (Abfrage historischer Zustände)
 Flashback Table (Zurücksetzen ganzer Tabellen)
 Flashback Drop (Wiederherstellen gelöschter Tabellen)
 Flashback Database (Zurücksetzen gesamte Datenbank)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 47
Hochverfügbarkeit mit ORACLE
Flashback
Flashback Query (Beispiel)
SQL> SELECT * FROM test AS OF TIMESTAMP
to_timestamp(´30.01.2008 11:00:00´,´dd.mm.yyy
hh24:mi:ss´);
Flashback Table (ab 10g, benutzt UNDOTBS)
SQL> FLASHBACK TABLE test TO TIMESTAMP
to_timestamp(´30.01.2008 11:00:00´,´dd.mm.yyy
hh24:mi:ss´);
Flashback Drop (ab 10g, benutzt UNDOTBS)
SQL> FLASHBACK TABLE test TO BEFORE DROP;
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 48
Hochverfügbarkeit mit ORACLE
Flashback
Flashback Database
-- Herunterfahren der Datenbank
SQL> SHUTDOWN IMMEDIATE;
-- Hochfahren in den Mount Modus
SQL> STARTUP MOUNT;
-- Flashback absetzen
SQL> FLASHBACK DATABASE TO TIMESTAMP to_timestamp(´30.01.2008
11:00:00´,´dd.mm.yyy hh24:mi:ss´);
-- Datenbank öffnen
SQL> ALTER DATABASE OPEN RESETLOGS;
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 49
Hochverfügbarkeit mit ORACLE
Übersicht Standby-DB
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 50
Hochverfügbarkeit mit ORACLE
Data Guard Physical Standby-DB
Vorteile
Nachteile
kostenlos in der EE
nicht in der SE
geringer Administrationsaufwand
Oracle Lizenzen notwendig
automatische Übertragung aller
Änderungen (DDL und DML)
keine Nutzung der zusätzlichen Hardund Software möglich
kein Einfluss auf die Anwendung
gleiche Hardware und Betriebssysteme
„No-Data-Loss“-Konfiguration möglich
gleiche Oracle Releasestände
einfaches Switchover
Master-Slave-Prinzip
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 51
Hochverfügbarkeit mit ORACLE
Data Guard Logical Standby-DB
Vorteile
Nachteile
kostenlos in der EE
nicht in der SE
zusätzliche Hard- und Software kann
genutzt werden (Trennung OLTP und
Reporting möglich)
Oracle Lizenzen notwendig
geringer Administrationsaufwand
unterschiedliche Oracle Releasestände
ab 10.1.0.3 möglich
automatische Übertragung aller
Änderungen (DDL und DML)
gleiche Hardware und Betriebssysteme
geringer Einfluss auf die Anwendung
Master-Slave-Prinzip
„No-Data-Loss“-Konfiguration möglich
einfaches Switchover
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 52
Hochverfügbarkeit mit ORACLE
Oracle Streams
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 53
Hochverfügbarkeit mit ORACLE
Oracle Streams
Vorteile
Nachteile
kostenlos in der EE
nicht in der SE
zusätzliche Hard- und Software kann
genutzt werden (Trennung OLTP und
Reporting möglich)
hoher Administrationsaufwand
beteiligte Datenbanken sind
gleichberechtigt
Beeinflussung der produktiven
Umgebung durch Queue-Tabellen
automatische Übertragung aller
Änderungen (DDL und DML)
Konflikte müssen programmtechnisch
gelöst werden
keine Abhängigkeit von Hardware und
Betriebssystem
Abhängigkeit von Oracle-Version
kein manueller Eingriff für Umschaltung
nötig
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 54
Hochverfügbarkeit mit ORACLE
Oracle Advanced Replication
Vorteile
Nachteile
kostenlos in der EE
nicht in der SE
zusätzliche Hard- und Software kann
genutzt werden (Trennung OLTP und
Reporting möglich)
hoher Administrationsaufwand
beteiligte Datenbanken sind
gleichberechtigt
Produktionsumgebung muss angepasst
werden (Materialized View Logs)
bidirektionale Replikation möglich
Konfliktpotential (programmtechnische
Lösung erforderlich)
kaum Abhängigkeiten bezüglich
Hardware und Betriebssystem
kein manueller Eingriff für Umschaltung
nötig
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 55
Hochverfügbarkeit mit ORACLE
Virtualisierung der ORACLE-Datenbankinstanz mittels OSL-Storage-Cluster
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 56
Hochverfügbarkeit mit ORACLE
Oracle Fail Safe
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 57
Hochverfügbarkeit mit ORACLE
RAC-Architektur
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 58
Zusammenfassung
 Hochverfügbarkeit ist nicht auf die Datenbank beschränkt
 Software- und Anwendungsfehler sind die häufigsten
Fehlerursachen
 Anwender unterscheiden nicht zwischen keine oder
eingeschränkte Verfügbarkeit
 Service Level Agreements (SLA) sollten sich immer auf die
Gesamtanwendung beziehen
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 59
Agenda
Oracle Datensicherung
Hochverfügbarkeit
Sichere Konfiguration von Oracle-Datenbanken
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 60
Sichere Konfiguration von ORACLE Datenbanken
Einführung
Benutzer- und Passwortverwaltung
Schutz der Daten (Rollenkonzept, Schutz des DD, VPD)
Überwachung von Zugriffen (Auditing)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 61
Einführung
Marketingaussagen von Oracle
 Einbruchsicher
(Die Sicherheit von Oracle beweisen 14 unabhängige
Sicherheitszertifikate)
 Unschlagbar zuverlässig
(Oracle erfüllt 14 Sicherheitsstandards)
 Ausfallsicher
(Keine Ausfallzeiten mehr und auf jede mögliche Überraschung
vorbereitet)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 62
Einführung
Allgemeine Grundsätze - Vertraulichkeit
Empfänger
Sender
Abhören
Der Sender muss sicher sein, dass nur
sein Partner, der Empfänger, die Mitteilung
lesen kann. Eine Drittperson, die den
Transportweg abhört, darf diese
Information nicht verwerten können.
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 63
Einführung
Allgemeine Grundsätze - Integrität
Sender
Empfänger
Modifizieren
Der Sender und der Empfänger
müssen sicher sein, dass ihre Mitteilung
nicht durch eine Drittperson inhaltlich
verändert wurde.
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 64
Einführung
Allgemeine Grundsätze - Authentizität
Sender
Empfänger
Fälschen
Der Empfänger muss sicher sein, dass
die Nachricht auch vom Sender
kommt und nicht nur in dessen Namen
verfasst wurde.
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 65
Einführung
Allgemeine Grundsätze - Nichtabstreitbarkeit
?
Wer hat recht?
Sender
Nicht versendet
Empfänger
Erhalten
Der Sender behauptet:
Ich habe keine Nachricht versendet!
Der Empfänger behauptet:
Ich habe eine Nachricht vom Sender erhalten!
Wer hat recht?
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 66
Benutzer- und Passwortverwaltung
Wer hat mit DBA-Rechten Zugriff auf die Datenbank
 DBA
 Hinterlegte Passwörter (Safe)
 Unix und Windows Administratoren
 Jeder mit physikalischem oder Remotezugriff auf die
Arbeitsplätze der DBA (Hausmeister, Reinigungspersonal,
Sicherheitsdienst)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 67
Benutzer- und Passwortverwaltung
Standardbenutzer
 Je höher die Oracle-Version, desto mehr neue Benutzerkonten
werden automatisch eingerichtet
 Waren es bei Oracle7 die Benutzer SYS und SYSTEM, bei welchen
man das Standardpasswort (change_on_install, manager)
ändern musste, sind es bei Oracle 9i je nach installierten Features
über 20 Benutzerkonten
 Diese Benutzerkonten sind zum Teil sehr hoch privilegiert (DBA, all
privileges, …), da Oracle immer mehr Features in eigene Schemata
auslagert
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 68
Benutzer- und Passwortverwaltung
Standardbenutzer – Übersicht (10g)
Konto
CTXSYS
DBA
RESOURCE
(unlimited
tablespace)
execute
any
procedure
select
any
table
select any
dictionary





exempt
access
policy
alter
system


DBSNMP
LBACSYS



OLAPDBA



OLAPSVR



OLAPSYS



ORDPLUGINS

ORDSYS

OUTLN


MDSYS






WKSYS






XDB
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 69


Benutzer- und Passwortverwaltung
Eigenschaften guter Passwörter
 möglichst lang (max. 30 Zeichen)
 Oracle erlaubt keine Sonderzeichen, aber mit "…" möglich
 möglichst Zahlen und Buchstaben mischen
 einen Merksatz bilden:
z.B. „Ich wohne seit 1999 in Leipzig“ -> Iws1999iL
 an den "Faktor Mensch" denken …
(Passworte während Telefonat, auf Zetteln)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 70
Benutzer- und Passwortverwaltung
Alle Authentifizierungsarten
 Datenbankauthentifizierung (Überprüfung des Benutzers und
Passworts erfolgt autonom durch die DB)
 Externe Authentifizierung (Überprüfung des Benutzers durch
Datenbank, Überprüfung des Passworts durch Betriebssystem
oder Netzwerk)
 Globaler Benutzer (Authentifizierung durch Secure Socket
Layer)
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 71
Benutzer- und Passwortverwaltung
Betriebssystemauthentifizierte Benutzer
 Oracle hat schon seit Version 5 die Möglichkeit eingebaut, bei der
Anmeldung auf die Passworteingabe zu verzichten:
SQL> connect /
 sobald Oracle diese Syntax erkennt, wird der BetriebssystemBenutzername gelesen und diesem folgender INIT.ORA-Parameter
vorangestellt:
OS_AUTHENT_PREFIX = "OPS$" # Default
REMOTE_OS_AUTHENT = TRUE
# Default = FALSE
 wenn sich also der Benutzer MUELLER anmeldet, wird getestet, ob es
einen Oracle-Benutzer OPS$MUELLER gibt, wenn ja, wird dieser ohne
Passwort-Abfrage angemeldet
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 72
Benutzer- und Passwortverwaltung
Betriebssystemauthentifizierte Benutzer - Sicherheitshinweise

nach dem Aufruf (von Routinen) mit username/password Syntax läßt sich das Passwort gut in der Prozessliste finden
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 73
Benutzer- und Passwortverwaltung
Betriebssystemauthentifizierte Benutzer - Sicherheitshinweise

deshalb Nutzung von OPS$-Benutzern
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 74
Benutzer- und Passwortverwaltung
Passwort-Policies
 Standardmäßig sind bei Oracle keine Passwortrichtlinien aktiv,
das heißt, ein Benutzer ist nicht gezwungen, sein Passwort jemals
zu ändern
 Es sind keine Komplexitätsregeln festgelegt, so dass ein
beliebiges Passwort (beliebige Länge, beliebiger
Schwierigkeitsgrad, …) benutzt werden kann
 Ein Benutzer kann sich beliebig oft mit falschem Passwort
anmelden, ohne gesperrt zu werden
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 75
Benutzer- und Passwortverwaltung
Passwort-Policies
 ab Oracle 8 besteht die Möglichkeit, Passwort-Profiles zu
erzeugen, die den Benutzern zugeordnet werden können
 Zum Teil können die geforderten Werte direkt im EnterpriseManager (oder per SQL-Befehl) erfasst werden, zum Teil ist
PL/SQL-Programmierung notwendig
 Oracle liefert ein Beispielscript mit, welches als Vorlage benutzt
werden kann: $ORACLE_HOME/rdbms/admin/utlpwdmg.sql
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 76
Benutzer- und Passwortverwaltung
Passwort-Policies – Passwortprofiles im Enterprise Manager
Das Passwort muss nach
30 Tagen geändert
werden
Wird das Passwort nicht
geändert, wird das Konto
unendlich lang gesperrt
Das Passwort darf nach
365 Tagen wieder
verwendet werden
Nach 3 fehlerhaften
Anmeldeversuchen wird
das Konto 10 Tage
gesperrt
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 77
Benutzer- und Passwortverwaltung
Angriffsmöglichkeiten über Startup Dateien
 Einige Clients erlauben es, automatisch und versteckt bei jedem
Start, SQL-Befehle im Hintergrund auszuführen
 SQL*Plus: glogin.sql oder login.sql
(unter $ORACLE_HOME\sqlplus\admin)
 TOAD: toad.ini
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 78
Benutzer- und Passwortverwaltung
Angriffsmöglichkeiten über Startup Dateien – Beispiel glogin.sql
-------------- glogin.sql ---------------Create user hacker identified by hacker;
Grant dba to hacker;
-------------- glogin.sql ----------------
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 79
Benutzer- und Passwortverwaltung
Angriffsmöglichkeiten über Startup Dateien – Beispiel glogin.sql
-------------- glogin.sql ----------------
set term off
create user hacker identified by hacker;
grant dba to hacker;
set term on
-------------- glogin.sql ----------------
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 80
Schutz der Daten
Rollenkonzept
 User / Rolle
Einem User werden Objekt und Systemprivilegien vergeben, zur
Berechtigung von SQL-statements (DDL, DML)
Eine Rolle ist eine Gruppierung von Objekt-und oder
Systemprivilegien oder eine Gruppierung von Rollen (nested
Roles)
 Bei der Erstellung des Data Dictionary werden außer Objekten auch
Standardbenutzer und
Standardrollen angelegt.
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 81
Schutz der Daten
Rollenkonzept
 nur wenig Rollen als default role vergeben, denn auch
eine Passwort geschützte Rolle – solange sie default role
ist – wird ohne Passwortabfrage aktiviert
 setzen der Rollen zum benötigten Zeitpunkt durch die
Applikation
 Schreiben von Package-Procedures für INSERT, UPDATE,
DELETE etc. auf Tabellen von HR
 Grants der EXECUTE Privileges auf diese Package-Procedures
an die Application-User
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 82
Schutz der Daten
Schutz des Data Dictionary (1)

O7_DICTIONARY_ACCESSIBILITY
neu ab Oracle 9.0.x ist DEFAULT = FALSE (vorher DEFAULT = TRUE für
Abwärtskompatibilität mit Oracle 7)
Parameter im init<SID>.ora Parameter-File oder, ab Oracle9i im
sp<SID>.ora Server-Parameter-File
Parameter ist NICHT dynamisch änderbar, die Datenbank muss neu
gestartet werden
ein User mit %ANY% Privileges kann somit alle Objekte des DataDictionarys lesen UND verändern

O7_DICTIONARY_ACCESSIBILITY= FALSE setzen
nur SYSDBA hat Zugriff auf Data-Dictionary, DBA nicht
ein User mit %ANY% Privilegien kann Objekte des Data-Dictionarys nicht
mehr verändern noch einsehen
es ist aber möglich, einzelnen Usern direkte Objekt-Privilegien auf Objekte
des Data-Dictionarys zu geben
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 83
Schutz der Daten
Schutz des Data Dictionary (2)
 O7_DICTIONARY_ACCESIBILITY = TRUE
 EXECUTE ANY PROCEDURE
User OUTLN/OUTLN (gibt es seit Oracle 8.1.5, Stored Outlines)
CONNECT outln/outln
CREATE OR REPLACE PROCEDURE grant_dba_to_scott
IS
cur INTEGER;
BEGIN
cur := DBMS_SQL.open_cursor;
-- uid 0 = SYS
SYS.DBMS_SYS_SQL.PARSE_AS_USER(cur, 'GRANT DBA TO SCOTT',
DBMS_SQL.native,0);
DBMS_SQL.close_cursor (cur);
END;
/
EXECUTE grant_dba_to_scott;
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 84
Schutz der Daten
Schutz des Data Dictionary (3)
 O7_DICTIONARY_ACCESIBILITY = FALSE
 EXECUTE ANY PROCEDURE
Benutzer OUTLN/OUTLN wurde nicht gesperrt
Connected.
Warning: Procedure created with compilation errors.
BEGIN grant_dba_to_scott; END;
*
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00905: object OUTLN.GRANT_DBA_TO_SCOTT is invalid
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 85
Schutz der Daten
Virtual Private Database (1)
 Probleme traditioneller Rechteverwaltung:
kein Rollenkonzept für Zeilen, nur für Objekte
Hilfskonstrukt VIEW ist zu aufwendig bei grossen
Nutzergruppen mit vielen Tabellen
 VPD war bis Oracle 8i unter dem Namen Security Policy
bekannt
 ab Oracle 9i erweitert und nur in der Enterprise Edition verfügbar
 Steuerung des Zugriffs auf Datenbankebene (Bezeichnung:
Fine-Grained Access Control oder Row Level Security)
 Erweiterung ist Label Security (Vereinfachung der VPD) durch
Label die an Benutzer und Tabellenzeilen vergeben werden
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 86
Schutz der Daten
Virtual Private Database (2)

Vorgabe: Tabelle darf nur von bestimmten Personen gelesen werden
Wenn Verkäufer, dann 1=1 (TRUE)
Wenn Kunde, dann 0=1 (FALSE)

SELECT * FROM Aufträge WHERE name=´Mitropa´
Verkäufer: SELECT * FROM Aufträge WHERE name=´Mitropa´ and (1=1)
NAME
MENGE
PREIS
Mitropa
10000
148
Mitropa
7300
172
Mitropa
7400
171
Kunde: SELECT * FROM Aufträge where NAME=´Mitropa´ and (0=1)
NAME
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 87
MENGE
PREIS
Schutz der Daten
Virtual Private Database (3)
es muss eine PL/SQL Funktion geschrieben werden, die eine
Zeichenkette als Ergebnis liefert (1=1 oder 0=1)
Diese Zeichenkette wird als zusätzliche WHERE-Bedingung an jeden
Befehl angehängt
diese Policy-Funktion wird mit einer Tabelle oder View durch eine
Policy (aus Package dbms_rls) verbunden
SQL wird danach optimiert und ausgeführt
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 88
Schutz der Daten
Virtual Private Database (4) – Beispiel
 Zugriff auf Tabelle SCOTT.EMP ist für alle Benutzer nur während der Geschäftszeit erlaubt
 Anlegen einer PL/SQL-Funktion GetWorkHoursPredicate, die folgende WHERE Klauselm in
Form eines Textstrings generiert:
„1=1“ zwischen 08:00 und 16:00 Uhr
„0=1“ sonst
Anlegen einer Policy:
dbms_rls.add_policy( object_schema
=> 'SCOTT',
object_name
=> 'EMP',
policy_name
=> 'EMP_POLICY',
function_schema => 'SCOTT',
policy_function => 'GetWorkHoursPredicate',
statement_types => 'SELECT,INSERT,UPDATE,DELETE',
update_check
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 89
=> true);
Schutz der Daten
Virtual Private Database (5) – Beispiel
SQL*Plus um 07:30 Uhr
Interne Oracle Verarbeitung
SQL> SELECT ename FROM
SCOTT.EMP WHERE deptno=10;
SQL> SELECT ename FROM
SCOTT.EMP WHERE deptno=10
CLARK
AND (1=1);
KING
MILLER
SQL*Plus um 18:00 Uhr
Interne Oracle Verarbeitung
SQL> SELECT ename FROM
SCOTT.EMP WHERE deptno=10;
SQL> SELECT ename FROM
SCOTT.EMP WHERE deptno=10
Es wurden keine Zeilen
ausgewählt.
AND (0=1);
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 90
Überwachung von Zugriffen
Standardauditing

Auditing wird verwendet, um generelle Aktivitäten auf der Datenbank zu
protokollieren (in Tabelle SYS.AUD$)

Wer macht wann ein SELECT, INSERT, CREATE INDEX, ALTER TABLE
etc. auf einem Datenbank Objekt

Standard Auditing benötigt die INIT.ORA Parameter
AUDIT_TRAIL = TRUE/NONE/OS/DB
DEFAULT ist AUDIT_TRAIL = NONE

kann eingestellt werden für
die gesamte Instanz und für alle neu erstellten Tabellen
einem Schema/Besitzer von Tabelle(n) für die eigenen Objekte
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 91
Fazit
 Oracle unternimmt große Anstrengungen, um die Datenbank sicherer
zu machen. Von Version zu Version gibt es mehr und bessere
Möglichkeiten, um die Daten zu schützen
 diese neuen Möglichkeiten erfordern aber immer mehr technisches
und organisatorisches Wissen, denn nur beim richtigen Einsatz wird
die Sicherheit erhöht
 die Komplexität wird immer höher und dies erleichtert die
Administration der Datenbank nicht
 es müssen diverse Sachen selbst gemacht werden
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 92
Ende
Ihre Ansprechpartner:
Haben Sie Fragen oder Hinweise?
Wenden Sie sich bitte an:
Steffen
VielenKlehr
Dank für Ihre
Datenbankadministrator
Aufmerksamkeit.
Telefon:
0345 585-2333
E-Mail:
[email protected]
© GISA GmbH | www.gisa.de | Steffen Klehr | 29.01.2008 | Seite 93