Ausarbeitung Datenbanken II Aufbau einer Oracle

Ausarbeitung
Datenbanken II
Aufbau einer Oracle-Datenbank
Boris Meißner
05 – INDT
HTWK Leipzig
Fachbereich Informatik, Mathematik und Naturwissenschaften
26. Juni 2008
Inhaltsverzeichnis
1 Einleitung
3
2 Tablespaces
2.1 Konzept . . . . . . . . . . . . . .
2.2 Arten . . . . . . . . . . . . . . .
2.2.1 obligatorische Tablespaces
2.2.2 empfohlene Tablespaces .
2.3 Operationen . . . . . . . . . . . .
.
.
.
.
.
5
5
6
6
6
8
.
.
.
.
.
.
12
12
12
12
12
14
14
3 Dateien
3.1 Datendateien . . . . . .
3.1.1 Smallfile . . . . .
3.1.2 Bigfile . . . . . .
3.2 Online-Redolog-Dateien
3.3 Control-Dateien . . . . .
3.4 Parameterdatei . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Quellenangabe
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
2
1 Einleitung
Relationale Datenbanken dienen der Speicherung großer Daten und ermöglichen einen schnellen und selektiven Zugriff auf die Daten. Deswegen sind relationale Datenbanken heute die
am weitesten verbreitete Form der Speicherung von Informationen. Aus der Fülle der Anbieter hat sich vor allem das relationale Datenbankmanagment System (RDBMS) der Firma
Oralce im kommerziellen Bereich etabliert. Die Oracle-Datenbank liegt aktuell in der Version 11g (Stand 10.Juli 2007) vor. Diese Ausarbeitung bezieht sich auf den technischen Stand
der Version 11g.
Prinzipiell besteht eine Oracle Datenbank aus mehreren Komponenten, die aus physikalischer Sicht als Dateien eines Dateisystems (NTFS, ReiserFS, etc.) gespeichert werden. Eine
weitere Möglichkeit der Speicherung dieser Komponenten besteht in der Nutzung von RawDevices oder dem seit Oracle 10g integrierten Volume-Manager ASM. Auf letztere Methoden
sei hier nur am Rande verwiesen. Die Oracle Datenbank besteht aus vier unverzichtbaren
und einigen optionalen Komponenten.
Zwingend erfordlich sind Datendateien, Redolog-Dateien, Control-Datei und Parameterdatei. Datendateien dienen der Speicherung von Nutzer- und Metadaten. Redolog-Dateien bzw.
Online-Redolog-Dateien sind mindestens zweifach vorhanden und speichern abwechselnd in
der Datenbank durchgeführte Transaktionen. Die Control-Datei beinhaltet Metadaten über
die physikalische Struktur und die logische Konsistenz sowie backuprelevante Informationen.
Diese wenige MB große Datei sollte wegen ihrer Wichtigkeit einfach oder zweifach gespiegelt
werden. Die Parameterdatei ist eine wenige KB große Datei zur Speicherung der Konfiguration der Oracle-Instanz.
Die optionalen Komponenten seien hier nur der Vollständigkeit halber genannt. Eine weitergehende Betrachtung findet in dieser Ausarbeitung jedoch nicht statt.
Zu ihnen gehören Temporärdateien, welche Daten aus Zwischenergebnissen speichern und
damit die Performance erhöhen. Archiv-Redolog-Dateien speichern Online-Redolog-Dateien
3
Kapitel 1. Einleitung
um eine Wiederherstellung im Fehlerfall zu gewährleisten. Diese Dateien bilden häufig einen
wesentlichen Teil des Gesamtspeicherbedarfs, sollten aber in einer Produktivdatenbank unbedingt angelegt werden. Flashback-Log-Dateien enthalten Abbilder alter Datenbankinhalte
und können je nach Änderungsrate und Aufbewahrungszeit einen hohen Speicherbedarf haben. Die Block Change Tracking-Datei beinhaltet Informationen über Änderungen an den
Datenbankblöcken seit dem letzten Backup. Die optionale Passwortdatei dient der Authentifizierung des Datenbankadministrators um eine heruntergefahrene Datenbank zu starten.
Diese Ausarbeitung befasst sich im ersten Kapitel mit Tablespaces. Dabei wird auf das Konzept eingegangen und eine Unterscheidung der verschiedenen Arten vorgenommen. Weiterhin
werden wichtige Operationen zur Administration von Tablespaces betrachtet. Das zweite Kapitel enthält Informationen zu den verschieden Arten von Dateien einer Oracle Datenbank,
speziell Datendateien, Redolog-Dateien, Control-Datei und der Parameterdatei.
4
2 Tablespaces
2.1 Konzept
Zur Verwaltung einer Oracle Datenbank wird zwischen logischer Architektur und physischer
Speicherung unterschieden. Die logische Architektur wird durch die Verwaltung aller Daten
in Tablespaces realisiert. Diese Tablespaces werden auf physikalischer Ebene wiederum durch
Datendateien (Datafiles) repräsentiert und ermöglichen den gleichen Aufbau der Oracle Datenbank auf unterschiedlichen Plattformen (Microsoft Windows, Unix, Open-VMS, MVS
etc.).
Abbildung 2.1: Tablespaces und Datendateien
5
Kapitel 2. Tablespaces
2.2 Arten
2.2.1 obligatorische Tablespaces
2.2.1.1 SYSTEM - Tablespace
Der System - Tablespace verwaltet das Data-Dictonary, also sämtliche Metadaten und Verwaltungsinformationen der Datenbank. Desweiteren beinhaltet er PL/SQL - Code, wie Prozeduren, Funktionen, Packete und Trigger. Er wird beim Erstellen der Datenbank mit dem
CREATE DATABASE - Befehl angelegt und kann weder gelöscht noch umbenannt werden.
Er ist immer Online wenn die Datenbank offen ist.
2.2.1.2 SYSAUX - Tablespace
Seit Orcale 10g wird beim Erstellen der Datenbank ein zusätzlicher SYSAUX - Tablespace
erstellt. In ihm werden Daten, die im Laufe der Weiterentwicklung der Oracle-Datenbank
zum SYSTEM - Tablespace hinzugefügt wurden, jedoch ungünstige Eigenschaften haben,
gespeichert. Dadurch wird der SYSTEM - Tablespace entlastet. Beispielsweise werden hier die
Daten von systemnahen Anwendungen wie dem dem Oracle Enterprise Managers abgelegt.
Auch der SYSAUX - Tablespace kann weder gelöscht noch umbenannt werden.
2.2.2 empfohlene Tablespaces
Zu den soeben beschriebenen Tablespaces wird empfohlen, die folgenden Tablespaces je nach
Bedarf anzulegen. Dadurch können Verbesserungen im Bereich der Performance, der Verfügbarkeit, bei Backups und Recovery, der Administration und der Anwendungsgruppierung
erreicht werden.
Die hier verwendeten Tablespacenamen sind Empfehlungen, die sich in der Praxis bewährt
haben.
2.2.2.1 Temporär - Tablespace
Temporär - Tablespaces werden benötigt, um die Ergebnisse von Sortieroperationen temporär
zu speichern. Als Beispiel dient ein Join zweier großer Tabellen, deren Sortierung nicht im
Hauptspeicher realisiert werden kann. Um zu vermeiden, dass dafür der System - Tablespace
6
Kapitel 2. Tablespaces
benutzt wird, müssen für jeden User Temporär - Tablespaces (temp) angelegt werden.
Da Temporäre - Tablespaces keine dauerhaften Objekte enthalten, müssen keine Backups
erstellt werden.
2.2.2.2 Undo - Tablespace
Der Undo-Tablespace (undotbs) speichert ausschließlich Undo-Segmente, um im Fehlerfall
den alten Zustand von Feldinhalten (before images) wiederherzustellen. Die Speicherung
erfolgt bis zum persistenten Schreiben der Daten in die Datenbank (COMMIT).
Es wird eine automatische Undo-Verwaltung empfohlen, weil dadurch die Erstellung und
Verwaltung vom System übernommen wird.
Die Undo-Segmente werden intern als Ringpuffer realisiert.
2.2.2.3 Tablespace für Werkzeuge
Dieser Tablespace beinhaltet zum Beispiel Daten für den Oracle Enterprise Manager. Üblicherweise wird er als tools bezeichnet.
2.2.2.4 Tablespace für die Daten einer Anwendung
Für Anwendungen wird empfohlen mindestens einen weiteren Tablespace zur Verfügung zu
stellen. Dieser kann für die Anwendung XYZ z.B. xyz data genannt werden.
2.2.2.5 Tablespace für die Indizes einer Anwendung
Ebenso sollte für eine Anwendung XYZ mindestens ein Tablespace für die Indizes mit dem
Namen xyz index erstellt werden.
2.2.2.6 Tablespace für Tests und Benutzerdaten
Weiterhin kann ein Tablespace für Benutzerdaten und Tests, z.B. users genutzt werden.
2.2.2.7 Tablespace für ungewöhnlich große Objekte
Für ungewöhnlich große Objekte einer Anwendung XYZ können Tablespaces für Daten
(xyz data big) und Indizes (xyz index big) erstellt werden.
7
Kapitel 2. Tablespaces
2.3 Operationen
Im folgenden werden einige SQL-Befehle zur Verwaltung von Tablespaces beschrieben.
Listing 2.1: CREATE TABLESPACE
1
CREATE SMALLFILE TABLESPACE kunden daten
2
DATAFILE ’ / o r a d a t a 1 /PDWH10g/ kundendaten01 . d b f ’ SIZE 1000M
3
AUTOEXTEND ON NEXT 100M MAXSIZE 5000M
4
BLOCKSIZE 8K
5
LOGGING
Das CREATE TABLESPACE Statement erzeugt einen neuen Tablespace, im hier gezeigten
Beispiel mit dem Namen kunden daten. Der Tablespacename sollte aussagekräftig sein, darf
30 Zeichen nicht überschreiten und es wird zwischen Groß- und Kleinschreibung unterschieden. Seit Oracle 10g wird zwischen SMALLFILE und BIGFILE Tablespaces differenziert,
wobei erstere aus maximal 4M Blöcken und zweitere aus maximal 4G Blöcken bestehen. Die
mit DATAFILE angegebene Datendatei sollte den Tablespacenamen enthalten und erhält
eine für das Betriebssystem übliche Endung wie .dbf oder .ora. Mit SIZE wird die initiale
Größe der Datendatei auf der Festplatte festgelegt, die ohne die Angabe von SIZE standardmäßig 100MB beträgt. Da die Datei sofort erstellt wird, kann es zu einer Wartezeit
von mehreren Minuten kommen. Mit AUTOEXTEND wird die Datendatei nach Bedarf um
den Wert ON NEXT bis zum Maximalwert MAXSIZE vergrößert. Der Standardwert für
ON NEXT ist die Datenbankblockgröße, weshalb durch ständiges Erweitern Performanceprobleme auftreten können. Bei einer fehlenden Angabe von MAXSIZE kann der Tablespace
unbegrenzt bis zur physikalischen Grenze wachsen. Mit dem BLOCKSIZE Statement können Blockgrößen, welche von der Standardblockgröße abweichen, erstellt werden. Diese kann
2KB, 4KB, 8KB, 16KB oder 32KB entsprechen. Das LOGGING Statement entspricht der
Standardeinstellung und kann ohne Auswirkungen entfallen. Es bewirkt die Protokollierung
aller DML-Operationen über den Redolog-Mechanismus.
Listing 2.2: ALTER TABLESPACE I
1
ALTER TABLESPACE u s e r t s 1
2
ADD DATAFILE ’ c : \ o r a c l e \ o r a d a t a \ o r a \ u s e r t s 1 . d b f ’ SIZE 10M
3
AUTOEXTEND ON NEXT 200K
MAXSIZE 200M;
8
Kapitel 2. Tablespaces
Listing 2.2 zeigt die Erstellung einer neuen Datendatei zur Erweiterung des Tablespace
user ts1. Diese Datendatei kann von ihrer initialen Größe von 10M durch das AUTOEXTEND Statement bei Bedarf in 200K Schritten auf 200M vergrößert werden.
Listing 2.3: ALTER TABLESPACE II
1
ALTER TABLESPACE u s e r t s 1
2
ADD DATAFILE ’ c : \ o r a c l e \ o r a d a t a \ o r a \ u s e r t s 2 . d b f ’ SIZE 10M
3
AUTOEXTEND OFF;
Listing 2.3 zeigt die Erstellung einer weiteren Datendatei. Diese ist jedoch permanent durch
das AUTOEXTEND OFF Statement auf 10M begrenzt.
Listing 2.4: ALTER TABLESPACE III
1
ALTER DATABASE
2
DATAFILE ’ c : \ o r a c l e \ o r a d a t a \ o r a \ u s e r t s 1 . d b f ’
3
RESIZE 10M;
Durch RESIZE wird die Datendatei, wenn sie den zu begrenzenden Speicherplatz nicht schon
belegt, auf die angegebene Größe begrenzt. Die Realisierung wird in Listing 2.4 gezeigt.
In den folgenden Listings wird auf das ONLINE- und OFFLINE-Setzen von Tablespaces eingegangen, welches für bestimmte administrative Tätigkeiten nötig ist. Dabei wird zwischen
dem NOARCHIVLOG- und dem ARCHIVLOG-Modus unterschieden. Listing 2.5 zeigt das
OFFLINE setzen eines NOARCHIVLOG Tablespace, bei dem Redolog-Dateien nicht archivert werden.
Listing 2.5: Tablespace OFFLINE setzen (NOARCHIVLOG)
1
ALTER TABLESPACE u s e r t s 1 OFFLINE DROP;
Das folgende Listing 2.6 zeigt das OFFLINE-Setzen eines ARCHIVLOG Tablespace. Dabei
müssen die Redolog-Dateien archiviert werden, wodurch zwischen verschiedenen Arten des
OFFLINE-Setzens unterschieden werden muss.
Das Schlüsselwort NORMAL bewirkt die Ausführung der Anweisung im Fehlerfall.
IMMEDIATE führt zum sofortigen OFFLINE setzen des Tablespace. Eine aktive Transaktion muss nach dem ONLINE setzen des Tablespace durch ein Recovery wiederhergestellt
werden.
Das Schlüsselwort TEMPORARY bewirkt eine Sicherung aller Dateien, die sich nicht in ei-
9
Kapitel 2. Tablespaces
ner Fehlersituation befinden, in einem Checkpoint. Beim ONLINE setzen muss das Recovery
lediglich für die fehlerhaften Dateien stattfinden.
Listing 2.6: Tablespace OFFLINE setzen (ARCHIVLOG)
1
ALTER TABLESPACE u s e r t s 1 OFFLINE NORMAL;
2
ALTER TABLESPACE u s e r t s 1 OFFLINE IMMEDIATE;
3
ALTER TABLESPACE u s e r t s 1 OFFLINE TEMPORARY;
Das ONLINE-Setzen ist für ARCHIVLOG und NOARCHIVLOG Tablespaces gleich und
wird im Listing 2.7 gezeigt.
Listing 2.7: Tablespace ONLINE setzen
1
ALTER TABLESPACE u s e r t s 1 ONLINE ;
Weiterhin ist es möglich, einzelne Datendateien ONLINE bzw. OFFLINE zu setzen. Das
folgende Listing zeigt das Vorgehen, sowohl für ARCHIVLOG als auch für NOARCHIVLOG
Dateien. Die NORARCHIVLOG Datendateien benötigen wie schon beim Tablespace das
DROP Statement.
Listing 2.8: Datendateien ONLINE/OFFLINE setzen
1
ALTER DATABASE DATAFILE <Dateiname> OFFLINE ;
2
ALTER DATABASE DATAFILE <Dateiname> OFFLINE DROP;
3
ALTER DATABASE DATAFILE <Dateiname> ONLINE ;
Das Umbenennen einer Datendatei benötigt folgende Schritte. Zuerst muss der die Datendatei enthaltende Tablespace OFFLINE gesetzt werden. Danach erfolgt die Umbenennung mit
Betriebssystemmitteln und anschließend die Umbenennung in der Datenbank gemäß Listing
2.9. Abschließend wird der TABLESPACE wieder ONLINE gesetzt.
Listing 2.9: Datendateien umbenennen
1
ALTER TABLESPACE u s e r t s
2
RENAME DATAFILE <Dateiname1−a l t >, <Dateiname2−a l t >, . . .
3
TO <Dateiname1−neu >, <Dateiname2−neu >, . . .
;
Das Löschen eines leeren Tablespace erfolgt durch das DROP TABLESPACE Statement.
Wenn noch Objekte im Tablespace gespeichert sind, kann durch Erweiterung um INCLUDING CONTENTS deren Löschung erzwungen werden. Eine Erweiterung um AND DATAFILES bewirkt die zusätzliche Löschung der Datendateien auf Betriebssystemebene. Listing
10
Kapitel 2. Tablespaces
2.10 zeigt das Löschen des Tablespace sowie aller enthaltenen Objekte und der Datendateien
auf Betriebssystemebene.
Listing 2.10: Tablespace löschen
1
DROP TABLESPACE u s e r t s INCLUDING CONTENTS AND DATAFILES ;
11
3 Dateien
3.1 Datendateien
Datendateien enthalten sämtliche Datenbankobjekte. Dazu zählen Tabellen, Indexe, Rollback
Segmente, Temporäre Segmente und LOBs. Diese Datenbankobjekte werden in unterschiedlichen Segmenten abgebildet. Die verschiedenen Segmenttypen sind Daten- Index-, LOB-,
Rollback- und Undo- sowie Temporärsegment.
3.1.1 Smallfile
Durch die Einführung der Bigfile-Tablespaces in Oracle 10g wird ein weiterer, als Smallfile
bezeichneter Tablespace nötig. Dieser beschreibt die bis dahin standardmäßig verwendete
Maximalgröße von Tablespaces. Dabei ist die maximale Anzahl von Blöcken auf 4M begrenzt.
Es ergibt sich bei einer angenommenen Blockgröße von 8K eine Maximalgröße der Datendatei
von 32GB. Eine Vergrößung des Tablespace kann danach nur noch durch Hinzufügen weiterer
Datendateien realisiert werden.
Tablespaces werden standardmäßig als Smallfile Tablespaces erstellt.
3.1.2 Bigfile
Bigfile-Tablespaces sind auf 4G Blöcke begrenzt. Somit können 32TB Große Datendateien
bei einer Blockgröße von 8K erstellt werden. Bigfile-Tablespaces unterliegen jedoch diversen Einschränkungen. Ein Bigfile-Tablespace darf beispielsweise nur aus einer Datendatei
bestehen.
3.2 Online-Redolog-Dateien
Redolog-Dateien protokollieren die Transaktionen der Datenbank und speichern die für die
Wiederherstellung benötigten Recovery Informationen. Es werden immer mindestens zwei
12
Kapitel 3. Dateien
Online-Redolog-Dateien benötigt, die wenn sie voll sind abwechselnd beschrieben bzw. überschrieben werden.
Es existieren zwei Modi zur Archivierung der Online-Redolog-Dateien. Im ARCHIVLOGModus wird vor dem Überschreiben der Online-Redolog-Dateien eine Sicherungskopie der
Transaktionen in den Archivierten-Redolog-Dateien gespeichert. Der NOARCHIVLOG-Modus
verzichtet auf das Speichern, und die Informationen über Transaktionen gehen beim Überschreiben der Online-Redolog-Datei verloren. Letztere Methode sollte nur in Testsystemen
genutzt werden.
Wegen der Wichtigkeit für die Wiederherstellung sollte in Produktivsystemen zusätzlich eine
Spiegelung der Online-Redolog-Dateien stattfinden. Das folgende Bild zeigt eine gute Absicherung gegen Ausfälle, mittels Spiegelung und Archivierten-Redolog-Dateien.
Abbildung 3.1: gespiegelte Online-Redolog-Dateien und Archiv-Redolog-Dateien
13
Kapitel 3. Dateien
3.3 Control-Dateien
Kontrolldateien enthalten Zeitstempel, Konsistenzinformationen und physikalische Struktur
der Oracle Datenbank. Dies sind z.B. alle Namen und Größen von Online Redolog- und
Datendateien. Zu jedem Zeitpunkt gibt es eine gültige Version der Control-Dateien, die aufgrund ihrer Wichtigkeit gespiegelt werden sollten. Trotz ihrer geringen Größe von wenigen
MB, sind Control-Dateien vor allem im Wiederherstellungsfall unerlässlig für Konsistenz und
Verfügbarkeit der Datenbank.
Unter anderem werden folgende Informationen gespeichert:
• Name und Erstellungszeitpunkt der Datenbank
• Namen der Control-, Daten-, Redolog- und Temporärdateien
• Informationen über Tablespaces
• Informationen über Archivierungsstatus
• Redolog-History
• Informationen für den Recovery-Manager
• die aktuelle Log-Sequence-Number
• Checkpoint Informationen
Control-Dateien werden beim Erstellen der Datenbank automatisch erzeugt. Aufgrund ihrer
Bedeutsamkeit für den laufenden Betrieb und den Wiederanlauf der Datenbank wird eine
Spiegelung empfohlen.
3.4 Parameterdatei
Die Parameterdatei enthält sämtliche Serverparamter, unter anderem die Namen der Kontrolldateien. Dadurch wird beim Systemstart die Konfiguration und das Verhalten der Instanz des Oracle-Servers festgelegt. Es wird zwischen der herkömmlichen Parameterdatei
und Serverparameterdatei unterschieden. Die Serverparameterdatei wird in verteilten Rechnerumgebungen benötigt.
14
Abbildungsverzeichnis
2.1
Tablespaces und Datendateien . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.1
Online-Redolog-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
15
Listings
2.1
CREATE TABLESPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2
ALTER TABLESPACE I . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3
ALTER TABLESPACE II . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.4
ALTER TABLESPACE III . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.5
Tablespace OFFLINE setzen (NOARCHIVLOG)
. . . . . . . . . . . . . . .
9
2.6
Tablespace OFFLINE setzen (ARCHIVLOG) . . . . . . . . . . . . . . . . .
10
2.7
Tablespace ONLINE setzen . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.8
Datendateien ONLINE/OFFLINE setzen . . . . . . . . . . . . . . . . . . . .
10
2.9
Datendateien umbenennen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.10 Tablespace löschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
16
4 Quellenangabe
• Oracle 10g für den DBA - Effizient konfigurieren, optimieren und verwalten
Johannes Ahrends, Dierk Lenz, Patrick Schwanke, Günter Unbescheid
Addision-Wesley, 2005
• http://de.wikibooks.org/wiki/Oracle:Tablespaceverwalten
• http://de.wikipedia.org/wiki/Oracle %28Datenbanksystem%29
• http://www.datenbank-backup.de
17