Oracle Database 11g DBA-Handbuch Eine skalierbare und sichere Oracle Datenbank administrieren

Transkript

1 Bob Bryla, Kevin Loney Oracle Database 11g DBA-Handbuch Eine skalierbare und sichere Oracle Datenbank administrieren ISBN-10: ISBN-13: Leseprobe Weitere Informationen oder Bestellungen unter sowie im Buchhandel.

2 3 3 Tablespaces planen und verwalten Wie ein DBA das Layout der Tablespaces in einer Datenbank konfiguriert, wirkt sich direkt auf die Performance und Verwaltbarkeit der Datenbank aus. In diesem Kapitel beschäftigen wir uns mit den verschiedenen Tablespace-Typen und zeigen, wie der Einsatz von temporären Tablespaces die Anzahl und Größe der Tablespaces in einer Datenbank beeinflussen kann. Das Leistungsmerkmal der Gruppenbildung für temporäre Tablespaces wird seit Oracle 10g angeboten. Ein weiteres Thema ist die OFA (Optimal Flexible Architecture), die es seit Oracle 7 gibt, und eine Hilfe zur Standardisierung und Optimierung der Verzeichnisstruktur und der Oracle- Programme bietet. In Oracle 11g wurde die OFA ein weiteres Mal erweitert und unterstützt jetzt eine verbesserte Sicherheit, ein vereinfachtes Cloning, und erleichtert das Upgraden. Eine Standardinstallation von Oracle bietet dem DBA nicht nur einen guten Startpunkt zum Anlegen einer OFA-konformen Verzeichnisstruktur, sondern auch zum Aufteilen von Segmenten auf verschiedene Tablespaces. Zudem untersuchen wir die Platzanforderungen der einzelnen Tablespaces und bieten einige Tipps zum Feintuning der Tablespace-Charakteristiken. Am Ende des Kapitels finden Sie einige Richtlinien, mit deren Hilfe sich die Segmente basierend auf ihrem Typ, ihrer Größe und der Zugriffshäufigkeit in unterschiedliche Tablespaces aufteilen lassen. Außerdem zeigen wir, wie man Hotspots in Tablespaces identifiziert und adäquat behandelt.

3 70 3 Tablespaces planen und verwalten 3.1 Tablespace-Architektur Eine Voraussetzung für eine kompetente Einrichtung der Tablespaces in Ihrer Oracle-Datenbank ist, dass man die unterschiedlichen Tablespace-Typen und deren Einsatzmöglichkeiten kennt. In diesem Abschnitt bieten wir eine kurze Übersicht über die verschiedenen Tablespace-Typen und ihre Verwaltung. Zusätzlich beschäftigen wir uns mit Oracles Optimal Flexible Architecture und untersuchen, inwieweit sie ein Gerüst zum Speichern von Tablespace-Datendateien, Oracle-Programmen und anderen Oracle-Komponenten wie Redo-Logdateien, Steuerdateien etc. darstellt. Weiterhin gehen wir auf die verschiedenen Tablespace-Kategorien ein SYSTEM-Tablespaces, SYS- AUX-Tablespace, temporäre Tablespaces, Undo- und Bigfile-Tablespaces und beschreiben ihre Funktion Tablespace-Typen Die wichtigsten Tablespace-Typen in einer Oracle-Datenbank sind permanent, Undo und temporär. Permanente Tablespaces enthalten Segmente, die länger als eine Sitzung oder Transaktion bestehen. Auch wenn der Undo-Tablespace Segmente enthalten kann, die länger als eine Sitzung oder Transaktion vorgehalten werden, stellt er einmal die Lesekonsistenz für select-anweisungen, die auf veränderte Tabellen zugreifen, und Undo-Daten für zahlreiche Flashback-Funktionen zur Verfügung. Doch in erster Linie speichern Undo-Segmente die alten Daten von Spalten, die geändert oder gelöscht wurden. Weiterhin können sie einen Hinweis bieten, dass die Zeile für ein insert nicht existiert sollte die Benutzersitzung vor Eingabe eines commit oder rollback scheitern, werden alle Aktualisierungen, Einfügungen und Löschungen entfernt. Undo- Segmente sind über Sitzungen nicht direkt zugänglich, und Undo-Tablespaces können nur Undo-Segmente enthalten. Wie der Name impliziert, enthalten temporäre Tablespaces flüchtige Daten, die nur für die Dauer einer Sitzung existieren, wie der Speicherplatz für eine Sortieroperation, die nicht in den Arbeitsspeicher passt. Bigfile-Tablespaces lassen sich für alle drei genannten Tablespace-Typen einsetzen und vereinfachen die Tablespace-Verwaltung, indem Sie den Wartungspunkt von der Datendatei in den Tablespace verschieben. Bigfile-Tablespaces bestehen aus einer einzigen Datendatei. Dennoch haben die Bigfile-Tablespaces auch einige Nachteile, die weiter unten ausführlich dargestellt werden. Permanent Die SYSTEM- und SYSAUX-Tablespaces sind zwei Beispiele für permanente Tablespaces. Grundsätzlich sollte man alle Segmente, die von einem Benutzer oder einer Sitzung länger als eine Transaktion oder Sitzung vorzuhalten sind, in permanenten Tablespaces speichern. SYSTEM-Tablespace Im SYSTEM-Tablespace sollten niemals Benutzersegmente liegen. Seit Oracle 10g kann man standardmäßig einen permanenten Tablespace vorgeben. Das ergänzt die Funktionalität ab Oracle 9i, wo man erstmals standardmäßig einen temporären Tablespace definieren konnte.

4 3.1 Tablespace-Architektur 71 Falls Sie sich mit dem Oracle Universal Installer (OUI) eine Datenbank anlegen lassen, werden neben SYSTEM für permanente und temporäre Segmente weitere Tablespaces angelegt. Richten Sie die Datenbank manuell ein, ist sicherzustellen, dass ein standardmäßiger permanenter und ein temporärer Tablespace vorgegeben wird. Siehe dazu das folgende Beispiel für einen create database-befehl: CREATE DATABASE rjbdb USER SYS IDENTIFIED BY kshelt25 USER SYSTEM IDENTIFIED BY mgrab45 LOGFILE GROUP 1 ('/u02/oracle11g/oradata/rjbdb/redo01.log') SIZE 100M, GROUP 2 ('/u04/oracle11g/oradata/rjbdb/redo02.log') SIZE 100M, GROUP 3 ('/u06/oracle11g/oradata/rjbdb/redo03.log') SIZE 100M MAXLOGFILES 5 MAXLOGMEMBERS 5 MAXLOGHISTORY 1 MAXDATAFILES 100 MAXINSTANCES 1 CHARACTER SET US7ASCII NATIONAL CHARACTER SET AL16UTF16 DATAFILE '/u01/oracle11g/oradata/rjbdb/system01.dbf' SIZE 325M REUSE EXTENT MANAGEMENT LOCAL SYSAUX DATAFILE '/u01/oracle11g/oradata/rjbdb/sysaux01.dbf' SIZE 325M REUSE DEFAULT TABLESPACE USERS DATAFILE '/u03/oracle11g/oradata/rjbdb/users01.dbf' SIZE 50M REUSE DEFAULT TEMPORARY TABLESPACE tempts1 TEMPFILE '/u01/oracle11g/oradata/rjbdb/temp01.dbf' SIZE 20M REUSE UNDO TABLESPACE undotbs DATAFILE '/u02/oracle11g/oradata/rjbdb/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED; Seit Oracle 10g ist der SYSTEM-Tablespace standardmäßig lokal verwaltet. Damit wird die Speicherplatzbelegung für den gesamten Tablespace von einem Bitmap-Segment verwaltet, das im ersten Abschnitt der ersten Datendatei liegt. In einer Datenbank mit einem lokal verwalteten SYSTEM-Tablespace müssen auch die anderen Tablespaces entweder lokal verwaltet oder read-only sein. Lokal verwaltete Tablespaces entlasten den SYSTEM-Tablespace, da die Speicherreservierung und -freigabe für den Tablespace keine Data Dictionary-Tabellen benötigen. Weitere Einzelheiten zu lokal verwalteten Tablespaces finden Sie in Kapitel 6. SYSAUX-Tablespace Genau wie der SYSTEM-Tablespace sollte auch der SYSAUX-Tablespace keine Benutzersegmente enthalten. Die Inhalte des SYSAUX-Tablespace lassen sich applikationsbezogen mit der EM Database Control überprüfen. Um den SYSAUX-Tablespace zu editieren, klicken Sie auf den Tablespaces-Link unterhalb des Server-Registers. Abbildung 3-1 zeigt eine grafische Darstellung der Platzbelegung in SYSAUX.

5 72 3 Tablespaces planen und verwalten Abbildung 3-1: Die Inhalte des SYSAUX-Tablespace, dargestellt in der EM Database Control. Wenn eine bestimmte Applikation in SYSAUX zu viel Platz belegt oder in Konkurrenz mit anderen Anwendungen einen I/O-Engpass verursacht, lassen sich ausgewählte Applikationen in einen anderen Tablespace verschieben. Unterhalb des Tortendiagramms in Abbildung 3-1 können wir den Change Tablespace-Link für ein SYSAUX-Element anklicken und es in einen anderen Tablespace verschieben (siehe Abbildung 3-2). Ein Beispiel für das Verschieben eines SYSAUX-Elements mit Hilfe der Befehlszeilenschnittstelle zeigen wir in Kapitel 6. Abbildung 3-2: Verschieben eines SYSAUX-Elements mit der EM Database Control. Der SYSAUX-Tablespace lässt sich wie jeder andere Tablespace überwachen. Weiter unten zeigen wir, wie sich mit der EM Database Control in einem Tablespace Hotspots identifizieren lassen.

6 3.1 Tablespace-Architektur 73 Undo Innerhalb einer Datenbank kann es mehrere Undo-Tablespaces geben, aber immer nur ein Undo-Tablespace kann zu einem gegebenen Zeitpunkt aktiv sein. Undo-Tablespaces benötigt man für Rollbacks von Transaktionen, für die Lesekonsistenz von select-anweisungen, die gleichzeitig mit DML-Anweisungen auf dieselben Tabellen oder Tabellensets zugreifen, und zur Unterstützung von verschiedenen Oracle Flashback-Funktionen, wie Flashback Queries. Der Undo-Tablespace ist korrekt zu dimensionieren, denn nur so lassen sich Snapshot too old -Fehler vermeiden. Zudem wird dieser Platz zur Unterstützung von Initialisierungsparametern wie UNDO_RETENTION benötigt. Für weiterführende Informationen zum Überwachen, Dimensionieren und Anlegen von Undo-Tablespaces siehe Kapitel 7. Temporär In der Datenbank kann mehr als ein temporärer Tablespace online und aktiv sein. Doch bis zur Oracle-Version 10g nutzten mehrere Sitzungen eines Benutzers denselben temporären Tablespace, da man einem Benutzer nur einen standardmäßigen Tablespace zuweisen konnte. Um diesen potenziellen Performanceengpass zu beseitigen, unterstützt Oracle jetzt temporäre Tablespace-Gruppen. Eine temporäre Tablespace-Gruppe ist ein Synonym für eine Liste mit temporären Tablespaces. Eine temporäre Tablespace-Gruppe muss mindestens einen temporären Tablespace enthalten, kann also nicht leer sein. Besitzt eine temporäre Tablespace-Gruppe keine Elemente, existiert sie nicht mehr. Einer der großen Vorteile von temporären Tablespace-Gruppen ist, dass man einem Benutzer mit mehreren Sitzungen für jede Sitzung tatsächlich einen separaten temporären Tablespace zuweisen kann. Das Diagramm in Abbildung 3-3 zeigt, dass der Benutzer OE zwei aktive Sitzungen hat, die temporären Platz für Sortieroperationen benötigen. OE Sitzung #1 Seriell Gleichzeitige Sitzungen OE Sitzung #2 Parallel Tablespace TEMP 1 Tablespace TEMP 2 Tablespace TEMP 3 Temporäre Tablespace-Gruppe TEMPGRP Abbildung 3-3: Die temporäre Tablespace-Gruppe TEMPGRP. Statt eines einzelnen temporären Tablespace wird dem Benutzer die temporäre Tablespace- Gruppe zugewiesen. In unserem Beispiel wird OE die temporäre Tablespace-Gruppe TEMP- GRP zugewiesen. Da die Tablespace-Gruppe TEMPGRP jedoch drei temporäre Tablespaces umfasst, kann die erste OE-Sitzung den temporären Tablespace TEMP1 nutzen, während die select-anweisung der zweiten Oracle-Sitzung von OE parallel die beiden anderen temporären Tablespaces TEMP2 und TEMP3 verwenden kann. Vor Oracle 10g hätten beide Sitzungen den gleichen temporären Tablespace eingesetzt, was potenziell zu Performanceproblemen führen kann.

7 74 3 Tablespaces planen und verwalten Das Anlegen einer temporären Tablespace-Gruppe ist relativ einfach. Nach dem Anlegen der einzelnen Tablespaces TEMP1, TEMP2 und TEMP3 richten wir die temporäre Tablespace- Gruppe TEMPGRP wie folgt ein: SQL> alter tablespace temp1 tablespace group tempgrp; Tablespace altered. SQL> alter tablespace temp2 tablespace group tempgrp; Tablespace altered. SQL> alter tablespace temp3 tablespace group tempgrp; Tablespace altered. Um der Datenbank TEMPGRP als standardmäßigen temporären Tablespace zuzuweisen, nutzt man den gleichen Befehl wie beim Zuweisen eines temporären Tablespace als Default; temporäre Tablespace-Gruppen werden logisch wie temporäre Tablespaces behandelt: SQL> alter database default temporary tablespace tempgrp; Database altered. Zum Löschen einer Tablespace-Gruppe sind zuerst alle vorhandenen Elemente zu entfernen. Dazu weist man den temporären Tablespace einer Gruppe zu, deren Name ein leerer String ist (anders gesagt, löscht man den Tablespace aus der Gruppe): SQL> alter tablespace temp3 tablespace group ''; Tablespace altered. Eine temporäre Tablespace-Gruppe weist man genauso zu wie einen temporären Tablespace; diese Zuweisung geschieht entweder nach dem Anlegen des Benutzers oder zu einem späteren Zeitpunkt. Im folgenden Beispiel wird dem neuen Benutzer JENWEB der temporäre Tablespace TEMPGRP zugewiesen: SQL> create user jenweb identified by pi default tablespace users 3 temporary tablespace tempgrp; User created. Hätten wir beim Anlegen des Benutzers die Zuweisung des Tablespace nicht vorgenommen, würde JENWEB weiterhin mit dem temporären Tablespace TEMPGRP arbeiten, da es der Datenbank-Standard aus unserem letzten create database-befehl ist. Zur Unterstützung von temporären Tablespace-Gruppen wurden an den Data Dictionary Views zahlreiche Änderungen vorgenommen. Die Data Dictionary View DBA_USERS besitzt weiterhin die Spalte TEMPORARY_TABLESPACE, doch sie kann jetzt den Namen des temporären Tablespace, der dem Benutzer zugewiesen ist, oder den Namen einer temporären Tablespace-Gruppe enthalten. SQL> select username, default_tablespace, temporary tablespace 2 from dba_users where username = 'JENWEB'; USERNAME DEFAULT_TABLESPACE TEMPORARY_TABLESPACE JENWEB USERS TEMPGRP 1 row selected.

8 3.1 Tablespace-Architektur 75 Die neue Data Dictionary View DBA_TABLESPACE_GROUPS zeigt die Elemente der einzelnen temporären Tablespace-Gruppen: SQL> select group_name, tablespace_name from dba_tablespace_groups; GROUP_NAME TABLESPACE_NAME TEMPGRP TEMPI TEMPGRP TEMP2 TEMPGRP TEMP3 3 rows selected. Ähnlich wie bei anderen Oracle-Funktionen, die man über die Befehlszeile ausführen kann, lässt sich das Zuweisen von Elementen zu temporären Tablespace-Gruppen oder das Löschen von Elementen aus temporären Tablespace-Gruppen mit der EM Database Control bewerkstelligen. In Abbildung 3-4 kann man Elemente für temporäre Tablespace-Gruppen hinzufügen oder löschen. Abbildung 3-4: Editieren temporärer Tablespace-Gruppen mit der EM Database Control. Bigfile Ein Bigfile-Tablespace enthält nur eine Datendatei und erleichtert damit das Administrieren der Datenbank. Diese Datendatei kann bis zu 128TB (Terabytes) groß sein. Viele Befehle zur Verwaltung von Datendateien lassen sich jetzt auf Tablespace-Ebene auch für Bigfile-Tablespaces einsetzen. Kapitel 6 zeigt, wie man Bigfile-Tablespaces anlegt und verwaltet. Trotz aller Vorteile bei der Verwaltung von Bigfile-Tablespaces sollte man die Nachteile nicht verschweigen. Da ein Bigfile-Tablespace eine einzige Datendatei umfasst, dauert ein vollständiges Backup sehr viel länger als die Sicherung von verschiedenen kleineren Datendateien (die in der Summe gleich groß sind wie der Bigfile-Tablespace). Der Grund dafür ist, dass Oracle pro Datendatei nur einen Slave-Prozess verwendet und somit nicht in der Lage ist, verschie-

9 76 3 Tablespaces planen und verwalten dene Teile des Bigfile-Tablespace mit parallelen Prozessen zu sichern. Falls Ihr Bigfile-Tablespace read-only ist oder die geänderten Blöcke regelmäßig gesichert werden, spielen diese Fragen in Ihrer Umgebung keine große Rolle Optimal Flexible Architecture Oracles OFA (Optimal Flexible Architecture) bietet Richtlinien, mit denen sich die Verwaltung der Software und Datenbankdateien von Oracle vereinfachen, und gleichzeitig die Performance der Datenbank verbessern lässt. Dazu hinterlegt man die Datenbankdateien so, dass I/O-Engpässe minimiert werden. Obgleich beim Anlegen oder Verwalten einer Oracle-Umgebung der Einsatz der OFA nicht strikt erzwungen wird, lässt sich anhand der OFA gut verdeutlichen, wie die Datenbank auf Laufwerksebene organisiert ist. Abhängig von den gewählten Speicheroptionen kann sich die OFA geringfügig unterscheiden ob es eine ASM (Automatic Storage Management)-Umgebung oder ein standardmäßiges Betriebssystem-Dateisystem ist, das entweder den logischen Laufwerksmanager eines Fremdherstellers oder ein RAID-fähiges Plattensubsystem einsetzen kann. Abbildung 3-5: OFA-konforme Unix-Verzeichnisstruktur. Nicht-ASM-Umgebung In einer Nicht-ASM-Umgebung auf einem Unix-Server benötigt man zur Implementierung der OFA-Empfehlungen mindestens drei physische Laufwerke. Ganz oben angefangen, ist das

10 3.1 Tablespace-Architektur 77 empfohlene Format für einen Mount-Punkt /<string const><numeric key>, wobei <string const> ein oder mehrere Buchstaben, und <numeric key> zwei oder drei Ziffern sein kann. So kann ein System beispielsweise die Mount-Punkte /u01, /u02, /u03 und /u04 haben, was 96 zusätzliche Mount-Punkte zulässt, ohne die Konvention zur Dateibenennung ändern zu müssen. Abbildung 3-5 zeigt ein typisches Unix-Dateisystemlayout mit einer OFA-konformen Oracle- Verzeichnisstruktur. Auf diesem Server gibt es zwei Instanzen: Eine ASM-Instanz zur Verwaltung der Laufwerksgruppen und eine standardmäßige RDBMS-Instanz (dw). Softwarekomponenten Die Softwarekomponenten für die einzelnen Produktnamen liegen im Verzeichnis /<string const><numeric key>/<directory type>/<product owner>, wobei <string const> und <numeric key> bereits definiert wurden, <directory type> die in diesem Verzeichnis installierten Dateitypen impliziert, und <product owner> den Namen des Benutzers wiedergibt, der Eigentümer der Dateien ist und sie in diesem Verzeichnis installiert. /u01/app/oracle würde beispielsweise applikationsbezogene Dateien (Progammdateien) enthalten, die der Benutzer oracle auf dem Server installiert hat. Das Verzeichnis /u01/app/apache würde die Komponenten für den Middleware-Webserver enthalten, die von einer früheren Oracle-Version installiert wurden. Seit Oracle 10g erleichtert der OFA-Standard dem DBA das Installieren mehrerer Versionen von Datenbank- und Client-Software innerhalb des gleichen High-Level-Verzeichnisses. Der OFA-konforme Oracle Home-Pfad entspricht der Umgebungsvariable ORACLE_HOME und enthält eine Erweiterung, die dem Typ und der Inkarnation der Installation entspricht. So können beispielsweise in den folgenden drei Verzeichnissen eine Installation von Oracle 11g, zwei unterschiedliche Oracle 10g-Installationen und eine Installation von Oracle 9i liegen: /u01/app/oracle/product/ /u01/app/oracle/product/10.1.0/db_1 /u01/app/oracle/product/10.1.0/db_2 /u01/app/oracle/product/11.1.0/db_1 Gleichzeitig lassen sich die Oracle-Clientprogramme und -konfigurationen im gleichen Parent-Verzeichnis wie die Datenbankkomponenten hinterlegen: /u01/app/oracle/product/10.1.0/client_1 Manche Installationsverzeichnisse enthalten für ein gegebenes Produkt niemals mehr als eine Instanz. So werden die CRS (Oracle Cluster Ready Services) bei unserer Installation beispielsweise im folgenden Verzeichnis hinterlegt: /u01/app/oracle/product/10.1.0/crs Da sich die CRS auf jedem System nur einmal installieren lassen, hat es keine numerische Erweiterung. Datenbankdateien Alle Nicht-ASM-Datendateien liegen in /<mount point>/oradata/<database name>, wobei <mount point> einer der oben besprochenen Mount-Punkte ist. <database name> ist der Wert des Initialisierungsparameters DB_NAME. So würden /u02/oradata/rac0 und /u03/oradata/rac0 zum Beispiel die Nicht-ASM-Steuerdateien, Redo- Log- und Datendateien für die Instanz rac0 enthalten, und in /u05/oradata/dev1 liegen dieselben Dateien für die dev1-instanz, die auf dem gleichen Server läuft. Die Benennungskon-

11 78 3 Tablespaces planen und verwalten ventionen für die verschiedenen Dateitypen unter dem oradata-verzeichnis sind in Tabelle 3-1 zusammengefasst. Tabelle 3-1: OFA-konforme Benennungskonventionen für Steuerdateien, Redo-Logdateien und Tabelle 3-1: Datendateien. Dateityp Dateinamenformat Variablen Steuerdateien control.ctl Keine. Redo-Logdateien redo<n>.log n ist eine zweiziffrige Zahl. Datendateien <tn>.dbf t ist ein Oracle Tablespace-Name, und n eine zweiziffrige Zahl. Obwohl die Namen der Oracle-Tablespaces bis zu 30 Zeichen umfassen können, sollten die Namen in einer Unix-Umgebung maximal 8 Zeichen lang sein. Da portable Unix-Dateinamen auf 14 Zeichen beschränkt sind, und die Erweiterung eines OFA-Dateinamens <n>.dbf ist, wobei n zwei Ziffern sind, werden insgesamt sechs Zeichen für die Erweiterung im Dateisystem benötigt. Damit bleiben acht Zeichen für den Tablespace-Namen. Nur Steuerdateien, Redo-Logdateien und Datendateien, die zur Datenbank <database name> gehören, sollten im Verzeichnis /<mount point>/oradata/<database name> gespeichert sein. Für die Datenbank ord, die ohne ASM verwaltet wird, sind die Datendateinamen wie folgt: SQL> select file#, name from v$datafile; FILE# NAME /u05/oradata/ord/system01.dbf 2 /u05/oradata/ord/undotbs01.dbf 3 /u05/oradata/ord/sysaux01.dbf 4 /u05/oradata/ord/users01.dbf 5 /u09/oradata/ord/example01.dbf 6 /u09/oradata/ord/oe_trans01.dbf 7 /u05/oradata/ord/users02.dbf 8 /u06/oradata/ord/logmnr_rep01.dbf 9 /u09/oradata/ord/big_users.dbf 10 /u08/oradata/ord/idx01.dbf 11 /u08/oradata/ord/idx02.dbf 12 /u08/oradata/ord/idx03.dbf 13 /u08/oradata/ord/idx04.dbf 14 /u08/oradata/ord/idx05.dbf 15 /u08/oradata/ord/idx06.dbf 16 /u08/oradata/ord/idx07.dbf 17 /u08/oradata/ord/idx08.dbf 17 rows selected. Mit Ausnahme der Elemente mit den Nummern 8 und 9 sind alle Datendateien in der ord- Datenbank OFA-konform und über vier verschiedene Mount-Punkte verteilt. Der Tablespace-Name mit der Dateinummer 8 ist zu lang, und die Dateinummer 9 hat keinen numeri-

12 3.1 Tablespace-Architektur 79 schen, zwei Ziffern langen Zähler, und kann so für den gleichen Tablespace keine neuen Datendateien abbilden. ASM-Umgebung In einer ASM-Umgebung sind die ausführbaren Programme in der oben dargestellten Verzeichnisstruktur hinterlegt; wenn Sie sich in Abbildung 3-5 jedoch das Verzeichnis /u02/oradata ansehen, werden Sie keine Dateien finden. Alle Steuerdateien, Redo-Log- und Datendateien für die Instanz rac0 werden auf diesem Server von der ASM-Instanz +ASM verwaltet. Für die meisten administrativen Funktionen werden die tatsächlichen Datendateinamen nicht benötigt, da ASM-Dateien Oracle-verwaltete Dateien (OMFs) sind. Damit vereinfacht sich der gesamte Verwaltungsaufwand für die Datenbank. Innerhalb der ASM-Speicherstruktur wird zur weiteren Unterteilung der Dateitypen eine OMF-ähnliche Syntax eingesetzt: SQL> select file#, name from v$datafile; FILE# NAME DATA/dw/datafile/system DATA/dw/datafile/sysaux DATA/dw/datafile/undotbs DATA/dw/datafile/users DATA/dw/datafile/example rows selected. SQL> select name from v$controlfile; NAME DATA/dw/controlfile/current RECOV/dw/controlfile/current rows selected. SQL> select member from v$logfile; MEMBER DATA/dw/onlinelog/group_ RECOV/dw/onlinelog/group_ DATA/dw/onlinelog/group_ RECOV/dw/onlinelog/group_ DATA/dw/onlinelog/group_ RECOV/dw/onlinelog/group_ rows selected. Innerhalb der Laufwerksgruppe +DATA und +RECOV haben die verschiedenen Datenbankdateitypen, wie Datendateien, Steuerdateien und Online Redo-Logdateien, eigene Verzeichnisse. Voll qualifizierte ASM-Dateinamen haben das Format +<group>/<dbname>/<file type>/<tag>.<file>.<incarnation>

13 80 3 Tablespaces planen und verwalten wobei <group> der Laufwerksgruppenname ist. <dbname> ist die Datenbank, zu der die Dateien gehören. <file type> ist der Oracle-Dateityp, <tag> ist eine spezifische Information für den Dateityp, und das Paar <file>.<incarnation> sichert die Eindeutigkeit innerhalb der Laufwerksgruppe. Das Automatic Storage Management (ASM) wird in Kapitel 6 besprochen. 3.2 Tablespaces der Oracle-Installation Tabelle 3-2 führt die Tablespaces auf, die bei einer Standard-Oracle-Installation mit Hilfe des OUI (Oracle Universal Installer) angelegt werden. Der EXAMPLE-Tablespace ist optional. Er wird installiert, wenn Sie im Installationsdialog vorgeben, dass die Beispiel-Schemas einzurichten sind. Tabelle 3-2: Die Tablespaces einer Standard-Oracle-Installation. Tablespace Typ Segment-Platzverwaltung Ungefähre Anfangsgröße (MB) SYSTEM Permanent Manual 680 SYSAUX Permanent Auto 585 TEMP Temporary Manual 20 UNDOTBS1 Permanent Manual 115 USERS Permanent Auto 16 EXAMPLE Permanent Auto SYSTEM Wie weiter oben bereits erwähnt, sollte der SYSTEM-Tablespace keine Benutzersegmente enthalten. Die neue default tablespace-klausel im create database-befehl unterstützt diese Forderung, indem es allen Benutzern, für die explizit kein permanenter Tablespace definiert wurde, einen solchen zuweist. Eine Oracle-Installation mit dem Oracle Universal Installer weist den USERS-Tablespace automatisch als standardmäßigen permanenten Tablespace zu. Der SYSTEM-Tablespace wird relativ schnell wachsen, sobald Sie prozedurale Objekte wie Funktionen, Prozeduren, Trigger usw. einsetzen, weil diese Objekte im Data Dictionary liegen müssen. Das gilt auch für abstrakte Datentypen und andere objektorientierte Leistungsmerkmale SYSAUX Genau wie beim SYSTEM-Tablespace sollten auch im SYSAUX-Tablespace keine Benutzersegmente gespeichert sein. Falls ein bestimmter Nutzer des SYSAUX-Tablespace einen Großteil des verfügbaren Platzes belegt oder die Performance anderer Applikationen beeinträchtigt ist,

14 3.3 Segmentaufteilung 81 die gleichfalls mit diesem Tablespace arbeiten, sollten Sie diese Daten möglichst in einen anderen Tablespace verschieben TEMP Anstatt nur einen einzigen, großen temporären Tablespace anzulegen, sollten Sie mehrere kleinere Tablespaces einrichten und in einer temporären Tablespace-Gruppe zusammenführen. Wie weiter oben bereits erwähnt, kann das die Antwortzeiten für Applikationen verbessern, die zahlreiche Sitzungen mit dem gleichen Benutzernamen anlegen UNDOTBS1 Auch wenn eine Datenbank mehr als einen Undo-Tablespace enthalten kann, kann zu einem gegebenen Zeitpunkt immer nur ein Undo-Tablespace aktiv sein. Wird für einen Undo-Tablespace mehr Speicherplatz benötigt und AUTOEXTEND ist nicht aktiviert, lässt sich eine weitere Datendatei hinzufügen. Da in einer RAC (Real Application Clusters)-Umgebung jede Instanz ihre eigenen Undos verwaltet, muss für jeden Knoten ein Undo-Tablespace verfügbar sein USERS Der USERS-Tablespace ist für alle sonstigen Segmente gedacht, die ein Datenbankbenutzer anlegt. Allerdings lässt sich dieser Tablespace nicht für Produktionsanwendungen einsetzen. Stattdessen sollten Sie für jede Applikation und jeden Segmenttyp einen separaten Tablespace anlegen. Weiter unten beschreiben wir zusätzliche Kriterien für die Entscheidung, wann Segmente in eigene Tablespaces aufzuteilen sind EXAMPLE In einer Produktionsumgebung sollte man den EXAMPLE-Tablespace löschen. Er belegt 100MB Speicherplatz und enthält Beispiele für sämtliche Oracle-Segmente und -Datenstrukturen. Für Trainingszwecke kann man mit diesen Beispielschemas eine eigene Datenbank anlegen. In einer vorhandenen Trainingsdatenbank legt man die Beispielschemas mit den Skripten in $ORACLE_HOME/ demo/schema an. 3.3 Segmentaufteilung Als Faustregel gilt, dass man die Segmente basierend auf ihrem Typ, ihrer Größe und der Zugriffshäufigkeit auf verschiedene Tablespaces verteilt. Weiterhin wäre es vorteilhaft, diese Tablespaces in eigenständigen Diskgruppen oder separaten Laufwerken zu hinterlegen. In der Praxis gönnen sich allerdings nur wenige Datenbankbetreiber diesen Luxus. Die folgende Aufzählung zeigt verschiedene Bedingungen, anhand derer Sie entscheiden können, wie man die Segmente auf die Tablespaces verteilt. Prioritäten wurden keine gesetzt, da sich die Möglichkeiten aus der jeweiligen Konfigurationen ableiten. Setzt man das ASM (Automatic Storage

15 82 3 Tablespaces planen und verwalten Management) ein, erledigen sich viele der nachstehenden Punkte von selbst. Das ASM wird in Kapitel 4 erörtert. Große und kleine Segmente sollte man in separaten Tablespaces hinterlegen. Tabellensegmente und die dazugehörigen Indexsegmente sollten in separaten Tablespaces liegen. Für jede Applikation sollte ein eigener Tablespace zur Verfügung stehen. Segmente mit geringer und hoher Nutzung sollten in unterschiedlichen Tablespaces liegen. Statische Segmente sollten von Segmenten mit vielen DML-Zugriffen getrennt sein. Read-only-Tabellen sollte man in eigenen Tablespaces hinterlegen. Zwischengespeicherte Tabellen für ein Data Warehouse sollte man in einem eigenen Tablespace platzieren. Tablespaces sollte man in Abhängigkeit davon, ob der Segmentzugriff zeilenweise oder über einen Full Table Scan erfolgt, mit der korrekten Blockgröße anlegen. Materialisierte Views sollte man von den Basistabellen trennen und in einem separaten Tablespace speichern. Bei partitionierten Tabellen und Indizes sollte jede Partition in einem eigenen Tablespace liegen. Mit der EM Database Control lassen sich bei allen Tablespaces Konkurrenzsituationen ermitteln. Dazu werden die Hotspots auf Datei- oder Objektebene identifiziert. Im Zusammenhang mit dem Performancetuning (siehe Kapitel 8) werden wir uns auch mit dem Auflösen von Engpasssituationen auseinandersetzen.