Der Oracle-DBA: Handbuch für die Administration der Oracle Database 11g R2

andrea HELD mirko HOTZY lutz FRÖHLICH marek ADAR christian ANTOGNINI konrad HÄFELI daniel STEIGER sven VETTER peter WELK...

612 downloads 4315 Views 14MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

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

EXTRA: Mit kostenlosem E-Book Aktuell: Inklusive 11g Release 2

Held/Hotzy/Fröhlich/Adar/Antognini/Häfeli/Steiger/Vetter/Welker Der Oracle-DBA

v

Bleiben Sie einfach auf dem Laufenden: www.hanser.de/newsletter Sofort anmelden und Monat für Monat die neuesten Infos und Updates erhalten.

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

Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso übernehmen Autoren und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. © 2011 Carl Hanser Verlag München (www.hanser.de) Lektorat: Margarete Metzger Herstellung: Irene Weilhart Copy editing: Wolfgang Taschner, Wörthsee Umschlagdesign: Marc Müller-Bremer, www.rebranding.de, München Umschlagrealisation: Stephan Rönigk Datenbelichtung, Druck und Bindung: Kösel, Krugzell Ausstattung patentrechtlich geschützt. Kösel FD 351, Patent-Nr. 0748702 Printed in Germany Print-ISBN: 978-3-446-42081-6 e-Book-ISBN: 978-3-446-42933-8

Inhalt Vorwort............................................................................................................................. XXI 1

Schnelleinstieg......................................................................................................... 1

1.1

1.6 1.7 1.8

Die Datenbank-Software installieren .......................................................................................2 1.1.1 Die Installation vorbereiten ........................................................................................2 1.1.2 Die Installation durchführen.......................................................................................6 Eine Datenbank erstellen........................................................................................................12 Administrationswerkzeuge.....................................................................................................19 Erste Administrations-Schritte ...............................................................................................23 Produktübersicht ....................................................................................................................29 1.5.1 Oracle-Editionen ......................................................................................................29 1.5.2 Management Packs und Plugins ...............................................................................31 Online-Hilfe (My Oracle Support) .........................................................................................33 Die Oracle-Dokumentation ....................................................................................................35 Resümee.................................................................................................................................36

2

Architektur und Administration ............................................................................ 37

2.1 2.2

Datenbank und Instanz...........................................................................................................38 Physische Architektur einer Oracle-Datenbank......................................................................38 2.2.1 Datenblöcke..............................................................................................................42 2.2.2 Datafiles ...................................................................................................................44 2.2.3 Tablespaces ..............................................................................................................45 2.2.4 Informationen zu Tablespaces im Data Dictionary...................................................49 2.2.5 Empfehlungen zum Tabelspace-Layout ...................................................................49 2.2.6 Redologs...................................................................................................................51 2.2.7 Controlfiles...............................................................................................................53 2.2.8 Parameterfile ............................................................................................................55 2.2.9 Passwordfile .............................................................................................................56 2.2.10 Alert- und Trace-Dateien..........................................................................................57

1.2 1.3 1.4 1.5

V

Inhalt 2.2.11 Flashback Logs......................................................................................................... 58 2.2.12 Block-Change-Tracking-Protokoll ........................................................................... 59 2.3

2.4

2.5

2.6

2.7

VI

Instanz: Arbeitsspeicher- und Prozessarchitektur .................................................................. 60 2.3.1 System Global Area (SGA)...................................................................................... 60 2.3.2 Program Global Area (PGA) .................................................................................... 66 2.3.3 Memory Management .............................................................................................. 67 2.3.4 Prozesse.................................................................................................................... 70 Konsistenz der Datenbank ..................................................................................................... 74 2.4.1 Transaktionsmanagement......................................................................................... 74 2.4.2 Lesekonsistenz ......................................................................................................... 75 2.4.3 Undo Management ................................................................................................... 75 2.4.4 Sperren ..................................................................................................................... 76 2.4.5 Isolation Level.......................................................................................................... 77 2.4.6 System Change Number (SCN)................................................................................ 78 2.4.7 Checkpoints.............................................................................................................. 78 2.4.8 Crash Recovery ........................................................................................................ 80 Start und Stopp einer Oracle-Datenbank................................................................................ 81 2.5.1 Phasen während des Startup ..................................................................................... 81 2.5.2 Phasen während des Shutdowns............................................................................... 83 2.5.3 Startup-Befehle ........................................................................................................ 84 2.5.4 Shutdown-Befehle.................................................................................................... 86 Verwaltung von Tablespaces ................................................................................................. 89 2.6.1 Informationen zu bestehenden Tablespaces ermitteln .............................................. 89 2.6.2 Tablespaces erstellen................................................................................................ 92 2.6.3 Tablespace umbenennen .......................................................................................... 95 2.6.4 Tablespaces vergrößern und verkleinern .................................................................. 96 2.6.5 Datafiles zu Tablespaces hinzufügen ....................................................................... 98 2.6.6 Datafiles verschieben oder umbenennen .................................................................. 98 2.6.7 Tablespaces löschen ................................................................................................. 99 2.6.8 Datafiles löschen .................................................................................................... 100 2.6.9 Default- und Temporary-Tablespace für Benutzer setzen ...................................... 101 2.6.10 Offline- und Online-Setzen eines Tablespaces....................................................... 101 2.6.11 Read-Only- und Read-Write-Setzen....................................................................... 102 2.6.12 Aktivieren und Deaktivieren des Logging für Tablespaces.................................... 103 2.6.13 Verwaltung von Undo Tablespaces........................................................................ 104 2.6.14 Verwaltung von Temporary Tablespaces ............................................................... 111 Verwaltung von Redologs.................................................................................................... 113 2.7.1 Informationen zu Redologs aus dem Data Dictionary ermitteln............................. 114 2.7.2 Redolog-Historie .................................................................................................... 114 2.7.3 Empfehlungen zur Konfiguration von Redologs .................................................... 115 2.7.4 Anlegen einer Redolog-Gruppe.............................................................................. 117 2.7.5 Hinzufügen eines weiteren Mitglieds zu einer bestehenden Gruppe ...................... 117 2.7.6 Löschen eines Mitglieds einer Redolog-Gruppe .................................................... 117 2.7.7 Löschen einer Redolog-Gruppe.............................................................................. 118 2.7.8 Wechseln der Redolog-Gruppe .............................................................................. 118 2.7.9 Verschieben und Umbenennen von Redologs........................................................ 119

Inhalt

2.8

2.9

2.10

2.11

2.12

2.7.10 Logfiles bereinigen.................................................................................................119 2.7.11 Redologs für Real Application Clusters (RAC)......................................................120 2.7.12 Der Archive Log Modus.........................................................................................120 Verwaltung der Controlfiles.................................................................................................122 2.8.1 Informationen zu Controlfiles ermitteln .................................................................122 2.8.2 Controlfiles spiegeln...............................................................................................122 2.8.3 Controlfiles durch eine Kopie sichern ....................................................................123 2.8.4 Controlfiles mit einem Trace dumpen ....................................................................123 Parametrisierung ..................................................................................................................124 2.9.1 Der Startvorgang mit Parameterfile........................................................................124 2.9.2 Welche Parameterdatei wird aktuell verwendet?....................................................126 2.9.3 Ändern der Parametrisierung..................................................................................126 2.9.4 Zurücksetzen eines Parameters...............................................................................127 2.9.5 Probleme bei der Änderung der Parametrisierung..................................................127 2.9.6 Aktuelle Parametrisierung ermitteln.......................................................................128 2.9.7 Parameter zur Datenbank- und Instanz-Konfiguration ...........................................128 2.9.8 Verdeckte Parameter ..............................................................................................130 2.9.9 PFiles und SPFiles erzeugen...................................................................................130 Passwort-Dateien verwalten.................................................................................................131 2.10.1 Passwort-Datei erstellen .........................................................................................131 2.10.2 Passwort-Dateien und Datenbankparameter ...........................................................132 2.10.3 Priviligierte Benutzer einer Passwort-Datei hinzufügen und entfernen ..................132 Weitere Administrationsbefehle...........................................................................................133 2.11.1 Ändern des Globalen Namens der Datenbank ........................................................133 2.11.2 Ändern des Zeichensatzes ......................................................................................133 2.11.3 Benutzerverbindungen beenden: Kill Session ........................................................135 2.11.4 Benutzerverbindungen beenden: Disconnect Session.............................................136 2.11.5 Benutzersessions sperren: Restricted Mode............................................................136 2.11.6 Benutzeraktionen unterbinden: Quiesce Restricted ................................................137 2.11.7 Einen Checkpoint erzwingen..................................................................................138 2.11.8 Den Blockpuffer leeren: Flush buffer_cache..........................................................138 2.11.9 Den Shared Pool leeren: Flush shared_pool ...........................................................138 2.11.10 Den Inhalt eines Datenblockes dumpen..................................................................139 Informationen zur Datenbank ermitteln ...............................................................................140 2.12.1 Statische Data Dictionary Views ............................................................................140 2.12.2 Dynamische Performance Views............................................................................141 2.12.3 Allgemeine Informationen zur Datenbank..............................................................142 2.12.4 Startzeit und Status der Instanz...............................................................................143 2.12.5 Hostname und Instanz-Name..................................................................................143 2.12.6 Spracheinstellungen und Zeichensätze ...................................................................143 2.12.7 Aktuelle Datenbankversion ....................................................................................143 2.12.8 Installierte Oracle-Optionen ...................................................................................144 2.12.9 Größen der Caches der SGA ..................................................................................144 2.12.10 Pfad zu Trace-Dateien und Alertlog .......................................................................144 2.12.11 Datenbank-Benutzer ...............................................................................................145 2.12.12 Rechte und Rollen eines Datenbank-Benutzers ......................................................145

VII

Inhalt

2.14

2.12.13 Datenbankobjekte................................................................................................... 146 2.12.14 Offene Datenbankverbindungen............................................................................. 147 2.12.15 Aktive Sessions ...................................................................................................... 147 2.12.16 SQL-Statement nach Session ................................................................................. 147 2.12.17 Waits ...................................................................................................................... 147 2.12.18 Langlaufende Operationen ..................................................................................... 148 2.12.19 Sperren in der Datenbank ....................................................................................... 148 2.12.20 Die aktuelle System Change Number (SCN) ermitteln .......................................... 149 Verwaltungswerkzeuge........................................................................................................ 149 2.13.1 Der Oracle Enterprise Manager (OEM) ................................................................. 150 2.13.2 Der Oracle SQL Developer .................................................................................... 171 2.13.3 Toad ....................................................................................................................... 175 Resümee............................................................................................................................... 178

3

Verwaltung von Datenbankobjekten .................................................................. 179

3.1 3.2 3.3 3.4 3.5 3.6

Benutzer und Schemata........................................................................................................ 179 Bezeichner ........................................................................................................................... 180 Speicherhierarchie................................................................................................................ 181 Zeichensätze ........................................................................................................................ 183 Datentypen........................................................................................................................... 185 Speicherorganisation von Tabellen ...................................................................................... 186 3.6.1 Heap Tables............................................................................................................ 187 3.6.2 Index Organized Tables (IOTs).............................................................................. 187 3.6.3 Object Tables ......................................................................................................... 189 3.6.4 Global Temporary Tables....................................................................................... 190 3.6.5 External Tables....................................................................................................... 191 3.6.6 Geclusterte Tabellen............................................................................................... 192 3.6.7 Tabellenkomprimierung ......................................................................................... 195 3.6.8 Tabellenpartitionierung .......................................................................................... 195 Administrationsbefehle für Tabellen.................................................................................... 195 3.7.1 Tabellen erstellen ................................................................................................... 195 3.7.2 Erstellen einer Tabelle aus einem Select-Statement ............................................... 196 3.7.3 Tabellen kopieren................................................................................................... 196 3.7.4 Tabellennamen ändern ........................................................................................... 197 3.7.5 Tabelleneigenschaften ändern ................................................................................ 197 3.7.6 Löschen einer Tabelle ............................................................................................ 197 3.7.7 Tablespace zuordnen .............................................................................................. 198 3.7.8 Eine Tabelle in einen anderen Tablespace verschieben.......................................... 198 3.7.9 Extent-Größen festlegen......................................................................................... 199 3.7.10 Einstellen der Größe des Transaktionsheaders ....................................................... 199 3.7.11 Verzögerte Speicherallokation / Deferred Segment Creation................................. 200 3.7.12 Cache / Nocache / Cache Reads ............................................................................. 201 3.7.13 Logging und Nologging ......................................................................................... 202 3.7.14 Parallelisierung....................................................................................................... 202 3.7.15 Schreibschutz für Tabellen: Read Only / Read write.............................................. 203

2.13

3.7

VIII

Inhalt

3.8

3.9

3.10

3.7.16 Spalten hinzufügen .................................................................................................203 3.7.17 Spaltennamen ändern..............................................................................................204 3.7.18 Default-Werte für Spalten vergeben .......................................................................204 3.7.19 Spaltendefinitionen ändern .....................................................................................204 3.7.20 Spalten physisch löschen........................................................................................205 3.7.21 Spalten logisch löschen ..........................................................................................206 3.7.22 Speicherplatz einer Tabelle ermitteln .....................................................................206 3.7.23 Speicherplatz freigeben ..........................................................................................207 3.7.24 Tabellen leeren mit Truncate Table ........................................................................208 3.7.25 Wichtige Rechte rund um Tabellen ........................................................................210 3.7.26 Informationen zu Tabellen und Spalten im Data Dictionary ..................................210 Constraints ...........................................................................................................................211 3.8.1 Not Null..................................................................................................................212 3.8.2 Unique ....................................................................................................................212 3.8.3 Primary Key ...........................................................................................................212 3.8.4 Foreign Key............................................................................................................213 3.8.5 Check-Contraints....................................................................................................214 3.8.6 Aktivierung und Deaktivierung von Constraints ....................................................215 3.8.7 Verzögerte Überprüfung.........................................................................................216 3.8.8 Umbenennen von Constraints.................................................................................216 3.8.9 Entfernen von Constraints ......................................................................................217 3.8.10 Wichtige Rechte rund um Constraints ....................................................................217 3.8.11 Informationen zu Constraints im Data Dictionary..................................................217 Views ...................................................................................................................................218 3.9.1 Standard-Views ......................................................................................................218 3.9.2 Materialized Views.................................................................................................219 3.9.3 Objekt-Views .........................................................................................................220 3.9.4 Wichtige Rechte rund um Views............................................................................221 3.9.5 Informationen zu Views im Data Dictionary..........................................................221 Indizes..................................................................................................................................222 3.10.1 B*Baum..................................................................................................................222 3.10.2 Bitmap Index ..........................................................................................................224 3.10.3 Reverse Key Index .................................................................................................225 3.10.4 Funktionsbasierter Index ........................................................................................225 3.10.5 Unique Index ..........................................................................................................226 3.10.6 Online Erstellung eines Index.................................................................................227 3.10.7 Speicherparameter: Tablespace und Extentgrößen .................................................227 3.10.8 Einstellen der Größe des Transaktionsheaders .......................................................227 3.10.9 Reorganisation / Index Rebuild ..............................................................................228 3.10.10 Speicherplatz eines Index ermitteln........................................................................229 3.10.11 Speicherplatz freigeben ..........................................................................................229 3.10.12 Deaktivieren eines Index ........................................................................................230 3.10.13 Invisible Index........................................................................................................231 3.10.14 Logging ..................................................................................................................232 3.10.15 Parallelisierung.......................................................................................................232 3.10.16 Umbenennen eines Index........................................................................................233

IX

Inhalt

3.11

3.12

3.13

3.14

3.15

Resümee............................................................................................................................... 241

4

Speicherplatzverwaltung..................................................................................... 243

4.1

Datenbank-Speicheroptionen ............................................................................................... 244 4.1.1 Eigenschaften eines Speichersystems..................................................................... 245 4.1.2 Filesysteme............................................................................................................. 248 4.1.3 Raw-Devices .......................................................................................................... 250 4.1.4 Automatic Storage Management ............................................................................ 253 4.1.5 Die Auswahl der Datenbank-Speicheroption ......................................................... 255 Data-, Temp- und Redolog-File-Attribute............................................................................ 255 4.2.1 Initial Size .............................................................................................................. 256 4.2.2 Automatische Filevergrößerung ............................................................................. 257 4.2.3 Manuelle Filevergrößerung .................................................................................... 258 Extent Management Optionen.............................................................................................. 258 4.3.1 Extent Map............................................................................................................. 259 4.3.2 Storage-Parameter .................................................................................................. 260 4.3.3 Extent-Allozierung ................................................................................................. 260 4.3.4 Dictionary Managed Tablespaces........................................................................... 263 4.3.5 Locally Managed Tablespaces ............................................................................... 264 4.3.6 Auswahl der Extent-Management-Optionen .......................................................... 267 Segmentspace-Verwaltung................................................................................................... 268 4.4.1 High-Water Mark ................................................................................................... 269 4.4.2 Manuelle Segmentspace-Verwaltung ..................................................................... 271 4.4.3 Automatische Segmentspace-Verwaltung .............................................................. 273

4.2

4.3

4.4

X

3.10.17 Monitoring der Index-Nutzung............................................................................... 233 3.10.18 Wichtige Rechte rund um Indizes .......................................................................... 234 3.10.19 Informationen zu Indizes im Data Dictionary ........................................................ 234 Synonyme ............................................................................................................................ 235 3.11.1 Public Synonym ..................................................................................................... 235 3.11.2 Wichtige Rechte rund um Synonyme..................................................................... 235 3.11.3 Informationen zu Synonymen im Data Dictionary................................................. 236 Datenbank-Links.................................................................................................................. 236 3.12.1 Public Database-Link ............................................................................................. 237 3.12.2 Verbindungsdescriptor zur Remote-Datenbank...................................................... 237 3.12.3 Rechte zu Datenbank-Links ................................................................................... 237 3.12.4 Informationen zu Datenbank-Links im Data Dictionary ........................................ 238 Sequenzen ............................................................................................................................ 238 3.13.1 Rechte zu Sequenzen.............................................................................................. 239 3.13.2 Informationen zu Sequenzen im Data Dictionary................................................... 239 PL/SQL-Programme ............................................................................................................ 239 3.14.1 Stored Procedures / Functions................................................................................ 239 3.14.2 Packages................................................................................................................. 239 3.14.3 Trigger.................................................................................................................... 240 3.14.4 Wichtige Rechte rund um PL/SQL-Programme..................................................... 240 3.14.5 Informationen zu PL/SQL-Programmen im Data Dictionary................................. 240

Inhalt

4.7

4.4.4 Auswahl einer Segmentspace-Verwaltungsoption..................................................276 Zusätzliche Segmentoptionen ..............................................................................................276 4.5.1 Interested Transaction List (ITL)............................................................................276 4.5.2 Minimal Logging....................................................................................................278 Reorganisationen..................................................................................................................280 4.6.1 Datensatzmigration und Datensatzverkettung ........................................................280 4.6.2 Verschieben von Segmenten ..................................................................................283 4.6.3 Verschieben von Tabelleninhalten .........................................................................284 4.6.4 Rückgewinnung von freiem Platz...........................................................................285 Resümee...............................................................................................................................287

5

Automatic Storage Management ........................................................................ 289

5.1 5.2

5.9

Die ASM-Architektur im Überblick.....................................................................................289 Eine ASM-Umgebung konfigurieren ...................................................................................291 5.2.1 Die Software bereitstellen ......................................................................................291 5.2.2 Manuelle ASM-Konfiguration ...............................................................................292 5.2.3 ASM-Disks auf spezifischen Plattformen...............................................................294 5.2.4 Der Discovery-Prozess ...........................................................................................297 5.2.5 Der ASMCA...........................................................................................................298 5.2.6 ASM im Enterprise Manager..................................................................................299 ASM-Disks, -Diskgruppen und -Fehlergruppen...................................................................301 Das Utility ASMCMD .........................................................................................................306 ASM-Sicherheit ...................................................................................................................308 ASM Monitoring, Performance und Troubleshooting..........................................................309 Eine Datenbank nach ASM konvertieren .............................................................................313 Das ASM Cluster File-System (ACFS)................................................................................316 5.8.1 General Purpose ACFS-Dateisystem......................................................................318 5.8.2 CRS Managed ACFS-Dateisystem.........................................................................319 5.8.3 ACFS Snapshots.....................................................................................................320 5.8.4 ACFS verwalten .....................................................................................................321 Resümee...............................................................................................................................321

6

Security................................................................................................................. 323

6.1

Authentifizierung .................................................................................................................323 6.1.1 Benutzername/Passwort .........................................................................................323 6.1.2 Authentifizierung über Betriebssystem ..................................................................327 6.1.3 Authentifizierung per SSL und Zertifikaten ...........................................................328 6.1.4 Proxyuser................................................................................................................329 Autorisierung .......................................................................................................................330 6.2.1 Systemprivilegien...................................................................................................330 6.2.2 Objektprivilegien....................................................................................................331 6.2.3 Berechtigungen auf Directories ..............................................................................332 6.2.4 Fine-Grained Access für Netzwerk-Callouts ..........................................................333 6.2.5 Rollen .....................................................................................................................334

4.5

4.6

5.3 5.4 5.5 5.6 5.7 5.8

6.2

XI

Inhalt

6.5

6.2.6 Überwachung von Privilegien ................................................................................ 336 6.2.7 Virtual Private Database......................................................................................... 336 6.2.8 Database Vault ....................................................................................................... 339 Auditing ............................................................................................................................... 341 6.3.1 Standardauditing .................................................................................................... 342 6.3.2 Auditing mit Triggern ............................................................................................ 348 6.3.3 Fine Grained Auditing............................................................................................ 349 6.3.4 Audit Vault............................................................................................................. 351 Verschlüsselung ................................................................................................................... 354 6.4.1 Verschlüsselung der Oracle Dateien....................................................................... 354 6.4.2 Verschlüsselung und Integritätsprüfung des Netzwerkverkehrs............................. 358 Resümee............................................................................................................................... 362

7

Oracle Net............................................................................................................. 363

7.1

Oracle Net Architektur......................................................................................................... 364 7.1.1 Involvierte Komponenten....................................................................................... 364 7.1.2 Netzwerkschichten ................................................................................................. 365 7.1.3 Oracle Net in den Applikations-Topologien........................................................... 366 7.1.4 Servicenamen ......................................................................................................... 368 7.1.5 Service Registrierung ............................................................................................. 369 7.1.6 Aufbau einer Verbindung zur Datenbank............................................................... 369 7.1.7 Konfigurationsdateien ............................................................................................ 370 Konfiguration....................................................................................................................... 371 7.2.1 Verbindungsprofile mit sqlnet.ora.......................................................................... 371 7.2.2 Serverseitig............................................................................................................. 372 7.2.3 Clientseitig ............................................................................................................. 378 7.2.4 Ausfalltolerante Verbindungen .............................................................................. 382 Werkzeuge ........................................................................................................................... 385 7.3.1 Manuell .................................................................................................................. 385 7.3.2 Net Configuration Assistant ................................................................................... 386 7.3.3 Net Manager........................................................................................................... 388 7.3.4 Im RAC: Service-Konfiguration (srvctl) und DBCA ............................................. 392 Performance-Optimierung ................................................................................................... 393 7.4.1 Parametrisierung .................................................................................................... 394 7.4.2 Timeouts für nicht autorisierte User....................................................................... 396 7.4.3 Database Resident Connection Pooling (DRCP).................................................... 396 Fehlersuche .......................................................................................................................... 397 7.5.1 Werkzeuge ............................................................................................................. 397 7.5.2 Logging und Tracing.............................................................................................. 399 7.5.3 Log- und Tracefiles ................................................................................................ 401 Empfehlungen...................................................................................................................... 402 Resümee............................................................................................................................... 403

6.3

6.4

7.2

7.3

7.4

7.5

7.6 7.7

XII

Inhalt 8

Optimierung.......................................................................................................... 405

8.1

8.7

Designing for Performance ..................................................................................................405 8.1.1 Unzulänglichkeiten im logischen Datenbankdesign ...............................................406 8.1.2 Implementation von generischen Tabellen .............................................................406 8.1.3 Verzicht auf Constraints .........................................................................................407 8.1.4 Unzulängliches physisches Datenbankdesign.........................................................407 8.1.5 Falsche Datentyp-Auswahl.....................................................................................408 8.1.6 Inkorrekte Verwendung von Bindvariablen............................................................408 8.1.7 Fehlender Einsatz von Advanced Datenbankfeatures.............................................409 8.1.8 Fehlende Verwendung von Stored-Procedures.......................................................409 8.1.9 Ausführung von unnötigen Commits......................................................................410 8.1.10 Häufiges Öffnen und Schließen von Datenbankverbindungen ...............................410 8.1.11 Verzicht auf Lasttests .............................................................................................410 Konfigurationsempfehlungen...............................................................................................411 8.2.1 Initialisierungsparameter ........................................................................................411 8.2.2 Systemstatistiken ....................................................................................................417 8.2.3 Objektstatistiken.....................................................................................................419 Vorgehen bei Performance-Problemen ................................................................................420 8.3.1 Probleme einordnen................................................................................................421 8.3.2 Probleme lösen .......................................................................................................422 Identifikation von Performance-Problemen .........................................................................422 8.4.1 Die Analyse von reproduzierbaren Problemen .......................................................423 8.4.2 Echtzeitanalyse von nichtreproduzierbaren Problemen ..........................................430 8.4.3 Nachträgliche Analyse von nichtreproduzierbaren Problemen...............................441 Ausführungspläne ................................................................................................................447 8.5.1 Ermittlung des Ausführungsplans...........................................................................447 8.5.2 Interpretation von Ausführungsplänen ...................................................................452 8.5.3 Erkennen von ineffizienten Ausführungsplänen.....................................................455 Methoden zur Lösung von Performance-Problemen ............................................................459 8.6.1 Verhinderung unnötiger Arbeit ..............................................................................459 8.6.2 Datenbankaufrufe schneller machen.......................................................................459 8.6.3 Ressourcen-Verwaltung .........................................................................................462 8.6.4 Hardware-Upgrade .................................................................................................463 Resümee...............................................................................................................................463

9

Troubleshooting................................................................................................... 465

9.1 9.2 9.3 9.4 9.5 9.6

Alert.log ...............................................................................................................................465 Automatic Diagnostic Repository ........................................................................................468 Health Monitoring................................................................................................................469 Data Recovery Advisor ........................................................................................................475 Support Workbench .............................................................................................................477 My Oracle Support ORA-600/ORA-7445 Lookup-Tool......................................................480 9.6.1 Best-Practice-Guideline für das ORA-600/7445-Lookup-Tool ..............................482 9.6.2 Bereitstellung der richtigen Informationen für den Support ...................................484 Resümee...............................................................................................................................485

8.2

8.3

8.4

8.5

8.6

9.7

XIII

Inhalt 10

Jobsteuerung ....................................................................................................... 487

10.1 10.2

10.3

Oracle Jobs (dbms_job) ....................................................................................................... 487 Oracle Scheduler (dbms_scheduler)..................................................................................... 488 10.2.1 Einfache Jobs (PL/SQL)......................................................................................... 488 10.2.2 Einfache Jobs (extern)............................................................................................ 490 10.2.3 Jobs und Wiederverwendbarkeit ............................................................................ 492 10.2.4 Jobketten ................................................................................................................ 494 10.2.5 Wartungsfenster (Automatic Maintenance Tasks) ................................................. 497 10.2.6 Advanced Features ................................................................................................. 498 10.2.7 Privilegien .............................................................................................................. 502 Resümee............................................................................................................................... 503

11

Monitoring ............................................................................................................ 505

11.1

Monitoring-Architektur........................................................................................................ 506 11.1.1 Automatic Diagnostic Repository .......................................................................... 507 11.1.2 ADRCI – Die Schnittstelle zum ADR.................................................................... 507 11.1.3 Enterprise Manager Support Workbench ............................................................... 508 11.1.4 Incident Package Service (IPS) .............................................................................. 509 11.1.5 Automatic Workload Repository (AWR)............................................................... 509 Monitoring-Datenbasis ........................................................................................................ 510 11.2.1 Alert-Log................................................................................................................ 510 11.2.2 Tracefiles, Dumps und Corefiles............................................................................ 511 11.2.3 Data Dictionary Views ........................................................................................... 511 11.2.4 Datenbankmetriken ................................................................................................ 512 11.2.5 Server Generated Alerts ......................................................................................... 514 11.2.6 Baseline Metric Thresholds und Adaptive Thresholds........................................... 514 11.2.7 User Defined Metrics ............................................................................................. 515 11.2.8 Policies................................................................................................................... 516 Monitoring von Oracle Datenbanken................................................................................... 518 11.3.1 Überwachung der Serviceverfügbarkeit ................................................................. 518 11.3.2 ORA-Fehlermeldungen und Alerts......................................................................... 519 11.3.3 Monitoring der Systemaktivität.............................................................................. 521 11.3.4 Platzüberwachung .................................................................................................. 522 11.3.5 Überwachung von Sicherheitsrichtlinien................................................................ 528 11.3.6 Monitoring von SQL-Befehlen............................................................................... 529 11.3.7 Monitoring der CPU-Auslastung............................................................................ 532 11.3.8 Monitoring von RMAN-Backups........................................................................... 533 11.3.9 Überwachung von Konfigurationsänderungen ....................................................... 536 11.3.10 Locking (Hang Manager) ....................................................................................... 537 11.3.11 Best-Practice (Basis-Monitoring)........................................................................... 538 Monitoring-Werkzeuge........................................................................................................ 541 11.4.1 Auswahlkriterien für Monitoring-Werkzeuge ........................................................ 541 11.4.2 Database Control / Grid Control............................................................................. 542 11.4.3 Health Monitor ....................................................................................................... 543 11.4.4 SQL Developer....................................................................................................... 544

11.2

11.3

11.4

XIV

Inhalt

11.5

11.4.5 Werkzeuge anderer Tool-Anbieter .........................................................................544 Resümee...............................................................................................................................545

12

Aufbau und Betrieb eines Datenbankservers.................................................... 547

12.1 12.2 12.3

12.7

Der Lifecycle eines Datenbankservers .................................................................................547 Oracle-Plattform...................................................................................................................548 Betriebssystembenutzer und Berechtigungen.......................................................................550 12.3.1 Software-Owner und Betriebssystembenutzer........................................................550 12.3.2 Home-Verzeichnis der User „oracle“ und „grid“ ...................................................551 12.3.3 Betriebssystemgruppen...........................................................................................551 12.3.4 File-Permissions, Ownership und umask................................................................552 Oracle-Verzeichnisstruktur ..................................................................................................553 12.4.1 Optimal Flexible Architecture (OFA).....................................................................553 12.4.2 Die „/u00“-Philosophie ..........................................................................................554 12.4.3 Mountpoints ...........................................................................................................555 12.4.4 Der OFA-Verzeichnisbaum....................................................................................555 12.4.5 ORACLE_BASE....................................................................................................556 12.4.6 ORACLE_HOME ..................................................................................................557 12.4.7 Shared-Home-Installationen...................................................................................557 12.4.8 Multi-Home-Installationen .....................................................................................557 12.4.9 OUI-Inventory ........................................................................................................558 12.4.10 Automatic Diagnostic Repository (ADR)...............................................................558 Verwaltung des Oracle-Environments .................................................................................559 Betrieb eines Oracleservers..................................................................................................560 12.6.1 Das Betriebshandbuch ............................................................................................561 12.6.2 Monitoring und Reporting ......................................................................................562 12.6.3 Backup und Recovery.............................................................................................563 12.6.4 Maintenance ...........................................................................................................563 Resümee...............................................................................................................................564

13

Backup und Recovery ......................................................................................... 565

13.1

Übersicht ..............................................................................................................................565 13.1.1 Entwicklung eines Sicherungskonzepts..................................................................565 13.1.2 Offline- und Online-Sicherung ...............................................................................566 13.1.3 Logische und physische Sicherung.........................................................................566 13.1.4 Restore und Recovery.............................................................................................567 13.1.5 Vollsicherung, inkrementelle und differentielle Sicherung ....................................567 13.1.6 Flash Recovery Area / Fast Recovery Area (FRA).................................................568 13.1.7 Werkzeuge zur Sicherung und Wiederherstellung..................................................568 Betriebssystemkopie ............................................................................................................568 13.2.1 Offline-Backup mit Betriebssystemmitteln ............................................................569 13.2.2 Online-Backup mit Betriebssystemmitteln .............................................................571 13.2.3 Dateien im Backup-Modus identifizieren...............................................................575 13.2.4 Troubleshooting: „Datafile needs Recovery” .........................................................575 13.2.5 Wiederherstellung aus einer Betriebssystemsicherung...........................................575

12.4

12.5 12.6

13.2

XV

Inhalt

XVI

13.3

Recovery Manager (RMAN) ............................................................................................... 577 13.3.1 RMAN-Komponenten .......................................................................................... 577 13.3.2 Backup-Sets und Image-Kopien........................................................................... 578 13.3.3 Aufruf und Anmeldung ........................................................................................ 578 13.3.4 Interaktiver Modus und Batch-Modus.................................................................. 578 13.3.5 Anzeige aktueller Konfigurationen mit show all .................................................. 579 13.3.6 Sicherungsoptimierung......................................................................................... 579 13.3.7 Maximale Größe von Backups konfigurieren....................................................... 580 13.3.8 Standard-Konfiguration von Channels ................................................................. 580 13.3.9 Parallelisierung..................................................................................................... 581 13.3.10 Duplexing............................................................................................................. 581 13.3.11 Komprimierung .................................................................................................... 582 13.3.12 Verschlüsselung von Sicherungen........................................................................ 582 13.3.13 Ausschließen von Tablespaces ............................................................................. 583 13.3.14 Limitierung der Bandbreite .................................................................................. 584 13.3.15 Zurücksetzen der RMAN-Konfiguration auf den Standardwert ........................... 584 13.3.16 Aufbewahrungszeit von Informationen im Controlfile......................................... 584 13.3.17 Sicherungen auf Band einbinden.......................................................................... 585 13.3.18 Mehrere Befehle in einem Run-Block bündeln .................................................... 586 13.3.19 Durchführung einer Sicherung mit RMAN .......................................................... 587 13.3.20 Sicherung der Datenbank im Online- und Offline-Modus.................................... 587 13.3.21 Inkrementelle Sicherung der Datenbank............................................................... 588 13.3.22 Sichern von archivierten Redologs....................................................................... 589 13.3.23 Sichern des Controlfiles und SPFiles ................................................................... 589 13.3.24 Sichern von Sicherungsdateien............................................................................. 590 13.3.25 Sprechende Namen mit Tags vergeben ................................................................ 590 13.3.26 Pfade und Namensformate der Backup-Pieces ..................................................... 590 13.3.27 Monitoren des Job-Fortschritts............................................................................. 591 13.3.28 Reports zu Sicherungen........................................................................................ 591 13.3.29 Prüfung auf Korruptionen..................................................................................... 592 13.3.30 Löschen alter Sicherungen und Dateien ............................................................... 592 13.3.31 Löschen archivierter Redologs ............................................................................. 593 13.3.32 Langzeitsicherungen............................................................................................. 593 13.3.33 Recovery-Katalog................................................................................................. 594 13.3.34 RMAN Virtual Private Catalog ............................................................................ 596 13.3.35 Wiederherstellung: Übersicht ............................................................................... 597 13.3.36 Wiederherstellung eines Datenblockes................................................................. 598 13.3.37 Wiederherstellung einer Datendatei ..................................................................... 599 13.3.38 Wiederherstellung eines Tablespaces ................................................................... 599 13.3.39 Wiederherstellung einer Datenbank ..................................................................... 600 13.3.40 Unvollständige Wiederherstellung / Point in Time Recovery .............................. 600 13.3.41 Wiederherstellung der Controlfiles....................................................................... 601 13.3.42 Data Recovery Advisor (DRA) ............................................................................ 602 13.3.43 Übersicht der RMAN-Befehle.............................................................................. 603 13.3.44 Monitoring und Troubleshooting.......................................................................... 604

13.4

Data Pump ........................................................................................................................... 604

Inhalt

13.7

13.4.1 Übersicht ................................................................................................................605 13.4.2 Befehle ...................................................................................................................606 13.4.3 Parameter................................................................................................................607 13.4.4 Monitoring der Data-Pump-Jobs ............................................................................609 Restore Points ......................................................................................................................609 Flashback .............................................................................................................................610 13.6.1 Flashback Database / Zurücksetzen der Datenbank................................................611 13.6.2 Flashback Table / Zurücksetzen einer Tabelle........................................................611 13.6.3 Flashback Drop / Wiederherstellen einer gelöschten Tabelle .................................612 13.6.4 Flashback Transaction / Transaktionen zurücksetzen.............................................612 Resümee...............................................................................................................................613

14

Verfügbarkeit........................................................................................................ 615

14.1 14.2

Übersicht Grid Infrastruktur.................................................................................................615 Oracle Restart.......................................................................................................................616 14.2.1 Architektur .............................................................................................................617 14.2.2 Installation..............................................................................................................617 14.2.3 Administration........................................................................................................618 Grid Infrastruktur und Oracle Real Application Clusters (RAC) .........................................621 14.3.1 Architektur .............................................................................................................622 14.3.2 Oracle Cluster Registry (OCR)...............................................................................623 14.3.3 Voting Devices .......................................................................................................623 14.3.4 Prozesse..................................................................................................................624 14.3.5 Logfiles ..................................................................................................................624 14.3.6 Grid Plug and Play (GPnP).....................................................................................624 14.3.7 Grid Naming Service (GNS) ..................................................................................624 14.3.8 Single Client Access Name (SCAN) ......................................................................625 14.3.9 Installation..............................................................................................................625 14.3.10 Administration........................................................................................................628 14.3.11 Server Pools............................................................................................................630 14.3.12 Administrator-managed und Policy-managed Cluster ............................................630 Grid Infrastruktur für Third-Party-Applikationen ................................................................631 14.4.1 Installation..............................................................................................................631 14.4.2 Administration........................................................................................................631 RAC One Node ....................................................................................................................634 Oracle Data Guard ...............................................................................................................635 14.6.1 Architektur .............................................................................................................636 14.6.2 Data Guard Services ...............................................................................................638 14.6.3 Data Guard Protection Modes ................................................................................639 14.6.4 Data Guard Broker .................................................................................................640 14.6.5 Verwaltungswerkzeuge ..........................................................................................640 14.6.6 Hard- und Softwarevoraussetzungen ......................................................................640 14.6.7 Verzeichnisstrukturen der Standby-Database .........................................................641 14.6.8 Vorbereitung der Primärdatenbank.........................................................................641 14.6.9 Erstellung der Physical Standby Database..............................................................644

13.5 13.6

14.3

14.4

14.5 14.6

XVII

Inhalt

14.8

14.6.10 Überwachung der Physical Standby Database........................................................ 647 14.6.11 Real Time Apply und Standby Logfiles ................................................................. 648 14.6.12 Starten und Stoppen des Redo-Apply..................................................................... 648 14.6.13 Aktivierung des Data Guard Brokers ..................................................................... 649 14.6.14 Hinzufügen und Aktivieren von Standby-Datenbanken ......................................... 651 14.6.15 Ändern von Konfigurationseinstellungen............................................................... 652 14.6.16 Durchführen eines Switchovers.............................................................................. 654 14.6.17 Durchführen eines Failovers .................................................................................. 655 14.6.18 Aufbau einer Logical Standby Database ................................................................ 656 Failover der Clients.............................................................................................................. 657 14.7.1 Transparent Application Failover (TAF)................................................................ 657 14.7.2 Failover mit ONS, FAN und FCF .......................................................................... 658 Resümee............................................................................................................................... 660

15

Große Datenbanken............................................................................................. 661

15.1

Parallelverarbeitung ............................................................................................................. 663 15.1.1 Verarbeitungsweise ................................................................................................ 664 15.1.2 Definitionsmöglichkeiten des Parallelisierungsgrades ........................................... 665 15.1.3 Abschlussbemerkungen zur Parallelverarbeitung................................................... 668 Partitionieren........................................................................................................................ 669 15.2.1 Grundprinzipien ..................................................................................................... 669 15.2.2 Partition Pruning .................................................................................................... 670 15.2.3 Partition Wise Join ................................................................................................. 671 15.2.4 Partitionstypen........................................................................................................ 672 15.2.5 Partition Maintenance Operations (PMOP)............................................................ 675 15.2.6 Partitionierte Indizes .............................................................................................. 675 Materialisieren ..................................................................................................................... 676 15.3.1 Materialized Views – Das Konzept ........................................................................ 676 15.3.2 Materialized Views erstellen .................................................................................. 678 15.3.3 Notwendige Rechte ................................................................................................ 679 15.3.4 Materialized Views modifizieren ........................................................................... 679 15.3.5 Materialized Views und Query Rewrite ................................................................. 680 15.3.6 Materialized Views und Refresh Modes ................................................................ 681 15.3.7 Materialized Views und Analysemöglichkeiten ..................................................... 683 15.3.8 Materialized Views und Partitionen ....................................................................... 684 Komprimieren...................................................................................................................... 685 15.4.1 „Index und Index Organized Table“-Komprimierung............................................ 686 15.4.2 DIRECT-LOAD-Datenkomprimierung.................................................................. 687 15.4.3 OLTP-Tabellenkomprimierung.............................................................................. 689 Data Warehouses ................................................................................................................. 690 15.5.1 Daten cachen oder In-Memory Operationen: PGA versus SGA ............................ 691 15.5.2 Backup & Recovery von großen Data-Warehouse-Datenbanken........................... 693 15.5.3 OLAP, ETL und Co. .............................................................................................. 697 15.5.4 Dimensionen .......................................................................................................... 700 Resümee............................................................................................................................... 705

14.7

15.2

15.3

15.4

15.5

15.6

XVIII

Inhalt 16

Datenbank-Upgrades........................................................................................... 707

16.1 16.2 16.3 16.4 16.5

Generelle Rahmenbedingen .................................................................................................709 Technische Planung .............................................................................................................710 Überblick Upgrade-Methoden..............................................................................................712 Generell mögliche Upgrade-Pfade .......................................................................................716 Database Upgrade Assistant (DBUA) ..................................................................................716 16.5.1 Software-Download................................................................................................716 16.5.2 Datenbanksoftware-Installation..............................................................................717 16.5.3 Upgrade mithilfe des DBUA ..................................................................................718 16.5.4 Silent Upgrade........................................................................................................721 Manueller Upgrade...............................................................................................................722 16.6.1 Manueller Upgrade im Detail .................................................................................725 Downgrade...........................................................................................................................727 Patchset 11.2.0.2 Out-Of-Place-Upgrade .............................................................................729 Patchset 11.2.0.2 In-Place-Upgrade .....................................................................................729 16.9.1 Vorgehensweise In-Place-Upgrade ........................................................................730 Best Practices Datenbank-Upgrade ......................................................................................731 Alternative Upgrade-Methoden............................................................................................734 16.11.1 Original Export-und-Import-Utilities (exp/imp).....................................................734 16.11.2 Export und Import mittels Data Pump....................................................................735 16.11.3 Transportable Tablespaces .....................................................................................737 Komplexe Upgrade-Methoden .............................................................................................739 16.12.1 Copy Table (Create Table as select) .......................................................................740 16.12.2 Oracle Streams / Oracle Golden Gate.....................................................................740 16.12.3 Upgrade mit logischer Standby-Datenbank ............................................................741 Datenbank-Konvertierung auf 64-Bit...................................................................................743 Wechsel von einer Standard Edition auf die Enterprise Edition...........................................744 Wechsel von einer Enterprise Edition auf eine Standard Edition.........................................744 Resümee...............................................................................................................................745

16.6 16.7 16.8 16.9 16.10 16.11

16.12

16.13 16.14 16.15 16.16

Die Autoren...................................................................................................................... 747 Register............................................................................................................................ 751

XIX

Inhalt

XX

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

Vorwort Bei Fragen zu den hier behandelten Themen gibt es darüber hinaus die Möglichkeit, die Autoren über Email oder einen ihrer Blogs zu kontaktieren: [email protected] [email protected] (für die Trivadis-Autoren) [email protected] 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

Vorwort Im Internet Auf http://downloads.hanser.de 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

Vorwort

XXIV

1.1 Die Datenbank-Software installieren

1 1 Schnelleinstieg Wenn Sie bisher nur wenig praktische Erfahrung im Umgang mit Oracle-Datenbanken sammeln konnten, dann hilft Ihnen dieser Schnelleinstieg bei der Installation der Datenbank-Software sowie dem Erstellen einer Standard-Datenbank. Zusätzlich finden Sie Hinweise zum grundlegenden Umgang mit der Datenbank sowie zu den wichtigsten Konfigurations- und Log-Dateien. Das Kapitel wird abgerundet mit Informationen, wie Sie Hilfe bei Problemen erhalten und sich in der umfangreichen Oracle-Dokumentation zurechtfinden können sowie mit einer Produktübersicht. In diesem Kapitel finden Sie folgende Themen:

 die Oracle-Datenbank-Software installieren;  eine Datenbank erstellen und konfigurieren;  erste Schritte für die Datenbank-Administration;  eine Übersicht der Oracle-Datenbank-Produkte;  Online-Hilfe und Support;  Informationen zur Oracle-Dokumentation. Praxistipp Installieren Sie die Enterprise Edition, um alle in diesem Buch beschriebenen Features und Beispiele ausprobieren zu können.

Die Beschreibung der Installation erfolgt für das Betriebssystem „Oracle Enterprise Linux (OEL)“ und lässt sich problemlos auf alle verbreiteten Unix-Systeme wie AIX, Solaris oder HP-UX übertragen. An den Stellen, wo es Plattform-spezifische Besonderheiten für Windows-Betriebssysteme gibt, finden Sie einen entsprechenden Hinweis. Die mit Hilfe dieses Kapitels erstellte Datenbank können Sie als Übungsumgebung für die weiteren Kapitel des Buches verwenden und alle mitgelieferten Skripte und Szenarien leicht nachvollziehen.

1

1 Schnelleinstieg

1.1

Die Datenbank-Software installieren In diesem Abschnitt wird die Installation für das Betriebssystem Oracle Enterprise Linux beschrieben. Wenn Sie die Installation auf einem Windows-Betriebssystem vornehmen möchten, dann können Sie ebenfalls den hier dargestellten Schritten folgen. Wir weisen an den entsprechenden Stellen auf Windows-spezifische Besonderheiten hin. Praxistipp Verwenden Sie ausschließlich von Oracle zertifizierte Betriebssysteme. Andernfalls erhalten Sie keinen Support von Oracle.

Die aktuellen Zertifizierungen finden Sie auf der Webseite http://support.oracle.com. Zum Zeitpunkt, als dieses Buch geschrieben wurde, gab es Zertifizierung für folgende LinuxBetriebssysteme (x86 und x86-64) für die Oracle Enterprise Edition 11gR2:

 Oracle Enterprise Linux 5/Oracle VM  Oracle Enterprise Linux 4/Oracle VM  Red Hat Enterprise 5/Oracle VM  Red Hat Enterprise 4/Oracle VM  SLES-11  SLES-10  Asianux Server 3.0 Der Oracle Universal Installer bietet die Auswahlmöglichkeit, die Installation der Software sowie das Erstellen einer Datenbank zusammenhängend durchzuführen. Die Anleitung in diesem Kapitel ist in zwei Schritte untergliedert, die Installation der Datenbank-Software und das Erstellen einer Datenbank. Die Installation der Datenbank-Software besteht aus zwei Teilen:

 Die Installation vorbereiten  Die Installation mit dem Universal Installer durchführen 1.1.1

Die Installation vorbereiten

1.1.1.1 Installationsquellen Sie können die Datenbank-Software als Entwickler-Lizenz unter Beachtung der Lizenzbedingungen kostenlos von der Webseite http://edelivery.oracle.com herunterladen. Eine weitere Quelle ist Oracles Technologie-Webseite http://www.oracle.com/technetwork. Hier erhalten Sie die einzelnen Produkte in losgelöster Form und müssen nicht den gesamten DVD-Baukasten herunterladen.

2

1.1 Die Datenbank-Software installieren Praxistipp Die Software mit der Installationsquelle „Technologie-Webseite“ ist offiziell nicht unter Support. Verwenden Sie deshalb für produktive Systeme stets die eDelivery-Webseite. Diese hat die frühere Auslieferung über CDs und DVDs offiziell abgelöst.

1.1.1.2 Optimal Flexible Architecture (OFA) OFA ist eine Empfehlung für das Layout von Dateisystemen und Verzeichnisstrukturen. Sie ist die Grundlage für eine Standardisierung und eine vereinfachte Administration. Die Richtlinien wurden im Jahre 1990 mit einem Whitepaper von Cary Millsap herausgegeben und im Jahre 1995 überarbeitet. Dieses Dokument ist unter dem Titel „The OFA-Standard – Oracle for Open Systems“ erschienen und wird als offizieller OFA-Standard angesehen. Für den Schnelleinstieg empfehlen wir, den Standard-Vorgaben des „Universal Installer“ sowie des „Database Configuration Assistant“ zu folgen. Damit liegen Sie sehr nahe am OFA-Standard. Detaillierte Informationen zum Thema „Optimal Flexible Architecture“ finden Sie in Kapitel 5. 1.1.1.3 Vorbereitung des Betriebssystems Linux-Betriebssysteme erfordern im Vergleich zu UNIX-Systemen ein gewisses Maß an Vorbereitung. So müssen z.B. Kernel-Parameter angepasst werden, was für AIX oder Solaris 10 nicht erforderlich ist. Für Windows-Systeme gibt es einige Besonderheiten, die in Abschnitt 1.1.1.4 beschrieben werden. Vorbereitung des Betriebssystems durch den Benutzer „root“ Überprüfen Sie, ob die Voraussetzungen durch die Hardware erfüllt sind. Für den Betrieb einer Datenbank in der Version 11gR2 werden benötigt:

 Mindestens 1 GB realer Hauptspeicher  Mindestens 1 GB freier Speicherplatz im Verzeichnis /tmp  Mindestens 4 GB für die Datenbank-Software (ORACLE_HOME) der Enterprise Edition Tabelle 1.1 zeigt die Anforderungen an die Version des Betriebssystem-Kerns, die abhängig von der Wahl des Linux-Derivats erfüllt sein müssen. Tabelle 1.1 Voraussetzungen an die Version des Betriebssystem-Kerns Betriebssystem

Kernel

Oracle Enterprise Linux 4, Red Hat Enterprise Linux 4, Asianux 2

>= 2.6.9

Oracle Enterprise Linux 5, Red Hat Enterprise Linux 5, Asianux 3

>= 2.6.18

SUSE Linux Enterprise Server 10

>= 2.6.16.21

SUSE Linux Enterprise Server 11

>= 2.6.27.19

Für die erweiterte Administration der Datenbank hält Oracle zwei Rollen (Gruppen) bereit:

3

1 Schnelleinstieg

 OSDBA: Benutzer des Betriebssystems, dem das SYSDBA-Privileg zugewiesen wird. Mit diesem Privileg ist es z.B. möglich, eine Datenbank zu starten und herunterzufahren.

 OSOPER: Benutzer des Betriebssystems mit eingeschränkten administrativen Rechten, wie z.B. das Durchführen von Sicherungen der Datenbank. In der Praxis wird häufig auf das Einrichten der Gruppe SYSOPER verzichtet und die Aktivitäten durch einen Benutzer mit SYSDBA-Privileg ausgeführt. Schließlich wird eine Inventar-Gruppe benötigt. Das Mitglied dieser Gruppe ist der Eigentümer der OracleSoftware. Wir legen die Gruppen dba (OSDBA) und oinstall (Inventar-Gruppe) an und ordnen diese dem neuen Benutzer oracle zu. Die Gruppe oinstall wird dabei die Primäre Gruppe von oracle. Die Standard-Umgebung für den Benutzer oracle sollte die Korn Shell oder die BASH sein: # groupadd orainst # groupadd dba # useradd –g orainst –g dba –p oracle –s /bin/ksh oracle

Die Anpassung der Kernel-Parameter erfolgt in der Datei oder bearbeiten Sie die folgenden Parameter:

/etc/sysctl.conf.

Ergänzen

# Oracle fs.file-max = 6815744 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 kernel.shmmax = *)

*) Das Minimum von 4 GB und der Hälfte des physikalischen Hauptspeichers (in Bytes). Aktivieren Sie die eingetragenen Werte mit dem Befehl triebssystems ist nicht erforderlich.

sysctl –p.

Weiterhin müssen die Grenzwerte der Shell für den Benutzer sind die folgenden Schritte erforderlich:

Ein Neustart des Be-

oracle

gesetzt sein. Dazu

1. Ergänzen Sie die folgenden Einträge in der Datei /etc/security/limits.conf: oracle oracle oracle oracle

soft hard soft hard

nproc nproc nofile nofile

2047 16384 1024 65536

2. Fügen Sie, falls noch nicht vorhanden, den folgenden Eintrag in der Datei /etc/pam.d/limits.conf hinzu: session

required

pam_limits.so

Erstellen Sie einen Mount-Point für das Oracle Base-Verzeichnis (ORACLE_BASE), z.B. /opt/app/oracle. Laut OFA ist Oracle Base das oberste Verzeichnis für die Oracle-Software-Installation.

4

1.1 Die Datenbank-Software installieren Im Inventar-Verzeichnis (Oracle Inventory) werden Informationen über die installierte Software, Produkte und Patches gespeichert. Es sollte sich außerhalb des Oracle BaseVerzeichnisses befinden, z.B. in /opt/app/oraInventory. Erstellen Sie die Verzeichnisse mit den folgenden Befehlen: # # # # #

mkdir chown chmod mkdir chown

–p /opt/app/oracle oracle:oinstall /opt/app/oracle 775 /opt/app/oracle –p /opt/app/oraInventory oracle:oinstall /opt/app/oraInventory

Damit sind die Vorbereitungen des Betriebssystems fast abgeschlossen. Beachten Sie an dieser Stelle noch den folgenden Praxistipp. Praxistipp Stellen Sie sicher, dass genügend Memory auf /dev/shm gemountet ist. Andernfalls erhalten Sie beim ersten Startversuch der Instanz die Fehlermeldung ORA-00845 „MEMORY_TARGET not supported on this system“.

Unter Linux erfolgt das Anhängen des Hauptspeichers mit folgendem Befehl: # mount –t tmpfs shmfs –o size=1500m /dev/shm

Fügen Sie die folgende Zeile in die Datei /etc/fstab ein, um die Änderung für einen Neustart persistent zu machen: shmfs

/dev/shm

tmpfs

size=1500m

0 0

1.1.1.4 Vorbereitung für die Installation unter Windows Wenn Sie mit Ihrer Arbeitsstation bereits von Windows XP nach Vista oder Windows 7 oder Laptop gewechselt haben, dann können Sie sicherlich erahnen, welche Probleme im Zusammenhang mit dem Betrieb einer Oracle-Datenbank auftreten können. Insbesondere die Benutzerkontensteuerung (User Account Control oder kurz UAC) legt die Hürde für den Administrator etwas höher. Zum Vergleich lässt sich sagen, dass in der Funktionalität des Kernel Windows Vista dem Betriebssystem Windows 2008 R1 und Windows 7 dem Betriebssystem Windows 2008 R2 entspricht. Zu den Besonderheiten dieser Versionen werden wir noch Hinweise bringen. Zunächst jedoch die allgemeine Vorbereitung der Installation für Windows. Die grundlegenden und die Installation betreffenden Unterschiede zwischen Windows und Unix/Linux finden Sie in Tabelle 1.2 zusammengefasst. Tabelle 1.2 Unterschiede zwischen Windows- und Unix-Betriebssystemen UNIX/Linux

Windows

Instanz

Beim Hochfahren der Instanz werden Prozesse des Betriebssystems gestartet.

Während der Installation wird ein Windows-Dienst erstellt. Die Instanz kann gestartet werden, wenn der Dienst läuft.

OS-Gruppen

Die Gruppen für OSDBA und OSOPER werden bei der Vorbereitung des Betriebssystems angelegt.

Die Gruppen ORA_DBA und ORA_OPER werden durch den Universal Installer angelegt.

5

1 Schnelleinstieg UNIX/Linux

Windows

OS-Benutzer

Es wird ein spezieller Benutzer angelegt, der sich in der Inventar-Gruppe befindet.

Es wird ein Benutzer benötigt, der über lokale Administrator-Rechte verfügt. Empfohlen wird, den Benutzer „Administrator“ zu verwenden.

Umgebung

Umgebungsvariablen werden in der Shell gesetzt.

Umgebungsvariablen werden durch den Universal Installer in das Registry geschrieben.

Wenn Sie Windows 2008, Vista oder Windows 7 als Betriebssystem verwenden, müssen Sie beachten, dass die Benutzerkontensteuerung − so wie alle anderen Applikationen − auch die Oracle-Software mit ihren Zugriffen beschränkt. Die UAC abzuschalten ist aus dem Blickwinkel der Sicherheit nicht sinnvoll, es sei denn, Sie können dieses Sicherheitsfeature durch andere Maßnahmen ersetzen. Insbesondere wenn der Rechner, auf dem die Oracle-Datenbank läuft, Verbindung zum Internet hat, sollte die UAC nicht abgeschaltet werden. Allgemein gilt, dass Sie Administrator-Rechte besitzen müssen, wenn Sie Tools wie den Database Configuration Assistant (DBCA) oder der Net Configuration Assistant (NETCA) ausführen wollen. Gleiches gilt für den Zugriff auf Konfigurations- und Logdateien im Oracle Home-Verzeichnis. Wenn Sie als Lokaler Administrator angemeldet sind, dann können Sie diese Tools wie gewohnt ausführen. Sind Sie jedoch nur Mitglied der Administrator-Gruppe, dann müssen Sie das entsprechende Programm explizit als Administrator aufrufen. Dies erreichen Sie durch einen rechten Mausklick im Windows-Menü mit der Auswahl „Als Administrator ausführen“. Wenn Sie Arbeiten auf der Kommandozeile ausführen, dann sollten Sie das DOS-Fenster auf dieselbe Art und Weise aufrufen.

1.1.2

Die Installation durchführen

Die Installation der Datenbank-Software erfolgt mit dem Oracle Universal Installer (OUI). Der OUI ist ein Java-Programm, das auf allen Plattformen in gleicher Weise funktioniert. Die folgenden Schritte beschreiben die Installation im interaktiven Modus: 1. Machen Sie die Installationsquelle auf dem Datenbankserver verfügbar. Starten Sie als Benutzer oracle das Programm runInstaller im Verzeichnis database. Unter Windows wird der Installer mit dem Programm setup.exe aufgerufen. Es erscheint das erste Fenster, in dem Sie aufgefordert werden, Ihre E-Mail-Adresse und Ihr Passwort für die Webseite „My Oracle Support“ einzugeben. Dieser Schritt ist optional, Sie können die Felder auch leer lassen.

6

1.1 Die Datenbank-Software installieren

Abbildung 1.1 Schritt 1 im Universal Installer − Sicherheitsupdates

2. Im zweiten Schritt können Sie auswählen, welche Aktion durchgeführt werden soll. Wählen Sie die Option „Install database software only“. 3. Es erscheint die Abfrage, ob es sich um die Installation für eine Single InstanceDatenbank oder eine Cluster-Datenbank handelt. Wählen Sie die Option „Single instance database installation“. 4. In Schritt 4 können Sie die Produktsprache festlegen. Englisch wird immer installiert und kann nicht entfernt werden. Fügen Sie „German“ hinzu, wenn Sie vorzugsweise mit deutschen Meldungen arbeiten wollen. 5. Im nächsten Schritt erscheint die Auswahl der zu installierenden Oracle-Edition. Detaillierte Informationen zu den Editionen finden Sie in Abschnitt 1.5.1. Wählen Sie die Option „Enterprise Edition“, um alle Features und Beispiele aus diesem Buch nachvollziehen zu können. 6. In Schritt 6 erfolgt die Abfrage der Verzeichnisse für ORACLE_BASE und ORACLE_HOME. ORACLE_BASE ist laut OFA das oberste Verzeichnis für die SoftwareInstallation. Unter ORACLE_HOME liegen in diesem Fall die Binaries sowie Konfigurationsdateien der Oracle-Datenbanksoftware.

7

1 Schnelleinstieg

Abbildung 1.2 Die Lokation für die Oracle-Software festlegen

7. Im weiteren Verlauf werden Sie aufgefordert, den Namen für das Inventar-Verzeichnis, das „Oracle Inventory“ einzugeben, z.B. /opt/app/oraInventory. Der Gruppenname ist in unserem Fall oinstall, also die primäre Gruppe des Benutzers oracle. 8. Wählen Sie nun die Gruppen für die erweiterten Privilegien SYSDBA und SYSOPER aus. In diesem Fall ist es für beide die Gruppe dba. 9. In Schritt 9 überprüft der Universal Installer, ob alle Anforderungen an das Betriebssystem erfüllt sind. Das betrifft u.a. die Kernel-Parameter, die Betriebssystem-Version und die erforderlichen Pakete. Der OUI gibt Hinweise, wenn Voraussetzungen nicht erfüllt sind. Sie können an dieser Stelle noch Kernel-Parameter verändern oder Pakete nachinstallieren. Der OUI führt alle Prüfungen erneut durch, wenn Sie auf „Check Again“ klicken.

8

1.1 Die Datenbank-Software installieren Praxistipp Sie haben die Möglichkeit, den Marker „Ignore All“ zu markieren. Damit würde der OUI keine weiteren Prüfungen durchführen und Sie gelangen zum nächsten Schritt. Möglicherweise läuft die Installation ohne weitere Fehler durch. Allerdings besteht die Gefahr, dass es zu Problemen im laufenden Datenbank-Betrieb kommt. Dies kann im Extremfall zum Absturz der Datenbank führen. Lösen Sie deshalb an dieser Stelle die Probleme, die Ihnen der OUI anzeigt.

Abbildung 1.3 Überprüfung durch den OUI, ob die Anforderungen an das Betriebssystem erfüllt sind

10. Schließlich bekommen Sie die wichtigsten Parameter für die Installation in einer Zusammenfassung angezeigt. Klicken Sie auf „Finish“, um mit der Installation zu beginnen.

9

1 Schnelleinstieg

Abbildung 1.4 Zusammenfassung der Installationsparameter

11. In Schritt 11 können Sie den Fortschritt der Installation verfolgen. Für Unix/LinuxBetriebssystem werden die Binaries und die Shared Libraries zusätzlich gelinkt. Unter Windows werden die EXE- und DDL-Dateien einfach kopiert. 12. Zum Abschluss der Installation müssen zwei Skripte durch den Benutzer root auf der Kommandozeile ausgeführt werden. Mit dem Skript orainstRoot.sh werden vor allem die Rechte für das Inventar gesetzt. Das Skript rootsh setzt noch spezielle Rechte im Oracle Home-Verzeichnis und schreibt einige Konfigurationsdateien und Skripte (siehe das folgende Listing). Unter Windows müssen diese Skripte nicht ausgeführt werden.

10

1.1 Die Datenbank-Software installieren

Abbildung 1.5 Root-Skripte zum Abschluss der Installation ausführen

[root@dar12 11.2.0]# /opt/app/oraInventory/orainstRoot.sh Changing permissions of /opt/app/oraInventory. Adding read,write permissions for group. Removing read,write,execute permissions for world. Changing groupname of /opt/app/oraInventory to oinstall. The execution of the script is complete. [root@dar12 11.2.0]# /opt/app/oracle/product/11.2.0/dbhome_1&root.sh Running Oracle 11g root.sh script... The following environment variables are set as: ORACLE_OWNER= oracle ORACLE_HOME= /opt/app/oracle/product/11.2.0/dbhome_1 Enter the full pathname of the local bin directory: [/usr/local/bin]: Copying dbhome to /usr/local/bin ... Copying oraenv to /usr/local/bin ... Copying coraenv to /usr/local/bin ... Creating /etc/oratab file... Entries will be added to the /etc/oratab file as needed by Database Configuration Assistant when a database is created Finished running generic part of root.sh script. Now product-specific root actions will be performed. Finished product-specific root actions.

13. Damit ist die Installation abgeschlossen und Sie können den Universal Installer schließen.

11

1 Schnelleinstieg

1.2

Eine Datenbank erstellen Verwenden Sie für die Erstellung einer Datenbank ausschließlich den Database Configuration Assistant (DBCA). Sie können sich auch Skripte durch den DBCA erstellen lassen. Die Notwendigkeit, den DBCA zu verwenden, wird durch folgende Punkte unterstrichen:

 Der DBCA verwendet alle neuen oder geänderten Programme der neuen Oracle-Version.  Er verwaltet die große Anzahl von Produkten und Optionen der Datenbank und stellt sicher, dass alle Abhängigkeiten berücksichtigt werden.

 Der DBCA unterstützt die OFA und macht Standard-Vorgaben für das Anlegen von Verzeichnissen.

 Sie können mit dem DBCA Templates erstellen und verwalten. Setzen Sie zur Vorbereitung die erforderliche Umgebung und übernehmen Sie diese in das Profil des Benutzers oracle: export ORACLE_BASE=/opt/app/oracle export ORACLE_HOME=/opt/app/oracle/product/11.2.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH

Wir werden mit dem DBCA auch direkt den Enterprise Manager Database Control konfigurieren. Dazu benötigt der DBCA einen laufenden Listener. Legen Sie den Listener mit dem Net Configuration Assistant (NETCA) an. Gestartet wird der NETCA von der Kommandozeile über den Befehl netca oder unter Windows über das Startmenü. Führen Sie zum Anlegen und Starten des Listener die folgenden Schritte durch: 1. Starten Sie den NETCA und wählen Sie die Option „Listener Configuration“. 2. Markieren Sie im zweiten Fenster die Option „Add“. 3. Vergeben Sie im nächsten Fenster den Namen des Listener, als Standard ist „LISTENER“ voreingestellt (siehe Abbildung 1.6). 4. Wählen Sie das Netzwerk-Protokoll „TCP“. 5. Markieren Sie im folgenden Fenster die Standard-Portnummer „1521“. 6. Beenden Sie den NETCA. Damit ist die Konfiguration abgeschlossen und der Listener ist gestartet.

12

1.2 Eine Datenbank erstellen

Abbildung 1.6 Den Namen des Listener vorgeben

Weitere Details zur Listener- und Oracle Net-Konfiguration diskutieren wir in Kapitel 7 „Oracle Net“. Wir beginnen jetzt mit dem Erstellen der Datenbank. Starten Sie den DBCA durch Aufruf des Befehls dbca von der Kommandozeile oder über das Windows-Startmenü und führen Sie die folgenden Schritte durch: 1. Im ersten Schritt können Sie die durchzuführende Aktion auswählen. Markieren Sie „Create a Database“. 2. Es erscheint eine Auswahlliste der mitgelieferten Standarddatenbanken. Die rechte Spalte „Include Datafiles“ beschreibt, ob es sich um vordefinierte Datenbanken handelt, deren Datafiles sich auf dem Installationsmedium befinden. Das Erstellen der Datenbank erfolgt damit schneller, da die Datafiles einfach kopiert werden, allerdings können sie weniger Optionen auswählen. Markieren Sie „Custom Database“ um eine individuelle Datenbank zu erstellen (siehe Abbildung 1.7, nächste Seite).

13

1 Schnelleinstieg

Abbildung 1.7 Das Template für die Datenbank auswählen

3. Im nächsten Fenster werden der Globale Datenbankname sowie der Oracle System Identifier (SID) abgefragt. Die SID ist identisch mit dem Namen der Instanz und wird uns bei der weiteren Konfiguration noch öfter begegnen. Der Globale Datenbankname besteht aus der SID, gefolgt von der Domäne der Datenbank, z.B. „ORADBA.world“. Für die Domäne eignet sich auch die Internet-Domäne des Unternehmens. Die Datenbankdomäne muss nicht mit dem Domänkonzept des Betriebssystems übereinstimmen (siehe Abbildung 1.8). 4. In Schritt 4 erscheint die Konfigurationsseite für den Enterprise Manager Database Control. Markieren Sie die Option „Configure Enterprise Manager“ und wählen Sie „Configure Database Control for local management“ aus (siehe Abbildung 1.9). 5. Klicken Sie auf den Reiter „Automatic Maintenance Tasks“. Dort können Sie festlegen, ob von der Datenbank automatische Wartungsaufgaben, wie z.B. das Erstellen von Optimizer-Statistiken ausgeführt werden sollen. Die Arbeiten erfolgen dann in einem vordefinierten Zeitfenster. Markieren Sie an dieser Stelle die Option, Sie können diese später noch anpassen oder entfernen. 6. Geben Sie im nächsten Schritt die Passwörter für die System-Benutzer in der Datenbank ein. Sie haben die Wahl zwischen individuellen Passwörtern oder einem Passwort für alle.

14

1.2 Eine Datenbank erstellen

Abbildung 1.8 Den Globalen Datenbanknamen und die SID festlegen

Abbildung 1.9 Die Optionen für den Enterprise Manager auswählen

15

1 Schnelleinstieg 7. Im folgenden Schritt werden die Speicheroptionen für die Datenbank festgelegt. Wählen Sie als Speichertyp „File System“ aus und markieren Sie „Use Database File Locations from Template“. 8. Sie werden nun gefragt, ob Sie eine „Flash Recovery Area (FRA)“ anlegen wollen. Die FRA ist Basis für eine Reihe von Features für Datensicherung und –wiederherstellung. Bestätigen Sie die Option und wählen Sie als Speicherort {ORACLE_BASE}/flash_ recovery_area. Vergeben Sie die Größe nach den aktuellen Platzverhältnissen, jedoch mindestens 2 GB (siehe Abbildung 1.10).

Abbildung 1.10 Die Flash Recovery Area im DBCA einrichten

9. In Schritt 9 erfolgt die Auswahl der Datenbank-Optionen. Wir wollen eine „schlanke“ Datenbank anlegen. Entfernen Sie dazu alle Optionen mit Ausnahme des „Enterprise Manager Repository“. Vergessen Sie dabei nicht, die Standardkomponenten zu entfernen, und klicken Sie dazu auf den Knopf „Standard Database Components“. Falls Sie zu einem späteren Zeitpunkt weitere Optionen benötigen, können Sie diese jederzeit mit dem DBCA hinzufügen (siehe Abbildung 1.11). 10. Nun können Sie einige erste und grundlegende Einstellungen von Parametern für die Datenbank vornehmen. Es erscheinen die folgenden Register (siehe Abbildung 1.12):

Memory Markieren Sie die Optionen „Typical“ und „Use Automatic Memory Management“. Legen Sie die Größe des Hauptspeichers für die Datenbank nach der verfügbaren Hard-

16

1.2 Eine Datenbank erstellen

Abbildung 1.11 Die Optionen der Datenbank auswählen

Abbildung 1.12 Die Datenbankparameter im DBCA festlegen

17

1 Schnelleinstieg ware-Ausstattung fest. Beachten Sie, dass evtl. andere Applikationen sowie das Betriebssystem noch Platz finden müssen. Handelt es sich um einen dedizierten Datenbankserver, dann können Sie 65 − 75 Prozent des verfügbaren Hauptspeichers vergeben.

Sizing Verwenden Sie für eine Standard-Datenbank eine Blockgröße von 8 KB. Geben Sie 16 KB an, wenn es sich um eine Data-Warehouse-typische Datenbank handelt.

Character Sets Der Standardzeichensatz ist WEMSWIN1252. Es handelt sich um einen westeuropäischen Zeichensatz der verwendet werden sollte, wenn Sie vorwiegend mit Windows-Applikationen auf die Datenbank zugreifen. Stellen Sie Sprache und Territorium auf „Deutsch“ ein, wenn Sie eher mit deutschen Meldungen und deutschen Zahlen- und Datumsformaten arbeiten wollen.

Connection Mode Markieren Sie „Dedicated Server Mode“. 11. Im nächsten Schritt haben Sie die Möglichkeit, die Speicherorte der Dateien anzupassen, weitere Tablespaces hinzuzunehmen sowie die Konfiguration und Spiegelung der Kontrolldateien und Online Redo Log-Dateien festzulegen. Die vom DBCA vorgeschlagenen Parameter erfüllen die Mindestanforderungen an das Erstellen einer Datenbank sowie der OFA-Richtlinien (siehe Abbildung 1.13).

Abbildung 1.13 Die Parameter für die Dateien im DBCA festlegen

18

1.3 Administrationswerkzeuge 12. Nun können Sie die durchzuführende Aktion festlegen. Markieren Sie „Create Database“. Wenn Sie die anschließende Zusammenfassung aller ausgewählten Optionen und festgeleg#ten Parameter bestätigen, beginnt der DBCA mit dem Erstellen der Datenbank. 13. Zum Abschluss zeigt der DBCA die wichtigsten Informationen zur gerade erstellten Datenbank an, wie die SID oder die URL für den Enterprise Manager (Abbildung 1.14).

Abbildung 1.14 Basis-Informationen zur erstellten Datenbank

Damit ist das Erstellen der Datenbank abgeschlossen. Die Datenbank, der Oracle Listener sowie der Enterprise Manager wurden gestartet und können verwendet werden.

1.3

Administrationswerkzeuge Für die Administration einer Oracle-Datenbank steht eine Reihe von Werkzeugen zur Verfügung. Jedes Werkzeug hat seine Vor- und Nachteile. Auch die Frage, ob die Administration eher von der Kommandozeile oder mit einem Werkzeug mit grafischer Oberfläche (GUI) erfolgen soll, kann nicht eindeutig beantwortet werden. In der täglichen Arbeit macht es Sinn, mit beiden zu arbeiten, da sowohl die GUI als auch die Kommandozeile − abhängig von der aktuellen Aufgabe − überlegen sein können. Bedenken Sie auch, dass die Kommandozeile immer zur Verfügung steht, während ein Werkzeug mit grafischer Oberfläche in einer speziellen Umgebung des Kunden unter Umständen nicht verfügbar ist.

19

1 Schnelleinstieg Praxistipp Verwenden Sie für die Administration von Oracle-Datenbanken sowohl ein Werkzeug mit grafischer Oberfläche als auch die Kommandozeile. Setzen Sie für die konkrete Aufgabe das Werkzeug ein, das effektiver ist oder mit dem Sie die Aufgabe am zuverlässigsten und schnellsten lösen können.

Die folgenden Werkzeuge werden am häufigsten für die Oracle-Datenbank-Administration genutzt:

 Oracle Enterprise Manager (Oracle Corp.)  Toad (Quest Software)  Oracle SQL Developer (Oracle Corp.)  Kommandozeile: SQL*Plus, RMAN, ASMCMD etc. Der Oracle Enterprise Manager ist sehr gut für die tägliche Datenbank-Administration geeignet, vor allem für die Datenbank-orientierte Administration. In ihm sind nahezu alle Features der Enterprise Edition abgebildet (siehe Abbildung 1.15). Die lokale Variante wird

Abbildung 1.15 Die Startseite des Oracle Enterprise Manager

20

1.3 Administrationswerkzeuge als „Enterprise Manager Database Control“ bezeichnet, die zentrale Variante heißt „Enterprise Manager Grid Control“. Der Enterprise Manager ist Browser-basierend und kann damit auf jedem Thin Client verwendet werden. Wenn Sie den „Enterprise Manager Database Control“, so wie im vorhergehenden Abschnitt beschrieben, mit dem DBCA angelegt haben, dann können Sie ihn direkt im Browser über die URL https:// :1158/em aufrufen. Detaillierte Informationen zum Thema „Enterprise Manager“ finden Sie in Abschnitt 2.4 „Verwaltungswerkzeuge“. TOAD von Quest Software ist ein Werkzeug mit einem Windows Client und grafischer Oberfläche. Er besitzt einen Schema-Browser ist eher ein Werkzeug für Administratoren, die Datenbankapplikationen unterstützen, PL/SQL-Prozeduren bearbeiten oder SQL-Anweisungen analysieren (siehe Abbildung 1.16). Zusätzlich verfügt der TOAD über Features zur Unterstützung der reinen Datenbankadministration wie einen Session Browser, Log Miner oder die Verwaltung von Tablespaces.

Abbildung 1.16 Der Object Browser in TOAD

21

1 Schnelleinstieg Der Oracle SQL Developer (siehe Abbildung 1.17) ist vorrangig für Entwickler von Datenbank-Applikationen oder Applikations-Administratoren geeignet. Seine Features sind stark auf die Verwaltung der Schemata orientiert, vergleichbar mit TOAD. Der SQL Developer verfügt nur über wenige Features zur Unterstützung der reinen DatenbankAdministration. Er kann hervorragend in Ergänzung zum Enterprise Manager eingesetzt werden, da die Bearbeitung von Schemas durch den Enterprise Manager nur ansatzweise unterstützt wird. Der SQL Developer ist ein mit Java programmiertes Werkzeug und kann damit auf allen verbreiteten Betriebssystemen verwendet werden. Ein weiterer Vorteil: Der SQL Developer ist kostenlos.

Abbildung 1.17 Der Oracle SQL Developer

Die Administration auf der Kommandozeile erfolgt hauptsächlich mit SQL*Plus. Der Nachteil bei der Administration ist, dass Sie die Befehle kennen müssen, und das sind bei der Vielfalt der Features und der Komplexität der Oracle-Datenbank nicht wenige. Die Kommandozeile ist vor allem dann der grafischen Oberfläche überlegen, wenn eine Bearbeitung für viele Benutzer oder allgemein viele Objekte durchgeführt werden muss. Dann

22

1.4 Erste Administrations-Schritte steht ein einfach generiertes Skript gegen viele Klicks mit der Maus. Außerdem steht SQL*Plus in jeder Umgebung zur Verfügung. Für Windows-Systeme gibt es zusätzlich den „Administrationsassistent für Windows“ (siehe Abbildung 1.18). Damit können Sie Windows-spezifische Besonderheiten wie Benutzer und Gruppen oder die Parameter im Registry bearbeiten.

Abbildung 1.18 Der Oracle Administration Assistant für Windows

1.4

Erste Administrations-Schritte Für die Administration von der Kommandozeile sowie die Verwaltung von Werkzeugen und Assistenten muss die entsprechende Umgebung gesetzt werden. Für das Setzen der Umgebungsvariablen stellt Oracle das Skript oraenv zur Verfügung. Es liest aus der Datei /etc/oratab und setzt die Umgebung. Als Parameter wird die SID mitgegeben. Das Skript ist insbesondere dann nützlich, wenn sich mehrere Datenbanken oder Oracle HomeVerzeichnisse auf dem Server befinden. Die Datei oratab besteht aus drei Spalten, der SID, dem Oracle Home-Verzeichnis sowie einem „N“ oder „Y“, mit dem festgelegt wird, ob ein automatischer Start der Instanz erfolgen soll.

23

1 Schnelleinstieg $ . oraenv ORACLE_SID = [ORADBA] ? ORADBA The Oracle base for ORACLE_HOME=/opt/app/oracle/product/11.2.0/dbhome_1 is /opt/app/oracle $ env|grep ORA ORACLE_BASE=/opt/app/oracle ORACLE_HOME=/opt/app/oracle/product/11.2.0/dbhome_1 ORACLE_SID=ORADBA $ cat /etc/oratab ORADBA:/opt/app/oracle/product/11.2.0/dbhome_1:N

Praxistipp Die Datei oratab befindet sich auf Unix- und Linux-Betriebssystemen standardmäßig im Verzeichnis /etc. Unter Solaris ist sie im Verzeichnis /var/opt/oracle gespeichert.

Mit der gesetzten Umgebung können Sie sich mit dem folgenden Befehl über das Betriebssystem identifizieren und an der Datenbank anmelden: $ sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Mon Jun 21 20:02:40 2010 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL>

Voraussetzung ist, dass sich der Benutzer des Betriebssystems in der Gruppe OSDBA (dba) befindet. Er ist dann als Benutzer „SYS“ an der Datenbank angemeldet und hat das Privileg SYSDBA. Damit kann unter anderem die Datenbankinstanz gestartet und gestoppt werden: SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 636100608 Fixed Size 1338392 Variable Size 427820008 Database Buffers 201326592 Redo Buffers 5615616 Database mounted. Database opened.

bytes bytes bytes bytes bytes

Das Kommando startup startet die Instanz und öffnet die Datenbank für den normalen Betrieb. Sowohl für das Starten als auch das Herunterfahren der Instanz gibt es folgende Optionen:

 STARTUP NOMOUNT: Ausschließlich die Instanz starten. Die Datenbank wird nicht geöffnet.

 STARTUP MOUNT: Die Instanz starten und die Kontrolldatei öffnen.  STARTUP: Die Instanz starten sowie die Kontrolldatei und die Datafiles öffnen.  STARTUP RESTRICT: Die Instanz starten und die Datenbank im eingeschränkten Modus öffnen. Die Datenbank kann ausschließlich mit einem Administrator-Account benutzt werden.

24

1.4 Erste Administrations-Schritte

 STARTUP FORCE: Ein SHUTDOWN ABORT durchführen und anschließend die Datenbank neu starten.

 SHUTDOWN NORMAL: Es werden keine neuen Verbindungen zur Datenbank zugelassen. Oracle wartet mit dem Herunterfahren, bis sich alle Benutzer abgemeldet haben. Das Schlüsselwort „NORMAL“ ist optional.

 SHUTDOWN TRANSACTIONAL: Es werden keine neuen Verbindungen zur Datenbank zugelassen. Oracle wartet, bis alle offenen Transaktionen abgeschlossen sind und beendet dann die Session.

 SHUTDOWN IMMEDIATE: Auch hier werden neue Verbindungen abgewiesen und alle offenen Transaktionen zurückgerollt. Anschließen wird die Datenbank geschlossen.

 SHUTDOWN ABORT: Die Prozesse der Instanz werden sofort beendet, ohne weitere Aktionen in der Datenbank durchzuführen. Diese Aktion hinterlässt die Datenbank in einem inkonsistenten Zustand. Beim nächsten Start wird ein Crash Recovery durchgeführt. Die Verbindung von einem Oracle-Client zur Datenbank wird über den Listener hergestellt. Auf der Kommandozeile wird er mit dem Utility lsnrctl administriert. Das Starten und Stoppen erfolgt mit folgenden Befehlen: $ lsnrctl stop LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 21-JUN-2010 20:08:56 Copyright (c) 1991, 2009, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dar12.dbexperts.com)(PORT=1521))) The command completed successfully $ lsnrctl start LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 21-JUN-2010 20:09:01 Copyright (c) 1991, 2009, Oracle. All rights reserved. Starting /opt/app/oracle/product/11.2.0/dbhome_1/bin/tnslsnr: please wait... . . .

Für die Verwaltung des Oracle Enterprise Manager steht das Utility emctl zur Verfügung. Das folgende Kommando startet den Enterprise Manager Database Control: $ emctl start dbconsole Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0 Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved. https://dar12.dbexperts.com:1158/em/console/aboutApplication Starting Oracle Enterprise Manager 11g Database Control ................. started. -----------------------------------------------------------------Logs are generated in directory /opt/app/oracle/product/11.2.0/dbhome_1/dar12.dbexperts.com_ORADBA/sysman/log

Der Enterprise Manager ist ein Browser-basierendes Werkzeug. Über die Anmeldung gelangen Sie auf die Startseite der Datenbank (siehe Abbildung 1.9). Unter Windows richtet der DBCA Dienste im Betriebssystem ein (siehe Abbildung 1.19). Ein Dienst repräsentiert die Datenbank. Er erhält den Namen „OracleService<SID>“.

25

1 Schnelleinstieg

Abbildung 1.19 Die Oracle-Dienste unter Windows

Voraussetzung für den Start der Instanz ist, dass der Windows-Dienst gestartet ist. Er sollte deshalb auf automatisch eingestellt sein, wenn die Instanz beim Neustart des Servers automatisch gestartet werden soll. Zusätzlich lässt sich einstellen, ob mit dem Start des Datenbankdienstes die Instanz automatisch gestartet werden soll. Diese Einstellung können Sie über das Utility oradim vornehmen: C:\oradim -EDIT -SID ORADBA -STARTMODE auto|manual

Der aktuelle Status des Startmodus ist im Registry unter dem Pfad HKEY_LOCAL_MACHINE\ SOFTWARE\ORACLE\KEY_\ORA_<SID>_AUTOSTART gespeichert.

In Windows-Betriebssystemen existiert keine Datei oratab. Die Umgebung wird aus dem Registry gelesen. Alternativ können Sie die Umgebung manuell setzen. Die weiteren Befehle und Programmaufrufe funktionieren dann genau wie unter UNIX/Linux: C:\>set ORACLE_SID=ORADBA C:\>sqlplus / as sysdba

Bis jetzt haben wir uns immer lokal auf dem Datenbankserver zur Datenbank verbunden. Wenn sich der Oracle Client auf einem anderen Rechner befindet, dann erfolgt die Verbindung über das TCP/IP-Netzwerk und den Listener. Dazu muss der Client wissen, auf welchen Server er sich verbinden soll und auf welchen Port der Listener hört. Diese Informationen werden in der Datei tnsnames.ora im Verzeichnis $ORACLE_HOME/network/

26

1.4 Erste Administrations-Schritte admin hinterlegt. Verwenden Sie den netca, um einen Eintrag zu erstellen. Wählen Sie

die Optionen „Konfiguration von lokalem Net Service Name“ sowie „Hinzufügen“. Danach werden Sie aufgefordert, den Service-Namen der Datenbank einzugeben. In unserem Fall lautet er „ORADBA.world“ (siehe Abbildung 1.20).

Abbildung 1.20 Den Service-Namen im NETCA eingeben

Das Standard-Protokoll ist TCP. Geben Sie im nächsten Schritt den Hostnamen sowie den Port des Listener an. Abschließend können Sie den Net-Service-Namen eingeben. Dabei handelt es sich um einen Alias, den Sie frei wählen können. Im Ergebnis erfolgt der folgende Eintrag in die Datei tnsnames.ora: ORADBA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dar12)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = ORADBA.world) ) )

Die Erreichbarkeit des Oracle Listener können Sie mit dem Utility tnsping mit Angabe des Net Service-Namen überprüfen: C:\>tnsping ORADBA TNS Ping Utility for 64-bit Windows: Version 11.2.0.1.0 - Production on 21-JUN2010 20:29:18 Copyright (c) 1997, 2010, Oracle. All rights reserved. Used parameter files: C:\app\Lutz\product\11.2.0\dbhome_1\network\admin\sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dar12)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = ORADBA.world))) OK (30 msec)

27

1 Schnelleinstieg Mit diesem Aufruf können Sie sich vom Client auf die Datenbank verbinden: C:\>sqlplus system/manager@ORADBA

Oracle benutzt für das Speichern der Datenbank-Parameter das „Server Parameter File (SPFILE)“. Das SPFILE befindet sich im Verzeichnis $ORACLE_HOME/dbs und besitzt den Namen spfile.ora. In Windows lautet das Verzeichnis %ORACLE_HOME%\ database. Praxistipp Das SPFILE ist eine Binärdatei und sollte nicht mit einem Texteditor bearbeitet werden. Es besteht die Gefahr der Zerstörung.

Die Parameter des SPFILE können in SQL*Plus mit dem Befehl SHOW PARAMETER ausgelesen werden: SQL> SHOW PARAMETER spfile NAME TYPE VALUE ---------------- ----------- ----------------------------spfile string opt/app/oracle/product/11.2.0 /dbhome_1/dbs/spfileORADBA.ora

Datenbank-Parameter können mit dem Befehl ALTER SYSTEM geändert werden. Es gibt Parameter, die dynamisch änderbar sind. Für alle anderen Parameter muss ein Neustart der Datenbank erfolgen. Mit der Option SCOPE können Sie steuern, wo die Änderung erfolgen soll. Dabei bedeutet:

 SCOPE=MEMORY: Die Änderung erfolgt für die laufende Instanz und nicht im SPFILE. Der Parameter muss dynamisch änderbar sein.

 SCOPE=SPFILE: Der Änderung erfolgt ausschließlich im SPFILE. Die Änderung wird nach dem Neustart der Instanz wirksam.

 SCOPE=BOTH: Die Änderung erfolgt sowohl für die laufende Instanz als auch im SPFILE. Der Parameter muss dynamisch änderbar sein. Im folgenden Beispiel wird der Parameter service_names geändert: SQL> ALTER SYSTEM SET service_names='ORADBA.world,TESTDB' SCOPE=BOTH; System altered.

Eine weitere Möglichkeit zum Auslesen und Bearbeiten des SPFILE ist das Erstellen einer Kopie im Textformat, einer sogenannten Init-Datei. Diese Datei kann mit einem Texteditor bearbeitet und wieder in ein SPFILE zurück kopiert werden: SQL> CREATE PFILE='/tmp/init.ora' FROM SPFILE; File created. SQL> exit $ vi /tmp/init.ora *.db_block_size=8192 *.db_domain='world' *.db_name='ORADBA' *.db_recovery_file_dest='/opt/app/oracle/flash_recovery_area' *.db_recovery_file_dest_size=5218762752 *.diagnostic_dest='/opt/app/oracle' . . .

28

1.5 Produktübersicht Die zentrale Log-Datei der Datenbank ist das „Alert-Log“. Diese Datei befindet sich in einem Unterverzeichnis des Parameters diagnostic_dest. In unserem Fall liegt sie im Verzeichnis /opt/app/oracle/diag/rdbms/oradba/ORADBA/trace. Sie besitzt den Namen alert_<SID>.log. Im Alert-Log finden Sie alle wichtigen Hinweise und Meldungen aus dem laufenden Betrieb sowie Fehlermeldungen, die die Datenbank insgesamt betreffen.

1.5

Produktübersicht Die Oracle-Datenbanksoftware besteht aus vielen einzelnen Produkten und Optionen. Da verliert man schon mal die Übersicht. Die sollte man jedoch haben, da es hierbei auch um Lizenzkosten geht und man viel Geld verschenken kann. Sie sollten aber auch die rechtliche Seite beachten. Oracle-Software ist technisch nur dadurch limitiert, dass bestimmte Produkte und Features in einigen Editionen nicht enthalten sind. Es liegt jedoch immer in der Verantwortung des Anwenders, dass er nur Editionen und Optionen einsetzt, die er lizenziert hat. Mit den Erklärungen und Tabellen im folgenden Abschnitt führen wir Sie durch den Irrgarten.

1.5.1

Oracle-Editionen

Eine Edition ist ein Bündel von Produkten und Features. Die Oracle-Software unterscheidet folgende Editionen:

 Enterprise Edition  Standard Edition  Standard Edition One  Express Edition (10g) Jede Edition, mit Ausnahme der Enterprise Edition, besitzt einerseits Beschränkungen auf die Hardware-Ressourcen, die von der Datenbank genutzt werden (siehe Tabelle 1.3, nächste Seite). Andererseits ist genau festgelegt, welches Produkt, welche Option oder welches Feature in welcher Edition enthalten ist. Oder anders herum gesagt, um ein bestimmtes Produkt oder Feature nutzen zu können, müssen Sie die Edition einsetzen und lizensieren, in der es enthalten ist. Zwar enthält die Enterprise Edition alle Produkte, Optionen und Features, allerdings gibt es hier so genannte „Extra Cost Options (ECO)“. Diese müssen zusätzlich lizensiert werden. Innerhalb der Enterprise Edition gibt es keine Software-technische Beschränkung für die Verwendung eines ECO-Produkts. Für den Bereich Hochverfügbarkeit (Tabelle 1.4, nächste Seite) sind „Total Recall“ und „Active Dataguard“ ausschließlich Bestandteil der Enterprise Edition und gleichzeitig eine Extra Cost Option.

29

1 Schnelleinstieg Tabelle 1.3 Beschränkung der Editionen Enterprise

Standard

Standard One

Express (10g)

Maximum CPU

Keine Beschr.

4 Sockets

2 Sockets

1 CPU

Memory

Keine Beschr.

Keine Beschr.

Keine Beschr.

1 GB

Größe der DB

Keine Beschr.

Keine Beschr.

Keine Beschr.

4 GB

Windows

Ja

Ja

Ja

Ja

Linux

Ja

Ja

Ja

Ja

Unix

Ja

Ja

Ja

Nein

64bit

Ja

Ja

Ja

Nein

Tabelle 1.4 Produkte und Features für Hochverfügbarkeit Hochverfügbarkeit

Enterprise

Standard

Standard One

Express (10g)

Total Recall

ECO

Nein

Nein

Nein

Active Dataguard

ECO

Nein

Nein

Nein

Fail Safe

Ja

Ja

Ja

Nein

Flashback Query

Ja

Ja

Ja

Ja

Flashback Database

Ja

Ja

Ja

Nein

Recovery Manager

Ja

Ja

Ja

Nein

Wie Sie in Tabelle 1.5 für die Produkte und Features der Skalierbarkeit sehen, ist Real Application Clusters in der Standard Edition enthalten und für die Enterprise Edition eine Extra-Cost-Option. Dies ist kein Druckfehler. Im Rahmen einer Marketing-Aktion versucht Oracle damit, das Produkt zu promoten und besser im Markt zu platzieren. Allerdings gibt es, wie Sie bereits erahnen, für den Einsatz von Real Application Clusters im Rahmen der Standard-Edition eine Reihe von Einschränkungen:

 Maximal 2 Knoten pro Cluster  Maximal 4 CPU (Sockets) pro Cluster  Auf der Storage-Seite darf nur ASM und kein anderes Cluster-Dateisystem benutzt werden. Real Application Clusters darf nicht mit der Standard Edition One eingesetzt werden. Tabelle 1.5 Produkte und Features für Skalierbarkeit

30

Skalierbarkeit

Enterprise

Standard

Standard One

Express (10g)

Real Application Clusters

ECO

Ja

Nein

Nein

RAC One Node

ECO

Nein

Nein

Nein

Oracle Clusterware

Ja

Ja

Ja

Nein

Automatic Workload Man.

Ja

Ja

Nein

Nein

1.5 Produktübersicht Skalierbarkeit

Enterprise

Standard

Standard One

Express (10g)

Native Compilation

Ja

Ja

Ja

Nur PL/SQL

In Memory Cache

Ja

Nein

Nein

Nein

Wenn Sie sich den Bereich Sicherheit anschauen, dann ist offensichtlich, dass erweiterte Sicherheits-Features nur in der Enterprise-Edition enthalten sind (siehe Tabelle 1.6). Das heißt keineswegs, dass die Datenbanken der Standard-Editionen unsicher sind. Es handelt sich hierbei um verschärfte Sicherheits-Features, die für besondere Datenbanken benötigt werden. Tabelle 1.6 Produkte und Features für Sicherheit Sicherheit

Enterprise

Standard

Standard One

Express (10g)

Database Vault

ECO

Nein

Nein

Nein

Advanced Security

ECO

Nein

Nein

Nein

Oracle Label Security

ECO

Nein

Nein

Nein

Secure Application Roles

Ja

Nein

Nein

Nein

Virtual Private Database

Ja

Nein

Nein

Nein

Fine Grained Autditing

Ja

Nein

Nein

Nein

Data Encryption

Ja

Ja

Ja

Ja

Im Bereich der Verwaltung ist nur das Produkt „Real Application Testing“ ausschließlich in der Enterprise Edition als Extra Cost Option enthalten. Tabelle 1.7 Produkte und Features für die Verwaltung Wartung

Enterprise

Standard

Standard One

Express (10g)

Real Application Testing

ECO

Nein

Nein

Nein

Enterprise Manager

Ja

Ja

Ja

Nein

Autom. Memory Manag.

Ja

Ja

Ja

Ja

ASM

Ja

Ja

Ja

Nein

Automatic UNDO Manag.

Ja

Ja

Ja

Ja

1.5.2

Management Packs und Plugins

Die Management Packs sind Bestandteil des Enterprise Manager. Sie können sowohl mit dem Enterprise Manager Grid Control als auch mit dem Enterprise Manager Database Control eingesetzt werden. In Oracle 11g gibt es sechs Management Packs:

 Diagnostic Pack  Tuning Pack  Change Management Pack 31

1 Schnelleinstieg

 Configuration Management Pack  Data Masking Pack  Provisioning Pack Management Packs müssen extra lizensiert werden. Wenn Sie als Datenbank-Administrator arbeiten, dann werden Sie vor allem das Diagnostic Pack und das Tuning Pack zu schätzen wissen. Das Diagnostic Pack stellt eine automatische Performance-Diagnose und erweitertes Monitoring mit den folgenden Features zur Verfügung:

 Automatic Workload Repository  Automatic Database Diagnostic Monitor (ADDM)  Active Session History (ASH)  Performance Monitoring  Benachrichtigung im Fall von Ereignissen  Blackouts  Monitoring Templates Das Tuning Pack stellt Features zur Analyse und Optimierung von SQL-Anweisungen zur Verfügung. Voraussetzung für die Verwendung des Tuning Packs ist der Einsatz des Diagnostic Packs. Im Tuning Pack finden Sie folgende Features:

 SQL Access Advisor  SQL Tuning Advisor  Automatic SQL Tuning  SQL Tuning Sets  SQL Plan Management  SQL Monitoring Praxistipp Nach der Standard-Installation einer Datenbank sind die Features für das Diagnostic Pack und das Tuning Pack standardmäßig aktiviert. Sind die Packs nicht lizenziert, müssen Sie dafür Sorge tragen, dass die Features nicht zum Einsatz kommen.

Die beiden Packs lassen sich Software-technisch mit Hilfe des Init-Parameters CONTROL_ MANAGEMENT_PACK_ACCESS aktivieren und deaktivieren. Standardmäßig sind beide Packs aktiviert. Der Parameter kann folgende Werte annehmen:

 DIAGNOSTIC+TUNING  DIAGNOSTIC  NONE SQL > show parameter control_management_pack_access NAME TYPE VALUE ------------------------------------ ----------- ----------------control_management_pack_access string DIAGNOSTIC+TUNING

32

1.6 Online-Hilfe (My Oracle Support)

1.6

Online-Hilfe (My Oracle Support) Der normale Weg für Hilfe bei Problemen geht über die Webseite „My Oracle Support“ (http://support.oracle.com), auch bekannt unter dem früheren Namen „Metalink-Webseite“. Der Zugang ist Passwort-geschützt. Der Zugang erfolgt mithilfe des „Customer Identifier“ (CID), den Sie mit der Lizenzierung der Oracle-Produkte erhalten. Wählen Sie zum Beantragen eines neuen Accounts das Register „Settings“ und dort die Option „Account & Privileges“. Geben Sie den Support Identifier ein und klicken Sie auf „Send Request“. Der Administrator erhält automatisch eine E-Mail zu Ihrem Antrag und kann Sie freischalten. Nach der Freischaltung erhalten Sie per Mail Ihr Passwort. Nachdem Sie Ihr persönliches Passwort erhalten haben, können Sie sich an der SupportWebseite anmelden. Die Webseite arbeitet mit einer Flash-Oberfläche, das heißt, Sie sollten den Adobe Flash Player als Plugin in Ihrem Browser installiert haben. Praxistipp Wenn Sie den Flash-Player nicht installieren können, z.B. weil Sie einen 64-bit Browser verwenden oder nicht mit der Flash-Oberfläche arbeiten wollen, dann können Sie mit der HTML-Version der Webseite arbeiten. Diese erreichen Sie über die URL http://supporthtml.oracle.com.

Auf der Startseite finden Sie die wichtigsten Kategorien in Form von Registern:

 Dashboard  Knowledge Base  Service Requests  Patches & Updates  Systems Beim Auftreten eines Problems, dessen Ursache Sie nicht kennen, ist die erste Anlaufstelle die Knowledge Base (siehe auch Kapitel 9 „Troubleshooting“). Hier finden Sie Informationen darüber, ob es sich möglicherweise um ein bekanntes Problem handelt. Können Sie das Problem eindeutig identifizieren, dann liefert Ihnen die Webseite eine Lösung oder einen Workaround. Die Lösung des Problems kann zum Beispiel im Einspielen einer höheren Oracle-Version oder eines Patches, der Beseitigung von Konfigurationsfehlern oder einer Anpassung auf Betriebssystem-Ebene bestehen. Workarounds müssen dann angewandt werden, wenn Oracle aktuell für die von Ihnen betriebene Plattform und Oracle-Version keine Lösung anbieten kann. Es kann der Fall sein, dass das Problem in einer höheren Oracle-Version gelöst ist und Sie aus unterschiedlichen Gründen kein Upgrade der Datenbank durchführen können. Dann hilft Ihnen der Workaround, das Problem bis zum Upgrade zu umgehen. Praxistipp Ein Workaround sollte stets nur angewandt werden, um das Problem mit sofortiger Wirkung umgehen zu können. Mittel- und langfristig sollten Sie eine saubere Lösung anstreben.

33

1 Schnelleinstieg Das folgende Beispiel zeigt, wie ein Problem durch die Suche in der Knowledge Base gelöst werden kann. Sie wollen sich auf einem Windows-Betriebssystem von der Kommandozeile mit dem Befehl sqlplus / as sysdba als Benutzer „SYS“ lokal an der Datenbank anmelden und erhalten die folgende Fehlermeldung: C:\Users\Lutz>sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Sun Jul 4 15:38:28 2010 Copyright (c) 1982, 2010, Oracle. All rights reserved. ERROR: ORA-01031: insufficient privileges

Geben Sie für eine Analyse des Problems die Suchbegriffe „ORA-01031“, „Windows“ und „sysdba“ in der Knowledge Base ein. Damit finden Sie das Dokument „Troubleshooting ORA-1031 Insufficient Privilege“ mit der Dokumenten-ID 730067.1 (siehe Abbildung 1.21).

Abbildung 1.21 Suche nach dem Fehler ORA-01031 in der Knowledge Base

In diesem Artikel finden Sie den folgenden Hinweis: Troubleshooting ORA-1031 with OS Authentication 1. Check whether the OS user is part of DBA group and OPER group if not add the user to these groups. 2. Check the SQLNET.AUTHENTICATION_SERVICES parameter in the SQLNET.ORA . On unix based platforms either this parameter should not be present or should be set to ALL. On windows this parameter should be set to NTS.

34

1.7 Die Oracle-Dokumentation Die Überprüfung ergibt, dass Punkt 1 erfüllt ist. Der angemeldete Benutzer befindet sich in der DBA-Gruppe, das ist unter Windows die Gruppe ORA_DBA. Dann bleibt noch Punkt 2 zu überprüfen. Hier stellen wir fest, dass der Eintrag des Parameters in der Datei SQLNET.ORA im Verzeichnis %ORACLE_HOME%\network\admin fehlt und nehmen den folgenden Eintrag vor: SQLNET.AUTHENTICATION_SERVICES = (NTS)

Danach funktioniert die Anmeldung an SQL*Plus wie erwartet und das Problem ist beseitigt. Finden Sie auf der Oracle-Supportseite keine Hinweise zu Ihrem Problem, kann eine Suche in Google sinnvoll sein. Allerdings gibt Google wie gewohnt auch hier sehr viele Einträge zurück und es kann einige Zeit in Anspruch nehmen, bis man einen passenden Artikel gefunden hat. Können Sie die Problemursache nicht über die Knowledge Base ermitteln oder finden Sie keinen Fix oder Workaround zu Ihrem Problem, dann sollten Sie einen Service Request bei Oracle Support eröffnen. Für Service Requests existieren vier Dringlichkeitsstufen (Severities). Die Stufe 1 reflektiert ein dringendes Produktionsproblem und ist für Probleme gedacht, bei denen sich die Datenbank nicht mehr starten lässt oder die Funktionalität der Datenbank so stark eingeschränkt ist, das es zu erheblichen Störungen im Betriebsablauf kommt. Oracle stellt für solche Fälle einen 24x7 Support nach dem „Follow-the-sun“-Prinzip zur Verfügung. Im Gegenzug müssen Sie die Erreichbarkeit rund um die Uhr auch auf Ihrer Seite garantieren. Die Bearbeitung der anderen Dringlichkeitsstufen erfolgt normalerweise zu den üblichen Bürozeiten in Ihrer Zeitzone. Weitere Informationen zu „My Oracle Support“ finden Sie in Kapitel 9 „Troubleshooting“. Im Register „Patches & Upgrades” können Sie nach Patches, Upgrades, CPUs oder PSUs suchen und diese herunterladen. Zu jedem Patch oder Upgrade ist eine detaillierte Installationsanweisung beigelegt. Zusätzlich finden Sie eine Liste der Bugs, die damit gefixt werden.

1.7

Die Oracle-Dokumentation Die komplette Oracle-Dokumentation finden Sie auf der Webseite http://www.oracle.com/technetwork. Klicken Sie auf „Support“ und „Documentation“, um die Dokumentation auszuwählen. Sie können die Dokumentation wahlweise im Internet einsehen oder als Zip-Datei herunterladen (siehe Abbildung 1.22).

35

1 Schnelleinstieg

Abbildung 1.22 Die Oracle-Dokumentation für die Datenbank 11g R2 im Internet

Praxistipp Die Dokumentation ist sehr umfangreich und umfasst viele wichtige Details und Beispiele. Gelegentlich kommt es vor, dass die Dokumentation Fehler enthält oder nicht aktualisiert wurde. Suchen Sie in solchen Fällen nach alternativen Dokumenten oder White Papers auf der Webseite von „My Oracle Support“.

1.8

Resümee Die Oracle-Datenbank ist ein komplexes Produkt, das auf vielen Plattformen läuft. Mit Hilfe der Anleitungen und Beispiele in diesem Abschnitt sind Sie in der Lage, die Grundlagen kennen zu lernen sowie eine Datenbank zu erstellen und die ersten Administrationsaufgaben zu lösen. Die Produktübersicht zeigt auf, welche Ausprägung für welchen Zweck eingesetzt werden sollte. Mit der Durcharbeitung der weiteren Kapitel dieses Buches sind Sie in der Lage, Ihr Wissen schrittweise bis zum Experten-Niveau zu vertiefen. Greifen Sie dabei auch auf die in diesem Kapitel empfohlenen Quellen wie die Support-Webseite und die Online-Dokumentation zurück.

36

2 2 Architektur und Administration In diesem Kapitel zeigen wir Ihnen: den Aufbau einer Oracle-Instanz mit ihren Prozessen und Arbeitsspeicherstrukturen;  die Architektur einer Oracle-Datenbank, ihrer Dateien und sonstiger Bestandteile;  Startup und Shutdown einer Datenbank;  eine umfassende Übersicht über Administrationsbefehle, die über die Kommandozeile  abgesetzt werden; grafische Verwaltungswerkzeuge.  Exzellente Kenntnisse der Datenbank-Architektur sind die Basis für jede DBA-Tätigkeit – gleich, ob es sich um Standard-Administrationstätigkeiten, Optimierung, Wiederherstellungsoperationen oder Troubleshooting handelt. Der erste Teil dieses Kapitels soll das erforderliche Verständnis vermitteln. Hier stellen wir Ihnen grundlegende Datenbankstrukturen vor. Dazu zählen neben den zur Datenbank gehörenden Dateien wie Datafiles, Controlfiles und Redologs auch Passwort- und Parameterdateien sowie Arbeitsspeicherstrukturen und Prozesse. Sie erfahren, wie Oracle-Datenbanken für Konsistenz sorgen und lernen das Transaktions- und Sperrmanagement einer Oracle-Datenbank kennen. Der zweite Teil des Kapitels zeigt die konkrete Administration. Sie erfahren, wie man Parameter setzt, den Arbeitsspeicher einer Oracle-Instanz konfiguriert, Prozesse steuert, Pfade für Dump- und Controlfiles setzt, Tablespaces erzeugt und Redologs spiegelt. Eine umfassende Übersicht zu Verwaltungsbefehlen ergänzt das jeweilige Themengebiet. Im dritten Teil zeigen wir Ihnen, wie Sie aktuelle Informationen über eine Oracle-Datenbank aus dynamischen Performance Views und Data Dictionary Views ermitteln. Zudem stellen wir Ihnen grafische Verwaltungswerkzeuge vor, die die Administration einer Oracle-Datenbank erleichtern: Enterprise Manager Database Control, Enterprise Manager Grid Control sowie SQL Developer. Nach Abschluss dieses Kapitels verfügen Sie über das notwendige Know-how, um eine Oracle-Datenbank zu verwalten.

37

2 Architektur und Administration

2.1

Datenbank und Instanz Häufig werden Begriffe wie Datenbank und Instanz synonym verwendet. Es handelt sich jedoch um unterschiedliche Entitäten. Datenbank: Als Datenbank werden jene Teile bezeichnet, die passiv auf Festspeicher  liegen. Dazu zählen Datafiles, Redologs und Controlfiles. Instanz: Beim Starten einer Datenbank werden Arbeitsspeicherbereiche allokiert und  Prozesse gestartet. Dieses Konglomerat aus Arbeitsspeicherstrukturen und Prozessen ist eine Instanz. Alle Aktivitäten einer Datenbank werden über die Instanz ausgeführt. Beispielsweise beim Ändern eines Datensatzes liest zunächst ein Prozess den betreffenden Datenblock aus den Datenbankdateien und überträgt ihn in den Arbeitsspeicher. Dieser Prozess führt im Arbeitsspeicher dann die angeforderten Änderungen aus, bevor ein anderer Prozess den Datenblock wieder in die Datenbankdateien zurückschreibt.

Abbildung 2.1 Datenbank und Instanz

Während die Datenbank den passiven Teil der auf den Festplatten gespeicherten Datafiles, Redologs und Controlfiles darstellt, ist die Instanz mit ihren Arbeitsspeicherstrukturen und Prozessen der aktive Part.

2.2

Physische Architektur einer Oracle-Datenbank Physisch besteht eine Oracle-Datenbank aus etlichen Dateien. Zur Speicherung dieser Datenbankdateien gibt es drei Optionen: Dateisystem  Oracle Automatic Storage Management (ASM)  Raw Devices 

38

2.2 Physische Architektur einer Oracle-Datenbank Als Dateisysteme kommen NTFS, ext3, UFS oder VxFS in Betracht1. Seit Oracle-Database 10g Release 1 gibt es zusätzlich Oracle Automatic Storage Management (ASM), das als Logical Volume Manager mit integriertem Dateisystem für Oracle-Datenbanken agiert2. Als dritte Option können diese Dateien auf Raw Devices gespeichert werden. Ein Raw Device – auch als Raw Partition bezeichnet – ist eine zeichenorientierte Gerätedatei, die den direkten Zugriff auf eine Festplattenpartition erlaubt.

SQL Work Areas Session Memory Private SQL Area

Client-Prozess PGA

Client-Prozess

ServerProzess

Client-Prozess PGA

PGA

ServerProzess

Client-Prozess PGA

ServerProzess

Client-Prozess PGA

ServerProzess

Client-Prozess PGA

ServerProzess

ServerProzess

System Global Area (SGA) Redolog -Puffer

DB Blockpuffer

Shared Pool Library Cache Private SQL Area

Shared SQL Area

UGA Data Dictionary Cache

Server Result Cache

Reserved Pool

Sonstiges

frei I/O Buffer Area

Large Pool Request Queue

Response Queue

Java Pool Streams Pool Fixe SGA

DBWR0 DBWR0 DBWR

CKPT

LGWR

Gespiegelte Controlfiles

Datafiles

Datafiles

ARCH ARCH

Log Group 1

Log Group 2

Log Group 3

Redolog 1a

Redolog 2a

Redolog 3a

RVWR

SMON

PMON

RECO

MMON

MMNL

ParameterDatei

Datafiles Datafiles Redolog 1b

Redolog Redolog 2b 2b

Redolog 3b

Weitere

Archiv. Redologs

Flashback Log

PasswortDatei

Abbildung 2.2 Architektur einer Oracle-Datenbank

Folgende Dateitypen sind für den Betrieb einer Oracle-Datenbank zwingend erforderlich: Datafiles dienen der Speicherung von Daten (Tabellen) und Zugriffstrukturen (Indizes,  Metadaten etc.). Sie speichern die eigentlichen Datenbankinhalte. Redologs sind die physischen Transaktionsprotokolle der Datenbank. Darin wird jede  Datenänderung verzeichnet.

1

Wird Oracle Real Application Clusters (RAC) eingesetzt, so muss ein zertifiziertes Clusterfilesystem verwendet werden. Die Verwendung eines nicht clusterfähigen Dateisystems ist hier nicht möglich. 2 Siehe auch Kapitel 5.

39

2 Architektur und Administration Controlfiles speichern Informationen über den physischen Aufbau einer Oracle-Daten bank. Hierzu zählen Pfad- und Verzeichnisnamen der Datafiles und Redologs, aber auch Konsistenzinformationen3 sowie Informationen zu Datenbanksicherungen, die mit dem Oracle Recovery Manager (RMAN) durchgeführt wurden. Eine Oracle-Datenbank verfügt stets über mindestens ein Datafile4, mindestens zwei Redologs sowie mindestens ein Controlfile. Die Parametrisierung einer Oracle-Datenbank erfolgt über die Parameterdatei. Man spricht hier gelegentlich auch von der Initialisierungsdatei. Es gibt zwei Formate, die eingesetzt werden können: Server Parameter Files (SPFiles) speichern das Parameterset eines Oracle-Systems in  einem proprietären Format und ermöglichen die Verwaltung und die dynamische Änderung von Initialisierungsparametern einer Datenbank mit dem Befehl alter system. Parameter Files (PFiles) sind die etwas ältere Variante von Parameterfiles. Sie sind im  ASCII-Format gespeichert. PFiles können mit Editoren wie Notepad und vi geändert werden, jedoch nicht über den Befehl alter system. PFiles werden umgangssprachlich häufig als Init.ora bezeichnet. Darüber hinaus gibt es einige weitere Datei-Typen, die optional – je nach Konfiguration – im Einsatz sind. Dazu zählen: Passwort-Datei für Benutzer mit Sysdba- oder Sysoper-Privilegien.  Archivierte Redologs speichern und archivieren Redologs.  Temporär-Dateien enthalten Temporär-Segmente der Datenbank.  Flashback Logs enthalten Informationen, um eine Datenbank auf einen Zeitpunkt in  der Vergangenheit zurücksetzen zu können. Block-Change-Tracking-Protokolle speichern Informationen darüber, welche Daten blöcke geändert wurden, in einem Bitmap5. Block Change Tracking kann inkrementelle Datenbanksicherungen mit dem Oracle Recovery Manager (RMAN) enorm beschleunigen. Eine Übersicht aller Dateitypen finden Sie in Tabelle 2.1. Alle Dateitypen werden in den nächsten Abschnitten genauer beschrieben. Administrationsbefehle und Initialisierungsparameter, die für den alltäglichen Betrieb erforderlich sind, finden Sie im zweiten Teil dieses Kapitels.

3

Unter anderem die System Change Number der Datenbank (siehe Abschnitt 2.4.7 „Checkpoints“) Für den System-Tablespace wird mindestens ein Datafile benötigt. Faktisch werden jedoch weit mehr Datafiles für diverse Tablespaces verwendet. Siehe auch Abschnitt 2.2.3, „Tablespaces“. 5 Siehe Kapitel 13. 4

40

2.2 Physische Architektur einer Oracle-Datenbank Tabelle 2.1 Übersicht Dateitypen einer Oracle-Datenbank Dateityp

Obligatorisch

Beschreibung

Speicherort

Datafile

Erforderlich

Speicherung der Daten einer Oracle-Datenbank: Tabellen-, Index-, Temporärund Undo-Segmente

Frei konfigurierbar, Dateierweiterung siehe auch Abschnitt 8.1 „Designing .dbf empfohlen for Performance“

Redologs

Erforderlich

Transaktionsprotokoll der Datenbank

Frei konfigurierbar, siehe auch 8.1 „Designing for Performance“

Dateierweiterung .rdo empfohlen

Archivierte Redologs

Optional, für Produktionssysteme empfohlen

Archivierte Transaktionsprotokolle der Datenbank

Frei konfigurierbar, siehe auch 8.1 „Designing for Performance“

Dateierweiterung .arch empfohlen

Controlfile

Erforderlich

Speicherung von Pfaden und Dateinamen der Datafiles und Redologs, Konsistenzinformationen, Informationen zu Datenbanksicherungen mit RMAN

Frei konfigurierbar, siehe auch 8.1 „Designing for Performance“

Dateierweiterung .ctl empfohlen

ParameterDatei

Erforderlich

Parametrisierung der Datenbank

$ORACLE_HOME/dbs (Linux/Unix) bzw. $ORACLE_HOME/database (Windows)

init<SID>6.ora bzw. spfile<SID>.ora, wobei <SID> für den Namen der Instanz steht.

PasswortDatei

Optional

Authentifizierung für Benutzer mit Privilegien wie sysdba, sysoper und sysasm

$ORACLE_HOME/dbs (Linux/Unix) bzw. $ORACLE_HOME/database (Windows)

orapw<SID> (Linux/Unix) bzw. PWD<SID>.ora (Windows), wobei <SID> für den Namen der Instanz steht.

AlertDatei

Wird von der Daten- Zentrale Log-Datei mit bankinstanz Fehlerinformationen geschrieben

Zielverzeichnis wird durch den alert<sid>.log Initialisierungsparameter background_dump_destination (bis 10g) bzw. diagnostic_dest (ab 11g) festgelegt

TraceDatei

Wird in Fehlerfällen Detaillierte Fehlervon der Datenbank- informationen instanz geschrieben

Zielverzeichnisse werden durch *.trc Initialisierungsparameter festgelegt: user_dump_destination für Benutzer-Traces, background_dump_destination für Hintergrundprozesse sowie core_dump_dest für Core Dumps

6

Dateiname

Mit <SID>: System Identifier (Name der Datenbankinstanz)

41

2 Architektur und Administration Dateityp

Obligatorisch

Beschreibung

Speicherort

Dateiname *.flb

Frei wählbar. Dateierweiterung .bct empfohlen

Flashback Logs

Optional

Logs zum Zurücksetzen einer Datenbank auf einen Zeitpunkt in der Vergangenheit

Flash Recovery Area7

Block Change Tracking Protokoll

Optional

Protokoll geänderter Datenblöcke für inkrementelle Sicherungen mit dem Oracle Recovery Manager

Flash Recovery Area

Die folgenden Abschnitte gehen detailliert auf den internen Aufbau der Datenbank aus physischer Sicht ein.

2.2.1

Datenblöcke

Die kleinste Einheit, die in einer Oracle-Datenbank angesprochen werden kann, ist der Datenbankblock (kurz Datenblock). Alle Daten einer Oracle-Datenbank werden in Blöcken gespeichert, gleich ob es sich um Nutzerdaten handelt oder um Metadaten der Datenbank. Die Standard-Größe eines Datenbankblockes wird beim Anlegen einer Datenbank festgelegt. Sie gilt generell für Tablespaces wie System und Sysaux sowie als Standardwert für alle weiteren Tablespaces. Tablespaces für Benutzertabellen können mit einer vom Standard der Datenbank abweichenden Größe erstellt werden. So ist es möglich, zur Speicherung von Large Objects (LOBs) eine andere Blockgröße zu wählen als für kleine Indizes. Systemrelevante Tablespaces wie system und Sysaux nutzen jedoch stets die Standardblockgröße, die zum Zeitpunkt der Datenbankerstellung festgelegt wurde. Eine Blockgröße gilt stets für einen kompletten Tablespace. Für die Pufferung von Datenblöcken, die von der Standard-Blockgröße der Datenbank abweichen, sind Subcaches zu konfigurieren. Sie können hierfür den Initialisierungsparameter db_k_cache_size setzen, wobei durch die Größe der Datenbankblöcke zu ersetzen ist. Während der Lebenszeit einer Datenbank lässt sich die Standardblockgröße übrigens nicht mehr ändern. Sollte eine Änderung der Standard-Blockgröße erforderlich sein, so muss eine neue Datenbank mit der neuen Blockgröße erstellt und der Datenbestand mittels Export und Import übernommen werden. Daher ist es sinnvoll, sich vor dem Anlegen der Datenbank bereits Gedanken über die Blockgröße zu machen. Gestattet sind 2, 4, 8, 16 sowie 32 KB, üblich sind Werte zwischen 4 KB und 16 KB abhängig von Betriebssystem und Anwendung. Eine größere Blockgröße benötigt weniger Overhead im Verhältnis zur Speicheremenge und ermöglicht effizientere Diskzugriffe bei großen Objekten. Bei kleinen Objekten führen große Datenblöcke unter Umständen zu unnötigen Verschnitt.

7

42

Siehe Kapitel 13.

2.2 Physische Architektur einer Oracle-Datenbank Sofern die Blockgröße von der Größe der Betriebssystemblöcke (Pagesize) abweicht, sollten Sie darauf achten, dass Sie die Blockgröße stets auf ein ganzzahliges Vielfaches der Betriebssystemblockgröße setzen8. Praxistipp Generell gilt: Für Large Objects (LOBs) mit Bild- und Tondaten sollten Sie eher große Blockgrößen, für Tabellen mit kurzen Satzlängen eher kleine Blockgrößen einsetzen. Oft bestehen Anwendungen aus Daten unterschiedlichster Satzlängen. In diesem Fall kann die Blockgröße der Datenbank auf 4 oder 8 KB gesetzt sein. Für Daten größerer Satzlängen wie LOBs können zusätzliche Tablespaces mit vom Standard abweichenden Blockgrößen erstellt werden. Auf keinen Fall sollten Sie einen Tablespace beispielsweise mit einer Blockgröße von 4K auf 8K Sector Size Disks erstellen, da dies die Performance mindert.

Interner Aufbau Ein Datenblock unterteilt sich intern in einen Kopf- und einen Daten-Teil. Der Kopf enthält Metainformationen wie die Blockadresse und den Segmenttyp9 der in ihm gespeicherten Daten. Im Kopfbereich sind zusätzlich das Tabellenverzeichnis und das Zeilenverzeichnis gespeichert. Im Tabellenverzeichnis ist vermerkt, zu welchen Tabellen die Dateninhalte gehören10. Das Zeilenverzeichnis gibt an, welche Zeilen gespeichert sind und unter welcher Adresse jede einzelne dieser Zeilen im Datenbereich des Blockes abgerufen werden kann. Das Zeilenverzeichnis kann bei zunehmender Anzahl an Datenzeilen wachsen, es verkleinert sich jedoch nicht mehr. Wurden in einem Block, der inzwischen leer ist, irgendwann einmal 50 Zeilen gespeichert, so belegt das Zeilenverzeichnis weiterhin etwa 100 Byte an Platz, um Meta-Informationen von 50 Datenzeilen zu speichern. Das Konglomerat aus Kopfdaten, Tabellen- und Zeilenverzeichnis nennt man Block Overhead. Dieser bewegt sich in der Regel zwischen etwa 80 und 120 Byte. Zusätzlich wird für jede Transaktion, die den Datenblock ändert, vorübergehend ein Transaktionsheader genutzt, der etwa 23 Byte benötigt. Beide Teile, der Kopf- und der Datenbereich sind in ihrer Größe variabel. Beim Befüllen eines Blockes wachsen sie einander entgegen. Der dazwischenliegende freie Speicherplatz verringert sich dann entsprechend.

8

Die Betriebssystemblockgröße ermitteln Sie abhängig vom Betriebsystem. Linux: stat -f HPUX: vgdisplay -v oder df -g|grep -i "block size" Solaris: df -g Windows: fsutil, fsinfo, ntfsinfo Tru64: lsfs -q 9 Tabellen-, Index-, Temporär- oder Undo-Segment 10 Bei Clustertabellen kann es sich um Datenzeilen mehrerer Tabellen handeln

43

2 Architektur und Administration Kopfdaten Tabellenverzeichnis Zeilenverzeichnis

Block-Overhead

Freier Platz

Datenzeilen

Abbildung 2.3 Aufbau eines Oracle-Datenblocks

Datenblöcke unterliegen bestimmten Konsistenzrichtlinien. Wurde ein Datenblock beispielsweise durch die Speicherung über einen defekten Festplattencontroller beschädigt, kann er nicht mehr gelesen und interpretiert werden. Oracle bietet hierfür die Blockreparatur mit dem Recovery Manager (RMAN) an. Genauere Informationen dazu finden Sie in Abschnitt 13.3.36 „Wiederherstellung eines Datenblockes“.

2.2.2

Datafiles

Ein Tablespace ist ein Speicherbereich für Daten und Zugriffsstrukturen, Temporärsegmente sowie Undo-Informationen. Jeder Tablespace besteht aus mindestens einem Datafile. Umgekehrt ist jedes Datafile genau einem Tablespace zugeordnet. Oracle-Datenbanken benötigen mindestens ein Datafile, das für den System-Tablespace verwendet wird sowie ein weiteres für den Tablespace sysaux. Doch in der Praxis werden sehr viel mehr Datafiles eingesetzt: Man unterteilt in Speicherbereiche für Anwendungsund Indexdaten, für Temporärsegmente und Undo-Informationen und speichert diese in eigene Tablespaces.11

Abbildung 2.4 Tablespaces und Datafiles

11

44

Siehe auch Abschnitt 2.2.3 „Tablespaces“.

F:\oradata\ meineDB\ index_02.dbf

F:\oradata\ meineDB\ index_01.dbf

Benutzerdaten: Indizes

E:\oradata\ meineDB\ data_03.dbf

E:\oradata\ meineDB\ data_02.dbf

Benutzerdaten: Tabellen

E:\oradata\ meineDB\ data_01.dbf

D:\oradata\ meineDB\ temp_01.dbf

Temporary Tablespace

F:\oradata\ meineDB\ undo_03.dbf

D:\oradata\ meineDB\ undo_01.dbf

D:\oradata\ meineDB\ system_01.dbf

E:\oradata\ meineDB\ undo_02.dbf

Undo Tablespace

System Tablespace

2.2 Physische Architektur einer Oracle-Datenbank Datafiles werden als physische Dateien im Betriebssystem gespeichert. Für ihre Speicherung können normale Dateisysteme, aber auch Clusterdateisysteme, Automatic Storage Management (ASM) oder Raw Devices und, ab Oracle 10.2, auch Block Devices zum Einsatz kommen12. Jedes Datafile besteht aus Datenblöcken. Vor der Bearbeitung eines Datenblockes wird dieser vom Festspeicher in den Arbeitsspeicher gelesen. Ändert man Daten eines Blocks, so werden diese Änderungen aus Performance-Gründen nicht synchron in die Datafiles zurückgeschrieben, sondern zunächst in den Redologs protokolliert. Das Schreiben in die Datafiles erfolgt dagegen asynchron über den Database-Writer-Prozess. Er schreibt in Intervallen geänderte Blöcke anhand einer Dirty-List in die Datafiles. Kommt es zu einem Ausfall des Datenbankservers, so ist es unproblematisch, wenn ein geänderter Block aus dem Arbeitsspeicher noch nicht in die Datafiles geschrieben wurde: Alle Änderungen lassen sich aus den Redologs reproduzieren. So kann man die Datenbank auch nach einem Ausfall wieder in einen konsistenten Zustand überführen. Oracle-Systeme führen diesen als „Crash Recovery“ bezeichneten Vorgang beim Öffnen der Datenbank automatisch durch. Informationen zur Erstellung und Verwaltung von Tablespaces und Datafiles finden Sie im Abschnitt 2.6 „Verwaltung von Tablespaces“.

2.2.3

Tablespaces

Erstellt man Datenbankobjekte wie Tabellen oder Indizes, so werden diese in einem Tablespace abgelegt. Ein Tablespace ist ein Speicherbereich in einer Datenbank. Oracle kennt verschiedene Tablespace-Typen, die nachfolgend vorgestellt sind. System-Tablespace Der System-Tablespace enthält systemrelevante Daten. In ihm ist das Data Dictionary13 der Datenbank gespeichert. Zudem wird hier ein System-Rollbacksegment14 angelegt, das unmittelbar nach der Datenbankerstellung zur Verfügung steht. Der System-Tablespace wird implizit bei der Erstellung der Datenbank angelegt. Seine Datendateien werden mit der datafile-Klausel des create database-Befehls angegeben. Wie bei jedem anderen Tablespace können auch für den System-Tablespace mehrere Datafiles angelegt werden. Ähnlich wie für die root-Partition eines Betriebssystems sollte auch der System-Tablespace für normale Anwender gesperrt sein. Hier sollten ausschließlich das interne Data Dictionary der Datenbank sowie andere systemrelevante Informationen abgelegt werden. Der Eigentümer der Basistabellen des Data Dictionary ist der Benutzer SYS. Dieser Benut-

12

Siehe auch Kapitel 4 „Speicherplatzverwaltung“. Es enthält die Metadaten der Datenbank: Informationen zu Benutzern, Datenbankobjekten, Rechtestrukturen etc. sind hier hinterlegt. 14 Siehe auch Abschnitt 2.4.3 „Undo Management“ 13

45

2 Architektur und Administration zer ist stets Eigentümer der Datenbank und – ähnlich dem root-User eines Betriebssystems – umfassend berechtigt. Auf die Tabellen des Data Dictonary lassen sich keine DML-Befehle wie Insert, Update oder Delete ausführen. Die Aktualisierung dieser Tabellen erfolgt vielmehr implizit durch DDL- und DCL-Befehle15. So hinterlegt beispielsweise der Befehl create table MetaInformationen in den Basistabellen des Data Dictionary: Tabellenname, Spalten, Datentypen etc. Die hierfür erforderlichen Insert-Statements werden dabei implizit als Folge des create table-Statements im Hintergrund ausgeführt. Diese implizit ausgeführten SQLStatements auf das Data Dictionary nennt man auch Rekursives SQL. Der initiale Platzbedarf des System-Tablespaces liegt meist zwischen 600 bis 800 MB. Sysaux-Tablespace Im Laufe der Oracle-Versionen gab und gibt es immer wieder neue Optionen und Funktionen. Diese sind zwar logisch durch eigenständige Datenbank-Schemata getrennt, wurden jedoch physisch gemeinsam mit systemrelevanten Daten gespeichert: Ihre Daten wurden in Versionen vor Oracle Database 10g meist im System-Tablespace hinterlegt16. Beispiele solcher Optionen und Funktionen sind Stored Outlines, (Benutzerschema OUTLN), der Workspace Manager (Benutzerschema WMSYS) und der Oracle Warehouse Builder (Benutzerschema OWBSYS). Seit Oracle Database 10g werden zusätzlich automatisiert Performance-Statistiken der Datenbank im Automatic Workload Repository (AWR) gespeichert. Da dies erheblichen Speicherplatz erfordern kann, hat der Hersteller im selben Release den Tablespace Sysaux17 eingeführt, um Daten der Zusatzoptionen der Datenbank zu speichern und diese aus dem System-Tablespace auszulagern. Seit 10g R1 ist der Sysaux-Tablespace ein zwingender Bestandteil einer Oracle-Datenbank. Er wird wie der System-Tablespace beim Anlegen einer Oracle-Datenbank ab 10g R1 erstellt. Bei Upgrades von Oracle-Datenbanken vor 10g auf eine der aktuellen Versionen ist daher darauf zu achten, dass dieser Tablespace der Datenbank angefügt wird. Typische Bestandteile des Sysaux-Tablespaces sind Objekte des Benutzers Systems und des Enterprise Managers. Aber auch OLAP, Data Mining, Spatial, der Logminer sowie Ultra Search und Oracle Text legen Objekte im Tablespace Sysaux ab. 15

DML, DDL und DCL sind Subsets des SQL-Befehlssatzes. DML-Befehle (Data Manipulation Language) sind Befehle zur Änderung von Dateninhalten. Dazu zählen Insert, Update und Delete. DDL-Befehle (Data Definition Language) sind Befehle, die Strukturänderungen an Datenbankobjekten wie Tabellen, Views, Indizes oder Synonymen bewirken. Dazu zählt beispielsweise das Erstellen oder Löschen einer Tabelle, Anfügen oder Löschen von Spalten usf. DCL (Data Control Language) sind SQL-Befehle zur Rechtevergabe. 16 Die Speicherung systemrelevanter Daten gemeinsam mit Anwendungsdaten oder Daten zusätzlicher Datenbankoptionen und Features kann zu erheblichen Problemen führen: Benötigt eine Option oder ein Feature übermäßigen Speicherplatz, kann der System-Tablespace voll laufen. Ein vollständig gefüllter System-Tablespace kann unter anderem zu einem kompletten Systemausfall führen. Vergleichbar ist dies mit einem Voll-Laufen einer Root-Partition des Betriebssystems. 17 Für system auxiliary.

46

2.2 Physische Architektur einer Oracle-Datenbank Die View v$sysaux_occupants zeigt Komponenten, die Objekte in diesem Tablespace speichern sowie den hierfür genutzten Speicherplatz. Einige Komponenten können in alternative Tablespaces migriert werden. Die hierfür gültige Methode zeigt die Spalte move_procedure der View v$sysaux_occupants. Der initiale Platzbedarf des SysauxTablespace sollte mit einer Größe von 800 MB bis zu wenigen GB kalkuliert werden. Undo Tablespace In einem Undo Tablespace sind ausschließlich Undo-Segmente gespeichert. Undo-Segmente gewährleisten folgende Funktionen: Rollbacks von Transaktionen  Lesekonsistenz  Flashback Query  Korrekturen logischer Korruptionen des Datenbestands mit Flashback Transaction  Wird eine Datenzeile geändert, so speichert der Oracle-Server stets zunächst ein als before image bezeichnetes Abbild des Datensatzes in einem Undo-Segment, bevor die Datenmanipulation durchgeführt wird. Dies ermöglicht die Option eines Rollbacks einer offenen Transaktion: Die before images werden in diesem Fall einfach aus dem Undo Tablespace zurück in die Datenzeile übernommen. Zudem garantieren Undo-Segmente ein konsistentes Lesen ohne dirty reads: Werden Datenzeilen gelesen, während eine zweite Session den darunter liegenden Datenbestand ändert, so wird der Datenbestand konsistent zur System Change Number (SCN)18 zum Startpunkt der Abfrage angezeigt. Dazu entnimmt der Server-Prozess die zum Startzeitpunkt konsistente Satzversion entweder aus dem Datenblock selbst oder bei Änderung des Datensatzes über einen Zeiger im Blockheader aus dem before image eines Undo-Segments. Dirty reads, die Anzeige von Änderungen, die im Verlauf der Abfrage ausgeführt werden, sind bei Oracle-Datenbanken somit ausgeschlossen. Seit Oracle 9i wird mit der Flashback-Option die Möglichkeit unterstützt, historische Datenbestände auszuwerten und diese im Bedarfsfall auch zur Behebung logischer Korruptionen in der Datenbank zu nutzen. Auch Flashback Query nutzt die before images des Undo Tablespace. Weitere Informationen zur Flashback-Funktionalität finden Sie in Abschnitt 13.6 „Flashback“. Permanente und Temporary Tablespaces Tablespaces, wie der system- und der sysaux-Tablespace, Undo Tablespaces sowie Tablespaces für Benutzerdaten werden als permanente Tablespaces bezeichnet. Ein permanenter Tablespace persistiert Daten meist in Form von Datenbankobjekten wie Tabellen und Indizes. Aber auch Undo-Informationen sind in der Datenbank persistent hinterlegt. Ein 18

Die System Change Number (SCN) wird bei jedem Commit einer Datenbanktransaktion inkrementiert und gibt einen eindeutigen, konsistenten Zustand der Datenbank an. Siehe auch Abschnitt 2.4.6 „System Change Number“.

47

2 Architektur und Administration Temporary Tablespace dagegen speichert Daten in Form von Temporärsegmenten. Diese bleiben maximal für die Dauer einer Benutzersession bestehen. Locally Managed19 Temporary Tablespaces nutzen dazu Tempfiles, die für die Speicherung von Daten für das Hashing, von Sorts und ähnlichen Operationen optimiert wurden. Tempfiles sind den permanenten Datafiles sehr ähnlich. Es gelten nur einige Ausnahmen: Permanente Datenbankobjekte wie Tabellen oder Indizes können nicht in Tempfiles ge speichert werden. Tempfiles befinden sich stets im Nologging-Modus, das heißt, Änderungen werden nie mals in Redologs protokolliert . Tempfiles können nicht read-only gesetzt werden.  Bei der Erstellung von Tempfiles wird nicht immer der vollständige Plattenplatz allo kiert. Auf Dateisystemen, wie sie unter Linux und Unix üblich sind, werden Tempfiles als Sparse Files erstellt. Hier werden Blöcke nicht während der Dateierzeugung oder während eines resizing, sondern erst bei deren erster Nutzung belegt. Informationen zu Tempfiles finden Sie in den Views dba_temp_files und v$tempfile.  Sie werden nicht – wie andere Dateien – in den Views dba_data_files oder v$datafile angezeigt. Bei Erstellung einer neuen Datenbank wird mit der Klausel default temporary tableein Temporary Tablespace erzeugt, der als Standard für jene Datenbankbenutzer gilt, denen nicht explizit ein anderer Temporary Tablespace zugewiesen wurde.

space

Smallfile und Bigfile-Tablespaces Oracle unterscheidet zwischen Smallfile- und Bigfile-Tablespaces: Ein Smallfile-Tablespace besteht aus einem oder mehreren Datafiles.  Bigfile-Tablespaces nutzen nur genau eine Datendatei, die maximal 232 Datenblöcke  enthalten und bis zu bis zu 128 TB groß werden kann. Praxistipp Überlegungen, ob man eine sehr große Datei für einen Tablespace verwenden möchte oder aber viele kleine, sollte man am besten vor dem Erstellen einer Datenbank bzw. eines neuen Tablespaces anstellen. Kleinere Dateien vereinfachen unter Umständen die Handhabung: Sie können schneller kopiert und verschoben werden. Auch die parallele Wiederherstellung mehrerer Dateien aus einer Sicherung ist unter Umständen sehr viel schneller als die einer einzelnen sehr großen.

Bigfile-Tablespaces sollten ausschließlich gemeinsam mit Automatic Storage Management (ASM) oder einem Logical Volume Manager (LVM) eingesetzt werden. Auch ist zu be-

19

48

In früheren Versionen wurden noch Dictionary Managed Temporäry Tablespaces verwendet. Diese sind jedoch inzwischen obsolet. Ausführliche Informationen finden Sie in der Oracle-Dokumentation der Version 9i.

2.2 Physische Architektur einer Oracle-Datenbank rücksichtigen, dass Bigfile-Tablespaces nur auf solchen Betriebssystemen wirklich sinnvoll genutzt werden können, die ultragroße Dateigrößen unterstützen. Erst ab Oracle 11g werden Bigfile-Tablespaces auch bei Backup- und Recovery-Prozeduren gut handhabbar: Da ein Bigfile-Tablespace eine einzige Datendatei umfasst und Oracle RMAN vor dem Release 11g nur parallelisieren konnte, wenn mehrere Datafiles gelesen wurden, dauerte ein vollständiges Backup sehr viel länger als die Sicherung von mehreren kleineren Datendateien, die in der Summe gleich groß sind wie der BigfileTablespace20. Mit Oracle Database 11g wurde das Multisection Backup eingeführt. So lässt sich eine einzelne Datenbankdatei mit mehreren parallelen Prozessen sichern. Dabei können Bereichsgrößen angegeben werden. Die Datenbankdatei wird dann in gleich große Bereiche unterteilt und von parallelen Prozessen verarbeitet. Praxistipp Ab Oracle 11g sind Bigfiles durchaus einsetzbar. In Releases davor raten die Autoren eher zur Verwendung mehrerer kleinerer Datendateien. Ein wichtiger Faktor ist die Verwendung von Werkzeugen, die Größenbeschränkungen bei der Dateiverarbeitung setzen. So sollten Sie Ihre Sicherungswerkzeuge sowie Ihr Betriebssystem auf entsprechende Limits prüfen und im Bedarfsfall die Maximal-Größe Ihrer Datafiles unterhalb dieser Limits setzen.

2.2.4

Informationen zu Tablespaces im Data Dictionary

Informationen zu bestehenden Tablespaces zeigen die Views

v$tablespace

und

dba_

tablespaces: SELECT FROM

tablespace_name, block_size, status, contents, logging, bigfile dba_tablespaces;

SELECT FROM

name, bigfile v$tablespace;

2.2.5

Empfehlungen zum Tabelspace-Layout

Es empfiehlt sich die Trennung von Tabellen- und Index-Daten. Wartungsarbeiten werden so erleichtert. So kann beispielsweise eine gelegentliche Reorganisation des Index-Tablespace mittels Online Rebuild aufgrund der höheren Volatilität von Indexstrukturen durchaus sinnvoll sein. Sorgen Sie zudem dafür, dass Benutzerdaten nicht im System- oder Sysaux-Tablespace gespeichert werden. Tabelle 2.2 zeigt ein typisches Tablespace-Layout.

20

Oracle 10g verwendet pro Datendatei nur einen Slave-Prozess.

49

2 Architektur und Administration Tabelle 2.2 Beispiel eines Tablespace-Layoutes. Tablespace

Typ

Zweck

Anfangsgröße (M)

SYSTEM

Permanent

Speicherung systemrelevanter Daten wie der Metadaten des Data Dictionary

800

SYSAUX

Permanent

Speicherung von Daten zu Datenbankoptionen

800

TEMP

Temporär

Temporär-Segmente

Mind. 20021

UNDO

Permanent

Undo-Segmente

Mind. 20022

USERS

Permanent

Benutzerdaten

50

EXAMPLE

Permanent

Beispiel-Schemata

200

BWM_DATA

Permanent

Daten der Anwendung BWM23

Anwendungsabhängig

BWM_INDEX

Permanent

Indizes der Anwendung BWM

Anwendungsabhängig

TXP_DATA

Permanent

Daten der Anwendung TXP

Anwendungsabhängig

TXP_INDEX

Permanent

Indizes der Anwendung TXP

Anwendungsabhängig

UTL_DATA

Permanent

Daten der Anwendung UTL

Anwendungsabhängig

UTL_INDEX

Permanent

Indizes der Anwendung UTL

Anwendungsabhängig

Praxistipp Bei neuen Datenbankanwendungen können oftmals die erforderlichen Größen des Undo Tablespaces und des Temporary Tablespaces nicht von vorneherein abgeschätzt werden. Erstellen Sie in diesem Fall einen Tablespace mit einer Initialgröße, einer automatischen 24 Erweiterung und einer Maximalgröße . Achtung: Sofern keine Maximalgröße angegeben wird, wächst ein Datafile unbegrenzt.

Informationen zur Erstellung und Verwaltung von Tablespaces finden Sie im Abschnitt 2.6 „Verwaltung von Tablespaces“.

21

Die Betriebsgröße des Temporary Tablespaces ist von der Art der Anwendung und deren SQL-Statements abhängig: Werden häufig SQL-Statements genutzt, die Sortierungen großer Datenmengen oder die Verwendung von Temporärtabellen erfordern, muss die Größe des Temporary Tablespaces darauf abgestimmt werden. Dies kann jedoch auch später noch korrigiert werden. 22 Die erforderliche Betriebsgröße des Undo Tablespaces ist primär von zwei Faktoren abhängig: Dem Transkationsvolumen sowie der Zeitdauer, für die before images in den Undo-Segmenten aufbewahrt werden sollen. Siehe auch Abschnitt 2.6.13 „Verwaltung von Undo Tablespaces“. Die Größe kann auch später noch problemlos korrigiert werden. 23 BWM, TXP und UTL stehen stellvertretend als Kürzel von Anwendungsnamen. 24 Weitere Informationen zur Klausel autoextend finden Sie im Abschnitt 2.6.4 „Tablespaces vergrößern und verkleinern“

50

2.2 Physische Architektur einer Oracle-Datenbank

2.2.6

Redologs

Jede Datenänderung wird in den Redologs protokolliert. Sie dienen als Transaktionslogs der Datenbank. Fällt ein Datenbanksystem beispielsweise durch einen Stromausfall aus, so lassen sich alle Datenänderungen, die noch nicht in die Datenblöcke geschrieben wurden, über die Redologs nachvollziehen. Auch bei einer Wiederherstellung einer Datenbank aus einer Sicherung können Änderungen, die nach der Sicherung stattfanden, über solche Transaktionslogs nachvollzogen werden. Dazu ist erforderlich, dass die Datenbank im Archive Log Modus betrieben wird. In diesem Modus werden Redologs archiviert, bevor sie mit neuen Transaktionsinformationen überschrieben werden25. Oracle Redologs beinhalten ein physisches Transaktionslog in Form eines Change-Vektors, der unter anderem aus der Zeilenadresse sowie der eigentlichen Änderung besteht. Eine Oracle-Datenbank benötigt mindestens zwei Redologs. Diese werden zyklisch beschrieben: Ist die erste Log-Datei voll, so erfolgt ein Log Switch auf die zweite. Ist diese gefüllt, erfolgt ein Log Switch auf die nächste und so fort. Mit jedem Log Switch wird eine neue Log Sequence Number vergeben, die innerhalb einer Inkarnation26 der Datenbank eindeutig ist. Wurden alle Redolog-Gruppen beschrieben, wird wieder auf die erste LogDatei zugegriffen, deren Informationen damit überschrieben werden. Betreibt man die Datenbank nicht im Archive Log Modus, sind somit alte Transaktionsinformationen verloren. Im Regelbetrieb einer Datenbank stellt dies kein Problem dar. Wird eine Datenbank aber aus einem Backup wiederhergestellt, so können archivierte Redologs dafür sorgen, dass alle Transaktionen seit der letzten Vollsicherung nachvollzogen werden können. Die Datenbank ist nach diesem als Recovery bezeichneten Vorgang wieder verlustfrei auf dem aktuellen Stand. Produktionssysteme werden daher meist im Archive Log Mode betrieben. Bei Entwicklungssystemen ist dies nicht unbedingt notwendig, sofern im Fehlerfall die Wiederherstellung einer alten Sicherung genügt. Allgemeine Informationen zu Redologs Die Konfiguration aktueller Redolog-Gruppen können Sie der View v$log entnehmen: SELECT thread#, group#, members, status, bytes FROM v$log;

Die einzelnen Redolog-Dateien inklusive der Pfade und Namen finden Sie in v$logfile: SELECT group#, member FROM v$logfile;

Wird eine Datenbank mit Real Application Clusters betrieben, so benötigt jede Datenbankinstanz ein eigenes Set an Redolog-Gruppen, die auch als „instance thread“ bezeichnet werden.

25 26

Siehe auch Abschnitt 2.7.12 „Der Archive Log Modus“ Siehe Kapitel 13 „Backup und Recovery“.

51

2 Architektur und Administration Spiegelung von Redologs Redologs können mit Datenbankmitteln gespiegelt werden. Dazu werden Redologs in Gruppen zusammengefasst. Alle Member einer Redolog-Gruppe sind identisch und werden von der Datenbank zeitgleich beschrieben. Meist legt man zwei oder mehr Member einer Redolog-Gruppe auf unterschiedliche Devices (Festplatten, LUNs). Fällt nun eine dieser Devices aus, kann man die Datenbank noch mit dem Spiegel weiter betreiben. Oft werden zwei, in hochsensiblen Systemen durchaus auch drei, gespiegelte Member je Gruppe konfiguriert. Abbildung 2.5 zeigt drei Redolog-Gruppen mit je zwei gespiegelten Redolog-Membern, die auf unterschiedlichen Plattensystemen abgelegt sind. Disk 1 Log Group 1

Log Group 2

Log Group 3

Redolog 1a

Redolog 2a

Redolog 3a

Disk 2

Redolog 1b

Redolog Redolog 2b 2b

Redolog 3b

Abbildung 2.5 Drei Redolog-Gruppen mit je zwei Mitgliedern

Die Anzahl an gespiegelten Membern einer Gruppe finden Sie in v$log.members. Die folgende Abfrage gibt zudem alle Gruppen und assozierten Logs detailliert aus: BREAK ON group# SKIP 1 COL member FORMAT a30 SET LINES 120 SET PAGES 300 SELECT g.group#, round (g.bytes/1024/1024) "Size MB", f.member FROM v$log g, v$logfile f WHERE g.group# = f.group#;

Größe der Redologs Die Größe eines Redolog können Sie beim Anlegen bestimmen. Typisch sind Größen zwischen 10 und 500 MB, abhängig vom Transaktionsvolumen. Nach dem Anlegen lässt sich diese Größe nicht mehr ändern. Fügen Sie stattdessen einfach neue Gruppen mit der neuen Dateigröße an und entfernen Sie anschließend die alten. Da der Wechsel eines Redologs einen gewissen Overhead erzeugt, sollte die Größe der Logs so gewählt werden, dass Log Switches auch in Spitzenlasten nicht häufiger als etwa alle 5 Minuten stattfinden. Folgende Abfrage zeigt die Größen aktueller Redo Logs :

52

2.2 Physische Architektur einer Oracle-Datenbank SELECT group#, members, round(bytes /1024/1024) "Size MB" FROM v$log;

Aktive und inaktive Redologs Eine Instanz schreibt zu einem gegebenen Zeitpunkt stets in genau eine Redolog-Gruppe. Während ein Redolog beschrieben wird, trägt es den Status current. Nach einem Log Switch gilt ein Redolog noch als aktiv, solange es Informationen zu Änderungen an Datenblöcken enthält, die noch nicht durch den Database Writer in die Datafiles übertragen wurden. In diesem Fall wird es bei einem Crash für ein Instance Recovery benötigt. Der interne Status ist dementsprechend active. Redolog Files, die nicht mehr für ein Instance Recovery benötigt werden, erhalten den Status inactive. Die View v$log zeigt den Status einer Redolog-Gruppe: SELECT group#, status FROM v$log;

Da alle Member einer Redolog-Gruppe zeitgleich beschrieben werden, ist der Status für alle Redolog-Member einer Gruppe auch stets derselbe. Log Sequence Number Eine Log Sequence Number ist ein eindeutiger Bezeichner, der bei jedem Log Switch zur nächsten Redolog-Gruppe inkrementiert wird. Sofern der Archive Log Modus aktiviert ist, übernimmt die archivierte Version eines Redologs diese Sequence Number. Die aktuelle Log Sequence Number einer Gruppe zeigt die View v$log: SELECT thread#, group#, sequence# FROM v$log;

Sequence Numbers archivierter Redologs können über v$archived_log ermittelt werden: SELECT name, thread#, sequence# FROM v$archived_log;

Praxistipp War der Archive Log Mode bereits einmal aktiviert und wurde später deaktiviert, zeigt diese View auch später noch die Historie. So kann der „falsche“ Eindruck entstehen, die Datenbank laufe noch immer im Archive Log Modus.

Erstellung und Verwaltung von Redologs Informationen zur Erstellung und Verwaltung von Redologs finden Sie im Abschnitt 2.7 „Verwaltung von Redologs“.

2.2.7

Controlfiles

Controlfiles bilden die Struktur der Datenbank ab: In Ihnen sind alle Pfade und Namen der Datafiles und Redologs sowie deren aktueller Status verzeichnet. Werden Änderungen an der physischen Struktur der Datenbank vorgenommen, indem beispielsweise Datafiles oder Redologs hinzugefügt, gelöscht oder verschoben werden, so wird dies im Controlfile umgehend vermerkt.

53

2 Architektur und Administration Zusätzlich verzeichnet das Controlfile Informationen über Datenbanksicherungen, die mit dem Recovery Manager (RMAN) ausgeführt wurden. Weitere Informationen wie der Name der Datenbank sowie Konsistenzinformationen27 werden hier vorgehalten. Im Falle eines Datenbank-Crashs werden diese Informationen für ein Crash- und im Falle der Verwendung von RMAN auch für ein Media-Recovery benötigt. Controlfiles bilden damit so etwas wie das Rückgrat einer Oracle-Datenbank. Ein Controlfile enthält folgende Informationen: Name und Erstellungszeitpunkt der Datenbank  Pfade und Namen aller zur Datenbank gehörenden Datafiles und Redologs  Status-Informationen aller verzeichneten Tablespaces sowie der Datafiles und Redologs  Die aktuelle Log Sequence Number der Redologs  Informationen zur Redolog-Historie  Informationen zur Archivierung der Redologs  Informationen zu Datenbanksicherungen mit RMAN  Konsistenz-Informationen der Datenbank  Die Informationen sind in unterschiedlichen Bereichen in den Controlfiles gespeichert. Jeder dieser Bereiche besteht aus einem Set von Records, der einen Aspekt der Datenbank beschreibt. Ein Controlfile enthält zwei Record-Typen: Zirkulär wieder verwendbare und solche, die nicht zirkulär wiederverwendet werden. Diese sind in den folgenden Abschnitten genauer dargestellt. Zirkulär wiederverwendbare Records Zirkulär wiederverwendbare Records enthalten Slots, die zyklisch wieder verwendet werden können. Sind alle Record-Slots gefüllt, so wird ein Record, der veraltet ist, überschrieben. Ist kein veralteter Record-Slot vorhanden, der überschrieben werden darf, so erweitert die Datenbank das Controlfile. Beispiele solcher zirkulär wiederverwendbarer Bereiche sind Records zu archivierten Redologs oder zu RMAN-Sicherungen. Nicht zirkulär wiederverwendbare Records Nicht zirkulär wiederverwendbare Records enthalten kritische Informationen, die nicht überschrieben werden dürfen und die sich nur selten ändern. Dazu zählen Informationen über Tablespaces, Datafiles und Redologs. Oracle-Datenbanken nutzen diese nur dann erneut, wenn das entsprechende Objekt gelöscht wurde. Spiegelung der Controlfiles Da die in Controlfiles gespeicherten Informationen von immenser Bedeutung sind, empfiehlt es sich, diese zu spiegeln und zusätzlich regelmäßig zu sichern. Oracle bietet für die

27

54

u.a. in Form der System Change Number (SCN)

2.2 Physische Architektur einer Oracle-Datenbank Spiegelung eigene Bordmittel an, auch als Multiplexing bezeichnet. Dazu werden zwei oder mehr Kopien der Controlfiles angelegt, die – aus Sicherungsgründen – am besten auf unterschiedliche physische Storages zu speichern sind. Bei Verlust eines Controlfiles kann man dieses durch einen der Spiegel ersetzen. Controlfiles sind meist nur einige 10 MB groß. Ein Zweifach- oder sogar Dreifach-Spiegel benötigt daher nicht allzuviel Speicherplatz. Zudem ist der I/O auf Controlfiles nicht sonderlich hoch. Die Speicherung gemeinsam mit Redologs und Datafiles ist daher problemlos möglich. Praxistipp Da Controlfiles alle Informationen zum physischen Aufbau der Datenbank enthalten, sind diese enorm wichtig für den Betrieb sowie im Fall einer Wiederherstellung aus einer Sicherung der Datenbank. Sichern Sie die Controlfiles nach jeder physischen Änderung der Datenbank! Zu den physischen Änderungen zählen das Hinzufügen oder Löschen von Tablespaces, Datafiles oder Redologs.

Controlfiles und Startup der Instanz Die Pfade und Namen der Controlfiles sind in der Datenbank-Parameterdatei im Parameter control_files hinterlegt. Während des Starts liest die Oracle-Instanz zunächst den Wert des Parameters aus der Parameterdatei, öffnet dann die Controlfiles und überprüft, ob diese untereinander konsistent sind. Wird eines der Controlfiles nicht gefunden oder kann nicht darauf zugegriffen werden, so gibt der Datenbankserver eine Fehlermeldung aus und bricht den Startvorgang ab. Der Startvorgang wird ebenfalls mit einer Fehlermeldung abgebrochen, wenn die Controlfiles nicht konsistent zueinander sind, der Inhalt, Zeitstempel- und Konsistenzinformationen nicht vollständig miteinander übereinstimmen. In diesem Fall kann man das fehlende oder fehlerhafte Controlfile durch eine Kopie eines validen Controlfiles ersetzen. Erstellung und Verwaltung von Controlfiles Informationen zur Erstellung und Verwaltung von Controlfiles finden Sie im Abschnitt 2.8 „Verwaltung von Controlfiles“.

2.2.8

Parameterfile

Die Parameterdatei einer Oracle-Datenbank enthält alle Initialisierungsparameter. Hier sind Informationen wie der Name der Datenbank, die Größe der Datenblöcke und der verwendete Zeichensatz hinterlegt. Auch die maximale Anzahl der Prozesse und der BenutzerSessions sowie die Konfiguration der Caches im Arbeitsspeicher der Datenbankinstanz werden über das Parameterfile konfiguriert. Parameter lassen sich in folgende funktionale Gruppen gliedern: Limits: Parameter, die Grenzwerte beispielsweise für Prozesse und Datenbankressour cen setzen

55

2 Architektur und Administration Konfiguration der Datenbankinstanz: Parameter, die Teile der Instanz wie beispiels weise die System Global Area (SGA) konfigurieren Pfade und Namen: Parameter, die Entitäten wie Dateien und Verzeichnisse beschrei ben Formate Oracle kennt zwei verschiedene Formate von Parameterfiles: PFile (Parameter File)  Das PFile wird oft auch als „init<SID>.ora“ bezeichnet. Das Format ist textbasiert. Ein PFile kann man mit einem Editor wie Notepad oder vi änderen, diese Änderungen werden jedoch erst nach einem Neustart der Datenbankinstanz aktiv. Es ist jedoch möglich, zusätzlich zur Änderung mit einem Editor im PFile dieselbe Änderung mit einem SQLBefehl durchzuführen und damit einen Neustart zu vermeiden. SPFile (Server Parameter File)  Das Format des SPFiles ist proprietär. Änderungen dürfen nur mit SQL-Befehlen vorgenommen werden. Sie sind dafür im laufenden Betrieb durchführbar. Ein Neustart der Instanz ist nicht erforderlich. Ab Oracle 9i aufwärts verwendet man meist das SPFile. Es verhält sich bei Änderungen der Parametrisierung etwas flexibler. Informationen zur Erstellung und Verwaltung von Parameterfiles sowie zur Parametrisierung von Datenbankinstanzen finden Sie in Abschnitt 2.9 „Parametrisierung“.

2.2.9

Passwordfile

Benutzer, die keine sysdba- oder sysoper-Privilegien besitzen, identifizieren sich über das Data Dictionary der Datenbank. Das Data Dictionary enthält Base Tables mit Metadaten unter anderem zu Benutzern und Passwörtern. Da das Data Dictionary im System-Tablespace gespeichert ist, muss auf diesen zugegriffen werden, um Standardbenutzer zu authentifizieren. Dies ist jedoch nur möglich, wenn die Datenbank bereits geöffnet ist. Um eine Datenbankinstanz zu starten, ist es daher erforderlich, dass sich Datenbankadministratoren bei geschlossener Datenbank über einen externen Mechanismus authentifizieren können. Hierzu bestehen grundsätzlich drei Möglichkeiten: Die Authentifizierung über das Betriebssystem, die Authentifizierung über einen Verzeichnisdienst oder die über eine Passwort-Datei28. Informationen zur Erstellung und Verwaltung von Passwortfiles finden Sie im Abschnitt 2.10 „Passwort-Dateien verwalten“.

28

56

Siehe auch Kapitel 6 „Security“.

2.2 Physische Architektur einer Oracle-Datenbank

2.2.10 Alert- und Trace-Dateien Eine der wichtigsten Informationsquellen im Fehlerfall ist die Alertlog-Datei. Sie enthält Status- und Fehlermeldungen. Beim Start einer Datenbankinstanz werden zudem alle vom Standard abweichenden Parameterwerte vermerkt. Auch Änderungen der Parametrisierung im laufenden Betrieb werden aufgezeichnet. Befehle, die mit alter system und alter database ausgeführt werden, wie das Erstellen und Löschen von Tablespaces, aber auch Informationen zu beschädigten Redologs oder Meldungen zu Problemen von Datafiles sind hier zu finden. Bis einschließlich Oracle Database 10g R2 wurde die Alertlog-Datei in jenem Verzeichnis abgelegt, das im Parameter background_dump_dest hinterlegt ist. Sie ist so zu ermitteln: SQL> SELECT name, value FROM v$parameter WHERE name ='background_dump_dest';

Oder kürzer in SQL*Plus: SQL> show parameter background_dump_dest

Ab Oracle Database 11g Release 1 finden Sie ein XML-basiertes Alertlog im Automatic Diagnostic Repository (ADR). Das ADR ist ein dateibasiertes Repository, das DiagnoseInformationen wie Trace Files, Alertlog und Health Monitor Reports speichert. Der Standard-Pfad des ADR liegt im Verzeichnis $ORACLE_BASE. Ist diese Umgebungsvariable nicht gesetzt, wird $ORACLE_HOME/log verwendet. Über den Parameter diagnostic_dest lässt sich der Pfad jedoch ändern. Folgender Befehl zeigt den Pfad: SQL> SELECT name, value FROM v$parameter WHERE name ='diagnostic_dest';

Oder kürzer in SQL*Plus: SQL> show parameter diagnostic_dest

Details stehen auch in der View v$diag_info: SELECT name, value FROM v$diag_info;

Das „alte“ textbasierte Alertlog finden Sie im Verzeichnis Diag Trace des ADR. Den Pfad ermitteln Sie wie folgt: SQL> SELECT FROM WHERE

name, value v$diag_info name = 'Diag Trace';

Weitere Informationen hierzu stehen in Abschnitt 9.1 „Alert.log“. Praxistipp: Die Datei log.xml wird automatisch ab einer Größe von 10 MB umbenannt und es wird eine neue Datei erzeugt. Für Alertlog-Dateien im alten Format gilt das nicht. Während einer Fehleranalyse ist es hinderlich, beim Öffnen des Alertlogs aufgrund von Problemen mit der Dateigröße minutenlang warten zu müssen. Die Alertlog-Datei lässt sich jederzeit löschen oder umbenennen. Beim Auftreten der nächsten Meldung wird sie automatisch

57

2 Architektur und Administration neu angelegt. Es empfiehlt sich daher, das Alertlog mittels eines Cronjobs oder über den Oracle Scheduler regelmäßig umzubenennen und zu sichern.

Trace-Dateien Bis Oracle Database 10g werden Trace-Dateien in die Verzeichnisse geschrieben, die in den Parametern background_dump_dest (Hintergrundprozesse), user_dump_dest (Benutzerprozesse und core_dump_dest (core dumps) angegeben sind. Die maximale Größe der Tracefiles lässt sich hier mit dem Parameter max_dump_file_size begrenzen. Ab Oracle Database 11g finden Sie Trace-Dateien im Automatic Diagnostic Directory (ADR). Das ADR ist ein dateibasiertes hierarchisches Verzeichnis im Betriebssystem. Den Pfad können Sie über die View v$diag_info ermitteln: SQL> SELECT name, value FROM v$diag_info;

Der Standardpfad entspricht der Umgebungsvariablen ORACLE_BASE des Betriebssystems oder – falls diese während der Installation nicht gesetzt war – dem Verzeichnis ORACLE_ HOME/log. ADR-Base: diagnostic_dest ADR

diag ProduktTypen asm

clients

crs

diagtool

lsnrctl

netcman

ofm

rdbms

tnslsnr Produkt-ID

Instanz-ID

<SID1>

alert

cdump

hm

incident

incpkg

ir

lck

<SID2>

<SID3>

metadata

stage

sweep

trace

Abbildung 2.6 Lage des Alertlogs und der Tracefiles im Automatic Diagnostic Repository (ADR)

2.2.11 Flashback Logs Oracle 10g brachte zahlreiche neue Funktionen, darunter auch Flashback Database. Flashback Database funktioniert wie ein Rückspulknopf für die Datenbank: Es setzt den Datenbestand auf einen Zeitpunkt in der Vergangenheit zurück. Dies ist zum Beispiel bei Systemtests enorm hilfreich: Nach Abschluss eines Tests kann man so die Datenbank einfach

58

2.2 Physische Architektur einer Oracle-Datenbank wieder auf ihren Ausgangszustand zurücksetzen. Ein weiterer wichtiger Anwendungsfall ist ein logischer Fehler in der Datenverarbeitung. Angenommen, ein Batch-Prozess oder ein Benutzer hat Datenänderungen in fehlerhafter Weise vorgenommen oder gar Daten gelöscht, so erlaubt ein Flashback ein relativ schnelles Zurücksetzen aller Änderungen. Dazu zwei Beispiele: SQL> flashback database to timestamp sysdate – 1/24;

oder SQL> flashback database to timestamp to_timestamp('15.12.2009 15:27:00', 'dd.mm.yyyy hh24:mi:ss');

Der erste Befehl setzt den Datenbestand um eine Stunde zurück (aktuelle Systemzeit minus 1/24). Der zweite verwendet einen festen Zeitstempel für das Zurücksetzen. Damit dies funktioniert, muss zuvor das Archivieren von Redologs sowie das Schreiben von Flashback Logs in der Datenbank aktiviert sein. Flashback Logs werden in die Fast Recovery Area geschrieben. Den Pfad finden Sie mit dem folgenden Befehl heraus: SQL> show parameter db_recovery_file_dest;

oder SQL> SELECT value FROM v$parameter WHERE name = 'db_recovery_file_dest';

Weitere Informationen zu Flashback-Funktionalitäten finden Sie in Abschnitt 13.6 „Flashback“.

2.2.12 Block-Change-Tracking-Protokoll Oracle RMAN bietet in der Enterprise Edition die Möglichkeit, inkrementelle Sicherungen einer Datenbank zu erstellen. Dabei werden, aufbauend auf einer vollständigen Sicherung, nur jene Datenblöcke gesichert, die sich seit der letzten Vollsicherung geändert haben. Gerade bei sehr großen Datenbanken ist dies ein Vorteil: Die zu sichernde Datenmenge ist wesentlich geringer. Bei traditionellen inkrementellen Backups liest RMAN jedoch alle Böcke einer zu sichernden Datafile und prüft, ob sich der Block seit dem letzten Backup geändert hat. Bei sehr großen Datenbanken kann dies einige Zeit in Anspruch nehmen. Oracle 10.1 brachte das Block-Change-Tracking-Protokoll. Es hat zum Ziel, geänderte Blöcke gezielt zu identifizieren. Ist Block-Change-Tracking aktiviert, wird jede Blockänderung in einem Protokoll verzeichnet. RMAN liest während einer inkrementellen Sicherung dieses Protokoll und greift dann dezidiert nur die geänderten Blöcke heraus. Die Sicherungszeit für inkrementelle Sicherungen lässt sich somit wesentlich reduzieren. Standardmäßig ist Block Change Tracking deaktiviert. Folgender Befehl aktiviert es: SQL> alter database enable block change tracking using file '/opt/oracle/oradata/ora11g/change_track.ctf;

Genauso einfach lässt sich Block-Change-Tracking auch wieder deaktivieren: SQL> alter database disable block change tracking;

59

2 Architektur und Administration Die binäre Datei enthält ein Bitmap, das für jeden 32-KB-Block anzeigt, ob dieser geändert wurde. Die Größe von 32 KB ist übrigens unabhängig von der tatsächlichen Blockgröße der Datenbank bzw. des Tablespaces. Je 32 KB fällt nur ein Bit zur Speicherung an. Für je 300 GB genügt daher eine Speicher-Größe von rund 10 MB für das Protokoll. Der Overhead ist also recht klein. Inkrementelle Sicherungen mit RMAN sind nur mit der Enterprise Edition möglich. Prüfen Sie unbedingt vor der Nutzung, ob Sie Block-Change-Tracking lizenziert haben.

2.3

Instanz: Arbeitsspeicher- und Prozessarchitektur Um auf die Daten einer Oracle-Datenbank zugreifen zu können, muss eine Instanz gestartet sein. Eine Instanz besteht aus Arbeitsspeicherstrukturen und Prozessen. Zu den Basisstrukturen einer Oracle-Instanz im Hauptspeicher zählen: System Global Area (SGA)  Bei der SGA handelt es sich um eine Gruppe von Shared Memory-Strukturen im Hauptspeicher, die Daten sowie Steuerinformationen einer Oracle-Instanz enthalten. Zu diesen Strukturen zählen unter anderem der Database Buffer Cache, der Datenblöcke der Datafiles puffert, und ein Shared SQL Area. Die SGA wird gemeinsam von allen Server- und Hintergrundprozessen genutzt. Program Global Area (PGA)  Eine PGA ist ein von einem Prozess exklusiv genutzter Bereich im Hauptspeicher. Sie wird beim Start eines Prozesses in einer initialen Größe allokiert und enthält Daten und Steuerinformationen eines einzelnen Prozesses. Jeder Server- und jeder Hintergrundprozess besitzt eine eigene PGA. Die Summe aller PGAs wird als total instance PGA bezeichnet. Die maximal allokierbare Speichergröße kann mit Initialisierungsparametern festgelegt werden. Software Code Areas  Die Software Code Areas speichern einen ausführbaren Code in einem geschützten Bereich abseits der Benutzerprogramme. Ihre Größe ist statisch und vom Release der Datenbanksoftware abhängig. Die einzelnen Speicherbereiche werden in den folgenden Abschnitten detailliert besprochen.

2.3.1

System Global Area (SGA)

Bei der System Global Area (SGA) handelt es sich um Arbeitsspeicherstrukturen, die zum Caching von Daten und Steuerinformationen einer Oracle-Instanz dienen. Die SGA einer Datenbankinstanz wird von allen Server- und Hintergrundprozessen gemeinsam genutzt. In Unix- und Linux-Systemen ist dieser gemeinsame Zugriff über Shared Memory realisiert. Auf Windows-Plattformen nutzt Oracle eine Thread-Architektur, die es ermöglicht, dass alle Threads gemeinsam auf diese Speicherbereiche zugreifen.

60

2.3 Instanz: Arbeitsspeicher- und Prozessarchitektur Informationen, auf die häufig zugegriffen wird, werden gecacht. Dazu zählen Kopien der Datenblöcke aus den Datafiles, die für einen schnelleren Zugriff im Cache im Hauptspeicher gehalten werden. Zusätzliche Caches halten häufig genutzte SQL-Statements sowie Meta-Informationen aus dem Data Dictionary der Datenbank. Auch der Programmcode wird in einem Cache gehalten. Er liegt im Software-Codebereich. Praxistipp 64

Viele Unix-Plattformen sind als 64-Bit-Version verfügbar. Der virtuelle Adressraum ist mit 2 Bit (16.777.216 TB) enorm groß im Vergleich zu den 32-Bit-Plattformen, die nur 4 GB adressieren können. Oracle bietet passende 64-Bit-Versionen der Datenbanksoftware an. Da heutige Hardware oftmals mit mehreren 10 GB Hauptspeicher ausrüstbar ist, kann man durch Einsatz einer 64-Bit-Version die Konfiguration einer großen SGA mit entsprechenden Performance-Steigerungen durch den Zugriff auf Caches erreichen.

Die SGA wird seit Oracle 9.0.1 in sogenannten Granules verwaltet. Wenn Sie die Größe eines Pool-Bereichs der SGA festlegen, wird stets auf ein Vielfaches der Granule-Größe gerundet. Die Größe eines Granules wird durch die Gesamtgröße der SGA determiniert. Für die meisten Plattformen gilt: Ist die Größe der SGA gleich oder kleiner 1 GB, so ist die Größe eines Granules 4 MB. Ist sie größer als 1 GB, so wird die Granule-Größe auf 16 MB gesetzt. Für einige Plattformen gelten jedoch Abhängigkeiten. Auf 32-Bit-Windows beispielsweise beträgt die Granule-Größe 8 MB für SGAs, die größer als 1 GB sind. Die View v$sgainfo gibt exakt Auskunft. Die hier angegebene Granule-Größe gilt für alle Komponenten der SGA. Das erste Granule enthält die Fixed SGA, ein Granule-Verzeichnis sowie Heap Header. Im letzten Granule befindet sich unter anderem der RedologBuffer sowie ein betriebssystemspezifischer Overhead. Die einzelnen Caches der SGA sind in den folgenden Abschnitten detailliert beschrieben. Database Buffer Cache Der Database Buffer Cache (auch Datenblock-Puffer) hält Kopien von Datenblöcken aus den Datafiles im Hauptspeicher. Benötigt ein Prozess einen Datenblock, so wird zunächst überprüft, ob dieser bereits im Cache vorhanden ist. Ist dies nicht der Fall, so liest der Prozess den Block aus dem Datafile und überträgt ihn in den Hauptspeicher. Alle weiteren Verarbeitungen wie beispielsweise Änderungen an Datenzeilen erfolgen dann zunächst im Hauptspeicher. Der Database Writer-Prozess (DBWR) schreibt geänderte Datenblöcke asynchron in die Datafiles zurück. Zudem werden Änderungen in den Redologs protokolliert. Der Database Buffer Cache wird wie der Shared Pool über einen LRU29-Algorithmus bereinigt. Ist weiterer Speicherplatz notwendig, so werden die am längsten nicht mehr benötigten Datenblöcke zurück in die Datafiles auf dem Festplattensystem geschrieben und aus dem Hauptspeicher entfernt. Der Database Buffer Cache enthält so die Daten, auf die am häufigsten zugegriffen wurde. 29

Last recently used

61

2 Architektur und Administration

Default Cache

2K

4K

Keep Cache

Recycle Cache

16K

Abbildung 2.7 Buffer Pools im Datenblock-Puffer (Database Buffer Cache)

Zusätzlich gibt es die Option, verschiedene Bereiche für die Pufferung mit unterschiedlichen Vorhaltezeiten im Hauptspeicher zu definieren. Dazu zählen folgende Caches: Keep-Cache für Objekte, die dauerhaft im Hauptspeicher vorzuhalten sind. Dieser  Bereich wird häufig für Look-up-Tabellen genutzt. Recycle-Cache für Objekte, die nach deren Nutzung umgehend wieder aus dem Arbeits speicher entfernt werden. Damit die Datenblöcke einer Tabelle oder eines Index im Keep- bzw. im Recycle-Pool gehalten werden, müssen diese mit einem entsprechenden Flag versehen sein. SQL> ALTER TABLE meine_lookup_tabelle1 STORAGE (BUFFER_POOL KEEP);

bzw. SQL> ALTER TABLE meine_tabelle2 STORAGE (BUFFER_POOL RECYCLE);

Über das Schlüsselwort default in der Storage-Klausel, kann die Zuordnung auf den Default-Pool zurückgesetzt werden. SQL> ALTER TABLE meine_tabelle2 STORAGE (BUFFER_POOL DEFAULT);

Mit dem folgenden Statement können Sie die Konfiguration überprüfen: SQL> SELECT a.buffer_pool FROM dba_tables a WHERE a.table_name = 'MEINE_LOOKUP_TABELLE1';

Beachten Sie: Die Abfrage des Tabellennamens in der Where-Klausel ist case sensitiv! Keep- und Recycle-Pools sind optional konfigurierbar. Seit Oracle 9i lassen sich diese Pools unabhängig von den anderen Caches der SGA reservieren. Die Verwendung des Default-Pools ist der Standard und benötigt keine gesonderte Konfiguration. Keep- und Recycle-Pools sollte man jedoch nur dann konfigurieren, wenn ihre Nutzung eine Performance-Verbesserung verspricht. Mit Oracle 9.0.1 wurden Caches für abweichende Blockgrößen eingeführt. Deren Verwendung ist dann erforderlich, wenn man Tablespaces mit vom Standard abweichenden Blockgrößen verwendet.

62

2.3 Instanz: Arbeitsspeicher- und Prozessarchitektur Die Größe des Default Caches wird mit db_cache_size eingestellt. Wird Automatic Memory Management eingesetzt, so wird dieser Bereich automatisch kalibriert. Gesonderte Caches wie der Keep- und der Recycle Cache sowie Buffer für Datenblöcke von Tablespaces, deren Datenblocksize von der Standardgröße der Datenbank abweicht, können mit den Parametern db_keep_cache_size und db_recycle_cache_size sowie db_k_cache_size30 dimensioniert werden. Informationen zum Sizing und zur Verwaltung der Caches finden Sie im Abschnitt 2.3.3 „Memory Management“. Redolog Buffer Änderungen an Datenblöcken werden zunächst in den Redolog Buffer geschrieben und anschließend in den Redologs protokolliert. Der Logwriter-Prozess überträgt diese Änderungen aus dem Redolog Buffer in die Redologs in folgenden Fällen: Sobald der Redolog Buffer entweder zu einem Drittel oder zu mehr als 1 MB gefüllt ist  Wenn eine Zeitspanne von drei Sekunden seit dem letzten Schreibvorgang verstrichen  ist Bei einem Log Switch  Bevor der Database Writer-Prozess schreibt (beispielsweise bei einem Checkpoint)  Nach einem Commit durch einen Benutzer  Wenn ein Benutzer eine Transaktion mit Commit bestätigt, werden alle Redo-Einträge aus dem Buffer sowie ein Commit-Satz für die Transaktion in die Redologs übertragen. Dabei wird zunächst eine System Change Number (SCN) zugeordnet, die mit dem Commit-Satz und allen Transaktions-Redos in die Redo Logs geschrieben wird. Die Bestätigung, dass ein Commit erfolgreich war, wird stets erst dann an die Benutzersession zurückgereicht, wenn dieser Schreibvorgang erfolgreich abgeschlossen ist. Redologs sind äußerst wichtig für den Fall, dass eine Datenbank-Instanz abstürzt, bevor die geänderten Datenblöcke aus dem Puffer-Cache an die Datafiles geschrieben werden konnten. Die festgeschriebene Transaktion eines Benutzers wird daher solange nicht als abgeschlossen betrachtet, bis die Redo-Informationen erfolgreich in die Redologs geschrieben wurden. Der Parameter log_buffer steuert die Größe dieses Puffers. Typisch sind Größen von etwa 8 bis 30 MB. Sofern Automatic Memory Management eingesetzt wird, hat dies keinen Einfluss auf die Größe der Redolog-Puffers. Seine Größe muss weiterhin explizit gesetzt werden.

30

steht für eine gültige Blockgröße

63

2 Architektur und Administration Shared Pool Der Shared Pool wurde bereits mit Oracle 7 eingeführt. Er umfasst zwei wichtige SubCaches: den Library Cache und den Data Dictionary Cache. Die Größe für den Shared Pool gibt der Initialisierungsparameter shared_pool_size an. Dieser Parameter ist dynamisch und lässt sich im laufenden Betrieb ändern, solange die Gesamtgröße der SGA kleiner als sga_max_size und sga_target bleibt. Wird Automatic Memory Management eingesetzt, so wird dieser Parameter automatisch kalibriert. Der Library Cache ist einer der Sub-Caches des Shared Pool. Er hält Informationen rund um SQL- und PL/SQL-Anweisungen, die in der Datenbankinstanz laufen. Da der Library Cache von allen Benutzern gemeinsam genutzt wird, können viele Datenbankbenutzer mit den gleichen SQL-Anweisungen arbeiten, ohne zusätzlichen Overhead zu verursachen. Neben den SQL-Anweisungen sind im Library Cache auch der Parse Tree und der Ausführungsplan einer SQL-Anweisung hinterlegt. Wird eine identische SQL-Anweisung ein zweites Mal ausgeführt − entweder vom gleichen oder einem anderen Benutzer − sind der Ausführungsplan und der Parse Tree bereits berechnet. Dies minimiert die Ausführungszeit von Abfragen und DML-Anweisungen wesentlich, da unnötige Neuberechnungen entfallen. Ist der Library Cache zu klein dimensioniert, werden die Ausführungspläne und Parse Trees häufiger aus dem Cache entfernt, um Platz für neue zu schaffen. Dies hat zur Folge, dass bei wiederholten SQL-Anweisungen deren Information häufig nicht mehr im Library Cache vorliegt und erneut der parse tree und der Ausführungsplan zu berechnen sind. Ein wichtiger Punkt für die effiziente Nutzung des Library Cache ist die Verwendung von Bind-Variablen. Oracle nutzt nämlich einen einfachen Hash-Algorithmus für die Überprüfung, ob ein SQL-Statement bereits geparst und mit Ausführungsplan im Cache vorgehalten wird. Die Hash-Werte für Statements, die beispielsweise in der Where-Klausel voneinander abweichen, sind jedoch unterschiedlich. Ein regelmäßiges Re-Parsing ist die Folge. Dazu ein Beispiel: SQL> SELECT * FROM aheld.kunden WHERE id = 637; SQL> SELECT * FROM aheld.kunden WHERE id = 25; SQL> SELECT * FROM aheld.kunden WHERE id = 938;

Eine Überprüfung der im Cache gehaltenen Statement-Varianten zeigt die verschiedenen Hash-Werte: SQL> SELECT hash_value, sql_text FROM v$sqlarea WHERE upper(sql_text) like ('SELECT * FROM AHELD.KUNDEN WHERE%'); HASH_VALUE ---------3165551335 2302642270 2959326624

SQL_TEXT ------------------------------------------------SELECT * FROM aheld.kunden WHERE id = 637 SELECT * FROM aheld.kunden WHERE id = 25 SELECT * FROM aheld.kunden WHERE id = 938

Die Verwendung von Bind-Variablen sorgt dafür, dass ein Platzhalter anstelle der fest codierten Werte in der Where-Klausel eingesetzt wird. Unnötiges Re-Parsing wird damit vermieden. Genauere Informationen zur Verwendung von Bind-Variablen finden Sie in Kapitel 8 „Optimierung“.

64

2.3 Instanz: Arbeitsspeicher- und Prozessarchitektur Teile des Data Dictionary31 werden in einem weiteren Sub-Cache gehalten. Der Data Dictionary Cache hält ein Subset von Spalten aus den Data Dictionary-Tabellen vor. Datenblöcke aus Tabellen im Data Dictionary werden kontinuierlich zur Unterstützung beim Verarbeiten von Benutzerabfragen und anderen DML-Befehlen benötigt. Ist der Data Dictionary Cache zu klein, verursachen Anforderungen von Data-Dictionary-Informationen zusätzliche Lesezugriffe. Diese I/O-gebundenen Data-Dictionary-Anforderungen sind möglichst zu vermeiden, um unnötigen Overhead während der internen Verarbeitung von Anfragen zu minimieren. Daher sollte der Data Dictionary Cache ausreichend groß dimensioniert werden. Large Pool Der Large Pool ist seit Oracle 8.0 verfügbar. Dabei handelt es sich um einen optionalen Bereich der SGA, der Platz für Shared Server-Prozesse sowie Nachrichten-Puffer für Prozesse, die parallele Abfragen verarbeiten, und für Backup- und Recovery-Operationen mit RMAN bereitstellt. Der Initialisierungsparameter large_pool_size steuert die Größe des Large Pools. Dieser Parameter ist seit Oracle 9i Release 2 dynamisch; sein Wert kann also zur Laufzeit der Datenbankinstanz geändert werden. Wird Automatic Memory Management eingesetzt, wird die Größe des Large Pools automatisch kalibriert. Java Pool Die Oracle JVM32 nutzt den mit Oracle 8.1.5 eingeführten Java Pool für den Java-Code in der Datenbank. Die Speicherung des Java-Codes im Java Pool wird entsprechend der von SQL- und PL/SQL-Code im Shared Pool gehandhabt. Der Parameter zur Größenbestimmung ist java_pool_size. Bei Automatic Memory Management wird die Größe des Java Pools automatisch kalibriert. Streams Pool Der Streams Pool wurde mit Oracle 10g R1 eingeführt. Er enthält Steuerstrukturen und Daten zu Oracle Streams, einer Option der Enterprise Edition, die die gemeinsame Nutzung von Daten und Events in einer verteilten Umgebung unterstützt. Die Steuerung seiner Größe erfolgt über den Parameter streams_pool_size. In Oracle 10g R1 ist dieser Parameter noch nicht dynamisch. Erst ab Version 10g R2 lässt er sich zur Laufzeit ändern. Ist der Wert dieses Parameters auf 0 gesetzt, so wird der notwendige Hauptspeicher für Streams-Operationen aus dem Shared Pool reserviert. Seine Größe kann dann bis zu 10

31

Dabei handelt es sich um eine Sammlung aus internen Datenbanktabellen, die in den Schemata der Benutzer SYS und SYSTEM abgelegt sind. Diese internen Tabellen enthalten die Meta-Daten der Datenbank. Dazu zählen Informationen zu Datafiles und Tablespaces, Datenbankobjekten sowie Berechtigungen und Rollen der Datenbankbenutzer. 32 Java Virtual Machine

65

2 Architektur und Administration Prozent des Shared Pools ausmachen. Wird Automatic Memory Management eingesetzt, wird die Größe des Streams Pool automatisch kalibriert. Fixe SGA und Software Code Areas Die fixe SGA dient internen Strukturen. So speichert sie Informationen zur Interprozesskommunikation und für Hintergrundprozesse. Die Größe der fixen SGA ist releaseabhängig und lässt sich nicht manuell ändern. Auch die Größe der Software Code Areas ist statisch. Sie ändert sich nur, wenn Software aktualisiert oder neu installiert wird. Die erforderliche Größe ist zudem betriebssystemabhängig.

2.3.2

Program Global Area (PGA)

Neben der gemeinsam genutzten SGA gibt es die Program Global Areas (PGAs). Auch die PGA wird im Arbeitsspeicher gehalten. Dabei handelt es sich um einen Speicherbereich, der exklusiv von einem Serverprozess genutzt wird33: Jeder einzelne Serverprozess34 besitzt eine eigene PGA und auch Hintergrundprozesse nutzen eine eigene PGA. Die Gesamtgröße aller PGAs heißt „Instanz-PGA“. Eine PGA unterteilt sich in weitere Bereiche: Die Private SQL Area enthält session-spezifische Informationen, die zur Verarbeitung  von Statements erforderlich sind. Dazu zählen Werte von Bind-Variablen oder auch der Status der Anfrageausführung. SQL Work Areas werden für memory-intensive Operationen wie beispielsweise Sor tierungen, Hash Joins und Bitmap Merges genutzt. PGA Sort Area

Hash Area

Session Memory

Bitmap Merge Area

Persistent Area

SQL Work Areas Private SQL Area

Runtime Area

Abbildung 2.8 Aufbau der PGA

Verwendung der PGA Die Verwendung der PGA hängt von der Verbindungskonfiguration der Oracle-Datenbank ab: Standard ist die Verwendung dedizierter Serverprozesse. In dieser Konfiguration erhält  jeder Benutzer einen eigenen Serverprozess, der seine eigenen Sitzungsinformationen in einer exklusiv genutzten PGA hält. Die PGA umfasst unter anderem einen Sortierbe-

33 34

66

Gelegentlich spricht man daher auch von der Private Global Area Mit Ausnahme von Shared Server-Konfigurationen

2.3 Instanz: Arbeitsspeicher- und Prozessarchitektur reich. Dieser wird eingesetzt, sobald ein SQL-Statement Sortierungen, Bitmap-Mergeoder Hash-Join-Operationen benötigt. Bei einer Shared-Server-Konfiguration nutzen mehrere Benutzer einen gemeinsamen  Serverprozess. Diese Konfigurationsoption ist dann von Vorteil, wenn zahlreiche konkurrierende Verbindungen bestehen, die nur sporadisch relativ wenig ressourcenverbrauchende Abfragen an den Datenbankserver senden. Bei solchen Shared-ServerKonfiguration werden die Sitzungsinformation in der SGA − speziell im Large Pool − gespeichert. Ab Oracle 9i kann man den Parameter pga_aggregate_target für die Größendefinition verwenden. Er legt fest, wie groß der belegte Speicher aller PGAs in der Summe sein darf. Der Parameter workarea_size_policy muss zusätzlich auf den Wert AUTO gesetzt werden. Die Verteilung des Arbeitsspeichers zwischen den Benutzerprozessen erfolgt dann automatisch. Ab Oracle 11g R1 kann man auch den Parameter memory_target setzen. Er sorgt für eine automatische Verwaltung des Arbeitsspeichers − sowohl der SGA als auch der PGA − und soll beide Speicherbereiche als Ganzes optimieren. User Global Area (UGA) Die User Global Area (UGA) speichert Session-Variablen. Dazu zählen Logon-Informationen und der Status der Session. Sofern eine Session PL/SQL-Packages nutzt, speichert die UGA den Package-Status. Zusätzlich kann sie den OLAP-Pool enthalten. Die Informationen der UGA müssen für die gesamte Zeit einer Session gehalten werden. In einer Dedicated Server-Verbindung sind die Informationen der UGA Bestandteil der PGA. In Shared Server-Konfigurationen werden die Informationen der UGA jedoch im Shared Pool der SGA abgelegt (siehe auch in Abschnitt 7.2.2.3 „Shared/Dedicated Server“).

2.3.3

Memory Management

Folgende Methoden des Memory Managements stehen zur Verfügung: Automatic Memory Management (AMM) ab Version 11g  Automatic Shared Memory Management (ASMM) ab Version 10g  Manuelles Memory Management gültig für alle Versionen  Diese Memory-Management-Methoden sind im Folgenden genauer erläutert. Automatic Memory Management (AMM) Ab Oracle 11g kann man das Memory Management komplett automatisieren. Dazu wird die Gesamtgröße des für die Oracle-Instanz zu nutzenden Hauptspeichers angegeben. Dieses als Automatic Memory Management (AMM) bezeichnete Feature erlaubt einen dynamischen Austausch der einzelnen Speicherbereiche und zwar sowohl aller Caches und Puffer-

67

2 Architektur und Administration bereiche der SGA als auch der exklusiv genutzten PGAs der Benutzerprozesse. So kann die Instanz im laufenden Betrieb beispielsweise bei einer Reduktion der Gesamtgröße der PGAs den deallokierten Speicher der SGA zuweisen und anschließend den für diese Pufferbereiche genutzten Speicher vergrößern. Für die Aktivierung wird der Initialisierungsparameter memory_target gesetzt, die maximale Obergrenze mit memory_max_target. Die Oracle-Instanz regelt dann mittels interner Algorithmen die Größenzuordnung der einzelnen Pools innerhalb der SGA sowie die Verteilung zwischen SGA und PGA. Für die automatische Größenänderung ist der Prozess MMON verantwortlich. Sofern für die Verwaltung der Datenbank ein SPFile verwendet wird, speichert die Oracle-Instanz die Größen der SGA-Komponenten in den verdeckten Parametern __db_cache_size, __shared_pool_size und __large_pool_size. Bei einem Restart nutzt das System daher automatisch die Informationen des alten Lastprofils. Dies gilt auch bei einem Restart nach einem Instanz-Crash. Parameter wie db_cache_size, shared_pool_size, java_pool_size, large_pool_size und streams_pool_size können auf 0 gesetzt werden. Falls Sie für einen oder mehrere dieser Parameter Werte vorgeben, die größer 0 sind, so werden diese beim Einsatz von AMM als Untergrenze des jeweiligen Puffers gewertet. AMM verwaltet einige Pools nicht, diese sind weiterhin explizit zu dimensionieren. Dazu zählen der Redolog- und Datenblock-Puffer, die vom Standard abweichende Datenblockgrößen verwalten sowie der Keep-Pool und der Recycle-Pool. Automatic Shared Memory Management (ASMM) Bereits ab Oracle 10g kann man auch Automatic Shared Memory Management (ASMM) einsetzen. ASMM ist nicht ganz so flexibel wie AMM: Hier werden nur die Speicherverteilungen innerhalb der SGA reguliert. Die Instanz-PGA wird hier nicht berücksichtigt und ist getrennt zu konfigurieren. Zum Aktivieren der automatischen SGA-Verwaltung setzen Sie den Initialisierungsparameter sga_target auf einen Wert größer 0. Er gibt die Gesamtgröße aller Caches innerhalb der SGA an. Alle anderen Cache-Parameter (db_cache_size, shared_pool_size, java_pool_size, large_pool_size und streams_pool_size) können auf 0 gesetzt werden. Falls Sie für einen oder mehrere dieser Parameter Werte vorgeben, die größer 0 sind, so werden diese beim Einsatz von ASMM als Untergrenze des jeweiligen Puffers gewertet. Sowohl AMM als auch ASMM verwalten einige Sub-Caches nicht automatisch. Sie müssen weiterhin explizit dimensioniert werden. Dazu zählen der Redolog-Puffer, der Keepund der Recycle-Pool sowie der Datenblock-Puffer, die Caches für vom Standard abweichende Datenblockgrößen bereitstellen. Der Speicher dieser Pools wird von der Gesamtmenge des in sga_target angegebenen Speichers abgezogen. ASMM aktiviert man durch Belegen der Parameter sga_max_size und sga_target. Der Parameter sga_max_size bestimmt die maximale Größe der SGA und ist statisch. Der Parameter sga_target lässt sich im laufenden Betrieb ohne Neustart ändern. Der maximale Grenzwert von sga_max_size darf dabei jedoch nicht überschritten werden.

68

2.3 Instanz: Arbeitsspeicher- und Prozessarchitektur Manuelles Memory Management Wer die Kontrolle über das Memory Management nicht aus der Hand geben möchte, kann das automatische Speichermanagement deaktivieren. In diesem Fall setzt man die Parameter memory_max_target, memory_target, sga_max_size und sga_target auf 0 und belegt die einzelnen Pufferbereiche mit explizit genannten festen Größen. Setzen der Größe Datenblockpuffers: SQL> alter system set db_cache_size = 500 M scope = spfile;

Setzen der Größe des Redo Log Buffers: SQL> alter system set log_buffer = 8 M scope = spfile;

Setzen der Größe des Shared Pool: SQL> alter system set shared_pool_size = 500 M scope = spfile;

Setzen der Instanz-PGA: SQL> alter system set workarea_size_policy = AUTO scope = spfile; SQL> alter system set pga_aggregate_target = 100 M scope = spfile;

Deaktvieren des Automatic Memory Managements: SQL> alter system set memory_target = 0 scope = spfile;

Deaktvieren des Automatic Shared Memory Management: SQL> alter system set sga_target = 0 scope = spfile;

Die folgende Tabelle zeigt eine Übersicht zur Dimensionierung der SGA. Tabelle 2.3 Parameter für die manuelle Dimensionierung von SGA und PGA Parameter

Beschreibung

DB_CACHE_SIZE

Größe des Puffers für Standard-Blockgrößen

DB_K_CACHE_SIZE

Größe des Puffers für abweichende Blockgrößen mit Element in {2, 4, 8, 16, 32}

DB_KEEP_CACHE_SIZE

Puffer für die dauerhafte Haltung von Datenobjekten

DB_RECYCLE_CACHE_SIZE

Puffer für Objekte, deren Informationen sofort nach Nutzung wieder aus dem Hauptspeicher entfernt werden sollen

SHARED_POOL_SIZE

Größe des Shared Pools

LARGE_POOL_SIZE

Größe des Large Pools

JAVA_POOL_SIZE

Größe des Java Pools

STREAMS_POOL_SIZE

Größe des Streams Pools

LOG_BUFFER

Größe des Redolog-Puffers

PGA_AGGREGATE_TARGET

Größe der Instanz-PGA

WORKAREA_SIZE_POLICY

PGA-Verwaltung mittels PGA-Aggregierung

69

2 Architektur und Administration Hybrid-Konfiguration Die in Tabelle 2.3 angegebenen Parameter können auch in Kombination mit ASMM oder AMM gesetzt werden. Sie legen dann Mindestgrößen für die jeweiligen Cache-Bereiche fest.

2.3.4

Prozesse

Eine Datenbank-Instanz arbeitet mit folgenden Prozesstypen: Background-Prozesse, die mit der Datenbank-Instanz starten  Client-Prozesse einer Applikation oder eines Oracle-Werkzeugs  Server-Prozesse, die Anfragen eines Clients an das Datenbank-Managementsystem ver arbeiten Die Prozess-Strukturen einer Oracle-Instanz variieren, abhänging vom Betriebsystem und aktivierten Datenbankoptionen. Die maximale Gesamtzahl aller Prozesse lässt sich mit dem Initialisierungsparameter processes festlegen. Er bestimmt die Anzahl aller Prozesse inklusive aller Benutzer- und Hintergrundprozesse. Hintergrundprozesse stellen die Verbindung zwischen der Datenbank und den Hauptspeicherstrukturen der Instanz her: Sie lesen und schreiben Datenblöcke, schreiben Redo-Informationen und sorgen für Checkpoints der Datenbank. Die SGA und die Hintergrundprozesse bilden zusammen eine Oracle-Instanz. Der Zugriff auf den gemeinsamen Speicherbereich wird über Shared Memory realisiert. Für die Interprozess-Kommunikation nutzt Oracle Semaphoren. Beim Start einer Oracle-Instanz werden zwingend folgende Prozesse gestartet: System Monitor (SMON)  Prozess-Monitor (PMON)  Database Writer-Prozesse (DBW)  Log Writer (LGWR)  Checkpoint-Prozess (CKPT)  Manageability Monitor-Prozess (MMON and MMNL)  Recoverer-Prozess (RECO)  Je nach Konfiguration können zusätzlich weitere Prozesse Bestandteil einer Instanz sein. Beispiele sind: Flashback Data Archiver Process (FBDA)  Space Management Coordinator Process (SMCO)  Slave-Prozesse  I/O-Slave-Prozesse (I)  Parallel Query Slaves 

70

2.3 Instanz: Arbeitsspeicher- und Prozessarchitektur Auf den folgenden Seiten sind die Interaktion zwischen Prozessen, Arbeitspeicherstrukturen und Datenbank genau beschrieben. Database Writer (DBW) Der Database Writer (DBWR) ist dafür verantwortlich, geänderte Datenblöcke aus dem Datenblockpuffer in die Datenbankdateien zu schreiben. Eine Dirty Block List gibt an, welche Blöcke „dreckig“ sind. Darunter sind Blöcke zu verstehen, die im Cache geändert und noch nicht in die Datenbankdateien übertragen wurden, sodass der Block im Cache sich von jenem in der Datei unterscheidet. Das Schreiben geänderter Blöcke wird durch folgende Ereignisse ausgelöst: Freier Datenblockpuffer wird benötigt: Benötigt ein Prozess freien Speicher im Data base Buffer Cache, um Datenblöcke aus Datendateien im Cache verarbeiten zu können, so wird der Prozess DBWR veranlasst, modifizierte Datenblöcke in die Datendateien zu schreiben und den Speicher freizugeben. Kein freier Platz in der LRU-Liste: Überschreitet die Anzahl der modifizierten Daten blöcke eine Grenze, so beginnt DBWR ebenfalls zu schreiben. Ein Checkpoint ist erreicht: Auch bei einem Checkpoint schreibt DBWR die Ände rungen in die Datendateien. Timeout des Database Writer: Löst keines der vorgenannten Ereignisse einen Schreib vorgang aus, so schreibt der DBWR nach einem Timeout von drei Sekunden. Gemäß der LRU-Liste werden jene Blöcke zunächst in die Datendateien geschrieben, die den längsten Zeitraum nicht mehr genutzt wurden. Um Schreibvorgänge zu optimieren, kann man bis zu 20 Database Writer-Prozesse konfigurieren. Der Parameter db_writer_processes nimmt die Anzahl an DBWR-Prozessen entgegen. Deren Namen lautet dann in der Prozessliste DBW0 bis DBW9 sowie DBWA bis DBWj. Die Verwendung mehrerer Database Writer ist vor allem bei hohen Transaktionsraten sowie bei großen Database Buffer Caches35 sinnvoll. Empfehlenswert ist die Konfiguration von mindestens einem DBWR je acht CPUs oder je Multiple Processor Group. Zusätzlich gibt es die Möglichkeit, IO-Slaves zu konfigurieren. Sie sind nützlich, wenn mehrere DBWR nicht sinnvoll einsetzbar sind (bspw. weil das System mit nur einer CPU ausgestattet ist) oder bei Systemen, für die kein asynchronous IO auf Betriebssystemlevel verfügbar ist. Die Anzahl an IO-Slaves wird über den Parameter dbwr_io_slaves gesteuert. Der DBWR ist dann der einzige Prozess, der die LRU-Liste liest, das Schreiben auf Festspeicher wird dann jedoch über die IO-Slaves in Form von nonblocking, asynchronous requests ausgeführt. Asynchronous IO auf Betriebssysteme-Ebene ist jedoch in jedem Fall vorzuziehen.

35

Hier reicht gelegentlich ein DBWR nicht aus, sodass in den Statistiken häufig Waits wie bspw. der free buffer wait auftreten.

71

2 Architektur und Administration Log Writer (LGWR) Der Log Writer (LGWR) schreibt Redolog-Einträge aus dem Redolog-Puffer in die Redologs. Der Schreibvorgang wird bei jedem der folgenden Ereignisse aktiviert: Bei einer Commit-Anweisung durch einen Benutzerprozess  Alle drei Sekunden  Bei einem Füllgrad des Redolog Buffer von mehr als einem MB  Wenn der Redolog Buffer zu einem Drittel gefüllt ist  Bevor ein Database-Writer-Prozess schreibt  Weitere Informationen dazu stehen auch in den Abschnitten 2.2.6 und 2.3.1. Archiver (ARC) Ist der Archive Log Mode aktiviert, so kopiert der Archiver-Prozess (ARC) die Redologs vor dem Überschreiben in ein oder mehrere Zielverzeichnisse, Geräte oder Netzwerkstandorte. Die Archivierung erfolgt, sobald ein Redolog bzw. eine Redolog-Gruppe gefüllt ist und ein Log Switch zur nächsten erfolgt. Optimal ist, wenn der Archivierungsprozess den Kopiervorgang abschließen kann, bevor der nächste Log Switch erfolgt. Bis zu zehn Archiver-Prozesse können aktiv sein. Deren Namen lauten dann ARC0 bis ARC9. Der Logwriter startet zusätzliche Archiver-Prozesse nach, sofern die vorhandenen nicht ausreichen. Der Parameter log_archive_max_processes gibt die Anzahl maximal zu startender Prozesse an. Er kann dynamisch geändert werden. System Monitor (SMON) Der Hintergrundprozess System Monitor (SMON) ist für die Konsistenz der Datenbank verantwortlich. Ist eine Datenbankinstanz gecrasht, so prüft der SMON bei einem Neustart die Header aller Datafiles und gleicht diese untereinander sowie mit den Konsistenzinformationen der Controlfiles ab. Gibt es hier Abweichungen beispielsweise der System Change Number (SCN), so führt der SMON anschließend ein Crash Recovery aus, um die Datenbank wieder in einen konsistenten Zustand zu bringen. Dazu liest er in einer ersten Phase, die als roll forward bezeichnet wird, die Einträge aus den Online Redologs und überträgt die Änderungen, die vor dem Crash noch nicht in Datenblöcke der Datafiles geschrieben wurden, in die Datafiles. Bisherige Transaktionen werden also nachvollzogen. Anschließend werden in einer zweiten Phase, die als roll back bezeichnet wird, alle Transaktionen zurück gerollt, die zum Zeitpunkt des Crashes noch nicht mit einem Commit bestätigt waren. Abschließend ist die Datenbank wieder in einem konsistenten Zustand. Der Prozess SMON ist zudem für das Löschen temporärer Segmente verantwortlich. Wieterhin sorgt der SMON dafür, dass freie Extents in Dictionary-verwalteten Tablespaces zusammengeführt werden.

72

2.3 Instanz: Arbeitsspeicher- und Prozessarchitektur Prozess Monitor (PMON) Der Prozess-Monitor (PMON) bereinigt bei Fehlschlagen einer Benutzersitzung bzw. eines Benutzerprozesses (beispielsweise bei einem System-Crash des Clients) die allokierten Ressourcen. Dazu zählen Sperren sowie weitere Ressourcen, die von der Benutzersitzung verwendet wurden. PMON führt dann folgende Bereinigungsarbeiten aus: Ein Rollback der Transaktion, die zum Zeitpunkt des Ausfalls offen war.  Sperren auf die betroffenen Zeilen in der Tabelle werden entfernt.  Die Prozess-ID des unterbrochenen Prozesses wird aus der Liste der aktiven Prozesse  gelöscht. PMON stellt zudem Informationen über den Status der Instanz für neue Verbindungen  über den Listener zur Verfügung. Checkpoint (CKPT) Der Checkpoint-Prozess (CKPT) hat die Aufgabe, die Zeit für ein Crash-Recovery zu reduzieren. Er sorgt dafür, dass Database-Writer-Prozesse alle geänderten Datenblöcke in die Datafiles auf Festplatte schreiben. Abschließend schreibt der Checkpoint-Prozess Konsistenzinformationen wie die letzte System Change Number in die Header aller Datafiles sowie in die Kontrolldateien. Ein Checkpoint wird in folgenden Situationen ausgeführt: Ein Online Redolog ist vollgeschrieben und ein Log Switch auf das nächste Redolog  findet statt Der im Parameter log_checkpoint_interval hinterlegte Wert an geänderten Daten blöcken wird überschritten Die Zeit seit dem letzten Checkpoint in Sekunden, der im Parameter  point_timeout hinterlegt ist, ist abgelaufen

log_check-

Der Parameter fast_start_mttr_target hat ebenfalls Einfluss auf Checkpoints. Genauere Informationen stehen in Abschnitt 2.4.7 „Checkpoint“. Recoverer (RECO) Der Recoverer-Prozess (RECO) löst Fehler auf, die im Umfeld verteilter Transaktionen entstehen. Unter verteilten Transaktionen versteht man solche, die sich auf mehrere Datenbanken beziehen. Der Recoverer verbindet sich im Falle des Scheiterns einer verteilten Transaktion zu den beteiligten Datenbanken und gibt etwaige Sperren frei. Job Queue-Prozesse (QJQ und J) Job Queue-Prozesse sind für die Ausführung von Datenbankjobs verantwortlich. Die JobKoordinationsprozesse (QJQ) werden abhängig vom Oracle Scheduler gestartet (siehe auch Kapitel 10 „Jobsteuerung“). Diese starten wiederum dynamisch weitere Job Queue Slave-Prozesse (J
73

2 Architektur und Administration Flashback Data Archiver Process (FBDA) Der Flashback Data Archiver Prozess (FBDA) ist dafür verantwortlich, zu archivierende historische Daten in die Flashback Data Archive zu übertragen (siehe auch Kapitel 15 „Große Datenbanken“). Der Prozess speichert ein Pre-Image geänderter Datenzeilen von Tabellen, für die die Archivierung historischer Daten aktiviert wurde. Zudem verwaltet er den Speicherplatz der Archive sowie die Aufbewahrungszeiten der Daten. Manageability Monitor Process (MMON) Der Manageability Monitor Process (MMON) bewerkstelligt Aufgaben rund um das Automatic Workload Repository (AWR). So schreibt er etwa Informationen wie die Überschreitung einer Metrik, nimmt Performance-Schnappschüsse der Datenbank auf und verwaltet statistische Daten. Manageability Monitor Lite Process (MMNL) Der Manageability Monitor Lite Process (MMNL) schreibt statistische Daten aus der Active Session History (ASH) aus dem Puffer der SGA auf Platte.

2.4

Konsistenz der Datenbank 2.4.1

Transaktionsmanagement

Moderne Datenbankmanagement-Systeme arbeiten transaktionsorientiert. Eine Transaktion besteht aus einer Folge von SQL-Befehlen, die den Inhalt einer Datenbank ändern und die in einer Transaktionsklammer zusammengefasst werden: Entweder werden alle in einer Transaktion zusammengefassten SQL-Befehle gemeinsam bestätigt oder gemeinsam verworfen. Die Bestätigung erfolgt mit dem Befehl commit, das Verwerfen mit einem rollback. Für Oracle-Datenbanken gelten einige Besonderheiten. So startet eine Transaktion implizit in folgenden Fällen: Nach dem Öffnen einer Session  Nach dem Beenden der letzten Transaktion durch commit oder rollback  Nach jedem DDL-Befehl  Eine Transaktion wird durch folgende Aktionen beendet: Den Befehl commit  Den Befehl rollback ohne savepoint-Klausel  Jeden DDL-Befehl36 wie create, alter oder drop  36

74

Diese enthalten ein implizites commit. Sie beenden damit die vorhergehende Transaktion mit einer Bestätigung

2.4 Konsistenz der Datenbank Das gezielte Beenden der Client-Session durch einen Benutzer37  Den Abbruch einer Client-Session38  Nach dem Beenden einer Transaktion startet mit dem folgenden SQL-Statement automatisch die nächste.

2.4.2

Lesekonsistenz

Oracle-Datenbanken nutzen ein Multiversion-Konsistenzmodell zur Sicherung der Lesekonsistenz. Dazu greift der Oracle-Server gegebenenfalls auf before images der Datenblöcke im Undo Tablespace zurück. Zur Veranschaulichung ein Beispiel: Angenommen, eine Abfrage muss zur Verarbeitung auf 800 Datenblöcke einer Tabelle zugreifen. Die Abfrage verarbeitet die ersten 100 Blöcke, während eine zweite Benutzersession mit einem Update-Statement den Datenblock 225 ändert. Erreicht nun die erste Session den Block 225, so findet diese Informationen im Block-Header über die Änderung des Blockes seit dem Start der Abfrage vor. Ein Zeiger im Block-Header weist auf einen Undo-Block in einem Undo-Segment, in dem das before image − also die Satzversion vor der Änderung − gespeichert ist. Dort wird die zum Startzeitpunkt der Abfrage konsistente Satzversion entnommen. Oracle verhindert so das Zustandekommen von „dirty reads“ und Schreib-/Lesekonflikten.

2.4.3

Undo Management

Vor jeder Änderung eines Datensatzes sichert Oracle die aktuelle Satzversion inklusive Metainformationen wie der aktuellen System Change Number. Diese Sicherung wird als before image bezeichnet. Before images in Undo-Segmenten werden in folgenden Fällen genutzt: Lesekonsistenz gewährleisten  Transaktionen nach einem Rollback-Befehl zurückrollen  Mit Flashback Query den Datenbestand zu einem Zeitpunkt in der Vergangenheit  analysieren Logische Korruptionen mit Flashback Features beheben  Bei einem Recovery der Datenbank die noch nicht mit Commit bestätigten Transaktio nen zurückrollen Before images werden in Rollback- bzw. Undo-Segmenten verwaltet. Beim Zurückrollen einer Transaktion werden diese zurück in den Datenblock kopiert. Before images dienen außerdem der Sicherung konsistenter Lesezugriffe: Führt eine Benutzer-Session eine (mög-

37

Ob mit dem Beenden einer Anwendung eine Transaktion bestätigt oder zurückgerollt wird, ist anwendungsspezifisch 38 In diesem Fall wird die Transaktion stets zurückgerollt

75

2 Architektur und Administration licherweise lang laufende) Abfrage aus, so werden die Daten stets konsistent zum Startzeitpunkt der Abfrage angezeigt. Dies gilt auch dann, wenn andere Sessions die der Abfrage zugrunde liegenden Daten ändern. Der Oracle Server ermittelt anhand der System Change Number der Abfrage die zum Startzeitpunkt gültigen Satzversionen und holt diese gegebenenfalls aus den before images der Rollbacksegmente. Oracles Automatic Undo Management (AUM) sorgt für die automatische Verwaltung und Optimierung der Rollbacksegmente. Weitere Informationen dazu finden Sie in Abschnitt 2.6.13 „Verwaltung von Undo Tablespaces“.

2.4.4

Sperren

Oracle nutzt Sperren stets mit sehr feiner Granularität, um ein hohes Maß konkurrierender Zugriffe und Änderungen zu ermöglichen. So wird bei DML-Statements nur auf SatzEbene, nicht jedoch auf Tabellen-Ebene gesperrt. Wenn möglich, nutzt Oracle Shared Locks, die eine gemeinsame Nutzung von Ressourcen ermöglichen. So behindert ein lesender Zugriff auch auf eine sehr große Tabelle keinen anderen lesenden oder schreibenden Zugriff. Ein schreibender Zugriff behindert seinerseits keine lesenden Zugriffe. Nur ein schreibender Zugriff zweier Sessions auf dieselbe Datenzeile führt zu einer Blockade der zweiten Session, die jedoch sofort nach Transaktionsabschluss der ersten Session wieder aufgehoben ist. Zusammenfassend gilt: Eine Datenzeile wird nur dann exklusiv gesperrt, wenn sie geändert wird.  Ein lesender Prozess blockiert weder lesende noch schreibende Prozesse.  Ein schreibender Prozess blockiert niemals lesende Prozesse.  Ein schreibender Prozess blockiert einen zweiten nur dann, wenn dieser exakt dieselbe  Datenzeile zu ändern versucht. Einige andere Datenbanksysteme nutzen Lock Escalation: Werden viele Datenzeilen einer Tabelle in Zugriff genommen, so wird der Sperrmechanismus eskaliert und unter Umständen die gesamte Tabelle für konkurrierende Zugriffe gesperrt. Oracle nutzt niemals Lock Escalation. Stattdessen setzt Oracle ein sehr fein granulares Sperrmanagement ein, das ein hohes Maß an Konkurrenz zulässt. Deadlocks Auch in Oracle-Datenbanken können Deadlock-Situationen auftreten. Deadlocks sind in der Regel im Anwendungsdesign, gelegentlich auch im Datenbankdesign begründet. Ein Deadlock tritt auf, wenn eine Session (A) eine Ressource exklusiv benötigt, die durch eine andere Session (B) bereits exklusiv belegt ist, während Session (B) eine Ressource exklusiv benötigt, die Session (A) bereits exklusiv belegt. Es können auch mehr als nur zwei Sessions in ein solches Szenario involviert sein; das Prinzip ist jedoch dasselbe.

76

2.4 Konsistenz der Datenbank Oracle-Datenbanken lösen Deadlocks automatisch auf, indem eines der Statements, das in einen Deadlock involviert ist, zurück gerollt wird. Danach werden entsprechende Sperren aufgehoben. Treten Deadlocks häufiger auf, sollte unbedingt die Ursache identifiziert und behoben werden. Deadlocks treten in folgenden Fällen häufig auf: Wenn Foreign Key-Spalten nicht indiziert sind  Bei zu kleinem Transaktionsheader einer Tabelle oder eines Index39  Bei Updates auf Spalten, die mit Bitmap-Indizes indiziert wurden  Sofern bei Updates mehrere Zeilen geändert werden, für diese Änderung jedoch keine  strikte Reihenfolge vorgegeben ist Oracle-Datenbanken schreiben bei einem Deadlock ein Trace-File in das User Dump Destination40. Diesem Trace File können Sie genauere Informationen entnehmen.

2.4.5

Isolation Level

Ändert eine Benutzer-Session Datensätze, während eine zweite diese liest, so stellt Oracle eine konsistente Sicht der Daten über die before images im Undo Tablespace bereit. „Dirty Reads“, wie sie in anderen Datenbanksystemen vorkommen, sind somit in Oracle-Datenbanken ausgeschlossen. Oracle kennt folgende Isolation Level: Read Commited  Serializable  Read Only  Read Commited ist die Standardeinstellung. Eine Abfrage zeigt den Datenbestand konsistent zum Start der Ausführung derselben an. Eine inkonsistente Sicht der Daten, die Änderungen während des Abfragevorgangs einschließt, wird unterbunden. Der Isolation Level Serializable zeigt den Datenbestand zum Start der Transaktion (nicht der Abfrage) sowie eigene Datenänderungen an. Der Isolation Level Read Only verhält sich ähnlich, lässt jedoch keine Datenänderungen zu, es sei denn, der Benutzer ist SYS. Folgende Befehle ermöglichen einen vom Standard abweichenden Isolation Level: SQL> SET TRANSACTION READ ONLY; SQL> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SQL> SET TRANSACTION READ COMMITED;

39

Siehe Kapitel 4 „Speicherplatzverwaltung“, hier insbesondere Abschnitt „Interested Transaction List (ITL)“. 40 Informationen zum User Dump Destination finden Sie in Abschnitt 13.3 „Recovery Manager (RMAN)“.

77

2 Architektur und Administration

2.4.6

System Change Number (SCN)

Eine System Change Number (SCN) ist ein logischer Zeitstempel. SCNs werden monoton inkrementiert und ermöglichen eine Zuordnung von Vorgängen in der Datenbank zu einem Zeitstrahl. Jeder Transaktion wird eine eindeutige SCN zugeordnet. Auch der Commit-Satz erhält eine SCN. SCNs werden unter anderem während des Instanz- und Media-Recoverys genutzt, um die Datenbankkonsistenz zu überprüfen und gegebenenfalls mittels Redologs alle fehlenden Änderungen bis zur letzten SCN nachzuvollziehen. Auch während eines Checkpoints wird die aktuelle SCN im Datei-Header sowie in den Controlfiles verzeichnet. Die aktuelle SCN der Datenbank kann mit der Funktion Paketes dbms_flashback ermittelt werden:

get_system_change_number

des

SQL> SELECT dbms_flashback.get_system_change_number FROM dual;

Die Tabelle smon_scn_time zeigt SCN und Zeitstempel in Fünf-Minuten-Intervallen an. Diese undokumentierte Tabelle enthält maximal 1440 Zeilen und speichert somit Information der letzten fünf Tage. SQL> SELECT * FROM smon_scn_time;

Die Funktionen scn_to_timestamp zeigt den zu einer SCN gehörenden Zeitstempel: SQL> SELECT scn_to_timestamp (1086200) AS zeit FROM dual; ZEIT ---------------------------------------------------11.01.10 11:06:58,000000000

Die Umkehrungsfunktion lautet scn_to_timestamp: SQL> SELECT timestamp_to_scn ('22.02.10 12:06:00,000000000') AS SCN FROM dual; SCN ---------1165083

2.4.7

Checkpoints

Während eines Checkpoints werden alle geänderten Datenblöcke in die Datafiles geschrieben. Folgende Ereignisse lösen automatisch einen Checkpoint aus: Herunterfahren der Datenbankinstanz mit shutdown 

normal, shutdown immediate

oder

shutdown transactional

Starten einer Online-Sicherung mit 

alter

database

begin

backup

oder

alter

tablespace begin backup

Offline-Setzen eines Tablespaces mit 

alter

tablespace

temporary

Bei einem automatischen Wechsel der Redolog-Gruppe 

78

offline

normal

oder

2.4 Konsistenz der Datenbank Bei einem erzwungenen Wechsel der Redolog-Gruppe mit alter 

system switch log-

file

Bei einem erzwungenen Checkpoint mit alter system checkpoint  Hat eines dieser Ereignisse einen Checkpoint ausgelöst, so schreibt der Database-WriterProzess alle geänderten Datenblöcke aus dem Datenbankblockpuffer der SGA in die Datafiles. Checkpoints lassen sich im fast mode oder im normal mode durchführen. Welcher Modus zum Einsatz kommt, hängt vom auslösenden Ereignis ab. So wird beim Herunterfahren der Datenbank der fast mode genutzt, bei dem schnellstmöglich alle Blöcke in die Datafiles übertragen werden, während bei einem Wechsel der Redolog-Gruppe im laufenden Betrieb der normal mode zum Tragen kommt, der weniger Ressourcen, dafür jedoch mehr Zeit für die Durchführung benötigt. Der Abschluss eines Checkpoints wird mit der aktuellen System Change Number (SCN) im Kopf jedes Datafiles sowie in den Controlfiles vermerkt. Database Buffer Cache Default Cache

2K

4K

Keep Cache

Recycle Cache

DBWR0

CKPT

DBWR Datenblöcke => Datafiles

16K

SCN => Datafile-Header

Checkpoint-Informationen

Controlfiles Datafiles Datafiles Datafiles

Datafiles

Abbildung 2.9 Checkpoint einer Oracle-Datenbank

Praxistipp Bei hoher Transaktionslast können zu häufige Checkpoints als Performance-Bremse wirken. In diesem Fall schreibt die Datenbankinstanz eine Information in die Alert-Datei: Der Eintrag lautet „checkpoint not complete“. Die Datenbank bleibt in diesem Fall vorübergehend in einem Wartezustand, der erst mit Abschluss des Checkpoints beendet wird. Um die Anzahl der Checkpoints zu reduzieren, empfiehlt es sich, entweder größere Redologs anzulegen oder mehr Redolog-Gruppen zu verwenden.

79

2 Architektur und Administration Die Häufigkeit von Checkpoints lässt sich mit den Parametern log_checkpoint_interval, und fast_start_mttr_target steuern:

log_checkpoint_timeout

log_checkpoint_interval gibt die Anzahl an Blöcken à 512 KB an, nach denen  spätestens ein Checkpoint erfolgt. log_checkpoint_timeout gibt die Zeit in Sekunden an, nach denen spätestens ein  Checkpoint erfolgen muss.

Praxistipp Um unnötige Checkpoints zu vermeiden, empfiehlt es sich, die Parameter log_checkpoint_ interval und log_checkpoint_timeout auf 0 zu setzen und damit die Steuerung über diese Parameter zu deaktivieren. Ein Checkpoint wird dann nur während eines der oben genannten Ereignisse ausgelöst. Aus Performance-Gesichtspunkten ist dies optimal.

Ein weiterer Parameter zur Steuerung von Checkpoints ist fast_start_io_target. Er wurde mit Oracle 8i eingeführt und dient dazu, die maximale Anzahl an I/Os bei einer Instanz-Wiederherstellung zu beschränken. Er wird zwar in aktuellen Versionen noch unterstützt, doch stattdessen sollte man den neueren Parameter fast_start_mttr_target verwenden, der mit Oracle 9i eingeführt wurde und in der Enterprise Edition zur Verfügung steht. Er steuert die Mean Time to Recover (MTTR), den mittleren Zeitraum für die Instanz-Wiederherstellung. Die Angabe erfolgt in Sekunden. Mit Oracle 10g wurde der Algorithmus weiter verbessert, so dass nun Zeiten mit geringer I/O-Last genutzt werden. Systeme, die kurze Wiederanlaufzeiten benötigen, lassen sich so recht komfortabel steuern.

2.4.8

Crash Recovery

Wird eine Datenbankinstanz hart beendet, beispielsweise durch einen Stromausfall, durch ein shutdown abort oder kill -9, so sind die Datafiles nicht synchronisiert. Der Wiederanlauf benötigt in diesem Fall ein Recovery, um die Datafiles wieder in einen konsistenten Zustand zu bringen. Dieser implizite Recovery-Prozess, den die Datenbankinstanz automatisch und ohne administrative Eingriffe selbst ausführt, heißt Crash Recovery. Oracle führt automatisch ein Recovery durch, sobald man die Datenbank das erste Mal nach einem Absturz öffnet. Um Inkonsistenzen zu erkennen, gleicht SMON in der OpenPhase der Datenbank die System Change Number in den Datei-Headern ab. Sind diese konsistent, wird die Datenbank geöffnet, ansonsten leitet der SMON das Crash Recovery ein. Verkürzt stellt sich ein Crash Recovery wie folgt dar: 1. SMON stellt Inkonsistenzen fest. 2. Roll Forward-Phase

Die Redologs werden gelesen. Alle Änderungen, die in den Redologs protokolliert sind, werden auf die Datenblöcke angewendet.

DBWR schreibt mit commit die bestätigten wie auch die unbestätigten Änderungen in die Datafiles.

80

2.5 Start und Stopp einer Oracle-Datenbank 3. Open-Phase

Bestätigte und nicht bestätigte Daten sind in den Datafiles. Die Datenbank wird geöffnet. 4. Rollback-Phase

Nicht bestätigte Datenänderungen werden mittels der Informationen aus dem UndoBereich zurückgerollt. 5. In den Datafiles sind ausschließlich mit commit bestätigte Daten gespeichert. Die Oracle-Instanz nutzt in Schritt 2 die Informationen des letzten Checkpoints, um zu bestimmen, welche Änderungen appliziert werden müssen: Änderungen mit einer SCN, die kleiner ist als die des letzten Checkpoints, sind bereits in den Datafiles enthalten. Die SCN des letzten Checkpoint ist im Header jeder Datafile verzeichnet. In einer Umgebung, die Oracle Real Application Clusters nutzt, wird bei einem Absturz einer Datenbankinstanz von einer der noch intakten Instanzen im Wesentlichen der gleiche Vorgang ausgeführt, wie bei einem Crash Recovery. Man spricht hier jedoch von einem Instance Recovery.

2.5

Start und Stopp einer Oracle-Datenbank Der erste Teil dieses Abschnitts zeigt die Phasen während des Startup bzw. Shutdown einer Oracle-Datenbank. Dieses Wissen ist zwingend notwendig, um einige Wartungsarbeiten41 durchführen zu können. Auch für die Analyse im Fehlerfall und die Wiederherstellung einer Datenbank sind Kenntnisse der einzelnen Phasen hilfreich. Konkrete Befehle für den Startup und Shutdown stehen im Anschluss daran in den Abschnitten 2.5.3 „Startup-Befehle“ und 2.5.4 „Shutdown-Befehle“.

2.5.1

Phasen während des Startup

Eine Oracle-Datenbank durchläuft beim Start drei Phasen: Nomount  Mount  Open  Nomount-Phase In der Nomount-Phase liest Oracle die Werte der Initialisierungsparameter aus der Parameterdatei, allokiert den für die Instanz erforderlichen Arbeitsspeicher und startet die Hintergrundprozesse. Dazu wird wie folgt vorgegangen: 41

wie beispielsweise das Verschieben von Controlfiles, Redologs oder Datafiles

81

2 Architektur und Administration 1. Suchen der Initialisierungsdatei.

Wurde beim Startup nicht explizit der Pfad einer Parameterdatei angegeben, sucht die Instanz in den Standardverzeichnissen $ORACLE_HOME/dbs auf Unix- und LinuxSystemen bzw. $ORACLE_HOME/database auf Windows-Systemen. Der Oracle Datenbankserver nutzt dazu folgende Auswertungsreihenfolge: 1.

spfile<SID>.ora42

2.

spfile.ora

3.

init<SID>.ora

4.

init.ora

Es wird nur genau eines dieser Files gelesen und ausgewertet, und zwar jenes, das gemäß der oben genannten Reihenfolge als erstes gefunden wurde. Besteht eine spfile<SID>.ora, so wird eine eventuell ebenfalls vorhandene init<SID>.ora nicht mehr beachtet. Sie wird nur dann geöffnet und gelesen, wenn entsprechend der Auswertungsreihenfolge nicht schon eine spfile<SID>.ora oder spfile.ora im oben angegebenen Pfad steht.

Ist weder ein SPFile noch eine Init.ora vorhanden, bricht der Startup-Vorgang mit einer Fehlermeldung ab. 2. Öffnen der Initialisierungsdatei und Auswerten der Datenbank-Parameter. 3. Allokieren des Arbeitsspeichers gemäß der Parametrisierung in der Initialisierungsdatei. 4. Starten der Hintergrundprozesse. Nach erfolgreichem Abschluss der Nomount-Phase ist die Instanz gestartet, hat jedoch noch keine Verbindung zur Datenbank. Befehle wie create database und create controlfile können in dieser Phase abgesetzt werden. Auch auf einige Dynamische Performance Views43 hat man bereits Zugriff. Der in der Initialisierungsdatei hinterlegte Parameter control_files enthält Pfade und Namen der Controlfiles. Diese Information wird benötigt, um mit der nächsten Phase fortzufahren. Mount-Phase In der Mount-Phase stellt die Oracle-Instanz die Verbindung zur Datenbank her. 1. Öffnen der Controlfiles. Der Pfad wird dem Parameter control_files der Initialisierungsdatei entnommen. Das Öffnen der Controlfiles stellt die Verbindung zwischen Instanz und Datenbank her.

42 43

82

Mit <SID>: System Identifier (Name der Datenbankinstanz) Dynamische Performance Views (V$-Views) sind virtuelle Views, die dynamische Informationen wie zu Strukturen der SGA und zur Parametrisierung der Datenbank anzeigen. Siehe auch Abschnitt 2.12.2 Dynamische Performance Views.

2.5 Start und Stopp einer Oracle-Datenbank 2. Überprüfen der Konsistenz der Controlfiles. Die Controlfiles sind üblicherweise mit Oracle-Bordmitteln gespiegelt. In der Mount-Phase werden die gespiegelten Dateien geöffnet und miteinander verglichen. Nur wenn alle Spiegel konsistent zueinander sind, kann die Mount-Phase erfolgreich beendet werden. Die Controlfiles enthalten Informationen wie den Pfad und Namen aller Daten- und Redologs. In der Mount-Phase können Dateien umbenannt werden. Namens- und Pfadänderungen werden in den Controlfiles gespeichert und ersetzen die alten Einträge. Eine Wiederherstellung der Datenbank mit RMAN muss ebenfalls in der Mount-Phase erfolgen. Hintergrund ist, dass Informationen zu Datenbanksicherungen mit RMAN in den Controlfiles gespeichert sind. Diese sind notwendig, damit RMAN ein Restore und Recovery durchführen kann44. Die in den Controlfiles enthaltenen Namens- und Pfadangaben von Daten- und Redologs sind für die nächste Phase erforderlich. Open-Phase In der Open-Phase werden Daten- und Redologs auf Konsistenz geprüft und geöffnet. Dazu wird wie folgt vorgegangen: 1. Lesen der Pfade und Namen der Daten- und Redologs aus den Controlfiles. 2. Der Datenbankserver öffnet nun diese Dateien und überprüft die Konsistenzinformationen in den Datei-Headern. 3. Stimmen die Informationen miteinander überein, ist die Open-Phase abgeschlossen. Die Datenbank steht nun für Benutzerzugriffe zur Verfügung. Sind die Konsistenzinformationen nicht identisch, führt der SMON-Prozess ein CrashRecovery durch. SMON liest dazu die Online Redologs und vollzieht die Änderungen in den Datafiles nach. Sind neben den Informationen aus den Online Redologs auch die der archivierten Redologs notwendig, gibt die Oracle-Instanz eine entsprechende Meldung aus. In diesem Fall ist ein Recovery in der Mount-Phase erforderlich. Genauere Informationen finden Sie im Kapitel 13 „Backup und Recovery“.

2.5.2

Phasen während des Shutdowns

Ähnlich wie ein Startup läuft auch der Shutdown in drei Phasen ab: Close: Schließen der Datafiles  Dismount: Schließen der Controlfiles  Terminierung der Instanz: Freigabe des allokierten Arbeitsspeichers und Stoppen der  Hintergrundprozesse

44

Bei Verwendung eines Recovery-Kataloges ist der Zugriff auf die Controlfiles obsolet

83

2 Architektur und Administration Close- Phase In der Close-Phase werden die Datafiles konsistent geschlossen: 1. Auslösen eines Checkpoints; der Database Writer schreibt alle geänderten Blöcke in die Datafiles. 2. Schreiben der Konsistenzinformationen – unter anderem der System Change Number – in die Header der Datafiles. 3. Schließen der Daten- und Redologs. Dismount- Phase Die Dismount-Phase schließt die Controlfiles konsistent: 1. Schreiben der Konsistenzinformationen – unter anderem der System Change Number – in die Controlfile-Header. 2. Schließen der Controlfiles. Terminierung der Instanz Abschließend wird die Instanz terminiert: 1. Freigeben des von der Instanz genutzten Arbeitsspeichers. 2. Beenden der Hintergrundprozesse der Instanz.

2.5.3

Startup-Befehle

Für den Start eines Oracle-Systems ist es erforderlich, als sysdba oder sysoper angemeldet zu sein. Die allgemeine Syntax des Startup-Befehls für Oracle-Datenbanken lautet: startup [FORCE] [RESTRICT] [PFILE=filename] [QUIET] [ MOUNT [dbname] | [ OPEN [open_options] [dbname] ] | NOMOUNT ]

mit open_options: READ {ONLY | WRITE [RECOVER]} | RECOVER

Enthält der Startup-Befehl keine weitere Option, startet Oracle stets bis in die Open-Phase und öffnet die Datenbank. In diesem Fall durchläuft das System automatisch alle drei Phasen und steht – sofern kein Fehler aufgetreten ist – abschließend für Benutzerzugriffe zur Verfügung. SQL> startup;

Sofern Sie die Datenbank mit einer Initialisierungsdatei, die vom Standard abweicht, starten möchten, geben Sie deren Pfad- und Dateinamen explizit an: SQL> startup pfile='/opt/oracle/admin/ora11g/pfile/init_test.ora';

Leider ist es nur möglich, eine Init.ora als Initialisierungsdatei anzugeben. Für ein SPFile, das vom Standard abweicht, gibt es einen Trick: Erstellen Sie eine Init.ora, in der Sie nur den Parameter spfile hinterlegen: SPFILE='/opt/oracle/admin/ora11g/pfile/spfile_test.ora';

84

2.5 Start und Stopp einer Oracle-Datenbank Nun starten Sie mit Angabe dieser Init.ora; hier liest die Instanz den SPFile-Parameter und greift anschließend auf das SPFile zu. In den Nomount- oder Mount-Status starten Bei Wartungsarbeiten kann es erforderlich sein, die Instanz bis zur Nomount- oder zur Mount-Phase zu starten und die Datenbank (noch) nicht zu öffnen. In diesem Fall gibt man die Phase an, bis zu der der Startvorgang durchgeführt werden soll, zum Beispiel: SQL> startup nomount;

Es ist auch möglich, mit einer vom Standard abweichenden Initialisierungsdatei zu starten: SQL> startup nomount pfile='/opt/oracle/admin/ora11g/pfile/init_test.ora';

Für die Mount-Phase gilt das gleiche Vorgehen: SQL> startup mount;

Oder auch: SQL> startup mount pfile='/opt/oracle/admin/ora11g/pfile/init_test.ora';

Sofern Sie in der Nomount- oder Mount-Phase anhalten, kann die Datenbank nur mit dem Befehl alter database in die nächste Phase überführt werden: SQL> alter database mount; SQL> alter database open;

Session-Restriktion Will man Wartungsarbeiten an einer geöffneten Oracle-Datenbank ausführen und dafür sorgen, dass sich unpriviligierte Benutzer währenddessen nicht anmelden können, wählt man den Start in den restricted Modus: SQL> startup restrict;

Nur Benutzer, die das Privileg restricted session besitzen, können sich dann anmelden. Dazu zählen DBAs, aber keine normalen Benutzer. Schnelles Durchstarten Der Befehl startup force führt dazu, dass die Instanz mit einem shutdown abort abgebrochen und danach neu gestartet wird. Der Effekt ist im Wesentlichen derselbe, als hätten Sie einen Reset-Knopf gedrückt oder kurz den Strom abgeschaltet. Die Datenbank ist daher zunächst inkonsistent und wird beim Wiederanlauf über ein Crash Recovery korrigiert. Der folgende Befehl ist daher nur im Notfall anzuwenden: SQL> startup force;

Im Read-only-Modus öffnen Eine Datenbank lässt sich auch mit der Option read

only

schreibgeschützt öffnen:

SQL> startup read only;

85

2 Architektur und Administration Um in den Read-write-Modus zu wechseln, kann man die Datenbankinstanz entweder durchstarten oder aber den folgenden Befehl verwenden: SQL> alter system read write;

Upgrade und Downgrade Möchten Sie ein Upgrade oder Downgrade der Datenbank durchführen, ist der Befehl startup upgrade bzw. downgrade hilfreich: SQL> startup upgrade; SQL> startup downgrade;

Bildschirmausgabe beim Start unterdrücken Um die Ausgabe bei einem Startup zu unterdrücken, gibt es ab Oracle 11.2 den Befehl startup quiet: SQL> startup quiet;

unterdrückt Ausgaben wie die der SGA-Größen und ist geeignet, um eine Instanz via Shell-Skript ohne Bildschirmoutput zu starten.

Startup quiet

Zudem bietet es sich an, den Startup-Befehl über eine SQL*Plus-Session im Silent-Modus abzusetzen. Der Silent-Modus unterdrückt die Anzeige des Oracle-Banners bei der Anmeldung und das Echo eines Befehls. Wird beim Aufruf von SQL*Plus im Silent-Modus kein Benutzername und Kennwort übergeben, wartet SQL*Plus auf die Eingabe, jedoch ohne die Aufforderung zur Eingabe anzuzeigen. Der folgende Aufruf startet SQL*Plus im Silent-Modus und ruft das Skript auf:

restart.sql

sqlplus -s /nolog @restart.sql

Der Schalter /nolog sorgt dafür, dass zunächst keine Angaben von Benutzer und Kennwort erfolgen muss. Diese werden einfach in das Skript ausgelagert. Das Skript restart.sql kann beispielsweise folgenden Inhalt haben: connect / as sysdba shutdown immediate; startup quiet; exit;

Vor Oracle 11g R2 wird der Schalter quiet nicht unterstützt. Stattdessen muss eine Umlenkung beispielsweise auf /dev/null erfolgen.

2.5.4

Shutdown-Befehle

Auch für das Herunterfahren eines Oracle-Systems ist es erforderlich, als sysdba oder sysoper angemeldet zu sein. Die allgemeine Syntax lautet: shutdown [normal | immediate | transactional [local] | abort]

Wird bei einem Shutdown keine Option angeben, so ist normal die Voreinstellung.

86

2.5 Start und Stopp einer Oracle-Datenbank Normal Bei einem shutdown normal wird mit dem Stoppen des Systems solange gewartet, bis alle Benutzer sich abgemeldet haben. Die Instanz nimmt jedoch keine neuen Benutzeranmeldungen an. Danach wird ein Checkpoint im fast mode ausgeführt. Der Database Writer schreibt alle geänderten Blöcke in die Datafiles. Anschließend schreibt der Prozess SMON Konsistenzinformationen in die Header der Datafiles. Daten- und Redologs werden danach geschlossen. Damit ist die Close-Phase abgeschlossen. Anschließend erhalten die Controlfiles aktuelle Konsistenzinformationen. Auch sie werden danach geschlossen. Damit ist die Dismount-Phase beendet. Abschließend werden die Hintergrundprozesse beendet und der Arbeitsspeicher wird freigegeben. Die Datenbank befindet sich in einem konsistenten Zustand und lässt sich in diesem Zustand konsistent sichern. Praxistipp Der Befehl shutdown normal wird in der Praxis selten eingesetzt. Halten beispielsweise Agenten des Enterprise Managers eine Verbindung zur Datenbank, verhindert dies ein Herunterfahren des Systems in diesem Modus. Meist verwendet man die Option shutdown immediate, um die Datenbankinstanz herunterzufahren.

Immediate Der Ablauf eines shutdown immediate entspricht dem des shutdown normal. Jedoch wird nicht gewartet, bis sich alle Benutzer abgemeldet haben. Vielmehr beendet der Prozess PMON alle Benutzerprozesse und rollt anschließend alle offenen Transaktionen zurück. Dabei wird so lange gewartet, bis das aktuelle Statement beendet ist. Neue Befehle werden jedoch nicht mehr ausgeführt. So kann es vorkommen, dass ein Delete-Statement noch ausgeführt wird, das folgende Commit aber nicht mehr. Danach folgen der Checkpoint, die Close- und die Dismount-Phase. Die Datenbank ist konsistent geschlossen. Im Regelfall wird eine Oracle-Datenbank mit dieser Option heruntergefahren. Dennoch: Sofern lang laufende Transaktionen zurückgerollt werden müssen, kann selbst ein shutdown immediate recht lange dauern. Präventiv kann man vor dem Herunterfahren der Datenbank-Instanz überprüfen, welche Transaktionen derzeit geöffnet sind und wie viele Undo-Blöcke diese nutzen. Die folgende Abfrage zeigt die Anzahl der durch offene Transaktionen genutzten Undo-Blöcke: SQL> SELECT sum(used_ublk) FROM v$transaction;

Die Anzahl der Undo-Blöcke multipliziert mit der Größe eines Datenblockes ergibt die Menge an Undo-Informationen, die zunächst zurückgerollt werden muss. Die folgende Abfrage gibt die Menge der Undo-Informationen in MB aus:

87

2 Architektur und Administration SQL> SELECT (used_ublk * (SELECT block_size FROM dba_tablespaces WHERE contents = 'UNDO') )/1024/1024 MB FROM v$transaction;

Wie viel Zeit ein System für das Zurückrollen der hier ausgegebenen Datenmenge benötigt, hängt von vielen Faktoren ab, etwa die Anzahl der CPUs oder der Geschwindigkeit des Storage. Zumindest liefert die Ausgabe einen Anhaltspunkt: Wenige MB sind stets recht schnell zurückgerollt, während Hunderte von GB auch beim schnellsten System etwas mehr Zeit erfordern. Transactional Bei einem shutdown transactional wird auf den Abschluss aller noch offenen Transaktionen gewartet. Danach folgen der Checkpoint sowie die Close- und die DismountPhase. Die Datenbank wird abschließend konsistent geschlossen. Faktisch wird dieser Befehl selten eingesetzt. Sofern eine Anwendung eine offene Transaktion über einen längeren Zeitraum nicht beendet, kann die Datenbankinstanz mit dieser Option nicht heruntergefahren werden. Transactional local Der Befehl shutdown transactional local entspricht dem shutdown transactional. Wird die Option local in einem Real Application Cluster verwendet, wird das Herunterfahren einer Instanz nicht durch offene Transaktionen anderer Instanzen im Cluster blockiert. Abort Ein shutdown abort stoppt die Instanz instantan, also sofort. Bei einem shutdown abort wird kein Checkpoint ausgeführt. Geänderte Blöcke werden nicht mehr in die Datafiles übertragen. Vielmehr werden unmittelbar alle Hintergrundprozesse beendet und der Arbeitsspeicher wird freigegeben. Das Ergebnis eines shutdown abort ist stets ein inkonsistenter Zustand der Datenbank. Praxistipp Die Datenbank ist nach einem shutdown abort nicht konsistent. Für eine konsistente OfflineDatensicherung ist sie demzufolge nicht geeignet.

Bei einem Startup nach einem shutdown abort muss stets ein Crash Recovery ausgeführt werden, um die Datenbank wieder in einen konsistenten Zustand zu überführen. In diesem Zustand ist die Datenbank nicht für eine Sicherung geeignet. Ein shutdown abort sollte man nur in Notfällen einsetzen.

88

2.6 Verwaltung von Tablespaces Praxistipp Um die Datenbank für eine Offline-Sicherung in einen konsistenten Zustand zu bringen, starten Sie diese erneut und beenden sie anschließend geordnet mit einem shutdown immediate.

2.6

Verwaltung von Tablespaces Die folgenden Abschnitte zeigen Ihnen, wie Sie Informationen zu vorhandenen Tablespaces ermitteln  Einen neuen Tablespace erstellen, vergrößern, verkleinern oder löschen  Einen Tablespace offline und online, read only und read write setzen  Datafiles umbenennen und verschieben  Temporary und Undo Tablespaces verwalten  Benutzern einen Default Tablespace für permanente Daten sowie für Temporärsegmen te zuweisen Wir starten zunächst damit, Informationen über vorhandene Tablespaces zu sammeln.

2.6.1

Informationen zu bestehenden Tablespaces ermitteln

Namen und Attribute vorhandener Tablespaces Die Views Datenbank:

dba_tablespaces

und

v$tablespace

geben Auskunft zu Tablespaces der

SQL> SELECT tablespace_name, block_size FROM dba_tablespaces; SQL> SELECT name, bigfile, flashback_on FROM v$tablespace;

Speziell dba_tablespaces ist nützlich: Sie liefert Informationen darüber, ob der Tablespace verschlüsselt wurde, ein Bigfile- oder Smallfile-Tablespace ist, welches Extent- und Segmentmanagement verwendet wird sowie ob Komprimierung genutzt oder Logging deaktiviert wurde: SQL> desc dba_tablespaces Name ----------------------------------------TABLESPACE_NAME BLOCK_SIZE INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS MAX_SIZE PCT_INCREASE MIN_EXTLEN STATUS CONTENTS

Null? -------NOT NULL NOT NULL

Typ ----------------VARCHAR2(30) NUMBER NUMBER NUMBER NOT NULL NUMBER NUMBER NUMBER NUMBER NUMBER VARCHAR2(9) VARCHAR2(9)

89

2 Architektur und Administration LOGGING FORCE_LOGGING EXTENT_MANAGEMENT ALLOCATION_TYPE PLUGGED_IN SEGMENT_SPACE_MANAGEMENT DEF_TAB_COMPRESSION RETENTION BIGFILE PREDICATE_EVALUATION ENCRYPTED COMPRESS_FOR

VARCHAR2(9) VARCHAR2(3) VARCHAR2(10) VARCHAR2(9) VARCHAR2(3) VARCHAR2(6) VARCHAR2(8) VARCHAR2(11) VARCHAR2(3) VARCHAR2(7) VARCHAR2(3) VARCHAR2(18)

Die View v$tablespace zeigt weit weniger Informationen: SQL> desc v$tablespace Name Null? ----------------------------------------- -------TS# NAME INCLUDED_IN_DATABASE_BACKUP BIGFILE FLASHBACK_ON ENCRYPT_IN_BACKUP

Typ ----------------NUMBER VARCHAR2(30) VARCHAR2(3) VARCHAR2(3) VARCHAR2(3) VARCHAR2(3)

Informationen zu Tablespaces und Datafiles Um zusätzliche Informationen wie die Größe des Tablespaces bzw. der Datafiles zu ermitteln, verknüpft man die View v$datafile mit v$tablespace über die Spalte TS#: SELECT FROM WHERE GROUP BY

ts.name, round(sum(bytes) / 1024 / 1024, 2) MB v$tablespace ts, v$datafile df ts.ts# = df.ts# ts.name;

Die Größen der einzelnen Datafiles lassen sich wie folgt ermitteln: SELECT FROM WHERE ORDER BY

ts.name, df.name, round(bytes / 1024 / 1024, 2) MB v$tablespace ts, v$datafile df ts.ts# = df.ts# ts.name, df.name;

Während die Views v$datafile und v$tablespace bereits im Mount-Status der Datenbank abgefragt werden können, benötigen dba_tablespace und dba_data_files den Zugriff auf die Basistabellen des Data Dictionary. Sie sind daher nur dann verfügbar, wenn die Datenbank geöffnet ist. SELECT FROM

tablespace_name, block_size, status, contents bigfile, encrypted, compress_for dba_tablespaces;

Die View dba_data_files zeigt zusätzliche Informationen zu Datafiles an: SELECT

FROM ORDER BY

tablespace_name, file_name, status, round(bytes / 1024 / 1024, 2) "MB CURRENT SIZE", autoextensible, round(maxbytes / 1024 /1024, 2) "MB MAXSIZES", increment_by dba_data_files 1, 2;

Eine umfassende Übersicht erhalten Sie durch die folgenden Abfragen: SELECT name, status, creation_time last_time

90

AS AS

"Erstellungsdatum", "Letzte Aenderung",

2.6 Verwaltung von Tablespaces round(bytes/1024/1024,2) block_size FROM v$datafile;

AS AS

"Groesse in MB", "Groesse Datenbloecke"

SELECT tablespace_name file_name round(bytes/1024/1024, 2) autoextensible round(maxbytes/1024/1024, 2) online_status FROM dba_data_files ORDER BY 1, 2

AS AS AS AS AS AS

"Tablespace", "Name", "Groesse MB", "automatisch erweiterbar", "max. Groesse MB", "Status"

Praxistipp Um Informationen zu Tempfiles eines Temporary Tablespaces zu ermitteln, ist die View dba_temp_files anstelle von dba_data_files abzufragen.

Namen und Attribute der Data Files ermitteln Die Views v$datafile und Data Files an: SET SET COL COL COL COL COL

PAGES 3000 LINES 120 Tablespace_name file_name size_GB max_size_GB inc_size_GB

SELECT

FROM ORDER BY

dba_data_files

FORMAT FORMAT FORMAT FORMAT FORMAT

zeigen Pfad und Namen sowie Attribute zu

a20 A38 999,990.0000 999,990.0000 999,990.0000

tablespace_name, file_name, online_status round (bytes/1073741824, 4) autoextensible round (maxbytes/1073741824, 4) round (increment_by/1073741824, 4) dba_data_files tablespace_name, file_name;

AS AS AS AS AS

status, size_GB, auto_ext, max_size_GB, inc_size_GB

Namen und Attribute von Temp Files Informationen zu Tempfiles liefert die View v$tempfile: SELECT name, status, bytes, block_size FROM v$tempfile;

Belegung von Extents im Tablespace Die View dba_extents gibt detaillierte Informationen zur Speicherbelegung aus. Jedes Extent eines Speichersegments kann über diese View ermittelt werden. SELECT FROM WHERE GROUP BY ORDER BY

tablespace_name, segment_type, owner, segment_name, round(sum(bytes/1024/1024), 2) "Size MB" dba_extents tablespace_name = 'APP_01_DATA' tablespace_name, segment_type, owner, segment_name tablespace_name, segment_type, owner, segment_name;

Die Data Dictionary View dba_free_space zeigt eine Übersicht zum freien Speicherplatz:

91

2 Architektur und Administration SELECT FROM GROUP BY

tablespace_name, round(sum(bytes)/1024/1024,2) "free MB" dba_free_space tablespace_name;

Diese Übersicht lässt sich bis auf Datafile-Ebene herunterbrechen: SELECT

FROM WHERE GROUP BY

sp.tablespace_name, df.file_name, df.autoextensible, round(sum(sp.bytes)/1024/1024,2) "free MB", round(sum(df.bytes)/1024/1024,2) "current size MB", round(sum(df.maxbytes)/1024/1024,2) "max size MB" dba_free_space sp, dba_data_files df sp.file_id = df.file_id sp.tablespace_name, df.file_name, df.autoextensible;

Default-Tablespaces eines Benutzers Welche Tablespaces als Standard- bzw. Temporary Tablespaces einem Benutzer zugewiesen wurden, zeigt die View dba_users: SELECT FROM ORDER BY

2.6.2

username, default_tablespace, temporary_tablespace dba_users username;

Tablespaces erstellen

Bigfile- und Smallfile-Tablespaces Bigfile-Tablespaces nutzen genau eine Datendatei. Sie kann maximal 232 Datenblöcke enthalten und bis zu 128 TB groß werden. Bigfile-Tablespaces sollte man ausschließlich in Kombination mit Automatic Storage Management (ASM) oder einem Logical Volume Manager (LVM) einsetzen, der Striping bzw. RAID unterstützt. Es ist zu berücksichtigen, dass Bigfile-Tablespaces nur auf solchen Betriebssystemen wirklich sinnvoll sind, die ultragroße Dateigrößen unterstützen. Der traditionelle Tablespace-Typ ist der Smallfile Tablespace. Er kann bis zu 1022 Datafiles oder Tempfiles enthalten, von denen jedes bis zu maximal 222 Blöcke45 groß werden kann. Die maximale Dateigröße eines Datafiles oder Tempfiles in einem Smallfile Tablespace ist daher von der Blockgröße des Tablespace abhängig. Praxistipp Beim Einsatz eines Logical Volume Managers ist die Verwendung von Bigfile-Tablespaces durchaus eine Option. Jedoch kann die Datensicherung und Wiederherstellung eines einzelnen Datafiles bis Oracle Database 11g R2 nicht parallelisiert werden. Der Restore des Datafiles eines Bigfile-Tablespaces kann daher unter Umständen akzeptable Zeitfenster sprengen. Prüfen Sie dies vor dem Einsatz von Bigfile-Tablespaces genau!

45

92

Etwas mehr als 4 Millionen (genau 4 194 304) Blöcke

2.6 Verwaltung von Tablespaces Default-Typ für Tablespaces festlegen Der Befehl alter

database

setzt den Default-Typ für Tablespaces auf Bigfile:

ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;

Um wieder auf Smallfile zurückzusetzen, gibt es den Befehl: ALTER DATABASE SET DEFAULT SMALLFILE TABLESPACE;

Permanenten Tablespace gemäß Standardtyp erstellen CREATE TABLESPACE user_ts DATAFILE '/opt/oracle/oradata/meineDB/user_01.dbf' SIZE 2000 M;

Permanenten Smallfile-Tablespace erstellen CREATE SMALLFILE TABLESPACE user_ts DATAFILE '/opt/oracle/oradata/meineDB/users_01.dbf' SIZE 2000 M;

Permanenten Bigfile-Tablespace erstellen CREATE BIGFILE TABLESPACE big_ts_01 DATAFILE '/opt/oracle/oradata/meineDB/big_ts_01.dbf' SIZE 2000 M AUTOEXTEND ON;

Weitere Informationen zur Klausel vergrößern und verkleinern“.

autoextend

stehen im Abschnitt 2.6.4 „Tablespace

Temporary Tablespace erstellen Der folgende Befehl erstellt einen Temporary Tablespace: CREATE TEMPORARY TABLESPACE temp_01 TEMPFILE '/opt/oracle/oradata/meineDB/temp01.dbf' SIZE 800M;

Auch temporäre Tablespaces können als Bigfile-Tablespace erstellt werden: CREATE BIGFILE TEMPORARY TABLESPACE temp_01 TEMPFILE '/opt/oracle/oradata/meineDB/temp01.dbf' SIZE 800M;

Undo Tablespace erstellen Der Befehl create database erstellt implizit einen Undo Tablespace. Im Regelfall ist ein weiterer Undo Tablespace nicht erforderlich. Umgebungen mit Real Application Clusters (RAC) bilden hier eine Ausnahme. Jede Instanz im Cluster benötigt einen eigenen, exklusiv genutzten Undo Tablespace. Ein neuer Undo Tablespace wird wie folgt erstellt: CREATE UNDO TABLESPACE undotbs_02 DATAFILE '/opt/oradata/myDB/undo02_01.dbf' SIZE 200M;

93

2 Architektur und Administration Man kann einen Undo Tablespace auch als Bigfile-Tablespace erstellen: CREATE BIGFILE UNDO TABLESPACE undotbs_02 DATAFILE '/opt/oradata/myDB/undo02_01.dbf' SIZE 200M;

Gleich ob Smallfile- oder Bigfile-Tablespace: Damit der neue Undo Tablespace genutzt wird, muss der Datenbankparameter undo_tablespace gesetzt und anschließend die Instanz durchgestartet werden. Für RAC-Datenbanken ist zusätzlich noch der Instanzname über die Klausel SID anzugeben. SQL> ALTER SYSTEM SET undo_tablespace = 'UNDOTBS_02' SID = 'ORA01' SCOPE = SPFILE; SQL> shutdown immediate; SQL> startup; SQL> show parameter undo_tablespace

Weitere Informationen stehen im Abschnitt 2.6.13 „Verwaltung von Undo Tablespaces“. Tablespaces mit vom Standard abweichenden Blockgrößen Um mit Datenblockgrößen zu arbeiten, die von der Standardblockgröße der Datenbank abweichen, ist zunächst ein passender Cache bereitzustellen. Dies erfolgt über die Datenbankparameter db_k_cache_size46: ALTER SYSTEM SET db_16k_cache_size=20 M;

Anschließend kann der Tablespace mit abweichender Blockgröße erstellt bzw. bei Verwendung transportabler Tablespaces47 angehängt werden: CREATE TABLESPACE TS_USER_16 DATAFILE '/opt/oracle/oradata/meineDB/ts_users_16_01.dbf' SIZE 2000 M BLOCKSIZE 16 K;

Temporary Tablespaces können nicht mit abweichender Blockgröße erzeugt werden. Dies gilt auch für jeden Tablespace, in dem ein beliebiger Benutzer Temporär-Segmente speichert. Praxistipp Die Nutzung von Tablespaces mit vom Standard abweichenden Blockgrößen ist im Hinblick auf Performance-Optimierung nur in sehr seltenen Fällen sinnvoll. Im Regelfall lohnt der Aufwand kaum, der reale Performance-Gewinn ist oft nicht sehr hoch. Abweichende Blockgrößen kommen meist im Zusammenhang mit transportablen Tablespaces zum Einsatz, die zwischen Datenbanken unterschiedlicher Blockgrößen transferiert werden.

46 47

94

mit n Element in{2, 4, 8, 16, 32} Siehe Kapitel 16 im Abschnitt „Transportable Tablespaces“.

2.6 Verwaltung von Tablespaces Tablespaces mit Verschlüsselung der Benutzerdaten Permanente Tablespaces lassen sich ab Version 11g R1 vollständig verschlüsseln, um sensible Daten zu schützen. Die Tablespace-Verschlüsselung verhält sich gegenüber der Applikation transparent. Änderungen bestehender Anwendungen sind daher nicht erforderlich. Folgende Verschlüsselungsalgorithmen werden unterstützt: 3DES168  AES128  AES192  AES256  Ein Beispiel: ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "ein_passwort";

CREATE TABLESPACE encrypt_ts_01 DATAFILE '/opt/oracle/oradata/meineDB/encrypt_ts_01a.dbf' SIZE 1000M ENCRYPTION USING '3DES168' DEFAULT STORAGE (ENCRYPT);

Folgende Restriktionen gelten für verschlüsselte Tablespaces: Ein bestehender Tablespace kann nicht mit einem alter  selt werden.

tablespace-Befehl

verschlüs-

Transportable Tablespaces weisen einige Besonderheiten auf. Verschlüsselte Table spaces benötigen für den Transport das passende Wallet auf der Zieldatenbank. Hat die Zieldatenbank bereits ein Wallet, entsteht hier ein Konflikt. Zudem lassen sich verschlüsselte Tabelspaces nicht in Zieldatenbanken mit einem anderen Endformat als das der Quelldatenbank einbinden. Bei einem Recovery einer Datenbank, die einen oder mehrere verschlüsselte Table spaces enthält, ist zunächst das Oracle Wallet im Mount-Status zu öffnen, sodass der Recovery-Prozess die Daten entschlüsseln und aus dem Redo recovern kann. Die View v$encrypted_tablespaces liefert Informationen zur Verschlüsselung von Tablespaces: SELECT t.name, e.encryptionalg algorithm FROM v$tablespace t, v$encrypted_tablespaces e WHERE t.ts# = e.ts#;

Die Verschlüsselung von Tablespaces adressiert nicht alle Sicherheitsanforderungen. So kann jeder Benutzer, der Zugriffsrechte auf die Daten hat, diese auch lesen. Benutzern mit Privilegien wie select any table stehen damit die Daten frei zur Verfügung, auch wenn diese innerhalb des Tablespaces verschlüsselt gespeichert sind.

2.6.3

Tablespace umbenennen

Ein Tablespace wird mit der Klausel rename des Befehls alter

tablespace

umbenannt:

ALTER TABLESPACE users RENAME TO usersts;

95

2 Architektur und Administration

2.6.4

Tablespaces vergrößern und verkleinern

Die aktuelle Größe eines Datafiles wird über die Spalte ermittelt.

bytes

der View

dba_data_files

SELECT tablespace_name, file_name, round(bytes/1024/1024) AS MB, FROM dba_data_files ORDER BY tablespace_name, file_name;

Datafiles können entweder mit einer festen Größe oder aber mit der Option autoextend konfiguriert werden. Während man Datafiles mit einer festen Größe später manuell erweitern muss, vergrößern sich jene mit der Option autoextend automatisch, wenn zusätzlicher Speicherplatz benötigt wird. Optional lässt sich eine maximale Größe setzen, die nicht überschritten werden darf. Wird keine maximale Größe angegeben, so wächst die Datei so lange, wie Platz auf dem Laufwerk vorhanden ist. Ob ein Datafile automatisch erweitert wird und welche Maximalgröße für die automatische Erweiterung gesetzt wurde, zeigt die folgende Abfrage: SELECT tablespace_name, file_name, round(bytes/1024/1024) AS MB, autoextensible, round(maxbytes/1024/1024) AS max_MB FROM dba_data_files ORDER BY tablespace_name, file_name;

Für Temporary Tablespaces muss die View dba_temp_files abgefragt werden. Vergrößern und Verkleinern eines Bigfile-Tablespaces Die Größe eines Bigfile-Tablespaces wird wie folgt geändert: ALTER TABLESPACE bigtbs RESIZE 80G;

Auch für die Verkleinerung eines Datafiles wird der Resize-Befehl verwendet. Jedoch gibt es hier Einschränkungen: Sofern ein Datenblock hinter der Verkleinerungsgrenze belegt ist, kann nur bis zu diesem belegten Datenblock verkleinert werden. Dies gilt auch dann, wenn durch Fragmentierung noch sehr viel Speicherplatz im Datafile frei ist. Hier ist unter Umständen eine Reorganisation des Tablespaces erforderlich. Das Online Segment Shrink kann hierzu genutzt werden. Weitere Informationen finden Sie in Kapitel 4 „Speicherplatzverwaltung“. Vergrößern und Verkleinern von Datafiles eines Smallfile-Tablespace Um die Größe eines Smallfile-Tablespaces zu ändern, muss auf die einzelnen Datafiles zugegriffen werden. Die Klausel resize des Befehls alter database vergrößert manuell ein einzelnes Datafile: ALTER DATABASE DATAFILE 'C:\TEMP\TEST.DBF' RESIZE 2000 M;

Für die Verkleinerung von Datafiles in Smallfile Tablespaces gelten dieselben Einschränkungen wie die im vorherigen Abschnitt dargestellten für Bigfile-Tablespaces: Sofern ein

96

2.6 Verwaltung von Tablespaces Block hinter der Verkleinerungsgrenze belegt ist, ist eine Verkleinerung über dieses Limit hinaus nicht möglich. Gegebenenfalls muss man zunächst den Tablespace reorganisieren. Vergrößern und Verkleinern von Temporary Tablespaces Ein Locally Managed Temporary Tablespace kann im laufenden Betrieb vergrößert und verkleinert werden. Der folgende Befehl vergrößert bzw. verkleinert ein Temp-File: ALTER DATABASE TEMPFILE '/opt/oracle/oradata/meineDB/temp_01.dbf' RESIZE 500M;

Ab Oracle Database 11g R1 ist folgende Alternative zum Verkleinern möglich: ALTER TABLESPACE temp_01 SHRINK TEMPFILE '/opt/oracle/oradata/meineDB/temp_01.dbf' KEEP 20M;

Wird die Keep-Klausel nicht angegeben, so wird, so weit möglich, verkleinert. Folgender Befehl ist ebenfalls erst ab 11g R1 gültig. Er verkleinert den gesamten Tablespace: ALTER TABLESPACE temp_01 SHRINK SPACE KEEP 20M;

Autoextend aktivieren und deaktivieren Die Auto-Erweiterung von Bigfile-Tablespaces wird wie folgt aktiviert: ALTER TABLESPACE bigtbs AUTOEXTEND ON NEXT 20G;

Die automatische Erweiterung eines Smallfile-Tablespaces wird aktiviert, wenn man dessen Datafiles entsprechende Attribute zuweist. Der Befehl ist für jedes einzelne Datafile abzusetzen. ALTER DATABASE DATAFILE '/opt/oracle/oradata/meineDB/user_05_02.dbf' AUTOEXTEND ON NEXT 500 M MAXSIZE 4000 M;

Wird keine Maxsize angegeben, so wird die Dateigröße nicht begrenzt. Möchten Sie eine bestehende Maximalgröße erhöhen, so ist dies wie folgt möglich: ALTER DATABASE DATAFILE '/opt/oracle/oradata/meineDB/user_05_02.dbf' AUTOEXTEND ON MAXSIZE 10000 M;

Der folgende Befehl sorgt dafür, dass die Größe eines Datafiles nicht begrenzt ist. Das Limit wird nur noch durch den im Betriebssystem vorhandenen Plattenplatz gesetzt: ALTER DATABASE DATAFILE '/opt/oracle/oradata/meineDB/user_05_02.dbf' AUTOEXTEND ON MAXSIZE UNLIMITED;

Die Klausel tiert wird:

next

gibt an, um welche Speichermenge bei einer Autoallokation inkremen-

ALTER DATABASE DATAFILE '/opt/oracle/oradata/meineDB/user_05_02.dbf' AUTOEXTEND ON NEXT 1000 M;

97

2 Architektur und Administration Die Größe des Inkrements wird in dba_data_files abgebildet: SELECT file_name, increment_by FROM dba_data_files;

Die automatische Erweiterung eines Datafiles kann auch wieder deaktiviert werden: ALTER DATABASE DATAFILE '/opt/oracle/oradata/meineDB/user_05_02.dbf' AUTOEXTEND OFF;

2.6.5

Datafiles zu Tablespaces hinzufügen

Der Befehl space an:

alter tablespace

hängt weitere Datafiles einem bestehenden Smallfile-Table-

ALTER TABLESPACE user_05 ADD DATAFILE '/opt/oracle/oradata/meineDB/user_05_02.dbf' SIZE 500 M AUTOEXTEND ON NEXT 100 M MAXSIZE 4000 M;

Bei einem Bigfile-Tablespace ist dieser Befehl ungültig: Er besteht per Definition aus nur einem Datafile. Der folgende Befehl erweitert einen Temporary Tablespace um ein Tempfile: ALTER TABLESPACE temp_01 ADD TEMPFILE '/opt/oracle/oradata/meineDB/temp_01_09.dbf' SIZE 500 M AUTOEXTEND ON NEXT 500 M MAXSIZE 2000 M;

2.6.6

Datafiles verschieben oder umbenennen

Benutzer-Tablespaces Um ein Datafile verschieben oder umbenennen zu können, muss zunächst der betreffende Tablespace offline gesetzt sein. ALTER TABLESPACE tbs_02 OFFLINE NORMAL;

Dann benennt man das betreffende Datafile mit Betriebssystembefehlen um oder verschiebt es mit Betriebssystembefehlen an den neuen Speicherort. Der neue Pfad bzw. Dateiname wird anschließend der Datenbank mit dem Befehl tablespace bekanntgegeben: ALTER TABLESPACE tbs_02 RENAME DATAFILE '/opt/oracle/oradata/meineDB/tbs_02_09.dbf' TO '/odbfs03/oracle/oradata/meineDB/tbs_02_09.dbf';

Abschließend setzt man den Tablespace wieder online: ALTER TABLESPACE tbs_02 ONLINE;

98

alter

2.6 Verwaltung von Tablespaces Praxistipp Wir empfehlen, Dateien zu kopieren statt sie zu verschieben, sofern Sie ein Datafile oder Tempfile in ein anderes Dateisystem verlegen möchten. Ein Abbruch des Verschiebens über Dateisystemgrenzen hinweg, führt in seltenen Fällen zu nicht vorhersagbaren Ergebnissen. Nach Abschluss der Wartungsarbeiten können Sie das (veraltete) Original einfach löschen.

System- und Undo Tablespaces Obiges Verfahren ist für Benutzer-Tablespaces geeignet. Will man Dateien des Systemoder eines Undo Tablespaces verschieben, muss man die Datenbank in den Mount-Zustand überführen, sodass auf die Controlfiles zugegriffen werden kann, während System- und Undo-Dateien nicht geöffnet sind: 1. Herunterfahren der Datenbank shutdown immediate;

2. Umbenennen oder Verschieben der Dateien mit Betriebssystemmitteln 3. Die Datenbank in den Mount-Status starten startup mount;

4. Rename ausführen ALTER database RENAME FILE '/opt/oracle/oradata/meineDB/system.dbf' TO '/odbfs03/oracle/oradata/meineDB/system.dbf';

2.6.7

Tablespaces löschen

Löschen eines permanenten Tablespaces Ein permanenter Tablespace wird wie folgt gelöscht: DROP TABLESPACE user_ts_01 ;

Sofern noch Objekte im Tablespace gespeichert sind, wird die Fehlermeldung „ORA01549: Tablespace nicht leer, verwenden Sie die Option INCLUDING CONTENTS“ ausgegeben. Der Tablespace wird zunächst nicht gelöscht. Die Klausel including contents löscht implizit alle im Tablespace enthaltenen Objekte. Mit diesem Befehl sollte man äußerst sensibel umgehen: Er löscht ohne jede weitere Nachfrage alle enthaltenen Objekte. DROP TABLESPACE user_ts_01 INCLUDING CONTENTS;

Der obige Befehl entfernt den Tablespace aus der Datenbank. Die Datendateien bleiben jedoch im Filesystem bestehen und müssen manuell bereinigt werden. Möchten man den Tablespace inklusive aller Inhalte und Datendateien löschen, kann dies mittels entsprechender Klausel forciert werden: DROP TABLESPACE user_ts_01 INCLUDING CONTENTS AND DATAFILES;

99

2 Architektur und Administration Löschen eines Temporary Tablespaces Der folgende Befehl löscht einen Temporary Tablespace: DROP TEMPORARY TABLESPACE temp_01 ;

Löschen eines Undo Tablespace Der folgende Befehl entfernt einen Undo Tablespace: DROP TABLESPACE undo_01 ;

Wurde nicht zuvor ein anderer Undo Tablespace aktiviert, gibt das System folgende Fehlermeldung aus: ORA-30013: Undo Tablespace 'UNDOTBS_01' wird momentan benutzt

Nach Erstellung und Aktivierung eines neuen Undo Tablespaces lässt sich der alte erfolgreich löschen. Ein Beispiel: CREATE UNDO TABLESPACE undotbs_02 DATAFILE '/opt/ordata/myDB/undo02_01.dbf' SIZE 200M REUSE AUTOEXTEND ON MAXSIZE 2000 M; ALTER SYSTEM SET undo_tablespace = undotbs_02 SCOPE = SPFILE; SHUTDOWN IMMEDIATE; STARTUP; DROP TABLESPACE undotbs_01;

Weitere Informationen finden Sie in Abschnitt 2.6.13 „Verwaltung von Undo Tablespaces“.

2.6.8

Datafiles löschen

Der folgende Befehl löscht ein leeres Datafile eines permanenten Tablespace: ALTER TABLESPACE user_01 DROP DATAFILE '/opt/oracle/oradata/meineDB/user_01_09.dbf';

Für das Löschen eines Tempfiles wird die Klausel drop

tempfile

benötigt:

ALTER TABLESPACE temp_01 DROP TEMPFILE '/opt/oracle/oradata/meineDB/temp_01_05.dbf';

Folgende Restriktionen gelten: Die Datenbank muss geöffnet und das betreffende Datafile online gesetzt sein.  Data Files, die nicht leer sind, kann man nicht löschen.  Jeder Tablespace benötigt mindestens ein Datafile. Ist nur noch eines vorhanden, so  kann man dieses nicht löschen. Das Datafile eines Bigfile-Tablespace kann daher nicht entfernt werden. Datafiles des System-Tablespace lassen sich nicht löschen.  Datafiles eines Read-Only-Tablespace lassen sich nicht löschen. 

100

2.6 Verwaltung von Tablespaces

2.6.9

Default- und Temporary-Tablespace für Benutzer setzen

Der Standard-Tablespace eines Benutzers wird zur Speicherung von Datenbankobjekten wie Tabellen und Indizes verwendet, sofern bei deren Erstellung nicht explizit ein anderer Tablespace angegeben wurde. Folgender Befehl weist einem Benutzer einen StandardTablespace für die Speicherung zu: ALTER USER anton DEFAULT TABLESPACE users_05;

Die Zuweisung eines Temporary Tablespaces kann ebenfalls mit dem Befehl erfolgen:

alter user

ALTER USER anton TEMPORARY TABLESPACE temp;

Die View dba_users zeigt Informationen zum Default- bzw. Temporary Tablespace eines Benutzers an: SQL> SELECT FROM ORDER BY

username, default_tablespace, temporary_tablespace dba_users username;

USERNAME ------------------------ANONYMOUS APEX_PUBLIC_USER AN_XDT BP_USER DIP MDDATA …

DEFAULT_TABLESPACE ------------------------SYSAUX USERS AN_XDT_DATA BP_DATA USERS USERS

TEMPORARY_TABLESPACE --------------------TEMP TEMP AN_XDT_TEMP TEMP TEMP TEMP

Soll ein vom Standard abweichender Tablespace zur Speicherung genutzt werden, so wird dem Create-Befehl einfach die Tablespace-Klausel angehängt. Die folgende Tabelle wird beispielsweise im Tablespace app_data angelegt. CREATE table eine_test_tabelle ( spalte_1 NUMBER, spalte_2 VARCHAR2(20) ) TABLESPACE app_data;

Zuvor muss der angegebene Tablespace bereits bestehen und ein Administrator muss dem Benutzer Rechte (Quota) für diesen Tablespace erteilt haben. Zusätzlich muss ausreichend Platz für die Speicherung des Objekts im Tablespace vorhanden sein.

2.6.10 Offline- und Online-Setzen eines Tablespaces Wird ein Tablespace offline gesetzt, kann auf dessen Daten vorübergehend nicht zugegriffen werden. Dies ist häufig bei Wartungsarbeiten – wie beispielsweise beim Verschieben eines Datafiles – erforderlich. ALTER TABLESPACE user_data OFFLINE;

Temporary Tablespaces können nicht offline gesetzt werden. Für alle anderen TablespaceTypen gibt es folgende Modi:

101

2 Architektur und Administration Offline normal: Alle Datenblöcke werden aus der SGA in die Datafiles übertragen.  Um den Tablespace später wieder in Betrieb zu nehmen, ist kein Recovery erforderlich. Offline temporary: Ein Checkpoint für alle Online Datafiles des Tablespaces wird aus geführt. Es wird nicht sichergestellt, dass alle Datafiles beschrieben werden können. Datafiles, die zum Zeitpunkt der Ausführung des Statements offline waren, können bei Wieder-Inbetriebnahme des Tablespace ein Recovery erfordern. Offline immediate: Der Tablespace wird unmittelbar offline gesetzt. Bei Wieder-Inbe triebnahme des Tablespace ist ein Recovery der Datafiles erforderlich.

Der Standardmodus ist „normal“. ALTER TABLESPACE user_data offline NORMAL; ALTER TABLESPACE user_data offline TEMPORARY; ALTER TABLESPACE user_data offline IMMEDIATE;

Der folgende Befehl setzt den Tablespace online. Die Daten sind wieder zugreifbar: ALTER TABLESPACE user_data ONLINE;

Troubleshooting beim Online-Setzen Ein Online-Setzen nach einem offline temporary oder offline immediate kann zunächst fehlschlagen. Nach einem Recovery des betreffenden Datafiles kann man den Tablespace wieder in Betrieb nehmen. SQL> ALTER TABLESPACE users offline IMMEDIATE; Tablespace wurde geändert. SQL> ALTER TABLESPACE users ONLINE; alter tablespace users online * FEHLER in Zeile 1: ORA-01113: Für Datei '4' ist Media Recovery erforderlich ORA-01110: Datendatei 4: '/opt/oracle/oradata/meineDB/users_01.DBF' SQL> RECOVER DATAFILE 4; Media Recovery abgeschlossen. SQL> ALTER TABLESPACE users ONLINE; Tablespace wurde geändert.

2.6.11 Read-Only- und Read-Write-Setzen Die Daten eines Tablespaces lassen sich mit dem folgenden Befehl vor Schreibzugriffen schützen: ALTER TABLESPACE tbs_02 READ ONLY;

Achtung: Nur DML-Befehle werden unterbunden. DDL-Befehle sind teilweise weiterhin möglich. Es können keine neuen Objekte erstellt und keine Dateninhalte geändert werden. Dennoch sind Strukturänderungen möglich, solange dazu nicht auf den Tablespace zugegriffen wird. Dazu zählt auch das Löschen der Tabelle. Dies gelingt trotz Read-OnlyModus des Tablespaces. Ein Beispiel:

102

2.6 Verwaltung von Tablespaces SQL> CREATE TABLE eine_tabelle (eine_spalte NUMBER) 2 TABLESPACE users; Tabelle wurde erstellt.

Eine Tabelle wurde im Tablespace users erstellt. Die Tabelle wird nun im nächsten Schritt befüllt. Danach setzt man den Tablespace auf „read only”: SQL> BEGIN 2 FOR i IN 1..99 LOOP 3 INSERT INTO eine_tabelle values (i); 4 END LOOP; 5 COMMIT; 6 END; 7 / PL/SQL-Prozedur erfolgreich abgeschlossen. SQL> ALTER TABLESPACE users READ ONLY; Tablespace wurde geändert.

Insert-, Update- und Delete-Statements sind somit auf Objekte des Tablespaces nicht mehr möglich. Sie werden mit einer Fehlermeldung quittiert: SQL> INSERT INTO eine_tabelle VALUES (100); INSERT INTO eine_tabelle VALUES (100) FEHLER in Zeile 1: ORA-00372: Datei 4 kann zur Zeit nicht modifiziert werden ORA-01110: Datendatei 4: 'D:\APP\A\ORADATA\ORA11G\USERS01.DBF'

Doch Statements, die Strukturänderungen vornehmen, sind weiterhin möglich: SQL> ALTER TABLE eine_tabelle add (eine_zweite_spalte VARCHAR2(20)); Tabelle wurde geändert.

Zudem kann die Tabelle gelöscht werden: SQL> drop table eine_tabelle; Tabelle wurde gelöscht.

Hintergrund ist, dass Strukturänderungen im Data Dictionary der Datenbank gespeichert werden. Dessen Basistabellen liegen im System-Tablespace – und dieser ist ja nicht für Schreibzugriffe gesperrt. Ein unschöner Seiteneffekt! So kann eine Tabelle aus einem Read-Only Tablespace sogar gelöscht werden: SQL> DROP TABLE eine_tabelle; Tabelle wurde gelöscht.

2.6.12 Aktivieren und Deaktivieren des Logging für Tablespaces Das Schreiben in die Redologs benötigt Zeit und Systemressourcen. Gelegentlich ist es sinnvoll, das Mitschreiben von Änderungsinformationen in den Redologs zu unterdrücken. So gibt es Objekte, die nur temporär während eines Ladevorgangs befüllt und später nicht mehr benötigt werden. Deren Änderungslogs sind in manchen Fällen nicht erforderlich: Stürzt das Datenbanksystem ab, so kann der Ladevorgang möglicherweise einfach erneut gestartet werden. Ein Recovery mittels Redologs ist nicht nötig.

103

2 Architektur und Administration Die nologging-Klausel deaktiviert das Schreiben in Redologs, sofern nicht explizit für ein Objekt etwas anderes angegeben oder aber Force Logging für die Datenbank aktiviert wurde: ALTER TABLESPACE apps_tbs NOLOGGING;

Der folgende Befehl reaktiviert das Logging für den angegebenen Tablespace: ALTER TABLESPACE apps_tbs LOGGING;

Soll für einen Tablespace das Logging erzwungen werden, und zwar auch dann, wenn für Objekte explizit etwas anderes angegeben wurde, kann force logging genutzt werden: ALTER TABLESPACE apps_tbs FORCE LOGGING;

Dies ist bei Verwendung von Standby-Datenbanken und von Streams sinnvoll, da durch fehlende Log-Informationen auf dem Zweitsystem Dateninkonsistenzen und Korruptionen entstehen können.

2.6.13 Verwaltung von Undo Tablespaces Informationen zum Undo Tablespace im Data Dictionary Folgende Views zeigen Informationen rund um Undo Tablespaces an: View-Name

Beschreibung

V$PARAMETER

Zeigt die Parameter undo_management, undo_retention und undo_tablespace

V$UNDOSTAT

Statistiken für das Tuning von Undo Tablespaces

V$ROLLSTAT

Informationen zu Undo-Segementen im Undo Tablespace

V$TRANSACTION

Informationen zu offenen Transaktionen, die Undo-Segmente nutzen

DBA_HIST_UNDOSTAT

Enthält Schnappschüsse zu V$UNDOSTAT

Den Namen des Undo Tablespace zeigt die folgende Abfrage: SQL> SELECT name, value FROM v$parameter WHERE name like 'undo_tablespace';

Die Aufbewahrungszeit der Before Images im Undo Tablespace ermitteln Sie wie folgt: SQL> SELECT name, value FROM v$parameter WHERE name like 'undo_retention';

Die View v$undostat ist insbesondere für das Monitoring hilfreich. Sie zeigt Statistiken zur Nutzung des Undo Tablespaces an. Hier ein Beispiel: SELECT to_char(u.begin_time, 'dd.mm.yyyy hh24:mi') to_char(u.end_time, 'dd.mm.yyyy hh24:mi') t.name, u.undoblks, u.txncount, u.maxconcurrency u.maxquerylen FROM v$undostat u, v$tablespace t

104

AS AS AS AS

BEGIN_TIME, END_TIME, MAXCON, MAXLEN

2.6 Verwaltung von Tablespaces WHERE u.undotsn = t.ts# ORDER BY 1; BEGIN_TIME ---------------09.03.2010 13:16 09.03.2010 13:26 09.03.2010 13:36 09.03.2010 13:46 09.03.2010 13:56

END_TIME ---------------09.03.2010 13:26 09.03.2010 13:36 09.03.2010 13:46 09.03.2010 13:56 09.03.2010 14:06

NAME UNDOBLKS TXNCOUNT MAXCON MAXLEN ------ -------- -------- ------ ------UNDO02 3923 198 54 304 UNDO02 123 349 23 909 UNDO02 1120 5 212 308 UNDO02 4511 13 72 913 UNDO02 9247 49 63 315

Die Ausgabe zeigt folgende Informationen: begin_time und end_time: Angabe des Zeitraumes, der ausgewertet wurde  name: Name des Undo Tablespaces  undoblks: Anzahl genutzter Undo-Blöcke  txncount: Anzahl der Transaktionen während des Auswertungszeitraumes  maxconcurrency: Maximale Anzahl konkurrierender Transaktionen im Auswertungs zeitraum maxquerylen: Maximale Dauer in Sekunden, die eine Abfrage im Auswertungszeitraum  bearbeitet wurde. Diese Statistik kann gut dazu genutzt werden, den passenden Wert für den Parameter undo_retention zu ermitteln.

Die folgende Abfrage zeigt das am längsten laufende SQL-Statement während eines Auswertungszeitraumes. Sie können diese Abfrage sehr gut nutzen, um die passenden Einstellungen für den Parameter undo_retention zu ermitteln. SQL> SELECT to_char(u.begin_time, 'dd.mm.yyyy hh24:mi') AS BEGIN_TIME, to_char(u.end_time, 'dd.mm.yyyy hh24:mi') AS END_TIME, maxquerylen AS SEKUNDEN, sql_fulltext AS SQL_STATEMENT FROM v$undostat u , v$sqlarea a WHERE u.maxqueryid = a.sql_id;

Erstellung eines Undo Tablespaces Ein Undo Tablespace wird implizit während der Datenbankerstellung erzeugt: CREATE DATABASE myDB CONTROLFILE REUSE . . UNDO TABLESPACE undotbs_01 DATAFILE '/opt/ordata/myDB/undo01_01.dbf';

Der Befehl create undo tablespace erzeugt einen neuen Undo Tablespace. Im Regelfall ist dies nicht erforderlich. Wird jedoch eine Real Application Cluster-Datenbank eingesetzt, so benötigt jede Instanz einer Datenbank einen eigenen Undo Tablespace. In diesem Fall kann es notwendig sein, für neu hinzuzufügende Cluster-Nodes weitere Undo Tablespaces zu erstellen. Hier die Syntax: CREATE UNDO TABLESPACE undotbs_02 DATAFILE '/opt/ordata/myDB/undo02_01.dbf' SIZE 200M AUTOEXTEND ON MAXSIZE 2000 M;

105

2 Architektur und Administration Die Option autoextend on führt dazu, dass der Tablespace automatisch erweitert wird, und zwar bis zu der in der Klausel maxsize angegebenen Größe. Möchten Sie keine automatische Erweiterung für den Undo Tablespace nutzen, so kann der Tablespace ohne autoextend mit einer festen Größe erstellt werden: CREATE UNDO TABLESPACE undotbs_02 DATAFILE '/opt/ordata/myDB/undo02_01.dbf' SIZE 200M AUTOEXTEND OFF;

Die Größe eines manuell verwalteten Tablespace lässt sich bei Bedarf entweder durch einen resize-Befehl oder aber durch Anhängen weiterer Datafiles an den Undo Tablespace vergrößern: ALTER DATABASE DATAFILE '/opt/ordata/myDB/undo02_01.dbf' RESIZE 500M;

Hinzufügen eines weiteren Datafile zum Tablespace: ALTER TABLESPACE undotbs_02 ADD DATAFILE '/opt/ordata/myDB/undo02_02.dbf' SIZE 200 M;

Der Name des zu verwendenden Undo Tablespaces wird im Datenbankparameter undo_tablespace angegeben: ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_01 SCOPE=SPFILE;

Der Parameter undo_management gibt an, ob Undo-Informationen mit Automatic Undo Management (AUM), einer weitgehend automatisierten Verwaltung also, oder manuell mittels Rollbacksegmenten erfolgen soll. Letztere Methode wird heute kaum noch eingesetzt. ALTER SYSTEM SET UNDO_MANAGEMENT = AUTO SCOPE=SPFILE;

Die Instanz muss abschließend durchgestartet werden. Aufbewahrungszeit von Undo-Informationen Die Aufbewahrungszeit von before images wird mittels Parameter im Undo Tablespace eingestellt. Sie ist insbesondere dann wichtig, wenn langlaufende Abfragen nicht in den Fehler „ORA-01555 (snapshot too old)“ laufen sollen oder aber Flashback Query über einen garantierten Zeitraum möglich sein soll. Hintergrund ist, dass nach einem Commit einer Transaktion die zugehörigen Undo-Bereiche zum Überschreiben freigegeben werden. Falls ein Select-Statement diese Informationen für einen konsistenten Lesevorgang benötigt oder aber ein Flashback Query über diesen Zeitraum ausgeführt werden soll, stehen diese dann eventuell nicht mehr zur Verfügung. Oracle optimiert die Aufbewahrungszeit der before images in Abhängigkeit zur Größe des Undo Tablespaces und zur Transaktionslast der Datenbank. Optional kann man jedoch auch mit dem Parameter undo_retention die Aufbewahrungszeit in Sekunden angeben. Der Standardwert liegt bei 900 Sekunden (15 Minuten). Um die Aufbewahrungszeit anzupassen, setzen Sie den Parameter auf den erforderlichen Wert:

106

2.6 Verwaltung von Tablespaces ALTER SYSTEM SET UNDO_RETENTION = 2400;

Bei einem Undo Tablespace mit fester Größe wird dieser Parameter ignoriert. Wurde die automatische Erweiterung des Undo Tablespaces aktiviert, bewirkt der Parameter undo_ retention, dass der Tablespace im Bedarfsfall erweitert wird, um die Aufbewahrungszeit zu gewährleisten48. Ist die konfigurierte Maximalgröße erreicht, so beginnt Oracle, ältere Undo-Informationen zu überschreiben, auch wenn deren Alter unterhalb der „retention time“ liegt. Optional kann eine Garantie für die Aufbewahrungszeit konfiguriert werden. Dies hat jedoch Nachteile: Ist der Undo Tablespace nicht ausreichend groß dimensioniert, so können keine Änderungen mehr ausgeführt werden, sofern der Undo Tablespace mit Undo-Informationen gefüllt ist, deren Aufbewahrungszeit noch nicht überschritten ist. Daher ist diese Option mit Bedacht zu wählen. Die Garantie der Aufbewahrungszeit wird wie folgt aktiviert: ALTER TABLESPACE undotbs_01 RETENTION GUARANTEE;

Diese Einstellung können Sie über die View dba_tablespaces überpüfen: SELECT tablespace_name, retention FROM dba_tablespaces; TABLESPACE_NAME -----------------------------SYSTEM SYSAUX TEMP USERS EXAMPLE FLASHBACK_T101 UNDOTBS_02

RETENTION ----------NOT APPLY NOT APPLY NOT APPLY NOT APPLY NOT APPLY NOT APPLY GUARANTEE

Sizing der Aufbewahrungszeit im Undo Tablespace Um in den Standard-Modus ohne Garantie zurück zu wechseln, verwenden Sie die folgende Syntax: ALTER TABLESPACE undotbs_01 RETENTION NOGUARANTEE;

Die folgende Abfrage zeigt das am längsten laufende SQL-Statement während eines Auswertungszeitraumes. Sie können diese Abfrage sehr gut nutzen, um den passenden Wert für den Parameter undo_retention festzulegen: SQL> SELECT to_char(u.begin_time, 'dd.mm.yyyy hh24:mi') AS BEGIN_TIME, to_char(u.end_time, 'dd.mm.yyyy hh24:mi') AS END_TIME, maxquerylen AS SEKUNDEN, sql_fulltext AS SQL_STATEMENT FROM v$undostat u , v$sqlarea a WHERE u.maxqueryid = a.sql_id;

48

Datenbanken, die mit dem Database Configuration Assistant (DBCA) erstellt wurden, erhalten zunächst einen Undo Tablespace mit der Einstellung autoextend

107

2 Architektur und Administration Manuelles Sizing der Größe des Undo Tablespace Um eine geeignete Größe des Undo Tablespaces schätzen zu können, sind drei Parameter notwendig: Der Wert des Datenbankparameters undo_retention: Er bestimmt die Aufbewahrungs zeit der before images im Undo Tablespace und sollte mindestens den Zeitraum der am längsten laufenden Abfragen Ihres Systems umfassen. Der Parameter gibt die Anzahl der Sekunden an, die before images im Undo Tablespace aufzubewahren sind. Die Anzahl an Undo-Blöcken, die pro Sekunde generiert werden.  Der Overhead, der abhänging von der Blockgröße ist.  Die Größe des Undo Tablespace berechnet sich dann wie folgt: SUndo-TS = (UR * UPS * DBS) + (DBS * 24) mit UR: Wert des Parameters undo_retention  DBS: Wert des Parameter db_block_size  UPS: Anzahl der Undo-Blöcke per Sekunde, die über die View v$undostat ermittelbar  ist. Die folgende Abfrage gibt die Anzahl an Undo-Blöcken pro Sekunde (UPS) zurück: SQL> SELECT (SUM(undoblks))/ SUM ((end_time - begin_time) * 86400) FROM v$undostat;

Die Spalten begin_time und end_time werden intern im Datentyp Date gespeichert. Deren Subtraktion ergibt eine Differenz in Tagen. Um diesen Wert in Sekunden zu konvertieren, wird er mit 86400 – der Anzahl an Sekunden pro Tag – multipliziert. Das Ergebnis der Abfrage liefert die Anzahl an Undo-Blöcken pro Sekunde. Folgende Abfrage errechnet die Größe in MB, die für den Undo Tablespace erforderlich sind, sofern die Last des Systems in etwa der bisherigen Last entspricht: SQL> SELECT round((UR * (UPS * DBS)) + (DBS * 24) AS "Bytes" FROM ( SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'), ( SELECT (SUM(undoblks) / SUM(((end_time - begin_time)*86400)))/1024/1024) AS UPS FROM v$undostat), ( SELECT block_size AS DBS FROM dba_tablespaces WHERE tablespace_name= (SELECT value FROM v$parameter WHERE name = 'undo_tablespace'));

Möchten Sie die Undo-Retention ändern, so können Sie obige Frage anpassen. Dazu geben Sie einen festen Wert für UR an. Ist Ihr System noch nicht produktiv und können Sie die Menge an anfallenden Undo Tablespace auch nicht über Schätzungen bestimmen, gehen Sie wie folgt vor: Erstellen Sie den Undo Tablespace mit mehreren Datafiles in einer Initialgröße von 100  MB.

108

2.6 Verwaltung von Tablespaces Setzen Sie alle Datafiles auf „autoextend“, sodass diese automatisch erweitert werden.  Setzen Sie eine Extent-Größe von ebenfalls 100 MB für die automatische Erweiterung. Legen Sie eine Maximal-Größe für die Datafiles fest. Achten Sie dabei insbesondere auf  Größen-Limitierungen von Seiten des Betriebssystems sowie aller Werkzeuge, die sie im Zusammenhang mit Datafiles verwenden. So kann beispielsweise ein Samba-Share, auf den Sie Ihre Datensicherung durchführen, möglicherweise nicht mehr als 2 GB große Dateien verwalten. Achten Sie bei der Größen-Limitierung auf alle Schnittstellen. Angenommen, Sie legen den Undo Tablespace mit fünf Datafiles in einer Initialgröße von 100 MB an und begrenzen die Maximalgröße auf 2 GB. Sie belegen so initial 500 MB für den Undo Tablespace und ermöglichen ein Wachstum bis maximal 10 GB. Auf diese Weise erreichen Sie ein recht hohes Maß an Flexibilität. Ein Beispiel: SQL> CREATE UNDO TABLESPACE undotbs_01 DATAFILE '/opt/oradata/myDB/undo_01_01.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M '/opt/oradata/myDB/undo_01_02.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M '/opt/oradata/myDB/undo_01_03.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M '/opt/oradata/myDB/undo_01_04.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M '/opt/oradata/myDB/undo_01_05.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M

MAXSIZE 2000 M, MAXSIZE 2000 M, MAXSIZE 2000 M, MAXSIZE 2000 M, MAXSIZE 2000 M;

Undo Advisor Undo Tablespaces mit einer festen Größe erfordern ein passendes Sizing. Der Undo Advisor unterstützt bei einer näherungsweisen Abschätzung des Platzbedarfs. Er kann sowohl über die Oberfläche des Enterprise Managers als auch über eine PL/SQL-API genutzt werden. Für die Abschätzung nutzt der Undo Advisor die Daten des Automatic Workload Repository (AWR)49. Daher ist es wichtig, dass im AWR aktuelle und realitätsnahe Statistiken vorliegen. Bei einer neu erstellten Datenbank können die Statistiken zunächst noch unzureichend sein. Hier kann zunächst mit einem Undo Tablespace im Autoextend-Modus50 gearbeitet und nach einiger Laufzeit der Datenbankinstanz das Sizing durchgeführt werden. Für die Nutzung des Undo Advisors benötigen Sie eine Abschätzung der Antwortzeit der am längsten laufenden Abfrage. Dies können Sie beispielsweise im Enterprise Manager auf der Unterseite zur Systemaktivität ermitteln. Ein zweiter Aspekt ist die Vorhaltezeit der before images für Oracle Flashback. Möchten Sie beispielsweise mit Flashback Query stets die Änderungshistorie der letzten 48 Stunden einsehen können, so ist dies die Maßgabe für die Aufbewahrungszeit der before images. Den Undo Advisor können Sie entweder im Enterprise Manager auf der Seite Automatic Undo Management oder aber über PL/SQL aufrufen. Für den Aufruf mit PL/SQL müssen 49 50

Die Nutzung des AWR ist i.A. lizenzkostenpflichtig. Setzen Sie in diesem Fall unbedingt ein Limit für die Größenbegrenzung

109

2 Architektur und Administration für Start und Ende die entsprechenden Snap-IDs des Automatic Workload Repository angegeben werden. Dazu ein Beispiel: DECLARE tid NUMBER; tname VARCHAR2(30); oid NUMBER; BEGIN DBMS_ADVISOR.CREATE_TASK ('Undo Advisor', tid, tname, 'Undo Advisor Task'); DBMS_ADVISOR.CREATE_OBJECT (tname, 'UNDO_TBS', null, null, null, 'null', oid); DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS', oid); DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', 200); DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', 210); DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'INSTANCE', 1); DBMS_ADVISOR.execute_task(tname); END; /

Die Ergebnisse werden über den Automatic Database Diagnostic Monitor (ADDM) des Enterprise Managers angezeigt. Alternativ kann man auch einige Views des Advisory Frameworks nutzen: DBA_ADVISOR_TASKS, DBA_ADVISOR_OBJECTS und DBA_ADVISOR_ FINDINGS. Der Undo Advisor liefert nur eine Abschätzung der erforderlichen Größe des Undo Tablespacces. Er ändert jedoch die Größe nicht. Die Größenänderungen müssen Sie selbst mit einem Alter Database-Befehl durchführen: ALTER DATABASE DATAFILE '/opt/oradata/myDB/undotbs_01.dbf' RESIZE 1200M;

Entfernen eines Undo Tablespaces Ein Undo Tablespace kann mit dem Befehl drop

tablespace

gelöscht werden.

DROP TABLESPACE undotbs_01;

Ein aktiver Undo Tablespace kann jedoch nicht gelöscht werden. In diesem Fall ist ein neuer Undo Tablespace zu erstellen und der Parameter undo_tablespace auf den neu erstellten Tablespace umzustellen. Nach einem Neustart der Datenbankinstanz wird der neue Undo Tablespace genutzt, der alte lässt sich nun löschen. CREATE UNDO TABLESPACE undotbs_02 DATAFILE '/opt/ordata/myDB/undo02_01.dbf' SIZE 200M REUSE AUTOEXTEND ON MAXSIZE 2000 M; ALTER SYSTEM SET undo_tablespace = undotbs_02 SCOPE = SPFILE; SHUTDOWN IMMEDIATE; STARTUP; DROP TABLESPACE undotbs_01;

110

2.6 Verwaltung von Tablespaces Informationen zu Undo Tablespaces Folgende Views zeigen Informationen rund um Undo Tablespaces an: View-Name

Beschreibung

V$UNDOSTAT

Statistiken für das Tuning von Undo Tablespaces

V$ROLLSTAT

Informationen zu Undo-Segementen im Undo Tablespace

V$TRANSACTION

Informationen zu offenen Transaktionen, die Undo-Segmente nutzen

DBA_HIST_UNDOSTAT

Enthält Schnappschüsse zu V$UNDOSTAT

Die View v$undostat ist insbesondere für das Monitoring hilfreich. Sie zeigt Statistiken zur Nutzung des Undo Tablespaces an. Dazu ein Beispiel: SELECT to_char(begin_time, 'dd.mm.yyyy hh24:mi:ss') to_char(end_time, 'dd.mm.yyyy hh24:mi:ss') undotsn, undoblks, txncount, maxconcurrency FROM v$UNDOSTAT WHERE rownum <= 100; BEGIN_TIME ------------------14.07.2009 15:53:09 14.07.2009 15:43:09 14.07.2009 15:33:09 14.07.2009 15:23:09

AS BEGIN_TIME, AS END_TIME, AS MAXCON

END_TIME UNDOTSN UNDOBLKS TXNCOUNT MAXCON ------------------- ------- -------- -------- ------14.07.2009 15:55:21 8 2 12 1 14.07.2009 15:53:09 8 8 91 3 14.07.2009 15:43:09 8 72 490 3 14.07.2009 15:33:09 8 13 84 2

2.6.14 Verwaltung von Temporary Tablespaces Informationen zu Temporary Tablespaces aus dem Data Dictionary Die View dba_tablespaces zeigt Informationen zu Temporary Tablespaces an: SELECT * FROM dba_tablespaces WHERE contents = 'TEMPORARY';

Welche Dateien zu Temporary Tablespaces existieren, können Sie der View entnehmen:

dba_temp_

files

SELECT tablespace_name, file_name, status, round(bytes /1024 /1024) "SIZE MB", autoextensible, round(maxbytes /1024 /1024) "MAXSIZE MB", increment_by FROM dba_temp_files;

Temporary Tablespace erstellen Sollte kein Default Tempoary Tablespace bestehen, so können Sie ihn mit folgendem Befehl erstellen: CREATE TEMPORARY TABLESPACE temp_02 TEMPFILE '/opt/oradata/myDB/temp_02_01.dbf' SIZE 800 M;

Sizing des Temporary Tablespace Im Temp-Tablespace werden primär temporäre Daten für Sortieroperationen der Benutzerprozesse ausgelagert sowie Daten temporärer Dateien gespeichert. Die für den TempTablespace erforderliche Größe hängt daher wesentlich von SQL-Statements der Anwen-

111

2 Architektur und Administration dungen ab, die mit Ihrer Datenbank betrieben werden. Sofern es keine Erfahrungswerte für Ihre Anwendungen gibt, gehen Sie wie folgt vor: Erstellen Sie den Temp-Tablespace mit mehreren Tempfiles in einer Initialgröße von  100 MB. Setzen Sie alle Tempfiles auf autoextend, sodass diese automatisch erweitert werden.  Setzen Sie eine Extent-Größe von ebenfalls 100 MB für die automatische Erweiterung. Legen Sie unbedingt eine Maximal-Größe für die Tempfiles fest! Der Temp-Table space bzw. dessen Tempfiles wachsen sonst unbegrenzt. Angenommen, Sie legen den Temp-Tablespace mit fünf Tempfiles in einer Initialgröße von 100 MB an und begrenzen die Maximalgröße auf 1 GB. Sie belegen so initial 500 MB für den Temp-Tablespace und ermöglichen ein Wachstum bis maximal 5 GB. Auf diese Weise erreichen Sie ein recht hohes Maß an Flexibilität. Ein Beispiel: SQL> CREATE TEMPORARY TABLESPACE temptbs_01 TEMPFILE '/opt/oradata/myDB/temp_01_01.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M '/opt/oradata/myDB/temp_01_02.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M '/opt/oradata/myDB/temp_01_03.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M '/opt/oradata/myDB/temp_01_04.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M '/opt/oradata/myDB/temp_01_05.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M

MAXSIZE 1000 M, MAXSIZE 1000 M, MAXSIZE 1000 M, MAXSIZE 1000 M, MAXSIZE 1000 M;

Temporary Tablespace an Benutzer zuweisen Welcher Temporary Tablespace als Default verwendet wird, können Sie mit folgendem Statement prüfen: SELECT PROPERTY_NAME, PROPERTY_VALUE FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME='DEFAULT_TEMP_TABLESPACE'; ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_02;

Benutzer, die einen davon abweichenden Temporary Tablespace nutzen sollen, können darauf umgestellt werden: ALTER

USER scott TEMPORARY TABLESPACE temp_02;

Die Einstellung können Sie mit folgendem Statement überprüfen: SELECT username, temporary_tablespace FROM dba_users ORDER BY username;

Vergrößern und verkleinern eines Temporary Tablespaces Um einen Temporary Tablespace zu vergrößern, können Sie eine der folgenden Optionen wählen: Ein bestehendes Tempfile vergrößern  Ein weiteres Tempfile anhängen  Autoextend aktivieren 

112

2.7 Verwaltung von Redologs Sofern Sie die automatische Erweiterung wählen, raten wir dringend, eine Maximalgröße anzugeben! Um die Größe eines Tempfiles zu ändern, können Sie wie folgt vorgehen: ALTER DATABASE TEMPFILE '/opt/oradata/myDB/temp_02_01.dbf' RESIZE 220 M

Der folgende Befehl legt ein weiteres Tempfile für einen bestehenden Temporary Tablespace an: ALTER TABLESPACE temp_02 ADD TEMPFILE '/opt/oradata/myDB/temp_02_02dbf' SIZE 200 M;

Der folgende Befehl aktiviert die automatische Dateierweiterung und setzt eine Maximalgröße: ALTER DATABASE TEMPFILE 'c:\temp\2.dbf' AUTOEXTEND ON NEXT 100 M MAXSIZE 1000 M;

Löschen eines Temporary Tablespaces Der folgende Befehl löscht einen Temporary Tablespace: DROP TEMPORARY TABLESPACE temp_01 ;

Löschen von Tempfiles Für das Löschen eines Tempfiles wird die Klausel drop

tempfile

benötigt:

ALTER TABLESPACE temp_01 DROP TEMPFILE '/opt/oracle/oradata/meineDB/temp_01_05.dbf';

Umbenennen und Verschieben von Tempfiles Ein Tempfile lässt sich nicht mit einem rename umbenennen oder verschieben. Fügen Sie stattdessen dem Tablespace ein neues Tempfile mit dem neuen Pfad- und Dateinamen an und löschen Sie die alte Temp-Datei: ALTER TABLESPACE temp ADD TEMPFILE '/opt/oradata/ora11g/TEMP01.DBF' SIZE 200 M; ALTER TABLESPACE temp drop TEMPFILE '/alterPfad/TEMP_01.DBF';

2.7

Verwaltung von Redologs Der Logwriter-Prozess schreibt Redo Records in die Redologs. Diese bestehen aus einer Gruppe von Change-Vektoren, von denen jeder einzelne die Änderung eines Datenblocks beschreibt. Wird ein Datensatz geändert, so enthält der zugehörige Change-Vektor die Änderungen des Blocks des Datensegments der Tabelle, die Änderungen des Undo-Segments sowie der Transaktionstabelle des Undo-Segments. Jeder Änderung wird eine Sys-

113

2 Architektur und Administration tem Change Number (SCN) zugeordnet. Zusätzlich wird der Zeitstempel vermerkt sowie die ID der Transaktion, zu der die Änderung gehört.

2.7.1

Informationen zu Redologs aus dem Data Dictionary ermitteln

Die View v$log gibt Auskunft darüber, welche Redolog-Gruppen existieren, wie groß die Dateien der Redolog-Gruppe sind, über wie viele Spiegel (Member) eine Redolog-Gruppe verfügt und ob die Redolog-Gruppe gerade beschrieben wird oder nicht: SQL> SELECT group#, sequence#, bytes, members, status, archived FROM v$log; GROUP# SEQUENCE# BYTES MEMBERS STATUS ------ --------- -------- -------- --------1 3865 52428800 2 INACTIVE 2 3866 52428800 2 ACTIVE 3 3867 52428800 2 CURRENT 4 3865 52428800 2 INACTIVE 5 3865 52428800 2 INACTIVE

ARCHIVED ------------YES YES NO YES YES

Die Dateinamen der einzelnen Mitglieder einer Gruppe können Sie der View entnehmen:

v$logfile

SQL> SELECT group#, member FROM v$logfile; GROUP# ---------1 1 2 2 3 3 4 4 5 5

MEMBER ---------------------------------------/data/oracle/ora11g/redo_g01_01.log /data/oracle/ora11g/redo_g01_02.log /data/oracle/ora11g/redo_g02_01.log /data/oracle/ora11g/redo_g02_02.log /data/oracle/ora11g/redo_g03_01.log /data/oracle/ora11g/redo_g03_02.log /data/oracle/ora11g/redo_g04_01.log /data/oracle/ora11g/redo_g04_02.log /data/oracle/ora11g/redo_g05_01.log /data/oracle/ora11g/redo_g05_02.log

Eine Verknüpfung über die Spalte group# verbindet die Informationen beider Views miteinander: SQL> SELECT l.group#, f.member, l.status, l.archived FROM v$log l, v$logfile f WHERE l.group# = f.group#;

Die Group Number ist für Member einer gemeinsamen Redolog-Gruppe gleich.

2.7.2

Redolog-Historie

Bei jedem Log Switch vergibt der Datenbankserver eine neue Log Sequence Number, die innerhalb einer Datenbankinkarnation eindeutig ist. Die aktuell verwendete Log Sequence Number einer Redo Log Gruppe ist in der View v$log zu finden. Die View v$log_ history gibt Auskunft über die Log-Historie inklusive der Log Sequence Number, des Zeitraums und der System Change Numbers:

114

2.7 Verwaltung von Redologs SELECT FROM WHERE ORDER BY

thread#, sequence#, first_change# AS first_scn, first_time v$log_history first_time > trunc(sysdate) first_time;

Die View v$archived_log liefert Informationen zu archivierten Redologs: SELECT

FROM WHERE ORDER BY

2.7.3

thread#, sequence#, first_change# AS scn, first_time, next_change# as next_scn, next_time, archived, applied, deleted, status v$archived_log first_time > trunc(sysdate) first_time;

Empfehlungen zur Konfiguration von Redologs

Anzahl der Redolog-Gruppen Eine Oracle-Datenbank benötigt mindestens zwei Redolog-Gruppen, zwischen denen umgeschaltet werden kann. Die meisten Produktionssysteme werden jedoch mit mehr Redolog-Gruppen konfiguriert. Bei einer Datenbank im Archivelog-Modus lässt sich ein Redolog erst dann überschreiben, wenn es zuvor erfolgreich archiviert (vom Archiver-Prozess in das Archivierungsziel kopiert) wurde. Geschieht dies – beispielsweise bei hoher Transaktionslast – nicht schnell genug, so entsteht ein Wartezustand in der Datenbank, der auch „Archiver Stuck“ heißt. Werden mehr Redolog-Gruppen verwendet, so bleibt dem Archivierungsprozess mehr Zeit für die Archivierung, bis wieder auf ein bereits verwendetes Redolog zurückgegriffen wird. Typische Konfigurationen enthalten fünf bis acht RedologGruppen. Größe der Redologs Ist eine Redolog-Gruppe vollständig beschrieben, wird auf die nächste umgeschaltet. Dieses Umschalten ist mit einem Checkpoint verbunden, der dazu führt, dass alle geänderten Blöcke im Blockpuffer in die Datafiles geschrieben werden. Bei einer sehr großen SGA (siehe Abschnitt 2.3.1 „System Global Area (SGA)“) und einer hohen Transaktionsrate kann dies zu einer recht hohen Systemlast führen. Werden weniger Checkpoints ausgelöst, so entlastet dies das System. Größere Redologs mindern die Checkpoint-Rate. Dafür verlängert sich die mittlere Zeitdauer, die für einen Wiederanlauf im Fehlerfall erforderlich ist: Seltenere Checkpoints erfordern im Mittel mehr Abgleiche mit den Redologs, um die Datenbank nach einem Abbruch wieder in einen konsistenten Zustand zu bringen. Hier kann jedoch mit dem Parameter fast_start_mttr_target nachgesteuert werden. Doch die Verlängerung des Wiederanlaufes ist auch ohne diesen Parameter meist in einem völlig unkritischen Bereich von nur wenigen Minuten. Ein zweiter sehr viel kritischerer Punkt ist, dass bei einem Verlust eines größeren Online Redologs der Verlust an Transaktionsinformationen weit höher sein kann als bei kleineren Logs. Jedoch kann man mit Oracle-Bordmitteln die Redologs in Gruppen spiegeln, sodass das Risiko des Verlustes erheblich minimiert wird.

115

2 Architektur und Administration Praxistipp Redologs sehr kleiner, transaktionsarmer Systeme können mit einer Größe von 50 MB auskommen. Typische Datenbanksysteme weisen heute jedoch Redolog-Größen von 100 bis 250 MB auf. Transaktionslastige Systeme können durchaus auch mit Redologs in der Größe von 500 MB und mehr konfiguriert werden.

Redolog-Spiegel in einer Redolog-Gruppe weisen stets die gleiche Größe auf. RedologGruppen können jedoch in ihrer Größe voneinander abweichend sein. Davon ist jedoch abzuraten: Redolog-Gruppen sollten im Normalbetrieb eine einheitliche Größe aufweisen. Nur bei Wartungsarbeiten (wie beispielsweise einer Größenänderung) ist vorübergehend eine abweichende Größe akzeptabel. Spiegelung in Redolog-Gruppen Crasht die Datenbank, so sind die Online Redologs erforderlich, um die Datenbank wieder in einen konsistenten Zustand zu bringen. Sie sind enorm wichtig, um im Fehlerfall keinen Transaktionsverlust zu erleiden. Es empfiehlt sich daher, die Redologs zu spiegeln. Dies kann mit Oracle-Bordmitteln geschehen. Dazu werden einfach für jede RedologGruppe zwei (oder mehr) Redologs konfiguriert. Man bezeichnet diese auch als Member einer Gruppe. Die Member einer Gruppe werden parallel beschrieben. Fällt nun ein Speichergerät aus, so kann die Oracle-Datenbank solange weiterbetrieben werden, solange noch mindestens ein Mitglied der Redolog-Gruppe beschrieben werden kann. Dies erhöht die Ausfallsicherheit ungemein. Ein Beispiel zum Anlegen von drei Redolog-Gruppen mit je zwei gespiegelten Log-Dateien: SQL> ALTER DATABASE ADD LOGFILE GROUP 6 ('/odbfs01/oracle/oradata/ora11g/log_g06_01.rdo', '/odbfs02/oracle/oradata/ora11g log_g06_02.rdo') SIZE 200 M; SQL> ALTER DATABASE ADD LOGFILE GROUP 7 ('/odbfs01/oracle/oradata/ora11g log_07_01.rdo', '/odbfs02/oracle/oradata/ora11g log_07_02.rdo') SIZE 200 M; SQL> ALTER DATABASE ADD LOGFILE GROUP 8 ('/odbfs01/oracle/oradata/ora11g/log_08_01.rdo', '/odbfs02/oracle/oradata/ora11g/log_08_02.rdo') SIZE 200 M;

Speicherorte für Redologs Wird eine Transaktion mit einem Commit in der Datenbank festgeschrieben, so bestätigt die Datenbank die Festschreibung stets erst dann, wenn alle Änderungen in die Redologs geschrieben sind. Bei hoher Transaktionslast sind daher die Redologs Performance-kritisch: Kann nicht schnell genug geschrieben werden, entstehen Wartezustände, die den Durchsatz erheblich bremsen. Um dies zu vermeiden, empfiehlt es sich, Redologs stets auf schnelle Platten zu legen. Hier sollte auch über Stripping nachgedacht werden. RAID-5Systeme sind für hohe Transaktionslasten oft weniger geeignet: Aufgrund der Checksummenberechnung beim Schreiben entsteht ein Performanceverlust. RAID 10 hingegen ist für Redologs eine gute, wenn auch etwas teurere Wahl.

116

2.7 Verwaltung von Redologs Praxistipp Die Last des Storage-Subsystems sollte durch I/O anderer Prozesse nicht allzu hoch sein, um die Performance beim Schreiben der Logs nicht unnötig zu bremsen. Die Separierung auf eigene Platten abseits der Ablage von Datafiles empfiehlt sich ohnehin. Redologs dienen schließlich bei einem Plattencrash der Wiederherstellung.

2.7.4

Anlegen einer Redolog-Gruppe

Der Befehl alter

database add logfile

erstellt eine neue Redolog-Gruppe:

SQL> ALTER DATABASE ADD LOGFILE GROUP 8 ('/odbfs01/oracle/ora11g/log_g08_01.rdo', '/odbfs02/oracle/ora11g/log_g08_02.rdo', '/odbfs03/oracle/ora11g/log_g08_03.rdo') SIZE 200 M;

Möchten Sie eine Redolog-Gruppe mit nur einem Mitglied erstellen, so geben Sie nur einen Pfad- und Dateinamen an: SQL> ALTER DATABASE ADD LOGFILE GROUP 8 ('/odbfs01/oracle/ora11g/log_g08.rdo') SIZE 200M;

2.7.5

Hinzufügen eines weiteren Mitglieds zu einer bestehenden Gruppe

Der folgende Befehl fügt einer Redolog-Gruppe einen weiteren gespiegelten Member hinzu: SQL> ALTER DATABASES ADD LOGFILE GROUP 8 '/odbfs01/oracle/ora11g/log_g08_02.rdo';

Praxistipp Es empfiehlt sich für Produktionssysteme, jede Redolog-Gruppe mit zwei Logdateien auszustatten. Diese werden parallel beschrieben und gewährleisten so ein höheres Maß an Sicherheit. Einige Sicherheitsfanatiker nutzen auch drei gespiegelte Logdateien je Gruppe. Liegen diese auf unterschiedlichen Devices, minimiert dies die Wahrscheinlichkeit, dass die komplette RedologGruppe ausfällt.

2.7.6

Löschen eines Mitglieds einer Redolog-Gruppe

Der Befehl alter Redolog-Gruppe:

database drop logfile member

entfernt ein einzelnes Mitglied einer

SQL> ALTER DATABASE DROP LOGFILE MEMBER '/odbfs01/oracle/ora11g/log_g08_03.dbf';

Der Eintrag der Redolog-Datei wird damit aus der Kontrolldatei entfernt. Außer bei Verwendung von Oracle Managed Files, die automatisch von Oracle verwaltet werden, bleibt

117

2 Architektur und Administration die Redolog-Datei jedoch im Betriebssystem bestehen und ist mit Betriebssystembefehlen zu löschen.

2.7.7

Löschen einer Redolog-Gruppe

Eine bestehende Redolog-Gruppe lässt sich im laufenden Betrieb mit folgendem Befehl entfernen: SQL> ALTER DATABASE DROP LOGFILE GROUP 5;

Dazu ist jedoch erforderlich, dass die Redolog-Gruppe nicht gerade aktuell beschrieben wird. Dies können Sie als Datenbank-Administrator mit folgender Abfrage ermitteln: SQL> SELECT group#, status FROM v$log; GROUP# ---------1 2 3 4 5

STATUS ---------------INACTIVE ACTIVE CURRENT INACTIVE INACTIVE

Der Status current gibt an, dass die Redolog-Gruppe aktuell genutzt wird. Der Status active erscheint, wenn noch nicht alle Datenänderungen, die in der betreffenden RedologGruppe verzeichnet sind, auch in die Datafiles übertragen wurden. Die Redolog-Gruppe wird dann im Falle eines Systemabsturzes für ein Crash Recovery benötigt. Gruppen, die „current“ oder „active“ sind, können daher nicht entfernt werden. Eine Oracle-Datenbank benötigt stets mindestens zwei Redolog-Gruppen. Beim Versuch, eine der letzten zwei Gruppen zu löschen, gibt Oracle die Fehlermeldung ORA-01567 aus. Praxistipp Außer bei Oracle Managed Files führt das Löschen einer Redolog-Gruppe dazu, dass der Eintrag aus den Kontrolldateien entfernt wird. Im Betriebssystem bleiben die Dateien weiter bestehen. Sie müssen daher anschließend mit einem Betriebssystembefehl explizit gelöscht werden.

2.7.8

Wechseln der Redolog-Gruppe

Im Bedarfsfall können Sie die Redolog-Gruppe auch gezielt wechseln: SQL> ALTER SYSTEM SWITCH LOGFILE;

Der Log-Writer-Prozess gibt dann die aktuelle Redolog-Gruppe frei und beginnt die nächste zu beschreiben. Der Status wechselt dann von „current“ auf „active“. Möchten Sie die Redolog-Gruppe löschen, so muss der Status auf „inactive“ gesetzt sein. Dies können Sie erreichen, indem Sie nach dem Wechsel der Redolog-Gruppe zusätzlich einen Checkpoint mit folgendem Befehl erzwingen: SQL> ALTER SYSTEM CHECKPOINT;

118

2.7 Verwaltung von Redologs

2.7.9

Verschieben und Umbenennen von Redologs

Der trivialste Weg, Redologs zu verschieben oder umzubenennen ist, zunächst eine neue Logdatei anzulegen und anschließend die alte zu löschen: SQL> ALTER DATABASES ADD LOGFILE GROUP 8 '/neuer_pfad/log_g08_03.rdo'; SQL> ALTER DATABASE DROP LOGFILE MEMBER '/alter_pfad/log_g08_03.dbf';

Der erste Befehl legt ein neues Redolog für die Gruppe im neuen Pfad an, der zweite entfernt den Eintrag des alten Redologs aus dem Controlfile. Achtung: Sie müssen anschließend die Datei noch im Betriebssystem entfernen, da der Befehl drop logfile member die bestehende Datei nicht aus dem Dateisystem entfernt. Eine zweite Möglichkeit besteht darin, die Redolog-Datei im Dateisystem zu verschieben und anschließend mit dem folgenden Befehl den neuen Pfad und Dateinamen der Datenbank bekannt zu machen: SQL> ALTER DATABASES RENAME FILE '/alter_pfad/log_g08_03.dbf' TO '/neuer_pfad/log_g08_03.dbf';

Dies ist jedoch nur dann möglich, wenn die Redolog-Gruppe weder im Status „current“ noch im Status „active“ ist. Andernfalls gibt der Datenbankserver eine Fehlermeldung zurück. Um eine aktive Redolog-Gruppe in den Status „inactive“ zu überführen, kann man zunächst ein Logswitch und anschließend ein Checkpoint ausführen: SQL> ALTER SYSTEM SWITCH LOGFILE; SQL> ALTER SYSTEM CHECKPOINT;

2.7.10 Logfiles bereinigen Das folgende Statement reinitialisiert ein Logfile. Dies kann erforderlich sein, wenn ein Logfile korrupt ist. ALTER DATABASE CLEAR LOGFILE

'/odbfs01/oracle/ora11g/log_g08_03.dbf';

Der folgende Befehl reinitialisiert jeden Member einer Logfile Group: ALTER DATABASE CLEAR LOGFILE GROUP 4;

Der Status des Logs wechselt bei beiden Statements nach der Initialisierung auf „unused“ – gerade so, als sei es soeben neu erstellt worden.

119

2 Architektur und Administration

2.7.11 Redologs für Real Application Clusters (RAC) In Umgebungen, die Real Application Clusters nutzen, benötigt jede Instanz einer Datenbank eigene Redolog-Gruppen, die exklusiv genutzt, jedoch von allen Clusterknoten aus lesbar sind. Das Schlüsselwort thread gibt an, welche Cluster-Instanz die Redolog-Gruppe nutzen soll: SQL> ALTER DATABASE ADD LOGFILE THREAD 2 GROUP 8 ('/odbfs01/oracle/ora11g/log_g08_01.rdo', '/odbfs02/oracle/ora11g/log_g08_02.rdo', '/odbfs03/oracle/ora11g/log_g08_03.rdo') SIZE 200 M;

Die Thread Number einer Instanz ermitteln Sie vorab über folgende Abfrage: SELECT FROM

instance_number, instance_name, thread# gv$instance;

2.7.12 Der Archive Log Modus Im Archive Log Modus archiviert die Datenbank Redologs, bevor sie überschrieben werden. Möchten Sie den Archive Log Modus für eine bereits bestehende Datenbank aktivieren oder deaktivieren, so muss die Datenbank in den Mount-Status überführt werden (siehe auch Abschnitte 2.5.1 „Phasen während des Startup“ und 2.5.3 „Startup-Befehle“). Die Datenbank ist während des Umschaltens in den Archive Log-Modus daher für kurze Zeit nicht verfügbar. Informationen zur Archivierung ermitteln Eine Gesamtübersicht über die aktuelle Archiver-Konfiguration sowie die aktuell verwendete Log-Sequenz erhalten Sie mit dem Befehl archive log list: SQL> ARCHIVE LOG LIST; Datenbank-Log-Modus Automatische Archivierung Archivierungsziel Älteste Online-Log-Sequenz Nächste zu archivierende Log-Sequenz Aktuelle Log-Sequenz

Archive-Modus Aktiviert USE_DB_RECOVERY_FILE_DEST 317 319 319

Archive Log Modus (de-)aktivieren Die Umschaltung selbst ist recht unproblematisch. Dazu ein Beispiel: 1. Setzen des Archivierungsverzeichnisses In der Standard Edition muss der Parameter log_archive_dest verwendet werden. Ein zweites Archivierungsziel kann optional mit log_archive_duplex_dest angegeben werden. Die Enterprise Edition erlaubt hingegen ab 11g R2 bis zu 30 Archivierungsziele bzw. bis zu 10 davor. Der Parametername lautet hier log_archive_dest_, wobei n eine Ganzzahl zwischen 1 und 30 bzw. 1 und 10 ist. Ein Beispiel:

120

2.7 Verwaltung von Redologs SQL> ALTER SYSTEM SET log_archive_dest_1 = 'location=/archive/db01';

2. Überführen der Datenbank in den Mount-Status SQL> shutdown immediate; SQL> startup mount;

-- Datenbank-Instanz herunterfahren -- Datenbank mounten

3. Aktivieren des Archive Log-Modus SQL> ALTER DATABASE ARCHIVELOG;

4. Öffnen der Datenbank SQL> ALTER DATABASE OPEN;

Die Datenbank archiviert nun je ein Redolog einer Gruppe, bevor die Mitglieder der Gruppe überschrieben werden können. Zum Deaktivieren des Archive Log-Modus verwenden Sie in Schritt 3 den Befehl SQL> ALTER DATABASE NOARCHIVELOG;

Zusätzlich können Sie das Archivierungsziel zurücksetzen. Dies ist jedoch nicht zwingend erforderlich: Ist der Archive Log-Modus nicht aktiviert, erfolgt auch keine Archivierung. Redologs manuell archivieren Rund um die Archivierung von Redologs gibt es einige nützliche Administrationsbefehle. Der folgende sorgt für die Archivierung aller noch nicht archivierten Redologs: ALTER SYSTEM ARCHIVE LOG ALL;

Der Archiver-Prozess führt die Archivierung automatisch nach jedem Log Switch durch. Mit obigem Befehl können Sie diese jedoch unabhängig von einem Log Switch explizit ausführen. Dies ist beispielsweise vor dem Duplizieren einer Datenbank mit RMAN, vor einer Datensicherung oder bei Tests mit Oracle Streams sinnvoll. Die folgenden Varianten ermöglichen weiterhin die Archivierung von Redologs, wobei jeweils angegeben wird, welches Log zu archivieren ist: ALTER ALTER ALTER ALTER

SYSTEM SYSTEM SYSTEM SYSTEM

ARCHIVE ARCHIVE ARCHIVE ARCHIVE

LOG LOG LOG LOG

NEXT; SEQUENCE 2192; CURRENT; CURRENT NOSWITCH;

Archivierung vorübergehend stoppen und starten Der folgende Befehl deaktiviert die Archivierung vorübergehend: ALTER SYSTEM ARCHIVE LOG STOP;

Achtung: Da kein Redolog überschrieben wird, solange es nicht archiviert wurde, bleibt die Datenbank nach einigen Logswitches im Archiver Stuck hängen: Es wird gewartet, bis wieder archiviert werden kann. Folgender Befehl reaktiviert die Archivierung: ALTER SYSTEM ARCHIVE LOG START;

121

2 Architektur und Administration

2.8

Verwaltung der Controlfiles 2.8.1

Informationen zu Controlfiles ermitteln

Pfad und Namen der Controlfiles ermitteln Sie wie folgt: SQL> SELECT name FROM v$controlfile;

Alternativ können Sie auch die View v$parameter prüfen: SQL> SELECT name, value FROM v$parameter WHERE name = 'control_files';

In SQL*Plus zeigt der Befehl show

parameter

Informationen zu Controlfles an:

SQL> show parameter control_files

2.8.2

Controlfiles spiegeln

Um dem Verlust eines Controlfiles vorzubeugen, empfiehlt es sich, diese zu spiegeln, sofern die Datenbank nicht von vorneherein mit gespiegelten Controlfiles angelegt wurde. Die Spiegelung eines Controlfiles ist leider nicht ohne Durchstarten möglich. Ermitteln Sie zunächst den Pfad und Namen eines vorhandenen Controlfiles: SQL> SELECT name FROM v$controlfile; NAME -------------------------------------/odbfs01/oradata/ora11g/control01.ctl

Setzen Sie dann den Parameter Inhalt Ihres Parameterfiles:

control_files.

Am besten sichern Sie zuvor noch den

SQL> create pfile = '/tmp/parametersicherung.ora' FROM spfile; SQL> alter system set control_files = '/odbfs01/oradata/ora11g/control01.ctl', '/odbfs02/oradata/ora11g/control02.ctl' scope = spfile;

Anschließend fahren Sie die Datenbankinstanz herunter und kopieren das vorhandene Controlfile in den neuen Zielpfad. Sollte es bereits mehr als ein Controlfile geben, kopieren Sie eines davon in den neuen Pfad. SQL> shutdown immediate; cp

/odbfs01/oradata/ora11g/control01.ctl \ /odbfs02/oradata/ora11g/control02.ctl

Nun können Sie die Instanz wieder starten: SQL> startup;

Prüfen Sie abschließend, ob alle Controlfiles verwendet werden. Sie können dies unter anderem am einheitlichen Zeitstempel der Dateien im Betriebssystem erkennen. Auch die View v$controlfile sollte nun alle Pfade und Namen anzeigen:

122

2.8 Verwaltung der Controlfiles SQL> SELECT name FROM v$controlfile; NAME -------------------------------------------------------------------/odbfs01/oradata/ora11g/control01.ctl /odbfs02/oradata/ora11g/control02.ctl

Ist dies nicht der Fall, wurde der Parameter Controlfiles nicht korrekt gesetzt. Sie müssen in diesem Fall die komplette Prozedur noch einmal durchführen.

2.8.3

Controlfiles durch eine Kopie sichern

Eine Sicherung der Controlfiles lässt sich leicht im laufenden Betrieb erstellen. Der folgende Befehl erzeugt eine Kopie des aktuellen Controlfiles: SQL> alter database backup controlfile to '/mnt_backup/ora11g.ctl.sic';

Sind in einem Fehlerfall alle Online-Controlfiles der Datenbank defekt, können Sie diese aus der oben erzeugten Kopie wieder herstellen. Dazu wird die obige Sicherung in alle Pfade kopiert, die in der View v$controlfile bzw. in v$parameter verzeichnet sind.

2.8.4

Controlfiles mit einem Trace dumpen

Der folgende Befehl erzeugt eine Trace-Datei. Diese enthält den Befehl, um bei einem Verlust der Controlfiles diese mit create controlfile wiederherzustellen. SQL> alter database backup controlfile to trace;

Im Alert Log wird der Pfad und Name der Trace-Datei angezeigt. Praxistipp Informationen zu RMAN-Backups sind im obigen Trace-File nicht enthalten. Sofern Sie RMAN für Datenbanksicherungen ohne Katalogdatenbank verwenden, empfiehlt sich die Wiederherstellung des Controlfiles aus einer Kopie oder aus einer RMAN-Sicherung.

Das mit dem obigen Befehl erzeugte Skript kann auch verwendet werden, um ein neues Controlfile mit abweichenden Pfaden – beispielsweise bei einer SAP-Systemkopie – zu erstellen. Zudem ist es möglich, neue Werte für die Parameter maxDatafiles und maxlogfiles zu vergeben. Der Befehl zur Neu-Erzeugung eines Controlfile kann beispielsweise wie folgt aussehen: STARTUP NOMOUNT CREATE CONTROLFILE REUSE DATABASE "V1_ARS" RESETLOGS FORCE LOGGING ARCHIVELOG MAXLOGFILES 192 MAXLOGMEMBERS 4 MAXDATAFILES 1024 MAXINSTANCES 8 MAXLOGHISTORY 2337 LOGFILE GROUP 1 ('/oradata/ora11g/redo_001', '/oradata/ora11g/redo_011') SIZE 256M, GROUP 2 ('/oradata/ora11g/redo_003', '/oradata/ora11g/redo_013') SIZE 256M,

123

2 Architektur und Administration GROUP 3 ('/oradata/ora11g/redo_005', '/oradata/ora11g/redo_015') SIZE 256M, GROUP 4 ('/oradata/ora11g/redo_007', '/oradata/ora11g/redo_017') SIZE 256M, GROUP 5 ('/oradata/ora11g/redo_009', '/oradata/ora11g/redo_019') SIZE 256M DATAFILE '/oradata/ora11g/system_001', '/oradata/ora11g/undotbs1_001', '/oradata/ora11g/sysaus_001', '/oradata/ora11g/undotbs1_002', '/oradata/ora11g/users_01', '/oradata/ora11g/xdb01.dbf', '/oradata/ora11g/ars_data01.dbf', '/oradata/ora11g/ars_idx01.dbf', '/oradata/ora11g/ars_data01.dbf', '/oradata/ora11g/ars_idx01.dbf', '/oradata/ora11g/app_data_001.dbf', '/oradata/ora11g/app_indx_001.dbf', '/oradata/ora11g/dla_data_001.dbf', '/oradata/ora11g/dla_indx_001.dbf', '/oradata/ora11g/pit_data_001.dbf', '/oradata/ora11g/pit_indx_001.dbf' CHARACTER SET UTF8;

Controlfiles sollten nicht ohne Not neu erzeugt werden. Zum einen ist ein Wartungsfenster erforderlich, während dem die Datenbankinstanz nicht zur Verfügung steht. Zum anderen kann man durchaus auch einiges falsch machen: Falsche Pfadangaben beispielsweise können dazu führen, dass sich die Datenbank zunächst nicht mehr starten lässt. Es empfiehlt sich daher, sowohl vor als auch nach der Neu-Erzeugung der Controlfiles eine Datenbanksicherung durchzuführen.

2.9

Parametrisierung 2.9.1

Der Startvorgang mit Parameterfile

Oracle-Instanzen lesen beim Start aus dem Parameterfile die Parametrisierung der Datenbank und der Instanz. Beim Startup-Befehl kann explizit ein Pfad und Name übergeben werden: SQL> startup pfile='/opt/oracle/admin/ora11g/pfile/initora11g.ora';

Falls keine explizite Angabe für den Pfad und Namen des Parameterfiles gemacht wurde, durchsucht die Oracle-Instanz zunächst den Standardpfad. Er ist vom Betriebssystem abhängig und lautet: $ORACLE_HOME/dbs für Unix/Linux-Systeme  $ORACLE_HOME/database auf Windows-Systemen  Oracle-Instanzen halten bei der Suche nach einem Parameterfile eine klare Abfolge ein:

Zunächst wird nach einer Datei namens spfile<SID>.ora gesucht, wobei <SID>51 durch  den Namen der Datenbankinstanz zu ersetzen ist.

51

124

SID: System Identifier

2.9 Parametrisierung War die vorherige Suche nicht erfolgreich, wird nach einer spfile.ora (ohne <SID> im  Dateinamen) gesucht. Ist keine der beiden vorgenannten Dateien vorhanden, sucht die Instanz nach einem  PFile mit dem Namen init<SID>.ora. Zuletzt wird nach einer init.ora gesucht.  Existiert keine der oben genannten Dateien, endet der Startversuch mit einer Fehlermeldung: SQL> Startup ORA-01078: failure in processing system parameters LRM-00109: Parameterdatei '/opt/oracle/product/dbs/initora11g.ora' konnte nicht geöffnet werden

Lassen Sie sich nicht davon irritieren, wenn in der Fehlermeldung der Name eines PFiles angezeigt wird. Diese Meldung resultiert daraus, dass zuletzt nach einem Pfile gesucht und dieses nicht gefunden wurde. Sobald irgendeine den Namenskonventionen entsprechende Parameterdatei, gleich ob SPFile oder PFile, im Pfad gefunden wird, taucht diese Fehlermeldung nicht mehr auf. Praxistipp Hier liegt eine häufige Fehlerquelle bei Parameteränderungen: Ein PFile wird geändert, doch die Änderungen bewirken nichts. Ist ein SPFile vorhanden, wird dieses präferiert gelesen. Nur wenn kein SPFile vorhanden ist, kommt die Suche nach dem textbasierten PFile zum Zug. Eine Änderung eines PFiles mit anschließendem Neustart bewirkt daher nichts, sofern ein SPFile vorhanden ist, das nicht geändert wurde. In diesem Fall wird einzig und allein das SPFile ausgewertet.

Wie eingangs erwähnt, können Sie die Instanz auch mit einer vom Standard-Pfad und -Namen abweichenden Parameterdatei starten. Dies ist mit der Klausel pfile möglich, die den Pfad und Namen einer Init.ora entgegen nehmen kann. Die Syntax lautet: SQL> startup pfile='/opt/oracle/oradata/ora11g/ein_anderes_pfile.ora'

Leider gibt es nur eine Klausel für PFiles, nicht jedoch für SPFiles. Möchten Sie mit einem SPFile starten, das vom Standardpfad und -namen abweicht, so müssen Sie zu einem kleinen Trick greifen: Sie erstellen eine init.ora und hinterlegen darin den Namen des SPFiles, das verwendet werden soll. Ein Beispiel: sqlplus / as sysdba SQL> startup pfile = '/u01/oracle/dbs/spf_init.ora';

Der Inhalt der Datei aussehen:

/u01/oracle/dbs/spf_init.ora

kann beispielsweise wie folgt

SPFILE = /u01/oracle/dbs/test_spfile.ora

Auf Unix-/Linux-Systemen kann man zudem auch einfach einen Link unter dem Standardpfad mit dem Namen spfile<sid>.ora hinterlegen und bei Bedarf ganz einfach umsetzen.

125

2 Architektur und Administration

2.9.2

Welche Parameterdatei wird aktuell verwendet?

Wird eine Instanz mit einem SPFile gestartet, so vermerkt Oracle dies im Parameter SPFile. Den Wert des Parameters können Sie über die View v$parameter ermitteln: SQL> SELECT name, value FROM v$parameter WHERE name = 'spfile';

Oder kürzer in SQL*Plus: SQL> show parameter spfile NAME_COL_PLUS_SHOW_PARAM TYPE VALUE_COL_PLUS_SHOW_PARAM --------------------------- ----------- -----------------------------spfile string /opt/oracle/admin/ora11g/param s/spfileora11g.ora

Bleibt die Ausgabe leer, so ist eine init.ora für den Start der Instanz im Einsatz.

2.9.3

Ändern der Parametrisierung

Die älteren PFiles sind im Textformat gespeichert und mit Werkzeugen wie vi oder Notepad editierbar. Die Änderungen werden jedoch nur bei einem Neustart der Instanz ausgelesen. Die neueren SPFiles besitzen ein proprietäres Format. Sie sollten diese niemals mit einem Editor ändern, sondern für die Änderung von Parameterwerten folgenden SQL-Befehl verwenden: alter system set <parameter_name> = ;

Ein Beispiel: SQL> alter system set memory_target = 4000 M;

Die allgemeine Syntax lautet: alter system set <parameter_name> = scope=[SPFILE|MEMORY|BOTH];

Die Klausel scope erlaubt, eine der folgenden Optionen zu nutzen: memory: Eine Änderung an der Instanzparametrisierung nur zur Laufzeit vornehmen,  ohne diese in das SPFile zu schreiben spfile: Eine Änderung nur in das SPFile schreiben, ohne jedoch die Laufzeitumgebung  zu ändern both: Sowohl in der Laufzeitumgebung als auch persistent im SPFile ändern  Der folgende Befehl ändert die Größe des Arbeitsspeichers in der Laufzeitumgebung ohne diese Änderung in das SPFile zu schreiben. Nach einem Neustart der Instanz wird also wieder der alte Wert für den Parameter memory_target verwendet. SQL> alter system set memory_target = 4000 M scope=memory;

Gleichermaßen kann eine Änderung nur in das SPFile geschrieben werden, ohne dass die Änderung zur Laufzeit wirkt: SQL> alter system set memory_target = 4000 M scope=spfile;

126

2.9 Parametrisierung Wird die Klausel scope nicht angegeben, so wird der Wert both angenommen: Die Änderung der Parametrisierung erfolgt zur Laufzeit und wird im SPFile persistiert.

2.9.4

Zurücksetzen eines Parameters

Die reset-Klausel setzt den Wert eines Parameters zurück: SQL> alter system reset sga_target;

Bei Oracle-Versionen vor 11g ist eine explizite Angabe der Klausel SID52 bei einem Reset erforderlich: SQL> alter system reset sga_target sid='*';

Praxistipp Bis Oracle 9i ließen sich die Initialisierungsparameter für die Datenbank-Instanz nur über die init.ora vorgeben. Die Datei war mit einem Texteditor zwar leicht zu ändern. Doch dieses inzwischen veraltete Format hat auch Nachteile: Wurde ein dynamischer Parameter mit dem Befehl alter system geändert, musste der DBA diese Änderung in der init.ora-Datei zusätzlich explizit hinterlegen, damit der neue Parameterwert beim nächsten Start der Instanz aktiv wurde. Mit einem SPFile kann der DBA Änderungen der Parameter sehr viel einfacher pflegen. Ein alter system-Befehl mit Angabe des scopes genügt. Wir empfehlen die Verwendung eines SPFiles.

2.9.5

Probleme bei der Änderung der Parametrisierung

Gelegentlich kommt es vor, dass ein Parameter im SPFile nicht mehr geändert werden kann. Probleme gibt es unter anderem dann, wenn sich die Instanz aufgrund einer fehlerhaften Parametrisierung nicht mehr starten lässt, sowie gelegentlich mit verdeckten Parametern, manchmal auch mit SIDs in RAC-Umgebungen. Ein einfacher Workaround ist die Erstellung einer temporären init.ora, deren Änderung mit einem Editor und die abschließende Neuerstellung des SPFiles aus der geänderten init.ora. Dazu wird wie folgt vorgegangen: 1. Sicherungskopie des SPFile mit einer Betriebssystemkopie erstellen. 2. Ein PFile mit dem folgenden Befehl erstellen: SQL> create pfile='/tmp/tmp_pfile.ora' FROM spfile;

3. Das erzeugte PFile mit einem Editor wie vi oder Notepad ändern. 4. Aus dem PFile wieder ein SPFile erzeugen: SQL> create spfile FROM pfile '/tmp/tmp_pfile.ora';

Diese Vorgehensweise ist ein guter Notbefehl in Problemfällen.

52

Diese Klausel wird sonst nur im Oracle Real Application Cluster (RAC) verwendet. Vermutlich hat der Entwickler einfach nicht bedacht, dass die Mehrheit der Oracle-DBAs ohne RAC arbeitet.

127

2 Architektur und Administration

2.9.6

Aktuelle Parametrisierung ermitteln

Die Parameter Ihrer Datenbankinstanz und deren Werte finden Sie mit folgendem Statement heraus: SQL> SELECT name, value FROM v$parameter;

Noch einfacher geht es in SQL*Plus: SQL> show parameter

Sie können dem Befehl show parameter einen Bestandteil des Parameternamens übergeben. Die Ausgabe zeigt dann alle Parameter, die diesen Namensbestandteil enthalten, mit ihrem aktuellen Wert. Dazu ein Beispiel: SQL> show parameter dump NAME --------------------background_dump_dest core_dump_dest max_dump_file_size shadow_core_dump user_dump_dest

TYPE -----string string string string string

VALUE -------------------------------------------/opt/oracle/oradata/ora11g/trace /opt/oracle/oradata/ora11g/cdump unlimited none /opt/oracle/oradata/ora11g/trace

Die View v$parameter gibt Ihnen noch weitere hilfreiche Informationen aus. Beispielsweise können Sie ihr entnehmen, ob ein Parameter zur Laufzeit geändert werden kann oder ob ein Neustart der Instanz für eine Änderung erforderlich ist. Die Spalte isses_modifiable gibt an, ob der Parameter innerhalb einer Session geändert werden kann. Mit issys_modifiable sehen Sie, ob eine systemweite Änderung zur Laufzeit möglich ist. Über die Spalten ismodified und isadjusted lässt sich ermitteln, ob der Parameterwert manuell geändert oder vom System adjustiert wurde. Ein Beispiel: SQL>

SELECT name, value, issys_modifiable, ismodified, isadjusted FROM v$parameter WHERE name like '%sga%';

NAME ---------------sga_max_size pre_page_sga lock_sga sga_target

2.9.7

VALUE --------------369098752 FALSE FALSE 352 M

ISSYS_MOD --------FALSE FALSE FALSE IMMEDIATE

ISMODIFIED ---------FALSE FALSE FALSE TRUE

ISADJ ----FALSE FALSE FALSE FALSE

Parameter zur Datenbank- und Instanz-Konfiguration

Oracle bietet etwa 30 grundlegende (Basic) Parameter sowie rund 260 erweiterte Parameter. Einer Übersicht der Parameter erhalten Sie mit folgender Abfrage: SQL> SELECT * FROM v$parameter;

128

2.9 Parametrisierung Tabelle 2.4 Wichtige Parameter zur Datenbank- und Instanz-Konfiguration Parameter

Beschreibung

CLUSTER_DATABASE

True, wenn die Datenbank eine Clusterdatenbank / RAC ist

COMPATIBLE

Kompatibilitätsmodus für ein bestimmtes Release einstellen

CONTROL_FILES

Namen und Pfade der Controlfiles

DB_BLOCK_SIZE

Standardgröße der Datenbankblöcke

DB_CREATE_FILE_DEST

Standardverzeichnis zur Erstellung von Datafiles

DB_CREATE_ONLINE_LOG_DEST_n

Standarverzeichnis zur Erstellung von Online Redo Logs

DB_DOMAIN

Datenbankdomäne

DB_NAME

Datenbankname

DB_RECOVERY_FILE_DEST

Pfad zur Fast / Flash Recovery Area

DB_RECOVERY_FILE_DEST_SIZE

Grenze der Speichermenge, die in der Fast / Flash Recovery Area abgelegt werden darf

DB_UNIQUE_NAME

Globaler Unique Name der Datenbank. Der Unique Name muss unternehmensweit eindeutig sein.

INSTANCE_NUMBER

Die Nummer der Instanz in einem Oracle Real Application Cluster.

LDAP_DIRECTORY_SYSAUTH

aktiviert oder deaktiviert directory-basierte Authentifizierung für Benutzer mit der Rolle sysdba oder sysoper.

LOG_ARCHIVE_DEST_n

Verzeichnis(se) zur Archivierung von Redologs

LOG_ARCHIVE_DEST_STATE_n

Status der Archivierungsverzeichnisse. Er kann die Werte enable (aktiv), defer (deaktiviert), alternate (deaktivert, wird automatisch aktiviert, sobald ein andere Archivierungsverzeichnis nicht zugreifbar ist) annehmen.

NLS_LANGUAGE

Spracheinstellung / National Language Support

NLS_TERRITORY

Ländereinstellung für den National Language Support

OPEN_CURSORS

Maximale Anzahl gleichzeitig geöffneter Cursor

PGA_AGGREGATE_TARGET

Maximale Größe aller PGAs (Program Global Areas), des Arbeitsspeichers für Benutzerprozesse

PROCESSES

Maximale Anzahl der Prozesse

REMOTE_LISTENER

Im Real Application Cluster (RAC): Remote Listener für die ORACLE-Instanzen

REMOTE_LOGIN_PASSWORDFILE

Passwortdatei für die Authentifzierung als SYSDBA von einem Remote-Rechner

SESSIONS

Maximale Anzahl an Sessions

SGA_TARGET

Größe des von der Oracle-Instanz allokierten Shared Memory

SHARED_SERVERS

Anzahl der Shared Server-Prozesse bei Nutzung des Oracle Multithreaded Server (MTS)

STAR_TRANSFORMATION_ENABLED Star Transformation beispielsweise für Datawarehouse-Umgebungen UNDO_TABLESPACE

Name des/der Undo Tablespaces

129

2 Architektur und Administration

2.9.8

Verdeckte Parameter

Im Hintergrund einer Oracle-Instanz gibt es zahlreiche undokumentierte Parameter. Sie sollten grundsätzlich nur in enger Zusammenarbeit mit und nach Direktive durch den OracleSupport geändert werden. Verdeckte Parameter werden nicht in der View v$parameter angezeigt. Möchten Sie deren Werte ermitteln, können Sie auf die View x$ksppi zurückgreifen. Sie zeigt die Werte der Parameter an. Die zugehörigen Namen und Beschreibungen können Sie der View x$ksppcv entnehmen. Hier ein Beispiel: SQL> SQL> SQL> SQL> SQL>

SET SET VOL COL VOL

LINESIZE 150 PAGESIZE 3000 NAME FORMAT a30 VALUE FORMAT a20 DESCRIPTION FORMAT a60

SQL> SELECT x.ksppinm AS NAME, y.ksppstvl AS VALUE, ksppdesc AS DESCRIPTION FROM x$ksppi x, x$ksppcv y WHERE x.inst_id = userenv('Instance') AND y.inst_id = userenv('Instance') AND x.indx = y.indx AND substr(x.ksppinm,1,1) = '_' ORDER BY 1;

Soll ein verdeckter Parameter auf seinen Standardwert zurückgesetzt werden, kann auch hier ein Reset vorgenommen werden. SQL> alter system reset "_abort_recovery_on_join" scope=spfile sid='*';

Verdeckte Parameter beginnen stets mit einem Unterstrich. Beim Setzen und Zurücksetzen eines verdeckten Parameters muss dieser daher in Doppel-Quotes eingerahmt werden. Praxistipp Ändern Sie keinen verdeckten Parameter, sofern Sie nicht ausdrücklich durch den Oracle-Support dazu aufgefordert werden.

2.9.9

PFiles und SPFiles erzeugen

SPFiles lassen sich ab Oracle Database 11g R1 auch aus den aktuellen Speicherwerten der Laufzeitumgebung erstellen. Möchten Sie die aktuelle Umgebung sichern, verwenden sie den Befehl create spfile mit der Klausel from memory. Dazu ein Beispiel: SQL> create spfile = '/opt/oracle/oradata/ora11g/spfile_sicherung.ora' from memory;

Ein SPfile kann zudem auch aus einer bestehenden init.ora erzeugt werden: SQL> create spfile = '/opt/oracle/oradata/ora11g/spfile_sicherung.ora' from pfile = '/opt/oracle/oradata/ora11g/pfile_sicherung.ora';

Die Pfadangabe ist optional. Wenn sie fehlt, verwendet der Oracle-Server die Standardpfade.

130

2.10 Passwort-Dateien verwalten Umgekehrt ist es ebenfalls möglich, eine init.ora aus einem SPFile zu erzeugen. Dies ist gerade als Sicherung der aktuellen SPFile-Werte sinnvoll. Der folgende Befehl erstellt ein Pfile aus dem Standard-SPFile: SQL> create pfile = '/opt/oracle/oradata/ora11g/pfile_sicherung.ora' from spfile;

Um ein PFile aus einer vom Standard-Pfad und -Namen abweichenden Datei zu erstellen, ist der Name voll qualifiziert anzugeben: SQL create pfile = '/opt/oracle/oradata/ora11g/pfile_sicherung.ora' from spfile = '/opt/oracle/oradata/ora11g/spfile_sicherung.ora';

2.10

Passwort-Dateien verwalten Name und Speicherort der Passwort-Datei sind systemspezifisch. Auf Unix- und LinuxPlattformen liegt sie im Verzeichnis $ORACLE_HOME/dbs und trägt den Namen orapw<SID> bei exklusiv genutzten bzw. orapw bei gemeinsam genutzten Passwort-Dateien. Auf Windows-Systemen finden Sie die Passwort-Datei im Verzeichnis $ORACLE_HOME/database. Ihr Name lautet pwd<SID>.ora bei exklusiv sowie pwd.ora bei gemeinsam genutzten Passwort-Dateien. Der Platzhalter <SID> steht für den Namen der Datenbankinstanz.

2.10.1 Passwort-Datei erstellen Der Befehl orapwd erstellt Passwort-Dateien. Die allgemeine Syntax lautet: orapwd file= password=<passwort> entries= force= ignorecase= nosysdba=

/

Achten Sie darauf, dass Sie sich beim Namen der Passwort-Datei an die oben beschriebene Namens- und Pfadvorgabe halten. Andernfalls wird die Passwort-Datei nicht angezogen: Die Authentifizierung mit der Passwort-Datei ist dann nicht möglich. Achtung: Die neue Passwort-Datei wird erst nach einem Neustart der Instanz aktiv. Tabelle 2.5 Schalter des Befehls orapwd Schalter

Beschreibung

Pfad und Name der zu erstellenden Passwort-Datei

<passwort>

Passwort für den Benutzer sys

Maximale Anzahl an Benutzern, die DBA-Rechte erhalten force

Flag, um das Überschreiben einer eventuell schon vorhandenen Datei zu forcieren

ignorecase

Standardmäßig wird ab Oracle 11g zwischen Groß- und Kleinschreibung unterschieden. Dieser Schalter ermöglicht die explizite Steuerung. In Versionen vor 11g existiert dieser Schalter nicht. Kennworte unterscheiden in diesen Versionen die Groß-/Kleinschreibung nicht.

nosysdba

Dieser Schalter gilt für Database Vault

131

2 Architektur und Administration Praxistipp Haben Sie das Kennwort für den Sysdba-Benutzer vergessen, können Sie eine bestehende Passwort-Datei umbennen und eine neue mit einem Ihnen bekannten Passwort erstellen. Die neue Passwort-Datei wird jedoch erst nach einem Neustart der Instanz aktiv.

2.10.2 Passwort-Dateien und Datenbankparameter Der Datenbankparameter remote_login_passwordfile steuert die Vewendung der Passwort-Datei. Es gibt drei Werte: „none“, „exclusive“ und „shared“. Steht der Wert auf „none“, wird das Passwordfile nicht verwendet. Privilegierte Benutzer müssen sich in diesem Fall in anderer Weise, beispielsweise über Betriebssystemauthentifizierung anmelden. Der Wert „exclusive“ bindet das Passwordfile an genau eine Datenbank. Wird der Wert auf „shared“ gesetzt, so nutzen mehrere Datenbankinstanzen gemeinsam die Passwort-Datei. Dies ist beispielsweise bei Real Application Clusters (RAC) nützlich. Der Standardwert ist „exclusive“.

2.10.3 Priviligierte Benutzer einer Passwort-Datei hinzufügen und entfernen Neue Benutzer werden durch Vergabe eines der Privilegien sysdba, in das Passwordfile übernommen. Ein Beispiel:

sysoper

oder

sysasm

SQL> create user anna_meier; SQL> grant sysdba to anna_maier;

Um einen Benutzer aus einer Passwort-Datei zu entfernen, nehmen Sie diese Rechte einfach wieder zurück: SQL> revoke sysdba from anna_maier;

Die dynamische Performance-View v$pwfile_users zeigt alle Datenbankbenutzer mit den Privilegien sysasm, sysdba und sysoper an. SQL> SELECT * from v$pwfile_users;

Praxistipp Nur exklusiv genutzte Passwort-Dateien lassen sich ändern. Bei gemeinsam genutzten Passwort-Dateien sind Änderungen nicht möglich: So können keine Benutzer hinzugefügt werden. Auch Passworte der Benutzer sysdba, sysoper und sysasm sind nicht änderbar. Um Änderungen durchzuführen, muss die Passwort-Datei wieder auf „exclusive“ gesetzt werden. Dann führen Sie die Änderungen durch und setzen abschließend den Wert wieder auf „shared“.

132

2.11 Weitere Administrationsbefehle

2.11

Weitere Administrationsbefehle 2.11.1 Ändern des Globalen Namens der Datenbank Der Globale Name einer Datenbank muss in verteilten Umgebungen eindeutig sein. Hier wird er auch als Basis des Namens von Datenbank Links53 eingesetzt. Den aktuellen Global Name können Sie mit der folgenden Abfrage ermitteln: SQL> SELECT * FROM GLOBAL_NAME;

Standardmäßig ergibt sich der Globale Name der Datenbank aus den Parametern .. Er kann zudem explizit gesetzt werden: SQL> ALTER DATABASE RENAME GLOBAL_NAME TO sales.jp.acme.com;

Wird der Global Name einer Datenbank geändert, so sind die Administratoren, die auf diese Datenbank zugreifen, zu informieren, sodass sie ihre Datenbank-Links anpassen können.

2.11.2 Ändern des Zeichensatzes Bis Oracle 11.1 lässt sich der Zeichensatz der Datenbank mit dem Befehl alter ändern, sofern der neue Zeichensatz eine Obermenge des alten ist.

database

SQL> ALTER DATABASE CHARACTER SET al32utf8;

Ab Oracle 11.2 ist es nicht mehr möglich, den Zeichensatz der Datenbank mit dem Befehl alter database zu ändern. Stattdessen muss das Skript csalter verwendet werden. Den aktuellen Zeichensatz sowie weitere Einstellungen des National Language Supports (NLS) können Sie über die View nls_database_parameters ermitteln: SQL> SELECT * FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';

Die Änderung des Zeichensatzes erfolgt in zwei Schritten: Zunächst wird mit einem Scan überprüft, ob der Datenbestand in den Ziel-Zeichensatz konvertierbar ist. In einem zweiten Schritt kann die eigentliche Konvertierung durchgeführt werden. Für den Scan steht das Werkzeug csscan zur Verfügung. Der Aufruf kann beispielsweise wie folgt aussehen: $ csscan full=Y fromchar= WE8MSWIN1252 tochar= WE8ISO8859P15 process=2 \ log=/tmp/scan.log

Eine Beschreibung aller Parameter erhalten Sie mit dem folgenden Befehl: csscan help=y

53

Verbindungen einer Datenbank zu einer anderen

133

2 Architektur und Administration Praxistipp Sollte die Fehlermeldung „CSS-00107: Character set migration utility schema not installed” ausgegeben werden, so wurde das für csscan erforderliche Datenbank-Schema noch nicht installiert. Dies können Sie nachholen, indem Sie als Benutzer mit Sysdba-Privilegien das Skript csminst.sql im Verzeichnis $ORACLE_HOME/rdbms/admin aufrufen: sqlplus

"sys as sysdba" @?/rdbms/admin/csminst.sql

Der Scanvorgang benötigt durchaus einige Zeit, da der komplette Datenbestand zu überprüfen ist. Er erzeugt drei Ausgabedateien, darunter ein Error-Log. Darin sind Informationen wie die verwendeten Parameter des Scans, Probleme der Data Dictionary Tabellen sowie von Objekt-Tabellen angezeigt. Eine Detail-Sicht gibt die Spaltenwerte und RowIDs jener Datenzeilen aus, die Probleme bei einer Konvertierung verursachen. Ein Beispiel: User : SYS Table : JOB$ Column: NLSENV Type : VARCHAR2(4000) Number of Exceptions : 0 Max Post Conversion Data Size: 194 ROWID -----------------AAAAEXAABAAAAciAAA AAAAEXAABAAAAciAAB AAAAEXAABAAAAciAAF

Exception Type --------------convertible convertible convertible

Size Cell Data(first 30 bytes) ----- ----------------------------NLS_LANGUAGE='GERMAN' NLS_TERR NLS_LANGUAGE='GERMAN' NLS_TERR NLS_LANGUAGE='GERMAN' NLS_TERR

Korrigieren Sie zunächst Daten, die während der Konvertierung Probleme bereiten und starten Sie anschließend csscan erneut. Erst wenn csscan für die komplette Datenbank erfolgreich und ohne Fehler durchgeführt werden konnte, ist der Zeichensatz der Datenbank in einem zweiten Schritt änderbar. Bis Oracle 11g R1 lässt sich der Zeichensatz der Datenbank mit dem Befehl alter ändern, sofern der neue Zeichensatz eine Obermenge des alten ist.

data-

base

SQL> ALTER DATABASE CHARACTER SET al32utf8;

Ab Oracle 11g R2 ist dies nicht mehr möglich. Stattdessen ist das csalter-Skript zu verwenden. Sie finden es in $ORACLE_HOME/rdbms/admin/csalter.plb. Sichern Sie unbedingt zuvor die Datenbank und starten Sie sie im resctriced mode54. Hier der Aufruf: sqlplus "sys as sysdba" SQL> shutdown immediate; SQL> startup restrict; SQL> @?/rdbms/admin/csalter.plb

Das Skript prüft nun ab, ob ein csscan des Datenbestandes vorliegt, der innerhalb der letzten sieben Tage erzeugt wurde. Das Ergebnis des Scans muss eine problemlose Konvertibilität ergeben haben. Ist dies nicht der Fall, so bricht csalter mit einer Meldung ab; die Daten werden in diesem Fall nicht konvertiert. Sollte dies der Fall sein, überprüfen Sie das Error-Log des cscan.

54

134

Siehe auch Abschnitte 2.5.3 „Startup-Befehle“ und 2.4.5 „Shut-down-Befehle“.

2.11 Weitere Administrationsbefehle Praxistipp Sie können den Zeichensatz auch ändern, indem Sie eine neue Datenbank mit dem Zielzeichensatz mit einem Datenexport der alten Datenbank befüllen. Doch auch hier gilt: Der Datenbestand muss mit dem Zielzeichensatz vollständig abbildbar sein.

2.11.3 Benutzerverbindungen beenden: Kill Session Der Befehl kill session beendet eine Benutzersession. Alle offenen Transaktionen werden zurückgerollt, Ressourcen wie Sperren sowie der von der Session belegte Arbeitsspeicher freigegeben. Zunächst müssen SID und Serial-Number der Session ermittelt werden. SID steht hier übrigens für den eindeutigen Session Identifier, also nicht für SID im Sinne des Namens einer Datenbankinstanz. Die View v$session gibt Auskunft. Ein Beispiel: SQL> SELECT sid, serial#, inst_id FROM V$SESSION WHERE USERNAME='SCOTT'; SID SERIAL# ---------- ---------80 4

Die Session wird nun mit folgendem Befehl beendet: SQL> ALTER SYSTEM KILL SESSION '80, 4; System altered.

Sofern die Session noch Aktivitäten offen hat, die beendet werden müssen – beispielsweise das Abwarten einer Rückmeldung einer Remote-Datenbank oder das Zurückrollen einer Transaktion – so wartet die Datenbankinstanz mit der Beendigung der Session und markiert diese nach 60 Sekunden mit dem Status killed. Die folgende Meldung wird ausgegeben: ORA-00031: session marked for kill

Die Session wird dann automatisch nach dem Beenden des aktuellen Vorgangs durch den Prozess PMON terminiert. Soll darauf nicht gewartet werden, ist die Option immediate hilfreich. Sie sorgt dafür, dass die Session unmittelbar beendet wird: ALTER SYSTEM KILL SESSION '80, 4' IMMEDIATE;

Soll eine Session in einem RAC auf einer spezifischen Instanz beendet werden, so ist noch die Instanz-ID anzugeben. Diese lässt sich aus der View gv$session ermitteln. Die allgemeine Syntax lautet dann: SQL> ALTER SYSTEM KILL SESSION '<SID>, <SERIAL#>[, @]'

Ein Beispiel: SQL> SELECT sid, serial#, inst_id FROM GV$SESSION WHERE username='SCOTT'; SID SERIAL# INST_ID ---------- ---------- ---------80 4 2 SQL> ALTER SYSTEM KILL SESSION '80, 4, @2'; System altered.

135

2 Architektur und Administration

2.11.4 Benutzerverbindungen beenden: Disconnect Session Der Befehl disconnect session wurde mit Oracle 11g R1 eingeführt. Er arbeitet ähnlich wie ein kill session. Während kill session die Session beauftragt, sich selbst zu beenden55, killt ein disconnect session einfach den Server-Prozess. Das Verfahren entspricht einem kill auf den Betriebssystem-Prozess. Die Option warten.

immediate

beendet die Verbindung, ohne auf aktuelle Transaktionen zu

SQL> ALTER SYSTEM DISCONNECT SESSION '80, 4' POST_TRANSACTION;

Der Zusatz post_transaction bewirkt, dass der Abschluss der aktuellen Transaktion abgewartet wird.

2.11.5 Benutzersessions sperren: Restricted Mode Für die Durchführung von Wartungsarbeiten ist es manchmal erforderlich, dass keinerlei Benutzeraktionen in der Datenbank ausgeführt werden. Dazu wird der Zugang normaler Datenbankbenutzer mit folgendem Befehl unterbunden: SQL> alter system enable restricted session;

Danach können sich nur noch Benutzer an der Datenbankinstanz anmelden, die das Privileg restricted session besitzen. Benutzer mit den Rollen sysdba und dba erhalten implizit dieses Privileg. Der Restricted Mode bewirkt – je nach Datenbankumgebung – Folgendes: In einer Single-Instance-Umgebung ohne Oracle Restart werden Benutzerverbindungen  nicht beendet. Sie bleiben bestehen und müssen gegebenenfalls mit einem kill oder disconnect (siehe Abschnitt 2.11.3 „Benutzerverbindungen beenden: Kill Session“) beendet werden. In einer Single-Instance-Umgebung mit Oracle Restart erhalten alle Services, die mittels  Oracle Restart verwaltet werden, den Status „offline“. Alle Benutzer, die über einen dieser Services verbunden sind, werden beendet. Der Standard-Service einer Datenbankinstanz, der aus den Komponenten . zusammengesetzt ist und der automatisch beim Oracle Listener registriert wird, bleibt online, da er nicht mit Oracle Restart verwaltet wird. In einer Umgebung mit Oracle Real Application Clusters wird jeder Service auf offline  gesetzt, der von dieser Instanz bedient und den die Oracle Clusterware verwaltet. Alle Benutzersessions, die über einen dieser Services verbunden waren, werden mit einem kill beendet. Der Standard-Service einer Datenbankinstanz . bleibt jedoch auch in dieser Konfiguration online. Zudem ist es möglich, beim Start einer Instanz direkt in den Restricted Mode zu gehen:

55

136

Dies kann problematisch sein, wenn die Session nicht mehr reagiert.

2.11 Weitere Administrationsbefehle SQL> startup restrict;

oder SQL> startup restrict pfile='/opt/oracle/admin/ora11g/pfile/init.ora';

Folgender Befehl beendet den Restricted Mode einer Datenbankinstanz: SQL> alter system disable restricted session;

2.11.6 Benutzeraktionen unterbinden: Quiesce Restricted Manchmal ist es erforderlich, eine Datenbank in einen Zustand zu bringen, in dem nur DBAs Transaktionen ausführen, Daten abfragen und PL/SQL-Code starten dürfen. Der Status „quiesce“ ist dann sinnvoll, wenn Aktionen ohne konkurrierende Arbeiten ausgeführt werden müssen. So kann eine neue Spalte einer Tabelle nur hinzugefügt werden, wenn dies nicht durch Sperren anderer Benutzer behindert wird. Ist die Datenbank im Status „quiesce“, so unterbindet der Oracle Resource Manager alle Tätigkeiten von Benutzern ohne DBA-Privileg. SQL> ALTER SYSTEM QUIESCE RESTRICTED;

Alle aktuell ausgeführten Statements werden noch abgearbeitet. Neu abgesetzte Statements bleiben für die Dauer des Quiesce Mode sozusagen hängen. Sie werden weiter ausgeführt, sobald die Datenbank wieder freigeben ist. Für Datenbanken mit Oracle Real Application Clusters gilt der Status „quiesce“ für alle Instanzen. Der Quiesce-Befehl wartet, bis alle Sessions inaktiv geworden sind, bis sie also ihr aktuelles Statement verarbeitet haben. Dies kann manchmal ein Weilchen dauern. Um herauszufinden, welche Sessions ein Quiesce blockieren, können Sie in einer zweiten Session folgendes Statement nutzen: SELECT bl.sid, user, osuser, type, program FROM v$blocking_quiesce bl, v$session se WHERE bl.sid = se.sid;

Alternativ kann folgende Abfrage genutzt werden, um alle derzeit aktiven Benutzersessions zu ermitteln: SELECT FROM WHERE AND AND

s.username, s.program, a.sql_text v$session s, v$sqlarea a s.sql_hash_value = a.hash_value s.sql_id = a.sql_id s.status = 'ACTIVE';

Im Zweifelsfall muss entschieden werden, ob mit dem Quiesce auf alle Sessions gewartet wird, oder ob diese mit einem kill session (siehe Abschnitt 2.11.3 „Benutzerverbindungen beenden: Kill Session“) entfernt werden. In letzterem Fall ist zu bedenken, dass auch bei einem Kill die offenen Transaktionen zunächst noch zurückgerollt werden, so dass unter Umständen auch dies einige Zeit in Anspruch nehmen kann.

137

2 Architektur und Administration Praxistipp Während eines Quiesce lässt sich keine Sicherung der Datenbank durchführen. Oracle Hintergrundprozesse führen unter Umständen weiterhin Aktualisierungen interner Datenbankstrukturen durch, auch wenn die Datenbank im Zustand „quiesced“ ist. Zusätzlich können Header von Datafiles geändert werden. Eine Online-Sicherung dagegen ist problemlos möglich. Siehe auch Kapitel 13 „Backup und Recovery“.

Der folgende Befehl gibt die Datenbank wieder frei: SQL> ALTER SYSTEM UNQUIESCE;

Alle Sessions können nun wieder arbeiten. Dabei werden auch jene Statements ausgeführt, die durch Sessions während des Quiesce-Status abgesandt und zunächst angehalten wurden. Für Benutzer stellt sich ein Quiesce so dar, als würde die Datenbank „hängen“ und später wieder weiterarbeiten. Die View v$database zeigt in der Spalte active_state an, ob sich die Datenbank im Status „quiesced“ befindet. Es sind drei Ergebnisse möglich: Normal: Die Datenbank ist im Status unqiesced  Quiescing: Die Datenbank wird aktuell in den Status quiesced überführt, wartet jedoch  noch auf aktive Sessions von Benutzern, die kein DBA-Privileg besitzen Quiesced: Die Datenbank ist im Status quiesced. Nur Benutzer mit DBA-Privilegien  können Abfragen und Änderungen in der Datenbank ausführen.

2.11.7 Einen Checkpoint erzwingen Der folgende Befehl erzwingt einen Checkpoint: SQL> ALTER SYSTEM CHECKPOINT;

Dies kann beispielsweise bei Wartungsarbeiten an Redologs erforderlich werden. Das Herunterschreiben aller geänderten Datenblöcke bewirkt, dass im Falle eines Crash Recovery kein Online Redolog erforderlich ist und man diese bei Bedarf verschieben oder löschen kann.

2.11.8 Den Blockpuffer leeren: Flush buffer_cache Mit einem Flush des Buffer Caches wird der Datenbankblockpuffer geleert. Der Befehl ist primär für Test und Entwicklungsumgebungen gedacht: Performance-Messungen können so unter vergleichbaren Eingangsbedingungen getestet werden. SQL> alter database flush buffer_cache;

2.11.9 Den Shared Pool leeren: Flush shared_pool Der Shared Pool ist jener Bereich der SGA, in dem die Informationen des Data Dictionary sowie Shared SQL und PL/SQL gepuffert sind. Mit einem Flush des Shared Pools wird dieser geleert:

138

2.11 Weitere Administrationsbefehle SQL> ALTER SYSTEM FLUSH SHARED_POOL;

Ein Flush des Shared Pools kann nach folgender Fehlermeldung vorübergehend hilfreich sein: ORA 4031 "unable to allocate %s bytes of shared memory

Hintergrund: Der Shared Pool kann über die Zeitdauer des Betriebes zunehmend fragmentieren. Wird ein größeres SQL- oder PL/SQL-Codeobjekt in den Shared Pool geladen, so tritt der obige Fehler auf, wenn kein ausreichend großer Chunk an Memory für das Objekt allokiert werden kann. Allerdings ist es sinnvoll, die Ursache des Problems zu identifizieren. Häufig ist eine mangelhafte Programmierung einer Anwendung die Ursache, die keine Bind-Variablen einsetzt. Siehe Kapitel 8 „Optimierung“.

2.11.10 Den Inhalt eines Datenblockes dumpen Möchten Sie den Inhalt von Datenblöcken dumpen, so ist dies mit dem Befehl alter tem dump möglich:

sys-

ALTER SYSTEM DUMP DATAFILE 5 BLOCK MIN 50 BLOCK MAX 55;

Meist ist bereits bekannt, welcher Block gedumpt werden soll. Ein typischer Anwendungsfall ist eine Blockkorruption, bei der bereits in der Fehlermeldung die Nummer des Datafile sowie die Blocknummer angegeben sind. Es gibt jedoch auch vielfältige andere Anwendungsfälle. Möchten Sie den Header eines Datensegments lesen, so können Sie die Adresse des Header-Blockes aus der View dba_segments ermitteln und anschließend den betreffenden Block mit dem Dump-Befehl auslesen: SQL> SELECT owner, segment_type, segment_name, header_file, header_block FROM dba_segments WHERE owner = 'SCOTT' AND segment_name = 'EMP'; OWNER SEGMENT_TYPE SEGMENT_NAME HEADER_FILE HEADER_BLOCK ---------- ------------------ --------------- ----------- -----------SCOTT TABLE EMP 4 403 SQL> ALTER SYSTEM DUMP DATAFILE 4 BLOCK 403;

Daten wie die einer Tabelle oder eines Index werden in Extents gespeichert. Diese sind in der View dba_extents einsehbar: SQL> SELECT owner, segment_name, file_id, block_id, blocks FROM dba_extents WHERE owner = 'SCOTT' AND segment_name = 'EMP'; OWNER SEGMENT_NAME FILE_ID BLOCK_ID BLOCKS ---------- ---------- ---------- ---------- --------SCOTT EMP 4 25 8

Die Spalte file_id gibt die Dateinummer an und block_id die Blocknummer und Blocks die Anzahl der Blöcke, die im Extent enthalten sind. Um den letzten Block eines Extents zu ermitteln, errechnet man [block_id] + [blocks] -1. Im obigen Falle wäre dies 25 +8 -1= 32. SQL> alter system dump datafile 4 block min 25 block max 32;

139

2 Architektur und Administration Block-Dumps werden in das im Parameter schrieben:

user_dump_dest

angegebene Verzeichnis ge-

SQL> show parameter user_dump_dest NAME TYPE VALUE ------------------ ----------- -----------------------user_dump_dest string d:\app\a\diag\rdbms\ora11g\ora11g\trace

2.12

Informationen zur Datenbank ermitteln Oracle bietet zahlreiche Möglichkeiten, um Informationen rund um Ihre Datenbank zu ermitteln. Dazu bietet Oracle im Wesentlichen zwei View-Typen an: Statische Data Dictionary Views: Zeigen Informationen über relativ statische Objekte  wie Datafiles und Redologs, Tabellen, Benutzer und deren Privilegien und vieles mehr an Dynamische Performance Views: Geben Auskunft zur Datenbank-Aktivität  Da diese Views für die Arbeit mit Oracle-Datenbanken enorm wichtig sind, stellen wir sie im Folgenden genauer vor.

2.12.1 Statische Data Dictionary Views Eine Oracle-Datenbank speichert im System-Tablespace interne Tabellen mit Informationen über die Datenbank selbst. Man spricht hier von Meta-Information der Datenbank im Data Dictionary. Die Tabellen, die diese Informationen speichern, werden als Base Tables bezeichnet. In ihnen ist verzeichnet, welche Benutzer es gibt, welche Rechte diese Benutzer haben, welche Objekte wie Tabellen, Indizes, Views und Stored Procedures sie besitzen und vieles mehr. Diese Base Tables sind hochgradig normalisiert und für den durchschnittlichen Anwender nur schwer verständlich. Die sogenannten Data Dictionary Views bieten lesbare Sichten auf diese Metadaten. So gibt es Views wie dba_users, dba_tables, dba_indexes, dba_ constraints, dba_sequences, dba_views usw. Diese können Sie in exakt der gleichen Weise wie andere Views und Tabellen abfragen. Ein Beispiel: SQL> SELECT FROM WHERE

owner, table_name dba_tables owner = 'SCOTT';

Möchten Sie erfahren, wie eine bestimmte View aufgebaut ist, welche Spalten sie enthält und welche Datentypen diese Spalten nutzen, so können Sie in SQL*Plus den Befehl describe (oder abgekürzt desc) verwenden: SQL> desc dba_tables

Die Meta-View dict liefert eine Übersicht aller in einer Oracle-Datenbank vorhandenen Data Dictionary Views:

140

2.12 Informationen zur Datenbank ermitteln SQL> SELECT FROM ORDER BY

table_name, comments dict table_name;

Achtung: Es gibt enorm viele Views. Schränken Sie deshalb die Abfrage mit einer WhereKlausel ein, beispielsweise: SQL> SELECT FROM WHERE

table_name, comments dict table_name like '%FILE%';

Die Abfrage gibt Ihnen alle Namen jener Data Dictionary Views aus, die den Namensbestandteil „FILE“ enthalten. Möchten Sie alle Data Dictionary Views zu Tabellen oder zu Benutzern ermitteln, ersetzen Sie die Zeichenkette einfach durch „TABLE“ oder „USERS“. Achten Sie darauf, dass diese Abfrage casesensitiv ist: Alle View-Namen sind in Großbuchstaben hinterlegt. Views mit dem Namenspräfix dba_ sind nur für Benutzer mit DBA-Privilegien sowie für jene mit dem Recht select_catalog_role lesbar. Die meisten dieser Views haben korrespondierende Views mit dem Präfix all_ und user_. So gibt es die Views all_tables und user_tables, all_indexes und user_indexes und so fort. Jedes Präfix beschreibt einen exakten Scope: DBA_: Zeigt alle Objekte eines Typs  ALL_: Zeigt nur jene Objekte, deren Eigentümer der aktuelle Benutzer ist sowie Objekte,  deren Eigentümer ein anderer Benutzer ist und auf die der aktuelle Benutzer Zugriffsrechte hat. USER_: Zeigt nur jene Objekte, deren Eigentümer der aktuelle Benutzer ist  Der Aufbau dieser Views ist, unabhängig vom Scope, meist sehr ähnlich. Views mit dem Präfix user_ verzichten jedoch auf die Spalte owner, da deren Inhalt sich von selbst ergibt: Der Eigentümer ist stets der aktuelle Benutzer.

2.12.2 Dynamische Performance Views Dynamische Performance Views zeigen volatile (flüchtige) Informationen an. Dazu zählen Informationen zur aktuellen Datenbankaktivität, zu Benutzersitzungen und SQL-Statements, die gerade ausgeführt werden sowie zu Wartezuständen, die aktuell in der Datenbank auftreten. Auch die aktuelle Parametrisierung sowie die Konfiguration des Arbeitsspeichers werden über dynamische Performance Views abgebildet. Dynamische Performance Views beginnen mit dem Präfix „v$“. Um eine Übersicht aller dynamischen Performance Views zu erhalten, können Sie die View v$fixed_table abfragen. Suchen Sie beispielsweise nach Views, die Informationen rund um die SGA enthalten, so können Sie diese wie folgt ermitteln: SQL> SELECT FROM WHERE

name v$fixed_table name LIKE '%SGA%';

141

2 Architektur und Administration NAME -----------------------------GV$SGA GV$SGA_CURRENT_RESIZE_OPS GV$SGA_DYNAMIC_COMPONENTS … V$SGA_RESIZE_OPS V$SGASTAT V$SGA_TARGET_ADVICE X$KELRSGA X$KRASGA

Views mit dem Präfix „GV$“ zeigen in einem Real Application Cluster zusätzliche Informationen zu allen an der Clusterdatenbank beteiligten Instanzen. Ihr Aufbau gleicht dem von V$-Views, wird jedoch durch die Spalte inst_id für die Instanznummer im Cluster ergänzt. Praxistipp Oracle X$-Tables sind keine realen Tabellen, sondern C-Strukturen des Datenbankkernels. Diese auch als Fixed Tables bezeichneten Strukturen sind im Allgemeinen nicht dokumentiert und können sich von Release zu Release ändern. X$-Tabellen sind intern durch Latches geschützt. Ein Full Table Scan kann daher eine Latch Contention verursachen, die schlimmstenfalls ein ganzes System in die Knie zwingt56. Der Zugriff auf X$-Tabellen sollte daher nur mit Vorsicht genutzt werden.

Bei den mit „X$“ gekennzeichneten Objekten handelt es sich um C-Programmstrukturen im Sourcecode des Datenbank-Kernels. Sie sind im Allgemeinen undokumentiert und können sich von Release zu Release ändern. V$-und GV$-Views werden auf Basis der X$-Tabellen gebildet. Die Definitionen der GV$- und V$-Views mit Ihren Zugriffen auf X$-Strukturen können Sie über die MetaView v$fixed_view_definition ermitteln: SELECT view_name, view_definition FROM v$fixed_view_definition WHERE view_name = 'V$SESSION';

2.12.3 Allgemeine Informationen zur Datenbank Die View database_properties zeigt allgemeine Informationen zur Datenbank wie die Zeitzone, den Zeichensatz, den globalen Datenbanknamen sowie die Default Tablespaces zur Speicherung permanenter und temporärer Daten: SELECT property_name, description, property_value FROM database_properties;

Die View global_name zeigt zudem den globalen Datenbanknamen: SELECT * FROM global_name;

56

142

Dies gilt beispielswiese für X$KGLOB und X$KQLFXPL

2.12 Informationen zur Datenbank ermitteln Über v$database können Sie die Datenbank-ID, den Namen, die aktuelle System Change Number, das Erstellungsdatum der Datenbank sowie Informationen rund um das Logging, Flashback und Data Guard ermitteln: SELECT * FROM v$database;

2.12.4 Startzeit und Status der Instanz Die View v$instance zeigt die Startzeit und den aktuellen Status einer Instanz: SELECT instance_name, startup_time, status, shutdown_pending, blocked FROM v$instance;

2.12.5 Hostname und Instanz-Name Die View v$instance zeigt den Namen des Hosts und den der Instanz: SELECT host_name, instance_name FROM

v$instance;

2.12.6 Spracheinstellungen und Zeichensätze Die Views

nls_database_parameters, nls_instance_parameter und nls_session_ zeigen Informationen zu Einstellungen rund um den National Language Support (NLS): parameter

SELECT parameter, value FROM nls_database_parameters;

Mit Abfrage der View v$nls_parameters erhalten Sie ebenfalls Informationen zum National Language Support: SELECT parameter, value FROM v$nls_parameters;

2.12.7 Aktuelle Datenbankversion Die View v$instance zeigt, welches Oracle-Release eingesetzt wird: SELECT version FROM v$instance;

Detailliertere Informationen gibt die View v$version aus: SELECT * FROM v$version;

Wurde die Datenbank bereits gepatcht oder aktualisiert, so finden Sie eine Historie in sys.registry$history: SELECT * FROM sys.registry$history;

Genaue Auskunft zu einzelnen Patches gibt zudem der Betriebssystembefehl opatch: cd $ORACLE_HOME/OPatch ./opatch lsinventory -detail

143

2 Architektur und Administration

2.12.8 Installierte Oracle-Optionen Die View v$option zeigt Ihnen, welche Optionen installiert sind: SELECT parameter, value FROM v$option;

Statistiken zur Nutzung von Features und Optionen finden Sie in statistics:

dba_feature_usage_

ALTER SESSION SET NLS_DATE_FORMAT = 'dd.mm.yyyy hh24:mi'; SELECT a.name, a.detected_usages, a.first_usage_date, a.last_usage_date FROM dba_feature_usage_statistics a WHERE a.version = (SELECT MAX(b.version) FROM dba_feature_usage_statistics b WHERE b.name = a.name) ORDER BY a.name;

Für die Lizenzierung Ihres Oracle-Produktes kann diese Übersicht wichtig sein. Wurde beispielsweise Partitionierung genutzt, aber nicht lizenziert, kann dies bei einem Audit durch Oracle zu einer Nach-Lizenzierung führen, die unter Umständen – je nach Option und Lizenzierungsmodus – Kosten nach sich ziehen kann.

2.12.9 Größen der Caches der SGA Nützliche Views für das Monitoring der SGA sind v$sga: Zusammenfassende Informationen  v$sgainfo: Größe der einzelnen SGA-Komponenten sowie des freien Speichers  v$sgastat: Detaillierte Informationen  v$sga_dynamic_components: Informationen zu dynamischen Komponenten der SGA  v$sga_dynamic_free_memory: Zeigt den verfügbaren Speicher, der bei Konfigurations änderungen genutzt werden kann v$sga_current_resize_ops: Aktuelle Größenänderung  v$sga_resize_ops: Informationen zu den letzten 100 Größenänderungen 

Die folgende Abfrage zeigt die aktuellen Größen der einzelnen Caches: SELECT name, round(bytes / 1024 / 1024) "Size MB", resizeable FROM v$sgainfo;

2.12.10 Pfad zu Trace-Dateien und Alertlog Ab Oracle Database 11g R1 gibt es ein neues Diagnoseverzeichnis, in dem sowohl eine textbasierte als auch eine XML-formatierte Version des Alertlogs sowie die Trace-Files vorliegen. Die View v$diag_info zeigt die Pfade:

144

2.12 Informationen zur Datenbank ermitteln SELECT name, value FROM v$diag_info; NAME -----------------------Diag Enabled ADR Base ADR Home Diag Trace Diag Alert Diag Incident Diag Cdump Health Monitor Default Trace File Active Problem Count Active Incident Count

VALUE --------------------------------------------TRUE d:\app\a d:\app\a\diag\rdbms\ora11g\ora11g d:\app\a\diag\rdbms\ora11g\ora11g\trace d:\app\a\diag\rdbms\ora11g\ora11g\alert d:\app\a\diag\rdbms\ora11g\ora11g\incident’ d:\app\a\diag\rdbms\ora11g\ora11g\cdump d:\app\a\diag\rdbms\ora11g\ora11g\hm d:\app\a\diag\rdbms\ora11g\ora11g\trace\ora11 g_ora_2104.trc 1 1

Die textbasierte Version finden Sie im Verzeichnis Verzeichnis Diag Alert.

Diag Trace,

die XML-formatierte im

Bis einschließlich Oracle Database 10g ist eine textbasierte Alertlog-Datei im Background Dump Destination zu finden. Den Pfad ermitteln Sie wie folgt: SELECT FROM WHERE

name, value v$parameter name ='background_dump_dest';

Benutzer-Tracedateien liegen im Verzeichnis user_dump_dest: SELECT FROM WHERE

name, value v$parameter name LIKE '%dump%';

2.12.11 Datenbank-Benutzer Allgemeine Informationen zu Benutzern zeigt die View dba_users: SELECT FROM ORDER BY

username, created, account_status, default_tablespace, temporary_tablespace dba_user username;

2.12.12 Rechte und Rollen eines Datenbank-Benutzers Informationen zu Rechten und Rollen finden Sie in den Views dba_tab_privs, dba_roles, dba_role_privs, dba_profiles, dba_sys_privs und dba_sys_grants. Die Abfrage der effektiven Rechte eines Benutzers ist aufgrund etlicher Rekursionen verhältnismäßig komplex. Eine sehr einfache Möglichkeit die aktuellen Berechtigungen eines Benutzers zu prüfen, bietet das Package dbms_metadata. SELECT dbms_metadata.get_granted_ddl('SYSTEM_GRANT', 'SCOTT') FROM dba_users; SELECT dbms_metadata.get_granted_ddl('OBJECT_GRANT', 'SCOTT') FROM dba_users; SELECT dbms_metadata.get_granted_ddl('ROLE_GRANT', 'SCOTT') FROM dba_users;

Eine Übersicht erhalten Sie auch durch die folgende Abfrage:

145

2 Architektur und Administration SET SET COL COL COL

PAGES 3000 LINES 3000 grantee FORMAT A20 priv FORMAT A25 owner FORMAT A20

SELECT * FROM ( SELECT c.grantable AS GRANTEE, 'Spalte' AS LVL, c.privilege AS PRIV, c.grantable AS ADMIN, c.owner AS OWNER, c.table_name AS OBJ FROM dba_col_privs c UNION SELECT r.admin_option a, 'Rolle', r.granted_role, r.admin_option, NULL, NULL FROM dba_role_privs r UNION SELECT s.grantee, 'Sys Priv', s.privilege, s.admin_option, NULL, NULL FROM dba_sys_privs s UNION SELECT t.grantee, 'Tabelle', t.privilege, t.grantable, t.owner, t.table_name FROM dba_tab_privs t ) WHERE GRANTEE IN ('SCOTT', 'MUELLER', 'MEIER') ORDER BY 1, 2, 3, 5, 6;

2.12.13 Datenbankobjekte Informationen zu Datenbankobjekten wie Tabellen, Views, Indizes und Synonymen finden Sie in dba_tables, dba_views, dba_indexes und dba_synonyms: SQL> SELECT owner, table_name, partitioned, compression FROM dba_tables; SQL> SELECT owner, view_name, text FROM dba_views; SQL> SELECT owner, index_name, index_type FROM dba_indexes; SQL> SELECT owner, synonym_name FROM dba_synonyms;

Eine allgemeine Übersicht zu allen Objekten zeigt die View dba_objects: SELECT owner, object_type, object_name, created, last_ddl_time FROM dba_objects ORDER BY owner, object_type, object_name;

Gespeicherte PL/SQL-Prozeduren und Funktionen, Packages, Trigger und Typen werden in dba_source abgebildet: SELECT line, text FROM dba_source WHERE owner = 'SCOTT' AND name = 'PKG_EMP' ORDER BY name, type, line;

Weitere Informationen zu Views finden Sie in den jeweiligen Abschnitten zum jeweiligen Themengebiet.

146

2.12 Informationen zur Datenbank ermitteln

2.12.14 Offene Datenbankverbindungen Die View v$sessions zeigt, welche Datenbankbenutzer aktuell eine oder mehrere Datenbankverbindung(en) geöffnet haben: SELECT FROM ORDER BY

sid, serial#, username, machine, program, status v$session s username;

Bei jenen Sessions, für die kein Benutzername angezeigt wird, handelt es sich um Oracle Background-Prozesse wie den Database Writer (DBWR), den Logwriter (LGWR) oder den Archiver (ARC). Die Spalte program zeigt Informationen zum jeweiligen Hintergrundprozess an.

2.12.15 Aktive Sessions Aktive Sessions sind Sessions, die aktuell ein Statement ausführen und auf dessen Abarbeitung warten. Sie enthalten in der Spalte status den Wert „ACTIVE“: SELECT FROM WHERE ORDER BY

sid, serial#, username, machine, program, status v$session s status = 'ACTIVE' username;

2.12.16 SQL-Statement nach Session Möchten Sie zusätzlich ermitteln, welche SQL-Statements ein Benutzer aktuell ausführt, so können Sie über die View v$sqlarea auf den Library Cache der Datenbank zugreifen. Dazu müssen der Hash-Value und die Adresse des SQL-Statements aus den Views v$session und v$sqlarea miteinander verknüpft werden: SELECT FROM WHERE AND ORDER BY

sid, serial#,username, machine, program, status, sql_text v$sqlarea a, v$session s sql_hash_value = hash_value (+) sql_address = address (+) username;

2.12.17 Waits Sie möchten herausfinden, worauf eine Session aktuell wartet? Die View gibt Auskunft. Dazu ein Beispiel:

gv$session_

wait

COL COL COL COL COL SET SET SET

sid spid username event machine LINES TRIMSPOOL TRIMOUT

SELECT

FORMAT 999 FORMAT 9999 FORMAT a20 FORMAT a20 FORMAT a20 200 ON ON

sw.sid, p.spid, s.username, s.osuser, sw.event, s.machine, s.program, decode(sw.event,'db file sequential read', sw.p3, 'db file scattered read', sw.p3,

147

2 Architektur und Administration NULL) blocks FROM , , WHERE AND AND

v$session_wait sw v$session s v$process p s.paddr = p.addr sw.wait_class != 'Idle' sw.sid = s.sid;

Die Spalte spid zeigt die Prozess-ID des Betriebssystemprozesses.

2.12.18 Langlaufende Operationen Über die View v$session_longops finden Sie Informationen zu lang laufenden Operationen in der Datenbank. Die Spalte time_remaining gibt den geschätzten Zeitraum in Sekunden an, den die Operation noch benötigt, elapsed_seconds zeigt die bisherige Laufzeit an. Die Spalte opname zeigt die Operation, target das Ziel der Operation. SELECT FROM WHERE

sid, serial#, opname, target, start_time, elapsed_seconds, time_remaining v$session_longops time_remaining > 0;

Über die Spalten SID und serial# lässt sich v$session_longops mit v$session verknüpfen, um zusätzliche Informationen zur Datenbankverbindung zu erhalten: SELECT FROM WHERE AND AND

l.sid, l.serial#, s.username, s.machine, s.program, l.opname, l.target, l.start_time, l.elapsed_seconds, l.time_remaining v$session_longops l, v$session s s.sid = l.sid s.serial# = l.serial# l.time_remaining > 0;

2.12.19 Sperren in der Datenbank Die View v$lock gibt Auskunft über aktuell in der Datenbank gehaltene Sperren. Die Spalte SID gibt den Session-Identifier des betreffenden Benutzers an. Sie kann mit der Spalte desselben Namens der View v$session verknüpft werden, um Informationen zur Benutzersession zu ermitteln, die die Sperre hält. Die Spalte ID1 gibt die Objekt-ID desjenigen Objekts an, das von der Sperre betroffen ist. Die folgende Abfrage zeigt Informationen über Benutzer, die andere durch eine Sperre blockieren, das betreffende Objekt und den Sperrtyp: COLUMN object_name FORMAT A30 COLUMN holder FORMAT A25 COLUMN Waiter FORMAT A25 SELECT

DISTINCT o.owner, o.object_name, o.object_type, sh.sid "SID", sh.SERIAL# "SERIAL", sh.username||'('||sh.sid||','||sh.SERIAL#||')' "Holder", sw.username||'('||sw.sid||','||sw.SERIAL#||')' "Waiter", decode(lh.lmode, 1, 'null', 2, 'row share', 3, 'row exclusive', 4, 'share',

148

2.13 Verwaltungswerkzeuge 5, 'share row exclusive' , 6, 'exclusive') "Lock Type" FROM

WHERE AND AND AND AND AND AND AND

v$session sw, v$lock lw, dba_objects o, v$session sh, v$lock lh lh.id1 = o.object_id lh.id1 = lw.id1 sh.sid = lh.sid sw.sid = lw.sid lh.type = 'TM' lw.type = 'TM' sh.lockwait is null sw.lockwait is not null;

2.12.20 Die aktuelle System Change Number (SCN) ermitteln Die aktuelle SCN einer Datenbank finden Sie mit folgendem Statement heraus: SQL> SELECT current_scn FROM v$database;

Möchten Sie die SCN des letzten Checkpoints aus dem Header einer Datei ermitteln, so können Sie die View v$datafile abfragen: SQL> ALTER SESSION SET nls_date_format = 'dd.mm.yyyy hh24:mi'; SQL> SELECT checkpoint_change#, checkpoint_time FROM v$datafile;

2.13

Verwaltungswerkzeuge Eine Administration von Oracle-Datenbanken sowie der zugehörigen Infrastruktur wie Cluster oder ASM ist ohne Unterstützung durch Verwaltungswerkzeuge nicht mehr denkbar. Obwohl Oracle alle neuen Produkte und Features so ausliefert, dass eine Administration komplett mithilfe von Kommandozeilen-Utilities wie SQL*Plus, ASMCMD, srvctl oder DGMGRL geleistet werden könnte, ist dies aus Gründen der Effektivität nicht sinnvoll. Es gibt eine Vielzahl von Verwaltungswerkzeugen mit grafischer Oberfläche für die unterschiedlichsten Belange. In diesem Abschnitt des Buches schauen wir uns die folgenden Tools etwas näher an: Oracle Enterprise Manager (OEM)  Oracle SQL Developer  Quest Toad 

149

2 Architektur und Administration

2.13.1 Der Oracle Enterprise Manager (OEM) Der Oracle Enterprise Manager deckt fast alle Produkte und Features der und rund um die Oracle-Datenbank ab. Er ist in zwei verschiedenen Ausprägungen verfügbar: dem Enterprise Manager Database Control sowie dem Enterprise Manager Grid Control. Während der EM Database Control für die Verwaltung einzelner Datenbanken ausgelegt ist, stellt der EM Grid Control eine zentrale Infrastruktur zur Verwaltung einer Vielzahl von Datenbanken zur Verfügung. Der EM Database Control fokussiert mit seiner Bandbreite an Target-Systemen auf die Datenbank und damit verbundener Features wie ASM oder dem Listener. Der EM Grid Control unterstützt eine große Anzahl von Target-Typen einschließlich Nicht-Oracle-Produkte wie Microsoft SQL Server oder auch Netzwerk- und Storage-Komponenten. Hervorzuheben ist, dass sich beide Ausprägungen in Look-andFeel und Bedienung kaum unterscheiden. Natürlich verfügt der EM Grid Control über eine erweiterte Enterprise-Funktionalität. Die Funktionalität des Enterprise Managers wurde in den letzten Jahren permanent erweitert und ist heute nicht ausschließlich ein Administrationswerkzeug. Er bietet unter anderem: Überwachung der Ziele (Monitoring)  Benachrichtigung der Administratoren  ein Job-System  Service Management  Change Management für Datenbanken  Lifecycle Management (Software Provisioning)  Configuration Management  Auf alle Funktionen des Enterprise Managers einzugehen, würde den Rahmen dieses Abschnitts deutlich sprengen. Wir konzentrieren uns deshalb auf die Features für die Datenbank-Administration und das Monitoring. Darüber hinaus finden Sie in diesem Abschnitt auch die nötigen Informationen und Hilfestellung zur Installation und Verwaltung des Enterprise Managers an sich. 2.13.1.1

Der Enterprise Manager Database Control

Der EM Database Control ist für die Verwaltung der Datenbank gedacht, auf der er installiert ist. Sein Funktionsumfang beschränkt sich damit auf die eigene Datenbank sowie zugehörige Komponenten wie ASM-Instanz oder Listener. Das Repository befindet sich in der Target-Datenbank, der Management-Service läuft auf demselben Server. Der EM Database Control kann mit dem DBCA beim Erstellen der Datenbank oder nachträglich installiert werden. Wählen Sie dazu die Option „Configure Database Control for local management“ (siehe Abbildung 2.10).

150

2.13 Verwaltungswerkzeuge

Abbildung 2.10 Den Enterprise Manager Database Control mit dem DBCA installieren

Das Repository wird in der Datenbank unter dem Schema „SYSMAN“ eingerichtet, und es wird ein lokaler Management Server konfiguriert und gestartet. Das Starten und Stoppen des Management Server erfolgt mit dem Utility „emctl“. Die Abfrage des Status liefert gleichzeitig die URL für den Webbrowser. Der Standard ist https://:1158/em. Hinweis Auf einem Windows-Betriebssystem wird ein Windows-Dienst für den Management Server eingerichtet. Das Starten und Stoppen kann auch über den Dienst erfolgen. Der Name des Dienstes ist „OracleDBConsole“. $ emctl start dbconsole . . . $ emctl stop dbconsole . . . $ emctl status dbconsole Oracle Enterprise Manager 11g Database Control Release 11.2.0.1.0 Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved. https://localhost:1158/em/console/aboutApplication Oracle Enterprise Manager 11g is running. -----------------------------------------------------------------Logs are generated in directory /u01/app/oracle/product/11.2.0/dbhome_1/serv1.dbexperts.com_EXPSEM/sysman/log

Nach der Anmeldung erscheint die Startseite der Datenbank (siehe Abbildung 2.11).

151

2 Architektur und Administration

Abbildung 2.11 Die Startseite des Enterprise Managers Database Control

Erstellung und Konfiguration können auch mit dem Enterprise Manager Configuration Assistant (EMCA) erfolgen. Er bietet wesentlich mehr Konfigurationsmöglichkeiten als der DBCA. Eine Hilfe mit den Optionen des Kommandos erhalten Sie mit „emca –h“. Mit dem Kommando im nachfolgenden Listing kann der Enterprise Manager komplett entfernt und das Repository gelöscht werden: $ emca -deconfig dbcontrol db -repos drop STARTED EMCA um 09.07.2011 09:24:33 EM-Konfigurationsassistent, Version 11.2.0.0.2 Production Copyright (c) 2003, 2005, Oracle. All rights reserved. Alle Rechte vorbehalten. Geben Sie folgende Informationen ein: Datenbank-SID: ORA112 Listener-Port-Nummer: 1521 Kennwort f³r SYS-Benutzer: Kennwort f³r SYSMAN-Benutzer: Kennwort f³r SYSMAN-Benutzer: M÷chten Sie fortfahren? [ja(Y)/nein(N)]: Y 08.07.2011 09:25:10 oracle.sysman.emcp.EMConfig perform INFO: Dieser Vorgang wird in /data/oracle/product/11.2.0/dbhome_1/cfgtoollogs/emca/ORA112/emca_2011_07_08_09_24 _32.log protokolliert. . . . INFO: Repository erfolgreich gelöscht Konfiguration von Enterprise Manager erfolgreich abgeschlossen FINISHED EMCA um 09.07.2011 09:29:23

Analog zum Entfernen kann der Enterprise Manager mit dem EMCA komplett neu eingerichtet werden (siehe folgendes Listing). $ emca -config dbcontrol db -repos create STARTED EMCA um 09.07.2011 09:33:29 EM-Konfigurationsassistent, Version 11.2.0.0.2 Production Copyright (c) 2003, 2005, Oracle. All rights reserved. Alle Rechte vorbehalten. Geben Sie folgende Informationen ein: Datenbank-SID: ORA112 Listener-Port-Nummer: 1521 Listener ORACLE_HOME [/data/oracle/product/11.2.0/dbhome_1 ]: Kennwort f³r SYS-Benutzer:

152

2.13 Verwaltungswerkzeuge Kennwort f³r DBSNMP-Benutzer: Kennwort f³r SYSMAN-Benutzer: . . . Konfiguration von Enterprise Manager erfolgreich abgeschlossen FINISHED EMCA um 09.07.2011 09:46:17

In Fehlersituationen kann es vorkommen, dass sich der Enterprise Manager mit dem EMCA einerseits nicht entfernen und andererseits nicht neu installieren lässt. Der einzige Ausweg ist dann, die Datenbank-Objekte manuell zu entfernen. Nachfolgend sehen Sie ein komplettes Listing von SQL-Anweisungen. Melden Sie sich dazu als User „SYS“ an. SQL> EXEC DBMS_AQADM.DROP_QUEUE_TABLE(queue_table => 'SYSMAN.MGMT_NOTIFY_QTABLE',force=>TRUE); PL/SQL-Prozedur erfolgreich abgeschlossen. SQL> SHUTDOWN IMMEDIATE; Datenbank geschlossen. Datenbank dismounted. ORACLE-Instanz heruntergefahren. SQL> STARTUP RESTRICT; ORACLE-Instanz hochgefahren. . . . Datenbank mounted. Datenbank geöffnet. SQL> EXEC sysman.emd_maintenance.remove_em_dbms_jobs; PL/SQL-Prozedur erfolgreich abgeschlossen. SQL> EXEC sysman.setEMUserContext('',5); PL/SQL-Prozedur erfolgreich abgeschlossen. SQL> DECLARE 2 CURSOR c1 IS 3 SELECT owner, synonym_name name 4 FROM dba_synonyms 5 WHERE table_owner = 'SYSMAN'; 6 BEGIN 7 FOR r1 IN c1 LOOP 8 IF r1.owner = 'PUBLIC' THEN 9 EXECUTE IMMEDIATE 'DROP PUBLIC SYNONYM '||r1.name; 10 ELSE 11 EXECUTE IMMEDIATE 'DROP SYNONYM '||r1.owner||'.'||r1.name; 12 END IF; 13 END LOOP; 14 END; 15 / PL/SQL-Prozedur erfolgreich abgeschlossen. SQL> DROP USER mgmt_view CASCADE; Benutzer wurde gelöscht. SQL> DROP ROLE mgmt_user; Rolle wurde gelöscht. SQL> DROP USER sysman CASCADE; Benutzer wurde gelöscht. SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION; System wurde geändert.

Praxistipp Wenn der Servername mehrere Netzwerk-Interfaces besitzt, kann der Enterprise Manager einem Interface (Hostnamen) dezidiert zugeordnet werden. Setzen Sie dazu die Umgebungsvariable „ORACLE_HOSTNAME“ beim Einrichten und Starten des Enterprise Managers. Dies ist auch eine gute Möglichkeit, den Hostnamen „localhost“ fest zuzuweisen, um Probleme, die zum Beispiel auf einem Laptop entstehen können, zu umgehen.

153

2 Architektur und Administration 2.13.1.2

Der Enterprise Manager Grid Control

Die Architektur des Enterprise Manager Grid Control ist in Abbildung 2.12 dargestellt. Er ist als zentrale Komponente für die Verwaltung und Überwachung einer größeren Anzahl von Zielsystemen konzipiert. Auf den Zielsystemen muss ein Agent installiert werden, der Daten zum Oracle Management Server hochlädt. Praxistipp Der Enterprise Manager Grid Control kann zu einem „Single Point of Failure“ werden. Fällt er aus, hat dies Einschränkungen auf die Administration und bedeutet einen Ausfall von Monitoring und Job-System für die gesamte Infrastruktur, die er unterstützt. Sie sollten deshalb in Erwägung ziehen, den Enterprise Manager hoch verfügbar aufzusetzen. Der Management Server läuft dann im Active-Active Cluster mit einem vorgeschalteten Load Balancer, und die Datenbank für das Repository wird als RAC aufgesetzt.

Abbildung 2.12 Die Architektur des Enterprise Manager Grid Control

Mit dem Erscheinen der aktuellen Version des Enterprise Managers 11g hat zugleich ein Technologiewechsel stattgefunden. Während die Vorgänger-Versionen noch mit dem herkömmlichen Oracle Application Server arbeiteten, basiert die Version 11g auf dem Oracle WebLogic Server. Im Folgenden finden Sie eine Beschreibung der Installation auf einem Linux/Unix-Betriebssystem.

154

2.13 Verwaltungswerkzeuge Achten Sie, bevor Sie mit der Installation beginnen, darauf, dass die einzelnen Komponenten miteinander zertifiziert und die Mindestanforderungen und Empfehlungen an Hardund Software erfüllt sind. In Tabelle 2.7 finden Sie eine Übersicht von zertifizierten Komponenten für eine Linux x86-64-Plattform. Tabelle 2.7 Zertifizierte Komponenten des EM Grid Control für x86-64 Komponente

Zertifiziert

Betriebssystem

RHEL 4,5, OEL 4,5, SUSE 10, Asianux 3

Repository-Datenbank

10.2.0.4, 10.2.0.5, 11.1.0.7, 11.2.0.1, 11.2.0.2

Oracle Agent

Agent 11gR1, ältere Version mit Einschränkung der Funktionalität

Oracle WebLogic Server

10.3.2

Internet Browser

IE 7,8, Firefox 3.0, 3.5, Safari 4.0, Adobe Flash Player >= 9.0.115

Nur wenn Sie zertifizierte Komponenten einsetzen, können Sie sicher sein, bei Problemen Support von Oracle zu erhalten. Beim Einsatz nicht-zertifizierter Bestandteile kann Oracle den Support ablehnen. Stellen Sie zudem sicher, dass die Mindestanforderungen an Hard- und Software erfüllt sind. Andernfalls kann es zu Problemen bei der Installation oder im späteren Betrieb kommen. Die Anforderungen sind in Tabelle 2.8 zusammengefasst. Tabelle 2.8 Anforderungen an Hard- und Software Anforderung an

Beschreibung

Hardware

Hauptspeicher für OMS: 3 GB (< 100 Zielsysteme), 4 GB (< 1000 Zielsysteme), 6 GB (< 10.000 Zielsysteme) Diskspace 50 GB (< 100 Zielsysteme), 100 GB (< 1000 Zielsysteme), 400 GB (< 10.000 Zielsysteme)

Hostname

Es muss einen einzigen Hostnamen mit einer statischen IP-Adresse geben. Im Falle einer dynamischen Adresse wird die Installation fehlschlagen.

Anzahl File Descriptors

Die Anzahl der File Descriptors für „oracle“ muss mindestens 4096 betragen: „ulimit –n“

JDK

Stellen Sie sicher, dass mindestens die folgenden JDK-Versionen installiert sind: Linux:SUN JDK 1.6_18 Solaris: JDK 6.0.05 AIX: JDK 1.6.0 SR6 Windows: SUN JDK 1.6_18

WebLogic Server

Version 10.3.2, Patch ID WDJ7

155

2 Architektur und Administration Praxistipp Stellen Sie vor der Installation sicher, dass der Enterprise Manager Database Control nicht in der Datenbank konfiguriert ist, die als Repository für den Enterprise Manager Grid Control dienen soll. Eine Anleitung zum Entfernen finden Sie in Abschnitt 2.13.1.1 „Der Enterprise Manager Database Control“.

Wenn keine Datenbank für das Repository zur Verfügung steht, sollten Sie eine erstellen. Eine Übersicht der zertifizierten Versionen finden Sie in Tabelle 2.7. Im ersten Schritt muss der Oracle WebLogic Server installiert werden. Starten Sie das Installationsprogramm und folgen Sie den Schritten des Installations-Assistenten (siehe Abbildung 2.13).

Abbildung 2.13 Die Startseite des Oracle WebLogic Installer

Praxistipp Installieren Sie keine Domain auf dem WebLogic Server. Dies erfolgt durch den Installer des Enterprise Managers.

Nach diesen Vorbereitungen können wir mit der Installation des EM Grid Control beginnen. Starten Sie den Universal Installer aus dem Installationsverzeichnis des Enterprise Managers und folgen Sie den Anweisungen. Wählen Sie im Schritt 3 die Option „Install a new Enterprise Manager system“. Danach überprüft der Installer, ob alle Voraussetzungen seitens des Betriebssystems erfüllt sind. In Schritt 5 fordert der Installer die Eingabe des

156

2.13 Verwaltungswerkzeuge Middleware Home-Verzeichnisses. Das Middleware Home ist das Verzeichnis, unter dem der WebLogic Server installiert wurde.

Abbildung 2.14 Auswahl des Middleware Home-Verzeichnis

Im nächsten Schritt wird eine neue WebLogic Domain erstellt. Geben Sie die Passwörter für den WebLogic User und den Node Manager ein. Im Weiteren werden die Verbindungsinformationen zum Datenbank-Repository sowie das SYSMAN-Passwort abgefragt. Mit dem Registration-Passwort werden sich später die Agenten am Management Server registrieren. Praxistipp Markieren Sie die Optionen „Allow only secure agent to communicate with the OMS“ und „Allow only secure access to the console“. Damit wird sichergestellt, dass die Kommunikation ausschließlich mit “HTTPS” erfolgt. So ist ein sicherer Zugriff garantiert, auch wenn einzelne Komponenten sich außerhalb des Firmennetzwerks oder hinter der Firewall befinden.

Schließlich erhalten Sie noch eine Übersicht der Ports, mit denen der OMS konfiguriert wird (siehe Abbildung 2.15). Sichern Sie diese Information, sie kann später nützlich sein, zum Beispiel wenn Firewalls konfiguriert werden müssen.

157

2 Architektur und Administration

Abbildung 2.15 Information der TCP/IP Ports im Enterprise Manager

Nachdem Sie die Zusammenfassung bestätigt haben, beginnt die Installation. Unter dem Middleware Home werden folgende Produkte installiert: OMS Home: $ORACLE_MIDDLEWARE_HOME/oms11g  Agent Home: $ORACLE_MIDDLEWARE_HOME/agent11g  Webtier Home: $ORACLE_MIDDLEWARE_HOME/Oracle_WT  Der Agent für den Management Server wird also direkt mitinstalliert. Nach der Installation laufen die Configuration Assistants für die Erstkonfiguration der einzelnen Komponenten (siehe Abbildung 2.16). Nach erfolgreicher Installation sind der Management Server und der Management Agent gestartet. Sie können auf den Enterprise Manager unter der folgenden URL zugreifen: https://:7799/em

Melden Sie sich als User „SYSMAN“ an, das Passwort haben Sie während der Installation vergeben. Es erscheint die Startseite des EM Grid Control (siehe Abbildung 2.17). Diese enthält eine Übersicht aller Ziele, deren Status und Software-Version sowie alle Alerts und Policy-Verletzungen.

158

2.13 Verwaltungswerkzeuge

Abbildung 2.16 Die Configuration Assistants für die Erstkonfiguration des Enterprise Managers

Abbildung 2.17 Die Startseite des Enterprise Manager Grid Control

159

2 Architektur und Administration Sowohl der Management Server als auch der Agent wurden für einen automatischen Start beim Hochfahren des Servers konfiguriert. Sie können die Komponenten manuell mit dem Utility „emctl“ starten und stoppen. Setzen Sie dazu die jeweilige Umgebung für das Oracle Home-Verzeichnis: ORACLE_SID = [oms] ? agent The Oracle base for ORACLE_HOME=/opt/oracle/product/OEM/agent11g is … $ emctl stop agent Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0 Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved. Stopping agent ... stopped. $ emctl start agent Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0 Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved. Starting agent ............. started. $ . oraenv ORACLE_SID = [agent] ? oms The Oracle base for ORACLE_HOME=/opt/oracle/product/OEM/oms11g is… $ emctl stop oms Oracle Enterprise Manager 11g Release 1 Grid Control Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved. Stopping WebTier... WebTier Successfully Stopped Stopping Oracle Management Server... Oracle Management Server Successfully Stopped Oracle Management Server is Down $ emctl start oms Oracle Enterprise Manager 11g Release 1 Grid Control Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved. Starting WebTier... WebTier Successfully Started Starting Oracle Management Server... Oracle Management Server Successfully Started Oracle Management Server is Up

Damit verfügen Sie über eine voll funktionsfähige Umgebung des Enterprise Manager Grid Control. Für die Hinzunahme weiterer Ziele muss der EM-Agent auf den Zielservern installiert werden. Mithilfe des Registration-Passworts meldet er sich am Management Server an und lädt Informationen hoch. 2.13.1.3

Der Enterprise Manager im Einsatz

Das Layout der Webseiten sowie der Funktionalität wurden zwischen dem EM Database Control und dem EM Grid Control weitgehend angeglichen. Sie können deshalb die Aussagen dieses Abschnitts zu großen Teilen auf beide Produkte anwenden. Natürlich fehlen im Enterprise Manager Database Control die Features und Komponenten, die mit der GridFunktionalität sowie der Architektur des Enterprise Manager Grid Control zusammenhängen. An wichtigen Stellen weisen wir auf die Unterschiede hin. Wie bereits erwähnt, kann im Enterprise Manager Grid Control eine Vielzahl von Zielen eingebunden werden, deren Produkte nicht ausschließlich von Oracle stammen. Wir wollen uns an dieser Stelle auf Zieltypen beschränken, die sich im direkten Umfeld der OracleDatenbank befinden. Das sind: die Oracle-Datenbank sowie deren Instanzen  der Oracle Listener  die Grid-Infrastruktur mit der ASM-Instanz 

160

2.13 Verwaltungswerkzeuge der Datenbankserver  der Oracle Agent  Die Funktionalität des Enterprise Managers wurde in den vergangenen Jahren permanent erweitert. Neben der Verwaltung der Ziele mit ihren zahlreichen Funktionen bietet der Enterprise Manager viele zusätzliche Funktionen und Komponenten. Eine komplette Beschreibung würde den Rahmen dieses Kapitel sprengen. Wir beschränken uns deshalb auf Funktionen, die für die tägliche Arbeit des Datenbank-Administrators essenziell benötigt werden. Datenbank-Administration mit dem Enterprise Manager Der Enterprise Manager ist die beste Alternative für die Datenbank-Administration. Er enthält alle Features und erscheint zeitnah zu den neuen Datenbank-Versionen. Sie finden alle registrierten Datenbanken im Register „Targets“ unter „Databases“. Wenn Sie keine weiteren Datenbanken registriert haben, erscheint dort nur die Repository-Datenbank des Enterprise Manager Grid Control. Im Enterprise Manager Database Control wird die Startseite der Datenbank direkt angezeigt. Auf der Startseite der Datenbank finden Sie neben dem allgemeinen Status Kurzinformationen über die Auslastung, eine Übersicht der Alerts, Informationen über Policy-Verletzungen sowie weitere Basisinformationen. Aufgrund der stark gewachsenen Komplexität und der hohen Anzahl von Features sind die Seiten der Datenbank inzwischen in sieben Registern zusammengefasst: Home  Performance  Availability  Server  Schema  Data Movement  Software und Support  Praxistipp Wenn Sie den Enterprise Manager lieber in deutscher Sprache verwenden wollen, können Sie diese Einstellung einfach über den Browser vornehmen. Der EM verwendet die Sprache, die als „erste“ eingestellt ist. Wählen Sie im Internet-Explorer über das Menü „Extras“ die Internetoptionen aus und klicken Sie auf den Button „Sprachen“. Verschieben Sie den Eintrag für „Deutsch“ ganz nach oben.

1. Die Seite „Performance“ Auf der Performance-Seite (siehe Abbildung 2.18) finden Sie mehrere Charts zur Systemauslastung, zu Wait Events der Datenbank sowie Links zum Automatic Workload Repository und weiteren Performance-Tools. Die Seite verfügt über eine Drill-down-

161

2 Architektur und Administration Funktionaltität. Sie können sich bis zu einzelnen Sessions und Cursorn durchklicken und damit Performance-Problemen auf den Grund gehen sowie Top-SQL-Anweisungen herausfiltern. Beachten Sie, dass für die Benutzung dieser Funktionalität das Diagnostic Pack zu lizenzieren ist. Über die Links unter den Charts können Sie nach Sessions suchen sowie Locks und blockierende Locks finden.

Abbildung 2.18 Die Performance-Seite des Enterprise Managers

2. Die Seite „Availability“ Unter dem Register „Availability“ finden Sie alle Features rund um die Themen Hochverfügbarkeit, Data Guard sowie Backup and Recovery. Sie können zum Beispiel ein RMAN-Backup einrichten und planen. 3. Die Seite „Server“ Auf der Seite „Server“ finden Sie alle Features, die mit dem RDBMS-Server sowie seiner Konfiguration zu tun haben, mit Ausnahme von Aktivitäten, die sich direkt auf ein Datenbank-Schema beziehen.

162

2.13 Verwaltungswerkzeuge Praxistipp Auf vielen Seiten finden Sie den Button „Show SQL“. Damit können Sie sich parallel die SQLAnweisung anzeigen lassen, die der Enterprise Manager an die Datenbank sendet und so Ihre SQL-Kenntnisse vertiefen oder bei Unklarheiten die Syntax erfragen. Eine weitere Option ist, diese SQL-Anweisung auf mehrere Datenbanken anzuwenden (gilt nur für den Enterprise Manager Grid Control). In Abbildung 2.19 sehen Sie ein Beispiel für das Anlegen eines Tablespace.

Abbildung 2.19 Eine SQL-Anweisung im Enterprise Manager anzeigen lassen

4. Die Seite „Schema“ Ergänzend zur Seite „Server“ finden Sie unter dem Register „Schema“ alle Links zur Bearbeitung von Schemata in der Datenbank, bis hin zur XML-Datenbank. Aufgrund der HTML-Architektur ist das Browsen durch die Objekte eines Schemas teilweise etwas schwerfällig und andere Werkzeuge wie der SQL Developer oder Toad sind besser geeignet. 5. Die Seite „Data Movement“ Auf dieser Seite finden Sie alle Features zum Datenaustausch von Daten zwischen Datenbanken, angefangen von Export und Import, über das Transportable Tablespace Feature, das Clonen von Datenbanken bis hin zur Advanced Replication und zur Replikation mit Oracle Streams. 6. Die Seite „Software and Support“ Im Bereich „Software and Support“ befinden sich die Features zur Konfiguration der Zielsysteme. Hier können Sie Ziele vergleichen, clonen sowie die Konfiguration prüfen. Es besteht die Möglichkeit, Patches auf mehrere Systeme auszurollen. Weiterhin finden Sie einen Link zur Support Workbench. Monitoring mit dem Enterprise Manager Die Überwachung von Datenbanken sowie deren Komponenten ist ein wichtiger Bestandteil der täglichen Tätigkeiten des Datenbank-Administrators. Schließlich will man rechtzeitig wissen, wenn ein Tablespace oder ein Dateisystem volllaufen oder die Systemressourcen knapp werden.

163

2 Architektur und Administration Der Oracle Enterprise Manager verfügt über ein eingebautes Monitoring, das direkt verwendet werden kann, das so genannte Out-of-Box-Monitoring. Die Einstellung der Schwellenwerte („Warning“ und „Critical“) erfolgt mithilfe von Metriken. Für jede vordefinierte Metrik können die Schwellwerte festgesetzt werden. Wenn Sie keine passende Metrik finden, können Sie eine benutzerdefinierte Metrik erstellen, zum Beispiel mit einer SQLAnweisung. Klicken Sie im Bereich „Related Links“ auf den Link „Metric and Policy Settings“. Hier finden Sie für die Datenbank vordefinierte Metriken und deren Schwellwerte und können diese verändern.

Abbildung 2.20 Metriken und Schwellwerte im Enterprise Manager verwalten

Für die Verwaltung von vielen Targets wäre das Anpassen der Metriken und Schwellwerte für jedes einzelne Zielsystem über die grafische Oberfläche recht zeitaufwendig. Aus diesem Grund können Monitoring Templates eingesetzt werden. Diese Templates können dann direkt auf mehrere Zielsysteme angewandt werden. Änderungen, die Sie nachträglich im Template vornehmen, können ebenfalls auf alle Zielsysteme eines Typs angewandt werden. Das vereinfacht die nachträgliche Hinzunahme von Metriken oder die Änderung von Schwellwerten.

164

2.13 Verwaltungswerkzeuge Klicken Sie auf den Link „Setup“ in der rechten oberen Ecke und wählen Sie „Monitoring Templates“ aus. Klicken Sie auf den Button „Create“. Wählen Sie ein repräsentatives Zielsystem aus, zum Beispiel eine Datenbank. Vergeben Sie danach einen Namen für das Template. Anschließend können die Metriken und deren Schwellwerte festgelegt werden.

Abbildung 2.21 Ein Monitoring Template einrichten

Klicken Sie auf den Button „Apply“, um das Template auf Zielsysteme anzuwenden. Wählen Sie über den Button „Add“ die Zielsysteme aus und bestätigen Sie mit „OK“.

Abbildung 2.22 Ein Monitoring Template anwenden.

165

2 Architektur und Administration

Abbildung 2.23 Eine Schwellenwertverletzung im Enterprise Manager

Kommt es zu Verletzungen von Schwellenwerten, sind diese auf der Startseite des Zielsystems sichtbar. Durch Klicken auf den Link erhalten Sie alle Details zur SchwellenwertVerletzung (siehe Abbildung 2.23). Alerts können bestätigt werden, bleiben jedoch so lange im Enterprise Manager sichtbar, bis das Problem behoben ist. Ein Löschen oder Ausblenden von Alerts ist nicht möglich. Zusätzlich können Sie im Enterprise Manager ein Benachrichtigungssystem einrichten, um bei Aufkommen von Alerts E-Mails oder SMS an Administratoren und Verantwortliche zu senden. Klicken Sie dazu auf „Setup“ und wählen Sie „Notification Methods“. Geben Sie auf dieser Seite die Parameter für den Mailserver ein.

Abbildung 2.24 Die Anbindung zu einem Mailserver einrichten

166

2.13 Verwaltungswerkzeuge Das E-Mail-Format kann über den Menüpunkt „E-Mail Customization“ angepasst werden. Die Benachrichtigung erfolgt über festgelegte Regeln. Diese finden Sie über den Link „Preferences“ unter dem Punkt „Notification Rules“ (Abbildung 2.25).

Abbildung 2.25 Notification Rules im Enterprise Manager

Die Designer des Entperprise Managers haben auch daran gedacht, dass es unterschiedliche Supportzeiten für unterschiedliche Datenbanken gibt (Abbildung 2.26, nächste Seite). Wie Sie feststellen konnten, bietet der Enterprise Manager die Möglichkeit, mit wenigen „Klicks“ ein Monitoring- und Benachrichtigungssystem aufzusetzen. Es gibt darüber hinaus noch mehr Möglichkeiten, zu individualisieren und mit Gruppen zu arbeiten. Hinzuzufügen bleibt noch, dass der Enterprise Manager Grid Control über eine eigene Benutzerverwaltung verfügt. Dem Benutzer können verschiedene Rollen zugewiesen werden. Der Benutzer „SYSMAN“ besitzt die Rolle „Superuser“.

167

2 Architektur und Administration

Abbildung 2.26 Die Benachrichtigungszeiten festlegen

Das Job-System des Enterprise Managers Für das Betreiben von Datenbanken ist das regelmäßige Ausführen von Jobs eine notwendige Voraussetzung. Häufig werden dafür Cron-Jobs oder Windows-Jobs verwendet, mit dem Nachteil, dass die Log-Dateien auf den Zielsystemen verteilt sind und die Kontrolle auf erfolgreiche Ausführung sehr aufwendig werden kann. Das Job-System des Enterprise Managers bietet den Vorteil, dass die Ergebnisse und LogDateien an zentraler Stelle verfügbar sind. Damit erhalten Sie ohne großen Aufwand eine Übersicht, welche Jobs Probleme hatten. Das hier beschriebene Job-System ist Bestandteil des Enterprise Manager Grid Control und im EM-Database-Control nicht enthalten. Laufende Jobs können unterbrochen und wieder aufgenommen werden, fehlgeschlagene wiederholt werden. Jobs können auf verschiedenen Zielsystemen laufen, angefangen von der Datenbank bis hin zum Datenbank-Server, also im Betriebssystem. Damit ein Job auf einer Datenbank oder in einem Betriebssystem laufen kann, muss er sich dort mit einem Account anmelden können. Diese Informationen können entweder dem Job bei der Erstellung direkt mitgegeben werden oder als Standard-Voreinstellung im Enterprise Manager gespeichert werden. Klicken Sie zum Speichern der Voreinstellung auf „Preferences“ und wählen Sie „Preferred Credentials“. Auf dieser Seite finden Sie eine

168

2.13 Verwaltungswerkzeuge Liste aller verwendeten Ziel-Typen. Klicken Sie auf „Database Instance“, um die Voreinstellung für Datenbanken vorzunehmen. Hier gibt es die Möglichkeit, einen StandardBenutzernamen für alle Datenbanken festzulegen und diesen für einzelne Datenbanken zu überschreiben.

Abbildung 2.27 Preferred Credentials im Enterprise Manager setzen

Mit den folgenden Schritten wird ein Job zum Erstellen einer Datenbank-Sicherung mit dem Recovery Manager eingerichtet. Wählen Sie das Register „Jobs“. Markieren Sie in der Drop-down-Liste „Create Job“ den Eintrag „RMAN Script“ und klicken Sie auf „Go“. Vergeben Sie einen Job-Namen und fügen Sie die Datenbank als Ziel hinzu. Geben Sie unter „Parameters“ das folgende RMAN-Skript ein. run { backup database format ‘/opt/oracle/backup/%U.bckp’; }

Überschreiben Sie die Credentials mit dem SYS-Account der Datenbank. RMAN-Skripte können nur unter dem User „SYS“ laufen. Im Register „Schedule“ können Sie die Ausführungszeiten des Jobs festlegen (siehe Abbildung 2.28, nächste Seite). Im Beispiel läuft der Job täglich um 16:00 Uhr. Klicken Sie auf „Submit“, um den Job einzureichen. Sie können den Status jederzeit auf der Job-Seite abfragen. Der Job besitzt zunächst den Status „Scheduled“, nach der Ausführung den Status „Succeeded“. Die Logdatei kann direkt im Enterprise Manager eingesehen werden (Abbildung 2.29, nächste Seite). Auf der Webseite lassen sich fehlgeschlagene Jobs gezielt anzeigen. Das Job-System kann in das Monitoring eingebunden werden, so dass eine Benachrichtigung erfolgt, wenn ein Job fehlgeschlagen ist.

169

2 Architektur und Administration

Abbildung 2.28 Die Ausführungszeiten eines Jobs festlegen

Abbildung 2.29 Die Logdatei des Jobs im Enterprise Manager

170

2.13 Verwaltungswerkzeuge

2.13.2 Der Oracle SQL Developer Der Oracle SQL Developer ist ein kostenfreies Java-Programm und besonders für Datenbank-Administratoren mit einem starken Entwickler-Hintergrund geeignet. Während der Oracle Enterprise Manager sehr stark auf die Administration ausgerichtet ist, findet der SQL Developer überall da Einsatz, wo Administratoren Unterstützung für Entwickler leisten oder selbst entwickeln. Der SQL Developer unterstützt die Datenbanken Oracle, Times Ten und Microsoft Access. Für das Herstellen der Verbindung zur Datenbank kann zwischen folgenden Methoden gewählt werden: TNS: Zugriff über einen Oracle Client und einen Eintrag in der Datei „tnsnames.ora“.  Einfach: Oracle Easy Connect / Thin JDBC unter Angabe von Hostname, Port und SID  order Servicename. LDAP: Namensauflösung über einen LDAP-Server.  Erweitert: Angabe einer benutzerdefinierten URL für die JDBC-Verbindung.  Wählen Sie für das Erstellen einer neuen Verbindung die Option „Datenbankanmeldung“ über die Menüpunkte „Datei“ und „Neu“ aus. Geben Sie einen frei wählbaren Verbindungsnamen sowie Benutzername und Passwort ein. Nach Auswahl des Verbindungstyps können Sie die Parameter für die Verbindung zur Datenbank eingeben (siehe Abbildung 2.30).

Abbildung 2.30 Anmeldung mit dem SQL Developer an einer Oracle-Datenbank

171

2 Architektur und Administration Die Verbindungen werden im linken Fenster gespeichert, das gleichzeitig als SchemaBrowser fungiert. Es werden die Objekte des angemeldeten Schemas angezeigt. Die Objekte anderer Schemata finden Sie unter dem Zweig „Andere Benutzer“ (siehe Abbildung 2.31).

Abbildung 2.31 Die Schemata anderer Benutzer

SQL-Befehle können im SQL-Arbeitsblatt ausgeführt werden. Ergebnisse von SELECTAnweisungen werden in Tabellenform im Ausgabefenster dargestellt. Über einen Button im SQL-Arbeitsblatt oder die Funktionstaste F10 können Sie sich den Explain-Plan einer SQL-Anweisung anzeigen lassen (siehe Abbildung 2.32).

Abbildung 2.32 Den Explain-Plan einer SQL-Anweisung anzeigen

172

2.13 Verwaltungswerkzeuge Hinweis Beachten Sie, dass es sich bei der SQL-Schnittstelle im SQL Developer nicht um natives SQL*Plus handelt. Insbesondere SET-Anweisungen werden ignoriert. SQL-Skripte werden deshalb in der Regel nicht im SQL-Arbeitsblatt laufen. Allerdings führen solche Befehle nicht zum Abbruch, sie werden ignoriert: Zeile 1: SQLPLUS-Befehl übersprungen: SET LINESZIZE 100

Im SQL-Developer ist eine DDL-Funktionalität integriert, mit deren Hilfe DDL-Code generiert werden kann. Markieren Sie ein oder mehrere Objekte im Schema-Browser und wählen Sie „DDL exportieren“ über das Kontext-Menü, das Sie mit der rechten Maustaste erhalten. Interessant für Entwickler von PL/SQL-Code ist der eingebaute Debugger (siehe Abbildung 2.33). Klicken Sie mit der rechten Maustaste auf den Namen der Prozedur oder Funktion im Schema-Browser und wählen Sie im Kontext-Menü „Zum Debuggen kompilieren“ aus. Setzen Sie die Breakpoints im Codefenster durch Anklicken der Zeile. Die Zeile wird als Breakpoint markiert. Klicken Sie dann auf das Icon „Debuggen“. Der Debug-Lauf wird damit gestartet und die Ausführung am Breakpoint angehalten. Über die Menüpunkte „Ansicht“ und „Debugger“ können Sie die Werte von Variablen am Breakpoint anschauen und über den Menüpunkt „Ausführen“ die weitere Bearbeitung steuern.

Abbildung 2.33 Der PL/SQL-Debugger im SQL Developer

173

2 Architektur und Administration Unter dem Menüpunkt „Extras“ finden Sie eine Reihe von nützlichen Werkzeugen: Mit „Datenbank-Diff“ lassen sich Objekte von Schemata in zwei Datenbanken vergleichen. Dies ist hilfreich, wenn man zum Beispiel die Unterschiede zwischen einer Test- und einer Produktionsdatenbank herausfinden will.

Abbildung 2.34 Der Bericht des Diff-Werkzeugs im SQL Developer

Mit dem Export-Werkzeug kann der gesamte DDL-Text der Datenbank oder ausgewählter Objekte und Schemata in eine SQL-Datei exportiert werden. Damit können Objekte von einer Datenbank in eine andere übertragen werden. Praxistipp Daten können im CSV-Format heruntergeladen werden. Klicken Sie mit der rechten Maustaste auf die Tabelle im Schema-Browser und wählen Sie „Exportkonfiguration“ aus dem KontextMenü aus.

Unter dem Menüpunkt „Datenbankkopie“ finden Sie ein Utility, mit dem ein Schema aus einer Datenbank in eine andere kopiert werden kann. Einen einfachen Session-Browser finden Sie unter dem Menüpunkt „Sessions überwachen“. Und schließlich ist noch eine Subversion Client-Funktionalität enthalten. Damit kann SQL-Code direkt aus dem Repository ausgecheckt und im SQL Developer verarbeitet werden. Als Fazit lässt sich feststellen, dass der Oracle SQL Developer eine ganze Reihe von nützlichen Funktionen und Utilities bietet. Er kann intuitiv bedient werden und ist sowohl für Administratoren geeignet, die Unterstützung in Richtung Applikation leisten oder ihre eigenen Utilities schreiben als auch für Entwickler, die ihre eigenen Entwicklungs-Datenbanken verwalten möchten. Und nicht zu vergessen: Er ist kostenfrei.

174

2.13 Verwaltungswerkzeuge

2.13.3 Toad Toad ist ein Werkzeug, das sowohl von Entwicklern als auch von Administratoren gleichermaßen gern benutzt wird. Für Administratoren empfiehlt sich die Lizenzierung des DBA-Moduls. In dieser Kombination kann er überall da eingesetzt werden, wo DatenbankEntwicklung geleistet wird und für die Datenbank-Administration der Oracle Enterprise Manager nicht zur Verfügung steht. Hersteller ist die Firma „Quest Software“, bei der das Produkt erworben und lizenziert werden muss. Für Testzwecke kann eine Trial-Lizenz für 30 Tage kostenlos erworben werden. Weitere Informationen finden Sie auf der Seite http://www.questsoftware.de. Im Gegensatz zum Enterprise Manager ist Toad nicht Browser-basierend, sondern besteht aus einem Client-Programm, das mit der Datenbank nach dem Client/Server-Prinzip zusammenarbeitet. Neben Editoren für SQL- und PL/SQL-Anweisungen sowie einem PL/SQL-Debugger verfügt Toad über einen Schema-Browser. Wie Sie feststellen konnten, ist der SchemaBrowser im Enterprise Manager etwas holprig zu bedienen, was natürlich in erster Linie daran liegt, dass der Enterprise Manager Browser-basierend ist. Toad stellt an dieser Stelle eine sinnvolle Ergänzung dar. Der Schema-Browser ist flott zu bedienen und hält eine Reihe nützlicher Features bis zum DDL-Skript bereit.

Abbildung 2.35 Der Schema-Browser im Toad

175

2 Architektur und Administration Das DBA-Modul finden Sie unter dem Menüpunkt „Database“. Hier ist insbesondere der Session-Browser zu empfehlen, der über das Untermenü „Monitor“ gestartet werden kann. Der Einstieg in den Session-Browser kann über das linke Fenster erfolgen. Die Sessions sind nach Programmen sortiert. Zusätzlich können Sie Filter setzen, um bestimmte Sessions herauszustellen. Im rechten Fenster finden Sie detaillierte Informationen zur ausgewählten Session, wie das aktuelle Statement, Wait Events, Locks, lang laufende Operationen und den Ausführungsplan der aktuellen Anweisung (siehe Abbildung 2.36).

Abbildung 2.36 Der Session-Browser im Toad

Ein anderer Einstiegspunkt in den Session-Browser sind die Wait Events der Datenbank. Wählen Sie das Register „Waits“ und sortieren Sie die Events nach Wartezeit. Im unteren Fenster bekommen Sie alle Sessions angezeigt, die zu diesem Event gehören. Die Informationen beziehen sich auf die letzten 60 Sekunden und liefern die Werte aus den Performance Views von „Active Session History“ (siehe Abbildung 2.37). Hilfreiche Zahlen und Charts für Performance-Analysen erhalten Sie aus dem AWRBrowser, den Sie über die Menüpunkte „Database“ und „Monitor“ erreichen. Damit lässt sich eine historische Analyse basierend auf AWR-Snapshots durchführen (siehe Abbildung 2.38). Markieren Sie die Snapshots und wählen Sie die Charts aus. Praxistipp Besonders positiv an Toad ist, dass es noch immer über einen Statspack-Browser verfügt, den Sie sich als Analogon zum AWR-Browser vorstellen können. Wenn Sie also das PerformancePack nicht lizenzieren wollen und dafür Statspack einsetzen, erhalten Sie Unterstützung durch Toad.

176

2.13 Verwaltungswerkzeuge

Abbildung 2.37 Der Session-Browser nach Wait Events

Abbildung 2.38 Der AWR-Browser im Toad

177

2 Architektur und Administration

2.14

Resümee In diesem Kapitel haben wir die Architektur einer Oracle-Datenbank behandelt. Sie kennen nun physische Datenbankstrukturen und Befehle zur Verwaltung, die im Alltag eines DBAs unabdingbar sind. Grafische Werkzeuge wie Enterprise Manager Database Control, Grid Control und SQL Developer erleichtern die Administration. Damit haben Sie das Rüstzeug, eine Oracle-Datenbank zu verwalten. Im nächsten Kapitel gehen wir auf Datenbankobjekte wie Tabellen, Views und Indizes, Sequenzen und Datenbank Links ein, und zeigen Ihnen die interne Speicherorganisation sowie deren Konfiguration.

178

3 3 Verwaltung von Datenbankobjekten In diesem Kapitel zeigen wir Ihnen:

 wie Objekte wie Tabellen, Views und Indizes gespeichert werden;  welche Konfigurationsmöglichkeiten es gibt;  welche Datentypen und welche Zeichensätze unterstützt werden;  wie man Sequenzen, Datenbank-Links, Synonyme und PL/SQL-Programme administriert. Zunächst beschreiben wir die Verwaltung von Objekten, die in einer Datenbank gespeichert werden. Versierte DBAs können diesen Teil überspringen. Zunächst lernen Sie Schemata zur logischen Separierung von Objekten kennen. Wir erläutern die Regeln für Bezeichner für Objekt-Namen. Im Anschluss finden Sie Informationen zur Speicherhierarchie, insbesondere zu Segmenten und Extents. Sie erfahren einiges über den Datenbankzeichensatz und erhalten eine Übersicht der in Oracle verfügbaren Datentypen. Im zweiten Teil des Kapitels gehen wir auf die konkrete Verwaltung von Datenbankobjekten ein. Wir starten mit Tabellen und stellen Ihnen verschiedene Speicherorganisationen vor, darunter Heap Tables, Index Organized Tables (IOTs), geclusterte Tabellen, Tabellenpartitionierung sowie externe Tabellen und Temporär-Tabellen. Ein weiteres wichtiges Thema sind Standard Views, Materialized Views und Object Views. Weiterhin stellen wir Ihnen Indextypen wie den B*-Tree-Index, den Bitmap-Index, den Reverse Key-Index und den Functions Based-Index vor. Abschließend gehen wir auf Objekte wie Synonyme, Datenbank Links, Sequenzen und PL/SQL-Programme ein. Alle Abschnitte enthalten die passenden Administrationsbefehle.

3.1

Benutzer und Schemata Jedes Objekt, das in einer Oracle-Datenbank erstellt wird, liegt in einem Schema eines Benutzers. Der Schema-Name dient hier als logische Strukturierung. Er wird dem Objektnamen vorangestellt:

179

3 Verwaltung von Datenbankobjekten CREATE TABLE

a_schmidt.t_kunde (id_kunde nachname vorname

NUMBER, VARCHAR2(30), VARCHAR2(20));

INSERT INTO VALUES

a_schmidt.t_kunde (id_kunde, nachname, vorname) ( 90212, 'Milller', 'Joanna');

SELECT * FROM a_schmidt.t_kunde;

Wird auf ein Objekt im eigenen Benutzerschema zugegriffen, ist keine vollqualifizierte Referenzierung erforderlich: Der Schema-Name kann dann entfallen. CREATE TABLE

t_kunde(id_kunde NUMBER, nachname