Ausarbeitung im Fach Datenbanken 2

Transkript

1 Ausarbeitung im Fach Datenbanken 2 Aufbau einer Oracle-Datenbank Jonny Matischok IND-T Behandelt wird der Aufbau einer Oracle Datenbank insbesondere Tablespaces (Konzept, Arten, Operationen) sowie die unterschiedlichen Arten von Dateien (Datafiles, Redolog-Files, Control Files).

2 Inhaltsverzeichnis 1. Einleitung Tablespaces Konzept Bespiele SYSTEM Tablespacee SYSAUX Tablespacee Undo Tablespace Temporary Tablespace Andere Tablespaces Operationenn Dateien INIT.ORA Control Files Datafiles Redolog-Files Andere Dateien Verzeichnisse & Quellen Abbildungsverzeichnis Quellen Anhang INIT.ORA Seite 2

3 1. Einleitung Eine Datenbank ist eine Ansammlung von Daten (Informationen) in Dateien, diese besitzen unterschiedliche physische und logische Strukturen, wobei die wichtigste logische die Tabelle ist, die ihrerseits aus Spalten (Attribute) und Zeilen (Datensatz) besteht. Die physische Struktur ist nach außen zum Betriebssystem in Form Datafiles) sichtbar. von Dateien (z.b. Wollen Nutzer auf dieser Datenbank arbeiten, so tun sie das nicht direkt, sondern immer auf einer Instanz dieser Datenbank, dies geschieht für die Nutzer vollkommen transparent, d.h. die Nutzer wissen nicht, dasss sie statt auf der Datenbank auf einer Instanz arbeiten (siehe Abbildung 1.1). Abbildung 1.1. Zusammenhang zwischen Datenbank und Instanz (Quelle:[1] Oracle Essentials ) Die Instanz liegt dabei in einem Bereich des Arbeitsspeichers vom Datenbankserver, der System Global Area (SGA). Eine Datenbank kann dabei nur Teil einer Instanz sein, aber es könnenn mehrere Instanzen auf die gleiche Datenbank verweisen. Im Folgenden wird zuerst das Konzept der Tablespaces näher erläutert, bevor ich einige Beispiele näher betrachten werde. Abschließend wird auf das erzeugen eines Tablespaces näher eingegangen. Im zweiten Hauptabschnittt liegt der Schwerpunkt dann bei den am häufigsten vorkommenden Dateien bei einer Oracle Datenbank: den Control-, Data- und Redolog-Files. 3 Seite 3

4 2. Tablespace 2.1. Konzept Ein Tablespace (dt.: Tabellenraum) ist eine logische Struktur, die die physischen Datafiles (siehe Kapitel 3.3..) zusammenfasst. Dabei ist in einem Tablespace immer mindestens ein Datafile vorhanden. Der Tablespace besteht dabei aus vielen Segmenten, die die logischen Datenbankstrukturen (Tabellen, Indexe) enthalten. Diese Segmente lassen sich weiter aufteilen, so besteht ein Segment wiederum aus mehreren Extents. In einem Extent sind Speichereinheiten zu einem zusammenhängenden Block zusammengefasst. Die Extents ihrerseits bestehen aus Blöcken. Abbildung Aufbau eines Tablespace (Quelle: [2] Oracle Database 11g DBA Handbook ) Diese feine Granularität ermöglicht es, den Speicher (Arbeitsspeicher & Festplattenspeicher) effizient zu kontrollieren, dabei ist allerdings das Problem der Fragmentierung zu beachten. Weiterhin hat dieser Aufbauu den Vorteil, dass eine Trennung der logischen Objekte der Datenbank von den physischen gespeicherten Files erfolgt. So hat eine Oracle Datenbank auf unterschiedlichen Betriebssystemen den gleichen strukturellen Aufbau. Da es in der Regel verschiedene Tablespaces gibt, kann beim Anlegenn einer Tabelle der Tablespace bestimmt werden in dem diese Tabelle abgelegt werden soll. 4 Seite 4

5 2.2. Beispiele Bei Tablespaces gibt es die Möglichkeit diese online/aktiv (erreichbar) oder offline/inaktiv (nicht erreichbar) zu setzen, wobei standardmäßig ein Tablespace immer online ist. Dies geschieht über die folgenden Befehle: alter tablespace <name> offline; alter tablespace <name> online; ein offline setzen kann z.b. beim Backup oder Recovery nötig werden. Der SYSTEM Tablespace kann aber niemals offline gehen, wenn auf der Datenbank gearbeitet wird, da er das Data Dictionary enthält, welches immer erreichbar sein muss. Lokal verwaltete Tablespacess / Locally Managed Tablespace (LMTS) Bei LMTS verwaltet der Tablespace seinee Extents über eine lokale Bitmap-Struktur in jedem zugehörigem Datafile selbst, um über den Status der Blöcke informiert zu sein. Dieses Verfahren hat den Vorteil, dass es frei nebeneinander liegende Blöcke automatisch findet, ohne die Notwendigkeit diesee zusammenzufügen. Weiterhin werden rekursive Speichermanagementoperationen vermieden. Diese könnenn bei DMTS auftreten, wenn Speicherplatz allokiert oder freigegeben wird und dies eine weitere Operation auslöst, die ihrerseits nun wieder Speicher im Dataa Dictonary oder ROLLBACK SEGMENT belegt oder freigibt. Dictonary verwaltete Tablespaces / Dictionary Managed Tablespaces (DMTS) Extents eines Tablespaces werden vom Data Dictonary verwaltet, d.h. das Data Dictonary muss jedesmal die entsprechenden Tabellen updaten, wennn ein Extentt freigegeben oder allokiert wird. Dazu müssen auch noch ROLLBACK Informationen für jedes Update des Data Dictionary gespeichert werden. 5 Seite 5

6 SYSTEM Tablespace Dieser Tablespace wird immer mit dem Anlegen einer Datenbank erstellt, somit ist es der erste den die Datenbank nach ihrem Start besitzt. Er selbst wiederrum beinhaltet das Data Dictionary 1 sowie Daten von gespeicherten PL/SQL Programmeinheiten (Prozeduren, Funktionen, Paketee und Trigger). Sollte deren Anzahl groß sein, muss der Administrator für ausreichend Speicherplatz für diesen Tablespace sorgen SYSAUX Tablespace Dieser Tablespace ist ein Zusatz für den SYSTEM Tablespace. Weil immer mehr Funktionen ihren Output in die SYSTEM Tablespace oder in ihren eigenen geschrieben haben, wurde der SYSTEM Tablespace immer größer bzw. es entstanden immer mehr Tablespaces, je mehr Funktionen aktiv waren. Um dies zu unterbinden, wurde mit der Version 10g dieser Tablespace eingeführt. Mit der View v$sysaux_occupants kann überprüft werden, welchee Komponenten die den SYSUAX Tablespace benutzen und wie deren Platzbedarf ausfällt Undo Tablespace Der Undo Tablespace ist ein optionaler Tablespace, er beinhaltet ausschließlichh Undobevor er Segmente. Dennoch sollten keine Transaktionen von Nutzern ausgeführt werden, angelegt wurde. Zu beachten ist, dasss Oracle pro Instanz nur mit einem aktiven Undo Tablespace arbeiten kann. Die Hauptaufgabe dieses Tablespaces ist es, den alten Zustand von Feldinhalten ( before images ) so lange zwischen zu speichern, bis der neue Zustand fest geschrieben ist (COMMIT) und physikalisch in die Datenbank übertragen wurde (auf der Festplatte steht). Oracle sieht jedee Änderung als permanent an, das heißt bei einer Änderung eines Datensatzes wird dieser sofort gespeichert. Unabhängig davon ob der Nutzer die Transaktion bereits durch ein COMMIT beendet hat oder nicht. Durch ein vorheriges Kopieren des alten Zustandes ist es möglich, dasss einmal gestartete Transaktionen vom Nutzer mit einem ROLLBACK Befehl oder vom System wieder rückgängig gemacht werden können, indem die before images wieder zurück kopiert werden. Damit wird der temporäree neue Zustand einfach mit dem alten before image überschrieben. 1 Das Data Dictionary (dt.: Datenwörterbuch) ist Datenbankelementen enthält. 6 ein Bestandteil der Datenbank, die Darstellungsregeln (Struktur) von Seite 6

7 Ein weiterer Vorteil eines Undo Tablespaces ist die Möglichkeit des konsistenten Lesens, d.h. sollte eine Transaktion über einen längeren Zeitraum Daten ändern, kann einee zweite Transaktion auf die älteren before images zugreifen und liest somit nur Konsistentee Daten. Wird die Undo-Verwaltung automatisch durch das System übernommen, so hat der Administrator weder Einflusss auf die Größe noch auf die Anzahl der angelegtenn Undo- Segmente. Angelegt wird ein Undo Tablespace mit dem Befehl (Erläuterung siehe 2.3. Tablespace Operationen ): Internerr Aufbau CREATE UNDO TABLESPACE <name> DATAFILE <path> SIZE <size>; Intern sind die Segmente des Undo Tablespaces wie Ringpuffer aufgebaut, dabei kann eine Transaktion mehrere Segmente beanspruchen bzw. kann ein Segment mehrere Transaktionen beinhalten (Abbildung I.). Sollte es zu der Situation kommen, dass ein Segment gefüllt ist, kann entweder ein weiteres Extend in den Ring eingebaut werden (Abbildung IV.) oder es wird der Ring weiterbeschrieben, wennn dabei keine noch aktive Transaktion überschrieben wird (Abbildung II. - III.). Abbildung Ringpufferaufbau eines Undo Segmentes (Quelle:[3] Oracle 10g für den DBA ) 7 Seite 7

8 Temporary Tablespace Der Temporary Tablespace ist ebenfalls ein optionaler Tablespace. Es wird jedoch dringend empfohlen diesen anzulegen (Warnung in ALERT.LOG) 1, da sonst standardmäßig der SYSTEM Tablespace als temporärer Tablespace benutzt wird. In zukünftigen Versionen (Stand 10g) soll das Anlegen eines Temporary Tablespace nicht mehr optional sein. Ein Hauptgrund für das Anlegen eines solchen Tablespaces ist, dass bei Sortier- bzw. Hashwieder Operationen, bei Gruppiervorgängen oder beim Aufbau eines Index immer Zwischenergebnisse gespeichert werden müssen. Geschieht dies im SYSTEM-Tablespace, so wird dieser durch das ständige Schreiben und Ändern von Daten fragmentiert. Dies führt dann im Folgendenn zu einer verminderten Performance. Das Erstellen von Temporärdateien geschieht unabhängig wie groß sie sind in wenigen Sekunden, da im Gegensatz zu Data Files keine Oracle Blockformatierung durchgeführt wird. Angelegt wird ein Temporary Tablespacee mit dem Befehl (Erläuterung siehe 2.3. Tablespace Operationen ): CREATEE TEMPORARY TABLESPACE <name> TEMPFILE <path> SIZE <size>; Andere Tablespaces USER Tablespace Dieser Tablespace hat primärr die Aufgabe Nutzer, Objekte und Daten zu speichern. Sollte in einem System kein USER Tablespace existieren, so werden von den Nutzern erzeugte Objektee standardmäßig im SYSTEM Tablespace gespeichert. Dies kann Performancenachteile mit sich bringen, da alle Nutzer und Prozesse auf ein und demselben Tablespace arbeiten. 1 bezogen auf Oracle Version 10g 8 Seite 8

9 2.3. Operationen CREATEE TABLESPACE CREATEE SMALLFILE TABLESPACE <spacename> DATAFILE '...\space01.dbf' SIZE <size> AUTOEXTEND ON NEXT <addsize> MAXSIZE <maxsize> BLOCKSIZE <blocksize> LOGGING EXTENTT MANAGEMENT LOCAL UNIFORM SIZE <extentsize> SEGMENT SPACE MANAGEMENT AUTO; CREATEE SMALLFILE TABLESPACE <spacename> Es wird ein Tablespace mit <spacename> angelegt. SMALLFILE(Standard) 2 22 Blöcke bei 32K Blockgröße ergibt eine maximale Größe von 128 GB pro Datafile. Eine Vergrößerung des Tablespaces kann nur durch das Hinzufügen neuer erfolgen. BIGFILE 2 32 Blöcke bei 32K Blockgröße ergibt eine maximale Größe des Datafiles von 128 TB. Es gelten allerdings Einschränkungen bei der Größe seites des eingesetztenn Dateisystems. So kommt nicht jedes Dateisystem mit 128 TB großen Dateien zurecht. Ein Vergleich von Dateisystemen findet sich unter: file_systems Eine BIGFILE Tablespace kannn im Gegensatz zu SMALLFILE Tablespaces nur aus einer Datei bestehen. Da eine Oracle Datenbank bis zu Datafiles umfassen kann, ergibt das im Zusammenhang mit der Verwendung von BIGFILEs eine maximale Größe von 2 63 Bytes bzw. 8 Exabyte für die Datenbank. 9 Seite 9

10 DATAFILE '...\space01.dbf' SIZE <size> Gibt den Ort und die Größe des Datafiles an, das dem Tablespace zugeordnet werden soll. Dabei gelten die folgenden Abkürzungen: K Kilobyte, M Megabyte, G Gigabyte, T Terabyte. Die Endung des Datafiles hat dabei weder einen Standardwe ert noch ist sie Pflicht. Es wird jedoch empfohlen aufgrund der besseren Lesbarkeit.dbf oder.ora zu verwenden. Sollen einem SMALLFILE Tablespace mehrere Datafiles zugeordnet werden, so werden diese einfach mit einem Komma getrennt angegeben. DATAFILE '...\space01.dbf' SIZE <size>, DATAFILE '...\space02.dbf' SIZE <size2>, DATAFILE '...\space03.dbf' SIZE <size3> AUTOEXTEND ON NEXT <addsize> MAXSIZE <maxsize> Sollte das Datafile größer werden als ursprünglich angenomm men, wird es mit diesem Befehl um <addsize> bis zu einer maximalen Größe von <maxsize> vergrößert. Standardmäßig wird es um einen Block unbeschränkt vergrößert. Das allokieren einzelner Blöcke führt meist zu Performanceeinbruchführen. Deshalb empfiehlt es sich hier eine geeignete Größe für neu zu reservierenden Speicher zu wählen. BLOCKSIZE <blocksize> Angabe der zu verwendendenn Blocksize (4KB 32KB). Siehe Kapitel 3.3. Datafiles. LOGGING Das Logging wird mit diesem Befehl aktiviert. 10 Seite 10

11 EXTENTT MANAGEMENT LOCAL UNIFORM SIZE <extentsize> LOCAL Definiert den Tablespace als Locally Managed Tablespace (LMTS). UNIFORM SIZE <extentsize> Mit diesem Befehl erhalten alle neu <extentsize>. AUTOALLOCATE Die Größe der Extents wird gestaffelt: 64 KB für die ersten 16 Extents 1 MB ab dem 17. Extent 8 MB ab dem 80. Extent 64 MB ab dem 200. Extent allokierten Extents eine einheitliche Größe von Diese Einstellung wird für die allermeisten Zwecke empfohlen, lediglich für sehr große Objektee sollte der Tablespacee eine einheitliche Größe für die Extents benutzen (UNIFORM SIZE). SEGMENT SPACE MANAGEMENT AUTO Mit diesem Befehl wird für die Verwaltung der freien Plätze in Blöcken die Methode des Automatic Segment Space Management (ASSM) benutzt. Dabei wird der Platz nicht über verkettete Listen ( Freilisten ), sondern über eine Bitstruktur verwaltet. Prinzipieller Aufbauu der Bitstruktur 1. Bit Beim Überschreiten eines Schwellwertes (PCTFREE) wird diese Bit auf 1 gesetzt, um anzuzeigen, dass der Block voll ist. 2. und 3. Bit Mit diesen Bits (siehe Übersicht rechts) wird der Füllgrad des Blockes angegeben (gilt nur für Datensegmente). Das letzte Bit Kombination Freier Platz Mehr als 75 % Mehr als 50 % Mehr als 25 % Weniger als 25% Dieses gibt Auskunft darüber ob der Block bereits Formatiert wurde (1) oder nicht (0). 11 Seite 111

12 3. Dateien Die Grundlage der Oracle Datenbank sind die Control Files, Datafiles und die Redolog-Files die im Folgenden Kapitel näher betrachtet werden. Bevor man jedoch mit der Datenbank arbeiten kann, musss eine Instanz der Datenbank vorhanden sein, diese wird mit einer Initialisierungsdatei (Parameterdatei), als INIT.ORA bezeichnet, gestartet INIT.ORA Diese Datei wird immer beim Start einer Instanz gelesen, dennn in ihr befinden sich wichtige Parameter die benötigt werden um einee neue Sitzung zu starten. Sie ist weiterhin einer der Punkte, an dem die Leistung einer Oracle Datenbank optimiert werden kann. Folgende Parameter sind u.a. in ihr gespeichert (Auswahl, die vollständige Liste befindet sich im Anhang (5.1)). Parameter Wirkung CONTROL_FILES Standort des Control Files DB_NAME Lokaler Name der Datenbank LOG_ARCHIVE_DEST Standort des Log-Archiv Abbildung Auszug aus der INIT.ORA Der Name und der Pfad der Datei sind von Betriebssystem abhängig (Abbildung ). Die angegebene ORACLE_SID ist die ID der Oracle Datenbank, die verwendet werden soll. Betriebssystem Windows Unix Pfad %ORACLE_HOME%\database $ORACLE HOME/dbs Name init%oracle_sid%.ora init$oracle_sid.ora Abbildung Namen und Standort der INIT.ORA unter Windows und Unix Die von der Datenbank aktuell verwendeten Parameter könnenn mit dem Befehl show parameters im SQL* *PLUS ausgelesen werden. 12 Seite 12

13 3.2. Control Files Diese Dateien sind die Grundlage für den Betrieb und den Start der Datenbank, da sie u.a. die Positionen der anderen Dateien (z.b. Datafiles, Redolog-Files) sowie wichtige Informationen über Status und Inhalt einer Datenbank beinhaltet. Information The name of the database Names and locations of datafiles and redo log files Tablespace information Checkpoint information Abbildung Ausgewählte Informationen des Control Files In der Abbildung wird der genaue Zusammenhang zwischen den Control Files, den Datafiles und den Redolog-Files genauer aufgezeigt. Abbildung Zusammenhang zwischen Control Files, Datafiles und Redolog-Filebei einem Crash ein (Quelle:[1] Oracle Essentials ) Ein Control File sollte nach Möglichkeit mehrfach vorhanden sein, um Backup zu haben, dies kann mittels des entsprechenden Parameters (s.u.) in der INIT.ORA eingestellt werden. Angabe mehrerer Control Dateien in der INIT.ORA: control_files = (/u00/oradata/control.1.dbf, /u01/oradata/control.2.dbf) Dabei werden alle von Oracle angelegten Kopien der Control Files Inkonsistenzen zu vermeiden. synchronisiert, um 13 Seite 13

14 3.3. Datafiles Datafiles sind das eigentlichee Herzstück einer jeden Oracle Datenbank, denn sie beinhalten die (Meta-)Informationen, wie Tabellen, Indexe, das Data Dictonary und Rollback Segmente, die in der Datenbank gespeichert werden. Das Datafile besteht dabei aus Oracle Blöcken, die wiederum aus Blöcken des Dateisystems bestehen (siehe Abbildung ). Der Block ist kleinste Einheit die geschrieben bzw. gelesen werden kann auch I/O Operation. Benötigte Daten werden in Oracle Block Größe je nach Bedarf gelesen. Ein Datafile kann immer nur zu einem Tablespace gehören. Abbildung Aufbau eines Datafile Abbildung Aufbau eines Datenblocks (Quelle:[1] Oracle Essentials Quelle: [3] Oracle 10g für den DBA ) Am Anfang des Datafile befindet sich der Datafile Header, welcher Richtung Dateiende wächst. Der Teil, der die Informationenn enthält, beginnt hingegen am Ende und wächst Richtung des Kopfes zum Anfang. Diese Art des Füllens der Blöcke garantiertt größte Flexibilität in Bezug auf wachsende Daten- und Headerinformationen. Der Header enthält kritische Informationen, um die Integrität der Datenbank zu gewährleisten. Eine dieser Informationen ist die Checkpoint Structure. Sie enthält einen Zeitstempel, der den letzten Zeitpunkt angibt, an dem das Datafile zum letzten Mal geschrieben wurde. Dies ist u.a. für den Recovery-Prozess wichtig, um zu wissen welche Aktionen des Redologs durchgeführt müssen damit, nach einem Crash, einen konsistenter Zustand erhalten wird. In einer Datenbank sind bis z Tablespace. Standartmäßig INIT.ORA festgelegt. zu 5 unters wir diese schiedliche über ein Blockgröße Parameter en möglich, aber nur eine pro (DB_BLOCK_SIZE)) in der 14 Seite 14

15 Gängige Größen reichen von 4 KB, dies ist besonders für Online Transaction Processing (OLTP) geeignet (da nur wenige Daten verarbeitet werden müssen), bis hin zu 32 KB, was besonders für Data Warehousing geeignet ist (da hier viele Daten auf einmal verarbeitet werden). Beim Update von Daten wird versucht die neuen Daten in denselben Block zu schreiben. Ist dies Aufgrund von zu wenig Speicher nicht möglich, werden die Daten in einen neuen Block geschrieben. Dabei ist es möglich, dass dieser in einem anderen Extent liegt. (vgl. Abbildung Aufbau eines Tablespace). Temporary Datafiles Lokal verwaltete Temporary Tablespacess haben auch temporäre Datafiles (tempfiles). Diese unterscheiden sich von den normalen Datafiles in folgenden Punkten: Bei tempfiles gibt es kein Logging (NOLOGGING) Nicht als Read-Only definierbar Können nicht mit ALTER DATABASE Befehl erstellt werden 3.4. Redolog-Files Sind Dateien in denen die getätigten Änderungen in der Datenbank, z.b. durch Transaktionen und/oder interne Oracle Prozesse verursacht, mit protokolliert (mit geloggt) 1 werden. Sie enthalten dabei nicht wie man vermuten könnte eine Reihee von SQL Befehlen, sondernn es werden Änderungen von an Datenblockzuständen protokolliert. Es gibt neben den Online-Redolog-Files auch noch die Archived-Redolog-Files, die Kopien von gefüllten Online-Redologfiles enthalten, damit diese nicht überschrieben werden und es zum Verlust von Informationen kommt. Im Fehlerfall (z.b. Crash) kann daher mit Hilfe der Log Dauerhaftigkeit der Daten bewahrt werden. Dateien die Konsistenz und Komprimierung Es gibt Möglichkeiten das Redolog-File in seiner Größe geringg zu halten. Erreicht wird dies allerdings nicht über einen aufwändigen Komprimierungsalgorithmus, sondern einfach durch das Weglassen von Einträgen bei bestimmten Aktionen. Damit erhöht sich zwar die Geschwindigkeit mit der einee Transaktion bearbeitet wird, sollte es aber zu einem Fehler kommen, kann nicht nachvollzogen werden, was die Transaktion bis zu ihren Absturz schon erledigt hat. 15 Seite 15

16 Das Logging kann sowohl für einzelne Transaktionen aber auch für den ganzen Tablespace abgeschaltet werden. Dies geschieht indem NOLOGGING im SQL Statement bei den Transaktionen bzw. beim Erstellen des Tablespace mit abgegeben wird. Vervielfältigung Wie auch bei den Control Files bietet Oracle die Möglichkeit Redologs mehrfach zu speichern (in Abbildung sind das die member). Dabei müssen aber immer mindestens zwei existieren. Diese sollten nach Möglichkeit auf einer anderen Festplatte liegen. Auf alle angelegtenn Kopien (member) wird dabei gleichzeitig geschrieben, um Inkonsistenzen zu vermeiden. Es ist zu beachten, dass solange gewartet wird, bis alle Logging-Dateien auf die Festplatte geschrieben wurden. Das heißt die langsamste Platte bestimmt die Geschwindigkeit, mit der das Logging stattfindet, sie könnte also zum Flaschenhals werden. Weiterhin müssen mindestens zwei Gruppen von Redolog-Fil les vorhanden sein, damit der Protokollierende Prozess (Logwriter-Prozess) zwischen ihnen umschalten kann, wenn eine gefüllt ist. Abbildung Redolog-File Gruppen (Quelle:[1] Oracle Essentials ) Das Logging Oracle füllt sequentiell die Logdateien auf, ist die erste voll geschrieben wird der Logwriter Prozesss beginnen das nächste File zu beschreiben. Die Nummerierung der Files erfolgt dabei 16 Seite 16

17 fortlaufend, unabhängig davon um welches File es sich handelt (siehe Abbildungg Sequentielles füllen der Online-Redolog-Files ). Abbildung Sequentielles füllen der Online-Redolog-Files (Quelle:[1] Oracle Essentials ) NOARCHIVLOG Die Logfiles werden bei dieser Methodee immer wieder zyklisch überschrieben ohne diese vorher zu sicher. Dies hat ein offensichtliches Defizit, sollte es zu Fehlern kommen. Die protokollierten Aktionen wären verloren und können nicht wiederhergestellt werden. Damit das Prinzip der Dauerhaftigkeit von Transaktionen verletzt und daher ist diese Methode für den praktischen Einsatz nicht geeignet. ARCHIVLOG Wenn ein Redolog gefüllt ist, wird es zuerst gesichert und erst danach kann der Logwriter die Gruppe wechseln. Um dabei Diskrepanzen zu vermeiden ist das Redolog während es gesichert wird nicht nutzbar. Durch die Kombinationn von Online- und Archived-Redolog-Files bietet Oracle eine vollständige Liste aller an der Datenbank gemachten Änderungen, somit könnenn alle beendeten Transaktionen wieder hergestellt werden. Dabei gilt eine Transaktion 17 Seite 17

18 nicht mit ihrem COMMIT als abgeschlossen, sondern wenn das Ende der Transaktion in das Log geschrieben wurde. Der SQL-Befehl für das automatische Archivieren einer Datenbank lautet: ALTER DATABASE ARCHIVELOG Es ist möglich mittels des Initialisierungsparameters, LOG_ARCHIVE_DUPLEX_DEST mehrere Orte anzugeben, in die ein Log gespeichert werden soll Andere Dateien Password File Diese Datei dient dazu den starten oder zu beenden. Administrator zu authentifizieren, um z.b. die Datenbank zu Allerdings ist die nicht die einzige Methode zur Authentifizierung, weshalb diese Datei nicht immer vorhanden sein muss. Backup Files Backupfiles sind keine direkten Kopien bei einem Crash wiederherzustellen. der Datenbank, dennoch ermöglichen sie es Daten 18 Seite 18

19 4. Verzeichnisse & Quellen 4.1. Abbildungsverzeichnis Abbildung Zusammenhang zwischen Datenbank und Instanz Quelle: [1] Oracle Essentials 3 Abbildung Abbildung Aufbau eines Tablespace Quelle: [2] Oracle Database 11g DBA Handbook - Ringpufferaufbau eines Undo Segmentes Quelle: [3] Oracle 10g für den DBA 4 7 Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Abbildung Auszug aus der INIT.ORA 12 - Namen und Standort der INIT..ORA unter Windows und Unix 12 - Ausgewählte Informationen des Control Files 13 - Zusammenhang zwischen Control Files, Datafiles und Redolog-Files 13 Quelle: [1] Oracle Essentials - Aufbau eines Datafile 14 Quelle: [1] Oracle Essentials - Aufbau eines Datenblocks 14 Quelle: [3] Oracle 10g für den DBA - Redolog-File Gruppen 16 Quelle: [1] Oracle Essentials - Sequentielles füllen der Online-Redolog-Files 17 Quelle: [1] Oracle Essentials 4.2. Quellen [1] Oracle Essentials von Rick Greenwald, Robert Stackowiak, Jonathan Stern; O'Reilly Media; Auflage: 4th edition (23. November 2007); November 2007; ISBN-10: [2] Oracle Database 11g DBA Handbook von Bob Bryla, Kevin Loney; Mcgraw-Hill Professional (6. Dezember 2007) ISBN-10: [3] Oracle 10g für den DBA: Effizient konfigurieren, optimieren und verwalten von Johannes Ahrends, Dierk Lenz, Patrick Schwanke, Günther Unbescheid; Verlag: Addison-Wesley, München (November 2005); ISBN-10: [4]Oracle Database 2 Day DBA; 19 Seite 19

20 5. Anhang 5.1 INIT.ORA CONTROL FILES The control file locations DB_NAME The local database name DB_DOMAIN The database domain name (such as us.companyname..com) LOG_ARCHIVE_DEST The log archive destinationn LOG_ARCHIVE_DEST_STATE The parameter that enables log archiving DB_RECOVERY_FILE_DEST The location of the database flash recovery area (directory, filesystem, or ASM disk group) DB_RECOVERY_FILE_DEST_SIZE The database flash recovery area maximum size in total bytes DB_BLOCK_SIZE The database block size in bytes (e.g., 4 KB = 4,,096) PROCESSES The maximum number of concurrent database operating system processes SESSIONSS The maximum number of database sessionss OPEN_CURSORS The maximum number of database open cursors SHARED_SERVERS The minimum number of database shared servers REMOTE_LISTENER The remote listener name COMPATIBLE 20 Seite 20

21 The database version you want for compatibility where features affect file format (e.g., , ) MEMORY_TARGET The target memory size that is automatically allocated to SGA and instance PGA components DDL_LOCK_TIMEOUT For data definition language (DDL) statements, the time a DDL statement waits for an exclusivee lock (in seconds) before failing NLS_LANGUAGE The National Language Support (NLS) language specified for the database NLS_TERRITORY The National Language Support territory specified for the database 21 Seite 21