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!
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.
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
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
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
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
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
Ü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
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:
*) 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: # # # # #
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:
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
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)
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
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
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
Default-Tablespaces eines Benutzers Welche Tablespaces als Standard- bzw. Temporary Tablespaces einem Benutzer zugewiesen wurden, zeigt die View dba_users: SELECT FROM ORDER BY
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;
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";
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
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
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
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:
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
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
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
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 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;
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
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
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
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
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
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:
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
Ü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
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
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:
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
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
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:
Wird auf ein Objekt im eigenen Benutzerschema zugegriffen, ist keine vollqualifizierte Referenzierung erforderlich: Der Schema-Name kann dann entfallen. CREATE TABLE
Vollqualifizierte Objektnamen müssen innerhalb einer Datenbank eindeutig sein. So kann man mehrere Objekte mit dem Namen „t_kunde“ in verschiedenen Schemata, jedoch nicht innerhalb desselben Schemas erstellen.
3.2
Bezeichner Ein Bezeichner ist ein Name für ein Datenbankobjekt. Dazu zählen Schema-Namen, Namen für Tabellen, Indizes, Views und Constraints, PL/SQL-Programme sowie Benutzernamen, Namen für Rollen und Profile. Bezeichner können mit oder ohne Anführungszeichen (Quotes) verwendet werden. Die Interpretation unterscheidet sich, je nachdem ob ein Bezeichner mit oder ohne Quotes angegeben wurde. SELECT * FROM "t_kunde"; SELECT * FROM t_kunde;
-- Objektname mit Quotes -- Objektname ohne Quotes
In der Regel werden Bezeichner ohne Quotes angegeben. Dann gelten folgende Restriktionen:
Bezeichner ohne Anführungszeichen sind im Data Dictionary der Datenbank stets in Großbuchstaben gespeichert.
In SQL-Statements wird der ohne Anführungszeichen angegebene Bezeichner stets nicht Case-sensitiv interpretiert. Im Data Dictionary der Datenbank ist er jedoch in Großschreibung gespeichert.
Bezeichner ohne Anführungszeichen dürfen nicht mit Schlüsselwörtern übereinstimmen.
Bezeichner müssen mit einem Zeichen des Alphabetes beginnen, das vom eingesetzten Zeichensatz unterstützt wird.
Neben alphanumerischen Zeichen dürfen Unterstriche (_), Dollarzeichen ($) und Rauten (#) im Objektnamen enthalten sein. Namen von Datenbanklinks dürfen den Punkt (.) sowie das At-Symbol (@) enthalten. Weitere Sonderzeichen sind in nicht quotierten
Namen von Datentypen, Schema- und Funktionsnamen, der Name der Dummy-Tabelle dual, Bestandteile von SQL-Befehlen sowie Wörter mit spezieller Bedeutung wie „dimension“, „segment“, „allocate“ oder „disable“ sind ebenfalls nicht zulässig. Diese sind zwar nicht reserviert, werden jedoch teilweise intern genutzt. Insbesondere sollte auf Objektnamen verzichtet werden, die mit „SYS_“ oder „ORA_“ beginnen. Die Verwendung dieser Namensbestandteile in Objektnamen kann zu nicht vorhersagbaren Resultaten führen.
Bei Quotes sind Sonderzeichen, Leerzeichen und sogar reservierte Schlüsselwörter1 in Objektnamen möglich. Zudem werden Objektnamen in Quotes Case-sensitiv behandelt. Allgemein gilt für Objektnamen mit oder ohne Quotes: Objektnamen können zwischen 1 und 30 Bytes belegen. Ausnahmen bilden Datenbanknamen, die bis zu 8 Byte lang sein dürfen sowie Namen von Datenbank-Links, die bis zu 128 Byte belegen können. Folgende Objektnamen sind gültig: KUNDE Nachname schmidt.mitarbeiter „Dies & jenes!“
Der folgende Objektname ist nicht gültig, da er die Grenze von 30 Byte übersteigt: Ein_zu_langer_Objektname_ist_ungueltig
3.3
Speicherhierarchie Der folgende Abschnitt erläutert die logischen Speicherstrukturen einer Oracle-Datenbank. Dazu zählen:
Datenblöcke: Oracle-Datenbanken speichern Daten in Datenblöcken. Ein Datenblock ist die kleinste allokierbare Einheit2.
Extents: Ein Extent ist eine Speichereinheit, die aus einer Anzahl logisch fortlaufender Datenblöcke besteht. Oracle-Objekte allokieren Speicherplatz stets in Form von Extents.
Segmente: Als Segment wird die Gesamtheit aller Extents bezeichnet, die zu einem Objekt – beispielsweiese einer Tabelle oder einem Index – gehören. Oracle kennt verschiedene Segmenttypen. Dazu zählen Tabellen- und Index-Segmente sowie Undound Temporärsegmente.
Tablespaces: Eine Oracle-Datenbank unterteilt sich in verschiedene logische Speicherbereiche, die Tablespaces. Ein Tablespace ist ein logischer Container für die Speiche1
Innerhalb von Quotes sind Schlüsselwörter zwar als Objektname möglich, wir raten jedoch dringend davon ab. 2 Siehe auch Abschnitt 2.2.1 „Datenblöcke“.
181
3 Verwaltung von Datenbankobjekten rung von Datenbankobjekten wie Tabellen und Indizes3. Dabei kann ein einzelner Tablespace die Speicher-Segmente von keinem, einem oder mehreren Datenbankobjekten aufnehmen. Umgekehrt ist ein Segment stets in genau einem Tablespace abgelegt. Logisch
Physisch
Tablespace
Datafile
Segment
Extent
Datenblock
BetriebssystemBlock
Abbildung 3.1 Speicherhierarchie in OracleDatenbanken
Extents und Segmente Ein Extent ist ein Set zusammenhängender Datenblöcke. Beim Erstellen eines Datenbankobjekts wie beispielsweise einer Tabelle oder ein Index wird mit der Speicherung des ersten Datensatzes ein erstes Extent in einem Tablespaces allokiert4. Füllt sich der Speicherplatz in diesem Extent und reicht für die Speicherung neuer Daten nicht mehr aus, so wird ein nächstes Extent allokiert und so fort. Die Gesamtheit aller Extents, die zu einem Datenbankobjekt wie beispielsweise einer Tabelle oder einem Index gehören, heißt Segment. Oracle kennt verschiedene Segmenttypen:
Tabellensegmente: In einem Tabellensegment sind die Daten einer Datenbanktabelle gespeichert.
Indexsegmente: Ein Indexsegment speichert die Informationen eines Datenbankindex. Temporärsegmente: Temporärsegmente werden dann gespeichert, wenn die Ausführung eines SQL-Statements vorübergehend Plattenplatz erfordert. So können beispielsweise große Sortieroperationen oft nicht komplett im Arbeitsspeicher ausgeführt werden. In diesem Fall wird in ein Temporärsegment ausgelagert. Vergleichbar ist dieser 3 4
182
Siehe auch Abschnitt 2.2.3 „Tablespaces“. In Releases vor 11g R2 wird bereits Speicherplatz beim Anlegen eines Objekts durch ein erstes Extent belegt – und zwar auch dann, wenn noch keine Datenzeile gespeichert wurde!
3.4 Zeichensätze Vorgang mit der Nutzung von Swap Space eines Betriebsystems. Der Speicher wird nach Beendigung des SQL-Statements wieder freigegeben.5
Undo- bzw. Rollbacksegmente: Eine spezielle Rolle spielen die Undo-Segmente bzw. Rollbacksegmente. Im Falle einer Datenänderung an einer Tabellenzeile wird ein Before Image, ein Abbild der Werte vor der Datenänderung in ein Undo-Segment kopiert6.
3.4
Zeichensätze Der Standard-Zeichensatz sowie der erweiterte nationale Zeichensatz (National Characterset) wird während der Erstellung der Datenbank festgelegt7. Der Standard-Zeichensatz gilt für Datentypen wie Char, Varchar2 und CLOB, der nationale Zeichensatz für Datentypen wie NChar, NVarchar2 und NCLOB. Den Standard-Zeichensatz Ihrer Datenbank ermitteln Sie mit folgender Abfrage: SELECT * FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';
Folgende Abfrage gibt den für Ihre Datenbank eingestellten nationalen Zeichensatz aus: SELECT * FROM nls_database_parameters WHERE parameter = 'NLS_NCHAR_CHARACTERSET';
Praxistipp Oracle-Datenbanken bieten gute Möglichkeiten, nahezu alle erdenklichen Sprach- und Zeichensysteme abzubilden. Problematisch wird es erst dann, wenn bereits eine Datenbank betrieben wird und nachträglich die Notwendigkeit besteht, auf einen anderen Zeichensatz zu migrieren. Der Wechsel des Zeichensatzes einer Datenbank ist eine tief greifende Änderung. Wir empfehlen deshalb, vor der Erstellung der Datenbank den Zeichensatz festzulegen. Sofern zukünftig weitere Sprachen erforderlich sind, sollten diese möglichst schon im ausgewählten Character Set vorhanden sein.
Empfehlungen zur Wahl des Zeichensatzes Single Byte Character Sets bieten bessere Performance und brauchen weniger Speicherplatz als Multi Byte Character Sets, begrenzen aber die Anzahl der verfügbaren Zeichen und damit die Bandbreite der zur Verfügung stehenden Sprachen.
5
Es gibt weitere Fälle, in denen Temporärsegmente angelegt werden. So sind beispielsweise die Daten einer temporären Tabelle in Temporärsegmenten gespeichert. Siehe auch Abschnitt 3.6.4 „Global Temporary Tables“. 6 Genauere Informationen hierzu finden Sie in den Abschnitten 2.4.2 „Lesekonsistenz“ und 2.4.3 „Undo Management“. 7 Siehe auch Abschnitt 1.2 „Datenbankerstellung“.
183
3 Verwaltung von Datenbankobjekten Die Zeichensätze WE8ISO8859P1 und WE8ISO8859P15 sind ISO-genormt. Bei beiden handelt es sich um Single-Byte-Zeichensätze, wobei der erste ohne Eurozeichen, der zweite mit Eurozeichen versehen ist. Beide Zeichensätze sind im deutschsprachigen Umfeld meist auf Unix-Maschinen im Einsatz. WE8MSWIN1252 ist ein Zeichensatz, der auf Microsoft-Betriebssystemen häufig eingesetzt wird. Er ist ein binäres Superset von WE8ISO8859P18 sowie ein logisches Superset von WE8ISO8859P159. US7ASCII ist ein Single-Byte-ASCII-Zeichensatz (7-bit). Er ist zur Speicherung deutschsprachiger Umlaute wie „Ä“, „Ö“ und „Ü“ sowie des Konsonanten „ß“ ungeeignet. Sofern mit Daten aus verschiedenen Sprach- und Zeichensystemen gearbeitet wird, empfiehlt sich „Unicode“, ein universaler Character Set, in dem die Zeichen jeder von Oracle unterstützten Sprache abbildbar sind. Für jedes Zeichen bietet Unicode einen eindeutig zugeordneten, binären Wert in verschiedenen Längen – zum Teil Single Byte, zum Teil Multi Byte. Unicode bildet für alle in Oracle möglichen Character Sets ein Super Set und ist damit für die Globalisierung oder Konsolidierung verschiedener Datenbanken eine sinnvolle Wahl. Der Performance-Overhead gegenüber einem reinen Single Byte Character Set liegt jedoch bei etwa 10 Prozent. Praxistipps Wenn nur einige Spalten einen erweiterten Zeichensatz benötigen, kann es eine gute Alternative sein, ein Single Byte Characterset als Basiszeichensatz zu verwenden und Spalten, die einen erweiterten Zeichensatz benötigen, als „Nchar“, „NVarchar2“ und „NCLob“ zu definieren. Der Zeichensatz WE8ISO8859P1 sollte für neue Datenbanken nicht verwendet werden, da ihm das Euro-Zeichen fehlt. Sofern alle Clients Unix-basiert sind und den Zeichensatz ISO-8859-P15 nutzen, kann man sowohl WE8ISO8859P15 als auch WE8MSWIN1252 als Standard-Datenbankzeichensatz einsetzen. Sofern auch Windows-basierte Clients mit der Datenbank arbeiten, ist der Zeichensatz WE8MSWIN1252 vorzuziehen – und zwar auch dann, wenn die Datenbank auf einer UnixMaschine läuft! Hintergrund: Windows-Clients können mit WE8MSWIN1252 unter anderem auch Zeichen nutzen, die in WE8ISO8859P15 nicht kodierbar sind. Diese Zeichen werden bei einer Speicherung in der Datenbank als umgekehrtes Fragezeichen dargestellt. Werden webbasierte Clients eingesetzt, empfiehlt sich der Einsatz eines Unicode-Zeichensatzes. Sofern ein Mix aus webbasierten und nicht webbasierten Clients mit der Datenbank arbeitet, ist ein Unicode-Zeichensatz ebenfalls vorzuziehen.
8
Alle Zeichen, die in WE8ISO8859P1 belegt sind, werden in exakt der gleichen Weise in WE8MSWIN1252 kodiert. WE8MSWIN1252 kodiert jedoch 28 zusätzliche Zeichen, die in WE8ISO8859P1 nicht enthalten sind. 9 Alle Zeichen des Satzes WE8ISO8859P15 werden auch in WE8MSWIN1252 abgebildet. Jedoch gibt es in der Binärkodierung an acht Stellen Unterschiede.
184
3.5 Datentypen Zusammengefasst:
Sofern ausschließlich westeuropäische Zeichen gespeichert werden, ist WE8MSWIN1252 die beste Wahl – gleich ob Unix- oder Windows-Clients auf die Datenbank zugreifen und gleich ob die Datenbank auf einem Windows- oder Unix-System betrieben wird.
Sofern nicht sichergestellt ist, dass nur westeuropäische Zeichen in der Datenbank gespeichert sind, sollte man auf einen Unicode-Zeichensatz zurückgreifen. Die View v$nls_valid_values zeigt die Zeichensätze, die Ihr Oracle-Release generell unterstützt: SELECT value FROM v$nls_valid_values WHERE parameter ='CHARACTERSET' ORDER BY 1;
Datentypen Tabellen speichern Tupel einer Relation. Ihre Attribute sind durch einen Datentyp bestimmt. Tabelle 3.1 zeigt eine Übersicht der hierfür verwendbaren Oracle Built-in-Datentypen. Tabelle 3.1 Oracle Built-in-Datentypen
Code10 Datentyp
Beschreibung
1
VARCHAR2(n [BYTE | CHAR])
Zeichenkette variabler Länge bis zu n Zeichen oder Byte im Standardzeichensatz der Datenbank
1
NVARCHAR2(n)
Zeichenkette variabler Länge bis zu n Zeichen im nationalen Zeichensatz der Datenbank.
96
CHAR [(n [BYTE | CHAR])]
Zeichenkette fester Länge mit genau n Zeichen im Standardzeichensatz der Datenbank
96
NCHAR[(n)]
Zeichenkette fester Länge mit genau n Zeichen im nationalen Zeichensatz der Datenbank.
8
LONG
Zeichenkettendaten variabler Länge bis zu 2 -1 Bytes Länge (2 GB). Dieser Datentyp gilt als veraltet, wird jedoch zwecks Abwärtskompatibilität weiter bereitgestellt.
2
NUMBER [ (p [, s]) ]
Zahlenwerte zwischen 10-130 bis unterhalb 10126
2
FLOAT [(b)]
Gleitkommazahl mit der Binärpräzision b. Subtyp von Number: Float wird datenbankintern als NUMBER gespeichert.
10
31
Der Code eines Datentyps wird intern verwendet. Die Funktion DUMP zeigt diesen als Rückgabewert.
185
3 Verwaltung von Datenbankobjekten Code11 Datentyp
Beschreibung
21
BINARY_FLOAT
32-Bit Floating Point
22
BINARY_DOUBLE
64-Bit Floating Point
12
DATE
Datum und Uhrzeit sekundengenau
180
TIMESTAMP [(fractional_ seconds_precision)]
Datum und Uhrzeit inklusive Sekundenbruchteilen
181
TIMESTAMP [(fractional_ seconds)] WITH TIME ZONE
Wie TIMESTAMP, jedoch mit Zeitzonenverschiebung
231
TIMESTAMP [(fractional_ seconds)] WITH LOCAL TIME ZONE
Wie TIMESTAMP WITH TIMEZONE, jedoch werden die Daten beim Speichern zur Datenbankzeitzone normalisiert
182
INTERVAL YEAR [(year_precision)] TO MONTH
Zeitperiode in Jahren und Monaten
183
INTERVAL DAY [(day_precision)] TO SECOND [(fractional_seconds)]
Zeitperiode in Tagen, Stunden, Minuten, Sekunden und Sekundenbruchteilen
23
RAW(size)
Binäre Raw-Daten mit einer maximalen Größe von 2000 Bytes
24
LONG RAW
Binäre Raw-Daten variabler Länge mit einer Größe bis zu 2 GB
112
CLOB
Große Zeichenketten im Standard-Zeichensatz der Datenbank
112
NCLOB
Große Zeichenketten im nationalen Zeichensatz der Datenbank
113
BLOB
Große binäre Objekte zur Speicherung von Daten wie Bild, Ton, Dokumenten und Sheets
114
BFILE
Zeiger auf eine Binärdatei im Dateisystem
69
ROWID
Speicherung der eindeutigen Zeilenadresse
208
UROWID [(size)]
Speicherung der logischen Adresse einer Zeile in einer indexorganisierten Tabelle
3.6
Speicherorganisation von Tabellen Oracle bietet verschiedene Speicherorganisationen für Tabellen an:
Heap Tables: Speichern Daten ungeordnet Index Organizd Tables (IOTs): Nutzen eine Index-Struktur zur Speicherung und speichern Daten sortiert nach Primary Key
Object Tables: Unterstützen objektorientiere Konzepte Temporaray Tables: Speichern temporäre Zwischenergebnisse für die Dauer einer Transaktion oder einer Session
External Tables: Erlauben einen Zugriff auf strukturierte Daten (z.B. kommaseparierte Listen) im Dateisystem Eigenschaften und Administration der Speichertypen beschreiben wir in den folgenden Abschnitten. 11
186
Der Code eines Datentyps wird intern verwendet. Die Funktion DUMP zeigt diesen als Rückgabewert.
3.6 Speicherorganisation von Tabellen
3.6.1
Heap Tables
Eine Tabelle ist standardmäßig als Heap Table gespeichert. Darin sind Daten in einer ungeordneten Reihenfolge abgelegt. Der Begriff „Heap Table“ wird meist nur zur Abgrenzung gegenüber Index Organized Tables (IOTs) und External Tables verwendet. Meist spricht man einfach nur von Tabellen. Während für die Erstellung von IOTs und External Tables zusätzliche Schlüsselwörter im Create Table-Statement notwendig sind, erstellt der Standard-Create Table-Befehl stets eine Heap Table. Ein Beispiel: CREATE TABLE t_kunden (kd_nr NUMBER, nachname VARCHAR2(60), vorname VARCHAR2(20) );
Weitere Informationen zur Verwaltung von Tabellen finden Sie in Abschnitt 3.7 „Administrationsbefehle für Tabellen“. Die Zuordnung zu Tablespaces sowie die Konfiguration von Extentgrößen und des Transaktionsheaders finden Sie in den Abschnitten 3.7.8 „Eine Tabelle in einen anderen Tablespace verschieben“, 3.7.9 „Extent-Größen festlegen“ und 3.7.10 „ Einstellen der Größe des Transaktionsheaders“. Informationen zu Tabellen finden Sie in den Views ments und dba_extents12.
3.6.2
dba_tables, dba_objects, dba_seg-
Index Organized Tables (IOTs)
Eine Index Organized Table (IOT) ist intern wie ein B*-Tree-Index organisiert. Anders als Heap-Tables, die Daten in einer ungeordneten Folge speichern, sind die Daten einer IOT in der Reihenfolge des Primärschlüssels abgelegt. Die Leaf-Blöcke speichern sowohl den Primärschlüssel als auch alle weiteren Datenspalten. Die Struktur einer IOT bietet einen sehr schnellen Datenzugriff über den Primärschlüssel und mindert den Speicherverbrauch gegenüber der getrennten Speicherung eines Index und der darunterliegenden Tabelle. Für die Erstellung einer IOT ist zwingend ein Primary Key-Constraint13 erforderlich. Zusätzlich gibt die Klausel organization index die Speicherung als IOT vor. CREATE TABLE t_kunden (kd_nr NUMBER, nachname VARCHAR2(60), vorname VARCHAR2(20), CONSTRAINT pk_kunden PRIMARY KEY (kd_nr)) ORGANIZATION INDEX;
Für IOTs sind optional noch folgende Klauseln möglich:
OVERFLOW: Erlaubt die Speicherung einiger Spalten, die nicht Teil des Primary Key sind, in einem separaten Overflow-Segment, das optional auch in einem anderen Tablespace abgelegt werden kann.
PCTTHRESHOLD: Gibt an, wann ein Overflow-Segment zu nutzen ist. Der Wert definiert den Füllgrad des Index-Blockes in Prozent, der von einer Datenzeile nicht überschritten werden darf. Der Standardwert ist 50.
INCLUDING: Bestimmt, welche Spalte noch im Index-Block zu speichern ist, auch wenn es sich um keine Primary Key-Spalte handelt. Das folgende Statement erstellt eine IOT, die im Tablespace app_01_data gespeichert wird, mit einem Overflow-Segment im Tablespace app_05_data. Eine Datenzeile darf nicht mehr als 20 Prozent des Speicherplatzes im Leaf-Block belegen, die Spalte f_name ist jedoch in jedem Fall dort zu speichern. CREATE TABLE t_kunden (kd_nr NUMBER, nachname VARCHAR2(60), vorname VARCHAR2(20), bonitaetsstufe CHAR(1), rahmenvertrag_doc BLOB, CONSTRAINT pk_kunden PRIMARY KEY (kd_nr)) ORGANIZATION INDEX TABLESPACE APP_01_DATA -- IOT wird im Tablespace APP_01 gespeichert PCTTHRESHOLD 20 INCLUDING nachname OVERFLOW TABLESPACE APP_05_DATA; -- Overflow-Segment wird in APP_05 gespeichert
Für IOTs gelten folgende Restriktionen:
Sie können keine virtuellen Spalten enthalten. Die maximale Spaltenanzahl ist auf 1000 begrenzt. Es sind maximal 255 Spalten ohne Overflow Segment möglich. Bis zu 32 Spalten können in den Primary Key inkludiert werden. Der Wert für PCTTHRESHOLD muss zwischen 1 und 50 liegen, der Standardwert ist 50.
Alle Schlüsselspalten müssen innerhalb des in PCTTHRESHOLD angegebenen Werts gespeichert sein. IOTs lassen sich online ohne Downtime reorganisieren: ALTER TABLE t_kunden MOVE ONLINE;
Informationen zu IOTs finden Sie in den gleichen Views wie bei normalen Heap Tables: die Views dba_tables, dba_objects, dba_segments und dba_extents geben Auskunft über die Konfiguration14. Die Spalte iot_type der View dba_tables enthält jedoch stets den Wert 'IOT'. Zusätzlich finden Sie Informationen in der View dba_indexes. Sie entsprechen im Wesentlichen jenen anderer Indizes. Die Spalte dba_indexes.index_type zeigt jedoch den Wert 'IOT - TOP'.
14
188
Siehe Abschnitt 3.7.25 „Wichtige Rechte rund um Tabellen“.
3.6 Speicherorganisation von Tabellen
3.6.3
Object Tables
Ein Oracle Object Type speichert benutzerdefinierte Objekt-Typen mit Namen, Attributen und Methoden in Datenzeilen. Ein Beispiel: create or replace type adresse_t as object ( strasse varchar2(30), hausnr number(3), plz number(5), ort varchar2(40)); / create type personal_t as object ( nachname varchar2(40), vorname varchar2(40), geburtsdatum date, gehalt number(12,2), kinder number(2), adresse adresse_t ); / create table personal (angestellter personal_t); insert into personal values ( personal_t('Mustermann', 'Gabi', '12.101971', 5670.00, 2, adresse_t('Musterallee',1,12345,'Musterstadt')); commit; SELECT FROM WHERE
p.angestellter.nachname, p.angestellter.adresse.ort personal p p.angestellter.gehalt > 5000.00;
Auch die Implementierung von Methoden ist gestattet: CREATE OR REPLACE TYPE personen_typ AS OBJECT ( persno NUMBER, vorname VARCHAR2(20), nachname VARCHAR2(25), email VARCHAR2(25), phone VARCHAR2(20), MAP MEMBER FUNCTION get_persno RETURN NUMBER, MEMBER PROCEDURE zeige_details ( SELF IN OUT NOCOPY personen_typ )); / CREATE OR REPLACE TYPE BODY personen_typ AS MAP MEMBER FUNCTION get_persno RETURN NUMBER IS BEGIN RETURN persno; END; MEMBER PROCEDURE zeige_details ( SELF IN OUT NOCOPY personen_typ ) IS BEGIN DBMS_OUTPUT.PUT_LINE(TO_CHAR(persno) || ' ' || vorname || ' ' || nachname); DBMS_OUTPUT.PUT_LINE(email || ' ' || phone); END; END; /
Informationen zu Objekttypen in der Datenbank finden Sie in den Views dba_types_attrs, dba_typesmethods und dba_types_versions.
dba_types,
189
3 Verwaltung von Datenbankobjekten Die Metadaten im Data Dictionary zu Objekt-Tabellen können über dba_tables, dba_ objects und dba_segments ermittelt werden. Die View dba_tab_columns zeigt Informationen zu enthaltenen Spalten und deren Datentypen. SELECT FROM WHERE ORDER BY
Global Temporary Tables (GTs) stehen seit Oracle 8i zur Verfügung. GTs sind für die Speicherung von Temporärdaten und Zwischenergebnissen geeignet und von beliebig vielen Sessions und Anwendungen nutzbar. Dabei sieht jede der Sessions nur jeweils ihre eigenen Dateninhalte. Diese werden – je nach Definition der Tabelle – am Ende einer Transaktion oder mit Beendigung einer Benutzersession automatisch entfernt. Die Datenspeicherung erfolgt im temporären Tablespace des Tabellen-Eigentümers. CREATE GLOBAL TEMPORARY TABLE my_temp_table1 ( column1 NUMBER, column2 NUMBER ) ON COMMIT DELETE ROWS; CREATE GLOBAL TEMPORARY TABLE my_temp_table2 ( column1 NUMBER, column2 NUMBER ) ON COMMIT PRESERVE ROWS;
Temporäre Tabellen lassen sich auch aus einer Selektion einer anderen Tabelle erzeugen: CREATE GLOBAL TEMPORARY TABLE orders_today ON COMMIT PRESERVE ROWS AS SELECT * FROM orders WHERE order_date >= SYSDATE;
Global Temporary Tables können wie andere Tabellen indiziert oder mit Views belegt, mit anderen Tabellen verknüpft und mit Triggern ausgestattet werden. DML-Operationen wie Insert-, Update- oder Delete-Statements erzeugen kein Redo, Undo-Informationen für ein Rollback werden jedoch geschrieben. Auch Constraints15 sind möglich, einzige Ausnahme: Foreign Keys sind auf GTs nicht gestattet. Wichtig: Constraints auf GTs wie beispielswiese ein Unique Key werden nur auf die Daten innerhalb einer Session angewendet. Parallele Abfragen oder paralleles DML ist mit temporären Tabellen leider nicht möglich. Die Definition als IOT sowie Partitionierung sind für temporäre Tabellen ebenfalls nicht gestattet. Standardmäßig sind Segmente temporärer Tabellen im Default Temporär-Tablespace des Tabelleneigentümers gespeichert. Optional kann ein anderer Temporär-Tablespace in der Storage-Klausel angegeben werden. Physisch erhält jede Session eine eigene Version der Global Temporary Table, die entsteht, sobald eine Session die Tabelle das erste Mal refe-
15
190
Siehe Abschnitt 3.8 „Constraints“
3.6 Speicherorganisation von Tabellen renziert. Die Klausel ON COMMIT DELETE gibt die für die GT genutzten Temporärsegmente mit dem folgenden Commit, ansonsten erst mit dem Ende der Session frei. Informationen zu Global Temporary Tables finden Sie in porary hat hier jeweils den Wert „Y“:
dba_tables.
Die Spalte
tem-
SELECT owner, table_name, temporary FROM dba_tables WHERE temporary = 'Y';
Der Speicherbedarf entspricht etwa dem einer Heap Table. Anders als bei normalen Heap Tables zeigt die View dba_segments Temporär-Segmente nicht an. Der Speicherbedarf wird stattdessen über die View v$sort_usage ermittelt: SELECT username, tablespace, contents, segtype FROM v$sort_usage;
3.6.5
External Tables
External Tables erlauben den Zugriff auf strukturierte Daten wie etwa kommaseparierte Listen, die im Dateisystem gespeichert sind. Die Metadaten liegen in der Datenbank, die Daten selbst jedoch außerhalb. External Tables können wie andere Tabellen mit Select-Statements abgefragt und mit anderen Tabellen verknüpft werden. Indizes auf External Tables sind nicht möglich. Hintergrund ist, dass ein Index die eindeutige Zeilenadresse (RowId) für den Verweis nutzt; für externe Tabellen sind jeodch keine Zeilenadressen16 verfügbar. Um eine External Table zu lesen, ist ein Zugriffstreiber erforderlich. Oracle bietet zwei Treiber an: ORACLE_LOADER und ORACLE_DATAPUMP. Letzterer ist auch für das Entladen von Tabellen nutzbar. Ein Beispiel: Die Textdatei /data/countries.txt enthält folgende Zeilen: ENG,England,English SCO,Scotland,English IRE,Ireland,English WAL,Wales,Welsh
Um auf die externen Daten zugreifen zu können, ist zunächst ein Directory-Objekt notwendig, das auf den Pfad verweist: CREATE OR REPLACE DIRECTORY EXT_TABLES AS '/data/';
Nun wird die Tabellendefinition in der Datenbank mit Verweis auf die externe Datei erstellt: CREATE TABLE countries_ext ( country_code VARCHAR2(5), country_name VARCHAR2(50), country_language VARCHAR2(50)) ORGANIZATION EXTERNAL ( TYPE ORACLE_LOADER DEFAULT DIRECTORY ext_tables ACCESS PARAMETERS ( 16
Zeilenadressen von Standard-Tabellen bestehen unter anderem aus der Nummer der Datendatei und der Blockadresse der Datenzeile.
191
3 Verwaltung von Datenbankobjekten RECORDS DELIMITED BY NEWLINE FIELDS TERMINATED BY ',' MISSING FIELD VALUES ARE NULL ( country_code CHAR(5), country_name CHAR(50), country_language CHAR(50)) ) LOCATION ('countries.txt')) REJECT LIMIT UNLIMITED;
Die Tabelle wird nun mit SQL-Statements abgefragt: SELECT * FROM countries_ext ORDER BY country_name;
Externe Tabellen bieten vielfältige Möglichkeiten. Das folgende Beispiel zeigt, wie man eine External Table zum Lesen des Alert-Logs verwendet: CREATE OR REPLACE DIRECTORY bdump AS '/u01/app/oracle/diag/rdbms/ora11g/ora11g/trace'; CREATE TABLE alert_log (line VARCHAR2(4000)) ORGANIZATION EXTERNAL ( TYPE ORACLE_LOADER DEFAULT DIRECTORY bdump ACCESS PARAMETERS ( RECORDS DELIMITED BY NEWLINE BADFILE bdump:'read_alert_%a_%p.bad' LOGFILE bdump:'read_alert_%a_%p.log' FIELDS TERMINATED BY '~' MISSING FIELD VALUES ARE NULL (line CHAR(4000)) ) LOCATION ('alert_meineDB.log') ) PARALLEL 10 REJECT LIMIT UNLIMITED;
Das Alert-Log wird nun wie folgt abgefragt: SQL> SET LINESIZE 1000 SQL> SEL * FROM alert_log;
3.6.6
Geclusterte Tabellen
Tabellen-Cluster sind nicht zu verwechseln mit Real Application Clusters. Bei letzteren handelt es sich um einen Rechnerverbund, der eine Datenbank mit mehreren Instanzen nutzt. Tabellen-Cluster hingegen speichern Daten verschiedener Tabellen anhand eines Schlüssels – dem sogenannten „Cluster Key“ – gemeinsam in denselben Datenblöcken. Die Verwendung eines Tabellen-Clusters eignet sich dann, wenn man Daten mehrerer Tabellen regelmäßig über eine Verknüpfung des Cluster Keys abfragen möchte. Die Verwendung eines Clusters ist in folgenden Fällen weniger geeignet:
um Tabellen regelmäßig einzeln ohne Verknüpfung abzufragen; um häufig ein Full Table Scan auf eine der Tabellen zu machen; um die Daten einer der Tabellen häufig und regelmäßig zu ändern; um eine der Tabellen über ein Truncate Table zu leeren. Die Zuordnung von Cluster-Schlüsseln zu Datenblöcken regeln zwei unterschiedliche Verfahren: Indizierung oder ein Hash-Algorithmus. Dementsprechend sprechen wir von Index-
192
3.6 Speicherorganisation von Tabellen Clustern oder Hash-Clustern. Als Cluster-Schlüssel sind sowohl einzelne als auch mehrere Spalten möglich. Bei Index-Clustern übernimmt der Cluster-Index die Zuordnung. Er wird wie ein traditioneller Index als B*-Tree gespeichert und verbessert die I/O-Rate auf die geclusterten Tabellen, sofern der Zugriff über den Cluster Key erfolgt. Dafür benötigt er einen Index Scan, der seinerseits nur geringfügig I/O verursacht. Hash-Cluster nutzen eine Hash-Funktion zur Clusterung, die über den Cluster Key angewandt wird. Bei vorhersehbarer Anzahl der Schlüsselwerte ist ein Hash-Cluster gut geeignet. Die Zugriffszeiten sind speziell bei Gleichheitsabfragen auf den Cluster Key hervorragend. Hier entfällt sogar der für einen Index-Scan erforderliche I/O. Eine spezielle Form des Hash-Clusters ist der Sorted Hash-Cluster, dessen Zugriff unter bestimmten AbfrageBedingungen noch schneller ist. Cluster kommen in der Praxis ausgesprochen selten vor. Lediglich im Data Dictionary ist ein halbes Dutzend von ihnen vorhanden. Praxistipp Wird bei der Erstellung eines Clusters weder das Schlüsselwort „Hash“ noch ein Index angegeben, so entsteht stets ein Index-Cluster.
3.6.6.1 Index-Cluster Um Tabellen in einem Index-Cluster zu speichern, verfahren Sie wie folgt: 1. Cluster erstellen CREATE CLUSTER mitarbeiter_abteilung_cluster (abteilungs_nr NUMBER(4,0)); CREATE INDEX idx_mitarbeiter_abt_cluster ON CLUSTER mitarbeiter_abteilung_cluster;
2. Tabellen im Cluster speichern Hier sind die Namen der Spalten anzugeben, die als Cluster Key dienen sollen. Die Namen der Tabellenspalten können von dem für den Cluster angegebenen Cluster Key abweichen, die Datentypen müssen mit denen des Cluster Keys übereinstimmen. CREATE TABLE t_abteilung (abteilungs_nr NUMBER (4,0), abtteilungs_name VARCHAR2 (100)) CLUSTER mitarbeiter_abteilung_cluster (abteilungs_nr); CREATE TABLE t_mitarbeiter (pers_nr NUMBER , nachname VARCHAR2 (60) , vorname VARCHAR2 (20) , gehalt NUMBER (10,2) einstellungsdatum DATE, abteilungs_nr NUMBER (4,0)) CLUSTER mitarbeiter_abteilung_cluster (abteilungs_nr);
3.6.6.2 Hash-Cluster Ein Hash-Cluster wird ebenfalls mit dem Befehl Anzahl der Hash-Keys anzugeben.
create cluster
erstellt. Jedoch ist die
193
3 Verwaltung von Datenbankobjekten 1. Cluster erstellen CREATE CLUSTER fahrkartenautomat_cluster (ID_automat HASH IS ID_automat HASHKEYS 1200;
3.6.6.3 Sorted Hash-Cluster Sorted Hash-Cluster wurden mit Oracle Database 10g eingeführt. Sie speichern die Daten intern sortiert. Fragen Sie Daten aus einem Sorted Hash-Cluster ab, so werden die Daten ebenfalls in dieser Sortierung ausgelesen. So ist die Verwendung der Order By-Klausel in Select-Statements nicht notwendig, sofern die Ausgabe in der Reihenfolge der Cluster-Sortierung erfolgen soll. 1. Cluster erstellen CREATE CLUSTER bestellungen_cluster ( kunden_id NUMBER(8), bestelldatum DATE SORT ) HASHKEYS 10000 HASH IS ora_hash(kunden_id) SIZE 256;
2. Tabellen im Cluster speichern CREATE TABLE bestellungen( bestell_id NUMBER, bestelldatum DATE, kunden_id NUMBER(8) SORT) CLUSTER bestellungen_cluster (kunden_id, bestelldatum); CREATE TABLE bestell_positionen( bestelldatum DATE, kunden_id NUMBER ( 8) SORT, position NUMBER ( 3), art_nr NUMBER (12), anzahl NUMBER ( 3)) CLUSTER bestellungen_cluster (kunden_id, bestelldatum);
Informationen zu Clustern im Data Dictionary Informationen zu Clustern finden Sie in den Views dba_clusters und dba_clu_columns, Informationen zu Tabellen, die in Clustern gespeichert sind, in der View dba_tables. Die Spalte cluster_name der View dba_tables erlaubt eine Zuordnung zwischen Tabellen und Clustern.
194
3.7 Administrationsbefehle für Tabellen
3.6.7
Tabellenkomprimierung
Bei Heap Tables ist Tabellenkomprimierung möglich. Die Klauseln compress oder compress basic aktivieren Basic Table Compression. Diese sorgt dafür, dass während Direct Path Inserts komprimiert wird. Um Daten auch für OLTP (Standard-Inserts und Updates) zu verwenden, ist die Klausel compress for oltp erforderlich. In älteren Oracle-Versionen wird dies über die Syntax compress for all operations erreicht. CREATE TABLE t_mitarbeiter ( pers_no NUMBER, vorname VARCHAR2(60), nachname VARCHAR2(60)) COMPRESS FOR OLTP;
Praxistipp Einige Komprimierungsoptionen sind Bestandteil der „Advanced Compression“. Prüfen Sie vorab, ob dafür Lizenzkosten anfallen.
Weitere Informationen zur Komprimierung finden Sie in Kapitel 15 „Große Datenbanken“.
3.6.8
Tabellenpartitionierung
Die Partitionierung teilt Tabellen in kleinere Segmente auf. Dabei kommt eine Tabellenspalte als Partitionierungschlüssel zum Einsatz. So werden häufig Datumsangaben wie das Rechnungsdatum für Time Range Partitioning eingesetzt. Aus Sicht der Applikation ist die Partitionierung transparent im Sinne von „nicht sichtbar“: SQL-Statements auf partitionierte Tabellen unterscheiden sich nicht von jenen auf nicht partitionierte. Weitere Informationen finden Sie in Kapitel 15 „Große Datenbanken“.
3.7
Administrationsbefehle für Tabellen In den folgenden Abschnitten stellen wir die Administrationsbefehle rund um Tabellen vor.
Erstellen einer Tabelle aus einem Select-Statement
Das folgende Statement erzeugt eine neue Tabelle aus den Daten einer bestehenden: CREATE TABLE <storage_klausel> AS <select_tatement>;
Beispiel: CREATE TABLE ein_schema.t_mitarbeiter_neu TABLESPACE users STORAGE (INITIAL 10 M NEXT 10 M) AS SELECT * FROM scott.t_mitarbeiter ORDER BY pers_no;
Erlaubt sind auch Projektionen und Selektionen: CREATE TABLE ein_schema.t_mitarbeiter_neu TABLESPACE users STORAGE (INITIAL 10 M NEXT 10 M) AS SELECT pers_no, nachname, vorname, gehalt AS monatsgehalt, (gehalt * 12) AS jahresgehalt FROM scott.t_mitarbeiter WHERE lokation IN ('BERLIN', 'MÜNCHEN', 'FRANKFURT A. M. ') ORDER BY pers_no;
Die Spaltenreihenfolge der neu erstellten Tabelle entspricht der im Select-Statement. Alias verändert den Spaltennamen. So wird im obigen Beispiel die Spalte gehalt der alten Tabelle in monatsgehalt umbenannt. Der Einsatz eines Ausdrucks inklusive aller gültigen Funktionen und Berechnungen ist gestattet. Für solche Spalten ist die Verwendung eines Spaltenalias zwingend. Die neu erstellte Tabelle enthält lediglich die eingefügten Daten. Abhängige Objekte werden nicht transferiert. So sind Trigger und Constraints bei Bedarf zusätzlich zu erstellen.
3.7.3
Tabellen kopieren
Der Copy-Befehl kopiert Tabellen in SQL*Plus: COPY {FROM database | TO database | FROM database TO database} {APPEND | CREATE | INSERT | REPLACE} destination_table[(column, column, column, ...)] USING query
mit :
Datenbankzeichenfolge, z.B. scott/tiger@fraDB
:
eine beliebige, gültige SQL-SELECT-Anweisung
Beispiel: COPY FROM scott/tiger@fraDB TO king/oatao@mucDB CREATE personaldaten (abt_nr, abt_name, stadt) USING SELECT * FROM v_personaldaten;
Wird keine to-Klausel angegeben, so kommt das aktuelle Schema der aktuellen Datenbank zur Anwendung.
196
3.7 Administrationsbefehle für Tabellen Alternativ ist der Befehl create table as select möglich, siehe Abschnitt 3.7.2 „Erstellen einer Tabelle aus einem Select-Statement“.
3.7.4
Tabellennamen ändern
Der Befehl rename erlaubt die Änderung des Tabellennamens, er ist jedoch auch für andere Objekttypen möglich: RENAME TO ;
Beispiel: RENAME personaldaten TO mitarbeiterdaten;
3.7.5
Tabelleneigenschaften ändern
Der Befehl alter
table
ändert die Konfiguration einer bestehenden Tabelle:
Mit drop table wird eine Tabelle gelöscht. Ab Oracle Database 10g gibt es den Recycle Bin, der – sofern er aktiviert ist – eine Wiederherstellung einer gelöschten Tabelle ermöglicht17. Syntax: DROP TABLE [CASCADE CONSTRAINTS];
Beispiel: DROP TABLE einwohnerdaten;
Bestehen noch Fremdschlüssel, die auf die zu löschende Tabelle zeigen, so wird das Löschen der Tabelle mit folgender Fehlermeldung abgelehnt: ORA-02449: Eindeutige und Primärschlüssel in Tabelle von Fremdschlüsseln referenziert. Sie können vor dem Löschen zunächst alle auf die Tabelle referenzierenden Fremdschlüsselbeziehungen entfernen18. Alternativ löscht die Klausel drop cascade constraints existierende Fremdschlüsselbeziehungen: DROP TABLE einwohnerdaten CASCADE CONSTRAINTS;
17 18
Siehe Abschnitt 13.6 „Flashback“. Siehe Abschnitt 3.8.9 „Entfernen von Constraints“.
197
3 Verwaltung von Datenbankobjekten
3.7.7
Tablespace zuordnen
Wir empfehlen die Speicherung von Benutzer- und Indexdaten sowie von Daten verschiedener Applikationen in verschiedenen Tablespaces19. Die Zuordnung einer Tabelle zu einem Tablespace erfolgt explizit mit der Klausel tablespace: CREATE TABLE (<spalten_liste>) TABLESPACE ; ALTER TABLE MOVE TABLESPACE ;
Eine Tabelle ohne die Klausel tablespace legt die Speicherextents der Tabelle im Default Tablespace20 des Benutzers ab.
3.7.8
Eine Tabelle in einen anderen Tablespace verschieben
Der folgende Befehl verschiebt eine Tabelle von einem Tablespace in einen anderen: ALTER TABLE MOVE TABLESPACE ;
Beispiel: ALTER TABLE einwohnerdaten MOVE TABLESPACE app_09_data;
Da Datenzeilen verschoben werden, ändern sich die physischen Adressen der Datenzeilen (RowIds). Von der Tabelle abhängige Indizes werden daher intern mit dem Flag „unusable“ markiert. Deshalb muss anschließend ein Index-Rebuild erfolgen, möchte man den Fehler ORA-01502 vermeiden. Auch Statistiken der Tabelle sind anschließend nicht mehr gültig. Diese sollte man nach einem Move ebenfalls erneuern. Werden LOB-Spalten verwendet, so können auch LOB-Segmente verschoben werden, indem diese explizit angesprochen werden. Heap Tables benötigen Sperren während des Verschiebens. IOTs dagegen können online verschoben und reorganisiert werden: CREATE TABLE t_kunden (kd_nr NUMBER, nachname VARCHAR2(60), vorname VARCHAR2(20), CONSTRAINT pk_kunden PRIMARY KEY (kd_nr))
19 20
198
Siehe Abschnitt 2.2.5 „Empfehlungen zum Tablespace-Layout“. Siehe Abschnitt 2.6.9 „Default- und Temporary-Tablespace für Benutzer setzen“.
3.7 Administrationsbefehle für Tabellen ORGANIZATION INDEX TABLESPACE users; ALTER TABLE t_kunden MOVE ONLINE TABLESPACE APP_DATA_05;
3.7.9
Extent-Größen festlegen
Daten einer Tabelle sind stets in Extents gespeichert21. Die Größe der für eine Tabelle zu allokierenden Extents können Sie mit den Klauseln initial für das erste Extent und next für jedes weitere Extent angeben. Die Klausel maxextents legt fest, wie viele Extents maximal allokiert werden dürfen. Syntax: CREATE TABLE (<spalten_liste>) [STORAGE ([INITIAL ] [NEXT ] [maxextents ])] [TABLESPACE ]; ALTER TABLE MOVE [STORAGE ([INITIAL ] [NEXT ] [maxextents ])] [TABLESPACE ];
Beispiel: CREATE TABLE t_kunden (kd_nr NUMBER, nachname VARCHAR2(60), vorname VARCHAR2(20) ) STORAGE (INITIAL 100 M NEXT 10 M MAXEXTENTS 10) TABLESPACE app_01_data;
Die Konfiguration der Extent-Größen liefert die View dba_tables: SELECT FROM WHERE
Informationen zum Extentmanagegement finden Sie in Kapitel 4 „Speicherplatzverwaltung“.
3.7.10 Einstellen der Größe des Transaktionsheaders Für jede Transaktion, die einen Datenblock ändert, wird vorübergehend ein Transaktionsslot im Header des Blocks genutzt, der 24 Byte benötigt. Standardmäßig wird mindestens ein Transaktionsslot pro Datenblock zur Verfügung gestellt. Erfolgen mehrere Transaktionen parallel auf denselben Datenblock, so vergrößert sich der Transaktionsheader entsprechend. Es sind bis zu 255 parallele Transaktionen möglich. Ist ein Datenblock vollständig gefüllt, so kann möglicherweise kein weiterer Transaktionsslot allokiert werden, weil der Speicherplatz nicht ausreicht. Die Folge: Jede folgende Transaktion muss auf den Abschluss der vorhergehenden warten. Es entstehen ITL22-Waits.
21 22
Siehe Abschnitt 3.3 „Speicherhierarchie“. ITL: Interested Transaction List
199
3 Verwaltung von Datenbankobjekten Um dem vorzubeugen, reserviert der Parameter initrans in Tabellen und Indizes eine Mindestanzahl an Transaktionsslots je Datenblock. Damit ist die in initrans angegebene Anzahl an Transaktionen stets parallel innerhalb des Datenblockes ausführbar. Der Parameter maxtrans limitiert die maximale Anzahl paralleler Transaktionen. Syntax: CREATE TABLE (<spalten_liste>) INITRANS MAXTRANS <m>; ALTER TABLE tabellen_name MOVE INITRANS MAXTRANS <m>;
Praxistipp Wir empfehlen, den Parameter initrans für Tabellen mit hoher Transaktionsdichte auf 4 zu setzen. Treten weiterhin ITL-Waits auf eine Tabelle bzw. einen Index auf, wird dieser schrittweise hochgesetzt. Für Indizes ist dies mit einem Online-Rebuild möglich. Wird bei Tabellen ein alter table move verwendet, treten während der Reorganisation Locks auf. Änderungen am Transaktionsheader sollten daher entweder auf ein geeignetes Wartungsfenster verlegt oder aber mit einer Online Redefinition ausgeführt werden. Den Parameter maxtrans können Sie auf 255 – seinem Standardwert – belassen.
3.7.11 Verzögerte Speicherallokation / Deferred Segment Creation Ab Oracle Database 11g R2 kann während der Erstellung einer Heap-Tabelle ein erstes Extent allokiert werden. Der Schalter deferred sorgt dafür, dass ein erstes Extent erst mit dem Einfügen der ersten Datenzeile allokiert wird. Diese gilt auch für LOB-Spalten der Tabelle sowie für Indizes. Gerade für Anwendungen, die Tabellen während der Installation erstellen, diese aber nicht zwingend nutzen, lässt sich so Speicherplatz sparen. Für die Deferred Segment Creation muss der Datenbankparameter compatible mindestens auf 11.2.0 gesetzt sein:
Die Default-Einstellung für neu zu erstellende Tabellen wird mit dem Datenbankparameter deferred_segment_creation eingestellt. Die Views dba_tables, dba_indexes und dba_lobs zeigen in der Spalte segment_creaob Deferred Segment Creation für das jeweilige Objekt genutzt wurde.
ted,
3.7.12 Cache / Nocache / Cache Reads Die Klausel Cache sorgt dafür, dass Datenblöcke während eines Full Table Scans auf die Most Recently Used-Seite der LRU-Liste23 gesetzt sind. Ist Nocache (Default) gesetzt, so kommen Datenblöcke der Tabelle sofort nach Benutzung an das „Last Recently Used-Ende“ der LRU-Liste. Wird zur Erstellung einer Tabelle die Cache-Klausel nicht explizit angegeben, so ist nocache der Default. Syntax: ALTER TABLE CACHE|NOCACHE;
Beispiele: ALTER TABLE
scott.t_mitarbeiter CACHE;
ALTER TABLE
scott.t_mitarbeiter NOCACHE;
Praxistipp Die Cache-Klausel ist für kleine Look-up-Tabellen bis Oracle 10g Release 2 gut geeignet. Ab Oracle 11g Release 1 entscheidet der Oracle Optimizer über das Caching-Verhalten, soweit keine Cache-Klausel gesetzt wurde: Ist der Parameter statistics_level auf typical oder höher gesetzt, wird aufgrund der Workload-Historie entschieden, ob die Blöcke einer Tabelle auch bei einem Full Table Scan gecacht werden. Sofern statistics_level auf basic gesetzt ist, cacht der Oracle-Server Datenblöcke bei Full Table Scans nicht, es sein denn, der Cache-Parameter ist gesetzt.
Die Klauseln Cache und Nocache sind für Tabellencluster nicht möglich. Index Organized Tables (IOTs) nutzen implizit stets das Cache-Verhalten. Nocache ist für IOTs dagegegen nicht vorgesehen. Die Einstellung Cache Reads ist nur für LOBs bzw. Securefiles gültig und sorgt dafür, dass LOBs während Leseoperationen, nicht aber bei Schreiboperationen in den Cache über23
LRU (Last Recently Used) ist eine Seitenverdrängungsstrategie für Cache-Speicher. Sie lagert diejenige Seite aus, deren letzte Referenzierung zeitlich am längsten zurückliegt
201
3 Verwaltung von Datenbankobjekten tragen werden. Der Defaultwert für LOBs / Securefiles ist nocache, das heißt, dass der Zugriff auf LOBs standardmäßig nicht über den Buffer Cache, sondern über direct physical reads und writes erfolgt. CREATE TABLE t_mitarbeiter (pers_no NUMBER, nachname VARCHAR(60), vorname VARCHAR(60), passfoto BLOB) LOB (passfoto) STORE AS (CACHE READS); SELECT table_name, cache FROM dba_lobs; ALTER TABLE t_mitarbeiter MODIFY LOB (passfoto) (NOCACHE);
3.7.13 Logging und Nologging Standardmäßig schreibt der Logwriter-Prozess Informationen zu allen Änderungen am Datenbestand in die Oracle Redo Logs. Ist eine Tabelle auf Nologging gesetzt, so wird dieser Overhead vermieden. Im Falle einer Wiederherstellung der Datenbank aus einem Backup und einem anschließenden Recovery über die Redo Logs, ist die Tabelle jedoch unbrauchbar. Bei Staging-Tabellen für Ladeprozesse beispielsweise stellt dies aber kein Problem dar, sofern der Ladeprozess einfach erneut angestoßen werden kann. Die Umsetzung des Log-Modus erfolgt im laufenden Betrieb: ALTER TABLE NOLOGGING|LOGGING;
Beispiel: ALTER TABLE einwohnerdaten NOLOGGING;
Generell sollten Sie jedoch sehr genau überlegen, für welche Tabellen Sie das Logging deaktivieren. In Umgebungen mit Standby-Datenbanken oder Oracle Streams sollte man darauf verzichten. Nach einem Media Recovery erhalten Sie hinsichtlich nicht geloggter Objekte beispielsweise die folgende Fehlermeldung: ORA-01578: ORACLE data block corrupted (file # 7, block # 982) ORA-01110: data file 7: '/opt/oracle/oradata/meineDB/app_01_121.dbf' ORA-26040: Data block was loaded using the NOLOGGING option
Die folgenden Befehle deaktivieren bzw. aktivieren das Logging: ALTER TABLE einwohnerdaten NOLOGGING; ALTER TABLE einwohnerdaten LOGGING;
Die View dba_tables zeigt die aktuelle Einstellung: SELECT owner, table_name, logging FROM dba_tables WHERE tablespace_name = 'APP_01_DATA';
3.7.14 Parallelisierung Parallel Query wurde bereits seit Release 7.1 eingeführt. Die parallele Ausführung von Abfragen kann bei Full Table Scans auf sehr große Tabellen signifikante Performanceverbesserungen bringen. Dazu zerlegt der Datenbankserver Teile einer Abfrage und vergibt
202
3.7 Administrationsbefehle für Tabellen diese an parallele Slave-Prozesse, während der eigentliche Benutzerprozess die Rolle des Query Coordinator übernimmt. Parallelisierung kann mittels Hint in einer Abfrage forciert werden. Jedoch ist es auch möglich, für Full Table Scans auf eine Tabelle einen Standard-Parallelisierungsgrad anzugeben: ALTER TABLE t_rechnungsdaten parallel |NOPARALLEL;
Beispiele: ALTER TABLE t_rechnungsdaten parallel 4; ALTER TABLE t_rechnungsdaten noparallel;
Die View dba_tables zeigt den Standard-Parallelisierungsgrad einer Tabelle: SELECT owner, table_name, degree FROM dba_tables WHERE table_name = 'T_KUNDEN';
Weitere Informationen finden Sie in Kapitel 15 „Große Datenbanken“.
3.7.15 Schreibschutz für Tabellen: Read Only / Read write Für Tabellen ist ein genereller Schreibschutz möglich. Diese Restriktion gilt auch dann, wenn ein Benutzer explizit Rechte wie „insert“, „update“ oder „delete“ erhalten hat. Syntax: ALTER TABLE READ ONLY|READ WRITE;
Beispiel: ALTER TABLE personaldaten READ ONLY;
Wird nun versucht, Daten zu ändern, neue einzufügen oder zu löschen, wird dies mit einer Fehlermeldung verweigert: ORA-12081: Aktualisierenvorgang bei Tabelle
nicht zulässig
Möchten Sie Änderungen auf die Tabelle wieder gestatten, so ist dies wie folgt möglich: ALTER TABLE personaldaten READ WRITE;
3.7.16 Spalten hinzufügen Die Klausel add des Befehls alter
table
fügt eine neue Spalte hinzu:
ALTER TABLE ADD (<spalten_definition>);
Beispiel: ALTER TABLE t_mitarbeiterdaten ADD (bonus NUMBER (10,2));
Achtung: Zu komprimierten Tabellen können nur Spalten ohne Standardwert (Klausel default) hinzugefügt werden.
203
3 Verwaltung von Datenbankobjekten
3.7.17 Spaltennamen ändern Die Klausel rename
column
des Befehls alter
table
benennt eine Spalte um:
ALTER TABLE RENAME COLUMN TO ;
Beispiel: ALTER TABLE t_mitarbeiterdaten RENAME COLUMN n_name TO nachname;
3.7.18 Default-Werte für Spalten vergeben Syntax: ALTER TABLE MODIFY <spalten_name> DEFAULT <default_wert>;
Beispiel: ALTER TABLE t_mitarbeiterdaten MODIFY bonus DEFAULT 100;
Wird ein neuer Datensatz in die Tabelle t_mitarbeiterdaten, ohne Wert für die Spalte bonus eingefügt, so erhält dieser standardmäßig den Wert 100.
3.7.19 Spaltendefinitionen ändern Die Klausel tion;
modify
des Befehls
alter table
erlaubt die Änderung einer Spaltendefini-
ALTER TABLE MODIFY (<spalten_definition>);
Beispiel: CREATE TABLE t_mitarbeiterdaten (pers_no NUMBER ( 5 nachname VARCHAR ( 60 vorname VARCHAR ( 60 gehalt NUMBER ( 10,2 bonus NUMBER ( 4,2 abt_nr NUMBER ( 8 );
), ), ), ), ), )
ALTER TABLE t_mitarbeiterdaten MODIFY (bonus NUMBER (10,2));
Eine Erweiterung der Längendefinition, der Präzision oder der Skalierung einer Spalte – beispielsweise von Number (8) auf Number (10) – ist jederzeit möglich. Wird die Längendefinition, die Präzision oder die Skalierung einer Spalte jedoch reduziert, so darf in keinem der Tupel ein Wert für diese Spalte hinterlegt sein. Dies gilt auch bei einer Änderung des Datentyps: Wird der Datentyp umgestellt – beispielsweise von Number auf Varchar2 – so ist dies nur möglich, wenn die zu ändernde Spalte leer ist. Alternativ kann man eine neue Spalte erstellen und mit einem Update füllen. Abschließend wird die alte Spalte entfernt und die neue umbenannt. ALTER TABLE t_mitarbeiterdaten ADD (bonus_neu VARCHAR2(200)); UPDATE t_mitarbeiterdaten SET bonus_neu = bonus; COMMIT; ALTER TABLE t_mitarbeiterdaten DROP (bonus); ALTER TABLE t_mitarbeiterdaten RENAME COLUMN bonus_neu TO bonus;
204
3.7 Administrationsbefehle für Tabellen Achtung: Diese Aktion ändert die Spaltenreihenfolge, da die neue Spalte der Tabelle angehängt wird. Möchte man die Spaltenreihenfolge beibehalten, empfiehlt sich die Rekonfiguration der Tabelle mit Online Table Redefinition.
3.7.20 Spalten physisch löschen Die Klausel drop des Befehls alter table entfernt eine Spalte aus einer Tabelle. Dabei wird jeder einzelne Datensatz gelesen und – ohne den Spaltenwert – neu geschrieben. Diese Operation ist daher sehr Ressourcen-intensiv. Eine Alternative ist das logische Löschen einer Spalte. Dabei wird die Spalte zunächst nicht physisch gelöscht, sondern auf „unused“ gesetzt. Der physische Löschvorgang kann dann in einem Wartungsfenster erfolgen. Eine genaue Beschreibung finden Sie in Abschnitt 3.7.21 „Spalten logisch lösen“. Doch zunächst zurück zum physischen Löschen. Syntax: ALTER TABLE t_mitarbeiter DROP (<spalten_name>) [CASCADE CONSTRAINTS] [CHECKPOINT ];
Beispiel: ALTER TABLE t_mitarbeiter DROP (bonus);
Beim Löschen einer Spalte erfolgen diese Aktionen:
Löschen aller assoziierten Indizes Entfernen alle Constraints, die diese Spalte referenzieren Invalidieren aller Statistiken, die die Spalte betreffen Sofern ein Foreign Key auf die betreffende Spalte verweist, erscheint eine Fehlermeldung. In diesem Fall ist die Syntax mit der Klausel cascade constraints zu verwenden: ALTER TABLE dept DROP (deptno) CASCADE CONSTRAINTS;
Bei der Klausel checkpoint führt der Datenbankserver nach jeweils verarbeiteten Zeilen einen Checkpoint aus. Ist der Wert für größer als die Satzanzahl der Tabelle, so führt der DB-Server einen Checkpoint nach der Verarbeitung aller Datenzeilen aus. Der Standardwert für ist 512. Er soll verhindern, dass es einen Überlauf der UndoSegmente gibt. ALTER TABLE t_mitarbeiter DROP (GEHALT) CHECKPOINT 5000;
Praxistipp Wird ein Drop Column unterbrochen, so bleibt die Tabelle in einem invaliden Status. In diesem sind nur noch die Befehle alter table drop columns continue, drop table und truncate table gestattet. Sie sollten daher das Löschen einer Spalte nicht unterbrechen! Auch nach einem „kill session“ oder „disconnect session“ bleibt die Tabelle zunächst invalid, bis der komplette Löschvorgang erfolgreich abgeschlossen ist.
Wurde das Löschen einer Spalte vorzeitig beendet, so kann der Vorgang mit der Klausel continue abgeschlossen werden: ALTER TABLE t_mitarbeiter DROP COLUMNS CONTINUE;
205
3 Verwaltung von Datenbankobjekten Praxistipp Das Löschen einer Spalte in einer sehr großen Tabelle ist eine der aufwendigsten Operationen: Jede einzelne Datenzeile der gesamten Tabelle wird geändert. Dies kann unter Umständen einige Zeit in Anspruch nehmen. Bleiben Sie geduldig und prüfen Sie den Fortschritt des Löschvorganges gegebenenfalls über die Views v$session_longops, v$session und v$session_wait.
3.7.21 Spalten logisch löschen Das physische Löschen einer Spalte benötigt bei großen Tabellen einige Zeit und Ressourcen. Eine Alternative ist das logische Löschen einer Spalte mit einem set unused: ALTER TABLE SET UNUSED (<spalten_name>);
Beispiel: ALTER TABLE t_mitarbeiterdaten SET UNUSED (bonus);
Auf „unused“ gesetzte Spalten werden nicht mehr angezeigt. Ein Zurücksetzen auf „used“ ist leider nicht möglich. Ungenutzte Spalten können später – beispielsweise während eines geeigneten Wartungsfensters – auch physisch gelöscht werden: ALTER TABLE t_mitabeiter DROP UNUSED COLUMNS;
Optional kann man beim Löschen die Klausel checkpoint setzen24: ALTER TABLE table_name DROP UNUSED COLUMNS CHECKPOINT 250;
Informationen zu ungenutzten Spalten können Sie der View nehmen.
dba_unused_col_tabs
ent-
3.7.22 Speicherplatz einer Tabelle ermitteln Die View dba_segments zeigt die Speicherbelegung einer Tabelle: SELECT owner, segment_type, segment_name, round(bytes/1024/1024,2) MB FROM dba_segments WHERE owner = 'EIN_BENUTZER' AND segment_name = 'EINE_TABELLE';
Eine Tabelle belegt Speicherplatz in Form von Extents25. Folgende Abfrage zeigt die Belegung der einzelnen Extents: SELECT e.owner, e.segment_name, e.segment_type, e.tablespace_name, e.extent_id, f.file_name, round(e.bytes/1024/1024,2) MB, e.blocks FROM dba_extents e, dba_data_files f WHERE e.file_id = f.file_id AND owner = 'EIN_BENUTZER' AND segment_name = 'EINE_TABELLE';
Beim Löschen von Daten einer Tabelle kann ein relativ hoher Fragmentierungsgrad entstehen, wenn Datenblöcke nicht mehr vollständig genutzt werden. Welchen Speicherplatz die Daten einer Tabelle effektiv benötigten, ermitteln Sie wie folgt:
24
Weitere Informationen zur Checkpoint-Klausel finden Sie in Abschnitt 3.7.20 „Spalten physisch löschen“ 25 Siehe Abschnitt 3.3 „Speicherhierarchie“.
206
3.7 Administrationsbefehle für Tabellen BEGIN dbms_stats.gather_table_stats('EIN_BENUTZER', 'EINE_TABELLE'); END; / SELECT owner, table_name, round((num_rows*avg_row_len/1024/1024),1) "Speicher (MB)" FROM dba_tables WHERE owner = 'EIN_BENUTZER' AND segment_name = 'EINE_TABELLE';
In Abschnitt 3.7.23 „Speicherplatz freigeben“ sowie in Kapitel 4 „Speicherplatzverwaltung“ finden Sie Informationen zur Defragmentierung bzw. Reorganisation von Tabellen.
3.7.23 Speicherplatz freigeben Die Klauseln shrink Speicherplatz frei.
space
und
deallocate unused
des Befehls
alter table
geben
Shrink Space Oracle bietet ab 10g die Klausel shrink space, um Tabellenzeilen in Blöcken zusammenzufassen und anschließend Speicherplatz einer Tabelle freizugeben. Dies ist insbesondere bei einer starken Fragmentierung – beispielsweise dann, wenn eine größere Menge Datenzeilen aus einer Tabelle entfernt wurden – sinnvoll. Voraussetzung für den Einsatz ist die Verwendung von Automatic Segment Space Management (ASSM). Syntax: ALTER TABLE SHRINK SPACE [CASCADE];
Für die zu verkleinernde Tabelle muss Row Movement aktiviert sein: ALTER TABLE einwohnerdaten ENABLE ROW MOVEMENT;
Anschließend erfolgt die eigentliche Freigabe des Speicherplatzes: ALTER TABLE einwohnerdaten SHRINK SPACE;
oder ALTER TABLE einwohnerdaten SHRINK SPACE CASCADE;
Die Option cascade sorgt dafür, dass Segmente aller abhängigen Objekte ebenfalls verkleinert werden. So geben alle abhängigen Indizes – sofern möglich – ebenfalls Speicher frei. Der folgende Befehl verkleinert nur ein LOB-Segment: ALTER TABLE einwohnerdaten MODIFY LOB (perf_review) (SHRINK SPACE);
Eine Partition einer partitionierten Tabelle wird wie folgt verkleinert: ALTER TABLE einwohnerdaten MODIFY PARTITION cust_P1 SHRINK SPACE;
Index Organized Tables (IOTs) sind ebenfalls verkleinerbar: ALTER TABLE t_kunden_iot SHRINK SPACE CASCADE;
Folgender Befehl verkleinert nur ein Overflow-Segment einer IOT: ALTER TABLE t_kunden_iot OVERFLOW SHRINK SPACE;
207
3 Verwaltung von Datenbankobjekten Die Option compact defragmentiert ein Segment in einem ersten Schritt, doch die Deallokation und das Heruntersetzen der High Water Mark erfolgt nicht. ALTER TABLE t_kunden SHRINK SPACE COMPACT;
Shrink Space ist nicht möglich für:
Tabellen mit RowId-basierten Materialized View Tabellen mit Function Based Indizes Securefile LOBs IOT Mapping Tables Hingegen ist ein Shrink Space möglich auf:
Heap Tables IOTs IOT Overflow-Segmente einzelne Tabellenpartitionen LOB-Segmente Deallokation Der folgende Befehl gibt ebenfalls ungenutzten Speicherplatz frei. Anders als bei einem shrink space werden die Datenzeilen jedoch nicht bewegt: Nur Extents, die hinter der High Water Marki eines Segments liegen, werden freigegeben. Eine Defragmentierung wie bei einem shrink space erfolgt nicht: ALTER TABLE DEALLOCATE UNUSED [KEEP K|M|G|T];
mit n:
Integer-Zahl
Beispiel: ALTER TABLE einwohnerdaten DEALLOCATE UNUSED KEEP 100 M;
Die Klausel keep ist optional und sorgt dafür, dass die angegebene Speichermenge belegt bleibt. Die View dba_free_space überprüft dieFreigabe des Speicherplatzes.
3.7.24 Tabellen leeren mit Truncate Table Truncate Table ist ein DDL-Statement, das nur die High Water Mark (HWM)26 zurücksetzt. Diese unterteilt ein Segment in genutzte und freie Datenblöcke. Da hinter der HWM grundsätzlich keine Daten liegen können, liest Oracle stets nur Datenblöcke bis zur HWM. Die HWM wird im Header eines Segmentes hinterlegt. Ihre initiale Position ist Extent 0 Block 0 für Tabellen sowie Extent 0 Block 1 für Indizes. Ein Truncate setzt die HWM auf diese initiale Position zurück. Truncate Table gibt anschließend die Extents der Tabelle – bis auf das Initial-Extent – wieder frei. 26
208
Siehe auch Abschnitt 4.4.1 „High Water Mark“.
3.7 Administrationsbefehle für Tabellen Truncate Table leert eine Tabelle, ohne Datenblöcke – mit Ausnahme des Segment-Headers – zu ändern und ohne Redo- oder Undo-Informationen zu generieren. So fallen wenig Ressourcen an: Der Befehl ist im Bruchteil einer Sekunde durchgeführt, gleich wie groß die Tabelle ist. Dafür ist kein Zurück-Rollen möglich. Nach einem Truncate Table ist die Tabelle unwiederbringlich leer. Syntax: TRUNCATE TABLE ;
Beispiel: TRUNCATE TABLE einwohnerdaten;
Praxistipp Da der Befehl truncate table ein DDL- und kein DML-Statement ist, wird implizit ein Commit vor und nach dem Truncate abgesetzt. Dies sollten Sie unbedingt beachten, sofern Sie Truncate in Transaktionen einbinden möchten. Nutzen Sie bei Bedarf autonome Transaktionen: SQL> SELECT count(*) FROM tabelle_1; COUNT(*) ---------14 SQL> SELECT count(*) FROM tabelle_2; COUNT(*) ---------18 SQL> SELECT count(*) FROM tabelle_3; COUNT(*) ---------45 SQL> DELETE FROM tabelle_2; -- Löschen der Daten aus tabelle_2, -- jedoch ohne Commit SQL> DECLARE PRAGMA AUTONOMOUS_TRANSACTION; -- Starten einer autonomen Transaktion BEGIN EXECUTE IMMEDIATE 'TRUNCATE TABLE SCOTT.tabelle_1'; -- Truncate mit -- implizitem -- Commit END; / SQL> ROLLBACK;
-- Zurückrollen der Transaktion außerhalb der -- autonomen Transaktion
SQL> SELECT count(*) FROM tabelle_1; COUNT(*) ---------14 SQL> SELECT count(*) FROM tabelle_2; COUNT(*) ---------18 SQL> SELECT count(*) FROM tabelle_3; COUNT(*) ---------45
209
3 Verwaltung von Datenbankobjekten
3.7.25 Wichtige Rechte rund um Tabellen Privileg
Beschreibung
CREATE TABLE
Tabellen im eigenen Schema erstellen, ändern und löschen27
ALTER TABLE
Ändern der Eigenschaften einer Tabelle
X
DROP TABLE
Löschen einer Tabelle
X
SELECT ON
Daten einer Tabelle abfragen
X
INSERT
Daten in eine Tabelle einfügen
X
UPDATE
Daten einer Tabelle ändern
X
DELETE
Löschen von Daten einer Tabelle
X
REFERENCES
Referenzieren einer Tabellenspalte mittels Foreign Key Constraint
X
INDEX
Indizieren von Spalten einer Tabelle
X
FLASHBACK
Flashback auf eine spez. Tabelle
X
CREATE ANY TABLE
Erstellen von Tabellen in jedem Schema (datenbankweit)
X
ALTER ANY TABLE
Ändern von Tabellen in jedem Schema (datenbankweit)
X
DROP ANY TABLE
Löschen von Tabellen in jedem Schema (datenbankweit)
X
INSERT ANY TABLE
Einfügen von Daten in Tabellen jedes Schema (datenbankweit)
X
SELECT ANY TABLE
Daten abfragen in jedem Schema (datenbankweit)
X
DELETE ANY TABLE
Löschen von Daten in jedem Schema (datenbankweit)
X
UPDATE ANY TABLE
Daten ändern in jedem Schema (datenbankweit)
X
LOCK ANY TABLE
Sperren von Tabellen in jedem Schema (datenbankweit)
X
FLASHBACK ANY TABLE
Flashback auf jede Tabelle in jedem Schema (datenbankweit)
X
ObjektPrivileg
Systemprivileg X
3.7.26 Informationen zu Tabellen und Spalten im Data Dictionary Die View dba_tables liefert Informationen zu Tabellen: SELECT owner, tablespace_name, table_name, cluster_name, iot_name, iot_type, partitioned, temporary, row_movement,read_only, status, ini_trans, max_trans, logging, degree AS parallelisierungsgrad, cache, last_analyzed, num_rows, blocks, empty_blocks, avg_space FROM dba_tables WHERE owner = 'SCOTT';
Die View dba_segments zeigt die Speicherbelegung: SELECT owner, tablespace_name, segment_name, segment_type, round(bytes/1024/1024) MB FROM dba_segments WHERE owner = 'SCOTT';
Informationen zu einzelnen Extents gibt die View dba_extents aus: SET LINES 150 SET PAGES 3000 SELECT e.owner, e.segment_name, e.segment_type, e.tablespace_name, d.file_name AS "Dateiname", e.file_id, e.extent_id, e.block_id,
27
210
Schließt nicht das Recht ein, Tabellen in fremden Schemata zu erstellen.
3.8 Constraints
FROM WHERE AND AND
round(e.bytes/1024/1024,2) AS "Groesse in MB", e.blocks AS "Anzahl Datenbloecke" dba_extents e, dba_data_files d e.file_id = e.file_id owner = 'SCHMIDT' segment_name = 'T_KUNDEN';
In dba_objects finden Sie Informationen wie den Erstellungszeitpunkt und den Zeitpunkt der letzten Änderung: SELECT owner, object_type, object_name, created, last_ddl_time FROM dba_objects WHERE owner = 'SCOTT' ORDER BY 1, 2, 3;
Informationen zu Spaltennamen und Datentypen zeigt die View dba_tab_columns: SELECT column_id, column_name, data_type, data_length, data_precision FROM dba_tab_columns WHERE owner = 'SCOTT' AND table_name = 'EMP' ORDER By column_id;
3.8
Constraints Constraints definieren Bedingungen, die beim Einfügen, Ändern und Löschen von Datensätzen zu erfüllen sind. Die Implementierung von Constraints in Oracle-Datenbanken entspricht weitestgehend dem ANSI-Standard. Oracle Constraints erhalten stets einen Namen, der entweder bei der Erstellung explizit angegeben oder vom Datenbankserver generiert wird. Wir empfehlen die explizite Vergabe eines für sich sprechenden Namens, da Fehlermeldungen so weitaus verständlicher sind. Der systemgenerierte Name eines Constraints entspricht dem Schema sys_c. Die folgenden Beispiele setzen zwei Tabellen voraus: t_abteilung und t_mitarbeiter: CREATE TABLE t_abteilung (abt_nr NUMBER, abt_name VARCHAR2(20) );
VARCHAR2(22), VARCHAR2(40), DATE, NUMBER (12,2), NUMBER (10,2)
---------
Personalnummer Nummer der Abteilung, in der der Mitarbeiter beschäftigt ist Vorname Nachname Einstellungsdatum Gehalt Bonus
Beide Tabellen werden in den nächsten Abschnitten mit Constraints belegt. Constraints können bereits bei der Tabellenerstellung angegeben werden. Wir empfehlen jedoch eine Trennung von den Schritten des Anlegens und der Belegung mit Constraints sowie die Hinterlegung in verschiedenen Skripten, da dies mehr Flexibilität erlaubt: Bei einer späteren Migration können Sie so beispielsweise zunächst die Tabellen anlegen, danach mit Daten beladen und abschließend die Constraints anlegen.
211
3 Verwaltung von Datenbankobjekten
3.8.1
Not Null
Ein NOT NULL28 Constraint gibt an, dass die betreffende Tabellenspalte stets mit einem Wert belegt werden muss: ALTER TABLE MODIFY <spalten_name> NOT NULL;
Beispiele: ALTER TABLE t_mitarbeiter MODIFY gehalt NOT NULL;
Häufig ergänzt man diese Einschränkung, indem man einen Standardwert an dieselbe Spalte bindet: ALTER TABLE t_mitarbeiter MODIFY einstelldatum DEFAULT sysdate NOT NULL; ALTER TABLE t_mitarbeiter MODIFY gehalt DEFAULT 1000 NOT NULL; ALTER TABLE t_mitarbeiter MODIFY bonus DEFAULT 0 NOT NULL;
3.8.2
Unique
Ein Unique Constraint definiert, dass die Werte einer Spalte bzw. die Werte kombinierter Spalten eindeutig sein müssen. Dies wird auch als Unique Key oder Sekundärschlüssel29 bezeichnet. Eine Tabelle darf beliebig viele Unique Keys enthalten. Syntax: ALTER TABLE ADD CONSTRAINT UNIQUE (<spalten_liste>);
Beispiel: ALTER TABLE t_mitarbeiter ADD CONSTRAINT t_mit_unique_name UNIQUE (nachname, vorname);
Die Überprüfung auf Eindeutigkeit erfolgt mittels Index. Liegt beim Anlegen eines UniqueConstraints noch kein passender Index vor, wird implizit ein eindeutiger Index mit gleichlautendem Namen im Default Tablespace des Tabelleneigentümers erstellt. Möchten Sie die Erstellung des Index gezielt steuern, so können Sie eine Storage-Klausel für diesen anhängen: ALTER TABLE t_mitarbeiter ADD CONSTRAINT t_mit_unique_name UNIQUE (nachname, vorname) USING INDEX TABLESPACE app_01_index;
3.8.3
Primary Key
Ein Primärschlüssel bzw. Primary Key dient in einer relationalen Datenbank dazu, die Tupel einer Relation eindeutig zu identifizieren. Implizit wird mit dem Primary Key auch ein NOT NULL sowie ein Unique-Constraint auf die Spalte bzw. Spaltenkombination gelegt.
28
Wurde einer Spalte eines Tupels kein Wert zugewiesen, so wird hier der NULL hinterlegt. Dies darf nicht mit dem Wert 0 verwechselt werden. Vielmehr steht NULL für einen nicht bekannten Wert. 29 In Abgrenzung zum später dargestellten Primärschlüssel
212
3.8 Constraints Syntax: ALTER TABLE ADD CONSTRAINT PRIMARY KEY(<spalten_liste>);
Beispiel: ALTER TABLE t_abteilung ADD CONSTRAINT pk_abteilung PRIMARY KEY(abt_nr);
Wie ein Unique-Constraint benötigt auch der Primary Key einen Index. Besteht noch kein passender, so wird auch hier wieder implizit ein Index mit gleich lautenden Namen im Default Tablespace des Tabelleneigentümers erstellt. Um die Indexerstellung gezielt zu steuern, können Sie entweder vorab einen passenden Index explizit anlegen oder aber die Storage-Klausel an die Constraint-Klausel anfügen: ALTER TABLE ADD CONSTRAINT USING INDEX
Ein Fremdschlüssel bzw. ein Foreign Key bezeichnet ein Attribut oder eine Attributkombination einer Relation, die auf einen Primärschlüssel einer anderen oder derselben Relation verweist. Foreign Keys gewährleisten referenzielle Integrität. Die Tabelle, auf deren Primärschlüssel verwiesen wird, heißt Mastertabelle. Die Tabelle, die den Fremdschlüssel enthält, ist die Detailtabelle. Syntax: ALTER TABLE ADD CONSTRAINT REFERENCES
FOREIGN KEY () ();
Im folgenden Beispiel wird ein Fremdschlüssel der Tabelle Er verweist auf die Spalte abt_nr der Tabelle t_abteilung. ALTER TABLE ADD CONSTRAINT REFERENCES
Sollen beim Löschen eines Datensatzes der Mastertabelle auch die zugehörigen Datensätze der Detailtabelle entfernt werden, kann man dies mit der Klausel on delete cascade automatisieren: ALTER TABLE t_mitarbeiter ADD CONSTRAINT fk_mitarbeiter_abteilung FOREIGN KEY (abt_nr) REFERENCES t_abteilung (abt_nr) ON DELETE CASCADE;
Alternativ ist es möglich, die Fremdschlüsselspalte auf NULL setzen zu lassen, sobald der referenzierte Datensatz der Primärschlüsseltabelle gelöscht wird: ALTER TABLE t_mitarbeiter ADD CONSTRAINT fk_mitarbeiter_abteilung FOREIGN KEY (abt_nr) REFERENCES t_abteilung (abt_nr) ON DELETE SET NULL;
213
3 Verwaltung von Datenbankobjekten Wurde keine der beiden Klauseln angegeben, so ist beim Löschen eines Datensatzes der Mastertabelle zunächst zu prüfen, dass keine referenzierenden Datensätze in der Detailtabelle enthalten sind. Andernfalls erscheint folgende Fehlermeldung: SQL> DELETE FROM t_abteilung; FEHLER in Zeile 1: ORA-02292: Integritäts-Constraint (SYS.FK_MITARBEITER_ABTEILUNG) verletzt - untergeordneter Datensatz gefunden
Praxistipp Die Implementierung eines Foreign Keys in einer Oracle-Datenbank schließt nicht die implizite Erstellung eines Index ein. Dies führt gelegentlich zu Sperrkonflikten und kann negativen Einfluss auf die Performance bei Abfragen mit einer Verknüpfung über die Fremdschlüsselbeziehung haben. Wir empfehlen dringend die Indizierung von Fremdschlüsselspalten: CREATE INDEX t_mitarbeiter_fk_abt_idx ON t_mitarbeiter (abt_nr) TABLESPACE app01_index;
3.8.5
Check-Contraints
Check-Constraints sind für Plausibilitätsprüfungen geeignet: ALTER TABLE ADD CONSTRAINT CHECK
();
Beispiel: ALTER TABLE t_mitarbeiter ADD (geschlecht CHAR(1)); ALTER TABLE ADD CONSTRAINT CHECK
t_mitarbeiter chk_mitarbeiter_geschlecht (geschlecht IN ('W', 'M') OR geschlecht IS NULL );
Das Beispiel stellt sicher, dass die Spalte geschlecht der Tabelle Einwohnerdaten nur einen der Werte W, M oder unbekannt (NULL) speichern darf. Versucht man nun einen Wert außerhalb des Wertebereichs anzugeben, der im Check-Constraint hinterlegt wurde, so erhält man eine Fehlermeldung: INSERT INTO t_mitarbeiter (pers_nr, nachname, vorname, geschlecht) VALUES (899, 'Schmidt', 'Joan', 'X'); Fehler in Zeile 1: ORA-02290: CHECK-Constraint (SYS.CHK_MITARBEITER_GESCHLECHT) verletzt
Bei Bedarf können Sie auf eine Spalte mehrere Check-Constraints erstellen. Praxistipp Die Verwendung von Unterabfragen, Sequenzen und einigen Funktionen ist in Check-Constraints nicht gestattet. Komplexere Prüfungen, die übergreifend über mehrere Datensätze derselben Tabelle oder auch über mehrere Tabellen hinweg Anwendung finden, können mit einem Trigger implementiert werden.
214
3.8 Constraints Da Trigger jedoch einen negativen Einfluss auf die Performance haben, empfehlen wir, Trigger zur Implementierung von Logik in der Datenbank nur dann anzuwenden, wenn einfache Constraints nicht möglich sind.
3.8.6
Aktivierung und Deaktivierung von Constraints
Bei Wartungsarbeiten, wie beispielsweise einer Reorganisation oder auch bei Datenbeladungen, kann es sinnvoll sein, bestehende Constraints zu deaktivieren. Zum einen kommt es vor, dass der Datenbestand während der Wartungstätigkeiten vorübergehend nicht den Integritätsbedingungen entspricht. Zum anderen benötigen Integritätsprüfungen auch Zeit und Ressourcen und wirken sich damit negativ auf die Laufzeit aus. Syntax: ALTER TABLE ENABLE|DISABLE CONSTRAINT ;
Beispiele: ALTER TABLE t_mitarbeiter DISABLE CONSTRAINT pk_mitarbeiter; ALTER TABLE t_mitarbeiter ENABLE CONSTRAINT pk_mitarbeiter;
Für die Aktivierung mit enable constraints können Sie zusätzlich eines der Schlüsselworte novalidate oder validate angeben. Ein validate sorgt dafür, dass vorhandene Datensätze auf Gültigkeit überprüft werden, während novalidate diese Überprüfung nicht durchführt und voraussetzt, dass der Datenbestand den Gültigkeitskriterien entspricht. Da auch die Validierung der Gültigkeitskriterien bestehender Datensätze Zeit und Ressourcen erfordert, kann eine Umgehung dieser Prüfung sinnvoll sein, sofern gesichert ist, dass der Datenbestand den Kriterien entspricht: ALTER TABLE t_mitarbeiter ENABLE NOVALIDATE CONSTRAINT pk_mitarbeiter;
Bei einer Deaktivierung eines Constraints mit der Aktivierung mit enable ist es validate.
disable
ist
novalidate
der Standard, bei
Um zu identifizieren, welche Datensätze bei einer Validierung zu einer Constraint-Verletzung führen, bietet sich die Exceptions-Klausel an: ALTER TABLE t_mitarbeiter ENABLE VALIDATE CONSTRAINT pk_mitarbeiter EXCEPTIONS INTO exceptions;
Dazu muss man zunächst eine Tabelle exceptions mit folgendem Aufbau erzeugen: SQL> desc exceptions Name Null? ----------------------------------------- -------ROW_ID OWNER TABLE_NAME CONSTRAINT
Typ ------------------ROWID VARCHAR2(30) VARCHAR2(30) VARCHAR2(30)
Für die Erstellung dieser Ausnahmetabelle steht ein SQL-Skript im Verzeichnis rdbms/ Ihres Oracle-Homes zur Verfügung, das Sie beispielsweise aus SQL*Plus heraus wie folgt aufrufen können:
admin
SQL> @?/rdbms/admin/utlexcpt.sql Tabelle wurde erstellt.
215
3 Verwaltung von Datenbankobjekten Oracle bietet für die Aktivierung und Deaktivierung von Constraints weitere Optionen. So wird beim Deaktivieren eines Primary Key- oder Unique-Constraints über die Klausel keep index bzw. drop index gesteuert, wie mit Indizes umzugehen ist, die für die Sicherstellung des Constraints erstellt wurden: ALTER TABLE t_mitarbeiter DISABLE NOVALIDATE CONSTRAINT pk_mitarbeiter KEEP INDEX;
Der Default ist drop index, sodass bei einer Reaktivierung eines Constraints einige Zeit für den Neu-Aufbau des Index einzuplanen ist. Generell gilt: Sofern Abhängigkeiten zwischen Constraints bestehen, sind zunächst abhängige Constraints zu deaktivieren. Besteht beispielsweise ein Foreign Key, der auf eine Primary Key-Spalte zeigt, so kann das Primary Key-Constraint nicht deaktiviert werden, sofern nicht auch alle assozierten Foreign Keys bereits deaktiviert sind: SQL> ALTER TABLE t_abteilung DISABLE CONSTRAINT pk_abteilung; FEHLER in Zeile 1: ORA-02297: Constraint (MBP.PK_ABTEILUNG) kann nicht deaktiviert werden Abhängigkeiten sind vorhanden
Für die Reaktiverung gilt dies in umgekehrter Folge: Zunächst sind Primary Key-Constraints, anschließend abhängige Foreign Key-Constraints zu aktivieren.
3.8.7
Verzögerte Überprüfung
Will man während einer Transaktion erst zum Ende die Gültigkeit der Constraints überprüfen, so kann dies für die aktuelle Session aktiviert werden. Die allgemeine Syntax lautet: ALTER SESSION SET CONSTRAINTS = [IMMEDIATE | DEFERRED | DEFAULT];
Die Verzögerung wird wie folgt aktiviert: ALTER SESSION SET CONSTRAINTS = DEFERRED;
Die verzögerte Überprüfung am Transaktionsende ist für Datenänderungen gut geeignet, die vorübergehend Verletzungen referenzieller Constraints bewirken, die jedoch noch vor dem Transaktionsende wieder korrigiert werden. So lassen sich Datensätze in Detailtabellen noch vor jenen der Mastertabelle einfügen. Wird die Transaktion mit einem Commit abgeschlossen, müssen alle Integritätsbedingungen erfüllt sein. Andernfalls wird ein Fehler mit Angabe des Constraint-Namens zurückgegeben.
3.8.8
Umbenennen von Constraints
Wie bereits erwähnt, empfehlen wir, für sich sprechende Namen für Constraints zu verwenden. Fehlermeldungen bei Constraint-Verletzungen sind damit aussagekräftiger. Um Bezeichner bestehender Constraints zu ändern, können Sie die Klausel rename constraint des Befehls alter table nutzen: ALTER TABLE RENAME CONSTRAINT TO ;
216
3.8 Constraints Beispiel: ALTER TABLE scott.emp RENAME CONSTRAINT sys_c009212 TO pk_emp_empno;
3.8.9
Entfernen von Constraints
Die Klausel drop
constraint
des Befehls alter
table
löscht ein Constraint:
ALTER TABLE DROP CONSTRAINT ;
Beispiel: ALTER TABLE t_mitarbeiter DROP CONSTRAINT t_mit_unique_name ;
Ein „NOT NULL“-Constraint lässt sich wie folgt zurücksetzen: ALTER TABLE t_mitarbeiter MODIFY (gehalt
null);
3.8.10 Wichtige Rechte rund um Constraints ObjektPrivileg
Privileg
Beschreibung
REFERENCES
Referenzieren mittels Foreign Key Constraint
X
ALTER TABLE
Hinzufügen, ändern und löschen von Constraints
X
Systemprivileg
3.8.11 Informationen zu Constraints im Data Dictionary Die Views dba_constraints und dba_cons_columns zeigen Informationen zu Constraints. Die Spalte dba_constraints.constraint_type gibt den Typ an:
U: Unique P: Primary Key R: Foreign Key (Reference) C: Check V: View mit Check-Option O: Read Only View Folgende Abfrage zeigt eine Übersicht: SELECT FROM WHERE AND
Mittels dba_cons_columns.column_name können Sie die Spalten eines Constraints abfragen. dba_cons_columns.position ermittelt zusätzlich die Spaltenreihenfolge bei mehrspaltigen Constraints: SELECT con.owner, con.table_name, con.constraint_name, con.constraint_type, col.position, col.column_name FROM dba_constraints con, dba_cons_columns col WHERE con.owner = col.owner AND con.table_name = col.table_name AND con.constraint_name = col.constraint_name AND con.owner = 'SCOTT'
217
3 Verwaltung von Datenbankobjekten AND con.table_name ORDER BY 1, 2, 3, 5;
= 'EMP'
Check-Constraints zeigen in der Spalte search_condition die Plausibilitätsprüfung: SELECT owner, table_name, constraint_type, search_condition FROM dba_constraints WHERE constraint_type = 'C';
Informationen zu Foreign Keys und deren Referenzen ermitteln Sie wie folgt: COL COL COL COL COL COL COL SET SET
SELECT c.table_name DETAIL_TAB, c.constraint_name FOREIGN_KEY, c.position position, c.column_name DETAIL_COL, d.table_name MASTER_TAB, d.column_name MASTER_COL FROM dba_cons_columns c, dba_cons_columns d, dba_constraints a WHERE c.owner='SCOTT' AND c.constraint_name=a.constraint_name AND a.constraint_type='R' AND a.R_CONSTRAINT_NAME=d.CONSTRAINT_NAME AND c.position = d.position ORDER BY 1, 2, 3;
3.9
Views Eine View ist eine benannte Abfrage. Sie dient der aufbereiteten Darstellung von Daten, die in Tabellen gespeichert sind. Ihre Definition wird in Form eines SQL-Statements hinterlegt. Die Details des Statements bleiben dem Anwender verborgen. Man nutzt daher häufig Views als zusätzlichen Abstraktionslayer, um das Datenmodell zu kapseln und Komplexität zu verbergen. Auf Views kann mit SQL-Statements zugegriffen werden. Die Syntax der Statemetents und die Darstellung der Ergebnismenge entsprechen denen auf Tabellen. Beim Verarbeiten einer Abfrage einer View ersetzt Oracle die darunterliegende Abfragedefinition.
3.9.1
Standard-Views
Standard-Views speichern selbst keine Daten, sondern lediglich die Definition eines SQLStatements: CREATE [OR REPLACE] VIEW AS <select_statement>;
Beispiel: CREATE OR REPLACE VIEW v_mitarbeiter_gehalt_abt_20 AS SELECT abt_nr, nachname, gehalt*13.5 AS Jahresgehalt
218
3.9 Views FROM WHERE
t_mitarbeiter abt_nr = 20;
Die Syntax zur Abfrage einer View entspricht der einer normalen Tabelle: SELECT * FROM v_mitarbeiter_gehalt_abt_20; SELECT abt_name, jahresgehalt FROM v_mitarbeiter_gehalt_abt_20 g, t_abteilung a WHERE g.abt_nr = a.abt_nr;
Views können ihrerseits auf andere Views verweisen: CREATE OR REPLACE VIEW v_abt_jahresgehalt AS SELECT abt_name, jahresgehalt FROM v_mitarbeiter_gehalt_abt_20 g, t_abteilung a WHERE g.abt_nr = a.abt_nr;
SQL-Statements einer View-Definition können beliebig gültige Abfragen enthalten. Ausnahme ist die „Order By“-Klausel, die in Views nicht möglich ist. Verknüpfungen mehrerer Tabellen, Funktionsaufrufe, Gruppierungen und Aggregate sind jedoch gestattet: CREATE OR REPLACE VIEW v_mitarbeiter_gehalt_agg AS SELECT abt_nr AS Abteilungsnummer, min(gehalt) AS Mindestgehalt, max(gehalt) AS Maximalgehalt, avg(gehalt) AS Gehaltsdruchschnitt FROM t_mitarbeiter GROUP BY abt_nr;
Eine Standard-View kann aktualisiert oder mit neuen Daten befüllt werden. Dies gilt auch dann, wenn die View auf mehrere Tabellen zugreift. Jedoch gibt es hierfür einige Einschränkungen: Damit ein direktes Insert in eine View möglich ist, sind Klauseln wie distinct oder group by nicht im Select-Statment der View zulässig. Zudem sind beim Einfügen von Sätzen ein eventuell vorhandener Primary Key sowie alle „Not Null“-Spalten zu befüllen. Komplexe Views, die Klauseln wie distinct oder group by verwenden oder auf komplexe Abfragen auf mehrere Tabellen zugreifen, können auch mit einem Instead-Of-Trigger belegt werden. Hier lässt sich die Logik für Datenmanipulationen von Views höherer Komplexität hinterlegen. dba_views zeigt die Informationen zu Views: SELECT FROM WHERE
3.9.2
owner, view_name, read_only, text dba_views view_name = 'V_ABT_JAHRESGEHALT';
Materialized Views
Materialized Views speichern Abfrage-Resultate. Sie werden häufig genutzt, um umfangreiche Abfragen mit Aggregaten und Berechnungen zu beschleunigen und um Daten zu replizieren. Dies ist auch datenbankübergreifend über eine Database Link möglich: CREATE MATERIALIZED VIEW LOG ON <speicher_parameter>;30
30
Die Verwendung eines Materialized View Logs ist optional. Ohne Log ist ein Complete Refresh erforderlich, mit Log ein Fast Refresh möglich.
219
3 Verwaltung von Datenbankobjekten CREATE MATERIALIZED VIEW <speicher_parameter> AS <select_statement>;
<mview_name>
Beispiel: CREATE MATERIALIZED VIEW mv_abt_jahresgehalt TABLESPACE app_01_data AS SELECT abt_name, jahresgehalt FROM v_mitarbeiter_gehalt_abt_20 g, t_abteilung a WHERE g.abt_nr = a.abt_nr;
Eine Materialized View kann mit einem Complete Refresh oder inkrementell über eine Fast Refresh aktualisiert werden. Wird die View angelegt, erfolgt initial stets ein Complete Refresh. Dabei wird die hinterlegte Abfrage ausgeführt und die Ergebnismenge gespeichert. Die Initialisierung kann daher bei komplexen Abfragen und großen Datenmengen einige Zeit in Anspruch nehmen. Sofern die Daten der Quelltabellen in derselben Datenbank liegen, lässt sich ein Fast Refresh ausführen, sobald Datenänderungen auf die Basistabellen mit einem Commit bestätigt sind. Alternativ kann der Refresh in einem regelmäßigen Turnus oder aber nur auf Anfrage erfolgen. Für die Durchführung von Fast Refreshs sind Materialized View Logs für jede assoziierte Tabelle erforderlich. Materialized View Logs auf die Basistabellen müssen vor der Erstellung der Materialized View bereitgestellt werden. CREATE MATERIALIZED VIEW LOG ON t_mitarbeiter TABLESPACE app_05_data STORAGE (INITIAL 10 M NEXT 10 M); CREATE MATERIALIZED VIEW LOG ON t_mitarbeiter TABLESPACE app_05_data STORAGE (INITIAL 2 M NEXT 2 M); CREATE MATERIALIZED VIEW mv_abt_jahresgehalt TABLESPACE app_01_data AS SELECT abt_name, gehalt * 13.5 AS jahresgehalt FROM t_mitarbeiter m, t_abteilung a WHERE m.abt_nr = a.abt_nr;
Weitere Informationen finden Sie in Kapitel 15 „Große Datenbanken“.
3.9.3
Objekt-Views
Objekt-Views unterstützen beim objektrelationalen Mapping: Sie ermöglichen, dass objektorientierte Applikationen die Daten als Sammlung von Objekten sehen, die Attribute und Methoden besitzen, während andere Systeme weiterhin Operationen auf relationale Strukturen ausführen können. Objekt-Views können abstrakte Datentypen, Objekt-Identifier (OIDs) und Referenzen simulieren, wie sie sonst objektorientierte Datenbanken bieten. Wie bei regulären Views lassen sich in der View-Definition Instead Of-Trigger einsetzen. So kann DML mithilfe eines PL/SQL-Blocks anstelle der tatsächlichen DML-Anweisung ausgeführt werden. CREATE TABLE t_mitarbeiter ( mit_nr NUMBER (8), nachname VARCHAR2 (30),
220
3.9 Views gehalt Beruf
NUMBER (12,2), VARCHAR2 (20));
CREATE TYPE mitarbeiter_type AS OBJECT ( mit_nr NUMBER (8), nachname VARCHAR2 (30), gehalt NUMBER (12,2), Beruf VARCHAR2 (20)); / CREATE VIEW DBA_ov OF mitarbeiter_type WITH OBJECT IDENTIFIER (mit_nr) AS SELECT m.mit_nr, m.nachname, m.gehalt, m.beruf FROM t_mitarbeiter m WHERE beruf = 'DBA';
3.9.4
Wichtige Rechte rund um Views ObjektPrivileg
Privileg
Beschreibung
CREATE VIEW
Erstellen von Views
SELECT
Daten einer View abfragen
X
INSERT
Einfügen von Daten in eine View
X
UPDATE
Aktualisieren von Daten einer View
X
DELETE
Löschen von Daten einer View
X
REFERENCES
Verweise mit Fremdschlüssel gestatten
X
3.9.5
Systemprivileg X
Informationen zu Views im Data Dictionary
Informationen zur Views finden Sie unter dba_views. Hier können Sie unter anderem auch das hinterlegte SQL-Statement entnehmen: SET LONG 1000 SELECT FROM WHERE AND
owner, view_name, text dba_views owner = 'SCHMIDT' view_name = 'EINE_VIEW';
dba_objects SELECT FROM WHERE AND
zeigt zudem Daten wie den Erstellungs- und Änderungszeitpunkt:
Die Spalte dba_object.status enthält Informationen über nicht kompilierbare Views. Wurde beispielsweise eine Tabelle gelöscht, die im Select-Statement einer View angesprochen wird, so lautet der Status „invalid“. Materialized Views belegen physisch Speicherplatz in einem Tablespace. Informationen zu belegten Speicherextents sind daher in dba_extents, zu Segmenten in dba_segments zu finden.
221
3 Verwaltung von Datenbankobjekten
3.10
Indizes Ein Index ist eine Datenstruktur, die den direkten Zugriff auf Tupel anhand eines Attributwertes beschleunigen kann. Indizes optimieren Zugriffe auf Datenzeilen, sofern nur ein kleiner Teil der Zeilen aus der Tabelle abzuholen ist. Sie speichern Werte der indizierten Spalte(n) in einer sortierten Reihenfolge gemeinsam mit der RowID31, der Zeile, die den indizierten Wert enthält. Die RowId ist für jede Datenzeile eindeutig und enthält neben der Dateinummer des Datafiles auch die exakte Blockadresse des Datenblockes, in dem die Zeile gespeichert ist.
3.10.1 B*Baum Standardmäßig werden Indizes unter Oracle in einer B*-Tree-Struktur gespeichert. Durch Verwendung eines B*-Baums fallen bei einem Suchlauf im Index nur wenige I/Os an. Die allgemeine Syntax zur Erstellung eines B*-Baum-Index lautet: CREATE INDEX ON (<spalte> | <spalten_liste>);
Beispiel: CREATE INDEX t_einwohnerdaten_name02_idx ON t_einwohnerdaten (nachname, vorname);
Die Views dba_indexes, tionen zu Indizes.
dba_objects, dba_segments
und
dba_extents
liefern Informa-
Tablespace-Klausel Die Tablespace-Klausel legt den Tablespace für die Speicherung des Index fest: CREATE INDEX ON (<spalte> | <spalten_liste>) TABLESPACE ;
Beispiel: CREATE INDEX t_einwohnerdaten_name02_idx ON t_einwohnerdaten (nachname, vorname) TABLESPACE app_01_index;
Die Angabe des Tablespaces zur Speicherung ist optional. Wird kein Tablespace angegeben, speichert Oracle den Index im Default Tablespace des Benutzers. Die View dba_segments gibt an, in welchem Tablespace ein Index gespeichert ist: SELECT owner, segment_name, segment_type, tablespace_name FROM dba_segments WHERE segment_name = 'T_EINWOHNERDATEN_NAME02_IDX'; 31
222
Die RowId ist die eindeutige Adresse einer Datenzeile in einer Datenbank. Oracles RowId nutzt eine 64-Base-Kodierung mit den Zeichen A-Z, a-z, 0-9, + und /. Das Format OOOOOO-FFFBBBBBB-RRR gibt die Objekt-Nummer (O), die relative Dateinummer (F), die Blocknummer (B) und die Zeilenadresse innerhalb des Blockes (R) an. Mit ihr ist eine Datenzeile eindeutig und direkt allokierbar. Ein Datenbank-Index ähnelt dem Index eines Buchs: Auch hier liegt eine sortierte Reihenfolge von Suchbegriffen vor, die einer Adresse (hier: Seitennummer und Absatz) zugeordnet wird.
3.10 Indizes Praxistipp Wir empfehlen, Kerndaten und Indizes zu trennen, um Wartungsarbeiten wie die Index-Reorganisation zu erleichtern. Siehe auch Kapitel 2 „Architektur und Administration“, Abschnitt 2.2.5 „Empfehlungen zum Tablespace-Layout“.
Nosort Standardmäßig sortiert Oracle die zu indizierenden Werte vor der Index-Erstellung. Sofern die Daten bereits in aufsteigend sortierter Reihenfolge vorliegen, kann mit der Klausel nosort dieser Schritt übersprungen werden. Dies spart – gerade bei sehr großen Tabellen – Ressourcen und Zeit. Liegen die Daten nicht in sortierter Reihenfolge vor, gibt Oracle einen Fehler zurück. CREATE INDEX t_einwohnerdaten_name02_idx ON t_einwohnerdaten (nachname, vorname) NOSORT;
Der Sortiervorgang der Daten während der Indexerstellung entfällt damit. Gerade bei Datenbeladungen großer Tabellen mit Attributen in sortierter Reihenfolge kann dies einige Zeit sparen. Liegen die Daten nicht in sortierter Form vor, schlägt der Befehl mit folgender Fehlermeldung fehl: ORA-01409: Option NOSORT darf nicht benutzt werden; Zeilen nicht in aufsteigender Folge
Komprimierung Index Key Compression ist bereits seit Oracle 8i verfügbar und steht für B*-Tree-Indizes und IOTs zur Verfügung. Innerhalb eines Datenblocks eliminiert sie sich wiederholende Schlüssel-Werte im Präfix eines Index. Zusammengesetzte Schlüssel in einem Index werden dabei in einen Präfix- und einen Suffix-Anteil differenziert. Wenn sich Schlüsselwerte im Präfix-Teil des Index wiederholen, werden diese Werte nur einmal gespeichert und vom Suffix referenziert. Präfix und Suffix befinden sich dabei grundsätzlich im gleichen Datenblock. Dies bewirkt eine Reduzierung der Index Leaf Pages und damit der Anzahl der I/O Operationen bei einem Indexzugriff. Index Key Compression wird entweder beim Anlegen oder mittels Rebuild implementiert. Syntax: CREATE INDEX ON (<spalten_liste>) COMPRESS|NOCOMPRESS <speicher_parameter>; ALTER INDEX REBUILD ONLINE COMPRESS|NOCOMPRESS; CREATE INDEX t_einwohnerdaten_name02_idx ON t_einwohnerdaten (nachname, vorname) COMPRESS TABLESPACE app_01_index;
Komprimierung während eines Index Rebuilds: ALTER INDEX t_einwohnerdaten_name02_idx REBUILD ONLINE COMPRESS;
223
3 Verwaltung von Datenbankobjekten Die Klausel nocompress sorgt für die Dekomprimierung: ALTER INDEX t_einwohnerdaten_name02_idx REBUILD ONLINE NOCOMPRESS;
Ob ein Index komprimiert wurde, ermitteln Sie mit folgendem Statement: SELECT WHERE
index_name, compression FROM dba_indexes index_name = 'T_EINWOHNERDATEN_NAME02_IDX';
3.10.2 Bitmap Index Ein Bitmap Index zeigt im Vergleich zu einem B*-Tree-Index signifikante strukturelle Unterschiede in den Blattknoten des Index. Er speichert für jeden differenzierten Wert der indizierten Spalte einen Eintrag mit je einem eigenen Bitmap, das anzeigt, ob dieser in der indizierten Spalte einer Datenzeile enthalten ist oder nicht. Die Länge des Bit-Strings entspricht der Anzahl der Zeilen der indizierten Tabelle. Bitmap Indizes sind daher primär für Spalten mit niedriger Kardinalität geeignet, also einer geringen Werteausprägung. Ein Bitmap Index kann Speicherplatz sparen und die Antwortzeit verbessern. So eliminiert Oracle bei einer Abfrage mit mehreren where-Klauseln auf Spalten, die mit einem Bitmap Index indiziert wurden, vor dem eigentlichen Zugriff auf die Tabelle alle potenziellen Zeilen. Mehrere Bitmaps ermitteln anhand von and- und or-Operationen, auf welche Zeilen der Tabelle ein Zugriff erfolgen soll.
Abbildung 3.2 Aufbau der Bitmap-Indizes auf die Attribute Geschlecht und Augenfarbe
Praxistipp Auch wenn die Verwendung eines Bitmap Index auf jede Spalte gestattet ist, ist sein Einsatz nur effizient, wenn die zu indizierende Spalte eine niedrige Kardinalität, also wenige unterschiedliche Werte besitzt. Die Spalte geschlecht der Tabelle t_mitarbeiter wäre hierfür geeignet (Werteausprägungen „w“, „m“ und „NULL“) oder eine Spalte artikel_farbe einer Artikel-Tabelle. Der Bitmap-Index auf die Spalte geschlecht speichert nur zwei Bitmaps in einem Index. Andererseits enthielte ein Bitmap-Index auf die Spalte nachname nahezu so viele Bitmaps wie Zeilen in der Tabelle. In diesem Fall ist einem B*-Tree-Index der Vorzug zu geben.
Eine Variante der Bitmap-Indizes sind Bitmap-Join-Indizes. Diese legen einen BitmapIndex auf Tabellenspalten an, die häufig mit der gleichen Spalte in einer oder mehreren Tabellen verknüpft werden. Die Vorteile zeigen sich insbesondere in Data-Warehouse-Umgebungen, in denen man auf eine Fact-Tabelle und eine oder mehrere Dimensionstabellen
224
3.10 Indizes einen Bitmap-Index anlegt: Die Tabellen werden vorab verknüpft; dies kann bei der späteren Ausführung einer Abfrage mit dem passenden Join signifikant CPU- und I/O-Ressourcen sparen. Syntax: CREATE BITMAP INDEX ON (<spalten_liste>) <speicher_parameter>;
Beispiel: CREATE BITMAP INDEX t_mitarbeiter_geschlecht_idx ON t_mitarbeiter (geschlecht) TABLESPACE USERS;
Weitere Informationen finden Sie in Kapitel 15 „Große Datenbanken“.
3.10.3 Reverse Key Index B*-Tree-Indizes können auch als Reverse Key Index definiert sein. Dabei sind alle Bytes der indizierten Spalte in umgekehrter Reihenfolge indiziert. So wird eine Kundennummer „12345“ als „54321“ und der Wert „Schmidt“ als „tdimhcS“ indiziert. Durch die umgekehrte Speicherung der Bytes werden Werte, die bei einem normalen B*-Tree im selben Leaf Block gespeichert sind, auf unterschiedliche Blätter verteilt. Diese Verteilung gilt auch bei DML-Operationen: I/O-Zugriffe, die beispielsweise beim Einfügen von Datenzeilen mit einem monoton steigenden Primärschlüssel auf Leaf-Blöcke entstehen, werden breiter verteilt. Syntax: CREATE INDEX ON (<spalten_liste>) REVERSE <speicher_parameter>;
Beispiel: CREATE INDEX pk_t_mitarbeiter ON t_mitarbeiter (pers_nr) REVERSE TABLESPACE USERS;
Reverse Key-Indizes kommen häufig in Oracle RAC-Konfigurationen zum Einsatz, um Hot Blocks bei konkurrierenden Zugriffen bei Einfügevorgängen und den daraus entstehenden Overhead zu vermeiden. Aufgrund der Umkehrung der Byte-Reihenfolge sind jedoch keine Index Range Scans möglich. Für eine Abfrage auf Bereiche wie beispielsweise mit der Einschränkung where pers_nr between 100 and 125 ist dieser Index-Typ daher nicht nutzbar.
3.10.4 Funktionsbasierter Index Wird in der Where-Klausel einer Abfrage ein Ausdruck oder eine Funktion genutzt, so kann dabei kein Standard-B*-Tree-Index vorkommen. Ein Beispiel: CREATE INDEX ew_nachname_idx ON einwohnerdaten(nachname) TABLESPACE app_01_index; SELECT * FROM einwohnerdaten WHERE upper(nachname) = 'SCHMIDT';
225
3 Verwaltung von Datenbankobjekten Obiger Index ist nicht möglich, da die Spalte Nachname in Groß-/Kleinschreibung indiziert wurde, nicht jedoch der Ausdruck upper(nachname). Ein funktionsbasierter Index indiziert eine Spalte inklusive eines Ausdrucks. Stimmt dieser mit der Angabe in der Where-Klausel überein, so ist der Index nutzbar. Syntax: CREATE INDEX ON () <speicher_parameter>;
Beispiel: CREATE INDEX ew_nachname_idx ON einwohnerdaten(upper(nachname)) TABLESPACE app_01_index;
Ähnlich verhält es sich im folgenden Beispiel, einer Abfrage nach dem Jahresgehalt der Mitarbeiter: CREATE INDEX t_mitarbeiter_gehalt_idx ON t_mitarbeiter (gehalt) TABLESPACE USERS; SELECT * FROM t_mitarbeiter WHERE (gehalt * 12) > 60000;
Obiger Index ist nicht nutzbar. Ein passender funktionsbasierter Index wäre: CREATE INDEX t_mitarbeiter_jahresgehalt_idx ON t_mitarbeiter ((gehalt*12)) TABLESPACE USERS;
Damit ein funktionsbasierter Index genutzt wird, muss Query Rewrite aktiviert sein. ALTER SYSTEM SET query_rewrite_enabled = TRUE;
Die Struktur eines funktionsbasierten Index entspricht der eines B*-Tree-Index. Jedoch wird anstelle des Spaltenwerts eine Funktion oder ein Ausdruck eingesetzt. Funktionsbasierte Indizes sind hilfreich, wenn häufig derselbe Ausdruck auf eine Spalte in der WhereKlausel von Abfragen zum Einsatz kommt. Ein typisches Beispiel ist die Abfrage von Namen und Adressen, die in Groß-/Kleinschreibung in der Datenbank hinterlegt sind, jedoch über eine Abfragemaske mit einer upper- oder lower-Funktion abgefragt werden.
3.10.5 Unique Index Belegt man eine Tabelle mit einem Unique- oder Primary Key-Costraint, so wird ein Unique Index implizit vom Datenbankserver angelegt, sofern nicht schon ein passender Index vorhanden ist. Das Schlüsselwort unique erstellt bei der Indexerstellung explizit einen eindeutigen Index: CREATE UNIQUE INDEX ON (<spalten_liste>) <speicher_parameter>;
Beispiel: CREATE UNIQUE INDEX u_mitarbeiter_01 ON t_mitarbeiter (pers_nr) TABLESPACE USERS;
Die View dba_indexes zeigt, ob ein Index als Unique Index angelegt ist: SELECT WHERE
226
owner, index_name, uniqueness FROM dba_indexes index_name = 'U_MITARBEITER_01';
3.10 Indizes
3.10.6 Online Erstellung eines Index Das Schlüsselwort online minimiert Sperren während der Index-Erstellung oder während eines Index Rebuild. Weitere DML-Operationen wie „insert“, „update“ und „delete“ sind auf die zu indizierende Tabelle möglich. Syntax: CREATE INDEX ON (<spalten_name>) ONLINE;
Beispiel: CREATE INDEX t_einwohnerdaten_name02_idx ON t_einwohnerdaten (nachname, vorname) ONLINE;
DDL-Operationen sowie Parallel Execution sind während der Online-Erstellung nicht gestattet.
3.10.7 Speicherparameter: Tablespace und Extentgrößen Datenbankobjekte wie Indizes und Tabellen sind stets in Extents gespeichert32. Die Größe der zu allokierenden Extents können Sie mit den Klauseln initial für das erste Extent und next für jedes weitere Extent angeben. Die Klausel maxextents legt fest, wie viele Extents maximal allokiert werden dürfen: CREATE INDEX [STORAGE ([INITIAL ] [NEXT ] [maxextents ])] [TABLESPACE ]; ALTER INDEX REBUILD [STORAGE ([INITIAL ] [NEXT ] [maxextents ])] [TABLESPACE ];
Beispiel: CREATE INDEX t_kunden_02_idx ON t_kunden(nachname) STORAGE (INITIAL 10 M NEXT 10 M MAXEXTENTS UNLIMITED) TABLESPACE app_01_data;
3.10.8 Einstellen der Größe des Transaktionsheaders Oracle speichert im Kopf eines jeden Datenblockes einen Transaktionsheader. Jede Transaktion auf einen Daten- oder einen Index-Block benötigt einen eigenen Transaktionsslot. Aufgrund der hohen Anzahl an Einträgen in einem Leaf-Block kann so für Indizes – speziell auch für jene, die Spalten mit monoton steigenden Werten indizieren – ein Engpass entstehen. Typisches Beispiel sind Datenbeladungen für Tabellen, die inkrementierte Primary Key-Werte enthalten. Der Parameter initrans legt fest, wie viele Slots für Transaktionen initial bereitgestellt werden. Sofern Block Waits auf Index-Blöcke aufgrund mangelnder Transaktionsslots ent32
Siehe Abschnitt 3.3 “Speicherhierarchie”.
227
3 Verwaltung von Datenbankobjekten stehen, ist er zu erhöhen. Der Parameter maxtrans gibt die maximale Anzahl an Transaktionsslots im Header an. Beide Parameter sind entweder während der Index-Erstellung oder während eines Rebuilds möglich. CREATE INDEX ON (<spalten_liste>) INITRANS MAXTRANS <m> [<speicher_parameter>];
mit 1 <= n <= m <= 255
Beispiel: CREATE INDEX t_kunde_nachname_idx INITRANS 2 MAXTRANS 200 TABLESPACE app_07_index;
ON kunde(nachname)
ALTER INDEX t_kunde_nachname_idx REBUILD INITRANS 12 MAXTRANS 255 TABLESPACE USERS;
Die Einstellungen des Transaktionsheaders lassen sich auch für Tabellen anwenden. Siehe auch Abschnitt 3.7.10 „ Einstellen der Größe des Transaktionsheaders“. Praxistipp Da Indizes aufgrund der höheren Schlüsseldichte meist auch eine höhere Transaktionsdichte pro Datenblock als Tabellen aufweisen, empfiehlt es sich, den Wert für initrans eines Index höher als den der Tabelle, mindestens jedoch auf 2 zu setzen. Hiermit garantieren Sie, dass stets mindestens die in initrans angegebene Anzahl paralleler Transaktionen auf denselben Datenblock möglich sind.
3.10.9 Reorganisation / Index Rebuild Beim Löschen von Datenzeilen einer indizierten Tabelle erhalten deren Einträge in einem Index ein Lösch-Flag, sie bleiben jedoch physisch vorhanden. Auch bei einer Aktualisierung eines indizierten Spaltenwertes ist der Effekt ähnlich: der alte Eintrag bekommt ein Lösch-Flag, der neue wird dem Index hinzugefügt. Der freie Speicher im Index-Block ist zwar wieder frei, doch bei monoton steigenden Werten wie bei Angaben zu einem Rechnungsdatum oder Primärschlüsseln, die inkrementiert werden, ist eine Wiederverwendung nicht sehr wahrscheinlich. Ein Index Rebuild sorgt in einem solchen Fall für eine interne Reorganisation: ALTER INDEX REBUILD [ONLINE] [<speicher_parameter>];
Beispiel: ALTER INDEX t_einwohnerdaten_name02_idx REBUILD;
Oracle nutzt bei einem Rebuild den vorhandenen Index als Datenquelle für den neuen Index. Daher ist genügend Speicherplatz notwendig, um während der Operation zwei Versionen des Index hinterlegen zu können. Der Befehl alter index rebuild ändert auch die Speichercharakteristiken, die Größe des Transaktionsheaders und die Tablespace-Zuweisungen für einen Index:
228
3.10 Indizes ALTER INDEX t_einwohnerdaten_name02_idx REBUILD INITRANS 4 STORAGE (INITIAL 10 M NEXT 10 M) TABLESPACE USERS;
Bei einem Online Rebuild sind weitere DML-Operationen wie „insert“, „update“ und „delete“ auf die indizierte Tabelle möglich: ALTER INDEX t_einwohnerdaten_name02_idx REBUILD ONLINE;
Will man einen partitionierten Index reorganisieren, kann dies nicht über den gesamten Index, sondern nur über eine einzelne Partition erfolgen: ALTER INDEX t_einwohnerdaten_name02_idx REBUILD PARTITION p063 TABLESPACE app_01_index;
Das folgende Statement führt ein Index Rebuild im Nologging-Modus aus: ALTER INDEX t_einwohnerdaten_name02_idx REBUILD NOLOGGING;
Das Rebuild wird nicht in den Redo Logs verzeichnet. Dies hat zur Folge, dass nach einem Restore und Recovery der Datenbank der Index zunächst erneut über ein Rebuild aktualisiert werden muss, bevor er wieder verwendet werden kann. Nologging-Operationen sollte man daher mit Bedacht nutzen. Praxistipp Bei größeren Schlüssellängen ist es möglich, dass sich die Online-Option nicht einsetzen lässt. In diesem Fall ist auf ein Standard-Rebuild ohne Online-Klausel zurückzugreifen.
3.10.10 Speicherplatz eines Index ermitteln Die View dba_segments zeigt den durch Indizes belegten Speicherplatz an: SELECT FROM
owner, segment_name, round(bytes/1024/1024) AS MB dba_segments WHERE segment_type = 'INDEX';
3.10.11 Speicherplatz freigeben Werden Indizes durch Datenänderungen häufig aktualisiert, kann es notwendig sein, eine Reorganisation mittels Rebuild durchzuführen, um Fragmentierungen zu minimieren. Der Hintergrund dazu: Index-Einträge werden nicht physisch gelöscht, sondern nur mit einem Lösch-Flag versehen. Da Schlüsselwerte in Indizes sortiert gespeichert sind, werden bei B*-Tree-Indizes auch Update-Operationen als Löschen und Einfügen des neuen Werts realisiert. Der Index wird so stets größer. Das gilt auch dann, wenn man Daten entfernt. Eine Reorganisation verkleinert den Index wieder: Einträge, die mit einem Lösch-Flag versehen waren, werden in den reorganisierten Index nicht übernommen. Syntax: ALTER ALTER ALTER ALTER
3 Verwaltung von Datenbankobjekten Beispiel: Eine Analyse überprüft, ob eine Reorganisation sinnvoll ist: ANALYZE INDEX pk_mitarbeiter_idx VALIDATE STRUCTURE;
Die View index_stats zeigt dann Informationen zur Speicherbelegung und zur Anzahl gelöschter Einträge: SELECT name, height, blocks, del_lf_rows, del_lf_rows_len FROM index_stats; NAME HEIGHT BLOCKS DEL_LF_ROWS DEL_LF_ROWS_LEN -------------- ---------- ---------- ----------- --------------PK_MITARBEITER 3 2816 470616 7050887
Ein Rebuild baut den Index neu auf: ALTER INDEX pk_mitarbeiter REBUILD;
Alternativ kann auch ein Online Rebuild erfolgen: ALTER INDEX pk_mitarbeiter REBUILD ONLINE;
Ein Online Rebuild unterliegt strikteren Limitierungen bezüglich der Schlüssellänge. In einigen Fällen kann die Fehlermeldung „ORA-1450 maximum key length exceeded“ auftreten. In diesem Fall ist leider ein Offline Rebuild erforderlich. Ein Rebuild kann auch Storage-Parameter wie den Tablespace zur Speicherung ändern: ALTER INDEX pk_mitarbeiter REBUILD ONLINE TABLESPACE app_neu_index;
Der Befehl Shrink Space führt keine komplette Reorganisation des Index aus, er entfernt nur leere Blöcke. Dies kann sinnvoll sein, wenn bei einer Indizierung monoton steigender Werte ein Delete auf einen Bereich ausgeführt wurde. ALTER INDEX t_einwohnerdaten_name02_idx SHRINK SPACE;
Ein Coalesce führt benachbarte Index-Blöcke zusammen. Da der Index nicht komplett neu aufgebaut wird, ist der Ressourcenverbrauch geringer: Der temporäre Speicherbedarf eines Rebuild ist hier nicht erforderlich und es wird weit weniger CPU-Zeit benötigt. ALTER INDEX pk_mitarbeiter COALESCE;
Soll nur freier Speicherplatz deallokiert werden, so ist dies mit deallocate möglich: ALTER INDEX pk_mitarbeiter DEALLOCATE UNUSED;
Hierbei wird keine Reorganisation durchgeführt, sondern freier Platz oberhalb der High Water Mark33 freigegeben. Bei Bedarf kann auch eine Größe angegeben werden, die oberhalb der High Water Mark noch freien Platz beibehält: ALTER INDEX pk_mitarbeiter DEALLOCATE UNUSED KEEP 200 M;
3.10.12 Deaktivieren eines Index Ein Index mit dem Flag unusable kann (vorübergehend) nicht mehr aktualisiert und für Abfragen nicht genutzt werden. 33
230
Siehe auch Abschnitt 4.4.1 „High Water Mark“.
3.10 Indizes Syntax: ALTER INDEX UNUSABLE;
Beispiel: ALTER INDEX t_einwohnerdaten_name02_idx UNUSABLE;
Die View dba_indexes zeigt den Status usable oder unusable an: SELECT INDEX_NAME, STATUS FROM DBA_INDEXES WHERE INDEX_NAME LIKE 'T_EINWOHNERDATEN_NAME02_IDX'
Ein Rebuild führt einen nicht nutzbarer Index kann in den Status usable über: ALTER INDEX t_einwohnerdaten_name02_idx rebuild;
Der Wert der Spalte dba_indexes.status wechselt dann wieder auf valid.
3.10.13 Invisible Index Oracle Database 11g R1 brachte neue Statuskennzeichen für Indizes: „visible“ und „invisible“. Ein Index mit dem Flag „invisible“ ist für den Oracle Optimizer standardmäßig nicht sichtbar; er wird bei der Bestimmung des optimalen Datenzugriffsplanes ignoriert. Der Optimizer verhält sich also, als bestünde der Index gar nicht. Mit Setzen des Parameters optimizer_use_invisible_indexes oder aber mit einem Hint in einem SQL-Statement werden invisible Indizes explizit angesteuert. Dies macht es möglich, neue Indizes auf einem System zu testen, ohne dass sich dies auf produktive Zugriffe auswirkt. Um einen nicht sichtbaren Index zu erstellen, wird dem Befehl Klausel invisible angefügt:
create index
einfach die
CREATE INDEX ON (<spalten_liste>) VISIBLE|INVISIBLE;
Beispiel: CREATE INDEX t_einwohnerdaten_name02_idx ON t_einwohnerdaten (nachname, vorname) INVISIBLE;
Die Schlüsselwörter visible bzw. unvisible ändern den Status eines bestehenden Index: ALTER INDEX VISIBLE|INVISIBLE;
Beispiel: ALTER INDEX t_einwohnerdaten_name02_idx VISIBLE; ALTER INDEX t_einwohnerdaten_name02_idx INVISIBLE;
Der Parameter optimizer_use_invisible_indexes aktiviert bzw. deaktiviert sowohl auf System- als auch auf Session-Ebene die Nutzung solcher Indizes. So ist es möglich, die Verwendung eines nicht sichtbaren Index nur für die eigene Session zu aktivieren. Die Änderung des Parameters für die eigene Session erfolgt mit dem Befehl: ALTER SESSION SET optimizer_use_invisible_indexes = TRUE;
Die Änderung soll systemweit greifen: ALTER SYSTEM SET optimizer_use_invisible_indexes = TRUE;
231
3 Verwaltung von Datenbankobjekten Praxistipp Nicht sichtbare Indizes lassen sich wie andere Indizes explizit mit einem Optimizer Hint ansprechen. So können Sie einzelne Abfragen gezielt mittels Hint testen.
3.10.14 Logging Standardmäßig werden Änderungen an Indizes in den Redo Logs mitgeschrieben. Faktisch handelt es sich bei Indizes jedoch um redundante Informationen, die nicht zwingend über ein Restore und ein anschließendes Recovery über die Redo Logs hergestellt werden müssen: Die indizierten Werte sind in der Basistabelle gespeichert, ein Index lässt sich daher jederzeit neu aufbauen. Bei hoher Transaktionslast wie beispielsweise Ladevorgängen verursacht das Schreiben der Change-Vektoren in die Redo Logs unter Umständen einigen Overhead. Ist ein Index auf „nologging“ gesetzt, fällt dieser Overhead weg. Im Falle einer Wiederherstellung der Datenbank aus einem Backup und einem anschließenden Recovery über die Redo Logs bleibt die Indexdefinition zwar im Data Dictionary bestehen, der Index ist jedoch logisch korrupt. Ein Index Rebuild behebt diese logische Korruption. Je nach Größe der darunterliegenden Tabelle kann dies mehr oder weniger Zeit in Anspruch nehmen. Index Rebuilds sind zwar technisch gesehen unproblematisch, sie verlängern jedoch die Ausfallzeit im Falle einer Wiederherstellung. Hier sind die Vorteile des Performancegewinnes sowie der Verringerung des Log-Aufkommens gegenüber den Nachteilen einer im Fehlerfall längeren Downtime abzuwägen. Syntax: ALTER INDEX LOGGING|NOLOGGING;
Beispiel: ALTER INDEX t_einwohnerdaten_name02_idx NOLOGGING;
Der Log-Modus wird wie folgt (re-)aktiviert: ALTER INDEX t_einwohnerdaten_name02_idx LOGGING;
Die Umsetzung des Log-Modus kann im laufenden Betrieb erfolgen. Wurde der Index seit dem letzten Backup auf „nologging“ gesetzt, so ist bei einer Wiederherstellung in jedem Fall ein Rebuild erforderlich. Dies gilt auch dann, wenn der LogModus zwischenzeitlich wieder aktiviert wurde.
3.10.15 Parallelisierung Die Klausel parallel setzt die Default-Einstellung für die Anzahl paralleler Prozesse, sodass ein Index mit mehreren parallelen Prozessen gelesen wird. Syntax: CREATE INDEX ON (<spalten_liste>) [<speicher_parameter>] NOPARALLEL|PARALLEL ;
232
3.10 Indizes ALTER INDEX [<speicher_parameter>] NOPARALLEL|PARALLEL ;
Mit 1 <= n <= 65535
Beispiel: CREATE INDEX pk_t_mitarbeiter ON t_mitarbeiter (pers_nr) TABLESPACE USERS PARALLEL 4;
Die View dba_indexes zeigt den Standard-Parallelisierungsgrad eines Index: SELECT owner, table_name, degree FROM dba_indexes WHERE index_name = 'PK_T_MITARBEITER';
Praxistipp Generell lohnt eine Parallelisierung nur bei lang laufenden Abfragen mit einer hohen Anzahl an Blockzugriffen auf ein Objekt.
3.10.16 Umbenennen eines Index Der Befehl alter
index
benennt einen Index um:
ALTER INDEX RENAME TO ;
Beispiel: ALTER INDEX PK_T_MITARBEITER RENAME TO pk_mitarbeiterdaten_idx;
3.10.17 Monitoring der Index-Nutzung Sie möchten herausfinden, welche Indizes wirklich genutzt werden? Der Schalter monibefüllt die View v$object_usage mit Nutzungsdaten. Wird ein Index mit dem Flag monitoring während der Ausführung eines SQL-Statements verwendet, so zeigt die Spalte used der View v$object_usage den Wert „YES“.
toring usage
Das folgende Statement aktiviert das Monitoring für den Index idx:
pk_mitarbeiterdaten_
ALTER INDEX pk_mitarbeiterdaten_idx MONITORING USAGE;
Der Schalter nomonitoring
usage
stellt das Monitoring wieder ab:
ALTER INDEX pk_mitarbeiterdaten_idx NOMONITORING USAGE;
Wird das Monitoring für einen Index erneut aktiviert, so sind die alten Nutzungsinformationen des Index mit den neuen überschrieben. Die Nutzung eines gemonitorten Index können Sie mit dem folgenden Statement prüfen: SELECT index_name, table_name, used, start_monitoring, end_monitoring FROM v$object_usage;
233
3 Verwaltung von Datenbankobjekten Praxistipp Die View v$object_usage zeigt nur die Nutzung von Indizes, deren Besitzer der aktuell angemeldete Benutzer ist. Möchten Sie die Nutzung aller Indizes prüfen, ist ein Trick notwendig: Als priviligierter Benutzer mit DBA-Privilegien greifen Sie direkt auf die Base Tables des Data Dictionary zu. So können Sie die Index-Nutzung auch von Objekten monitoren, ohne Besitzer der jeweiligen Objekte zu sein: SELECT u.name , io.name , t.name , decode(bitand(i.flags, 65536), 0, 'NO', 'YES') , decode(bitand(ou.flags, 1), 0, 'NO', 'YES') , ou.start_monitoring , ou.end_monitoring FROM sys.user$ u, sys.obj$ io, sys.obj$ t, sys.ind$ WHERE i.obj# = ou.obj# AND io.obj# = ou.obj# AND t.obj# = i.bo# AND u.user# = io.owner#;
AS AS AS AS AS AS AS
OWNER INDEX_NAME TABLE_NAME MONITORING USED START_MONITORING END_MONITORING
i, sys.object_usage ou
Sie können sich selbstverständlich auch eine eigene View anlegen, in der Sie obiges Statement hinterlegen. Dies vereinfacht die Abfrage nochmals erheblich.
3.10.18 Wichtige Rechte rund um Indizes Privileg
Beschreibung
CREATE INDEX
Erstellen eines Tabellen-Index im eigenen Schema
ObjektPrivileg
Systemprivileg
X
CREATE ANY INDEX
Indizieren jeder Tabelle (datenbankweit)
X
ALTER ANY INDEX
Ändern jedes Index (datenbankweit)
X
DROP ANY INDEX
Löschen jedes Index (datenbankweit)
X
3.10.19 Informationen zu Indizes im Data Dictionary Die View dba_indexes zeigt genauere Angaben zu Indizes: SELECT * FROM dba_indexes;
Informationen zur Erstellungs- und Änderungszeit von Indizes finden Sie in der View dba_ objects: SELECT owner, object_name, object_type, created, last_ddl_time, status FROM dba_objects WHERE object_type = 'INDEX';
Die View dba_segments zeigt Informationen zu Index-Segmenten: SELECT owner, segment_name, segment_type FROM dba_segments WHERE owner = 'SCHMIDT';
Die View dba_extents liefert Informationen zu einzelnen Speicher-Extents eines Index.
234
3.11 Synonyme
3.11
Synonyme Ein Synonym ist ein Aliasname für ein Datenbankobjekt. Er ähnelt einem symbolischen Link in einem Dateisystem. Syntax: CREATE [PUBLIC] SYNONYM <synonym_name> FOR ;
Beispiel: CREATE SYNONYM mitarb FOR t_mitarbeiter;
Synonyme können auf Objekte anderer Schemata verweisen: CREATE SYNONYM mitarb FOR personal_daten.t_mitarbeiter;
Auch der Zugriff auf Objekte in Remote-Datenbanken ist über ein Synonym möglich. Dazu wird ein Verweis über einen Datenbank-Link für das Synonym hinterlegt: CREATE SYNONYM mitarb FOR personal_daten.t_mitarbeiter@DB_FRA;
Sie können anschließend in allen Statements das Synonym anstelle des originalen Objektnamens verwenden: SELECT * FROM mitarb WHERE nachname = 'SCHMIDT'; INSERT INTO mitarb (mitarbeiternr, nachname, gehalt) VALUES ( 920, 'Schmidt', 6280) UPDATE mitarb SET gehalt = gehalt * 1,10 WHERE abt_nr = 280;
3.11.1
Public Synonym
Ein Public Synonym steht für alle Benutzer der Datenbank zur Verfügung: CREATE PUBLIC SYNONYM mitarb FOR personal_daten.t_mitarbeiter;
Um ein Public Synonym erstellen zu können, benötigt der erstellende Benutzer das System-Privileg create public synonym. Beispiel: GRANT CREATE PUBLIC SYNONYM TO scott;
3.11.2 Wichtige Rechte rund um Synonyme Privileg
Beschreibung
CREATE SYNONYM
Erstellen eines Synonyms im eigenen Schema
ObjektPrivileg
Systemprivileg X
CREATE ANY SYNONYM
Erstellen von Synonymen in beliebigen Schemata
X
CREATE PUBLIC SYNONYM
Erstellen von öffentlich zugänglichen Synonymen
X
DROP ANY SYNONYM
Löschen von Synonymen in beliebigen Schemata
X
DROP PUBLIC SYNONYM
Löschen von öffentlich zugänglichen Synonymen
X
235
3 Verwaltung von Datenbankobjekten
3.11.3 Informationen zu Synonymen im Data Dictionary Die View dba_synonyms bietet allgemeine Informationen zu Synonymen: SELECT owner, synonym_name, table_owner, table_name, db_link FROM dba_synonyms;
Informationen zur Erstellungs- und Änderungszeit von Synonymen finden Sie in der View dba_objects: SELECT owner, object_name, object_type, created, last_ddl_time, status FROM dba_objects WHERE object_type = 'SYNONYM';
3.12
Datenbank-Links Ein Datenbank-Link ist ein Verweis auf eine andere Oracle-Datenbank. Er erlaubt den Zugriff auf eine Remote-Datenbank und die darin enthaltenen Objekte. Ein Datenbank-Link umfasst den Namen der Remote-Datenbank, einen Verbindungsdeskriptor zur Remote-Datenbank und eine Benutzername/Password-Kombination, die zur Authentifizierung der Verbindung zur Remote-Datenbank dient. Damit Links zwischen Datenbanken in einer verteilten Umgebung funktionieren, müssen die globalen Datenbanknamen eindeutig sein. Daher sollten Sie in solchen Umgebungen darauf achten, die Werte für die Initialisierungsparameter DB_NAME und DB_DOMAIN bzw. DB_UNIQUE_NAME korrekt zu setzen. CREATE [PUBLIC] DATABASE LINK CONNECT USING ;
Beispiel: CREATE DATABASE LINK FRA.DE.EU CONNECT TO CURRENT_USER USING 'FRA_DB'; Der obenstehende Datenbank-Link fra.de.eu
nutzt den Eintrag FRA_DB, der über Namensauflösung über die tnsnames.ora34 zur Verfügung steht. Zur Authentifizierung bei RemoteZugriffen wird der aktuelle Benutzer mit seinem Kennwort verwendet.
Soll nicht der aktuelle Benutzer, sondern stets ein spezieller Benutzer der Zieldatenbank zur Authentifizierung verwendet werden, so können Sie den Datenbank-Link explizit mit einer Kombination aus Benutzernamen und Kennwort belegen: CREATE DATABASE LINK FRA.DE.EU CONNECT TO a_schmidt IDENTIFIED BY ein_password USING 'FRA_DB';
Der Zugriff auf Objekte in Remote-Datenbanken erfolgt in der gleichen Weise wie auf lokale Objekte. Durch ein „@“ getrennt wird jedoch zusätzlich der Name des DatenbankLinks an den Objektnamen angehängt: SELECT * FROM [email protected];
34
236
Siehe auch Kapitel 7 „Oracle Net“.
3.12 Datenbank-Links Um den Zugriff auf Remote-Objekte zu vereinfachen, bietet es sich an, Synonyme zu erstellen: CREATE synonym t_mitarbeiter FOR [email protected]; SELECT * FROM t_mitarbeiter;
Wird ein Objekt in eine andere Remote-Datenbank oder in die lokale Datenbank verschoben, so kann der Synonymname gleich bleiben − nur die Definition ist anzupassen. Für den Benutzer ist der Remote-Zugriff somit transparent.
3.12.1 Public Database-Link Standardmäßig ist ein Datenbank-Link einem Schema zugeordnet. Ein Public-DatabaseLink dagegen steht für alle Benutzer der Datenbank zur Verfügung: CREATE PUBLIC DATABASE LINK FRA.DE.EU CONNECT TO SCOTT IDENTIFIED BY TIGER USING 'FRA_DB';
Um einen Public-Database-Link zu erstellen, benötigt der erstellende Benutzer das System-Privileg create public database link. Beispiel: GRANT CREATE PUBLIC DATABAES LINK TO scott;
3.12.2 Verbindungsdescriptor zur Remote-Datenbank Ist kein Alias für die Remote-Datenbank in der tnsnames.ora hinterlegt und ist er auch sonst nicht auflösbar, kann man auch die gesamte Beschreibung in die using-Klausel eintragen: CREATE DATABASE LINK FRA.DE.EU CONNECT TO SCOTT IDENTIFIED BY TIGER USING '(DESCRIPTION = (ADDRESS = (PROTOCOL= TCP) (Host=172.22.53.71)(Port= 1521)) (CONNECT_DATA = (SERVER = DEDICATED)(SERVICE_NAME = fra_db.world)))' ;
3.12.3 Rechte zu Datenbank-Links Privileg
Beschreibung
CREATE DATABASE LINK
Erstellen eines Datenbank Links im eigenen Schema
X
CREATE PUBLIC DATABASE LINK
Erstellen von öffentlich zugänglichen Datenbank Links
X
DROP DATABASE LINK
Löschen von Datenbank Links
X
ObjektPrivileg
Systemprivileg
237
3 Verwaltung von Datenbankobjekten
3.12.4 Informationen zu Datenbank-Links im Data Dictionary Die View dba_db_links liefert Informationen zu Datenbank-Links: SELECT owner, db_link, username, host, created FROM dba_db_links;
Informationen zur Erstellungs- und Änderungszeit von Datenbank-Links finden Sie in der View dba_objects: SELECT owner, object_name, object_type, created, last_ddl_time, status FROM dba_objects WHERE object_type = 'DATABASE LINK';
3.13
Sequenzen Eine Sequenz ist ein Nummerngenerator. Sequenzen werden meist zur Generierung eindeutiger Werte für Primärschlüssel verwendet. Syntax: CREATE SEQUENCE INCREMENT BY START WITH MAXVALUE | NOMAXVALUE MINVALUE | NOMINVALUE CYCLE | NOCYCLE CACHE | NOCACHE ORDER | NOORDER;
Beispiele: CREATE SEQUENCE kd_nr_seq; CREATE SEQUENCE pers_nr_seq START WITH 1000 MAXVALUE 9999 INCREMENT BY 1 NOCYCLE CACHE 50 NOORDER;
Die Klausel start with gibt den Initialwert der Sequenz an. Mit increment by wird die Schrittweite der Inkrementierung, mit minvalue und maxvalue der kleinste und der größte zu vergebende Wert festgelegt. Der Schalter cycle bzw. nocycle gibt an, ob bei Erreichen des Maximalwerts der Initialwert wieder verwendet werden darf (cycle) oder nicht (nocycle). Der Schalter order bzw. noorder legt fest, ob Sequenznummern zwingend in sortierter Reihenfolge zu vergeben sind. Da das Ziehen eines Wertes aus einer Sequenz etwas Overhead verursacht, bietet es sich an, nicht nur einen Wert, sondern gleich mehrere zu ziehen und diese zu cachen. Mit cache legt man die Anzahl gecachter Sequenzwerte fest. Wird die Datenbank-Instanz heruntergefahren, verfallen Sequenzwerte, die gezogen, aber nicht verwendet wurden. In Standardanwendungen stellt dies jedoch kein Problem dar: Im Regelfall wird über Sequenzen nur ein eindeutiger Schlüssel generiert, der nicht zwingend ohne Lücken fortlaufend sein muss. Beispielsweise bei Rechnungsnummern ist dies in Deutschland aufgrund gesetzlicher Vor-
238
3.14 PL/SQL-Programme schriften problematisch. In einem solchen Fall kann der Schalter Der Standardwert für Cache ist 20.
nocache
gesetzt werden.
3.13.1 Rechte zu Sequenzen Privileg
Beschreibung
CREATE SEQUENCE
Erstellen von Sequenzen im eigenen Schema
ALTER
Ändern einer bestehenden Sequenz
X
SELECT
Abfragen einer bestehenden Sequenz
X
Objekt- SystemPrivileg privileg X
CREATE ANY SEQUENCE
Erstellen von Sequenzen in beliebigen Schemata
X
ALTER ANY SEQUENCE
Ändern von Sequenzen in beliebigen Schemata
X
DROP ANY SEQUENCE
Löschen von Sequencen in beliebigen Schemata
X
SELECT ANY SEQUENCE
Abfragen von Sequenzen in beliebigen Schemata
X
3.13.2 Informationen zu Sequenzen im Data Dictionary Die View quenzen :
dba_objects
zeigt Informationen zur Erstellungs- und Änderungszeit von Se-
SELECT owner, object_name, object_type, created, last_ddl_time, status FROM dba_objects WHERE object_type = 'SEQUNCE';
Genauere Angaben zu Sequenzen sind der View dba_sequences zu entnehmen: SELECT sequence_owner, sequence_name, min_value, max_value increment_ny, cycle_flag, order_flag, cache_size last_number FROM dba_sequences;
3.14
PL/SQL-Programme Oracle PL/SQL ist eine Spracherweiterung zu SQL und bietet prozedurale Erweiterungen wie Bedingungen und Schleifen gemeinsam mit allen Leistungsmerkmalen von SQL.
3.14.1 Stored Procedures / Functions Oracle-Datenbanken bieten die Möglichkeit, PL/SQL-Programme in der Datenbank zu speichern. So können in PL/SQL codierte Programme als Prozeduren und Funktionen hinterlegt und zur Bearbeitung von Datenbankoperationen genutzt werden.
3.14.2 Packages Packages sind Gruppierungen von Stored Procedures und Functions. Im Grunde handelt es sich um Bibliotheken, die mit Package-Variablen und Cursorn, benutzerdefinierten Typen
239
3 Verwaltung von Datenbankobjekten und vielem mehr versehen sind. Packages bestehen aus zwei Teilen: Einer Package Spezifikation und einem Package Body. Die Spezifikation beschreibt die Schnittstellen des Paketes. Im Body befindet sich die eigentliche Implementierung.
3.14.3 Trigger Ein Trigger ist ein PL/SQL-Programm, das durch ein Ereignis automatisch aufgerufen (angetriggert) wird. Auslösende Ereignisse können DML-Anweisungen auf eine Tabelle oder Views, DDL-Anweisungen und Datenbank-Events wie ein Startup oder Shutdown sein. Das auslösende Ereignis wird mit der Trigger-Implementierung definiert. Trigger eignen sich beispielsweise für folgende Aktionen:
Implementierung von komplexen Integritätsregeln, die sich mit den vordefinierten Oracle Constraint-Typen nicht realisieren lassen
Automatisiertes Befüllen von Historientabellen Simulierung von Fremdschlüsselbeziehungen in verteilten Umgebungen zwischen Tabellen, die nicht in der gleichen Datenbank liegen
3.14.4 Wichtige Rechte rund um PL/SQL-Programme Privileg
Beschreibung
Objekt- System Privileg privileg
CREATE PROCEDURE
Erstellen von PL/SQL-Programmen
X
CREATE ANY PROCEDURE
Erstellen von PL/SQL-Programmen in beliebigen Schemata
X
ALTER ANY PROCEDURE
Ändern von PL/SQL-Programmen in beliebigen Schemata
X
DEBUG ANY PROCEDURE
Debuggen von PL/SQL-Programmen in beliebigen Schemata
X
DROP ANY PROCEDURE
Löschen von PL/SQL-Programmen in beliebigen Schemata
X
EXECUTE
Ausführen eines PL/SQL-Programmes
EXECUTE ANY PROCEDURE
Ausführen jedes PL/SQL-Programmes
X X
3.14.5 Informationen zu PL/SQL-Programmen im Data Dictionary Die View dba_source zeigt Informationen rund um PL/SQL-Programme, darunter auch den Prozedur-Text: SELECT FROM WHERE AND ORDER BY
240
name, type, line, text dba_source owner = 'SCOTT' name = 'EINE_PROZEDUR' name, type, line;
3.15 Resümee Objekt-Informationen wie den Status, den Zeitpunkt der Erstellung und der letzten Änderung finden Sie in der View dba_objects: SELECT FROM WHERE AND
3.15
owner, object_type, object_name, created, last_ddl_time, status dba_objects owner = 'SYS' object_type IN ( 'FUNCTION', 'PROCEDURE', 'PACKAGE', 'PACKAGE BODY');
Resümee In diesem Kapitel haben wir Ihnen wichtige Datenbankobjekte wie Tabellen und Indizes, Views, Seqenzen, Datenbank-Links und PL/SQL-Programme und deren Administrationsbefehle vorgestellt. Im nächsten Kapitel gehen wir auf die Verwaltung von Speicherplatz ein.
241
3 Verwaltung von Datenbankobjekten
i
242
4 4 Speicherplatzverwaltung In diesem Kapitel zeigen wir Ihnen:
wie die grundlegenden Speicherstrukturen einer Oracle Datenbank aufgebaut sind; wie damit die unterschiedlichen Segmenttypen verwaltet werden; die Vor- und Nachteile der verschiedenen Verwaltungsmethoden; welche Reorganisationsmethoden Oracle zur Verfügung stellt. In einer Oracle-Datenbank sind Objekte, die Daten beinhalten (z.B. Tabellen und Indizes), nicht direkt in Files auf Betriebssystemebene gespeichert, sondern logischen Strukturen zugeordnet, die ihrerseits in physischen Strukturen abgelegt sind. Ziel dieser Architektur ist die klare Trennung des logischen Designs von der physischen Implementierung. Abbildung 4.1 zeigt eine Übersicht der Speicherstrukturen und deren Beziehung zueinander. logische Struktur Datenbank
Objekt
Tablespace
Segment
File
Extent
Block physische Struktur
Abbildung 4.1 Übersicht der Datenbank-Speicherstrukturen
243
4 Speicherplatzverwaltung Eine Datenbank besteht aus mehreren Tablespaces. Datenbank und Tablespaces sind lediglich logische Strukturen, die Objekte bzw. Segmente beinhalten. Man kann sie auch als eine Art Container betrachten. Aus Sicht der Speicherung unterscheidet man vier Objekttypen:
Objekte, die keine Daten und demzufolge auch keine Segmente beinhalten. Eine View ist beispielsweise eine logische Struktur, die nur im Data Dictionary definiert ist
Objekte, die aus einem einzigen Segment bestehen, z.B. eine nichtpartitionierte HeapTabelle
Objekte, die aus mehreren Segmenten bestehen. Eine partitionierte Tabelle hat z.B. ein Segmente pro Partition
Objekte, die ein Segment mit einem anderen Objekt teilen, z.B. Cluster-Tabellen Jeder Tablespace besteht aus einem oder mehreren Files, die aus einer bestimmten Anzahl Blöcke bestehen. Blöcke sind die kleinsten Strukturen, die die Datenbank speichertechnisch verwaltet. Über mehrere Files pro Tablespace verhindert man Einschränkungen, die durch die Database-Engine, das Betriebssystem oder die Hardware bezüglich der maximalen Filegröße entstehen können. Jedes File ist in Einheiten von zusammenhängenden Blöcken, den sogenannten „Extents“, unterteilt. Jedes Extent ist genau einem einzigen Segment zugeordnet. In den folgenden Abschnitten beschreiben wir die Möglichkeiten der DatenbankfileSpeicherung und wie man die erwähnten logischen und physischen Speicherstrukturen verwaltet.
4.1
Datenbank-Speicheroptionen Oracle unterstützt die unterschiedlichsten Speicherarchitekturen. Im einfachsten Fall werden die Disks direkt an den Datenbankserver angeschlossen. Man spricht dann von Direct Attached Storage (DAS). Weitaus häufiger wird auf die Disks in den heutigen Rechenzentren jedoch über ein Netzwerk zugegriffen. Dabei kommen hauptsächlich zwei Architekturen zum Einsatz: Storage Area Networks (SAN) und Network Attached Storage (NAS). Ein SAN verfügt über einen Management Layer und über ein spezielles Netzwerk, das die physische Verbindung zu den Disks sicherstellt. Die NAS-Architektur verwendet spezielle Fileserver, die für Speicherlösungen über ein lokales Netzwerk (LAN) geeignet sind. Die DAS- und SAN-Architekturen erlauben Block-I/O-Zugriff, während NAS-Server den Zugriff über File-I/O ermöglichen. Oracle nutzt für die Verwaltung der Datenbankfiles die betriebssystemseitigen Möglichkeiten. Dies hat aus Sicht der Datenbankadministration den Vorteil, dass die eingesetzte Speicherarchitektur die Fileverwaltung auf Datenbankebene nicht beeinflusst. Aus diesem Grund gehen wir an dieser Stelle nicht tiefer auf die erwähnten Architekturen ein und konzentrieren uns auf die Anforderungen, die ein Speichersubsystem aus Datenbanksicht erfüllen muss. Wir betrachten insbesondere, wie diese Anforderungen mit den drei grundlegenden Methoden erfüllt werden, die Oracle für die Speicherung von Datenbankfiles
244
4.1 Datenbank-Speicheroptionen verwendet: Filesysteme, Raw-Devices und Automatic Storage Management (ASM). Abgerundet wird dieses Kapitel mit Empfehlungen für die Auswahl von Datenbank-Speichersystemen.
4.1.1
Eigenschaften eines Speichersystems
Ein zuverlässiges Speichersystem ist für die dauerhafte Speicherung von Datenbankfiles unabdingbar. Die Hauptanforderungen an ein Speichersystem sind:
Verwaltung: Einfache und flexible Verwaltung der Disks Verfügbarkeit: Schutz gegen Hard- und Softwarefehler Performance: Erforderlichen Durchsatz und Anzahl I/O-Operationen pro Sekunde Zugriff: Gemeinsamer Zugriff auf die gleichen Disks von mehreren Servern aus in einer Clusterumgebung Bestimmte Anforderungen widersprechen einander jedoch. So existiert beispielsweise oft ein Konflikt zwischen einfacher, flexibler Verwaltung und hoher Performance. Im Falle des gleichzeitigen Zugriffs ist die Anforderung bei bestimmten Systemen gar nicht relevant. Es ist deshalb für die Wahl eines Speichersystems entscheidend, die Features entsprechend zu gewichten. 4.1.1.1 Verwaltung Operationen wie das Hinzufügen, Entfernen oder Ersetzen einer Disk sollten einfach und unterbrechungsfrei ohne Stoppen der Datenbankinstanz möglich sein, im Idealfall sogar ohne Auswirkungen auf die Datenbankinstanz – auch wenn auf den betroffenen Disks bereits Teile der Datenbank gespeichert sind. Wenn eine solche Operation durchgeführt wird, ist es zudem essenziell, dass die bereits gespeicherten Daten bei Bedarf automatisch neu verteilt werden. Solche Funktionen können nur dann zur Verfügung stehen, wenn eine Virtualisierungsschicht, beispielsweise ein Logical Volume Manager (LVM), zwischen Datenbankinstanz und physischen Disks zum Einsatz kommt. Wenn solche Features nicht unterstützt sind, sind die betroffenen Tablespaces manuell offline zu nehmen und/oder die Daten manuell zu verschieben. Ein Speichersystem sollte Operationen wie Datenbankfiles verschieben oder kopieren ebenfalls unterstützen. Diese Operationen erfordern jedoch ein Wartungsfenster, weil die betroffenen Tablespaces offline, oder in den Backupmodus genommen werden müssen – ansonsten ist die Konsistenz der Datenbankfiles nicht mehr gewährleistet. Weil Oracle das Vergrößern und Verkleinern (Resize) von Datenbankfiles unterstützt, sollte auch das Speichersystem dazu in der Lage sein. 4.1.1.2 Verfügbarkeit Der Schutz gegenüber Hard- und Softwarefehlern sowie gegenüber menschlichen Fehlern ist für Datenbanken von höchster Bedeutung: den Verlust einer abgeschlossenen Trans-
245
4 Speicherplatzverwaltung aktion gilt es unter allen Umständen zu verhindern. Einerseits verfügt Oracle über diverse Features, die – sofern korrekt angewendet – sicherstellen, dass keine abgeschlossene Transaktion verloren geht. Der Einsatz dieser Möglichkeiten liegt meistens beim Applikationsverantwortlichen, wobei es vielfach aus Kostengründen nicht möglich ist, das System gegen alle möglichen Fehler zu schützen. Andererseits verfügen die Speichersubsysteme über bewährte Ausfallschutzoptionen. Die bekannteste Methode, um Daten gegen Hardware-Ausfall zu schützen, ist das Duplizieren von Hardware-Komponenten wie Disks und Interfaces. Üblich ist beispielsweise die Spiegelung der Daten auf zwei unabhängige Disks, auch bekannt unter dem Begriff „RAID 1“. Aus Performance-Gründen empfehlen wir, solche Spiegelungen auf Hardware-Ebene umzusetzen. In einer DAS-Umgebung sind dazu Controller erforderlich, welche die Spiegelung unterstützen. Spiegelung wird heutzutage von jedem SAN oder NAS unterstützt. Trotz Spiegelung auf Hardware-Ebene macht die zusätzliche Spiegelung auf SoftwareEbene, beispielsweise für die Control-Files, die Redolog-Files und die archivierten LogFiles Sinn (siehe Kapitel 2, „Architektur und Administration“). Die meisten Datenbanken nutzen die Möglichkeiten der Spiegelung und es gibt keinen Grund, auf diese zu verzichten. Weitere Möglichkeiten der Spiegelung stellen ASM oder ein LVM zur Verfügung. Eine Problematik der Hardware-Spiegelung ist der doppelte Platzbedarf. Devices, die Datenredundanz auf Basis von Parity-Information (z.B. RAID 5 und RAID 6) zur Verfügung stellen, verringern den Overhead in Bezug auf den Diskplatz stark. Anstelle der vollständigen Replizierung der Daten speichern diese Technologien lediglich die Parity-Information, die für die Rekonstruktion von fehlenden Daten notwendig ist. Der Nachteil dieser Methode liegt in einer allgemein schlechteren Schreib-Performance. Wir empfehlen daher deren Einsatz für Oracle-Datenbanken nicht. Praxistipp Für die optimale Performance sollte man parity-basierte Datenredundanz-Technologien wie RAID 5 und RAID 6 nicht einsetzen.
4.1.1.3 Performance Für die optimale Performance ist die Wahl der Hardware von höchster Bedeutung. Es ist deshalb sehr wichtig, diesen Aspekt bei den Auswahlkriterien zu berücksichtigen. Praxistipp Obwohl die Kapazität in Bits und Bytes ein Schlüsselkriterium für die Wahl eines Speichersystems ist, sind die erforderlichen I/O-Operationen pro Sekunde (IOPS) und deren Größe nicht weniger wichtig. Im Gegenteil: Ein Speichersystem sollte nicht ausschließlich aufgrund seiner Kapazität ausgewählt werden.
Dazu ein Beispiel: Für eine OLTP-Datenbank von 1,4 TB Größe sind die notwendigen Disks (Typ und Anzahl) zu evaluieren, damit eine Spitzenlast von 1000 IOPS à 8 KB be-
246
4.1 Datenbank-Speicheroptionen wältigt werden kann. Die Daten sollten zudem gespiegelt sein und es stehen zwei Disktypen zu Auswahl:
High Performance SAS-Disks mit insgesamt 600 GB Kapazität und einem Durchsatz von 175 IOPS à 8 KB
High Capacity SATA-Disks mit insgesamt 2 TB Kapazität und einem Durchsatz von 75 IOPS à 8 KB Wenn wir nur die Kapazität in Betracht ziehen, sind die Anforderungen mit 2 SATA-Disks (2*1.4/2.0) oder 6 SAS-Disks (2*1.4/0.6) zu erfüllen. Wenn wir jedoch die IOPS berücksichtigen, müssen mehr Disks eingesetzt werden. Um 1000 IOPS zu erreichen, sind mindestens 28 SATA-Disks (2*1000/75), oder 12 SAS-Disks (2*1000/175) erforderlich. Diese Betrachtung zeigt deutlich auf, dass bei der Auswahl des Speichermediums nicht nur die Kapazität, sondern auch die Performance-Anforderungen wichtig sind. Die Auswahl des richtigen Disktyps und der richtigen Anzahl Disks ist schon einmal ein guter Anfang. Aber Vorsicht: Die erforderliche Spitzenlast ist nur dann gewährleistet, wenn die Disks korrekt und in geeigneter Art und Weise mit dem Server verbunden sind. In einer DAS-Umgebung müssen genügend Controller verfügbar sein und in einer SAN/NAS-Umgebung muss die Netzwerkinfrastruktur (HBA1, Netzwerkkarten und Switches) adäquat dimensioniert sein. Ein wichtiger Aspekt für die optimale Nutzung der verfügbaren Hardware ist die gleichmäßige Verteilung der Last über alle Komponenten. Praxistipp Die manuelle Verteilung der Speicher-Operationen, beispielsweise durch die Zuordnung von einzelnen Disks zu spezifische Tablespaces, ist in der Regel wenig sinnvoll. Für die Maximierung der Performance empfehlen wir Striping (RAID 0) zu verwenden und die automatische Verteilung der Speicher-Operationen über die verfügbaren Komponenten dem Speicher-Subsystem zu überlassen. Die einzige Situation in der eine manuelle Verteilung in Betracht kommt, besteht dann, wenn Disks mit unterschiedlicher Performance zur Verfügung stehen. Es ist beispielsweise sinnvoll, die schnellsten Disks für die Redolog-Files und für häufig benutzte Datenfiles einzusetzen, während die Disks mit der größten Kapazität mehr für sporadisch genutzte Daten zum Einsatz kommen.
Für die optimale Performance empfehlen wir, Striping auf Hardware-Ebene zu implementieren. In einer DAS-Umgebung muss dazu ein Controller verwendet werden, der Striping unterstützt. Striping ist eine Funktionalität, die heutzutage von jedem SAN oder NAS unterstützt wird. Wenn sowohl hohe Verfügbarkeit als auch hohe Performance erforderlich sind, dann sollte man Spiegelung und Striping kombinieren (RAID 1+0 oder RAID 10). Das heißt, die Disks werden paarweise gespiegelt und das Striping erfolgt über die beiden Disks. Vorsicht ist im umgekehrten Fall geboten. Erfolgt die Spiegelung über gestripte Disks (RAID 0+1), verliert man den Vorteil der höheren Verfügbarkeit. 1
Host Bus Adapter (HBA): Mediator, vermittelt zwischen dem SAN und dem Datenbankserver
247
4 Speicherplatzverwaltung Der höchstmögliche Nutzen der verfügbaren Hardware hängt auch von der eingesetzten Software ab. Auf Software-Ebene sind daher zwei Dinge zu beachten: Erstens sollte das Betriebssystem I/O-Operationen bis zu einer Größe von mindestens 1 MB unterstützen. Zweitens sollte asynchrones I/O2 nicht nur vom Betriebssystem unterstützt werden, sondern auch auf Datenbankebene über den Parameter disk_asynch_io eingeschaltet sein (Defaultwert ist TRUE). Der Parameter ist eine Art Hauptschalter, über den asynchrone I/OOperationen für Datenbankfiles auf beliebigen Speichersystemen ein- oder ausgeschaltet werden. 4.1.1.4 Zugriff In einer Single-Instanz-Umgebung ist es normalerweise nicht notwendig, den gleichzeitigen Zugriff auf das Speichersubsystem von mehreren Servern aus zu ermöglichen. Die einzige Ausnahme besteht in einer Failovercluster-Umgebung. Doch selbst in diesem Fall ist es besser, die erforderlichen Disks (beziehungsweise Devices) exklusiv auf jenem Clusterknoten zu mounten, auf dem die Instanz aktiv ist. Im Gegensatz dazu müssen in einer Real-Application-Cluster-Umgebung die Datenbankfiles von allen Instanzen aus simultan zugreifbar sein – daran führt kein Weg vorbei.
4.1.2
Filesysteme
Datenbankfiles sind am häufigsten auf Filesystemen gespeichert. Der Grund dafür ist einfach: Filesysteme sind weit verbreitet und der Umgang damit entsprechend vertraut. Die Oracle Binaries werden auf einem Filesystem installiert und auch die Datenbankfiles lassen sich ohne zusätzliche Konfiguration darauf speichern. Jedes Betriebssystem unterstützt diverse Filesysteme, aber nicht jedes Filesystem ist von Oracle unterstützt – beispielsweise ist der Support für Linux von der Distribution und der Version abhängig. Details dazu stehen in den folgenden My Oracle Support Notes :
Linux: Supported and Recommended File Systems on Linux (236826.1) SuSE/Novell: Linux, Filesystem & I/O Type Supportability (414673.1) Enterprise Linux: Linux, Filesystem & I/O Type Supportability (279069.1) AIX: Direct I/O or concurrent I/O on AIX 5L (272520.1) Auf Plattformen wie Linux, Solaris, AIX und HP-UX unterstützt Oracle auch Filesysteme von Drittanbietern, wie zum Beispiel die Veritas Storage Foundation von Symantec. In den folgenden Abschnitten beschreiben wir die Eigenschaften von Filesystemen bezüglich Verwaltung, Verfügbarkeit, Performance und Zugriff.
2
248
Asynchrones I/O, auch „non-blocking I/O“ genannt, ist eine sehr effiziente Form von Input/OutputVerarbeitung, die parallele I/O-Verarbeitung ermöglicht. So muss beispielsweise ein Schreibprozess nicht auf die Schreibbestätigung warten, um weiterzuarbeiten. Asynchrones I/O muss vom Betriebssystem unterstützt sein.
4.1 Datenbank-Speicheroptionen 4.1.2.1 Verwaltung Operationen wie das Hinzufügen, Entfernen oder Ersetzen einer Disk (inklusive Wiederverteilung der Daten) kann nur dann unterbrechungsfrei (ohne Stoppen der Datenbankinstanz) erfolgen, wenn ein Logical Volume Manager oder ein Netzwerk-Device, das solche Features unterstützt, eingesetzt sind. Operationen wie Verschieben oder Kopieren von Datenbankfiles können – nach vorgängiger Benachrichtigung der Datenbankinstanz – mit den allgemein bekannten Betriebssystembefehlen (wie cp oder mv unter Linux/UNIX) erfolgen. Das folgende Beispiel, ausgeführt auf einem Linux-Server, zeigt wie ein Datenbankfile eines Tablespaces von einem Verzeichnis in ein anderes verschoben wird: SQL> SELECT file_name 2 FROM dba_data_files 3 WHERE tablespace_name = 'TEST'; FILE_NAME ------------------------------------/u00/oradata/ora11g/test01ora11g.dbf SQL> ALTER TABLESPACE test OFFLINE; SQL> !mv /u00/oradata/ora11g/test01ora11g.dbf > /u01/oradata/ora11g/test01ora11g.dbf SQL> ALTER DATABASE 2 RENAME FILE '/u01/oradata/ora11g/test01ora11g.dbf' 3 TO '/u00/oradata/ora11g/test01ora11g.dbf'; SQL> ALTER TABLESPACE test ONLINE;
Auch das Vergrößern (respektive Verkleinern) eines Datenbankfiles wird von Oracle unterstützt. Die einzige Voraussetzung, welche natürlicherweise erfüllt sein muss, ist genügend freier Platz im entsprechenden Filesystem. In Abschnitt 4.2.2 und 4.2.3 zeigen wir je ein Beispiel für automatisches und manuelles Resizing. 4.1.2.2 Verfügbarkeit Mit Ausnahme der Control-Files, der Redolog-Files und der archivierten Log-Files (die auch softwaremäßig gespiegelt werden können) kann die Verfügbarkeit der Files auf dem Filesystem nur durch den Einsatz von Spiegelung auf Hardware-Ebene, oder mithilfe eines Logical Volume Managers gewährleistet werden. 4.1.2.3 Performance Die Datenbankblockgröße sollte gleich oder ein Vielfaches der Systemblockgröße sein. Ist sie kleiner, ist die Performance nicht optimal. Das heißt, es muss ein ganzer Filesystemblock von der Platte gelesen werden, wenn eine I/O-Operation durchgeführt wird. Standardmäßig sind die I/O-Operationen von Oracle auf den meisten Filesystemen gepuffert. Das heißt, die Daten sind in einem betriebssystemseitigen Buffercache gespeichert, nachdem sie gelesen bzw. bevor sie geschrieben werden. Weil Oracle jedoch einen eigenen
249
4 Speicherplatzverwaltung Buffercache besitzt, führt eine solche Doppelpufferung im Allgemeinen zu unnötigem Overhead. Praxistipp Wir empfehlen, die Pufferung von I/O-Operationen zu verhindern. Dazu unterstützen die Filesysteme Direct-I/O, womit – wie der Name impliziert – der betriebssystemseitige Buffercache umgangen wird.
Der Parameter filesystemio_options bestimmt, wie die I/O-Operationen auf Datenbankfiles gegenüber dem Filesystem ausgeführt werden. Folgende Werte stehen zur Verfügung:
none: Deaktiviert direkte und asynchrone I/O-Operationen directIO: Aktiviert nur direkte I/O-Operationen asynch: Aktiviert nur asynchrone I/O-Operationen setall: Aktiviert direkte und asynchrone I/O-Operationen Der Parameter filesystemio_options ist für die Aktivierung von asynchronen I/OOperationen nicht möglich, wenn der Parameter disk_asynch_io auf FALSE gesetzt ist. Der Wechsel einer Datenbankinstanz von gepufferten I/O-Operationen auf Direct-I/O kann auch zu einer schlechteren Performance führen, etwa wenn viele I/O-Operationen aus dem betriebssystemseitigen Buffercache bedient werden. Ein größerer Datenbank-Buffercache verhindert diese Probleme. Grundsätzlich muss die Datenbank gleich viel Memory zur Verfügung haben, wie das Betriebssystem vor der Umstellung für den Buffercache. 4.1.2.4 Zugriff In einer Real-Application-Cluster-Konfiguration sind für die Speicherung von Datenbankfiles nur von Oracle zertifizierte Cluster-Filesysteme (CFS) möglich. Eine Übersicht, welche Plattformen welche CFS unterstützen, ist auf My Oracle Support im Artikel 183408.1, „Raw Devices and Cluster Filesystems With Real Application Clusters“ dokumentiert. Es ist dabei zu beachten, dass gewisse CFS nur die Speicherung der Oracle Binaries unterstützen, nicht aber der Datenbankfiles.
4.1.3
Raw-Devices
Werden Raw-Devices eingesetzt, muss für jedes Datenbankfile ein entsprechendes RawDevice auf Betriebssystemebene vorhanden sein. Aus diesem Grunde ist der Einsatz von Raw-Devices ohne Virtualisierungsschicht, welche die darunterliegenden physischen Disks virtualisiert, schwer denkbar. Abbildung 4.2 zeigt ein Beispiel über die Anwendung eines Logical Volume Managers. Jedes der vier physischen Volumes (PV) basiert auf zwei Disks, die hardwaremäßig gespiegelt sind (hier insgesamt 8 physische Disks). Jeder Tablespace besteht aus einem Datenfile, das auf einem Logical Volume (LV) basiert. Dieses
250
4.1 Datenbank-Speicheroptionen SYSTEM
SYSAUX
TEMP
UNDO
DATA
LV
LV
LV
LV
LV
Volume Group
PV
PV
PV
PV
Mirrored Disk
Mirrored Disk
Mirrored Disk
Mirrored Disk
Abbildung 4.2 Beispiel einer Raw-DeviceKonfiguration, die hardwaremäßige Spiegelung und Striping auf Software-Ebene nutzt
wiederum nutzt die Vorteile aller physischen Volumes, indem die Daten über diese gestriped werden. Mit einer solchen Konfiguration werden die physischen Disks nicht direkt von der Datenbankinstanz angesprochen, was Änderungen auf der physischen Ebene ermöglicht, ohne das Setup auf Datenbankebene zu ändern. In den folgenden Abschnitten beschreiben wir die Eigenschaften von Raw-Devices bezüglich Verwaltung, Verfügbarkeit, Performance und Zugriff. 4.1.3.1 Verwaltung Operationen wie Hinzufügen, Entfernen oder Ersetzen einer Disk (inklusive Wiederverteilung der Daten) können nur dann unterbrechungsfrei (ohne Stoppen der Datenbankinstanz) erfolgen, wenn ein Logical Volume Manager, oder ein Netzwerkdevice, das solche Features unterstützt, eingesetzt werden. Operationen wie Verschieben oder Kopieren von Datenbankfiles können – nach vorgängiger Benachrichtigung der Datenbankinstanz – mit Betriebssystembefehlen erfolgen. Im Gegensatz zu den Filesystemen sind die allgemein bekannten Befehle bei Raw-Devices nicht möglich. Für diese einfachen Operationen mit Raw-Devices ist spezielles Wissen notwendig. Im folgenden Beispiel, ausgeführt auf einem Linux-Server, zeigen wir, wie ein Datenbankfile von einem Device auf ein anderes verschoben wird. Für die Evaluation der Filegröße verwenden wir den dbfsize-Befehl (dbfsize ist Teil der Oracle Binaries) und für das Kopieren des Datenfiles kommt der dd-Befehl zum Einsatz (dd wird vom Betriebssystem zur Verfügung gestellt). SQL> SELECT file_name 2 FROM dba_data_files 3 WHERE tablespace_name = 'TEST'; FILE_NAME ----------------------/dev/mapper/vg01-test1 SQL> ALTER TABLESPACE test OFFLINE;
251
4 Speicherplatzverwaltung
SQL> !dbfsize /dev/mapper/vg01-test1 Database file: /dev/mapper/vg01-test1 Database file type: raw device Database file size: 12800 8192 byte blocks SQL> !dd if=/dev/mapper/vg01-test1 > of=/dev/mapper/vg01-test2 > count=12800 bs=8192 12800+0 records in 12800+0 records out SQL> ALTER DATABASE 2 RENAME FILE '/dev/mapper/vg01-test1' 3 TO '/dev/mapper/vg01-test2'; SQL> ALTER TABLESPACE test ONLINE;
Bei der Planung einer solchen Operation ist zu berücksichtigen, dass bestimmte Betriebssysteme den ersten Teil eines Raw-Devices für die Verwaltung von Meta-Informationen reservieren. In diesem Fall ist ein Teil des Files beim Kopieren des Raw-Device-Inhalts zu überspringen. Diese Problematik lässt sich durch den Einsatz von RMAN (siehe Kapitel 13 „Backup und Recovery“) einfach umgehen. Der folgende RMAN-Befehl führt die gleiche Operation aus, wie im vorhergehenden Beispiel. RUN { ALLOCATE CHANNEL c TYPE disk; SQL 'ALTER TABLESPACE test OFFLINE'; BACKUP AS COPY DATAFILE '/dev/mapper/vg01-test1' FORMAT '/dev/mapper/vg01-test2'; SWITCH DATAFILE '/dev/mapper/vg01-test1' TO DATAFILECOPY '/dev/mapper/vg01-test2'; SQL 'ALTER TABLESPACE test ONLINE'; RELEASE CHANNEL c; }
Sind die Verfügbarkeitsanforderungen erhöht, bietet RMAN auch die Möglichkeit, die Kopie des Datenfiles online zu machen: RUN { ALLOCATE CHANNEL c TYPE disk; BACKUP AS COPY DATAFILE '/dev/mapper/vg01-test1' FORMAT '/dev/mapper/vg01-test2'; SQL 'ALTER TABLESPACE test OFFLINE'; SWITCH DATAFILE '/dev/mapper/vg01-test1' TO DATAFILECOPY '/dev/mapper/vg01-test2'; RECOVER DATAFILE '/dev/mapper/vg01-test1'; SQL 'ALTER TABLESPACE test ONLINE'; RELEASE CHANNEL c; }
Auch wenn das Vergrößern von Datenbankfiles auf Raw-Devices unterstützt wird, verzichtet man normalerweise darauf. Wer mehr Platz benötigt, weist üblicherweise dem neuen Datenfile ein neues Raw-Device zu. 4.1.3.2 Verfügbarkeit Mit Ausnahme der Control-Files, der Redolog-Files und der archivierten Log-Files (welche auch softwaremäßig gespiegelt werden können) kann die Verfügbarkeit der Files auf
252
4.1 Datenbank-Speicheroptionen Raw-Devices nur durch den Einsatz von Spiegelung auf Hardware-Ebene, oder mit Hilfe eines Logical Volume Managers gewährleistet werden. 4.1.3.3 Performance Raw-Devices benötigen keine spezielle Konfiguration für die optimale Performance. I/OOperationen auf Datenfiles, die auf Raw-Devices liegen, können nicht vom betriebssystemseitigen Buffercache profitieren. Dies kann zu einer verminderten Performance führen, wenn Datenfiles von einem Filesystem auf ein Raw-Device verschoben werden, das vorher stark vom betriebssystemseitigen Buffercache profitiert hat. Um dies zu verhindern, sollte der Datenbank Buffercache entsprechend groß sein. Grundsätzlich muss die Datenbank gleich viel Memory besitzen, wie das Betriebssystem vor der Umstellung für den Buffercache verwendet hat. 4.1.3.4 Zugriff In einer Real-Application-Cluster-Konfiguration stellt die Datenbankinstanz sicher, dass die Datenbankfiles auf konsistente und synchrone Art und Weise modifiziert sind. Daher kann eine Datenbank auf Raw-Devices gleichzeitig von mehreren Instanzen geöffnet werden. Dies ist auch der Grund dafür, wieso in der Vergangenheit fast alle geclusterten Datenbanken auf Raw-Devices verwaltet wurden.
4.1.4
Automatic Storage Management
Automatic Storage Management (ASM) ist ein Datenbank-Feature, das seit 10g eingeführt ist. ASM soll ohne zusätzliche Lizenzkosten die vier zentralen Anforderungen (Verwaltung, Verfügbarkeit, Performance und Zugriff) auf einfache, flexible und kostengünstige Art und Weise erfüllen. Anstelle einer vollständigen Beschreibung aller ASM-Features, konzentrieren wir uns in diesem Abschnitt auf die Möglichkeiten, um die erwähnten Anforderungen zu erfüllen. Die Installation und die Konfiguration von ASM ist in Kapitel 5 „Automatic Storage Management“ beschrieben. 4.1.4.1 Verwaltung Operationen wie das Hinzufügen, Entfernen oder Ersetzen einer Disk (inklusive Wiederverteilung der Daten) kann online erfolgen, d.h. ohne die Datenbankinstanz zu stoppen, welche die modifizierte Diskgruppe verwendet. Die Wiederverteilung der Daten, das Rebalancing, erfolgt automatisch mit jeder Modifikation einer Diskgruppe. Es empfiehlt sich daher beim Ersetzen einer Disk die beiden Operationen (ADD und DROP) in einem einzigen ALTER DISKGROUP-Statement zusammenzufassen. Auf diese Weise erfolgt nur eine Rebalance-Operation. Das folgende Beispiel illustriert dieses Vorgehen: ALTER DISKGROUP data DROP DISK disk05 ADD FAILGROUP fg02 DISK '/dev/mapper/vg01-asmdisk09' NAME disk09 REBALANCE POWER 1
253
4 Speicherplatzverwaltung Mit der Klausel REBALANCE POWER kontrolliert man die Zahl der Hintergrundprozesse (ARBn), welche die Re-Distribution der Daten durchführen. Werte von 0 bis 11 sind erlaubt. Je höher der Wert, desto schneller ist das Rebalancing, desto höher sind aber auch die Auswirkungen auf das System. Der Default-Wert (1) wird über den Parameter asm_ power_limit geändert. Achtung: der Wert 0 schaltet das automatische Rebalancing ganz aus. Ab 11g lässt sich das Rebalancing beschleunigen, indem man die Diskgruppe im Restricted-Modus mountet. Weil in diesem Modus nur eine einzige Instanz die Diskgruppe mounten kann, fällt der Synchronisationsaufwand zwischen den Instanzen weg und das Rebalancing ist entsprechend schneller. Für ein solches Rebalancing wird normalerweise ein hoher Wert in der REBALANCE POWER-Klausel definiert. Praxistipp Ein Vorteil von ASM ist die Möglichkeit, Rebalancing-Operationen unabhängig von der physikalischen Lokation der Disks durchzuführen. So kann beispielsweise eine Datenbank unterbrechungsfrei von einem Storage-Subsystem auf ein anderes (z.B. auf ein neues SAN) verschoben werden. Der gleichzeitige Zugriff von ASM auf die Disks beider Speichersubsysteme ist die einzige Voraussetzung, die erfüllt sein muss.
Das Verschieben und Kopieren von Datenbankfiles wird normalerweise mit einem der folgenden Tools gemacht:
RMAN (das Beispiel von Abschnitt 4.1.3.1 ist auch für ASM anwendbar) DBMS_FILE_TRANSFER-Package Das Vergrößern von Datenbankfiles wird mit ASM transparent unterstützt. Einzige Voraussetzung ist genügend freier Platz in der entsprechenden Diskgruppe. In Abschnitt 4.2.2 und 4.2.3 zeigen wir je ein Beispiel für automatisches und manuelles Resizing. 4.1.4.2 Verfügbarkeit ASM verfügt über drei verschiedene Diskgruppen-Typen: externe Redundanz, normale Redundanz und hohe Redundanz. Der Diskgruppen-Typ bestimmt den Level der Spiegelung. Mit externer Redundanz werden die Spiegelungseigenschaft des Speichersubsystem genutzt. Die anderen beiden Typen gewährleisten die Spiegelung von ASM. Normale Redundanz spiegelt die Daten doppelt, hohe Redundanz dreifach. Wenn das Speichersubsystem ein High-End-SAN oder -NAS ist, kommen die Spiegelungs- (und Striping-)Möglichkeiten von ASM normalerweise nicht zur Anwendung, eine Ausnahme bilden Cluster, deren Knoten und Speichersubsysteme über mehrere Lokationen verteilt sind. In einem solchen Fall ist es vorteilhafter, die Spiegelung (und das Striping) dem Speichersubsystem zu überlassen. ASM nutzt dann die entsprechenden Disks in einer Diskgruppe mit externer Redundanz.
254
4.2 Data-, Temp- und Redolog-File-Attribute 4.1.4.3 Performance ASM benötigen keine spezielle Konfiguration für die optimale Performance – einzige Ausnahme ist, wenn die Disks und die Instanzen über zwei (oder drei) Lokationen verteilt sind. In diesem Fall sollte man nicht nur für jede Lokation eine „Failure Group“ (welche die lokalen Disks beinhaltet) definieren, sondern auch die Instanzen so einrichten, dass die „Preferred Failure Group“ lokal ist. Für diesen Zweck steht der Parameter asm_preferred_read_failure_groups zur Verfügung. 4.1.4.4 Zugriff ASM wurde sowohl für den Einsatz in Real-Application-Clusters- als auch für SingleInstanz-Umgebungen entwickelt. Die einzige Voraussetzung beim Einsatz in RAC-Umgebungen ist, dass der Zugriff auf die Disks für alle Server im Clusterverbund gewährleistet ist. Weil sich die Disks dem ASM als Raw-Devices präsentieren, sollte dies grundsätzlich kein Problem sein.
4.1.5
Die Auswahl der Datenbank-Speicheroption
Früher waren Raw-Devices bezüglich Performance und Eignung für Clustersysteme die erste Wahl waren. Mit ASM steht heute eine viel einfachere und flexiblere Lösung zur Verfügung. Hinzu kommt, dass Oracle plant, Raw-Devices in Zukunft nicht mehr zu unterstützen (siehe My Oracle Support Artikel 754305.1 „Announcement on using Raw devices with release 11.2“). Aus diesem Grunde empfehlen wir, in neuen Systemen RawDevices nicht mehr einzusetzen. Um die vier zentralen Anforderungen (Verwaltung, Verfügbarkeit, Performance und Zugriff) zu erfüllen, ohne einen Logical-Volume-Manager eines Drittherstellers lizensieren zu müssen, empfehlen wir ASM. Wer Real Application Clusters mit der Standard Edition verwendet, muss zwingend ASM einsetzen. Auch wenn die Verwaltung von ASM nicht sehr schwierig ist, ist ASM eine zusätzliche Infrastrukturkomponente, die verwaltet und verstanden werden muss. Wenn der zusätzliche Aufwand für Verwaltung und Setup den Nutzen gegenüber einem Filesystem übersteigt, empfehlen wir, anstelle von ASM ein Filesystem zu verwenden.
4.2
Data-, Temp- und Redolog-File-Attribute Im vorherigen Abschnitt haben wir gezeigt, wie die Datenbankfiles im Storage-System gespeichert sind. In diesem Abschnitt beschreiben wir die Attribute, die für Datafiles, Tempfiles und Redolog-Files spezifiziert werden können. Das einzige Attribut, das man für alle drei Filetypen definieren kann, ist die initiale Filegröße (Initial Size). Zusätzlich lassen sich Datafiles und Tempfiles (vorausgesetzt, man verwendet keine Raw-Devices) so spezifizieren, dass sie sich bei Bedarf automatisch vergrößern. Natürlich kann man die Datafiles auch manuell vergrößern.
255
4 Speicherplatzverwaltung
4.2.1
Initial Size
Beim Erstellen eines Datafiles, eines Tempfiles oder eines Redolog-Files wird die initiale Größe mit der SIZE-Klausel definiert. Wie das folgende Beispiel zeigt, kann man die Größe mit dem entsprechenden Suffix „K“, „M“, „G“, „T“, „P“ oder „E“ sowohl in Bytes, Kilobytes, Megabytes, Gigabytes, Terabytes, Petabytes oder Exabytes spezifizieren. SQL> CREATE TEMPORARY TABLESPACE test 2 TEMPFILE '/u00/oradata/ora11g/test01ora11g.dbf' SIZE 1G;
Bei der Erstellung eines Datenfiles oder eines Redolog-Files initialisiert die DatabaseEngine alle zugehörigen Blöcke. Aus diesem Grund kann die Erstellung eines großen Tablespaces auch entsprechend viel Zeit beanspruchen. Eine vorgängige Initialisierung findet für Tempfiles nicht zwingend statt, sondern es entsteht, abhängig vom Betriebssystem, ein sogenanntes „Sparsefile“. Der erforderliche Platz für einen Block in einem Sparsefile wird erst dann alloziert, wenn man den Block das erste Mal verwendet. Dies bedeutet, dass der erforderliche Diskplatz für ein Tempfile erst bei dessen Nutzung vollständig alloziert wird. Das folgende Beispiel illustriert dieses Verhalten, wir verwenden dazu den zuvor erstellten Tablespace: 1. Anzeige der Dateigröße des Tempfiles mittels Betriebssystem-Kommando (in diesem Fall Linux). Wie aus dem folgenden Output ersichtlich ist, zeigt der Befehl ls -l eine Filegröße von 1 GB an (eigentlich 1 GB + ein Datenbankblock). Gleichzeitig zeigt uns der Befehl ls -s aber lediglich eine Filegröße von 129 Blöcken à 8192 Bytes (= 1‘056‘768 Bytes) an. Daraus folgt: Der erste Befehl zeigt die Dateigröße und der zweite Befehl den allozierten Platz an. $ cd /u00/oradata/ora11g/ $ ls -l test01ora11g.dbf -rw-r----- 1 oracle oinstall 1073750016 Aug 5 18:17 test01ora11g.dbf $ ls -s --block-size=8192 test01ora11g.dbf 129 test01ora11g.dbf
2. Nun erstellen wir im temporären Tablespace ein temporäres Segment mit ca. 100 MB Daten. Danach löschen wir das Objekt wieder. SQL> CREATE GLOBAL TEMPORARY TABLE t (id NUMBER, pad VARCHAR2(1000)) 2 TABLESPACE test; SQL> 2 3 4
INSERT INTO t SELECT rownum, rpad('*',1000,'*') FROM dual CONNECT BY level <= 100000;
SQL> DROP TABLE t PURGE;
3. Jetzt werten wir den Platz nochmals wie in Punkt 1 aus. Beachten Sie, dass nun 11‘335 Blöcke alloziert sind – das Tempfile verwendet nun ca. 93 MB Platz auf Betriebssystemebene. $ ls -s --block-size=8192 test01ora11g.dbf 11335 test01ora11g.dbf
256
4.2 Data-, Temp- und Redolog-File-Attribute Im Zusammenhang mit Sparsefiles gibt es zwei Probleme. Erstens: Weil der Platz erst bei der effektiven Nutzung alloziert wird, kann es vorkommen, dass der Platz auf Betriebssystemebene vorgängig bereits anderweitig verwendet wurde und für das Sparsefile nicht mehr zur Verfügung steht. Dies führt ggf. zu einem Fehler (z.B. ORA-01114: IO error writing block to file). Zweitens kann es zu Performance-Einbußen führen, weil auf bestimmten Betriebssystemen für Sparsefiles nicht alle Features unterstützt werden (beispielsweise unterstützt Solaris kein Direct-I/O). Praxistipp Wir empfehlen, keine Sparsefiles zu verwenden und die Tempfiles vorgängig, das heißt bevor die Zuordnung zur Datenbank erfolgt, auf Betriebssystem-Ebene zu erstellen.
Das folgende Beispiel zeigt, wie man Sparefiles beim Erstellen von Tempfiles verhindern kann. 1. Erstellen des Files auf Betriebssystem-Ebene (in diesem Fall Linux). Dazu kann das Unixprogramm dd verwendet werden. Beachten Sie, dass die Größe der Datei mit der Größe des Tempfiles übereinstimmen muss. $ cd /u00/oradata/ora11g $ dd if=/dev/zero of=test01ora11g.dbf bs=1024 count=1048584
2. Zuweisen des erstellten Files zur Datenbank. Dabei sind zwei Dinge zu beachten: Erstens die REUSE-Klausel zu verwenden, weil die Datei ja bereits existiert. Zweitens die SIZE-Klausel nicht zu spezifizieren, da die Datenbank die Dateigröße vom Betriebssystem übernimmt. SQL> CREATE TEMPORARY TABLESPACE test 2 TEMPFILE '/u00/oradata/ora11g/test01ora11g.dbf' REUSE;
4.2.2
Automatische Filevergrößerung
Datafiles und Tempfiles lassen sich mit oder ohne automatischer Filevergrößerung (Autoextend) erstellen. Defaultmäßig ist die automatische Filevergrößerung nicht aktiviert – vorausgesetzt die SIZE-Klausel ist spezifiziert, oder eine bestehende Datei wird wieder verwendet. Dies bedeutet, dass der DBA die Verantwortung für die manuelle Vergrößerung der Datafiles trägt, falls zusätzlicher Platz erforderlich ist. Das manuelle Vergrößern ist im nächsten Abschnitt beschrieben. Die automatische Filevergrößerung vermeidet das manuelle Eingreifen. Bei deren Aktivierung wird definiert, in welchen Schritten die Vergrößerung erfolgen soll und wie groß die Datei maximal sein darf. Das folgende Beispiel zeigt die Spezifikation eines Tempfiles mit automatischer Dateivergrößerung: SQL> CREATE TEMPORARY TABLESPACE test 2 TEMPFILE '/u00/oradata/ora11g/test01ora11g.dbf' SIZE 1G 3 AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED;
Die automatische Filevergrößerung ist nur interessant, wenn die Platzüberwachung anstelle auf Tablespace-Ebene auf Filesystem- oder auf Diskgroup-Ebene erfolgen soll.
257
4 Speicherplatzverwaltung Praxistipp Für Tempfiles empfehlen wir, die automatische Filevergrößerung auszuschalten. Fehlerhafte SQL-Anweisungen, die eine große Menge temporärer Informationen generieren, können einen temporären Tablespace sehr schnell füllen. Bei temporären Tablespaces ist es deshalb sinnvoller, eine Fehlermeldung an die verursachende Session zu senden, als unnötigerweise eines oder mehrere Tempfiles zu erweitern.
4.2.3
Manuelle Filevergrößerung
Data- und Tempfiles können bei Bedarf jederzeit vergrößert werden – vorausgesetzt der dazu erforderliche Platz ist im Speichersystem verfügbar. Im folgenden Beispiel zeigen wir den entsprechenden Befehl RESIZE : SQL> ALTER DATABASE 2 TEMPFILE '/u00/oradata/ora11g/test01ora11g.dbf' RESIZE 2G;
Der Befehl RESIZE kann Data- und Tempfiles auch verkleinern. Das kann jedoch nur dann erfolgen, wenn der zu verkleinernde Teil des Files keine Extents enthält. Das folgende Beispiel zeigt, was geschieht, wenn diese Voraussetzung nicht erfüllt ist: SQL> ALTER DATABASE 2 TEMPFILE '/u00/oradata/ora11g/test01ora11g.dbf' RESIZE 1G; ALTER DATABASE * ERROR at line 1: ORA-03297: file contains used data beyond requested RESIZE value
Beachten Sie, dass der freie Platz im File nicht entscheidend ist. Es kommt auf die Position der Extents innerhalb der Datei an. Auch wenn nur ein einzelnes, kleines Extent am Ende der Datei vorhanden ist, kann die Resize-Operation nicht ausgeführt werden. Praxistipp Das Skript lstsres.sql kann für die Anzeige der Platzverhältnisse (Größe, benutzter Platz, Verkleinerungspotenzial ohne Reorganisation) in den Datenfiles eines bestimmten Tablespaces verwendet werden. Ist der freie Platz im Datenfile wesentlich größer, als der Platz, der mit einem Resize gewonnen werden kann, sind Segmente gelöscht worden. Werden keine neuen Segmente in diesem Tablespace angelegt, ist es sinnvoll die Segmente zu verschieben, sodass mittels Resize das Datenfile verkleinert werden kann (siehe Abschnitt 4.6.2).
4.3
Extent Management Optionen Bei der Erstellung eines Tablespaces wird definiert, wie die Extents darin verwaltet werden sollen. Das heißt, es ist festgelegt, wie der freie Platz innerhalb des Tablespaces verwaltet wird. Es gibt grundsätzlich zwei Verwaltungsarten: Dictionary Managed Tablespaces und Locally Managed Tablespaces. Ein Extent ist eine Abfolge von Blöcken innerhalb einer Datei. Weil ein Extent sich nicht über mehrere Dateien erstrecken darf und auch keine “Löcher” aufweisen kann, ist es durch
258
4.3 Extent Management Optionen seinen Startblock und seine Größe definiert. Zwei Anforderungen müssen von der Datenbank bezüglich Extentverwaltung erfüllt sein. Erstens: Ein bestimmter Block (und demzufolge ein Teil eines Datafiles) kann nur einem einzigen Extent zugeordnet sein. Zweitens: Wird ein Extent nicht mehr benutzt, ist der freiwerdende Teil des Datafiles für andere Extents wieder zur Verfügung zu stellen. Während die erste Anforderung einfach zu implementieren ist, verhält es sich mit der zweiten etwas komplizierter. Sind die Extents unterschiedlich groß (nicht uniform), kann der freigewordene Platz nicht in allen Fällen wiederverwendet werden. Oder mit anderen Worten: Ungleiche Extentgrößen können zu Fragmentierung führen. Im folgenden Abschnitt beschreiben wir, wie die beiden oben erwähnten Anforderungen an das Extent Management mit Dictionary Managed und Locally Managed Tablespaces implementiert sind. Zuerst zeigen wir aber, was eine Extent-Map ist, und werden einige wichtige Konzepte betreffend Dimensionierung und Allokation von Extents betrachten. Zum Schluss geben wir ein paar praktische Hinweise betreffend Auswahl und Einsatz der verfügbaren Verwaltungsoptionen.
4.3.1
Extent Map
Zu Beginn dieses Kapitels haben wir gesehen, dass ein Segment aus einem oder mehreren Extents besteht. Die Information über Anzahl, Größe und Speicherort dieser Extents wird in einer sogenannten „Extent Map“ verwaltet (siehe Abbildung 4.3). Die Extent-Map ist im Segment selber gespeichert. Besteht das Segment aus einigen Hundert Extents, kann die Extent-Map vollständig im Segmentheader (siehe Kapitel 2 „Architektur und Administration“) gespeichert werden; etwa die Hälfte der Blöcke ist für diesen Zweck reserviert. Ist nicht genügend Platz im Segmentheader vorhanden, wird die Extent-Map über die notwendige Anzahl Blöcke verteilt.
Segmentheader-Block
Daten- Daten- DatenBlock Block Block
Daten- Daten- DatenExtent 1 Block Block Block
Extent-Map
Daten- Daten- DatenBlock Block Block
Daten- Daten- Daten- Extent 2 Block Block Block
Daten- Daten- DatenBlock Block Block
Daten- Daten- DatenExtent 3 Block Block Block
Abbildung 4.3 Die Extent-Map beinhaltet Ort und Größe aller Extents, die zum entsprechenden Segment gehören
Neben anderen Aufgaben verwendet die Database-Engine die Extent-Map für die Ausführung von Full-Scans. Beim Full-Scan werden die Extents in der gleichen Reihenfolge gelesen, wie sie in der Extent-Map gespeichert sind.
259
4 Speicherplatzverwaltung
4.3.2
Storage-Parameter
Die Storage-Klausel definiert über diverse Attribute die Größe und Anzahl der Extents. Weil die Bedeutung und auch die Validierung dieser Attribute von der Extentverwaltungsmethode abhängig sind, betrachten wir in diesem Abschnitt nur die allgemeine Bedeutung dieser Attribute. Die spezifische Implementierung wird zusammen mit den Extentverwaltungsoptionen später in diesen Kapitel beschrieben. Die folgenden drei Storageparameter bestimmen die Extentgröße:
INITIAL: Die Größe des ersten Extents eines Segments NEXT: Die Größe der Extents, die nach dem ersten Extent erstellt werden PCTINCREASE: Der Prozentsatz, zu dem das dritte und alle folgenden Extents gegenüber dem vorgängigen Extent wachsen. Ein Beispiel: Die Größe des dritten Extents ist gleich NEXT*(1+PCTINCREASE/100). Zwei weitere Storage-Parameter bestimmen die Anzahl Extents:
MINEXTENTS: Die Anzahl Extents, die bei der Erstellung des Segments alloziert werden MAXEXTENTS: Die maximale Anzahl Extents, die ein Segment haben kann. Das Schlüsselwort UNLIMITED definiert keine obere Grenze. Das folgende SQL-Statement zeigt, wie man diese Parameter für eine Tabelle definiert: SQL> CREATE TABLE t (id NUMBER, pad VARCHAR2(1000)) 2 STORAGE ( 3 INITIAL 10M 4 NEXT 1M 5 PCTINCREASE 0 6 MINEXTENTS 1 7 MAXEXTENTS UNLIMITED 8 );
Wie wir später in diesem Kapitel sehen werden, kann man für Dictionary Managed Tablespaces eine Defaultstorage-Klausel spezifizieren. Diese Klausel bestimmt die Defaulteinstellung für alle Segmente, für die keine explizite Storageklausel besteht.
4.3.3
Extent-Allozierung
In den meisten Situationen ist die Allokation von Extents eine triviale Operation. Benötigt ein Segment mehr Platz als bereits alloziert, muss ein neues Extent alloziert und diesem Segment zugeordnet werden. Es gibt jedoch zwei spezielle Situationen, die wir an dieser Stelle diskutieren wollen: die verzögerte (deferred) Segmenterstellung sowie parallele Inserts. Bis 11g R1 wurden gleichzeitig mit dem Erstellen eines Objekts immer auch die initialen Extents des Segmentes alloziert. Mit 11g R2 hat sich dieses Verhalten dank des Features „Deferred Segment Creation“ geändert. Ein Segment und seine initialen Extents werden erst dann alloziert, wenn der erste Eintrag (Einfügen eines Wertes) in die Tabelle erfolgt. Das folgende Beispiel illustriert dieses Verhalten:
260
4.3 Extent Management Optionen SQL> CREATE TABLE t (n NUMBER); Table created. SQL> SELECT segment_created 2 FROM user_tables 3 WHERE table_name = 'T'; SEGMENT_CREATED --------------NO SQL> SELECT segment_name 2 FROM user_segments 3 WHERE segment_name = 'T'; no rows selected SQL> INSERT INTO t VALUES (1); 1 row created. SQL> SELECT segment_created 2 FROM user_tables 3 WHERE table_name = 'T'; SEGMENT_CREATED --------------YES SQL> SELECT segment_name 2 FROM user_segments 3 WHERE segment_name = 'T'; SEGMENT_NAME -----------T
Dieses Verhalten lässt sich mit dem Datenbankparameter DEFERRED_SEGMENT_CREATION überschreiben. Dazu muss der (Default-)Wert TRUE auf FALSE gesetzt sein. Dies kann auf System- oder auf Sessionebene erfolgen, oder beim Erstellen der Tabelle mit der Klausel SEGMENT CREATION IMMEDIATE. Folgende Einschränkungen sind bezüglich „Deferred Segment Creation“ zu beachten:
Version 11.2.0.1 unterstützt nur nichtpartitionierte Heap-Tabellen und deren abhängige Objekte (z.B. Indizes und LOBs). Diese Einschränkung ist mit Version 11.2.0.2 aufgehoben.
Segmente, die zu SYS, SYSTEM, PUBLIC, OUTLN, oder XDB gehören, werden nicht unterstützt.
Bitmap-Join-Indizes und Domain-Indizes sind nicht unterstützt. Segmente, die in Dictionary Managed Tablespaces verwaltet werden, sind ebenfalls nicht unterstützt. Beim Arbeiten mit „Deferred Segment Creation“ muss der Tablespace ausreichend dimensioniert sein, um alle neuen Segmente zu speichern, beziehungsweise wenn auf Dateiebene Autoextend zum Einsatz kommt, genügend Platz auf Betriebssystemebene vorhanden ist).
261
4 Speicherplatzverwaltung Ist dies nicht sichergestellt, können Fehler auftreten, sobald die Datenbank versucht, ein neues Extent zu allozieren. Eine Eigenheit von parallelen Inserts ist, dass der verfügbare freie Platz in den bereits allozierten Extents bei der Ausführung nicht berücksichtigt wird. Dies bedeutet, dass für jeden parallelen Slaveprozess, welcher die Insertoperation durchführt, mindestens ein neues Extent alloziert und dem geänderten Tabellensegment zugeordnet wird. Das folgende Beispiel illustriert dieses Verhalten. Beachten Sie, wie die zweite Insertanweisung, die zehn Einträge parallel in die Tabelle einfügt, zur Allozierung von zwei neuen Extents führt, und dies obwohl noch genügend Platz im ersten Extent vorhanden ist. SQL> CREATE TABLE t (n NUMBER); Table created. SQL> INSERT INTO t VALUES (1); 1 row created. SQL> COMMIT; Commit complete. SQL> SELECT extent_id 2 FROM user_extents 3 WHERE segment_name = 'T'; EXTENT_ID ---------0 SQL> ALTER SESSION ENABLE PARALLEL DML; Session altered. SQL> INSERT /*+ parallel(t,2) */ INTO t 2 SELECT rownum+1 FROM dual CONNECT BY level <= 10; 10 rows created. SQL> COMMIT; Commit complete. SQL> SELECT extent_id 2 FROM user_extents 3 WHERE segment_name = 'T'; EXTENT_ID ---------0 1 2
262
4.3 Extent Management Optionen
4.3.4
Dictionary Managed Tablespaces
Die Extent-Informationen von Dictionary Managed Tablespaces sind in zwei DataDictionary-Tabellen verwaltet. Die erste Tabelle (uet$) beinhaltet für jedes benutzte Extent einen Eintrag. Die zweite Tabelle (fet$) beinhaltet einen Eintrag für jedes unbenutzte Extent. Wird ein neues Extent alloziert, muss Oracle freien Platz in fet$ finden, darin eine Row aktualisieren oder löschen und danach eine Row in uet$ einfügen. Um Platz freizugeben, der einem Extent zugeordnet ist, wird eine Row aus uet$ gelöscht und in fet$ eingefügt. Aufgrund dieser Methode können Operationen, die viele Extents ändern, wie beispielsweise das Löschen einer Tabelle mit Tausenden von Extents, sehr zeitintensiv sein. Dictionary Managed Tablespaces unterstützen alle Storageparameter. Sie funktionieren wie in Abschnitt 4.3.2 beschrieben. Dies führt oft dazu, dass Extents, die in einem Dictionary Managed Tablespace erstellt wurden, keine einheitliche Größe aufweisen, was zu Fragmentierung führt. Praxistipp In einem Dictionary Managed Tablespaces kann man Fragmentierung verhindern, indem die Extentgröße ein Vielfaches eines bestimmten Werts beträgt. Für diesen Zweck steht die Klausel MINIMUM EXTENT zur Verfügung.
Das folgende Beispiel zeigt, wie man einen Dictionary Managed Tablespace erstellt, dessen Extents ein Vielfaches von 1 MB betragen. SQL> 2 3 4
Beim Erstellen eines Dictionary Managed Tablespace sind Default-Storage-Parameter für Segmente möglich, denen keine expliziten Storage-Parameter zugewiesen sind. Hierzu ein Beispiel: SQL> 2 3 4 5 6 7 8 9 10
Folgende Einschränkungen beziehen sich auf Dictionary Managed Tablespaces:
Deferred Segment Creation ist nicht unterstützt. Automatic Freespace Management ist nicht unterstützt. Abschnitt 4.4.3 behandelt dieses Feature.
263
4 Speicherplatzverwaltung
4.3.5
Locally Managed Tablespaces
Die Extent-Informationen von Locally Managed Tablespaces sind in sogenannten „SpaceBlöcken“ verwaltet, die innerhalb des Tablespaces gespeichert werden. Mit anderen Worten: Die Extentverwaltung findet nicht mehr im Data Dictionary statt, sondern lokal im Tablespace. Um die Größe der Extents unter Kontrolle zu halten, kann man zwischen Uniform-Size oder Auto-Allocate wählen. Im zweiten Fall überlässt man die Wahl der passenden Extentgröße dem System. Zudem ist die Wahl zwischen Smallfile- und BigfileTablespaces möglich. 4.3.5.1 Uniform Extent Size Wie der Name sagt, haben mit der Uniform Extent Size alle Extents exakt dieselbe Größe. Dies hat den Vorteil, dass keine Fragmentierung entstehen kann. Auf der anderen Seite wird der allozierte Platz unter Umständen – speziell bei großen Extents – nicht optimal genutzt. De facto ist für jedes Segment mindestens ein Extent zu allozieren, unabhängig davon, wie viele Daten darin gespeichert werden müssen. Praxistipp Um eine Überallozierung zu verhindern, sollte die Extentgröße ein Vielfaches kleiner sein, als die für das Segment erwartete Datenmenge. Zudem sollte bei parallelen Inserts die Extentgröße ein Vielfaches kleiner sein, als die durch eine Ausführung eines einzelnen Slaveprozesses eingeführte Datenmenge.
Das folgende Beispiel zeigt die Erstellung eines Tablespace mit einer Uniform Size von 1 MB: SQL> CREATE TABLESPACE test 2 DATAFILE '/u00/oradata/ora11g/test01ora11g.dbf' SIZE 1G 3 EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;
Die Verwendung der Uniform Extent Size berücksichtigt die in Abschnitt 4.3.2 erwähnten Speicherparameter nur bei der Segmenterstellung. Es gibt auch keine Einschränkung bezüglich der Anzahl Extents (MAXEXTENTS wird beispielsweise ignoriert). Das folgende Beispiel zeigt die Auswirkung der Uniform Extent Size bei der Erstellung eines Segments. Beachten Sie, dass gemäß MINEXTENTS drei Extents alloziert sein sollten. Gemäß dem INITIAL-Parameter sollte das erste Extent 4 MB groß sein, das zweite Extent gemäß dem NEXT-Parameter 2 MB betragen und das dritte Extent gemäß NEXT und PCTINCREASE 3 MB groß sein. Mit einer Uniform-Size von 1 MB sollte dies in Summe eine allozierte Größe von 9 MB ergeben. Beachten Sie auch, dass im Data Dictionary angepasste Werte vorhanden sind und nicht die in der SQL-Anweisung spezifizierten Werte. SQL> CREATE TABLE t (id NUMBER, pad VARCHAR2(1000)) 2 STORAGE ( 3 INITIAL 4M 4 NEXT 2M 5 PCTINCREASE 50 6 MINEXTENTS 3 7 MAXEXTENTS 6
264
4.3 Extent Management Optionen 8 9 SQL> 2 3 4
) TABLESPACE test; SELECT bytes, count(*) FROM user_extents WHERE segment_name = 'T' GROUP BY bytes;
Das Beispiel zeigt, wie die Storage-Parameter die Extent-Allozierung beeinflussen. Wir empfehlen nicht, die Parameter in der Praxis auf diese Art und Weise zu spezifizieren. Praxistipp Beim Einsatz von Locally Managed Tablespaces mit Uniform Extent Size sollten die Storageparameter der Segmente nicht spezifiziert sein.
Für Locally Managed Tablespaces mit Uniform Extent Size gelten folgende Einschränkungen:
Diese Extentverwaltungsoption wird für Undo-Tablespaces nicht unterstützt. Die Default-Storage-Klausel ist nicht unterstützt. 4.3.5.2 System Managed Extent Size Das Ziel der System Managed Extent Size ist die Abstimmung der Extentgrößen auf die Größe des Segments, dem die Extents zugeordnet sind. Mit anderen Worten: Ein großes Segment sollte große Extents erhalten, ein kleines Segment kleine. Auf diese Weise sollte es möglich sein, sowohl Fragmentierung, als auch eine sehr große Anzahl Extents weitestgehend zu verhindern. Zu diesem Zweck verwendet die Database-Engine StandardExtentgrößen von 64 KB, 1 MB, 8 MB oder 64 MB. Das folgende Beispiel zeigt, wie man einen Tablespace mit System Managed Extent Size erstellt: SQL> CREATE TABLESPACE test 2 DATAFILE '/u00/oradata/ora11g/test01ora11g.dbf' SIZE 1G 3 EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
Mit der System Managed Extent Size werden die Storage-Parameter auf die gleiche Art und Weise behandelt wie mit der Uniform Extent Size (Details siehe Abschnitt 4.3.5.1 „Uniform Extent Size“). Mit anderen Worten: Die Storage-Parameter sind mit einer Ausnahme lediglich für die initiale Dimensionierung des Segments notwendig.
265
4 Speicherplatzverwaltung Ab Version 11.1.0.7 wird das NEXT-Attribut bei parallelen Inserts für die Dimensionierung der Extents verwendet (zur Erinnerung: parallele Inserts allozieren immer neue Extents). In diesem Zusammenhang ist jedoch (ein weiterer) Spezialfall zu beobachten: die Allozierung von Extents, die nicht der Standart-Extentgröße entsprechen. Zur Verhinderung von nicht wiederverwendbarem freiem Platz, lassen sich die Extents auf einen Bruchteil der Standardgröße (64 KB, 1 MB, 8 MB oder 64 MB) verkleinern, wie das folgende Beispiel zeigt: SQL> CREATE TABLE t (n NUMBER) 2 STORAGE (INITIAL 1M NEXT 1M) 3 TABLESPACE test; Table created. SQL> INSERT INTO t VALUES (1); 1 row created. SQL> COMMIT; Commit complete. SQL> SELECT extent_id, bytes 2 FROM user_extents 3 WHERE segment_name = 'T'; EXTENT_ID BYTES ---------- ---------0 1048576 SQL> ALTER SESSION ENABLE PARALLEL DML; Session altered. SQL> INSERT /*+ parallel(t,2) */ INTO t 2 SELECT rownum+1 FROM dual CONNECT BY level <= 200000; 200000 rows created. SQL> COMMIT; Commit complete. SQL> SELECT extent_id, bytes 2 FROM user_extents 3 WHERE segment_name = 'T'; EXTENT_ID BYTES ---------- ---------0 589824 1 1048576 2 327680 3 1048576 4 327680
Für Locally Managed Tablespaces mit System Managed Extent Size gelten folgende Einschränkungen:
Diese Art der Extentverwaltung ist für temporäre Tablespaces nicht unterstützt. Die Default Storage-Klausel ist nicht unterstützt.
266
4.3 Extent Management Optionen 4.3.5.3 Smallfile- vs. Bigfile-Tablespaces Traditionsgemäß verwendet Oracle Smallfile-Tablespaces. Damit kann ein Tablespace typischerweise aus bis zu 1022 Files à 222-1 Blöcken bestehen. Die Limitierung ist betriebssystemabhängig; die erwähnten Werte sind für die am häufigsten eingesetzten Betriebssysteme gültig. Mit anderen Worten: Die maximale Größe eines Tablespaces mit einer DefaultBlockgröße von 8 KB beträgt ca. 32 TB. Eine weitere Einschränkung ist die Anzahl der Datenbankfiles pro Datenbank. Diese wird mit dem Initialisierungsparameter db_files beschränkt. Maximal sind 65.533 Files pro Datenbank möglich. Insbesondere die zweite Einschränkung stellt für die meisten Datenbanken kein Problem dar, außer Sie planen eine sehr große Datenbank: Mit einer Blockgröße von 8 KB sind lediglich 64 Tablespaces à 32 TB möglich. Diese Limitierung fällt mit dem Einsatz von Bigfile-Tablespaces weg. Damit kann der Tablespace selber nicht größer werden, aber weil Bigfile-Tablespaces nur aus einem File bestehen, sind bis zu 65.533 Tablespaces à 32 TB vorstellbar. Defaultmäßig erzeugt die Database-Engine Smallfile-Tablespaces. Der Default kann auf Datenbankebene entweder über die SET DEFAULT TABLESPACE-Klausel in der CREATE DATABASE-Anweisung geändert werden, oder für eine bereits bestehende Datenbank mit folgendem SQL-Befehl: SQL> ALTER DATABASE SET DEFAULT BIGFILE TABLESPACE;
Die View database_properties zeigt die Default-Einstellung: SQL> SELECT property_value 2 FROM database_properties 3 WHERE property_name = 'DEFAULT_TBS_TYPE'; PROPERTY_VALUE --------------BIGFILE
Beim Erstellen eines neuen Tablespaces mit dem Statement CREATE TABLESPACE, kann man den Datenbank-Default mit der Klausel SMALLFILE oder BIGFILE überschreiben. Die folgende SQL-Anweisung zeigt diese Möglichkeit: SQL> CREATE SMALLFILE TABLESPACE test 2 DATAFILE '/u00/oradata/ora11g/test01ora11g.dbf' SIZE 1G;
Für Bigfile-Tablespaces gilt folgende Einschränkung:
Bigfile Dictionary Managed Tablespaces sind nicht unterstützt. Mit anderen Worten: Bigfile Tablespaces müssen “locally-managed” sein.
4.3.6
Auswahl der Extent-Management-Optionen
Locally Managed Tablespaces haben weitaus mehr Vorteile gegenüber Dictionary Managed Tablespaces und sind deshalb die erste Wahl beim Erstellen eines neuen Tablespaces. Auch Oracle empfiehlt nur noch die Erstellung von Locally Managed Tablespaces; es ist geplant das Erstellen von neuen Dictionary Managed Tablespaces in Zukunft nicht mehr zu unterstützen.
267
4 Speicherplatzverwaltung Praxistipp In einer neuen Datenbank sollte der SYSTEM-Tablespace nur noch dann „Dictionary Managed“ sein, wenn dictionary-managed Transportable Tablespaces angehängt und im Read/WriteModus betrieben werden. Wenn der SYSTEM-Tablespace „Locally Managed“ ist, müssen alle anderen Tablespaces im Read/Write-Modus locally-managed sein.
Die Wahl zwischen Uniform Extent Size und System Managed Extent Size hängt davon ab, ob die Größe des im Tablepace zu speichernden Segmentes bekannt ist oder nicht, und ob man in der Lage ist, geeignete INITIAL- und NEXT-Werte für jedes Segment zu spezifizieren. Praxistipp Ist die Segmentgröße bekannt und liegen keine speziellen Anforderungen für das INITIALund NEXT-Extent vor, sollte man ein Tablespace mit Uniform Extent Size verwenden. Werden Segmente mit sehr unterschiedlicher Größe erstellt, sind Tablespaces mit entsprechend unterschiedlicher Uniform Extent Size (beispielsweise ein Tablespace mit 64 KB und ein anderer mit 8 MB) möglich. Damit können die Segmente entsprechend ihrer Größe den Tablespaces zugeordnet sein. Für Segmente, deren Größe nicht bekannt ist, oder deren INITIAL- und NEXT-Attribute unkritisch sind, sollte man Tablespaces mit System Managed Extent Size verwenden.
Für die meisten Datenbanken empfiehlt es sich, Smallfile-Tablespaces einzusetzen. Deren Flexibilität ist nicht nur höher, sondern Bigfile-Tablespace sind auch nur dann relevant, wenn die Datenbank aus Tausenden von Tablespaces besteht, oder die Größe mindestens einige zehn TB beträgt. Praxistipp Datafiles von Bigfile-Tablespaces sollten nur dann auf Raw-Devices und Filesystemen verwaltet werden, wenn man das Device oder das Filesystem erweitern kann. Dies ist beispielsweise der Fall, wenn ein Logical Volume Manager zum Einsatz kommt. Wird dies nicht beachtet und benötigt der Tablespace mehr Platz, als das Speichersystem zur Verfügung stellen kann, ist unter Umständen der gesamte Inhalt des Tablespace zu reorganisieren, beispielsweise durch Verschieben von Segmenten in einen anderen Tablespace.
4.4
Segmentspace-Verwaltung Der vorangehende Abschnitt zeigt, wie die Database-Engine Extents alloziert und diese den Segmenten zuordnet. Mit anderen Worten, wie die Platzverwaltung auf Dateiebene funktioniert. In diesem Abschnitt gehen wir einen Schritt weiter und beschreiben die Platzverwaltung auf Segmentebene. Wir zeigen beispielsweise auf, wie Oracle die Rows bei einem Insert platziert, oder was mit dem freien Platz geschieht, wenn ein Datensatz gelöscht wird. Zu diesem Zweck verfügt Oracle über zwei Hauptstrategien: manuelle oder
268
4.4 Segmentspace-Verwaltung automatische Segmentspace-Verwaltung. Erstere, bis einschließlich 8i die einzig verfügbare Methode, bedingt für eine optimale Funktion eine sorgfältige Konfiguration. Die zweite – neuer und daher von Oracle entsprechend favorisiert – erfordert für die korrekte Funktion keinerlei Konfiguration. Das Kapitel beschreibt nicht nur, wie diese beiden Strategien funktionieren, sondern erklärt auch, wie deren Vorteile von Nutzen sind. Zuerst wollen wir aber das Konzept der High-Water Mark kennenlernen.
4.4.1
High-Water Mark
Typischerweise sind nicht alle Blöcke eines Segmentes mit Daten belegt. Während einige Blöcke Daten enthalten oder einmal enthalten haben, sind andere Blöcke unbenutzt und deshalb unformatiert. Die Grenze zwischen den unformatierten und den formatierten Blöcken wird durch die sogenannte „High-Water Mark“ markiert. Per Definition liegen die formatierten Blöcke unterhalb dieser. Die High-Water Mark spielt aus mehreren Gründen eine wichtige Rolle. Erstens hält sie die unformatierten Blöcke zusammen. Dies ist beispielsweise wichtig für ein Full-Scan auf ein Segment, der die Blöcke oberhalb der High-Water Mark nicht berücksichtigen muss; es sind lediglich die Blöcke unterhalb zu lesen. Dies ist besonders dann relevant, wenn das Verhältnis zwischen unformatierten und formatierten Blöcken groß ist. Zweitens werden bestimmte Operationen wie Direct-Inserts unterstützt. Um eine Direct-Insert Operation optimal auszuführen, darf die Database-Engine die bereits formatierten Blöcke unterhalb der High-Water Mark nicht berücksichtigen. Anstelle dessen bildet sie im Memory neue Blöcke, die direkt oberhalb der High-Water Mark in die Datafiles geschrieben werden. Ein wichtiger Punkt ist, dass die High-Water Mark nicht heruntergesetzt wird, wenn man Daten aus einem Segment löscht. Die einzigen beiden Möglichkeiten, die High-Water Mark in diesem Fall herunterzusetzen, sind entweder das Segment neu zu erstellen (beispielsweise mit einem ALTER TABLE MOVE-Befehl), oder dessen Inhalt mit dem ALTER TABLE SHRINK SPACE-Befehl zu reorganisieren. Das folgende Beispiel zeigt den Effekt einer solchen Reorganisation. Beachten Sie, dass sich die Zahl der untersuchten Blöcke (buffer_gets) erst mit der Reorganisation ändert: SQL> SELECT /* 1 */ count(*) FROM t; COUNT(*) ---------10000 SQL> 2 3 4 5
SELECT sq.buffer_gets FROM v$session se, v$sql sq WHERE se.prev_sql_id = sq.sql_id AND se.prev_child_number = sq.child_number AND se.sid = sys_context('userenv','sid');
BUFFER_GETS ----------1503
269
4 Speicherplatzverwaltung SQL> DELETE t WHERE id > 1000; 9000 rows deleted. SQL> COMMIT; Commit complete. SQL> SELECT /* 2 */ count(*) FROM t; COUNT(*) ---------1000 SQL> 2 3 4 5
SELECT sq.buffer_gets FROM v$session se, v$sql sq WHERE se.prev_sql_id = sq.sql_id AND se.prev_child_number = sq.child_number AND se.sid = sys_context('userenv','sid');
BUFFER_GETS ----------1503 SQL> ALTER TABLE t SHRINK SPACE; Table altered. SQL> SELECT /* 3 */ count(*) FROM t; COUNT(*) ---------1000 SQL> 2 3 4 5
SELECT sq.buffer_gets FROM v$session se, v$sql sq WHERE se.prev_sql_id = sq.sql_id AND se.prev_child_number = sq.child_number AND se.sid = sys_context('userenv','sid');
BUFFER_GETS ----------220
Die Implementierung der High-Water Mark für die manuelle Platzverwaltung unterscheidet sich von der automatischen Segmentspace-Verwaltung. Die Beschreibung in diesem Abschnitt trifft mehr auf die manuelle Verwaltung zu. De facto unterhält Oracle bei der automatischen Segmentspace-Verwaltung zwei High-Water Marken: die sogenannte „Low-High-Water Mark” und die „High-High-Water Mark”. Diese sind notwendig, weil keine exakte Grenze zwischen unformatierten und formatierten Blöcken existiert. Die Blöcke zwischen den beiden High-Water Marks können sowohl formatiert als auch unformatiert sein. Aus praktischer Sicht ist diese Unterscheidung jedoch nicht von Bedeutung und wir gehen deshalb an dieser Stelle nicht tiefer darauf ein. Tatsache ist jedoch, dass das Verhalten der High-High-Water Mark bei der automatischen Verwaltung konsistent mit der High-Water Mark bei der manuellen Segmentspace-Verwaltung ist.
270
4.4 Segmentspace-Verwaltung
4.4.2
Manuelle Segmentspace-Verwaltung
Die manuelle Segmentspace-Verwaltung basiert auf verlinkten Listen, die in einer Last-inFirst-out (LIFO) Warteschlange stehen. Sinn und Zweck solcher Listen ist die Verwaltung des freien Platzes. Sie heißen deshalb auch „Freelist“. Einfach gesagt ist eine Freelist eine verlinkte Liste, welche Datenblöcke referenziert, die freien Platz aufweisen. Demzufolge können nur Blöcke in dieser Liste stehen, die sich unterhalb der High-Water Mark befinden. Es gibt keinen spezifischen Ort, wo die gesamte Freelist gespeichert wird. Im Gegenteil, wie Abbildung 4.4 zeigt, kann eine Freelist über mehrere Blöcke verteilt sein. Der Headerblock des Segmentes beinhaltet neben diversen Basisinformationen eine Referenz zum ersten und zum letzten Block, der mit der Freelist verlinkt ist. Alle anderen Referenzen von Blöcken, die mit der Freelist verlinkt sind, werden – sofern vorhanden – im jeweiligen Blockheader gespeichert. SegmentheaderBlock
Daten-Block
Daten-Block
Header
Header
Header
Daten-Block Header Freie Platz
Erste
Extent-Map
ste ch Nä
Freie Platz Daten Daten
e Letz
Freelists
Daten
Abbildung 4.4 Segment mit vier Blöcken unterhalb der High-Water Mark: dem Segmentheader-Block, einen Datenblock ohne freien Platz und zwei teilweise gefüllte Datenblöcke, die auf der Freelist stehen
Nachdem wir nun die grundlegende Struktur einer Freelist beschrieben haben, wenden wir uns ihrer Verwaltung zu. Mit anderen Worten: Wann werden Datenblöcke mit einer Freelist verlinkt beziehungsweise wann wird diese Beziehung wieder aufgelöst? Ein Prozess, der Daten in ein Tabellensegment einfügt, prüft zuerst, ob freier Platz in der Freelist vorhanden ist. Sobald ein Block mit dem erforderlichen freien Platz gefunden ist, werden die Daten eingefügt. Ist kein solcher Block vorhanden, werden die High-Water Mark erhöht und ein oder mehrere Blöcke mit einer Freelist verlinkt. Nachdem die Daten in den Block eingefügt sind, muss der Prozess prüfen, ob er den betroffenen Block wieder aus der Freelist entfernen muss. Die Auflösung der Verlinkung ist nur dann notwendig, wenn der freie Platz innerhalb des Blockes kleiner als PCTFREE ist. Es ist zu beachten, dass bei einem Indexsegment das Attribut PCTFREE nur bei der Erstellung relevant ist, danach wird es nicht mehr berücksichtigt. Indexblöcke werden verwendet, bis sie vollständig gefüllt sind, und falls mehr Platz benötigt wird, aufgeteilt. Beim Löschen von Daten aus einem Tabellensegment muss der entsprechende Prozess prüfen, ob die betroffenen Blöcke mit einer Freelist verlinkt werden müssen oder nicht (vorausgesetzt die Blöcke sind nicht bereits auf einer Freelist). Eine Verknüpfung ist nur dann erforderlich, wenn der Block nicht bereits mit einer Freelist verlinkt ist und der freie
271
4 Speicherplatzverwaltung Platz größer als PCTUSED ist. Es ist zu beachten, dass PCTUSED für Indizes nicht spezifiziert werden kann, weil ein Indexblock nur dann mit einer Freelist verknüpft werden kann, wenn er leer ist. Praxistipp Die maximale Platzausnutzung lässt sich erzielen, wenn die Summe von PCTFREE und PCTUSED möglichst nahe bei 100 ist (die Summe kann 100 nicht überschreiten). Minimaler Aufwand bezüglich der Freelist-Verwaltung (Verknüpfungen von Blöcken erstellen und Verknüpfungen von Blöcken auflösen) lässt sich erreichen, indem die Summe von PCTFREE und PCTUSED möglichst klein gehalten wird (nahe bei 0). Dies bedeutet für die Konfiguration von PCTFREE und PCTUSED, dass man sich fragen muss, was wichtiger ist: maximale Platzausnützung in den Blöcken oder minimaler Verwaltungsaufwand für die Freelists. Generell ist es nicht möglich, beide Ziele gleichzeitig zu erreichen.
Standardmäßig hat ein Segment eine Freelist. Für Segmente, die sich selten ändern, ist das problemlos. In zwei Situationen kann jedoch eine einzelne Freelist zu PerformanceProblemen führen. Erstens, wenn gleichzeitig mehrere Prozesse Daten in dasselbe Segment einfügen, ist es wahrscheinlich, dass sie zur gleichen Zeit auf den genau gleichen Block in der Freelist zugreifen (Zur Erinnerung: die Freelist wird sequentiell mit einem LIFOAlgorithmus verwaltet). Dies kann zu Engpässen führen und Verzögerungen bei der Datenblockmodifikation zur Folge haben. Zweitens werden die Strukturen im Headerblock des Segments modifiziert – beispielsweise Verknüpfungen von Blöcken erstellen und Verknüpfungen von Blöcken auflösen – können ebenfalls Engpässe auftreten. Diese sind in v$waitstat protokolliert. Es stehen zwei Methoden zur Lösung solcher Probleme zur Verfügung. Die erste Situation wird vermieden, indem man die Anzahl Freelists erhöht (FREELIST > 1). Die zweite Situation lässt sich vermeiden, indem die Strukturen, die zur Freelist gehören, aus dem Headerblock des Segmentes in sogenannte „Freelist-Blöcke“ verschoben werden, indem das Attribut FREELIST GROUPS größer als 1 gewählt wird. Es ist dabei zu beachten, dass das Attribut FREELISTS die Anzahl Freelists in jedem FreelistBlock definiert. Existieren mehrere Freelists und/oder Freelist-Blöcke, weist die DatabaseEngine jeden Prozess einer spezifischen Freelist zu. Dies geschieht, durch einen HashAlgorithmus, der die Prozess-ID und – im Falle von Real Application Clusters – die Nummer der Instanz mit welcher der Prozess verbunden ist, als Parameter verwendet. Das folgende Beispiel zeigt, wie die Freelist-Parameter beim Erstellen einer Tabelle spezifiziert werden: SQL> 2 3 4 5 6 7
272
CREATE TABLE t (n NUMBER) PCTFREE 25 PCTUSED 25 STORAGE ( FREELISTS 4 FREELIST GROUPS 2 );
4.4 Segmentspace-Verwaltung Praxistipp Ein häufiges Missverständnis im Zusammenhang mit dem Attribut FREELIST GROUPS ist die Ansicht, dass dieses nur mit der Real-Application-Cluster-Option relevant ist. Aber das ist nicht korrekt, auch Single-Instanz-Datenbanken können von FREELIST GROUPS profitieren.
Folgende Einschränkungen betreffen die manuelle Freespace-Verwaltung:
Das Verkleinern von Segmenten (mit dem Befehl ALTER
TABLE SHRINK SPACE) mit dem Ziel, freien Platz unterhalb der High-Water Mark zu schaffen, ist nicht unterstützt.
Der Segment Advisor unterstützt Segmente mit manueller Freespace-Verwaltung nicht. 4.4.3
Automatische Segmentspace-Verwaltung
Wie im vorangehenden Abschnitt erläutert, sind im Zusammenhang mit der Segmentspace-Verwaltung zwei Situationen zu verhindern: konkurrierender Zugriff auf Datenblöcke und konkurrierender Zugriff auf Headerblöcke. Dieser Abschnitt zeigt, wie die automatische Segmentspace-Verwaltung sicherstellt, dass diese beiden Probleme nicht auftreten. Ein Segment mit automatischer Segmentspace-Verwaltung ist logisch in einer Baumstruktur organisiert, dessen Wurzel sich im Segmentheaderblock befindet. Die Verzweigungen sind durch Bitmapblöcke gebildet (es gibt zwei oder drei Ebenen). Am Ende der Baumstruktur befinden sich die Datenblöcke (leaf blocks). Abbildung 4.5 zeigt diese Struktur. Level-1Bitmap-Block Header
Extent 2
SegmentheaderBlock Header ExtentMap Level-3Map
Extent 1
Level-1Map Level-2Bitmap-Block Header Level-2Map
Extent 3 Extent 4
Level-1Bitmap-Block Header Level-1Map
Extent 5 Extent 6 Extent 7
Level-1Bitmap-Block Header
Extent 8
Level-1Map
Extent 10
Extent 9
Extent 11 Extent 12
Abbildung 4.5 Ein Segment mit automatischer SegmentspaceVerwaltung ist logisch in einer Baumstruktur organisiert
273
4 Speicherplatzverwaltung Der Segmentheaderblock referenziert in der Level-3-Map auf Level-2-Bitmap-Blöcke, die mit dem Segment verknüpft sind. In den meisten Fällen ist diese Struktur sehr klein und passt vollständig in den Segmentheaderblock. Reicht der Platz nicht aus, wird ein Teil der Level-3-Map in anderen Blöcken gespeichert. Diese zusätzlichen Blöcke heißen Level-3Bitmap-Blöcke (nicht erwähnt in Abbildung 4.5) und beinhalten nichts anderes, als Teile der Level-3-Map, die mit dem Segment verknüpft sind. Die Level-2-Bitmap-Blöcke referenzieren in der Level-2-Map auf Level-1-Bitmap-Blöcke, mit denen sie verknüpft sind. Passt die Level-2-Map nicht vollständig in einem Block, werden zusätzliche Blöcke der Baumstruktur zugefügt. Für jeden Level-1-Bitmap-Block sind in der Level-2-Map zwei Informationen gespeichert: Erstens über den verfügbaren freien Platz der mit der entsprechenden Level-2-Map verknüpften Datenblöcke. Die zweite Information ist nur relevant, wenn mehrere Instanzen auf die Datenbank zugreifen. Sie weist aus, welche Instanz zu diesem bestimmten Level-1-Bitmap-Block eine Affinität hat. Über diese Affinität versucht die Database-Engine den Austausch von Level-1-BitmapBlöcken zwischen den Instanzen zu minimieren. Der Level-1-Bitmap-Block referenziert in der Level-1-Map auf jedem Extent. Für jedes Extent sind darin auch detaillierte Informationen über den verfügbaren freien Platz in jedem Block vorhanden. Es ist zu beachten, dass alle Blöcke eines spezifischen Extents von einem einzigen Level-1-Bitmap-Block referenziert werden. Die maximale Anzahl Blöcke für einen Level-1-Bitmap-Block ist von der Segmentgröße abhängig:
16 für Segmente bis zu einer Größe von 1 MB 64 für Segmente bis zu einer Größe von 32 MB 256 für Segmente bis zu einer Größe von 1 GB 1024 für Segmente größer als 1 GB Um eine zu häufige Aktualisierung der Bitmap-Blöcke zu verhindern, ist die Information über den freien Platz in den Bitmap-Blöcken mit geringer Präzision gespeichert. Statt dessen sind folgende Stati möglich:
Der Block ist nicht formatiert. Der Block ist voll, oder er enthält Metadaten. Weniger als 25 Prozent des Blocks sind unbenutzt. Zwischen 25 Prozent (inklusiv) und 50 Prozent (exklusiv) des Blocks sind unbenutzt. Zwischen 50 Prozent (inklusiv) und 75 Prozent (exklusiv) des Blocks sind unbenutzt. Mindestens 75 Prozent des Blocks sind unbenutzt. Nachdem wir nun gesehen haben, wie ein Segment logisch strukturiert ist, betrachten wir jetzt, wie diese Datenstrukturen für die Verwaltung des freien Platzes zur Anwendung kommen. Ein Prozess, der Platz benötigt, um Daten in ein Segment einzufügen, durchläuft im Wesentlichen folgende Schritte:
274
4.4 Segmentspace-Verwaltung
Zugriff auf den Segmentheader und Adresse des zuletzt verwendeten Level-2 BitmapBlocks ermitteln.
Zugriff auf den Level-2-Bitmap-Block und Auswahl eines Level-1-Bitmap-Blocks, der Datenblöcke mit freiem Platz unterhalb der High-Water Mark referenziert. Ist kein solcher Block zu ermitteln, wird die High-Water Mark erhöht. Falls mehrere Level-1 Bitmap-Blöcke vorhanden sind, erfolgt die Auswahl aufgrund eines Hash-Algorithmus, der die Instanznummer und die Prozess-ID als Input verwendet. Das Ziel ist, konkurrierende Prozesse über mehrere Level-1-Bitmap-Blöcke zu verteilen.
Zugriff auf den Level-1-Bitmap-Block und Auswahl eines Datenblocks mit freiem Platz. Sind mehrere Blöcke verfügbar, erfolgt die Auswahl aufgrund eines Hash-Algorithmus, der die Prozess-ID als Input verwendet. Das Ziel ist, konkurrierende Prozesse über mehrere Datenblöcke zu verteilen.
Falls notwendig, wird die Freespace-Information im Bitmap-Block aktualisiert. Es ist zu beachten, dass der Block als gefüllt markiert wird, wenn der freie Platz kleiner als PCTFREE ist oder der Block für die Speicherung eines Index verwendet wird. Dies ist unabhängig davon, wie viel freier Platz im Block noch vorhanden ist. Beim Löschen von Daten aus einem Segment ist zu prüfen, ob die Freespace-Information im Bitmap-Block zu aktualisieren ist. Beinhaltet der modifizierte Block einen Index, ist eine Aktualisierung nur notwendig, wenn der Block leer ist. Beinhaltet der modifizierte Block eine Tabelle, hängt die Entscheidung vom Status des Blocks vor der Löschoperation ab. Falls der Block vor der Löschoperation nicht als gefüllt markiert wurde, ist ein Update nur dann erforderlich, wenn man eine der oben beschriebenen Schwellwerte überschreitet. Beispielsweise ist ein Update dann erforderlich, wenn der Freespace von 10 auf 40 Prozent (der Schwellwert von 25 Prozent wurde überschritten) reduziert wurde, jedoch nicht, wenn der Freespace lediglich von 10 auf 20 Prozent gesunken ist. Falls der Block vor der Löschoperation als gefüllt markiert war, ist ein Update nicht nur dann erforderlich, wenn einer der oben beschriebenen Schwellwerte überschritten wurde, sondern auch, wenn der überschrittene Schwellwert größer als PCTFREE ist. Beispielsweise ist ein Update dann erforderlich, wenn PCTFREE auf 30 Prozent gesetzt wurde und der Freespace von 10 auf 60 Prozent (der Schwellwert von 50 Prozent wurde überschritten) reduziert wurde, jedoch nicht, wenn der Schwellwert von 10 auf 40 Prozent (lediglich der Schwellwert von 25 Prozent wurde überschritten) gesunken ist. Es ist zu beachten, dass PCTUSED nicht relevant ist für Segmente mit automatischer Segmentspace-Verwaltung. Die folgenden Einschränkungen betreffen die automatische Segmentspace-Verwaltung:
Diese Verwaltungsoption wird nur für permanente, locally-managed Tablespaces unterstützt.
Diese Verwaltungsoption ist nicht für den SYSTEM-Tablespace unterstützt.
275
4 Speicherplatzverwaltung
4.4.4
Auswahl einer Segmentspace-Verwaltungsoption
Weil in bestimmten Situationen die manuelle Segmentspace-Verwaltung nur bei korrekter Konfiguration gut funktioniert, empfehlen wir, wenn immer möglich, die automatische Verwaltungsmethode zu verwenden. Mit anderen Worten: Verwenden Sie die automatische Methode für alle permanenten, lokal verwalteten Tablespaces (mit Ausnahme des SYSTEM-Tablespace). Diese Wahl verhindert nicht nur Contention-Probleme, sondern vereinfacht auch die Reorganisation, um beispielsweise freien Platz unterhalb der High-Water Mark zurückzugewinnen. Dies gilt auch für Datenbanken oder einzelne Tablespaces, für die die Vorteile der automatischen Segmentspace-Verwaltung nicht relevant sind. So ist es beispielsweise sehr unwahrscheinlich, dass Tablespaces, die nur Indizes enthalten, oder eine typische ETL-Ladeoperation, aufgrund der Platzverwaltung Contention-Probleme haben. Praxistipp Verwenden Sie die manuelle Segmentspace-Verwaltung nur, wenn dies eine Anforderung ist, oder genügend Informationen und Zeit für die sorgfältige Konfiguration vorhanden ist.
Die automatische Segmentspace-Verwaltung hat zwei Nachteile: Erstens den Platzbedarf für die möglicherweise hohe Anzahl Bitmap-Blöcke. Solche Blöcke machen nicht nur die Segmente größer (der zusätzliche Platzbedarf beträgt 0,1 Prozent für große Segmente und bis 25 Prozent für sehr kleine Segmente), sie benötigen auch Platz im Buffercache (normalerweise wird weniger als 0,5 Prozent des Buffercaches für Bitmap-Blöcke verwendet, aber es ist nicht ungewöhnlich, wenn 1 bis 5 Prozent des Buffercaches für diesen Zweck erforderlich sind). Zweitens ist die Platzverwendung gegenüber der manuellen Methode aufgrund der ungenaueren Granularität der Freespace-Informationen nicht sonderlich effizient.
4.5
Zusätzliche Segmentoptionen In diesem Abschnitt beschreiben wir zusätzliche Optionen, die auf Segmentebene möglich sind, im Speziellen die initiale Größe der Interested Transaction List und der Einsatz von Minimal Logging.
4.5.1
Interested Transaction List (ITL)
Jeder Datenblock beinhaltet eine Liste der aktiven Transaktionen auf diesem Block, die Interested Transaction List (ITL). Jeder Datensatz, der in eine Transaktion involviert ist, hat einen Pointer zur ITL. Einfach gesagt, wird dieser Pointer für das Locking auf Datensatzebene verwendet (siehe Abbildung 4.6). Jeder Eintrag in der ITL enthält neben anderen Informationen die Transaktions-ID und den Pointer zur Undo-Information dieser Transaktion.
276
4.5 Zusätzliche Segmentoptionen Header Interested Transaction List Slot 1
Abbildung 4.6 Die ITL enthält einige Slots, die für das Locking von modifizierten Datensätzen und für die Verknüpfung mit der entsprechenden Undo-Information verwendet werden. In der Abbildung hat die gleiche Transaktion Datensatz 1 und 4 geändert
Das Attribut INITRANS bestimmt die minimale Anzahl von Slots in der ITL. Auch wenn INITRANS auf 1 gesetzt sein kann, existieren immer mindestens zwei Slots. Vorausgesetzt, es ist genügend freier Platz vorhanden, lässt sich die Anzahl Slots bei Bedarf dynamisch erhöhen. Mit anderen Worten: Die Anzahl Slots steigt, wenn mehr aktive Transaktionen als Slots vorhanden sind. Ab 10g hängt die maximale Anzahl Slots von der Blockgröße ab und kann nicht mehr, wie in früheren Versionen, über den Parameter MAXTRANS spezifiziert werden. Praxistipp Es ist normalerweise besser, PCTFREE 1 bis 2 Prozent höher zu setzen, als einen hohen INITRANS-Wert zu definieren (jeder ITL-Slot benötigt 24 Bytes). Es gibt dafür zwei Gründe: Erstens kommt es nicht sehr häufig vor, dass viele Transaktionen gleichzeitig denselben Block modifizieren. Zweitens ist der von der ITL beanspruchte Platz bei Nichtgebrauch nicht für andere Zwecke wiederverwendbar.
Ist eine Transaktion nicht in der Lage, einen Slot zu erhalten oder einen neuen Slot zu kreieren (weil der benötigte freie Platz nicht verfügbar ist), muss sie warten, bis ein bestehender Slot freigegeben wird, sprich bis eine andere Transaktion ein Commit oder ein Rollback ausführt. Eine solche Situation nennt sich ITL-Wait. Es ist an dieser Stelle wichtig zu betonen, dass eine blockierte Session auf ein Shared Transaction Lock wartet. Deshalb kann man eine solche Situation mit der gleichen Methode untersuchen wie reguläre Lock-Contention. Die folgende Abfrage zeigt beispielsweise eine Session, die bereits zwölf Sekunden auf einen ITL-Slot gewartet hat. Beachten Sie, dass die Abfrage auch die den Lock verursachende Session (blocking session) zeigt: SQL> SELECT event, seconds_in_wait, blocking_session 2 FROM v$session 3 WHERE sid = 147; EVENT SECONDS_IN_WAIT BLOCKING_SESSION ---------------------------- --------------- ---------------enq: TX - allocate ITL entry 12 24
277
4 Speicherplatzverwaltung Folgende Abfrage zeigt an, auf welchen Segmenten seit dem letzten Start der Datenbank ITL-Waits aufgetreten sind und wie oft dies vorgekommen ist: SQL> 2 3 4
SELECT owner, object_name, value FROM v$segment_statistics WHERE statistic_name = 'ITL waits' AND value > 0;
Es gibt drei Möglichkeiten, ITL-Waits zu verhindern beziehungsweise zu minimieren:
Spezifizieren eines höheren INITRANS-Werts Verwendung eines höheren Werts für das PCTFREE-Attribut Verringerung der Anzahl gleichzeitiger Operationen auf einen einzelnen Datenblock. Treten ITL-Waits aufgrund von gleichzeitigen Updates auf, sollte man die Datendichte (Density) reduzieren (beispielsweise durch die Verwendung einer kleineren Blockgröße und einem höheren PCTFREE-Wert). Als Alternative kann auch eine andere Verteilung der Datensätze helfen (beispielsweise mittels Hash-Partitionierung). Treten ITLWaits aufgrund gleichzeitiger Inserts auf und werden die Segmente manuelle verwaltet, dann sollte man die Anzahl der Freelists erhöhen. Es ist zudem zu beachten, dass ITL-Waits zu ITL-Deadlocks führen können. Falls eine solche Situation auftritt, löst die Database-Engine typischerweise einen ORA-00060Fehler aus (deadlock detected while waiting for resource).
4.5.2
Minimal Logging
Das Ziel von Minimal Logging ist die Minimierung der Redo-Erzeugung. Dies ist zwar eine optionale Einstellung, verbessert aber für bestimmte Operationen die Antwortzeit oft stark. Das Setzen des NOLOGGING-Attributs auf Segmentebene weist die Datenbank an, Minimal Logging zu verwenden. Es ist wichtig zu verstehen, dass Minimal Logging nur für Direct-Path Inserts und für bestimmte DDL-Anweisungen (beispielsweise CREATE INDEX, oder CREATE TABLE AS SELECT) unterstützt wird. Für alle anderen Operationen wird weiterhin die Redo-Information generiert. Das folgende Beispiel zeigt die Auswirkung von Minimal Logging für eine ALTER TABLE MOVE-Operation. Es ist zu beachten, dass die im Beispiel verwendete Tabelle ca. 1 MB
Daten enthält und eine Move-Operation deshalb auch zu etwa 1 MB Redo-Information führen sollte. Wie das Beispiel zeigt, wird mit Minimal Logging wesentlich weniger RedoInformation generiert als mit normalem Logging: SQL> ALTER TABLE t NOLOGGING; SQL> SELECT value 2 FROM v$mystat NATURAL JOIN v$statname 3 WHERE name = 'redo size'; VALUE ---------6152 SQL> ALTER TABLE t MOVE;
278
4.5 Zusätzliche Segmentoptionen
SQL> SELECT value 2 FROM v$mystat NATURAL JOIN v$statname 3 WHERE name = 'redo size'; VALUE ---------58764 SQL> ALTER TABLE t LOGGING; SQL> ALTER TABLE t MOVE; SQL> SELECT value 2 FROM v$mystat NATURAL JOIN v$statname 3 WHERE name = 'redo size'; VALUE ---------1291940
Praxistipp Wir empfehlen, Minimal Logging nur dann zu verwenden, wenn die resultierenden Auswirkungen vollständig klar sind. So lassen sich beispielsweise Datenblöcke, die man mit Minimal Logging modifiziert hat, nicht mittels Media-Recovery wiederherstellen. Dies bedeutet, dass die DatabaseEngine nach einem Media-Recovery diese Blöcke lediglich als „logical corrupted“ bezeichnen kann, weil das Media-Recovery für die Rekonstruktion des Blockinhalts Zugriff auf die entsprechende Redo-Information benötigt. Dies führt dazu, dass SQL-Anweisungen, die auf Objekte mit solchen Blöcken zugreifen, mit einem ORA-26040-Fehler (Data block was loaded using the NOLOGGING option) abbrechen. Deshalb sollte man Minimal Logging nur dann verwenden, wenn die Daten manuell wieder geladen werden können oder wenn unmittelbar nach der Ladeoperation ein Backup erfolgt.
Folgende Besonderheiten betreffen den Einsatz von Minimal Logging:
Es ist möglich, auf Datenbank- oder Tablespace-Ebene FORCE
LOGGING zu aktivieren und damit die Einstellungen auf Segmentebene zu übersteuern. Dies ist speziell für Standby-Datenbanken und Streams nützlich. In der Tat funktionieren diese beiden Optionen nur dann erfolgreich, wenn die Redolog-Files Informationen von allen Modifikationen enthalten.
Minimal Logging wird für Segmente, die in temporären Tablespace mit Tempfiles abgelegt sind, immer genutzt.
Minimal Logging kommt für Datenbanken, die im
NOARCHIVELOG-Mode betrieben
werden, immer vor.
279
4 Speicherplatzverwaltung
4.6
Reorganisationen Es gibt drei Gründe, um ein Segment zu reorganisieren:
Man will das Segment in einen anderen Tablespace verschieben. Man will den freien Platz unterhalb der High-Water Mark zurückgewinnen. Im Allgemeinen wird der freie Platz von der Database-Engine automatisch wiederverwendet und eine Reorganisation sollte nicht notwendig sein. Ausnahme, wenn viele Datensätze gelöscht werden (es kann dabei lange dauern, bis der freie Platz wiederverwendet wird), oder wenn man neue Datensätze mittels Direct-Inserts einfügt.
Man will migrierte oder verkettete Datensätze eliminieren. Bevor wir die verschiedenen Reorganisationsmethoden beschreiben, ist es sinnvoll, den Unterschied zwischen Datensatzmigration (row migration) und Datensatzverkettung (row chaining) zu betrachten.
4.6.1
Datensatzmigration und Datensatzverkettung
Datensatzmigration und Datensatzverkettung wird oft verwechselt. Dies hat aus unserer Sicht zwei Hauptgründe: Erstens lassen sich die beiden Situationen leicht verwechseln, weil sie bestimmte gemeinsame Eigenschaften aufweisen. Zweitens wurden die beiden Begriffe in der Oracle-Dokumentation und -Implementation nie sehr konsistent unterschieden. Beim Einfügen von Datensätzen in einen Block reserviert die Database-Engine freien Platz für zukünftige Updates. Wie in diesem Kapitel bereits beschrieben, wird der für Updates reservierte Platz über das Attribut PCTFREE festgelegt. Abbildung 4.7 zeigt, dass ein Block, dessen Füllgrad PCTFREE erreicht hat, für Inserts nicht mehr zur Verfügung steht. Header
Abbildung 4.7 Bei Inserts wird im Datenblock Platz (PCTFREE) für zukünftige Updates freigehalten.
4.6 Reorganisationen Wird ein Datensatz aktualisiert und beansprucht dadurch mehr Platz, sucht die DatabaseEngine freien Platz im gleichen Block. Ist zu wenig Platz vorhanden, teilt sie den Datensatz in zwei Teile auf. Der erste Teil (der lediglich Kontrollinformationen wie die Row-Id zum zweiten Teil enthält) verbleibt im Originalblock. Damit wird eine Änderung der RowId verhindert, denn dies darf auf keinen Fall vorkommen, weil die Row-Id nicht nur in den Indizes permanent gespeichert wird, sondern auch temporär im Memory. Der zweite Teil, der die Daten enthält, wird in einem anderen Block abgelegt. Bei dem geänderten Datensatz spricht man von einem migrierten Datensatz. In Abbildung 4.8 sieht man beispielsweise, dass Datensatz Nummer 4 in einen zweiten Block migriert wurde. Header
Header
Datensatz 6 Datensatz 5
Teil 1 Datensatz 4 Datensatz 3 Datensatz 2 Datensatz 1
Teil 2 Datensatz 4
Abbildung 4.8 Ein aktualisierter Datensatz, der keinen Platz mehr im Originalblock findet, wird in einen anderen Block migriert (Datensatzmigration)
Passt ein Datensatz aufgrund seiner Größe nicht in einen einzelnen Datenblock, wird er ebenfalls in zwei, oder mehrere Stücke aufgeteilt. Dann ist jedes Stück in einem separaten Block gespeichert und es wird eine Verknüpfung beziehungsweise Verkettung zwischen den einzelnen Teilen gebildet. Einen solchermaßen geänderten Datensatz bezeichnet man als verketteten Datensatz (Chained Row). Abbildung 4.9 (nächste Seite) zeigt, wie ein Datensatz über drei Blöcke hinweg verkettet ist. Tabellen mit vielen Attributen können ebenfalls zu Datensatzverkettung führen, weil die Database-Engine nicht in der Lage ist, mehr als 255 Spalten pro Datensatz-Teil zu speichern. Konsequenterweise muss ein solcher Datensatz in mehrere Stücke aufgeteilt sein. Diese Situation ist insbesondere dann speziell, wenn die Stücke, die zum gleichen Datensatz gehören, im selben Block gespeichert werden. Dies nennt sich dann „Intra-Block Chaining“. Datenaktualisierung verursacht Datensatzmigration, während Datensatzverkettung entweder durch Einfügen oder durch Datenaktualisierung entsteht. Ist Datenaktualisierung die Ursache für Datensatzverkettung, werden die Datensätze gleichzeitig migriert und verkettet.
281
4 Speicherplatzverwaltung Header
Header
Teil 1 Datensatz 7
Teil 2 Datensatz 7
Header
Teil 3 Datensatz 7
Abbildung 4.9 Ein verketteter Datensatz ist über zwei oder mehrere Blöcke verteilt
Der Performance-Einfluss von Datensatzmigration ist vom Zugriffspfad auf die Datensätze abhängig. Erfolgt der Zugriff via RowId verdoppelt sich der Ressourcenbedarf, weil der Zugriff auf beide Teile des Datensatzes separat erfolgt. Andererseits gibt es keinen Nachteil, wenn der Zugriff über einen Full-Scan erfolgt, weil der erste Teil des Datensatzes, der keine Daten enthält, einfach übersprungen wird. Der Einfluss von Datensatzverkettung auf die Performance ist unabhängig vom Zugriffspfad. Jedes Mal, wenn der erste Teil eines Datensatzes gefunden wird, müssen alle anderen Teile über die RowId gelesen werden. Es gibt eine Ausnahme: Ist nur ein Teil des Datensatzes erforderlich, müssen nicht alle Teile gelesen werden. Werden beispielsweise nur Attribute aus dem ersten Teilstück benötigt, braucht man die anderen Teile des Datensatzes nicht zu lesen. Es gibt zwei wichtige Methoden, um Datensatzmigration und Datensatzverkettung zu identifizieren. Die erste basiert auf den beiden Views V$SYSSTAT und V$SESSTAT, die Hinweise auf Datensatzmigration und Datensatzverkettung in der Datenbank beinhalten. Die Idee dahinter ist, die Systemstatistik „table fetch continued row” zu prüfen, um die Anzahl Zugriffe auf Datensätze mit mehr als einem Stück (inkl. Intra-Block Chained Rows) auszuweisen. Die relative Auswirkung von Datensatzverkettung und Datensatzmigration lässt sich auch mit dem Vergleich der beiden Statistiken „table scan rows gotten” und „table fetch by rowid” beurteilen. Im Gegensatz dazu erhält man mit der zweiten Methode exakte Informationen über die migrierten und die verkettete Datensätze. Dies bedingt jedoch die vorgängige Analyse jeder Tabelle, die unter Verdacht steht, verkettete oder migrierte Datensätze zu enthalten, mit der SQL-Anweisung ANALYZE TABLE LIST CHAINED ROWS. Die RowId für verkettete oder migrierte Rows ist in der Tabelle CHAINED_ROWS eingetragen. Wie die folgende Abfrage zeigt, kann man danach, basierend auf den Row-Ids, die Größe der Datensätze und daraus – durch Vergleich mit der Blockgröße – Datensatzmigration oder Datensatzverkettung erkennen:
Praxistipp Das Attribut CHAIN_CNT der DBA_TABLES-View sollte die Anzahl verkettete und migrierte Rows beinhalten. Leider ermittelt das DBMS_STATS-Package diese Statistik nicht. Der Wert ist einfach auf „0“ gesetzt. Demnach ist die Ausführung des SQL-Befehls ANALYZE TABLE COMPUTE STATISTICS der einzige Weg, korrekte Statistikwerte zu berechnen. Dies führt allerdings zu einem unerwünschten Nebeneffekt, da hinterher die Objektstatistiken der analysierten Tabellen überschrieben sind.
Die Maßnahmen für die Verhinderung von Datensatzmigration und Datensatzverkettung unterscheiden sich grundsätzlich. Es ist deshalb auch zu unterscheiden, ob Probleme durch Datensatzmigration oder durch Datensatzverkettung entstanden sind. Das Verhindern von Datensatzmigration ist lediglich eine Frage der korrekten PCTFREEEinstellung. Mit anderen Worten: Bei einer ausreichenden Platzreservierung findet ein modifizierter Datensatz vollständig im Originalblock Platz. Stellen Sie also Datensatzmigration fest, sollten Sie den aktuellen PCTFREE-Wert erhöhen. Für die Wahl eines geeigneten PCTFREE-Werts ist das durchschnittliche Datensatzwachstum abzuschätzen. Dies gelingt am besten, wenn Sie die durchschnittliche Datensatzgröße vergleichen, unmittelbar nach dem Einfügen und nachdem keine Änderung mehr erfolgt. Die Verhinderung von Datensatzverkettung ist schwieriger. Die offensichtlichste Maßnahme ist die Verwendung von größeren Datenbankblöcken. Doch manchmal ist selbst die größtmögliche Blockgröße nicht ausreichend. Tritt Datensatzverkettung aufgrund von mehr als 255 Attributen auf, kann nur ein Re-Design der Tabelle Abhilfe schaffen. Deshalb ist die einzige wirksame Maßnahme in dieser Situation, die weniger oft verwendeten Spalten am Ende der Tabelle zu platzieren und somit den gleichzeitigen und übergreifenden Zugriff auf alle Teile des Datensatzes zu verhindern.
4.6.2
Verschieben von Segmenten
Die Idee dieser Methode ist das vollständige Verschieben eines Segments von der aktuellen Lokation in eine andere. Daher ist diese Methode für die Verschiebung eines Segments in einen anderen Tablespace, für die Freigabe von freiem Platz unterhalb der High-Water Mark oder für die Eliminierung von migrierten Rows möglich. Mit dem Verschieben des Segments in einen Tablespace mit größerer Blockgröße lässt sich auch Datensatzverkettung eliminieren. Der Segmenttyp bestimmt die SQL-Anweisung, die für die Verschiebung Anwendung findet. Die folgenden Beispiele zeigen einige gebräuchliche SQL-Anweisungen;
Tabellensegment (inklusiv Segmente von Index-Organized Tabellen) verschieben: SQL> ALTER TABLE t MOVE TABLESPACE users;
283
4 Speicherplatzverwaltung
Table-Partition-Segment (inklusiv Segmente von partitionierten, Index-Organized Tabellen) verschieben (P1 ist der Name der Partition): SQL> ALTER TABLE t MOVE PARTITION p1 TABLESPACE users;
Indexsegment verschieben: SQL> ALTER INDEX i REBUILD TABLESPACE users;
Index-Partition-Segment verschieben (P1 ist der Name der Partition): SQL> ALTER INDEX i REBUILD PARTITION p1 TABLESPACE users;
LOB-Segment verschieben (B ist der Name der LOB): SQL> ALTER TABLE t MOVE LOB (b) STORE AS (TABLESPACE users);
Alle Beispiele bedingen exklusiven Zugriff auf das zu reorganisierende Segment. Es gibt nur einen Segmenttyp, der eine Online-Reorganisation direkt unterstützt, Indexsegmente (inklusiv Segmente von Index-Organized-Tabellen). Eine solche Online-Reorganisation (Oracle Enterprise Edition erforderlich) muss mit dem Schlüsselwort ONLINE ausgeführt werden, wie das folgende Beispiel zeigt: SQL> ALTER INDEX i REBUILD ONLINE TABLESPACE users;
Ist eine Online-Reorganisation für einen anderen Segmenttyp notwendig, bietet sich das DBMS_REDEFINITION-Package an, obwohl der Hauptzweck dieses Package in der Änderung von Tabellenstrukturen liegt.
4.6.3
Verschieben von Tabelleninhalten
Besteht das Reorganisationsziel darin, Datensatzmigration zu eliminieren, ist die vollständige Reorganisation, wie sie im vorangehenden Abschnitt beschrieben wurde, nicht in jedem Fall die beste Lösung. Insbesondere wenn das Segment groß und die Zahl der migrierten Datensätze relativ klein sind (einige Prozent). In einer solchen Situation ist es eventuell sinnvoller, nur die migrierten Rows zu verschieben. Diese Methode funktioniert jedoch nicht zur Beseitigung von Datensatzverkettung. Die folgende Beschreibung zeigt, wie man die migrierten Datensätze einer Tabelle T verschiebt;
Lokalisieren der migrierten Rows (Dieser Schritt lokalisiert eigentlich migrierte und verkettete Datensätze). Beachten Sie, dass dieser Schritt weder exklusiven Zugriff auf die zu analysierende Tabelle bedingt, noch Wartezeit auf offene Transaktionen verursacht: SQL> @?/rdbms/admin/utlchain.sql SQL> ANALYZE TABLE t LIST CHAINED ROWS;
Erzeugen einer Scratch-Tabelle, die die gleiche Struktur aufweist wie die zu reorganisierende Tabelle: SQL> 2 3 4
284
CREATE TABLE t_scratch AS SELECT * FROM t WHERE 1 = 0;
4.6 Reorganisationen
Sperren der migrierten (und verketteten) Rows. Dieser Schritt ist nur dann notwendig, wenn man die Reorganisation ohne exklusiven Zugriff auf die zu reorganisierende Tabelle durchführt: SQL> 2 3 4
SELECT * FROM t WHERE rowid IN (SELECT head_rowid FROM chained_rows) FOR UPDATE;
Eintragen (Insert) der migrierten (und verketteten) Rows in die Scratch-Tabelle: SQL> 2 3 4
INSERT INTO t_scratch SELECT * FROM t WHERE rowid IN (SELECT head_rowid FROM chained_rows);
Löschen der migrierten (und verketteten) Rows aus der Originaltabelle: SQL> DELETE t 2 WHERE rowid IN (SELECT head_rowid FROM chained_rows);
Wiedereinfügen der migrierten (und verketteten) Rows in die Originaltabelle: SQL> INSERT INTO t 2 SELECT * FROM t_scratch;
Committen der Änderungen: SQL> COMMIT;
Löschen der Scratch-Tabelle: SQL> DROP TABLE t_scratch PURGE;
Soll die Reorganisation online erfolgen und sind viele Datensätze zu verschieben, kann die Verarbeitung auch Mengenweise (beispielsweise 1000 Datensätze auf einmal) geschehen. Damit erfolgen anstelle einer einzigen langen Transaktion einige kleine Transaktionen. Weil Datensätze bei dieser Reorganisationsmethode gelöscht und eingefügt werden, erfordern Trigger und Fremdschlüssel auf die zu reorganisierenden Tabellen spezielle Aufmerksamkeit. Existieren solche Objekte, ist ein exklusiver Zugriff auf die betroffenen Tabellen und die Deaktivierung von Triggern und Fremdschlüssel erforderlich.
4.6.4
Rückgewinnung von freiem Platz
Für die Rückgewinnung von freiem Platz unterhalb der High-Water Mark ist die vollständige Verschiebung des Segmentes in eine andere Lokation nicht zwingend notwendig. Vor allem in zwei Situationen möchte man dies verhindern. Erstens, wenn der freie Platz im Verhältnis zur Segmentgröße sehr klein ist, und zweitens, wenn nicht genügend Platz vorhanden ist, um das Segment zweifach zu speichern. Ist das zu reorganisierende Segment mit einem Index verbunden, kann man die COALESCEKlausel im ALTER INDEX-Befehl verwenden. Beachten Sie, dass diese Methode die HighWater Mark nicht verringert. Sie fügt hingegen den Inhalt der benachbarten Indexblöcke zusammen und löst die Verkettung der freien Blöcke von den Indexstrukturen. Beachten Sie zudem, dass kein exklusiver Zugriff auf den zu reorganisierenden Index notwendig ist.
285
4 Speicherplatzverwaltung Im folgenden Beispiel zeigen wir, wie der Befehl auf einen nicht-partitionierten Index angewendet wird. Für einen partitionierten Index sollte zusätzlich die PARTITION-Klausel spezifiziert sein. SQL> ALTER INDEX i COALESCE;
Ist das zu reorganisierende Segment mit einer Tabelle verbunden, ist die SHRINK-Klausel im ALTER TABLE-Befehl möglich. Das Ziel dieser Segment-Shrink-Methode ist, so viele Datensätze wie möglich am Anfang des Segmentes zu speichern. Zu diesem Zweck werden die Datensätze verschoben und erhalten damit eine neue Row-ID. Beachten Sie zudem, dass kein exklusiver Zugriff auf das zu reorganisierenden Segment notwendig ist. Voraussetzung ist jedoch die vorgängige Aktivierung von Row-Movement, wie das folgende Beispiel zeigt: SQL> ALTER TABLE t ENABLE ROW MOVEMENT; SQL> ALTER TABLE t SHRINK SPACE;
Standardmäßig sind mit Segment-Shrink die Datensätze nicht nur am Anfang des Segments gespeichert, sondern es werden auch die High-Water Mark verringert und die meisten freien Blöcke unterhalb der High-Water Mark freigegeben. Ist die Verringerung der High-Water Mark nicht erforderlich, kann man auch die COMPACT-Klausel verwenden: SQL> ALTER TABLE t SHRINK SPACE COMPACT;
Eine weitere Option, die während der Shrink-Operation spezifiziert werden kann, ist CASCADE. Damit werden nicht nur die Tabelle, sondern auch alle abhängigen Segmente wie
Indexe und LOBs verarbeitet. Zudem kann man auch eine einzelne Partition, oder nur ein abhängiges Segment verarbeiten, wie das folgende Beispiel zeigt;
Shrink einer einzelnen Partition (P1 ist der Name der Partition): SQL> ALTER TABLE t MODIFY PARTITION p1 SHRINK SPACE;
Shrink eines LOB-Segmentes (B ist der Name des LOB): SQL> ALTER TABLE t MODIFY LOB (b) (SHRINK SPACE);
In folgenden Fällen wird Segment-Shrink nicht unterstützt:
Für Tabellen mit manueller Segmentspace-Verwaltung (also für Tabellen, die nicht in einem ASSM-Tablespace gespeichert sind)
Für Tabellen mit Function-Based-Indizes, Domain-Indizes, oder Bitmap-Join-Indizes Für komprimierte Tabellen Für Tabellen mit LONG-Attributen Für Tabellen-Cluster
286
4.7 Resümee
4.7
Resümee In diesem Kapitel haben wir beschrieben, wie Oracle die Daten auf logischer und physischer Ebene speichert und verwaltet. Für diesen Zweck haben wir nicht nur die Möglichkeiten aufgezeigt, die uns die Datenbank-Engine zur Verfügung stellt, sondern auch die Eigenschaften beschrieben, die man von einem Speichersubsystem erwarten darf. Weil beinahe auf jeder Ebene mehrere Optionen für die gleiche Aufgabe existieren, legen wir ein spezielles Augenmerk auf die richtige, sprich situationsgerechte Auswahl. Wir haben zudem aufgezeigt, welche Reorganisationsmethoden angewendet werden können, wenn die Daten nicht optimal gespeichert sind.
287
4 Speicherplatzverwaltung
288
5 5 Automatic Storage Management In diesem Kapitel finden Sie folgende Themen:
die Architektur von Automatic Storage Management; Einrichten einer Testumgebung für ASM; ASM mit dem ASMCA und Enterprise Manager verwalten; Diskgruppen und Fehlergruppen bearbeiten; das Kommandozeilen-Utility ASMCMD; eine Datenbank nach ASM konvertieren; das Cluster-Dateisystem ACFS. Oracle Automatic Storage Management (ASM) ist ein vergleichsweise junges Produkt. Es ist erstmalig mit der Version 10g erschienen. Die Entwicklung eines eigenen Volume Managers war zu diesem Zeitpunkt konsequent, um mit der Oracle Cluster-Datenbank nicht mehr von Produkten anderer Hersteller abhängig zu sein oder alternativ mit Raw Devices arbeiten zu müssen. Die Tatsache, dass ASM permanent weiter entwickelt wurde, führte zu einer zunehmenden Verbreitung auch unter Single-Instance-Datenbanken. Neben seiner hohen Zuverlässigkeit zeichnet sich ASM durch eine sehr gute Performance aus, die nahe an die Werte von Raw Devices herankommt. Dies wurde durch einen geringen Overhead sowie eine Fokussierung auf die Anforderungen der Oracle-Datenbank erreicht. Inzwischen verfügt das Produkt über eine Reihe Datenbank-spezifischer Features, die andere Volume Manager nicht aufweisen. Mit der Version 11g R2 ist es nun auch möglich, Dateien in ASM zu speichern, die nicht zur Datenbank gehören.
5.1
Die ASM-Architektur im Überblick Die Oracle-Datenbank benötigt für das Speichern der Datafiles, Online-Redo-Log-Dateien oder Kontrolldateien keine besondere Struktur. Dies wird durch die Tatsache unterstrichen, dass eine Speicherung direkt auf Raw Devices erfolgen kann. Mit anderen Worten, die Datenbank bringt alle Strukturen für die Verwaltung der Dateien selbst mit und ist darüber
289
5 Automatic Storage Management hinaus in der Lage, die Schreibzugriffe paralleler Prozesse, zum Beispiel die des Database Writer, selbst zu serialisieren. Diesem Umstand macht sich ASM zu Nutze und beschränkt sich auf eine Verwaltung von Extents und Segmenten. Im Vergleich zur Speicherung der Datenbank-Dateien auf Dateisystemen wie JFS oder NTFS, die auf Blockebene arbeiten, weist ASM dadurch eine bessere I/OPerformance aus. Das Speichern der Dateien erfolgt in ASM-Diskgruppen, die sich aus einer oder mehreren ASM-Disks zusammensetzen. ASM-Disks können dynamisch zur Diskgruppe hinzugefügt oder aus ihr heraus genommen werden, ohne dass die zugreifenden Datenbanken herunter gefahren werden müssen. ASM stellt Striping- und Mirroring-Funktionalität zur Verfügung. Intern werden die Dateien im OMF-Format (Oracle Managed Files) gespeichert, wobei die Verwendung von Aliasen möglich ist. Ab Version 11g R2 steht das ClusterDateisystem ACFS zur Verfügung, in dem auch Dateien gespeichert werden können, die nicht zur Oracle-Datenbank gehören. Für den Betrieb von ASM-Disks ist eine ASM-Instanz erforderlich. Diese und die zugehörigen Diskgruppen können von mehreren Datenbanken genutzt werden. Für RAC-Datenbanken können ASM-Instanzen hochverfügbar als Cluster-Instanzen aufgesetzt sein. Eine Diskgruppe erstreckt sich über eine oder mehrere ASM-Disks und enthält die erforderlichen Metadaten. Eine Datei wird stets komplett in einer Diskgruppe gespeichert. Die Datenintegrität wird durch Spiegelung, in der ASM-Terminologie als „Redundanz“ bezeichnet, gewährleistet. Es existieren drei Redundanz-Arten:
Normal Redundancy: Einfache Spiegelung High Redundancy: Doppelte Spiegelung External Redundancy: keine Spiegelung Für Diskgruppen mit „Normal Redundancy“ und „High Redundancy“ können Fehlergruppen definiert werden. Eine Fehlergruppe ist eine Untermenge von Disks einer Diskgruppe, die ausfallen kann, ohne dass es zum Verlust von Daten kommt. ASM legt Fehlergruppen automatisch fest, wenn Sie keine definieren. Praxistipp Definieren Sie Fehlergruppen beim Erstellen einer Diskgruppe, da die automatische Zuteilung durch ASM nicht zwangsläufig die reale Hardware-Situation widerspiegelt. Wenn zum Beispiel eine Diskgruppe aus Disks besteht, die dediziert über zwei Controller angesprochen werden, dann sollten die Disks eines Controllers jeweils zu einer Fehlergruppe gehören. Das Thema verliert an Bedeutung, wenn Sie mit Multipathing arbeiten. Auf die Einsatzmöglichkeiten von Multipathing gehen wir im weiteren Verlauf des Kapitels noch ein.
Physikalisch besteht eine ASM-Disk aus Extents. Ein Extent setzt sich aus einer oder mehreren Allocation Units (AU) zusammen. Die Größe einer Allocation Unit kann im Bereich von 1 bis 64 MByte liegen. Die Standardgröße von 1 MByte ist für die Masse der Datenbanken optimal. Für größere Datenbanken, insbesondere im Data-Warehouse-Umfeld, kann es sinnvoll sein, eine höhere AU-Größe zu wählen.
290
5.2 Eine ASM-Umgebung konfigurieren Bei der ASM-Instanz handelt es sich um einen speziellen Instanz-Typ, der sich in seiner Funktionalität wesentlich von einer RDBMS-Instanz unterscheidet. Die Festlegung des Instanz-Typs erfolgt durch den Init-Parameter instance_type, der standardmäßig mit dem Wert „RDBMS“ vorbesetzt ist. Für eine ASM-Instanz ist damit der folgende Eintrag im SPFile zwingend: *.instance_type=ASM
Der Name einer ASM-Instanz ist fest vorgegeben und kann nicht verändert werden. Er lautet +ASM für eine Single-Instance-Datenbank und +ASMn für eine Cluster-Datenbank, wobei „n“ die Nummer der Cluster-Instanz ist.
5.2
Eine ASM-Umgebung konfigurieren 5.2.1
Die Software bereitstellen
Seit Oracle 11g R2 ist die ASM-Software Bestandteil der Komponente „Grid Infrastructure“ und nicht mehr wie früher, Bestandteil der Datenbank. Für die Installation einer RealApplication-Clusters-Datenbank ist die Installation der Grid Infrastructure fester Bestandteil des Installationsprozesses. Damit ist bereits die komplette Software für den Einsatz von ASM installiert. Wenn Sie eine Single Instance-Datenbank aufsetzen, dann installieren Sie normalerweise nur die Datenbank-Software. Wollen Sie ASM für das Speichern der Datenbank einsetzen, müssen Sie zusätzlich die Grid-Infrastructure-Software installieren. Praxistipp Wählen Sie während der Installation der Grid-Infrastructure-Software die Option „Nur Grid Infrastructure Software installieren“. Damit erfolgt nur die Installation der Software und es wird auf eine Konfiguration der Grid Infrastructure, wie zum Beispiel der Definition der Datenbank als Ressource der Steuerungssoftware, verzichtet. Es erfolgt keine Integration der Datenbank in die Grid Infrastructure, wie man das beispielsweise für das Erstellen eines Clusters mit einem Knoten (RAC One Node) machen würde. Die Installation der Grid Infrastructure-Software muss in ein eigenes Oracle-Home-Verzeichnis erfolgen.
Vergessen Sie nicht am Ende der Installation die High-Availabilty-Dienste (HA-Dienste) zu starten. So wie in früheren Versionen die CRS-Dienste laufen mussten, um ASM benutzen zu können, müssen ab der Version 11g R2 die HA-Dienste aktiviert sein. # $GRID_HOME/perl/bin/perl -I/$GRID_HOME/perl/lib -I/$GRID_HOME/crs/install $GRID_HOME/crs/install/roothas.pl 2009-11-13 15:00:03: Checking for super user privileges 2009-11-13 15:00:03: User has super user privileges 2009-11-13 15:00:03: Parsing the hostname Using configuration parameter file: /app/oracle/product/11.2.0/grid/crs/istall/crsconfig_params Creating trace directory LOCAL ADD NODE Creating OCR keys for user 'oracle', privgrp 'dba'... Operation successful.
291
5 Automatic Storage Management CRS-4664: Node localhost successfully pinned. Adding daemon to inittab CRS-4123: Oracle High Availability Services has been started. ohasd is starting localhost 2009/11/13 15:01:11 /app/oracle/product/11.2.0/grid/cdata/localhost/backup_20091113_150111.olr Successfully configured Oracle Grid Infrastructure for a Standalone Server
Praxistipp Wenn Sie auf einem Windows-Betriebssystem arbeiten, dann ist ein Dienst mit dem Namen „OracleOHService“ eingerichtet. Stellen Sie sicher, dass er beim Neustart des Betriebssystems automatisch gestartet wird.
Mit dem folgenden Befehl können Sie prüfen, ob die HA-Dienste auf dem Server gestartet sind: # $GRID_HOME/bin/crsctl check has CRS-4638: Oracle High Availability Services is online
Jetzt müssen Sie nur noch den CSS-Daemon starten. Im CSS-Daemon ist unter anderem die Funktionalität von ASM enthalten. # ./crsctl start resource –all . . . CRS-2676: Start of 'ora.cssd' on 'localhost' succeeded # ./crsctl check css CRS-4529: Cluster Synchronization Services is online
Damit ist die Software für den Einsatz von ASM installiert und gestartet. Die Konfiguration und die Verwaltung einer ASM-Umgebung kann mit folgenden Werkzeugen erfolgen:
ASM Configuration Assistant (ASMCA) Database Configuration Assistant (DBCA) Oracle Enterprise Manager Manuell mit Kommandozeilen-Utilities (SQL*Plus, ASMCMD) Um etwas hinter die Kulissen von ASM zu schauen, führen wir zuerst eine manuelle Konfiguration durch.
5.2.2
Manuelle ASM-Konfiguration
Wie sie bereits wissen, ist eine laufende ASM-Instanz die erste Voraussetzung für den Betrieb von ASM. Zum Starten dieser ASM-Instanz muss eine minimale Anzahl von Init-Parametern vorgegeben werden. Erstellen Sie eine Parameterdatei mit dem Namen init+ASM.ora im Verzeichnis $GRID_HOME/dbs (%GRID_HOME%\database unter Windows). Das Verzeichnis $GRID_HOME ist das Oracle-Home-Verzeichnis der Grid-InfrastructureSoftware. Tragen Sie die folgenden Parameter ein: *.instance_type=ASM *.processes=100 *.asm_diskstring='' *.remote_login_passwordfile='shared'
292
5.2 Eine ASM-Umgebung konfigurieren Der Pfad zu den ASM-Disks sollte alle Disks einschließen, die für ASM benutzt werden sollen. Sie können die üblichen Wildcards verwenden, zum Beispiel /opt/asmdisks/asm*. So wie die Datenbank-Instanz, benötigt die ASM-Instanz eine Passwortdatei. Diese können Sie wie gewohnt mit dem Utility orapwd im Verzeichnis $ORACLE_HOME/dbs anlegen: orapwd file=orapw+ASM password=manager
Jetzt kann die ASM-Instanz gestartet werden. Praxistipp Wenn Sie auf einem Windows-Betriebssystem arbeiten, dann müssen Sie mit dem Utility oradim den Windows-Dienst erstellen, bevor Sie die Instanz starten können: C:\Windows\system32>oradim -new -asmsid +ASM -syspwd manager -startmode manual -shutmode immediate Instanz erstellt C:\Windows\system32>oradim -edit -asmsid +ASM -startmode a
Setzen Sie die Umgebung für die Instanz mit dem Namen „+ASM“ und das Oracle HomeVerzeichnis auf das der Grid Infrastructure und starten Sie die ASM-Instanz. Melden Sie sich dabei nicht als sysdba, sondern als sysasm in SQL*Plus an. Dies ist notwendig aufgrund der neuen Rollentrennung in der Version 11g R2, auf die wir im weiteren Verlauf des Kapitels noch eingehen werden. $ sqlplus / as sysasm SQL*Plus: Release 11.2.0.1.0 Production on Di Aug 3 12:11:58 2010 Copyright (c) 1982, 2010, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ASM instance started Total System Global Area 283930624 bytes Fixed Size 2175048 bytes Variable Size 256589752 bytes ASM Cache 25165824 bytes ORA-15110: no diskgroups mounted
Die Fehlermeldung haben wir erwartet, da schließlich noch keine Diskgruppen definiert sind. Praxistipp Sollten Sie an dieser Stelle auf den folgenden Fehler stoßen, dann haben Sie vergessen, die HA-Dienste zu starten bzw. auf automatischen Start zu setzen: SQL> startup ORA-01078: failure in processing system parameters Starten Sie die HA-Dienste mit dem folgenden Befehl: $ crsctl start resource –all $ crs_stat –t Name Type Target State Host -----------------------------------------------------------ora.cssd ora.cssd.type ONLINE ONLINE lap3
Auch die ASM-Instanz sollte vorzugsweise ein SPFILE benutzen. Wenn Sie an dieser Stelle versuchen, das SPFILE zu erstellen, dann werden Sie in den folgenden Fehler laufen: ORA-29786: SIHA attribute GET failed with error [Attribute 'SPFILE' sts[200]
293
5 Automatic Storage Management Die Ursache liegt in der engeren Verknüpfung der Ressource ASM mit der Grid-Infrastruktur in der Version 11gR2. Deshalb muss an dieser Stelle eine Registrierung der ASMInstanz erfolgen: srvctl add asm -p $ORACLE_HOME/dbs/init+ASM.ora -d "/opt/asmdisks/asmdisk1"
Dabei definiert der Parameter „-p” das SPFILE oder die Initparameter-Datei und der Parameter „-d” den Pfad für den Discovery-Prozess. Jetzt können Sie das SPFILE wie gewohnt erstellen: SQL> CREATE spfile='?/dbs/[email protected]' FROM pfile='?/dbs/[email protected]'; File created.
Praxistipp Verwenden Sie für den normalen Betrieb der ASM-Instanz ein SPFILE. Wie bei der DatenbankInstanz können Sie damit Parameter dynamisch ändern. Weiterhin werden dann auch erstellte Diskgruppen automatisch in den Parameter asm_diskgroups eingetragen und beim Neustart der Instanz die Diskgruppe automatisch im Mount-Status angeschlossen.
Die ASM-Instanz sucht während des Starts nach ASM-Disks in den Pfaden, die im Parameter asm_diskstring vorgegeben sind. Dieser Prozess wird „Discovery“ genannt. Welche Disks ASM tatsächlich als ASM-Disk erkennt, hängt von verschiedenen Faktoren ab. Der folgende Abschnitt beschäftigt sich mit dem Thema, was auf den typischen Plattformen als ASM-Disk erkannt wird.
5.2.3
ASM-Disks auf spezifischen Plattformen
Für die UNIX-Betriebssysteme ist die Vorbereitung der ASM-Disks sehr ähnlich, jedoch gibt es auch da die eine oder andere Besonderheit zu beachten. Für Windows-Betriebssysteme gibt es wie gewohnt einige Abweichungen. Allgemein gilt, eine ASM-Disk kann sein:
Eine komplette Disk oder Festplatte Ein logisches Device eines RAID-Systems Die Partition einer Disk Eine Zusammenfassung mehrerer Partitionen über mehrere physikalische Disks Ein Logical Unit (LUN) eines Storage Subsystems Eine ASM-Disk kann im Größenbereich von 4 MByte bis 232 MByte liegen. 5.2.3.1 AIX Unter AIX wird einer Disk normalerweise ein sogenannter Physikalischer Volume Identifier (PVID) zugeordnet. Dies kann zum Beispiel mit der Zuweisung einer Volume-Gruppe oder manuell mit Befehlen des Betriebssystems erfolgen. Die Speicherung der PVID erfolgt sowohl auf dem Header der Disk als auch im Object Data Manager (ODM) von AIX. Der Disk Header mit der PVID belegt die ersten 4 KByte der Disk.
294
5.2 Eine ASM-Umgebung konfigurieren Andererseits verwendet ASM einen eigenen Disk Header, der sich auf den ersten 40 Byte der Disk befindet. Es besteht also die Gefahr des gegenseitigen Überschreibens. Normalerweise überschreibt AIX eine Disk, auf der sich ein ASM Header befindet, nicht automatisch. Die Gefahr besteht eher darin, dass der UNIX-Administrator die Disk für leer oder verfügbar hält, da sie keine PVID besitzt. Der Administrator sollte deshalb, z.B. mit ASMCMD prüfen, ob es sich um eine ASM-Disk handelt. 5.2.3.2 Solaris In Solaris setzt sich ein logischer Diskname aus den Komponenten Controller (c), Target (t), Device (d) und Slice (s) zusammen. Ein Diskname sieht dann zum Beispiel so aus: /dev/rdsk/c3t4d0s5
Hinter dem logischen Device-Namen verbirgt sich das Raw Device, das Sie mit dem lsBefehl abfragen können: $ ls –l /dev/rdsk/c3t4d0s5 lrwxrwxrwx 1 root root 45 Jan 12 06:33 c3t4d0s5 -> ../../devices/pci@1f,2000/scsi@3/sd@2,0:e,raw
Praxistipp Arbeiten Sie unter Solaris immer mit den logischen Device-Namen. Der physikalische DeviceName kann sich nach einem Hardware-Austausch im Server verändern. Setzen Sie den Parameter asm_diskstring zum Beispiel auf: ASM_DISKSTRING=’/dev/rdsk/c3t?d*‘ Damit ASM das logische Device benutzen kann, müssen die Besitzrechte sowohl für das logische als auch für das physikalische Device dem Benutzer „oracle“ zugewiesen werden: chown -h oracle:dba /dev/rdsk/c3t4d0s5
5.2.3.3 Linux Die Bereitstellung von ASM-Disks unter Linux ist ähnlich wie bei den UNIX-Betriebssystemen. Eine ASM-Disk kann eine ganze physikalische Disk oder eine Partition einer Disk sein. Das Anlegen einer Partition erfolgt mit dem Utility fdisk. Praxistipp Bevor wir mit dem Aufsetzen einer ASM-Testumgebung beginnen, noch ein Hinweis zum Einsatz von ASM-Disks. Zum Testen aller ASM-Features ist es erforderlich, eine Mindestanzahl von ASM-Disks zur Verfügung zu haben. In der Praxis ist es oft schwierig und teuer, so viele physikalische Disks bereitzustellen. ASM bietet die Möglichkeit, für Testzwecke, normale Dateien im Betriebssystem als ASM-Disks zu definieren. Führen Sie die folgenden Schritte aus, um solche Disks in Linux zu erstellen:
1. Erstellen Sie die Dateien, die als ASM-Disks verwendet werden sollen und weisen Sie die erforderlichen Benutzerrechte zu: # # # # # #
5 Automatic Storage Management 2. Mithilfe eines Hidden Parameters müssen Sie Oracle mitteilen, dass Dateien als ASM-Disks zugelassen werden sollen. Fügen Sie nach dem Erstellen der ASM-Umgebung den folgenden Parameter in das SPFILE der ASM-Instanz ein: *._ASM_ALLOW_ONLY_RAW_DISKS=FALSE ACHTUNG! Verwenden Sie diese Konfiguration ausschließlich für Testzwecke und niemals für produktive Systeme.
5.2.3.4 Windows Unter Windows kann eine ASM-Disk eine ganze physikalische Disk, die Partition einer Disk oder eine LUN eines Storage-Subsystems sein. Die Partitionen einer Disk sind mit Raw Devices zu vergleichen, das heißt, sie werden nicht formatiert und bekommen keinen Laufwerksbuchstaben zugeordnet. Sie können mit dem Windows Disk Manager oder dem Utility diskpart verwaltet werden (Abbildung 5.1).
Abbildung 5.1 Die Disk-Verwaltung in Windows-Betriebssystemen
Für Windows-Betriebssysteme stehen die Utilites asmtool und asmtoolg (mit grafischer Oberfläche) zur Verfügung. Damit können ASM-Disks mit einem Label versehen und der Discovery-Prozess erleichtert werden (Abbildung 5.2).
296
5.2 Eine ASM-Umgebung konfigurieren
Abbildung 5.2 Das Utility asmtoolg zum Stempeln von ASM-Disks
Mit dem Stempeln der ASM-Disk vergeben Sie einem ASM-Linknamen, zum Beispiel „ORADISK1“. Auf Windows-Ebene können Sie diese Disk unter \\.\ORADISK1 ansprechen und damit den Parameter asm_diskstring definieren: *.asm_diskstring=‘\\.\ORADISK*‘
5.2.4
Der Discovery-Prozess
ASM speichert die Disk-Konfiguration nicht intern ab, alle Metadaten der Disks und Diskgruppen befinden sich auf den Disks selbst. Der Discovery-Prozess ist die Methode zum Auffinden der ASM-Disks. Er wird automatisch bei folgenden Ereignissen ausgelöst:
Starten der ASM-Instanz Eine Diskgruppe wird in den Status ONLINE versetzt Eine Disk wird zu einer Diskgruppe hinzugefügt Eine Disk wird vergrößert SELECT . . . FROM v$asm_disk, v$asm_diskgroup Eine Disk, die durch den Discovery-Prozess erkannt wurde, erscheint in der View V$ASM_DISK. Disks, die zu einer Diskgruppe gehören, besitzen den Status „MEMBER“, Disks, die noch keiner Diskgruppe zugewiesen wurden, weisen den Status „CANDIDATE“ auf: SQL> SELECT name, header_status, path FROM v$asm_disk; NAME HEADER_STATUS PATH -------- ---------------- ---------------------------DISK01 CANDIDATE /dev/rdsk/c4t21ds13 DISK02 MEMBER /dev/rdsk/c2t12ds11
297
5 Automatic Storage Management Sobald Disks von der ASM-Instanz erkannt werden, können diese verwendet werden, um eine Diskgruppe zu erstellen. Das einfachste Beispiel ist eine Diskgruppe mit einer Disk ohne Spiegelung: SQL> CREATE DISKGROUP dg_test EXTERNAL REDUNDANCY 2 DISK 'C:\ASMDISKS\ASMDISK1'; Diskgroup created. SQL> SELECT name,state,total_mb,free_mb 2 FROM v$asm_diskgroup; NAME STATE TOTAL_MB FREE_MB ------------ ----------- ---------- ---------DG_TEST MOUNTED 1000 950 SQL> show parameter diskgr NAME TYPE VALUE ---------------------- ----------- -----------------------------asm_diskgroups string DG_TEST
Die Diskgruppe wird im Init-Parameter asm_diskgroups gespeichert und damit beim Neustart der Instanz automatisch gemountet.
5.2.5
Der ASMCA
Der ASMCA ist ein Assistent zum Anlegen und Verwalten der ASM-Instanz sowie der Diskgruppen. Er erscheint mit unterschiedlichen Masken in Abhängigkeit davon, ob bereits eine ASM-Instanz auf dem Server existiert. Wenn Sie den ASMCA zum erstmaligen Erstellen einer Instanz benutzen, dann erhalten Sie die Maske so wie in Abbildung 5.3 dargestellt.
Abbildung 5.3 Der ASMCA beim Erstellen einer Instanz
298
5.2 Eine ASM-Umgebung konfigurieren Es werden die Passwörter abgefragt. Sie können die Parameter der ASM-Instanz vorgeben und Diskgruppen anlegen. Sobald Sie den Butten „Create ASM“ drücken, wird die ASMInstanz gestartet und die Diskgruppen werden im Mount-Status geöffnet. Wenn bereits eine ASM-Instanz existiert, dann erscheint der ASMCA so, wie in Abbildung 5.4 dargestellt. Sie können neue Diskgruppen hinzunehmen, Diskgruppen entfernen oder ein ASM Cluster File-System (ACFS) einrichten. Mit dem Thema „ACFS“ beschäftigen wir uns später in diesem Kapitel.
Abbildung 5.4 Der ASMCA für die Verwaltung von Diskgruppen
5.2.6
ASM im Enterprise Manager
Wenn Sie den Enterprise Manager Grid Control verwenden, dann genügt ein DiscoveryProzess mit Hilfe des emca auf dem Datenbankserver und der Enterprise Manager erkennt die ASM-Instanz. Dem Enterprise Manager Database Control müssen Sie die neue Target „ASM-Instanz“ mit den folgenden Schritten bekannt machen: 1. Erstellen Sie eine xml-Datei mit folgendem Format und passen Sie die Werte an Ihre Umgebung an:
2. Fügen Sie diese Daten als Target zum Enterprise Manager hinzu: emctl config agent addtarget
3. Starten Sie den Enterprise Manager neu: $ emctl stop dbconsole $ emctl start dbconsole
Auf der Startseite der Datenbank erscheint ein Link zur ASM-Instanz (siehe Abbildung 5.5).
Abbildung 5.5 Die Startseite der Datenbank mit Link zur ASM-Instanz
Über diesen Link gelangen Sie zur Startseite der ASM-Instanz. Wir werden im weiteren Verlauf des Kapitels den Enterprise Manager für die Verwaltung der ASM-Umgebung noch mehrfach benutzen.
300
5.3 ASM-Disks, -Diskgruppen und -Fehlergruppen
Abbildung 5.6 Die Startseite der ASM-Instanz im Enterprise Manager
5.3
ASM-Disks, -Diskgruppen und -Fehlergruppen Für das Erstellen einer Diskgruppe müssen ASM-Disks bereit stehen, die nicht bereits zu einer Diskgruppe gehören. Diese Disks müssen einen der folgenden Status besitzen:
CANDIDATE: Disk wurde als ASM-Disk erkannt und war noch nicht einer Diskgruppe zugewiesen
PROVISIONED: Disk wurde als ASM-Disk erkannt, es müssen jedoch noch bestimmte Plattform-spezifische Aktivitäten durchgeführt werden, damit die Disk von ASM benutzt werden kann (z.B. die Bearbeitung mit asmtool unter Windows)
FORMER: Disk wurde als ASM-Disk erkannt, gehörte früher zu einer Diskgruppe und ist aktuell keiner Diskgruppe zugewiesen Mit der folgenden SQL-Anweisung können Sie die verfügbaren ASM-Disks abfragen: SQL> SELECT name,header_status,path 2 FROM v$asm_disk; NAME HEADER_STATU PATH ------------ ------------ ----------------------DISK01 FORMER /opt/asmdisks/asmdisk1 DISK02 CANDIDATE /opt/asmdisks/asmdisk2 DISK03 CANDIDATE /opt/asmdisks/asmdisk3 DISK04 CANDIDATE /opt/asmdisks/asmdisk4
301
5 Automatic Storage Management Es stehen also vier ASM-Disks zur Verfügung, mit denen eine Diskgruppe erstellt werden kann. In diesem Beispiel sind es Dateien auf einem Testsystem. Praxistipp Wenn eine Diskgruppe nicht sauber entfernt werden konnte, dann besteht die Möglichkeit, dass die zugehörigen ASM-Disks noch den Status „MEMBER“ besitzen. Sie können diese Disks trotzdem zum Erstellen einer neuen Diskgruppe verwenden, indem Sie im Befehl „CREATE DISKGROUP“ die Option „FORCE“ verwenden. Dann werden die ASM-Header einfach mit den Metadaten der neuen Diskgruppe überschrieben.
Wir wollen jetzt eine Diskgruppe mit einfacher Spiegelung und zwei Fehlergruppen erstellen. Dabei ordnen wir die Disks, die jeweils an einem physikalischen Controller angeschlossen sind, einer Fehlergruppe zu: SQL> CREATE DISKGROUP dg_data NORMAL REDUNDANCY 2 FAILGROUP controler_1 3 DISK 'C:\ASMDISKS\ASMDISK1','C:\ASMDISKS\ASMDISK3' 4 FAILGROUP controler_2 5 DISK 'C:\ASMDISKS\ASMDISK2','C:\ASMDISKS\ASMDISK4' 6 ATTRIBUTE 7 'compatible.asm' = '11.2', 8 'compatible.rdbms' = '11.2'; Diskgroup created.
Die Diskgruppe wurde mit zwei Attributen erstellt. Attribute gehören zur Diskgruppe und sind nicht Instanz-bezogen. Die Attribute legen den Kompatibilitätsstatus der Diskgruppe bezüglich der ASM-Instanz und der Datenbank-Instanz fest. Beachten Sie, dass Sie die Features der Version 11g R2 nur dann benutzen können, wenn die Diskgruppe mit der Kompatibilität „11.2“ angelegt wurde. Die Kompatibilität der ASM-Instanz muss größer oder gleich der Kompatibilität der Datenbank-Instanz sein. Praxistipp Die Standardwerte der Attribute compatible.asm und compatible.rdbms sind „10.1“. Geben Sie die Kompatibilitätswerte „11.2“ beim Erstellen der Diskgruppe stets an, wenn Sie ASM-Features der Version 11g R2 benutzen wollen. Die Kompatibilität kann auch nach dem Anlegen der Diskgruppe erhöht, allerdings nicht verkleinert werden.
Im Folgenden finden Sie eine Übersicht der wichtigsten Diskgruppen-Attribute:
AU_SIZE: Größe der Allocation Units innerhalb der Diskgruppe. Dieses Attribut kann nur beim Erstellen der Diskgruppe gesetzt und danach nicht mehr verändert werden. Es können die Werte 1, 2, 4, 8, 16, 32 oder 64 MByte vorgegeben werden. Der Standard ist 1 MByte. Für die Mehrheit kleiner bis mittelgroßer Datenbanken ist der Standard die optimale Größe. Größere Werte bieten vor allem Vorteile bei Full Table Scans oder Index Scans großer, Data-Warehouse-typischer Datenbanken.
COMPATIBLE.ASM: Bestimmt die Kompatibilität der Diskgruppe. Der Standard in Oracle 11g R2 ist „10.1“.
COMPATIBLE.RDBMS: Bestimmt die Kompatibilität der Datenbankversion. Der Standard in Oracle 11g R2 ist „10.1“.
302
5.3 ASM-Disks, -Diskgruppen und -Fehlergruppen
SECTOR_SIZE: 512 Byte oder 4 KByte. Der Standard ist Plattform-abhängig und liegt bei den meisten UNIX- und Windows-Systemen bei 512 Byte. ACFS unterstützt nicht 4-KByte-Sektoren. Mit der folgenden SQL-Anweisung können Sie die Attribute von Diskgruppen abfragen: SELECT a.name, b.name, b.value FROM v$asm_diskgroup a, v$asm_attribute b WHERE b.group_number = a.group_number ORDER BY 1,2; NAME NAME --------------- ---------------------------------------DG_DATA au_size DG_DATA cell.smart_scan_capable DG_DATA compatible.asm DG_DATA compatible.rdbms . . .
VALUE ---------1048576 FALSE 11.2.0.0.0 11.2.0.0.0
Fehlergruppen werden verwendet, um Daten möglichst ausfallsicher zu spiegeln. Die Kopie eines Datenblocks befindet sich stets auf den Disks anderer Fehlergruppen. Solange es zum Verlust von ASM-Disks kommt, die innerhalb einer Fehlergruppe liegen, kann ein Datenverlust ausgeschlossen werden. Beachten Sie die folgenden Regeln beim Anlegen von Fehlergruppen:
Eine einzelne ASM-Disk kann stets nur zu einer Fehlergruppe gehören. Die Speicherkapazität der Fehlergruppen einer Diskgruppe sollte identisch sein. ASM benötigt mindestens zwei Fehlergruppen für „Normal Redundancy“ und drei für „High Redundancy“. An dieser Stelle stellt sich die Frage, wie sich ASM im Falle eines Fehlers verhält und welche Möglichkeiten der Fehlerbehandlung bestehen. Beim Auftreten eines Lesefehlers führt die ASM-Instanz folgende Aktionen automatisch durch:
Lesen einer „guten“ Kopie der AU Kopieren der Daten auf die fehlerhafte Kopie der AU War das Überschreiben der fehlerhaften Kopie erfolgreich, dann wird die AU als „gesund“ gestempelt
Schlägt das Überschreiben fehl, dann versucht ASM die AU auf eine andere Stelle der Disk zu schreiben. Die ursprüngliche AU erhält das Attribut „unusable“.
Schlägt das Schreiben auf eine andere Position der Disk fehl, dann wird die Disk in den Status „offline“ gesetzt. Im Fall von Schreibfehlern reagiert die ASM-Instanz wie folgt:
Die ASM-Instanz benachrichtigt die Datenbank-Instanz, wenn ein Schreibfehler auftritt.
Wenn die Datenbank eine Meldung erhält, dass das Schreiben von mindestens einer Kopie erfolgreich war, dann wird der Schreibvorgang als erfolgreich gewertet.
Schlägt das Schreiben auf alle Spiegel fehl, wird dies von der Datenbank als Schreibfehler betrachtet. Eine mögliche Reaktion ist, den Tablespace in den Status „offline“ zu setzen.
303
5 Automatic Storage Management
Erhält die ASM-Instanz eine Meldung von der Datenbank oder erkennt selbst, dass wiederholte Schreibfehler auf einer Disk auftreten, dann setzt ASM die Disk in den Status „offline“.
Sind zu viele Disks von einem Fehler betroffen, sodass die Datenintegrität nicht mehr gewährleistet werden kann, dann wird die Diskgruppe in den Status „unmount“ gesetzt. Praxistipp In der Praxis stellt sich die Frage, auf welcher Ebene das Spiegeln von Daten erfolgen soll. Die Art und Weise, wie ASM mit Lese- und Schreibfehlern umgeht, favorisiert deutlich ASM gegenüber der Spiegelung auf Betriebssystem- oder Storage-Ebene. Während ASM logische Fehler weitestgehend automatisch behebt, werden diese durch Host-Based-Mirroring oder beispielsweise in RAID-Systemen gespiegelt. Das heißt, eine fehlerhafte Kopie wird auf den Spiegel übertragen. Bevorzugen Sie deshalb, wenn immer es möglich ist, die Spiegelung über ASM gegenüber anderen Verfahren.
Was passiert nun, wenn eine Disk unbrauchbar geworden ist? Wie nicht anders zu erwarten, ist die Reaktion der ASM-Instanz abhängig vom Grad der Spiegelung:
NORMAL REDUNDANCY und HIGH REDUNDANCY: Die fehlerhafte Disk wird automatisch in den Status „ “gesetzt. Die Diskgruppe verbleibt im MOUNT-Status und kann weiter genutzt werden. Nach dem Entfernen der Disk stellt ASM die Redundanz der Diskgruppe wieder her. Datenverlust kann ausgeschlossen werden.
EXTERNAL REDUNDANCY: Die Diskgruppe wird in den Status „unmount“ gesetzt. Dabei kommt es zum Datenverlust. Aus technischen Gründen und für Wartungszwecke kann es vorkommen, dass Disks für einen begrenzten Zeitraum in den Status „offline“ gesetzt werden müssen. Das Wiederherstellen der Redundanz einer Diskgruppe ist in der Regel Ressourcen-intensiv und zeitaufwendig. Mit „Fast Mirror Resync“ stellt Oracle ein Feature zur Verfügung, das den Wiederherstellungsaufwand signifikant verringert. Es werden alle Änderungen aufgezeichnet, die während der Offline-Zeit nicht auf die Disk geschrieben werden können. Ist die Disk wieder im Status „online“, dann werden nur die betroffenen Allocation-Units zurückgespiegelt. Die Maximaldauer wird durch das Attribut „DISK_REPAIR_TIME“ festgelegt. Danach wird die Disk automatisch aus der Diskgruppe entfernt. Der Standard ist 3,6 Stunden. Mit dem folgenden Befehl können Sie das Attribut ändern: SQL> ALTER DISKGROUP dg_data 2 SET ATTRIBUTE 'disk_repair_time' = '1.5h'; Diskgroup altered.
Eine Diskgruppe wird beim Start der ASM-Instanz automatisch in den Mount-Status gesetzt, wenn sie im Parameter asm_diskgroups eingetragen ist. Diskgruppen können manuell in den Status „mount“ oder „dismount“ gesetzt werden: SQL> ALTER DISKGROUP dg_data DISMOUNT; Diskgroup altered. SQL> ALTER DISKGROUP dg_data MOUNT; Diskgroup altered.
304
5.3 ASM-Disks, -Diskgruppen und -Fehlergruppen Eine ASM-Disk kann mit dem folgenden Befehl manuell in den Status „offline“ oder „online“ gesetzt werden: SQL> ALTER DISKGROUP dg_data OFFLINE DISK dg_data_0000; Diskgroup altered. SQL> ALTER DISKGROUP dg_data ONLINE DISK dg_data_0000; Diskgroup altered.
Die Konsistenz der Metadaten einer Diskgruppe kann mit der folgenden Anweisung überprüft werden: SQL> ALTER DISKGROUP dg_data CHECK; Diskgroup altered.
Das Ergebnis der Überprüfung wird in die Alertlog-Datei der ASM-Instanz geschrieben: SQL> ALTER DISKGROUP dg_data CHECK NOTE: starting check of diskgroup DG_DATA kfdp_checkDsk(): 18 kfdp_checkDsk(): 19 kfdp_checkDsk(): 20 kfdp_checkDsk(): 21 SUCCESS: check of diskgroup DG_DATA found no errors SUCCESS: ALTER DISKGROUP dg_data CHECK
Bei der Verwendung von gespiegelten Diskgruppen müssen genügend Kapazitäten zur Verfügung stehen, um bei Ausfall einer oder mehrerer Disks die Daten in einer Fehlergruppe unterzubringen. Die folgenden Spalten der View V$ASM_DISKGROUP liefern Informationen über die Kapazitäten der Diskgruppen:
REQUIRED_MIRROR_FREE_MB: Notwendiger Platz in einer Diskgruppe, um volle Redundanz im Fehlerfall wieder herzustellen
USABLE_FILE_MB: Speicherplatz, der nach einem Disk-Fehler für neue Daten zur Verfügung steht, um die Redundanz wieder herzustellen
TOTAL_MB: Gesamt verfügbare Kapazität der Diskgruppen FREE_MB: Freier Platz in den Diskgruppen, wobei noch ausstehende Ausbalancierungen nicht berücksichtigt sind: SQL> SELECT name,required_mirror_free_mb,usable_file_mb,total_mb,free_mb 2 FROM v$asm_diskgroup; NAME REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB TOTAL_MB FREE_MB ---------- ----------------------- -------------- ---------- ---------DG_DATA 106 1741 4000 3588
Informationen über die Kapazitäten der Diskgruppen erhalten Sie auch im Enterprise Manager (Abbildung 5.16). Es bleibt schließlich die Frage, welche Kapazitätsgrenzen beim Einsatz von ASM bestehen. Hier haben die Architekten weit in die Zukunft gedacht:
63 Diskgruppen in einem Storage-System 10.000 Disks in einem Storage-System 1 Million Dateien pro Diskgruppe 2 TByte pro ASM-Disk 20 PByte pro Storage-System
305
5 Automatic Storage Management
Abbildung 5.7 Übersicht der Diskgruppen-Kapazitäten im Enterprise Manager
5.4
Das Utility ASMCMD Die ersten ASM-Versionen wurden scherzhaft als „Schwarzes Loch“ bezeichnet. Die Situation hat sich grundlegend geändert; heute gibt es viele Möglichkeiten, sich in ASM zu bewegen und die Inhalte zu administrieren. Neben der komfortablen Bedienung über den Enterprise Manager wurde die Funktionalität des Utilities ASMCMD wesentlich erweitert und bietet alle Möglichkeiten, insbesondere für Administratoren, die es gewohnt sind, sich mit Befehlen des Betriebssystems durch Dateisysteme zu bewegen. Die Befehle ähneln sehr stark denen der Unix- und Linux-Systeme, sodass sich Administratoren intuitiv zurechtfinden. ASMCMD unterscheidet:
Instanz-Befehle File Management-Befehle Die Tabellen 5.1 und 5.2 geben eine Übersicht über die Befehlsgruppen. ASMCMD kann sowohl interaktiv als auch mit Parametern ausgeführt werden. Im folgenden Beispiel werden mit dem Befehl lsdg die Diskgruppen aufgelistet: $ asmcmd ASMCMD> lsdg State Type Req_mir_free_MB MOUNTED NORMAL 106 1741
306
Rebal Sector Block AU Usable_file_MB Offline_disks N 512 4096 1048576 0 N DG_DATA/
Total_MB Free_MB Voting_files Name 4000 3588
5.4 Das Utility ASMCMD Tabelle 5.1 Instanz-Befehle in ASMCMD Befehl
Beschreibung
dsget
Disk Discovery String abfragen
dsset
Disk Discovery String setzen
lsct
Informationen über ASM Clients ausgeben
lsop
Informationen über aktuelle DG-Operationen ausgeben
lspwuser
Oracle PW-File Benutzer auflisten
orapwuser
Änderungen der PW-File Benutzer vornehmen
shutdown
Die ASM-Instanz herunterfahren
spbackup
Eine Sicherung des ASM SPFILE erstellen
spcopy
Das ASM SPFILE kopieren
spget
Den Speicherort des ASM SPFILE feststellen
spmove
Ein ASM SPFILE verschieben
spset
Den Speicherort des ASM SPFILE festlegen
startup
Die ASM-Instanz starten
Tabelle 5.2 Dateiverwaltung mit ASMCMD Befehl
Beschreibung
cd
= cd in UNIX
cp
= cp in UNIX
du
Zeigt die aktuelle Belegung inkl. Unterverzeichnisse an
find
Suche nach Dateien ab dem spez. Verzeichnis
ls
Dateien im Verzeichnis auflisten
lsof
Offen Dateien auflisten
mkalias
Einen Alias für vom System erstellte Dateien generieren
mkdir
Ein ASM-Verzeichnis anlegen
Pwd
Das aktuelle ASM-Verzeichnis anzeigen
rm
Dateien und Verzeichnisse löschen
rmalias
Einen Alias löschen
Der nichtinteraktive Modus ist vor allem nützlich, um ASMCMD in Shell-Skripte einzubinden. Im folgenden Shell-Skript wird das SPFILE in ASM gesucht und in eine Datei im Betriebssystem kopiert. #!/bin/ksh SPFILE=`asmcmd find --type parameterfile . "*" ` asmcmd cp $SPFILE /data/oracle/backup/spfile_backup.ora
307
5 Automatic Storage Management
5.5
ASM-Sicherheit Mit der Version 11g R1 wurde das neue Privileg SYSASM für die ASM-Instanz eingeführt. Das Privileg ist vergleichbar mit dem Privileg SYSDBA für die RDBMS-Instanz. Es besitzt Rechte wie zum Beispiel das Hoch- und Herunterfahren der Instanz. Damit war erstmalig eine Rollentrennung zwischen Datenbank-Administrator und ASM-Administrator möglich. Der Benutzer mit dem SYSASM-Privileg erhält alle administrativen Rechte an der ASMInstanz. Andererseits ist dem Benutzer SYS das SYSASM-Privileg nicht standardmäßig zugewiesen. Allerdings besaß der User SYS in der Version 11.1 aus Kompatibilitätsgründen noch volle Admin-Rechte in der ASM-Instanz. Dies ist in der Version 11g R2 nicht mehr der Fall. Ein Benutzer der das SYSDBA-Privileg und nicht das SYSASM-Privileg besitzt, kann unter anderem folgende Operationen nicht mehr durchführen:
Diskgruppen anlegen Die ASM-Instanz hoch- und herunterfahren Ein Benutzer mit SYSDBA-Privileg hat noch die folgenden eingeschränkten Rechte:
Erstellen und Löschen von Dateien, Aliase und Directories ASM Views abfragen Zugriff auf eigene, selbst erstellte Dateien Die Mitgliedschaft in der Gruppe OSASM erlaubt den Zugriff mit SYSASM-Privileg über Authentifizierung durch das Betriebssystem. Während der Installation der Software mit dem Universal Installer haben Sie die Möglichkeit, den logischen Gruppen OSDBA, OSOPER und OSASM physikalische Gruppen im Betriebssystem zuzuweisen. Eine Authentifizierung mit dem SYSASM-Privileg kann auch über die Passwortdatei erfolgen. Führen Sie die folgenden Schritte aus, wenn Sie eine Rollentrennung vornehmen möchten: 1. Erstellen Sie einen Benutzer, der alle Rechte als ASM-Administrator erhalten soll: SQL> CREATE USER asm_admin IDENTIFIED BY manager; User created.
2. Weisen Sie dem Benutzer das Privileg „SYSASM“ zu: SQL> GRANT sysasm TO asm_admin; Grant succeeded.
3. Überprüfen Sie der Vergabe der administrativen Rechte: SQL> SELECT * FROM v$pwfile_users; USERNAME SYSDB ------------------------------ ----SYS TRUE ASM_ADMIN FALSE
SYSOP ----TRUE FALSE
SYSAS ----FALSE TRUE
4. Entfernen Sie den Benutzer „oracle“ aus der Gruppe „OSASM“. Sollen ASM-Instanz und RDBMS-Instanz von denselben Personen administriert werden, dann können Sie das SYSASM-Privileg dem Benutzer „SYS“ zuweisen. SQL> GRANT sysasm TO sys; Grant succeeded. SQL> SELECT * FROM v$pwfile_users;
ASM Monitoring, Performance und Troubleshooting Das am besten integrierte Werkzeug zur Überwachung der ASM-Instanz und der Diskgruppen ist der Oracle Enterprise Manager. Er besitzt vordefinierte Metriken, die mit individuellen Schwellwerten für Warnung und kritischen Fehler besetzt werden können. Klicken Sie im Standardverzeichnis der ASM-Instanz auf den Link „Metrik- und PolicyEinstellungen“ im Abschnitt „Zugehörige Links“. Auf dieser Seite (siehe Abbildung 5.8) können Sie Schwellwerte für ASM-spezifische Ereignisse festlegen. Schwellwertverletzung sind dann im Benachrichtigungssystem des Enterprise Manager eingebunden, so wie Sie es von der Datenbank-Instanz kennen. Verletzungen erscheinen auch auf der Startseite der Datenbank.
Abbildung 5.8 Metrik- und Policy-Einstellungen für die ASM-Instanz im Enterprise Manager
Für viele Oracle-Datenbanken ist die I/O-Performance ein entscheidender Faktor für Erfolg oder Misserfolg der Applikation. Tests haben bestätigt, dass die Performance von ASM mit der von Raw Devices vergleichbar ist. Dennoch werden in der Praxis beim DiskLayout immer wieder Fehler begangen, die auch unter ASM zu einer schlechten I/OPerformance führen.
309
5 Automatic Storage Management Die beste Grundlage für eine gute Performance ist das Striping. Eine einzelne Disk besitzt aufgrund ihrer Physik einen beschränkten Durchsatz und beschränkte Antwortzeiten. Daran hat sich auch in den Jahren des allgemeinen Kapazitätswachstums der Hardware wenig geändert. Ein gute bis sehr gute I/O-Performance erhält man in erster Linie durch ein Striping über möglichst viele Disks. Beim Einsatz von ASM gibt es zwei sinnvolle Möglichkeiten des Striping:
Striping auf Storage-Ebene: Es erfolgt ein Striping im Storage-Subsystem und in Richtung ASM wird eine (oder wenige) große LUN hochgereicht, die als ASM-Disk verwendet wird. In der Praxis hat sich bewährt, eine große LUN für die Datafiles sowie weitere kleinere LUNs für die Online Redo Logs und die Flashback Logs sowie die Flash Recovery Area bereitzustellen.
Striping auf ASM-Ebene: Die physikalischen Disks werden einzeln als LUN an das ASM weitergereicht und jede LUN wird zu einer ASM-Disk. Das Striping erfolgt dann auf ASM-Ebene. Praxistipp Vermeiden Sie ein gemischtes Striping auf Storage- und ASM-Ebene. Gemischte Stripings führen zu einer schlechteren Performance und können Probleme im Load Balancing verursachen. ASM führt eine automatische Verteilung der Extents auf alle Disks durch. Aus diesem Grund geht ASM davon aus, dass ASM-Disks voneinander unabhängig operieren. Deshalb sollten beim Striping auf ASM-Ebene ganze physikalische Disks als LUN an das ASM vermittelt werden. Werden Teile von Disks als LUNs festgelegt, dann ist dieses Prinzip nicht mehr garantiert.
ASM kennt zwei Arten von Striping:
Coarse-Grained Striping (grobkörnig) Fine-Grained Striping (feinkörnig) Das Coarse-Grained Striping wird vorwiegend für Datafiles eingesetzt. Die Größe der Stripes ist identisch mit der Allocation Unit, also im Standardfall 1 MByte. Damit wird ein optimaler I/O-Durchsatz garantiert. Das Fine-Grained Striping erfolgt mit einer Größe von 128 KByte und wird meist für Redo Log-Dateien und Flashback Log-Dateien verwendet. Fine-Grained Striping unterstützt kleine Dateioperationen und liefert kleine Latenzzeiten. ASM nimmt das Striping automatisch vor. Die Größe der Stripes wird abhängig vom Dateityp festgelegt und ist im Template der Diskgruppe gespeichert. SQL> SELECT name,stripe FROM v$asm_template 2 WHERE group_number = 1; NAME STRIPE ------------------------------ -----PARAMETERFILE COARSE ASMPARAMETERFILE COARSE ASMPARAMETERBAKFILE COARSE DUMPSET COARSE CONTROLFILE FINE FLASHFILE COARSE ARCHIVELOG COARSE ONLINELOG FINE
Neben dem Striping, also einer möglichst breiten Verteilung der AUs auf die Disks, ist das Ausbalancieren der I/O-Aktivitäten ein wichtiger Performance-Faktor. Das beste Striping bringt wenig, wenn es zu sogenannten „Hot Spots“ kommt und die Mehrheit der I/OAktivitäten auf einer oder wenigen Disks stattfinden. ASM führt selbst kein automatisches Rebalancing der Lastverteilung durch. Es erfolgt jedoch eine Verteilung der Extents auf alle Disks mit dem Ziel einen gleichmäßigen Füllgrad zu erreichen. In der Regel erfolgt damit auch eine Verteilung der I/O-Operationen, die jedoch nicht immer gleichmäßig ist. Die Intensität des Rebalancing wird durch den Parameter asm_power_limit festgelegt. Die Intensitätsbreite liegt auf einer Skala von 0 bis 11, der Standard ist 1. Im Normalbetrieb wird der Prozess also wenig intensiv durchgeführt, um den laufenden Betrieb möglichst wenig zu beeinflussen. Unabhängig davon können Sie ein Rebalancing manuell anstoßen. Das ist zum Beispiel sinnvoll, wenn eine Disk entfernt oder hinzugenommen wurde und die Arbeiten in einem Wartungsfenster ablaufen. Im Beispiel in Listing 5.3 wird die Rebalancing Power im Wartungsfenster erhöht. SQL> ALTER DISKGROUP dg_data REBALANCE POWER 11 WAIT; Diskgroup altered. SQL> ALTER DISKGROUP dg_data REBALANCE; Diskgroup altered.
Der Enterprise Manager liefert sehr gute Übersichten zur Performance der einzelnen Diskgruppen. Klicken Sie auf das Register Performance. Im unteren Bereich der Seite finden Sie eine kumulative I/O-Statistik. Da sehen Sie u.a. die Anzahl der I/O-Aufrufe pro Disk sowie die durchschnittlichen Antwortzeiten.
Abbildung 5.9 Die kumulative I/O-Statistik im Enterprise Manager
311
5 Automatic Storage Management Für eine Erhöhung der Ausfallsicherheit sowie ein Load Balancing über die I/O-Pfade wird häufig I/O Multipathing eingesetzt. ASM selbst bietet keine Multipathing-Funktionalität, kann aber zusammen mit Multipathing-Software anderer Hersteller eingesetzt werden. Beachten Sie dabei den folgenden Hinweis. Praxistipp Stellen Sie bei der Verwendung von Multipathing-Software sicher, dass ASM die Disks nur über die Pseudo-Devices anspricht. Vom ASM dürfen keine mehrfachen Pfade auf ein und dieselbe Disk (LUN) sichtbar sein, da dies zu Fehlern und Irritationen führt. Eine korrekte Einstellung des Parameters asm_diskstring ist dafür entscheidend.
Im Falle eines Fehlers der ASM-Instanz, einer Diskgruppe oder einer Disk sollte auch hier der erste Blick in die Alert-Logdatei gehen. Dort befinden sich die wichtigsten Nachrichten sowie Fehlermeldungen. Natürlich erscheinen kritische Fehler auch im Enterprise Manager. Für weitere Details kann man sich, so wie man es von der RDBMS-Instanz gewöhnt ist, die zugehörigen Trace-Dateien anschauen. Auch die ASM-Instanz besitzt eine Support Workbench, das heißt bei Fehlern werden Incident-Pakete geschnürt, die Sie an den Oracle Support weitergeben können. Im Folgenden finden Sie noch einige typische Fehlersituationen:
Die ASM-Instanz kann nicht gestartet werden. Läuft der Cluster Synchronization Services Daemon (CSSD)? $ crs_stat –t Name Typ Ziel Status Host -----------------------------------------------------------ora.cssd ora.cssd.type ONLINE ONLINE lap3
Ist genügend Hauptspeicher vorhanden? Überprüfen Sie die Alert-Logdatei auf Fehler. Überprüfen Sie die CRS/CSS Logdateien der Grid Infrastructure. Eine Diskgruppe wird nicht im Mount-Status angeschlossen. Überprüfen Sie den Parameter asm_diskstring. Überprüfen Sie die Status der Disks (V$ASM_DISK). Stellen Sie sicher, dass die Lese- und Schreibrechte der Devices stimmen. ORA-15020: discovered duplicate ASM disk: Es gibt mehrfache Pfade auf eine Disk. Verwenden Sie nur die Pseudo-Devices des Multipathing.
Überprüfen Sie, ob das Device eine gültige OS-Partition besitzt. ORA-15063: diskgroup “DG1” lacks quorum if 1 PST disks. Eine Diskgruppe soll gelöscht werden, um die Disks einer anderen Diskgruppe zur Verfügung zu stellen.
Eine Diskgruppe muss sich im MOUNT-Status befinden, damit sie gelöscht werden kann. Kann die Diskgruppe nicht mehr in den MOUNT-Status gebracht werden, dann führen Sie folgende Schritte durch:
312
5.7 Eine Datenbank nach ASM konvertieren 1.
Überschreiben Sie den Diskheader der Disks mit dem dd-Befehl: dd if=/dev/zero…
2.
5.7
Verwenden Die die FORCE-Option: CREATE
DISKGROUP … DISK … FORCE;
Eine Datenbank nach ASM konvertieren Bevor Sie den Einsatz von ASM für eine Datenbank planen, sollten Sie prüfen, welche Dateitypen von ASM unterstützt werden. Alle anderen Dateien gehören in das ACFS oder in ein Dateisystem des Betriebssystems. Tabelle 5.3 Von ASM unterstützte Dateitypen Dateityp
Templatename
Kontrolldateien
CONTROLFILE
Datafiles
DATAFILE
Redo Log-Dateien
ONLINELOG
Archived Redo Log-Dateien
ARCHIVELOG
Temporäre Dateien
TEMPFILE
RMAN Backup-Dateien
BACKUPSET
SPFile
PARAMETERFILE
Flashback Log-Dateien
FLASHBACK
Change Tracking-Dateien
CHANGETRACKING
Data Pump-Dateien
DUMPSET
In ASM werden Dateinamen durch das OMF-Feature (Oracle Managed Files) generiert. Ein voll qualifizierter Dateiname besteht aus Diskgruppe, DB-Name, Pfad (Dateityp) und Dateiname. Die Nummer im Dateinamen wird von Oracle generiert. Das folgende Beispiel ist der OMF-Name einer Kontrolldatei: +DB_DG1/dbasm/controlfile/current.256.702931785
Für jeden OMF-Dateinamen kann ein Alias angegeben werden. Damit können Sie einfache oder auch gewohnte Dateinamen verwenden. In den V$-Views (z.B. V$DATAFILE) erscheinen dann die Aliase, nicht die OMF-Namen. Der Init-Parameter control_files kann ebenfalls Aliase verwenden. Wenn Sie bei der Erstellung eines Objekts den Dateinamen vorgeben, dann wird dieser direkt als Alias gespeichert. Intern speichert Oracle immer den OMF-Namen: SQL> ALTER TABLESPACE USERS 2 ADD DATAFILE '+DB_DG1/dbasm/users_02.dbf' SIZE 10M; SQL> SELECT name FROM v$datafile; NAME -------------------------------------------------+DB_DG1/dbasm/users_02.dbf . . .
313
5 Automatic Storage Management Sie können natürlich auch nachträglich ein Alias hinzufügen und umbenennen: SQL> ALTER DISKGROUP DB_DG1 2 ADD ALIAS '+DB_DG1/dbasm/users_01.dbf' 3 FOR '+DB_DG1/dbasm/datafile/users.264.702931905'; Diskgroup altered. SQL> ALTER DISKGROUP DB_DG1 2 RENAME ALIAS '+DB_DG1/dbasm/users_01.dbf' 3 TO '+DB_DG1/dbasm/users_02.dbf'; Diskgroup altered.
Um eine Datenbank nach ASM zu konvertieren, können Sie zwei Wege gehen. Der eine wird durch den Enterprise Manager unterstützt. Klicken Sie dazu im Register „Server“ auf den Link „Zu ASM migrieren“ und folgen Sie den weiteren Anweisungen. Wir wollen an dieser Stelle die Migration mit einzelnen Schritten auf der Kommandozeile vornehmen, um wieder etwas hinter die Kulissen des Prozesses zu schauen. Die zweite Methode ist darüber hinaus im Fehlerfall transparenter. Führen Sie die folgenden Migrationsschritte durch: 1. Erstellen Sie eine ASM-Instanz mit den erforderlichen Diskgruppen zur Aufnahme der Dateien der Datenbank. 2. Ändern Sie im SPFILE der RDBMS-Instanz den Namen für die Kontrolldateien und legen Sie diesen in die ASM-Diskgruppe. Starten Sie danach die Instanz im MountStatus: SQL> ALTER SYSTEM SET control_files='+DG_DATA' SCOPE=SPFILE; System altered. SQL> SHUTDOWN IMMEDIATE SQL> STARTUP NOMOUNT
3. Verwenden Sie den Recovery Manager, um die Kontrolldatei nach ASM zu kopieren, und öffnen Sie danach die Datenbank im Mount-Status: $ rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Fri Aug 6 13:25:10 2010 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ODBA (not mounted) RMAN> RESTORE CONTROLFILE FROM '/opt/oracle/oradata/ODBA/control01.ctl'; Starting restore at 06-AUG-10 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=11 device type=DISK channel ORA_DISK_1: copied control file copy output file name=+DG_DATA/odba/controlfile/current.256.726326819 Finished restore at 06-AUG-10 RMAN> ALTER DATABASE MOUNT; database mounted released channel: ORA_DISK_1
4. Kopieren Sie mit RMAN alle Datafiles aus dem Betriebssystem nach ASM: RMAN> BACKUP AS COPY DATABASE FORMAT '+DG_DATA'; Starting backup at 06-AUG-10 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=11 device type=DISK channel ORA_DISK_1: starting datafile copy input datafile file number=00001 name=/opt/oracle/oradata/odba/system01.dbf output file name=+DG_DATA/odba/datafile/system.257.726327087 tag=TAG20100806T133125 RECID=1 STAMP=726327161 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:25 channel ORA_DISK_1: starting datafile copy input datafile file number=00002 name=/opt/oracle/oradata/odba/sysaux01.dbf
314
5.7 Eine Datenbank nach ASM konvertieren output file name=+DG_DATA/odba/datafile/sysaux.258.726327171 tag=TAG20100806T133125 RECID=2 STAMP=726327259 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:01:35 channel ORA_DISK_1: starting datafile copy input datafile file number=00003 name=/opt/oracle/oradata/odba/undotbs01.dbf output file name=+DG_DATA/odba/datafile/undotbs1.259.726327267 tag=TAG20100806T133125 RECID=3 STAMP=726327297 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:35 channel ORA_DISK_1: starting datafile copy copying current control file output file name=+DG_DATA/odba/controlfile/backup.260.726327303 tag=TAG20100806T133125 RECID=4 STAMP=726327307 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07 channel ORA_DISK_1: starting datafile copy input datafile file number=00004 name=/opt/oracle/oradata/odba/users01.dbf output file name=+DG_DATA/odba/datafile/users.261.726327311 tag=TAG20100806T133125 RECID=5 STAMP=726327311 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 06-AUG-10 channel ORA_DISK_1: finished piece 1 at 06-AUG-10 piece handle=+DG_DATA/odba/backupset/2010_08_06/nnsnf0_tag20100806t133125_0.262.726327313 tag=TAG20100806T133125 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 06-AUG-10
5. Öffnen Sie die Datenbank, legen Sie neue Tempfiles im ASM an und löschen Sie die Tempfiles im Betriebssystem: SQL> ALTER DATABASE OPEN; Database altered. SQL> ALTER TABLESPACE TEMP 2 ADD TEMPFILE '+DG_DATA' SIZE 20M; Tablespace altered. SQL> ALTER TABLESPACE TEMP 2 DROP TEMPFILE '/opt/oracle/oradata/odba/temp01.dbf'; Tablespace altered.
6. Benennen Sie die Datafiles um. Das geht einfach mit einem Befehl im Recovery Manager: RMAN> SWITCH DATABASE TO COPY; datafile 1 switched to datafile copy "+DG_DATA/odba/datafile/system.257.726327087" datafile 2 switched to datafile copy "+DG_DATA/odba/datafile/sysaux.258.726327171" datafile 3 switched to datafile copy "+DG_DATA/odba/datafile/undotbs1.259.726327267" datafile 4 switched to datafile copy "+DG_DATA/odba/datafile/users.261.726327311"
7. Im nächsten Schritt werden die Online Redo-Logdateien nach ASM migriert. Löschen Sie jeweils eine inaktive Gruppe und legen Sie danach eine neue im ASM an. Führen Sie einen manuellen Logfile-Switch durch und wiederholen Sie das Verfahren, bis sich alle Redo-Log-Dateien im ASM befinden: SQL> ALTER DATABASE DROP LOGFILE '/opt/oracle/oradata/odba/redo01.log'; Database altered. SQL> ALTER DATABASE ADD LOGFILE '+DG_DATA'; Database altered. SQL> ALTER DATABASE DROP LOGFILE '/opt/oracle/oradata/odba/redo02.log '; Database altered. SQL> ALTER DATABASE ADD LOGFILE '+DG_DATA'; Database altered. SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.
315
5 Automatic Storage Management SQL> ALTER DATABASE DROP LOGFILE '/opt/oracle/oradata/odba/redo03.log; Database altered. SQL> ALTER DATABASE ADD LOGFILE '+DG_DATA'; Database altered. SQL> SELECT member FROM v$logfile; MEMBER --------------------------------------------------+DG_DATA/odba/onlinelog/group_1.264.726328147 +DG_DATA/odba/onlinelog/group_2.265.726328223 +DG_DATA/odba/onlinelog/group_3.266.726328583
Praxistipp Falls eine Redo Log-Gruppe nicht gelöscht werden kann, da sie zwar nicht im Status „current“ jedoch im Status „active“ ist, dann hilft ein Checkpoint. Führen Sie den folgenden Befehl aus, danach ist die Gruppe im Status “inactive“. SQL> ALTER SYSTEM CHECKPOINT; System altered.
8. Auch das SPFILE soll in ASM gespeichert werden: SQL> CREATE SPFILE='+DG_MITP' FROM PFILE='?/dbs/[email protected]'; File created.
9. Falls Sie die Flash Recovery Area verwenden, dann muss diese nich umgestellt werden: SQL> ALTER SYSTEM SET db_recovery_file_dest='+DG_DATA' SCOPE=SPFILE; System altered. SQL> ALTER SYSTEM SET log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' SCOPE=BOTH; System altered.
Damit ist die Datenbank vollständig nach ASM migriert.
5.8
Das ASM Cluster File-System (ACFS) ACFS ist ein von Oracle entwickeltes Cluster-Dateisystem, das auf ASM aufsetzt. Der physikalische Speicherort ist eine ASM-Diskgruppe. Im ACFS können alle Dateien gespeichert werden, die nicht direkt von ASM unterstützt werden. Damit können jetzt nicht nur externe Tabellen, BFILEs oder Ausgaben der Datenbank, sondern auch Applikationsdateien, die nicht zur Datenbank gehören, gespeichert werden. Beachten Sie jedoch: Praxistipp Dateien, die direkt in ASM gespeichert werden können, werden von ACFS nicht unterstützt. Dazu gehören auch die Voting Disk und das Oracle Cluster Registry (OCR) der Oracle Clusterware.
Das folgende Beispiel zeigt, wie ein ACFS-Dateisystem erstellt werden kann. Zunächst muss eine ASM-Diskgruppe als Speicherort erstellt werden. Achten Sie darauf, dass für die Diskgruppe das Attribut compatible.advm auf den Wert „11.2“ gesetzt wird. Starten Sie vorher den ACFS-Treiber:
Die Mehrheit der Dateisysteme in einem Betriebssystem wird in einem Logischen Volume erstellt. Das Logische Volume wird von einem Logical Volume Manager (LVM) verwaltet. ACFS ist ähnlich aufgebaut. Physikalischer Speicherort ist ein Volume Device File (VDF). Für das Volume Device File wurde der neue Dateityp ASMVOL in ASM geschaffen. Die I/O-Aktivitäten laufen durch den ADVM-Treiber. Ein Volume Device File wird ähnlich wie andere Dateien im ASM behandelt, es erfolgt ein Striping über die ASM-Disks und es befindet sich komplett innerhalb einer Diskgruppe. Eine ASM-Diskgruppe kann mehrere Volume Device Files enthalten. Das Anlegen eines VDF kann mit dem Utility asmcmd vorgenommen werden. ASMCMD> volcreate -G dg_acfs vol_acfs -s 2G
Praxistipp Beachten Sie, dass die Länge des Volume-Namens auf 11 Zeichen beschränkt ist.
Der Befehl volcreate erstellt ein Volume Device File in der ASM-Diskgruppe und legt ein Device im Verzeichnis /dev/asm an. $ ls -l /dev/asm brwxrwx--- 1 root dba 252, 95745 Aug
9 21:09 vol_acfs-187
Es werden zwei Arten von ACFS-Dateisystemen unterschieden:
General Purpose ACFS-Dateisystem CRS Managed ACFS-Dateisystem 317
5 Automatic Storage Management Mit einem CRS Managed ACFS-Dateisystem sind Ressourcen der Oracle Clusterware verknüpft und es können Abhängigkeiten zu anderen Ressourcen definiert werden, wie zum Beispiel ASM-Diskgruppen. Ein General Purpose ACFS-Dateisystem wird nicht über die Clusterware gesteuert. Inhaltlich und funktional unterscheidet es sich nicht von einem CRS Managed ACFS-Dateisystem, der einzige Unterschied ist die fehlende Integration in Clusterware.
5.8.1
General Purpose ACFS-Dateisystem
Das Erstellen des Dateisystems kann von der Kommandozeile des Betriebssystems mit dem Utility mkfs erfolgen: $ /sbin/mkfs -t acfs /dev/asm/vol_acfs-187 mkfs.acfs: version = 11.2.0.1.0.0 mkfs.acfs: on-disk version = 39.0 mkfs.acfs: volume = /dev/asm/vol_acfs-187 mkfs.acfs: volume size = 2147483648 mkfs.acfs: Format complete.
Das Mounten des Dateisystems erfolgt mit dem Mount-Befehl des Betriebssystems, wobei der Typ „acfs“ anzugeben ist. Vergessen Sie nicht, die Rechte dem Benutzer „oracle“ zuzuweisen: # /bin/mount -t acfs /dev/asm/vol_acfs-187 /mnt/acfs # chown oracle:dba /mnt/acfs # mount . . . /dev/asm/vol_acfs-187 on /mnt/acfs type acfs (rw)
Um ein General Purpose ACFS-Dateisystem automatisch bei einem Neustart des Betriebssystems im Mount-Status anschließen zu können, stellt Oracle das ACFS Mount Registry zur Verfügung. Seine Funktionalität ist vergleichbar mit der Datei /etc/fstab in UNIXBetriebssystemen. Im Cluster wird das Dateisystem automatisch auf allen Knoten angeschlossen, das ACFS Mount Registry ist also eine global Mount-Tabelle. $ /sbin/acfsutil registry -a -f -n dar12 /dev/asm/vol_acfs-187 /mnt/acfs acfsutil registry: mount point /mnt/acfs successfully added to Oracle Registry $ /sbin/acfsutil registry Mount Object: Device: /dev/asm/vol_acfs-187 Mount Point: /mnt/acfs Disk Group: DG_ACFS Volume: VOL_ACFS Options: none Nodes: dar12
Praxistipp Erstellen Sie keinen Eintrag im ACFS Mount Registry, wenn Sie ein CRS Managed ACFSDateisystem erstellen. Die Steuerung erfolgt da durch die Oracle Clusterware.
318
5.8 Das ASM Cluster File-System (ACFS)
5.8.2
CRS Managed ACFS-Dateisystem
Die empfohlene Methode, um ein CRS Managed ACFS-Dateisystem zu erstellen, ist der ASM Configuration Assistant (ASMCA). Damit können Volumes und Dateisysteme erstellt sowie die Ressourcen in der Clusterware registriert werden. Wählen Sie das Register „Volumes“ und klicken Sie auf den Button „Create“. Geben Sie zu Erstellung des Volumes die erforderlichen Werte ein.
Abbildung 5.11 Ein ACFSVolume mit dem ASMCA anlegen
Klicken Sie auf das Register „ASM Cluster File System“ und betätigen Sie auch hier den Button „Create“, um das ACFS-Dateisystem zu erstellen. Führen Sie das angegebene Skript als Benutzer „root“ aus, um das Datei-System mit Mount anzuschließen.
Abbildung 5.12 Ein ACFS-Dateisystem mit dem ASMCA erstellen
319
5 Automatic Storage Management
5.8.3
ACFS Snapshots
ACFS verfügt über eine Snapshot-Funktionalität. Die Snapshots werden in einem versteckten Verzeichnis „.ACFS“ gespeichert. Es wird also kein zusätzlicher Mountpoint zum Speichern der Snapshot-Dateien benötigt. Das folgende Beispiel zeigt, wie ein Snapshot erstellt werden kann. 1. Erstellen Sie eine Textdatei im ACFS-Verzeichnis: $ cat test.txt Vor dem Snapshot
2. Erzeugen Sie als Benutzer root ein Snapshot mit dem Utility acfsutil: # /sbin/acfsutil snap create test_snap /mnt/acfs acfsutil snap create: Snapshot operation is complete.
3. Informationen über Snapshots können mit acfsutil und in der ASM-Instanz abgefragt werden: # /sbin/acfsutil info fs /mnt/acfs /mnt/acfs ACFS Version: 11.2.0.1.0.0 flags: MountPoint,Available mount time: Sun Aug 15 11:52:07 2010 volumes: 1 total size: 6442450944 total free: 6337380352 primary volume: /dev/asm/vol_acfs-417 label: flags: Primary,Available,ADVM on-disk version: 39.0 allocation unit: 4096 major, minor: 252, 213505 size: 6442450944 free: 6337380352 ADVM diskgroup DG_ACFS ADVM resize increment: 268435456 ADVM redundancy: unprotected ADVM stripe columns: 4 ADVM stripe width: 131072 number of snapshots: 1 snapshot space usage: 32768 SQL> SELECT fs_name,snap_name,create_time 2 FROM v$asm_acfssnapshots; FS_NAME SNAP_NAME CREATE_TIME -------------------- -------------------- ------------------/mnt/acfs test_snap 15.08.2010 12:04:14
4. Das Rückspeichern von Dateien aus dem Snapshot erfolgt mit Mitteln des Betriebssystems wie dem Copy-Befehl: # pwd /mnt/acfs/.ACFS/snaps/test_snap # ls –l -rw-r--r-- 1 oracle oinstall 17 Aug 15 11:57 test.txt
5. Das Löschen eines Snapshots erfolgt ebenfalls mit acfsutil: [root@dar12 ~]# acfsutil snap delete test_snap /mnt/acfs acfsutil snap delete: Snapshot operation is complete.
320
5.9 Resümee
5.8.4
ACFS verwalten
ACFS ist ein dynamisches Dateisystem, das heißt, es kann unterbrechungsfrei erweitert und verkleinert werden kann. Mit Veränderung der Größe des Dateisystems wird das unterliegende ACFS-Volume automatisch vergrößert oder verkleinert: [root@dar12 ~]# acfsutil size +100M /mnt/acfs acfsutil size: new file system size: 6710886400 (6400MB)
Für den Betrieb von ACFS sind folgende vier neue Hintergrundprozesse der ASM-Instanz zuständig:
VDBG: Volume Driver Background Process: Ist zuständig für die Extent-Verwaltung sowie das Vergrößern oder Verkleinern von Volumes
VBGx: Volume Background Process: Arbeitsprozesse zur Umsetzung von Anforderungen des ADVM-Treibers
VMBx: Volume Management Background Process: Setzt den Fencing-Mechanismus um ACFS: ACFS Background Process: Koordiniert die Mitgliedschaft im Cluster mit der ASM-Instanz Ähnlich wie im ASM selbst sind die Grenzen für ACFS-Dateisysteme hoch angesetzt, und man dürfte in der Praxis kaum darauf stoßen:
Unterstützung von Large File Support auf 64-bit-Plattformen mit einer Maximalgröße von einem Exabyte
Maximal 63 Snapshots Bis zu 64 Mountpoints (32-bit) und 256 Mountpoints (64-bit) Praxistipp Beachten Sie bei Planung und Einsatz von ACFS die folgenden Beschränkungen:
Verwenden Sie ACFS nicht für ein Root-Dateisystem. Speichern Sie in ACFS keine Dateien, die direkt von ASM unterstützt werden. ASM-Disks, die für die Speicherung von ACFS-Volumes vorgesehen sind, sollten nicht mit der ASMLIB behandelt werden.
Partitionieren Sie ADMV-Volumes nicht mit dem fdisk-Utility.
5.9
Resümee ASM hat sich zu einem stabilen Produkt für die Speicherung von Dateien der OracleDateibank und seit 11gR2 auch von sonstigen Dateien entwickelt. Es ist im Rahmen der Oracle HA-Software vollständig in den Stack für die Datenbank integriert und verbreitet sich zunehmend auch für Single-Instance-Datenbanken. Seine Features sind optimal auf den Datenbank-Betrieb zugeschnitten. ASM besticht durch eine Reihe von Online-Features, durch die die Downtime wesentlich reduziert wird. Dazu gehört das dynamische Hinzunehmen und Entfernen von ASM-Disks.
321
5 Automatic Storage Management Vergessen Sie nicht die Features zur Unterstützung der Datenbank-Performance wie die verschiedenen Striping-Arten, „Preferred-Mirror Read“, oder die gleichmäßige Verteilung der AUs über die ASM-Disks. Nicht zuletzt überzeugt die Vereinfachung der Administration durch die Verwendung von Oracle Managed Files. Alles in allem ist ASM ein Produkt, das immer da eingesetzt werden sollte, wo es möglich und sinnvoll ist.
322
6 6 Security Dieses Kapitel behandelt die drei großen „A“ der Security:
Authentifizierung (wer ist der Benutzer?); Autorisierung (was darf ein Benutzer?); Auditing (was hat ein Benutzer gemacht?). Außerdem werden wir auf die Verschlüsselung von Dateien und Netzwerk eingehen – und damit auf den Schutz unserer Daten vor Betriebssystems-, Netzwerk- und Backup-Administratoren.
6.1
Authentifizierung Oracle bietet mehrere Möglichkeiten, um sicherzustellen, dass sich nur berechtigte Benutzer anmelden. Die bekannteste (und am meisten benutzte) ist die Authentifizierung per Benutzernamen und Passwort. Aber je nach Umgebung kann auch eine der anderen Varianten sinnvoll sein.
6.1.1
Benutzername/Passwort
Ein Benutzer wird beispielsweise mit dem Befehl CREATE USER angelegt: CREATE USER user00 IDENTIFIED BY kadj123alkd09ads;
Dies ist die einfachste Variante. Außer dem Passwort kann dabei noch viel mehr definiert werden, zum Beispiel Quotas (Platzberechtigungen auf Tablespaces), Default und Temporary Tablespace, Profile oder der Account-Status. Über die Syntax − oder generell über diese Art der Authentifizierung – gibt es genügend gute Beschreibungen, nicht zuletzt die Oracle Dokumentation1 selbst. Deswegen hier einige Praxistipps, die den Umgang mit Passwort-authentifizierten Benutzern sicherer machen. 1
Oracle Database SQL Language Reference, Befehl CREATE USER
323
6 Security Praxistipps Installieren Sie nur die Optionen, die Sie wirklich benötigen. Oracle lagert Optionen häufig in eigene Schemas aus. Dadurch wird die Anzahl Benutzer erhöht − und damit auch das potenzielle Risiko.
Haben Sie eine Option installiert, ist es oft sinnvoll, den Schema-Owner zu sperren. Ein Anmeldeversuch (auch mit falschem Passwort) bringt dann die Fehlermeldung „Account locked“. Damit weiß ein Angreifer, dass diese Option installiert ist und kann eventuell vorhandene Sicherheitslücken ausnutzen. Besser ist es, ein „unmögliches“ Passwort zu setzen:
ALTER USER xdb IDENTIFIED BY VALUES 'geht sicher nicht'; Beachten Sie, auf welche Art die Passwörter geändert werden! Folgender Befehl übermittelt das Passwort im Klartext über das Netzwerk:
ALTER USER scott IDENTIFIED BY tiger; Verwenden Sie besser den in SQL*Plus eingebauten Befehl PASSWORD. Mit PASSWORD username können Sie Passwörter anderer Benutzer ändern, ohne Parameter ändern Sie ihr eigenes − und müssen dabei das alte Passwort angeben.
Überprüfen Sie, ob die Standardpasswörter von Oracle-Accounts wirklich geändert wurden! Oracle bietet dafür ab Oracle 11g eine praktische View:
SELECT * FROM dba_users_with_defpwd; USERNAME -----------------------------DIP HR OUTLN EXFSYS ORACLE_OCM SCOTT SYSTEM ... So sollte es nicht aussehen!
6.1.1.1 Case-sensitive Passwörter Ab Oracle 11g sind die Passwörter standardmäßig Case-sensitiv. Nicht alle Programme können damit umgehen und wandeln das Passwort in Großbuchstaben um, bevor sie es an die Datenbank schicken. Sollte es damit Probleme geben, kann man folgenden Initialisierungsparameter auf false setzen: sec_case_sensitive_logon = false
324
6.1 Authentifizierung Praxistipp Passwörter sind erst dann Case-sensitiv, wenn sie das erste Mal innerhalb 11g geändert (oder erstellt) werden. Nach einer Datenbankmigration sind die Passwörter noch auf dem alten 10g-Stand.
Mithilfe der View dba_users kann kontrolliert werden, ob ein Passwort schon „11g-ready“ ist: SELECT username, password_versions FROM dba_users; USERNAME –------------SYSTEM SYS SCOTT ...
Steht im Feld password_versions der Wert 10g (wie hier bei Scott), dann ist das Passwort nicht Case-sensitiv. Auch wenn das Passwort mit folgendem Befehl geändert wird: ALTER USER scott IDENTIFIED BY VALUES 'F894844C34402B67';
Es entsteht wieder ein 10g-Passwort, der Hash entspricht dem Passwort TIGER für den Benutzer Scott. Vor Oracle 11g war dieser Hash bei gleichem Benutzer und Passwort in jeder Datenbank gleich. Dadurch waren Manipulationen mit dem Hash möglich. Als Neuerung in 11g führt Oracle die Abhängigkeit der Passwort-Hashes von der Datenbank an. In der Tabelle user$ wird im Feld spare4 nun der Passwort-Hash und ein Salt gespeichert − aber nur, wenn es ein 11g-Passwort ist (siehe Datensatz von Scott): SELECT name, password, spare4 FROM user$; NAME PASSWORD SPARE4 ------ ---------------- -------------------------------SYS 5638228DAF52805F S:F55AF3D13FC4F670D5C1B16CFFCEF8 D0E6F16C694CE587F35979366D1D68 SYSTEM D4DF7931AB130E37 S:B873339271594D4A74E2844A7D11BF 65DF01F2B276FDECB19ED6D76BB683 SCOTT F894844C34402B67
Leider wird der alte Password-Hash standardmäßig noch immer im Feld password gespeichert. Die exklusive Benutzung von reinen 11g-Passwörtern ist möglich − bedarf aber einiges an Handarbeit2:
Nach einer Migration müssen alle Benutzer ihr Passwort mindestens einmal geändert haben (also in dba_users.password_versions darf in keiner Zeile mehr nur „10g“ stehen).
Alle Applikationen müssen daraufhin getestet sein, dass sie mit den 11g-Passwörtern umgehen können3.
2 3
Siehe Metalink Note 463999.1 Der JDBC-Thin-Treiber (Type 4) Version 10g und älter ist z.B. nicht kompatibel mit den 11g-Passwörtern, ebenso auch Oracle Clients der Version 9i
325
6 Security
In die Datei sqlnet.ora (auf dem Server) muss folgende Zeile eingetragen werden: sqlnet.allowed_logon_version=11
Die alten Passwörter müssen (als SYSDBA) aus der Benutzertabelle gelöscht werden: UPDATE sys.user$ SET password=NULL;
Die Tabelle mit der Passworthistorie muss geleert werden: DELETE FROM user_history$;
Erst nach diesen Schritten sind die „Altlasten“ beseitigt. 6.1.1.2 Passwortprofiles Standardmäßig sind bei Oracle keine Passwortrichtlinien aktiv. Dadurch ist ein Benutzer nicht gezwungen, sein Passwort jemals zu ändern. Außerdem sind keine Komplexitätsregeln festgelegt, so dass jedes beliebige Passwort (beliebige Länge, beliebiger Schwierigkeitsgrad, bekannte Wörter etc.) möglich ist. Ein Benutzer kann sich beliebig oft mit falschem Passwort anmelden, ohne gesperrt zu werden. Dies führt dazu, dass ein Benutzerpasswort oft ohne größere Schwierigkeiten herausgefunden werden kann, da viele Benutzer zu einfache Passwörter verwenden und ein Angreifer beliebig viele Versuche hat, das Passwort zu erraten. Sehr oft werden Namen (etwa der eigene Benutzername), Tiere, Geburtstage oder ähnlich offensichtliche Daten benutzt. Wurde ein Passwort herausgefunden, kann es über lange Zeit missbraucht werden, da kein Zwang besteht, dass Passwort nach einer bestimmten Anzahl von Tagen zu wechseln. Oracle bietet über Passwortprofiles die Möglichkeit, ein gutes Passwort zu erzwingen und die Änderung der Passwörter zu forcieren. Ein Teil der Parameter kann dabei direkt über den Befehl CREATE PROFILE (bzw. ALTER PROFILE) eingegeben werden, für den Komplexitätsteil ist eine PL/SQL-Funktion notwendig. Diese muss zwingend sys gehören. Syntaxbeispiel für die Änderung des Default-Profiles: ALTER PROFILE default LIMIT FAILED_LOGIN_ATTEMPTS 3 -- Lock nach 3 Fehlern PASSWORD_LOCK_TIME 10 -- für 10 Tage PASSWORD_LIFE_TIME 60 -- Passwort 60 Tage gültig PASSWORD_GRACE_TIME 7 -- Warnung 7 Tage vor Ablauf PASSWORD_REUSE_TIME 365 -- 1 Jahr nicht wiederbenutzbar PASSWORD_VERIFICATION_FUNCTION fkt_pwd_check /
Erstellen Sie Ihre Datenbanken mit dem Database Configuration Assistent (DBCA), wird seit Oracle 11g das Default-Profile automatisch angepasst: SELECT profile, resource_name, limit FROM dba_profiles WHERE resource_type='PASSWORD' PROFILE -------DEFAULT DEFAULT DEFAULT DEFAULT DEFAULT DEFAULT DEFAULT
6.1 Authentifizierung Praxistipp Haben Sie das Default-Profile geändert, gilt dies für alle Benutzer, also auch für Batch- oder Application-Server-Benutzer. Diese Programme haben aber normalerweise nicht die Möglichkeit der automatischen Passwortänderung. Erstellen Sie deswegen ein weiteres Passwortprofile mit den entsprechenden Parametern und weisen Sie dies den Application-Benutzern zu!
Oracle liefert ein gutes Beispielscript für eine Passwortfunktion mit: $ORACLE_HOME/rdbms/admin/utlpwdmg.sql
Praxistipps Benutzen Sie auch für eine ältere Datenbankversion das Script von Oracle Database Version 11g R2. Die enthaltenen Prüfungen sind wesentlich besser! Benutzen Sie dieses Script als Vorlage, starten Sie es aber nicht direkt, da dabei das Default-Profil angepasst wird, das heißt, Änderungen gelten für alle Benutzer.
Durch die im Script enthaltene Funktion werden typische Passwortrisiken minimiert, beispielsweise muss das Passwort mindesten acht Zeichen lang sein, jeweils mindestens ein numerisches und ein alphanumerisches Zeichen beinhalten, es muss sich um drei Zeichen vom alten unterscheiden und mehrere gebräuchliche Wörter sind ausgeschlossen. Praxistipp Überwachen Sie die Passwortfunktion! Diese bekommt als Parameter den Benutzernamen sowie im Klartext das alte und das neue Passwort übergeben. Sollte ein Angreifer diese Funktion manipulieren können, kann er die Passwörter in Tabellen speichern oder auch per Mail verschicken.
6.1.2
Authentifizierung über Betriebssystem
Oracle hat schon seit Version 5 die Möglichkeit eingebaut, bei der Anmeldung auf die Passworteingabe zu verzichten. Die Anmeldung erfolgt über folgenden Befehl: CONNECT /
Das System liest den Betriebssystem-Benutzername und stellt diesem den init.oraParameter os_authent_prefix (Default ops$) voran. Wenn sich also der Benutzer huber anmeldet, wird getestet, ob es einen Oracle-Benutzer ops$huber gibt, wenn ja, hat er ohne Passwort-Abfrage Zugang zu der Datenbank. Soll sich dieser Benutzer nur über Betriebssystem-Authentifizierung anmelden können (also nie mit Benutzernamen/Passwort), wird dies beim Anlegen (oder im Nachhinein) definiert: CREATE USER ops$huber IDENTIFIED EXTERNALLY; ALTER USER ops$huber IDENTIFIED EXTERNALLY;
Es ist denkbar, auch einen OPS$-DBA zu machen, um auf dem Datenbankserver privilegierte Jobs (nächtliche Exports etc.) auszuführen, ohne Passwörter in Programmen fest codieren zu müssen.
327
6 Security Diese Art von Benutzern ist gut geeignet, um direkt auf dem Server Operationen durchzuführen. Theoretisch ist es auch möglich, die Authentifizierung über das Netzwerk zuzulassen. Dazu muss der init.ora-Parameter REMOTE_OS_AUTHENT auf TRUE gesetzt werden. Praxistipp Wir raten dringend davon ab, da sonst an einem beliebigen Rechner ein Benutzer z.B. HUBER angelegt werden kann − und dieser kann sich dann ohne Passwort anmelden. Ab Oracle 11g R2 ist dieser Parameter deprecated und steht (richtigerweise) auf FALSE.
6.1.3
Authentifizierung per SSL und Zertifikaten
Außer über das Betriebssystem können Benutzer auch per SSL-Zertifikat authentifiziert werden. Dazu muss die SSL-Netzwerkumgebung komplett eingerichtet sein. Es braucht also eine interne oder externe Stelle, die Zertifikate für den Server und die Benutzer herausgibt. Diese sind dann in Wallets auf dem Server und dem Arbeitsplatzrechner gespeichert. Im Benutzerwallet muss der eindeutige Namen (Distinguished Name) eingetragen sein. Abbildung 6.1 zeigt den Oracle Wallet Manager.
Abbildung 6.1 Oracle Wallet Manager − Anzeige des „Distinguished Name“
Ein Datenbankbenutzer muss mit dem gleichen Namen angelegt sein: CREATE USER client1 IDENTIFIED EXTERNALLY AS 'CN=Client1, OU=Training, O=Trivadis, C=US';
Dann kann sich der der Benutzer ohne Passwort anmelden: sqlplus /@SSL_CONNECT
Das Script sousrinf.sql4 gibt dann die folgenden Authentifizierungs-Informationen aus: ... Authentification Information ---------------------------- SESSION_USER : CLIENT1 - CURRENT_USER : CLIENT1 - PROXY_USER : - AUTHENTICATION_TYPE : NETWORK - NETWORK_PROTOCOL : tcps - EXTERNAL_NAME : cn=Client1,ou=Training,o=Trivadis,c=US - OS_USER : Client1 ...
4 sousrinf.sql
328
kann unter www.trivadis.com heruntergeladen werden
6.1 Authentifizierung
6.1.4
Proxyuser
Proxyuser werden häufig von Applikationsservern benutzt. Sie sind aber auch sehr interessant für Wartungsarbeiten und für die Nachvollziehbarkeit von Änderungen. Nehmen wir an, das Schema hr ist unser Applikationsschema. Sind dort zum Beispiel Strukturänderungen notwendig, braucht es entweder das Passwort von hr (und dann sieht man nicht mehr, wer dies gemacht hat) oder ANY-Privilegien (und die gelten dann für die gesamte Datenbank). Die Alternative wäre, bestimmten Personen das Recht zu geben, als sich mit ihrem eigenen Passwort anzumelden:
hr
zu arbeiten, aber
CREATE USER user01 IDENTIFIED BY userpwd; ALTER USER hr GRANT CONNECT THROUGH user01; CONNECT user01[hr]/userpwd
Der (persönliche) Benutzer user01 bekommt keinerlei Rechte (nicht einmal CREATE SESSION) − aber er darf sich als hr anmelden (durch die eckigen Klammern im CONNECT Statement). Dadurch erhält er komplett alle Privilegien von hr und arbeitet als Schemaowner. Zur Nachvollziehbarkeit von Änderungen ist es wichtig, die richtige Funktion zu benutzen: SQL> show user USER is "HR" SQL> SELECT sys_context('userenv','proxy_user') FROM dual; SYS_CONTEXT('USERENV','PROXY_USER') ----------------------------------USER01
Nur die sys_context-Abfrage auf den Proxyuser ergibt das richtige Ergebnis und ist damit in eigenen Audit-Programmen (z.B. Triggern) anzuwenden.
user01
−
Hilfreich ist auch hier wieder das Script sousrinf.sql: ... Authentification Information ---------------------------- SESSION_USER : HR - CURRENT_USER : HR - PROXY_USER : USER01 - AUTHENTICATION_TYPE: PROXY - NETWORK_PROTOCOL : - EXTERNAL_NAME : oracle - OS_USER : oracle ...
Soviel zum Thema Authentifizierung. Nachdem wir nun diese Grundlagen kennen (Wer hat sich angemeldet?), wenden wir uns im nächsten Unterkapitel den Berechtigungen zu.
329
6 Security
6.2
Autorisierung Als Autorisierung bezeichnet man die Zuweisung von Privilegien an Benutzer bzw. Benutzergruppen. Nach dem Anlegen eines Benutzers in Oracle hat dieser keinerlei Berechtigungen (es sei denn, es wurden Berechtigungen an public erteilt) – er kann sich also nicht einmal anmelden. Die Berechtigungen (zumindest ein CREATE SESSION) müssen zuerst mit dem Befehl GRANT erteilt werden. Oracle kann Berechtigungen auf unterschiedlichen Ebenen erteilen:
Systemprivilegien (wie create session, alter user) Objektprivilegien wie SELECT, INSERT, UPDATE ... auf Tabellen und Views Ausführen von PL/SQL Berechtigungen auf Zeilenebene Berechtigungen für Netzwerk-Callouts (ab 11g) Hier gibt es genügend gute Literatur, die erklärt, wie man Privilegien erteilt. In diesem Kapitel geht es mehr darum, dass Sie die kritischsten Privilegien kennenlernen − sowie die Risiken, die bei unsachgemäßer Benutzung entstehen können. Jeder DBA weiß, dass ein Privileg nicht an public erteilt werden sollte, sondern immer Rollen anzulegen sind. Ziel ist, einem Benutzer zu jeder Zeit genau die Berechtigungen zu geben, die er für seine Tätigkeit braucht − aber nicht mehr („Principle of least privilege“).
6.2.1
Systemprivilegien
Eine Liste aller existierenden Systemprivilegien finden Sie in der View system_privilege_map. In Oracle 11g R2 sind es immerhin 208 Privilegien (in Oracle 10.2 waren es „nur“ 166). Nachfolgend die kritischsten davon − deren Zuteilung überwacht werden sollte. Dazu gehören alle ANY-Privilegien. Diese geben einem Benutzer die Berechtigung, auf alle Objekte der Datenbank (außer die des Schemas sys) zuzugreifen. Dies mag eventuell für einen bestimmten Zeitpunkt sogar sinnvoll sein (es existiert nur eine Applikation in der Datenbank − und der Applikationsverantwortliche soll auf alles Zugriff haben). Denken Sie jedoch an die regelmäßig wiederkehrenden Konsolidierungswellen. Auf einmal haben Sie noch weitere Applikationen in der gleichen Datenbank, niemand denkt an die ANYPrivilegien − und Ihr Verantwortlicher hat dann Zugriff auf alle Applikationen. Nachfolgend die wichtigsten ANY-Privilegien:
select
any table
Kann jede Tabelle lesen
330
6.2 Autorisierung
delete
any table | update any table | insert any table Kann jede Tabelle leeren bzw. ändern bzw. Datensätze einfügen
create
any trigger | alter any trigger
Kann Trigger auf Tabellen erstellen bzw. ändern, auf die keine Rechte vorhanden sind, und damit ohne Rechte Änderungen in eigenen Tabellen protokollieren
grant
any privilege
Kann alle Systemprivilegien an sich und andere erteilen
execute
any procedure
Ein User mit diesem Privileg kann Prozeduren und Funktionen in beliebigen Schemas ausführen
create
any library | alter any library
Benutzer mit diesem Privileg können Libraries anlegen/ändern und damit auf Betriebssystem-Kommandos zugreifen
select
any dictionary
Kann Data-Dictionary-Objekte lesen (und damit Passwort-Hashes5, SQL Statements, Berechtigungen ...)
create
any directory
Kann Directories auf Betriebssystem-Pfade anlegen und damit beliebige Dateien mit den Berechtigungen des Oracle-Software-Owners überschreiben (wenn execute-Rechte auf Package utl_file vorhanden – siehe weiter hinten) Weitere kritische Systemprivilegien sind:
exempt
access policy
Benutzer mit diesem Systemprivileg können Tabellen lesen, auch wenn diese durch Policies oder Label Security geschützt sind (siehe Kapitel 6.2.7)
alter
system
Kann diverse Eigenschaften der Datenbank manipulieren (Initalisierungsparameter, Trace einschalten, Session killen, ...)
alter
user
Kann das Passwort beliebiger Benutzer ändern und sich damit anmelden
unlimited
tablespace
Kann jeden Tablespace (auch Stillstand bringen
6.2.2
system)
beliebig füllen und damit die Datenbank zum
Objektprivilegien
Hier einige kritische Objekte, welche überwacht werden sollten, ob darauf Berechtigungen erteilt sind.
5
je nach Oracle Version
331
6 Security Tabellen und Views:
sys.aud$ Mit insert/update/delete-Rechten kann die Audit-Tabelle manipuliert werden
sys.user$ Wenn insert/update/delete-Rechte vorhanden sind, kann die Benutzerdefinitionen manipuliert werden (z.B. können Benutzer versteckt werden), mit select-Rechten können alle Benutzer und deren Passwort-Hashs eingesehen werden
dba_users Sieht alle Benutzer und deren Passwort-Hashs (abhängig von der Oracle Version)
sys.user_history$ Sieht alte (nicht mehr gültige) Passwort-Hashs und kann damit Rückschlüsse auf ein aktuelles Passwort ziehen Packages:
dbms_sys_sql Kann beliebige Befehle unter beliebigen Benutzern (auch sys) ausführen
utl_file Kann Files lesen und schreiben, auf die der Initialisierungsparameter utl_file_dir zeigt. Achtung: Diesen Parameter unbedingt kontrollieren, kann z.B. auf „*“ stehen. Am besten utl_file_dir nicht setzen, sondern ausschließlich mit Directories arbeiten, auf diese können Berechtigungen pro Benutzer vergeben werden (siehe Kapitel 6.2.3)
dbms_file_transfer Kann Files kopieren, auch von und zu entfernten Rechnern
dbms_backup_restore Kann Files kopieren, löschen etc.
6.2.3
Berechtigungen auf Directories
Auf Oracle Directories (eigentlich nichts anderes als Aliase auf physische Directories im Betriebssysteme) können Berechtigungen vergeben werden. Das READ- und das WRITERecht ist schon lang im Einsatz und wird für externe Tabellen und für das Package utl_file benutzt. Neu mit Oracle 11g R26 sind EXECUTE-Rechte auf Directories. Dies ist notwendig geworden, da nun mit externen Tabellen auch Scripte ausgeführt werden können. Im Grunde ist das ein sehr praktisches Feature, da diese Scripte, bevor die Dateien selbst gelesen werden, Vorbereitungsarbeiten ausführen können (z.B. Entpacken der Datei oder auch Transferieren der Datei von einem entfernten Rechner)7. 6 7
Steht im New Features Guide von 11.2, ist aber auch zurückportiert auf Oracle 11.1.0.7 und 10.2.0.5 Weitere Informationen und Beispiele dazu siehe http://www.svenvetter.com/2009/12/04/external_table1/
332
6.2 Autorisierung Praxistipp Hat ein Benutzer sowohl das WRITE- als auch das EXECUTE-Recht auf ein Directory (oder kann es sich selbst geben), kann er als Oracle Software Owner Scripte selbst schreiben und ausführen. Diese Privilegien sind dringend zu überwachen!
6.2.4
Fine-Grained Access für Netzwerk-Callouts
Hat ein Benutzer EXECUTE-Rechte auf die Packages utl_tcp, utl_smtp, utl_mail, oder utl_inaddr, konnte er bis Oracle 10g an beliebige Hosts8 Informationen schicken. Mit dem seit Oracle 11g eingeführten Package dbms_network_acl_admin lassen sich Access Control Listen (ACL) erzeugen, mit denen definiert wird, welcher Benutzer an welchen Host Callouts durchführen kann. Dies geht aber leider nur, wenn XDB installiert ist − Oracle speichert die ACL-Listen intern als XML-Files ab. Ansonsten kann man nur ein sysdba diese Packages benutzen: utl_http
EXEC dbms_output.put_line(utl_inaddr.get_host_name); BEGIN dbms_output.put_line(utl_inaddr.get_host_name); END; * ERROR at line 1: ORA-24248: XML DB extensible security not installed ORA-06512: at "SYS.UTL_INADDR", line 4 ORA-06512: at "SYS.UTL_INADDR", line 35 ORA-06512: at line 1
Ein Beispiel für die Definition einer ACL: BEGIN dbms_network_acl_admin.create_acl ( acl => 'scott_trivadis.xml', description => 'Allow scott to connect to trivadis', principal => 'SCOTT', is_grant => TRUE, privilege => 'connect' ); END; / BEGIN dbms_network_acl_admin.assign_acl ( acl => 'scott_trivadis.xml', host => 'www.trivadis.com' ); END; /
Der erste Package-Aufruf legt eine neue, leere ACL-Liste an und berechtigt Scott dafür. Durch den zweiten Aufruf wird definiert, auf welchen Host Zugriff gewährt wird. Es gibt hier noch einige Parameter mehr, beispielsweise die Einschränkung der Uhrzeit.
8
Natürlich muss der Host im Netzwerk (vom Datenbankserver aus) erreichbar sein
333
6 Security
6.2.5
Rollen
Rollen sind die Zusammenfassung von System- und Objektprivilegien. Sie können geschachtelt werden. 6.2.5.1
Rollenkonzept
Es empfiehlt sich, für jede Applikation ein gutes Rollenkonzept zu erstellen. Ansonsten wird es bei vielen Benutzern und vielen Objekten sehr schnell unübersichtlich − und es ist nicht mehr auf einen Blick ersichtlich, wer welche Privilegien hat. In der Praxis hat sich ein zweistufiges Rollenkonzept bewährt:
Stufe 1: Technische Rollen Pro Arbeitsschritt wird eine Rolle erstellt z.B. alle Privilegien für das Erstellen von Kundenaufträgen Stufe 2: Funktionale Rollen Pro Funktion wird genau eine Rolle erstellt, die alle technischen Rollen beinhaltet, die für diese Funktion benötigt wird Fängt ein neuer Mitarbeiter an, bekommt er genau eine Rolle entsprechend seiner Funktion zugewiesen Rollen lassen sich als Default-Rollen definieren, dann sind sie sofort aktiv. Aber Rollen können auch so erteilt werden, dass sie nach der Anmeldung noch nicht aktiv sind. Praxistipp Dies wird häufig gemacht, um Benutzern nach dem Anmelden erst einmal minimale Rechte zu geben (z.B. nur das Lesen von Daten). Die Applikation schaltet dann die weiteren Rollen ein. Es empfiehlt sich dann, diese zusätzlichen Rollen mit einem Passwort zu schützen − oder aber Secure Application Roles (siehe Abschnitt 6.2.5.3) zu benutzen.
Beispiel: GRANT ro_sales_read, ro_sales_write TO user12; ALTER USER user12 DEFAULT ROLE ALL EXCEPT ro_sales_write;
Nach dem Anmelden hat der Benutzer user12 nur die Read-Rolle: SELECT * FROM session_roles; ROLE -----------------------------RO_SALES_READ
Er kann aber mit dem Befehl einem Passwort geschützt ist:
SET ROLE
die Write-Rolle einschalten, die hier nicht mit
SET ROLE ro_sales_write, ro_sales_read; Role set. SQL> SELECT * FROM session_roles; ROLE -----------------------------RO_SALES_READ RO_SALES_WRITE
334
6.2 Autorisierung Praxistipp Achtung: Beim Befehl SET ROLE müssen alle Rollen angegeben werden, die gesetzt sein sollen. Ansonsten sind die Rollen, die vorher schon eingeschaltet sind (die Read-Rolle) wieder ausgeschaltet. Der Befehl schaltet also nicht Rollen zusätzlich zu den vorhandenen ein! Eine Variante wäre ein SET ROLE ALL; − aber dann dürfen die Rollen nicht durch ein Passwort geschützt sein!
6.2.5.2
Passwortgeschützte Rollen
Beim Anlegen der Rolle kann ein Passwort vergeben werden: CREATE ROLE ro_sales_write IDENTIFIED BY QhZ71_w#cG0YfQ;
Das Einschalten der Rolle ohne Angabe dieses Passworts erzeugt dann eine Fehlermeldung: SET ROLE ro_sales_read, ro_sales_write; SET ROLE ro_sales_read, ro_sales_write * ERROR at line 1: ORA-01979: missing or invalid password for role 'RO_SALES_WRITE'
Richtig wäre es so: SET ROLE ro_sales_read, ro_sales_write IDENTIFIED BY QhZ71_w#cG0YfQ; Role set.
Praxistipp Achtung: Das Passwort wird nur benötigt, wenn die Rolle eine Nicht-Default-Rolle ist. Default-Rollen sind immer eingeschaltet.
6.2.5.3
Secure Application Role
Eine andere Variante, Rollen zu schützen, ist die Secure Application Role9. Dabei wird eine Rolle mit einer PL/SQL-Prozedur verbunden und lässt sich nur durch diese PL/SQLProzedur einschalten. Dazu ein Beispiel: CREATE ROLE hr_clerk IDENTIFIED USING hr_security_clerk_pro;
In der Prozedur erfolgt ein einfacher Check auf den IP-Range. Wenn dieser mit 172 beginnt (also im internen Netz liegt), wird die Rolle eingeschaltet, ansonsten eine Fehlermeldung erzeugt: CREATE OR REPLACE PROCEDURE hr_security_clerk_pro AUTHID CURRENT_USER IS BEGIN IF SUBSTR(sys_context('userenv','ip_address'),1,4) = '172.' then dbms_session.set_role('hr_clerk'); ELSE raise_application_error(-20000, 'HR Work only allowed from within the Office');
9
Verfügbar nur in der Enterprise Edition
335
6 Security END IF; END; /
Versucht der Benutzer nun die Rolle mit dem Befehl SET einen Fehler:
ROLE
einzuschalten, bekommt er
SET ROLE hr_clerk; SET ROLE hr_clerk * ERROR at line 1: ORA-28201: Not enough privileges to enable application role 'HR_CLERK'
Erst das Einschalten per Prozedur-Aufruf würde klappen − hier aber nicht, da er nicht im entsprechenden Netzwerksegment ist: exec hr_security_clerk_pro BEGIN hr_security_clerk_pro; END; * ERROR at line ORA-20000: HR ORA-06512: at ORA-06512: at
6.2.6
1: Work only allowed from within the Office "HR_SECURITY_CLERK_PRO", line 8 line 1
Überwachung von Privilegien
Die folgenden Views zeigen, wer welche Privilegien erhalten hat:
dba_sys_privs Erteilte Systemprivilegien an Benutzer oder Rollen
dba_tab_privs Erteilte Objektprivilegien an Benutzer oder Rollen (im Namen steht zwar nur tab, aber es werden alle Objektarten angezeigt)
dba_role_privs Erteilte Rollen an Benutzer oder Rollen Die Kontrolle ist aber nicht einfach. Privilegien können direkt an Benutzer, an Rollen, an geschachtelte Rollen, an public etc. erteilt werden. Deswegen empfiehlt sich für die Überprüfung die Benutzung von Tools oder Scripts. In diesem Zusammenhang sei auf die Script-Sammlung von Pete Finnigan hingewiesen (www.petefinnigan.com Tools). Interessant für das Gebiet Autorisierung sind die Scripts, die mit „who“ beginnen, z.B. who_has_priv.sql zum Finden von Systemprivilegien und who_can_access.sql zum Finden von Objektprivilegien.
6.2.7
Virtual Private Database
In diversen Projekten taucht immer wieder folgende Anforderung auf: Innerhalb einer Tabelle sollen nur bestimmte Zeilen unter bestimmten Bedingungen sichtbar sein. Das klassische Beispiel dafür ist Mandantenfähigkeit, aber es gibt dafür noch viele weitere Anforderungen, beispielsweise dass Daten nur zu bestimmten Zeiten oder von bestimmten Rechnern aus sichtbar sind.
336
6.2 Autorisierung Auch ohne Virtual Private Databases (VPD) gibt es dafür mehrere Lösungsansätze − aber alle haben Nachteile:
Definition einer View und Zugriff nur über die View erlauben. Dieser Weg ist bei vielen Bedingungen schlecht administrierbar und bietet je nach Komplexität der View eine schlechte Performance
Einbau der Zugriffsrestriktionen in die Applikation. Diese Lösung lässt sich durch SQL*Plus, ODBC Tools etc. umgehen.
Zugriff nur über PL/SQL-Prozeduren. Das wiederum ist aufwendig. Hier kommt die Option „Virtual Private Database“ (nur in der Enterprise Edition, auch Row Level Security oder Fine Grained Access Control genannt) zum Tragen: Eine PL/SQL-Funktion wird fest mit der Tabelle verknüpft und bei jedem Zugriff auf die Tabelle aufgerufen. Die Funktion gibt als Returnwert eine Zeichenkette zurück, die an den Befehl als Where-Bedingung gehängt wird. So kann im einfachsten Fall ein „1=0“ zurückgegeben werden − und der Befehl liefert keine Daten. Im typischeren Fall wird nach Prüfung der Benutzerberechtigungen im PL/SQL ein Ausdruck wie „mandant=10“ oder „deptno=30“ zurückgeliefert. Im folgenden Beispiel soll zwar jeder die Tabelle scott.emp lesen können − aber nur seine eigenen Daten. Dazu wird eine Funktion angelegt, die als Return-Wert ename='' zurückgibt: CREATE OR REPLACE FUNCTION emp_restrict (schema IN varchar2, tab IN varchar2) RETURN VARCHAR2 AS BEGIN RETURN 'ename=''' || sys_context('userenv','session_user') || ''''; END emp_restrict; /
Praxistipp Es empfiehlt sich, diese Funktion in einem speziell für Security-Aufgaben gedachten Schema anzulegen. Ansonsten hätte der Schema-Owner die Möglichkeit, dies zu manipulieren. In vielen Fällen wird dafür ein Benutzer secusr angelegt.
Durch den nächsten Befehl wird die Funktion mit der Tabelle verbunden: BEGIN dbms_rls.add_policy ( object_schema => object_name => policy_name => function_schema => policy_function => ); END; /
6 Security Praxistipp Da die PL/SQL-Funktion bei jedem Zugriff ausgeführt wird, sollte sie so schnell wie möglich sein. Deswegen empfiehlt es sich, die Berechtigungsprüfung nicht bei jedem Aufruf durchzuführen. Idealerweise geschieht das beim Anmelden (Logon-Trigger) und man speichert die Resultate (z.B. Benutzer darf Abteilung 10 lesen) in einem selbst definierten Kontext. Dieser lässt sich dann per sys_context auswerten. Wir empfehlen hier dringend, ein gutes Konzept zu erstellen, das sowohl die Security- als auch die Performance-Aspekte berücksichtigt!
Zu beachten ist, dass Row Level Security auch für den „normalen“ DBA gilt. Dies hat großen Einfluss auf die Administrationsarbeiten. Ein konventioneller Export einer geschützten Tabelle ist so eventuell nicht (komplett) möglich! Dafür gibt es drei Lösungsmöglichkeiten:
Export als „as sysdba“ durchführen (wenn erlaubt und möglich) Der exportierende Benutzer darf aufgrund der Policy alle Daten sehen Der Benutzer bekommt das Privileg EXEMPT ACCESS POLICY, dadurch werden alle Policies ignoriert. Praxistipp Vereinzelt hört man, dass Row Level Security ein guter Schutz vor DBAs ist. Standardmäßig hat ein DBA das Systemprivileg EXEMPT ACCESS POLICY nicht, kann also nicht auf geschützte Daten zugreifen. Aber jeder DBA kann sich dieses Privileg jederzeit geben …
Ab Oracle10g kann auch eine Einschränkung auf Spaltenebene erfolgen. Dadurch wird erreicht, dass z.B. die nicht sicherheitsrelevanten Spalten aller Angestellten gelesen werden können, aber das Gehalt nur bei bestimmten Personen, für die die Berechtigung erteilt wurde (das heißt, für die die Policy-Bedingung zutrifft). Es existieren zwei Varianten:
Neben der einschränkenden Policy-Function werden Spalten definiert, die sicherheitsrelevant sind. Fragt man diese Spalten nicht ab, gilt die Policy nicht (es werden alle Zeilen angezeigt). Wird aber eine dieser Spalten abgefragt, wirkt die Einschränkung auf Zeilenebene. Definiert wird dies im Prozeduraufruf dbms_rls.add_policy: ... sec_relevant_cols => 'salary' ...
338
6.2 Autorisierung 6.2.7.2
Column Masking Behavior
Es werden unabhängig der Policy-Function immer alle Zeilen angezeigt. Gibt die Funktion für die aktuelle Zeile FALSE zurück, werden die Werte der sicherheitsrelevanten Spalten nicht angezeigt (sondern NULL). Definiert wird dies im Prozeduraufruf dbms_rls.add_policy: ... sec_relevant_cols => 'salary', sec_relevant_cols_opt => dbms_rls.all_rows ...
6.2.8
Database Vault
Das Thema „Database Vault“ würde ein ganzes Buch füllen. Deswegen konzentrieren wir uns hier auf die Punkte, die man nicht überall liest. Database Vault wird von Oracle als das Produkt positioniert, mit dem eines der letzten verbleibenden Risken im Datenbank-Security-Umfeld gelöst werden kann: Die Macht des DBA. Hier geht es genau darum, die Gewaltentrennung („Segregation of Duty“) durchzusetzen. Viele Richtlinien, Regularien oder Gesetze setzen voraus, dass der DBA keinen Zugriff auf vertrauliche Daten hat. Natürlich kann es auch im Firmeninteresse sein, dass er nicht alle Daten sehen und verändern kann − als Beispiel sind hier nur Betriebsgeheimnisse und Gehaltsdaten zu nennen. Da sehr viele Applikationen die Daten unverschlüsselt in den Datenbanken abspeichern, hat der Administrator aber immer vollen Zugriff. Und genau dies versucht Database Vault durch drei Mechanismen zu verhindern:
Schutz vor Spezialbenutzern (sysdba) Neue Rollen für Benutzer- und Berechtigungsmanagement (getrennt von anderen Administrationsarbeiten)
Neue zusätzliche Art des Zugriffsschutzes auf Objekte: Layer im Oracle Kernel, kommt nur bei System-Privilegien zum Zuge (typischerweise ANY-Privilegien, aber auch bei Befehlen wie ALTER
USER)
Keine Auswirkungen bei Objekt-Grants, außer durch Command Rules, wodurch die Ausführung jedes SQL Statements eingeschränkt werden kann Um nun die Gewaltentrennung durchsetzen zu können, muss klar geregelt sein, welche Tätigkeit durch welche Personengruppe wahrgenommen wird. Dabei hat sich folgende Aufteilung bewährt (die rechte Spalte bitte selbst ausfüllen):
339
6 Security Tabelle 6.1 Beispiel für ein Rollenkonzept mit Oracle Database Vault Task
Verantwortlich
Betrieb der DB und der Instanz (Erzeugen, Parametriseren, Instanztuning, Patching, Updates, Tablespace-Management, …) Security Management Anlegen von Realms10, Definition der zu schützenden Objekte Zuteilen der Benutzer zu Realms Anlegen von applikatorischen Rollen, Zuordnen von Objektprivilegien zu Rollen/Benutzern Account Management + Zuweisen von Rollen Anlegen von technischen Rollen, initiales Zuordnen von Systemprivilegien zu Rollen (nicht applikatorische Rollen!) Überwachung / Auditing der Konfiguration und der Zugriffe
Tätigkeiten, die sich im Vergleich zum klassischen DBA-Management geändert haben, sind kursiv dargestellt. Tabelle 6.2 zeigt, welche Risiken nicht durch Database Vault abgedeckt sind und jeweils eine empfohlene Maßnahme dagegen: Tabelle 6.2 Offene Risiken trotz Oracle Database Vault Risiko
Maßnahme
Daten in Datenfiles im Klartext (OS- und SAN-Admin sowie OracleUnix-Account kann Daten lesen)
Verschlüsselung der Datenfiles durch TDE (10g auf Spaltenebene, 11g auf Tablespace-Ebene)
Daten in Backups und Exports im Klartext
Verschlüsslung durch RMAN bzw. Datapump
sys-Account muss offen sein für RAC und RMAN Dieser ist nicht komplett durch DBV abgesichert
Personifizierte Accounts auf Unix und Datenbank + Sudo-Konzept Benutzung von sysoper Zulassen von sysdba-Connections nur zur RMAN-ConnectZeit
Während Patching (z.B. CPUs) sowie Migrationen muss DBV ausgeschaltet werden
Personifizierte Accounts auf Unix und Sudo-Konzept Überwachung auf Betriebssystemebene (inode+ctime Checks, z.B. manuell, Nimbus, iwatch (Linux, basierend auf inotify))
Daten im Klartext über Netzwerk bzw. Interconnect bei RAC)
Einsatz von ASO zur Verschlüsslung des Netzwerkes
10
340
Realms sind Container, mit denen definiert wird, welche Objekte geschützt werden sollen, also eine der Grundkonzepte von Database Vault
6.3 Auditing Risiko
Maßnahme
Direkte Object Grants
Bestehende Grants müssen bekannt sein bzw. kontrolliert werden
Applikatorische Exportmöglichkeiten
Können nur auf Applikations-Ebene überprüft werden, eventuell Einschränkungen über Rules (anhand IP, …)
Eventuell reicht eine sichere Authentifizierung und Autorisierung nicht aus. Es muss überwacht werden, wer was gemacht hat. Genau dazu wenden wir uns im nächsten Unterkapitel zu.
6.3
Auditing Auditing wird verwendet, um generelle Datenbankaktivitäten zu überwachen. Es kann auf unterschiedlichen Ebenen mit unterschiedlichen Ausgabekanälen eingeschaltet sein. Bevor Auditing aktiviert wird, sollte man sich ein paar Gedanken machen:
Was genau will ich erreichen bzw. muss ich erreichen, um Vorgaben umzusetzen? Darf ich dies überhaupt (Datenschutz)? Was kostet mich das an Performance und Speicherplatz? Wer wertet die Daten aus? Wer löscht die Daten wieder? Gerade die Frage nach den Geschwindigkeitseinbußen wird immer wieder gestellt. Sie kann aber nicht pauschal beantwortet werden. Je nach Anzahl der Auditeinträge, die entstehen, tendiert die Last fast gegen Null, wenn man aber wirklich jeden Befehl überwacht, wird sie sehr hoch. Praxistipp Schalten Sie deswegen Auditing nur sehr selektiv ein und nur für genau das, was Sie auswerten müssen − und überwachen Sie dringend den Inhalt und die Größe der Auditdaten!
Wichtig ist auch die Entscheidung, wo die Auditdaten gespeichert werden sollen. Jede Variante hat Vor- () und Nachteile ():
In der Datenbank Sehr einfach auszuwerten Kann durch DBA manipuliert werden
Im Dateisystem Je nach Berechtigungskonzept besserer Schutz vor DBAs11 (auf Betriebssystemebene sollten die Dateien überwacht werden, um Manipulationen zu erkennen) 11
Aber kein Schutz vor den Betriebssystem-Administratoren
341
6 Security Schwieriger auszuwerten12
Im Dateisystem als XML-Dateien Besser auszuwerten als „normales“ Auditing im Betriebssystem, da XML leicht weiterverarbeitet werden kann und es Views gibt, mit denen direkt aus der Datenbank per SQL auf die Dateien zugegriffen werden kann XML-Files sind recht groß und der Zugriff per View nicht sehr schnell
Im System-Log bzw. EventLog unter Windows Gut geschützt vor DBA-Manipulationen Schwierig auszuwerten, da erst ab Oracle 11g R2 der Datenbankname mitgeschrieben wird, extra Auswerte-Infrastruktur notwendig
Zentralisiert, zum Beispiel durch Oracle Audit Vault Schutz vor DBA bei richtiger Anwendung, gut auszuwerten Eigenes Produkt
6.3.1
Standardauditing
Es existieren zwei Hauptarten von Standardauditing:
Statement- und Privilegien-Auditing Objekt-Auditing 6.3.1.1
Statement- und Privilegien-Auditung
Hier werden bestimmte Statements oder die Benutzung von Privilegien protokolliert. Dazu ein einfaches Beispiel: AUDIT CREATE TABLE;
Immer wenn jemand eine Tabelle in seinem eigenen Schema oder auch in einem anderen Schema anlegt (dazu braucht er das CREATE ANY TABLE-Privileg), erzeugt dies einen Auditeintrag. Im Gegensatz dazu wird durch folgenden Befehl nur ein Auditeintrag erzeugt, wenn auch das CREATE ANY TABLE-Privileg benötigt wird: AUDIT CREATE ANY TABLE;
Es erfolgt kein Eintrag, wenn im eigenen Schema eine Tabelle angelegt wird und das Privileg CREATE TABLE vorhanden ist. Häufig werden ANY-Privilegien überwacht, da diese immer dann zum Einsatz kommen, wenn ein Benutzer nicht die entsprechenden Privilegien auf das Objekt hat, aber die Macht (z.B. als DBA), auf alle Daten zuzugreifen. Typische Beispiele wären hier SELECT ANY TABLE oder auch UPDATE ANY TABLE.
12
342
In den Dateien steht nicht die konkrete Aktion (z.B. CREATE INDEX), sondern nur eine Aktions-ID, siehe Beispiel in Abschnitt 6.3.1.3 „Auswertungen“.
6.3 Auditing Um den Umgang mit den vielen Optionen (angeblich) etwas zu erleichtern, fasst Oracle Optionen zusammen. So protokolliert folgender Befehl sowohl CREATE, DROP als auch TRUNCATE TABLE: AUDIT TABLE
Er protokolliert allerdings nicht ein fassungen sehr gut verstehen.
ALTER TABLE,
deswegen muss man diese Zusammen-
Es gibt hier drei Sonderfälle:
AUDIT
ALL STATEMENTS
Protokolliert alle „Top Level“-Statements, das sind die Befehle, die der Benutzer wirklich abgesetzt hat. Ruft er z.B. ein PL/SQL-Programm auf, wird dafür ein Eintrag geschrieben, nicht aber für alle Befehle, die innerhalb von PL/SQL ablaufen
AUDIT
ALL
Auditiert alle Statements, für die es eine Zusammenfassung gibt (wie TABLE), aber z.B. nicht ein ALTER TABLE oder ein GRANT auf eine Tabelle oder eine Prozedur13. Es werden dadurch nicht alle Befehle überwacht
AUDIT
ALL PRIVILEGES
Protokolliert alle Privilegien, die benötigt wurden In die Kategorie Privilegien-Auditing gehört auch die Überwachung von Datenbankanmeldungen: AUDIT CREATE SESSION;
6.3.1.2
Objekt-Auditing
Hier wird auf Objekt-Ebene (Tabelle, PL/SQL, Sequence ...) festgelegt, welche Operation auditiert werden sollen. Ein Beispiel: AUDIT SELECT ON hr.employees;
Jeder lesende Zugriff auf die Tabelle hr.employees wird protokolliert − egal, mit welchem Privileg er ausgeführt wurde. Durch diese Auditing-Art lässt sich jeder Befehl sehr fein granular für jedes Objekt überwachen. Dazu noch ein paar Beispiele: AUDIT AUDIT AUDIT AUDIT AUDIT AUDIT
UPDATE ON hr.employees; INDEX ON hr.employees; AUDIT ON hr.employees; LOCK ON hr.employees; ALL ON hr.employees; EXECUTE ON sys.utl_file;
Die Befehle sprechen für sich. Tabelle würde protokolliert.
AUDIT ALL
meint wirklich „ALL“, jeder Befehl auf dieser
Ein Sonderfall ist folgendes Statement: AUDIT AUDIT ON DEFAULT;
13
Siehe Oracle Dokumentation („Database SQL Language Reference“, Kapitel Auditing)
343
6 Security Es schaltet Auditing für alle Objekte ein, die in Zukunft angelegt werden (ON wird jedes neue Objekt auf Änderungen der Audit-Definitionen überwacht.
DEFAULT).
So
Die Default-Optionen sind durch folgenden Befehl einsehbar: SELECT * FROM all_def_audit_opts; ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---/- S/S -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-
Die am Anfang etwas schwierig zu verstehende View bedeutet, dass Auditing als Default eingeschaltet ist (Spalte AUD) und zwar auf Session-Ebene (S), egal, ob der Befehl erfolgreich ausgeführt wurde (Buchstabe vor dem „/“) oder nicht. Dazu später mehr. 6.3.1.3
Auswertungen
Erfolgt das Auditing in der Datenbank, lassen sich alle Ergebnisse über die View dba_audit_trail abfragen. Steht der Initialisierungsparameter audit_trail auf „db,extended“, werden auch das ausgeführte Statement und eventuelle Bind-Variablen protokolliert. Dies ist die Einstiegs-View mit allen Audit-Arten. Häufig ist es aber übersichtlicher, wenn man die „spezialisierteren“ Views benutzt, z.B. dba_audit_session für Logon/Logoffs oder dba_audit_object für Auditing auf Objekt-Ebene. Erfolgt die Speicherung im Dateisystem, wird für jeden Prozess eine Datei geschrieben. Die Einträge sehen beispielsweise folgendermaßen aus: SESSIONID:[8] "78250339" ENTRYID:[1] "2" STATEMENT:[2] "10" USERID:[5] "SCOTT" USERHOST:[7] "ttdb00r" TERMINAL:[5] "pts/1" ACTION:[1] "9" RETURNCODE:[1] "0" OBJ$CREATOR:[5] "SCOTT" OBJ$NAME:[4] "TEST" NEW$OWNER:[5] "SCOTT" NEW$NAME:[3] "EMP" OS$USERID:[6] "oracle" DBID:[10] "3333478954"
Hier ist leider nicht auf Anhieb zu erkennen, dass es sich um einen CREATE INDEX-Befehl handelt. Nur durch den Wert „9“ im Feld action und dem Überprüfen der View audit_actions erscheint folgendes Ergebnis: SELECT * from audit_actions WHERE action=9; ACTION NAME ---------- ---------------------------9 CREATE INDEX
Werden die Daten als XML abgespeichert, sieht ein Eintrag wie folgt aus. Die Zeilenumbrüche wurden vom Autor eingefügt, normalerweise steht alles in einer Zeile: 1 <Session_Id>78260341 <StatementId>11 <EntryId>3 <Extended_Timestamp>2010-06-30T08:55:29.320900Z SCOTToracle <Userhost>ttdb00r 32173pts/10SCOTT
344
6.3 Auditing TESTSCOTTEMP908001C000E2B00000 <Scn>18464249 3333478954 <Sql_Text>CREATE INDEX test ON emp(ename)
Auch hier ist wieder die Aktion mit der Nummer 9 erforderlich. Der Unterschied ist aber, dass audit_trail auf xml,extended14 steht − und dadurch auch das Statement mitgeschrieben wird. Außerdem können die Daten über die View v$xml_audit_trail abgefragt werden: SELECT extended_timestamp, db_user, os_user, new_name, sql_text FROM v$xml_audit_trail; EXTENDED_ --------30-JUN-10 30-JUN-10
6.3.1.4
DB_USER -------SCOTT SCOTT
OS_USER NEW_NAME SQL_TEXT -------- -------- ------------------------------oracle drop index test oracle EMP create index test on emp(ename)
Weitere Klauseln des Audit-Befehls
Bei der Definition des Auditings kann man angeben, ob es nur bei erfolgreichen oder nur bei nicht erfolgreichem Befehl protokollieren soll (standardmäßig bei beiden). So können z.B. alle fehlerhaften Anmeldeversuche auditiert werden: AUDIT CREATE SESSION WHENEVER NOT SUCCESSFUL;
Die Auswertung würde dann so aussehen: SELECT os_username, username, timestamp, returncode FROM dba_audit_session; OS_USERNAME ----------oracle oracle
Im Feld returncode stehen die Oracle-Fehlernummern:
ORA-01017: invalid username/password; logon denied ORA-28000: the account is locked Außerdem kann eingeschränkt werden, für welche Benutzer das Auditing gelten soll (standardmäßig für alle): AUDIT CREATE SESSION BY sh, hr;
Dies geht leider nicht auf Objekt-Ebene, obwohl es gerade hier häufig gewünscht ist: AUDIT SELECT ON hr.employees BY sh; AUDIT SELECT ON hr.employees BY sh * ERROR at line 1: ORA-01708: ACCESS or SESSION expected
14
Die Änderung dieses Parameters erfordert einen Neustart der Datenbank
345
6 Security Hier hilft nur, entweder alle Statements für einen Benutzer oder alle Statements auf ein Objekt zu überwachen. Alternativ sind auch alle Befehle einer Session möglich (siehe Praxistipp weiter unten). Darüber hinaus lässt sich die Granularität festlegen:
BY
ACCESS
Protokolliert jede Ausführung eines überwachten Statements
BY SESSION (default) Bis Oracle 10g: Es wird pro Session und pro Objekt nur ein Auditeintrag geschrieben, also bei 100 Zugriffen innerhalb einer Session auf die gleiche Tabelle nur ein Datensatz
Ab Oracle 11g: Es wird jedes Statement einzeln protokolliert, aber die Auswertung ist schwieriger als BY ACCESS15 Praxistipps Wir empfehlen bei jedem Audit-Befehl explizit die Angabe der Klausel BY ACCESS. Häufig besteht die Anforderung, alle Befehle einer bestimmten Session aufzuzeichnen. Typischerweise wird in einem Logon-Trigger die Umgebung geprüft. Wenn der Benutzer z.B. nicht aus einem vertrauenswürdigen Umfeld (etwa vom Application Server) kommt, soll Auditing aktiviert werden. Oracle bietet seit Version 11g auch dafür die entsprechende Syntax: AUDIT ALL STATEMENTS IN SESSION CURRENT; Achtung: Dies muss innerhalb der zu auditierenden Session abgesetzt werden, am besten im Logon-Trigger. Mehr zu diesen Triggerarten erfahren Sie in Abschnitt 6.3.2.1 „Event-Trigger“.
6.3.1.5
Auditing für SYSDBA und SYSOPER
Standardmäßig ist das Auditing für sysdba und sysoper nicht eingeschaltet. Alle normalen Benutzer − und auch alle normalen DBAs − werden überwacht, nicht aber z.B. sys. Erst durch Setzen des Initialisierungsparameters audit_sys_operations auf „true“ wird für diese Benutzergruppe das Auditing gestartet. Die Auditinformationen werden dabei immer in Dateien geschrieben (unter Windows ins Eventlog), auch wenn der Parameter audit_trail auf „db“ steht. Die Statements stehen dann im Klartext in den Auditfiles: Tue Jun 29 14:51:08 2010 +02:00 LENGTH : '177' ACTION :[23] 'select * from scott.emp'
15
346
Im Feld action_name steht nicht die Aktion, z.B. SELECT.Dies muss über ses_actions ermittelt werden, der Inhalt ist aber nicht wirklich einfach lesbar (z.B. ---------S------. Hier muss man dann wissen, dass das „S“ nicht etwa für Select steht, sondern für success − und da es an 10. Stelle steht, es ein Select war)
Der Speicherort der Auditfiles wird durch den Initialisierungsparameter festgelegt. 6.3.1.6
audit_file_dest
Ausschalten von Audit
Zum Ausschalten des Audits dient der Befehl denen Audit eingeschaltet wurde. Ein Beispiel:
NOAUDIT,
ergänzt um die Klausel(n), mit
NOAUDIT CREATE SESSION;
6.3.1.7
Management der Audit-Informationen
Bis einschließlich Oracle 10g gab es nur eine Art des Managements für Audit-Daten: das manuelle Löschen der Tabellen (benötigt die DELETE_CATALOG_ROLE) bzw. der Dateien. Ab Oracle 11g R2 (und zurückportiert auf Oracle 11.1.0.716) führte Oracle das Package dbms_audit_mgmt ein. Damit sind eine Reihe von Management-Operationen (manuell und automatisch) möglich. Dies ist auch die erste dokumentierte Möglichkeit, die Audit-Tabelle in einen anderen Tablespace zu verschieben: BEGIN dbms_audit_mgmt.set_audit_trail_location( audit_trail_type => dbms_audit_mgmt.audit_trail_aud_std, audit_trail_location_value => 'audit_data' ); END; /
Dieser Aufruf verschiebt die Standardauditing-Tabelle (aud$) in einen neuen Tablespace audit_data17. Außerdem kann durch die Prozedur dbms_audit_mgmt.create_purge_job ein regelmäßiger Löschjob aufgesetzt sowie die maximale Größe und das maximale Alter von Auditdateien definiert werden.18
16
Das Package wurde auch auf 10.2.0.5 zurückportiert und ist für ältere Versionen als Patch erhältlich Je nach Oracle-Version reicht der Aufruf nicht aus. Eventuell muss mit dbms_audit_mgmt.init_cleanup zuerst das Management initialisiert werden (Fehler: ORA-46258: Cleanup not initialized for the audit trail). Dadurch wird die Audittabelle aber erst einmal in den SYSAUX Tablespace verschoben! 18 Die dazu benötigte Syntax ist sehr gut im Oracle Database Security Guide 11g Release 2 erklärt 17
347
6 Security
6.3.2
Auditing mit Triggern
Trigger sind eigentlich eher aus dem Bereich der Programmierung bekannt, aber auch sehr gut für Auditing einsetzbar. Es gibt zwei unterschiedliche Arten von Triggern: Event- (oder auch System-) und DML-Trigger. 6.3.2.1
Event-Trigger
Wie der Name schon sagt, feuern diese Trigger bei Events. Der (aus Security-Sicht) wohl am häufigsten genutzte Event ist der Logon. Hier können sowohl Überprüfungen gemacht werden (z.B. von wo meldet sich der Client an, zugelassen ist nur der Application Server) als auch Protokollierungen. Häufig wird hierbei die Abfrage auf die Benutzerdaten per sys_context benutzt: CREATE OR REPLACE TRIGGER LOGON_EMPLOYEE AFTER LOGON ON DATABASE BEGIN IF (sys_context('userenv','sessionid') != 0 ) then INSERT INTO system.logon_events ( l_user, l_id, l_osuser, l_host, l_ip, l_program, l_date) ( SELECT USER, sys_context('userenv','sessionid'), sys_context('userenv','os_user'), sys_context('userenv','host'), sys_context('userenv','ip_address'), program, sysdate FROM sys.v_$session WHERE AUDSID = sys_context('userenv','sessionid') ); END IF; END; /
Dadurch wird für jede Anmeldung (ON DATABASE, die Alternative dazu wäre ON SCHEMA) ein Datensatz in die selbst erzeugte Tabelle system.logon_events geschrieben. Unter anderem wird der Betriebssystembenutzer, der Maschinenname und die IP-Adresse des Clients protokolliert. Praxistipp Achten Sie darauf, dass Ihre Logon-Trigger immer gültig (valid) bleiben. Ansonsten ist kein Logon mehr möglich! Sollte dies doch einmal passieren (z.B. weil Sie ihre eigene Audit-Tabelle löschen), melden Sie sich als sys as sysdba an (das geht noch) und schalten Sie den Trigger aus bzw. stellen die Logik wieder richtig.
Weitere Arten der Event-Trigger würden bei Logoffs, Datenbank Start, Datenbank Stop oder bei Serverfehlern feuern. Außerdem gibt es Trigger für DDL-Operationen, mit denen z.B. Strukturänderungen überwacht werden können. 6.3.2.2
DML-Trigger
DML-Trigger setzt man ein, wenn man nicht nur die Operation als solches überwachen will, sondern auch die Werte protokollieren möchte (Wer hat wann was geändert). Ein Beispiel:
348
6.3 Auditing CREATE OR REPLACE TRIGGER AUDIT_EMPLOYEE_SALARY AFTER UPDATE OF salary ON hr.employees FOR EACH ROW DECLARE PRAGMA AUTONOMOUS_TRANSACTION; v_program varchar2(128); BEGIN SELECT program INTO v_program FROM sys.v_$session WHERE AUDSID=sys_context('userenv','sessionid'); INSERT INTO system.employee_audit (e_id, e_new_sal, e_old_sal, e_user, e_date, e_ip, e_prog) VALUES ( system.seq_empl_audit.nextval, :new.salary, :old.salary, user, sysdate, nvl(sys_context('userenv','ip_address'),' Local connect'), nvl(v_program,'unknown') ); COMMIT; END; /
Dadurch wird bei jedem Update auf die Tabelle employees ein Datensatz in die selbst erzeugte Tabelle employee_audit geschrieben. Protokolliert werden unter anderem der alte und der neue Wert des Feldes Gehalt sowie Benutzerinformation wie Name, IP-Adresse und Programm. Dies kann natürlich genauso mit Insert- und Delete-Befehlen geschehen.
6.3.3
Fine Grained Auditing
Häufig besteht die Anforderung, nur bestimmte (kritische) Statements auf Tabellen zu protokollieren. Ein Standardauditing auditiert auf Objektebene aber immer alle Befehle, und über DML-Trigger können Selects überhaupt nicht überwacht werden. Der oben genannten Anforderung kann man nur mit Fine Grained Auditung (FGA) gerecht werden. Die Policies werden mit dem PL/SQL-Package dbms_fga definiert. Ein Beispiel: BEGIN dbms_fga.add_policy( object_schema object_name policy_name audit_condition audit_column statement_types handler_schema handler_module enable END; /
Durch diesen Aufruf wird eine Policy mit dem Namen FGA_EMP_POL auf die Tabelle hr.employees definiert. Ein Auditeintrag wird erzeugt, wenn Daten abgefragt werden, bei denen das Feld Gehalt in der Abteilung 20 selektiert wird. Zusätzlich wird im Package system.my_event_handler die Prozedur send_mail aufgerufen. Durch so einen (optionalen) Eventhandler lassen sich beliebige Aktionen ausführen, z.B. das Verschicken von Mails an einen Security-Verantwortlichen.
349
6 Security Praxistipp Dieses Feature limitiert den Zugriff. Wenn im Eventhandler ein Fehler erzeugt wird (raise_application_error), erfolgt keine Anzeige der Daten.
Die protokollierten Daten lassen sich über die View schließlich SQL-Statement und Bind Variablen.
SQL_TEXT ---------------------------------------------------SELECT last_name, salary FROM hr.employees create table employee1 as select * from employees select salary from employees select salary from employees where department_id=20
Einige Dinge sind zu beachten: Ein ROLLBACK erzeugt Audit-Einträge und verschickt auch die E-Mail, wenn dies in einer benutzerdefinierten Prozedur programmiert ist. Ebenso werden die Einträge erzeugt, wenn ein Select-Statement sicherheitsrelevante Daten lesen könnte, dies aber nicht macht, da nicht alle Records gelesen werden. Dazu ein Beispiel: SELECT * FROM ( SELECT * FROM hr.empl_fga ORDER BY department_id DESC ) WHERE ROWNUM = 1;
Da der erste Datensatz nicht in der Abteilung 20 ist, sollte hier eigentlich kein Auditing erfolgen. Da Oracle aber bereits zum Parse-Zeitpunkt prüft und bei anderer Datenverteilung durchaus alle Bedingungen eingehalten sein könnten, ist dies aus Sicht des Autors durchaus vertretbar. Praxistipp Die im obigen Bespiel definierte Policy ist eigentlich falsch. Es sind hier Gehaltsänderungen in der Abteilung 20 möglich, obwohl genau dies verhindert werden soll. Felder, die in audit_condition vorkommen, müssen ebenso in audit_column vorkommen!
Ein Beispiel mit der Policy wie oben definiert: UPDATE empl_fga SET department_id=1 WHERE department_id=20; UPDATE empl_fga SET salary=100000 WHERE department_id=1; UPDATE empl_fga SET department_id=20 WHERE department_id=1; COMMIT;
Keiner dieser drei Befehle erzeugt einen Eintrag, obwohl das Gehalt der Mitarbeiter von Abteilung 20 auf 100.000 erhöht wurde. Im ersten Befehl kommt das Feld Gehalt nicht vor, im zweiten werden Daten der Abteilung 1 geändert und im dritten kommt wiederum Gehalt nicht vor.
350
6.3 Auditing Würde jetzt Gehalt in audit_column aufgenommen werden (dieses Feld klingt zwar nach Einzahl, hier können aber seit Oracle 10g beliebig viele Felder kommasepariert aufgezählt werden), würde wenigstens der erste Befehl protokolliert werden. Praxistipp Auch hier ist es wieder wie an vielen Stellen im Bereich Security: Die Umsetzung ist recht einfach, wenn aber kein gutes Konzept da ist, geschehen Fehler und die Securitymaßnahmen lassen sich umgehen.
6.3.4
Audit Vault
Regularien, Gesetze und Vorschriften wie SOX, Basel II und PCI-DSI fordern die manipulationssichere Aufbewahrung von Audit-Daten. Audit Vault geht genau in diese Richtung. In einer zentraler Oracle Datenbank (mit installiertem Database-Vault-Schutz) werden die Auditeinträge verschiedener Quellen gesammelt. Sie sind aus dem integrierten Data Warehouse abfragbar (etwa durch Business Objects). Für Auswertungen stehen über eine Weboberfläche (ähnlich Oracle Enterprise Manager) komfortable Reports zur Verfügung. Außerdem können Alarme definiert werden, um bei außergewöhnlichen Ereignissen schnell informiert zu werden. Die Grundlage ist immer das in der Datenbank definierte Auditing. Audit Vault erzeugt nicht selbst Einträge, es werden nur die existierenden Einträge abgeholt. Abbildung 6.2 zeigt die benötigten Komponenten.
Abbildung 6.2 Komponenten von Oracle Audit Vault
Der Audit Vault Agent ist eine separat zu installierende Software-Komponente und kann auf dem Audit Vault Server oder auf beliebigen anderen Servern installiert werden. Er kann Datenbanken auf beliebigen (auch entfernten) Servern überwachen.
351
6 Security Praxistipps Es empfiehlt sich, den Agent auf dem Datenbank-Server zu installieren. Nur dann kann er Daten aus Oracle Audit-Dateien sammeln, ansonsten nur aus der Datenbank selbst. Außerdem ist nur dann das „near realtime“-Sammeln sichergestellt. Installieren Sie den Agent immer als anderer Betriebssystem-Benutzer als Ihre Datenbanken. Das Passwort dieses Benutzers sollten die DBAs nicht kennen, um keine Manipulationen am Agent (Stoppen) vornehmen zu können.
Die Source ist eine logische Komponente und fasst die Zugangsdaten zu einer Datenbank zusammen. Dabei werden Benutzernamen und Passwort nicht in XML-Dateien abgelegt, sondern in einem „Secure External Password Store“, also in einem Wallet. Kollektoren sammeln dann die Daten effektiv. Es gibt sechs unterschiedliche Kollektoren:
DBAUD Collector: Sammelt Auditing-Events aus der Datenbank (Standard Auditing, Fine Grained Auditing)
OSAUD Collector: Sammelt Audit Events aus den Audit Files der Datenbank (z.B. sys Operation)
REDO Collector: Sammelt per LogMiner DML- oder DDL-Änderungen direkt aus den Redo Logs; damit lassen sich auch alte und neue Werte protokollieren
MSSQL Collector: Sammelt Daten aus Microsoft SQL Servern (Version 2000 und 2005) SYBASE Collector: Sammelt Daten aus SYBASE ASE Datenbanken DB/2 Collector: Sammelt Daten aus IBM DB2 Datenbanken (Version 8.2 und 9.5 unter Linux, Unix und Windows) Der Audit Vault Server nimmt die Daten der Agents entgegen und legt diese im zentralen Data Warehouse ab. Außerdem stellt er die Weboberfläche für Administration, Reporting und Alarmierung zur Verfügung. Auf das Data Warehouse kann auch durch andere Reporting-Tools (z.B. BO) zugegriffen werden, das Datenmodell ist dokumentiert. Die Installation von Audit Vault Server und Agents ist mit dem bekannten Oracle Universal Installer kein Problem. Im Vorfeld sollte man sich aber Gedanken über die Aufgabenverteilung und -trennung („Separation of duties“) machen, da sich in der Datenbank vier zusätzliche Accounts anlegen lassen:
Audit Vault Administrator Audit Vault Auditor Database Vault Owner Database Vault Account Manager Nur wenn dieses System verstanden und durchgesetzt wird, ist sichergestellt, dass nicht eine Person allein Auditdaten verändern kann! Standardmäßig werden keine Auditereignisse von Audit Vault gesammelt. Diese muss man pro Datenbank zuerst definieren. Um die Arbeit etwas zu erleichtern, lassen sich die Auditdefinitionen einer Datenbank auf eine andere kopieren. Im Management-Interface werden diese Informationen komfortabel verwaltet.
352
6.3 Auditing
Abbildung 6.3 Audit Vault Definitionen für eine Datenbank
Wichtig ist, dass in der Spalte „In Use“ (ist wirklich auf Datenbank-Ebene eingeschaltet) ein grüner Pfeil und in der Spalte „Needed“ (ist in der Audit Vault Console definiert) ein grüner Haken steht (siehe Abbildung 6.3). Ansonsten ist etwas anders gewünscht als effektiv eingeschaltet. Für die Auswertungen stehen neben einer Übersicht auf der Startseite diverse vordefinierte Berichte zu Verfügung. Diese können auch weiter angepasst (Filter, Felder, Sortierung, Markierung, Grafiken) und als eigene Berichte abgespeichert werden.
Abbildung 6.4 Audit Vault Report (Überblick)
Von hier aus kann dann in die Tiefe verzweigt werden, um die Details für einen Event zu sehen. Die Darstellung entspricht den Feldern in den Audit-Views der Datenbank. Oracle Audit Vault ist aber nicht nur für Oracle gedacht. Es können auch Informationen von weiteren Datenbanken abgeholt werden:
Microsoft SQL Server (2005 und 2008) C2 audit logs Server-side trace logs Windows Event log 353
6 Security
Sybase (ASE 12.5.4-15.0.x) IBM DB/2 (UDB 8.2-9.5) Die Darstellung ist dann identisch wie bei den Oracle Reports. Abbildung 6.5 zeigt ein Beispiel von einem Microsoft SQL Server.
Zusätzlich zu den Audit-Events sind auch Alarme möglich. Genauer gesagt, kann ein Audit-Event auch gleichzeitig ein Alarm sein. Die Alarmierung erfolgt in der Console, lässt sich aber auch als E-Mail oder zur BMC Remedy IT Service Management Suite weiterleiten.
6.4
Verschlüsselung 6.4.1
Verschlüsselung der Oracle Dateien
Abbildung 6.6 zeigt ein kleines Schaubild zur Verdeutlichung des Ziels und der Motivation von Datenverschlüsselung.
Abbildung 6.6 Motivation für Datenverschlüsslung
354
6.4 Verschlüsselung In den ersten drei Abschnitten dieses Kapitels haben wir uns mit den drei großen „A“ beschäftigt: Authentifizierung, Autorisierung und Auditing. Was ist nun aber, wenn sich ein Hacker nicht ordentlich an die Datenbank anmeldet und sich somit nicht überwachen lässt? Was ist, wenn er versucht, die Datendateien zu lesen oder sogar zu manipulieren? Was ist, wenn er ein Backup in die Hand bekommt und daraus für sich eine neue Datenbank (mit Ihren Firmengeheimnissen) aufbaut? Genau dagegen hilft die Verschlüsslung der Oracle Dateien. Und nicht mehr19! Es ist nicht ein zusätzlicher Autorisierungslayer, bei dem der Benutzer zuerst sein (persönliches) Passwort eingeben muss, um auf die Daten zugreifen zu können. Es gibt zwar schon ein Passwort (dazu später mehr), aber dies muss nur genau einmal pro Instanz eingegeben werden und die Verschlüsslung ist freigeschaltet. 6.4.1.1
Wallet
Für diverse Oracle-Features wird ein Wallet gebraucht:
Verschlüsselung von sensitiven Daten in Datenfiles, Backups und Exports SSL-Verbindung (Verschlüsselung, Integritätsprüfung und Autorisierung) Secure External Password Store Ein Wallet entspricht dem PKCS#12-Standard20 und es können sowohl Zertifikate als auch seit Oracle 10g R2 Passwörter gespeichert werden21. Die Tools mkstore oder orapki22. legen ein Wallet an. Die Datei, in der das Oracle-Wallet gespeichert ist, heißt ewallet.p12. Damit die Datenbank ein Wallet lesen kann, muss es geöffnet sein. Dafür gibt es zwei Varianten:
Öffnen des Wallets nach dem Starten der Instanz durch folgenden Befehl: ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY walletpassword;
Dieser Befehl muss aber noch jedem Datenbankstart neu eingegeben werden, sonst kann man nicht auf die verschlüsselten Daten zugreifen.
Auto Login einschalten: Dadurch lässt sich das Wallet immer abfragen, das Wallet-Passwort ist nicht mehr notwendig. Praxistipp Wir empfehlen, diese Art des Auto Logins nicht zu verwenden. Kann ein Administrator das Wallet ewallet.p12 und das zweite File cwallet.sso, der durch das Auto Login erzeugt wird, auf einen anderen Rechner kopieren, ist es auch dort geöffnet.
19
Viele Anwender erhoffen durch Verschlüsslung einen zusätzlichen Schutz vor normalen Datenbankbenutzern 20 Personal Information Exchange Syntax Standard, ein Dateiformat für private Schlüssel und Zertifikate 21 Für den „Secure External Password Store“ 22 mkstore ist etwas einfacher zu bedienen (hat auch weniger Möglichkeiten) und reicht meist für das Wallet-Handling aus
355
6 Security Befinden sich die Oracle-Daten und das Wallet auf einem Backup, ist dieses Backup nicht geschützt, da alle Daten wieder entschlüsselt werden können.
Ab Oracle 11g R223 gibt es wieder24 die sicherere Möglichkeit, ein Local Auto Login Wallet zu erstellen: orapki wallet create -wallet <wallet_location> -auto_login_local
Dieses bleibt nur auf der gleichen Maschine geöffnet. Wird es auf einen anderen Rechner kopiert, ist es einmalig wieder (lokal) zu öffnen. Für die Verschlüsselung benutzt Oracle ein zweistufiges Schlüsselsystem. Ein Schlüssel ist in der Datenbank gespeichert25 (für Spaltenverschlüsselung in sys.enc$), der zweite Schlüssel (Hauptschlüssel oder auch Master Encryption Key) ist außerhalb in dem Wallet gespeichert. Folgender Befehl erstellt den Master Key: ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY password26;
Existiert zu diesem Zeitpunkt noch kein Wallet, wird es automatisch erstellt, wenn das Default Directory vorhanden ist ($ORACLE_BASE/admin/$ORACLE_SID/wallet)27. Existiert bereits ein Master Key, wird ein neuer, zusätzlicher Key erstellt, der ab diesem Moment für neu zu verschlüsselnde Objekte zum Einsatz kommt. 6.4.1.2
Verschlüsselung auf Spalten-Ebene
Typischerweise verschlüsselt man nur einzelne, kritische Spalten. Der Grund dafür sind die doch recht vielen Einschränkungen, die diese Art der Verschlüsselung hat:
Nicht alle Datentypen sind unterstützt (Long, LOB28). Ausschließlich B*Tree Indizes sind unterstützt (keine Function Based Indexes). Index Range Scans sind nur bei Abfragen auf Gleichheit unterstützt (also kein LIKE, >, <, BETWEEN ...).
Die Definition von Fremdschlüssel auf verschlüsselten Spalten „n“ ist nicht möglich. Dazu ein Beispiel: ALTER TABLE employees MODIFY salary ENCRYPT USING 'AES256';
Durch diesen Befehl wird die Spalte salary in der Tabelle employees mit dem Verschlüsselungsverfahren AES256 (Advanced Encryption Standard mit einer Schlüssellänge von 256 Bits) verschlüsselt. Weitere mögliche Schlüssellängen sind 128 und 192 Bit, die eine etwas schlechtere Verschlüsselungsqualität, aber eventuell eine etwas schnellere Ver-
23 24 25 26 27 28
356
Rückportiert auch auf 11.1.0.7 Das gab es schon mit Oracle 9, da waren Wallets immer nur lokal gültig Jede Tabelle hat einen eigenen Schlüssel „password“ entspricht dem Wallet-Passwort Existiert das Directory nicht, kommt folgende Fehlermeldung: ORA-28368: cannot auto-create wallet Erst ab Oracle 11g, aber als ein neuer, erweiterter Datentyp: Secure Files
6.4 Verschlüsselung schlüsselung bieten. Außerdem ist noch das Verfahren Triple-DES (3DES168) möglich. Dieses sollte man heute aber nicht mehr benutzen, da die Sicherheit gering und die Geschwindigkeit nicht besser ist. Information über verschlüsselte Spalten liefert die View dba_encrypted_columns: SELECT table_name, column_name, encryption_alg, salt FROM dba_encrypted_columns; TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SAL ----------- ------------ ----------------- --EMPLOYEES SALARY AES 256 bits key YES
Wie Sie sehen, wird hierbei ein Salt definiert. Aus Security-Sicht ist das durchaus zu empfehlen. Ohne Salt (Syntax wäre dann NO SALT) werden Felder mit gleichem Inhalt auch gleich verschlüsselt. Wenn man also weiß, was Person A verdient, bekommt man alle Personen heraus, die gleich viel verdienen. Durch den Salt wird etwas „Salz“ in die Verschlüsselung gestreut, und gleiche Werte werden nicht mehr gleich verschlüsselt. Praxistipps Wollen Sie verschlüsselte Felder indexieren, sind diese mit NO SALT zu definieren. Der Wechsel von SALT zu NO SALT ist nicht direkt möglich, zuerst muss das Feld wieder entschlüsselt werden.
Seit Oracle 11g ist es nun auch möglich, LOBs zu verschlüsseln. Dazu wird der neue Speichermechanismus SECUREFILE benutzt: CREATE TABLE test_securefile (id number, data clob ENCRYPT USING 'AES256' ) LOB (data) STORE AS SECUREFILE;
6.4.1.3
Verschlüsselung auf Tablespace-Ebene
Mit Oracle 11g besteht nun die Möglichkeit, ganze Tablespaces zu verschlüsseln (mit allen Daten, Indizes, Lobs ..., die sich in diesem Tablespace befinden). Dadurch sind die Einschränkungen bei Verschlüsselung auf Spalten-Ebene aufgehoben29. Ein verschlüsselter Tablespace wird wie folgt angelegt (ein nachträgliches Ändern ist nicht möglich): CREATE TABLESPACE enc_test DATAFILE SIZE 50M ENCRYPTION USING 'AES256' DEFAULT STORAGE (ENCRYPT);
Alle Daten, die im Tablespace enc_test gespeichert werden, sind nun mit dem Verschlüsselungsverfahren AES25630 verschlüsselt. Die Verschlüsselung bleibt auch erhalten, wenn man die Daten während Operationen in andere Dateiarten (Undo, Temp, Redo) speichert.
29
Bei der Verschlüsselung von Spalten mit Oracle 11 bleiben auch die Einschränkungen. Nur wenn man ganze Tablespaces verschlüsselt, fallen sie weg.
357
6 Security Bei normalen Operationen fallen die Geschwindigkeitseinbußen für die Verschlüsselung nicht ins Gewicht. Sie betragen im Normalfall unter 1 Prozent, wenn genügend CPULeistung zur Verfügung steht. Nur wenn sehr große Massenoperationen stattfinden (etwa sehr viele Inserts), könnten schon bis zu 10 Prozent anfallen. Praxistipp Wenn möglich, verwenden Sie für Massen-Inserts Direct-Load-Operationen (INSERT APPEND). Dadurch sind die Einbußen wieder bei ca. 1 Prozent.
6.4.1.4
Tools
Das klassische Export-Utility, das seit Oracle 10g nicht mehr verwendet werden sollte, kann keine verschlüsselten Daten exportieren: exp enc_test/manager file=test.dmp tables=test_enc ... EXP-00111: Table TEST_ENC resides in an Encrypted Tablespace ENC_TEST and will not be exported
Deshalb ist hier zwingend DataPump (expdp) zu benutzen. RMAN lässt die Spalten und die Tablespaces verschlüsselt. Dies bedeutet, dass für eine Recovery das (geöffnete) Wallet benötigt wird. RMAN kann aber auch selbst verschlüsseln (per Wallet oder per Passwort).
6.4.2
Verschlüsselung und Integritätsprüfung des Netzwerkverkehrs
Oracle überträgt im Normalfall alle Daten im Klartext über das Netzwerk, einzige Ausnahme sind Anmeldepasswörter. Zeichenketten sind durch einen Sniffer wie z.B. Wireshark einfach lesbar. Aber auch number- und date-Datentypen sind zu erkennen. Die Übertragung erfolgt zwar in einem gepackten Format, das aber gut dokumentiert ist. Deshalb sollte man in einem Umfeld mit vertraulichen Daten über Verschlüsselung nachdenken. Verschlüsselung und Integritätsprüfung sind in der Advanced Security Option (ASO) enthalten31. Durch die Implementierung in die Netzwerkschicht ist deren Benutzung für die Applikation transparent. 6.4.2.1
Verschlüsselung
Die Verschlüsselung entweder auf Server- oder auf Client-Seite32 wird durch folgende sqlnet.ora-Parameter eingeschaltet:
Weitere Verfahren sind 3DES168, AES128, AES192; ohne Angaben: AES192 ASO muss getrennt lizenziert werden und ist nur für die Enterprise Edition verfügbar 32 Ein Server kann auch gleichzeitig Client sein, z.B. durch Database Links 31
358
6.4 Verschlüsselung Folgende Werte sind für beide Parameter möglich:
rejected accepted (Standardwert) requested required Abbildung 6.7 zeigt die Auswirkung der Parameter:
Abbildung 6.7 Auswirkung der encryption-Parameter
Praxistipp Wir empfehlen, mit dem Server-Parameter zu arbeiten, da dieser unter Kontrolle ist. Auf dem Client kann eventuell jeder die Parameter anpassen, wie er möchte. Wenn also eine Verschlüsselung zwingend notwendig ist, dann sollte der Parameter sqlnet.encryption_server auf required gesetzt sein.
Folgende Parameter geben an, welcher Algorithmus zum Einsatz kommt:
sqlnet.encryption_types_server sqlnet.encryption_types_client Folgende Algorithmen sind verfügbar (in aufsteigender Qualität):
DES (Data Encryption Standard) 40 und 56 Bit, heute nicht mehr als sicher zu betrachten 3DES (Triple DES)
359
6 Security
Zwei bzw. drei Schlüssel werden für eine Sequenz von Ver-, Entschlüsseln verwendet, Heute nicht mehr als sicher zu betrachten
RC4 (Rivest Cipher) 40, 56, 128 und 256 Bit Schlüssellänge Sicherer als DES und 3DES - aber unsicherer als AES, dafür hoher Ressourcenverbrauch
AES (Advanced Encryption Standard) ab Oracle9i R2 128, 192 und 256 Bit Schlüssellänge Heute als sicher zu betrachten Der Verschlüsselungsalgorithmus wird immer durch den Server ausgewählt. Es schickt der Reihe nach alle Algorithmen an den Client. Der ersten Treffer aus encryption_types_ server, der in encryption_types_client gefunden wird, kommt zur Anwendung33. Praxistipps Sollten Sie auf dem Server mehrere Algorithmen zulassen, definieren Sie diese unbedingt in absteigender Qualität. Ansonsten wird eventuell eine schwächere Verschlüsselung benutzt, obwohl Client und Server in der Lage wären, besser zu verschlüsseln.
Da die Geschwindigkeitseinbußen minimal sind, benutzen Sie immer den bestmöglichen Algorithmus „AES256“. Nur wenn Sie noch ältere Clients oder Datenbanken haben, wählen Sie „RC4_256“.
Eine typische sqlnet.ora auf dem Server hat folgendes Aussehen34: sqlnet.encryption_server = required sqlnet.encryption_types_server= (aes256, rc4_256)
Ob Verschlüsselung effektiv eingeschaltet ist, zeigt folgender Befehl (pro Session): SELECT sid, osuser, AUTHENTICATION_TYPE, NETWORK_SERVICE_BANNER FROM v$session_connect_info WHERE sid=32 AND network_service_banner LIKE '%encryption%'; SID OSUSER AUTHENTI NETWORK_SERVICE_BANNER --- ------ -------- ----------------------------------------------32 user00 DATABASE Oracle Advanced Security: encryption service fo r Linux: Version 11.2.0.1.0 - Production 32 user00 DATABASE Oracle Advanced Security: AES256 encryption ser vice adapter for Linux: Version 11.2.0.1.0 - Pr oduct
Praxistipp Nur wenn ein „encryption service adapter“ (hier AES256) angezeigt ist, ist die Verschlüsselung aktiv. Die erste Zeile heißt nur, dass Verschlüsselung vom Client aus möglich wäre. 33
Standardmässig sind alle Algorithmen zugelassen, deswegen muss auf dem Client keine Anpassung der sqlnet.ora vorgenommen werden 34 Vor Oracle 10g ist noch der Parameter sqlnet.crypto_seed mit einem Zufallswert zu initialisieren
360
6.4 Verschlüsselung 6.4.2.2
Integritätsprüfung
Verschlüsselung alleine schützt nicht vor der Manipulation von Datenpaketen im Netzwerk35. Deshalb wird typischerweise gemeinsam mit Verschlüsselung auch die Integritätsprüfung eingeführt. Dies deckt folgende Angriffsszenarien ab:
Datenmodifikation Löschen von Datenpaketen Zusätzliche Datenpakete (z.B. Replay Attacks) Die Datenpakete sind durch Sequenznummern und Prüfsummen (Hashwerte) geschützt. Bei einer Manipulation der Daten (Sequenznummer und/oder Prüfsumme falsch), bricht die Session ab. Die Definition der Integritätsprüfung ist ähnlich der Definition einer Verschlüsselung. Die Parameter heißen hier:
sqlnet.crypto_checksum_server sqlnet.crypto_checksum_client Auch die Werte und damit die Auswirkungen sind gleich (siehe Abbildung 6.8).
Abbildung 6.8 Auswirkung der crypto-checksum-Parameter
Folgende Parameter entscheiden über den Algorithmus:
sqlnet.crypto_checksum_types_server sqlnet.crypto_checksum _types_client Möglich sind hier md5 und sha1.
35
Ein Angreifer weiß dann zwar nicht, was er ändert, kann aber doch großen Schaden anrichten
361
6 Security Praxistipp Beide Algorithmen sind nicht mehr ganz aktuell. Verwenden Sie deshalb sha1.
Eine typische sqlnet.ora auf dem Server hat folgendes Aussehen: sqlnet.crypto_checksum_server= required sqlnet.crypto_checksum_types_server= (sha1)
Ob Integritätsprüfung effektiv eingeschaltet ist, wird durch folgenden Befehl (pro Session) kontrolliert: SELECT sid, osuser, AUTHENTICATION_TYPE, NETWORK_SERVICE_BANNER FROM v$session_connect_info WHERE sid=32 AND network_service_banner LIKE '% checksumming%'; SID OSUSER AUTHENTI NETWORK_SERVICE_BANNER --- ------ -------- ----------------------------------------------32 user00 DATABASE Oracle Advanced Security: crypto-checksumming s ervice for Linux: Version 11.2.0.1.0 - Producti on 32 user00 DATABASE Oracle Advanced Security: SHA1 crypto-checksumm ing service adapter
Praxistipp Nur wenn ein „crypto-checksumming service adapter“ (hier SHA1) angezeigt wird, ist die Integritätsprüfung aktiv. Die erste Zeile bedeutet nur, dass die Prüfung vom Client aus möglich wäre.
6.5
Resümee In diesem Kapitel sind die Grundlagen beschrieben, um eine sicherere Datenbank zu erhalten. Aber Sicherheit geht natürlich weiter. Nicht nur innerhalb Oracle kann man weit mehr in die Tiefe gehen, auch das gesamte Umfeld muss betrachtet werden. Denken Sie an Ihre Benutzer: Was nützt die sicherste Datenbank, wenn diese ihre Passwörter weitergeben? Oder denken Sie an die Applikationen: Wenn es dort einen Knopf „Export nach Excel“ gibt, können alle Daten sehr leicht abgezogen und weiterverarbeitet (verkauft?) werden. Sicherheit bedarf immer eines ganzheitlichen Konzepts. Deswegen nochmals die Ermahnung: Führen Sie nicht schnell mal eine Security-Komponente ein, erstellen Sie zuerst ein gutes Gesamtkonzept. Bei Oracle ist es teilweise sehr einfach, Sicherheitsoptionen einzuführen − ohne ganzheitliche Sicht ist dies auch gefährlich.
362
7 7 Oracle Net In diesem Kapitel erfahren Sie:
welche Oracle Net Architekturen es gibt; wie man client- und serverseitige Konfigurationen erstellt; welche Werkzeuge man dafür einsetzen kann; welche Möglichkeiten es für die Performance Optimierung gibt; welche Hilfsmittel für eine effiziente Fehlersuche zur Verfügung stehen. Oracle Net ist gleichzeitig das Bindeglied und die Entkopplungsschicht zwischen Applikationen und Datenbanken. Diese Komponente des Oracle Software Stacks ermöglicht die Umsetzung von Client/Server- als auch von 3-Tier-Architekturen1 und ist die Basis für die logische und physikalische Trennung von Informationen und Funktionen innerhalb eines Netzwerks. Die Unterstützung verschiedener Standard-Netzwerkprotokolle,2 welche auf praktisch allen Rechner und Betriebssystemen implementiert sind, ermöglicht eine plattformunabhängige Kommunikation der Applikationen mit den Daten. Mit einfachen Mitteln ist bei mehreren verfügbaren Datenbankinstanzen eine automatische Lastverteilung konfigurierbar (Loadbalancing), zudem sind Funktionalitäten für das Weiterleiten von Verbindungsanfragen auf andere Knoten im Problemfall (failover) vorhanden. Oracle Net Softwarekomponenten erledigen auch das Verbinden von Datenbanken untereinander (Datenbank-Links), um applikationstransparent die gemeinsame Nutzung von Daten sicherzustellen. Sie erhalten Parametrisierungsvorschläge für Netzwerk-Tuning und erfahren zusätzliche Information für die Fehlersuche. Eine kurze Empfehlungsliste aus der Praxis, sowie ein Resümee runden das Kapitel ab.
1
Eine Drei-Schicht-Architektur beinhaltet einen Applikationsserver als mittlere Schicht, siehe auch Abschnitt 7.1.3.3 „Three-Tier-Architektur (Multi Tier)“. 2 Heute wird hauptsächlich das Protokoll TCP eingesetzt
363
7 Oracle Net
7.1
Oracle Net Architektur Kommunikation beinhaltet immer einen Sender und einen Empfänger. Dabei spielt es keine Rolle, ob der Sender auf demselben Rechner läuft wie der Empfänger oder nicht, das Prinzip ist immer mit Client/Server-Verbindung darstellbar. Auch bei einem mehrschichtigen Applikationsdesign (Drei-Schicht-Architektur) ist Oracle Net zwischen der mittleren Schicht, dem Applikationsserver, und dem Datenbank Server involviert. Der Applikationsclient ist dann in dieser Topologie ein schlanker Darstellungsprozess (z.B. ein Webbrowser), der wenig Ressourcen benötigt und sich mit dem Applikationsserver verbindet. Früher wurden Applikationsprogramme und Datenbanken vielfach auf denselben Rechnern betrieben. Dies hatte entscheidende Nachteile, die sich vor allem in der Auslegung der Hardware und der gegenseitigen Beeinflussung zeigten. Mit entsprechenden Netzwerktopologien und der Trennung von Benutzer-, Applikations- und Datenbankknoten ist eine Entkopplung der Systeme gegeben und demzufolge auch eine spezifische Auslegung der Maschinen auf die Bedürfnisnisse im Bereich von CPU-, Memory-, I/O- und auch Sicherheitsanforderungen. Dies ermöglicht dann auch die Trennung von Datenbank- und Applikationsbetrieb, der vielfach organisatorisch mit reinen Datenbankadministratoren- und Applikationsbetriebsteams umgesetzt wird.
7.1.1
Involvierte Komponenten
Die Kommunikation eines Client-(Programs) mit der Datenbank betrifft verschiedene Komponenten:
Clientprogramm Netzwerkschichten Listenerprozess Datenbankprozesse (Vordergrund- und Hintergrundprozesse) Für einzelne dieser Komponenten sind verschiedene Ausprägungen möglich, um praktisch alle heutigen Verbindungsanforderungen zu erfüllen. Abbildung 7.1 zeigt das Grundschema. Client
Server Programm
Listener
Netzwerk schicht
Netzwerk schicht
Netzwerk
Server Prozess
Abbildung 7.1 Oracle Net Prozessarchitektur
364
Datenbank
7.1 Oracle Net Architektur
7.1.2
Netzwerkschichten
Die Implementierung der Netzwerkschicht wurde auf verschiedenen Ebenen vollzogen. Basierend auf dem OSI-Modell (Open Systems Interconnection) bindet Oracle auf Serverund Clientseite den Oracle Net Foundation Layer und den Oracle Protocol Support ein. Der Foundation Layer erstellt und unterhält die Verbindung von der Applikation zum Datenbankserver. Die eingesetzte Transparent Network Substrate (TNS) Technologie kommuniziert mit den standardisierten Netzwerkprotokollen durch die Protokollschicht. Tabelle 7.1 Oracle Net im Bezug zum OSI 7-Schichtenmodell OSI Schicht
Oracle Schicht
Verwendung
Presentation
TTC (Two-Task Common)
Konvertiert Zeichensätze und Datenformate
Session
Oracle Net Foundation Layer (TNS)
Erstellt und unterhält die Verbindungen mit TNS (transparent network substrat) Technologie, implementiert auch die Namensauflösung und Sicherheitsfunktionalität
Protocol Support
Stellt die Schnittstellen zu den Standard Protokollen dar (TCP/IP3, TCP/IP mit SSL, SDP, named Pipes)
Application
Transport Network Data Link Physical
Auf der Applikationsseite wird über das Oracle Call Interface (OCI) kommuniziert. Auf der Serverseite ist das Oracle Program Interface (OPI) implementiert, das für jede Anfrage (Statement) vom OCI eine Antwort liefert. Das OCI bietet Schnittstellen zu den Applikationsprogrammen an, die je nach verwendeter Programmiersprache mittels Pre-CompilerBearbeitung auf diese Funktionalitäten zugreifen. Für Java Applikationen gibt es zwei Treiber, um auf den Datenbank Server zuzugreifen. Der sogenannte „JDBC Thin Driver“ hat die Java Database Connectivity mit Oracle Net Funktionalität direkt implementiert und benötigt keine zusätzliche Oracle Software Installation auf der Clientseite mehr. Er kommuniziert direkt mit dem Listener auf dem Datenbank Server. Aufwändiger ist der Einsatz des JDBC OCI Drivers, der eine Oracle Clientinstallation mit den OCI Libraries erfordert, aber dadurch auch die komplette Protokollunterstützung inkl. Inter Process Communication (IPC) von Oracle Net besitzt.
3
Ab Oracle 11g R2 ist neben IP Version 4 auch IP Version 6 unterstützt
365
7 Oracle Net Client
Server
Client Application (über OCI)
Oracle Net
RDBMS (über OPI)
Presentation – TTC
Naming Methods
Presentation – TTC
Oracle Net Foundation Layer
Security Services
Oracle Net Foundation Layer
Oracle Protocol Support
Oracle Protocol Support
Transport Protocol (TCP/IP, TCP/IP mit SSL, SDP und Named Pipes)
Transport Protocol (TCP/IP, TCP/IP mit SSL, SDP und Named Pipes)
Oracle Net
Abbildung 7.2 Client/Server Netzwerkschicht
JDBC OCI Driver Stack Java Client Application
JDBC Thin Driver Stack
JDBC OCI Driver (über OCI)
Java Applet/Application
Presentation – TTC
JDBC Thin Driver
Oracle Net Foundation Layer
Presentation – Java TTC
Oracle Protocol Support
Java Net
Transport Protocol (TCP/IP, TCP/IP mit SSL, SDP und Named Pipes)
TCP/IP Network Protocol
7.1.3
Abbildung 7.3 JDBC Drivers
Oracle Net in den Applikations-Topologien
In den verschiedenen Applikations-Topologien kommen folgende Oracle Net Komponenten und Treiber zum Einsatz:
Single Tier: Nur eine Schicht ist im Einsatz und somit keine netzwerkmäßige Trennung zwischen Applikations- und Datenbankprozessen. Die Prozesse kommunizieren via Interprozesskommunikation (IPC)4, da sie auf demselben Rechner laufen.
4
366
Wenn der Listener nicht involviert ist, setzt Oracle das BEQUEATH-Protokoll ein, dabei muss der Client und der Serverprozess aus demselben ORACLE_HOME gestartet werden
7.1 Oracle Net Architektur
Two Tier: Der Benutzerprozess beinhaltet die Applikations-Funktionalität und ist ein sogenannter „fat client“, der direkt mit der Datenbank Verbindung aufnimmt und somit eine Zwei-Schichten-Architektur darstellt.
Three Tier (Multi Tier): Der Benutzerprozess ist ein schlanker Darstellungsprozess (z.B. ein Webbrowser), der wenig Ressourcen erfordert und sich mit dem Applikationsserver verbindet. Er hat die Funktionalität der Applikation und verwaltet die Verbindungen zur Datenbank. 7.1.3.1 Single-Tier-Architektur In heutigen Architekturen werden, wenn überhaupt, nur noch wenige Applikationsteile auf der gleichen Schicht wie die Datenbank betrieben. Meistens sind das Batchprozesse wie das Laden oder Entladen von Daten. Dabei kann der Prozess eine Eigenentwicklung sein oder auch ein Oracle Werkzeug wie sqlplus, expdp oder impdp, die direkt auf dem Datenbank Server gestartet werden. Die Kommunikation mit den Datenbankprozessen findet über betriebssystemspezifische Funktionen statt und involviert die Netzwerkinfrastrukturen nicht. 7.1.3.2 Two-Tier-Architektur Die klassische Zwei-Schicht-Architektur (siehe Abbildung 7.4) lässt den Client mit dem Datenbankserver über das Netzwerk kommunizieren. Dadurch sind der Distanz nur physikalische Grenzen in Form von Bandbreite und Latenzzeit gesetzt. Durch die Einbindung der entsprechenden Oracle Net Libraries ist die Kommunikation über das Netzwerk transparent für die Applikation. Client
Server Application
RDBMS
Oracle Net
Oracle Net
TCP/IP Netzwerk
Datenbank
Abbildung 7.4 Client/Server-Architektur
Diese Architektur gibt es auch noch als Server/Server-Architektur. Kommuniziert der eine Datenbank Server mit einem anderen, dann tritt er als dessen Client auf. Die Implementierung erfolgt mittels Datenbank-Link, wobei der Zugriff von der initiierenden Seite − entsprechend ihrer Berechtigungen auf dem Zielsystem − schreibend oder lesend sein kann. Es sind dieselben Netzwerk-Schichten im Einsatz wie bei einem normalen ClientZugriff. Dies hat zur Folge, dass ein Datenbank-Server auch mit einer Client-Konfiguration ausgestattet sein muss (Details dazu in Abschnitt 7.2.3).
367
7 Oracle Net 7.1.3.3 Three-Tier-Architektur (Multi Tier) Hier ist neben dem Benutzer und dem Datenbank-Server-Knoten auch ein ApplicationServer-Knoten involviert. Ein Application-Server führt als Middle-Tier die Oracle-NetKommunikation auf die Datenbank.
Client
HTTP Protocol
Application Web Server
TCP/IP Netzwerk
Database Server
Application
RDBMS
Oracle Net
Oracle Net TCP/IP Netzwerk Datenbank
Abbildung 7.5 Drei Schichten Architektur
Meistens definiert und unterhält man in den Applikationen sogenannte „Connection Pools“, die dann von den aufgerufenen Funktionen der Benutzer eingesetzt werden.
7.1.4
Servicenamen
In älteren Oracle Versionen (8 und älter) war es nur möglich, durch die Angabe der Oracle SID eine Datenbankinstanz zu identifizieren. Mit den danach eingeführten Service-Namen können nun auf jeder Instanz verschiedene Dienstnamen bereitgestellt werden, die für die Verbindungsidentifikation der Applikation zu ihren Daten stehen. Erst dadurch lassen sich in Real Application Cluster5-Umgebungen Dienste hochverfügbar konfigurieren und auf den verschiedenen Instanzen starten, stoppen und verschieben. Durch die Angabe eines Servicenamens im Verbindungsdeskriptor wird dann die zustande kommende Verbindung von der physischen SID abgekoppelt und damit flexibler. Der Vorteil dieser Servicenamen ist auch bei Datenbankkonsolidierungen gegeben, wenn mehrere Applikationen auf derselben physischen Datenbank ihre Daten ablegen. Mit der Konfiguration von zwei Services (APPL1.dbnet.com, APPL2.dbnet.com) ist es möglich, durch Hinzufügen bzw. Entfernen des einen Servicenamens die Datenbank für die eine Applikation verfügbar zu machen bzw. zu sperren. Dies kann mit einer Anpassung des Parameters service_names durch ALTER SYSTEM gemacht werden oder mit dem PL/SQL Package dbms_service: BEGIN dbms_service.stop_service(' APPL1.dbnet.com'); END; /
5
368
Real Application Clusters (RAC) ist die Skalierungsfunktionalität, mit der Datenbankservices über mehrere physische Knoten und Instanzen hinweg skaliert und somit auch über Knotenausfälle hinweg verfügbar gemacht werden
7.1 Oracle Net Architektur Funktionalitäten wie Dataguard6 oder Real Application Clusters basieren auf diesen Servicenamen und haben vorgegebene Defaultwerte, etwa für die Definition von Logtransport und Brokerzugriff.
7.1.5
Service Registrierung
Damit der Listenerprozess überhaupt Verbindungswünsche erfüllen kann, muss er wissen, welche Datenbankservices auf dem jeweiligen Server zur Verfügung stehen. Dies erfolgt mit der Registrierung der Datenbank über den Hintergrundprozess pmon. Dieser meldet die konfigurierten Servicenamen an den über den Initialisierungsparameter local_listener gesetzten Listenerprozess: ALTER SYSTEM SET local_listener = (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST= dbserver01)(PORT=1523)))
Alle Servicenamen, die im Parameter service_names definiert sind, werden dadurch dem Listener mitgeteilt. Als Defaultwert steht dort der global_name, der sich aus dem db_name mit der db_domain erweitert zusammensetzt. Praxistipp Starten Sie immer zuerst den Listener und erst dann die Datenbankinstanz, damit sich der pmon beim Startup anmelden kann. Sonst kann es vorkommen, dass beide Komponenten am Laufen, aber die Servicenamen noch nicht registriert sind, da der pmon nur alle 60 Sekunden den Listener prüft. Die Registrierung kann aber auch forciert werden: ALTER SYSTEM REGISTER;
7.1.6
Aufbau einer Verbindung zur Datenbank
Folgende Komponenten und Informationen sind nötig, damit ein Client-Prozess auf eine Datenbank verbinden kann:
Clientprogramm: Die selbstgeschriebene Applikation oder auch sqlplus Benutzername: Ein gültiger Benutzername in der Datenbank Passwort: Das gültige Passwort zum Benutzer Verbindungsdeskriptor mit der Angabe von: Protocol Server Port Servicename
6
Dataguard ist ein Framework für das Aufsetzen und Betreiben einer Standby-Datenbank, diese Funktionalität steht nur in der Enterprise Edition zur Verfügung
369
7 Oracle Net Der Client-Prozess macht eine Verbindungsanfrage auf den Server über den Port, der im Verbindungsdeskriptor definiert ist. Dort wird dem lauschenden Listenerprozess der gewünschte Servicename übergeben und wenn dieser beim Listener registriert ist, ein dedizierter Server-Prozess gestartet und die Verbindung dem Client übergeben. Bei der Konfiguration von Shared-Server-Architektur wird die Verbindungsanfrage einem dem Protokoll entsprechenden Dispatcher-Prozess zugewiesen und dem Client die Verbindungsinformation übergeben. Anschließend ist der Listener-Prozess nicht mehr in die Verbindung involviert und könnte auch gestoppt werden, ohne dass sie verloren gehen würde. Praxistipp Bei wenigen Verbindungen ist die Konfiguration von dedizierten Serverprozessen zu bevorzugen, da diese leistungsfähiger sind als geteilte Verbindungen mittels Shared Server. Bei vielen (je nach Leistungsfähigkeit des Datenbankservers mehrere hundert), wo Shared Server angebracht sind, sollten für bestimmte Verbindungen, die auf Durchsatz angewiesen sind, vor allem Batchprozesse, explizit dedizierte Serverprozesse konfiguriert werden. Dies kann mit dem Schlüsselwort SERVER=dedicated im Verbindungsdeskriptor erfolgen: ORADB_BATCH = (DESCRIPTION = (ADDRESS = (PROTOCOL = tcp) (HOST = dbserver01) (PORT = 1521) ) (CONNECT_DATA = (SERVICE_NAME = ORADB.dbnet.com) (SERVER = dedicated) )
7.1.7
Konfigurationsdateien
Drei Textdateien ermöglichen die Konfiguration von Oracle-Net-Komponenten. Sie beinhalten spezifische Parameter bzw. Kombinationen von Schlüsselwörtern, die entsprechende Werte enthalten.
sqlnet.ora: Wird auf dem Server und dem Client benötigt und ermöglicht die Konfiguration von Grundeinstellungen in Form von Verbindungsprofilen
tnsnames.ora: Ist die dateibasierende Ablage der Verbindungsdeskriptoren und ermöglicht die Namensauflösung eines Net-Servicenamens. der als Abkürzung für einen solchen Deskriptor in der Datei steht. Dies ist eine clientseitige Datei.
listener.ora: Beinhaltet die Konfiguration der Listenerprozesse auf dem DatenbankServer. Wie in Abschnitt 7.3 „Werkzeuge“ beschrieben, lassen sich die Dateien mit den grafischen Werkzeugen Net Manager oder Net Configuration Assistant erstellen. Hält man die Syntax ein, ist es kein Problem, bzw. sogar einfacher, Erweiterungen manuell mit einem Texteditor zu machen.
370
7.2 Konfiguration Für die Ablage der Dateien hat Oracle Default-Lokationen vorgesehen, die im jeweiligen unter dem network/admin Directory liegen, z.B.:
ORACLE_HOME
/u00/app/oracle/product/11.2.0/network/admin
Praxistipp Wir empfehlen, die Dateien aus den Softwareverzeichnissen auf den Datenbankservern zentral abzulegen. Dadurch ist die Verschiebung der Files bei einer Neuinstallation von Software nicht nötig und es gibt keine Konflikte mit doppelten Dateien. Damit diese Verschiebung transparent für das Oracle Environment ist, kann die Betriebssystemvariable TNS_ADMIN auf dieses Directory gesetzt werden, das den Programmen ermöglicht, die Dateien zu finden. Um alle Eventualitäten abzudecken, empfehlen wir, zusätzlich Links (bei Windows „Junctions“) auf diese Dateien aus den Softwareverzeichnissen heraus zu machen, damit auch Programme, welche die Umgebungsvariable nicht einlesen (können), auf die zentralen Dateien zugreifen können: mkdir -p /u00/app/oracle/network/admin cd $ORACLE_HOME/network/admin ln –s /u00/app/oracle/network/admin/tnsnames.ora tnsnames.ora ln –s /u00/app/oracle/network/admin/sqlnet.ora sqlnet.ora ln –s /u00/app/oracle/network/admin/listener.ora listener.ora export TNS_ADMIN=/u00/app/oracle/network/admin
7.2
Konfiguration Die Konfiguration der Kommunikation zwischen den Netzwerkteilnehmern hängt stark von deren Anforderungen ab. Soll eine dedizierte Verbindung hergestellt werden, soll die Verbindung verschlüsselt sein, soll im Fehlerfall auf einen anderen Server ausgewichen oder etwa eine Lastverteilung gemacht werden? Damit die Verbindung auch funktioniert sind die richtigen Oracle Versionen erforderlich, dazu ist die Client/Server Interoperability Support Matrix7 zu konsultieren. Dabei gilt generell, dass Versionen im Premier Support untereinander verbindungsfähig sind, bei älteren Versionen gibt es Einschränkungen (9i muss mindestens 9.2.0.4 und 10g mindestens 10.2.0.2 sein). Bei Fehlern in diesen älteren Versionen gibt es nur Fixes bei bestehenden Extended-Support-Verträgen. Ein Spezialfall ist der Oracle Client 11.2.0, der gegenüber einem 10.1.0 Server nicht unterstützt ist.
7.2.1
Verbindungsprofile mit sqlnet.ora
Die Konfigurationsdatei sqlnet.ora wird auf beiden Kommunikationsseiten benötigt und ermöglicht die Implementierung von Verbindungs-Profilen und deren Funktionalitäten:
Spezifizierung der default Client Domäne: NAMES.DEFAULT_DOMAIN=dbnet.com
7
Die Interoperability Support Matrix ist im „My Oracle Support“ unter der ID: 207303.1 verfügbar
371
7 Oracle Net Erweitert alle nicht mit einer Domäne qualifizierten Net-Servicenamen (ORADB wird im als ORADB.dbnet.com gesucht)
tnsnames.ora
Definition und Priorisierung der Namensauflösungs-Methode: NAMES.DIRECTORY_PATH=(tnsnames,ldap,ezconnect)
Löst den angegebenen Servicenamen zuerst über die lokale Datei tnsnames.ora auf und geht in zweiter Priorität auf einen definierten ldap-Server. Erst danach wird die easy connect Methode evaluiert, bei der man im Connectstring den Server, Port und Datenbank Servicename direkt angibt (siehe dazu Abschnitt 7.2.3.2 Weitere Methoden zur Namensauflösung)
Konfiguration von Logging und Tracing, wenn DIAG_ADR_ENABLED=OFF (neu bei 11g, default ON, dabei wird die Automatic Diagnostic Repository Struktur angewendet), jeweils auf Client- oder Serverseite mit Angabe von Verzeichnis und Filename:
Konfiguration von Advanced-Security-Optionen: SQLNET.ENCRYPTION_SERVER=required
Konfiguriert, dass nur verschlüsselte Verbindungen zum Server möglich sind
Konfiguration von Zugriffsrestriktionen: TCP.INVITED_NODES=(applclient01,applclient02,dbserver02)
Lässt den Zugriff nur von aufgelisteten Maschinen zu Es gibt eine Vielzahl von gut dokumentierten Parametern, in der Regel kommt man aber mit ein paar wenigen aus.
7.2.2
Serverseitig
Die Anbindung eines Datenbankservers an die Außenwelt erfordert einen Kommunikationspartner. In der Architektur haben wir gesehen, dass dazu ein Listenerprozess eingesetzt wird. Grundsätzlich genügt ein Listenerprozess pro Server, auf den sich alle Datenbankinstanzen registrieren. Es wird empfohlen diesen mit der höchsten RDBMS-Version auf dem Server zu betreiben. Bei mehreren Listener pro Server sind diese mit unterschiedlichen Namen zu versehen.
! 372
Hinweis Es gibt Konzepte für Failover-Clustersysteme, wo jede Datenbank ihren Listener hat, der mit einer virtuellen IP-Adresse im Ressourcenpaket von einem auf den anderen Server verschoben werden kann.
7.2 Konfiguration 7.2.2.1 Listener-Konfiguration Die Datei listener.ora ist eine serverseitige Datei, jeder Datenbankserver sollte eine solche enthalten. Ohne das Konfigurationsfile gelten für einen gestarteten Listenerprozess die Defaultwerte. Der Listenername ist „LISTENER“, das PROTOCOL heißt „TCP“, der HOST ist der Servername, auf dem der Prozess läuft, und der PORT ist „1521“. Eine Konfigurationsdatei (sehr empfohlen) hat folgende Struktur:
Kontrollparameter: Optional Listenername: Die Parameter haben den Listenernamen als Erweiterung Protokolladresse: Es sind mehrere Adressen möglich (ADRESS_LIST), auf denen der jeweilige Listener Verbindungsanfragen entgegennimmt, was verschiedene Protokolle und auch verschiedene IP-Adressen und Port-Kombinationen ermöglicht
Datenbankinstanzen: Der Listener hört auf diese (statisches Setzen ist nur nötig beim Einsatz von external procedure calls8 und heterogenous services9) Das folgende Listing zeigt ein Dateiausschnitt mit einem dedizierten Listenernamen und einer Adressliste, die auch noch Interprocess Communication (IPC) zulässt, was bei lokalen Verbindungen (z.B. external procedure calls oder agents) eine bessere Performance bringt: LISTENER1120 = (DESCRIPTION = (ADRESS_LIST = (ADDRESS = (PROTOCOL = IPC) (KEY = extproc) ) (ADDRESS = (PROTOCOL = TCP) (HOST = dbserver01.dbnet.com) (PORT = 1521) ) ) )
Beim statischen Definieren der Services hat die Sektion SID_LIST folgendes Aussehen, wobei auch hier eine SID_LIST-Klausel für die Auflistung mehrerer SID-Deskriptoren möglich wäre: SID_LIST_LISTENER1120 = (SID_DESC = (GLOBAL_DBNAME = ORADB.dbnet.com) (SID_NAME = ORADB) (ORACLE_HOME = /u00/app/oracle/product/11.2.0) )
8 9
Der Aufruf einer in C geschriebenen Prozedur aus PL/SQL heraus, der einen Listenerprozess macht Eine Heterogenous Service Konfiguration ist notwendig, wenn vom Datenbank-Server transparent auf Drittsysteme zugegriffen werden soll
373
7 Oracle Net
!
Hinweis Beim Einsatz des Dataguard Broker CLI (dgmgrl) wird eine statisch definierte SID_LIST verlangt, um die Instanzen restarten zu können. Der Wert des Attributs GLOBAL_DBNAME- muss dann folgendermaßen zusammengesetzt sein: db_unique_name_DGMGRL.db_domain
7.2.2.2 Start, Stop und Status des Listeners Für die Steuerung des Listenerprozesses steht ein Kommandozeilen-Programm zur Verfügung. lsnrctl (listener control utility) kann entsprechend dem Befehlsumfang die Prozesse starten, stoppen und auch ändern. Die Parameter werden direkt auf dem BetriebssystemPrompt übergeben: $ lsnrctl stop $ lsnrctl start $ lsnrctl reload LISTENER1120
Wenn der Listenername fehlt, bezieht sich der Befehl immer auf den Defaultnamen LISTENER. Einmal im CLI enthalten (Listener Shell), zeigt help die Befehlsliste an bzw. jedes Kommando wird direkt ausgeführt. Der Listenernamensbezug lässt sich mit set current_listener ändern: # lsnrctl LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 20-JUL-2010 Copyright (c) 1991, 2009, Oracle.
All rights reserved.
Welcome to LSNRCTL, type "help" for information. LSNRCTL> help The following operations are available An asterisk (*) denotes a modifier or extended command: start services save_config change_password set*
stop version trace quit show*
status reload spawn exit
LSNRCTL>
Eine detaillierte Sicht der Services und der Verbindungen ist mit dem Befehl möglich:
services
LSNRCTL> services Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dbserver01.mvn.ch)(PORT=1521))) Services Summary... Service "ORADB.dbnet.com" has 1 instance(s). Instance "ORADB", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:3 refused:0 state:ready LOCAL SERVER The command completed successfully
! 374
Hinweis Das Programm lsnrctl ist aus der richtigen Oracle Version heraus zu starten. Dazu muss zuvor das entsprechende Oracle Environment gesetzt sein (ORACLE_HOME).
7.2 Konfiguration Bis und mit Oracle 9i war die Sicherheit des Listenerprozesses ein großes Problem. Da in der Default-Einstellung für den Listener kein Passwort gesetzt war, konnte man von jedem beliebigen Rechner aus mit Kenntnis des Datenbankservernamens und der Portnummer auf den Listener zugreifen. Ab Version 10g ist das Sichern des Listeners mit einem Passwort nicht mehr nötig und auch nicht mehr empfohlen, da die Berechtigung über OS-Authentifizierung sichergestellt und mit folgendem listener.ora-Parameter konfiguriert ist: LOCAL_OS_AUTHENTICATION_<listener> = ON
Ab Oracle 11g R2 ist der Parameter PASSWORDS_<listener> in der mehr unterstützt und ist deshalb beim Upgraden zu entfernen.
listener.ora
nicht
7.2.2.3 Shared/Dedicated Server Der Einsatz von Shared Servern, welche die Clientprozesse bedienen, ist eher Not als Tugend und wird oft als Skalierungsmöglichkeit eingesetzt. Solange die Rechnerleistung dedizierte Prozesse unterhalten kann, ist es von Vorteil, für die Antwortzeiten jedem Anwender einen eigenen Prozess zuzuteilen. Bei Tausenden von offenen Verbindungen kann man aber dieses Verfahren nicht mehr anwenden. Es ist eine maximale Anzahl Prozesse zu definieren (mit dem Initialisierungsparameter MAX_SHARED_SERVERS) und dynamisch für die Anfragen bereitzuhalten. Die eigentlichen Prozesse, welche an die Client Session gebunden sind, heißen Dispatcher-Prozesse. Deren Aufgabe ist es, die Anfragen der ihnen zugeteilten Sessions aufzunehmen, in eine Request-Queue zu stellen und regelmäßig ihre Response-Queue zu lesen, um gegebenenfalls der Session die Antwort auf ihre Anfrage mitzuteilen. Dies kann natürlich nicht gleich schnell sein wie ein dedizierter Prozess, der vom Listener gestartet und dem Client für die ganze Sessiondauer zugewiesen wird. Der Engpass liegt dabei nicht bei den dynamischen Shared-Servern, sondern bei den fix zugeteilten Dispatchern. Durch clientseitiges Loadbalancing können diese ihre Last bei den registrierten Listener mitteilen und so wenigstens vor zusätzlichen Aufgaben geschont werden, wenn andere gleichzeitig unterlastet sind. Request-Queue
Dispatcher 1
Client Netzwerk
Dispatcher 2 Dispatcher 3
ResponseQueue 1 ResponseQueue 2 ResponseQueue 3
Listener
Shared Server Shared Server Shared Server Shared Server Datenbank
Dedicated Server Dedicated Server
Abbildung 7.6 Dedicated/Shared Server Architektur
375
7 Oracle Net 7.2.2.4 Listener und Initialisierungsparameter Die Datenbankinstanz muss von den Listener-Informationen Kenntnis haben. Dies wird ihr mittels Initialisierungsparameter mitgeteilt. Folgende Parameter sind möglich:
LOCAL_LISTENER: Für die Anmeldung der Instanz bei ihrem lokalen Listener REMOTE_LISTENER: Für die Anmeldung der Instanz bei den remote Listener (beim Einsatz von RAC)
DISPATCHERS: Meldet beim Einsatz von Shared-Servern die Dispatcherprozesse bei den Listener an Entweder sind in den Parametern die ganzen Listenerdeskriptoren angegeben oder man definiert anstelle von Net-Servicenamen im lokalen tnsnames.ora (siehe Kapitel 7.2.3.1 clientseitige Konfiguration) Listener-Aliases, die auf diese Deskriptoren verweisen. Sie haben dieselbe Syntax wie die Net-Servicenamen, werden aber ohne CONNECT_DATAKlausel definiert: LISTENER_DBSERVER01.dbnet.com = (DESCRIPTION = (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver01)(PORT = 1521)) ) LISTENER_DBSERVER.dbnet.com = (DESCRIPTION = (ADDRESS_LIST= (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver01)(PORT = 1521)) (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver02)(PORT = 1521)) (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver03)(PORT = 1521)) ) )
Diese Listener-Aliases werden nun auf den Instanzen gesetzt:
Der Local Listener für die Registrierung beim eigenen Listener: ALTER SYSTEM SET LOCAL_LISTENER=listener_dbserver01; #ein lsnrctl services auf Server 1 listet u.A. folgendes auf: . Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=dbserver01)(Port=1521)) Services Summary... Service "ORADB.dbnet.com" has 1 instance(s). Instance "ORADB", status READY, has 2 handler(s) for this service... Handler(s): "DEDICATED" established:1 refused:0 state:ready LOCAL SERVER .
Der Remote Listener für die Registrierung bei allen andern Listener, die im Alias definiert sind: ALTER SYSTEM SET REMOTE_LISTENER=listener_dbserver; #ein lsnrctl services auf Server 2 listet u.A. folgendes auf: . Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=dbserver02)(Port=1521)) Services Summary... Service "ORADB.dbnet.com" has 2 instance(s). Instance "ORADB", status READY, has 2 handler(s) for this service...
376
7.2 Konfiguration Handler(s): "DEDICATED" established:0 refused:0 state:ready REMOTE SERVER (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbserver01)(PORT=1521))) Instance "ORADB", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER .
Beim Einsatz von Shared-Server für die Registrierung des DISPATCHERS bei allen definierten Listener: ALTER SYSTEM SET DISPATCHERS=(PROTOCOL=tcp)(DISPATCHERS=1)(LISTENER=listeners_dbserver); #ein lsnrctl services auf Server 2 listet u.A. folgendes auf: . Connecting to (ADDRESS=(PROTOCOL=TCP)(Host=dbserver02)(Port=1521)) Services Summary... Service "ORADB.dbnet.com" has 2 instance(s). Instance "ORADB", status READY, has 2 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready REMOTE SERVER (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbserver01)(PORT=1521))) "D000" established:0 refused:0 current:0 max:1022 state:ready DISPATCHER <machine: dbserver01, pid: 475138> (ADDRESS=(PROTOCOL=tcp)(HOST=dbserver01)(PORT=32785)) Instance "ORADB", status READY, has 1 handler(s) for this service... Handler(s): "DEDICATED" established:0 refused:0 state:ready LOCAL SERVER .
Praxistipp Damit auch bei der Shared-Server-Konfiguration und der Definition des DISPATCHERParameters noch mit dedicated Server verbunden werden kann (z.B. Batchjobs), muss der LOCAL_LISTENER zusätzlich gesetzt sein, denn sonst gibt es für keinen Service einen dedicated Handler (ersichtlich mit lsnrctl services).
!
Hinweis Der Parameter LISTENER_NETWORKS liefert ab Version 11g R2 eine Zusammenfassung der lokalen und remoten Listener, bei denen sich die Instanz zu registrieren hat. Die darin enthaltenen Listener sollen nicht mehr in den alten Parametern (LOCAL/REMOTE_LISTENER) gesetzt sein.
7.2.2.5 Server Side Listener Connection Load Balancing Die Lastverteilung erfolgt auf Datenbankseite zum Verbindungszeitpunkt (Connection Load Balancing) und ist in verschiedenen Stufen ausführbar. Zum einen geht es um die gleichmäßige Verteilung auf verschiedene Dispatcherprozesse, wenn Shared-Server konfiguriert sind, und zum anderen um die Aufteilung der Last auf die verschiedenen Instanzen bei einer Real-Application-Clusters-Umgebung. Dies ist möglich, weil sich der PMONProzess nicht nur bei seinem lokalen Listener, sondern auch bei den remote Listener im
377
7 Oracle Net RAC-Verbund registrieren kann. Der PMON kommuniziert regelmäßig mit seinen Listener-Prozessen und teilt ihnen die Last mit. Somit weiß ein von der Applikation angefragter Listener Bescheid über die aktuelle Lastverteilung der involvierten Knoten, Instanzen und − falls konfiguriert − Dispatcher. Er kann dann die Anfrage nach folgenden Kriterien weiterleiten: 1. An den am wenigsten belasteten Knoten 2. An die am wenigsten belastete Instanz dieses Knotens 3. An den am wenigsten belasteten Dispatcher dieser Instanz
!
Hinweis Die Lastverteilung findet nur beim Verbinden statt, das heißt, wenn ein Teil der Verbindungen wieder geschlossen wird, erfolgt kein Rebalancing. So kann es sein, dass ein Knoten oder Dispatcher stärker belastet ist als ein anderer.
7.2.3
Clientseitig
Damit ein Client zu einer Datenbank bzw. zu einem Datenbankservice verbinden kann, muss neben einer gültigen User ID und dem dazugehörenden Passwort auch ein Verbindungsdeskriptor angegeben sein. Der Deskriptor kann direkt beim Verbindungsaufruf des Clientprogramms (Applikation, sqlplus, sqldeveloper …) angegeben werden und muss die Information von HOST, PORT, PROTOCOL und SERVICE_NAME beinhalten. Er definiert somit die physische Lokation des angegebenen Datenbankservices: $ sqlplus scott/tiger@’(DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=dbserver01)(PORT =1521)) (CONNECT_DATA=(SERVICE_NAME=ORADB.dbnet.com )))’
Es gibt aber noch mehr zu konfigurieren, vor allem um Problemfälle10 abzufangen. Diese Failover-Konfigurationen erlauben einen möglichst unterbrechungsfreien Zugriff auf den gewünschten Datenbank-Service. Dies wirkt sich positiv auf die Verfügbarkeit des Services aus. Es wäre schlecht investiertes Geld, wenn auf der Serverseite teure Redundanzen und Skalierungsfunktionen eingebaut sind, die aber von einer hart codierten Verbindung in einer Applikation nicht ausgenutzt werden. 7.2.3.1 tnsnames.ora Die Verbindungsdeskriptoren mit den benötigten Informationen sind aber nicht jedes Mal beim Verbindungsaufruf komplett anzugeben. Sie werden meistens mit einem Namen versehen und in Repositories abgelegt, die entsprechend der Naming-Methode (definiert in der Datei sqlnet.ora) unterschiedlich ausgeprägt sind. Sind diese Net-Servicenamen und deren Deskriptoren in der Textdatei tnsnames.ora abgelegt, spricht man von der Local Naming Methode. Diese liegt typischerweise auf der
10
378
Siehe Abschnitt 7.5 „Fehlersuche“
7.2 Konfiguration Clientseite, muss aber bei einer Server/Server-Architektur auch auf der Serverseite vorhanden sein. Dabei arbeitet bei Datenbank-Links die eine Datenbank als Client der anderen. Sie wird auch auf dem Server benötigt, wenn darin Listener-Aliases definiert sind. Praxistipp Legen Sie die Datei tnsnames.ora in jedem Fall auch auf dem Datenbankserver ab, damit Sie die Verbindungen zuerst dort testen können. Dabei werden Clientnetzwerke und evtl. Firewalls nicht involviert und Sie können sicher sein, dass Sie keine Syntaxfehler in der Konfiguration haben, wenn diese Tests erfolgreich sind.
Diese sogenannten „Net-Servicenamen“ lassen sich individuell oder auch abteilungsspezifisch vergeben und müssen keinen Bezug zum Datenbank-Servicenamen haben: FINANZ_DB = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = dbserver01) (PORT = 1521) ) (CONNECT_DATA = (SERVICE_NAME = ORADB.dbnet.com ) ) )
Das hier gezeigte Beispiel definiert für den Net-Servicenamen FINANZ_DB die Verbindung auf einen Server mit dem Namen dbserver01. Der Port 1521 ist default für Oracle-NetVerbindungen, über die versucht wird, auf einen Datenbankservice mit dem Namen ORADB.dbnet.com zu verbinden. Folgender Verbindungsaufruf nutzt diese Namensauflösungsmethode aus: $ sqlplus scott/tiger@FINANZ_DB
Praxistipp Obwohl mit der Verwendung des Defaultports (1521) viele Automatismen vorgegeben sind, ist es aus Sicherheitsgründen nicht zu empfehlen, diesen zu verwenden. Bei Server-Attacken über das Netzwerk bietet ein dem Angreifer unbekannter Port eine zusätzliche Hürde, um das System zu knacken.
7.2.3.2 Weitere Methoden zur Namensauflösung Neben der „local naming“-Methode mit der dateibasierenden Konfiguration in mes.ora unterstützt Oracle noch weitere Methoden:
tnsna-
Easy Connect naming Methode: Benötigt keine Konfiguration, liefert alle Informationen beim Verbindungsaufruf: CONNECT username@[//]host[:port][/service_name][:server][/instance_name] Enter password: password SQL> CONNECT scott/tiger@dbserver01:1521/ORADB.dbnet.com Connected. SQL>
379
7 Oracle Net Die Methode ist nicht für große und komplexe Umgebungen gedacht, da sie nur einfache und keine fehlertoleranten Verbindungsdeskriptoren generiert. Als Voraussetzung muss in sqlnet.ora der Parameter NAMES.DIRECTORY_PATH mit dem Wert ezconnect aufgelistet sein. Die Angabe des Ports ist nicht nötig, wenn der Default 1521 eingesetzt wird, ebenfalls sind die beiden Schrägstriche nur nötig, wenn via URL verbunden wird.
Directory naming Methode: Die Net-Servicenamen sind in einem LDAP11-kompatiblen Directory Server zu Verbindungsdeskriptoren aufgelöst. Dies kann das Oracle Internet Directory (DIRECTORY_SERVER_TYPE=OID) oder auch das Active Directory von Microsoft (DIRECTORY_SERVER_TYPE=AD) sein. Die zentrale Verwaltung der Servicenamen hat Vorteile, da die Anpassungen immer nur an einem Ort anfallen. Soll ein ldap-Server zum Einsatz kommen, ist im sqlnet.ora.Parameter NAMES.DIRECTORY_PATH der Wert ldap aufzulisten. Ebenfalls notwendig ist eine Datei ldap.ora, die unter einem der Directorys $ORACLE_HOME/network/admin oder $TNS_ADMIN liegt und z.B. folgende Informationen beinhaltet: DEFAULT_ADMIN_CONTEXT = "dc=de,dc=company,dc=com" DIRECTORY_SERVERS= (oidserver01:389:636) DIRECTORY_SERVER_TYPE = OID
Hier wird angegeben, auf welchem Server der OID läuft und über welchen Port darauf zugegriffen werden kann. 389 ist der unverschlüsselte und 636 der SSL-Port. DEFAULT_ADMIN_CONTEXT definiert den Einstiegspunkt im Directory-Baum für die Ablagen der Verbindungsdeskriptoren. Das Aufsetzen eines Oracle Contextes für die Net-Service-Namensauflösung im OID ist detailliert im „Oracle Internet Directory Administrator's Guide“ beschrieben. Die Integration von Net-Service-Namen in das Directory kann mit dem Net Configuration Assistant oder mit dem Enterprise Manager erfolgen.
External naming Methode: Dabei kann Oracle auf einen Drittanbieter für NamensService gehen (z.B. NIS); diese sind aber nicht auf allen Plattformen vorhanden. Das Kommando adapters kann das überprüfen.
!
Hinweis Die „naming“-Methoden können in sqlnet.ora kommasepariert aufgelistet sein, die Reihenfolge definiert die Priorität der Anwendung. Steht z.B. der ldap-Server gerade nicht zur Verfügung, wird automatisch auf das lokale tnsnames.ora zurückgegriffen.
7.2.3.3 Client Side Connect-Time Load Balancing/Failover Durch die Angabe des tnsnames-Parameters LOAD_BALANCE=on werden die Verbindungsanfragen gleichmäßig zufällig über die vorhandenen Adressen verteilt. Die Reihenfolge in
11
380
LDAP steht für Lightweight Directory Access Protocol, mit dem auf einen zentralisierten Server zugegriffen wird, das die verteilten Oracle Net-Konfigurationen verwaltet und damit die client- und serverseitigen tnsnames.ora-Dateien ersetzt
7.2 Konfiguration der ADRESS_LIST ist nicht ausschlaggebend. Sind z.B. vier Adressen eines 4-Knoten-RACs im Net-Servicenamen definiert, landen bei 100 Verbindungen je 25 auf jedem Knoten. Dies erfolgt unabhängig der Lastverhältnisse auf den Servern, da es sich um die Funktionalität der clientseitigen Lastverteilung in Form der Anzahl Verbindungen handelt. Steht in tnsnames.ora eine DESCRIPTION_LIST-Klausel, ist Loadbalancing per default eingeschalten. Ist es nicht gesetzt, geht Oracle stur jedes Mal von Anfang an durch die angegebenen Adressen und verbindet bei der ersten erfolgreichen Listeneranfrage. Das nennt sich dann Client-Connect-Time Failover und wird mit dem tnsnames-Parameter FAILOVER=ON gesteuert. Ohne Angabe ist der Parameter immer eingeschaltet und ermöglicht das sequenzielle Durchgehen der verschiedenen Listeneradressen, bis eine funktioniert: ORADB_LB.dbnet.com= (DESCRIPTION = (LOAD_BALANCE = on) (FAILOVER = on) (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver01)(PORT (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver02)(PORT (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver03)(PORT (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver04)(PORT (CONNECT_DATA = (SERVICE_NAME = ORADB.dbnet.com ) ) )
= = = =
1521)) 1521)) 1521)) 1521))
Die Failover-Funktionalität ist für eine hochverfügbare Umgebung zwingend. Es stellt sich dabei aber die Frage, ob in jedem Fall dieser automatische Failover stattfindet und mit welcher Verzögerung. Bei welchen Fehlern wird überhaupt noch weiter probiert eine funktionierende Verbindung herzustellen? Da die Verbindungsanfrage zum Listener geht, wird nur die Verfügbarkeit des Listeners und des registrierten Services geprüft. Das heißt, wenn der Listener nicht gestartet ist, erfolgt automatisch ein neuer Versuch. Wenn der gewünschte Service nicht präsent ist, erscheint nach dem Prüfen jeder Adresse eine Fehlermeldung: ERROR: ORA-12516: TNS:listener could not find available handler with matching protocol stack
Liegt das Problem aber nicht beim Listener und den registrierten Services, sondern z.B. an der Instanz (hier ein Archiver Stuck), bleibt der Verbindungsversuch hängen, obwohl noch ein anderer Server verfügbar gewesen wäre: ERROR: ORA-00257: archiver error. Connect internal only, until freed.
7.2.3.4 Client Side Connect-Timeout Sind Knoten bzw. deren IP-Adressen nicht mehr verfügbar, ist es sehr zeitaufwändig durch die verschiedenen ADDRESS-Konfigurationen zu gehen und im schlimmsten Fall jeweils ein „TCP Connect Timeout“ abzuwarten. Das Setzen von SQLNET.OUTBOUND_CONNECT_ TIMEOUT in sqlnet.ora reduziert dies auf den spezifizierten Wert (wenige Sekunden).
381
7 Oracle Net Ab Oracle 11g R2 kann man Connection Timeouts auch auf Basis der Deskriptoren konfigurieren und global gesetzte Werte in sqlnet.ora übersteuern. Dies ergibt flexiblere Konfigurationen, z.B. im Dataguard-Umfeld:
TRANSPORT_CONNECT_TIMEOUT: Spezifiziert die Wartezeit von Oracle Net für die Etablierung einer Verbindung auf den Datenbank Server. Er übersteuert in sqlnet.ora.
TCP.CONNECT_
TIMEOUT
CONNECT_TIMEOUT: Spezifiziert die Wartezeit von Oracle Net für die Etablierung einer Verbindung auf die Datenbankinstanz. Er übersteuert TIMEOUT in sqlnet.ora.
SQLNET.OUTBOUND_CONNECT_
Welches der beiden Timeouts zum Tragen kommt hängt vom eingesetzten Tool ab. Pingt man z.B. mit tnsping den Listenerprozess an, wird das Server-Timeout abgewartet. Bei einem Verbindungsversuch mit sqlplus wirkt das kleinere der beiden, weil das InstanzTimeout auch abläuft, wenn der Server nicht verfügbar ist. Praxistipp Setzen Sie SQLNET.OUTBOUND_CONNECT_TIMEOUT oder CONNECT_TIMEOUT auf ein paar Sekunden, dann minimieren Sie die Wartezeit für Verbindungsprobleme jeder Art.
Praxistipp Vor allem bei der Integration von alten Systemen können Applikationskonfigurationen auftreten, bei denen die neuen Failover-Funktionen nicht in jedem Fall helfen. Wenn im Extremfall IPAdressen direkt in der Applikation codiert sind oder z.B. eigene Applikationsconnection Pools alloziert werden, kann es sinnvoll sein, die IP-Adresse(n) des abgestürzten Knotens auf den anderen Knoten zu übernehmen. Solche Funktionalität sind mit Clustern oder eigenen Skripten (im Dataguard-Umfeld) möglich und in der Regel einfacher zu implementieren, als komplizierte Client-Notifikationen in alten Applikationen einzuführen.
7.2.4
Ausfalltolerante Verbindungen
Oracle Net eignet sich sehr gut für das Abkoppeln der involvierten Kommunikationsschichten. Dies bringt nicht nur den Vorteil, in den Applikationen hardwareunabhängig auf die Daten zugreifen zu können, sondern hat auch im Fehlerfall praktischen Nutzen. Die vorhandenen Funktionalitäten bieten verschiedene Konfigurationsmöglichkeiten für eine applikationstransparente Fehlerumgehung, was natürlich der Verfügbarkeit der Systeme zugute kommt. 7.2.4.1 Transparent Application Failover (TAF) Transparent Application Failover (TAF) ermöglicht automatisches Wiederherstellen einer Verbindung im Fehlerfall. Diese Funktionalität ist auf der Oracle Net-Schicht implementiert und benötigt keine selbstgeschriebene Fehlerbehandlungsroutinen seitens der Applikation. Die Konfiguration von TAF kann auf der Clientseite in der CONNECT_DATA-Klausel im
382
7.2 Konfiguration Verbindungsdeskriptor erfolgen. Die FAILOVER_MODE-Klausel spezifiziert TYPE und METHODE, sowie RETRIES und DELAY.
TYPE:
erledigt ein Recovery der Select-Operationen, session macht keinen nahtlosen Failover von offenen Cursor, hat aber auch keinen Overhead select
METHOD: precconect hat den Prozess schon gestartet, basic nicht Für Failover und Loadbalancing-Verbindungen kann bei folgender Einstellung ein Session-Reconnect automatisch auf eine neue Instanz erfolgen. Sogar eine offene Query (TYPE=select) wird nach erfolgtem Wiederherstellen der Verbindung weitergeführt: ORADB_LB.dbnet.com = (DESCRIPTION = (LOAD_BALANCE = on) (FAILOVER = on) (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver01)(PORT = 1521)) (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver02)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = ORADB.dbnet.com ) (FAILOVER_MODE = (TYPE = select) (METHOD = basic) ) ) )
Offene Transaktionen werden dabei in jedem Fall zurückgesetzt und sind gleichwohl applikatorisch nachzufahren. Ohne Failover-Adresse kann die Anzahl der Versuche und die Wartezeit dazwischen angegeben werden, bis die Applikation eine Fehlermeldung erhält: ORADB.dbnet.com = (DESCRIPTION = (ADDRESS = (PROTOCOL = tcp)(HOST = dbserver01)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = ORADB.dbnet.com ) (FAILOVER_MODE = (TYPE = select) (METHOD = basic) (RETRIES=20) (DELAY=15) ) ) )
TAF kann auch auf der Serverseite beim Datenbankservice konfiguriert werden, dies übersteuert die clientseitige Parametrisierung im Verbindungsdeskriptor. Das PL/SQL-Package DBMS_SERVICE erstellt oder modifiziert einen Service, um die Failover-Konfiguration zu definieren. Jede Verbindung auf diesen Servicenamen besitzt danach TAF-Funktionalität: BEGIN DBMS_SERVICE.CREATE_SERVICE( service_name => 'ORADB_TAF’, failover_method => 'BASIC', failover_type => 'SESSION', failover_retries => 180, failover_delay => 1); END; /
383
7 Oracle Net 7.2.4.2 Fast Application Notification (FAN) Eine Fast Application Notification (FAN) kann ebenfalls innerhalb des Services definiert werden. Damit kann der Server mit den Clients kommunizieren und ihnen mitteilen, dass z.B. gerade ein Rollentausch in einer Dataguard-Umgebung bevorsteht. Daraufhin können die Clients aktiv auf die Situation zugehen und ohne Abwarten von Timeouts direkt einen Reconnect auf einen anderen Server machen. Bei OCI-Clients ist diese Kommunikation mittels „Advanced Queuing“-Funktionalität implementiert. Ist beim DB Service die Notification gesetzt, beinhaltet die Tabelle SYS.REG$ die nötigen Client-Daten, über die z.B. der Dataguard Broker beim Rollentausch durch einen DB Down Event in der Alert Queue informiert wird: BEGIN DBMS_SERVICE. MODIFY_SERVICE( service_name => 'ORADB_TAF’, aq_ha_notifications => true); END; /
7.2.4.3 Fast Connection Failover (FCF) Fast Connection Failover (FCF) liefert die Reconnect-Funktionalität − im Gegensatz zu TAF − weg von der Netzwerkschicht direkt in die Applikation. JDBC-Applikationen werden via RAC ONS (Oracle Notification Service) benachrichtigt und können so sehr schnelle Reconnects der Verbindungen machen, ohne dass dabei ein zeitaufwändiges ExceptionHandling auf einen Oracle Fehler notwendig ist. 7.2.4.4 Single Client Access Name (SCAN) Die Zukunft der Cluster-Umgebungen wird immer dynamischer. Es werden Server hinzugefügt und auch wieder weggenommen. Dies hat natürlich Auswirkungen auf die ADRESS_ LIST in einem Verbindungsdeskriptor. Bei zentralen Namesauflösungen ist die Nachführung noch machbar, beim Einsatz von dateibasierenden Konfigurationen wird es aber schon mühsam und fehleranfällig. Es bringt nämlich nichts, eine skalierende Serverumgebung aufzusetzen, wenn der Client den zusätzlichen Knoten nicht kennt. Darum wurde mit 11g R2 der Single Client Access Name (SCAN) eingeführt. Dabei geht es um die Definition einer weiteren Listenerschicht (SCAN_LISTENER) als ein stabiler Ansprechpartner zur Applikation, während sich die dynamischen RAC-Knoten bei diesen an- und abmelden. Dadurch kann eine Verbindungsanfrage des Clients vom SCAN_LISTENER immer auf den lastmäßig optimalsten Knoten-Listener weitergeleitet werden, da die vorhandenen Server dort bekannt sind.
384
7.3 Werkzeuge
7.3
Werkzeuge Verschiedene Werkzeuge unterstützen die Konfiguration von Oracle Net-Komponenten. Manchmal gilt auch hier, dass viele Wege nach Rom führen, aber für gewisse Tätigkeiten ist das eine oder andere Hilfsmittel besser bzw. direkt von Oracle gefordert. Schon fast philosophisch ist die Diskussion über Grafical User Interface (GUI) oder Comand Line Interface (CLI). Können bei GUI die Intuition und die kontextbezogenen Hilfsfunktionen eher mal einen Versuch zum Erfolg führen, so ist beim CLI die Syntax im Vorfeld zu evaluieren und genau anzuwenden. Beides hat seine Berechtigung, eines gilt es aber im Auge zu behalten: Die Dokumentation eines Setups mit Kommandozeilen-Anweisungen ist vom Umfang her erheblich kleiner und jederzeit reproduzierbar, da sind Screenshots von grafisch unterstütztem Aufsetzen von Umgebungen eher schwerfällig und nicht mit der „copy&paste“-Methode nachzuvollziehen.
7.3.1
Manuell
Die dateibasierte Konfiguration von Oracle Net kann client- und serverseitig sehr einfach mit einem ASCII Texteditor (z.B. vi) erfolgen, der keine Formatierungen verwendet. Die optische Gestaltung des Dateiinhalts lässt sich mit Kommentarzeichen (#), Leerzeilen und Einrückungen sehr übersichtlich gestalten. Zudem sind im selbst definierten Datei-Header Beschreibungen und Änderungshistorien möglich. Die Textdateien eignen sich auch sehr gut, um in Sourcecode Verwaltungssysteme (z.B. SVN) gehalten zu werden (checkin/ checkout), was die Anpassungen nachvollziehbar und von einem zentralen Punkt aus verteilbar macht.
Listener control utility (lsnrctl): Ermöglicht das Starten, Stoppen und Konfigurieren des Listenerprozesses. Abfragen über Status und registrierte Services geben eine Übersicht, für welche Verbindungsanfragen der Prozess zur Verfügung steht. Das Programm wird auch benötigt, um in automatisierten Umgebungen den Prozess beim Server-Startup zu starten: $ lsnrctl LSNRCTL for Linux: Version 11.2.0.1.0 - Production on … Copyright (c) 1991, 2009, Oracle.
All rights reserved.
Welcome to LSNRCTL, type "help" for information. LSNRCTL>
Server Control Utility (srvctl): Ist nur zu einem kleinen Teil für Oracle Net zuständig. Der Funktionsumfang bezieht sich auf alle Cluster-Ressourcen (Datenbanken, Instanzen, Listeners, Services…). Wir stellen das Werkzeug zum Erstellen und Konfigurieren von Datenbank-Services und das serverseitige Transparent Application Failover (TAF) später genauer vor:
