Oracle: Dateien
Arten von Datenbank-Dateien[Bearbeiten]
Die physikalische Datenbank besteht aus vier Typen von Dateien:
- Parameter-Dateien: Dateien, in denen Parameter das Hochfahren der Datenbank-Instanz und der Client-Verbindung abgelegt sind.
- Control-Dateien: Steuer-Dateien, in denen abgelegt wird, welche Datenbank-Dateien zur physischen Datenbank gehören.
- Tablespace-Dateien: Dateien, in denen die Daten des System-Katalogs und der Benutzer-Tabellen gespeichert sind.
- Redolog-Dateien: Informationen über Datenänderungen. Diese werden benötigt für Backup und Recover.
Die Tablespace-, Redolog- und Control-Dateien sind nach der Standard-Installation unter Windows in einem einzigen Verzeichnis angelegt: C:\Oracle\oradata\<SID>
Datenspiegelung[Bearbeiten]
Aus Sicherheitsgründen sollten die Dateien der Oracle-Datenbank auf mehrere Festplatten gespiegelt gespeichert werden. Das ist einerseits möglich durch den Einsatz von RAID-Platten, die hardwaremäßig die Spiegelung vornehmen. Die Datenbank-Dateien kann man auch von der Oracle-Datenbank auf mehreren Platten spiegeln lassen. Man sollte aber darauf achten, dass die Verbindung vom Server zu diesen Platten schnell genug ist (möglichst über den Datenbus und nicht über eine langsame Netzwerkverbindung).
Offline-Sicherung
Zusätzlich sollten diese Dateien regelmäßig gesichert werden. Am einfachsten ist eine Sicherung der Dateien, wenn gerade keine Instanz mit dieser Datenbank verbunden ist. Eine solche Sicherung kann man jederzeit wieder zurückspielen, man muss nur darauf achten, dass die Dateien vollständig sind und von derselben Version stammen. Danach kann man die Instanz wieder starten und mit der zurückgesicherten Version weiterarbeiten.
Online-Sicherung
Oft müssen Datenbanken 7 Tage zu je 24 Stunden verfügbar sein. Alle Datenbank-Dateien kann man auch während des laufenden Betriebes sichern. Dafür werden spezielle Tools eingesetzt (BACKUP, RECOVER, ARCH-Prozess).
Parameter-Dateien[Bearbeiten]
Die Parameter-Dateien liegen jeweils unter dem Pfad, in dem die Datenbank installiert wurde. Dies kann ein beliebiger Pfad sein und ist z. B. bei einer Unix-/Linux-Installation in der Umgebungsvariablen ORACLE_HOME abgelegt. Zur Veranschaulichung dieses "Home"-Verzeichnisses und dessen Variabilität wird diese Variable im Folgenden den Pfaden in der Windows-Notierung vorangestellt.
Init.ora bzw. Init<SID>.ora[Bearbeiten]
Datei: %ORACLE_HOME%\database\init<SID>.ora
In früheren Versionen waren hier die Initialisierungs-Parameter eingetragen. Seit der Version 8 steht hier nur noch ein Verweis auf eine Datei mit den Parametern drin, und zwar auf:
%ORACLE_HOME%\..\admin\<SID>\pfile\init.ora
Inhalt: Parameter der Datenbank und der Datenbank-Instanz.
tnsnames.ora[Bearbeiten]
Datei: %ORACLE_HOME%\network\ADMIN\tnsnames.ora
Inhalt: Verbindungsdaten für den Client. Hier müssen alle Server eingetragen sein, auf die der Client zugreifen kann.
listener.ora[Bearbeiten]
Datei: %ORACLE_HOME%\network\ADMIN\listener.ora
Inhalt: Parameter für den Listener-Prozess auf dem Server, der die Verbindung zu den Clients bedient.
sqlnet.ora[Bearbeiten]
Datei: %ORACLE_HOME%\network\ADMIN\sqlnet.ora
Inhalt: Parameter der Netzwerkverbindung
Es gibt noch eine Vielzahl weiterer Parameter-Dateien, die man anlegen kann, doch diese drei sind die wichtigsten.
Weitere Parameter-Dateien[Bearbeiten]
- %ORACLE_HOME%\sqlplus\ADMIN\init.sql SQL*PLUS-Parameter
Tablespace-Dateien[Bearbeiten]
Eine Tablespace-Datei ist ein Bereich auf der Festplatte, der vom Betriebssystem für die ORACLE-Datenbank zur Verfügung gestellt wird. Die Oracle-Datenbank verwendet eine oder mehrere Tablespace-Dateien zur Speicherung der Daten in dem Tablespace.
Die Datei wird in Extents aufgeteilt. Die Größe eines Extents beträgt ein ganzzahliges Vielfaches eines Betriebssystem-Blocks. Jeder Extent beinhaltet mehrere Datenblöcke. Die Größe eines Datenblocks ist in der init.ora - Datei eingetragen (Parameter db_block_size) und beträgt normalerweise 8 KB. Dieser Parameter wird beim Anlegen einer Database einmal festgelegt und kann danach nicht mehr verändert werden.
Bei Lese- und Schreib-Zugriffen wird immer ein ganzer Block gelesen oder geschrieben. Es wird nie auf einzelne Bytes der Speicherplatte zugegriffen. Bei Schreib-Zugriffen wird ein Block in die SGA gelesen. Dort werden einzelne Werte oder Sätze aus dem Block verändert. Der DBWR-Prozess hat die Aufgabe, in regelmäßigen Abständen, alle geänderten Blöcke wieder auf die Speicherplatte zu schreiben.
Aufbau eines Datenblocks[Bearbeiten]
Der Parameter PCTFREE gibt an, wieviel Prozent des Datenbereichs frei bleiben muss für Datenänderungen (UPDATEs). Dieser Bereich wird nicht für INSERTs verwendet. Wenn der Block durch INSERTs mit Daten bis zur PCTFREE-Grenze gefüllt wurde, dann wird er als "voll" markiert. Wenn dann durch UPDATE oder DELETE-Anweisungen wieder freier Platz entsteht, dann wird dieser Block aber nicht gleich wieder als "Frei" markiert. Erst wenn der Füllgrad unter die PCTUSED-Marke kommt, erst dann wird dieser Block wieder als "Frei" markiert und kann beim nächsten INSERT wieder neue Datensätze aufnehmen. Die Adressen von allen "freien" Blöcken werden in der Freispeicherliste notiert. PCTUSED sorgt dafür, dass ein Block nicht zu häufig in die Freispeicherliste eingetragen wird und wieder von dort entfernt werden muss.
Die Parameter PCTFREE und PCTUSED werden beim Erstellen eines Tablespace einmal für alle Datenblöcke festgelegt. Sie können auch nachträglich geändert werden. Wenn die Daten selten geändert werden, dann kann man PCTFREE / PCTUSED auf z. B. 5/80 festlegen (gute Speicherplatzausnutzung). Wenn die Daten sehr oft geändert werden, dann sollte man PCTFREE / PCTUSED auf z. B. 20/40 festlegen (Es wird viel freier Platz gelassen, um die Performance der Schreib-Zugriffe zu verbessern.).
Row-Fragmentierung[Bearbeiten]
Die Parameter PCTFREE und PCTUSED haben die Aufgabe, Row-Migration so weit wie möglich zu vermeiden.
ROW Migration entsteht, wenn ein Datensatz durch ein UPDATE so groß wird, dass er nicht mehr in den Datenbereich des Blocks passt. Dann wird ein Verweis auf einen neuen Block an die Stelle eingetragen. Beim Lesen muss dann der Original-Block gelesen werden und der neue Block. Row-Chaining ist erforderlich, wenn die Record-Länge eines Satzes größer ist, als der Datenbereich eines Blocks. Dann muss dieser Datensatz auf einen zweiten Block fortgeschrieben werden. Wenn der zweite Block auch nicht ausreicht, dann wird ein dritter, vierter ... Block dafür verwendet. So entsteht eine Kette von Blöcken, die zur Speicherung eines einzelnen Datensatzes benutzt werden. Row-Chaining kann man nur dadurch verhindern, wenn man beim Anlegen der Database die db_block_size entsprechend größer festlegt.
Über die Data-Dictionary-View v$datafile kann man die Größe der einzelnen Tablespace-Dateien anzeigen lassen.
select bytes, blocks, block_size, name from v$datafile;
BYTES BLOCKS BLOCK_SIZE NAME
---------- ---------- ---------- ---------------------------------------
287309824 35072 8192 C:\ORACLE\ORADATA\ORACLE\SYSTEM01.DBF
256901120 31360 8192 C:\ORACLE\ORADATA\ORACLE\RBS01.DBF
9437184 1152 8192 C:\ORACLE\ORADATA\ORACLE\TEST2.DBF
5242880 640 8192 C:\ORACLE\ORADATA\ORACLE\TEST3.DBF
Weitere Data-Dictionary-Views zur Speicherplatzverwaltung:
dba_data_files dba_extents dba_free_space dba_segments dba_tablespaces
Rollback-Segmente[Bearbeiten]
Rollback-Segmente sind spezielle Segmente in einem Tablespace, die Datenänderungen protokollieren.
Wenn eine Transaktion eine Änderung an den Daten vornimmt, dann wird die Änderung zunächst an dem Datensegment vorgenommen, aber die alte Version des Satzes wird in dem Rollback-Segment vermerkt. Solange die ändernde Transaktion ihre Änderung noch nicht durch COMMIT freigegeben hat, bekommen alle anderen lesenden Transaktionen die alte Version des Datensatzes zu lesen. Diese Informationen werden dann aus den Rollback-Segmenten gelesen. Wenn die ändernde Transaktion ihre Änderung durch COMMIT freigibt, bekommen andere lesende Transaktionen die neue Version des Satzes zu lesen. Nur solche Transaktionen, die ihren Lesezugriff noch vor dem COMMIT-Zeitpunkt begonnen haben, bekommen immer noch die alte Version des Satzes zu lesen, denn alle Lesezugriffe werden als Snapshot ermittelt d.h. als Sicht auf die Datenbank zu einem bestimmten Zeitpunkt. Wenn die Informationen in den Rollback-Segmenten nicht mehr gebraucht werden, können sie wieder überschrieben werden. Durch den System-Parameter UNDO-RETENTION wird festgelegt, wie lange die Informationen in den Rollback-Segmenten nach ihre Freigabe noch erhalten bleiben sollen für Lesezugriffe, die vor der Commit-Schreibung mit ihrem Zugriff begonnen haben.
Snapshot too old[Bearbeiten]
Falls ein Programm z.B. mit einem Select alle vorhandenen Sätze aus einer Tabelle auslesen muss und für jeden Satz eine zeitaufwändige Verarbeitung ausführen muss, dann kann es vorkommen, dass für dieses Programm auf Informationen aus den Rollback-Segmenten zugegriffen will, die aber bereits überschrieben wurden, weil die UNDO-RETENTION-Zeit schon vorbei ist. Dann bricht diesen Programm ab mit der Fehlermeldung „ORA-01555: Snapshot too old“. In diesem Fall kann man die UNDO-RETENTION-Zeit hochsetzen. Wenn das Programm drei Stunden braucht, dann muss die UNDO-RETENTION-Zeit auf 3 * 60 * 60 = 10800 gesetzt werden, d.h. alle Informationen in den Rollback-Segmenten bleiben nach ihrer Freigabe noch drei Stunden erhalten. Erst dann dürfen sie überschrieben werden.
ALTER SYSTEM SET UNDO_RETENTION = 10800;
Bei einer so hohen UNDO-RETENTION-Zeit wird viel Platz für die Rollback-Informationen gebraucht.
Nach einer Standard-Installation der Oracle-Datenbank gibt es nur den SYSTEM-Tablespace, in dem sowohl die User-Daten, als auch die Rollback-Daten abgelegt werden. Um die Dictionary-Tabellen nicht unnötig zu belasten und um das Recovery zu erleichtern, sollte man die User-Tabellen in eigenen Tablespaces ablegen. Ebenso ist es empfehlenswert, mindestens einen eigenen Tablespace anzulegen, in denen ausschließlich Rollback-Segmente gespeichert werden. Oracle empfielt, die Tablespace für die Rollback-Segmente auf einer anderen Platte zu plazieren, als die Tablespace in denen die Daten-Segmente gespeichert werden. Das fördert Parallelzugriffe auf Daten- und Rollback-Informationen.
Ab Version 10 spricht man von UNDO-Segmenten und UNDO-Tablespaces.
Neue Rollback-Segmente anlegen[Bearbeiten]
Um neue Rollbacksegmente anzulegen, müssen diese einem bestimmten Tablespace zugewiesen werden. Danach müssen die Rollback-Segmente ONLINE gesetzt werden.
CREATE PUBLIC ROLLBACK SEGMENT RBS0 TABLESPACE RBS STORAGE ( OPTIMAL 4096K ); CREATE PUBLIC ROLLBACK SEGMENT RBS1 TABLESPACE RBS STORAGE ( OPTIMAL 4096K );
ALTER ROLLBACK SEGMENT "RBS0" ONLINE; ALTER ROLLBACK SEGMENT "RBS1" ONLINE;
Falls eigene Rollback-Segmente angelegt werden, dann müssen diese in der Parameter-Datei init.ora bekanntgegeben werden z.B.
rollback_segments = ( RBS0, RBS1 )
Redolog-Dateien[Bearbeiten]
Redolog-Dateien speichern Informationen über alle Datenänderungen in den Tablespace-Dateien. Sie können im Falle eines Speichermediums-Fehlers zur Rekonstruktion der Daten herangezogen werden. Es müssen mindestens zwei Redolog-Dateien (mindestens zwei Gruppen mit jeweils mindestens einer Datei) für jede Database definiert sein. Jede Redolog-Datei sollte zusätzlich auf mehrere Platten gespiegelt werden.
Die Änderungen an den TS-Dateien werden immer in eine Redolog-Datei ausgegeben, bis diese voll ist. Dann führt das System einen Logswitch durch, d.h. es wird eine neue Redolog-Datei begonnen. Da aber nur eine begrenzte Anzahl von Redolog-Dateien vorhanden ist, wird nach dem Beschreiben der letzten Datei, wieder mit der ersten fortgesetzt. Die bisherigen Einträge der Datei, werden dabei überschrieben. Damit die Redolog-Informationen durch das Überschreiben nicht verloren gehen, hat der ARCH-Prozess die Aufgabe, nach einem Logswitch die gerade fertig geschriebene Redolog-Datei zu archivieren.
Nach der Installation ist der ARCH-Prozess nicht aktiv, d.h. die Datenbank befindet sich im NOARCHIVELOG-Modus. In diesem Zustand kann nur manuelles Offline-Backup und Recovery ausgeführt werden. (s. Seite 3) Um die Datenbank-Funktionen BACKUP und RECOVER ausführen zu können, muss die Datenbank in den ARCHIVELOG-Modus versetzt werden. Dann nimmt der ARCH-Prozess seine Arbeit auf.
Redolog-Gruppen[Bearbeiten]
Da die Redolog-Dateien elementare Voraussetzung für ein Recover nach einem Plattencrash sind, ist es dringend empfohlen, die Redolog-Dateien von der Datenbank gespiegelt zu beschreiben.
Anzeigen der aktuell vorhandenen Redolog-Dateien:
select * from v$logfile;
GROUP# STATUS MEMBER
---------- ------- -----------------------------------
1 C:\ORACLE\ORADATA\ORCL\REDOC1.LOG
1 D:\ORACLE\ORADATA\ORCL\REDOD1.LOG
2 C:\ORACLE\ORADATA\ORCL\REDOC2.LOG
2 D:\ORACLE\ORADATA\ORCL\REDOD2.LOG
3 C:\ORACLE\ORADATA\ORCL\REDOC3.LOG
3 D:\ORACLE\ORADATA\ORCL\REDOD3.LOG
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------ -------- ---------- -------- -------- --- --------
1 1 7 1048576 2 NO INACTIVE
2 1 8 1048576 2 NO CURRENT
3 1 6 1048576 2 NO INACTIVE
Redolog-Gruppen verändern[Bearbeiten]
Man kann nur Loggruppen ändern, die gerade nicht aktiv sind. Einen Wechsel zur nächsten Loggruppe kann man erzwingen durch den Befehl:
alter system switch logfile;
Einrichten einer zusätzlichen Redolog-Gruppe:
ALTER DATABASE orcl ADD LOGFILE GROUP 4
('C:\ORACLE\ORADATA\ORCL\REDOC4.LOG',
'D:\ORACLE\ORADATA\ORCL\REDOD4.LOG' ) SIZE 1M;
Redolog-Gruppe erweitern um eine zusätzliche Datei auf der E-Platte:
ALTER DATABASE orcl ADD LOGFILE MEMBER 'E:\ORACLE\ORADATA\ORCL\REDOE1.LOG' reuse to group 1;
Redolog-Gruppe löschen:
ALTER DATABASE orcl DROP LOGFILE GROUP 4;
Eine einzelne Datei aus einer Redolog-Gruppe löschen:
ALTER DATABASE orcl DROP LOGFILE MEMBER 'E:\ORACLE\ORADATA\ORCL\REDOE1.LOG';
Eine einzelne Datei umbenennen:
ALTER DATABASE orcl RENAME FILE 'E:\ORACLE\ORADATA\ORCL\REDOXX.LOG' TO 'E:\ORACLE\ORADATA\ORCL\REDOE1.LOG';
Die Datenbank entfernt die Dateien nur aus ihrem Verzeichnis. Das Entfernen der physischen Datei auf der Betriebssystem-Ebene muss man selber machen.
Ebenso muss beim Umbenennen die Datei auf Betriebssystem-Ebene bereits unter dem neuen Namen existieren.
Empfehlungen für die Handhabung von Redolog-Dateien[Bearbeiten]
- Redolog-Dateien sollten auf einer anderen Platte gespeichert werden, als die Tablespace-Dateien
- Jede Redolog-Gruppe sollte aus mindestens 2 Dateien bestehen
- Um Zugriffskollisionen zwischen dem LGWR und dem ARCH-Prozessen zu vermeiden, sollte sich das Verzeichnis, in den die Redolog-Dateien archiviert werden, auf einer anderen Platte befinden, als die Redolog-Dateien geschrieben werden.
- Wenn viele Datenänderungen ausgeführt werden, dann sollten die Redolog-Dateien entsprechend größer dimensioniert werden. Fall eine Redolog-Gruppe voll ist und der ARCH-Prozess die nächste Redolog-Gruppe noch nicht fertig archiviert hat, dann muss das System so lange warten, bis die Archivierung abgeschlossen ist.
- Bis Version 9 ist maximal eine fünffache Spiegelung der Redolog-Dateien möglich.
- Größe von Redolog-Dateien:
50 KB Minimalwert 500 KB default-Wert 1 MB das ist immer noch „klein“ 50 MB schon ganz gut für produktive Anwendungen 500 MB bei großen Anwendungen keine Seltenheit
Control-Dateien[Bearbeiten]
Die Control-Dateien enthalten die Informationen über alle physikalischen Datanbankdateien
Sie beinhalten die Verwaltungs- und Strukturinformationen
- Datenbankname
- Namen der Tablespace-Dateien
- Namen der Redolog-Dateien
- die aktuelle LOG-Sequenznummer
- weitere Informationen, die für ein Recover erforderlich sind.
Die Control-Dateien sollten ebenfalls auf unterschiedlichen Platten abgelegt werden.
Die aktuell vorhandenen Control-Dateien kann man sich ausgeben lassen mit:
select * from v$controlfile;
STATUS NAME
------- -------------------------------------
C:\ORACLE\ORADATA\ORCL\CONTROL01.CTL
C:\ORACLE\ORADATA\ORCL\CONTROL02.CTL
C:\ORACLE\ORADATA\ORCL\CONTROL03.CTL
Control-Dateien wiederherstellen[Bearbeiten]
Falls die Controldateien zerstört wurden (und alle anderen Dateien noch ok sind), dann kann man die Control-Dateien neu erstellen lassen mit folgender Befehlsfolge:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE SQL> SHUTDOWN IMMEDIATE
Dadurch wird in dem Trace-Verzeichnis ein Script erstellt, mit dem man die Control-Dateien sichern kann. Die Trace-Datei findet man in dem Verzeichnis:
C:\oracle\admin\<SID>\udump
Datei mit dem letzten Datum suchen. In der Datei muss man die Header-Zeilen und die Kommentar-Zeilen entfernen. Dann kann man die Datei z.B. speichern unter c:\con_neu.sql und ausführen:
SQL> @c:\con_neu.sql
Nun sind die Controldateien neu angelegt worden.