Dateisysteme und Datenbanken

Transkript

1 Sommersemester 2002 Vorlesung Betriebssysteme, Prof. Dr. Torsten Braun Semesterarbeit Von 1 / 22

2 Inhalt 1. Einführung 3 2. Dateisystemimplementierung Implementierung von Dateien Kontinuierliche Allokation Allokation mittels einer verknüpften Liste Allokation mittels einer verknüpften Liste und Indexeinsatz I-Nodes Performance der verschiedenen Allokationsmethoden 7 3. Plattenplatzmanagement Blockgrössen 8 4. Effizienz Performance Zuverlässigkeit des Dateisystems Fehlerblockverwaltung Backups und Wiederherstellung Dateisystemkonsistenz 9. Sicherheit 9.1 Identifikation und Authentifikation Zugriffsdomänen, Capabilities, ACLs Optimierung Beispiel Filesysteme für Oracle Datenbank Wahl des Filesystems RAW Devices Verwaltung der Daten einer Datenbank durch Oracle RAW Device oder Filesystem? SQL-Anweisungen zur Verwaltung der Datenfiles Festlegen von Filesystem oder RAW Device Literaturverzeichnis / 22

3 1. Einführung Hauptaufgabe einer Datenbanken ist es, Informationen abspeichern und wiederfinden. Während ein Prozess in Ausführung ist, kann er begrenzte Mengen von Informationen in seinem eigenen Adressraum abspeichern. Diese Speicherkapazität ist aber normalerweise durch die Grösse des virtuellen Adressraums beschränkt. Die Grösse ist für kleine Anwendungen angemessen, aber für grossen Datenbanken, wie zum Beispiel ein Banksystem, ein Flugreservierungssystem oder die Buchführung in grossen Unternehmen, ist sie viel zu klein. Dies ist also eine erste Anforderung an ein Dateisystem für Datenbanken. Ein zweites Problem ist das Speichern von Informationen im Adressraum eines Prozesses. Falls nun der Prozess terminiert, so würden sämtliche Informationen verloren gehen. Damit ergibt sich also ein zweites Problem, welches auf Dateisysteme für Datenbanken zukommt. In Datenbanken müssen die Informationen über Wochen, Monate oder sogar für immer gespeichert werden. Es darf also nicht passieren, dass die Informationen verschwinden, wenn der entsprechende Prozess terminiert. Weiter dürfen die Informationen also auch dann nicht verloren gehen, wenn ein Rechner ausfällt oder ein Prozess vorzeitig terminiert. Eine dritte Anforderung ist, dass es häufig notwendig ist, dass mehrere Prozesse gleichzeitig auf die Informationen (oder Teile von diesen) zugreifen. Wenn zum Beispiel in einer Personendatenbank eine Telefonnummer auch innerhalb des Adressraums eines einzelnen Prozesses gespeichert ist, hat nur dieser Prozess darauf Zugriff. Also könnte zu einem Zeitpunkt immer nur genau eine Telefonnummer nachgeschlagen werden. Dieses Problem wird in der Regel dadurch gelöst, dass die Informationen unabhängig von irgendeinem Prozess gespeichert werden. Daraus ergeben sich drei hauptsächliche Anforderungen an Dateisysteme für die langfristige Speicherung von Daten: 1. Sehr grosse Mengen von Informationen müssen gespeichert werden. 2. Die Informationen dürfen wegen einer Terminierung der Prozesse, die diese verwenden, nicht gelöscht werden. 3. Es muss für mehrere Prozesse möglich sein, gleichzeitig auf die Informationen zuzugreifen. Es wird dadurch geregelt, dass die Informationen auf Platten und anderen externen Speichermedien in Dateien abgelegt werden. Diese können dann von Prozessen gelesen und auch neu beschreiben werden. Die in Dateien gespeicherte Information muss persistent sein, das heisst, nicht von der Erzeugung und Terminierung von Prozessen beeinflusst sein. Eine Datei darf nur verschwinden, wenn ihr Eigentümer sie explizit entfernt. 3 / 22

4 Das Betriebssystem verwaltet die Dateien. Wie sie strukturiert, benannt, auf sie zugegriffen, benutzt, geschützt und implementiert werden, sind wesentliche Punkte beim Entwurf von Betriebssystemen. Als Ganzes betrachtet, ist dieser Teil des Betriebssystems der sich mit den Dateien beschäftigt, als Dateisystem bekannt. Dieser Teil des Betriebssystems, das Dateisystem, ist hier von Interesse, da für eine Datenbank vieles von dem Dateisystem abhängt. Neben den oben genannten wesentlichen grundlegenden Anforderungen an ein Dateisystem gibt es speziellere Anforderungen an Dateisysteme, welche für Datenbanken genutzt werden. Eine weitere Anforderung an ein Dateisystem ist die Effizienz. Weiter muss die Performance eines Dateisystems betrachtet werden. Bei grossen Datenbanken ist es nicht wünschenswert, dass eine Datenbankabfrage zu lange Zeit in Anspruch nimmt. Hier wird vor allem betrachtet, wie oft verwendete Blöcke in Disk Caches gespeichert werden, damit sie schnell wieder zur Verfügung stehen. Eine wichtige Anforderung ist die Zuverlässigkeit des Dateisystems, denn das Verlieren einer Datenbank kann für viele Firmen eine schlimme Katastrophe bedeuten. Dafür ist die Fehlerblockverwaltung ein wichtiges Thema. Weiter werden Methoden des Backups betrachtet, d.h. wie eine Datenbank wiederhergestellt werden kann im Falle einer Zerstörung des Dateisystems. Ein weiteres Thema ist die Dateisystemkonsistenz, welche garantiert werden muss, damit das Dateisystem nicht in einen inkonsistenten Zustand geraten kann und somit Daten verloren gehen können. Die Sicherheit der Daten einer Datenbank ist etwas sehr Wichtiges, da das Dateisystem normalerweise Informationen enthält, welche für den Datenbankbesitzer von beträchtlichem Wert sind. Der Schutz dieser Informationen gegenüber einer nicht autorisierten Benutzung ist deswegen ein wichtiger Aspekt in allen Dateisystemen. Heutzutage spielt der Datenschutz eine sehr wichtige Rolle, d.h. dass Informationen nicht öffentlich zugängig sein sollten, also auch vor Spionage geschützt. 2. Dateisystemimplementierung 2.1 Implementierung von Dateien Ein zentrales Thema für ein Dateisystem ist die Implementierung der Dateispeicherung. Das Problem hier ist die Verwaltung der Plattenblöcke und ihre Zugehörigkeit zu einer Datei. Im folgenden werden verschiedene Allokationsmethoden welche in unterschiedlichen Systemen angewandt werden - erläutert, da die Allokationsmethoden unterschiedlich sind bezüglich ihrer Speichereffizienz und Datenblockzugriffszeit. Diese zwei Sachen spielen eine wichtige Rolle, um das richtige Betriebssystem zu wählen auf dem die Datenbank aufgesetzt werden sollte. D.h. dass ein Betriebssystem gewählt werden sollte, welches die für die Datenbank günstigsten Allokationsmethoden verwendendes Dateisystem verwendet in Betracht von Schnelligkeit oder 4 / 22

5 Speicherplatzeffizienz. Nun werden die folgenden Allokationsmethoden erläutert und anschliessend diese in Betrachtung ihrer Performance verglichen, da dies ausschlaggebend sein kann für die Performance einer Datenbank, welche ein bestimmtes Dateisystem verwendet. 2.2 Kontinuierliche Allokation Die Kontinuierliche Allokation ist das einfachste Allokationsschema. Jede Datei wird als einen kontinuierlichen Block von Daten auf der Platte gespeichert (siehe Bild 1). Eine Datei der Grösse 50K würde auf einer Platte mit 1K Blöcken 50 zusammenhängende Blöcke belegen. Diese Methode hat zwei signifikante Vorteile. Erstens ist es einfach zu implementieren, da die Verwaltung der Dateiblöcke auf die Speicherung einer einzelnen Nummer reduziert wird, nämlich die Plattenadresse des ersten Blocks. Zweitens ist die Performance ausgezeichnet, da die gesamte Datei in einer einzigen Operation von der PIatte gelesen werden kann. Keine andere Allokationsmethode kommt diesen beiden Vorteile näher. Leider hat die kontinuierliche Allokation auch zwei Nachteile. Erstens ist die Allokation nicht durchführbar, wenn die maximale Grösse der Datei zum Zeitpunkt der Erzeugung nicht bekannt ist. Ohne diese Information weiss das Betriebssystem nicht, wieviel Plattenplatz es reservieren soll. Eine solche Methode ist sicherlich nicht ideal für ein Dateisystem, welches für Datenbanken benutzt werden soll, da die Grösse einer Datenbank stetig wächst. In Systemen hingegen, in denen Dateien auf einen Schlag geschrieben werden, kann es ein grosser Vorteil sein. Der zweite Nachteil ist die Fragmentierung der Platte, die aus der Allokationsstrategie herrührt. Es wird Platz verschwendet, der anderweitig genutzt werden könnte. Die Verdichtung der Platte ist gewöhnlich unerschwinglich teuer, obwohl es von Vorteil wäre, diese nachts durchzuführen, wenn das System sowieso unbenutzt ist. Bild 1: Kontinuierliche Allokation von Speicherplatz: man sieht, dass jede Datei zusammenhängende Blöcke belegt und im Directory der Start und die Länge jeder Datei festgehalten ist. 5 / 22

6 2.3 Allokation mittels einer verknüpften Liste Eine weitere Methode ist die Verwaltung der Dateien mittels einer verknüpften Liste, siehe Bild 2. Die Verknüpfung erfolgt dadurch, dass das erste Wort jedes Blockes als Zeiger auf den nächsten Block genutzt wird. Der Rest des Blockes ist frei und kann die Daten enthalten. Wie bei der kontinuierlichen Allokation kann jeder Plattenblock bei dieser Methode benutzt werden. Es geht kein Platz durch eine Fragmentierung der Platte verloren und sie ist ebenfalls für Verzeichniseinträge anwendbar, die nur die Plattenadresse des ersten Blockes speichern. Der Rest kann dann ab dieser neuen Startposition gefunden werden. Obwohl das sequentielle Lesen einer Datei einfach ist, ist der zufällige Zugriff extrem langsam. Weiterhin ist die Grösse des Datenspeichers in einem Block nicht mehr länger eine Zweierpotenz, da der Zeiger ein paar Bytes belegt. Obwohl dies nicht fatal ist, ist der Einsatz dieser eigenartigen Grösse wenig effizient, da viele Programme in Blöcken lesen und schreiben, deren Grösse eine Zweiterpotenz ist. Bild 2: Man sieht die Datei mit Namen jeep, welche im Directory als Startblock den Block Nr. 9 hat und als Endblock den Block 25. Dazwischen sind die jeweiligen Blöcke miteinander verknüpft. Die 1 im Endblock signalisiert NIL, d.h. das Ende der Datei. 2.4 Allokation mittels einer verknüpften Liste und Indexeinsatz Die oben genannten Nachteile einer Allokation mittels einer verknüpften Liste können durch die Speicherung der Zeigerworte jedes Plattenblocks in einer Tabelle oder einem Index im Speicher eliminiert werden. Auf diese Weise ist der gesamte Block für Daten verfügbar. Weiterhin ist der zufällige Zugriff sehr viel einfacher. Obwohl die Kette durchlaufen werden muss; um einen gegebenen Offset innerhalb der Datei zu finden, ist die Kette komplett im Hauptspeicher, wodurch das Durchlaufen ohne weitere Plattenreferenzen stattfinden kann. Analog zur vorherigen Methode reicht es aus, für einen Verzeichniseintrag nur eine einzelne Zahl zu verwalten (die Startblocknummer) und dennoch in der Lage zu sein, alle Blöcke zu lokalisieren, egal wie gross die Datei ist. MS-DOS benutzt diese Methode für seine Plattenallokation. Ein grosser Nachteil dieser Methode ist, dass die gesamte Tabelle während der ganzen Arbeitszeit im Speicher gehalten werden muss. Mit einer Platte, angenommen 6 / 22

7 1' K Blöcke (1GB), besitzt die Tabelle 1' Einträge, von denen jeder ein Minimum von 3 Bytes hat. Aber um einen schnelleren Einblick in die Tabelle zu haben, sollten sie schon 4 Bytes gross sein. Also belegt die Tabelle immer bis zu 3 (mit Einträgen von je 3 Bytes) oder 4 Megabytes (mit Einträgen von je 4 Bytes), abhängig davon, ob das System auf Platz oder Zeit optimiert wurde. 2.5 I-Nodes Dies ist das von UNIX verwendete Schema. Diese Methode der Verwaltung, ist die Verbindung jeder Datei mit einer kleinen Tabelle, der I-Node (Index-Node), die die Attribute und die Plattenadressen der Dateiblöcke auflistet, siehe Bild 3. Die ersten wenigen Plattenadressen werden in dem I-Node selbst gespeichert, so dass für kleine Dateien die notwendige Information im I-Node steckt, welcher durch das Öffnen der Datei von der Platte in den Hauptspeicher geholt wird. Für etwas grössere Dateien ist eine der Adressen in dem I-Node die Adresse eines Plattenblockes, der auch einfacher indirekter Block genannt wird. Dieser Block enthält weitere Plattenadressen. Falls diese immer noch nicht genug sind, enthält eine weitere Adresse in dem I-Node zweifacher indirekter Block genannt, eine Adresse eines Blockes, der eine Liste vor einfachen indirekten Blöcken besitzt. Jeder dieser einfachen indirekten Blöcke zeigt auf ein paar hundert Datenblöcke. Falls dies immer noch nicht genug ist, kann ein dreifacher indirekter Block eingesetzt werden. Bild 3: I-Node. Unterschiedung zwischen den direkten Daten Blöcken, den einfach indirekten Blöcken und den zweifach indirekten Blöcken. 2.6 Performance der verschiedenen Allokationsmethoden Für irgendeine Art Zugriff benötigt kontinuierliche Allokation nur ein Zugriff, um auf einen Disk-Block zuzugreifen. Da einfach nur die initiale Adresse des Files im Speicher gehalten werden muss, kann man unmittelbar die Adresse des i-ten Blocks berechnen und ihn direkt lesen. Dies wäre geeignet, um direkt und schnell Teile der Datenbank zu lesen. Da aber die maximale Grösse einer Datei einer Datenbank bei der Erzeugung nicht bekannt ist, sondern stetig wächst, ist die kontinuierliche Allokation nicht geeignet für ein Dateisystem für Datenbanken. 7 / 22

8 Ein Problem der Allokation mittels einer verknüpften Liste ist die Zuverlässigkeit. Da die Files miteinander mittels Zeiger über die ganze Disk verteilt verbunden sind, würde ein Verlust oder eine Beschädigung eines Zeigers den Verlust der ganzen Datenbank oder Teile davon bedeuten. Ein Fehler in der Betriebssystemsoftware oder ein Hardwarefehler in der Disk könnte darin resultieren, dass der falsche Zeiger gewählt wird. Dieser Fehler könnte dazu führen, dass auf nicht belegte Blöcke gezeigt wird oder auf einen anderen Dateiblock. Lösungen dafür sind doppelt verknüpfte Listen oder den Dateinamen und die relative Blocknummer in jedem Block zu speichern. Dies würde aber ein noch grösserer Overhead erzeugen für jedes File. Ein weiterer Nachteil ist, dass diese Methode nur für den sequentiellen Zugriff verwendet werden kann. Um den i-ten Block einer Datei zu finden, muss am Anfang der Datei begonnen werden und den Zeigern gefolgt werden, bis man beim i-ten Block angelangt ist. Jeder Zugriff zu einem Zeiger benötigt eine read-anweisung der Platte manchmal eine Plattendurchsuchung. Es ist also ineffizient, direkten Zugriff mit dieser Methode zu unterstützen. Eine wichtige Variation dieser Methode wird durch den Gebrauch einer file-allocation table (FAT) realisiert. Diese simple aber effiziente Methode wird von dem MS-DOSund dem OS/2-Betriebssystem verwendet. Eine Sektion der Disk am Anfang jeder Partition wird reserviert, um eine Tabelle zu speichern. Diese Tabelle besitzt einen Eintrag für jeden Diskblock, welcher mit der Blocknummer indiziert ist. Der Eintrag enthält die Blocknummer des ersten Blocks des Files. Der Tabelleneintrag, welcher durch die Blocknummer indiziert ist enthält wiederum die Blocknummer des nächsten Blocks des Files. Diese Kette geht so weiter bis zum letzten Block, welcher einen speziellen Wert enthält, der das Ende des Files anzeigt. Als Folge oben genannter Probleme unterstützen einige Systeme direkten Zugriff zu Files mittels kontinuierlicher Allokation und sequentiellen Zugriff mittels der Allokation über Linked Lists. Für diese Systeme muss der Zugriffstyp bei der Erstellung der Datei deklariert werden. Einmal erstellt, kann die andere Methode nicht mehr verwendet werden. Dies ist also nicht wirklich eine Lösung für Dateisysteme für Datenbanken. Indizierte Allokation löst das Problem der ineffizienten Unterstützung des direkten Zugriffs der Allokation mittels einer verknüpften Liste dadurch, dass alle Zeiger zusammen zu einem Ort gebracht werden, dem Indexblock. Jedoch verschwendet diese Methode mehr Platz als die Allokation mit Linked Lists. Falls für die Datenbank der Speicher problematisch ist, ist diese Methode ungeeignet. Die indizierte Allokation ist etwas komplexer: Falls der Indexblock bereits im Speicher ist, so kann der Zugriff direkt erfolgen. Dementgegen benötigt das Halten des Indexblocks im Speicher viel Platz. Wenn dieser Speicherplatz nicht verfügbar ist, so muss zuerst der Indexblock und danach der gewünschte Datenblock gelesen werden. Wenn zweifach indizierte Blöcke verwendet werden, so müssten zwei Indexblöcke gelesen werden. Für den Zugriff auf einen Block nahe des Endes des Files einer sehr grossen Datei wie es bei Datenbanken vorkommt müsste in allen Indexblöcken allen Zeigern nachgegangen werden bevor der Datenblock endlich gelesen werden könnte. Die Performance der indizierten Allokation hängt von der Indexstruktur, der Grösse der Datei und dem gewünschten Block ab. 8 / 22

9 3. Management des Plattenplatzes Da Dateien üblicherweise auf einer Festplatte gespeichert werden, ist die Verwaltung des Plattenplatzes eine Hauptaufgabe für die Dateisystemdesigner. Es gibt zwei generelle Strategien, um eine n Byte grosse Datei zu speichern: n zusammenhängende Bytes der Platte werden allokiert oder die Datei wird in eine Anzahl von (nicht notwendigerweise) gleich grossen Blöcken aufgeteilt. Dasselbe. Problem tritt in Speicherverwaltungssystemen zwischen der reinen Segmentierung und der Seitenersetzung auf. Eine Datei als zusammenhängende Sequenz von Bytes zu speichern, hat das offensichtliche Problem, dass, wenn die Datei wächst, sie wahrscheinlich auf der Platte verschoben werden muss, was für eine Datenbank ziemlich unvorteilhaft ist Das gleiche Problem gilt bei Segmenten im Speicher, mit dem Unterschied, dass die Verschiebung von Segmenten im Speicher eine relativ schnelle Operation ist im Vergleich zum Verschieben einer Datei von einer Plattenposition zu einer anderen. Aus diesem Grund teilen fast alle Dateisysteme ihre Dateien in Blöcke mit fixierter Grösse, die nicht zusammenliegen müssen. 3.1 Blockgrössen Also stellt sich die Frage, wie gross die Blöcke sein sollen. Die Festplatten sind organisiert in Sektoren, Spuren und Zylinder. Dies wären naheliegende Kandidaten für eine Allokationseinheit. In Seitenersetzungssystemen ist die Seitengrösse auch ein Hauptstreitpunkt. Würde ein Zylinder als Allokationseinheit gewählt, was einer grossen Allokationseinheit entspricht, so würde das bedeuten, dass jede Datei, auch eine 1 Byte grosse Datei, einen kompletten Zylinder belegen würde. Die durchschnittliche Dateigrösse in UNIX Umgebungen beträgt etwa 1K, so dass die Allokation eines 32K Zylinders für jede Datei 31/32 oder 97 Prozent des gesamten Plattenplatzes verschwenden würde. Für Datenbanken ist dies eher nicht ein grosses Problem, da Dateien von Datenbanken nicht diese kleine Grösse aufweisen. Demgegenüber bedeutet der Einsatz einer kleinen Allokationseinheit, dass jede Datei aus mehreren Blöcken besteht. Das Lesen eines Blockes benötigt generell eine Suche und eine Rotationsverzögerung, so dass das Lesen einer Datei, die aus vielen Blöcken besteht, langsamer sein wird. Normalerweise wird die Blockgrösse 512, 1K oder 2K Bytes gewählt. Wenn eine 1K Blockgrösse bei einer Platte mit einer Sektorgrösse von 512 Bytes gewählt wird, liest oder schreibt das Dateisystem immer zwei zusammenhängende Blöcke und behandelt diese als eine einzige, unteilbare Einheit. 9 / 22

10 4. Effizienz Der effiziente Gebrauch von Speicherplatz ist stark abhängig von der Allokation der Plattenblöcke. Zum Beispiel sind UNIX Inoden vorallokiert auf einer Partition. Sogar eine leere Disk hat einen Teil ihres Platzes an die Speicherung der Inoden verloren. Mit der Vorallokation der Inoden und der Verteilung dieser über die Partition, kann die Performance des Systems verbessert werden. Diese Verbesserung ist das Resultat der UNIX Allokation, welche den Datenblock einer Datei nahe an deren Inodenblock hält, um Suchzeit zu vermindern. 5. Performance Wenn einmal die grundlegenden Festplattenmethoden (Allokation) gewählt sind, dann gibt es immer noch verschiedene Wege, um die Performance zu steigern. Die meisten Disk Controllers beinhalten lokalen Speicher, um einen on-board Cache zu haben, der gross genug ist, um ganze Spuren aufs Mal zu lesen. Wenn eine Suche durchgeführt wird, so wird die Spur in den Festplatten Cache gespeichert beginnend beim Sektor unter dem Diskkopf. Der Diskkontroller verschiebt dann die Sektoranfrage zum Betriebssystem. Wenn Blöcke in den Hauptspeicher gelangen, dann werden sie vom Betribssystem dort gecached. Einige Systeme halten einen separaten Bereich reserviert für Disk Cache, wo Blöcke gespeichert werden unter der Annahme, dass sie häufig gebraucht werden. Dies ist besonders sinnvoll, wenn Teile einer Datenbank oder eine Datenbankabfrage häufig auftritt. UNIX zum Beispiel verwendet den nicht verwendeten physikalischen Speicher als Buffer Pool, welchen sich das Paging System und das Block Caching System teilen. Wenn das System viele Input / Output Operationen durchführt, wie bei einer Datenbank, so wird der meiste Speicher als Block Cache verwendet. Leider stellt sich ein Problem. Da man eine Situation erreicht hat, in der exaktes LRU, um Blöcke zu entfernen, möglich ist, stellt sich heraus, dass LRU nicht erstrebenswert ist. Das Problem liegt bei den Abstürzen und der Dateisystemkonsistenz. Falls ein kritischer Block, wie z.b. ein I-Node-Block, in den Cache gelesen und modifiziert, aber nicht auf die Festplatte zurückgeschrieben wurde, belässt ein Absturz das Dateisystem in einem inkonsistenten Zustand. Falls der I-Node-Block an das Ende der LRU-Kette gestellt wird, dauert es eine Weile, bis er den Anfang erreicht hat und wieder auf dir Festplatte geschrieben wird. Einige Blöcke, wie z.b. die doppelt indirekten Blöcke, werden selten zweimal innerhalb eines kurzen Intervalls referenziert. Diese Überlegungen führen zu einem modifizierten LRU-Schema, das zwei Faktoren berücksichtigt: Wird ein Block in nächster Zeit wieder benötigt? Ist der Block für die Konsistenz des Dateisystems bedeutsam? 10 / 22

11 Für beide Fragen können die Blöcke in Kategorien unterteilt werden, wie I-Node- Blöcke, indirekte Blöcke, Verzeichnisblöcke, volle Datenblöcke und teilweise gefüllte Datenblöcke. Blöcke, die wahrscheinlich sobald nicht wieder benötigt werden, können am Beginn der Kette positioniert werden und nicht an Ende der LRU-Liste, so dass deren Puffer so schnell wie möglich wieder benutzt werden. Blöcke, die öfter benutzt werden, wie ein teilweise gefüllter Datenblock, der beschrieben wird, werden am Ende der Liste positioniert, so dass sie eine längere Zeit in der Kette verbleiben. Die zweite Frage ist unabhängig von der ersten. Falls ein Block von grundlegender Bedeutung für die Konsistenz des Dateisystems ist (faktisch jeder, mit der Ausnahme der Datenblöcke), und verändert wurde, sollte er sofort auf die Platte zurückgeschrieben werden, unabhängig davon, an welcher Stelle er in der LRU-Liste eingelagert ist. Durch das sofortige Schreiben der kritischen Blöcke wird die Wahrscheinlichkeit der Zerstörung des Dateisystems durch einen Absturz reduziert. Die vorsichtige Wahl der Reihenfolge, in der kritische Blöcke abgespeichert werden, ist ebenso hilfreich. Mit dieser Annahme, die Dateisystemintegrität intakt zu halten, ist es nicht erstrebenswert, die Datenblöcke zu lange im Cache zu halten, bevor sie wieder zurückgeschrieben werden. Die Systeme wenden zwei Massnahmen dafür an. Die UNIX-Art ist die Bereitstellung eines Systemaufrufs, SYNC, der das sofortige Schreiben aller modifizierten Blöcke auf Platte forciert. Wenn das System gestartet wird, wird ein Programm, normalerweise update genannt, im Hintergrund gestartet, das in einer Endlosschleife sitzt und alle 30 Sekunden einen SYNC-Aufruf tätigt. Als Ergebnis wird nie mehr als die Arbeit von 30 Sekunden bei einem Absturz verlorengehen. Die MS- DOS-Art ist das Schreiben jedes modifizierten Blocks auf Platte, sobald er geschrieben wurde. Caches, in denen modifizierte Blöcke direkt auf die Platte zurückgeschrieben werden, werden Write-Through Caches genannt. Sie benötigen weitaus mehr Plattenein- und ausgabe als Nonwrite-Through Caches: Der Unterschied zwischen diesen beiden Massnahmen wird deutlich, wenn ein Programm einen 1K grossen Block vollschreibt, ein Zeichen nach dem anderen. UNIX sammelt alle Zeichen im Cache und schreibt den Block nur alle 30 Sekunden auf Platte, oder wenn der Block aus dem Cache entfernt wird. MS-DOS führt einen Plattenzugriff bei jedem geschriebenen Zeichen durch. Natürlich haben die meisten Programme eine interne Pufferung, so dass normalerweise nicht jedes Zeichen geschrieben wird, sondern eine Zeile oder eine grössere Einheit bei jedem Systemaufruf WRITE. Eine Konsequenz der Unterschiede in der Caching-Strategie ist, dass bei einem Entfernen einer Platte (Diskette) aus einem UNIx-System ohne Durchführung eines SYNC, fast immer Daten verloren gehen und häufig auch ein defektes Dateisystem zurückbleibt. Mit MS-DOS treten diese Probleme nicht auf. Diese unterschiedlichen Strategien wurden gewählt, da UNIX in einer Umgebung entwickelt wurde, in der alle Laufwerke Festplatten waren und somit nicht entfernbar, wohingegen MS-DOS in einer Welt von Disketten entstand. Da Festplatten zur Norm werden, auch auf kleinen Mikrocomputern, wird die UNIX-Variante mit der besseren Effizienz definitiv der zu gehende Weg sein. 11 / 22

12 6. Zuverlässigkeit des Dateisystems Wenn ein Dateisystems zerstört wird, ist dies meistens ein grösseres Desaster als wenn nur ein Rechner zerstört wird. Falls ein Rechner durch Feuer, Spannungsspitzen oder Wasserschaden zerstört wird, ist es ärgerlich und kostet Geld, aber generell kann die Ersetzung mit einem Minimum an Ärgernis bezahlt werden. Die Datenbank könnte von Band wieder geladen werden, nachdem der zerstörte Server, auf dem die Datenbank installiert war, ersetzt wurde. Falls das Dateisystem des Rechners unwiderruflich verloren ist, entweder durch die Hardware, Software oder das Anknabbern der Disketten durch Ratten, ist die Restauration der Information schwierig, zeitaufwendig und in vielen Fällen unmöglich. Ohne ein Backup der Datenbank sind die Informationen für immer verloren. Für z.b. eine Unternehmung, Datenbanken oder andere Daten für immer verloren sind, kann die Konsequenz katastrophal sein. Wenn das Dateisystem auch keinerlei Schutz gegenüber physikalischer Zerstörung des Equipments und des Mediums bietet, so kann es doch helfen, die Informationen zu schützen. Fehlerblockverwaltung, Backups und Methoden zur Dateisystemkonsistenzüberprüfung dienen dazu, ein Dateisystem zu retten. 6.1 Fehlerblockverwaltung Platten können fehlerhafte Blöcke enthalten. Disketten sind normalerweise perfekt, wenn sie die Fabrik verlassen, aber sie können fehlerhafte Blöcke während ihres Einsatzes bekommen. Winchesterplatten (Festplatten) haben häufig von Anfang an fehlerhafte Blöcke: es ist einfach zu teuer, sie komplett ohne Defekte zu produzieren. Tatsächlich legen die meisten Festplattenhersteller jeder Platte eine Liste von fehlerhaften Blöcken bei, die durch ihre Tests ermittelt wurden. Je eine Hardware- und eine Softwarelösung werden eingesetzt, um das Problem der fehlerhaften Blöcke zu lösen: Hardwarelösung: Hier wird ein Sektor verwendet, um die fehlerhaften Blöcke aufzulisten. Wenn der Controller dann initialisiert wird, liest er die Liste der fehlerhaften Blöcke und nimmt einen ausgesparten Block (oder Spur), um fehlerhafte zu ersetzen, wobei die Ersetzung in der Liste der fehlerhaften Blöcke notiert wird. Somit benutzen alle Anfragen auf den fehlerhaften Block den ausgesparten. Softwarelösung: Diese benutzt das Benutzer- oder Dateisystem, um vorsichtig eine Datei zu konstruieren, die alle fehlerhaften Blöcke enthält. Diese Technik entfernt die Blöcke aus der Freiliste, so dass sie niemals mehr für Datendateien benutzt werden. Solange die Datei mit den fehlerhaften Blöcken nicht gelesen oder beschrieben wird, treten keine Probleme auf. Vorsicht ist jedoch während Plattenbackups geboten, um das Lesen dieser Datei zu vermeiden. 12 / 22

13 7. Backups und Wiederherstellung Wie schon in den vorhergehenden Kapiteln angesprochen, ist es dennoch wichtig - trotz der Strategie im Umgang mit fehlerhaften Blöcken die Dateien regelmässig zu sichern. Weil bei magnetischen Disks manchmal Fehler auftreten oder Diskcrashes auf Festplatten auftreten, muss Vorsicht geboten werden, dass Daten nicht für immer verloren gehen. Dateisysteme auf Disketten können gesichert werden, indem die gesamte Diskette auf eine leere Diskette kopiert wird. Dateisysteme auf kleinen Winchesterplatten sichert man durch das Aufspielen der gesamten Platte auf Magnetbänder, industrielle 9-Spur Standardbänder (welche bis zu 50M pro Bandspur aufnehmen), Streamer-Bänder (welche in verschiedenen Grössen angeboten werden) oder auf 8mm Videoband. Bei grossen Platten, worauf z.b. grosse Datenbanken abgespeichert sind, ist die Sicherung der gesamten Platte auf Band schwierig und zeitaufwendig. Eine Strategie, die leicht zu implementieren ist, aber die Hälfte des Speichers verschwendet, ist die Ausstattung des Rechners mit zwei Laufwerken anstatt nur einem. Beide Laufwerke werden in zwei Hälften geteilt: Daten und Sicherungskopie. Jede Nacht wird dann die Datenhälfte von Laufwerk 1 auf die Sicherungshälfte von Laufwerk 2 kopiert, und umgekehrt. Bei dieser Art geht, sofern nur ein Laufwerk komplett ruiniert ist, keine Information verloren. Damit nicht das gesamten Dateisystem gespeichert werden muss, werden inkrementellen Speicherauszügen eingesetzt. Die einfachste Form des inkrementellen Speicherauszuges ist die periodische Durchführung eines kompletten Auszuges, sprich wöchentlich oder monatlich, und die Durchführung eines täglichen Auszuges, wobei nur die Dateien aufgenommen werden oder Teile von Dateien, die sich seit dem letzten grossen Auszug verändert haben. Um diese Methode zu implementieren, muss eine Liste der Auszugszeiten für jede Datei auf Platte verwaltet werden. Das Sicherungsprogramm überprüft dann jede Datei. Falls sie seit der letzten Sicherung verändert wurde, wird sie erneut gesichert und die Zeit der letzten Sicherung wird auf die aktuelle Zeit gesetzt. Wenn dies in einem Monatszyklus durchgeführt wird, benötigt die Methode 31 Auszugsbänder für den täglichen Auszug, eins pro Tag, plus genügend weitere Bänder, um den kompletten Speicherauszug zu halten, der einmal im Monat erfolgt. Weitere komplexe Schemata, die weniger Bänder brauchen, sind ebenfalls im Einsatz. In MS-DOS werden einige Unterstützungen zur Durchführung von Backups angeboten. Verbunden mit jeder Datei ist ein Attributbit, genannt das Archivbit. Wenn ein Dateisystem gesichert wird, werden die Archivbits aller Dateien zurückgesetzt. Wenn eine Datei verändert wird, setzt das Betriebssystem automatisch das Archivbit. Zum Zeitpunkt des nächsten Backups überprüft das Sicherungsprogramm alle Archivbits und sichert nur die Dateien, deren Bit gesetzt ist. Es löscht ebenfalls alle diese Bits, um eine spätere Benutzung der Dateien erkennen zu lassen. 13 / 22

14 Ein typisches Backup Scheduling könnte so aussehen: Tag 1: Tag 2: Tag 3:... Tag N: Kopie auf ein Backup Medium - wie z.b. ein Magnetband - aller Dateien. Dies ist ein kompletter Backup. Kopieren aller geänderten Dateien seit Tag 1 auf ein anderes Band. Kopieren aller sein Tag 2 geänderten Dateien wiederum auf ein anderes Band Kopieren aller geänderter Dateien seit dem Tag N-1. Dann fängt man wiederum bei Tag 1 an. In der Praxis geht ein solcher Zyklus meistens 1 Woche, d.h. man hält pro Tag ein Band, welches täglich gewechselt wird. Wird eine Datenbank laufend erweitert, so wird meistens die gesamte Datenbank während der Nacht, wenn niemand darauf zugreift auf ein Band abgelegt. Da heutige Bänder mehrere 100 GB an Daten speichern können, ist ein ablegen der gesamten Datenbank möglich. Probleme ergeben sich für Datenbanken, welche rund um die Uhr genutzt werden, wie z.b. Flugreservierungsdatenbanken, auf welche weltweit zu jeder Zeit ein Zugriff erfolgen kann. Als Folge dessen ist ebenso die Grösse der Datenbank ein Problem, da wegen Zeitmangels nicht die gesamte Datenbank auf ein Band gesichert werden kann. Es ist nicht akzeptabel, dass während einer bestimmten Zeit der Zugriff auf die Datenbank nicht erfolgen kann. Häufig werden Datenbanken auf eine parallel laufende Festplatte gespiegelt, damit falls eine Platte ausfallen sollte, immer noch mit der anderen weitergearbeitet werden könnte. Die defekte kann dann ausgewechselt werden und die Datenbank wird automatisch von neuem gespiegelt. Ein schlimmer Fall wäre es natürlich, wenn beide gleichzeitig ausfallen würden. Für diesen ziemlich unwahrscheinlichen Fall müsste dann auf die Bänder zurückgegriffen werden. Zur weiteren Sicherheit ist es ebenfalls üblich, dass ein Band (z.b. einmal pro Woche) feuerfest in einen Safe abgelegt wird, falls der Server mit der Datenbank in einem Feuer zerstört würde. 8. Dateisystemkonsistenz Da Dateien im Hauptspeicher und auf Festplatten gespeichert sind, muss darauf geachtet werden, dass ein Systemfehler nicht den Verlust oder die Inkonsistenz der Daten bedeutet. Die Konsistenz des Dateisystems ist ein weiterer Bereich, in dem Zuverlässigkeit gefordert ist. Viele Dateisysteme lesen Blöcke, verändern diese und schreiben sie später wieder zurück. Falls das System vor der Abspeicherung aller modifizierten Blöcke zusammenbricht, kann das Dateisystem in einem inkonsistenten Zustand 14 / 22

15 landen. Dieses Problem wird besonders kritisch, wenn die nicht zurückgeschriebenen Blöcke I-Node-Blöcke, Verzeichnisblöcke oder Blöcke der Freiliste sind. Damit das Problem der Inkonsistenz eines Dateisystems nicht auftritt, besitzen die meisten Rechner ein Hilfsprogramm, das die Konsistenz des Dateisystems prüft, Es kann immer durchlaufen werden, nachdem das System hochgefahren wurde, insbesondere nach einem Absturz. Diese Dateisystemüberprüfer verifizieren jedes Dateisystem (Platte) unabhängig von anderen Dateisystemen. 9. Sicherheit Vor allem im Zusammenhang mit dem Dateisystem spielen Sicherheitsaspekte eine wichtige Rolle. Sicherheit ist allerdings ein facettenreicher Begriff, dazu gehören Massnahmen zum Schutz vor Datenverlust genauso wie Abschirmung gegen unerwünschtes Ausspionieren oder gar Sabotieren der Datenbestände. Ursachen für Datenverluste gibt es viele, von Fehlbedienungen über Hard- und Softwarefehler bis hin zur Zerstörung von Speicherungsmedien durch Feuer oder hungrige Nagetiere. Gegen Datenverluste hilft nur eine gute Sicherungsstrategie. Gegen unerlaubten Zugriff auf Daten muss das Dateisystem entsprechende Mechanismen enthalten. 9.1 Identifikation und Authentifikation Die Identifikation und Authentifikation ist insofern nötig, dass nur berechtigte Personen auf ein Dateisystem zugreifen dürfen, welche auch Daten von der Datenbank lesen dürfen. Beim Login in einem Mehrbenutzersystem identifziert sich der Benutzer mit einem eindeutigen Benutzernamen. Aus seiner Identifikation werden dann die Rechte zum Zugriff auf Daten abgeleitet. Diese Rechte können direkt an die Identifikation gebunden sein, oder z.b. über Gruppenzugehörigkeiten des Benutzers indirekt über die Gruppenrechte. Damit nicht jemand ohne Erlaubnis eine fremde Identifikation angeben kann, wird die Identifikation überprüft. Eine übliche Methode ist die Abfrage eines geheimen Passworts, auch die Analyse von eindeutigen biologischen Merkmalen (Mustererkennung für Fingerabdrücke, Pupillen, Stimmfrequenz usw.) wird schon stellenweise genutzt. Diese Überprüfung der Identität heisst Authentifzierung. Ein Trend moderner Betriebssysteme (z.b. moderne UNIX-Systeme, Windows NT) sind frei austauschbare Authentifikationsmodule. Während früher die Authentifikation ein "fest verdrahteter Algorithmus war, kann nun der Rechnerbetreiber abhängig von seinen Sicherheitsanforderungen zwischen unterschiedlichen Authentifikationsmethoden wählen. 15 / 22

16 9.2 Zugriffsdomänen, Capabilities, ACLs Ein System verwaltet Objekte, die geschützt werden müssen (Hardware, Speichersegmente, Dateien u.a.). Jedes Objekt hat eine Reihe von Zugriffsoperationen, z.b. Lesen, Modifizieren, Löschen. Eine Zugriffsdomäne ist eine Menge von Paaren der Form (Objekt, erlaubte Operation). Zu jedem Prozess gehört eine Zugriffsdomäne, die genau definiert, welche Objekte der Prozess in welcher Weise verarbeiten darf. Ein Objekt kann gleichzeitig mehreren Zugriffsdomänen angehören. Beispiel: Bei UNIX oder NT ist die Zugriffsdomäne eines Prozesses durch seine Benutzeridentifikation und Gruppenzugehörigkeit exakt definiert. Es wäre möglich, eine komplette Liste aller Geräte und Dateien aufzustellen, die der Prozess verarbeiten darf, zusammen mit der Information über die Art der erlaubten Operationen. (NT nennt die Datenstruktur mit Benutzeridentifikation und Gruppenzugehörigkeit access token ). Man beachte, dass mit einem Systemaufruf ein Domänenwechsel verbunden ist: innerhalb des Systemkerns hat der Prozess erweiterte Rechte. Andere Betriebssysteme haben komplexere Zugriffsdomänenkonzepte. In einer Zugriffsrechtsmatrix könnte man zu jedem Objekt und jeder Zugriffsdomäne die erlaubten Operationen angeben, z.b: Objekt Domäne Datei A Datei B Datei C Drucker ISDN 1 read, write write read, write 2 read, execute write write 3 read, execute read read, write Die Speicherung der Zugriffsrechtsmatrix ist in der Regel nicht sinnvoll bzw. nicht praktikabel, da sie sehr gross und nur dünn besetzt ist. Wenn man nach einer Technik zur kompakten Abspeicherung sucht, kann man zeilenoder spaltenorientiert vorgehen. Zeilenorientierte Speicherung bedeutet, dass eine Zugriffsdomäne explizit als Datenstruktur angelegt wird, also eine jeweils Liste von Paaren (Objekt, Operationen). Man nennt diese Listen "Capability-Listen und einen Eintrag "Capability. Capability-Listen müssen gegenüber dem Benutzerprozess gegen unerlaubte Modifikation geschützt werden, damit dieser sich nicht durch Erweiterung Rechte verschafft, die ihm nicht zustehen. Dazu müssen sie im Betriebssystemadressraum gehalten (Hydra), mit kryptographischen Methoden geschützt werden (Amöba) oder mit spezieller Hardware unterstützt werden, die Capability-Objekte von modifizierbaren Objekten unterscheidet. Spaltenorientierte Speicherung bedeutet, dass zu jedem Objekt eine Liste von Paaren (Zugriffsdomäne, Operationen) angelegt wird. Man nennt eine solche Liste Zugriffskontrollliste ("access control list ) oder kurz ACL. 16 / 22

17 Windows NT verwendet beispielsweise ACLs. Jedes Objekt besitzt einen Zugriffskontrolldeskriptor mit einer ACL. Jeder ACL-Eintrag besteht aus einem Eintragsmerkmal "erlaubt / verboten, einem Benutzer- oder Gruppennamen und einer Reihe von (erlaubten/verbotenen) Zugriffsoperation. Die Zugriffsverbote stehen am Anfang der Liste. "Wildcards für die Operationen sind möglich. Windows NT Beispiel-ACL: Typ Identifikation Rechte verbiete profs Daten lesen, Daten schreiben verbiete Meier * erlaube WORLD Datei ausführen erlaube Müller Daten lesen Die UNIX Dateizugriffsrechte kann man als eine stark vereinfachte ACL- Implementierung auffassen. Statt die individuelle Zusammenstellung von Zugriffsdomänen und Rechten zu erlauben, wird nur eine grobe Klassifikation der Zugriffsdomänen unterstützt: Objekteigentümer, Gruppenmitglieder, Sonstige. Dies ist viel einfacher zu implementieren und reicht in der Praxis meist aus. Eine Erweiterung auf richtige ACLs wäre aus heutiger Sicht sicher sinnvoll, ist aber aus Kompatibilitätsgründen problematisch. Bei vielen modernen UNIX-Varianten (inkl. Linux) sind ACLs schon seit Jahren implementiert, genutzt werden sie in der Regel nicht. 11. Beispiel Filesysteme für Oracle Datenbank Bei der praktischen Aufsetzung einer Datenbank muss man sich darüber Gedanken machen, ob lokale Filesysteme, Netzwerk Filesysteme oder RAW Devices verwendet werden. Bei der Wahl muss man die vorgehenden Betrachtungen der Anforderungen berücksichtigen. Hier eine Übersicht über die gängigsten Filesysteme: Lokale Filesysteme Betriebssystem Filesystem Eigenschaften Linux: ext2 performant, geringe Fragmentierung, Check nach Absturz ReiserFS Journaling, gewichtete Bäume, kleine Dateien in einem Block Solaris: UFS performant, readahead für sequentielles Lesen, Blockgrösse wählbar vxfs dateigrössenbasiert -> sehr schnelles Lesen, starke 17 / 22

18 Fragmentierung WinNT/2000/XP: NTFS4.0/5.0 performant, (Journaling, Verschlüsselung 5.0), Fragmentierung FAT32 Erweiterung von FAT16 lange Dateinamen, >2GB, instabil Netzwerk Filesysteme NFS - Network File System für UNIX Ressourcen SMB - Server Message Blocks für Windows Ressourcen RAW Devices freie Partitionen auf der Festplatte ohne Filesystem 11.1 Wahl des Filesystems Theoretisch ist ein beliebiges Filesystem verwendbar, da die Verwaltungsaufgaben an das Betriebssystem abgegeben werden. Die Vor- und Nachteile der einzelnen Filesysteme sind bei der Einrichtung des Systems zu beachten, wie zuvor betrachtet etwa die Stabilität, die Performance und die Features RAW Devices Mittels RAW Devices ist ein direkter Zugriff auf das Gerät über Gerätetreiber möglich und hat keinen Einfluss auf die Daten durch das Betriebssystem, d.h. dass die Verwaltung der Daten und Blöcke durch die Anwendung geschieht. Das Oracle-DBMS bringt in der Regel seinen eigenen Buffermechanismus beim Zugriff auf Datendateien mit. Da es mehr über sein IO-Verhalten weiss als ein darunter liegendes Betriebssystem, kann es in der Regel immer effizienter arbeiten als dieses. Deshalb ist es sinnvoll, mit Raw Devices den Buffer des Betriebssystems zu umgehen. Bei Clustern mit dem Oracle Parallel Server sind Raw Devices unverzichtbar. Als Beispiel würden sich dann mehrere Linux-Rechner eine Festplatte teilen, und ein Buffering würde dazu führen, dass ein Rechner auf die gemeinsame Platte schreibt, während die anderen noch mit alten Daten in ihrem Buffer arbeiten würden. Für Linux sind Raw Devices ab Kernel 2.4 verfügbar, für die 2.2er Kernel existiert ein Patch, das beispielsweise Red Hat integriert hat. So legt man ein Raw Device an: raw /dev/raw/raw1 /dev/sdc2 chown oracle.dba /dev/raw/raw1 18 / 22

19 Bei der Benennung von Datendateien unter Oracle gibt man anschliessend nur den Pfad auf das Raw Device an. Um den Inhalt des Raw Devices für Backups zu kopieren, braucht man allerdings eine neuere Version des dd. Sonst erhält man die Fehlermeldung Invalid Argument. Red Hat 6.2 kommt bereits mit einer angepassten dd-version, da es schon Raw Devices im 2.2er Kernel unterstützt. Wer Raw Devices verwendet, ist bei der Grösse von Tablespaces an die Grösse von zuvor angelegten Partitionen gebunden. Oft weiss man aber nicht, wie viel Platz ein Tablespace im Laufe der Zeit belegen wird. Mit dem ebenfalls ab Kernel 2.4 verfügbaren Logical Volume Management kann man diesen Nachteil wieder wettmachen. Das Konzept von LVM ist es, die bisherigen Partitionen - jetzt Physical Volumes genannt - zu einer Volume Group zusammenzufassen und diese anschliessend in Logical Volumes aufzuteilen, die nachträglich in der Grösse verändert werden können. Partitionen, die man als Physical Volumes für LVM verwendet, müssen den Typ hexadezimal 8E haben. Ist dieser mit fdisk gesetzt, kann man ein Logical Volume mit vgscan pvcreate /dev/sdb1 vgcreate odata /dev/sdb1 lvcreate -L1m -nuser odata anlegen und darauf ein Raw Device einrichten: raw /dev/raw/raw1 /dev/odata/user 11.3 Verwaltung der Daten einer Datenbank durch Oracle Es gibt vier verschiedene Dateitypen: Initialisierungsdatei: In dieser Textdatei stehen Initialisierungsparameter wie die verwendete Blockgrösse, Buffergrösse oder der Pfad des Controlfiles. Standardmässig suchen einige Oracle-Tools nach einer Datei namens ${ORACLE _HOME}/dbs/init${ORACLE_SID}.ora, sonst muss man den Pfad der Datei von Hand übergeben. Kontrolldatei: Hier sind unter anderem die Namen aller übrigen Dateien vermerkt. Sicherheitshalber ist die Kontrolldatei spiegelbar. Datendatei: Hier legt Oracle die eigentlichen Daten der Datenbank ab. Jede Datendatei ist einem Tablespace zugeordnet und kann, da Oracle noch nicht den Large File Support unterstützt, maximal 2 GByte gross sein. Ein Tablespace nimmt Datenbankobjekte wie Tabellen-Indizes oder BLOBs auf. Er kann auch aus mehreren Dateien bestehen, doch das macht nur dann Sinn, wenn diese auf unterschiedlichen Platten liegen, da Oracle abwechselnd auf sie zugreift, um ein RAID0 zu simulieren. Oracle empfiehlt mehrere Tablespaces anzulegen, um die Verfügbarkeit der Datenbank zu erhöhen. So kann man beispielsweise einen Tablespace im laufenden Betrieb offline setzen und recovern, während die anderen Tablespaces verfügbar bleiben. 19 / 22

20 Redologs: Von diesem Typ braucht man mindestens zwei Dateien, da sie von Oracle rotiert werden. Für die Performance sind sie wichtig, weil Oracle alle Änderungen hier zunächst in kurzer Form notiert, noch bevor sie in den Datendateien landen. Ausserdem spielen sie eine wichtige Rolle beim Backup und Recovery. Sie können von Oracle gespiegelt und auch archiviert werden RAW Device oder Filesystem? Eine Entscheidung für ein Filesystem oder RAW Device wird von verschiedenen Faktoren beeinflusst. Erstens hängt es von der Art der Datei ab: Ist das Archiv-Log nur auf dem Filesystem, so ist die Verwendung von RAW Device ausgeschlossen. Weiter ist die vorrangige I/O Operation von Bedeutung. Ist die Operation vorwiegend write, so ist für RAW Device zu entscheiden wegen der Redo-Log Datei. Ist die Operation wahlfrei oder vorwiegend read, so kommt eher ein Filesystem in Frage, wegen den statischen Tabellen. Ein weiterer Punkt sind die überhaupt zur Verfügung stehenden Filesysteme, dann die Performance SQL-Anweisungen zur Verwaltung der Datenfiles Anlegen oder ändern der Datenfiles mit CREATE/ALTER CREATE TABLESPACE mein_erstes_tablespace DATAFILE /usr/oracle/db/testdb/datafile1.dbf SIZE 1000M DEFAULT STORAGE ( INITIAL 20M NEXT 10M MINEXTENTS 3 MAXEXTENTS 20 PCTINCREASE 15) ONLINE; Abfrage von Informationen über Datenfiles: SELECT * FROM user_tablespaces; 11.6 Festlegen von Filesystem oder RAW Device Aus der Pfadangabe ist es nicht immer erkennbar, ob es sich um ein Filesystem oder um RAW Device handelt. Bei der Verwendung des Filesystems verweist der Pfad auf eine normale Datei und bei der Verwendung von RAW Device verweist der Pfad auf ein Gerät oder auf einen Link, welcher auf ein Gerät verweist. Voraussetzung für die Verwendung eines RAW Devices 20 / 22

21 freie Partition auf dem Speichermedium volle Zugriffsrechte für Oracle Server User ($ chown oracle /dev/hdb2) ausschliessliche Rechte für Oracle Server User ($ chmod 600 /dev/hdb2) Anlegen eines symbolischen Links auf das Gerät im Oracle Verzeichnis 21 / 22

22 12. Literaturverzeichnis A. Tanenbaum: Modern Operating Systems Prentice-Hall (2. Auflage 1995) A. Silberschatz, P.B. Galvin: Operating Systems Concepts Addison-Wesley (5. Auflage 1998) Hans-Jürgen Siegert, Uwe Baumgarten: Betriebssysteme Oldenbourg Michael J. Folk, Bill Zoellick: File Structures, A Conceptual Toolkit Addison-Wesley (1987) Michael J. Folk, Bill Zoellick, Greg Riccardi: File Structures: An Object-Oriented Approach with C++ Addison-Wesley (1998) Rüdiger Brause: Betriebssysteme: Grundlagen und Konzepte Springer (2. Auflage 2001) Wolfgang Laun: Konzepte der Betriebssysteme (1989) 22 / 22