Vorwort. Andrea Held, Mirko Hotzy, Lutz Fröhlich, Marek Adar, Christian Antognini, Konrad Häfeli, Daniel Steiger, Sven Vetter, Peter Welker

Transkript

1 Vorwort Andrea Held, Mirko Hotzy, Lutz Fröhlich, Marek Adar, Christian Antognini, Konrad Häfeli, Daniel Steiger, Sven Vetter, Peter Welker Der Oracle-DBA Handbuch für die Administration der Oracle Database 11g R2 ISBN: Weitere Informationen oder Bestellungen unter sowie im Buchhandel. Carl Hanser Verlag, München

2 Vorwort Vorwort Mit der Version 11g Release 2 hat Oracle eine Version auf den Markt gebracht, in der einerseits viele neue Features integriert wurden und andererseits ein hoher Standard in den Bereichen Stabilität, Performance und Sicherheit gesetzt wurde. Eine Herausforderung für alle, die mit Oracle-Datenbanken arbeiten, ist es, die zunehmende Komplexität des Datenbanksystems zu beherrschen sowie die am besten geeigneten Features zu kennen und fachgerecht umzusetzen. Für dieses DBA-Handbuch, das in Zusammenarbeit mit der Deutschen ORACLE-Anwendergruppe (DOAG) entstanden ist, haben sich namhafte, praxiserfahrene Autoren zusammengefunden, die in den jeweiligen Kapiteln ihre Spezialgebiete darstellen. Einhundertvierunddreißig (in Ziffern 134) Jahre Oracle-Erfahrung sind darin eingeflossen! Und genau das ist es, was das Buch so einzigartig macht und wodurch es von anderen Oracle-Büchern unterscheidet. Wir, die Autoren, haben dabei nicht nur die langjährige Erfahrung gemeinsam, sondern teilen auch die Leidenschaft, Oracle-Datenbanken in der täglichen Praxis zu betreuen, weiter zu entwickeln und Probleme zu lösen. Diese Erfahrung möchten wir an Sie, lieber Leser, weitergeben. Sie finden neben einer Darstellung der Produkte und Features viele Beispiele, Praxistipps und Tricks, die Sie direkt in Ihre tägliche Arbeit integrieren können und die über Versionsgrenzen hinweg angewandt werden können. Mehr als drei Jahre sind seit der Erstellung des ersten Konzeptes für dieses Buch vergangen. Seit dem Start des Buchprojektes sind Monate voller Arbeit, Diskussionen und Geduldsproben, aber auch voller Spannung, Spaß und Freude vergangen. Ein solches Buch zu schreiben erfordert viel, nicht nur von den Autoren selbst, auch von deren Angehörigen Freunden und manchmal sogar von den Arbeitskollegen. Am Ende des Projekts können wir sagen, der Aufwand hat sich gelohnt. Wir wünschen Ihnen viel Spaß bei der Lektüre und vor allem praktische Hilfe für Ihre tägliche Arbeit! Marek Adar, Chris Antognini, Lutz Fröhlich, Konrad Häfeli, Andrea Held, Mirko Hotzy, Daniel Steiger, Sven Vetter, Peter Welker XXI

3 Vorwort Bei Fragen zu den hier behandelten Themen gibt es darüber hinaus die Möglichkeit, die Autoren über oder einen ihrer Blogs zu kontaktieren: (für die Trivadis-Autoren) Danksagung Wir danken vor allem dem Hanser Verlag, insbesondere Frau Metzger für ihre unendliche Geduld und ihren Glauben an den Erfolg des Buches. Andrea Held Ich möchte meinen größten Schätzen danken: Dem wunderbarsten Mann, den ich kenne, Hannes, und unserer wundervollen Tochter Sophie. Meinem Vater Herbert Held und meiner Schwester Erika Knobling bin ich sehr verbunden für ihre mentale Unterstützung und ihr Vertrauen in mich. Desiree Rorem und Birgit Pletzinger danke ich für die interessanten Diskussionen und für ihre Geduld mit mir. Hervorzuheben ist auch Margarete Metzger, unsere Lektorin, die von Entwurf zu Entwurf stets viel Geduld mit uns hatte. Danke an Stefan Kinkel, Lorenz Wack, Astrid Ringler, Oliver Spenkoch und Dr. Wolfgang Theobald für Korrekturen und Anmerkungen bei der Durchsicht des Skriptes. Mirko Hotzy Ich danke vor allem meiner Familie, die großes Verständnis für dieses Projekt entgegengebracht hat und dabei leider immer wieder zu kurz kam. Danken möchte ich auch der Trivadis, insbesondere der Niederlassung Stuttgart, die mir den nötigen Freiraum für dieses doch sehr umfangreiche Projekt gewährte. Lutz Fröhlich Ich danke allen, die zum Gelingen des Buches beigetragen haben, insbesondere dem Hanser Verlag mit Margarete Metzger und ihrem gesamten Team sowie allen, die etwas länger als gewohnt auf meine Antworten warten mussten. Marek Adar Ich danke meiner Frau Gaby und meinen tollen Kindern Deborah, Ilan und Julian, die immer vollstes Verständnis haben, wenn sie bei derartigen Projekten leider wieder zu kurz kommen. Und auch Andrea Held, die mich gebeten hat, zu diesem Projekt einen Beitrag beizusteuern. Konrad Häfeli Mein Dank geht an Claudia, Michelle und Joelle. Trivadis Autoren Wir danken der Firma Trivadis für die tolle und anhaltende Unterstützung. Der Glaube an dieses Buchprojekt war immer da. Besonders gefreut haben wir uns, dass uns als Autoren sehr großes Vertrauen entgegengebracht wurde und dass die Trivadis bereit war, doch erheblich in dieses Buchprojekt zu investieren. Es macht uns wirklich sehr viel Spaß, für die Trivadis zu arbeiten! XXII

4 Vorwort Im Internet Auf haben wir einige Zusatzmaterialien zu diesem Buch für Sie zusammengestellt. Sie finden dort nicht nur die nützlichen Skripte des Buches, sondern auch wichtige Informationen, ideal aufbereitet zum Nachschlagen: sqlplus-kommandos, Datentypen, v$ views, Dictionary-Tabellen, DB-Parameter und einiges mehr. XXIII

5 erscheint im Frühjahr 2011 Leseprobe (Vorabversion vom November 2010) 2011 Carl Hanser Verlag München ISBN

6 3 3 Speicherplatzverwaltung von Christian Antognini, Principal Consultant, Trivadis GmbH In diesem Kapitel gehen wir folgenden Fragen nach: Wie sind die grundlegenden Speicherstrukturen einer Oracle Datenbank aufgebaut? Wie werden damit die unterschiedlichen Segmenttypen verwaltet? Welches sind die Vor- und Nachteile der verschiedenen Verwaltungsmethoden? Welche Reorganisationsmethoden stellt Oracle zur Verfügung? 3.1 Einleitung In einer Oracle Datenbank sind Objekte, die Daten beinhalten (z.b. Tabellen und Indexe) nicht direkt in Files auf Betriebssystemebene gespeichert, sondern logischen Strukturen zugeordnet, die ihrerseits in physischen Strukturen abgelegt sind. Ziel dieser Architektur ist die klare Trennung des logischen Designs von der physischen Implementierung. Abbildung 3.1 zeigt eine Übersicht der Speicherstrukturen und deren Beziehung zueinander. Eine Datenbank besteht aus mehreren Tablespaces. Datenbank und Tablespaces sind lediglich logische Strukturen, die Objekte bzw. Segmente beinhalten. Man kann sie auch als eine Art Container betrachten. Aus Sicht der Speicherung unterscheidet man vier Objekttypen: Objekte, die keine Daten und demzufolge auch keine Segmente beinhalten. Eine View ist beispielsweise eine logische Struktur, die nur im Data Dictionary definiert ist Objekte, die aus einem einzigen Segment bestehen, z.b. eine nichtpartitionierte Heap- Tabelle Objekte, die aus mehreren Segmenten bestehen. Eine partitionierte Tabelle hat z.b. ein Segmente pro Partition Objekte, die ein Segment mit einem anderen Objekt teilen, z.b. Cluster-Tabellen. Jeder Tablespace besteht aus einem oder mehreren Files, die aus einer bestimmten Anzahl Blöcke bestehen. Blöcke sind die kleinsten Strukturen, die die Datenbank speichertechnisch 1

7 3 Speicherplatzverwaltung logische Struktur Datenbank Objekt Tablespace Segment File Extent Block physiche Struktur Abbildung 3.1 Übersicht der Datenbank-Speicherstrukturen verwaltet. Über mehrere Files pro Tablespace verhindert man Einschränkungen, die durch die Database-Engine, das Betriebssystem oder die Hardware bezüglich der maximalen Filegröße entstehen können. Jedes File ist in Einheiten von zusammenhängenden Blöcken, den sogenannten Extents, unterteilt. Jedes Extent ist genau einem einzigen Segment zugeordnet. In den folgenden Abschnitten beschreiben wir die Möglichkeiten der Datenbankfile-Speicherung und wie man die erwähnten logischen und physischen Speicherstrukturen verwaltet. 3.2 Datenbank-Speicheroptionen Oracle unterstützt die unterschiedlichsten Speicherarchitekturen. Im einfachsten Fall werden die Disks direkt an den Datenbankserver angeschlossen. Man spricht dann von Direct Attached Storage (DAS). Weitaus häufiger wird auf die Disks in den heutigen Rechenzentren jedoch über ein Netzwerk zugegriffen. Dabei kommen hauptsächlich zwei Architekturen zum Einsatz: Storage Area Networks (SAN) und Network Attached Storage (NAS). Ein SAN verfügt über einen Management Layer und über ein spezielles Netzwerk, das die physische Verbindung zu den Disks sicherstellt. Die NAS-Architektur verwendet spezielle Fileserver, die für Speicherlösungen über ein lokales Netzwerk (LAN) geeignet sind. Die DAS- und SAN-Architekturen erlauben Block-I/O-Zugriff, während NAS-Server den Zugriff über File-I/O ermöglichen. Oracle nutzt für die Verwaltung der Datenbankfiles die betriebssystemseitigen Möglichkeiten. Dies hat aus Sicht der Datenbankadministration den Vorteil, dass die eingesetzte Speicherarchitektur die Fileverwaltung auf Datenbankebene nicht beeinflusst. Aus diesem Grund gehen wir an dieser Stelle nicht tiefer auf die erwähnten Architekturen ein und konzentrieren uns auf die Anforderungen, die ein Speichersubsystem aus Datenbanksicht 2

8 3.2 Datenbank-Speicheroptionen erfüllen muss. Wir betrachten insbesondere, wie diese Anforderungen mit den drei grundlegenden Methoden erfüllt werden, die Oracle für die Speicherung von Datenbankfiles verwendet: Filesysteme, Raw-Devices und Automatic Storage Management (ASM). Abgerundet wird dieses Kapitel mit Empfehlungen für die Auswahl von Datenbank-Speichersystemen Eigenschaften eines Speichersystems Ein zuverlässiges Speichersystem ist für die dauerhafte Speicherung von Datenbankfiles unabdingbar. Die Hauptanforderungen an ein Speichersystem sind: Verwaltung: Einfache und flexible Verwaltung der Disks Verfügbarkeit: Schutz gegen Hard- und Softwarefehler Performance: Erforderlichen Durchsatz und Anzahl I/O-Operationen pro Sekunde Zugriff: Gemeinsamer Zugriff auf die gleichen Disks von mehreren Servern aus in einer Clusterumgebung Bestimmte Anforderungen widersprechen jedoch einander. So existiert beispielsweise oft ein Konflikt zwischen einfacher, flexibler Verwaltung und hoher Performance. Im Falle des gleichzeitigen Zugriffs ist die Anforderung bei bestimmten Systemen gar nicht relevant. Es ist deshalb für die Wahl eines Speichersystems entscheidend, die Features entsprechend zu gewichten Verwaltung Operationen wie Hinzufügen, Entfernen oder Ersetzen einer Disk sollten einfach und unterbrechungsfrei ohne Stoppen der Datenbankinstanz möglich sein, im Idealfall sogar ohne Auswirkungen auf die Datenbankinstanz auch wenn auf den betroffenen Disks bereits Teile der Datenbank gespeichert sind. Wenn eine solche Operation durchgeführt wird, ist es zudem essenziell, dass die bereits gespeicherten Daten bei Bedarf automatisch neu verteilt werden. Solche Funktionen können nur dann zur Verfügung stehen, wenn eine Virtualisierungsschicht, beispielsweise ein Logical Volume Manager (LVM), zwischen Datenbankinstanz und physischen Disks zum Einsatz kommt. Wenn solche Features nicht unterstützt sind, sind die betroffenen Tablespaces manuell offline zu nehmen und/oder die Daten manuell zu verschieben. Ein Speichersystem sollte Operationen wie Datenbankfiles verschieben oder kopieren ebenfalls unterstützen. Diese Operationen erfordern jedoch ein Wartungsfenster, weil die betroffenen Tablespaces offline, oder in den Backupmodus genommen werden müssen ansonsten ist die Konsistenz der Datenbankfiles nicht mehr gewährleistet. Weil Oracle das Vergrößern und Verkleinern (Resize) von Datenbankfiles unterstützt, sollte auch das Speichersystem dazu in der Lage sein. 3

9 3 Speicherplatzverwaltung Verfügbarkeit Der Schutz gegenüber Hard- und Softwarefehlern sowie gegenüber menschlichen Fehlern ist für Datenbanken von höchster Bedeutung: der Verlust einer abgeschlossenen Transaktion gilt es unter allen Umständen zu verhindern. Einerseits verfügt Oracle über diverse Features, die sofern korrekt angewendet sicherstellen, dass keine abgeschlossene Transaktion verloren geht. Der Einsatz dieser Möglichkeiten liegt meistens beim Applikationsverantwortlichen, wobei es vielfach aus Kostengründen nicht möglich ist, das System gegen alle möglichen Fehler zu schützen. Andererseits verfügen die Speichersubsysteme über bewährte Ausfallschutzoptionen. Die bekannteste Methode, um Daten gegen Hardwareausfall zu schützen, ist das Duplizieren von Hardwarekomponenten wie Disks und Interfaces. Üblich ist beispielsweise die Spiegelung der Daten auf zwei unabhängige Disks, auch bekannt unter dem Begriff RAID 1. Aus Performancegründen empfehlen wir, solche Spiegelungen auf Hardwareebene umzusetzen. In einer DAS-Umgebung sind dazu Controller erforderlich, welche die Spiegelung unterstützen. Spiegelung wird heutzutage von jedem SAN oder NAS unterstützt. Trotz Spiegelung auf Hardwareebene macht die zusätzliche Spiegelung auf Softwareebene, beispielsweise für die Control-Files, die Redolog-Files und die archivierten Log-Files Sinn (siehe Kapitel 2, Datenbankarchitektur). Die meisten Datenbanken nutzen die Möglichkeiten der Spiegelung und es gibt keinen Grund, auf diese zu verzichten. Weitere Möglichkeiten der Spiegelung stellen ASM oder ein LVM zur Verfügung. Eine Problematik der Hardwarespiegelung ist der doppelte Platzbedarf. Devices, die Datenredundanz auf Basis von Parity-Information (z.b. RAID 5 und RAID 6) zur Verfügung stellen, verringern den Overhead in Bezug auf den Diskplatz stark. Anstelle der vollständigen Replizierung der Daten speichern diese Technologien lediglich die Parity- Information, die für die Rekonstruktion von fehlenden Daten notwendig ist. Der Nachteil dieser Methode liegt in einer allgemein schlechteren Schreibperformance. Wir empfehlen daher deren Einsatz für Oracle-Datenbanken nicht. Praxistipp Für die optimale Performance sollte man parity-basierte Datenredundanz-Technologien wie RAID 5 und RAID 6 nicht einsetzen Performance Für die optimale Performance ist die Wahl der Hardware von höchster Bedeutung. Es ist deshalb sehr wichtig, diesen Aspekt bei den Auswahlkriterien zu berücksichtigen. Praxistipp Obwohl die Kapazität in Bits und Bytes ein Schlüsselkriterium für die Wahl eines Speichersystems ist, sind die erforderlichen I/O-Operationen pro Sekunde (IOPS) und deren Größe nicht weniger wichtig. Im Gegenteil: Ein Speichersystem sollte nicht ausschließlich aufgrund seiner Kapazität ausgewählt werden. 4

10 3.2 Datenbank-Speicheroptionen Dazu ein Beispiel: Für eine OLTP-Datenbank von 1,4 TB Größe sind die notwendigen Disks (Typ und Anzahl) zu evaluieren, damit eine Spitzenlast von 1000 IOPS à 8 KB bewältigt werden kann. Die Daten sollten zudem gespiegelt sein und es stehen zwei Disktypen zu Auswahl: High Performance SAS-Disks mit insgesamt 600 GB Kapazität und einem Durchsatz von 175 IOPS à 8 KB High Capacity SATA-Disks mit insgesamt 2 TB Kapazität und einem Durchsatz von 75 IOPS à 8 KB Wenn wir nur die Kapazität in Betracht ziehen, sind die Anforderungen mit 2 SATA-Disks (2*1.4/2.0) oder 6 SAS-Disks (2*1.4/0.6) zu erfüllen. Wenn wir jedoch die IOPS berücksichtigen, müssen mehr Disks eingesetzt werden. Um 1000 IOPS zu erreichen, sind mindestens 28 SATA-Disks (2*1000/75), oder 12 SAS-Disks (2*1000/175) erforderlich. Diese Betrachtung zeigt deutlich auf, dass bei der Auswahl des Speichermediums nicht nur die Kapazität, sondern auch die Performance-Anforderungen wichtig sind. Die Auswahl des richtigen Disktyps und der richtigen Anzahl Disks ist schon einmal ein guter Anfang. Aber Vorsicht: Die erforderliche Spitzenlast ist nur dann gewährleistet, wenn die Disks korrekt und in geeigneter Art und Weise mit dem Server verbunden sind. In einer DAS-Umgebung müssen genügend Controller verfügbar sein und in einer SAN/ NAS-Umgebung muss die Netzwerkinfrastruktur (HBA 1, Netzwerkkarten und Switches) adäquat dimensioniert sein. Ein wichtiger Aspekt für die optimale Nutzung der verfügbaren Hardware ist die gleichmäßige Verteilung der Last über alle Komponenten. Praxistipp Die manuelle Verteilung der I/O-Operationen, beispielsweise durch die Zuordnung von einzelnen Disks zu spezifische Tablespaces, ist in der Regel wenig sinnvoll. Für die Maximierung der Performance empfehlen wir Striping (RAID0) zu verwenden und die automatische Verteilung der I/O-Operationen über die verfügbaren Komponenten dem I/O-Subsystem zu überlassen. Die einzige Situation in der eine manuelle Verteilung in Betracht kommt, besteht dann, wenn Disks mit unterschiedlicher Performance zur Verfügung stehen. Es ist beispielsweise sinnvoll, die schnellsten Disks für die Redolog-Files und für häufig benutzte Datenfiles einzusetzen, während die Disks mit der größten Kapazität mehr für sporadisch genutzte Daten zum Einsatz kommen. Für die optimale Performance empfehlen wir, Striping auf Hardware-Ebene zu implementieren. In einer DAS-Umgebung muss dazu ein Controller verwendet werden, der Striping unterstützt. Striping ist eine Funktionalität, die heutzutage von jedem SAN oder NAS unterstützt wird. 1 Host Bus Adapter (HBA ): Mediator, vermittelt zwischen dem SAN und dem Datenbankserver 5

11 3 Speicherplatzverwaltung Wenn sowohl hohe Verfügbarkeit als auch hohe Performance erforderliche sind, dann sollte man Spiegelung und Striping kombinieren (RAID 1+0 oder RAID 10). Das heißt, die Disks werden paarweise gespiegelt und das Striping erfolgt über die beiden Disks. Vorsicht ist im umgekehrten Fall geboten. Erfolgt die Spiegelung über gestripte Disks (RAID 0+1), verliert man den Vorteil der höheren Verfügbarkeit. Der höchstmögliche Nutzen der verfügbaren Hardware hängt auch von der eingesetzten Software ab. Auf Software-Ebene sind daher zwei Dinge zu beachten: Erstens sollte das Betriebssystem I/O-Operationen bis zu einer Größe von 1 MB (die maximale von Oracle unterstützte Größe) unterstützen. Zweitens sollte asynchrones I/O 2 nicht nur vom Betriebssystem unterstützt werden, sondern auch auf Datenbankebene über den Parameter disk_ asynch_io eingeschaltet sein (Defaultwert ist TRUE). Der Parameter ist eine Art Hauptschalter, über den asynchrone I/O-Operationen für Datenbankfiles auf beliebigen Speichersystemen ein- oder ausgeschaltet werden Zugriff In einer Single-Instanz-Umgebung ist es normalerweise nicht notwendig, den gleichzeitigen Zugriff auf das Speichersubsystem von mehreren Servern aus zu ermöglichen. Die einzige Ausnahme besteht in einer Failovercluster-Umgebung. Doch selbst in diesem Fall ist es besser, die erforderlichen Disks (beziehungsweise Devices) exklusiv auf jenem Clusterknoten zu mounten, auf dem die Instanz aktiv ist. Im Gegensatz dazu müssen in einer Real-Application-Cluster-Umgebung die Datenbankfiles von allen Instanzen aus simultan zugreifbar sein daran führt kein Weg vorbei Filesysteme Datenbankfiles sind am häufigsten auf Filesystemen gespeichert. Der Grund dafür ist einfach: Filesysteme sind weit verbreitet und der Umgang damit entsprechend vertraut. Die Oracle Binaries werden auf einem Filesystem installiert und auch die Datenbankfiles lassen sich ohne zusätzliche Konfiguration darauf speichern. Jedes Betriebssystem unterstützt diverse Filesysteme, aber nicht jedes Filesystem ist von Oracle unterstützt beispielsweise ist der Support für Linux von der Distibution und der Version abhängig. Details dazu stehen in den folgenden My Oracle Support Notes : Linux: Supported and Recommended File Systems on Linux ( ) SuSE/Novell: Linux, Filesystem & I/O Type Supportability ( ) Enterprise Linux: Linux, Filesystem & I/O Type Supportability ( ) AIX: Direct I/O or concurrent I/O on AIX 5L ( ) 2 Asynchrones I/O, auch non-blocking I/O genannt, ist eine sehr effiziente Form von Input/Output- Verarbeitung, die parallele I/O-Verarbeitung ermöglicht. So muss beispielsweise ein Schreibprozess nicht auf die Schreibbestätigung warten, um weiterzuarbeiten. Asynchrones I/O muss vom Betriebssystem unterstützt sein 6

12 3.2 Datenbank-Speicheroptionen Auf Plattformen wie Linux, Solaris, AIX und HP-UX unterstützt Oracle auch Filesysteme von Drittanbietern, wie zum Beispiel die Veritas Storage Foundation von Symantec. In den folgenden Abschnitten beschreiben wir die Eigenschaften von Filesystemen bezüglich Verwaltung, Verfügbarkeit, Performance und Zugriff Verwaltung Operationen wie Hinzufügen, Entfernen oder Ersetzen einer Disk (inklusive Wiederverteilung der Daten) kann nur dann unterbrechungsfrei (ohne Stoppen der Datenbankinstanz) erfolgen, wenn ein Logical Volume Manager oder ein Netzwerkdevice, das solche Features unterstützt, eingesetzt sind. Operationen wie Verschieben oder Kopieren von Datenbankfiles können nach vorgängiger Benachrichtigung der Datenbankinstanz mit den allgemein bekannten Betriebssystembefehlen (wie cp oder mv unter Linux/UNIX) erfolgen. Das folgende Beispiel, ausgeführt auf einem Linux-Server, zeigt wie ein Datenbankfile eines Tablespaces von einem Verzeichnis in ein anderes verschoben wird: SQL> SELECT file_name 2 FROM dba_data_files 3 WHERE tablespace_name = 'TEST'; FILE_NAME /u01/oradata/ora11g/test01ora11g.dbf SQL> ALTER TABLESPACE test OFFLINE; SQL>!mv /u01/oradata/ora11g/test01ora11g.dbf - > /u00/oradata/ora11g/test01ora11g.dbf SQL> ALTER DATABASE 2 RENAME FILE '/u00/oradata/ora11g/test01ora11g.dbf' 3 TO '/u01/oradata/ora11g/test01ora11g.dbf'; SQL> ALTER TABLESPACE test ONLINE; Auch das Vergrößern (respektive Verkleinern) eines Datenbankfiles wird von Oracle unterstützt. Die einzige Voraussetzung, welche natürlicherweise erfüllt sein muss, ist genügend freier Platz im entsprechenden Filesystem. In Abschnitt und zeigen wir je ein Beispiel für automatisches und manuelles Resizing Verfügbarkeit Mit Ausnahme der Control-Files, der Redolog-Files und der archivierten Log-Files (die auch softwaremäßig gespiegelt werden können) kann die Verfügbarkeit der Files auf dem Filesystem nur durch den Einsatz von Spiegelung auf Hardware-Ebene, oder mit Hilfe eines Logical Volume Managers gewährleistet werden. 7

13 3 Speicherplatzverwaltung Performance Die Datenbankblockgröße sollte gleich oder ein Vielfaches der Systemblockgröße sein. Ist sie kleiner, ist die Performance nicht optimal. Das heißt, es muss ein ganzer Filesystemblock von der Platte gelesen werden, wenn eine I/O-Operation durchgeführt wird. Standardmäßig sind die I/O-Operationen von Oracle auf den meisten Filesystemen gepuffert. Das heißt, die Daten sind in einem betriebssystemseitigen Buffercache gespeichert, nachdem sie gelesen bzw. bevor sie geschrieben werden. Weil Oracle jedoch einen eigenen Buffercache besitzt, führt eine solche Doppelpufferung im Allgemeinen zu unnötigem Overhead. Praxistipp Wir empfehlen, die Pufferung von I/O-Operationen zu verhindern. Dazu unterstützen die Filesysteme Direct-I/O, womit wie der Name impliziert der betriebssystemseitige Buffercache umgangen wird. Der Parameter filesystemio_options bestimmt, wie die I/O-Operationen auf Datenbankfiles gegenüber dem Filesystem ausgeführt werden. Folgende Werte stehen zur Verfügung: none: Deaktiviert direkte und asynchrone I/O-Operationen directio: Aktiviert nur direkte I/O-Operationen asynch: Aktiviert nur asynchrone I/O-Operationen setall: Aktiviert direkte und asynchrone I/O-Operationen Der Parameter filesystemio_options ist für die Aktivierung von asynchronen I/O-Operationen nicht möglich, wenn der Parameter disk_asynch_io auf FALSE gesetzt ist. Der Wechsel einer Datenbankinstanz von gepufferten I/O-Operationen auf Direct-I/O kann auch zu einer schlechteren Performance führen, etwa wenn viele I/O-Operationen aus dem betriebssystemseitigen Buffercache bedient werden. Ein größerer Datenbank-Buffercache verhindert diese Problem. Grundsätzlich muss die Datenbank gleich viel Memory zur Verfügung haben, wie das Betriebssystem vor der Umstellung für den Buffercache Zugriff In einer Real-Application-Cluster-Konfiguration sind für die Speicherung von Datenbankfiles nur von Oracle zertifizierte Cluster-Filesysteme (CFS) möglich. Eine Übersicht, welche Plattformen welche CFS unterstützen, ist auf My Oracle Support im Artikel , Raw Devices and Cluster Filesystems With Real Application Clusters dokumentiert. Es ist dabei zu beachten, dass gewisse CFS nur die Speicherung der Oracle Binaries, nicht aber der Datenbankfiles, unterstützen. 8

14 3.2 Datenbank-Speicheroptionen Raw-Devices Werden Raw-Devices eingesetzt, muss für jedes Datenbankfile ein entsprechendes Raw- Device auf Betriebssystemebene vorhanden sein. Aus diesem Grunde ist der Einsatz von Raw-Devices ohne Virtualisierungsschicht, welche die darunterliegenden physischen Disks virtualisiert, schwer denkbar. Abbildung 3.2 zeigt ein Beispiel über die Anwendung eines Logical Volume Managers. Jedes der vier physischen Volumes (PV) basiert auf zwei Disks, die hardwaremäßig gespiegelt sind (hier insgesamt 8 physische Disks). Jeder Tablespace besteht aus einem Datenfile, das auf einem Logical Volume (LV) basiert. Dieses wiederum nutzt die Vorteile aller physischen Volumes, indem die Daten über diese gestriped werden. SYSTEM SYSAUX TEMP UNDO DATA LV LV LV LV LV Volume Group PV PV PV PV Mirrored Disk Mirrored Disk Mirrored Disk Mirrored Disk Abbildung 3.2 Beispiel einer Raw-Device- Konfiguration, die hardwaremäßge Spiegelung und Striping auf Software-Ebene nutzt Mit einer solchen Konfiguration werden die physischen Disks nicht direkt von der Datenbankinstanz angesprochen, was Änderungen auf der physischen Ebene ermöglicht, ohne das Setup auf Datenbankebene zu ändern. In den folgenden Abschnitten beschreiben wir die Eigenschaften von Raw-Devices bezüglich Verwaltung, Verfügbarkeit, Performance und Zugriff Verwaltung Operationen wie Hinzufügen, Entfernen oder Ersetzen einer Disk (inklusive Wiederverteilung der Daten) können nur dann unterbrechungsfrei (ohne Stoppen der Datenbankinstanz) erfolgen, wenn ein Logical Volume Manager, oder ein Netzwerkdevice, das solche Features unterstützt, eingesetzt werden. Operationen wie Verschieben oder Kopieren von Datenbankfiles können nach vorgängiger Benachrichtigung der Datenbankinstanz mit Betriebssystembefehlen erfolgen. Im Gegensatz zu den Filesystemen sind die allgemein bekannten Befehle bei Raw-Devices nicht möglich. Für diese einfachen Operationen ist mit Raw-Devices spezielles Wissen notwendig. Im folgenden Beispiel, ausgeführt auf einem Linux-Server, zeigen wir, wie ein Datenbankfile von einem Device auf ein anderes verschoben wird. Für die Evaluation der 9

15 3 Speicherplatzverwaltung Filegröße verwenden wir den dbfsize-befehl (dbfsize ist Teil der Oracle Binaries) und für das Kopieren des Datenfiles kommt der dd-befehl zum Einsatz (dd wird vom Betriebssystem zur Verfügung gestellt). SQL> SELECT file_name 2 FROM dba_data_files 3 WHERE tablespace_name = 'TEST'; FILE_NAME /dev/mapper/vg01-test1 SQL> ALTER TABLESPACE test OFFLINE; SQL>!dbfsize /dev/mapper/vg01-test1 Database file: /dev/mapper/vg01-test1 Database file type: raw device Database file size: byte blocks SQL>!dd if=/dev/mapper/vg01-test1 - > of=/dev/mapper/vg01-test2 - > count=12800 bs= records in records out SQL> ALTER DATABASE 2 RENAME FILE '/dev/mapper/vg01-test1' 3 TO '/dev/mapper/vg01-test2'; SQL> ALTER TABLESPACE test ONLINE; Bei der Planung einer solchen Operation ist zu berücksichtigen, dass bestimmte Betriebssysteme den ersten Teil eines Raw-Devices für die Verwaltung von Meta-Informationen reservieren. In diesem Fall ist ein Teil des Files beim Kopieren des Raw-Device-Inhalts zu überspringen. Diese Problematik lässt sich durch den Einsatz von RMAN (siehe Kapitel Backup und Recovery) einfach umgehen. Der folgende RMAN-Befehl führt die gleiche Operation aus, wie im vorhergehenden Beispiel. RUN { ALLOCATE CHANNEL c TYPE disk; SQL 'ALTER TABLESPACE test OFFLINE'; BACKUP AS COPY DATAFILE '/dev/mapper/vg01-test1' FORMAT '/dev/mapper/vg01-test2'; SWITCH DATAFILE '/dev/mapper/vg01-test1' TO DATAFILECOPY '/dev/mapper/vg01-test2'; SQL 'ALTER TABLESPACE test ONLINE'; RELEASE CHANNEL c; } Sind die Verfügbarkeitsanforderungen erhöht, bietet RMAN auch die Möglichkeit, die Kopie des Datenfiles online zu machen: RUN { ALLOCATE CHANNEL c TYPE disk; BACKUP AS COPY DATAFILE '/dev/mapper/vg01-test1' FORMAT '/dev/mapper/vg01-test2'; SQL 'ALTER TABLESPACE test OFFLINE'; SWITCH DATAFILE '/dev/mapper/vg01-test1' TO DATAFILECOPY '/dev/mapper/vg01-test2'; 10

16 3.2 Datenbank-Speicheroptionen } RECOVER DATAFILE '/dev/mapper/vg01-test1'; SQL 'ALTER TABLESPACE test ONLINE'; RELEASE CHANNEL c; Auch wenn das Vergrößern von Datenbankfiles auf Raw-Devices unterstützt wird, verzichtet man normalerweise darauf. Wer mehr Platz benötigt, weist üblicherweise dem neuen Datenfile ein neues Raw-Device zu Verfügbarkeit Mit Ausnahme der Control-Files, der Redolog-Files und der archivierten Log-Files (welche auch softwaremäßig gespiegelt werden können) kann die Verfügbarkeit der Files auf Raw-Devices nur durch den Einsatz von Spiegelung auf Hardwareebene, oder mit Hilfe eines Logical Volume Managers gewährleistet werden Performance Raw-Devices benötigen keine spezielle Konfiguration für die optimal Performance. I/O- Operationen auf Datenfiles, die auf Raw-Devices liegen, können nicht vom betriebssystemseitigen Buffer-Cache profitieren. Dies kann zu einer verminderten Performance führen, wenn Datenfiles von einem Filesystem auf ein Raw-Device verschoben werden, das vorher stark vom betriebssystemseitigen Buffer-Cache profitiert hat. Um dies zu verhindern, sollte der Datenbank Buffer-Cache entsprechend groß sein. Grundsätzlich muss die Datenbank gleich viel Memory besitzen, wie das Betriebssystem vor der Umstellung für den Buffercache verwendet hat Zugriff In einer Real-Application-Cluster-Konfiguration stellt die Datenbankinstanz sicher, dass die Datenbankfiles auf konsistente und synchrone Art und Weise modifiziert sind. Daher kann eine Datenbank auf Raw-Devices gleichzeitig von mehreren Instanzen geöffnet werden. Dies ist auch der Grund dafür, wieso in der Vergangenheit fast alle geclusterten Datenbanken auf Raw-Devices verwaltet wurden Automatic Storage Management Automatic Storage Management (ASM) ist ein Datenbank-Feature, das seit 10g eingeführt ist. ASM soll ohne zusätzliche Lizenzkosten die vier zentralen Anforderungen (Verwaltung, Verfügbarkeit, Performance und Zugriff) auf einfache, flexible und kostengünstige Art und Weise erfüllen. Anstelle einer vollständigen Beschreibung aller ASM-Features, konzentrieren wir uns in diesem Abschnitt auf die Möglichkeiten, um die erwähnten Anforderungen zu erfüllen. Die Installation und die Konfiguration von ASM ist im Kapitel Automatic Storage Management beschrieben. 11

17 3 Speicherplatzverwaltung Verwaltung Operationen wie Hinzufügen, Entfernen oder Ersetzen einer Disk (inklusive Wiederverteilung der Daten) kann online erfolgen, d.h. ohne die Datenbankinstanz, welche die modifizierte Diskgruppe verwendet, zu stoppen. Die Wiederverteilung der Daten, das Rebalancing, erfolgt automatisch mit jeder Modifikation einer Diskgruppe. Es empfiehlt sich daher beim Ersetzen einer Disk die beiden Operationen (ADD und DROP) in einem einzigen ALTER DISKGROUP-Statement zusammenzufassen. Auf diese Weise erfolgt nur eine Rebalance-Operation. Das folgende Beispiel illustriert dieses Vorgehen: ALTER DISKGROUP data DROP DISK disk05 ADD FAILGROUP fg02 DISK '/dev/mapper/vg01-asmdisk09' NAME disk09 REBALANCE POWER 1 Mit der REBALANCE POWER-Klausel kontrolliert man die Zahl der Hintergrundprozesse (ARBn), welche die Re-Distribution der Daten durchführen. Werte von 0 bis 11 sind erlaubt. Je höher der Wert, desto schneller ist das Rebalancing, desto höher sind aber auch die Auswirkungen auf das System. Der Default-Wert (1) wird über den Parameter asm_power_limit geändert. Achtung: der Wert 0 schaltet das automatische Rebalancing ganz aus. Ab 11g lässt sich das Rebalancing beschleunigen, indem man die Diskgruppe im Restricted-Modus mountet. Weil in diesem Modus nur eine einzige Instanz die Diskgruppe mounten kann, fällt der Synchronisationsaufwand zwischen den Instanzen weg und das Rebalancing ist entsprechend schneller. Für ein solches Rebalancing wird normalerweise eine hoher Wert in der REBALANCE POWER-Klausel definiert. Praxistipp Ein Vorteil von ASM ist die Möglichkeit, Rebalancing-Operationen unabhängig von der physikalischen Lokation der Disks durchzuführen. So kann beispielsweise eine Datenbank unterbrechungsfrei von einem Storage-Subsystem auf ein anderes (z.b. auf ein neues SAN) verschoben werden. Der gleichzeitige Zugriff von ASM auf die Disks beider Speichersubsysteme ist die einzige Voraussetzung, die erfüllt sein muss. Das Verschieben und Kopieren von Datenbankfiles wird normalerweise mit einem der folgenden Tools gemacht: RMAN (das Beispiel von Abschnitt ist auch für ASM anwendbar) DBMS_FILE_TRANSFER-Package Das Vergrößern von Datenbankfiles wird mit ASM transparent unterstützt. Einzige Voraussetzung ist genügend freier Platz in der entsprechenden Diskgruppe. In Abschnitt und zeigen wir je ein Beispiel für automatisches und manuelles Resizing. 12

18 3.2 Datenbank-Speicheroptionen Verfügbarkeit ASM verfügt über drei verschiedene Diskgruppen-Typen: externe Redundanz, normale Redundanz und hohe Redundanz. Der Diskgruppen-Typ bestimmt den Level der Spiegelung. Mit externer Redundanz werden die Spiegelungseigenschaft des Speichersubsystem genutzt. Die anderen beiden Typen gewährleisten die Spiegelung von ASM. Normale Redundanz spiegelt die Daten doppelt, hohe Redundanz dreifach. Wenn das Speichersubsystem ein High-End-SAN oder -NAS ist, kommen die Spiegelungs- (und Striping-)Möglichkeiten von ASM normalerweise nicht zur Anwendung, eine Ausnahme bilden Cluster, deren Knoten und Speichersubsysteme über mehrere Lokationen verteilt sind. In einem solchen Fall ist es vorteilhafter, die Spiegelung (und das Striping) dem Speichersubsystem zu überlassen. ASM nutzt dann die entsprechenden Disks in einer Diskgruppe mit externer Redundanz Performance ASM benötigen keine spezielle Konfiguration für die optimale Performance einzige Ausnahme, wenn die Disks und die Instanzen über zwei (oder drei) Lokationen verteilt sind. In diesem Fall sollte man nicht nur für jede Lokation eine Failure Group (welche die lokalen Disks beinhaltet) definieren, sondern auch die Instanzen so einrichten, dass die Preferred Failure Group lokal ist. Für diesen Zweck steht der Parameter asm_preferred_read_failure_groups zur Verfügung Zugriff ASM wurde sowohl für den Einsatz in Real-Application-Clusters- als auch für Single- Instanz-Umgebungen entwickelt. Die einzige Voraussetzung beim Einsatz in RAC-Umgebungen ist, dass der Zugriff auf die Disks für alle Server im Clusterverbund gewährleistet ist. Weil sich die Disks dem ASM als Raw-Devices präsentieren, sollte dies grundsätzlich kein Problem sein Die Auswahl der Datenbank-Speicheroption Früher waren Raw-Devices bezüglich Performance und Eignung für Clustersysteme die erste Wahlwaren. Mit ASM steht heute eine viel einfachere und flexiblere Lösung zur Verfügung. Hinzu kommt, dass Oracle plant, Raw-Devices in Zukunft nicht mehr zu unterstützen (siehe My Oracle Support Artikel , Announcement on using Raw devices with release 11.2 ). Aus diesem Grunde empfehlen wir, in neuen Systemen Raw- Devices nicht mehr einzusetzen. Um die vier zentralen Anforderungen (Verwaltung, Verfügbarkeit, Performance und Zugriff) zu erfüllen, ohne einen Logical-Volume-Manager eines Drittherstellers lizenzieren zu müssen, empfehlen wir ASM. Wer Real Application Clusters mit der Standard Edition verwendet, muss zwingend ASM einsetzen. 13

19 3 Speicherplatzverwaltung Auch wenn die Verwaltung von ASM nicht sehr schwierig ist, ist ASM eine zusätzliche Infrastrukturkomponente, die verwaltet und verstanden werden muss. Wenn der zusätzliche Aufwand für Verwaltung und Setup den Nutzen gegenüber einem Filesystem übersteigt, empfehlen wir, anstelle von ASM ein Filesystem zu verwenden. 3.3 Data-, Temp- und Redolog-Fileattribute Im vorherigen Abschnitt haben wir gezeigt, wie die Datenbankfiles im Storage-System gespeichert sind. In diesem Abschnitt beschreiben wir die Attribute, die für Datafiles, Tempfiles und Redolog-Files spezifiziert werden können. Das einzige Attribut, das man für alle drei Filetypen definieren kann, ist die initiale Filegröße (Initial Size). Zusätzlich lassen sich Datafiles und Tempfiles (vorausgesetzt, man verwendet keine Raw-Devices) so spezifizieren, dass sie sich bei Bedarf automatisch vergrößern. Natürlich kann man die Datafiles auch manuell vergrößern Initial Size Beim Erstellen eines Datafiles, eines Tempfiles oder eines Redolog-Files wird die initiale Größe mit der SIZE-Klausel definiert. Wie das folgende Beispiel zeigt, kann man die Größe mit dem entsprechenden Suffix K, M, G, T, P oder E sowohl in Bytes, Kilobytes, Megabytes, Gigabytes, Terabytes, Petabytes oder Exabytes spezifizieren. SQL> CREATE TEMPORARY TABLESPACE test 2 TEMPFILE '/u00/oradata/ora11g/test01ora11g.dbf' SIZE 1G; Bei der Erstellung eines Datenfiles, oder eines Redolog-Files, initialisiert die Database- Engine alle zugehörigen Blöcke. Aus diesem Grund kann die Erstellung eines großen Tablespaces auch entsprechend viel Zeit beanspruchen. Eine vorgängige Initialisierung findet für Tempfiles nicht zwingend statt, sondern es entsteht, abhängig vom Betriebssystem, ein sogenanntes Sparsefile. Der erforderliche Platz für einen Block in einem Sparsefile wird erst dann alloziert, wenn man den Block das erste Mal verwendet. Dies bedeutet, dass der erforderliche Diskplatz für ein Tempfile erst bei dessen Nutzung vollständig alloziert wird. Das folgende Beispiel illustriert dieses Verhalten, wir verwenden dazu den zuvor erstellten Tablespace: 1. Anzeige der Dateigröße des Tempfiles mittels Betriebssystem-Kommando (in diesem Fall Linux). Wie aus dem folgenden Output ersichtlich ist, zeigt der Befehl ls -l eine Filegröße von 1 GB an (eigentlich 1 GB + ein Datenbankblock). Gleichzeitig zeigt uns der Befehl ls -s aber lediglich eine Filegröße von 129 Blöcken à 8192 Bytes (= Bytes) an. Daraus folgt: Der erste Befehl zeigt die Dateigröße und der zweite Befehl den allozierten Platz an. 14

20 3.3 Data-, Temp- und Redolog-Fileattribute $ cd /u00/oradata/ora11g/ $ ls -l test01ora11g.dbf -rw-r oracle oinstall Aug 5 18:17 test01ora11g.dbf $ ls -s --block-size=8192 test01ora11g.dbf 129 test01ora11g.dbf 2. Nun erstellen wir im temporären Tablespace ein temporäres Segment mit ca. 100 MB Daten. Danach löschen wir das Objekt wieder. SQL> CREATE GLOBAL TEMPORARY TABLE t (id NUMBER, pad VARCHAR2(1000)) 2 TABLESPACE test; SQL> INSERT INTO t 2 SELECT rownum, rpad('*',1000,'*') 3 FROM dual 4 CONNECT BY level <= ; SQL> DROP TABLE t PURGE; 3. Jetzt werten wir den Platz nochmals wie in Punkt 1 aus. Beachten Sie, dass nun Blöcke alloziert sind das Tempfile verwendet nun ca. 93 MB Platz auf Betriebssystemebene. $ ls -s --block-size=8192 test01ora11g.dbf test01ora11g.dbf Im Zusammenhang mit Sparsefiles gibt es zwei Probleme. Erstens: Weil der Platz erst bei der effektiven Nutzung alloziert wird, kann es vorkommen, dass der Platz auf Betriebssystemebene vorgängig bereits anderweitig verwendet wurde und für das Sparsefile nicht mehr zur Verfügung steht. Dies führt ggf. zu einem Fehler (z.b.: ORA-01114: IO error writing block to file). Zweitens kann es zu Performance-Einbußen führen, weil auf bestimmten Betriebssystemen für Sparsefiles nicht alle Features unterstützt werden (beispielsweise unterstützt Solaris kein Direct-I/O). Praxistipp Wir empfehlen, keine Sparsefiles zu verwenden und die Tempfiles vorgängig, das heißt, bevor die Zuordnung zur Datenbank erfolgt, auf Betriebssystem-Ebene zu erstellen. Das folgende Beispiel zeigt, wie man Sparefiles beim Erstellen von Tempfiles verhindern kann. 1. Erstellen des Files auf Betriebssystem-Ebene (in diesem Fall Linux). Dazu kann das Unixprogramm dd verwendet werden. Beachten Sie, dass die Größe der Datei mit der Größe des Tempfiles übereinstimmen muss. $ cd /u00/oradata/ora11g $ dd if=/dev/zero of=test01ora11g.dbf bs=1024 count= Zuweisen des erstellten Files zur Datenbank. Dabei sind zwei Dinge zu beachten: Erstens die REUSE-Klausel zu verwenden, weil die Datei ja bereits existiert. Zweitens die SIZE-Klausel nicht zu spezifizieren, da die Datenbank die Dateigröße vom Betriebssystem übernimmt. 15