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 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 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>;
Mit 1 ;
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 ) 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 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 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 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 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:
299
5 Automatic Storage Management
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 SCOTT oracle <Userhost>ttdb00r 32173 pts/1 0 SCOTT
344
6.3 Auditing TEST SCOTT EMP 9 08001C000E2B0000 0 <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, >, 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:
385
7 Oracle Net $ srvctl Usage: srvctl [] commands: enable|disable|start|stop|status|add|remove|modify|getenv|setenv|unsetenv|config objects: database|service|asm|diskgroup|listener|home|ons|eons For detailed help on each command and object and its options use: srvctl -h or srvctl -h
sqlplus: Das gute alte
sqlplus wird natürlich auch eingesetzt, ALTER SYSTEM SET … setzt die Oracle Net-spezifischen Initialisierungsparameter (wenn ein spfile angewendet wird, sogar persistent): $ sqlplus /nolog SQL*Plus: Release 11.2.0.1.0 Production on … Copyright (c) 1982, 2009, Oracle. All rights reserved. SQL> connect / as sysdba Connected. SQL> show parameter listener NAME -----------------------------------listener_networks local_listener remote_listener SQL>
7.3.2
TYPE ----------string string string
VALUE ----------------------listener_dbserver01 listener_dbserver02
Net Configuration Assistant
Der Oracle Net Configuration Assistant ist ausschließlich notwendig, um zum Installationszeitpunkt die Basis-Netzwerkkomponenten zu konfigurieren. Der Assistent wird bei der Installation automatisch aufgerufen und stellt so eine funktionsfähige Verbindung auf den Datenbankserver sicher. Folgende Komponenten werden konfiguriert:
Listener mit Name und Zugriffsadresse, erstellt die Datei listener.ora Naming-Methoden, die notwendig sind, um die Verbindungsidentifikatoren aufzulösen, dabei wird die Datei sqlnet.ora erstellt
Net-Servicenamen, werden in die Datei
tnsnames.ora
geschrieben, damit korrekte
Verbindungsanfragen möglich sind
Beim Einsatz von Directory Server (Oracle Internet Directory) wird die Datei ldap.ora angepasst Der Aufruf kann auch interaktiv erfolgen und wird mit dem Programm netca, aus dem ORACLE_HOME/bin ausgeführt. Die Screenshots in den Abbildungen 7.7 bis 7.9 zeigen als Beispiel den grafischen Dialog für die Konfiguration der Naming Methode. $ /u00/app/oracle/product/11.2.0/bin/netca $ Oracle Net Services Configuration:
386
7.3 Werkzeuge
Abbildung 7.7 Net Configuration Assistant – Naming Methode
Abbildung 7.8 Net Configuration Assistant – Methodenzuteilung
387
7 Oracle Net
Abbildung 7.9 Net Configuration Assistant – Abschluss
7.3.3
Net Manager
Im Anschluss an die Installation kann man mit dem Oracle Net Manager (unter Unix: netmgr) die Net-Komponenten erstellen und anpassen. Die Möglichkeiten sind hier vielfältiger als beim netca. Der Net Manager kann auch die Umgebungsvariable TNS_ADMIN interpretieren und liest eine bestehende Konfiguration aus diesem Directory heraus. Ist die Variable nicht definiert, sucht das Programm auf ORACLE_HOME/network/admin. Vor dem Schreiben der neuen Files werden die alten sicherheitshalber kopiert, dies ermöglicht ein Zurücksetzen im Fehlerfall. Die nächsten Screenshots (Abbildung 7.10 bis Abbildung 7.15 dokumentieren die Erstellung einer tnsnames.ora Datei, in der ein Net-Servicename konfiguriert ist. $ /u00/app/oracle/product/11.2.0/bin/netmgr
388
7.3 Werkzeuge
Abbildung 7.10 Net Manager – Neuer Net Servicename
Abbildung 7.11 Net Manager – Protokoll Definition
389
7 Oracle Net
Abbildung 7.12 Net Manager – Host und Port Definition
Abbildung 7.13 Net Manager – Datenbank Servicenamen Definition
390
7.3 Werkzeuge
Abbildung 7.14 Net Manager – Verbindungstest
Abbildung 7.15 Net Manager – Net Servicenamen Definition
391
7 Oracle Net Nach dem Abspeichern liegt das folgende File im Directory der Umgebungsvariable TNS_ ADMIN: # tnsnames.ora Network Configuration File: u00/app/oracle/network/admin/tnsnames.ora # Generated by Oracle configuration tools. # SQL*Net with ORACLE_SID (8.0 like) # OracleNet with SERVICE_NAME (9i like) # Failover instances ORADB.DBNET.COM = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dbserver01)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = ORADB.dbnet.com) ) )
7.3.4
Im RAC: Service-Konfiguration (srvctl) und DBCA
In Real-Application-Clusters-Umgebungen sind Datenbankservices zentrale Ressourcen, die der Cluster hochverfügbar auf die laufenden Instanzen verteilt. Die Erstellung und Parametrisierung der Services erfolgt mit srvctl. Ab Version 11g R2 sind optional alle TAFParameter auf der Kommandozeile möglich. Dies ist der PL/SQL-Variante vorzuziehen, bei der im Nachhinein mit DBMS_SERVICE.MODIFY_SERVICE die Transparent-ApplicationFailover-Konfiguration zum Einsatz kam.
!
Hinweis Mit Version 11g R2 kam auch die Server-Pool-Konfiguration (mehrere Server eines Clusters bilden einen Pool). Wird nun eine Datenbank einem solchen Pool zugeweisen − man spricht dann von „policy-managed“ − ist die Syntax von srvctl add service mit der Option –P für die TAF_policy (NONE, BASIC, oder PRECONNECT) nicht mehr gültig: $ srvctl add service –h Usage: srvctl add service -d -s <service_name> [-l [PRIMARY][,PHYSICAL_STANDBY][,LOGICAL_STANDBY][,SNAPSHOT_STANDBY]] [-y {AUTOMATIC | MANUAL}][-q {true|false}] [-j {SHORT|LONG}] [-B {NONE|SERVICE_TIME|THROUGHPUT}][-e {NONE|SESSION|SELECT}] [-m {NONE|BASIC}][-z ] [-w ] -d Unique name for the database -s <service> Service name -l Role of the service (primary, physical_standby, logical_standby, snapshot_standby) -y <policy> Management policy for the service (AUTOMATIC or MANUAL) -e Failover type (NONE, SESSION, or SELECT) -m Failover method (NONE or BASIC) -w Failover delay -z Failover retries -j Connection Load Balancing Goal (SHORT or LONG). Default is LONG. -B Runtime Load Balancing Goal (SERVICE_TIME, THROUGHPUT, or NONE) -q AQ HA notifications (TRUE or FALSE) -h Print usage
392
7.4 Performance-Optimierung Nachfolgend das Beispiel einer Servicekonfiguration, die bei einem Failover bis 180 Mal im Fünf-Sekundenintervall versucht wieder eine langlebige Verbindungen mit serverseitiger Lastverteilung zu erreichen, um den select-Befehl weiter zu führen. $ srvctl add service -d ORADB -s TAF_TEST -q TRUE -m BASIC \ -e SELECT -z 180 -w 5 -j LONG
Mit srvctl implementiert man individuelle Servicenamens-Konzepte. Der Database Configuration Assistant (DBCA) konfiguriert implizit beim Erstellen einer RAC Datenbank folgende Oracle Net Einstellungen:
Serverseitiges Loadbalancing (auf dem Datenbank-Service) LOCAL_LISTENER- und REMOTE_LISTENER-Parameter für die korrekte Registrierung beim Listener
Beispielkonfiguration im lokalen tnsnames.ora für eine clientseitige Verbindung mit Lastverteilung
7.4
Performance-Optimierung Das Optimieren von Oracle-Net-Verbindungen ist auf verschiedenen Ebenen möglich. Am einfachsten ist die Reduktion der zu übertragenden Datenmenge. Der Einsatz von Datenbankprozeduren hält die Verarbeitung in der Datenbank und minimiert den Datentransfer zur Applikation auf die Statusrückgabe der Prozedur. Auch das Management von offenen Datenbankverbindungen bringt Vorteile, denn übermäßiger Verbindungsauf- und -abbau kostet Zeit. Häufig ist die Datentransferlast einer Applikation kein Problem für eine Oracle-Net-Verbindung. Datentransfer und das Verhalten bei großen Lasten ist jedoch relevant beim Redotransport in Dataguard-Umgebungen. Dabei tritt die Primary-Datenbank als Client auf, der Daten über das Netz zum Standby-Knoten überträgt. Die Bandbreite für die Übertragung der Daten von und zu den Clients hängt natürlich vom physischen Netzwerkanschluss ab, der heute meist nicht unter 1 GBit/sec liegt. Dies entspricht einer maximalen Datenmenge von ca. 90 MB/s12. Neben konfigurationsrelevanten Anpassungen kommen auch physikalische Effekte zum Tragen. Diese sind nicht zu umgehen und in der Auslegung der Systeme zu berücksichtigen. Diese Effekte hängen mit der zunehmenden Latenzzeit über die Distanz zusammen und werden als RTT (round trip time) gemessen. Faustregel für die Latenzzeit: 1 ms pro 50 km Übertragungsstrecke Eine genaue Messung von RTT ist mit dem Programm traceroute möglich: $ traceroute dbserver02 traceroute to dbserver02 (172.16.64.104), 30 hops max, 40 byte packets 1 dbserver02.dbnet.com (172.16.64.104) 0.330 ms 0.322 ms 0.312 ms 12
Faustregel: maximal 70 Prozent Auslastung des Netzwerks als Sicherheit, für die Bit/Byte Umrechnung dividiert man durch 8
393
7 Oracle Net
7.4.1
Parametrisierung
Auslöser für Performance-Probleme sind schlechte Default-Konfigurationen oder Parametrisierungen. Dies kann auch außerhalb von Oracle Net erfolgt sein – wichtige Einstellungen sind auch auf Betriebssystemebene möglich und nötig. Folgende Punkte sind beim Netzverkehr relevant:
HW Device Queue Längen: Diese werden auf dem Netzwerk-Interface bzw. im OSKernel gesetzt.
Linux Interface transmit queue (empfohlen für Gigabit und RTT über 100ms) $ ifconfig eth1 txqueuelen 10000
Oracle Buffer (senden und empfangen): Das Setzen auf das Dreifache des Bandwidth Delay Product (BDP) kann massive Verbesserungen bringen. Das BDP berechnet sich aus der Roh-Bandbreite des Netzwerks multipliziert mit der Round Trip Time (RTT). Für ein GB Netzwerk mit einer Millisekunde RTT ergibt das ein BDP von 125 KB. Die Bufferparameter sind optimal mit dem Faktor 3 zu multiplizieren und somit auf 375.000 Byte zu setzen. Die Parameter lassen sich auf allen Ebenen setzen:
Send Data Unit (SDU): Oracle verpackt in dieser Einheit die Daten für den Transfer. Sie sollte so groß sein wie die durchschnittliche Nachrichtengröße, die Oracle versendet. Das Maximum liegt bei 32 KB. Bei hoher Last erreicht man eine Verbesserung der Netzwerkauslastung und somit der Performance mit dem client- und serverseitigen Anpassen der SDU-Werte auf das Maximum (default liegt bei 8 KB).
In der Listener-Konfiguration bei der SID_LIST, was die sqlnet.ora-Einstellungen auf dem Server übersteuert: SID_LIST_LISTENER1120 = (SID_DESC = (GLOBAL_DBNAME = ORADB.dbnet.com) (SDU = 32767) (SID_NAME = ORADB) (ORACLE_HOME = /u00/app/oracle/product/11.2.0) )
Bandbreite des Netzwerks: Oracle unterstützt auch das Sockets Direct Protocol (SDP) für InfiniBand-Netzwerke. Diese zeichnen sich durch ihre effiziente Kommunikation und große Bandbreite aus. In der Oracle Database Machine13 verwendet Oracle solche Interfaces für die Interconnects der Knoten und für die Anbindung des Exadata-Storage-Servers.
Primary DB-Server
Send Data Unit (SDU)
OS Buffer Limits
Standby DB-Server
Oracle Buffers HW Device Queue Länge
Round Trip Time (RTT)
Netzwerk Bandbreite
Abbildung 7.16 Involvierte Netzwerk Komponenten
13
Die Oracle Exadata Database Machine ist ein vorkonfiguriertes, ausbalanciertes System. Es besteht aus Hardware-Komponenten von Oracle Sun, die optimal aufeinander abgestimmt sind und so große Performance-Vorteile für DWH- und auch OLTP-Anwendungen bieten (siehe http://www.oracle.com/us/products/database/database-machine/index.html)
395
7 Oracle Net
7.4.2
Timeouts für nicht autorisierte User
„Denial of service“-Attacken auf den Datenbankserver durch nicht autorisierte Benutzer können Performance-Probleme verursachen. Große Mengen an Verbindungsanfragen auf den Server (via HOST- und PORT-Information) behindern durch die Belastung des Listenerprozesses andere, korrekte Benutzer im Verbindungsaufbau. Je schneller man nun diese unbefugten Anfragen abweist, desto weniger tritt das Problem auf. Das Zeitintervall setzt man mit INBOUND_CONNECT_TIMEOUT_listener_name im listener.ora. Es definiert die Anzahl Sekunden bis der Listener eine nicht authentifizierte Verbindung beendet (Defaultwert ist 60). Mit SQLNET.INBOUND_CONNECT_TIMEOUT (Defaultwert ist auch 60 Sekunden) kann im serverseitigen sqlnet.ora das Intervall gesetzt werden, bis der Datenbankserver eine Anfrage eines unbefugten Benutzers abweist. Zusätzlich werden die gescheiterten Verbindungen in den serverseitigen Listener- bzw. sqlnet-Logdateien protokolliert. Abhängig von den systembedingten Netzwerkverzögerungen setzen Sie die beiden Werte möglichst klein (ein paar Sekunden), wobei der SQLNET-Wert etwas höher sein sollte als der Wert des Listeners. Stellen Sie dabei aber sicher, dass keine Timeouts im Normalbetrieb stattfinden.
7.4.3
Database Resident Connection Pooling (DRCP)
Bisher haben wir zwei verschiedene Verbindungspunkte, Service-Handler genannt, zu einer Oracle Datenbank kennengelernt, den dedizierten und den shared Serverprozess. Ab Oracle 11g gibt es noch einen dritten, den pooled Service-Handler. Diese Funktionalität heißt Database Resident Connection Pooling (DRCP) und bietet einen Shared-Pool an Datenbankverbindungen an. Die Arbeitsweise ist ähnlich dem shared Server Modell. Bei DRCP ist der Client permanent zu einem Brokerprozess verbunden und authentisiert. Dieser weist dem Client aus dem Pool einen Serverprozess zu, der dann dediziert für seine Aktivitäten zuständig ist. Diese Arbeitsweise ist dann wie bei einer Verbindung zu einem dedizierten Serverprozess. Wenn die Arbeit erledigt ist, geht der Prozess an den Pool zurück. Pooled-Server eignen sich vor allem für viele kleinere Datenbankaktivitäten und skalieren dabei besser als die Shared-Server, bei denen der eigentliche Datentransfer immer über den Dispatcherprozess geht. Die benötigten Speicheranforderungen einer inaktiven Verbindung bei DRCP sind sehr klein, was mit denselben Ressourcen zigtausend von Verbindungen zulässt, die dann auch noch aktiv leistungsfähiger sind. Damit die Applikation von dieser Art Service Handling profitieren kann, muss im Verbindungsdeskriptor in der CONNECT_DATA-Klausel SERVER=POOLED angegeben sein: ORADB.DBNET.COM = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = dbserver01)(PORT = 1521)) (CONNECT_DATA=(SERVICE_NAME = ORADB.dbnet.com)(SERVER = POOLED)) )
DRCP-Verbindungen sind auch mit „Easy Connect“ möglich: SQL> CONNECT scott/tiger@dbserver01:1521/ORADB.dbnet.com:POOLED Connected.
396
7.5 Fehlersuche Mit dem PL/SQL-API dbms_connection_pool stellt man auf der Datenbankseite den Pool zur Verfügung (start_pool, stop_pool) und konfiguriert (configure_pool) diesen. SQL> execute dbms_connection_pool.start_pool; PL/SQL procedure successfully completed.
Anpassungen der Defaultwerte vollzieht man mit der Prozedur alter_param. Das Beispiel zeigt das Setzen der minimalen Serveranzahl von default 4 auf 10: SQL> execute dbms_connection_pool.alter_param ('','minsize','10'); PL/SQL procedure successfully completed.
Datenbankseitiges Monitoring der Pools ist über die View dba_pool_info möglich: SQL> SELECT status, minsize, maxsize, max_use_session 2 FROM dba_cpool_info; STATUS MINSIZE MAXSIZE MAX_USE_SESSION ---------------- ---------- ---------- --------------ACTIVE 10 40 500000
7.5
Fehlersuche Bei einer Datenbankverbindung sind verschiedene Komponenten und deren Konfiguration involviert. Der Top-Down-Ansatz grenzt die fehlerhaften Komponenten ein. Dazu prüfen auf Netzwerk- und Oracle-Net-Ebene verschiedene Dienstprogramme die jeweilige Funktionalität.
7.5.1
Werkzeuge
Zuerst wird die Erreichbarkeit des Knotens geprüft. Dies erfolgt mit dem ssh-Befehl: $ ssh dbserver01 oracle@dbserver01's password:
Ist der Knoten erreichbar, wird nach dem Passwort gefragt, andernfalls läuft das Kommando in ein TCP-Timeout. Der Einsatz von ping ist auch verbreitet, dabei ist aber zu berücksichtigen, dass viele Firewall-Administratoren dieses Kommando blockieren, was dann zu falschen Interpretationen führen kann. $ ping dbserver01 PING dbserver01.dbnet.com: 64 bytes from 172.31.4.51: 64 bytes from 172.31.4.51: 64 bytes from 172.31.4.51:
Die Antwortzeit (time) lässt auch Rückschlüsse auf die Qualität der Verbindung zu (round trip time). Ist die Erreichbarkeit des Servers gewährleistet, prüft man mit dem OracleProgram tnsping den Listenerprozess. Der als Parameter übergebene Net-Servicename wird über die lokale tnsnames.ora-Datei oder über einen Directoryserver aufgelöst und
397
7 Oracle Net die involvierte
sqlnet.ora-Datei
angezeigt (abhängig von der Umgebungsvariablen
TNS_
ADMIN): $ tnsping ORADB TNS Ping Utility for Linux: Version 11.2.0.1.0 - Production on 26-JUL-2010 15:54:28 Copyright (c) 1997, 2009, Oracle. All rights reserved. Used parameter files: /u00/app/oracle/network/admin/sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS= (PROTOCOL = TCP)(HOST = dbserver01)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = ORADB.dbnet.com ))) OK (0 msec)
Ähnlich wie das Unixprogramm traceroute, kann auch das Oracle Dienstprogramm trcroute die Auflistung der gewählten Route erledigen. Als Parameter gibt man einen Net-Servicenamen an, der auch wieder via Naming-Methode (siehe 7.2.3.2) auf dem Client aufgelöst wird: $ trcroute ORADB.DBNET.COM
Der End-to-End-Test ist dann das Verbinden mit einem Benutzernamen und dem dazugehörigen Passwort. Dazu nimmt man am einfachsten das Clientprogram sqlplus, wobei auch hier wieder der Net-Servicename das Zielsystem bestimmt: $ sqlplus scott/tiger@ORADB SQL*Plus: Release 11.2.0.1.0 Production on Mon Jul 26 16:48:50 2010 Copyright (c) 1982, 2009, Oracle.
All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL>
Bei diesem Test stellt sich dann auch heraus, ob die Name/Passwort-Kombination gültig ist, oder evtl. der Benutzer in der Datenbank gesperrt ist. Es wird auch klar ersichtlich, ob die Datenbank im restriktiven Modus läuft: $ sqlplus /nolog CONNECT / as sysdba Connected. SQL> ALTER SYSTEM enable restricted session; System altered. SQL> exit Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options $ sqlplus scott/tiger@ORADB SQL*Plus: Release 11.2.0.1.0 Production on Mon Jul 26 16:54:49 2010
398
7.5 Fehlersuche Copyright (c) 1982, 2009, Oracle.
All rights reserved.
ERROR: ORA-12526: TNS:listener: all appropriate instances are in restricted mode Enter user-name:
Ist nach diesen Prüfungen ein Fehler bei den Oracle-Net-Komponenten offensichtlich, beginnt man mit der vertieften Analyse der Logfiles und startet das Tracing.
7.5.2
Logging und Tracing
Logging und Tracing liefert detaillierte Informationen, um Probleme im Bereich von Oracle Net zu finden. Dies können Verbindungsprobleme, unerwartete Verbindungsabbrüche oder Verbindungsverzögerungen sein. Tracing bringt Informationen in unterschiedlichen Detaillierungsgraden und listet verbindungsspezifische interne Operationen während dem Einsatz von Oracle Net auf. Logging ermöglicht die Erstellung von zusammenfassenden Rapporten, Statusinformationen und Fehlermeldungen. Logfiles, Tracefiles und deren Tracelevels sind auf Client- und Serverseite in den sqlund listener.ora-Dateien konfiguriert. Mit der Einführung von Automatic Diagnostic Repository (ADR) bei Oracle 11g (siehe Kapitel 2 „Architektur und Administration“) werden die Log- und Tracedateien in einer zentralen Verzeichnisstruktur verwaltet. net.ora-
Ausgehend vom ADR-Basisdirectory ist die Verzeichnisstruktur vorgegeben und kann im Fall vom Listener folgendermaßen aussehen: $ cd /u00/app/oracle/diag/tnslsnr/dbserver01/listener/ $ ls alert cdump incident incpkg lck metadata stage sweep
trace
Ob die ADR-Struktur (ab Version 11g) zum Tragen kommt, wird mit folgendem Parameter in der Datei sqlnet.ora gesetzt; DIAG_ADR_ENABLED=on
In der Datei listener.ora wird der Parameter mit dem jeweiligen Listenername erweitert: DIAG_ADR_ENABLED_LISTENER=on
Der Defaultwert ist ON. Somit muss ab Version 11g explizit OFF gesetzt sein, wenn man die Dateinamen und Verzeichnisse selbst setzen möchte. Tabelle 7.2 Übersicht über Log- und Trace-Parameter Parameter
Die Parameter mit [CLIENT|SERVER] oder diejenigen ohne Varianten sind in der Clientbzw. Server-sqlnet.ora-Datei definiert, die mit der [LISTENER]-Erweiterung in der listener.ora-Datei mit dem jeweiligen Listenername. Wenn das ADR gesetzt ist, sind nur noch folgende Parameter aktiv:
ADR_BASE: Setzt den Pfad für das ADR Einstiegsdirectory, z.B. /u00/app/oracle DIAG_ADR_ENABLED[_LISTENER]: Schaltet die ADR-Funktionalität ein TRACE_LEVEL_[CLIENT|SERVER|LISTENER]: Definiert die Tiefe des Tracings, die Werte stehen für:
OFF: Das Tracing ist ausgeschalten USER: Tracing der durch die Benutzer hervorgerufenen Fehlerbedingungen ADMIN: Tracing der installationsspezifischen Probleme SUPPORT: Liefert Informationen für die Fehlerbehebung durch den Oracle Support TRACE_TIMESTAMP_[CLIENT|SERVER|LISTENER]: Setzt einen Zeitstempel bei jedem TraceEreignis
400
7.5 Fehlersuche
7.5.3
Log- und Tracefiles
Die Dateien sind als Textdateien im Unterdirectory trace und als XML-formatierte Dateien im Unterdirectory alert abgelegt. Das ADRCI-Tool zeigt die XML-Dateien, z.B. die Datei listener.log: adrci> set base /u00/app/oracle adrci> set home diag/tnslsnr/dbserver01/listener adrci> show alert –tail 2 –f 2010-07-28 15:25:48.029000 +02:00 28-JUL-2010 15:25:48 * service_update * ORADB * 0 28-JUL-2010 15:25:48 * ping * 0 2010-07-28 15:25:51.947000 +02:00 28-JUL-2010 15:25:51 * (CONNECT_DATA=(SERVICE_NAME= ORADB.dbnet.com)(CID=(PROGRAM=sqlplus) (HOST=dbclient01)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp) (HOST=dbserver01)(PORT=55984)) * establish * ORADB.dbnet.com * 0
Diese Einträge werden beim Aufruf eines tnsping vom Client dbclient01 auf einen Listener des Servers dbserver01 und einem anschließenden Verbindungsaufbau in die Datenbank mit sqlplus geschrieben. Dieselben Einträge findet man auch in der Datei listener.log (der Name ergibt sich aus dem Listenername im listener.ora): $ cd /u00/app/oracle/diag/tnslsnr/dbserver01/listener/trace $ tail -f listener.log 28-JUL-2010 15:25:48 * service_update * ORADB * 0 28-JUL-2010 15:25:48 * ping * 0 28-JUL-2010 15:25:51 * (CONNECT_DATA=(SERVICE_NAME=ORADB.dbnet.com)(CID=(PROGRAM=sqlplus) (HOST=dbclient)(USER=oracle))) * (ADDRESS=(PROTOCOL=tcp) (HOST=dbserver01)(PORT=55984)) * establish * ORADB.dbnet.com * 0
!
Hinweis: Speziell beim Tracen werden große Datenmengen geschrieben und es ist darauf zu achten, dass der Platzverbrauch kontrolliert wird und nach erfolgter Auswertung die Files wieder gelöscht werden. Sonst kann es vorkommen, dass wegen der Fehleranalyse ein Datenbankserver aus Platzmangel auf den Filesystemen zum Stehen kommt. Das extensive Tracing benötigt mehr Leistung von den Prozessen, was sich negativ auf den Durchsatz der Datenbank auswirkt. Tracing auf dem SUPPORT-Level sollte nur gemacht werden, wenn Oracle Support dies anfragt, denn die Auswertung der Unmengen an Daten ist manuell schwer möglich.
Werden die Verzeichnisse und Dateinamen explizit in den Dateien sqlnet.ora und listener.ora angegeben, dann sind sie nicht XML-formatiert, sondern im Klartext. Praxistipp Implementieren Sie eine regelmäßige Bereinigung der Logfiles. Die Datei listener.log kann schon nach kurzer Zeit mehrere Gigabyte groß werden. Der Unterhalt (Housekeeping) ist beispielsweise unter Unix mit einem einfachen crontab-Job möglich: $ $ $ $
cd /u00/app/oracle/network/log rm listener.log_save mv listener.log listener.log_save echo > listener.log
401
7 Oracle Net
7.6
Empfehlungen Die vielfältigen Einsatzmöglichkeiten der Oracle-Net-Komponenten macht es nicht einfach, allgemein gültige Empfehlungen zu geben. Dennoch stellen wir zum Abschluss dieses Kapitels die wichtigsten „Best Practices“ vor.
SID vs. Servicename: Arbeiten Sie mit Datenbank-Servicenamen. Dies macht das Konzept viel flexibler und koppelt den Zugriff auf die Daten von der physischen Datenbank-Implementierung ab. Ein Servicename kann z.B. auf eine schon bestehende Datenbank konfiguriert, oder auf eine neue Datenbank migriert werden. Dies erfolgt transparent zur Applikation: tnsnames.ora
(SERVICE_NAME = ORADB.dbnet.com)
SID_LIST ja/nein: Die Auflistung der SIDs im listener.ora sollte nicht mehr erfolgen (Ausnahmen siehe Kapitel 7.2.2.1), da sich die Instanzen selbst beim Listener mit ihren Servicenamen registrieren können.
Local-Listener ja/nein: Damit die automatische Service-Registrierung auch bei nicht default Portnummern funktioniert, muss der Datenbank-Initialisierungsparameter local_ listener gesetzt sein.
Listener-Security: Der Listener ist ab Oracle 10g14 per default durch BetriebssystemAuthentifizierung geschützt, d.h. nur derjenige OS-Benutzer der ihn gestartet hat, kann ihn auch administrieren. Es sind deshalb keine Passwortsettings nötig bzw. ab Oracle 11g R2 nicht mehr zugelassen.
Default Ports: Der Einsatz von Defaultwerten für Netzwerkports ist aus Sicherheitsgründen nicht zu empfehlen. Diese Portnummern sind die ersten, die attackiert werden und wenn diese nicht gesetzt sind, dann ist eine erste (kleine) Sicherheitshürde vorhanden. Der einzusetzende Bereich an Ports muss mit dem jeweiligen Netzwerkadministrator besprochen werden. In der Regel sind alle freien Ports über 1024 einsetzbar.
Ein Listener pro Datenbankserver: Wenn keine speziellen Verfügbarkeitskonzepte implementiert werden sollen, reicht ein Listener pro Datenbankserver aus. Er sollte aber immer aus der höchsten Oracle-Version heraus gestartet werden, damit keine Kompatibilitätsprobleme entstehen.
Shared Server vs. Dedicated Server: Bei kleineren gleichzeitigen Benutzermengen (im Bereich von maximal ein paar Hundert) setzt man auf heutigen Datenbankservern ohne Probleme Dedicated-Server ein. Erst bei Problemen mit der steigenden Anzahl Verbindungen ist eine Shared-Server-Konfiguration in Betracht zu ziehen.
14
402
Bei Oracle 9i war das Setzen eines Passworts unbedingt nötig, um Manipulationen am Listener von beliebigen Knoten im Netzwerk zu verhindern. Darum hat Oracle ab 10g das Sicherheitskonzept geändert.
7.7 Resümee
7.7
Resümee Mit Oracle Net stellt Oracle eine bewährte, zuverlässige und einfach konfigurierbare Kommunikationsschicht zwischen Applikation und Daten zur Verfügung. Die Unterstützung von verschiedenen Applikationsentwicklungssprachen und Topologien sowie praktisch aller heute eingesetzten Netzwerkprotokolle garantiert den vielfältigen Einsatz. Die dateibasierte Konfiguration ist erweiterbar mit zentralisierten Verzeichnissen (Directories) und erfüllt die höchsten Anforderungen an Skalierbarkeit und Verfügbarkeit. Erst durch die Funktionalität von Oracle-Net-Komponenten sind Real-Application-Cluster- und Dataguard-Architekturen transparent für die Applikationen und lassen automatische Lastverteilung und applikatorisch transparente Failover-Operationen zu. Diese Fehlertoleranz und die Mechanismen der frühzeitigen Benachrichtigung im Ausnahmefall, ermöglichen der Applikation ein proaktives Verhalten. Grafische und kommandozeilenorientierte Werkzeuge ermöglichen die einfache und fehlerfreie Konfiguration. Logging- und Tracing-Parameter unterstützen die Statusrapportierung und die vertiefte Fehlersuche. Durch die Anwendung der vorgestellten Best Practices ist man von Beginn weg auf einem guten Weg und verfügt über eine funktionierende Verbindung zwischen Applikationsprogramm und Datenbankserver.
403
7 Oracle Net
404
8 8 Optimierung In diesem Kapitel zeigen wir Ihnen:
warum es wichtig ist, das Design von Applikationen und Datenbanken hinsichtlich ihrer Performance zu betrachten;
wie man eine Oracle-Instanz konfiguriert, um optimale Performance zu erreichen; wie man Performance-Probleme identifiziert; welche Methoden für die Lösung von Performance-Problemen zur Verfügung stehen; wie man Ausführungspläne generiert und sie interpretiert.
8.1
Designing for Performance Viel zu oft beginnt die Optimierung einer Applikation zu spät – nämlich erst dann, wenn deren Entwicklung bereits abgeschlossen ist. Soweit kann es nur kommen, wenn der Performance eine geringere Bedeutung als anderen Applikationsanforderungen beigemessen wird. Performance ist jedoch nicht eine Option; sie ist ein Schlüsselkriterium jeder Applikation. Ungenügende Performance wirkt sich nicht nur nachteilig auf die Akzeptanz der Applikation aus, sie führt normalerweise – aufgrund der geringeren Produktivität – auch zu einem niedrigeren Return of Investment. Zusätzlich verursacht schlechte Performance auch höhere Software-, Hardware- und Betriebskosten. Angenommen, man möchte das Design einer Applikation auf höchste Performance ausrichten, wäre die detaillierte und vertiefte Beschäftigung damit sicher sehr interessant. Der Fokus dieses Buches ist aber ein anderer. Wir beschränken uns deshalb auf die Beschreibung der häufigsten datenbankrelevanten Designprobleme, die in vielen Fällen zu schlechter Performance führen.
405
8 Optimierung
8.1.1
Unzulänglichkeiten im logischen Datenbankdesign
Früher war es selbstverständlich, einen Datenarchitekt in das Entwicklungsprojekt einzubeziehen. Dieser war oft nicht nur für die Daten und das Datenbankdesign verantwortlich, sondern auch Teil des Teams für die Gesamtarchitektur und das Design der Applikation. Er hatte meist große Erfahrung mit Datenbanken und wusste genau, wie man Datenintegrität und Performance mittels geeignetem Design sicherstellen kann. Heutzutage ist dies leider immer weniger der Fall. Viel zu oft gibt es in Projekten kein formales Datenbankdesign mehr. Die Applikationsentwickler erstellen das Client- oder das Middle-Tier-Design und plötzlich wird das Datenbankdesign von einem sogenannten „Persistent-Framework-Tool“ (im Java-Umfeld sind dies beispielsweise Hibernate oder iBatis) generiert. Die Datenbank wird lediglich als einfacher Datencontainer betrachtet. Praxistipp Die Bedeutung des logischen Datenbankdesigns darf nicht unterschätzt werden. Wird dieses nicht korrekt entwickelt, können Performance-Probleme auftreten.
8.1.2
Implementation von generischen Tabellen
Jeder CIO träumt von Applikationen, die sich einfach und schnell an neue oder veränderte Anforderungen anpassen lassen. Der Schlüsselbegriff heißt Flexibilität. Solche Träume manifestieren sich oftmals in Form von Applikationen mit generischem Datenbankdesign. Dinge, wie beispielsweise das Hinzufügen von neuen Attributen, sind dann nur noch eine Frage der Konfiguration. Die beiden folgenden Datenbankdesign-Modelle erlauben diese Flexibilität:
Entity-Attribute-Value-Modell (EAV): Wie der Name sagt, werden für jede Information mindestens drei Spalten benötigt: Entität, Attribut und Wert. Jede Kombination definiert den Wert eines spezifischen Attributs, das mit einer spezifischen Entität verknüpft ist.
XML: Jede Tabelle hat nur wenige Spalten, wobei zwei Spalten immer vorhanden sind: ein Identifier und eine XML-Spalte, in der fast alles gespeichert ist. Es können auch zusätzliche Spalten für die Speicherung von Metadaten (z.B. wer wann die letzte Modifikation vorgenommen hat) vorhanden sein. Aus Sicht der Performance sind diese Designs äußerst problematisch. Der Grund liegt in der engen Beziehung von Flexibilität zur Performance (siehe Abbildung 8.1). Ist die Flexibilität maximal ausgeprägt, dann ist die Performance minimal (und umgekehrt). Maximale Performanz Minimale Flexibilität Flexibilität Performanz Maximale Flexibilität Minimale Performanz
406
Abbildung 8.1 Flexibilität und Performance sind zwei gegensätzliche Eigenschaften. Hohe Flexibilität und hohe Performance sind nicht zur gleichen Zeit möglich.
8.1 Designing for Performance Praxistipp Ein flexibles Design bedeutet implizit auch suboptimale Performance. In gewissen Situationen mag suboptimal gut genug sein, aber in anderen Situationen kann dies gravierende Folgen haben. Daher sollten generische Tabellen nur dann zum Einsatz kommen, wenn damit auch die erforderliche Performance erreicht werden kann.
8.1.3
Verzicht auf Constraints
Constraints (Primärschlüssel, Unique-Keys, Fremdschlüssel, NOT NULL-Constraints und Check-Constraints) sind nicht nur fundamental, um die Datenintegrität zu gewährleisten, sie werden auch vom Optimizer für die Generierung der Ausführungspläne verwendet. Ohne Datenbankconstraints ist der Optimizer nicht in der Lage, bestimmte Optimierungstechniken auszunutzen. Sind Constraints auf Applikationsebene definiert, führt dies zu zusätzlichem Code, der sowohl geschrieben, als auch getestet werden muss. Probleme können dabei auch im Bereich der Datenintegrität entstehen, weil die Daten auf Datenbankebene jederzeit manuell geändert werden können. Praxistipp Wir empfehlen, alle Constraints auf Datenbankebene zu definieren.
8.1.4
Unzulängliches physisches Datenbankdesign
Projekte, in denen das logische Design direkt auf das physische Design abgebildet wird, ohne die Vorteile der Oracle-Datenbankeigenschaften zu nutzen, sind nicht ungewöhnlich. Das häufigste und offensichtlichste Beispiel ist die direkte Verknüpfung aller Beziehungen zu einer Heap-Tabelle. Aus Sicht der Performance ist dies nicht optimal. In gewissen Situationen gewährleisten Index-Organized-Tabellen (IOT), Index-Cluster oder Hash-Cluster eine bessere Performance. Eine Oracle-Datenbank bietet wesentlich mehr Indexierungsmöglichkeiten als normale BTree- und Bitmapindizes. Je nach Situation sind komprimierte Indizes, Revers-Indizes, Function-Based-Indizes (FBI), linguistische Indizes oder Text-Indizes zur Verbesserung der Performance geeignet. Für große Tabellen ist zudem der Einsatz von Partitionierung interessant. Den meisten Datenbank-Administratoren ist dies auch bewusst. Ein häufiges Problem ist jedoch, dass die Entwickler denken, die Partitionierung der Tabellen hätte keinen Einfluss auf das logische Datenbankdesign. Dies trifft nur teilweise zu. Aus diesem Grunde empfehlen wir, Partitionierung gleich von Anfang an einzuplanen. Praxistipp Für eine bestmögliche Performance sollte man das logische Design nicht direkt auf das physische Design abbilden.
407
8 Optimierung
8.1.5
Falsche Datentyp-Auswahl
Auf den ersten Blick scheint die Wahl des Datentyps keine schwierige Aufgabe zu sein. Trotzdem findet man immer mehr Systeme mit unzulänglichen Datentypen. Es gibt vier Hauptprobleme im Zusammenhang mit der Datentyp-Auswahl:
Falsche oder unzureichende Datenvalidierung: Daten müssen innerhalb der Datenbank validiert werden können. Das heißt, es sollten beispielsweise keine numerischen Werte in einem VARCHAR2-Datentyp gespeichert sein, weil die Daten sonst extern zu validieren sind.
Informationsverlust: Beim Konvertieren eines Originaldatentyp in einen Datenbankdatentyp können Informationen verloren gehen. Werden beispielsweise Datum und Zeit in einem DATE-Datentyp anstelle eines TIMESTAMP WITH TIME ZONE-Datentyps gespeichert, gehen die Sekundenbruchteile und die Zeitzonen-Information verloren.
Gewisse Dinge funktionieren nicht wie erwartet: Operationen und Eigenschaften, für die die Reihenfolge der Daten wichtig sind, können zu unerwarteten Resultaten führen. Zwei typische Beispiele sind range-partitionierte Tabellen und ORDER BY-Klauseln.
Optimizer-Anomalien: Der Optimizer kann unter Umständen aufgrund einer falschen Datentyp-Auswahl keine gute Schätzung machen, was zu nicht optimalen Zugriffspfaden führt. Der Optimizer kann in einem solchen Fall seine Aufgabe nicht erfüllen, weil ihm die korrekte Information fehlt. Praxistipp Es gibt viele gute Gründe, die Datentypen korrekt und sorgfältig auszuwählen; man erspart sich damit viele Probleme.
8.1.6
Inkorrekte Verwendung von Bindvariablen
Aus Sicht der Performance haben Bindvariablen Vor- und Nachteile. Zu den Vorteilen zählt das Cursorsharing im Library-Cache und der damit verbundenen Verhinderung von Parsing. Der Nachteil von Bindvariablen in der WHERE-Klausel (und ausschließlich dort) ist, dass entscheidende Informationen dem Optimizer verborgen bleiben. Der Optimizer kann beispielsweise Literale besser verwenden als Bindvariablen. Dies ist speziell dann der Fall, wenn dieser prüfen muss, ob ein bestimmter Wert innerhalb oder außerhalb eines Wertebereichs liegt (größer oder kleiner als der größte oder der kleinste Attributswert), wenn ein Prädikat in der WHERE-Bedingung auf einem Wertebereich basiert (beispielsweise HIREDATE > '2009-12-31') oder wenn der Optimizer für die Optimierung Histogramme verwendet. Konsequenterweise sollte man Bindvariablen nur dann verwenden, wenn keine der drei erwähnten Bedingungen zutrifft. Ausgenommen davon sind SQL-Anweisungen, deren Parsezeit um Größenordnungen kleiner ist als deren Ausführungszeit. In diesem Fall ist der Einsatz von Bindvariablen nicht nur irrelevant für die Ausführungszeit, sondern es erhöht sich auch das Risiko von sehr ineffizienten Ausführungsplänen.
408
8.1 Designing for Performance Praxistipp Bindvariablen sollten auf keinen Fall zum Einsatz kommen, wenn der Optimizer maßgeblich von Histogrammen Gebrauch macht.
Bindvariable verringern das Sicherheitsrisiko durch SQL-Injection, weil die Syntax einer SQL-Anweisung über einen Bindvariablenwert nicht geändert werden kann.
8.1.7
Fehlender Einsatz von Advanced Datenbankfeatures
Oracle verfügt mit seiner High-End-Datenbank-Engine über zahlreiche Advanced-Features1. Wir empfehlen die datenbankseitigen Möglichkeiten soweit wie möglich zu nutzen und bereits existierende Features nicht manuell nachzubilden. Dies bedeutet natürlich auch, die mit der jeweiligen Version neu eingeführten Features speziell zu beachten und nicht nur hinsichtlich ihrer Funktionalität, sondern auch bezüglich Stabilität zu testen. Ein verbreitetes Argument gegen den Einsatz von sogenannten „advanced” Datenbankfeatures sind die eingeschränkten Portierungsmöglichkeiten auf Datenbanken anderer Hersteller – und damit eine gewisse Abhängigkeit von Oracle. Auf der anderen Seite werden Unternehmen die Datenbank unter einer bestimmten Applikation nur in Ausnahmefällen austauschen, sondern gleich die ganze Applikation ersetzen. Praxistipp Wir empfehlen die Entwicklung von datenbankunabhängigem Applikationscode nur dann, wenn dafür gute Gründe vorliegen. Auch wenn dies der Fall ist, sind die Erkenntnisse aus der Diskussion in Abschnitt 8.1.2 über Flexibilität vs. Performance zu beachten.
8.1.8
Fehlende Verwendung von Stored-Procedures
Ein Spezialfall des oben erwähnten Punktes ist die Verwendung von PL/SQL-StoredProcedures für die Verarbeitung großer Datenmengen. Das bekannteste Beispiel ist ein Extract-Transform-Load-Prozess (ETL). Erfolgt die Extrakt- und Ladephase in derselben Datenbank, ist es aus Performance-Sicht beinahe fahrlässig, in der Transformationsphase auf die Vorteile der SQL- und PL/SQL-Engine zu verzichten, welche die Quell- und ZielDaten verwaltet. Leider führt die Architektur diverser bekannter ETL-Werkzeuge genau zu diesem Verhalten. Das heißt, die Daten werden aus der Datenbank extrahiert (und oft auf einen anderen Server verschoben), transformiert und wieder in die Datenbank geladen. Praxistipp Für die optimale Performance empfehlen wir eine möglichst datennahe Verarbeitung mittels Einsatz von PL/SQL-Prozeduren.
1
Unter Advanced Features verstehen wir Datenbankfunktionen und -eigenschaften, die üblicherweise in anderen Datenbankprodukten nicht verfügbar sind
409
8 Optimierung
8.1.9
Ausführung von unnötigen Commits
Commit-Operationen führen zu Serialisierung. Der Grund dafür ist einfach: Es gibt einen einzigen Prozess, der Logwriter-Prozess, der Daten in die Redolog-Files schreibt. Weil eine serialisierte Operation nicht skaliert, sollte man sie aus Performance-Gründen soweit wie möglich verhindern oder zumindest minimieren. Teilweise ist dies durch das Zusammenfassen einzelner Transaktionen möglich – also beispielsweise das Laden von Datensätzen mittels Batchjobs. Anstatt nach jedem Datensatz ein Commit auszuführen, ist es vorteilhafter, die Daten in Batches einzufügen und nach jedem Batch einen Commit-Befehl auszuführen. Praxistipp Transaktionen sollten nicht zu häufig einen Commit-Befehl enthalten. Das Zusammenfassen von Transaktionen ist daher sinnvoll und meistens auch effizienter.
8.1.10 Häufiges Öffnen und Schließen von Datenbankverbindungen Das Erstellen einer Datenbankverbindung und Starten des damit verbundenen dedizierten Prozesses auf dem Datenbankserver ist bezüglich der erforderlichen Ressourcen und der notwendigen Zeit nicht zu unterschätzen. Schlimmster Fall ist eine Web-Applikation, die für jede Anfrage eine Datenbankverbindung öffnet und gleich wieder abbaut. Dies ist natürlich alles andere als optimal. In einer solchen Situation bietet sich der Einsatz eines Connection-Pools an. Praxistipp Häufiger Auf- und Abbau von Datenbankverbindungen ist zu vermeiden.
8.1.11 Verzicht auf Lasttests Der Sinn und Zweck von Integrations- und Acceptance-Tests ist die Verifizierung der funktionalen Anforderungen, der Performance, sowie der Applikationsstabilität. Es kann nicht genug betont werden, dass Performance-Tests dieselbe Wichtigkeit haben wie funktionale Tests. Liefert die Applikation ungenügende Antwortzeiten, ist das ebenso schlecht, wie wenn die funktionalen Anforderungen nicht erfüllt werden. In beiden Fällen kann die Applikation unbrauchbar sein. Auch wenn die Entwicklung, die Implementierung und die Durchführung von aussagekräftigen Integrations- und Acceptance-Tests keine einfache Aufgabe ist, darf man darauf nicht verzichten. Ohne Lasttests hat man keine Gewähr, dass die Applikation der erwarteten Belastung standhält. Praxistipp Um die erwartete Performance zu verifizieren, sollte eine Applikation nie ohne Lasttest entwickelt werden. Das Mantra sollte heißen: Was nicht getestet ist, wird nicht funktionieren.
410
8.2 Konfigurationsempfehlungen
8.2
Konfigurationsempfehlungen Die Datenbank-Engine ist direkt verantwortlich für die Performance der SQL-Anweisungen, die gegen die Datenbank ausgeführt werden. Ohne optimale Konfiguration wird man daher auch keine optimale Performance erzielen können. Die Konfiguration einer Datenbank-Engine besteht nicht nur aus Initialisierungsparametern, sondern auch aus System- und Objekt-Statistiken. Das Ziel dieses Abschnittes ist nicht die Vorstellung der magischen Konfiguration, die in jedem Fall optimale Ergebnisse liefert. Eine solche Konfiguration existiert aus zwei Gründen nicht:
Jede Applikation (und somit auch jede Datenbank) hat ihre eigenen, spezifischen Anforderungen und Belastungsprofile
Jedes System, bestehend aus unterschiedlichen Hard- und Software-Komponenten, hat seine eigene Charakteristik Daher besteht das Ziel dieses Abschnitts darin, Ihnen ein paar Konfigurations-Empfehlungen zu geben, die sich im Performance-Bereich bewährt haben.
8.2.1
Initialisierungsparameter
In den aktuellen Oracle-Datenbank-Releases existieren nicht sehr viele Parameter, die man explizit definieren muss, um eine optimale Konfiguration zu erhalten, weil bereits beim Starten der Instanz automatisch für diverse Parameter sinnvolle Werte gesetzt sind. Praxistipp Initialisierungsparameter sollte man nur dann spezifizieren, wenn dafür gute Gründe vorliegen, beispielsweise dann, wenn eine zugekaufte Applikation für die korrekte Funktion eine spezifische Parametrisierung voraussetzt, oder wenn die Standardwerte nicht zur optimalen Performance führen. Speziell im zweiten Fall muss ein gutes Verständnis über die zu ändernden Parameter vorliegen. Andernfalls ändert man die Konfiguration blind, ohne die Auswirkungen wirklich abschätzen zu können.
Aus Performance-Sicht gibt es Parameter in drei Kategorien:
Speicher-Subsystem Arbeitsspeicher Abfrageoptimierung (Optimizer) In den folgenden Abschnitten zeigen wir die wichtigsten Parameter und wie man gute Werte dafür ermitteln kann. Selten benutzte Parameter oder solche, die bereits an einer anderen Stelle in diesem Buch behandelt sind, werden an dieser Stelle nicht diskutiert. 8.2.1.1
Speicher-Subsystem
Die relevanten Parameter in dieser Kategorie sind disk_asynch_io, filesystemio_ options, asm_power_limit, asm_preferred_read_failure_groups und db_file_
411
8 Optimierung multiblock_read_count. Die Performance-Aspekte dieser Parameter sind, mit Ausnahmen von db_file_multiblock_read_count, vollständig in Kapitel 4 „Speicherplatzverwaltung“ beschrieben und werden daher an dieser Stellen nicht weiter behandelt.
Der Parameter db_file_multiblock_read_count wird zum Erreichen der maximalen I/O-Größe bei Multiblock-Leseoperationen (beispielsweise bei Full Table Scans) verwendet. Die aktuelle I/O-Größe ist durch das Produkt der Werte der beiden Parameter db_file_multiblock_read_count und db_block_size festgelegt. Das heißt, der Parameter db_file_multiblock_read_count definiert die Anzahl Blöcke, die bei einem Multiblockzugriff gelesen werden. Der berechnete Wert stellt jedoch lediglich einen Maximalwert dar. Folgende vier typische Situationen führen zu Multiblockzugriffen, die kleiner sind, als der Wert der mit dem Parameter db_file_multiblock_read_count ursprünglich spezifiziert wurde:
Die maximale I/O-Größe ist limitiert (abhängig von Version und Plattform) Blöcke mit Metadaten (beispielsweise Segmentheader) werden mit einem einzelnen Blockzugriff gelesen
Physische Leseoperationen erstrecken sich nie über mehrere Extents Blöcke, die sich bereits im Buffer-Cache befinden, werden mit Ausnahme von DirectReads, nicht nochmals aus dem Speicher-Subsystem gelesen Man muss den Multiblockzugriff als Performance-Eigenschaft betrachten. Deshalb sollte der Parameter db_file_multiblock_read_count auch explizit gesetzt sein. Normalerweise führen höhere Werte zu einer besseren Performance. Ein einfacher Full-Table-Scan mit unterschiedlichen Werten ergibt nützliche Erkenntnisse über den Einfluss dieses Parameters und hilft, den optimalen Wert zu finden. Seit 10g R2 gibt es auch die Möglichkeit, die Konfiguration des db_file_multiblock_read_count-Parameters automatisch von der Datenbank-Engine durchführen zu lassen. In diesem Fall darf man den Parameter nicht explizit definieren. Die Datenbank-Engine setzt den Parameter auf einen Wert, der physische Zugriffe von 1-MB-Größe erlaubt. Gleichzeitig sorgt ein Prüfmechanismus für die Verkleinerung des Parameters, wenn der Buffer-Chache im Verhältnis zur Anzahl Datenbankverbindungen sehr klein ist. 8.2.1.2
Arbeitsspeicher
Die Initialisierungsparameter, die man für die Parametrisierung der PGA und der SGA verwendet, sind in Kapitel 2 „Architektur und Administration“ beschrieben. Nachfolgend geben wir einige Empfehlungen, wie die Parameter für die optimale Nutzung des verfügbaren Arbeitsspeichers zu setzen sind. Eine wichtige Erkenntnis bei der Dimensionierung der Speicherstrukturen ist, dass „größer“ nicht zwingend „besser“ bedeutet. In der Tat kann die Datenbank-Engine bestimmte Speicherbereiche gar nicht vollständig nutzen, wenn sie zu groß sind. Aus diesem Grund bietet Oracle die Möglichkeit, die verschiedenen Komponenten automatisch anzupassen. Wie in Kapitel 2 „Architektur und Administration“ beschrieben, stehen für die SGA die folgenden Speicherverwaltungsmethoden zur Verfügung:
412
8.2 Konfigurationsempfehlungen
Automatisches Memory Management (ab 11g verfügbar) Automatisches Shared Memory Management (ab 10g verfügbar) Manuelles Memory Management Die unterschiedlichen Verwaltungsmethoden beeinflussen die Performance lediglich dadurch, dass sie zu unterschiedlichen Memory-Verteilungen führen können, und nicht, weil die eine oder die andere Methode schneller oder langsamer wäre. Entscheidend ist daher die Größe der Memory-Komponenten und nicht, wie diese zustande gekommen sind. Wir empfehlen deshalb, wenn immer möglich, die automatische Memory-Verwaltung einzusetzen und nur, wenn diese nicht zu einer optimalen Verteilung führt, die Konfiguration manuell vorzunehmen. Praxistipp Unter Linux kann man die automatische Memory-Verwaltung (z.B. durch die Definition von memory_target) nicht verwenden, wenn „huge pages” eingesetzt werden. Deren Verwendung kann den Speicherverbrauch auf OS-Ebene stark reduzieren, was vor allem dann der Fall ist, wenn sowohl die SGA, als auch die Zahl der Verbindungen zur Instanz groß sind. Wir empfehlen daher, „huge pages” mit automatischem Shared Memory Management zu verwenden.
Für folgende Speicherstrukturen trifft die Regel “größer ist besser” nicht zu: Shared-Pool, Large-Pool, Streams-Pool und Java-Pool. Die Datenbank-Engine kann nicht in jedem Fall den verfügbaren Arbeitsspeicher vollständig ausnutzen. Viel freier Platz in einem der erwähnten Pools ist ein Hinweis auf eine suboptimale Memory-Verteilung. Die aktuelle Arbeitsspeicherausnutzung lässt sich mit der folgenden Abfrage kontrollieren: SQL> 2 3 4 5 6 7 8
SELECT pool, sum(decode(name,'free sum(decode(name,'free sum(decode(name,'free sum(decode(name,'free FROM v$sgastat WHERE pool IS NOT NULL GROUP BY pool;
memory',0,bytes)) AS used_mem, memory',0,bytes))/sum(bytes)*100 AS "USED_%", memory',bytes,0)) AS free_mem, memory',bytes,0))/sum(bytes)*100 AS "FREE_%"
POOL USED_MEM USED_% FREE_MEM FREE_% ------------ ---------- ------ ---------- -----shared pool 7403093104 95.93 314426256 4.07 streams pool 665224 0.99 66443640 99.01 large pool 0 0.00 402653184 100.00 java pool 0 0.00 402653184 100.00
Wenn Sie sehen wollen, wie das Memory über eine bestimmte Zeit verwendet wurde, können Sie über die View dba_hist_sgastat auf die historischen Daten zugreifen (der Zugriff auf diese View bedingt eine Lizenz für die Diagnostics-Pack-Option). Der Shared-Pool, der Large-Pool, der Streams-Pool und der Java-Pool lassen sich nur dimensionieren, indem man die erwartete Last generiert und dabei den Memory-Verbrauch beobachtet. Der Inhalt dieser Pools ist sehr dynamisch und abhängig von den verwendeten Features, der Anzahl gleichzeitiger Sessions und der Anzahl offener Cursors. Um herauszufinden, ob die Memoryverteilung suboptimal ist, muss man folgende Punkte prüfen:
413
8 Optimierung
Ist zu viel freier Platz verfügbar (Hunderte oder Tausende von Megabytes)? Ist kein Platz mehr verfügbar und generiert die Datenbank-Engine in Folge davon einen ORA-04031-Fehler? Zusätzlich kann man für den Shared-Pool mit folgender Abfrage prüfen, ob die für das Hard-Parsing benötigte Zeit im Verhältnis zur Gesamt-Datenbank-Zeit zu groß ist: SQL> SELECT sum(decode(stat_name,'DB time',0,value))/ 2 sum(decode(stat_name,'DB time',value,0))*100 AS percent 3 FROM v$sys_time_model 4 WHERE stat_name IN ('DB time','hard parse elapsed time'); PERCENT ------6.08
Im Idealfall sollte die Auswertung einen Wert von 1 Prozent oder weniger ergeben. Zweistellige Werte sind definitiv nicht gut. Bevor man jedoch den Shared-Pool vergrößert, sollte man auch prüfen, ob die Bindvariablen korrekt genutzt werden. Grundsätzlich kann man die Parse-Zeit nur verhindern, wenn ein bestimmtes SQL-Statement mehrmals ausgeführt wird. Das heißt, wenn ein SQL-Statement nicht mehrfach genutzt werden kann, ist die Vergrößerung des Shared-Pools keine Lösung. Abhilfe schafft dann nur die Anpassung der Applikation. Ist dies nicht möglich, kann man als Workaround den Parameter cursor_sharing auf den Wert force setzen. Die Dimensionierung des Buffer-Cache ist recht einfach. Man kann ihm im Wesentlichen den gesamten, nicht anderweitig benutzten Arbeitsspeicher zur Verfügung stellen. Die einzige Grenze, die zu überschreiten nicht sinnvoll ist, ist die Größe der Datenbank, oder für die Nicht-Default-Caches, die Größe der zu „cachenden“ Objekte. Eine ähnliche Regel lässt sich auf den Keep-Cache anwenden. Er kann so groß wie nötig definiert werden, um alle Objekte zu speichern, die für die Benutzung dieses Buffers konfiguriert sind. Der einzige Buffer-Cache, den man nicht zu groß machen sollte, ist der Recycle-Cache. Dessen Inhalt wir ja per Definition nicht wiederverwendet. Die Größe des Recycle-Cache beträgt normalerweise daher nur ein paar Granules2. Mit den aktuellen Oracle-Versionen ist es normalerweise nicht nötig, die Größe des Redolog-Buffers zu definieren. Man kann die Größe also ruhig auf dem Defaultwert belassen. Tatsächlich stammen die Probleme im Bereich von Redo normalerweise von langsamen I/O-Operationen, exzessiver Redo-Aktivität oder zu vielen Commit-Operationen und nicht von der Größe des Redolog-Buffers. Um herauszufinden, ob Ihr System zu wenig oder zu viel PGA alloziert hat, kann man die nachfolgende Abfrage ausführen. Wenn der Wert von „maximum PGA allocated” viel höher oder tiefer ist als der Wert von „aggregate PGA target parameter”, dann ist der Wert des Parameters pga_aggregate_target (oder der durch das automatische MemoryManagement eingestellte Wert) vermutlich nicht optimal. Das folgende Beispiel zeigt eine überallozierte PGA. Das heißt, der Wert des Parameters pga_aggregate_target ist zu klein definiert. 2
414
Allokationseinheit für SGA-Komponenten, die abhängig von SGA_MAX_SIZE ist
8.2 Konfigurationsempfehlungen SQL> SELECT name, value, unit 2 FROM v$pgastat 3 WHERE name IN ('aggregate PGA target parameter', 4 'maximum PGA allocated'); NAME VALUE UNIT ------------------------------ ---------- ----aggregate PGA target parameter 1073741824 bytes maximum PGA allocated 1648665600 bytes
Um zu prüfen, ob die PGA korrekt eingestellt ist, kann man auch die Statistiken aus der View v$sql_workarea_histogram verwenden. Im besten Fall, wenn die PGA nicht zu klein dimensioniert ist, sollten nur optimale Ausführungen vorhanden sein. SQL-Anweisungen, die sehr viele Daten verarbeiten, können durchaus ganz ohne Onepass- und MultipassAusführungen durchgeführt werden. Auf jeden Fall sollten Onepass- und Multipass-Ausführungen im Bereich von ein paar wenigen Prozenten der Gesamtanzahl Ausführungen liegen. SQL> SELECT low_optimal_size||'-'||high_optimal_size AS range, 2 optimal_executions/total_executions*100 AS "OPTIMAL_%", 3 onepass_executions/total_executions*100 AS "ONEPASS_%", 4 multipasses_executions/total_executions*100 AS "MULTIPASS_%", 5 ratio_to_report(total_executions) OVER ()*100 AS "EXEC_%" 6 FROM v$sql_workarea_histogram 7 WHERE total_executions > 0 8 ORDER BY low_optimal_size; RANGE OPTIMAL_% ONEPASS_% MULTIPASS_% EXEC_% -------------------- ---------- ---------- ----------- ---------2048-4095 100.0 0.0 0.0 93.7 65536-131071 100.0 0.0 0.0 1.0 131072-262143 100.0 0.0 0.0 1.1 262144-524287 100.0 0.0 0.0 0.6 524288-1048575 100.0 0.0 0.0 2.8 1048576-2097151 100.0 0.0 0.0 0.8 2097152-4194303 99.8 0.2 0.0 0.0 4194304-8388607 99.6 0.4 0.0 0.0 8388608-16777215 99.6 0.4 0.0 0.0 16777216-33554431 98.6 1.4 0.0 0.0 33554432-67108863 97.8 2.2 0.0 0.0 67108864-134217727 85.6 14.4 0.0 0.0 134217728-268435455 14.3 85.7 0.0 0.0 268435456-536870911 32.0 68.0 0.0 0.0
8.2.1.3
Optimizer
Der wichtigste Parameter im Zusammenhang mit dem Optimizer ist optimizer_mode. Für die Wahl dieses Parameters muss man sich fragen, ob es für den Optimizer wichtiger ist, einen Ausführungsplan für die schnelle Lieferung des ersten oder des letzten Datensatzes einer bestimmten Resultatmenge zu erstellen.
Wenn die Anzeige des letzten Datensatzes wichtig ist, dann sollte man den Wert all_rows (dies ist der Defaultwert) verwenden. Eine solche Konfiguration wird typi-
scherweise in Reportingsystemen, in OLAP-Systemen, Data-Warehouse-Applikationen und Middle-Tier-Komponenten verwendet, die Daten in Caches halten.
Wenn die Anzeige der ersten n Datensätze wichtig ist, sollte man den Wert
first_
rows_n (wobei n die Werte 1, 10, 100, oder 1,000 Rows annehmen kann) verwenden.
Diese Konfiguration kommt typischerweise in OLTP-Systemen vor. Der ältere Parame-
415
8 Optimierung ter first_rows ist nur noch aus Gründen der Rückwärtskompatibilität vorhanden und sollte nicht mehr verwendet werden. Mit jeder Datenbank-Version führt Oracle neue Optimizer-Features ein. Wenn Sie eine neue Version einsetzen, kann mit dem Parameter optimizer_features_enable das ursprüngliche Verhalten beibehalten werden. Dies ist jedoch nur ein Workaround. Früher oder später sollte man die Applikation an den neuen Datenbank-Release anpassen. Zudem ist zu beachten, dass nicht alle neuen Features mit diesem Parameter ausgeschaltet werden. Wir empfehlen daher, den Parameter optimizer_features_enable sehr vorsichtig zu verwenden. Der Parameter optimizer_index_cost_adj wird für die Kostenabschätzung von Tabellenzugriffen über Indexscans eingesetzt. Der Default ist 100. Werte größer als 100 machen Indexzugriffe teurer und damit Fulltablescans attraktiver. Werte kleiner als 100 machen Indexzugriffe günstiger. Daher kann man den Parameter optimizer_index_cost_adj, abhängig davon, ob sich der Optimizer für zuviel oder zuwenig Indexscans entscheidet, entsprechend anpassen. Das Problem dabei ist, dass mit Werten, die kleiner als 100 sind, auch gewisse Instabilitäten bei der Indexauswahl entstehen können. Erwähnenswert sind zudem die Systemstatistiken, die sich ähnlich wie die Parameter-Einstellungen auswirken, jedoch keine negativen Nebeneffekte aufweisen. Dies bedeutet, dass es mit guten Systemstatistiken nicht notwendig ist, diesen Parameter zu verwenden. optimizer_index_caching ist ein weiterer Parameter, der die Kostenabschätzung von Indexzugriffen beeinflusst. Sein Defaultwert ist 0. Werte größer 0 verringern die Kosten von Indexscans bei In-List-Iterationen und im inneren Loop von Nested-Loop-Joins (ausschließlich in diesen Fällen). Diesen Parameter muss man anpassen, wenn der Optimizer zu wenig Nested-Loops verwendet, oder wenn er zu viele In-List-Prädikate appliziert, ohne die Vorteile von Indizes zu nutzen.
Die oben diskutierten Optimizer-Parameter beeinflussen die Kostenschätzungen des Optimizers und somit die Auswahl der verfügbaren Ausführungspläne. Die nachfolgend beschriebenen Parameter haben einen anderen Zweck: sie sind für die Aktivierung bzw. Deaktivierung von spezifischen Eigenschaften zuständig. Sie sollten demzufolge entsprechend den applikatorischen Anforderungen konfiguriert werden. Generelle Konfigurationsempfehlungen sind deshalb nicht möglich. Der Optimizer macht seine Schätzungen ausschließlich aufgrund der im Data Dictionary abgelegten Objektstatistiken. Mit der Einführung von Dynamic Sampling hat sich dies jedoch geändert und es werden bestimmte Statistiken dynamisch während der Parsephase ermittelt. Der Parameter optimizer_dynamic_sampling zeigt, wann und wie Dynamic Sampling verwendet wird. Der Wert 0 (der Default für 9i R1) schaltet dieses aus. Die Werte 1 (Default in 9i R2) und 2 (Default ab 10g) sind normalerweise nicht sehr nützlich. Sie aktivieren Dynamic Sampling lediglich für Tabellen ohne Objektstatistiken (wie wir später sehen werden, sollten Tabellen und Indizes immer über aktuelle Objektstatistiken verfügen). Eine Ausnahme bilden temporäre Tabellen, die typischerweise nicht über Objektstatistiken verfügen. Werte zwischen 3 und 10 sind sinnvoll für die Verbesserung der Selektivitätsabschätzung komplexer Prädikate. Wenn der Optimizer nicht in der Lage ist,
416
8.2 Konfigurationsempfehlungen korrekte Schätzungen bei komplexen Prädikaten zu machen, empfehlen wir den Parameter optimizer_dynamic_sampling auf 4 oder höher zu setzen. Andernfalls belassen wir ihn auf dem Defaultwert. Der Parameter optimizer_secure_view_merging, der seit 10g R2 vorhanden ist, aktiviert oder deaktiviert Secure View Merging. Per Default ist diese Funktion eingeschaltet. Das bedeutet, der Optimizer prüft ob View-Merging zu einem Sicherheitsproblem führen könnte. Falls ein Risiko besteht, wird View-Merging unterbunden, was zu suboptimaler Performance führen kann. Aus diesem Grund (außer Sie setzen Views aus Sicherheitsgründen ein) empfehlen wir, diesen Parameter auf FALSE zu setzen. Der Parameter optimizer_use_sql_plan_baselines aktiviert bzw. deaktiviert die Verwendung von SQL Plan Baselines. Diese sind standardmäßig aktiviert, was auch sinnvoll ist. Der Parameter query_rewrite_enabled aktiviert bzw. deaktiviert die Verwendung von Query Rewrites auf Materialized Views. Standardmäßig ist diese Funktion seit Version 10g aktiviert. query_rewrite_integrity ist ein weiterer Parameter im Zusammenhang mit Query Rewrite. Er legt fest, in welchen Situationen nichterzwungene Beziehungen und Stale Materialized Views zum Einsatz kommen. Standardmäßig wird der jeweils höhere Integritätsgrad forciert. Dieses Verhalten sollte man nur dann ändern, wenn man die Auswirkungen gut verstanden hat. Der Parameter sqltune_category spezifiziert, welche SQL-Profilkategorie aktiv ist. Standardmäßig ist die DEFAULT-Kategorie aktiv. Der Parameter star_transformation_enabled aktiviert bzw. deaktiviert Star-Transformationen. Standardmäßig sind diese nicht aktiviert. Ist die Funktion aktiviert, kann man wählen ob die Vorteile von temporären Tabellen genutzt werden sollen Der Parameter use_stored_outlines aktiviert bzw. deaktiviert die Verwendung von Stored Outlines. Sind sie aktiviert, kann man eine spezifische Kategorie definieren. Leider lässt sich dieser Parameter nicht in einer Intialisierungsdatei (init.ora oder spfile.ora) speichern. Der Parameter muss entweder auf Systemebene (nach jedem Instanzstart) oder auf Sessionebene (nach jedem Sessionaufbau) gesetzt werden.
8.2.2
Systemstatistiken
Die Kostenabschätzungen des Optimizers basierten auf der Anzahl physischer Lesezugriffe, die für die Ausführung einer SQL-Anweisung notwendig sind. Dies ist bekannt unter dem Begriff „I/O Cost Model“. Der Hauptnachteil dieses Modell ist die kostenmäßige Gleichbehandlung von Single-Block- und Multiblock-Lesezugriffen, obwohl in den meisten Fällen das Lesen eines einzelnen Blocks schneller ist als das Lesen mehrerer Blöcke. Als Folge davon werden Multiblockzugriffe wie beispielsweise Full Table Scans bevorzugt. Seit 9i ist eine neues Kostenmodell verfügbar. Das „CPU Cost Model“ soll diesen Mangel beheben. Es kommt jedoch erst ab 10g standardmäßig zum Einsatz und setzt das Vorhandensein von sogenannten „Systemstatistiken“ voraus. Diese stellen der Datenbank-
417
8 Optimierung Engine Informationen über die System-Performance zur Verfügung. Im Wesentlichen werden Performance-Informationen über das Speicher-Subsystem und die CPU ermittelt. Das CPU Cost Model berücksichtigt – trotz der Namengebung – auch die Kosten der physischen Lesezugriffe, wobei die Kostenabschätzung nicht nur auf der Anzahl physischen Lesezugriffen basiert, sondern auch auf der Performance des Speicher-Subsystems. Für die Berechnung der Systemstatistiken muss die Datenbank-Engine die Performance des Speicher-Subsystems und der CPU messen. Dies erfolgt mithilfe eines Benchmarks. Für die CPU kommt ein von Oracle erstellter synthetischer Benchmark zum Einsatz. Für das Speicher-Subsystem hat man die Wahl zwischen einem von Oracle erstellten synthetischen Benchmark oder einem eigenen Benchmark (auf einer Produktionsdatenbank ist es üblich, die vorhandene Last als Referenz zu verwenden). Die Prozedur gather_system_stats des Packages dbms_stats berechnet die Systemstatistiken. Der synthetische Benchmark wird verwendet, indem man für den Parameter gathering_mode den Wert noworkload einsetzt (siehe folgendes Beispiel). dbms_stats.gather_system_stats(gathering_mode => 'noworkload')
Die Verwendung der effektiven Last als Benchmark bedingt diverse Schritte:
Der Wert start im Parameter gathering_mode startet das Sammeln von Systemstatistiken. dbms_stats.gather_system_stats(gathering_mode => 'start')
Nun muss man dem System genügend Zeit gewähren, um die Last relevanter Systemstatistiken zu generieren (in einem Produktionssystem mindestens 30 Minuten).
Das Sammeln von Systemstatistiken beendet man, indem man für den Parameter gathering_mode der Wert stop setzt. Gleichzeitig werden damit die Statistikdaten im
Data Dictionary gespeichert. dbms_stats.gather_system_stats(gathering_mode => 'stop')
Die Ermittlung von Systemstatistiken ist wesentlich für die Verbesserung der Kostenabschätzung des Optimizers, auch wenn deren Bedeutung nicht zu überschätzen ist. Was zählt ist, dass der Optimizer mithilfe der Statistiken gute Ausführungspläne generieren kann. Die Systemstatistikwerte lassen sich nur mit einer Abfrage auf die interne Tabelle sys.aux_stats$ überprüfen. Oracle stellt leider keine View für diesen Zweck zur Verfügung. Praxistipp Wenn Sie ein Set von Systemstatistiken gefunden haben, das gute Ergebnisse liefert, empfehlen wir, diese Statistikwerte einzufrieren und somit das System zu stabilisieren. Die Systemstatistiken sollten also wie ein Datenbank-Parameter betrachtet werden, den man nicht periodisch ändert. Eine Aktualisierung der Statistiken ist nur nach einer größeren Hardware- oder SoftwareÄnderung notwendig. Es ist zudem sehr verbreitet, das gleiche Set von Systemstatistiken für alle Datenbanken, die zu einer bestimmten Applikation gehören (Entwicklung, Test, Acceptance und Produktion), zu verwenden. Damit sollte der Optimizer für alle Umgebungen die gleichen Ausführungspläne generieren.
418
8.2 Konfigurationsempfehlungen Um die Systemstatistiken von einer Datenbank in eine andere zu transferieren, führt man folgende Schritte aus:
Erstellen Sie auf der Quelldatenbank eine Scratch-Tabelle (im folgenden Beispiel mit dem Namen MYSTATS bezeichnet) für die Ablage der Systemstatistiken. dbms_stats.create_stat_table(ownname => user, stattab => 'MYSTATS', tblspace => 'USERS');
Kopieren Sie die Systemstatistiken in die Scratch-Tabelle. dbms_stats.export_system_stats(statown => user, stattab => 'MYSTATS');
Kopieren Sie nun die Scratch-Tabelle von der Quelldatenbank in die Zieldatenbank. Dazu können Sie beispielsweise Export/Import oder einen Datenbank-Link verwenden.
Importieren Sie auf der Zieldatenbank die Systemstatistiken von der Scratch-Tabelle in das Data Dictionary. dbms_stats.import_system_stats(statown => user, stattab => 'MYSTATS');
8.2.3
Objektstatistiken
Objektstatistiken beschreiben die in der Datenbank gespeicherten Daten. Sie zeigen beispielsweise, wie viele Datensätze pro Tabelle vorhanden sind. Ohne diese quantitative Information könnte der Optimizer nie die richtige Entscheidung treffen, wie etwa die Wahl der richtigen Join-Methode für kleine oder große Resultatmengen. Für das Sammeln der Objektstatistiken stellt Oracle mit dem Package dbms_stats diverse Prozeduren zur Verfügung:
gather_database_stats: Sammelt Objektstatistiken über die gesamte Datenbank gather_dictionary_stats: Sammelt Objektstatistiken über das Data Dictionary Dieses beinhaltet nicht nur Objekte aus dem SYS-Schema, sondern auch Objekte von optional installierten Datenbank-Komponenten. Diese Prozedur ist ab 10g verfügbar.
gather_fixed_objects_stats: Sammelt Objektstatistiken von Fixed-Tabellen im Data Dictionary. Die View v$fixed_table gibt Auskunft, welche Tabellen mit dieser Prozedur berücksichtigt werden. Diese Prozedur ist ab 10g verfügbar.
gather_schema_stats: Sammelt Objektstatistiken von einem Schema gather_table_stats: Sammelt Objektstatistiken von einer Tabelle und optional von deren Indizes
gather_index_stats: Sammelt Objektstatistiken von einem Index Vor der Version 10g war der DBA für das Sammeln der Objektstatistiken mittels einer der oben beschriebenen Prozeduren verantwortlich. Nun sorgt ein automatischer Job für aktuelle Statistiken. Dies ist sehr nützlich, weil aktuelle Statistiken die Regel und nicht die Ausnahme sein sollten. Mit anderen Worten: Ändern sich die Daten, ändern sich auch die Objektstatistiken.
419
8 Optimierung Praxistipp Wir empfehlen, den Standardjob für das Sammeln der Objektstatistiken nicht zu deaktivieren. Man sollte jedoch die Standardkonfiguration und die Ausführungszeiten überprüfen und den Applikationsanforderungen anpassen.
Die Konfiguration des dbms_stats-Packages auf Tabellenebene, mit der Prozedur dbms_stats.set_table_prefs, ist erst ab 11g möglich. Bei älteren Releases sollte die spezifische Behandlung der Statistiken auf Tabellenebene mit einem Job erfolgen, der vor dem Standardjob ausgeführt wird. Weil der Standardjob nur Tabellen mit veralteten Statistiken berücksichtigt, überspringt er diese Tabellen. Auch mit Locking auf Tabellenebene (mit der Prozedur dbms_stats.lock_table_stats) kann man sicherstellen, dass der Default-Job für Tabellen, die eine spezifische Behandlung erfordern, keine Statistiken berechnet. Wenn die Datenverarbeitung viele Daten ändert, sollte man nicht auf die geplante, automatische Objektstatistikberechnung warten. Am einfachsten wird das Sammeln der Objektstatistiken nach größeren Datenänderungen als Teil der Verarbeitung ausgeführt. Wenn sich also Daten substantiell ändern, sollte das Sammeln der Statistiken unmittelbar danach erfolgen.
8.3
Vorgehen bei Performance-Problemen Auch wenn Datenbank-Design und Konfiguration sorgfältig erarbeitet sind, ist die Wahrscheinlichkeit groß, dass früher oder später die Performance einer Applikation in Frage gestellt wird. Es können immer wieder unerwartete Situationen oder Probleme auftreten, die unsere Pläne ändern. In diesem Abschnitt beschreiben wir die zwei Hauptaufgaben für die Bearbeitung von Performance-Problemen:
Probleme einordnen Probleme lösen Der erste Aufgabenbereich ist nur dann relevant, wenn man für die Analyse der Performance-Probleme einer Applikation zuständig ist und nicht nur ein spezifisches Problem behandeln muss. Dies ist beispielsweise dann der Fall, wenn Ihnen jemand sagt: „Ein Endbenutzer beschwert sich andauernd über schlechte Performance. Finden Sie heraus, was die Ursache ist”. Anders ist die Situation, wenn Sie hören: „Die Ausführung des Reports XY dauert viel zu lange”. Im ersten Fall haben Sie zunächst keine Vorstellung, welche Teile der Applikation in Frage kommen. Im zweiten wissen Sie bereits, welcher Teil der Applikation analysiert werden muss.
420
8.3 Vorgehen bei Performance-Problemen
8.3.1
Probleme einordnen
Der erste Schritt bei der Behandlung von Performance-Problemen besteht aus der Identifikation des Problems aus Geschäftssicht, der Priorisierung und der Zieldefinition (siehe Abbildung 8.2). Eine Betrachtung aus Geschäftssicht ist wichtig, weil der Zweck einer Applikation darin besteht, einen Nutzen für das Geschäft zu schaffen. Konsequenterweise liegt der Systemoptimierung die Maximierung des Geschäftsnutzens zugrunde.
Identifiziere die Probleme aus Geschäftssicht
Priorisiere jedes Problem
Setze ein Optimierungsziel für jedes Problem
Abbildung 8.2 Vorgehen für die Einordnung von Performance-Problemen
Natürlich kann man Geschäftsprobleme nicht erkennen, indem man nur die Systemstatistiken betrachtet. Wenn eine Überwachung der Service-Levels (basierend auf einem SLA) vorhanden ist, offenbaren sich Performance-Probleme durch die Identifikation von Geschäftsoperationen, die ihre Anforderungen nicht erfüllen. Andererseits gibt es oft keine andere Möglichkeit, als mit den Benutzern oder den Applikationsverantwortlichen zu sprechen. Solche Diskussionen können zu einer Liste von Geschäftsoperationen führen wie beispielsweise das Anlegen eines neuen Users, Ausführen eines bestimmten Reports oder Laden von Daten, die als langsam empfunden werden. Wenn die problematischen Geschäftsoperationen bekannt sind, kann man diese nach Priorität ordnen. Für diesen Zweck stellt man Fragen wie: „Wenn wir nur fünf Probleme bearbeiten können, welche davon sollen behandelt werden?” Natürlich sollten möglichst alle Probleme gelöst werden, aber oftmals sind die Zeit, das Budget, oder beides limitiert. Zudem kann man Fälle, die sich gegenseitig beeinflussen, normalerweise nicht ignorieren. Wichtig ist auch, dass nicht nur die absoluten Performance-Werte die Priorisierung beeinflussen sollte. So darf beispielsweise bei der Behandlung von Reporting-Problemen nicht in jedem Fall derjenige Report die höchste Priorität erhalten, der am langsamsten läuft. Möglicherweise wird ein schnellerer Report häufiger ausgeführt und man muss ihn deshalb höher priorisieren und zuerst optimieren. Einmal mehr sind auch hier die Geschäftsanforderungen die treibende Kraft. Für jede Geschäftsoperation sollte man ein quantifizierbares Optimierungsziel definieren wie beispielsweise: “Wenn die Schaltfläche XY angeklickt wird, darf die Antwortzeit maximal zwei Sekunden betragen“. Wenn diese Anforderungen an die Performance definiert sind oder sogar ein Service-Level-Agreement vereinbart ist, sind die Optimierungsziele bekannt. Ansonsten muss man – einmal mehr – die Ziele anhand der Geschäftanforderungen optimieren. Beachten Sie auch, dass Sie ohne Optimierungsziel nicht wissen, wann die Suche nach einer besseren Lösung beendet ist. Das heißt, die Optimierung kann sich endlos hinziehen, was sicher nicht anzustreben ist, denn Aufwand und Nutzen sollten immer in einem vernünftigen Verhältnis stehen.
421
8 Optimierung
8.3.2
Probleme lösen
Fehlersuche und Problemlösung sind auf Gesamtsystem-Ebene viel komplexer als auf der Ebene von Einzelkomponente. Daher sollte man, wenn immer möglich, nur ein Problem zur gleichen Zeit bearbeiten. Halten Sie sich strikt an die Liste der erfassten Probleme und arbeiten Sie diese gemäß der Priorisierung ab. Für jedes Problem sollte man drei Fragen beantworten (siehe Abbildung 8.3):
Wo wird die Zeit verbraucht? Zuerst muss man identifizieren, wo die Zeit verloren geht. Wenn beispielsweise eine bestimmte Operation zehn Sekunden dauert, ist zu analysieren, welches Modul, oder welche Komponente den größten Anteil dieser zehn Sekunden beansprucht.
Wie wird die Zeit verbraucht? Wenn bekannt ist, wo die Zeit verbraucht wird, muss man untersuchen, wie diese Zeit verbraucht wird. Sie finden beispielsweise heraus, dass die Applikation 4,2 Sekunden für CPU, 0,4 Sekunden für I/O-Operationen und 5,1 Sekunden für das Dequeueing einer Meldung benötigt, die von einer anderen Komponente kommt.
Wie kann man die verbrauchte Zeit reduzieren? Schlussendlich muss man herausfinden, wie man die Operation schneller machen kann. Dabei ist entscheidend, dass man sich auf die zeitintensivsten Teile der Verarbeitung konzentriert. So macht es beispielsweise wenig Sinn, zuerst die I/O-Operationen zu optimieren, die nur wenige Prozent der Gesamtverarbeitungszeit beanspruchen, auch wenn diese langsam sind.
Wo wurde die Zeit verbraucht?
Wie wurde die Zeit verbraucht?
Wie kann die verbrauchte Zeit reduziert werden?
Abbildung 8.3 Drei Fragen, die man bei der Problembearbeitung beantworten muss.
Die positiven Nebeneffekte lösen durch die Implementierung der getroffenen Maßnahmen manchmal auch andere Probleme. Natürlich kann auch der umgekehrte Fall eintreffen: Umgesetzte Maßnahmen führen zu neuen Problemen. Es ist deshalb wichtig, alle möglichen Nebeneffekte zu berücksichtigen, die eine bestimmte Anpassung bewirken könnten. Und natürlich muss man alle Änderungen gründlich testen, bevor man sie auf dem Produktionssystem implementiert.
8.4
Identifikation von Performance-Problemen Im vorangehenden Abschnitt haben wir das Vorgehen bei Performance-Problemen beschrieben. Das Ziel dieses Abschnittes ist es, die wichtigsten Datenbank-Features vorzustellen, die für das Sammeln von Informationen über das Runtime-Verhalten einer Applikation verfügbar sind, und damit herauszufinden, wo und wie die Zeit innerhalb der Datenbank verbraucht wird (siehe Abbildung 8.3).
422
8.4 Identifikation von Performance-Problemen Der erste Punkt, den man im Zusammenhang mit Performance-Problemen beachten sollte, ist die Frage, ob das Problem reproduzierbar ist. In diesem Fall ist vieles einfacher. Wenn man das Problem reproduzieren kann, sollte es eigentlich sehr leicht sein, eine kontrollierte Messung durchzuführen und das Problem dann zu identifizieren, wenn es tatsächlich in der Applikation auftritt. Diesen Fall behandeln wir in Abschnitt 8.4.1 „Die Analyse von reproduzierbaren Problemen”. Wenn das Problem nicht reproduzierbar ist, gibt es zwei Möglichkeiten: Entweder man wartet, bis das Problem wieder auftritt, oder man schaut in einem Repository nach, welche historischen Performance-Statistiken vorhanden sind. Beide Fälle beschreiben wir in den folgenden zwei Abschnitten „Echtzeit-Analyse von nichtreproduzierbaren Problemen“ und „Nachträgliche Analyse von nichtreproduzierbaren Problemen“. Liegt die Ursache der schlechten Performance in der Datenbank, muss man diejenigen SQL-Anweisungen untersuchen, die die meiste Zeit benötigen, und zwar unabhängig davon, ob ein Problem reproduzierbar ist oder nicht. Für jede dieser SQL-Anweisungen sind sämtliche Informationen zu sammeln, die für das Verständnis des Problems hilfreich sind. Im Speziellen sind das der Ausführungsplan, die wichtigsten Laufzeit-Statistiken wie Anzahl verarbeiteter Datensätze, CPU-Verbrauch und die aufgetretenen Wait-Events. Wir beschreiben in diesem Abschnitt, wie die Informationen zu finden sind, und konzentrieren uns auf die Methoden, die sich aus unserer Erfahrung für die Analyse der häufigsten Probleme bewährt haben.
8.4.1
Die Analyse von reproduzierbaren Problemen
Die einfachste Methode, um reproduzierbare Probleme zu analysieren, ist, alle DatenbankCalls zu untersuchen, die eine Applikation zur Laufzeit auslöst. Dazu stellt Oracle SQLTrace zur Verfügung. SQL-Trace generiert vereinfacht formuliert Trace-Dateien, die für jeden Datenbank-Call die Informationen über den Call selbst sowie Performance-Daten wie Elapsed-Time, CPU-Verbrauch und Waits, beinhalten. Um ein Problem mit SQL-Trace zu analysieren, muss man die in Abbildung 8.4 dargestellten Schritte ausführen.
SQL-Trace einschalten
Problem reproduzieren
SQL-Trace ausschalten
Tracedatei finden
Tracedatei formatieren
Output-File analysieren
Abbildung 8.4 Essenzielle Schritte für die Problemanalyse mittels SQL-Trace
Ab 10g verwendet man normalerweise das Package dbms_monitor, um SQL-Trace einbzw. auszuschalten. Für den gleichen Zweck stehen vier weitere Methoden zur Verfügung: das Statement ALTER SESSION sowie die Packages dbms_session, dbms_support und dbms_system. Weil diese Methoden nur bis einschließlich 9i relevant waren, gehen wir an dieser Stelle nicht weiter darauf ein.
423
8 Optimierung Im ersten Schritt wird SQL-Trace eingeschaltet. Dazu muss man wissen, wie die Datenbankaufrufe identifiziert werden können. SQL-Trace kann man auf ganz unterschiedlichen Ebenen aktivieren. Am häufigsten schaltet man es auf Session-Ebene ein. Damit werden die Informationen von allen Datenbank-Aufrufen einer spezifischen Session in eine TraceDatei geschrieben. Die Session, die den Applikationscode (die SQL-Statements) ausgeführt hat, muss hierzu natürlich identifiziert werden. Ist die Session bekannt, kann man mit der folgenden PL/SQL-Anweisung SQL-Trace aktivieren (beachten Sie, dass die Session mit der Session-ID und der Serial-Number identifiziert ist): dbms_monitor.session_trace_enable(session_id => 127, serial_num => 29)
Kann man die Session nicht identifizieren (weil beispielsweise ein Connection-Pool verwendet wird), bietet das Package dbms_monitor die Möglichkeit, SQL-Tracing aufgrund weiterer Session-Attribute einzuschalten:
Client-Identifier: Dieser String identifiziert den Client, wobei dieser nicht zwingend eindeutig ist
Service-Name: Der Service, der verwendet wurde, um die Verbindung zur Datenbank zu öffnen
Modul-Name: Die Module, die von einer Session verwendet werden Action-Name: Die Aktion, die gerade ausgeführt wird Während der Service-Name bei einer Verbindung über einen Datenbankservice immer vorhanden ist, sind die anderen Session-Attribute explizit von der Applikation zu definieren. Andernfalls sind sie für die Datenbank-Engine unbekannt (NULL). Die SessionAttribute kann man entweder mit einer PL/SQL-Prozedur (für den Client-Identifier verwendet man die Prozedur dbms_session.set_identifier, für den Modul- und ActionName steht die Prozedur dbms_application_info.set_module zur Verfügung) oder über Funktionen, die in APIs wie OCI, JDBC oder ODP.NET integriert sind, definieren. Der folgende PL/SQL-Aufruf aktiviert SQL-Trace für alle Sessions, die den Client-Identifier als Parameter spezifiziert haben: dbms_monitor.client_id_trace_enable(client_id => 'myclient')
Der folgende PL/SQL-Aufruf aktiviert SQL-Trace für alle Sessions mit den spezifizierten Attributen als Parameter. Der einzige Parameter, der keinen Defaultwert hat, ist der Service-Name. Der Defaultwert des Modul-Name und des Action-Name ist any_module, bzw. any_action. Bei einer Real-Application-Cluster-Datenbank kann man mit dem Parameter instance_name das Tracing auf eine Instanz beschränken. Per Default wird SQL-Trace auf allen Instanzen aktiviert. dbms_monitor.serv_mod_act_trace_enable(service_name module_name action_name instance_name
=> => => =>
'myservice', 'mymodule', 'myaction', NULL)
Auch wenn es in den meisten Fällen nicht sinnvoll ist, kann man seit 10g R2 SQL-Trace für alle Datenbanksessions aktivieren (außer die Sessions, die zu den Hintergrundprozessen gehören). Dies erfolgt mit folgendem PL/SQL-Aufruf, wobei zu beachten ist, dass der
424
8.4 Identifikation von Performance-Problemen Parameter instance_name auf für alle Instanzen aktiviert.
NULL
gesetzt (was dem Defaultwert entspricht) SQL-Trace
Die View dba_enabled_traces zeigt, auf welcher Ebene SQL-Trace aktiviert worden ist. Praxistipp Der Parameter timed_statistics bestimmt, ob Zeitinformationen wie „elapsed time“ und „CPU time“ in die Trace-Dateien geschrieben werden. Wenn der Wert auf „TRUE“ steht, erscheinen Zeitinformationen in der Trace-Datei. Bei „FALSE“ nicht. Abhängig von der Plattform ist es aber durchaus möglich, dass die Zeitinformationen trotzdem teilweise vorhanden sind. Der Defaultwert von timed_statistics ist abhängig vom Parameter statistics_level. Wenn dieser auf „basic“ gesetzt ist, ist der Defaultwert von timed_statistics=FALSE. Ansonsten ist der Defaultwert „TRUE“. Tracefiles ohne Zeitinformationen sind unbrauchbar. Es muss daher sichergestellt sein, dass der Parameter auf „TRUE“ steht, bevor SQL-Trace eingeschaltet wird.
Die zweite Operation besteht darin, das Problem zu reproduzieren. Weil dieser Schritt von der Problemstellung abhängig ist, können wir dazu lediglich allgemeine Hinweise geben. Ein spezifisches Problem zu reproduzieren, bedeutet im Allgemeinen, die geschäftsrelevanten Operationen zu analysieren wie Kundendaten ändern, eine Bestellung ausführen oder einen Report erstellen. Wir empfehlen, wenn möglich die Laufzeit der problematischen Operation einfach mit der Stoppuhr zu messen. In einem späteren Schritt vergleichen wir die so ermittelte Laufzeit mit den Informationen aus den SQL-Trace-Dateien. Die Zeiten sollten natürlich möglichst genau übereinstimmen. Im dritten Schritt schalten wir das SQL-Trace wieder aus. Dazu verwenden wir das dbms_monitor-Package, das für jede Aktivierungsprozedur eine entsprechende Deaktivierungsprozedur beinhaltet. So aktiviert beispielsweise die Prozedur session_trace_ enable das Tracing und die Prozedur session_trace_disable schaltet das Tracing aus. Praxistipp Normalerweise ist man an einer Beschränkung der Tracefile-Größe nicht interessiert. Sollte eine Limitierung trotzdem notwendig sein, kann dies auf Session- oder Systemebene mit dem Parameter max_dump_file_size erfolgen. Die Größe spezifiziert man mit einem numerischen Wert gefolgt von einem K für Kilobyte oder M für Megabyte. Ist keine Limitierung gewünscht, kann man den Parameterwert auf „unlimited“ setzen.
Wenn SQL-Trace ausgeschaltet ist, muss man den Namen und die Lokation der Tracedatei ermitteln. Weil Tracefiles von Prozessen auf dem Datenbankserver generiert werden, stehen sie auf einem Filesystem, auf das der Datenbankserver schreiben kann. Bis einschließlich 10g schreibt Oracle die Tracefiles in zwei unterschiedliche Verzeichnisse (abhängig vom Prozess, der das Tracefile generiert):
Dedizierte Serverprozesse schreiben die Tracefiles in ein Verzeichnis, das über den Parameter user_dump_dest definiert ist.
Hintergrundprozesse schreiben die Tracefiles in ein Verzeichnis, das über den Parameter background_dump_dest konfiguriert ist.
425
8 Optimierung Seit der Einführung des Automatic Diagnostic Repository (ADR) mit 11g ist die Verwendung der Parameter user_dump_dest und background_dump_dest nicht mehr empfohlen. Man sollte an deren Stelle den Parameter diagnostic_dest verwenden. Der neue Parameter definiert lediglich das Basisverzeichnis für das ADR. Wie in der folgenden Abfrage gezeigt wird, kann man über die View v$diag_info die genaue Lokation der Tracefiles ermitteln: SELECT value FROM v$diag_info WHERE name = 'Diag Trace';
Der Name des Tracefiles ist versions- und plattformunabhängig. Auf den meisten Plattformen hat der Tracefile-Name folgenden Aufbau: {instance name}_{process name}_{process id}.trc
Um das Tracefile eines dedizierten Serverprozesses leichter zu finden, steht der Parameter tracefile_identifier zur Verfügung. Damit kann man den Tracefile-Namen mit einem frei wählbaren Identifier mit einer Länge von bis zu 255 Zeichen ergänzen. Somit sieht die Struktur des Tracefile-Namens folgendermaßen aus: {instance name}_{process name}_{process id}_{tracefile identifier}.trc
Wurde das richtige Tracefile identifiziert, ist es nun an der Zeit, dessen Inhalt zu analysieren. Dazu stellt Oracle sowohl mit den Server-, wie auch mit den Client-Binaries das Tool TKPROF zur Verfügung. Dessen Hauptzweck besteht darin, aus einem Tracefile formatierten Text zu generieren. Es verfügt über diverse Parameter, wobei wir für die Analyse von Performanceproblemen nur die folgenden Parameter empfehlen: tkprof {input trace file} {output file} sys=no sort=prsela,exeela,fchela
Wir bezwecken damit zwei Ziele: Erstens wird verhindert, dass rekursive Abfragen des User SYS in das Output-File geschrieben werden. Zweitens sind damit die SQL-Statements nach Antwortzeit absteigend geordnet. Dadurch kann man die Top-Verbraucher einfach identifizieren. Sobald das durch TKPROF generierte Output-File vorliegt, beginnt die eigentliche Analyse. Dazu ist ein gutes Verständnis des Inhalts des Outputfiles notwendig. Im folgenden Beispiel beleuchten wir Schritt für Schritt die einzelnen Abschnitte. Das Output-File beginnt mit Informationen über die Version von TKPROF, mit der das File generiert wurde, den Namen des Input-Tracefiles, die verwendeten Sortieroptionen sowie etwas statischen Text: TKPROF: Release 11.2.0.1.0 - Development on Mon Feb 28 05:29:47 2011 Copyright (c) 1982, 2009, Oracle and/or its affiliates.
All rights reserved.
Trace file: ora11g_ora_7603.trc Sort options: prsela exeela fchela ************************************************************************ count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call ************************************************************************
426
8.4 Identifikation von Performance-Problemen Im zentralen Teil des Output-Files stehen detaillierte Informationen über die ausgeführten SQL-Anweisungen. Für jede SQL-Anweisung sind der Text des SQL-Statements, die Ausführungsstatistiken, Informationen über das Parsen, der Ausführungsplan und die WaitEvents ausgewiesen. Als erste Information ist der Text des SQL-Statements (seit 11g inklusiv der ID und der Hash-Wert des Ausführungsplans) aufgeführt. Die Bindvariablen, im folgenden Beispiel :B1 und :B2, sind mit einem vorangestellten Doppelpunkt markiert. SQL ID: 8dq0v1mjngj7t Plan Hash: 900611645 SELECT CUSTOMER_ID, CUST_FIRST_NAME, CUST_LAST_NAME, NLS_LANGUAGE, NLS_TERRITORY, CREDIT_LIMIT, CUST_EMAIL, ACCOUNT_MGR_ID FROM CUSTOMERS WHERE CUSTOMER_ID = :B2 AND ROWNUM < :B1
Die Ausführungsstatistiken stehen nach Datenbank-Call-Typ (Parse, Execute und Fetch) zusammengefasst in einer Tabelle. Für jedem Typ sind folgende Performance-Werte ausgewiesen:
count: Die Anzahl Datenbank-Calls. cpu: Die gesamte CPU-Zeit in Sekunden, die für die Ausführung der Datenbank-Calls benötigt wurde.
elapsed: Die Gesamtzeit in Sekunden, die für die Ausführung der Datenbank-Calls benötigt wurde. Wenn dieser Wert höher ist als die CPU-Zeit, sollten im nachfolgenden Abschnitt über die Wait-Events Hinweise vorhanden sein, um die Differenz zu verstehen.
disk: Die Anzahl Blöcke, die per physischem Zugriff gelesen wurden (nicht zu verwechseln mit der Anzahl physischer I/O-Operationen).
query: Die Anzahl Blöcke, die via logischem Zugriff im Consistent-Mode aus dem Buffer-Cache gelesen wurden. Normalerweise verwenden SQL-Abfragen (Queries) diesen Typ des logischen Lesezugriffs (daher auch die Bezeichnung).
current: Die Anzahl Blöcke, die via logischem Zugriff im Current-Mode aus dem Buffer-Cache gelesen wurden. Normalerweise verwenden DML-Operationen diesen Typ des logischen Lesezugriffs (solche Operationen benötigen den „current“-Block, daher die Bezeichnung).
rows: Die Zahl der verarbeiteten Datensätze. Für Abfragen ist dies die Anzahl zurückgegebener (fetched) Rows. Für andere DML-Statements ist es die Anzahl der geänderten Rows. call count ------- -----Parse 1 Execute 109 Fetch 109 ------- -----total 219
In den folgenden Zeilen sind die wesentlichen Informationen über das Parsing zusammengefasst. Direkt von einer Applikation ausgeführte SQL-Anweisungen haben eine Tiefe (recursive depth) von 0. Eine Tiefe von n (in diesem Fall 1) bedeutet, dass ein anderes
427
8 Optimierung SQL-Statement mit der Tiefe n-1 (in diesem Fall 0) rekursiv gegenüber einem anderen Statement ausgeführt wurde. Misses in library cache during parse: 1 Misses in library cache during execute: 1 Optimizer mode: ALL_ROWS Parsing user id: 96 (recursive depth: 1)
Nach dem allgemeinen Abschnitt über das Parsing stellt der TKPROF-Report den Ausführungsplan dar. In Abschnitt 8.5 beschreiben wir ausführlich, wie man diesen liest und interpretiert. Nachfolgend zunächst die Einzelheiten des TKPROF-Outputs. Die Anzeige des Ausführungsplans ist abhängig von der Datenbankversion. Bis einschließlich 10g wird der Ausführungsplan nur dann in das Tracefile geschrieben, wenn der Cursor geschlossen wird, während das Tracing noch aktiv ist. Ab 11g erscheint der Ausführungsplan unmittelbar nach der ersten Ausführung im Tracefile. Für jede einzelne Row-Source-Operation des Ausführungsplans werden die folgenden Runtime-Statistiken ausgewiesen (es handelt sich dabei mit Ausnahme von „card“ um kumulative Werte, das heißt, sie beinhalten auch die Werte der Child-Row-Source-Operationen):
cr: Anzahl Blöcke, die via logischen Zugriff im Consistent-Mode gelesen wurden pr: Anzahl Blöcke, die via physischen Zugriff von der Disk gelesen wurden pw: Anzahl Blöcke, die physisch auf die Disk geschrieben wurden time: Gesamtzeit in Mikrosekunden, die für die Verarbeitung der Operation benötigt wurde. Die ermittelten Statistikwerte sind nicht in jedem Fall sehr genau, weil für die Ermittlung der Laufzeiten eine Samplingmethode verwendet wird, um den Overhead zu reduzieren.
cost: Die geschätzten Kosten für die Operation (verfügbar ab 11g) size: Die geschätzte, von der Operation zurückgegebene Datenmenge in Bytes (verfügbar ab 11g)
card: Die geschätzte, von der Operation zurückgegebene Anzahl Datensätze (verfügbar ab 11g) Rows ------1 1 1
Row Source Operation --------------------------------------------------COUNT STOPKEY (cr=4 pr=0 pw=0 time=0 us) TABLE ACCESS BY INDEX ROWID CUSTOMERS (cr=4 pr=0 pw=0 time=0 us cost=3 size=64 card=1) INDEX UNIQUE SCAN CUSTOMERS_PK (cr=3 pr=0 pw=0 time=0 us cost=2 size=0 card=1) (object id 77818)
Bis Version 11.2.0.1 wird für das Reporting der Anzahl Rows eine einzige Spalte (Rows) verwendet. Ab Version 11.2.0.2 sind drei Spalten (Rows (1st), Rows (avg) und Rows (max)) vorhanden. Die Idee dahinter ist auszuweisen, ob mehrere Ausführungen die gleiche Datenmenge zurückgegeben haben. Zu diesem Zweck wird die Anzahl zurückgegebener Rows der ersten Ausführung sowie der Durchschnitt und die maximale Anzahl zurückgegebener Rows aller Ausführungen angezeigt. Die Runtime-Statistiken für die einzelnen Row-Source-Operationen werden seit Version 11.2.0.2 ebenfalls unterschiedlich angezeigt. Bis 11.2.0.1 sind die Werte aus der ersten Ausführung in das Tracefile geschrieben; ab Version 11.2.0.2 ist es der Durchschnitt basierend auf allen Ausführungen.
428
8.4 Identifikation von Performance-Problemen Der nächste Abschnitt des TKPROF-Reports fasst die Wait-Events zusammen, auf die das SQL-Statement warten musste. Für jeden Wait-Event-Typ sind die folgenden Werte ausgewiesen:
Times Waited: Zeigt an, wie häufig ein Wait-Event aufgetreten ist Max. Wait: Die maximale Wait-Time in Sekunden für einen einzelnen Wait-Event Total Waited: Die gesamte Wartezeit in Sekunden für einen Wait-Event. Idealerweise sollte die Summe der Wartezeiten aller Wait-Events gleich sein wie die Differenz zwischen der Gesamtlaufzeit (Elapsed Time) und der CPU-Zeit. Elapsed times include waiting on following events: Event waited on --------------------------------Disk file operations I/O db file sequential read
Times Waited 1 171
Max. Wait ---------0.00 0.02
Total Waited -----------0.00 0.71
Weil es sich bei diesen Statistiken um stark aggregierte Werte handelt, zeigen sie lediglich auf, auf welchen Ressourcen-Typ man wie lange warten musste. Entscheidend bei der Analyse von Wait-Events ist zu wissen, zu welchem Operationstyp sie gehören. Auch wenn es Hunderte von Wait-Event-Typen gibt, treten normalerweise nur ein paar wenige Typen immer wieder auf. Im Anhang der „Oracle Database Reference“ sind die meisten Typen kurz beschrieben. Nach den SQL-Statements steht im TKPROF-Report eine Zusammenfassung der Ausführungsstatistiken sowie der Parsing- und Wait-Events. Der einzige Punkt auf den wir in diesem Teil hinweisen möchten ist, dass nicht-rekursive SQL-Anweisungen (recursive depth = 0) von den rekursiven SQL-Anweisungen (recursive depth größer als 0) getrennt dargestellt sind. OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count ------- -----Parse 129 Execute 129 Fetch 0 ------- -----total 258
Misses in library cache during parse: 1 Elapsed times include waiting on following events: Event waited on --------------------------------SQL*Net message to client SQL*Net message from client db file sequential read library cache: mutex X PL/SQL lock timer log file sync
Times Waited 132 132 58 1 723 46
Max. Wait ---------0.00 10.39 0.02 0.00 0.20 0.31
Total Waited -----------0.00 30.08 0.23 0.00 108.62 0.40
Misses in library cache during parse: 6 Misses in library cache during execute: 5 Elapsed times include waiting on following events: Event waited on --------------------------------Disk file operations I/O db file sequential read cursor: pin S wait on X library cache: mutex X library cache load lock read by other session db file scattered read latch free latch: cache buffers chains buffer busy waits
Der TKPROF-Report wird abgeschlossen mit einer Übersicht über das Tracefile. Ab 10g sieht man am Ende des Reports die Summe der Laufzeiten aller SQL-Statements. Wir würden diese Information jedoch lieber am Anfang und nicht am Ende des Reports sehen, weil wir für die Analyse eines TKPROF-Reports generell empfehlen, zuerst einen Blick auf diese letzte Zeile zu werfen. Es ist entscheidend zu wissen, wie viel Zeit für das gesamte Tracefile verwendet wurde; ohne diese Information kann man die anteilmäßige Auswirkung eines bestimmten SQL-Statements auf die Gesamtantwortzeit nicht beurteilen. Trace file: ora11g_ora_7603.trc Trace file compatibility: 11.1.0.7 Sort options: prsela exeela fchela 1 session in tracefile. 1250 user SQL statements in trace file. 23 internal SQL statements in trace file. 1273 SQL statements in trace file. 48 unique SQL statements in trace file. 14191 lines in trace file. 143 elapsed seconds in trace file.
8.4.2
Echtzeitanalyse von nichtreproduzierbaren Problemen
Wenn es nicht möglich ist, das Problem zu reproduzieren oder zum Zeitpunkt des Auftretens zu untersuchen, ist die oben beschriebene Methode (SQL-Trace) in den meisten Fällen nutzlos. Dann empfehlen sich für eine Analyse die Informationen aus den dynamischen Performance-Views. Weil jedoch sehr viele solcher Views vorhanden sind, ist es für die gezielte Problemanalyse absolut entscheidend herauszufinden, welche Views und in welcher Reihefolge man diese verwenden kann. Dazu sind zwei Fragen wichtig:
Darf ich die Features der „Oracle Diagnostics Pack“-Option nutzen? Zielt die Analyse auf eine einzelne Session oder auf das Gesamtsystem? Bestimmte Datenbankfunktionen (das Schlüsselfeature für die Echtzeitanalyse heißt „Active Session History“) darf man nur verwenden, wenn die „Oracle Diagnostics Pack“-Option
430
8.4 Identifikation von Performance-Problemen lizenziert ist. Weil diese Option für die Standard Edition nicht verfügbar ist, ist die Enterprise Edition ebenfalls Voraussetzung. Details zur Lizenzierung stehen im „Oracle Database Licensing Information“-Guide. Die Beantwortung der zweiten Frage ist wichtig, um den Ausgangspunkt der Analyse zu bestimmen. Ist die vom Performance-Problem betroffene Session bereits bekannt, sollte man sich natürlich gleich darauf konzentrieren. Ansonsten muss man das Gesamtsystem betrachten. Auch wenn wir generell empfehlen, sich auf spezifische Probleme zu konzentrieren, ist es in der Praxis durchaus üblich, die Analyse auf Systemebene zu beginnen, wenn eine allgemeine Verlangsamung festgestellt wird und keine klare Ursache ersichtlich ist. 8.4.2.1
Analyse mit dem Diagnostics Pack
Für die Analyse mit dem Diagnostics Pack empfehlen wir, die Performance-Seiten des Enterprise Managers (Database Control oder Grid Control) zu verwenden. Wenn die Analyse nicht auf eine einzelne Session zielt, sollten Sie mit der „Top Activity“Seite beginnen. Die „Database Performance“-Seite ist dafür weniger geeignet, weil deren Drilldown-Möglichkeiten nur dann zu einer schnellen Identifikation des Problems führen, wenn eine einzelne Wait-Klasse den größten Teil der Antwortzeit verursacht. Das heißt, wenn man über den entsprechenden Link auf der „Database Performance“-Seite auf die „Top Activity“-Seite geht, sieht man auf einen Blick die Gesamtsystem-Belastung. Wir empfehlen aber nochmals, die Analyse direkt von der „Top Activity“-Seite aus zu starten. Die „Top Activity“-Seite zeigt entweder Echtzeitdaten oder historische Daten an. Weil wir uns in diesem Abschnitt mit der Analyse von Performance-Problemen befassen, die gerade aktuell sind, interessieren uns natürlich die Echtzeitdaten. Für diesen Fall sind die Daten der letzten Stunde relevant. Auf der „Top Activity“-Seite stehen drei Datensets zur Verfügung:
Die Activity-Grafik (siehe Abbildung 8.5) zeigt die Datenbankzeit aufgeschlüsselt nach CPU und Wait-Klassen. Die Grafik zeigt die Daten einer Stunde.
Die Top-SQL-Tabelle (siehe Abbildung 8.6) zeigt diejenigen SQL-Statements des ausgewählten Fünfminutenintervalls der Activity-Grafik, die am meisten Zeit verbraucht haben. Für jedes Statement wird die Gesamtaktivität und die SQL-ID ausgewiesen.
Die Top-Sessions-Tabelle (siehe Abbildung 8.7) zeigt diejenigen Sessions des ausgewählten Fünfminutenintervalls der Activity-Grafik, die am meisten Zeit verbraucht haben. Für jede Session erscheinen Informationen für deren Identifikation und Beschreibung sowie über ihre Gesamtaktivität. Die Activity-Grafik ist aus zwei Gründen ein guter Einstiegspunkt: Erstens erhält man einen Eindruck über die Belastung der Instanz über einen größeren Zeitraum und zweitens verwenden wir die Grafik für die Auswahl eines interessanten Fünfminuten-Intervalls, um damit mehr Details über die Datenbankbelastung zu erfahren. Wenn wir nicht etwas untersuchen, das zu einem bestimmten Zeitpunkt geschehen ist, wählen wir die Zeitperiode mit der größten Anzahl Sessions aus. Das heißt, wir wählen die Periode mit der höchsten Belastung.
431
8 Optimierung
Abbildung 8.5 Das Activity-Chart auf Systemebene zeigt, wie viel Zeit innerhalb der Datenbank verbraucht wurde
Nach Auswahl des gewünschten Fünfminuten-Intervalls betrachten wir die beiden Tabellen mit den Detail-Informationen. Wenn nur wenige SQL-Statements oder Sessions für einen großen Teil der Aktivität verantwortlich sind (beispielsweise wenn der Wert eine zweistellige Prozentzahl ist), dann ist das zu untersuchende SQL-Statement oder die Session klar identifiziert. Während beispielsweise in Abbildung 8.6 zehn Abfragen für mehr als 90 Prozent der Last verantwortlich sind, zeigt Abbildung 8.7, dass keine Session für mehr als 2 Prozent der Aktivität verantwortlich ist. Das heißt, nur Abbildung 8.6 erlaubt die klare Identifikation eines potenziellen Problems. Wenn jedoch kein SQL-Statement und keine Session besonders auffällt, wird die Aktivität offensichtlich durch viele SQL-Statements und/oder Sessions verursacht. Dies ist ein Hinweis, dass für eine Verbesserung der Performance größere applikatorische Änderungen notwendig sind. Wenn Sie einen solchen Fall entdecken, empfehlen wir, die Aktivitätsdaten aus einer anderen Perspektive zu betrachten, in dem Sie die Dropdown-Liste in der „Top Session“-Tabelle ändern. Damit kann man Detail-Informationen anzeigen, die auf anderen Dimensionen wie Top Services, Top Modules und Top Clients basieren. In manchen Fällen kann man damit jenen Teil der Applikation identifizieren, der die Last verursacht. Es ist jedoch anzumerken, dass diese Dimensionen nur dann interessante Informationen beinhalten, wenn die zu untersuchende Applikation entsprechend instrumentiert ist. Dazu sind Eigenschaften wie Module, Action und Client zu definieren. Abbildung 8.8 zeigt ein solches Beispiel. Ist die zu untersuchende Session noch aktiv, kann man auf die Session-Information über den „Search Sessions“-Link auf der „Database Performance“-Seite zugreifen. Ansonsten zeigt man die Session-Statistiken über den „Session ID“-Link auf der „Top Activity“-Seite („Top Session“-Tabelle) an.
432
8.4 Identifikation von Performance-Problemen
Abbildung 8.6 Die „Top SQL“-Tabelle zeigt die zeitintensivsten SQL-Statements auf Systemebene
Abbildung 8.7 Die „Top Session“Tabelle zeigt die zeitintensivsten Sessions
Abbildung 8.8 Die „Top Modules“Tabelle zeigt die zeitintensivsten Module
Es stehen zwei Datensets zur Verfügung:
Die Activity-Grafik (siehe Abbildung 8.9) zeigt die Datenbankzeit aufgeschlüsselt nach CPU und Wait-Events. Die Grafik enthält die Daten von einer Stunde.
Die „Top SQL“-Tabelle (siehe Abbildung 8.10) zeigt diejenigen SQL-Statements des ausgewählten Fünfminutenintervalls der Activity-Grafik, die am meisten Zeit verbraucht haben. Für jedes SQL-Statement werden die Gesamtaktivität, die SQL-ID, der Hash-Wert des Ausführungsplans sowie diverse Sessioneigenschaften ausgewiesen.
433
8 Optimierung
Abbildung 8.9 Die „Session Level Activity“Grafik zeigt, wie die Zeit einer Session verbraucht wurde
Abbildung 8.10 Die „Top SQL“-Tabelle zeigt die zeitintensivsten SQL-Statements auf Sessionebene
Wenn man ein SQL-Statement identifiziert hat, das für den Großteil der Aktivität verantwortlich ist, werden durch Klicken auf die SQL-ID in der „Top SQL“-Tabelle Detailinformation angezeigt. Von dort gelangt man auf die „SQL Detail“-Seite, die für das ausgewählte SQL-Statement zusätzlich zum Text weitere Informationen in Form von sogenannten „Tabs“ zur Verfügung stellt:
Statistics: Die Ausführungsstatistiken und weitere allgemeine Informationen zum SQLStatement. Die Ausführungsstatistiken sind kumulierte Werte, die seit dem initialen Load des Cursors im Shared Pool gesammelt wurden. Diese Daten kann man nur anzeigen, solange sie nicht aus dem Shared Pool verdrängt wurden.
Activity: Eine ähnliche Grafik wie in Abbildung 8.9, wobei nur die Informationen eines SQL-Statements angezeigt sind. Die Grafik zeigt die Daten einer Stunde.
Plan: Die mit den SQL-Statements verknüpften Ausführungspläne. Diese Informationen sind nur verfügbar, so lange sie nicht aus dem Shared-Pool verdrängt wurden. Wie man einen Ausführungsplan liest und wie man ihn beurteilt, erklären wir in Abschnitt 8.5.
434
8.4 Identifikation von Performance-Problemen
Plan Control: Die zum SQL-Statement gehörenden Stored Outlines, SQL Profiles oder SQL Plan Baselines.
Tuning History: Die vom SQL Tuning Advisor oder vom ADDM generierten Informationen.
SQL Monitoring: Die gerade in Ausführung befindlichen SQL-Statements (ab 11g verfügbar). 8.4.2.2
Analyse ohne Diagnostics Pack
Das Vorgehen bei der Analyse von Performance-Problemen ohne Verwendung der „Diagnostics Pack“-Option ist grundsätzlich wie im vorangehenden Abschnitt beschrieben:
Überprüfung der systemweiten Performance-Statistiken Identifizierung der Top-Sessions (oder Komponenten) Identifizierung der Top-SQL-Statements Anzeige der Detail-Informationen der Top-SQL-Statements Wie bereits beschrieben, muss man die beiden ersten Schritte nur ausführen, wenn die zu untersuchenden Sessions nicht bekannt sind. Es muss nicht besonders erwähnt werden, dass das Ziel dieser Art von Analyse die Nutzung von dynamischen Performance-Views ist, auf die man ohne „Diagnostics Pack“Lizenz zugreifen darf. Die Herausforderung bei der Auswertung besteht darin, dass die meisten dieser Views nur kumulative Statistiken beinhalten, die unregelmäßig aktualisiert werden. Einzige Ausnahme sind die dynamischen Performance-Views, die Metriken aus der AWR-Infrastruktur zur Verfügung stellen. Weil diese Views jedoch primär auf Metriken, Proportionen und Counters ausgerichtet sind, sind sie für die Untersuchung von Performance-Problemen nur bedingt geeignet. Die Analyse muss daher auf kumulativen Statistiken basieren. Für die effiziente Analyse von Performance-Problemen mit dynamischen PerformanceViews, die kumulative Statistiken beinhalten, sind Werkzeuge für das Sampling der Daten erforderlich. Solche Werkzeuge können einfache Skripts oder komplexe Applikationen wie der Enterprise Manager sein. Obwohl diverse Tools von Drittherstellern existieren, die einen ähnlichen Funktionsumfang wie der Enterprise Manager aufweisen, stellen wir in diesem Abschnitt Skripts vor, die frei verfügbar sind und deshalb auf jedem System einsetzbar sind. Da die meisten dieser Skripte auf kumulative Statistiken zugreifen, besteht das Ziel darin, die Veränderung einer bestimmten Statistik in einem kurzen Zeitraum herauszufinden. Für diesen Zweck selektiert man periodisch Werte aus einer dynamischen Performance-View und berechnet die Differenz zwischen den einzelnen Statistikwerten. Wenn man, wie bereits erwähnt, nicht bereits eine einzelne Session im Fokus hat. sollte man sich auf die systemweiten Statistiken konzentrieren. Für diesen Zweck sind die kumulierten Statistiken aus der View v$system_wait_class ein guter Einstiegspunkt. Damit lassen sich systemweite Informationen ähnlich wie in Abbildung 8.5 darstellen. Das sind die durchschnittliche Anzahl aktiven Sessions und die benötigte Zeit für jede Wait-Klasse.
435
8 Optimierung Wir empfehlen für die Analyse dieser Statistik die Verwendung eines Skripts wie system_activity.sql. Wie das folgende Beispiel zeigt3, benötigt das Skript zwei Parameter:
Interval: Legt fest, wie lange (in Sekunden) zwischen den Messungen für die Berechnung der Differenz gewartet werden soll. Da die Datenbank-Engine die Statistiken nicht in Echtzeit aktualisiert, macht ein Intervall, das kürzer als 10 bis 15 Sekunden ist, normalerweise wenig Sinn.
Die View v$sys_time_model zeigt einen weiteren interessanten Aspekt über die systemweite Systemlast: die von Schlüsseloperationen wie SQL-Statements oder PL/SQL-Code benötigte Laufzeit. Dies ist vor allem dann interessant, wenn das System viel CPU-Zeit verbraucht. Weil auch diese View kumulierte Statistikwerte beinhaltet, empfehlen wir für die Analyse ein Skript wie time_model.sql. Dessen Output zeigt für einen gegebenen Zeitbereich die Differenzen für alle Time-Modell-Statistiken an. Das Skript benötigt zwei Parameter:
Interval: Legt fest wie lange (in Sekunden) für die Berechnung der Deltawerte gewartet werden soll. Da die Datenbank-Engine die Statistiken nicht in Echtzeit aktualisiert, macht ein Intervall, das kürzer als 10 bis 15 Sekunden ist, normalerweise wenig Sinn.
Count: Definiert die Anzahl Samples SQL> @time_model.sql 15 1 Time Statistic AvgActSess Activity% -------- ------------------------------- ---------- --------06:38:20 DB time 7.0 97.5 .DB CPU 0.4 5.0 .sql execute elapsed time 6.9 96.0 .parse time elapsed 0.0 0.3
3
436
Aus Gründen der Übersichtlichkeit wurde der Output des Skripts angepasst und nicht relevante Spalten entfernt
8.4 Identifikation von Performance-Problemen ..hard parse elapsed time ...hard parse (sharing criteria .PL/SQL execution elapsed time background elapsed time .background cpu time
0.0 0.0 0.1 0.2 0.1
0.2 0.2 2.0 2.5 0.8
Für die korrekte Interpretation der Ergebnisse des time_model.sql-Skripts ist das Verständnis der View v$sys_time_model entscheidend. Folgende Punkte sind zu beachten:
Die Time-Model-Statistiken haben eine Baumstruktur. Deren Verzweigungen stellen eine Beziehung zwischen den einzelnen Statistiken dar. Beispielsweise ist „parse time elapsed” das Child-Element von „DB time” und dieses ist wiederum das Parent-Element von „hard parse elapsed time”.
Die Zeit eines Child-Elements ist ein Teil der Zeit des entsprechenden Parent-Elements. Achtung: Dies heißt jedoch nicht, dass die Summe der Zeiten der Child-Elemente gleich der Zeit des Parent-Elements ist. Die Zeit von bestimmten Operationen wird nicht exklusiv mit einem einzigen Child-Element verknüpft und gewisse Operationen werden zu gar keinem Child-Element hinzugerechnet.
Es gibt zwei Bäume: Der erste Baum mit „DB time” als Ursprung zeigt, wie lange die Datenbank-Engine für die Ausführung von User-Level-Calls benötigte. Der zweite Baum mit der „background elapsed time” als Ursprung zeigt, wie lange die DatenbankEngine für die Hintergrundoperationen benötigte.
Die Summe von „DB time” und „background elapsed time” ist die Gesamtprozesszeit, welche die Datenbank-Engine benötigte. Sie beinhaltet die CPU-Zeit sowie die Summe aller Wait-Events mit Ausnahme der Idle-Events4. Wenn bekannt ist, wie stark das System beschäftigt ist, kann man mit der Untersuchung der Sessions (oder Komponenten) weiterfahren. Dazu empfehlen wir die kumulierten Statistiken aus der View v$sess_time_model zu sampeln. Diese View stellt im Wesentlichen die gleiche Information wie v$sys_time_model zur Verfügung, jedoch detailliert auf Sessionebene. Um die Analyse zu vereinfachen, empfehlen wir auch in diesem Fall die Verwendung eines Skripts ähnlich wie active_sessions.sql. Dieses Skript zeigt für einen gegebenen Zeitbereich den Anteil der DB-Zeit, für welchen die Top-Sessions verantwortlich sind. Wie das folgende Beispiel zeigt, benötigt das Skript drei Parameter:
Interval: Legt fest wie lange (in Sekunden) für die Berechnung der Deltawerte gewartet werden soll. Da die Datenbank-Engine die Statistiken nicht in Echtzeit aktualisiert, macht ein Intervall, das kürzer als 10 bis 15 Sekunden ist, normalerweise wenig Sinn.
Count: Definiert die Anzahl Samples Top: Definiert, wie viele Sessions angezeigt werden sollen. Normalerweise ist es wenig sinnvoll, mehr als 10 bis 20 Sessions anzuzeigen.
4
Die folgende Abfrage zeigt, welche Events nicht aktiv (idle) sind: SELECT name FROM v$event_name WHERE wait_class = 'Idle'
User Program Activity% ---- ---------------- --------LGWR 1.6 SOE JDBC Thin Client 1.2 SOE JDBC Thin Client 1.2 SOE JDBC Thin Client 1.2 SOE JDBC Thin Client 1.1 SOE JDBC Thin Client 1.1 SOE JDBC Thin Client 1.1 SOE JDBC Thin Client 1.1 SOE JDBC Thin Client 1.1 SOE JDBC Thin Client 1.1 11.9
Der Output zeigt auch für jedes Intervall die Anzahl offener Sessions und die Logins. Diese Information ist wichtig, weil das Skript die Arbeit jener Sessions nicht erfasst, die während des Sample-Intervalls enden. Man sollte deshalb vorsichtig sein, wenn eine abnehmende Anzahl Sessions oder eine große Anzahl Logins auftaucht, ohne dass sich die Zahl der Sessions entsprechend proportional erhöht. Wenn nur wenige Sessions für einen großen Teil der Aktivität verantwortlich sind (beispielsweise wenn der Wert eine zweistellige Prozentzahl ist), hat man die näher zu untersuchenden Sessions klar identifiziert. Wenn jedoch, wie im obigen Beispiel, keine Session besonders auffällt, wird die Aktivität offensichtlich durch viele Sessions verursacht. Wie bereits im vorherigen Abschnitt erwähnt, ist es notwendig, die Performance-Statistiken nach einer anderen Dimension als die Session-ID zu aggregieren. Für diese Aufgabe empfehlen wir die Verwendung eines Skripts namens „Snapper“ (snapper.sql), das von Tanel Poder5 entwickelt wurde. Seine Hauptaufgabe besteht darin, die View v$session in einer Frequenz zu sampeln, die umgekehrt proportional zur Sampling-Periode6 ist. Während des Samplings überprüft Snapper den Status der Sessions und erfasst Informationen über die aktiven Sessions (beispielsweise welche SQL-Statements ausgeführt werden). Weil Snapper ein sehr flexibles und mächtiges Skript ist, das viele Parameter akzeptiert, beschränken wir uns auf ein paar Beispiele. Das erste zeigt, wie man mit Snapper Informationen sammelt, ähnlich denen in Abbildung 8.6. Zu diesem Zweck verwenden wir die folgenden vier Parameter:
Der erste (ash=sql_id) legt fest, dass die Daten nach der SQL-ID aggregiert werden Der zweite (15) definiert eine Sampling-Periode von 15 Sekunden Der dritte (1) bestimmt, dass eine einzige Sampling-Periode evaluiert werden soll Der vierte (all) spezifiziert, dass alle Sessions untersucht werden sollen
5
Das Skript und die dazugehörige Dokumentation ist unter http://tech.e2sn.com/oracle-scripts-and-tools/ session-snapper verfügbar 6 Zum Zeitpunkt, an dem diese Kapitel geschrieben wurde, lag die Frequenz zwischen 100 Hz (für eine Samplingperiode von 10 Sekunden und weniger) bis 1 Hz (für eine Samplingperiode von 100 Sekunden oder mehr)
Wie das Beispiel zeigt, kann die Spalte Active% größer als 100 Prozent sein, wenn das Sampling über mehrere Sessions erfolgt. Im Beispiel bedeutet dies, dass im Durchschnitt 1,27 Sessions das Top-SQL-Statement mit der SQL-ID 8dq0v1mjngj7t ausgeführt haben. Das nachfolgende Beispiel zeigt, wie man ähnliche Informationen wie in Abbildung 8.8 sammeln kann. Zu diesem Zweck werden vier Parameter spezifiziert. Der einzige Unterschied zum vorangehenden Beispiel besteht im ersten Parameter: diesmal wird ash=module verwendet, um die Daten nach dem Modul-Name zu aggregieren. SQL> @snapper.sql ash=module 15 1 all ----------------------------------Active% | MODULE ----------------------------------411% | New Order 122% | Process Orders 71% | Browse Products 60% | New Customer 45% | 30% | Browse and Update Orders 1% | Realtime Connection 1% | OEM.SystemPool
Wie das folgenden Beispiel zeigt, kann man die Daten gleichzeitig auch nach mehreren Dimensionen aggregieren; in diesem Fall nach SQL-ID und Modul-Name: SQL> @snapper.sql ash=sql_id+module 15 1 all ----------------------------------------------------Active% | SQL_ID | MODULE ----------------------------------------------------109% | c13sma6rkr27c | New Order 101% | 7hk2m2702ua0g | Process Orders 95% | bymb3ujkr3ubk | New Order 74% | 0yas01u2p9ch4 | New Order 63% | 8dq0v1mjngj7t | Browse Products 55% | 0bzhqhhj9mpaa | New Customer 52% | 8dq0v1mjngj7t | New Order 23% | f9u2k84v884y7 | Process Orders 23% | 8z3542ffmp562 | New Order 20% | |
Im vorangehenden Beispiel haben wir gezeigt, wie man die Aktivität des Gesamtsystems (beispielsweise die Aktivitäten aller Sessions) untersuchen kann. Snapper ist natürlich auch in der Lage, eine spezifische Session genauer zu analysieren. Für diesen Zweck muss man mit dem vierten Parameter anstelle von all die Session-ID spezifizieren. Das folgende Beispiel zeigt, wie Informationen ähnlich wie in Abbildung 8.9 und Abbildung 8.10 angezeigt werden können:
439
8 Optimierung SQL> @snapper.sql ash=event 15 1 172 ----------------------------------Active% | EVENT ----------------------------------4% | db file sequential read 1% | ON CPU SQL> @snapper.sql ash=sql_id+module 15 1 172 ----------------------------------------------------Active% | SQL_ID | MODULE ----------------------------------------------------2% | 7hk2m2702ua0g | Process Orders 2% | 0bzhqhhj9mpaa | New Customer 2% | bymb3ujkr3ubk | New Order 1% | 8dq0v1mjngj7t | Browse Products
Wurde ein SQL-Statement identifiziert, das für einen großen Teil der Aktivität verantwortlich ist, lassen sich mit einer Abfrage auf die dynamische Performance-View v$sqlstats entsprechende Detail-Informationen anzeigen. Diese Aufgabe vereinfacht das Skript sqlstats.sql. Das folgende Beispiel (achten Sie auf die Parameterübergabe der SQL-ID des identifizierten SQL-Statements) illustriert das Vorgehen: SQL> @sqlstats.sql 0bzhqhhj9mpaa Text ---------------------------------------------------------------------INSERT INTO CUSTOMERS(CUSTOMER_ID ,CUST_FIRST_NAME ,CUST_LAST_NAME ,NLS_LANGUAGE,NLS_TERRITORY ,CREDIT_LIMIT ,CUST_EMAIL ,ACCOUNT_MGR_ID ) VALUES (:B9 , :B4 , :B3 , :B8 , :B7 , FLOOR(DBMS_RANDOM.VALUE(:B6 , :B5 )), :B4 ||'.'||:B3 ||'@'||'oracle.com', FLOOR(DBMS_RANDOM.VALUE(:B2 , :B1 ))) Activity By Time ---------------------------------------------------------------------Elapsed Time (seconds): 208.58 CPU Time (seconds): 38.83 Wait Time (seconds): 169.75 Elapsed Time Breakdown ---------------------------------------------------------------------SQL Time (seconds): 208.58 PL/SQL Time (seconds): 0 Java Time (seconds): 0 Activity By Waits ---------------------------------------------------------------------Application Waits (%): 0 Concurrency Waits (%): 0 Cluster Waits (%): 0 User I/O Waits (%): 80.13 Remaining Waits (%): 1.25 CPU (%): 18.62 Execution Statistics ---------------------------------------------------------------------Executions: 100 Buffer Gets: 172315 Disk Reads: 164787 Direct Writes: 0 Rows: 100 Fetches: 100
sqlstats.sql zeigt eine sehr wichtige Information nicht an, den Ausführungsplan. Wir
sehen in Abschnitt 8.5, wie man diesen sichtbar macht.
440
8.4 Identifikation von Performance-Problemen
8.4.3
Nachträgliche Analyse von nichtreproduzierbaren Problemen
In diesem Abschnitt beschreiben wir, wie man Performance-Probleme untersucht, die weder reproduzierbar sind, noch zum Zeitpunkt ihres Auftretens erfasst werden können. Dies heißt mit anderen Worten, wie man Probleme, die in der Vergangenheit aufgetreten sind, analysieren kann. Für diesen Zweck muss ein Repository mit historischen PerformanceStatistiken zur Verfügung stehen. Oracle stellt zwei entsprechende Repositories zur Verfügung:
Automatic Workload Repository (AWR) Statspack Weil AWR mächtiger als Statspack ist, empfehlen wir, generell AWR zu verwenden. Eine wichtige Voraussetzung muss jedoch erfüllt sein, die Lizenzierung der Oracle Diagnostics Pack-Option, und damit auch der Enterprise Edition. Abhängig davon, ob man eine einzelne Session oder das Gesamtsystem betrachtet, muss man einen weiteren Punkt beachten: Statspack erfasst keine Informationen auf Sessionebene. Das heißt, man muss für sessionspezifische Informationen AWR verwenden. 8.4.3.1
Analyse mit dem Automatic Workload Repository
Für die Analyse mit AWR empfehlen wir, die Performance-Seiten des Enterprise Manager (es ist an dieser Stelle nicht relevant, ob es sich dabei um Database Control oder Grid Control handelt) zu verwenden. Wie wir in Abschnitt 8.4.2.1 beschrieben haben, zeigt die „Top Activity“-Seite entweder Echtzeit-Information oder historische Daten an. Weil wir uns in diesem Abschnitt auf die Untersuchung von Performance-Problemen aus der Vergangenheit konzentrieren, sind wir an den historischen Daten interessiert. Per Default sind im AWR Daten der vergangenen Woche verfügbar. Wie lange zurück die Daten dort gehalten werden, kann man auf der „Automatic Workload Repository“-Seite anzeigen und ändern. Die Analyse der historischen Daten erfolgt grundsätzlich auf die gleiche Art und Weise wie bei den Echtzeitdaten. Wir verweisen deshalb für weitere Informationen auf Abschnitt 8.4.2.1. Die wichtigsten Unterschiede sind folgende:
Für die historischen Daten wird ein Dreißig-Minutenintervall (anstelle von fünf) verwendet, um eine Periode auszuwählen, über die man Details zur Datenbanklast anzeigen möchte.
Die Daten sind weniger detailliert oder gar nicht vorhanden, weil im AWR nicht alle Echtzeitdaten gespeichert sind. Trotzdem sollten genügend Informationen über die Top-Verbraucher vorliegen.
Man kann nicht nach einer spezifischen Session suchen. Das heißt, der „Search Sessions-Link“ auf der „Database Performance“-Seite existiert nicht. Session-Informationen lassen sich nur über die „Top Sessions“-Tabelle anzeigen. Im Gegensatz zum GUI verfügt das AWR über diverse Reports für die Untersuchung der Last über einen bestimmten Zeitraum. Die folgenden drei werden am meisten verwendet:
441
8 Optimierung
Der „AWR"-Report fasst die Operationen über einen bestimmten Zeitraum zusammen. Man kann ihn über den Enterprise Manager oder mit dem Skript awrrpt.sql (im Verzeichnis $ORACLE_HOME/rdbms/admin) erzeugen. Da dieser Report auf dem StatspackReport basiert, verweisen wir für dessen Interpretation auf den Abschnitt 8.4.3.2. Der „Compare Periods“-Report vergleicht die Operationen von zwei unterschiedlichen Perioden. Die ist beispielweise nützlich, um die Unterschiede zwischen einer Referenzperiode und einer Periode, in der Performance-Probleme aufgetreten sind, zu untersuchen. Auch dieser Report kann man mit dem Enterprise Manager oder aber mit dem Skript awrddrpt.sql erstellen. Der „SQL Statement“-Report liefert detaillierte Informationen über ein bestimmtes SQL-Statement. Weitere Informationen siehe Abschnitt 8.5.1.3. 8.4.3.2
Analyse mit dem Statspack
Statspack ist der Vorgänger von AWR. Beide Tools haben zum Ziel, Performance-Daten in einem Repository zu speichern, wobei sie sich in vier wesentlichen Punkten unterscheiden:
AWR ist vollständig integriert, das heißt, es wird beim Erstellen einer Datenbank automatisch installiert. Statspack ist manuell zu installieren. AWR speichert Daten auf System- und auf Session-Ebene; Statspack nur auf SystemEbene. AWR ist eine lizenzpflichtige Option (verfügbar ab 10g). Statspack bedingt keine Zusatzlizenz und ist seit 8i verfügbar. Für Statspack ist kein GUI verfügbar. Informationen zur Installation und Konfiguration von Statspack finden Sie in der Datei spdoc.txt, die zusammen mit den Installationsskripts im Verzeichnis $ORACLE_HOME/ rdbms/admin/ verfügbar ist. Leider beinhaltet die Oracle-Datenbank-Dokumentation nur wenige Informationen über Statspack. Praxistipp AWR ist eine Weiterentwicklung von Statspack. Deshalb können Sie die meisten Informationen in diesem Abschnitt, im Speziellen die Erläuterungen, wie man einen Statspack-Report interpretiert, auch auf AWR übertragen.
Die Untersuchung eines Performance-Problems mit Statspack beginnt mit der Ausführung des Skripts spreport.sql, das unter $ORACLE_HOME/rdbms/admin/ zu finden ist. Es verlangt die Zeitperiode, über die man den Report erstellen will, und schreibt den Report in eine Datei. Ein solcher Report umfasst typischerweise 2.500 bis 3.000 Zeilen. Wir beschränken uns hier auf die ersten beiden Seiten, die eine Übersicht und die wichtigsten Informationen beinhalten. Ein Statspack-Report beginnt mit einigen generischen Informationen über die Instanz und den Server:
442
8.4 Identifikation von Performance-Problemen Database DB Id Instance Inst Num Startup Time Release RAC ~~~~~~~~ ----------- --------- -------- --------------- ----------- --3085881766 DBA11201 1 06-Apr-11 07:10 11.2.0.1.0 NO Host Name Platform CPUs Cores Sockets Memory (G) ~~~~ -------- ---------------------- ----- ----- ------- -----------helicon Linux x86 64-bit 4 4 2 15.7
Es folgen Informationen über die Auswertungsperiode (Anfang, Ende und Dauer), die Anzahl Sessions zu Beginn und am Ende der Periode und – interessant aus Sicht der Performance – die durchschnittliche Zahl aktiver Sessions (7,5 im vorliegenden Beispiel). Dieser Wert berechnet sich aus der Division der DB-Time durch die Gesamtzeit (Elapsed Time): Snapshot Snap Id Snap Time Sessions Curs/Sess Comment ~~~~~~~~ -------- ------------------ -------- --------- -------------Begin Snap: 21 06-Apr-11 16:07:46 140 5.2 End Snap: 31 06-Apr-11 16:18:22 143 5.1 Elapsed: 10.60 (mins) Av Act Sess: 7.5 DB time: 79.94 (mins) DB CPU: 3.75 (mins)
Die durchschnittliche Zahl aktiver Sessions ist eine wichtige Metrik, die aussagt, wie stark die Instanz belastet ist. Als Richtwert gilt: Das System ist sozusagen im Leerlauf (idle), wenn diese Zahl viel kleiner als die Anzahl CPUs ist. Umgekehrt gilt: Wenn die Zahl größer als die Anzahl CPUs ist, ist das System ziemlich beschäftigt. Weil es sich dabei um einen Durchschnittswert handelt, können dahinter viele Informationen verborgen sein. Verwendet man lediglich diese Zahl für eine Beurteilung, muss man etwas vorsichtig sein. Dies gilt besonders dann, wenn die Beobachtungsperiode mehrere Stunden oder mehr beträgt. Anschließend folgt die Größe der wichtigsten SGA-Komponenten. Egal, ob der BufferCache oder der Shared-Pool während der Beobachtungsperiode verändert wurde, es wird der jeweilige Endwert angezeigt. Im folgenden Beispiel haben die Komponenten die gleiche Größe: Cache Sizes Begin End ~~~~~~~~~~~ ---------- ---------Buffer Cache: 124M Shared Pool: 216M
Std Block Size: Log Buffer:
8K 6,864K
Als Nächstes sehen wir die Prozesszeiten diverser Metriken pro Sekunde, pro Transaktion und für einige Metriken auch pro Ausführung und pro Call. Die meisten dieser Informationen kann man nicht direkt für die Beurteilung der System-Performance verwenden. Sie dienen hauptsächlich zwei Dingen: Zum einen vermitteln sie einen allgemeinen Eindruck über die Systembelastung. Im folgenden Beispiel sehen wir, dass 270 Transaktionen pro Sekunde ausgeführt wurden und dass jede Transaktion durchschnittlich 5,9 Ausführungen ausgelöst hat. Das heißt, das System steht unter einer bestimmten Last. Zum anderen – und das ist der wichtigste Aspekt – kann man durch den Vergleich mit Daten aus einer Referenzperiode feststellen, ob das System mehr oder weniger Arbeit als erwartet bewältigen muss. Load Profile Per Second ~~~~~~~~~~~~ ----------DB time(s): 7.5 DB CPU(s): 0.4 Redo size: 664,039.8 Logical reads: 17,244.3 Block changes: 3,880.9
Per Transaction Per Exec Per Call ---------------- ----------- ----------0.0 0.00 0.02 0.0 0.00 0.00 2,459.3 63.9 14.4
443
8 Optimierung Physical reads: Physical writes: User calls: Parses: Hard parses: W/A MB processed: Logons: Executes: Rollbacks: Transactions:
(7,5) und DB CPU per second (0,4) sind die einzigen beiden Kennzahlen aus dem obigen Teil, mit denen man ohne zusätzliche Informationen die Systemlast beurteilen kann. Den ersten Wert haben wir bereits besprochen: die durchschnittliche Anzahl aktiver Sessions. Den zweiten Wert kann man mit der Anzahl CPUs vergleichen, um festzustellen, ob das System CPU-lastig ist. Im vorliegenden Beispiel sind vier CPUs vorhanden; das heißt die Instanz verwendet lediglich 10 Prozent (0.4/4*100) der CPUKapazität des Servers. Der Report geht weiter mit einigen Verhältniszahlen, die nur eingeschränkt nützlich sind. Diese Kennwerte sind vor allem im Vergleich mit einer Referenzperiode interessant, um festzustellen, was sich geändert hat:
DB time per second
Instance Efficiency Indicators ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 100.00 Buffer Hit %: 91.76 Library Hit %: 99.74 Execute to Parse %: 74.88 Parse CPU to Parse Elapsd %: 46.82 Shared Pool Statistics Memory Usage %: % SQL with executions>1: % Memory for SQL w/exec>1:
Der nächste Teil zeigt ein Profil des Ressourcen-Verbrauchs der Top-5-Events (inkl. CPUAuslastung). Vereinfacht gesagt, wird in dieser Tabelle die DB-Zeit aufgeschlüsselt in die einzelnen Komponenten dargestellt. Im folgenden Beispiel geht der große Anteil der verbrauchten Zeit (92.3% = 88.6% + 2.7% + 1.0%) auf das Konto von I/O-Operationen: Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time ----------------------------- ------------ ----------- ------ -----db file sequential read 848,130 4,251 5 88.6 CPU time 213 4.4 db file parallel read 16,492 131 8 2.7 log file parallel write 157,396 46 0 1.0 log file sync 55,706 45 1 0.9
Der vorherige Abschnitt zeigt die Wait-Klassen (beispielsweise User-I/O, System-I/O, Commit oder Concurrency) leider nicht. Mit folgender Abfrage kann man die (unterdrückte) Wait-Klasse anzeigen, die zu einem Event gehört: SQL> SELECT wait_class 2 FROM v$event_name 3 WHERE name = 'db file parallel read'; WAIT_CLASS -------------------------------------------User I/O
444
8.4 Identifikation von Performance-Problemen Der Report setzt sich Betriebssysteminformationen über die CPU- und die Memory-Auslastung fort. Damit kann man feststellen, ob der CPU- und Memory-Verbrauch auf OSEbene primär von der Instanz verursacht wird oder eine andere Ursache hat. Dies ist eine wichtige Information, wenn auf dem Server mehrere Instanzen oder sogar andere Applikationen betrieben werden. Die wichtigste Kennzahl, die den anteilmäßigen CPU-Verbrauch ausweist, der durch die Instanz verursacht wurde, ist % of Busy CPU used for Instance. Ist dieser Wert kleiner als 80 bis 90 Prozent, dann beansprucht eine andere Applikation einen nicht zu vernachlässigenden Anteil der CPU-Ressourcen für sich. Im folgenden Ausschnitt sieht man beispielsweise, dass die Instanz den Großteil (92,7 Prozent) des CPUVerbrauchs konsumiert. Das heißt auch, auf diesem Server sind keine anderen Prozesse vorhanden, die substanziell CPU-Ressourcen verbrauchen. Host CPU ~~~~~~~~
(CPUs: 4 Cores: 4 Sockets: 2) Load Average Begin End User System Idle WIO WCPU ------- ------------- ------- ------- ------- -------6.41 7.97 9.06 1.53 88.85 44.86
Instance CPU ~~~~~~~~~~~~ Host: Total time (s): Host: Busy CPU time (s): % of time Host is Busy: Instance: Total CPU time (s): % of Busy CPU used for Instance: Instance: Total Database time (s): %DB time waiting for CPU (Resource Mgr): Memory Statistics ~~~~~~~~~~~~~~~~~ Host Mem (MB): SGA use (MB): PGA use (MB): % Host Mem used for SGA+PGA:
Begin End ------------ -----------16,030.3 16,030.3 637.1 637.1 631.9 649.4 7.9 8.0
Die letzte Information auf den ersten beiden Seiten gibt Auskunft über die Time-ModelStatistiken. Wie bereits in Abschnitt 8.4.2.2 vorgestellt, kann man damit die Ausführungszeit von bestimmten Schlüssel-Operationen angezeigen. Im folgenden Beispiel sieht man gut, dass die Ausführung von SQL-Anweisungen die meiste Zeit (98,6 Prozent) beansprucht hat: Statistic Time (s) % DB time ----------------------------------- -------------------- --------sql execute elapsed time 4,728.5 98.6 DB CPU 224.8 4.7 PL/SQL execution elapsed time 87.6 1.8 parse time elapsed 37.6 .8 hard parse elapsed time 32.6 .7 hard parse (sharing criteria) elaps 4.1 .1 PL/SQL compilation elapsed time 4.0 .1 connection management call elapsed 1.2 .0 hard parse (bind mismatch) elapsed 0.9 .0 repeated bind elapsed time 0.0 .0 sequence load elapsed time 0.0 .0 DB time 4,796.5 background elapsed time 120.2 background cpu time 32.7
445
8 Optimierung Basierend auf den Informationen der ersten beiden Seiten des Statspack-Reports sollte man ein gutes Verständnis über die Systembelastung gewinnen. Beispielsweise, wie stark das System belastet ist und welche Operationen hauptsächlich dafür verantwortlich sind. Im nächsten Schritt gilt es herauszufinden, welches die Top-SQL-Anweisungen sind. Dazu beinhaltet der Report diverse Listen, die nach unterschiedlichen Kriterien geordnet sind (beispielsweise CPU, Elapsed Time und Executions). Da die Elapsed Time in den meisten Fällen das wichtigste Kriterium ist, empfehlen wir bei der weiteren Untersuchung den Abschnitt SQL ordered by Elapsed time zu betrachten. Im folgenden Beispiel sehen wir, wie man nicht nur die Gesamtlaufzeit und die durchschnittliche Laufzeit für jedes SQLStatement anzeigen kann, sondern auch den CPU-Verbrauch und das physische I/O. Auch der Hash-Wert des SQL-Statements ist ausgewiesen. Diesen kann man, wie in Abschnitt 8.5.1.3 vorgestellt, zusammen mit dem Skript sprepsql.sql verwenden, um damit alle Informationen (beispielsweise den Ausführungsplan) eines SQL-Statements anzuzeigen: Elapsed Elap per CPU Old Time (s) Executions Exec (s) %Total Time (s) Physical Reads Hash Value -------- ---------- -------- ------ -------- -------------- ---------1944.88 23,501 0.08 40.5 73.35 395,113 3565022785 Module: JDBC Thin Client BEGIN :1 := orderentry.neworder(:2 ,:3 ,:4 ); END; 650.20 71,339 0.01 13.6 13.40 108,742 3107051069 Module: Browse and Update Orders SELECT CUSTOMER_ID, CUST_FIRST_NAME, CUST_LAST_NAME, NLS_LANGUAG E, NLS_TERRITORY, CREDIT_LIMIT, CUST_EMAIL, ACCOUNT_MGR_ID FROM CUSTOMERS WHERE CUSTOMER_ID = :B2 AND ROWNUM < :B1 548.65 70,662 0.01 11.4 16.11 140,291 2319948924 Module: New Order SELECT PRODUCTS.PRODUCT_ID, PRODUCT_NAME, PRODUCT_DESCRIPTION, C ATEGORY_ID, WEIGHT_CLASS, WARRANTY_PERIOD, SUPPLIER_ID, PRODUCT_ STATUS, LIST_PRICE, MIN_PRICE, CATALOG_URL, QUANTITY_ON_HAND FRO M PRODUCTS, INVENTORIES WHERE PRODUCTS.CATEGORY_ID = :B3 AND INV
Die restlichen Abschnitte des Reports können weitere nützliche Informationen über das spezifische Verhalten des Systems oder dessen Konfiguration enthalten. Ist das System beispielsweise I/O-bound, ist es interessant, für die Top-5-Events die Histogramme im Abschnitt Wait Event Histogram zu prüfen. Damit und mit dem Wissen der SpeicherSubsystem-Konfiguration sollte es möglich sein, zu beurteilen, ob das I/O-Verhalten erwartungsgemäß ist oder nicht. Im folgenden Fall stellen wir fest, dass die Schreiboperationen immer weniger als 1 Millisekunde benötigen, die Leseoperationen jedoch bis zu einer Größenordnung langsamer sind: Total ----------------- % of Waits -----------Event Waits SELECT * FROM table(dbms_xplan.display_cursor('1hqjydsjbvmwq',0)); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------SQL_ID 1hqjydsjbvmwq, child number 0 ------------------------------------SELECT SUM(AMOUNT_SOLD) FROM SALES S, PROMOTIONS P WHERE S.PROMO_ID = P.PROMO_ID AND PROMO_SUBCATEGORY = 'online discount' Plan hash value: 265338492 ------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes| Cost(%CPU)| Time | ------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 517 (100)| | | 1 | SORT AGGREGATE | | 1 | 30 | | | |* 2 | HASH JOIN | | 913K| 26M| 517 (4)| 00:00:07 |
Die Funktion display_cursor beschränkt sich nicht auf die beiden Parameter im obigen Beispiel. Für die Formatierung steht ein dritter Parameter zur Verfügung (siehe Beispiel in Abschnitt 8.5.3). Detaillierte Informationen finden Sie in der Oracle-Dokumentation „PL/SQL Packages and Types Reference 11g Release 2, Abschnitt DBMX_XPLAN“. 8.5.1.3
Automatic Workload Repository und Statspack
Automatic Workload Repository (AWR) und Statspack sind in der Lage, die Ausführungspläne zu sammeln. Um diese zu erhalten, führt man auf die im vorhergehenden Abschnitt beschriebenen dynamischen Performance-Views Abfragen aus. Sind die Ausführungspläne einmal vorhanden, kann man sie als Text-Report oder aus dem AWR mit dem Enterprise Manager anzeigen. Sowohl für das AWR als auch für Statspack entspricht die Repositorytabelle, in der die Ausführungspläne abgelegt sind, im Wesentlichen der im vorherigen Abschnitt beschriebenen View v$sql_plan. Man kann daher die gleichen Methoden wie oben beschrieben anwenden. Die View dba_hist_sql_plan zeigt die im AWR abgelegten Ausführungspläne. Für die Abfrage steht im Package dbms_xplan die Funktion display_awr zur Verfügung. Wie das folgende Beispiel zeigt, ist die Verwendung dieser Funktion sehr einfach. Als Parameter wird der Funktion die SQL-ID der zu analysierenden SQL-Anweisung übergeben: SQL> SELECT * FROM table(dbms_xplan.display_awr('1hqjydsjbvmwq')); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------SELECT SUM(AMOUNT_SOLD) FROM SALES S, PROMOTIONS P WHERE S.PROMO_ID = P.PROMO_ID AND PROMO_SUBCATEGORY = 'online discount' Plan hash value: 265338492 ------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes| Cost(%CPU)| Time | ------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 517 (100)| | | 1 | SORT AGGREGATE | | 1 | 30 | | | | 2 | HASH JOIN | | 913K| 26M| 517 (4)| 00:00:07 | | 3 | TABLE ACCESS FULL| PROMO | 23 | 483 | 17 (0)| 00:00:01 | | 4 | TABLE ACCESS FULL| SALES | 918K| 8075K| 494 (3)| 00:00:06 | -------------------------------------------------------------------------
Die Funktion display_awr besitzt zusätzliche Parameter wie beispielsweise Formatieranweisungen oder die Datenbank-ID. Eine detaillierte Beschreibung von DBMS_XPLAN steht im „PL/SQL Packages and Types Reference“-Guide. Wenn der Snapshot-Level größer oder gleich 6 definiert ist, speichert Statspack die Ausführungspläne in der Tabelle stats$sql_plan. Leider steht im Package dbms_xplan keine Möglichkeit für deren Abfrage zur Verfügung. Wir empfehlen daher, den Ausführungsplan in eine Plan-Tabelle zu kopieren und mit der Funktion display des Packages dbms_xplan anzuzeigen.
451
8 Optimierung Zusätzlich stellt Oracle mit den beiden Skripts awrsqrpt.sql für das AWR und sprepsql.sql für das Statspack nützliche Reports für die Anzeige von Änderungen der
Ausführungspläne und des Ressourcen-Verbrauchs für ein bestimmtes SQL-Statement zur Verfügung. Die Skripts stehen im Verzeichnis $ORACLE_HOME/rdbms/admin. Das Skript für das AWR ist erst ab 10g R2 verfügbar.
8.5.2
Interpretation von Ausführungsplänen
Den Ausführungsplan kann man als Baumstruktur betrachten, die nicht nur die Reihenfolge der Operationen beschreibt, sondern auch die Beziehungen zwischen den einzelnen Operationen. Jeder Knoten in der Baumstruktur stellt eine Operation dar, beispielsweise ein Tabellenzugriff, eine Verknüpfung oder eine Sortieroperation. Zwischen den Operationen besteht eine Eltern-Kind-Beziehung. Das Verständnis dieser Beziehungen ist für die Interpretation eines Ausführungsplans zwingend notwendig. Für die Eltern-Kind-Beziehung kann man folgende Regeln formulieren:
Eltern-Elemente haben ein oder mehrere Kinder. Ein Kind-Element hat genau einen Elternknoten. Die Wurzeloperation ist die einzige Operation ohne Eltern. Beim Ausführungsplan in Textform sind die Kinder nach rechts eingerückt (ein, zwei, oder mehrere Zeichen, abhängig von der Darstellungsmethode). Beachten Sie, dass alle Kinder einer spezifischen Operation die exakt gleiche Einrückung aufweisen.
Ein Elternknoten ist vor seinen Kindern platziert (der Eltern-Identifier ist kleiner als die Identifier ihrer Kinder). Bei mehreren vorgängigen Operationen eines Kindes mit der gleichen Einrückung wie der Elternknoten, ist die am nächsten liegende Operation der Elternknoten. Im folgenden Beispiel gehen wir Schritt für Schritt durch einen Ausführungsplan. Dazu ist im Grunde nur die Spalte Operation notwendig; die Spalte Id dient lediglich der einfacheren Identifikation der Operationen. Das SQL-Statement wurde bewusst weggelassen, weil es für die Interpretation des Ausführungsplanes nicht notwendig ist. ----------------------------------------| Id | Operation | ----------------------------------------| 0 | SELECT STATEMENT | | 1 | SORT ORDER BY | | 2 | FILTER | | 3 | HASH GROUP BY | | 4 | HASH JOIN | | 5 | NESTED LOOPS | | 6 | INDEX RANGE SCAN | | 7 | TABLE ACCESS BY INDEX ROWID| | 8 | INDEX UNIQUE SCAN | | 9 | TABLE ACCESS FULL | | 10 | TABLE ACCESS FULL | -----------------------------------------
Aufgrund der oben beschriebenen Regeln kann man aus dem vorliegenden Ausführungsplan folgende Erkenntnisse gewinnen:
452
8.5 Ausführungspläne
Operation 0 bildet die Wurzel des Baums. Sie hat ein Kind: 1. Diese ist keine eigentliche Operation. Sie beinhaltet lediglich die Information über die Art der SQL-Anweisung (in diesem Fall eine SELECT-Operation).
Operation 1 hat ein Kind: 2 Operation 2 hat zwei Kinder: 3 und 10 Operation 3 hat ein Kind: 4 Operation 4 hat zwei Kinder: 5 and 9 Operation 5 hat zwei Kinder: 6 und 7 Operation 7 hat ein Kind: 8 Die Operationen 6, 8, 9 und 10 haben keine Kinder Es sind ca. 200 Operationen möglich. Um einen Ausführungsplan vollständig zu verstehen, müsste man jede einzelne Operation im Detail beschreiben. Wir beschränken uns auf die Betrachtung der am häufigsten verwendeten Operationen. Zudem formulieren wir einige nützliche Regeln, um zu verstehen, in welcher Reihenfolge die Operationen ausgeführt werden. Die Ausführung beginnt bei der Wurzeloperation. Weil aber eine Elternoperation – um ihren Zweck zu erfüllen – Kinderoperationen ausführen muss, beginnt man typischerweise gleich mit der Betrachtung einer Leaf-Operation. Im Falle von mehreren Leaf-Operationen (in unserem Beispiel sind es deren vier) kann man zwei einfache Regeln anwenden, um herauszufinden, an welcher Stelle die Ausführung beginnt. Ein typischer Interpretationsfehler ist zu meinen, dass die am weitesten nach rechts eingerückte Operation (in unserem Beispiel Operation 8) zuerst ausgeführt wird. Dies ist jedoch falsch. Folgende Regeln sind zu beachten:
Kinder werden immer vor ihren Eltern ausgeführt. Wenn Eltern mehrere Kinder haben, werden die Kinderoperationen sequentiell, in aufsteigender Reihenfolge (gemäß des Identifiers) ausgeführt. Bei der Interpretation eines Ausführungsplans muss man auch die Anzahl Kinder beachten, die zu einer Operation gehören. Abhängig von deren Anzahl gelten folgende Regeln:
Bei Operationen, die höchstens ein Kind haben, wird jedes Kind-Element nur einmal ausgeführt.
Für die Operationen
NESTED LOOPS, UPDATE, FILTER, CONNECT BY WITH FILTE-
RING und BITMAP KEY ITERATION kontrolliert das Kind mit der kleinsten ID nicht nur
die Ausführung der anderen Kinder, sondern es wird auch maximal einmal ausgeführt. Alle anderen Kinder können mehrmals (maximal so oft, wie die Anzahl resultierender Datensätze des ersten Kindes) oder gar nicht ausgeführt werden.
Für alle Operationen, die mehrere Kindelemente haben und die im vorhergehenden Punkt nicht erwähnt sind, wird jedes Kind höchstens einmal und unabhängig von allen anderen Kindern ausgeführt.
453
8 Optimierung Nun wenden wir die beschriebenen Regeln an und gehen Schritt für Schritt durch den Ausführungsplan: 1. Operation 0 und 1 haben nur ein Kind (1 bzw. 2). Die Ausführung kann nicht von hier aus gestartet werden. Fahren wir weiter mit Operation 2. 2. Operation 2 hat zwei Kinder (3 und 10). Zuerst wird die Operation mit der kleinsten ID (Operation 3) ausgeführt. 3. Operation 3 hat ein Kind (4). Operation 4 wird vor 3 ausgeführt. 4. Operation 4 hat zwei Kinder (5 und 9). Operation 5 wird zuerst ausgeführt. 5. Operation 5 hat zwei Kinder (6 und 7). Operation 6 wird zuerst ausgeführt. 6. Operation 6 hat kein Kind. Diese Operation wird also zuerst ausgeführt. Die Operation INDEX RANGE SCAN greift auf einen Index zu und gibt mehrere Einträge an deren Elternoperation (5) zurück. 7. Operation 5 (NESTED LOOPS), die zwei Resultatsets miteinander verknüpft, führt für jeden Datensatz, der von Operation 6 zurückgegeben wird, das zweite Kind (7) einmal aus. 8. Operation 7 hat genau ein Kind (8). Operation 8 wird vorrangig ausgeführt. 9. Operation 8 hat kein Kind und kann daher ausgeführt werden. Diese Operation (INDEX UNIQUE SCAN) verwendet einen Index und gibt der aufrufenden Elternoperation (7) maximal einen Datensatz zurück. 10. Operation 7 (TABLE ACCESS BY INDEX ROWID) verwendet diejenige RowId für den Tabellenzugriff, die von ihrer Kindoperation (8) stammt. Dabei wird der referenzierte Datensatz an die Elternoperation (5) zurückgegeben. 11. Operation 5 verknüpft die Einträge ihrer beiden Kinder (6 und 7) und gibt das Resultat an deren Elternoperation (4) zurück. 12. Operation 4 (HASH JOIN), die auch zur Verknüpfung von zwei Resultatsets verwendet wird, erhält Einträge von ihrem ersten Kind (5) und stellt diese in eine Hash-Tabelle in den Arbeitsspeicher. Danach wird das zweite Kind (9) einmal ausgeführt. 13. Operation 9 (TABLE ACCESS FULL) greift auf eine Tabelle zu und gibt das Resultat an ihre Elternoperation (4) zurück. 14. Operation 4 verwendet die Einträge ihres zweiten Kindes (9) und versucht über die Hashtabelle im Arbeitsspeicher Datensätze zu finden, die die Joinbedingung erfüllen. Dann gibt sie diejenigen Datensätze, die die Joinbedingung erfüllen, an die Elternoperation (3) zurück. 15. Operation 3 (HASH GROUP BY) erhält die Datensätze ihres Kindes (4), führt eine GROUP BY Operation durch und gibt die resultierenden Datensätze an die Elternoperation (2) zurück. 16. Operation 2 (FILTER) erhält die Datensätze ihres ersten Kindes (3), legt darüber eine Filterbedingung und gibt die daraus resultierenden Datensätze an die Elternoperation (1) zurück. Für die Filterbedingung greift sie über ihr zweites Kind (10) auf eine weite-
454
8.5 Ausführungspläne re Tabelle zu. Dieses zweite Kind kann für jeden Datensatz, der vom ersten Kind stammt, einmal ausgeführt werden (in diesem Fall ist dies sehr ähnlich wie die Operation NESTED LOOP). Die Operation FILTER hat eine variable Anzahl Kinder. Wenn nur ein Kind vorhanden ist, ist für diese Operation kein Zugriff auf andere Datenbankstrukturen notwendig. Alle Informationen für die Filterung werden von der Kindoperation zur Verfügung gestellt. Wenn zwei und mehr Kinder existieren, kann jedes folgende Kind (zweites, drittes etc.) einmal pro Datensatz des ersten Kindes ausgeführt werden. 17. Operation 1 (SORT ORDER BY) erhält die Datensätze von ihrem Kind (2), sortiert diese und gibt die resultierenden Datensätze an die Elternoperation (0) zurück. Die Ausführung ist nun zu Ende (Operation 0 ist ja keine eigentliche Operation).
8.5.3
Erkennen von ineffizienten Ausführungsplänen
Wenn ein Ausführungsplan nicht effizient ist, gilt es, einen besseren Plan zu finden. Dies ist eine ernüchternde Feststellung. Trotzdem beschreiben wir in diesem Abschnitt zwei einfache Checks, um Hinweise auf einen ineffizienten Ausführungsplan zu erhalten. Voraussetzung für beide Checks sind Laufzeitstatistiken zum entsprechenden Ausführungsplan. Der einfachste und bekannteste Weg, um diese Statistiken zu ermitteln, ist die Ausführung der SQL-Anweisung mit dem Hint gather_plan_statistics. Danach kann man mit der Funktion display_cursor aus dem Package dbms_xplan die Statistiken anzeigen. Zentrales Merkmal dieses Checks ist, dass für die Beurteilung der Qualität des Ausführungsplans keine Informationen über die SQL-Anweisung oder die Datenbankstruktur notwendig sind. Beachten Sie, dass dieses Feature ab 10g verfügbar ist. Mit dem ersten Check finden wir heraus, ob der verwendete Zugriffspfad gut ist. Er liefert jedoch keine Informationen über die anderen Operationen des Ausführungsplans. Daher kann er nur für Datenzugriffsoperationen (die bekanntesten Operationen beginnen mit TABLE, INDEX und MAT_VIEW) zum Einsatz kommen. Grundidee dieses Checks ist, dass die für den Zugriffspfad verwendeten Ressourcen in einem sinnvollen Verhältnis zur Anzahl zurückgegebener Datensätze (das ist die Anzahl Datensätze, die im Ausführungsplan an die Elternoperation zurückgegeben werden) stehen sollten. Das heißt, wenn wenige Datensätze retourniert werden, sollte der Ressourcenverbrauch klein sein, wenn viele Datensätze zurückgegeben werden, darf der Ressourcenverbrauch entsprechend höher sein. Um diesen Check durchzuführen, beschränken wir uns auf die Ermittlung der durchschnittlichen Anzahl Logical-I/O-Operationen (was grob gesagt der Anzahl untersuchten Blöcke entspricht), die für den Zugriff der Datenstruktur benötigt werden. Die folgenden Regeln können als allgemeine Empfehlung angewendet werden:
Zugriffspfade, die weniger als etwa fünf Logical-Reads pro zurückgegebenem Datensatz verursachen, kann man als gut betrachten.
Zugriffspfade, welche ungefähr zehn bis fünfzehn Logical-Reads pro zurückgegebenem Datensatz verursachen, sind akzeptierbar.
Zugriffspfade, die mehr als zehn bis zwanzig Logical-Reads pro retourniertem Datensatz verursachen, sind ineffizient und können vermutlich optimiert werden.
455
8 Optimierung Beachten Sie im folgenden Beispiel die viel zu hohe Anzahl Logical-I/Os (Buffers) von 2641 im Verhältnis zu den zurückgegebenen Datensätzen (A-Rows), die 1 für Operation 2 ist. Um diese beiden Informationen anzuzeigen, muss man einen dritten Parameter an die Funktion display_cursor übergeben: SQL> SELECT * 2 FROM table( 3 dbms_xplan.display_cursor('fpdyj5ms5parp',0,'iostats last') 4 ); PLAN_TABLE_OUTPUT ------------------------------------------------------------------SQL_ID fpdyj5ms5parp, child number 0 ------------------------------------SELECT /*+ gather_plan_statistics */ count(*) FROM t1 WHERE id = 42 Plan hash value: 3724264953 ----------------------------------------------------| Id | Operation | Name | A-Rows | Buffers | ----------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 2641 | | 1 | SORT AGGREGATE | | 1 | 2641 | |* 2 | TABLE ACCESS FULL| T1 | 1 | 2641 | ----------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - filter("ID"=42)
Im Zusammenhang mit sehr vielen Logical-I/Os gibt es zwei typische Probleme: Entweder fehlen die notwendigen Zugriffsstrukturen (beispielsweise ein fehlender Index) oder die Zugriffsstrukturen sind zwar verfügbar, aber der Optimizer verwendet sie nicht. In unserem Beispiel sieht die Zugriffsstatistik, nachdem ein Index angelegt wurde, wesentlich besser aus: SQL> SELECT * 2 FROM table( 3 dbms_xplan.display_cursor('fpdyj5ms5parp',0,'iostats last') 4 ); PLAN_TABLE_OUTPUT ------------------------------------------------------------------SQL_ID fpdyj5ms5parp, child number 0 ------------------------------------SELECT /*+ gather_plan_statistics */ count(*) FROM t1 WHERE id = 42 Plan hash value: 3890952636 -----------------------------------------------------| Id | Operation | Name | A-Rows | Buffers | -----------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 2 | | 1 | SORT AGGREGATE | | 1 | 2 | |* 2 | INDEX UNIQUE SCAN| T1_ID | 1 | 2 | -----------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------2 - access("ID"=42)
Die Idee hinter dem zweiten Check ist sehr einfach. Der Optimizer berechnet zuerst die Kosten und entscheidet dann, welcher Zugriffspfad, welche Join-Reihenfolge und welche Join-Methode verwendet werden soll, um einen effizienten Ausführungsplan zu ermitteln.
456
8.5 Ausführungspläne Wenn die Kostenberechnung falsch ist, ist es sehr wahrscheinlich, dass der Optimizer einen suboptimalen Ausführungsplan auswählt. Das heißt, falsche Schätzungen können leicht zu einem Fehler bei der Auswahl des Ausführungsplanes führen. Die Kosten einer SQL-Anweisung werden in der Praxis üblicherweise nicht beurteilt. Es ist wesentlich einfacher, die Schätzung des Optimizers aufgrund der geschätzten Anzahl Datensätze (Kardinalität) zu kontrollieren, die von einer Operation zurückgegeben werden. Der Check basiert auf einem Vergleich der Schätzung und den aktuellen Daten. Schauen wir uns dieses Konzept anhand eines Beispiels an, das den Ausführungsplan mit der geschätzten (E-Rows) und der aktuellen Anzahl Datensätze (A-Rows) zeigt. Um diese Information anzuzeigen, ist ein zusätzlicher Parameter der Funktion display_cursor zu übergeben. Wie man in der folgenden Ausgabe sehen kann, ist die Schätzung von Operation 4 (und damit auch von Operation 2 und 3) total falsch. Der Optimizer schätzt für Operation 4 lediglich 32 anstelle von 80.016 retournierten Datensätzen. Und weil Operation 2 ein Nested-Loop ist, vervielfacht sich dieser Fehler. Dies bedeutet, dass die Operationen 5 und 6 anstatt 32 Mal effektiv 80.016 Mal ausgeführt werden. Dies wird zudem durch den Wert in der Spalte Starts bestätigt. Die Schätzung für die Operationen 5 und 6 ist hingegen korrekt, denn die korrekte Kardinalität (A-Rows) muss vor einem Vergleich immer durch die Anzahl Ausführungen (Starts) dividiert werden. SQL> SELECT * 2 FROM table( 3 dbms_xplan.display_cursor('6n8gjd30ar8r1',0,'iostats last') 4 ); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------SQL_ID 6n8gjd30ar8r1, child number 0 ------------------------------------SELECT /*+ gather_plan_statistics */ count(t2.col2) FROM t1 JOIN t2 USING (id) WHERE t1.col1 = 666 Plan hash value: 708808766 ------------------------------------------------------------------------| Id | Operation | Name | Starts | E-Rows | A-Rows | ------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | | 1 | | 1 | SORT AGGREGATE | | 1 | 1 | 1 | | 2 | NESTED LOOPS | | 1 | 32 | 75808 | | 3 | TABLE ACCESS BY INDEX ROWID| T1 | 1 | 32 | 80016 | |* 4 | INDEX RANGE SCAN | T1_I1 | 1 | 32 | 80016 | | 5 | TABLE ACCESS BY INDEX ROWID| T2 | 80016 | 1 | 75808 | |* 6 | INDEX UNIQUE SCAN | T2_PK | 80016 | 1 | 75808 | ------------------------------------------------------------------------Predicate Information (identified by operation id): --------------------------------------------------4 - access("T1"."COL1"=666) 6 - access("T1"."ID"="T2"."ID")
Um das Problem zu verstehen, muss man untersuchen, aus welchem Grund der Optimizer nicht in der Lage ist, gute Schätzwerte zu berechnen. Die Kardinalität berechnet sich aus der Selektivität multipliziert mit der Anzahl Datensätze. Daraus ergeben sich drei möglich Ursachen, wieso die Kardinalität falsch ist: eine falsche Selektivität, eine falsche Anzahl Datensätze oder ein Fehler des Optimizers.
457
8 Optimierung In unserem Fall sollten wir die Analyse mit der Schätzung für Operation 4 beginnen, mit anderen Worten: mit der Schätzung bezüglich des Prädikats "T1"."COL1"=666. Weil die Schätzungen des Optimizers auf den Objektstatistiken basieren, müssen wir untersuchen, ob diese auch die aktuellen Daten reflektieren. Mit der folgenden Abfrage kann man die Objektstatistiken für den Index t1_i1 ermitteln, der in Operation 4 verwendet wird. Gleichzeitig kann man die durchschnittliche Anzahl Rows pro Schlüssel berechnen. Dies ist jener Wert, der vom Optimizer verwendet wird, wenn kein Histogramm vorhanden ist. SQL> SELECT num_rows, distinct_keys, 2 num_rows/distinct_keys AS avg_rows_per_key 3 FROM user_indexes 4 WHERE index_name = 'T1_I1'; NUM_ROWS DISTINCT_KEYS AVG_ROWS_PER_KEY ---------- ------------- ---------------160000 5000 32
Wie man in diesem Fall erkennen kann, entspricht die durchschnittliche Anzahl Datensätze (32) exakt der geschätzten Kardinalität des vorhergehenden Ausführungsplans. Um zu prüfen, ob diese Objektstatistiken gut sind, muss man sie mit den aktuellen Daten vergleichen. Also führen wir die folgende Abfrage auf die Tabelle t1 aus. Wie man sehen kann, zeigt die Abfrage nicht nur die Objektstatistiken der vorhergehenden Abfrage an, sondern berechnet auch die Anzahl Datensätze, bei denen der Attributswert von Spalte col1 „666“ beträgt: SQL> SELECT count(*) AS num_rows, 2 count(DISTINCT col1) AS distinct_keys, 3 count(CASE WHEN col1=666 THEN 1 ELSE NULL END) AS num_rows_666 4 FROM t1; NUM_ROWS DISTINCT_KEYS NUM_ROWS_666 ---------- ------------- -----------160000 5000 79984
Aufgrund dieses Resultates können wir bestätigen, dass die Objektstatistiken korrekt sind. Man sieht aber auch, dass die Daten sehr ungleich verteilt sind. Dies bedeutet, dass Histogramme für die korrekte Schätzung absolut notwendig sind. Mit der folgenden Abfrage kann bestätigt werden, dass in diesem Fall kein Histogramm existiert: SQL> SELECT histogram, num_buckets 2 FROM user_tab_col_statistics 3 WHERE table_name = 'T1' AND column_name = 'COL1'; HISTOGRAM NUM_BUCKETS --------------- ----------NONE 1
Nachdem die fehlenden Histogramm-Informationen ermittelt sind, ist der Optimizer in der Lage, die Kardinalität korrekt abzuschätzen und in Folge dessen einen effizienteren Ausführungsplan auszuwählen: -------------------------------------------------------------| Id | Operation | Name | Starts | E-Rows | A-Rows | -------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | | 1 | | 1 | SORT AGGREGATE | | 1 | 1 | 1 | |* 2 | HASH JOIN | | 1 | 80000 | 75808 | |* 3 | TABLE ACCESS FULL| T1 | 1 | 80000 | 80016 | | 4 | TABLE ACCESS FULL| T2 | 1 | 151K| 151K| --------------------------------------------------------------
458
8.6 Methoden zur Lösung von Performance-Problemen
8.6
Methoden zur Lösung von Performance-Problemen Mit der Identifikation der zeitintensivsten SQL-Anweisungen ist das Ziel noch nicht erreicht. Im nächsten Schritt muss man beurteilen, ob und wie die Laufzeit allenfalls verringert werden kann. Dazu stehen diverse Methoden zur Verfügung. Wir stellen die verfügbaren Methoden vor und zeigen auf, in welchem Fall diese Sinn machen.
8.6.1
Verhinderung unnötiger Arbeit
Die einfachste Methode ist ohne Zweifel die, eine SQL-Anweisung gar nicht erst auszuführen. Das klingt zwar trivial, aber man sollte sich bei der Lösung von PerformanceProblemen immer fragen, ob es wirklich notwendig ist, das SQL-Statement auszuführen. Die wiederholte Abfrage statischer Daten ist einer der häufigsten Fälle unnötiger Arbeit. Hier ist es natürlich sinnvoller, die Daten nur einmal zu selektieren und das Resultat für die spätere Verwendung im Memory zu speichern. Diese Methode ist nicht nur für langsame Abfragen interessant, sondern auch für Abfragen, die sehr schnell sind, aber in einer hohen Frequenz ausgeführt werden. So kann auch eine sehr schnelle Abfrage wie beispielsweise „SELECT user FROM dual”, die hundert oder tausend Mal pro Sekunde ausgeführt wird, viel Zeit kosten. Weitere Beispiele unnötiger Arbeit sind das Lesen von nichtrelevanten Daten oder das Modifizieren von Daten, die sich nicht geändert haben. Ein typisches Beispiel des ersten Falles ist eine Abfrage mit „SELECT *”, obwohl nicht alle Attribute benötigt werden. Eine solche Abfrage führt zu unnötig hohem Aufwand: der Optimizer ist nicht in der Lage, einen optimalen Ausführungsplan zu wählen, mehr CPU-Ressourcen für das Extrahieren der Daten aus den Datenbankblöcken fällt an, mehr Netzwerkbandbreite ist notwendig, um die Daten über das Netz zu transportieren und vom Caller wird mehr CPU-Leistung für die Verarbeitung der Daten benötigt. Ein typisches Beispiel des zweiten Falles ist ein Update-Statement, das jeden Attributwert eines bestimmten Datensatzes modifiziert, obwohl eigentlich nur wenige Attribute geändert werden. Dies geschieht normalerweise in der Absicht, die Komplexität und somit die Entwicklungszeit zu reduzieren. In bestimmten Situationen wird ein solcher Fall aus Sicht der Performance gar nicht erkannt; in anderen Fällen führt dies zu massiven Problemen.
8.6.2
Datenbankaufrufe schneller machen
Wenn es wirklich notwendig ist, ein bestimmtes SQL-Statement auszuführen, sollte man untersuchen, ob dies mit einem optimalen Ausführungsplan erfolgt. Wie man das beurteilt, ist in Abschnitt 8.5.3 beschrieben. Wenn eine Optimierung notwendig ist, kann man eine der in den folgenden Abschnitten beschriebenen Methoden anwenden. Wenn Sie die „Oracle Tuning Pack“-Option lizenziert haben, sollten Sie als Erstes – bevor Sie sich weitere Gedanken machen – die fraglichen SQL-Anweisungen vom „SQL Tuning
459
8 Optimierung Advisor“ analysieren lassen. Dieser gibt Ihnen ohne viel Aufwand nützliche Hinweise, wie man die Performance verbessern kann. 8.6.2.1
Änderung der Zugriffsstrukturen
Die Antwortzeit eines SQL-Statements hängt nicht nur davon ab, wie die Daten gespeichert sind, sondern auch, wie man darauf zugreifen kann. Für die Lösung von Performance-Problemen ist deshalb der erste Schritt die Verifikation der Zugriffsstrukturen. Basierend auf den Informationen aus dem Data-Dictionary sollte man folgende Fragen beantworten:
Wie sind die betroffenen Tabellen organisiert? Handelt es sich um Heap-Tabellen, Index-Organized-Tabellen oder um externe Tabellen? Ist die Tabelle in einem Cluster gespeichert?
Werden Materialized Views verwendet? Welche Indizes sind auf den Tabellen, den Clusters und den Materialized Views vorhanden? Welche Attribute sind indexiert und in welcher Reihenfolge?
Wie sind die Segmente partitioniert? Als nächstes gilt es zu beurteilen, ob die vorhandenen Zugriffsstrukturen für die effiziente Verarbeitung des problematischen SQL-Statements geeignet sind. So stellt sich beispielsweise während der Untersuchung heraus, dass für die WHERE-Klausel eines SQL-Statements ein zusätzlicher Index notwendig ist. 8.6.2.2
Änderung der SQL-Statements
SQL ist eine sehr mächtige und flexible Abfragesprache. In vielen Fällen kann man damit die gleiche Abfrage auf unterschiedlichste Art und Weise formulieren. Dies ist besonders für die Entwickler interessant. Für den Query-Optimizer hingegen ist die Berechnung von effizienten Ausführungsplänen für alle möglichen Varianten eine große Herausforderung. Bei der Optimierung von SQL-Statements sollte man sich daher immer fragen, ob es nicht ein äquivalentes SQL-Statement gibt. Ist dies der Fall, kann man die Ausführungspläne, den Ressourcenverbrauch und die Antwortzeiten sorgfältig miteinander vergleichen. Eventuell findet man eine SQL-Anweisung, die im Vergleich eine deutlich bessere Performance aufweist. 8.6.2.3
Ändern der Runtime-Umgebung
Abschnitt 8.2.1 beschreibt, wie man eine Instanz konfiguriert, um eine optimale Performance zu erzielen. Die Konfiguration auf Instanzebene definiert die Default-Runtime-Umgebung für alle mit der Datenbank-Engine verbundenen Benutzer. Wenn man eine Datenbank von verschiedenen Applikationen mit unterschiedlichen Anforderungen benutzt, ist es nicht ungewöhnlich, dass die Runtime-Umgebung nicht in jeder Situation eine adäquate Performance bietet. Dasselbe gilt natürlich auch für eine einzelne Applikation mit unterschiedlichen Modul-Anforderungen. In einem solchen Fall ist es sinnvoll, die RuntimeUmgebung auf Sessionebene oder sogar auf SQL-Statement-Ebene anzupassen.
460
8.6 Methoden zur Lösung von Performance-Problemen 8.6.2.4
Ändern des Ausführungsplans
Auch wenn Sie eine gute Konfiguration und die nötigen Zugriffsstrukturen besitzen, können Situationen entstehen, in denen der Query-Optimizer nicht in der Lage ist, eine optimale Entscheidung zu treffen. In einem solchen Fall müssen Sie diesen bei der Suche eines optimalen Ausführungsplans unterstützen. Wenn es möglich ist, das SQL-Statement zu modifizieren, können Sie Hints einbauen, die zum gewünschten Ausführungsplan führen. Wenn man das Statement nicht ändern kann, stehen als Alternative Stored Outlines, SQL Profiles oder SQL Plan Baselines zur Verfügung. Stored Outlines, die ab 11g nicht mehr verwendet werden sollten (deprecated), sind das einzige Feature, das bisher immer vorhanden war. Der Einsatz von SQL Profiles bedingt die „Oracle Tuning Pack"-Option“ und SQL Plan Baselines sind nur ab 11g und in der Enterprise Edition verfügbar. 8.6.2.5
Einsatz von Advanced-Features
Wenn die Performance-Probleme mit keiner der vorgestellten Methoden gelöst werden können, ist es an der Zeit, eine der folgenden Advanced-Methoden anzuwenden:
Materialized Views: Besonders dann, wenn man regelmäßig viele semistatische Daten aggregiert und/oder verknüpft, sollten diese Operationen nicht x-fach zur Laufzeit ausgeführt werden, sondern in einem Schritt. Das Resultat wird dann in einer redundanten Datenstruktur wie beispielsweise eine Materialized View gespeichert. Der Vorteil dieses Vorgehens ist der optimale Datenzugriff. Der Nachteil liegt in der Redundanz der Datenstruktur: diese muss man aktuell halten.
Result Caching (ab 11g): Sinn und Zweck des Result Caching ist die Vermeidung von wiederholten Ausführungen ein und derselben Abfrage, indem die Resultatmenge im Memory gespeichert wird. Im Prinzip ist dies dasselbe, wie bei den Materialized Views. Der Hauptunterschied liegt darin, wo und wann die Daten gespeichert werden. Man muss sich zwei wichtige Fragen stellen, um zu entscheiden, welche Methode die bessere ist. Erstens, habe ich genug Memory um die Daten zwischenzuspeichern? Zweitens, müssen die Daten bereitstehen, bevor der erste Benutzer mit der Abfrage beginnt? Es ist auch zu bedenken, dass Result Caching und Materialized Views unterschiedlich mit volatilen Daten umgehen. Welche Methode besser geeignet ist, hängt deshalb von der jeweiligen Situation ab.
Parallele Verarbeitung: Per Default wird eine SQL-Anweisung von der DatenbankEngine seriell von einem Serverprozess ausgeführt. Das heißt, auch wenn der Datenbankserver über mehrere CPUs verfügt, wird das SQL-Statement auf genau einer CPU ausgeführt. Das Ziel der parallelen Verarbeitung ist die Verteilung der Ausführung einer SQL-Anweisung über mehrere CPUs.
Direct-Path Inserts und Minimal Logging: Ziel von Direct-Path Inserts und Minimal Logging ist, große Datenmengen effizient in die Datenbank zu laden. Beide Methoden sind dazu geeignet, weil sie primär auf Performance und nicht auf Funktionalität optimiert sind. Im Vergleich zu Conventional Inserts sind mehr Restriktionen und Anforderungen zu berücksichtigen. Man sollte sie deshalb nur dann in Betracht ziehen, wenn große Datenmengen geladen werden müssen.
461
8 Optimierung
Row Prefetching: Wenn eine Applikation Daten aus der Datenbank bezieht, kann dies Datensatz für Datensatz erfolgen, oder – was natürlich effizienter ist – durch Bezug mehrerer Datensätze auf einmal. Immer dann, wenn man mehr als einen Datensatz bezieht, ist der Einsatz von Row Prefetching sinnvoll.
Array Interface: Das Array Interface erlaubt das Binding von Arrays anstelle von skalaren Werten. Dies ist dann sehr nützlich, wenn man mit einer DML-Anweisung viele Datensätze einfügt oder modifiziert. Anstatt die DML-Anweisung für jeden Datensatz auszuführen, werden alle benötigten Attributwerte als Array gebunden und in einem Schritt ausgeführt. Bei vielen Datensätzen kann man die Verarbeitung auch in kleinere Batches aufteilen. 8.6.2.6
Verhinderung von Contention
Wenn mehrere Benutzer gleichzeitig die Datenbank-Engine benutzen, kann dies in verschiedenen Bereichen zu Konkurrenzsituationen (Contention) führen. Dies ist durch die Architektur bedingt, weil sich alle Benutzer die Strukturen in der SGA und die Daten in der Datenbank teilen. Tritt ein Contention-Problem auf, sollte man entweder die Anzahl Zugriffe auf die geteilte Komponente (Struktur oder Block) reduzieren oder die Last über mehr Komponenten verteilen. Ein Beispiel für den ersten Fall ist eine Applikation, die übermäßig Parse-Operationen auslöst. Mit einer umsichtigen Cursor-Verwaltung sollte es möglich sein, die meisten Parse-Operationen zu vermeiden. Ein Beispiel für den zweiten Fall sind mehrere Benutzer, die gleichzeitig Daten in den gleichen Block einfügen. Durch Verteilen der Inserts in mehrere Blöcke kann man Contention minimieren oder ganz verhindern.
8.6.3
Ressourcen-Verwaltung
Wenn ein System nur während bestimmten Zeiten unter Ressourcen-Engpässen leidet, kann es durchaus Sinn machen, die Operationen zeitlich zu entflechten. Die Verschiebung von konkurrierenden Operationen auf einen Zeitpunkt außerhalb der Peak-Time kann ein einfacher und effektiver Weg sein, Performance-Probleme zu vermeiden (oder zu verstecken). Folgende drei Vorgehensweisen stehen für diesen Zweck zur Verfügung:
Führen Sie Hintergrundoperationen explizit außerhalb der Peak-Time aus. Schränken Sie die Anzahl konkurrierender Operationen ein, die zu einem bestimmten Zeitpunkt ausgeführt werden. Dies führt üblicherweise zu einer Warteschlange für Operationen, die asynchron ausgeführt werden können.
Nutzen Sie die Vorteile des Datenbank Ressource Managers, der die Priorisierung bestimmter Operationen oder Benutzer vornehmen kann.
462
8.7 Resümee
8.6.4
Hardware-Upgrade
Als letzte Möglichkeit kommt die Aktualisierung der Hardware in Betracht. Man sollte dabei aber nur Ressourcen ersetzen oder hinzufügen, die in der bestehenden Konfiguration einen Engpass darstellen und die das bestehende Problem effektiv auch lösen. Andernfalls stellt man im besten Fall keinen Unterschied fest und im schlechtesten Fall verschärft sich das Problem. Die Wahl zwischen mehr Durchsatz auf der einen Seite und Reduktion der Wartezeit auf der anderen Seite ist typischerweise die kritische Entscheidung in der Praxis. Manchmal benötigt man mehr Durchsatz, manchmal weniger Wartezeit. Wenn man beispielsweise die Antwortzeit einer Operation verbessern will, die CPU-lastig ist, hat man zwei Möglichkeiten: zusätzliche CPUs einbauen oder die bestehenden CPUs durch schnellere zu ersetzen. Wenn die CPUs auf dem aktuellen System komplett ausgelastet sind, kommen beide Optionen in Betracht. Wenn die Operation nicht parallelisiert werden kann und bereits eine ganze CPU für sich beansprucht, hilft nur eine schnellere CPU. Daher muss man auf jeden Fall zuerst ermitteln, was wirklich benötigt wird, bevor man einen Hardware-Upgrade in Betracht zieht.
8.7
Resümee Im ersten Teil dieses Kapitels haben wir nicht nur beschrieben, wieso es wichtig ist das Design von Applikationen und Datenbanken aus Performance-Sicht zu betrachten, sondern auch, wie man eine Oracle-Instanz konfiguriert, um die optimale Performance zu erreichen. Dies sind kritische Aspekte, weil ohne solide Grundlagen die Wahrscheinlichkeit, ein Performance-Problem zu verursachen, viel höher ist. Im zweiten Teil haben wir beschrieben, wie man mit Performance-Problemen umgeht. Nachdem wir das grundlegende Vorgehen erklärt haben, gingen wir detailliert auf die Problem-Identifikation in verschiedenen Situationen ein. Das Erstellen, Lesen und Interpretieren von Ausführungsplänen wurde ebenfalls im Detail diskutiert. Das Kapitel ist mit einer Übersicht über die verschiedenen Problemlösungsmethoden abgerundet. Um Performance-Probleme zu lösen, bedarf es einer sorgfältigen und fundierten Vorgehensweise.
463
8 Optimierung
464
9 9 Troubleshooting In diesem Kapitel besprechen wir folgende Themengebiete:
Auswertungen der Datei Alert.log über SQL*Plus; das Automatic Diagnostic Repository und Health Monitoring; der Data Recovery Advisor; die Support Workbench; das My Oracle Support ORA-600/ORA-7445 Lookup Tool. Eine funktionierendes Datenbank-Monitoring sowie eine ganzheitliche Überwachung der vollständigen IT-Infrastruktur (Applikation, Applikations-Server, Betriebssystem, Netzwerk, Datenbank und Storage-Subsystem) sind im Ernstfall die Grundvoraussetzungen für eine effiziente Fehleranalyse und Fehlerbehebung. Die wichtigsten Bestandteile und Techniken für ein effizientes Datenbank-Monitoring sind in Kapitel 11 „Monitoring“ ausführlich besprochen. Im Rahmen von Kapitel 8 „Optimierung“ haben Sie zudem die Tiefen des Performance-Tunings wie die Identifizierung von Performance-Problemen, strukturierte Lösungsansätze sowie wichtige Stellschrauben der Datenbank kennengelernt. In diesem Kapitel geht es nun um einige mit Oracle 11g neu implementierte Hilfsmittel zur Erleichterung der Analyse von Datenbankproblemen und der Behebung von Fehlersituationen. Ein sogenanntes „Fehlerdiagnose-System“ soll den Datenbank-Administrator bei der Fehlersuche und Problembehebung wesentlich unterstützen.
9.1
Alert.log Die wichtigste Datei für eine fundierte Fehleranalyse einer Oracle-Datenbank heißt „Alert.log“. Diese Datei muss generell in jedes Datenbank-Monitoring einbezogen werden. Hier sind chronologisch alle Meldungen von Administrationsoperationen bis hin zu Fehlersituationen protokolliert. Die Meldungen umfassen folgende Ereignisse:
465
9 Troubleshooting
Starten und Stoppen der Datenbankinstanz. Beim Startup werden alle Parameter angezeigt, die nicht den Standardeinstellungen entsprechen.
Fehlermeldungen, die Trace-Files hervorrufen, wie zum Beispiel interne Fehlermeldungen (ORA-600), Block-Korruptionen (ORA-1579, ORA-1578), Deadlocks (ORA-60) oder andere interne Fehlermeldungen (ORA-7445)
Administrative, datenbankbezogene SQL-Befehle wie zum Beispiel CREATE, ALTER oder DROP sowie Befehle bezogen auf Tablespaces, Datenfiles oder auch datenbankprozessbezogene Aktivitäten
Fehler beim Refresh von Materialized Views Fehler aufgrund von Platzproblemen (ORA-1653) Mit Einführung der Automatic-Diagnostic-Repository-Struktur in 11g R1 ist die Alert.logDatei nicht mehr im bdump-Verzeichnis unter $ORACLE_BASE/admin/SID zu finden, sondern gleich zweimal in folgenden Zielverzeichnissen:
Als Text-Datei unter $ADR_BASE/rdbms/db_unique_name/SID/trace Als XML-File unter $ADR_BASE/rdbms/db_unique_name/SID/alert/log.xml Das XML-File lässt sich mit dem ADRCI-Utility auswerten, während für die Text-Datei herkömmliche Mittel erforderlich sind. Herkömmlich heißt in diesem Fall Auswertung mit Stringparsing oder seit Version 11g mit SQL*Plus. Über die Fixed-Table X$DBGALERTEXT kann das Alert-Log (log.xml) ausgewertet werden: SQL> SELECT message_text FROM x$dbgalertext WHERE rownum SELECT id, name, offline_capable, description FROM V$HM_CHECK ORDER BY id; ID -1 2 3 4 5 10 11 12 13 14
NAME ----------------------------HM Test Check DB Structure Integrity Check Data Block Integrity Check Redo Integrity Check Logical Block Check Transaction Integrity Check Undo Segment Integrity Check No Mount CF Check CF Member Check All Datafiles Check
O Y Y Y Y N N N Y Y Y
DESCRIPTION ---------------------Check for health monitor functionality Checks integrity of all database files Checks integrity of a data file block Checks integrity of redo log content Checks logical content of a block Checks a transaction for corruptions Checks integrity of an undo segment Checks control file in NOMOUNT mode Checks a multiplexed copy of the cf Checks all datafiles in the database
Single Datafile Check Log Group Check Log Group Member Check Archived Log Check Redo Revalidation Check IO Revalidation Check Block IO Revalidation Check Txn Revalidation Check Failure Simulation Check Dictionary Integrity Check CF Block Integrity Check ASM Mount Check ASM Allocation Check ASM Disk Visibility Check ASM File Busy Check Tablespace Check Check Mount CF Check
Y Y Y Y Y Y Y N Y N Y Y Y Y Y Y Y
Checks a data file Checks all members of a log group Checks a particular member of a loggrp Checks an archived log Checks redo log content Checks file accessibility Checks file accessibility Revalidate corrupted transaction Creates dummy failures Checks dictionary integrity Checks integrity of a control file blk Diagnose mount failure Diagnose allocation failure Diagnose add disk failure Diagnose file drop failure Checks a tablespace Checks control file in mount mode
Grundsätzlich sind die Health-Monitor-Prüfungen in zwei Kategorien unterteilt:
DB-Online: Diese Prüfungen sind nur bei geöffneter Datenbank möglich DB-Offline: Diese Prüfungen sind sowohl bei geöffneter Datenbank als auch bei einer im NOMOUNT-Status befindlichen Datenbank möglich Die erstellten Berichte erhalten eine Priorität (Low, High, Critical), Beschreibungen der festgestellten Untersuchungsergebnisse sowie deren Auswirkungen und sind im XMLFormat im ADR abgelegt. Zum Lesen dient entweder die View V$HM_RUN, das Package DBMS_HM, das Utility ADRCI oder der Enterprise Manager. Das folgende Beispiel zeigt das Ausführen eines Dictionary-Integrity-Checks über das Package DBMS_HM sowie das anschließende Auswerten. SQL> exec dbms_hm.run_check ('Dictionary Integrity Check','MyDictionary Check1',60);
Die für diese Prozedur erforderlichen Übergabe-Parameter haben folgende Bedeutung:
Checkname (IN VARCHAR2): Name des ausgewählten Health Checks (siehe View V$HM_CHECK)
Run_Name (IN VARCHAR2): Selbst vergebener Name für diese Health-Check-Auswertung
Timeout (IN NUMBER): Mögliche Zeitüberschreitung in Minuten, hier maximal 60 Minuten
Input_Params (IN VARCHAR2): Eingabe möglicher Eingabeparameter. Im Falle des Dictionary-Integrity-Checks können folgende Werte für die Prüfungsmaske mitgegeben werden:
COLUMN_CHECKS: Nur Spaltenprüfungen, Verifizieren von Constraints auf Spaltenebene in den Core-Tabellen
ROW_CHECKS: Nur Zeilenprüfungen, Verifizieren von Constraints auf Zeilenebene in den Core-Tabellen
REFERENTIAL_CHECKS: Nur referentielle Prüfungen, Verifizieren von referentiellen Constraints in den Core-Tabellen
ALL: Standardwert. Alle oben aufgeführten Prüfungen werden durchgeführt
470
9.3 Health Monitoring Das Anzeigen des Berichts erfolgt am einfachsten über das ADRCI-Utility: adrci> show hm_run ********************************************************** HM RUN RECORD 8 ********************************************************** RUN_ID 579 RUN_NAME MyDictionaryCheck1 CHECK_NAME Dictionary Integrity Check NAME_ID 24 MODE 0 START_TIME 2011-06-05 14:12:44.593826 +02:00 RESUME_TIME END_TIME 2011-06-05 14:12:46.003335 +02:00 MODIFIED_TIME 2011-06-05 14:13:27.406772 +02:00 TIMEOUT 60 FLAGS 0 STATUS 5 SRC_INCIDENT_ID 0 NUM_INCIDENTS 0 ERR_NUMBER 0 REPORT_FILE /u00/app/oracle/diag/rdbms/mu1db1/MU1DB1/hm/HMREPORT_MyDictionaryCheck1.hm adrci> create report HM_RUN MyDictionaryCheck1 adrci> show report HM_RUN MyDictionaryCheck1 <TITLE>HM Report: MyDictionaryCheck1 Dictionary Integrity Check 579 MyDictionaryCheck1 MANUAL COMPLETED 0 <SOURCE_INCIDENT_ID>0 0 2011-06-05 14:12:44.593826 +02:00 2011-06-05 14:12:46.003335 +02:00 TABLE_NAME=ALL_CORE_TABLES CHECK_MASK=ALL Dictionary Inconsistency 580 FAILURE OPEN …
Falls der Enterprise Manager verfügbar ist, ist das Auslesen der Health-Monitor-Berichte damit zu empfehlen (siehe Abbildung 9.3). Zudem steht der Recovery-Advisor bei Bedarf über die grafische Oberfläche ebenfalls zur Verfügung. Das Health-Monitoring-Auswahlmenü ist über , , zu erreichen. Der Enterprise Manager bietet nur eine eingeschränkte Auswahl an ausführbaren Health Checks an:
DB Structure Integrity Data Block Integrity Transaction Integrity
471
9 Troubleshooting
Abbildung 9.3 Verfügbare Health Checks über den Enterprise Manager 11g Version 11.2.0.2
Redo Integrity Dictionary Integrity Undo Segment Integrity CF Block Integrity Eine Auswahl des gewünschten Health Checks zeigt die Analyse-Ergebnisse im Detail. Die Berichte (siehe Abbildung 9.4) werden persistent in der Datenbank vorgehalten und sind somit jederzeit bis zur endgültigen Lösung aufrufbar. Bei Bedarf ist auch der Aufruf des Data Recovery Advisors möglich. Dieser bietet entsprechende Hilfsfunktionalitäten (ADVISE-Befehl) für bestimmte Fehlersituationen. In Abbildung 9.4 werden einige Zeilenverweise von Core-Datenbanktabellen bemängelt. Diese Fehlermeldungen werden wir nun über den Recovery Advisor weiter bearbeiten (siehe Abbildung 9.5). Nach Auswahl der Untersuchungsergebnisse unseres Health-Monitor-Checks und der Nutzung des Recovery Advisors erscheint die Empfehlung „Please contact Oracle Support Services to resolve failure …“. Manuelle Analysen der gefundenen Fehler ergeben, dass es sich bei den angeblich beschädigten RowIds lediglich um Segmente des Typs „Indexed Organized Tables“ im Schema REORG1 handelt.
472
9.3 Health Monitoring
Abbildung 9.4 Ergebnisbericht eines Dictionary-Integrity-Checks über den Enterprise Manager 11g Version 11.2.0.2
Abbildung 9.5 Ergebnisse des Recovery Advisors auf Basis eines Health-Monitor-Dictionary-IntegrityErgebnisberichts durch den Enterprise Manager 11g
473
9 Troubleshooting Mit dem RMAN-Utility lässt sich der Recovery Advisor auf Kommandozeilenebene benutzen: RMAN> connect target / RMAN> list failure all; List of Database Failures ========================= Failure ID Priority Status Time Detected ---------- -------- --------- ------------512 CRITICAL OPEN 05-JUN-11 42 on object FILE$ failed 509 CRITICAL OPEN 05-JUN-11 42 on object FILE$ failed 81 CRITICAL OPEN 10-MAY-11 42 on object FILE$ failed 58 CRITICAL OPEN 09-MAY-11 42 on object FILE$ failed 28 CRITICAL OPEN 02-MAY-11 pctfree found 10 on object TAB$ failed 25 CRITICAL OPEN 02-MAY-11 pctfree found 10 on object TAB$ failed 22 CRITICAL OPEN 02-MAY-11 pctfree found 10 on object TAB$ failed
Summary ------SQL dictionary health check: file$ pk SQL dictionary health check: file$ pk SQL dictionary health check: file$ pk SQL dictionary health check: file$ pk SQL dictionary health check: invalid SQL dictionary health check: invalid SQL dictionary health check: invalid
RMAN> advise failure 512; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary ---------- -------- --------- ------------- ------512 CRITICAL OPEN 05-JUN-11 SQL dictionary health check: file$ pk 42 on object FILE$ failed Mandatory Manual Actions ======================== 1. Please contact Oracle Support Services to resolve failure 512: SQL dictionary health check: file$ pk 42 on object FILE$ failed Optional Manual Actions ======================= no manual actions available Automated Repair Options ======================== no automatic repair options available
Auch RMAN bietet uns in diesem Fall kein automatisiertes Reparieren der Fehlersituation an. Dies ist leider auch in der aktuellen Version 11.2.0.2 in vielen Fällen so. Von daher bleibt nur die Prüfung der Fehlersituation über das eigene verfügbare Know-how und gegebenenfalls eine manuelle Korrektur oder wie in diesem Fall das manuelle Schließen dieser Fehlermeldung. Im Zweifel empfiehlt es sich immer, den Oracle Support zu kontaktieren. Praxistipp Die neue Health-Monitoring-Funktionalität ist eine gute Sache. Wir haben die Möglichkeit, entweder über den Enterprise Manager, über das PL/SQL-Package oder über das Kommandozeilen-Utiltity ADRCI die Datenbank proaktiv oder reaktiv über zahlreiche zur Verfügung stehende Health Checks zu prüfen. Die Ergebnisberichte sind größtenteils einfach verständlich. Als verantwortungsvoller DBA sollten wir allerdings diese Ergebnisse sehr genau prüfen, da sich hinter den Meldungen manchmal keine wirklichen Fehler verbergen.
474
9.4 Data Recovery Advisor Die Idee des Data Recovery Advisors ist im Prinzip gut. Jedoch merkt man noch deutlich, dass hier die Entwicklung erst am Anfang steht. Längst verfügbare RMAN-Funktionalität wie das Failover auf ältere Backups oder fehlende Archivelogs für ein Recovery bieten noch Raum für Verbesserungen. Hier lautet die Empfehlung: Auf jeden Fall die Vorschläge oder bereits generierte RMAN-Skripte sorgfältig prüfen. In den meisten Fällen ist man mit der herkömmlichen manuellen Methode auf der sichereren Seite. Mit den neu integrierten Fehleranalyse-Möglichkeiten sollten Sie gut vertraut sein. Im Ernstfall wird der Oracle Support in dem einen oder anderen Fall entsprechende Health-CheckBerichte für eine fundierte Fehleranalyse anfordern.
9.4
Data Recovery Advisor Wie bereits schon im vorhergehenden Abschnitt angedeutet, geht es beim Data Recovery Advisor um folgende Ziele:
Schnelle Entdeckung, Analyse und das Reparieren von Datenbank-Fehlersituationen Minimierung von möglichen Betriebsstörungen Lösen von Ausfallzeiten und Laufzeitfehlern der Datenbank Das RMAN-Kommandozeilen-Utility oder der Enterprise Manager als grafische Variante stellen die derzeit zur Verfügung stehenden Analysemöglichkeiten dar. Es werden leider nur Single-Instance-Datenbankkonfigurationen unterstützt. RAC-Konfigurationen werden momentan leider noch nicht unterstützt. Das Failover auf Standby-Datenbanken hingegen schon, allerdings nicht das Analysieren und Reparieren von Standby-Datenbanken.
Abbildung 9.6 Einstiegsseite für den Data Recovery Advisor über den Menüpunkt
Neben den Memory Advisors, SQL Advisors, Automatic Undo Management, MTTR Advisor, SQL Performance Advisor, Segment Advisor und Streams Performance Advisor finden wir hier auch der Haupteinstiegspunkt für den Data Recovery Advisor. Je nach Kontextabhängigkeit kann man auch über die Menüpunkte „Database Instance Health“, „Active Incidents“ oder die Support-Workbench per Link dorthin verzweigen.
475
9 Troubleshooting
Abbildung 9.7 Fehlerbearbeitungsseite des Data Recovery Advisors
Der Diagnose-Ablauf ab Oracle 11g stellt sich wie folgt dar: Mit dem Data Recovery Advisor wird über die Funktion „Advise“ eine Analyse der Fehlersituation ausgeführt und anschließend über die Funktion „Repair“ die Behebung dieser Betriebsstörung durchgeführt. Der Ablauf gestaltet sich folgendermaßen:
Das Health Monitoring führt automatische Prüfungen durch und protokolliert Störungen und deren Symptome als sogenannte „Findings“ in das Automatic Diagnostic Repository.
Der Data Recovery Advisor konsolidiert die Untersuchungsergebnisse in zugehörigen Störfällen. Die erkannten Datenfehler erhalten eine Klassifizierung (Critical oder High).
Wenn nun eine Anfrage nach einer Korrekturempfehlung abgesetzt wird, verbindet der Data Recovery Advisor die Störfälle entweder mit automatischen oder manuellen Lösungsmöglichkeiten, prüft die Basisausführbarkeit und stellt die Lösungsempfehlung vor.
Der Anwender hat die Wahl zwischen einer manuellen Lösungsausführung oder einer durch den Data Recovery Advisor automatisch ausgeführten Skriptlösung.
Zusätzlich zu den reaktiven und proaktiven Prüfungen wird allerdings ein regelmäßiges Ausführen des Kommandos RMAN-VALIDATE empfohlen; RMAN> VALIDATE DATABASE; RMAN> VALIDATE DATAFILE 7; RMAN> VALIDATE DATAFILE 7 BLOCK 5;
Das Kommando VALIDATE ermittelt Datenstörungen. Folgende Fehlersituationen können dadurch erkannt werden:
476
9.5 Support Workbench
Nicht mehr zugreifbare Datenbank-Komponenten Fehlende Datenfiles auf Betriebssystemebene Nicht korrekte Zugriffsrechte Tabelspaces, die sich im Offline-Status befinden Physikalische Korruptionen wie Block-Prüfsummen-Fehler oder ungültige BlockHeader-Werte
Logische Korruptionen wie inkonsistentes Dictionary, korrupte Zeilen oder Teile von Zeilen, korrupte Indexeinträge oder korrupte Transaktionen
Sonstige Inkonsistenzen, wie Controlfiles, die älter oder neuer als die zugehörigen Datenfiles oder Online-Redolog-Dateien sind
I/O-Fehler wie das Überschreiten des Limits bei der Anzahl geöffneter Dateien, nicht zugreifbare Kanäle, Netzwerk oder I/O Fehler Praxistipp Die Ergebnisse des Data Recovery Advisors sind in den aktuellen Datenbankversionen noch mit Vorsicht zu genießen. Oft wird als Empfehlung die Meldung „Contact Oracle Support“ ausgegeben. Bei schwerwiegenden Störfällen ist das zwar ein guter Rat, jedoch leider noch weit von der von Oracle vorgegebenen Zielsetzung des automatischen Fehlerbehebens entfernt. Die Empfehlungen und Korrekturskripte können ein guter Hinweis auf eine mögliche Lösung des Problems darstellen. Das fundierte Know-how in diesem Bereich können sie aber nicht ersetzten.
9.5
Support Workbench Die Support Workbench ist ein zentralisiertes grafisches Interface für das Anzeigen und Erkennen von kritischen Alarmsituationen innerhalb der Oracle-Datenbank. Sie visualisiert kritische Problembereiche und Incidents über den Enterprise Manager. Mithilfe der Support-Workbench können kritische Fehlersituationen erforscht, berichtet und in einigen Fällen sogar sofort behoben werden. Folgende Schritte sind hierzu notwendig:
Über die Enterprise-Manager-Datenbank-Homepage kritische Fehlermeldungen durch Selektion im Detail anzeigen
Problemdetails und zugehörige Incidents (Störfälle) untersuchen, die bei diesen speziellen Problemfällen aufgetreten sind
Optional zusätzliche Health Checks ausführen oder auch den SQL-Test-Case-Builder aufrufen. Dieser sammelt alle nötigen Daten zu einem bestehenden SQL-Problem ein und packt sie zusammen
Anschließend einen Service Request über das Incident-Packaging-System erstellen. Die gepackten Informationen können optional über den Enterprise Manager direkt an Oracle Support weitergegeben werden
Für einen so erstellten Service Request wird ein Aktivitätslog in der Datenbank gepflegt 477
9 Troubleshooting
Abbildung 9.8 Anzeige der kritischen Oracle-Fehlermeldung ORA-00600 über die Datenbank-Homepage des Enterprise Managers 11g
Ausgehend von der Support-Workbench-Startseite kann direkt auf die zugehörige Problem-Detailseite navigiert werden (siehe Abbildung 9.9).
Abbildung 9.9 Detailansicht eines protokollierten ORA-600-Fehlers über den Enterprise Manager 11g
In unserem Beispiel ist der ORA-600-Fehler mit dem Argument [kck_rls_check must use (11,0,0,0,0) or lower] nur einmal am 10. Mai 2011 um 17:59 Uhr aufgetreten. Über weitere Links kann direkt in das damals erstellte Tracefile navigiert werden. Entsprechende Alert.Log-Einträge vom 10. Mai 2011 sind ebenfalls einsehbar. Alle zugehörigen Traceund Logfiles zu diesem ORA-600-Fehler können zentral über das Automatic Diagnostic Repository bereitgestellt, verwaltet, ergänzt und für die Kommunikation mit dem Oracle
478
9.5 Support Workbench Support genutzt werden. Die hier beschriebene Support-Workbench-Funktionalität wird auch Incident Packaging Service (IPS) genannt. Sie extrahiert die gesammelten Diagnoseund Testdaten aus dem Automatic Diagnostic Repository. Alle Daten werden für einen Upload an Oracle Support paketiert. Der Anwender kann zwischen zwei möglichen Paketierungsoptionen wählen:
Vollautomatisiertes Paketieren aller zugehörigen Trace- und Log-Dateien (Quick Packaging). Das so geschnürte Paket lässt sich später jederzeit anpassen.
Selbstdefiniertes Paketieren von Trace- und Log-Dateien (Custom Packaging). Es lassen sich beliebige Dateien und Prüfergebnisse auswählen. Das Hochladen eines erstellten Pakets über den Enterprise Manager ist optional. Natürlich können Sie auch über den Incident Packaging Service erstellte Pakete manuell an Oracle Support weiterleitet. Alle Incidents der folgenden Oracle Fehlermeldungskategorien sind automatisch über die IPS-Funktionalität protokolliert:
ORA-00600: Interner Fehler, generiert über den generischen Kernel-Code der RDBMSServer-Software. Diese internen Fehler sind mit Zusatzargumenten zur genaueren Fehlerbestimmung versehen.
ORA-07445: Interner Fehler, hervorgerufen durch eine Betriebssystem-Fehlermeldung, die wiederum ein Core Dumpfile erstellt. Diese Fehlermeldungen sind zur genauerer Fehlerbestimmung mit Zusatzargumenten versehen.
ORA-4031: keine Allokierung von zusätzlichem Speicherplatz (Angabe in Bytes) mehr möglich. Die Incident Packaging Configuration (siehe Abbildung 9.10) beinhaltet konfigurierbare Aufbewahrungsfristen für alle Incidents und deren zugehörige Trace- und Logdateien. Diese werden über die Support Workbench, Menüpunkt „Incident Packaging Configuration“ verwaltet.
Abbildung 9.10 Support Workbench Menü Incident Packaging Configuration
479
9 Troubleshooting Folgende Parameter können zentral konfiguriert werden:
Incident Metadata Retention Period: Metadaten sind Informationen über die eigentlichen Daten. Bei Incidents beinhalten diese den Incident-Zeitstempel, die ID, die Größe und die Problemnummer. Als Daten werden die eigentlichen Inhalte eines Incidents (z.B. Inhalte eines Tracefiles) bezeichnet.
Cuttoff Age for Incident Inclusion: Dieser Wert beinhaltet die Zeitspanne aller Incidents, die für das Paketieren vorgehalten werden. Der Standardwert beträgt hier 90 Tage. Das bedeutet, alle Incidents der letzten 90 Tage werden vorgehalten.
Leading Incidents Count und Trailing Incidents Count: Für jedes Problem, das aus gleichartigen Incidents besteht, bestimmt das System eine bestimmte Anzahl führender Incidents sowie abschließende Incidents. Zum Beispiel besteht ein ORA-00600Problem aus insgesamt vierzig ORA-00600-Incidents mit gleichen Zusatzargumenten. Der Parameter „Leading Incident Count“ ist mit fünf und der „Trailing Incident Count“ ist mit drei konfiguriert. Dies bedeutet, dass für dieses Problem nur die fünf führenden Incidents und die drei abschließenden Incidents protokolliert sind.
Correlation Time Proximity: Dieser Parameter definiert das Zeitintervall von möglichen korrelierenden Incidents oder Problemen. Standardmäßig ist dieser Parameter auf 90 Minuten eingestellt. Dies bedeutet, alle Incidents und Probleme innerhalb von 90 Minuten können Abhängigkeiten voneinander aufweisen. Praxistipp Die Support Workbench ist der richtige Schritt zur einfachen und effizienten Fehlererkennung und Fehlerbearbeitung über den Enterprise Manager. Das ADRCI-Utility dient hier in eingeschränktem Maße als Kommandozeilen-Interface. Der angebotene Funktionsumfang ist sehr mächtig, auch wenn nicht jeder Datenbank-Administrator von seinen Datenbankservern aus direkten Zugriff auf My Oracle Support hat. Trotzdem lohnt es sich, die Vorteile der grafisch unterstützten Fehlerbearbeitung zu nutzen.
9.6
My Oracle Support ORA-600/ORA-7445 Lookup-Tool Wie wir bereits im vorigen Abschnitt gezeigt haben, sind die ORA-600- und ORA-7445Fehlermeldungen intern generierte RDBMS-Kernelfehlermeldungen versehen mit einer Vielzahl von möglichen Zusatzargumenten. Vor Einführung des früheren Metalink-Support-Tools gab es keinen elektronischen Support durch Oracle. Die Wissensdatenbank war ausschließlich intern für Oracle-Mitarbeiter zugänglich und Dateien wurden nicht über E-Mail oder Fax versendet. Es wurde damals nicht davon ausgegangen, dass ORA-600- oder ORA-7445-Fehler jemals außerhalb der Oracle-Organisation lesbar oder gar diagnostizierbar sein würden. In der darauffolgenden Metalink-Support-Tool-Version gab es nach und nach ReferenzNotes – meist mit dem Label „INTERNAL“ versehen – sowie Bug-Einträge und SupportArtikel. Das aufkommende elektronische Publizieren von Informationen bedeutete einen
480
9.6 My Oracle Support ORA-600/ORA-7445 Lookup-Tool Vorteil für Kunden und ein Bewusstsein der Anwender über die Vielzahl der möglichen internen Fehlermeldungen. Jedoch bekamen die Kunden keine zusätzlichen Analysetools zur Verfügung gestellt. Während der Umwandlungsphase von Oracle Metalink zu My Oracle Support existierten bereits über 4000 öffentliche Notes zu den ORA-600- und ORA-7445-Fehlermeldungen. Sogenannte „BUGTAG1-Notes“ wurden eingeführt und das Lookup-Tool wurde ins Leben gerufen. Über die Artikel-ID 153788.1 ist das Lookup-Tool seither in My Oracle Support aufrufbar. In der bisher letzten Evolutionsstufe wurde in My Oracle Support ein neues ORA600/7445-Lookup-Tool eingeführt (siehe Abbildung 9.10). Im Wesentlichen sind hier weitere umfangreiche Funktionserweiterungen implementiert:
Leichterer Zugriff auf Referenz und BUGTAG-Informationen Die BUGTAG-Informationen sind nun dynamisch an die Referenz Notes angehängt Möglichkeit, nach 600/7445-Argumenten zu suchen Möglichkeit, nach einer vollständigen Fehlermeldung in einem Tracefile zu suchen Möglichkeit, über Stack-Traces zu suchen
Abbildung 9.11 Einstiegsseite MOS Note 153788.1 ORA-600/ORA-7445-Lookup-Tool
Beim Auftreten eines ORA-600- oder ORA-7445-Fehlers gibt es immer folgende Aktionen: 1
Eindeutige Bug-Kennung
481
9 Troubleshooting
Schreiben einer Meldung in die Alert.log-Datei Schreiben einer Trace-Datei In manchen Fällen Ausgeben von Fehlermeldungen über die Benutzeroberfläche oder den Applikationslog Wie bereits erwähnt, liegt die Alert.log-Datei ab der Oracle Version 11g im Automatic Diagnostic Repository. Die zugehörige Incident-Datei ist die interessante Datei für die Analyse solcher Fehlermeldungen.
9.6.1
Best-Practice-Guideline für das ORA-600/7445-Lookup-Tool
Im Fehlerfall bietet sich die folgende Vorgehensweise an:
Kopieren Sie die Fehlermeldung aus dem zugehörigen Trace-File in das ORA-600/7445Lookup-Tool
Achten Sie darauf, dass der Radio-Button auf die korrekte Fehlerart (ORA-600 oder ORA-7445) gesetzt ist
Die Datenbank-Version sollte korrekt eingestellt sein Lesen Sie den BUGTAG-Artikel zur Verifizierung der darin aufgeführten Symptome Parallel dazu sollten Sie eine Suche über den Menüpunkt „General Search for Knowledge“ durchführen. Bitte achten Sie wieder darauf, dass das Kopieren und Einfügen der Fehlermeldung aus dem Tracefile korrekt ist. Sollte ein Bug-Eintrag existieren, benutzen Sie die MOS-Schlüsselwort-Suche, um nach weiteren zutreffenden Fehlerdokumenten zu suchen.
Abbildung 9.12 ORA-600-Suche nach dem Argument [kck_rls_check must use (11,0,0,0,0) or lower]
Die tiefere Analyse zeigt, dass es sich bei diesem aufgetretenen ORA-600-Fehler wohl um einen Bug handelt. Dieser Bug ist ab dem Oracle 11.2.0.2 Patchset gefixt (siehe Abbildung 9.13).
482
9.6 My Oracle Support ORA-600/ORA-7445 Lookup-Tool
Abbildung 9.13 Das Ergebnis der Recherche zum Bug 8773765
Wenn Sie einen Bug gefunden haben, sind als nächstes folgende Schritte zu tun:
Sollte ein Hinweis auf einen Workaround vorhanden sein, dann prüfen Sie, ob dieser in Ihrer Umgebung realisierbar ist.
Prüfen Sie, ob ein One-Off-Fix verfügbar ist. Prüfen Sie, ob ein höheres oder neueres Patchset einspielbar ist. Überlegen Sie, Ihre Datenbanksoftware auf einen aktuellen Stand zu bringen. Die Wahl des geeigneten Schritts hängt stark von einer möglichen Beeinträchtigung ihres Datenbankbetriebs ab. Falls Sie über das Lookup-Tool keinen passenden Bug-Eintrag finden, gibt es folgende Möglichkeiten:
Es existiert kein Bug-Eintrag, weil es hierfür keine Referenz-Note gibt. Es existiert kein Bug-Eintrag, da keine Referenz-Note eine passende Information beinhaltet.
Es existiert kein Bug-Eintrag aufgrund der Komplexität des Problems (zum Beispiel mehrere gleichzeitig auftretende Probleme führen zu dieser Fehlersituation). Praxistipp Das Lookup-Tool kann oft einen Lösungsweg anbieten, im Zweifel steht immer noch die Unterstützung des Oracle Supports zur Verfügung. Nutzen Sie dieses Angebot.
483
9 Troubleshooting
9.6.2
Bereitstellung der richtigen Informationen für den Support
Involvieren Sie auf jeden Fall den Support, wenn Sie auf folgende Probleme stoßen:
Sie sind nicht in der Lage, ein bereits bekanntes Problem zu finden. Sie wollen ihre Diagnose-Ergebnisse bestätigt haben. Sie benötigen einen neuen Patch, den es bisher noch nicht gibt. Die Minimum-Anforderungen für einen Service Request bezüglich der ORA-600/ORA7445-Fehlermeldungen sind:
Die Alert.log-Datei steht wenigstens ab dem Startup der Datenbank vor dem Eintreten der Fehlermeldung zur Verfügung. Bei RAC-Datenbanken sind die Alert.log-Dateien aller Knoten hilfreich.
Die zugehörige Trace-Datei muss zur Verfügung stehen. Bei mehreren Trace-Dateien genügt für eine erste Analyse die erste Trace-Datei.
Oft wird eine aktuelle Remote Diagnostic Analyse (RDA ) verlangt. Hierzu liefert der My-Oracle-Support-Artikel 314422.1 detaillierte Informationen.
Ab Oracle 11g R1: Leiten Sie das zugehörige Incident Package an den Oracle Support weiter (siehe My-Oracle-Support-Artikel 738732.1). Sollte es sich um ein neues Problem handeln, wird Oracle Support gegebenenfalls nach einem sogenannten „Testcase“ verlangen. Dieser dient einer Reproduktion des Problems und dient dem Oracle Development zur schnellen Diagnose und Lösung. Hierfür wird entweder das PL/SQL Package DBMS_SQLDIAG (siehe My-Oracle-Support-Artikel 727863.1) oder der im ADRCI integrierte SQL-Testcase-Builder des ADRCI-Utilities (siehe My-Oracle-Support-Artikel 1174105.1) verwendet. Betrifft Ihr gemeldetes Problem das Data Dictionary, ist unter Umständen eine Kopie folgender Tablespaces erforderlich:
SYSTEM UNDO SYSAUX Eventuell die Redo-Log-Dateien Gegebenenfalls ist noch ein zusätzliches Tracing nötig oder das Einspielen eines Diagnose-Patches. Die nötigen Aktionen werden aber von Fall zu Fall zwischen den OracleSupport-Mitarbeitern und dem Kunden abgestimmt. Praxistipp My Oracle Support bietet eine Fülle von nützlichen Tools und Informationsquellen. Nutzen Sie diese! Bei schwerwiegenden Oracle-Fehlermeldungen ist immer der Oracle Support zu kontaktieren. Dort bekommen Sie technisch fundierte Beratung und Lösungen zur Verfügung gestellt.
484
9.7 Resümee
9.7
Resümee Mit Oracle 11g sind zahlreiche neue Funktionalitäten eingeführt worden wie das Automatic Diagnostic Repository, das Health Monitoring, der Data Recovery Advisor sowie die Support Workbench inklusive dem Incident Packaging Service. Insbesondere im Zusammenspiel mit dem Enterprise Manager erleichtern sie bei schwerwiegenden Fehlern das Datenbank-Troubleshooting enorm. Aber auch die klassischen Informationsquellen wie die Alert.log-Datei, die Nutzung des My-Oracle-Support-Portals im Allgemeinen oder das ORA-600/ORA-7445-Lookup-Tool im Speziellen haben längst noch nicht ausgedient. Nutzen Sie alle verfügbaren Informationsquellen, wenn es darauf ankommt. Bei schwerwiegenden Fehlern ist das Eröffnen eines Service Requests allerdings nach wie vor unumgänglich. Die richtige Kombination der verfügbaren Tools und Utilities führen hier zum Erfolg.
485
9 Troubleshooting
486
10 10 Jobsteuerung In diesem Kapitel zeigen wir Ihnen:
die alten Jobs innerhalb der Datenbank (dbms_job); den neuen Scheduler innerhalb der Datenbank (dbms_scheduler); die Jobverwaltung des Enterprise Managers Grid Control; die Jobverwaltung von Database Control; ein eigenes Produkt mit dem Namen Oracle Workflow. Daneben gibt es natürlich noch weitere Möglichkeiten wie die in das Betriebsystem eingebauten Befehle (cron, at) oder externe Produkte wie UC4 und Cronacle. Wir konzentrieren uns hier auf die in die Datenbank eingebauten Möglichkeiten – und behandeln deshalb nur sehr kurz die Oracle Jobs (dbms_job) sowie ausführlich den Oracle Scheduler (dbms_scheduler).
10.1
Oracle Jobs (dbms_job) Oracle Jobs ist die erste und schon seit langer Zeit in Oracle vorhandene Jobsteuerung. Einen Job startet man z.B. so: DECLARE vJobNo number; BEGIN dbms_job.submit( job => vJobNo, what => 'BEGIN statspack.snap(); END;', next_date => SYSDATE, interval => 'SYSDATE + 1/24'); COMMIT; dbms_output.put_line('Jobno: '||to_char(vJobNo)); END; /
Etwas schwierig ist dabei die Definition des Intervalls (Parameter interval), hier ist ein Datumsausdruck als Zeichenkette zu übergeben. Im gezeigten Beispiel soll der Job jede
487
10 Jobsteuerung Stunde laufen (SYSDATE ist die aktuelle Zeit und dazu wird eine Stunde – also 1/24 Tag – addiert). Praxistipp Denken Sie dran, das Erstellen eines Jobs mit dem Befehl COMMIT abzuschließen, ansonsten startet der Job nicht.
Um einfache PL/SQL-Programme zu automatisieren, reicht dbms_job aus. Oracle hat sich dennoch entschieden, mit der Version 10g ein vollkommen neues Konzept zu bauen. Das liegt daran, dass es diverse Punkte gibt, die bei dbms_job fehlen, unter anderem:
Jobabhängigkeiten Job B darf nur starten, wenn Job A fertig ist Job B darf gleichzeitig mit Job C, aber nicht mit Job A laufen Flexiblere Verwaltung des Intervalls Zeitfenster (Job darf nur von … bis … laufen) Ressourcenverwaltung und Prioritätenverwaltung der Jobs Benachrichtigung des Verantwortlichen Einfacher Start von externen Programmen Reaktion auf externe Ereignisse (z.B. neue Dateien)
10.2
Oracle Scheduler (dbms_scheduler) dbms_scheduler ist ein PL/SQL-Package und bietet alle Möglichkeiten für die Erstellung,
Manipulation und das Löschen von Jobs und weiteren Komponenten der Jobverwaltung (dazu später mehr). Als PL/SQL-API kann es natürlich in eigene Programme und SQLSkripte eingebunden werden – aber es gibt mit dem Enterprise Manager ein Werkzeug zur grafischen Verwaltung der Jobs, wobei Enterprise Manager Grid Control zwei Varianten von Jobs bietet: Einmal den Datenbank Scheduler, von dem wir hier reden. Dieser ist erreichbar über Targets / Database. Außerdem gibt es noch die Grid-Control-Jobs, die im rechten oberen Reiter unter „Jobs“ zu finden sind.
10.2.1 Einfache Jobs (PL/SQL) Ein Beispiel: BEGIN sys.dbms_scheduler.create_job( job_name => 'FILL_DEPT_SAL_TABLE', job_type => 'PLSQL_BLOCK', job_action => ' BEGIN DELETE dept_sal;
488
10.2 Oracle Scheduler (dbms_scheduler) INSERT INTO dept_sal SELECT deptno, sum(sal), sysdate FROM emp GROUP BY deptno; COMMIT; END;', start_date => systimestamp, enabled => TRUE); END; /
Damit wird ein Job mit dem Namen FILL_DEPT_SAL_TABLE angelegt. Dieser füllt eine Tabelle mit gruppierten Daten aus der Tabelle EMP durch einen kleinen PL/SQL-Block. Er startet sofort (siehe Parameter start_date) und läuft nur einmal ab. Das ist noch nicht ganz die typische Variante. Im Normalfall will man ja Tätigkeiten automatisieren und Jobs wiederholt ausführen. Dazu ergänzen wir obigen Aufruf um den Parameter repeat_interval: repeat_interval => 'FREQ=MINUTELY;INTERVAL=10'
Jetzt startet der Job alle 10 Minuten neu. Dieser Parameter ist sehr mächtig. Es können dadurch unter anderem Jobs nur an bestimmten Tagen und zu bestimmten Uhrzeiten wiederholt werden: repeat_interval => 'FREQ=MINUTELY;INTERVAL=10;BYDAY=SAT,SUN;BYHOUR=20,21,22',
Der Job wird jetzt zwar alle 10 Minuten wiederholt, aber nur am Samstag und Sonntag zwischen 20:00 und 22:59 Uhr. Die Wiederholungsintervalle lassen sich im Enterprise Manager recht komfortabel einstellen (siehe Abbildung 10.1):
Abbildung 10.1 Einstellen der Intervalle im EM Grid Control
Praxistipp Häufig will man einen Job am letzten Tag des Monats starten. Dies ist aber nicht immer der 31. Dafür gibt es die Möglichkeit, den Parameter BYMONTHDAY auf „-1“ zu setzen (also 1 Tag weniger als der Monatsanfang): repeat_interval => 'FREQ=MONTHLY;INTERVAL=10;BYMONTHDAY=-1;BYHOUR=22;BYMINUTE=0',
489
10 Jobsteuerung
10.2.2 Einfache Jobs (extern) Der Oracle Scheduler startet Programme außerhalb der Datenbank, um beispielsweise den Inhalt eines Verzeichnisses auszulesen. Vor dem Start sollte man sich überlegen, mit welchen Betriebsystemberechtigungen dieser Job laufen soll. Standardmäßig hat hier Oracle den Benutzer nobody und die Gruppe nobody eingestellt. Die Definition hat Oracle in die Datei .$ORACLE_HOME/rdbms/admin/externaljob.ora ausgelagert1: ... run_user = nobody run_group = nobody
Diese zwei Zeilen könnten nun auf die gewünschten Werte geändert werden. Dies ist aber nicht zu empfehlen, da dann alle Jobs von allen Datenbanken dieses ORACLE_HOMEs mit den gleichen Berechtigungen laufen. Die bessere (feiner granulare) Art ist die Definition von Credentials2: BEGIN DBMS_SCHEDULER.CREATE_CREDENTIAL( credential_name => 'JOB_USER', username => 'job', password => 'very_secret_password'); END; /
Diese gehören dem anlegenden Benutzer. Sie können damit nur von ihm und von Benutzern, denen Rechte darauf erteilt werden, bearbeitet werden. Definieren wir wieder einen Job. Beachten Sie dabei, dass Sie nicht von einer gesetzten Umgebung ausgehen können, Sie müssen also alle Programme mit vollständigem Pfad angeben (und innerhalb Ihrer Scripts selbstständig dafür sorgen, dass die Umgebung gesetzt wird): BEGIN sys.dbms_scheduler.create_job( job_name => 'RUN_OS_CMD', job_type => 'EXECUTABLE', job_action => '/bin/ls', start_date => systimestamp, number_of_arguments => 1, enabled => FALSE); END; /
Neu ist nun:
Der Jobtyp ist EXECUTABLE (im Gegensatz zu PLSQL_BLOCK im ersten Beispiel) Wir haben einen neuen Parameter number_of_arguments, weil dem Programm ein Parameter übergeben werden soll (das Verzeichnis, welches der ls-Befehl ausgeben soll). Dies ist wichtig, da in job_action wirklich nur das Programm ohne Parameter
1
In älteren Oracle Versionen (bis 10.2.0.2) wurde dies über den Owner der Datei ?/bin/extjob gesteuert 2 Wenn man das Passwort auf Betriebssystemebene ändert, muss das Passwort auch hier geändert werden!
490
10.2 Oracle Scheduler (dbms_scheduler) stehen darf. Ansonsten würde es eine Fehlermeldung geben, da Oracle eine Datei sucht, die genau so heißt.
Der Job wird noch nicht aktiviert (sonst würde er ja sofort starten) bis wir den Parameter und die Credentials setzen Im zweiten Schritt definieren wir, mit welchen Credentials dieser Job laufen soll: BEGIN dbms_scheduler.set_attribute( name => 'RUN_OS_CMD', attribute => 'credential_name', value => 'JOB_USER' ); END; /
Im letzten Schritt definieren wir den (ersten und einzigen) Parameter und aktivieren auch sofort den Job: BEGIN sys.dbms_scheduler.set_job_argument_value( job_name => 'RUN_OS_CMD', argument_position => 1, argument_value => '/u00/app/oracle/product/'); sys.dbms_scheduler.enable('RUN_OS_CMD'); END; /
Ob der Job gelaufen ist, können wir über die View user_scheduler_job_run_details kontrollieren: SELECT log_id, status, actual_start_date FROM user_scheduler_job_run_details WHERE job_name='RUN_OS_CMD' ORDER BY log_id DESC; LOG_ID STATUS ACTUAL_START_DATE ------ --------- -----------------------------------557 SUCCEEDED 08-APR-11 09.56.10.753662 PM +02:00
Diese View hat noch viele weitere Felder, unter anderem ist auch eine eventuelle Fehlermeldung im Feld ADDITIONAL_INFO erkennbar. Der Job ist gelaufen, das ls wurde durchgeführt. Aber wo sind nun die ausgegebenen Zeilen? Im Beispiel ist die Ausgabe nicht umgeleitet, das heißt, die Ergebnisse wurden auf Standard-Output ausgegeben3. Diese Daten speichert Oracle im Verzeichnis $ORACLE_ HOME/scheduler/log ab. Leider ist die Namensgebung der Dateien nicht ganz so leicht – z.B. über die LOG_ID – ersichtlich. Die Datei für den Beispieljob heißt job_14163_ 556_stdout. Dieser Name ist nur durch das Feld ADDITIONAL_INFO verfügbar, muss aber dann noch durch einen regulären Ausdruck extrahiert werden: SELECT additional_info FROM user_scheduler_job_run_details WHERE log_id=557; ADDITIONAL_INFO
3
Natürlich wäre hier eine Ausgabe-Umleitung in eine Datei möglich – und wird auch oft verwendet. Aber dann muss diese Datei manuell eingelesen werden. Oracle hat dies aber schon eingebaut. Deshalb erscheint es dem Autor besser, den Oracle-Mechanismus zu benutzen.
491
10 Jobsteuerung --------------------------------------------EXTERNAL_LOG_ID="job_14163_556", USERNAME="job" SELECT regexp_substr(additional_info,'job[_0-9]*') FROM user_scheduler_job_run_details WHERE log_id=557; REGEXP_SUBSTR(ADDITIONAL_INFO,'JOB[_0-9]*') --------------------------------------------job_14163_556
Dieser Aufwand lohnt sich aber. Denn nun bietet Oracle eine einfache Möglichkeit, die ausgegebenen Daten innerhalb Oracle zu lesen: DECLARE vLob clob; vLog_id varchar2(50) := 'job_14163_556'; BEGIN dbms_lob.createtemporary(vLob, false); dbms_scheduler.get_file( source_file => vLog_id ||'_stdout', credential_name => 'JOB_USER', file_contents => vLob, source_host => null); dbms_output.put_line(vLob); end; / 11.1.0 11.2.2
Die beiden letzten Zeilen sind die gefundenen Verzeichnisse des ls-Befehls.
10.2.3 Jobs und Wiederverwendbarkeit Bis jetzt haben wir einen Job direkt definiert. Besser wäre es aber, diesen zu modularisieren, um den auszuführenden Code von der Zeitsteuerung zu trennen. Ziel ist, den Job zentral zu verwalten und einfach wiederzuverwenden. Es existieren dafür folgende Komponenten (siehe Abbildung 10.2).
Abbildung 10.2 Hauptkomponenten eines Jobs
Ein Program(-Objekt) definiert die Metadaten darüber, „was“ laufen soll, ist also nicht zu verwechseln etwa mit einem PL/SQL-Programm. So lassen sich vordefinierte Programme (Libraries) erzeugen, denen dann einfach eine Ausführungszeit zugeordnet wird. Eine Program-Definition hat folgenden Inhalt:
(interner) Programmname Typ der Programms
492
10.2 Oracle Scheduler (dbms_scheduler)
PL/SQL (Stored Procedure) Anonymer PL/SQL-Block Externes Programm (C, Shell-Script, Windows-Batch-Script über cmd.exe …) Aufzurufender Programmname Standardparameter, diese können beim Starten überschrieben werden Ein Schedule definiert die Metadaten darüber, „wann“ ein Job laufen soll. Eine Schedule-Definition hat folgenden Inhalt:
Erste Startzeit Wiederholungen (Intervall: Minuten, Stunden, Tage, Woche, Monate, Jahre) Ende der Wiederholungen Ein Beispiel: BEGIN sys.dbms_scheduler.create_schedule( repeat_interval => 'FREQ=MONTHLY;BYHOUR=21;BYMINUTE=5;BYSECOND=0', start_date => systimestamp at time zone '+1:00', end_date => to_timestamp_tz('2011-02-29 +1:00', 'YYYY-MM-DD TZH:TZM'), comments => 'Definition for daily cleanup jobs (only on weekdays)', schedule_name => 'DAILY_CLEANUP'); END;
Der Job kombiniert nun das Program und den Schedule zu einer lauffähigen Instanz. Außer Program, Schedule und Job gibt es noch weitere, optionale Komponenten (siehe Abbildung 10.3).
Abbildung 10.3 Weitere Jobkomponenten
Job Classes sind Gruppierungen von Jobs, welche folgende Eigenschaften festlegen:
Resource consumer group (um Ressourcen zu limitieren) Service (um in einer RAC-Umgebung zu definieren, auf welchen Nodes Jobs laufen dürfen)
493
10 Jobsteuerung
Logging Level (um festzulegen, wie viele Informationen protokolliert werden, von keine über nur fehlerhafte bis zu allen Infos)
Log History (um festzulegen, wie lange die Log-Daten aufgehoben werden sollen) Windows definieren neben dem Schedule (Startzeit) auch eine maximale Laufzeit und die Job-Priorität (hier gibt es aber nur HIGH und LOW). Ist die Zeit abgelaufen, bekommt der Job eine Fehlermeldung („ORA-01013: user requested cancel of current operation") und sollte entsprechend darauf reagieren. Window Groups sind die Zusammenfassung mehrerer Windows. Beispielsweise könnten ressourcenintensive Tasks am zeitigen Morgen und am späten Abend durchgeführt werden. Dann definiert man zwei Windows und fasst diese zu einer Window Group zusammen. Im Job wird dann die Window Group (anstatt Schedule oder Window) definiert. Benutzerdefinierte Kalender sind eine weitere Möglichkeit der flexiblen Zeitplanung. Zum Beispiel könnte man ein Schedule definieren, das die drei Wochen Betriebsferien im Sommer enthält: BEGIN sys.dbms_scheduler.create_schedule( repeat_interval => 'FREQ=WEEKLY;BYDAY=MON,TUE,WED,THU,FRI', start_date => to_timestamp_tz('2011-08-01 Europe/Berlin','YYYY-MM-DD TZR'), end_date => to_timestamp_tz('2011-08-21 Europe/Berlin','YYYY-MM-DD TZR'), comments => 'company holidays in august (3 weeks)', schedule_name => 'COMPANY_HOLIDAYS'); END; /
Mithilfe dieses Schedules lässt sich jetzt ein weiteres definieren (Schachtelung von Schedules). Darin soll ein Job jeden Freitag laufen – außer in den Betriebsferien: BEGIN sys.dbms_scheduler.create_schedule( repeat_interval => 'FREQ=YEARLY;BYDAY=FRI;BYHOUR=12;EXCLUDE=COMPANY_HOLIDAYS', start_date => to_timestamp_tz('2011-04-11 +2:00', 'YYYY-MM-DD TZH:TZM'), schedule_name => 'WEEKLY_JOB'); END; /
10.2.4 Jobketten Unter Jobketten stellt man sich die grafische Darstellung und das Bearbeiten von Abhängigkeiten vor, etwa in der Art wie in Abbildung 10.4. Leider trifft dies (noch) nicht ganz zu, denn alle Abhängigkeiten können zwar sehr gut definiert werden – aber nicht grafisch. Dadurch wird der Überblick bei größeren Ketten etwas schwierig. Da man Jobketten aber schachteln kann, ist durch sinnvolle Modularisierung eventuell doch eine gewisse Übersichtlichkeit erreichbar. Immerhin ist die Anzeige der Abhängigkeiten inzwischen grafisch möglich. Zuerst einmal muss die Jobkette (die Hülle für die einzelnen Schritte) angelegt werden:
Jetzt werden die Jobschritte definiert: BEGIN sys.dbms_scheduler.define_chain_step (chain_name => '"SYSTEM"."ETL_CHAIN_1"', step_name => 'STEP1', program_name => 'SYSTEM.PROGRAM_1'); END; /
In einer Jobkette mit dem Namen ETL_CHAIN_1 ist ein Schritt STEP1 definiert, der das Programm PROGRAM_1 ausgeführt. Dieser Step hängt nun zuerst einmal allein in der Luft, er wird auch nie ausgeführt. Erst Regeln definieren die Reihenfolge und Abhängigkeiten von Steps. Wichtig dabei ist, dass zumindest ein Step eine Regel bekommt, die immer auf „wahr“ ausgewertet wird, um dadurch den Anfangsschritt zu definieren: BEGIN SYS.dbms_scheduler.define_chain_rule (chain_name => '"SYSTEM"."ETL_CHAIN_1"' , condition => '1=1' , rule_name => 'R1_Start_Step1' , comments => 'Start Step1 (first step, starts job chain)' , action => 'START "STEP1"'); END; /
Sie sehen hier als condition den Wert 1=1 – also wahr –, deshalb wird dieser Step gestartet (Parameter action), sobald die Jobkette startet. Weitere Steps werden dann typischerweise beim Beenden des Vorgängers gestartet: BEGIN SYS.dbms_scheduler.define_chain_rule (chain_name => '"SYSTEM"."ETL_CHAIN_1"' , condition => 'step1 COMPLETED' , rule_name => 'R2_Start_Step2' , comments => 'Start Step2 (after Step1)'
495
10 Jobsteuerung , action
=> 'START "STEP2"');
END; /
Im Parameter condition steht hier der Ausdruck step1 completed, d.h. egal, wie Step 1 beendet wurde, Step 2 läuft los. Hier könnte auch auf failed oder succeeded getestet werden. Außerdem ist es an dieser Stelle möglich, beliebige logische Bedingungen zu testen, z.B. einen Folgestep nur zu starten, wenn der Vorgänger kürzer als 30 Minuten lief: condition => ':step1.duration < interval ''30'' minute'
Im Parameter action kann neben Anweisungen zum Start eines Steps auch der Befehl stehen, einen laufenden Step zu beenden ('STOP step1') oder auch die gesamte Jobkette zu beenden ('END [errorcode]')4. Abbildung 10.5 zeigt eine mögliche Definition im Enterprise Manager.
Abbildung 10.5 Beispiel einer Jobkette im Grid Control
Nur der Internet Explorer mit installiertem Adobe SVG Plugin zeigt dies auch grafisch an (siehe Abbildung 10.6).
Abbildung 10.6 Grafische Anzeige einer Jobkette
4
496
Wichtig ist, dass die Jobkette durch END beendet wird. Ansonsten bleibt sie im Status CHAIN_STALLED und wartet auf weitere (wahrscheinlich nicht eintretende) Bedingungen
10.2 Oracle Scheduler (dbms_scheduler)
10.2.5 Wartungsfenster (Automatic Maintenance Tasks) Ein Spezialfall innerhalb der Jobsteuerung sind die „Automatic Maintenance Tasks“ – von Oracle vordefinierte tägliche Wartungsaufgaben. Im Moment gibt es drei Tasks:
Automatic Optimizer Statistics Collection Automatic Segment Advisor Automatic SQL Tuning Advisor Alle drei laufen in der Window Group DEFAULT_MAINTENANCE_PLAN, die aus den Windows MONDAY_WINDOW bis SUNDAY_WINDOW besteht. Sollten Sie also z.B. mit der Uhrzeit der täglichen automatischen Statistikerstellung nicht zufrieden sein, können Sie die Zeiten über die Windows anpassen. Ebenso könnten Sie weitere Windows in dieser Gruppe erstellen, etwa wenn Sie am frühen Morgen noch freie Ressourcen haben. Dies ist offiziell erlaubt (obwohl dies Data Dictionary Objekte sind) und auch dokumentiert. Ebenso ist es möglich, einzelne automatische Jobs an Ihre Datenbankauslastung anzupassen und diese an bestimmten Tagen nicht laufen zu lassen. Dazu gibt es ein spezielles Package dbms_auto_task_admin (Der Vorgang sollte nicht mit dbms_scheduler gemacht werden). Diese Konfiguration ist auch im Enterprise Manager möglich (siehe Abbildung 10.7).
Abbildung 10.7 Konfiguration der „Automated Maintenance Tasks“ im Grid Control
497
10 Jobsteuerung
10.2.6 Advanced Features 10.2.6.1
E-Mail Notification
Um Jobs nicht nur über Views oder den Enterprise Manager zu überwachen, hat Oracle die Möglichkeit eingebaut, E-Mails zu verschicken5. Statusveränderungen des Jobs (z.B. Start, Failed, Succeded) lösen diese aus. Bevor E-Mails verschickt werden können, benötigt der Scheduler einen Mailserver: BEGIN dbms_scheduler.set_scheduler_attribute ('email_server', 'localhost:25'); END; /
Hier lässt sich außerdem definieren, ob sich die Datenbank gegenüber dem Mailserver authentifizieren soll und ob die Netzwerkverbindung zum Mailserver per SSL oder TLS verschlüsselt sein soll6. Nun schaltet man pro Job (nach dem Erzeugen und vor dem Starten) die Mailbenachrichtigung ein: BEGIN dbms_scheduler.add_job_email_notification ( job_name => 'FILL_DEPT_SAL_TABLE', recipients=> '[email protected]', sender => '[email protected]', subject => 'Job Notification-%job_owner%.%job_name%-%event_type%', body => '%event_type% occurred at %event_timestamp%. %error_message%', events => 'JOB_RUN_COMPLETED'); END; /
Abbildung 10.8 zeigt eine Nachricht (es wurde bewusst ein Fehler erzeugt).
Abbildung 10.8 Bespiel einer E-Mail, erzeugt durch Job Notification
Der optionale Parameter filter_condition legt Einschränkungen für den Mailversand fest, z.B. dass die Mail nur verschickt werden soll, wenn ein ORA-00600 Fehler aufgetreten ist: :event.error_code=600
5 6
498
Verfügbar ab Oracle Database Version 11.2 Sowohl Authentifizierung als auch Verschlüsselung sind erst ab Oracle Database Version 11.2.0.2 verfügbar
10.2 Oracle Scheduler (dbms_scheduler) 10.2.6.2
Event Scheduling
Jobs können nicht nur zeitbasierend, sondern auch durch Ereignisse gestartet werden. Ereignisse können von Applikationen kommen oder Änderungen im Status eines Jobs sein (STARTED, FAILED, COMPLETED, LIMIT_REACHED …). Als Folge dieser Ereignisse sind sowohl Jobs als auch Schedules möglich. Für Applikationsereignisse kommt Advanced Queuing zum Einsatz. Dabei wird wie folgt vorgegangen:
TYPE anlegen, der die Nutzdaten der Message hält Queue-Table anlegen Queue anlegen und starten Enqueuer und Dequeuer (Job-Owner) berechtigen Job anlegen, Bedingung definieren Im Job (siehe Abbildung 10.9) ist zu sehen, bei welcher Bedingung in welcher Queue er gestartet wird.
Abbildung 10.9 Beispiel eines Jobs mit Event-Scheduling
Die Jobs starten bei Eintreten eines Events zeitnah (typischerweise innerhalb 1 bis 2 Sekunden). Sollen Daten an den Job übergeben werden, muss der Job eine PL/SQL-Prozedur aufrufen, die als Input-Parameter einen Wert vom Typ des AQ-Types übernimmt. 10.2.6.3
File Watcher
Ein Sonderfall von Event-Scheduling ist der „File Watcher“. Hier startet ein Job, wenn eine Datei angelegt wird7. Voraussetzung dafür ist die Installation der Java Virtual Machine innerhalb der Datenbank. Wenn der Scheduler Agent auf einem entfernten System installiert und registriert ist, kann man auch dort das Anlegen von Dateien überwachen.
7
Verfügbar ab Oracle Database Version 11g R2
499
10 Jobsteuerung Beispiel für einen File Watcher: BEGIN dbms_scheduler.create_file_watcher( file_watcher_name => 'ETL_LOAD_WATCHER', directory_path => '/u02/transfer/etl_data', file_name => 'load*.txt', credential_name => 'ETL_WATCHER_CREDENTIAL', destination => NULL); END; /
Überwacht wird hier das Verzeichnis /u02/transfer/etl_data auf Dateien mit dem Namen load*.txt. Dazu sind der Betriebssystembenutzer und dessen Credentials in ETL_WATCHER_CREDENTIAL definiert (der Berechtigungen haben muss, diese Dateien zu lesen). Weitere, optionale Parameter legen fest, wie groß die Datei mindestens sein muss (min_ file_size) und wie lang die Datei sich nicht verändert haben darf (steady_state_ duration), bis der Job startet. Letzteres ist sehr sinnvoll, wenn die Datei nicht auf einmal erstellt wird, sondern die Daten „reintröpfeln“. Der File Watcher benötigt ein Program-Objekt. Dieses übergibt als Argument den Inhalt von event_message an das PL/SQL-Programm (Datentyp SYS.SCHEDULER_FILEWATCHER_RESULT). Darin sind Informationen über die Datei (Name, Größe, ...) enthalten. Der File Watcher und das Program-Objekt werden nun bei der Erstellung des Jobs benutzt: ... PROGRAM_NAME QUEUE_SPEC ...
=> 'ETL_LOAD_PROGRAM', => 'ETL_LOAD_WATCHER',
Standardmäßig überprüft Oracle alle 10 Minuten, ob neue Dateien angekommen sind. Ist das zu langsam, lässt sich dieses Intervall anpassen (hier z.B. auf eine Minute): BEGIN dbms_scheduler.set_attribute( 'FILE_WATCHER_SCHEDULE', 'REPEAT_INTERVAL', 'FREQ=MINUTELY;INTERVAL=1'); END; /
10.2.6.4
Remote Destination Jobs
Ein Remote Job wird durch einen Scheduler Agent ausgeführt (nicht zu verwechseln mit dem Grid Control Agent). Dieser Agent muss zuerst einmal auf dem entfernten Host (in ein eigenes Oracle Home) installiert, konfiguriert und registriert sein. Die Software ist auf der Oracle Client CD8. Befindet sich auf diesem Host keine (lizenzierte) Datenbank, ist der Agent zu lizenzieren („System Monitoring Plug-in for Hosts“). In der steuernden Datenbank müssen folgende Voraussetzungen eingehalten sein:
Installation von XDB 8
500
Vor Oracle Database Version 11g R2 war der Scheduler Agent auf der Oracle Database Gateway CD
10.2 Oracle Scheduler (dbms_scheduler)
Starten des integrierten XDB-Webservers (Port muss vom Remote Host erreichbar sein, eventuell Firewall-Regeln anpassen)
Konfiguration von Shared Server Festlegen eines Passworts für das Registrieren der Agents Das zusätzliche Attribut destination legt beim Anlegen des Jobs fest, auf welchem Host der Job (hier für ein externes Programm) laufen soll: BEGIN dbms_scheduler.set_attribute( name => 'EXTRACT_ETL_DATA', attribute => 'destination', value => 'oltp.trivadis.com:12345'); END; /
Soll kein externes Programm laufen, sondern ein Job innerhalb einer Datenbank9, ist zuerst eine Datenbank-Destination anzulegen: BEGIN DBMS_SCHEDULER.CREATE_DATABASE_DESTINATION ( destination_name => 'OLTP_DB_DESTINATION', agent => 'oltp.trivadis.com ', tns_name => 'OLTP_DATABASE', comments => 'OLTP source database instance'); END; /
Diese Destination ist dann dem Parameter destination beim Anlegen des Jobs zu übergeben. 10.2.6.5
Multiple Destination Jobs
Soll ein Job nicht nur gegen ein (Remote-)Ziel gleichzeitig ausgeführt werden, sind Destination Groups zu definieren: BEGIN dbms_scheduler.create_group( group_name => 'all_production_dbs', group_type => 'DB_DEST', member => 'local, ProdDB1, ProdDB2, ProdDB3'); END; /
Dieses Bespiel fasst eine Gruppe von Datenbank-Destinationen zusammen (local ist die aktuelle Datenbank sowie drei weitere Produktionsdatenbank-Destinationen). Dies ist eine sehr interessante Variante der zentralen Definition für die Automatisierung von vielen Datenbanktätigkeiten. Stellen Sie sich vor, Sie wollen an allen Produktionsdatenbanken Passwörter ändern. Damit ist das leicht möglich! Sind die Gruppen von Datenbanken einmal definiert, kann man sie in beliebigen Jobs benutzen (natürlich nur, wenn der aufrufende Benutzer Rechte auf das Gruppen-Objekt hat). Ebenso wäre eine Gruppe von Hosts möglich, um gegen mehrere Hosts gleichzeitig Befehle auszuführen (z.B. für Platzberechnungen). 9
Verfügbar ab Oracle Database Version 11g R2 und Scheduler Agent Version 11g R2
501
10 Jobsteuerung 10.2.6.6
Lightweight Jobs
Jobs sind normale Datenbankobjekte wie Tabellen. Sollten täglich sehr viele, typischerweise kurze Jobs (mehrere tausend) starten, kann der Overhead bei der Objektgenerierung (Eintrag in mehrere Tabellen) störend sein. Für diesen Fall gibt es die Lightweight Jobs. Sie sind keine Objekte, dadurch entfällt einiges an Datenbankoperationen beim Anlegen, Ablaufen und Beenden dieser Jobart. Es gibt aber auch nicht so viele Möglichkeiten und Parameter, u.a. keine Privilegien. Diese werden von dem zwingend notwendigen Program-Object geerbt. Ein Beispiel: BEGIN dbms_scheduler.create_job ( job_name => 'lightweight_job1', program_name => 'check_program_1', repeat_interval => 'freq=secondly;interval=5', end_date => '12-APR-11 08.00.00 AM Europe/Berlin', job_style => 'LIGHTWEIGHT', comments => 'Job repeats every 5 sec'); END; /
Das Program-Objekt muss schon existieren, aktiviert und vom Typ „PLSQL_BLOCK“ oder „STORED_PROCEDURE“ sein.
10.2.7 Privilegien Tabelle 10.1 Systemprivilegien für Jobs und Jobkomponenten
502
Systemprivileg
Berechtigung
CREATE JOB
Anlegen, Ändern und Löschen von Jobs, Jobketten, Programs, Schedules, Destination, Destination Groups und File Watcher im eigenen Schema
CREATE EXTERNAL JOB
Zum Ausführen von externen Programmen ist zusätzlich noch dieses Privileg erforderlich, um zu steuern, wer auf Betriebsystemebene Zugriff bekommt
CREATE ANY JOB
Anlegen, Ändern und Löschen von Jobs, Jobketten, Programs, Schedules, Destination, Destination Groups und File Watcher in fremden Schemas
EXECUTE ANY PROGRAM
Ausführen von Programmen anderer Schemas in eigenen Programmen
EXECUTE ANY CLASS
Ausführen von Jobs in Job Classes anderer Schema
MANAGE SCHEDULER
Alle vorherigen Privilegien, zusätzlich administrative Privilegien (Löschen von Logs, Setzen von Attributen, Definition von Windows und Window Classes)
10.3 Resümee Die Rolle SCHEDULER_ADMIN beinhaltet alle Systemprivilegien mit ADMIN OPTION. Zusätzlich können andere Benutzer auf Objektebene (Job, Program, ...) Objektprivilegien (EXECUTE, ALTER, ALL) erhalten.
10.3
Resümee Der Oracle Scheduler hat einen höheren Lernaufwand als die alte Jobsteuerung per dbms_job. Da er aber deutlich flexibler ist und wesentlich mehr Möglichkeiten bietet, sollte man unbedingt auf den Scheduler setzen, vor allem, da nicht klar ist, wie lange dbms_job überhaupt noch in der Datenbank verfügbar sein wird. Der Scheduler bietet alle grundlegenden Tätigkeiten, die auch bei anderen, externen Schedulern möglich sind (u.a. remote Jobs, externe Jobs, Jobketten, Benachrichtigungen). In sehr großen Umgebungen wird man trotzdem überlegen, einen externen, zentralen Scheduler zu betreiben, der mehr Komfort bietet. Aber um nur Datenbankjobs und vielleicht ein paar zusätzliche externe und/oder entfernte Jobs durchzuführen, ist der Oracle Scheduler eine ausgezeichnete Wahl. Auch weil er unter der Kontrolle der DBAs bleibt.
503
10 Jobsteuerung
504
11 11 Monitoring In diesem Kapitel zeigen wir Ihnen:
welches die Hauptkomponenten der Oracle 11g Monitoring-Architektur sind; welche Monitoring-Konzepte sich in der Praxis bewährt haben; nach welchen Kriterien eine Monitoring-Lösung ausgewählt werden soll: was man überhaupt überwachen soll und muss; welche Monitoring-Werkzeuge dem DBA zur Verfügung stehen. Wie beim Firmenname „Oracle“ geht auch die Wurzel des Begriffs „Monitoring“ auf das frühe Altertum zurück. Das Wort „Monitor“ stammt vom lateinischen „monere = warnen, mahnen“ ab. Und diese Warnfunktion ist in der Tat eine der wichtigsten Aufgaben des Monitoring. Dass Oracle dieser Warnfunktion eine große Bedeutung beimisst, zeigt sich alleine schon in den umfangreichen Überwachungsmöglichkeiten, deren Zahl von Release zu Release wächst. Mit dem in Oracle 10g eingeführten Metrikkonzept und den daraus abgeleiteten Server Generated Alerts, wurde eine solide konzeptionelle Basis für die Datenbanküberwachung geschaffen. Darauf aufbauend stellt Oracle mit dem Enterprise Manager eine umfangreiche Monitoring- und Managementlösung zur Verfügung. Der Oracle Enterprise Manager liegt in zwei Ausprägungen vor: Während mit EM Database Control lediglich eine Datenbank verwaltet werden kann, dient EM Grid Control als zentrale Management-Infrastruktur für die unternehmensweite Datenbankverwaltung. In diesem Kapitel konzentrieren wir uns auf die Überwachungsmöglichkeiten von EM Database Control 11g R2. Wir gehen in diesem Kapitel auf die grundlegenden Konzepte wie Metriken, Policies und Server Generated Alerts ein und stellen die entsprechenden Werkzeuge für die Verwaltung und Auswertung der Diagnostikdaten vor. Wir beschränken uns dabei nicht nur auf die Produkte von Oracle, sondern zeigen auch Alternativen oder Ergänzungen zum Enterprise Manager auf.
505
11 Monitoring Es stehen zahlreiche Monitoringprodukte von Drittanbietern zur Verfügung. Welche Kriterien bei der Auswahl solcher Produkte beachtet werden sollten, zeigen wir in diesem Kapitel ebenfalls auf. Praxistipp Die in diesem Kapitel vorgestellten Überwachungsmöglichkeiten sind teilweise von der Oracle Software-Edition abhängig. So sind beispielsweise die (lizenzpflichtigen) Enterprise Manager Management Packs (Change Management Pack, Configuration Management Pack, Data Masking Pack, Diagnostic Pack, Provisioning and Patch Automation Pack und das Tuning Pack) nur in der Enterprise Edition verfügbar. Auch der Zugriff via SQL*Plus oder einem anderen API auf Views, die zu einem der oben erwähnten Packs gehören, ist lizenzpflichtig. Mit Oracle 11g R2 wurde zudem der Parameter CONTROL_MANAGEMENT_PACK_ACCESS eingeführt, um das Diagnostic Pack und das Tuning Pack zu deaktivieren, falls diese nicht lizenziert sind.
11.1
Monitoring-Architektur Mit dem Database Release 11g hat Oracle die bisherige Monitoringarchitektur zu einem umfangreichen Fehlerdiagnosesystem erweitert. So wurde beispielsweise für die Verwaltung und Auswertung der Log- und Tracefiles eine Repositorystruktur mit entsprechenden Werkzeugen eingeführt. Das Ziel der erweiterten Architektur ist die schnellere und zuverlässigere Problem- und Fehlererkennung und Behebung, sowie die vereinfachte Zusammenarbeit mit Oracle Support. Die Monitoringarchitektur ist in zwei Hauptbereiche aufgeteilt:
Fault Diagnostic Framework Automatic Diagnostic Repository (ADR) ADRCI Command Line Utility Enterprise Manager Support Workbench Incident Package Service (IPS) SQL Repair Advisor Health Monitor Performance Diagnostic Framework1 Automatic Workload Repository (AWR) Active Session History (ASH) Advisory Framework Automatic Database Diagnostic Monitor (ADDM) Die Komponenten des Fault Diagnostic Framework sind primär für die Problem- und Fehlererkennung im Bereich Datenbankserver, -instanz und Datenbank selber ausgelegt. Das Performance Diagnostic Framework dient der Performanceüberwachung auf Session- und Befehls-Ebene. Im folgenden Abschnitt stellen wir die wichtigsten Komponenten dieser beiden Monitoringbereiche im Detail vor. 1
506
Die Komponenten sind im Oracle Diagnostics Pack (lizenzpflichtig) zusammengefasst
11.1 Monitoring-Architektur
11.1.1
Automatic Diagnostic Repository
Das Automatic Diagnostic Repository (ADR) dient als Dreh- und Angelpunkt für die Diagnose sämtlicher Oracle-Komponenten wie RDBMS, ASM, Listener, Clientsoftware etc. Die Diagnostik-Informationen wie Log- und Tracefiles, Dumps, Corefiles, Incident Packages, Health Monitor Reports, Data Repair Records, SQL Test Cases etc. werden dabei in einem dateibasierten Repository verwaltet. Aufbau und Lokation des ADR wurde bereits in Kapitel 2 „Architektur und Administration“ vorgestellt. Die View V$DIAG_INFO zeigt die aktuelle ADR-Struktur: 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
VALUE --------------------------------------------TRUE /u00/app/oracle /u00/app/oracle/diag/rdbms/ora11g/ORA11G /u00/app/oracle/diag/rdbms/ora11g/ORA11G/trace /u00/app/oracle/diag/rdbms/ora11g/ORA11G/alert /u00/app/oracle/diag/rdbms/ora11g/ORA11G/incident /u00/app/oracle/diag/rdbms/ora11g/ORA11G/cdump /u00/app/oracle/diag/rdbms/ora11g/ORA11G/hm /u00/app/oracle/diag/rdbms/ora11g/ORA11G /trace/ORA11G_ora_16395.trc Active Problem Count 2 Active Incident Count 2
11.1.2
ADRCI – Die Schnittstelle zum ADR
Das ADR Command Line Utility ADRCI dient als Schnittstelle zum Automatic Diagnostic Repository. Es verfügt über folgende Funktionen:
Anzeigen von Diagnostik-Information aus dem ADR Erstellen von Health Monitor Reports Erzeugen von Incident- und Problem-Packages für den Oracle Support Verwaltung und Konfiguration der gesammelten Daten Das ADRCI verfügt über einen umfangreichen Befehlssatz, welcher interaktiv oder mittels ADRCI-Skripts genutzt werden kann. Nachfolgend die ADRCI-Befehle einer 11g R2-Installation. adrci> help HELP [topic] Available Topics: CREATE REPORT ECHO EXIT HELP HOST IPS PURGE RUN SET BASE SET BROWSER SET CONTROL SET ECHO
507
11 Monitoring SET EDITOR SET HOMES | HOME | HOMEPATH SET TERMOUT SHOW ALERT SHOW BASE SHOW CONTROL SHOW HM_RUN SHOW HOMES | HOME | HOMEPATH SHOW INCDIR SHOW INCIDENT SHOW PROBLEM SHOW REPORT SHOW TRACEFILE SPOOL There are other commands intended to be used directly by Oracle, type ”HELP EXTENDED” to see the list adrci>
Die ADRCI-Befehle beziehen sich auf ein bestimmtes ADR-Homeverzeichnis. Das heißt, es muss zuerst das gewünschte ADR_HOME mit dem Befehl set home definiert werden. Andernfalls erfolgt eine Fehlermeldung, wie das folgende Beispiel zeigt: adrci> show alert -tail DIA-48449: Tail alert can only apply to single ADR home
Das nachfolgende Beispiel zeigt die verfügbaren ADR-Homeverzeichnisse und das Setzen des gewünschten ADR-Homeverzeichnisses. Es ist zu beachten, dass die ADR-Homes mit diag/… beginnen, das heißt, ohne ADR_BASE dargestellt sind. adrci> show homes ADR Homes: diag/rdbms/ora11g_site1/ora11g diag/rdbms/tech2_site1/TECH2 diag/clients/user_oracle/host_3802899293_11 adrci> set home diag/rdbms/ora11g_site1/ora11g
Nun kann man beispielsweise das Alert-Log mit einem ADRCI-Befehl auswerten, was neue Möglichkeiten für die Überwachung eröffnet: adrci> show alert -tail ... 2009-09-12 14:13:17.839000 +02:00 Current log# 3 seq# 1407 mem# 1: /u02/oradata/ora11g/redog3m2ora11g.dbf 2009-09-12 14:13:18.857000 +02:00 Thread 1 cannot allocate new log, sequence 1408 Private strand flush not complete ... (cont.)
11.1.3
Enterprise Manager Support Workbench
Etwas komfortabler als mit dem ADRCI können die Diagnostikinformationen aus dem ADR mit der Enterprise Manager Support Workbench bearbeitet werden. Diese analysiert Fehlerereignisse wie beispielsweise ORA-00600, ORA-07445 oder ORA-04031 und erstellt Reports. Zudem lassen sich sogenannte Incident Packages generieren. Aktuell (11gR2) ist die Support Workbench nur im EM Database Control implementiert.
508
11.1 Monitoring-Architektur
11.1.4
Incident Package Service (IPS)
Der Incident Package Service (IPS) extrahiert die zu einem Fehlerereignis gehörenden Diagnostik- und Testfalldaten aus dem Automatic Diagnostic Repository (ADR) und packt die Daten für den Upload an den Oracle Support zusammen, was eine erhebliche Vereinfachung bei der Eröffnung eines Servicerequests bedeuten kann. Das Packen erfolgt wahlweise automatisch oder benutzerdefiniert über den Enterprise Manager. Das IPS erfasst automatisch die Fehlermeldungen ORA-00600, ORA-07445 und ORA-04031, wobei mit Incident Flood Control die Menge der möglichen Tracefiles anhand von fix definierten Schwellwerten beschränkt ist.
11.1.5
Automatic Workload Repository (AWR)
Das Automatic Workload Repository (AWR) dient als Datenbasis für Performanceanalysen und -Tuningaktivitäten. Hier sind Performancestatistiken über das System, Sessions, SQL-Statements, Segmente und Services abgelegt. Der MMON-Prozess liest die Performancestatistiken aus der SGA (per Default jede Stunde) und schreibt sie in den SYSAUX-Tablespace. Das Sammeln der Statistiken ist standardmäßig eingeschaltet. Dies wird über den Parameter STATISTICS_LEVEL definiert, der auf TYPICAL (=Default) oder ALL gesetzt sein muss. Der Platz innerhalb des AWR wird durch die Snapshot Retention Policy gesteuert (Default 8 Tage). Die Häufigkeit der Datenermittlung und die Aufbewahrungszeit lässt sich über das Package DBMS_WORKLOAD_REPOSITORY ändern. Im folgenden Beispiel werden die Statistiken alle 30 Minuten ermittelt und zwei Wochen im AWR aufbewahrt: EXECUTE DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( interval => 30, retention => 20160);
Abbildung 11.1 zeigt den Weg der Statistikdaten von der SGA in das AWR.
Monitoring-Datenbasis Wenn wir über Monitoring reden, müssen wir uns auch fragen, woher die Daten stammen, auf denen die Überwachung aufbaut. Oracle ist in dieser Hinsicht sehr gut instrumentiert und stellt zeitnahe und historisierte Informationen in Form von Log- und Tracefiles, dynamischen Performanceviews (V$-Views), DBA-Views und Datenbankmetriken zur Verfügung. Im folgenden Abschnitt stellen wir die einzelnen Datenquellen vor.
11.2.1
Alert-Log
Das Alert-Log-File gehört zu den wichtigsten Datenquellen für das Monitoring. Oracle schreibt bei internen Fehlern (ORA-600) und Blockkorruption (ORA-1578) entsprechende Informationen in das Alert-Log bzw. in ein Tracefile. Zudem werden Operationen wie Redo-Log-Switches, das Anlegen und Löschen von Datenbankbenutzern, Vergrößerung eines Tablespaces, Parameteränderungen etc. in chronologischer Reihenfolge in das AlertLog geschrieben. Das Alert-Log ist daher zu überwachen. Mit der Einführung der ADR-Struktur (siehe Abschnitt 11.1.1), ist das Alert-Log-File nicht mehr im bdump-Verzeichnis unter $ORACLE_BASE/admin/SID zu finden, sondern an folgenden zwei Stellen:
Als Textfile unter $ADR_BASE/rdbms/SID_site1/SID/trace Als XML-File unter $ADR_BASE/rdbms/SID_site1/SID/alert/log.xml Das XML-File lässt sich mit dem ADRCI-Utility auswerten, während für das Textfile herkömmliche Mittel erforderlich sind. Herkömmlich heißt in diesem Fall Auswertung mit Stringparsing, oder seit Oracle Version 11g mit SQL*Plus 2 . Über die Fixed-Table X$DBGALERTEXT kann das Alert-Log (log.xml) ausgewertet werden: SQL> SELECT message_text FROM x$dbgalertext WHERE rownum DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL, warning_operator => DBMS_SERVER_ALERT.OPERATOR_GE, warning_value => ‘87’, critical_operator => DBMS_SERVER_ALERT.OPERATOR_GE, critical_value => ‘97’, observation_period => 1, consecutive_occurrences => 3, instance_name => ‘ora11g’, object_type => DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE, object_name => ‘TOOLS’ ); END; /
Die gesetzten Schwellwerte lassen sich im Enterprise Manager oder aus der View DBA_ THRESHOLDS abfragen: SELECT metrics_name, object_name, warning_value, critical_value FROM dba_thresholds WHERE object_name like ‘TOOLS’; METRICS_NAME OBJECT_NAME WARNING_VALUE CRITICAL_VALUE -----------------------------------------------------------------Tablespace Space Usage TOOLS 87 97
11.2.6
Baseline Metric Thresholds und Adaptive Thresholds
Baseline Metric Thresholds kalibrieren im Sinne eines lernenden Systems die MetrikSchwellwerte aufgrund von Erfahrungswerten aus dem Workload-Repository (AWR). Abbildung 11.3 zeigt anhand der Metrik Response Time (per transaction), wie die Schwellwerte basierend auf den Antwortzeiten aus der Vergangenheit eingestellt werden. Die historischen Daten stammen dabei aus dem AWR. Die Referenzperiode lässt sich fix definieren oder als „Moving Window“ dynamisch nachführen (Adaptive Thresholds). Letzteres ist vor allem für Metriken interessant, die sich im Verlauf der Zeit tendenziell erhöhen oder verringern, und wenn dies die Überwachung berücksichtigen soll.
514
11.2 Monitoring-Datenbasis
Abbildung 11.3 Konfiguration von Baseline Metric Thresholds und Adaptive Thresholds
11.2.7
User Defined Metrics
Wie der Name sagt, können Benutzer auch ihre eigenen Metriken definieren. User Defined Metriken (UDM) ergänzen die Default-Metriken, wenn eine spezifische Überwachung zu implementieren ist, die sich durch eine Default-Metrik nicht abdecken lässt. UDMs können auf Datenbank- oder auf Betriebssystemebene definiert werden. Man spricht dann von SQL-based UDMs bzw. OS-based UDMs. Was Erstellung, Historisierung, Purging und Verwaltung betrifft, fügen sich die UDMs nahtlos in das Metrikkonzept ein:
Die UDMs sind in denselben Tabellen wie die Default-Metriken abgelegt Historisierung und Purging erfolgt durch Enterprise Manager Jobs Die Verwaltung der UDMs erfolgt via EM Database Control oder Standard EM API Folgende MGMT-Views (Auswahl) zeigen Informationen über UDMs:
Im EM Database Control ist der Einstieg zu den UDMs auf der Einstiegsseite unter „Related Links“ zu finden. Eine wizzard-ähnliche Seite führt einen durch die Erstellung der UDM.
515
11 Monitoring
Abbildung 11.4 Verwaltungsseite für User Defined Metrics
Abbildung 11.5 Detailansicht einer User Defined Metrik
11.2.8
Policies
Policies sind von Oracle definierte Regeln für folgende Bereiche:
Konfiguration Sicherheit Speicherplatz Der Enterprise Manager überwacht die Einhaltung der Regeln und zeigt sie in der HTMLKonsole an. Die Überprüfung und Einhaltung von unternehmensweiten Standards wird dadurch stark vereinfacht. So werden grundlegende Dinge wie beispielsweise falsche Dateiberechtigungen auf die Oracle-Binaries oder die Vergabe der SELECT ANY TABLE-Berechtigung einfach – und vor allem regelmäßig6 – überprüft. 6
516
Policy-Regeln werden typischerweise alle 24 Stunden überprüft
11.2 Monitoring-Datenbasis Policies können für alle unterstützten Target-Typen wie beispielsweise Host oder Datenbank definiert und ausgewertet werden. Dies gilt im Falle von EM Grid Control auch für ältere Oracle-Versionen wie 9i. Die Policy-Definitions und -Verwaltungsseite erreicht man im Enterprise Manager über die Einstiegsseite. Dort sind auch die Policy-Verletzungen der jeweiligen Targets und der Erfüllungsgrad der Regel (Compliance Score) in Prozent angezeigt (siehe Abbildung 11.6). Mittels Drill-Down-Link sind die Details des Regelverstoßes einsehbar. Tauchen in der Spalte „Details“ Links auf, beispielsweise bei Invalid Objects, gelangt man durch einen einfachen Klick direkt zum entsprechenden Objekt, um es beispielsweise zu kompilieren.
Abbildung 11.6 EM Database Control − Übersicht über die Policy Violations
Es ist leider nicht möglich, eigene Policies zu erstellen. Die vordefinierten Policies lassen sich jedoch editieren und – in beschränktem Umfang – an die eigenen Bedürfnisse anpassen (siehe Abbildung 11.7):
Ein-/Ausschalten der gesamten Policy Festlegen der Wertigkeit zur Berechnung des Compliance Scores Anpassen von Parametern Ausschließen von Objekten Festlegen von Corrective Actions
Abbildung 11.7 EM Compliance: Policy Rule Library
517
11 Monitoring
11.3
Monitoring von Oracle Datenbanken Wie wir im ersten Teil dieses Kapitels gesehen haben, ist die Instrumentierung einer Oracleinstanz inzwischen sehr umfangreich. Eine große Herausforderung bei der Überwachung einer Oracle Datenbank ist daher die Beschränkung auf das Wesentliche7. Es stellt sich also die Frage: „Was muss ich wirklich auf meinen Datenbanken überwachen und über welche Probleme will ich unbedingt informiert sein?“. Die Antwort darauf ist natürlich sehr individuell, wobei in der Praxis viele Datenbankadministratoren folgende Monitoringbereiche als wesentlich ansehen:
Überwachung der Serviceverfügbarkeit Überwachung von ORA-Fehlermeldungen und Alerts Überwachung des Transaktionsvolumens Platzverbrauch in Tablespaces und Filesystemen Überwachung von ASM Überwachung von Sicherheitsrichtlinien Überwachung von SQL-Befehlen / Performance Überwachung der CPU-Auslastung Überwachung von RMAN-Backups Überwachung von Konfigurationsänderungen Locking Nachfolgend betrachten wir die oben erwähnten Monitoringbereiche und zeigen auf, wie eine entsprechend Überwachung möglich ist.
11.3.1
Überwachung der Serviceverfügbarkeit
Die Überwachung der Serviceverfügbarkeit – darunter ist die Verfügbarkeit der Datenbank und damit implizit auch deren Erreichbarkeit zu verstehen – verhindert zwar keinen Systemausfall, ermöglicht aber ein rasches und gezieltes Eingreifen . Die Varianten der Service-Überwachung sind:
Überwachung mit Grid Control Agent und Enterprise Manager Periodischer Verbindungsaufbau zur Datenbank (Polling) Prozessüberwachung (PMON, SMON und Listener)
7
518
M. A. Marvasti zeigt in seinem Paper “Everything you know about Monitoring is wrong!”, CMG Conference 2007, auf, dass mit 40 Prozent der verfügbaren Metriken 94 Prozent der häufigsten Problem erkannt werden – und das zu den geringstmöglichen Kosten.
11.3 Monitoring von Oracle Datenbanken Am einfachsten kann die Verfügbarkeit einer Datenbank im Enterprise Manager ausgewiesen werden. Über den Link „Availability“ auf der Einstiegsseite gelangt man zu der in Abbildung 11.8 gezeigten Ansicht.
Abbildung 11.8 Verfügbarkeitsstatus einer Datenbank
Praxistipp Vielfach wird versucht, die Verfügbarkeit einer Datenbank mittels tnsping zu ermitteln. Diese prüft jedoch lediglich die Verfügbarkeit des Listeners!
11.3.2
ORA-Fehlermeldungen und Alerts
Interne Fehler (ORA-600), Blockkorruption (ORA-1578) und andere ORA-Fehlermeldungen werden in das Alert-Log-File geschrieben, das entsprechend ausgewertet werden muss. Die Überwachung des Alert-Log geschieht am einfachsten mit dem Enterprise Manager und der Metrik „Generic Alert Log Error“. Diese Metrik, die die View V$METRICNAME angezeigt, wird vom Agent mit dem PERL-Skript $ORACLE_HOME/sysman/admin/ scripts/alertlog.pl evaluiert. Die Schwellwertdefinition legt fest, welche Fehlermeldungen zu einem Server Generated Alert führen und in der Grid Control Konsole angezeigt werden sollen. Der Schwellwert muss für diese Metrik als regulärer Ausdruck8 formuliert sein. Abbildung 11.9 zeigt eine Beispielkonfiguration . 8
Oracle Database SQL Language Reference 11g R2, Anhang D: Oracle Regular Expression Support
Das Alert-Log lässt sich auch manuell oder eingebunden in ein Skript mit dem ADRCITool auswerten. Das folgende Beispiel zeigt, wie das Alert-Log auf bestimmte Fehlermeldungen durchsucht oder analog dem Unixbefehl tail -f überwacht werden kann: adrci> SHOW ALERT -P “MESSAGE_TEXT LIKE ‘%ORA-600%’” adrci> SHOW ALERT -tail –f
Auswertungen via ADRCI lassen sich mittels Skript einfach automatisieren. Im folgenden Beispiel stellen wir ein ADRCI-Skript vor, welches das Alert-Log mittels zwei SHOW ALERTAnweisungen (fett markiert) analysiert: SET ECHO OFF SET TERMOUT OFF SPOOL /u00/app/oracle/admin/ora11g/adhoc/tail_alert.lst SET HOME diag/rdbms/ora11g_site1/ora11g SHOW ALERT -TAIL 5 SHOW ALERT -P “MESSAGE_TEXT LIKE ‘%ORA-600%’” SPOOL OFF SET ECHO ON SET TERMOUT ON
Nun kann das Skript aus dem ADRCI-Tool ausgeführt werden (zu beachten ist im folgenden Beispiel der host-Befehl, der Betriebssystembefehle ausführt). Das Skript wird aufgrund der Default-Extension .adi automatisch als ADRCI-Skript erkannt: adrci> @tail_alert.adi adrci> host “cat tail_alert.lst” 2009-08-19 10:08:24.220000 +02:00 replication_dependency_tracking turned off (no async multimaster replication found) 2009-08-19 10:08:25.694000 +02:00 Starting background process QMNC QMNC started with pid=24, OS id=2913 2009-08-19 10:08:29.633000 +02:00 Completed: ALTER DATABASE OPEN 2009-08-19 10:08:35.779000 +02:00 db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a
520
11.3 Monitoring von Oracle Datenbanken user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. 2009-08-19 10:08:38.847000 +02:00 Starting background process CJQ0 CJQ0 started with pid=30, OS id=2947 2009-08-19 10:13:46.042000 +02:00 Starting background process SMCO SMCO started with pid=27, OS id=3261 2009-08-19 10:25:15.958000 +02:00 Thread 1 advanced to log sequence 111 (LGWR switch) Current log# 3 seq# 111 mem# 0: /u02/oradata/ora11g/redog3m1ora11g.dbf Current log# 3 seq# 111 mem# 1: /u02/oradata/ora11g/redog3m2ora11g.dbf ADR Home = /u00/app/oracle/diag/rdbms/llbe11_site1/ora11g: ************************************************************************* adrci>
11.3.3
Monitoring der Systemaktivität
Die Systemaktivität, das heißt die Menge an Undo-Information pro Zeit, wird per Default im 10-Minuten-Intervall gesammelt und für die letzten sieben Tage aufbewahrt. Die Auswertung erfolgt grafisch mit dem Enterprise Manager oder via SQL*Plus über die View V$UNDOSTAT. Es ist zu beachten, dass die Daten in V$UNDOSTAT nicht persistent sind und somit nach einem Neustart der Instanz nicht mehr verfügbar sind.
Abbildung 11.10 Anzeige der Systemaktivität (Kennzahlen) im Enterprise Manager
Abbildung 11.11 Anzeige der Undo-Aktivität der letzten sieben Tage im Enterprise Manager
521
11 Monitoring V$UNDOSTAT enthält neben der Anzahl Undo-Blöcke diverse weitere interessante Informa-
tionen über die Systemaktivität. Eine Auswahl der Attribute ist nachfolgend aufgeführt. Für die vollständige Attributsliste verweisen wir auf die Oracle-Referenz.
UNDOBLKS: Platzverbrauch in Oracle-Blöcken TXNCOUNT: Anzahl Transaktionen während des Intervalls MAXQUERYLEN: Längste Abfrage (in Sekunden), welche während des Intervalls ausgeführt wurde (oder fertig wurde). Dies kann helfen, die UNDO_RETENTION sinnvoll zu definieren.
MAXQUERYID: SQL-Identifier des zeitintensivsten SQL-Statements innerhalb des Intervalls
MAXCONCURRENCY: Maximale Anzahl gleichzeitiger Transaktionen NOSPACEERRCNT: Anzahl Space Errors (cannot allocate...) während des Intervalls SSOLDERRCNT: Anzahl ORA-01555 Fehler während des Intervalls Die Systemaktivität kann natürlich auch anhand des Transaktionsvolumens (Redo-Information) beurteilt werden. Dazu eignen sich die beiden Views V$LOGHIST und V$ARCHIVED_ LOG (siehe Skript logswitches_anzeigen.sql). Multipliziert man die Anzahl Logswitches mit der Größe der Redo-Logs, ergibt sich daraus das Transaktionsvolumen über einen bestimmten Zeitraum9. Das folgende Beispiel zeigt einen solchen Output. Day Switches/day 00 ---------- ------------- -20.08.2009 79 2 21.08.2009 81 3 22.08.2009 95 2 ... (cont)
01 -1 0 2
02 03 04 -- -- -0 12 14 1 10 13 2 11 15
05 -9 5 7
06 -2 1 2
07 -2 2 2
08 -3 3 2
09 10 (cont...) -- -1 .. 1 .. 3 ..
Auf diese Weise kann man sehr schnell sehen, zu welcher Tageszeit Transaktionsspitzen aufgetreten sind. Im obigen Beispiel wurde beispielsweise zwischen drei und fünf Uhr morgens eine erhöhte Transaktionsaktivität registriert.
11.3.4
Platzüberwachung
Die Überwachung des Platzverbrauches in- und außerhalb der Datenbank ist ein weiterer wichtiger Monitoringbereich. Läuft ein Tablespace oder ein datenbankrelevantes Filesystem voll, führt dies in den meisten Fällen zu einem Datenbankstillstand, das bedeutet Serviceausfall! Der Füllgrad von Tablespaces muss dabei genauso beachtet werden wie der Platzverbrauch in den Archiv-Destinationen, der Flash Recovery Area (FRA) sowie den Verzeichnissen, die für externe Daten (External Tables, UTL_FILE_DIR, Directories) verwendet werden.
9
522
Sind die Redo-Logs nur teilweise gefüllt (z.B. infolge manueller oder zeitgesteuerter Logswitches), kann das so ermittelte Transaktionsvolumen vom tatsächlichen Volumen abweichen. Das heißt, das berechnete Volumen wäre größer als das tatsächliche.
11.3 Monitoring von Oracle Datenbanken Die Platzüberwachung erfolgt in der Regel schwellwertgesteuert über den Enterprise Manager oder mittels Skripte, die periodisch ausgeführt werden. 11.3.4.1
Überwachung von Tablespaces
Die Platzüberwachung von Tablespaces ist inzwischen eine recht einfache Angelegenheit. Die Schwierigkeit bei der Berechnung des freien Platzes bestand in der Vergangenheit darin, das potentielle Wachstum der Datenfiles (Autoextend-Feature) zu berücksichtigen. Eine praktische Data Dictionary View, die ab Version 11g R1 verfügbar ist, nimmt dem DBA nun auch diese Arbeit ab: DBA_TABLESPACE_USAGE_METRICS zeigt auf einen Blick die aktuelle Größe des Tablespace, den bereits verbrauchten Platz10, sowie den Füllgrad in Prozent bezüglich der maximal möglichen Größe des Tablespace: SELECT tablespace_name, used_space, tablespace_size, 100-used_percent free_pct FROM dba_tablespace_usage_metrics; TABLESPACE_NAME USED_SPACE TABLESPACE_SIZE FREE_PCT --------------- ------------- ------------------- ----------SYSAUX 53008 131072 59.6 SYSTEM 66056 131072 49.6 TEMP 0 262144 100.0 TOOLS 3480 64000 94.6 UNDOTS 168 262144 99.9 USERS 62080 131072 52.6
Die View zeigt den allokierten Platz innerhalb der Tablespaces, nicht aber den effektiv belegten Platz. Wenn Sie wissen wollen, wie viele der allokierten Datenbankblöcke wie stark belegt sind, hilft nur eine tiefer greifende Füllgrad-Analyse mit dem PL/SQL-Package DBMS_SPACE: SET SERVEROUTPUT ON DECLARE v_unformatted_blocks number; v_unformatted_bytes number; v_fs1_blocks number; v_fs1_bytes number; v_fs2_blocks number; v_fs2_bytes number; v_fs3_blocks number; v_fs3_bytes number; v_fs4_blocks number; v_fs4_bytes number; v_full_blocks number; v_full_bytes number; BEGIN DBMS_SPACE.SPACE_USAGE (‘&1’, ‘&2’, ‘&3’, v_unformatted_blocks, v_unformatted_bytes, v_fs1_blocks, v_fs1_bytes, v_fs2_blocks, v_fs2_bytes,v_fs3_blocks, v_fs3_bytes, v_fs4_blocks, v_fs4_bytes, v_full_blocks, v_full_bytes); DBMS_OUTPUT.PUT_LINE(‘FS1 Blocks ( 0-25% free) = ‘||v_fs1_blocks); DBMS_OUTPUT.PUT_LINE(‘FS2 Blocks (25-50% free) = ‘||v_fs2_blocks);
10
Siehe auch My Oracle Support Note 455715.1: Difference in Tablespace Size Values From dba_data_files and dba_tablespace_usage_metrics/V$Filespace_usage
Das obige Skript wird nun mit den Parametern für Segment-Owner, Segmentname und Segmenttyp aufgerufen. Die Auswertung ergibt die Anzahl Blöcke pro Füllgradklasse. Im folgenden Beispiel weisen die allokierten Blöcke der Tabelle EMPLOYEES einen relativ hohen Füllgrad auf und nur wenige Blöcke sind teilweise gefüllt: @dbms_space.sql “HR” “EMPLOYEES” “TABLE” FS1 Blocks ( 0-25% free) = 3 FS2 Blocks (25-50% free) = 28 FS3 Blocks (50-75% free) = 34 FS4 Blocks (75-99% free) = 3281 Full Blocks = 21031
Die Platzüberwachung im Enterprise Manager basiert auf entsprechenden TablespaceMetriken und Schwellwerten. Default-Schwellwerte für Tablespaces liegen bei 85 Prozent für eine Warnung und 95 Prozent für einen Critical-Alert. Die Schwellwerte können im Enterprise Manager angezeigt und angepasst werden, sind aber auch mit der View DBA_TABLESPACE_THRESHOLDS direkt einsehbar. Tabelle 11.2 Tablespace-Metriken METRIC_NAME
METRIC_UNIT
Tablespace Free Space (MB)
MegaBytes
Tablespace Free Space (MB) (dictionary managed)
MegaBytes
Tablespace Space Used (%)
%
Tablespace Free Space Used (MB) (dictionary managed)
MegaBytes
11.3.4.2
Überwachung der Fast Recovery Area
Die Überwachung der Fast Recovery Area11 (FRA) ist vor allem dann wichtig, wenn man darin die Archive-Logs, RMAN-Backupsets und Flashback-Logs verwaltet (siehe Kapitel 2 „Architektur und Administration“). Auf der Einstiegsseite des Enterprise Manager sieht man im Bereich „High Availability“, wie viel freier Platz in der FRA noch vorhanden ist (siehe Abbildung 11.12).
Abbildung 11.12 Monitoring des freien Platzes der Flash Recovery Area 11
524
Mit Oracle 11g R2 wurde die Flash Recovery Area in „Fast Recovery Area” umbenannt. Dies ist lediglich eine Namensänderung, die nicht mit neuen Funktionalitäten verbunden ist
11.3 Monitoring von Oracle Datenbanken Die Detailansicht zeigt, welches Files diesen Platz nutzt (siehe Abbildung 11.13).
Abbildung 11.13 Anzeige des Platzverbrauchs innerhalb der Fast Recovery Area
Natürlich stehen auch eine ganze Reihe Data Dictionary Views zur Verfügung, die sich für die Überwachung der FRA eignen. Die wichtigsten davon sind:
V$RECOVERY_FILE_DEST: Weist die Disk-Quota (Space Limit) und den aktuellen Diskverbrauch aus
V$FLASH_RECOVERY_AREA_USAGE: Zeigt den Platzverbrauch innerhalb der FRA aufgeteilt nach Filetyp an
V$FLASHBACK_DATABASE_LOG: Kann hinzugezogen werden, um für den aktuellen Workload den benötigten Platz in der Flashback Area abzuschätzen V$FLASHBACK_DATABASE_STAT und V$FLASHBACK_DATABASE_LOGFILE sind weitere Views,
die im Zusammenhang mit der I/O-Performance, resp. für Recovery-Operationen nützlich sind. 11.3.4.3
Überwachung des Automatic Diagnostic Repository
Ab Version 11g werden die Log- und Tracefiles von allen Oracleservices auf einem Server unter einem gemeinsamen Dach, dem Automatic Diagnostic Repository (ADR) verwaltet. Dies ermöglicht eine Instanz- bzw. service-übergreifende Diagnose. Was auf der einen Seite praktisch ist, erfordert auf der anderen Seite erhöhte Aufmerksamkeit vom DBA bezüglich der Platzüberwachung. Die Platzüberwachung der ADR-Verzeichnisse ist im Enterprise Manager integriert. Die aktuellen Platzverhältnisse werden auf der Übersichtsseite der jeweiligen Instanz angezeigt (siehe Abbildung 11.14). Maßgebend ist dabei die Metrik „Dump Area Used (%)“.
525
11 Monitoring
Abbildung 11.14 Anzeige der Platzverhältnisse im ADR (Dump Area)
Die Platzverwaltung erfolgt automatisch mit vordefinierten Retention-Policies12:
SHORTP_POLICY: Default 720 Stunden (30 Tage). Folgende Verzeichnisse werden über diese Policy verwaltet: ./trace, ./cdump, ./trace/cdmp_ sowie Files unter ./incpkg und Metadaten im IPS-Schema.
LONGP_POLICY: Default 8760 Stunden (365 Tage). Folgende Verzeichnisse sind unter Kontrolle der Long-Policy: ./alert, ./stage, ./sweep, ./hm und Metadaten im HMSchema sowie ./incident/incdir_ und Metadaten in den Verzeichnissen metadata, ir und lck und im Incident-Schema. Das Beispiel zeigt, wie im adrci die Policies angezeigt und geändert werden können (Einheit in Stunden13). Für gewisse Umgebungen ist eine Short-Policy von 30 Tage evtl. zu lange: adrci> show control ADR Home = /u00/app/oracle/diag/rdbms/ora11g_site1/ora11g: ************************************************************************* ADRID SHORTP_POLICY LONGP_POLICY LAST_MOD_TIME ------------------ ------------------ ----------------- ---------------------911312449 720 8760 2011-05-02 19:45:18.841492 +02:00 1 rows fetched adrci> set control (SHORTP_POLICY=360) adrci> show control ADR Home = /u00/app/oracle/diag/rdbms/ora11g_site1/ora11g: ************************************************************************* ADRID SHORTP_POLICY LONGP_POLICY LAST_MOD_TIME ------------------ ------------------ ---------------- ---------------------911312449 360 8760 2011-13-07 07:39:03.483698 +02:00 1 rows fetched
Die Log- und Tracefiles können im ADR bei Bedarf auch manuell gelöscht werden (purgen)14. Dies erfolgt ebenfalls mit dem Utility adrci; adrci> purge -age 360 -type trace
Der obige Purge-Befehl löscht alle Tracefiles aus dem ADR, die älter als 360 Stunden (15 Tage) alt sind.
12
My Oracle Support Note 975448.1: Which files are part of SHORTP Policy and LONGP Policy in ADR? 13 My Oracle Support Note 564012.1: ADRCI Online Help For Set Control Command Shows Wrong Units For Policy Value 14 Siehe dazu auch My Oracle Support Bug Nr. 6800147, ADRCI purge command doesn´t work when delete Alertlog using AGE option
526
11.3 Monitoring von Oracle Datenbanken 11.3.4.4
Überwachung von ASM
Mit Oracle 11g wurde die Verwaltung von ASM Disk-Gruppen in den Enterprise Manager integriert. Die neue ASM-Verwaltungsseite in Database Control (siehe Abbildung 11.15) stellt alle dazu notwendigen Funktionen zur Verfügung. Zugang zur ASM-Verwaltungsseite erhält man über den SYS-Account der ASM-Instanz (Login als SYSASM).
Abbildung 11.15 Überwachung von ASM mit Database Control
Über den Reiter „Disk Groups“ wird die Kapazität der einzelnen ASM Disk-Gruppen angezeigt (siehe Abbildung 11.16).
Abbildung 11.16 Anzeige der Platzverhältnisse von ASM-Diskgruppen mittels Database Control
Natürlich kann man die Platzverhältnisse auch per SQL-Abfrage überwachen. Die View V$ASM_DISKGROUP beinhaltet alle notwendigen Informationen für die Platzüberwachung. Das folgende Listing zeigt eine entsprechende Abfrage mit Output:
527
11 Monitoring SET PAGESIZE 9999 SET VERIFY off COLUMN group_name COLUMN sector_size COLUMN block_size COLUMN allocation_unit_size COLUMN state COLUMN type COLUMN total_mb COLUMN used_mb COLUMN pct_used
FORMAT FORMAT FORMAT FORMAT FORMAT FORMAT FORMAT FORMAT FORMAT
break on report on disk_group_name skip 1 compute sum label “Grand Total: “ of total_mb used_mb on report SELECT name sector_size block_size allocation_unit_size state type total_mb (total_mb - free_mb) ROUND((1- (free_mb / total_mb))*100, 2) FROM v$asm_diskgroup ORDER BY name / Disk Group Name ----DATA FRA
Sector Size -----512 512
Grand Total:
11.3.5
Block Size ----4,096 4,096
Alloc Unit Size --------1,048,576 1,048,576
State --------CONNECTED CONNECTED
Type -----EXTERN EXTERN
group_name, sector_size, block_size allocation_unit_size state type total_mb used_mb pct_used
Total Size(MB) -------4,126 8,189 -----12,315
Used PCT Size(MB) Used ------- -----3,475 84.22 5,767 70.42 ----9,242
Überwachung von Sicherheitsrichtlinien
Die Überwachung der Datenbanksicherheit erfährt eine immer größere Bedeutung. Gerade in regulierten Branchen wie in der Pharmaindustrie oder im Finanzbereich sind nicht nur hohe Sicherheitsanforderungen zu erfüllen, deren Einhaltung ist auch regelmäßig zu überprüfen und auszuweisen. Jeder Systemverantwortliche weiß, dass Sicherheit eine Angelegenheit ist, ohne deren ständige Überwachung sich rasch Lücken öffnen können. Es ist daher sinnvoll, eine entsprechende Überwachungsstrategie zu definieren und geeignete Werkzeuge einzusetzen. Die Überwachung der verschiedenen Sicherheitsbereiche bedingt auch eine entsprechend spezifische Betrachtung:
Generelle Datenbanksicherheit wie Passwortverwaltung, Privilegien auf Datenbankfiles und Verzeichnisse, Parametrisierung und Vergabe von System- und Objektprivilegien Überwachung der Datenbankzugriffe, beispielsweise hochprivilegierte Zugriffe, Zugriffe über Datenbanklinks, Remotezugriff etc. Überwachung von Datenmanipulationen (wer ändert welche Daten?) Die Regeln für die Überwachung der generellen Datenbanksicherheit sind – vorausgesetzt Sie setzen Enterprise Manager zur Überwachung ein – in Form von Sicherheits-Policies out-of-the-Box definiert und verfügbar. Diese Policies sind sehr umfangreich und decken
528
11.3 Monitoring von Oracle Datenbanken
Abbildung 11.17 Security at a Glance
die häufigsten Sicherheitsrisiken ab. Die Einstiegsseite „Security at a Glance“ zeigt den Sicherheitsstatus aller überwachten Targets auf einen Blick (siehe Abbildung 11.17). Mittels Drill-Down-Link gelangt man zu den entsprechenden Policy-Verletzungen. Auch für die Überwachung der Datenbankzugriffe sind entsprechende Sicherheits-Policies vorhanden. So stellt beispielsweise die Policy-Regel „Auditing of SYS Operations Enabled“ sicher, dass sämtliche Operationen eines Users, der sich als SYS einloggt, in Form von Auditeinträgen festgehalten werden. Diese Funktionalität ist mit den Advanced Security Settings ab Oracle11g R1 per Default verfügbar. Folgende Sicherheitseinstellungen (DB-Parameter und User-Profile) sind standardmäßig eingeschaltet: audit_trail = DB O7_DICTIONARY_ACCESSIBILITY = FALSE remote_os_roles = FALSE SELECT * FROM DBA_PROFILES WHERE profile = ‘DEFAULT AND resource_type = ‘PASSWORD’; PROFILE ---------DEFAULT DEFAULT DEFAULT DEFAULT DEFAULT DEFAULT DEFAULT
Im Gegensatz zu den bereits beschriebenen Sicherheitsbereichen ist die Überwachung von Datenmanipulationen nicht mittels Policies realisierbar. Dazu ist Datenbank-Auditing erforderlich, das eine gezielte, feingranulare Überwachung auf Tabellenebene erlaubt. Mehr zum Thema Auditing erfahren Sie in Kapitel 6 „Security“.
11.3.6
Monitoring von SQL-Befehlen
Die Überwachung von SQL-Befehlen – insbesondere die Überwachung von sogenannten Langläufern 15 – wurde lange Zeit etwas stiefmütterlich behandelt. Zwar konnte man bereits in früheren Enterprise-Manager-Versionen Rollback/UNDO- und RMAN-Restore15
Operationen mit einer Ausführungszeit von länger als fünf Sekunden
529
11 Monitoring Aktivitäten überwachen, aber „normale“ SQL-Befehle ließen sich nicht auf einfache Art und Weise überwachen. Auch die Integration in den Enterprise Manager ließ zu wünschen übrig. Diese Lücke wurde mit 11g geschlossen. Mit Version 11g R1 hat Oracle ein neues Feature, das „Real-Time SQL Monitoring“ eingeführt, das im Wesentlichen aus den beiden Views V$SQL_MONITOR und V$SQL_PLAN_ MONITOR sowie aus dem PL/SQL-Package DBMS_SQLTUNE besteht. Mit 11gR2 wurde es in den Enterprise Manager (Database Control) integriert. Um Real-Time SQL Monitoring zu nutzen, müssen folgende Voraussetzungen erfüllt sein:
Der Parameter STATISTICS_LEVEL muss auf TYPICAL (=Default) oder ALL gesetzt sein. Der Parameter CONTROL_MANAGEMENT_PACK_ACCESS muss auf DIAGNOSTIC+TUNING (=Default) gesetzt sein.
Der Parameter
COMPATIBLE muss auf 11.2.0.0 (oder höher) gesetzt sein, damit das SQL-Monitor-Feature im Enterprise Manager genutzt werden kann.
Die Session, mit der SQL-Statements überwacht werden sollen, muss Zugriff auf das Oracle Database Tuning Pack haben.
Das Oracle Tuning Pack muss lizenziert sein.16 Sind die oben erwähnten Voraussetzungen erfüllt, werden automatisch diejenigen SQLStatements überwacht, die eine Ausführungszeit von mehr als fünf Sekunden aufweisen, paralleli-siert oder mit dem MONITOR-Hint versehen sind. Falls gewünscht, können mit dem NO_MONITOR-Hint SQL-Anweisungen explizit vom Real-Time Monitoring ausgeschlossen werden. Von den überwachten SQL-Statements werden jede Sekunde Performancedaten wie I/Ound Wait-Statistiken, Elapsed-Time oder CPU-Time in V$SQL_MONITOR und V$SQL_PLAN_ MONITOR geschrieben. Diese beiden Views sowie die Views V$SQL, V$SQL_PLAN, V$ACTIVE_SESSION_HISTORY, V$SESSION_LONGOPS und V$SESSION lassen sich danach auswerten. Einfacher, das heißt, ohne eigene SQL-Abfragen formulieren zu müssen, erstellt die PL/SQL-Prozedur DBMS_SQLTUNE.REPORT_SQL_MONITOR Reports. Im Enterprise Manager ist das SQL-Monitor-Feature unter „Additional Monitoring Links“ im Performance-Bereich zu finden (siehe Abbildung 11.18). Dies ist der Ausgangspunkt für die Analyse der überwachten SQL-Statements mit Drilldown-Möglichkeiten auf die SQL Execution Details, Session Details und SQL Details. Für langlaufende SQL-Statements werden folgende Informationen angezeigt:
Status (Executing, Done oder Error) Laufzeit in Sekunden Session ID, die das SQL-Statement ausführt Parallelisierungsgrad CPU-Time in Sekunden 16
530
Das Oracle Tuning Pack und das Oracle Diagnostic Pack sind lizenzpflichtige Optionen
11.3 Monitoring von Oracle Datenbanken
Disk-Reads Start und Ende der Ausführung Ausgeführtes SQL-Statement
Abbildung 11.18 EM Performance-Seite: Additional Monitoring Links
Abbildung 11.19 EM SQL-Monitor: Übersicht der überwachten SQL-Statements
Mittels Klick auf das gewünschte SQL-Statement gelangt man in die Detailansicht. Hier werden Detail-Informationen wie Ausführungsplan, Wait-Informationen, Fortschrittsanzeige etc. angezeigt (siehe Abbildung 11.19). Interessant ist auch die Möglichkeit, ActivityReports in HTML-Format zu erstellen und diese per E-Mail aus Database Control zu versenden.
531
11 Monitoring
Abbildung 11.20 SQL-Monitor: Detailansicht der SQL-Ausführung
11.3.7
Monitoring der CPU-Auslastung
Möchten Sie beispielsweise per E-Mail eine Nachricht erhalten, wenn eine Datenbanksession oder eine einzelne Transaktion mehr CPU-Ressourcen verbraucht hat als vorgesehen? Oracle stellt dafür diverse Default-Metriken zur Verfügung. Sobald ein Schwellwert überschritten ist, wird ein Server Generated Alert ausgelöst und im Enterprise Manager angezeigt. Die Schwellwerte können bei Bedarf im Enterprise Manager oder über das PL/SQL API DBMS_SERVER_ALERTS geändert werden. Tabelle 11.3 zeigt alle CPU-relevanten Metriken, die in einer 11gR2-Datenbank verfügbar sind. Tabelle 11.3 CPU-Metriken
532
METRIC_NAME
METRIC_UNIT
Host CPU Utilization (%)
% Busy/(Idle+Busy)
Database CPU Time Ratio
% Cpu/DB_Time
CPU Usage Per Txn
CentiSeconds Per Txn
CPU Usage Per Sec
CentiSeconds Per Second
CPU Time (Session)
CentiSeconds
CPU Time Per User Call
Microseconds Per Call
Elapsed Time Per User Call
Microseconds Per Call
CPU Wait Time
Milliseconds
Consumed CPU Time
Milliseconds
11.3 Monitoring von Oracle Datenbanken
11.3.8
Monitoring von RMAN-Backups
In modernen, komplexen Datenbankumgebungen läuft praktisch zu jeder Tages- und Nachtzeit irgendein Backup. „Werden auch wirklich alle Datenbanken gesichert, die gesichert werden müssen?“ und „Werden die Datenbanken optimal, das heißt zur richtigen Zeit mit der effizientesten Methode gesichert?“ Die Antwort auf diese Fragen liefert eine systematische Überwachung. Im folgenden Abschnitt zeigen wir, wie man die Backup-Performance, das Volumen und die Aktualität der Backups überwacht und ausweist. 11.3.8.1
Backup-Überwachung mit dem Enterprise Manager
Einstiegspunkt für die Überwachung von RMAN-Backups mit dem Enterprise Manager sind die Backup Reports (siehe Abbildung 11.21).
Abbildung 11.21 Überwachung der RMAN-Backups mit dem Enterprise Manager
Hier sind alle Backup Logs mit Details zu den gesicherten Files angezeigt. Neben dem Status ist die Backup-Größe und auch die Schreib-Performance (Output Rate) zu beachten. „Ausreißer“ sind so schnell zu erkennen.
Abbildung 11.22 Enterprise Manager Backup Report
533
11 Monitoring 11.3.8.2
Backup-Überwachung mit SQL*Plus
Vorausgesetzt, Sie verwenden RMAN mit einem Katalog, was generell empfohlen wird (siehe Kapitel 13 „Backup und Recovery“), können Sie die Katalogtabellen für Reportingzwecke nutzen. Dies ist vor allem deshalb interessant, weil in einem RMAN-Katalog Backup-Informationen von mehreren Datenbanken verwaltet werden. Auf Instanzebene lassen sich die Backups über entsprechende V$-Views (V$BACKUP_%, V$RMAN_BACKUP%, u.a.m.) überwachen. Einen schnellen Überblick liefert beispielsweise die View V$BACKUP_ SET_SUMMARY. Die Katalogtabellen haben keine sprechenden Namen. Die RC_%-Views (RC steht für Recovery-Catalog) sind hingegen so benannt, dass auf ihren Inhalt geschlossen werden kann. Einige wichtige Views sind:
„Sind ihre Backups aktuell?“ und „Wann wurden die Datenbanken das letzte Mal gesichert?“ Diese Fragen beantwortet eine Abfrage auf den RMAN-Katalog (RC_DATABASE und RC_BACKUP_SET). Im folgenden Beispiel untersuchen wir, wie aktuell die Backups aller im Katalog registrierten Datenbanken sind (Beobachtungszeitraum sieben Tage): SELECT
d.name, TO_CHAR(MAX(s.start_time), “DD.MM.YY HH24:MI”) start_time FROM rc_backup_set s, rc_database d WHERE s.db_key = d.db_key GROUP BY d.name HAVING MAX(s.start_time) < SYSDATE - 7 ORDER BY MAX(s.start_time);
11.3.8.4
Monitoring der RMAN-Performance
Die View V$RMAN_STATUS überwacht die laufenden RMAN-Backups. Sie liefert Informationen wie Start- und Endzeitpunkt, I/O in Bytes, Megabytes verarbeitet in Prozent, Backuptyp etc. Mit periodischen Abfragen auf V$RMAN_STATUS erhält man einen guten Eindruck über den Status eines Backup-Jobs. Weitere nützliche Views für die Überwachung der Backup- und Restore-Performance sind V$SESSION, V$PROCESS und V$SESSION_ LONGOPS. In V$SESSION_LONGOPS werden Jobs ausgewiesen, die länger als sechs Sekunden dauern.
534
11.3 Monitoring von Oracle Datenbanken 11.3.8.5
Monitoring des Backup-Volumens
Über die RMAN-Katalogviews RC_BACKUP_DATAFILE, RC_BACKUP_REDOLOG, RC_BACKUP_CONTROLFILE und RC_BACKUP_SPFILE lässt sich das das Backup-Volumen mehrerer Datenbanken über einen bestimmten Zeitraum ermitteln. Dabei werden nicht nur die Datenfiles berücksichtigt, sondern auch die Redo-Logs, die Controlfiles und die SPFILES. Im folgenden Skript wird das Backup-Volumen der letzten dreißig Tage ermittelt: col vol form 999,990.99 head “Backup Volume|GB” BREAK ON report compute SUM OF vol ON report SELECT d.name, ROUND(SUM(v.vol)/1024/1024/1024, 2) vol FROM (SELECT db_key, completion_time, blocks*block_size vol FROM rc_backup_datafile UNION ALL SELECT db_key, completion_time, blocks*block_size vol FROM rc_backup_redolog UNION ALL SELECT db_key, completion_time, blocks*block_size vol FROM rc_backup_controlfile UNION ALL SELECT db_key, completion_time, bytes vol FROM rc_backup_spfile) v, rc_database d WHERE v.db_key = d.db_key AND v.completion_time > (SYSDATE - 10) GROUP BY name Backup Volume NAME GB -------- ------------TECH48 10.88 TECH11 33.49 TECH16 37.44 ... ... TECH19 230.07 TECH23 624.01 ------------sum 1248.97
Der Output zeigt auf einen Blick, welche Datenbank das größte Backup-Volumen verursacht hat. Diese Kennzahl ist beispielsweise als Kriterium17 für die Berechnung der Servicekosten interessant. 11.3.8.6
Monitoring von RMAN-Jobs
Bei der Ausführung von RMAN-Skripts erfolgt der Output in der Regel in ein Logfile, das dann zu Kontroll- oder Archivzwecken aufbewahrt werden kann. Weniger bekannt ist, dass der Output von RMAN-Operationen zusätzlich in der View V$RMAN_OUTPUT festgehalten wird (seit Version 10g R2). Dies kann sehr nützlich sein, wenn das Logfile nicht mehr verfügbar ist: SELECT output FROM v$rman_output
17
Dies ist nur ein Kriterium unter vielen, das für die Berechnung der Servicekosten verwendet werden kann. Metriken wie CPU-Verbrauch, User-Calls, I/O-Rate etc. sind ebenso zu berücksichtigen
535
11 Monitoring WHERE session_key = 3 ORDER BY recid; _________________________________________________________________________ connected to target database: ora11g (DBID=2349333548) Starting backup at 27-MAR-10 using target database controlfile instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=201 devtype=DISK channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00001 name=/u01/oradata/ora11g/system01.dbf input datafile fno=00003 name=/u01/oradata/ora11g/sysaux01.dbf input datafile fno=00002 name=/u01/oradata/ora11g/undotbs01.dbf input datafile fno=00004 name=/u01/oradata/ora11g/users01.dbf channel ORA_DISK_1: starting piece 1 at 27-MAR-10 channel ORA_DISK_1: finished piece 1 at 27-MAR-10 piece handle=/u04/app/oracle/backup/ora11g/07ggc7qr_1_1 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:01:46 channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset including current controlfile in backupset channel ORA_DISK_1: starting piece 1 at 27-MAR-10 channel ORA_DISK_1: finished piece 1 at 27-MAR-10 piece handle=/u04/app/oracle/backup/ora11g/08ggc7u6_1_1 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03 Finished backup at 27-MAR-10
Da es sich hierbei um eine „in-memory“-View handelt, bleiben die Daten maximal bis zum nächsten Restart der Instanz erhalten. Die View fasst maximal 32.768 Einträge. Weitere Informationen findet man zudem in den Views V$RMAN_BACKUP_JOB_DETAILS, V$RMAN_ STATUS und RC_RMAN_STATUS.
11.3.9
Überwachung von Konfigurationsänderungen
Die Überwachung von Konfigurationsänderungen, sprich Änderung von Datenbankparametern, gewinnt mit zunehmender Größe und Komplexität der Systemumgebung an Bedeutung. Zudem besteht aus Sicht des Change Managements (ITIL) die Anforderung, Parameteränderungen zentral zu erfassen und zu dokumentieren. Außerdem sollte auch der DBA über Konfigurationsänderungen informiert sein, was bei Problemen die Fehlersuche erleichtert. Mit EM Database Control 11g R2 können Konfigurationsänderungen überwacht und mit früheren Einstellungen verglichen werden (siehe Abbildung 11.23). Voraussetzung für die Nutzung dieser Funktionalität ist die Lizenzierung des Database Configuration Management Packs.
536
11.3 Monitoring von Oracle Datenbanken
Abbildung 11.23 Überwachung von Konfigurationsänderungen mit dem Enterprise Manager
Eine weitere Möglichkeit, Parameteränderungen zu überwachen, ist über das Auditing des ALTER SYSTEM-Befehls. Folgende Schritte sind dazu notwendig:
Parameter AUDIT_TRAIL=DB18 setzen (bedingt einen Neustart der Datenbank) Auditing aktivieren: AUDIT ALTER SYSTEM BY <user_name>; Auch die Operationen des Users SYS sollten überwacht werden. Dies aktivieren wir mit ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=SPFILE;
Nun ist nur noch periodisch die View DBA_AUDIT_STATEMENT auszuwerten 11.3.10 Locking (Hang Manager) Mit der Version 10g R2 wurde der Hang Manager eingeführt, der Lock-Situationen in der Datenbank automatisch erkennt (siehe Abbildung 11.24 auf der nächsten Seite). Wenn eine Lock-Situation auftritt, generiert der Hang Manager automatisch Tracefiles für die weitere Diagnose. Der Hintergrundprozess „DIA0“ ist dabei verantwortlich für die Erkennung von Lock- und Deadlock-Situationen.
18
Mit AUDIT_TRAIL=DB_EXTENDED werden zudem ab Version 10g auch Bind-Variablen erfasst. Es ist jedoch die My Oracle Support Note 733924.1 „Errors ORA-07445 [kzagetcid()+13] Reported When AUDIT_TRAIL=DB_EXTENDED“ zu beachten.
537
11 Monitoring
Abbildung 11.24 Identifikation von Lock-Situationen mit Enterprise Manager Hang Analysis
11.3.11 Best-Practice (Basis-Monitoring) Gemäß der eingangs erwähnten Monitoringregel (so wenig wie möglich überwachen …) haben wir nachfolgend die wichtigsten Metriken inkl. Schwellwerten nach folgenden TargetTypen geordnet zusammengestellt:
Datenbank Server Listener Agent Praxistipp Die hier dokumentierten Schwellwerte stammen aus der Erfahrung verschiedener Kundenprojekte. Sie repräsentieren sinnvolle Startwerte, die gegebenenfalls auf Ihre Umgebung anzupassen sind. Die Kunst der Schwellwert-Definition ist, einerseits keine Informationsflut durch zu tiefe Schwellwerte auszulösen und andererseits bei wirklich kritischen Zuständen trotzdem rechtzeitig informiert zu sein.
538
11.3 Monitoring von Oracle Datenbanken Best-Practice Empfehlung für die Überwachung einer Datenbank mittels Enterprise Manager Aus der Vielzahl von Metriken haben wir die zwanzig wichtigsten ausgewählt (siehe Tabelle 11.4) und mit Schwellwerten versehen, die sich in der Praxis bewährt haben. Tabelle 11.4 Basis-Monitoring: Metriken für die Datenbanküberwachung Metrikname Archive Area Used (%)
Warning
Critical
70
85
Archiver Hung Alert Log Error Broken Job Count
ORA0
Corrupt Data Block Count
0
Data Block Corruption Alert Log Error
ORA-
Datafiles Need Media Recovery Failed Job Count Generic Alert Log Error
0 0 ORA-0*(600?|7445|4[0-9][0-9] [0-9])[^0-9]
Media Failure Alert Log Error
ORA-
Missing Media File Count
0
Owner‘s Invalid Object Count
0
Segments Approaching Maximum Extents Count
0
Segments Not Able to Extend Count
0
Session Terminated Alert Log Error
ORA-
State
MOUNTED
Status
Down
Tablespace Space Used (%) – UNDO
101
102
– All others
80
90
Tablespace Space Used (%) (dictionary managed)
80
90
Best-Practice Empfehlung für die Überwachung eines DB-Servers In vielen Fällen überwachen die Systemadministratoren bereits den Datenbankserver, was eine Überwachung mit Oracle-Mitteln überflüssig beziehungsweise redundant macht. Wo dies nicht der Fall ist, kann man mit den Metriken aus Tabelle 11.5 auch das Hostsystem überwachen.
539
11 Monitoring Tabelle 11.5 Basis-Monitoring: Metriken für die Host-Überwachung Metrikname
Warning
Critical
CPU in I/O Wait (%)
40
80
CPU Utilization (%)
80
95
Disk Device Busy (%)
80
95
Filesystem Space Available (%)
20
5
Log File Pattern Matched Line Count
0
Memory Utilization (%)
99
Status Swap Utilization (%)
Down 80
95
Best-Practice Empfehlung für die Überwachung eines Listeners Die Überwachung des Listeners beschränkt sich auf zwei Kriterien: Status und Antwortzeit. Wenn der Listener nicht läuft, ist die Datenbank nicht erreichbar. Der Status ist also eine kritische Größe, die zwingend überwacht werden muss. Responsezeiten von mehr als einer Sekunde deuten auf ein Netzwerkproblem hin und sind ebenfalls als kritisch einzustufen. Tabelle 11.6 Basis-Monitoring: Metriken für die Listener-Überwachung Metrikname Response Time (msec)
Warning 400
Status
Critical 1000 Down
Best-Practice Empfehlung für die Überwachung eines Grid Control Agents Beim Einsatz von EM Grid Control ist der Grid Control Agent für das Sammeln und Weiterleiten der Monitoringdaten an den Managementserver zuständig. Agents, die auf den Target-Servern laufen, sind bezüglich Ressourcenverbrauch und Status zu überwachen. Tabelle 11.7 zeigt die von uns empfohlenen Metrikschwellwerte. Tabelle 11.7 Basis-Monitoring: Metriken für die Agent-Überwachung Metrikname
Critical
Count of targets not uploading data
0
0
CPU Usage (%)
10
20
128000
256000
Resident Memory Utilization (KB) Status
540
Warning
Down
11.4 Monitoring-Werkzeuge
11.4
Monitoring-Werkzeuge 11.4.1
Auswahlkriterien für Monitoring-Werkzeuge
Überlegungen zu Konzept und Architektur sind bei der Auswahl von Monitoring-Werkzeugen sehr entscheidend, weil damit in der Regel wesentliche finanzielle und personelle Aufwendungen verbunden sind. Praxistipp Der in Tabelle 11.8 dargestellte Kriterien- und Fragenkatalog soll als Leitfaden für die Wahl einer Monitoring-Lösung dienen.
Tabelle 11.8 Kriterien- und Fragenkatalog für eine Monitoring-Lösung Kriterium
Erläuterung
Architektur
Welche Architektur-Richtlinien müssen erfüllt werden? Beispielsweise der Einsatz von Agents, zentrales Repository, CMDB19, Trennung von Entwicklungs-, Testund Produktions-Systemen, Sicherheit, Technologie-Standards, Skalierbarkeit etc.
Benutzer
Wer sind die zukünftigen Benutzer der Monitoring-Lösung? Werden diese Benutzer in die Evaluation mit einbezogen?
Einsatzbereich
Dient die Lösung ausschließlich dem Monitoring oder auch der Systemverwaltung?
Erweiterbarkeit
Wie einfach lässt sich das Monitoring funktional erweitern (beispielsweise Einbau von neuen Tests)? Von wem werden die Erweiterungen realisiert und mit welchen Kosten ist zu rechnen?
Integration
Muss die Monitoring-Lösung in eine bestehende Monitoring-Infrastruktur integriert werden? Welche Schnittstellen existieren und wie groß ist der Integrationsaufwand?
Kosten
Wie groß ist das Budget für Lizenz-, Implementierungs- und Unterhaltskosten? Wurden die wiederkehrenden Kosten in der Planung berücksichtigt? Nicht vergessen: Lizenzierung der Enterprise Manager Packs.
Lifecycle
Sowohl die Monitoring-Lösung als auch die zu überwachenden Objekte unterliegen einem bestimmten Lebenszyklus. Die daraus resultierenden Abhängigkeiten sind in die Planung mit einzubeziehen (Releaseabhängigkeiten, Technologieabhängigkeiten etc.).
Mengengerüst
Wie viele Targets müssen überwacht werden und wie heterogen sind die Monitoringobjekte? Wie verändert sich die Systemumgebung mittel- und langfristig?
Produktwahl
Müssen zwingend die Produkte eines bestimmten Herstellers eingesetzt werden oder sind Alternativen wie Open-Source-Produkte denkbar? Tipp: Nicht alles auf ein Pferd setzen.
19
CMDB: Configuration Management Database, zentrale Datenbank für das Konfigurationsmanagement
541
11 Monitoring Kriterium
Erläuterung
Sicherheit
Erfüllt die Monitoring-Lösung die unternehmensweiten Sicherheitsrichtlinien? Wie flexibel können die Sicherheitsmechanismen an zukünftige Anforderungen angepasst werden?
Technische Anforderungen
Welche technischen Anforderungen muss die Monitoring-Lösung erfüllen? Dazu ist eine detaillierte Spezifikation zu erstellen.
Verfügbarkeit
Wie verfügbar muss die Monitoring-Lösung sein? Was bedeutet es für die Unternehmung, wenn die Monitoring-Lösung nicht verfügbar ist? Welche Alternativlösungen stehen bei einem Systemausfall zur Verfügung? Wichtig: Die Verfügbarkeitsanforderung der überwachten Datenbanken bestimmt im Allgemeinen auch die Verfügbarkeit der Monitoring-Infrastruktur.
Praxistipp Werfen Sie für das Monitoring nicht alle Sicherheitsregeln über Bord. Die meisten MonitoringWerkzeuge beziehen ihre Informationen direkt aus der Datenbank, das heißt aus Data-DictionaryTabellen wie beispielsweise V$SESSION oder V$SQLAREA. Der dazu verwendete Oracle Account muss demzufolge lediglich in der Lage sein, auf genau die benötigten Objekte zuzugreifen – nicht mehr und nicht weniger. In der Praxis wird dieser Account jedoch sehr oft mit System- und Objektprivilegien ausgestattet, die für seine eigentliche Aufgabe – das Monitoring – gar nicht notwendig sind. Monitoring-Accounts mit dem Privileg SELECT ANY TABLE oder gar der DBA-Rolle sind keine Seltenheit!
11.4.2
Database Control / Grid Control
Wenn man Tiefe, Detaillierungsgrad und Aktualität des Oracle Enterprise Managers mit Monitoring-Lösungen anderer Hersteller vergleicht, ist der Enterprise Manager in den beiden Ausprägungen Database Control und Grid Control ohne Zweifel das Tool der Wahl für die Überwachung und die Verwaltung von Oraclesystemen. Man muss jedoch die Lizenzkosten im Auge behalten, wenn Erweiterungen wie das Provisioning Pack, Change Management Pack, Tuning Pack, Configuration Pack, Diagnostic Pack oder eines der zahlreichen Management-Plugins eingesetzt werden. Der Oracle Enterprise Manager wird in Kapitel 1 „Schnelleinstieg“ vorgestellt. 11.4.2.1
Monitoring-Templates
Um bei größeren Systemumgebungen den Konfigurationsaufwand für den Enterprise Manager möglichst gering zu halten und vor allem zu standardisieren, sind MonitoringTemplates sinnvoll. Sie ermöglichen die unternehmensweite Definition von Metrik- und Policy-Settings für einen bestimmten Target-Typ. Monitoring-Templates sind damit eine Ergänzung zu den Metrik-Baselines und Policies. Die in den Templates festgelegten Metrik- und Policy-Settings überschreiben die Defaultwerte bzw. kommen als neue Defaultwerte zur Anwendung.
542
11.4 Monitoring-Werkzeuge Praxistipp Belassen Sie nur die wirklich wichtigen Metriken im Template. Alle anderen Metriken sollten Sie daraus entfernen. Das verhindert eine unkontrollierte Meldungsflut aufgrund von (ungewollten) Metrikverletzungen.
11.4.3
Health Monitor
Mit dem Automatic Health Monitoring – einem 11g-Feature – kann die Datenbank auf einfache Art und Weise einer Prüfung unterzogen werden. Dabei handelt es sich um ein vordefiniertes Set von Health Monitoring Checks (HM-Checks), die folgende Komponenten auf ihren Zustand überprüft:
Logical Block Check Table Row Check Transaction Check Undo Segment Check Data Block Check Table Check Table Index Row Mismatch Database Dictionary Check Table Index Cross Check Die View V$HM_CHECK liefert eine aktuelle Liste der HM-Checks. Die Prüfung selber erfolgt entweder reaktiv, sprich automatisch aufgrund eines kritischen Fehlers in der Datenbank, oder manuell. Die manuelle Prüfung kann mit dem PL/SQL-Package DBMS_HM oder über den Enterprise Manager erfolgen. Typischerweise führt man die Prüfung im DBOnline-Modus durch, das bedeutet, die Datenbank muss gemountet oder offen sein. Redound DB-Structure Integrity Checks sind jedoch auch bei geschlossener Datenbank (DBOffline-Mode) möglich; die Instanz muss dazu jedoch gestartet sein (NOMOUNT). Praxistipp Automatisieren Sie die HM-Checks. Mit dem Scheduler lassen sich die Health Checks einfach beispielsweise einmal wöchentlich ausführen:
Die RUN_CHECK-Prozedur generiert einen Report, der im XML-Format im Automatic Diagnostic Repository abgelegt wird. Anschließend ist dieser Report via V$HM_RUN, DBMS_HM, ADRCI oder dem Enterprise Manager einsehbar: adrci> show hm_run adrci> create report HM_RUN DicCheck adrci> show report HM_RUN DicCheck
543
11 Monitoring
11.4.4
SQL Developer
Der Oracle SQL Developer ist ein kostenloses grafisches Tool, das primär für SQL- und PL/SQL-Entwickler geschrieben ist. Viele der mitgelieferten Skripte eignen sich jedoch auch für die Überwachung von Datenbanken, sodass der SQL Developer auch für den DBA interessant ist. Seit Version 1.5.4 verfügt dieser zudem über das „Real-Time SQL Monitor“-Feature, das die Laufzeitanalyse von SQL-Code ermöglicht. Die Entwicklung, Verwaltung und Ausführung von eigenen Skripts ist mit der grafischen Oberfläche einfach zu bewerkstelligen. Erwähnenswert sind die Erweiterungen von weiteren Toolanbietern. Ein interessantes Plug-In, das sich für die Datenbanküberwachung eignet, ist der Insider der Firma FourthElephant (siehe Abbildung 11.25). Ausgehend von einer dynamischen Gesamtübersicht, die das Zusammenspiel der einzelnen Datenbankkomponenten visualisiert, lassen sich die einzelnen Datenbankkomponenten wie DB-Buffer, SGA oder Redo-Log-Files überwachen.
Abbildung 11.25 Monitoring-Plugin für den SQL Developer (Insider von FourthElephant)
11.4.5
Werkzeuge anderer Tool-Anbieter
Im Vergleich zu den Tools von Oracle sind Monitoring-Werkzeuge von Drittanbietern in der Regel breiter positioniert, was die Unterstützung unterschiedlicher Technologien und Hersteller betrifft. Andererseits weisen diese Produkte in der Regel eine geringere Technologietiefe aus oder müssen mit eigenen Programmen und Skripten erweitert werden.
544
11.5 Resümee Für mittlere und größere Datenbankumgebungen haben sich aufgrund der Flexibilität, Erweiterbarkeit und vorteilhaftem Lizenzmodell folgende Produkte20 bei zahlreichen Kunden bewährt:
Nimbus von Nimsoft (http://www.nimsoft.com/) ist eine umfassende, serviceorientierte Monitoringlösung mit breiter Technologie-Abdeckung (Netzwerk, Server, Datenbanken, Applikationen, Services, Endbenutzer), End-to-End-Antwortzeitüberwachung, SLAMonitoring, Business-Service-Dashboards etc.
BigSister (http://www.bigsister.ch/), ein Open-Source-Produkt und universelles Framework, mit PERL einfach erweiterbar.
Nagios (http://www.nagios.org/) ist eine umfassende Monitoringlösung mit zahlreichen Plug-Ins; mit ORCA sind auch Trendanalysen möglich. Weitere Tools:
TOra (http://torasql.com/) ist ein Open-Source-Produkt für Entwickler und DBAs. Es unterstützt neben Oracle die gängigsten Datenbankprodukte.
Oracle-Admin (http://oracleadmin.sourceforge.net/) ist ein Open-Source-Produkt das dem Enterprise Manager sehr ähnlich sieht.
Hyperic (http://www.hyperic.com/products/oracle-monitoring/) ist ein kommerzielles Monitoringprodukt für die Überwachung von heterogenen Umgebungen.
11.5
Resümee In diesem Kapitel haben Sie die wichtigsten Konzepte und Tools für die Überwachung einer Oracle 11g Datenbank kennengelernt. Mit den Möglichkeiten von Metriken, Policies, Server Generated Alerts, User Defined Metrics, Monitoringtemplates, Baselines und deren Integration in den Oracle Enterprise Manager stellt Oracle eine Monitoringlösung zur Verfügung, die (fast) keine Wünsche offenlässt. Wenn Sie aus bestimmten Gründen ein Nicht-Oracle-Produkt für die Datenbanküberwachung einsetzen möchten, stehen diverse Alternativen zur Verfügung. Eine sorgfältige Evaluation anhand der vorgestellten Kriterien ist auf jeden Fall zu empfehlen. Im Zweifelsfall investieren Sie jedoch besser Zeit in die Konfiguration von Metriken und Schwellwerten als in Eigenbaulösungen, die dann doch nicht alle Bedürfnisse abdecken. Last but not least – beherzigen Sie den bewährten Monitoring-Grundsatz, soviel wie nötig, aber das Richtige zu überwachen.
20
Die Auswahl der erwähnten Produkte basiert auf den persönlichen Erfahrungen des Autors.
545
11 Monitoring
546
12 12 Aufbau und Betrieb eines Datenbankservers In diesem Kapitel zeigen wir Ihnen:
die Auswahl der Oracle-Plattform; Berechtigungskonzept auf Betriebssystemebene; das Oracle-Verzeichnisstruktur; die Verwaltung des Oracle-Environments; den Betrieb eines Datenbankservers. Die grundlegende Architektur eines Datenbankservers sowie der physische und logische Aufbau einer Datenbank wurden bereits in den vorangehenden Kapiteln vorgestellt. In diesem Kapitel zeigen wir nun den Lifecycle eines Datenbankservers anhand der Phasen „Evaluation“, „Implementation“, „Betrieb“ und „Optimierung“ und stellen die damit verbundenen Tätigkeiten vor.
12.1
Der Lifecycle eines Datenbankservers Der Lifecycle eines Datenbankservers beginnt mit der Evaluation der Serverplattform, also der Prozessor-Architektur. Architekturbestimmende Themen wie Verfügbarkeit, Skalierbarkeit, Provisionierbarkeit sowie Rahmenbedingungen wie Plattformstrategie und Applikations-Lifecycle sind wesentliche Einflussgrößen bei der Evaluation der Serverplattform. Methoden wie Requirements Engineering, Proof-of-Concept (PoC) und auch Benchmarks helfen dabei. In der Implementationsphase erwachen die Architekturkonzepte zum Leben. Es entsteht die Grundlage für den effizienten Betrieb des Datenbankservers. Man muss sich an dieser Stelle bewusst sein, dass die Betriebsphase normalerweise wesentlich länger dauert als die Evaluations- und Implementationsphase. Das heißt, Entscheidungen bei der Evaluation
547
12 Aufbau und Betrieb eines Datenbankservers und der Implementation wirken sich langfristig aus – im Guten wie im Schlechten. Wir empfehlen daher bei der Implementation eines Datenbankservers bewährte Standards, wie sie nachfolgend beschrieben sind, sowie die Richtlinien von Oracle zu berücksichtigen.
Evaluation Requirements Engineering Proof of Concept Benchmarking
Optimierung Tuning Automatisierung
Implementation Architekturstandards Planung Installation und Konfiguration
Betrieb Betriebsstandards und SLAs Monitoring / Reporting Backup & Recovery Maintenance
Abbildung 12.1 Lifecycle eines Datenbankservers
Die Betriebsphase, die mehrere Jahre dauern kann, ist geprägt von Standard-Aktivitäten wie Monitoring, Backup sowie Pflege von Server, Betriebssystem, Software und Datenbank. Im Betrieb zeigt sich, ob die erwähnten architekturbestimmenden Themen wie beispielsweise die Serviceverfügbarkeit genügend Beachtung bekommen hat. Aus Erfahrung der Autoren sind die Automatisierung der Unterhaltsaktivitäten und der Einsatz bewährter Hilfsmittel, wie sie in Abschnitt 12.6 beschrieben sind, keine Option − sondern ein Muss. Natürlich gehört auch die Optimierung zum Lifecycle des Datenbankservers und der Datenbanken. Diese geht über den normalen Unterhalt hinaus und bedingt meistens eine Systemänderung wie beispielsweise die Änderung eines Parameters oder den Austausch einer Hardwarekomponente. Eine Optimierung lässt sich typischerweise nicht automatisieren und bedingt meist Spezialistenwissen. Auf Hardware- und Server-Optimierung gehen wir in diesem Kapitel nicht weiter ein und verweisen auf das Kapitel 8 „Optimierung“, wo wir detailliert auf die Optimierungsmöglichkeiten auf Instanz- und SQL-Befehlsebene eingehen.
12.2
Oracle-Plattform Die Wahl der Oracle-Plattform ist eine wichtige Entscheidung, die in der Evaluationsphase eines Datenbankservers getroffen werden muss. Der Begriff „Oracle-Plattform“ bezeichnet die Betriebssystem-Familie des Datenbankservers. Daraus leitet sich implizit die CPUArchitektur ab. So handelt es sich beispielsweise bei der Plattformbezeichnung „Linux x86-64“ um ein Linux-Derivat, das auf einem Intel x86 64-Bit-Prozessor läuft. Im folgenden Abschnitt gehen wir auf die wichtigsten Auswahlkriterien ein und zeigen die Abhängigkeiten auf, welche bei der Wahl der Oracle-Plattform berücksichtigt werden müssen.
548
12.2 Oracle-Plattform Empfehlungen zur Oracle-Plattform Bei der Plattformauswahl stellt sich früher oder später die Frage: „Welche Plattform erfüllt meine Anforderungen am besten?“ Um es gleich vorwegzunehmen: „There is no silver bullet in choosing the right platform.“ Welche Plattform die „Beste“ ist hängt von vielen Faktoren ab. Es kommt auf das Geschäftsmodell an, was Sie mit der Datenbank erreichen wollen (oder müssen), wie groß die Datenmenge sein wird, welcher Lifecycle zu berücksichtigen ist, welches Technologie-Portfolio eingehalten werden muss, ob Sie ein Data Warehouse oder eine Webapplikation planen etc. Im Allgemeinen ist die Auswahl umso kleiner je höher die Anforderungen an die Verfügbarkeit, die Performance und die Funktionalität sind, weil damit das Datenbanksystem als Ganzes komplexer wird und nicht alle Plattformen dafür gleich gut geeignet sind. Im Speziellen sind die Plattform-Empfehlungen für RAC (Real Application Cluster) zu erwähnen, für die Oracle genaue Richtlinien1 vorgibt. Damit die „Plattformdiskussion“ nicht in einer (emotionalen) Grundsatzdiskussion endet, empfehlen wir, einen Anforderungskatalog zu erstellen und die Rahmenbedingungen so vollständig wie möglich zu beschreiben.
Abbildung 12.2 Zertifizierte Plattformen für Oracle 11gR2
Aus der Oracle-Plattformstrategie, der Lifetime Support Policy und der Erfahrung der Autoren lassen sich folgende Empfehlungen ableiten:
Oracle-Datenbanken sollten nur auf Plattformen betrieben werden, die Oracle mittelund langfristig unterstützt. Eine entsprechende Planungshilfe ist auf My Oracle Support publiziert2.
Oracle sollte nur auf zertifizierten Plattformen betrieben werden. Abbildung 12.2 zeigt die für Oracle 11g R2 zertifizierten Plattformen. Die Zertifizierungsinformationen sind auf My Oracle Support publiziert (siehe Abbildung 12.3). 1 2
RAC: Frequently Asked Questions: My Oracle Support Note 220970.1 Zertifizierte Oracle-Plattformen: My Oracle Support Note 742060.1
549
12 Aufbau und Betrieb eines Datenbankservers
Abbildung 12.3 Zertifizierungsinformation auf My Oracle Support
Oracle sollte außerdem auf einer Plattform betrieben werden, die zum bereits vorhandenen Technologie-Portfolio passt und für deren Betrieb im Unternehmen Erfahrung vorhanden ist. Fehlt das notwendige Wissen, ist zu überlegen, ob man das Know-how aufbaut oder von extern bezieht. Die Auslagerung des Datenbankservices an einen spezialisierten Dienstleister im Rahmen eines Service-Level-Vertrags ist in vielen Fällen eine sinnvolle Option.
Bleibt die Frage: Unix/Linux oder Windows? Aus Sicht der Zertifizierung lässt sich eine Oracle-Datenbank sowohl auf einer Unix/Linux- als auch auf einer WindowsPlattform betreiben. Wenn jedoch vom Applikationshersteller Windows als Plattform nicht explizit gefordert wird und keine zusätzlichen Restriktionen vorliegen, empfehlen wir Oracle auf Oracle Enterprise Linux3 (OEL, 64-Bit) zu betreiben. Dies ist auch die Entwicklungsplattform für die Oracle-Datenbank. Oracle auf Linux hat zudem inzwischen den größten Verbreitungsgrad. Das bedeutet, dass damit mehr Erfahrungen existieren als mit anderen Plattformen und somit Softwarefehler früh erkannt, publiziert und behoben werden. Nicht zu unterschätzen ist zudem die aktive Linux-User-Community und der entsprechend rege Know-how-Austausch.
Beachten Sie plattformspezifische Einschränkungen. Diese können die Verfügbarkeit von Oracle-Releases, zukünftige Support-Einschränkungen4, oder technische Limitierungen wie die maximal unterstützte Anzahl CPUs5 betreffen.
12.3
Betriebssystembenutzer und Berechtigungen 12.3.1 Software-Owner und Betriebssystembenutzer Owner der RDBMS-Software und der Datenbank ist typischerweise der User oracle. Entsprechend werden auch alle RDBMS-Prozesse unter dem User oracle ausgeführt. Ist auf dem gleichen Server auch die Grid-Infrastrukur (CRS und ASM) installiert und soll das Prinzip der Funktionstrennung („segregation of duties“: Trennung von DatenbankAdministration und Cluster/Storage-Administration) implementiert werden, sollte die Installation der Grid-Infrastruktur unter dem User grid erfolgen. Das Prinzip der Funktions3
https://linux.oracle.com http://www.oracle.com/itanium 5 Maximum Number of CPU cores Supported by a Single Linux System: My Oracle Support Note 559611.1 4
550
12.3 Betriebssystembenutzer und Berechtigungen trennung ist eine Empfehlung von Oracle, die wir ebenfalls unterstützen − sie ist aber keine zwingende Voraussetzung für den Betrieb. Es ist durchaus möglich, die Datenbanksoftware und die Grid-Infrastruktur unter dem gleichen User (oracle) zu installieren. Praxistipp Die beiden Benutzer oracle und grid sollte man als funktionale User-Accounts betrachten, die nur für Installationen und Updates erforderlich sind. Für Administrationsaufgaben verbindet man sich mit einem persönlichen Betriebssystem-Account, der mit entsprechenden sudo-Rechten ausgestattet sein muss. Sudo gibt ausgewählten Benutzern die Möglichkeit, bestimmte Programme mit den Rechten des Users oracle beziehungsweise grid auszuführen, ohne deren Passwort kennen zu müssen. Welcher User welche Programme oder Befehle ausführen darf, ist vom Super-User root in der Datei /etc/sudoers definiert. Der Hauptgrund für den Einsatz des sudo-Konzeptes liegt in der Nachvollziehbarkeit6 von Systemaktivitäten.
12.3.2 Home-Verzeichnis der User „oracle“ und „grid“ Ab 11g verlangt der Oracle Universal Installer, dass das Home-Verzeichnis des SoftwareOwners nicht im „ORACLE_HOME“-Pfad liegen darf. Wir empfehlen daher, für den oracle-User /home/oracle und für den grid-User /home/grid als Home-Verzeichnis zu definieren.
12.3.3 Betriebssystemgruppen Oracle benötigt mindestens eine Betriebssystemgruppe, die Oracle Inventory Gruppe oinstall. Der Name dieser Gruppe muss mit dem Eintrag im File oraInst.loc (inst_group=oinstall) übereinstimmen. Betriebssystembenutzer, die Mitglied dieser Gruppe sind, dürfen die beiden Files oraInst.loc und oratab modifizieren, das heißt, sie können Software-Installationen durchführen. Normalerweise ist die Gruppe oinstall die Primary-Gruppe der Software-Owner oracle und grid. Bei mehreren Software-Ownern pro Server verwaltet man die administrativen Privilegien durch Zuweisung von bestimmten OS-Gruppen. Diese OS-Gruppen sollten vor der Software-Installation vorhanden sein. Das nachträgliche Erstellen von OS-Gruppen bedingt ein Relink der Oracle-Binaries7. Folgende Gruppen sind auf einem Unix-Server typischerweise notwendig:
OSDBA: User dieser Gruppe haben administrative Privilegien auf der Datenbank (SYSDBA-Privileg) bzw. auf der ASM-Instanz. Für diese Gruppe sollte man den Namen dba bzw. asmdba verwenden.
OSOPER: User dieser Gruppe haben eingeschränkte administrative Privilegien auf der Datenbank (SYSOPER-Privileg), bzw. auf der ASM-Instanz. Für diese Gruppe empfiehlt sich der Name oper bzw. asmoper. 6 7
Die Nachvollziehbarkeit ist ein Hauptkriterium im Kontext von „Compliance“-Anforderungen SYSDBA and SYSOPER Privileges in Oracle: My Oracle Support Note 50507.1
551
12 Aufbau und Betrieb eines Datenbankservers
OSASM: User dieser Gruppe haben administrative Privilegien auf ASM-Instanzen (SYSASM-Privileg), sie können beispielsweise Diskgruppen mounten und dismounten. Für diese Gruppe bietet sich der Name asmadmin an (gilt ab 11g R2). Im folgenden Beispiel sehen wir die Gruppenzugehörigkeiten der beiden User oracle und grid. oracle ist der Owner der Datenbanksoftware und grid ist der Owner der Grid-
Infrastruktur. Die Primary-Gruppe beider User ist oinstall. oracle@artemis> id uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba), 503(asmdba),505(oper) grid@artemis> id uid=600(grid) gid=500(oinstall) groups=500(oinstall),502(asmadmin), 503(asmdba),504(asmoper)
Unter Windows werden bei der Installation die beiden Gruppen ORA_DBA und ORA_OPER erstellt. Analog wie unter Unix erhalten die Windows-User über die Gruppenzugehörigkeit das SYSDBA-, resp. das SYSOPER-Privileg8.
12.3.4 File-Permissions, Ownership und umask Der Oracle Universal Installer setzt die Berechtigungen auf Dateien und Verzeichnisse bei der Softwareinstallation korrekt. Datenfiles, Redologfiles, Controlfiles und Archivelogfiles sowie Log-, Trace-, und Auditfiles erhalten unter Unix die Fileberechtigung 660. Eine sogenannte „Umask“ schränkt diese Berechtigungen automatisch ein. umask (user file creation mode mask) ist ein Unix-Shell-Kommando, das die Default-Berechtigungen (Read-, Write-, und Execute-Operationen) für neue Dateien setzt. Umask wird im Profil des Users oracle und grid definiert. Die Umask-Settings stellen sicher, dass Datenbankfiles sowie Log- und Tracefiles nur für berechtigte Benutzer zugreifbar sind. Eine detaillierte Beschreibung von umask ist auf My Oracle Support9 zu finden. Oracle empfiehlt, die Umask für den Software-Owner (oracle oder grid) auf „022“ zu setzen. Dies reduziert die Fileberechtigung auf den Wert „640“, was folgender Berechtigung entspricht: user group others rw- r----
Somit haben Benutzer, die nicht Mitglied einer Oracle-Gruppe sind (others), keinen Zugriff auf diese Dateien. Die Ownership setzt sich aus Username und Gruppenname zusammen: oracle:oinstall
Die Ownership von Oracle-Binaries und Verzeichnissen sollte auf keinen Fall geändert werden, weil sonst unter Umständen gewisse Prozesse nicht mehr funktionieren.
8
All About Security: User, Privilege, Role, SYSDBA, O/S Authentication, Audit, Encryption, OLS, Database Vault, Audit Vault: My Oracle Support Note 207959.1 9 My Oracle Support Note 68304.1: What is Umask?
552
12.4 Oracle-Verzeichnisstruktur Praxistipp Berechtigungen und Ownership auf Datei- und Verzeichnisebene sollten Sie aus Sicherheitsgründen nicht ändern. In den meisten Fällen ist der restriktive Zugriffsschutz auf Log- und Tracefiles gerechtfertigt. Trotzdem ist es in gewissen Situationen notwendig, die Tracefiles für Analysezwecke einem User zugänglich zu machen, der aufgrund seiner Gruppenzughörigkeit keinen Zugriff hat. Mit dem Befehl SQL> alter system set "_trace_files_public"=true scope=spfile; kann der Datenbank-Administrator Tracefiles zugänglich machen. Zwei Punkte sind dabei zu beachten: Erstens ist diese Parameteränderung erst nach einem Neustart der Instanz und nur für neu erzeugte Tracefiles aktiv10. Zweitens besteht die Gefahr, dass unberechtigte Benutzer auf vertrauliche Daten zugreifen können, insbesondere wenn Bindvariablen-Werte und SQL-Statements in den Tracefiles vorhanden sind.
12.4
Oracle-Verzeichnisstruktur Was die Verzeichnisstruktur betrifft, ist ein Oracle-Server ein sehr komplexes Gebilde. Selbst ein einfacher Datenbankserver mit einem „ORACLE_HOME“ und einer Datenbank besteht aus Hunderten von Software-, Konfigurations- und Datenfiles. Ein Teil dieser Dateien ist in sogenannten „Repositories“ – von Oracle angelegte Verzeichnisstrukturen – verwaltet. Beispiele solcher Repositories sind das Automatic Diagnostic Repository (ADR) und das Inventory des Oracle Universal Installers. Für die Repositories muss der Einstiegspunkt definiert sein; die interne Struktur wird von Oracle vorgegeben und verwaltet. Für alle anderen Dateien existieren Empfehlungen für Name und Lokation. Sie lassen sich aber grundsätzlich frei an die individuellen Bedürfnisse anpassen. Diese Wahlfreiheit birgt – sofern sie nicht durch Standards eingeschränkt ist – naturgemäß gewisse Gefahren, die sich in einem größeren Wartungsaufwand und einer erhöhten Fehlerquote auswirken können. Im folgenden Abschnitt zeigen wir, wie eine standardisierte Verzeichnisstruktur für einen Oracle-Datenbankserver aussieht und wie man damit den Administrationsaufwand verringern kann.
12.4.1 Optimal Flexible Architecture (OFA) Oracle beschreibt OFA als ein „Set von Dateinamen- und Konfigurationsrichtlinien, die einen zuverlässigen und wartungsarmen Betrieb von Oracle-Installationen sicherstellen soll“. OFA regelt also im Wesentlichen, an welchem Ort und unter welchem Namen die diversen Oracle-Dateien abgelegt sein sollten. Die OFA-Guidelines sind 1995 in Form eines Whitepapers11 erschienen. Das Konzept hat sich in der Praxis durchgesetzt und gilt als Standard sowohl für Unix-, als auch für Windows-Server. Die Hauptgründe für den Einsatz von OFA sind: 10 11
Zudem sollte man undokumentierte Parameter auf Produktions-Datenbanken zurückhaltend verwenden Cary V. Millsap; The OFA Standard: Oracle for Open Systems; Oracle Corporation, 1995
553
12 Aufbau und Betrieb eines Datenbankservers
Gleiche Verzeichnisstruktur für alle Server, unabhängig von der Plattform und der Hardware. Das erleichtert die System- und die Datenbank-Administration.
Gleiche Standards für Single-Server/Single-Instanz, RAC, Data Guard und Failovercluster
Klar definierter Ort für jede Datei. Dies erleichtert die Orientierung auf dem System. Zudem kann die Navigation durch standardisierte Aliase unterstützt werden.
Kleinerer Aufwand bei Releasewechsel, Migration und Patching Einsatz von Standardskripts für Administrationsaufgaben wie Backup und Monitoring Eine detaillierte Beschreibung der OFA-Implementierung ist im Anhang des „Oracle Database Installation Guide 11g R2 (11.2)“ zu finden.
12.4.2 Die „/u00“-Philosophie Ein wichtiges Element der OFA-Architektur ist der zentrale Bezugs- und Einstiegspunkt für sämtliche „ORACLE_HOME“-Verzeichnisse12, die instanzspezifischen Administrations-Verzeichnisse, die Inventardateien, die Netzwerkdateien sowie das Automatic Diagnostic Repository. Wir bezeichnen den entsprechenden Mountpoint mit /u00. Oracle verwendet /u01, wobei weniger die Bezeichnung an sich entscheidend ist, sondern viel mehr das Konzept eines dedizierten Bezugpunkts, der nach der Notation /<string> bezeichnet ist. Der Vorteil eines Bezugspunkts ist, dass in sämtlichen Setup-Skripts und Installationstools immer der gleiche Pfad verwendet werden kann – unabhängig davon, wie das darunterliegende Filesystemlayout definiert ist. Außerdem können bei knappen Platzverhältnissen unter /u00 die betroffenen Verzeichnisse mit wenig Aufwand auf ein anderes Filesystem ausgelagert werden. In der Praxis werden im Betrieb sich in Zahl und Größe laufend ändernde Dateien wie Log- und Tracefiles häufig mittels symbolischen Links aus dem /u00-Filesystem in ein Verzeichnis mit ausreichend Platz verlinkt. Praxistipp Auch unter Windows lässt sich die „/u00“-Philosophie mit symbolischen Links umsetzen. Anstelle von /u00 wird ein Laufwerk (beispielsweise D:\) verwendet. Seit Windows 2008 und Windows 7 stehen symbolische Links zur Verfügung. Die Links werden mit dem Programm mlink erstellt. Für ältere Windows-Versionen kann das Hilfsprogramm Junction13 verwendet werden.
Die „/u00“-Philosophie wird auch auf die Archivelog-Verzeichnisse angewandt. Die Archivelog-Destination zeigt per Default auf das Verzeichnis /u00/app/oracle/admin/ 12
Die „/u00“-Philosophie lässt sich sinngemäss auch auf das von Oracle vorgeschlagene Defaultverzeichnis „/u01“ anwenden 13 Junction ist ein Programm, das die Erstellung von symbolischen Verknüpfungen erlaubt (siehe http://technet.microsoft.com/de-de/sysinternals/bb896768). Es ist jedoch zu beachten, dass Junction für Network-Drives nicht eingesetzt werden kann
554
12.4 Oracle-Verzeichnisstruktur <SID>/arch. Weil jedoch unter dem Mountpoint /u00 keine Datenbankdateien (Redologfiles, Controlfiles, Datenfiles und Tempfiles) gespeichert werden sollten, wird das Archivelog-Verzeichnis mit einem symbolischen Link auf ein anderes Filesystem wie /umm/app/ oracle/admin/<SID>/arch umgeleitet. Der Standardeinstiegspunkt /u00 bleibt jedoch bestehen.
12.4.3 Mountpoints Pro Disk bzw. pro Diskset ist nur ein Mountpoint definiert, auf dem datenbankrelevante Daten gespeichert sind. Der Datenbank-Administrator kann damit die Dateien über mehrere Disks verteilen, ohne das Disksubsystem im Detail kennen zu müssen. Aus Gründen der Redundanz sollten mindestens drei, besser vier oder mehr OFA-Mountpoints zur Verfügung stehen. Zudem sollte man Oracle-Dateien grundsätzlich immer auf einem OFA-Filesystem platzieren. Das Default-Namensschema für die Mountpoints lautet /u[0-9][0-9]. Viele Anwender verwenden andere Mountpoint-Bezeichnungen. Entscheidend ist dabei weniger der Name des Mountpoints (wir empfehlen natürlich das obige Namensschema), sondern die physische Trennung der Filesysteme bzw. physischen Devices, auf denen die Mountpoints basieren.
12.4.4 Der OFA-Verzeichnisbaum Kernpunkt der OFA-Verzeichnisstruktur ist die Trennung zwischen Software/Administrationsfiles und Datenbankdateien. Abbildung 12.4 auf der nächsten Seite zeigt, wie diese Separierung implementiert ist. Die Software und die Administrations- und Konfigurationsfiles liegen unter dem Mountpoint /u00. Hier sind auch die „ORACLE_HOME“-Verzeichnisse, die Netzwerkkonfigurationsfiles, das Automatic Diagnostic Repository, das Inventory sowie die SID-spezifischen Administrationsfiles. Mit Ausnahme des Verzeichnisses diag, in dem die Log- und Tracefiles verwaltet werden, ist der Platzverbrauch der Verzeichnisse unter /u00 relativ statisch. Sollte der Platz trotzdem nicht mehr ausreichen, kann man die Unterverzeichnisse von /u00 jederzeit in ein Filesystem mit mehr Platz verlinken, ohne die „/u00“-Struktur ändern zu müssen. Unter /unn sind die Datenbankfiles getrennt nach SID abgelegt. Aus Gründen der Redundanz14 empfehlen wir, mindestens zwei Filesysteme für die Datenbankfiles einschließlich der Control- und Redolog-Files anzulegen. Je ein weiteres Filesystem stehen für die Fast Recovery Area (FRA) und für die Archivelog-Destinationen zur Verfügung.
14
Redundanz bedeutet in diesem Kontext auch die logische Trennung von wichtigen Dateien, um Fehlmanipulationen entgegenzuwirken. Das Argument „Ich hab ja ein SAN und darum brauche ich keine drei Controlfiles ...“ lässt sich so leicht entkräften.
555
12 Aufbau und Betrieb eines Datenbankservers
Abbildung 12.4 OFA-4-Verzeichnisstruktur: ein RDBMS auf Unix
12.4.5 ORACLE_BASE Das „ORACLE_BASE“-Verzeichnis bezeichnet den Mountpoint, unter dem eine oder mehrere Oracle-Software-Installationen eines bestimmten Users (typischerweise oracle oder grid) installiert sind. Unter Unix zeigen die Umgebungsvariablen $ORACLE_BASE bzw. %ORACLE_BASE% unter Windows auf das ORACLE_BASE-Verzeichnis. $ORACLE_BASE=/u00/app/<username> $ORACLE_BASE=/u00/app/oracle $ORACLE_BASE=/u00/app/grid %ORACLE_BASE%=DRIVE_LETTER:\app\<username> %ORACLE_BASE%=d:\app\oracle %ORACLE_BASE%=d:\app\grid
Mit Einführung der Grid-Infrastruktur kam ab Version 11g ein zweites ORACLE_BASE: /u00/app/grid. Aus Gründen der Funktionentrennung zwischen Datenbankadministration und Cluster/Storage-Administration empfehlen wir, konsequenterweise als Owner den User grid zu definieren.
556
12.4 Oracle-Verzeichnisstruktur
12.4.6 ORACLE_HOME Abgeleitet aus ORACLE_BASE ergibt sich das jeweilige „ORACLE_HOME“-Verzeichnis für Unix bzw. Windows: $ORACLE_HOME=$ORACLE_BASE/product/11.2.0.2/db_1 %ORACLE_HOME%=%ORACLE_BASE%\product\11.2.0.2\dbhome_1
Mit Einführung des ersten Patchsets für 11g R2 hat Oracle begonnen, das Releaseverzeichnis vierstellig zu benennen (11.2.0.2), während früher eine dreistellige Notation (10.1.0, 10.2.0, 11.1.0, 11.2.0) zum Einsatz kam. Für die Grid-Infrastruktur ist das „ORACLE_HOME“-Verzeichnis ebenfalls aus „ORACLE_BASE“ abgeleitet, wobei das product-Verzeichnis nicht vorkommt: $ORACLE_HOME=/u00/app/grid/11.2.0.2
12.4.7 Shared-Home-Installationen Bei einer Shared-Home-Installation nutzen mehrere Datenbanken das gleiche „ORACLE_HOME“-Verzeichnis. Auf der einen Seite ist damit der Wartungsaufwand geringer, auf der anderen Seite sind bei einem Releasewechsel oder beim Patchen der OracleSoftware alle Datenbanken des betreffenden Homeverzeichnisses von der Wartung betroffen. Oracle empfiehlt ab Release 11.2.0.2, den Upgrade wenn möglich „Out-of-Place“ durchzuführen15. Das heißt, jedes Patchset entspricht einer eigenständigen Oracle-Installation, die ein eigenes „ORACLE_HOME“-Verzeichnis benötigt. Dies führt automatisch zu einer Multi-Home-Installation.
12.4.8 Multi-Home-Installationen Sind mehrere Oracle-Versionen und mehrere SIDs auf einem Server installiert, spricht man von einer Multi-Home-Installation. Diese ist in vielerlei Hinsicht flexibler als SingleHome-Installationen. Es ist jedoch ein Mehraufwand bei der Softwarewartung erforderlich. Eine Multi-Home-Installation hat beispielsweise folgende „ORACLE_HOME“-Verzeichnisse: /u00/app/oracle/product/10.2.0/db_1 /u00/app/oracle/product/11.2.0/db_1 /u00/app/oracle/product/11.2.0/db_2 /u00/app/oracle/product/11.2.0.2/db_1
Die Dateien /etc/oratab bzw. /var/opt/oracle/oratab steuern, welche Instanz welches Oracle-Home nutzt (siehe Abschnitt 12.5).
15
Important Changes to Oracle Database Patch Sets Starting With 11.2.0.2: My Oracle Support Note 1189783.1
557
12 Aufbau und Betrieb eines Datenbankservers
12.4.9 OUI-Inventory Das Oracle Universal Installer (OUI) Inventar verwaltet die Oracle-Software-Installationen (inkl. Patches) des Servers. Es hat eine hierarchische Struktur, die folgendermaßen aufgebaut ist:
Central Inventory Pointer File (existiert einmal pro Server) Das zentrale Inventory-File oraInst.loc liegt unter /etc auf Linux und Solaris, unter /var/opt bei HP-UX Servern sowie auf Windows unter HKEY_LOCAL_MACHINE/ Software/Oracle/inst_loc. Das File oraInst.loc beinhaltet den Verweis auf das zentrale Inventory-Verzeichnis.
Das Central Inventory (existiert einmal pro Server) Die Liste der vorhandenen „ORACLE_HOME“-Verzeichnisse wird in der Datei ORACLE_BASE/oraInventory/ContentsXML/inventory.xml verwaltet.
Das Oracle Home Inventory (existiert einmal pro Oracle-Home) Im File ORACLE_HOME/inventory/ContentsXML/comps.xml befindet sich die Liste der in diesem Home installierten Komponenten. Der OUI bzw. das OPatch-Utility führen das Inventory bei jeder Installation und Deinstallation bzw. Patchinstallation automatisch nach. Praxistipp Es empfiehlt sich nicht, das Inventory zu verschieben, zu löschen oder manuell darin einzugreifen. Fehlt das Inventory auf einem Server oder ist es nicht lesbar, muss ein neues Inventory erstellt werden. Dies erfolgt mit dem Befehl ./runInstaller -silent -attachHome. Details zur Option -attachHome bzw. -detachHome sind der Originaldokumentation16 zu entnehmen.
12.4.10 Automatic Diagnostic Repository (ADR) Das ADR verwaltet die Log- und Tracefiles sämtlicher auf dem Server installierter OracleKomponenten. Die Struktur des ADR haben wir bereits in Kapitel 11 „Monitoring“ kennengelernt. Das Basisverzeichnis des ADR, das ADR-Base, wird über den DB-Parameter diagnostic_dest bestimmt. Im Normalfall ist der Parameter diagnostic_dest aus dem „ORACLE_BASE“-Verzeichnis abgeleitet. diagnostic_dest=/u00/app/oracle
Die ADR-Home-Verzeichnisse der verschiedenen Komponenten sind aus dem ADR-Base abgeleitet. /diag/rdbms//<SID>
16
558
Oracle Universal Installer and OPatch User's Guide 11g Release 2 (11.2) for Windows and UNIX
12.5 Verwaltung des Oracle-Environments
12.5
Verwaltung des Oracle-Environments Die Environment-Settings stellen sicher, dass alle notwendigen Umgebungsvariablen und Pfade konsistent und zuverlässig gemäß der ausgewählten SID gesetzt sind. Dies ist vor allem auf Servern mit mehr als einer Instanz und mehreren Oracle-Installationen eine Herausforderung. Dreh- und Angelpunkt der Environmentverwaltung ist die Datei /etc/oratab. Darin sind alle SIDs mit dem zugehörigen Oracle-Home-Verzeichnis und dem Autostart-Flag erfasst. Beim Erstellen einer neuen Datenbank generiert der Database Creation Assistant automatisch einen neuen Eintrag im oratab-File. Bei der manuellen Datenbankerstellung erfolgt der Eintrag manuell. Der folgende Ausschnitt aus einem oratab-File zeigt drei unterschiedliche Einträge. Die ersten beiden Einträge sind sogenannte „Dummy-SIDs“ (SIDs in Kleinbuchstaben, bezeichnet mit „D“ für das Autostart-Flag), für die keine Instanz existiert. Eine Dummy-SID dient lediglich der Definition einer Oracle-Home-Umgebung. Die beiden nächsten Einträge bezeichnen zwei SIDs, die 11.2.0.2-Binaries verwenden. Das AutostartFlag „Y“ bewirkt den automatischen Restart der Instanz nach dem Reboot des Servers. Der letzte Eintrag ist eine ASM-Instanz, die aus dem Grid-Home startet. Hier steht das Autostart-Flag auf „N“, das heißt die Instanz wir beim Serverboot nicht automatisch gestartet: rdbms1120:/u00/app/oracle/product/11.2.0.2/db_1:D grid1120:/u00/app/grid/:D TECH01:/u00/app/oracle/product/11.2.0.2/db_1:Y TECH02:/u00/app/oracle/product/11.2.0.2/db_1:Y +ASM:/u00/app/oracle/grid:N
Basierend auf dem oratab-File setzt das Oracle-Skript $ORACLE_HOME/bin/oraenv die gewünschte Umgebung: $. oraenv ORACLE_SID = [] ?
Unter Windows wird das Autostartverhalten in den Registries definiert. Folgender Registry-Key ist dabei zu berücksichtigen: \HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_Ora1120Home\ORA_<SID>_AUTOSTART
Diese Umgebungsvariablen werden mit oraenv definiert: $ORACLE_SID $ORACLE_HOME $PATH $LD_LIBRARY_PATH
Dies ist jedoch eine sehr minimalistische Arbeitsumgebung, die den meisten DatenbankAdministratoren nicht genügt. Viele nützliche Umgebungsvariablen wie $TNS_ADMIN oder $SQLPATH werden mit oraenv nicht definiert. Es fehlen auch Aliase, die ein effizientes Navigieren im Oracle-Verzeichnisbaum erlauben. Dies führt dazu, dass jeder DBA „seine“ Umgebung selbst definiert, was natürlich nicht im Sinne einer einheitlichen, standardisierten Betriebsumgebung ist. Wir empfehlen daher ein bewährtes Framework17, das ein umfassendes und einheitliches Environment-Handling ermöglicht.
17
Beispielsweise TvdBasenv der Firma Trivadis (www.trivadis.com)
559
12 Aufbau und Betrieb eines Datenbankservers
12.6
Betrieb eines Oracleservers Erfahrungsgemäß erneuert man den Großteil der geschäftsrelevanten Datenbankserver alle fünf bis sieben Jahre. Typische Treiber für diesen Zyklus sind neue Geschäftsanforderungen und die Innovationszyklen der Hard- und Software-Hersteller. Am Ende ihrer Lebensdauer ersetzt man die Server normalerweise durch leistungsfähigere Hardware. Auch die Oracle-Software wird in dieser Zeitspanne in den meisten Fällen ein-, oder mehrmals aktualisiert. Wie in Abschnitt 12.1 bereits angedeutet, summieren sich die Betriebsaufwendungen (und somit auch die Betriebskosten) über den gesamten Lifecycle, im Normalfall über mehrere Jahre. Die wiederkehrenden, operativen Kosten (wir sprechen hier nicht nur von den ebenfalls zu berücksichtigenden jährlichen Lizenzkosten) sind nicht zu unterschätzen. Mit zunehmendem Alter des Systems nimmt der Wartungsaufwand zu (siehe Abbildung 12.5). Die damit verbundene jährliche Kostenzunahme (cost grow rate) ist ein Indiz dafür, dass sich das System dem Ende seines Lebenszyklus nähert.
Abbildung 12.5 Entwicklung der jährlichen operativen Kosten (am Beispiel eines Datenbanksystems aus der Finanzindustrie)
Betrachtet man diese Kostenentwicklung, stellt sich natürlich die Frage, wie sich die Betriebsaufwendungen möglichst gering und stabil halten lassen. Aus der Erfahrung der Autoren sind zwei betriebskostenreduzierende Faktoren entscheidend:
Einsatz einer bewährten System- und -Betriebsarchitektur Reduktion der Komplexität durch Standardisierung und Automatisierung Den ersten Punkt haben wir bereits in Abschnitt 12.2 beleuchtet. Die Bedeutung des zweiten Faktors, die Standardisierung und die Automatisierung, nimmt mit Größe und Komplexität der Systemumgebung exponentiell zu. Es gilt, sowohl die wichtigsten Betriebsprozesse wie Monitoring, Reporting, Maintenance, Backup und Recovery zu standardisieren (Standard Operation Procedures = SOPs) als auch technische Standards und Konventionen unternehmensweit zu definieren und durchzusetzen. Eine zentrale Bedeutung hat dabei das Betriebshandbuch, in dem die Prozesse und die Standards dokumentiert sind. Ein hoher Standardisierungs- und Automatisierungsgrad wirkt sich nicht nur im Normalbetrieb günstig aus. Gerade bei außergewöhnlichen Situationen wie einem Stromausfall,
560
12.6 Betrieb eines Oracleservers einem Brand oder einem Bedienungsfehler sind betriebliche und technische Standards oft entscheidende Erfolgsfaktoren im Wiederherstellungsprozess.
12.6.1 Das Betriebshandbuch Das klassische Betriebshandbuch (operations manual), das die Systemumgebung dokumentiert und alle betriebsrelevanten Aktivitäten beschreibt, hat durch zunehmend höhere regulatorische Anforderungen18 in den letzten Jahren eine noch größere Bedeutung gewonnen. Die Einhaltung der rechtlichen Anforderungen − mit dem Begriff „Compliance“ bezeichnet − ist für das Unternehmen eine zunehmende Herausforderung und zwingt es, seinen IT-Betrieb zu formalisieren und jede Aktivität akribisch genau zu beschreiben. Praxistipp Werden Sie kreativ. Das Betriebshandbuch muss nicht zwingend ein „old-style“ Word-Dokument sein. Viele Betriebsanleitungen sind heutzutage grafisch („visio-style“) gestaltet. Ein Schema der Systemumgebung, ergänzt mit Screenshots, Ablaufdiagrammen und Textboxen, sagt oft mehr als tausend Worte.
Das Betriebshandbuch sollte folgende Elemente und Tätigkeiten beschreiben:
Wichtige Kontaktpersonen Entscheidungsträger Technische Ansprechpersonen Eskalationsliste Die Verantwortlichkeiten Wer ist für welche Komponenten, Aktivitäten und Entscheidungen zuständig Eine detaillierte Beschreibung des Systems Hardware Software/Applikationen Wichtige Schnittstellen zu (abhängigen) anderen Systemen Alle wichtigen Informationen, um das System erfolgreich zu betreiben Start-/Stop-Prozeduren Tägliche/wöchentliche/monatliche Geschäftsvorgänge Incident- und Problem-Handling Beschreibung der periodischen Wartungsaufgaben Betriebsjournal und Changelog Betriebsvoraussetzungen Verfügbarkeit/Einsatzplan Technische und personelle Fähigkeiten (Skills) 18
Im Kontext der Informationsverarbeitung und im Umgang mit Daten geht es dabei um Schutz, Verfügbarkeit, Nachvollziehbarkeit, Transparenz und Sorgfalt
561
12 Aufbau und Betrieb eines Datenbankservers
Sicherheitsmaßnahmen Service Level Agreements Anweisungen für den Notfall Notfallplan Disaster Szenario Externe Unterstützung 12.6.2 Monitoring und Reporting Monitoring und Reporting sind zwei wichtige Betriebsaspekte. Der DBA ist dafür verantwortlich, dass Systemstörungen und Ressourcen-Engpässe frühzeitig erkannt und eskaliert werden. Auf die Überwachung von Oracle-Datenbanken sind wir bereits in Kapitel 11 „Monitoring“ im Detail eingegangen. Zwei Punkte möchten wir an dieser Stelle nochmals herausstellen:
„Keep it simple.“ Überwachen Sie primär die wirklich betriebsrelevanten Punkte, wie die Platzverhältnisse, die Verfügbarkeit, das Alertlog-File und das Backup.
Automatisieren Sie die Überwachung. Der Oracle Enterprise Manager (Database Control oder Grid Control) eignet sich dazu bestens. Die Überwachung mit Tools von Drittherstellern oder mit eigenentwickelten Skripts kann durchaus sinnvoll sein. Es sind jedoch Zusatzkosten für Lizenzen, Integration, Entwicklung und Wartung zu berücksichtigen. Für das Reporting empfehlen wir ebenfalls, die Möglichkeiten des Enterprise Managers Database Control oder Grid Control zu nutzen. Auch der Oracle SQL Developer verfügt „out-of-the-box“ über eine Vielzahl Reports zu allen möglichen Aspekten einer Datenbank (siehe Kapitel 11 „Monitoring“).
Abbildung 12.6 „Out-of-the-Box”-Reports im SQL Developer
562
12.6 Betrieb eines Oracleservers
12.6.3 Backup und Recovery Das Backup-Konzept ist ein wichtiger Teil des Betriebshandbuchs. Es beschreibt, wie die Sicherung der Datenbank gemacht werden muss:
Backup-Methode (online, offline, physische und logische Sicherung) Backup-Strategie (Vollsicherung, inkrementelle Sicherung) Backup-Planung (Zeitpunkt und Häufigkeit der Sicherungen) Kapitel 13 „Backup und Recovery“ zeigt, wie man ein Backup-Konzept im Detail erstellt. Aus betrieblicher Sicht ist zu kontrollieren, ob die Backups gemäß den Vorgaben des Konzepts ausgeführt sind. Die Überwachung der RMAN-Backups ist in Kapitel 11 „Monitoring“ beschrieben. Praxistipp Die Backup-Strategie sollte bei jedem Oracle-Releasewechsel, Plattformwechsel oder Betriebssystem-Upgrade überprüft werden. Verifizieren Sie zudem regelmäßig ihre Recovery-Prozeduren und Checklisten. Alle im Backup-und-Recovery-Konzept beschriebenen Fehlersituationen sollten zunächst auf einem Testsystem durchgespielt werden. Das Testsystem muss dabei ein möglichst identisches Abbild der Produktion sein (Betriebssystem, Oracle-Release, Datenbankgröße und -Inhalt). Diese Tests sind regelmäßig zu wiederholen, damit das Wissen über die korrekte Vorgehensweise jederzeit präsent ist.
Zum Backup-Konzept gehört auch eine Anleitung (Recovery-Handbuch und Checklisten) für die Wiederherstellung der Daten im Störfall. Für jedes Szenario müssen die entsprechenden Massnahmen Schritt für Schritt beschrieben sein. Bei produktiven Recoveries handelt es sich immer um Stresssituationen, die leichter zu bewältigen sind, wenn die Beschreibungen im Recovery-Handbuch folgende Attribute erfüllen:
Leicht Verständlich Korrekt Vollständig Wird beispielsweise nach dem Recovery „vergessen“, die Datenbank wieder zu öffnen, oder die Applikationen zu starten, so verlängert sich die Ausfallzeit für die Benutzer unnötig.
12.6.4 Maintenance Unterhaltsarbeiten an der Datenbank können periodisch wiederkehrende oder sporadische Tätigkeiten sein. Die periodischen Wartungsarbeiten sollten Sie wenn immer möglich automatisieren. Oracle 11g bietet drei Automated Maintenance Tasks, die – wie der Name sagt – bestimmte Maintenance-Aufgaben automatisch erledigen:
Der Optimizer „Statistics Gathering“-Task führt die Objekt- und Systemstatistiken täglich nach.
563
12 Aufbau und Betrieb eines Datenbankservers
Der „Segment Advisor“-Task analysiert täglich die Speicherstrukturen von Datenbanksegmenten wie Tabellen und Indizes.
Der „Automatic SQL Tuning“-Task wertet Laufzeitinformationen über SQL-Anweisungen aus und generiert Optimierungsempfehlungen. Ganz ohne Handarbeit geht es aber doch nicht. Die Empfehlungen aus dem „Segment Advisor“-Task und dem „Automatic SQL Tuning“-Task sind vom Datenbank-Administrator manuell zu beurteilen, auszuwählen und auszuführen. Natürlich gibt es eine ganze Reihe weiterer Unterhaltsarbeiten, die der DBA auf seine Todo-Liste setzen sollte. Eine Auswahl davon sind:
Bereinigen von User-Accounts (löschen, sperren oder entsperren) Einspielen von Critical Patch Updates (CPUs) oder Patch Set Updates (PSUs) Clean-Up von Log- und Tracefiles, die außerhalb des ADR verwaltet werden Purgen der Audit-Daten (Auditing ist ab 11g vom DBCA automatisch aktiviert und lässt sich bei Bedarf auch ausschalten).
Clean-Up von Scheduler-Jobs Rekompilieren von invaliden Objekten
12.7
Resümee In diesem Kapitel haben wir anhand eines Lifecycle-Modells gezeigt, welche Aspekte bei der Auswahl, dem Aufbau und dem Betrieb eines Datenbankservers zu beachten sind. Wir haben gesehen, wie die Lifecycle-Phasen aufeinander aufbauen und wie ein methodisches und sorgfältiges Vorgehen in der Evaluations- und Designphase sich positiv auf den gesamten Lebenszyklus auswirken kann. Die Ausrichtung entlang bewährter Standards und Guidelines wie beispielsweise OFA und der Einsatz neuer Oracle-Features wie die Automated Maintenance Tasks helfen, die Betriebskosten tief zu halten und die Zuverlässigkeit der Systeme zu erhöhen. Das Betriebshandbuch, auf dessen Inhalt wir ebenfalls eingegangen sind, ist dabei ein wichtiges und nützliches Hilfsmittel.
564
13 13 Backup und Recovery In diesem Kapitel zeigen wir Ihnen:
welche Sicherungs- und Wiederherstellungsverfahren es gibt; welche Sicherungsstrategien sich in der Praxis bewährt haben; wie bestehende Einstellungen überprüft und geändert werden können; wie man eine Sicherung durchführt; wie man Datenbanken schnell und effizient wieder herstellt. Oracle unterstützt verschiedene Backup- und Recovery-Varianten. Dazu zählen Onlineund Offline-Sicherungen, logische Sicherungen mit Data Pump sowie physische Sicherungen mit Betriebssystembefehlen oder dem Recovery Manager (RMAN). Data Pump erzeugt ein logisches Backup. Es sichert keine physischen Datenblöcke, sondern exportiert die Metadaten der Tabellen und deren Inhalte. Die Sicherung mit RMAN oder mit Betriebssystembefehlen erzeugt dagegen eine physische Sicherung. Nur sie gestattet, mittels archivierter Redo Logs alle Transaktionen einschließlich der letzten wiederherzustellen.
13.1
Übersicht Vor der Implementierung sollten Sie ein Sicherungskonzept erstellen. Eine Backup- und Recovery-Strategie muss stets gut geplant, getestet und – am besten in einer Art Handbuch – dokumentiert werden.
13.1.1 Entwicklung eines Sicherungskonzepts Um eine geeignete Backup-Strategie zu wählen, sollten vorab einige Fragen geklärt werden:
Welches Zeitfenster steht für eine Datensicherung zur Verfügung? Wie schnell muss im Fehlerfall die Datenbank wieder zur Verfügung stehen? 565
13 Backup und Recovery
Welcher Datenverlust ist im ungünstigsten Fall tolerierbar? Welche Datenmenge ist zu sichern bzw. wiederherzustellen? Welche Bandbreiten stehen für die Sicherung und Wiederherstellung zur Verfügung? Im Netz? Auf dem Zielmedium?
Welche Komponenten sind zusätzlich zur Datenbank zu sichern? Gibt es Abhängigkeiten zu anderen Systemen? Planen Sie nach Beantwortung dieser Fragen sorgfältig Ihr Sicherungskonzept. Nach der Implementation sollten Sie vor allem auch die Wiederherstellung in verschiedenen Szenarien testen und sorgfältig dokumentieren. Backup- und Recovery-Handbuch Es hat sich in der Praxis bewährt, ein Backup- und Recovery-Handbuch zu erstellen, das nicht nur die Standard-Sicherungsverfahren des Systems genau beschreibt, sondern auch die Wiederherstellung und – ganz wichtig – das Troubleshooting. So kann im Falle einer Wiederherstellung auf erprobte Verfahren zurückgegriffen werden. Langwieriges Recherchieren nach Fehlermeldungen und deren Lösung sollte im Falle des Falles nicht mehr erforderlich sein. Testen Sie Ihr Sicherungsverfahren regelmäßig, indem Sie auch die Wiederherstellung proben. Das bietet gleich mehrere Vorteile:
Sie üben die Wiederherstellung ein und sind so im Fehlerfall gut vorbereitet. Eventuelle Probleme bei der Wiederherstellung werden entspannt und ohne Zeitdruck gelöst sowie im Handbuch dokumentiert. Mit regelmäßigen Tests der Wiederherstellung – beispielsweise einmal monatlich oder einmal im Quartal – stellen Sie sicher, dass das Verfahren auch weiterhin einwandfrei funktioniert. Oft wird erst im Fehlerfall festgestellt, dass aufgrund von Seiteneffekten, die durch manchmal nur kleinere Änderungen des Systems oder durch Ausfall einer Komponente hervorgerufen wurden, die Wiederherstellung – zumindest teilweise – versagt. Datenverlust ist dann oft die schmerzliche Folge.
13.1.2 Offline- und Online-Sicherung Unter einem Offline-Backup (auch Cold Backup) versteht man eine Sicherung, die erstellt wurde, während die Datenbank heruntergefahren, also offline war. Ein Online-Backup (auch Hot Backup) dagegen ist eine Sicherung, während der die Datenbank online bleibt, sodass die Benutzer gleichzeitig mit der Datenbank arbeiten können.
13.1.3 Logische und physische Sicherung Eine logische Sicherung sichert die Dateninhalte durch Exportieren der Daten. Sie haben den Nachteil, dass es mit ihnen nicht möglich ist, im Fehlerfall alle Daten bis zur letzten Transaktion wiederherzustellen.
566
13.1 Übersicht Physische Sicherungen dagegen sichern die Dateien einer Datenbank: Datafiles, Controlfiles und Redologs werden kopiert. Wird die Datenbank im Archivelog Modus betrieben, können bei einer physischen Sicherung alle Transaktionen bis zur letzten wiederhergestellt werden. Dazu werden nach der Wiederherstellung der Datendateien alle archivierten Redologs ausgewertet und die in ihnen enthaltenen Transaktionsbeschreibungen erneut gegen die Datenbank angewandt.
13.1.4 Restore und Recovery Bei einem Restore handelt es sich um die Wiederherstellung der Datenbank aus einer Sicherung. Nach dem Restore entspricht der Datenbestand zunächst dem Stand des Sicherungszeitpunkts. Sofern die Datenbank im Archive Log Modus betrieben wird, kann man mittels der Transaktionsbeschreibungen in den archivierten Redologs alle Transaktionen seit der letzten Vollsicherung nachvollziehen. Die Datenbank ist danach wieder verlustfrei auf dem aktuellen Stand. Dieser Vorgang wird als Recovery bezeichnet. In seltenen Fällen wird ein Recovery nicht bis zum aktuellen Zeitpunkt durchgeführt. Man spricht hier auch von einem unvollständigen Recovery. Sinnvoll ist dies beispielsweise dann, wenn ein logischer Fehler wie eine Datenkorruption vorliegt oder ein komplettes Schema der Datenbank gelöscht wurde. Wurden beispielsweise um 8.30 Uhr Daten in fehlerhafter Weise geändert, so lässt sich die Datenbank aus der letzten Vollsicherung mit einem Restore wiederherstellen und mit einem Recovery bis 8.29 Uhr auf den Stand vor der fehlerhaften Änderung setzen. Einfacher und schneller als ein unvollständiges Recovery ist ein Flashback (siehe auch Abschnitt 13.6 „Flashback“).
13.1.5 Vollsicherung, inkrementelle und differentielle Sicherung Eine Vollsicherung sichert alle Datenblöcke einer Datenbank. Eine alternative Strategie für Vollsicherungen ist der Einsatz von inkrementellen Backups mit RMAN. Als Basis der inkrementellen Sicherungen wird eine Vollsicherung genutzt, die man auch als „inkrementelles Level 0“-Backup bezeichnet. Jedes darauffolgende inkrementelle Backup – auch als „inkrementelles Level 1“-Backup bezeichnet – enthält nur die geänderten Blöcke und benötigt deshalb weniger Zeit und Platz. „Level 1“-Backups sind – je nach Konfiguration – entweder kumulativ oder differenziell. Ein kumulatives Backup protokolliert alle Blöcke, die seit der letzten Vollsicherung geändert wurden; ein differenzielles Backup protokolliert alle geänderten Blöcke seit dem letzten inkrementellen Backup, unabhängig davon, ob es sich um ein „Level 0“- oder „Level 1“-Backup handelt.
567
13 Backup und Recovery
13.1.6 Flash Recovery Area / Fast Recovery Area (FRA) Oracle bietet seit Version 10g die Option, eine Fast Recovery Area (FRA)1 zu nutzen. Dabei handelt es sich um einen Speicherbereich auf Disk, auf dem man Sicherungsinformationen vorhalten kann. So werden in der FRA archivierte Redologs, Kopien der Controlfiles sowie Datensicherungen mit RMAN hinterlegt. Die Nutzung einer FRA wird mit den Parametern aktiviert:
db_recovery_file_dest_size
und
db_recovery_file_dest
SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 10 G; SQL> ALTER SYSTEM SET db_recovery_file_dest = '/opt/oracle/FRA'; SQL> ALTER SYSTEM SET log_archive_dest_1 = 'LOCATION=db_recovery_file_dest';
RMAN erstellt innerhalb der FRA automatisch Unterverzeichnisse: ein Verzeichnis je Datenbank, darin Unterverzeichnisse für archivierte Redologs, RMAN-Backups usw. Diese sind wiederum nach Tagesdatum unterteilt. Die View v$recovery_file_dest ermöglicht das Monitoring der FRA: SQL> SELECT FROM
13.1.7 Werkzeuge zur Sicherung und Wiederherstellung Oracle-Datenbanken können auf unterschiedliche Weise gesichert und wiederhergestellt werden:
Sicherung und Wiederherstellung von Kopien der Datenbank mit Betriebssystemmitteln
Sicherung und Wiederherstellung mit Oracle Recovery Manager (RMAN) Export und Import der Daten mit Oracle Data Pump oder Oracle Export / Import Oracle Flashback zur Wiederherstellung bei logischen Fehlern Das Sicherungs- und Wiederherstellungsverfahren sollte gemäß den Anforderungen Ihrer Datenbankumgebung ausgewählt werden. Die Evaluation dieser Anforderungen bildet die Basis. Als Leitfaden können Sie die Fragen des Abschnitts 13.1.1 heranziehen.
13.2
Betriebssystemkopie Betriebssystemkopien mit „copy“ oder „tar“ sind sowohl als Offline-Backup bei heruntergefahrener Datenbank als auch als Online-Backup im laufenden Betrieb möglich. Bei einem Offline-Backup werden einfach alle Datendateien, die Redologs sowie eines der Controlfiles kopiert. Für eine Wiederherstellung der Datenbank ist es später nur erforder-
1
568
Bis 11g R1 wurde diese als Flash Recovery Area bezeichnet
13.2 Betriebssystemkopie lich, alle Dateien wieder am ursprünglichen Speicherort wiederherzustellen, indem man diese zurück kopiert. Bei einem Online-Backup können die Anwender weiter auf die Datenbank zugreifen und auch Daten ändern. Ein Online-Backup ist daher per se zunächst inkonsistent. Um im Falle einer Wiederherstellung die Datenbank wieder in einen konsistenten Zustand zu bringen, sind die archivierten Redologs des Sicherungszeitraums in einem Recovery anzuwenden. Online-Backups sind daher nur möglich, wenn die Datenbank im Archivelog-Modus betrieben wird. Praxistipp Skripte, die für eine Betriebssystemsicherung bereitgestellt werden, sollten niemals die Namen der Datenbankdateien „fest verdrahtet“ enthalten. Werden Dateien verschoben oder wird eine Datei außerhalb des üblichen Pfads angelegt, so wird damit das Sicherungsskript ungültig und muss nachbearbeitet werden. In der Praxis hat sich gezeigt, dass dies enorm fehleranfällig ist. Fehlt auch nur eine Datei eines Tablespaces in der Sicherung, ist der komplette Tablespace nicht mehr ohne Weiteres wiederherstellbar. Das gilt selbst dann, wenn das betreffende Datafile leer war. Verwenden Sie statt fest verdrahteter Namen und Pfade besser die Views v$datafile, v$logfile und v$controlfile, um die aktuellen Pfade und Namen der Dateien auszulesen: SELECT name FROM v$datafile; SELECT member FROM v$logfile; SELECT name FROM v$controlfile;
13.2.1 Offline-Backup mit Betriebssystemmitteln Ein Offline-Backup ist eine physische Sicherung der Datenbankdateien, nachdem die Datenbank mit shutdown normal, shutdown immediate oder shutdown transactional konsistent heruntergefahren wurde. In diesem Zustand werden alle Dateien gesichert. Diese Dateien bilden ein vollständiges Abbild der Datenbank zu dem Zeitpunkt, als sie heruntergefahren wurde.
Praxistipp Nach einem shutdown abort ist die Datenbank inkonsistent. Ist ein solcher Abbruch notwendig, sollten Sie die Datenbank vor der Offline-Sicherung neu starten und ein shutdown normal, ein shutdown immediate oder shutdown transactional ausführen.
In ein Offline-Backup sollten Sie folgende Dateien einbeziehen:
Alle Datafiles Ein Controlfile Alle Online Redologs Die Initialisierungsparameter- oder Serverparameterdatei (SPFILE) Die Passwortdatei 569
13 Backup und Recovery Sollten Sie Raw Devices – mit oder ohne ASM – als Datenbankspeicher einsetzen, sind diese gleichfalls mit Betriebssystembefehlen wie „dd“ in Kombination mit einem Komprimierungstool zu sichern: dd if=/dev/sdc | gzip > /mnt/dbbackup/mydb_backup_01.gz
Ein Sicherungsskript für ein Offline-Backup mit Betriebssystemmitteln kann beispielsweise wie folgt aussehen: export export export export export export
echo echo Sicherung der Datenbank ${ORACLE_SID} / ${DT} echo ${ORACLE_HOME}/bin/sqlplus -S '/ as sysdba' backup_${ORACLE_SID}_${DT}.tar.gz ${ORACLE_HOME}/bin/sqlplus -S '/ as sysdba' Hier die Dateien des Tablespace Users kopieren = &start_seq;
-- Abfrage der Tablespaces
-- Abfrage der Datafiles
BEGIN dbms_output.put_line( 'HOST mkdir -p &BACKUP_DIR' || chr(10)); -- 1. Loop über alle Tablespaces FOR ct IN cur_tablespace LOOP dbms_output.put_line ('ALTER TABLESPACE ' ||ct.tablespace_name|| ' BEGIN BACKUP;'); -- 2. Loop über die Datafiles eines Tablespaces FOR cd IN cur_datafile (ct.tablespace_name) LOOP dbms_output.put_line ('host cp '||cd.file_name||' &BACKUP_DIR'); END LOOP; dbms_output.put_line ('ALTER TABLESPACE ' ||ct.tablespace_name|| ' END BACKUP;' || chr(10)); END LOOP; dbms_output.put_line('ALTER SYSTEM CHECKPOINT;'); dbms_output.put_line('ALTER SYSTEM SWITCH LOGFILE;'); dbms_output.put_line('ALTER DATABASE BACKUP CONTROLFILE TO ' || '''&BACKUP_DIR/control.dbf'''; END; / SPOOL OFF @/tmp/backup_script.sql EXIT;
Speichern Sie das Skript beispielsweise unter dem Namen backup.sql. Sie können die Sicherung dann wie folgt aufrufen: sqlplus / as sysdba @backup.sql
Die Ausgabe kann folgendermaßen aussehen: BACKUP_DIR ----------------------------------------------------------/sicherungen/mydb_2010_08_08 HOST mkdir -p /sicherungen/mydb_2010_08_08
572
13.2 Betriebssystemkopie ALTER TABLESPACE SYSAUX BEGIN BACKUP; host cp /opt/oracle/oradata/mydb/sysaux01.dbf /sicherungen/mydb_2010_08_08 ALTER TABLESPACE SYSAUX END BACKUP; ALTER TABLESPACE SYSTEM BEGIN BACKUP; host cp /opt/oracle/oradata/mydb/system01.dbf /sicherungen/mydb_2010_08_08 ALTER TABLESPACE SYSTEM END BACKUP; ALTER TABLESPACE UNDOTBS1 BEGIN BACKUP; host cp /opt/oracle/oradata/mydb/undotbs01.dbf /sicherungen/mydb_2010_08_08 ALTER TABLESPACE UNDOTBS1 END BACKUP; ALTER TABLESPACE LOB_TS_01 BEGIN BACKUP; host cp /opt/oradata/myDB/LOB_TS_01_a.DBF /backup host cp /opt/oradata/myDB/LOB_TS_01_b.DBF /backup ALTER TABLESPACE LOB_TS_01 END BACKUP; ALTER TABLESPACE LOB_TS_02 BEGIN BACKUP; host cp /opt/oradata/myDB/LOB_TS_02_a.DBF host cp /opt/oradata/myDB/LOB_TS_02_b.DBF host cp /opt/oradata/myDB/LOB_TS_02_c.DBF host cp /opt/oradata/myDB/LOB_TS_02_d.DBF ALTER TABLESPACE LOB_TS_02 END BACKUP;
/backup /backup /backup /backup
Das folgende Sicherungsskript kann mit SQL*Plus ausgeführt werden. Es sichert alle Datafiles, ein Controlfile, die Parametrisierung der Datenbank sowie zusätzlich alle archivierten Redologs, die während der Sicherung angefallen sind: SET SET SET SET
LINES TRIMSPOOL VERIFY TERMOUT
1000 ON OFF OFF
DEFINE BACKUP_ROOT_DIR = d:\data\backup DEFINE BACKUP_DATABASE_SCRIPT = c:\temp\backup_database.sql DEFINE BACKUP_ARCHLOGS_SCRIPT = c:\temp\backup_archlogs.sql COL CUR_TIMESTAMP NEW_VALUE CUR_TIMESTAMP SELECT to_char(sysdate, 'YYYY_MM_DD_HH24MI') AS CUR_TIMESTAMP FROM dual; COL INSTANCE_NAME NEW_VALUE INSTANCE_NAME SELECT instance_name FROM v$instance; COL BACKUP_DIR NEW_VALUE BACKUP_DIR SELECT '&BACKUP_ROOT_DIR.\&instance_name._&CUR_TIMESTAMP.' AS BACKUP_DIR FROM dual; COL CONTROLFILE_BACKUP NEW_VALUE CONTROLFILE_BACKUP SELECT '&instance_name._controlile_&CUR_TIMESTAMP..bck' AS CONTROLFILE_BACKUP FROM DUAL; COL PFILE_BACKUP NEW_VALUE PFILE_BACKUP SELECT '&instance_name._PFILE_&CUR_TIMESTAMP..bck' AS PFILE_BACKUP FROM DUAL; COL FIRST_ARCHLOG_SEQ NEW_VALUE FIRST_ARCHLOG_SEQ SELECT sequence# AS FIRST_ARCHLOG_SEQ FROM v$log WHERE status = 'CURRENT'; SET FEEDBACK SET TERMOUT
OFF ON
573
13 Backup und Recovery SET SERVEROUTPUT ON SPOOL &BACKUP_DATABASE_SCRIPT. DECLARE CURSOR cur_tablespace IS -- Abfrage der Tablespaces SELECT tablespace_name FROM dba_tablespaces WHERE contents != 'TEMPORARY'; CURSOR cur_datafile (tn VARCHAR) IS -- Abfrage der Datafiles SELECT file_name FROM dba_data_files WHERE tablespace_name = tn; BEGIN dbms_output.enable (1000); -- Sicherungsverzeichnis erzeugen dbms_output.put_line( 'HOST mkdir &BACKUP_DIR' || chr(10)); -- Log Switch und Checkpoint ausfuehren dbms_output.put_line('ALTER SYSTEM SWITCH LOGFILE;'); dbms_output.put_line('ALTER SYSTEM CHECKPOINT;' || chr(10)); -- Loop über alle Tablespaces: Backup Modus setzen FOR ct IN cur_tablespace LOOP dbms_output.put_line ('ALTER TABLESPACE ' ||ct.tablespace_name|| ' BEGIN BACKUP;'); -- Loop über die Datafiles eines Tablespaces: Kopieren FOR cd IN cur_datafile (ct.tablespace_name) LOOP dbms_output.put_line ('HOST COPY '||cd.file_name||' &BACKUP_DIR'); END LOOP; dbms_output.put_line ('ALTER TABLESPACE ' ||ct.tablespace_name|| ' END BACKUP;' || chr(10)); END LOOP; -- Log Switch und Checkpoint ausfuehren dbms_output.put_line('ALTER SYSTEM CHECKPOINT;'); dbms_output.put_line('ALTER SYSTEM SWITCH LOGFILE;'); -- Controlfile sichern dbms_output.put_line('ALTER DATABASE BACKUP CONTROLFILE TO ' || '''&BACKUP_DIR.\&CONTROLFILE_BACKUP.'';'); -- SPFile sichern dbms_output.put_line('CREATE PFILE=''&BACKUP_DIR.\&PFILE_BACKUP''' || ' FROM SPFILE;'); END; / SPOOL OFF PROMPT Starte Datenbanksicherung von &INSTANCE_NAME. PROMPT Zielverzeichnis &BACKUP_DIR. @&BACKUP_DATABASE_SCRIPT. SPOOL &BACKUP_ARCHLOGS_SCRIPT. DECLARE CURSOR cur_arch_log IS -- Abfrage der Archived Logs SELECT name FROM v$archived_log WHERE sequence# >= &FIRST_ARCHLOG_SEQ; BEGIN -- Archivierte Redo Logs sichern FOR ar IN cur_arch_log LOOP dbms_output.put_line('HOST COPY '||ar.name||' &BACKUP_DIR'); END LOOP; END; / PROMPT Starte Archivelog-Sicherung @&BACKUP_ARCHLOGS_SCRIPT. PROMPT Sicherung beendet. EXIT;
574
13.2 Betriebssystemkopie Es besteht auch die Möglichkeit, die komplette Datenbank in den Backup-Modus zu setzen. Wie weiter oben beschrieben, erhöht sich dabei allerdings das Redolog-Aufkommen enorm. ALTER DATABASE BEGIN BACKUP; -- Kopieren der Datafiles ALTER DATABASE END BACKUP;
13.2.3 Dateien im Backup-Modus identifizieren Die Views sind:
v$backup
und
v$datafile
zeigen an, welche Dateien aktuell im Backup-Modus
SELECT name FROM v$datafile WHERE file# IN (SELECT file# FROM v$backup WHERE status = 'ACTIVE');
13.2.4 Troubleshooting: „Datafile needs Recovery” Sofern eine Datenbank-Instanz heruntergefahren oder abgebrochen wird, während sich ein Tablespace im Backup-Modus befindet, erfolgt beim Wiederanlauf die etwas irreführende Fehlermeldung ORA-10873. Sie besagt, dass die Datenbank ein Recovery benötigt. Hintergrund ist die veraltete SCN im Datafile-Header. Ein Recovery ist jedoch nicht nötig. Es genügt, die betreffenden Datafiles wieder aus dem Recovery-Modus zu nehmen: ALTER DATABASE END BACKUP;
Oder auch für einzelne Datafiles: ALTER DATABASE DATAFILE '/path/filename' END BACKUP;
13.2.5 Wiederherstellung aus einer Betriebssystemsicherung Die Wiederherstellung einer Sicherung mit Betriebssystemmitteln ist recht einfach: Datafiles, Controlfiles usw. werden dazu aus der Sicherung zurück kopiert. Betreibt man die Datenbank nicht im Archivelog-Modus, sind Transaktionen, die nach der Sicherung erfolgten, nicht nachvollziehbar. Die Datenbank wird in diesem Fall einfach mit einem Startup-Befehl geöffnet: SQL> startup;
Sofern man die Datenbank im Archivelog-Modus betreibt, können nach der Wiederherstellung der Dateien auch alle Transaktionen mittels Recovery im Mount-Modus wiederhergestellt werden. Abschließend wird die Datenbank geöffnet: 1. Datenbank mounten SQL> startup force mount;
575
13 Backup und Recovery 2. Recovery der Datenbank Nach der Wiederherstellung aus einer Online-Sicherung ist ein Recovery zwingend erforderlich.
Vollständiges Recovery SQL> recover database;
Anschließend wird Ihnen das für ein Recovery erforderliche archivierte Redolog vorgeschlagen: Log angeben: {=suggested | filename | AUTO | CANCEL}
Mit Return wird das vorgeschlagene Log verwendet. Alternativ können Sie einen Pfad und Datei-Namen angeben. Die Option „AUTO“ führt dazu, dass das Recovery automatisch ausgeführt wird. „CANCEL“ bricht das Recovery ab.
Recovery bei einem wiederhergestellten Controlfile Wurden auch die Controlfiles wiederhergestellt, so ist dies zusätzlich anzugeben: SQL> recover database using backup controlfile;
Wie oben beschrieben erhalten Sie auch hier die Option: Log angeben: {=suggested | filename | AUTO | CANCEL}
Unvollständiges Recovery Sofern ein unvollständiges Recovery ausgeführt werden soll, geben Sie für den Zielpunkt des Recovery einen Zeitpunkt an. Die Zeit ist dabei stets im Format „YYYYMM-DD:HI24:MI:SS“ zu übergeben: SQL> recover database until time '2010-08-08-14:15:00';
Wie oben beschrieben erhalten Sie auch hier die Option: Log angeben: {=suggested | filename | AUTO | CANCEL}
3. Öffnen der Datenbank Abschließend öffnen Sie die Datenbank: SQL> alter database open;
Falls ein unvollständiges Recovery oder eines mit wiederhergestellten Controlfiles ausgeführt wurde, sind die Redologs zurückzusetzen: SQL> alter database open resetlogs;
576
13.3 Recovery Manager (RMAN)
13.3
Recovery Manager (RMAN) Empfehlenswerter als die Sicherung und Wiederherstellung mit Betriebssystemmitteln ist die Verwendung des Recovery Managers (RMAN). Dieser bietet folgende Möglichkeiten:
Offline- und Online-Backups Vollsicherungen und inkrementelle Sicherungen Parallelisierung von Sicherung und Wiederherstellung RMAN wird mit der Datenbanksoftware installiert und steht im Verzeichnis ORACLE_HOME/ bin zur Verfügung. Dabei handelt es sich um eine Pro*C-Anwendung, die benutzerfreundliche Befehle für die Sicherung und Wiederherstellung von Oracle-Datenbanken in PL/SQL übersetzt und im Hintergrund ausführt. RMAN ist über den Enterprise Manager oder mit Kommandozeilen ausführbar. Sie können mit RMAN auf Disk sowie direkt auf ein Bandlaufwerk sichern. Bei Sicherungen auf Bandlaufwerke ist die Einbindung einer Bibliothek des Herstellers (wie Veritas, TSM oder Omniback) erforderlich. Zudem bietet RMAN weitere Optionen wie die Komprimierung und Verschlüsselung von Sicherungen, das Duplizieren von Datenbanken auf ein weiteres System, die Erstellung von Standby-Datenbanken oder auch inkrementelle Sicherungen mit einem Change-TrackingProtokoll.
13.3.1 RMAN-Komponenten
Target Database: RMAN nutzt zur Sicherung eine Verbindung zur Zieldatenbank. Diese wird als „Target“ bezeichnet.
Catalog Database: RMAN schreibt Meta-Informationen (wie den Speicherort und Art der Sicherung) in die Controlfiles der Datenbank. Sofern Controlfiles defekt sind und keine aktuelle Sicherung der Controlfiles vorhanden ist, wird die Wiederherstellung mit RMAN schwierig. Um dieser Situation vorzubeugen, empfiehlt es sich – insbesondere in Umgebungen mit mehreren Datenbanken – einen Sicherungskatalog anzulegen. Dabei handelt es sich um eine eigene Datenbank, die mit einem RMAN-Katalog ausgestattet ist und die bei Verlust der Controlfiles die Wiederherstellung unterstützt. Die Datenbank, die den RMAN-Katalog enthält, wird als Catalog bezeichnet.
Auxiliary Database: Soll eine Datenbank dupliziert oder eine Standby-Datenbank mit RMAN erstellt werden, so wird die Zieldatenbank der Duplikation als Auxiliary bezeichnet.
Channel: Ziel einer Sicherung können Verzeichnisse eines Dateisystems oder auch Bandlaufwerke sein. Das jeweilige Sicherungsziel wird über einen so genannten „Channel“ angesteuert.
577
13 Backup und Recovery
13.3.2 Backup-Sets und Image-Kopien RMAN kann in einem proprietären Format als Backup-Sets oder in Form von ImageKopien sichern. Backup-Sets sind Sicherungsdateien, in denen nur gefüllte Blöcke der Datenbankdateien gespeichert werden. Sie sparen daher Platz bei der Sicherung. Backup-Sets bestehen aus einzelnen Sicherungsdateien, den sogenannten „Backup-Pieces“. Darin können eine oder mehr Datenbankdateien gespeichert werden. Die maximale Größe eines Backup-Piece ist mit RMAN konfigurierbar, sodass eventuell vorhandene Größenbeschränkungen5 eingehalten werden können. Image-Kopien sind „1:1“-Kopien der Datenbankdateien, die RMAN erzeugt.
13.3.3 Aufruf und Anmeldung RMAN wird aus dem Betriebssystem heraus mit dem Befehl rman aufgerufen. Das Binary befindet sich in ORACLE_HOME/bin. Die Anmeldung an der Datenbank kann entweder direkt beim Aufruf oder nach dem Aufruf durch das Schlüsselwort connect erfolgen. Anmeldung beim Aufruf von RMAN $ $ $ $ $
Anmeldung an einer Auxiliary DB RMAN> connect auxiliary sys/duppasswort@dupDB
13.3.4 Interaktiver Modus und Batch-Modus Sie können RMAN interaktiv durch Eingabe von Befehlen oder aber im Batch-Modus nutzen. Im Batch-Modus wird eine Skriptdatei übergeben, die RMAN ausführt. Diese Skriptdatei enthält die auszuführenden RMAN-Befehle. Ihr Name und Pfad wird beim Aufruf an RMAN an den Parameter cmdfile übergeben: 5
578
beispielsweise Größenbeschränkungen des Dateisystems oder der Sicherungssoftware
Die Skriptdatei kann beispielsweise wie folgt aussehen: connect target / backup database plus archivelog delete input; backup current controlfile; backup spfile;
Sollen Kennwörter bei der Anmeldung verdeckt bleiben, empfiehlt es sich, die Anmeldung in einer Skriptdatei vorzunehmen und die Skriptdatei mit entsprechenden Rechten zu versehen. Ist RMAN bereits aufgerufen, kann auch im interaktiven Modus eine Skriptdatei ausgeführt werden. RMAN> @/opt/oracle/script/backup_archs.rman
Wird in einem RMAN-Script anstelle des „@“ ein „@@“ verwendet, so ruft RMAN weitere Skripte in demselben Verzeichnis auf, in dem die aufrufende Skriptdatei gespeichert ist.
13.3.5 Anzeige aktueller Konfigurationen mit show all Der Befehl show
all
zeigt die aktuelle RMAN-Konfiguration:
RMAN> show all;
13.3.6 Sicherungsoptimierung Wird Sicherungsoptimierung aktiviert, so werden Dateien, die bereits in einer identischen Version gesichert sind, bei neuen Sicherungen ausgelassen. Dafür gelten diese Kritierien:
Datafiles mit derselben DBID, Checkpoint-SCN, Erstellungs-SCN sowie ResetlogsSCN und -Zeit
Archivierte Redologs mit derselben DBID, Thread- und Sequence-Nummer sowie Resetlogs-SCN und -Zeit
Backup Sets mit derselben DBID, Backup Set Record ID und Backup Set RecordZeitstempel Die Einstellung konfigurieren Sie wie folgt: RMAN> configure backup optimization on; RMAN> configure backup optimization off;
Wird nun eine Sicherung wie die folgende ausgeführt, so werden nur jene Backup-Sets auf Tape (device type sbt) gesichert, die bisher noch nicht auf Tape gesichert waren: RMAN> backup device type disk database plus archivelog; RMAN> backup device type sbt backupset all;
Möchten Sie trotz Sicherungsoptimierung in einem Backup alle Dateien sichern, so können Sie dies mit dem Schlüsselwort force erzwingen: RMAN> backup database force; RMAN> backup archivelog all force;
579
13 Backup und Recovery
13.3.7 Maximale Größe von Backups konfigurieren Maximale Größe von Backup-Pieces Einige Dateisysteme unterstützen nur Dateien bis zu einer Maximalgröße. Auch einige Sicherungswerkzeuge weisen hier Begrenzungen auf. Sie können die Klausel maxpiecesize verwenden, um Backup Pieces auf eine maximale Größe einzuschränken: RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
Multisection Backup Speziell für Bigfile Tablespaces eignet sich das Multi Section Backup. Es zerlegt große Dateien in mehrere Backup-Pieces, die die angegebene „section size“ nicht überschreiten. RMAN> BACKUP SECTION SIZE 500M TABLESPACE ts_lobs_05;
Die Klausel section
size
lässt sich nicht mit maxpiecesize kombinieren.
Wird eine „section size“ angegeben, die die Größe einer Datendatei übersteigt, so erstellt RMAN ein normales anstelle eines Multi Section Backups. Sofern die angegebene Section Size mehr als 256 Sections erstellen würde, erhöht RMAN diese auf einen Wert, der exakt 256 Sections erzeugt. Größe der Backup-Sets konfigurieren Die maximale Größe eines Backup-Sets ist mit der Klausel maxsetsize konfigurierbar: RMAN> CONFIGURE MAXSETSIZE TO 15000 M; RMAN> BACKUP DATABASE; RMAN> BACKUP DEVICE TYPE sbt MAXSETSIZE 100M ARCHIVELOG ALL;
13.3.8 Standard-Konfiguration von Channels Ein Channel ist ein Sicherungskanal. Er dient als Kommunikationspipeline zu einer Datenbank und besteht aus einem Server-Prozess der Zieldatenbank (target) bzw. der Hilfsdatenbank (auxiliary) sowie einem Data Stream. Data Streams verlaufen zwischen der Datenbank auf der einen Seite und einer Disk oder einem Bandlaufwerk auf der anderen Seite. Für eine Sicherung oder Wiederherstellung einer Datenbank ist mindestens ein Channel notwendig. Bei parallelisierten Operationen werden mehrere Channel entsprechend dem Grad der Parallelisierung genutzt. Über Channels können Sie das Ziel einer Sicherung konfigurieren: Disk, Bandlaufwerk oder Fast Recovery Area6. Channels werden mit dem Befehl configure vorkonfiguriert oder während der Ausführung einer Sicherung mit allocate angesteuert. Persistente Einstellungen für Channel, mit dem Befehl configure channel konfiguriert, sind im RMAN Repository gespeichert.
6
580
Bis Oracle 11g R1: Flash Recovery Area
13.3 Recovery Manager (RMAN) Standard-Ziel für Sicherungskanäle auf Disk setzen RMAN> CONFIGURE DEFAULT DEVICE TYPE TO disk;
Standard-Ziel für Sicherungskanäle auf Band-Laufwerk setzen RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
Zwei Sicherungskanäle für Disk-Sicherungen als Standard konfigurieren RMAN> CONFIGURE DEVICE TYPE disk PARALLELISM 2; RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/backup_1/%U'; RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/backup_2/%U';
Vom Standard abweichende Channel-Konfiguration nutzen Bei einer Sicherung auf ein Sicherungsziel, das von der Standardkonfiguration abweicht, muss der entsprechende Kanal explizit angesteuert werden. Die allgemeine Syntax lautet: ALLOCATE CHANNEL [] DEVICE TYPE [disk|sbt] [];
Dazu verwenden Sie einen Run-Block etwa wie folgt: RMAN> RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK MAXPIECESIZE 200 M; BACKUP TABLESPACE users; }
Im folgenden Beispiel wird ein Channel zu einem Bandlaufwerk unter Verwendung einer Media Management Library genutzt: RMAN> RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=mydb_mf)'; BACKUP DATABASE PLUS ARCHIVELOG; }
13.3.9 Parallelisierung Parallelisierung beschleunigt Sicherungen und Wiederherstellungen. RMAN verwendet dann eine dem Parallelisierungsgrad entsprechende Anzahl von Channels. Jeder dieser Channels erhält einen Namen im Format ORA_SBT_TAPE_ bzw. ORA_DISK_TAPE_ mit n = 1 bis n = Parallelisierungsgrad. RMAN> CONFIGURE DEVICE TYPE disk PARALLELISM 8; RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
Bitte beachten Sie, dass bei Verwendung von Tapes der Parallelisierungsgrad nicht höher als die Anzahl der Bandlaufwerke gesetzt werden sollte.
13.3.10 Duplexing Duplexing ist sowohl für Bandlaufwerke als auch für Disk möglich. Darunter versteht man im Zusammenhang mit RMAN die Erstellung mehrerer Kopien einer Sicherung. Sind bei-
581
13 Backup und Recovery spielsweise zwei Kopien auf Band gesichert, kann eine Kopie korrupt sein, dennoch steht eine weitere zur Verfügung. RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 2; RMAN> CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt TO 2;
Einige Hersteller von Sicherungssoftware bieten die Option, unterschiedliche Bänder-Pools für die Kopien anzusteuern. So kann man beispielsweise gezielt Sicherungen auf Bandlaufwerken in unterschiedlichen Brandabschnitten speichern. Die hierfür erforderlichen Optionen werden häufig entweder mit der Klausel parms (siehe Abschnitt 13.3.17 „Sicherungen auf Band einbinden“) oder in einer software-spezifischen Datei hinterlegt. Ziehen Sie hierzu die Dokumentation der Sicherungssoftware heran. Bei Sicherungen auf Disk können Sie unterschiedliche Pfade für die Kopien angeben: CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2; BACKUP DEVICE TYPE DISK DATABASE FORMAT '/backup_1/%d_%I_%U','/backup_2/%d_%I_%U';
Ab Oracle 11g R2 kann auch Advanced Compression für Sicherungen verwendet werden: RMAN> CONFIGURE COMPRESSION ALGORITHM "HIGH"; Tabelle 13.1 Komprimierungsalgorithmen für RMAN Level
Bemerkung
LOW
Ergibt den geringsten Einfluss auf die Geschwindigkeit und Ressourcen
MEDIUM
Günstige Kombination zwischen Komprimierungsrate und Geschwindigkeit
HIGH
Günstig für Sicherungen über ein langsames Netzwerk, bei denen die Netzwerkbandbreite der limitierende Faktor ist
13.3.12 Verschlüsselung von Sicherungen Sicherungen können in der Enterprise Edition verschlüsselt werden. Die View v$rman_enzeigt Ihnen die hierfür zur Verfügung stehenden Algorithmen:
cryption_algorithms
SQL> SELECT * FROM v$rman_encryption_algorithms;
Voraussetzung für eine Verschlüsselung der RMAN-Sicherung ist, dass der Datenbankparameter compatible der Zieldatenbank mindestens auf 10.2.0 gesetzt ist. Wird kein Verschlüsselungsalgorithmus angegeben, so verwendet RMAN 128-bit Advanced Encryption Standard (AES). Möglich sind die transparente Verschlüsselung mit einem Oracle Wallet, die Verschlüsselung über ein Kennwort oder ein Mix aus beidem. Die Verschlüsselung über ein Wallet ist
582
13.3 Recovery Manager (RMAN) sicherer als die über ein Kennwort. Doch sofern eine Sicherung transportabel sein soll, ist die Kennwortverschlüsselung komfortabler. Die Verschlüsselung von Sicherungen auf Disk setzt den Einsatz der Advanced Security Option (ASO) voraus. Die verschlüsselte Sicherung auf Bandlaufwerke wird nur mit Oracle Secure Backup SBT unterstützt. ASO ist hierfür keine Voraussetzung. Während der Wiederherstellung einer Datenbank aus einer Sicherung wird diese automatisch entschlüsselt. Transparent Encryption Setzen Sie ein Oracle Wallet auf. Informationen hierzu finden Sie in Abschnitt 6.4.1.1 „Wallet“. Anschließend wird die Verschlüsselung der RMAN-Sicherungen mit folgendem Befehl aktiviert bzw. deaktiviert: RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON; RMAN> CONFIGURE ENCRYPTION FOR DATABASE OFF;
Für eine einzelne RMAN-Session können Sie diese persistente Konfiguration übersteuern: RMAN> SET ENCRYPTION ON; RMAN> SET ENCRYPTION OFF;
Den zu verwendenden Verschlüsselungsalgorithmus setzen Sie wie folgt: RMAN> CONFIGURE ENCRYPTION ALGORITHM 'AES256';
Vor dem Start einer Sicherung oder einer Wiederherstellung ist das passende Wallet zu öffnen: SQL> ALTER SYSTEM SET WALLET OPEN identified by "brussels1";
Fehlt das Wallet, gibt es keine Chance, die Sicherung wiederherzustellen. Password Encryption Der Befehl set
encryption
aktiviert diePasswortverschlüsselung:
RMAN> SET ENCRYPTION ON IDENTIFIED BY einPasswort ONLY; RMAN> BACKUP TABLESPACE USERS;
Vor der Wiederherstellung aus einem verschlüsselten Backup ist ebenfalls das Passwort zu setzen: RMAN> RMAN> RMAN> RMAN> RMAN>
13.3.13 Ausschließen von Tablespaces Tablespaces können aus Sicherungen auch ausgeschlossen werden. Das ist insbesondere dann sinnvoll, wenn nur Temporärdaten enthalten sind, die Daten auf andere Weise als über ein Restore schneller wiederherstellbar sind oder ein Tablespace schreibgeschützt wurde und seine Sicherung separat dauerhaft aufbewahrt wird. RMAN> CONFIGURE EXCLUDE FOR TABLESPACE users_01;
583
13 Backup und Recovery Wenn man nun die Datenbank mit backup database sichert, werden Dateien des Tablespace users_01 übersprungen. Das gilt auch für alle Dateien, die künftig an diesen Tablespace angehängt werden. Soll bei einem Backup ein ausgeschlossener Tablespace explizit mitgesichert werden, so kann die Klausel noexclude verwendet werden: RMAN> BACKUP DATABASE NOEXCLUDE;
Zudem ist es möglich, den Tablespace explizit zu sichern. Dazu verwenden Sie den Befehl backup tablespace: RMAN> BACKUP TABLESPACE users_01;
Der Befehl show
exclude
zeigt von der Sicherung ausgeschlossene Tablespaces:
RMAN> SHOW EXCLUDE;
Der folgende Befehl setzt den Ausschluss wieder zurück: RMAN> CONFIGURE EXCLUDE FOR TABLESPACE users_01 CLEAR;
Der Tablespace users_01 wird nun standardmäßig wieder mit mitgesichert.
13.3.14 Limitierung der Bandbreite Der Channel-Parameter rate limitiert die Rate gelesener Bytes pro Sekunde und verhindert damit, dass eine Datensicherung das gesamte System ausbremst. RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK RATE = 2000K FORMAT = '/backup/mydb_bkup_%U';
13.3.15 Zurücksetzen der RMAN-Konfiguration auf den Standardwert Das Schlüsselwort clear setzt Konfigurationen auf deren Standardwert zurück: RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;
13.3.16 Aufbewahrungszeit von Informationen im Controlfile Der Datenbank-Parameter control_file_record_keep_time bestimmt die Anzahl an Tagen, die Meta-Informationen im Controlfile aufbewahrt werden, bevor sie sich überschreiben lassen. Er sollte auf einen Wert in Höhe der Aufbewahrungszeit von Datensicherungen gesetzt werden: SQL> ALTER SYSTEM SET control_file_record_keep_time = 28;
Der Standardwert ist 7 Tage. Praxistipp Achtung: Achten Sie auf den Wert für die Aufbewahrungstage! Ein hoher Wert führt dazu, dass die Menge der Metainformation, speziell der ROUT-Table anwächst. Dies kann zu PerformanceProblemen bei der Sicherung und Wiederherstellung mit RMAN führen.
584
13.3 Recovery Manager (RMAN)
13.3.17 Sicherungen auf Band einbinden Damit RMAN mit einer Sicherungssoftware bzw. einem Media Manager arbeiten kann, muss zunächst eine spezifische Media Management Library (MML) eingebunden werden, die vom Hersteller als API für RMAN ausgeliefert wird7. Die Standard-MML für Unix-Systeme ist $ORACLE_HOME/lib/libobk.so. Die Dateierweiterung kann allerdings variieren: .so, .sl, .a etc. sind möglich. Auf Windows-Systemen ist die MML unter %ORACLE_HOME%\bin\orasbt.dll zu finden. Die Befehle allocate channel und configure channel bieten zusätzlich die Möglichkeit, über den Parameter sbt_library eine von der Standard-MML abweichende Library zu verwenden. Ein Skript zur Sicherung auf Band kann wie folgt aussehen: RMAN> RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='SBT_LIBRARY=/nsr/lib/libobk.so ENV=(NSR_SERVER=SI,NSR_GROUP=ora)'; BACKUP DATABASE PLUS ARCHIVELOG; BACKUP CURRENT CONTROLFILE; }
Ein Beispiel zu Netbackup auf Solaris: ALLOCATE CHANNEL c1 DEVICE TYPE 'SBT_TAPE' PARMS='SBT_LIBRARY=/usr/openv/netbackup/bin/libobk.so.1';
Omniback / DataProtector auf HP-UX: ALLOCATE CHANNEL c1 DEVICE TYPE 'SBT_TAPE' PARMS='SBT_LIBRARY= /opt/omni/lib/libob2oracle8_64bit.sl';
Sollte die Channel-Allokation fehlschlagen, so gibt RMAN den Fehler ORA-27211 aus und schreibt ein Trace File in das User Dump Destination. Praxistipp Falls eine Sicherung hängt, kann es sein, dass der Media Manager auf das Mounten eines Tapes wartet. Gibt RMAN den Fehler ORA-19511 zurück, so sollten Sie die Konfiguration des Media Managers prüfen.
Einige Hersteller bieten über RMAN hinausgehende Möglichkeiten wie die, Backups auf bestimmte Bänderpools zu sichern. RMAN nimmt hierzu Parameter entgegen, um die Media Management Library zu steuern. Für diese Parametrisierung gibt es zwei Wege:
Umgebungsvariablen, die mit der Klausel ENV der Option PARMS bei einem configure channel
oder allocate
channel
übergeben werden
Der Befehl SEND, über den herstellerspezifische Optionen an den Sicherungskanal gesendet werden können
7
Die MML ist nicht Teil der Oracle-Software. Sie wird in der Regel durch die Installation der Sicherungssoftware implementiert.
585
13 Backup und Recovery Beispiele zur Channel-Konfiguration: CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)'; ALLOCATE CHANNEL c1 DEVICE TYPE 'sbt_tape' PARMS 'ENV=(OB_MEDIA_FAMILY=first_pool)';
Beispiel zur Verwendung des send-Befehls: RMAN> RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; SEND 'OB_DEVICE tape2'; BACKUP TABLESPACE ts_lob_01; }
Mögliche Optionen entnehmen Sie bitte der Dokumentation des Herstellers.
13.3.18 Mehrere Befehle in einem Run-Block bündeln Der Befehl run ermöglicht die Bündelung mehrerer RMAN-Befehle. So kann beispielsweise eine Channel-Allokation erfolgen, die von der Standardkonfiguration abweicht, um anschließend mit diesem Channel eine Sicherung durchzuführen. RMAN> RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT "/backup_remote/%U"; BACKUP DATABASE PLUS ARCHIVELOG; BACKUP CURRENT CONTROLFILE; }
Möchten Sie während einer Sicherung spezielle Channels nutzen, die von der Standardkonfiguration entweder in der Art (Disk, SBT / Bandlaufwerk), der Anzahl (abweichender Parallelisierungsgrad), dem Format (abweichender Pfad auf Disk) oder auch der Parametrisierung abweichen, so können Sie die Allokation der Channels ebenfalls in einem RUNSkript vornehmen: RMAN> RUN { ALLOCATE CHANNEL disk1 DEVICE TYPE ALLOCATE CHANNEL disk2 DEVICE TYPE ALLOCATE CHANNEL disk3 DEVICE TYPE ALLOCATE CHANNEL disk4 DEVICE TYPE BACKUP DATABASE PLUS ARCHIVELOG; }
Auch weitere Befehle lassen sich hiermit bündeln. Folgendes Skript führt ein Restore und ein unvollständiges Recovery durch. Der Zielzeitpunkt wird zunächst mit set until time gesetzt und gilt sowohl für den Restore als auch für das anschließende Recovery: RMAN> RUN { SET UNTIL TIME 'sysdate -8'; RESTORE DATABASE; RECOVER DATABASE; }
586
13.3 Recovery Manager (RMAN)
13.3.19 Durchführung einer Sicherung mit RMAN Sicherungen können in Form von Backupsets, von komprimierten Backupsets und als Image Copy erstellt werden. Die Sicherung in Form von Backupsets erzeugt ein platzsparendes Dateiformat, in dem nur die tatsächlich belegten Datenblöcke gespeichert werden. Eine Sicherung als Image Copy erzeugt eine 1:1-Kopie der Datafiles. RMAN> BACKUP AS BACKUPSET DATABASE; RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE; RMAN> BACKUP AS COPY DATABASE;
Auch einzelne Tablespaces sowie einzelne Datafiles können gesichert werden: RMAN> RMAN> RMAN> RMAN> RMAN>
Möchten Sie während der Sicherung einer Datenbank auch gleich alle zugehörigen archivierten Redologs sichern, so verwenden Sie die Klausel plus archivelog: RMAN> BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG;
Der Standard-Typ einer Sicherung kann auch mit dem werden:
configure-Befehl
vorkonfiguriert
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY;
Eine Sicherung des Standardtyps kann dann – ohne eines der Schlüsselwörter compressed backupset oder copy – wie folgt erzeugt werden:
backupset,
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Möchten Sie jene archivierten Redologs, die gesichert wurden, anschließend aus dem Dateisystem entfernen, so verwenden Sie die Klausel delete input: RMAN> BACKUP DATABASE PLUS ARCHIVELOG DELETE INPUT;
13.3.20 Sicherung der Datenbank im Online- und Offline-Modus Online-Sicherung Um Online-Sicherungen durchführen zu können, muss die Datenbank im ArchivelogModus betrieben werden. In Abschnitt 2.7.12 „Archivelog-Modus“ finden Sie Informationen darüber, wie die Datenbank in den Archivelog-Modus gesetzt werden kann. Die Sicherung kann dann im laufenden Betrieb mit dem Befehl backup database ausgeführt werden: RMAN> BACKUP DATABASE;
587
13 Backup und Recovery Offline-Sicherung Um mit RMAN eine Offline-Sicherung durchzuführen, ist es erforderlich, die Datenbank in den Mount-Status zu bringen. Dann sind die Datafiles nicht geöffnet, die Controlfiles stehen für Lese- und Schreibzugriffe zur Verfügung. Letzteres ist erforderlich, da RMAN die Meta-Informationen zur Datensicherung in die Controlfiles schreibt: RMAN> RMAN> RMAN> RMAN>
SHUTDOWN IMMEDIATE; STARTUP MOUNT; BACKUP DATABASE; ALTER DATABASE OPEN;
Sie können obige Prozedur auch in ein RUN-Script verpacken: RMAN> RUN { SHUTDOWN IMMEDIATE; STARTUP MOUNT; BACKUP DATABASE; ALTER DATABASE OPEN; }
13.3.21 Inkrementelle Sicherung der Datenbank Basis einer inkrementellen Sicherung ist ein Level-0 Incremental Backup. Es sichert alle genutzten Blöcke einer Datenbank. Der Inhalt der Sicherung ist identisch mit einer Vollsicherung: RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE;
Ein Level-1 Incremental Backup sichert nur jene Blöcke, die sich seit dem letzten Level-0Backup geändert haben. Ein Level-1-Backup kann entweder kumulativ inkrementell oder differenziell inkrementell erfolgen. Kumulativ inkrementelle Backups beinhalten alle Blöcke, die seit der letzten Level-0-Sicherung geändert wurden: RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
Ein differenziell inkrementelles Backup sichert alle Blöcke seit dem letzten inkrementellen Backup, egal ob es sich um ein Level-0- oder Level-1-Backup handelte: RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
Inkrementelle Sicherungen können als Online-Backup bei geöffneter Datenbank oder auch als Offline-Backup mit einer Datenbank im Mount-Status erfolgen. Change Tracking Wird Block Change Tracking aktiviert, so verzeichnet Oracle in einem Bitmap, welche Datenblöcke geändert wurden. Dies kann inkrementelle Sicherungen signifikant beschleunigen. SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/opt/oracle/oradata/ora11g/change_track.ctf';
Weitere Informationen entnehmen Sie bitte dem Abschnitt 2.2.12 „Block-Change-Tracking-Protokoll“.
588
13.3 Recovery Manager (RMAN) Inkrementell aktualisierte Sicherung Inkrementelle Sicherungen können auch verwendet werden, um ein Level-0-Backup zu aktualisieren. Dazu wird die neue Level-1-Sicherung mit einer vorhanden Level-0-Sicherung fusioniert: RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'myDB_incr' DATABASE;
13.3.22 Sichern von archivierten Redologs Archivierte Redologs können mit dem Befehl backup
archivelog
gesichert werden:
RMAN> BACKUP ARCHIVELOG ALL;
Die Klausel delete
input
löscht archivierte Redologs nach einer erfolgreichen Sicherung:
RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT;
Die Sicherung von archivierten Redologs kann auch nach Kriterien wie Sequenznummer und Zeitstempel eingeschränkt werden: RMAN> RMAN> RMAN> RMAN> RMAN>
UNTIL TIME 'SYSDATE-5'; FROM TIME 'SYSDATE-31' UNTIL TIME 'SYSDATE-14'; SEQUENCE 1028; FROM SEQUENCE 1028 UNTIL SEQUENCE 1038; ALL NOT BACKED UP 2 TIMES;
13.3.23 Sichern des Controlfiles und SPFiles Controlfiles sind im Zusammenhang mit RMAN ausgesprochen wichtig: Sie enthalten die Metadaten zu den Sicherungen. Ohne sie gibt es keine Wiederherstellung einer Datenbank – zumindest, sofern kein Recovery-Katalog verwendet wird8. Es empfiehlt sich daher, die automatische Sicherung des Controlfiles zu aktivieren: RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Standardmäßig ist diese nicht aktiviert. Übrigens wird bei Aktivierung der Auto-Backups von Controlfiles stets auch das SPFILE mit gesichert. Der folgende Befehl deaktiviert die automatische Sicherung wieder: RMAN> CONFIGURE CONTROLFILE AUTOBACKUP OFF;
Möchten Sie das Controlfile und das SPFILE geziehlt und ohne Auto-Backup sichern, so ist dies mit folgenden Befehlen möglich: RMAN> BACKUP CURRENT CONTROLFILE; RMAN> BACKUP SPFILE;
8
Siehe auch Abschnitt 13.3.33 „Recovery-Katalog“
589
13 Backup und Recovery
13.3.24 Sichern von Sicherungsdateien Auch Datensicherungen lassen sich sichern. So können Sie ein Backup mit einer Sicherung zunächst auf Disk und anschließend von dort in einem zweiten Schritt auf ein Band übernehmen: RMAN> BACKUP RECOVERY FILES;
oder RMAN> BACKUP RECOVERY AREA;
Praxistipp Sofern Sie über ausreichend Plattenplatz verfügen, bietet es sich an, die letzte Vollsicherung sowie die nachfolgenden Sicherungen von archivierten Redologs auf Platte aufzubewahren und ältere Sicherungen auf Band zu übernehmen. Im Falle einer Wiederherstellung haben Sie im wahrscheinlichen Fall, dass die aktuellste Vollsicherung benötigt wird, einen Zeitvorteil: Die Wiederherstellung von Disk ist meist sehr viel schneller als die von einem Bandlaufwerk, das sequenziell gelesen werden muss. Die Sicherung auf Bandlaufwerk ist gut geeignet für die längerfristige Aufbewahrung.
13.3.25 Sprechende Namen mit Tags vergeben Mit der Klausel tag können Sie einer Datensicherung einen aussagekräftigen Namen geben. Tags sind für jede Art Sicherung nutzbar: RMAN> BACKUP AS BACKUPSET DATABASE TAG Montag_vollbckp;
Wird keine Tag-Klausel angegeben, so vergibt RMAN ein Tag im Format THHMMSS.
TAGYYYYMMDD-
13.3.26 Pfade und Namensformate der Backup-Pieces Die Klausel format erlaubt es, Pfade für die Datensicherung festzulegen und ein Format für die Dateinamen von Sicherungsdateien vorzugeben: RMAN> BACKUP DATABASE FORMAT "/disk1/backup_%U";
Gültige Formate zeigt Tabelle 13.2. Tabelle 13.2 RMAN Namensformate Parameter
590
Beschreibung
%a
Activation ID der Datenbank
%b
Dateiname ohne Verzeichnispfad, bspw. wird /ora/mydb/user.dbf zu user.dbf. Kann für Image-Kopien verwendet werden.
%c
Nummer der Kopie bei duplizierten Sicherungen
%d
Datenbank-Name
%D
Aktueller Tag
13.3 Recovery Manager (RMAN) Parameter
Beschreibung
%e
Archivelog Sequence-Nummer
%f
Absolute Dateinummer
%F
Entspricht dem Format c-%I-YYYYMMDD-, mit 1 SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK, ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE" FROM V$SESSION_LONGOPS WHERE OPNAME LIKE 'RMAN%' AND OPNAME NOT LIKE '%aggregate%' AND TOTALWORK != 0 AND SOFAR TOTALWORK;
13.3.28 Reports zu Sicherungen Der list-Befehl zeigt Informationen zu vorhandenen Datensicherungen sowohl von Backupsets als auch von Image-Kopien: RMAN> LIST BACKUP; RMAN> LIST BACKUPSET; RMAN> LIST COPY;
Die Klausel summary führt zur Ausgabe einer zusammenfassenden Übersicht: RMAN> LIST BACKUP SUMMARY; RMAN> LIST BACKUPSET SUMMARY;
Sie können die Anzeige auf Sicherungen der gesamten Datenbank, auf Tablespaces und Datafiles einschränken. Dazu einige Beispiele:
591
13 Backup und Recovery RMAN> LIST BACKUP OF DATABASE; RMAN> LIST BACKUP OF DATABASE SUMMARY; RMAN> LIST BACKUP OF TABLESPACE users_01; RMAN> RMAN> RMAN> RMAN> RMAN>
LIST LIST LIST LIST LIST
COPY OF DATAFILE 1, 2, 3; BACKUP OF DATAFILE 11 SUMMARY; BACKUP OF ARCHIVELOG FROM SEQUENCE 1437; BACKUP OF ARCHIVELOG FROM SEQUENCE 750 UNTIL SEQUENCE 820; COPY OF ARCHIVELOG FROM SEQUENCE 750 UNTIL SEQUENCE 820;
Der folgende Befehl zeigt Dateien der Datenbank, die derzeit kein gültiges Backup besitzen und daher nicht über eine RMAN-Sicherung wiederherstellbar sind: RMAN> REPORT NEED BACKUP;
Der Befehl report obsolete zeigt Sicherungen, die nach den Aufbewahrungsrichtlinien nicht mehr benötigt werden: RMAN> REPORT OBSOLETE;
13.3.29 Prüfung auf Korruptionen Der Befehl validate prüft Datenblöcke auf deren Validität: RMAN> VALIDATE DATABASE;
Sollten Datenblöcke eines Datafiles physisch beschädigt sein, lassen sie sich wie in Abschnitt 13.3.36 „Wiederherstellung eines Datenblockes“ beschrieben reparieren. Die Befehle backup validate und restore validate führen ebenfalls Validierungsprüfungen durch, überprüfen jedoch die jeweiligen Quelldateien. So kann man vor einer Wiederherstellung testen, ob die für einen Restore erforderlichen Dateien valide sind. RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE; RMAN> RESTORE VALIDATE CHECK LOGICAL DATABASE;
Sie können auch einzelne Backupsets validieren: RMAN> VALIDATE BACKUPSET 3;
Backupsets werden über den Primary Key angesprochen, den Sie dem Befehl list entnehmen können.
backup
Die folgenden Befehle prüfen Controlfiles und archivierte Redologs auf Validität: RMAN> VALIDATE CHECK LOGICAL CURRENT CONTROLFILE; RMAN> VALIDATE ARCHIVELOG ALL;
13.3.30 Löschen alter Sicherungen und Dateien Sie können Richtlinien für die Aufbewahrung von Sicherungen erstellen. Hierfür stehen entweder Zeitfenster für die Aufbewahrung oder aber Redundanzrichtlinien zur Verfügung. Ein Zeitfenster gibt die Anzahl an Tagen an, die Sicherungen aufbewahrt werden sollen: RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
592
13.3 Recovery Manager (RMAN) Praxistipp Informationen zu RMAN-Sicherungen sind in den Controlfiles gespeichert. Achten Sie darauf, den Datenbankparameter control_file_record_keep_time auf mindestens die gleiche Anzahl an Tagen zu setzen, wie sie in der RMAN-Aufbewahrungsrichtlinie hinterlegt ist: SQL> ALTER SYSTEM SET control_file_record_keep_time = 14;
Alternativ zu einem Zeitfenster lässt sich die Anzahl vorzuhaltender Sicherungen konfigurieren. Folgende Konfiguration legt fest, dass stets die letzten drei Sicherungen aufzubewahren sind: RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
Aufbewahrungsrichtlinien werden wie folgt deaktiviert: RMAN> CONFIGURE RETENTION POLICY TO none;
Der Befehl report obsolete zeigt Sicherungen an, die nach den Aufbewahrungsrichtlinien abgelaufen sind: RMAN> report obsolete;
Mit delete
obsolete
löschen Sie abgelaufene Sicherungen:
RMAN> delete obsolete;
Der Befehl delete obsolete führt zunächst zu einer Anzeige der Sicherungen, die gemäß der Aufbewahrungsrichtlinien abgelaufen sind. Das Löschen dieser Sicherungen ist interaktiv zu bestätigen. Sofern skriptbasiert ohne diese Sicherheitsabfrage gelöscht werden soll, fügen Sie das Schlüsselwort noprompt hinzu: RMAN> delete noprompt obsolete;
Der Befehl delete löscht Sicherungen – unabhängig von der Aufbewahrungsrichtlinie: RMAN> DELETE BACKUP OF TABLESPACE users DEVICE TYPE DISK;
Der folgende Befehl löscht Sicherungen, die mittels eines Tags identifiziert werden: RMAN> DELETE BACKUP TAG 'before_upgrade';
Siehe hierzu auch Abschnitt 13.3.25 „Sprechende Namen mit Tags vergeben“.
13.3.31 Löschen archivierter Redologs Archivierte Redologs lassen sich mit dem Befehl delete entfernen: RMAN> RMAN> RMAN> RMAN>
DELETE DELETE DELETE DELETE
ARCHIVELOG ALL; NOPROMPT ARCHIVELOG UNTIL SEQUENCE 2900; NOPROMPT ARCHIVELOG UNTIL TIME 'sysdate -3'; ARCHIVELOG ALL BACKED UP 3 TIMES TO SBT;
13.3.32 Langzeitsicherungen Verwenden Sie die keep-Klausel, wenn Sie eine Sicherung über den Zeitraum der Aufbewahrungsrichtlinien hinaus aufbewahren möchten.
593
13 Backup und Recovery RMAN> BACKUP DATABASE TAG jahresbackup KEEP UNTIL TIME 'SYSDATE + 365' LOGS; RMAN> BACKUP DATABASE TAG monatsbackup KEEP UNTIL TIME '01-JAN-2018' LOGS; RMAN> BACKUP DATABASE TAG langzeitbckp KEEP FOREVER LOGS;
Für Langzeitsicherungen, die mit der keep-Klausel erstellt wurden, generiert RMAN mehrere Backupsets. Darin sind Sicherungen der Datafiles, Controlfiles, SPFiles sowie alle für die Wiederherstellung notwendigen archivierten Redologs enthalten. Sofern die Parameter format, pool oder tag verwendet wurden, werden diese auf alle Sicherungen angewandt. Daher ist es erforderlich, dass der format-Parameter für die Erstellung mehrerer Backup Pieces geeignet ist. Am besten verwenden Sie %U9, um eindeutige Namen der Backup Pieces zu erreichen. Die Klausel logs sichert archivierte Redologs mit, während Letzteres ist bei Online-Sicherungen nicht gestattet.
nologs
diese nicht sichert.
Optional können Sie die Restore Point-Klausel verwenden. Sie führt dazu, dass ein Restore Point in der Datenbank angelegt wird, der bei einer späteren Wiederherstellung der Langzeitsicherung verwendet werden kann: RMAN> RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=jahres_backup)'; BACKUP DATABASE TAG jahres_backup_2010 KEEP FOREVER RESTORE POINT bckp_2010_12_31; }
Siehe auch Abschnitt 13.5 „Restore Points“.
13.3.33 Recovery-Katalog RMAN speichert Meta-Informationen zu Sicherungen standardmäßig in den Controlfiles. Optional kann zusätzlich eine RMAN-Katalogdatenbank verwendet werden. Die Aufbewahrungszeit von Sicherungsinformationen in den Controlfiles ist auf maximal 365 Tage begrenzt. Die Default-Einstellung ist 7 Tage. Der Datenbankparameter control_ file_record_keep_time steuert die Aufbewahrungszeit. Eine Katalogdatenbank kann dieselben Informationen unbegrenzt speichern. Sie ist daher bei Langzeitsicherungen sinnvoll. Zudem kann eine Katalogdatenbank die Sicherungsinformationen ihrer gesamten Datenbanklandschaft zentral speichern sowie eine Redundanz herstellen: Die Sicherungsinformationen liegen so nicht nur in den Controlfiles, sondern auch in Ihrem RMAN-Katalog vor.
9
594
Siehe Tabelle 13.2 „RMAN Namensformate“
13.3 Recovery Manager (RMAN) Sie benötigen hierzu ein Schema in einer gesonderten Datenbank. Diese sollte auf einem gesonderten System auf gesonderten Disks gespeichert werden. Praxistipp Es sind keine weiteren Lizenzen für die Katalogdatenbanken erforderlich, sofern diese ausschließlich für die Speicherung der Metadaten von Sicherungen verwendet wird.
Katalog erstellen Zunächst benötigen Sie einen Benutzer, der ausreichend Quota eines Tablespaces zur Speicherung des RMAN-Kataloges erhält. Der benötigte Speicherplatz hängt von der Anzahl der zu sichernden Datenbanken, deren Aufbau sowie der Art und Häufigkeit Ihrer Sicherungen ab. Um das Katalogschema zu erstellen, gehen Sie wie folgt vor: 1. Melden Sie sich an der Datenbank an, in der Sie den RMAN-Katalog speichern möchten: $sqlplus sys@rman_db as sysdba
2. Optional erstellen Sie einen gesonderten Tablespace zur Speicherung des RMANKatalogs: SQL> CREATE TABLESPACE ts_rman DATAFILE 'D:\APP\A\ORADATA\RMAN_DB\rman_01.dbf' SIZE 500 M;
3. Erstellen Sie einen Benutzer, der Owner des RMAN-Katalogschema werden soll: SQL> CREATE USER usr_rman IDENTIFIED BY einPasswort TEMPORARY TABLESPACE temp DEFAULT TABLESPACE ts_rman QUOTA UNLIMITED ON ts_rman;
4. Geben Sie diesem Benutzer die Rolle des Recoverykatalog-Owners: SQL> GRANT RECOVERY_CATALOG_OWNER TO usr_rman;
5. Nun verbinden Sie sich mit RMAN zur Katalogdatenbank und erstellen den RecoveryKatalog: $rman catalog usr_rman/einPasswort@rman_db RMAN> CREATE CATALOG TABLESPACE ts_rman;
Auch für die Katalogdatenbank benötigen Sie ein Sicherungskonzept. Sie können den Sicherungskatalog beispielsweise regelmäßig mit Datapump exportieren. Kapazitätsplanung Sie können die Metainformationen mehrerer Zieldatenbanken gemeinsam in einem Recovery-Katalog speichern. Hierfür sollten Sie den erforderlichen Speicherplatz entsprechend hochrechnen. Der notwendige Speicherplatz für einen RMAN-Katalog hängt unter anderem von folgenden Faktoren ab:
Anzahl der zu sichernden Datenbanken Anzahl der Datafiles der einzelnen Datenbanken 595
13 Backup und Recovery
Häufigkeit der Sicherung Anzahl der Backup Pieces Bei Datenbanken im Archivelog Mode: Häufigkeit der Log Switches Menge und Größe von RMAN-Scripts, die in der Katalogdatenbank gespeichert sind Registrierung der zu sichernden Datenbanken Nur Datenbanken, die im Recovery-Katalog registriert sind, können diese zur Sicherung und Wiederherstellung nutzen. Für die Registrierung melden Sie sich mit RMAN an der Zieldatenbank und der Katalogdatenbank an: $rman target sys@myDB catalog usr_rman@rman_db
Sofern die Zieldatenbank nicht gemountet und nicht geöffnet ist, mounten Sie diese: RMAN> STARTUP MOUNT;
Nun folgt die Registrierung: RMAN> REGISTER DATABASE;
Für Sicherungen und Wiederherstellungen unter Nutzung des Recovery-Kataloges verbinden Sie sich zur Ziel- und zur Katalogdatenbank, zum Beispiel: $rman target sys@myDB catalog usr_rman@rman_db RMAN> BACKUP DATABASE;
Katalog-Upgrade Wird eine Datenbank aktualisiert, die in einem RMAN-Katalog registriert ist, ist dieses Upgrade an den Katalog zu übermitteln. Dazu verbinden Sie sich mit der Katalogdatenbank und geben zweimal den Befehl upgrade catalog ein. Mit der zweiten Eingabe wird der Katalog aktualisiert. $rman target / catalog usr_rman@rman_db RMAN> UPGRADE CATALOG; Befehl UPGRADE CATALOG erneut eingeben, um Katalogumstellung zu bestätigen RMAN> UPGRADE CATALOG; DEREGISTER DATABASE;
13.3.34 RMAN Virtual Private Catalog Der Besitzer eines Recovery-Katalogs hat vollen Zugriff auf alle im Katalog gespeicherten Daten. Unter Sicherheitsaspekten kann es sinnvoll sein, dass Sicherungsbenutzer nur die
596
13.3 Recovery Manager (RMAN) eigenen Meta-Daten sehen können. Mit dem Virtual Private Catalog ist das möglich. Dazu muss zunächst ein Benutzer erstellt werden: SQL> CREATE USER RMAN01 IDENTIFIED BY mein_passwort DEFAULT TABLESPACE vpc_users QUOTA UNLIMITED ON vpc_users; SQL> GRANT RECOVERY_CATALOG_OWNER TO rman01;
Danach melden Sie sich mit RMAN bei der Katalogdatenbank an und erteilen die Rechte für die einzelnen Datenbanken: $rman catalog usr_rman/einPasswort @rman_db RMAN> GRANT CATALOG FOR DATABASE prod01 TO rman01; RMAN> GRANT CATALOG FOR DATABASE prod05 TO rman01; RMAN> GRANT REGISTER DATABASE TO rman01;
Nun kann sich der neue Benutzer eigenen Katalog erstellen:
Die weitere Handhabung des Virtual Private Catalogs entspricht der eines normalen RMAN-Katalogs.
13.3.35 Wiederherstellung: Übersicht Die Wiederherstellung einer Datenbank gliedert sich in zwei Schritte: Restore und Recovery. Der Restore-Vorgang stellt fehlende Dateien wieder her. Bei einem anschließenden Recovery werden fehlende Transaktionen aus den archivierten Redologs erneut ausgeführt. Eine vollständige Wiederherstellung kann wie folgt aussehen: RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; RMAN> ALTER DATABASE OPEN;
Sofern nur einzelne Teile der Datenbank fehlen oder korrupt sind, bietet es sich an, auch nur jene Teile wiederherzustellen − das spart Zeit! Im folgenden Beispiel wird nur ein einzelner Tablespace wiederhergestellt und recovert: RMAN> RMAN> RMAN> RMAN>
Praxistipp Analysieren Sie vor der Wiederherstellung, welche Teile der Datenbank beschädigt sind, und stellen Sie nur wieder her, was notwendig ist! So können Sie die Downtime häufig enorm reduzieren. Sie können einzelne Datenblöcke, Datafiles oder Tablespaces oder aber die gesamte Datenbank mit RMAN wiederherstellen. RMAN führt die Wiederherstellung in vielen Fällen im laufenden Betrieb durch. Testen Sie die Wiederherstellung regelmäßig! Am besten dokumentieren Sie in einem Notfallplan exakt die einzelnen Schritte.
597
13 Backup und Recovery
13.3.36 Wiederherstellung eines Datenblockes Sind in einer Datenbank nur wenige Blöcke wiederherzustellen, kann RMAN anstelle einer vollständigen Wiederherstellung ein Block Media Recovery ausführen. Dies reduziert die Wiederherstellungszeit. Während eines Block Media Recoverys können die betroffenen Datendateien online bleiben und die Benutzer darauf zugreifen. Der Zugriff auf die beschädigten Blöcke ist bis zum Abschluss des Recoverys selbstverständlich nicht möglich. Ermitteln defekter Datenblöcke Für die Wiederherstellung benötigen Sie die Datei- und Blocknummer der zu reparierenden Datenblöcke. Diese können Sie entweder aus einem Trace-File oder über die View v$database_block_corruption ermitteln. Ausschnitt eines Trace Files Liest ein Oracle-Server einen Datenblock, so prüft er diesen auf Konsistenz und schreibt im Fall einer Block-Korruption eine Trace-Datei in das Verzeichnis user_dump_dest und bricht die Transaktion ab. Die Trace-Datei enthält Informationen zur Datei- und Blocknummer des korrupten Blocks. ORA-01578: ORACLE data block corrupted (file # 12, block # 208) ORA-01110: data file 12: '/opt/oradata/mydb/ts_lob_05_01.dbf'
Informationen aus v$database_block_corruption RMAN prüft während Sicherungen jeden Datenblock auf Konsistenz. Greift RMAN während einer Datensicherung oder mittels eines backup validate auf einen beschädigten Block zu, so werden Informationen in der View v$database_block_corruption protokolliert. SQL> SELECT file#, block#, corruption_type FROM v$database_block_corruption;
Möchten Sie die gesamte Datenbank oder Teile davon nochmals auf Blockkorruptionen prüfen, führen Sie ein backup validate aus und prüfen anschließend nochmals die View v$database_block_corruption. Prüfung der gesamten Datenbank: RMAN> BACKUP VALIDATE DATABASE;
Prüfung eines einzelnen Datafiles: RMAN> BACKUP VALIDATE DATAFILE 1;
Wiederherstellung eines Blocks Zur Wiederherstellung eines Blocks benötigen Sie die Datei- und Blocknummer des defekten Blocks. Beides geben Sie im recover-Befehl an: RMAN> RECOVER DATAFILE 12 BLOCK 208;
Der RMAN-Befehl backup validate simuliert eine Sicherung, prüft dabei die Existenz der vorgegebenen Dateien sowie deren Konsistenz und protokolliert korrupte Blöcke in der View v$database_block_corruption: RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;
Der folgende Befehl arbeitet alle Datenblöcke ab, die in protokolliert wurden:
v$database_block_corruption
RMAN> RECOVER CORRUPTION LIST;
In Versionen vor Oracle Database 11g ist der Befehl blockrecover zu nutzen: RMAN> BLOCKRECOVER DATAFILE 12 BLOCK 208;
13.3.37 Wiederherstellung einer Datendatei Beschädigte Datafiles lassen sich entweder im Mount-Status oder bei geöffneter Datenbank wiederherstellen. Letzteres gilt allerdings nicht für Datafiles des SYSTEM-Tablespaces. Defekte Datafiles können Sie über das Alert-Log oder die View mitteln:
v$datafile_header
er-
SQL> SELECT tablespace_name, file#, status, error, name FROM v$datafile_header;
Nach deren Ermittlung setzen Sie den Tablespace offline, stellen die Datei(en) wieder her, recovern diese und setzen den Tablespace wieder online: RMAN> RMAN> RMAN> RMAN>
Wird die Datendatei nicht bei geöffneter, sondern nur mit einer gemounteten Datenbank wiedergestellt, entfallen die Schritte des Offline- und Online-Setzens.
13.3.38 Wiederherstellung eines Tablespaces Die Wiederherstellung eines Tablespaces verläuft analog zur der von Datafiles: Der Tablespace wird offline gesetzt, wiederhergestellt, recovert und anschließend wieder online gesetzt: RMAN> RMAN> RMAN> RMAN>
Auch hier gilt: Wird der Tablespace nicht bei geöffneter, sondern nur mit einer gemounteten Datenbank wiedergestellt, ist das Offline- und Online-Setzen nicht notwendig.
599
13 Backup und Recovery
13.3.39 Wiederherstellung einer Datenbank Die Wiederherstellung einer Datenbank erfolgt mit restore und recover database. Fehlen auch die Controlfiles, so sind diese zuvor im Nomount-Status wiederherzustellen (siehe auch Abschnitt 13.3.41 „Wiederherstellung der Controlfiles“) RMAN> RMAN> RMAN> RMAN> RMAN>
SHUTDOWN IMMEDIATE; STARTUP NOMOUNT; RESTORE CONTROLFILE; # Ohne Recovery-Katalog: RESTORE CONTROLFILE FROM AUTOBACKUP ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE;
Abschließend wird die Datenbank geöffnet: RMAN> ALTER DATABASE OPEN;
13.3.40 Unvollständige Wiederherstellung / Point in Time Recovery Bei einem vollständigen Recovery sind alle archivierten Redologs, die ab Beginn der Datenbanksicherung entstanden sind sowie die aktuellen Online Redologs erforderlich. Fehlt auch nur eine Datei in dieser Reihenfolge, ist kein vollständiges Recovery möglich, allenfalls ein unvollständiges. Ein zweiter typischer Anwendungsfall für ein unvollständiges Recovery ist die Reparatur von logischen Fehlern: Wurden Daten fehlerhaft verändert, so lässt sich mit einem unvollständigen Recovery der Datenbestand zurücksetzen. Beim unvollständigen Recovery werden alle Dateien nur bis zu einem definierten Punkt recovert. Abschließend wird die Datenbank mit dem Befehl alter database open resetlogs geöffnet. Durch die Option resetlogs werden die Online Redolog-Dateien zurückgesetzt. Die Datenbank wechselt in eine neue Inkarnation, die Log-Sequenz-Nummer beginnt wieder bei 1. RMAN> RUN { SET UNTIL TIME 'JAN 1 2010 07:55:00'; RESTORE CONTROLFILE; # Ohne Recovery-Katalog: RESTORE CONTROLFILE FROM AUTOBACKUP ALTER DATABASE MOUNT; RESTORE DATABASE; RECOVER DATABASE; } ALTER DATABASE OPEN RESETLOGS;
Der Befehl list
incarnation
zeigt die Inkarnationen einer Datenbank :
RMAN> LIST INCARNATION;
Praxistipp Beim Öffnen der Datenbank mit open resetlogs wechselt die Datenbank in eine neue Inkarnation. Datenbanken eines Release vor 10g sollten unbedingt sofort gesichert werden, da ein Recovery über den Resetlogs-Zeitpunkt hinweg in diesen Releases noch nicht unterstützt wird.
600
13.3 Recovery Manager (RMAN)
13.3.41 Wiederherstellung der Controlfiles Sofern die Datenbank mehrere Controlfiles besitzt, genügt es, eine vorhandene auf die Position der fehlenden bzw. fehlerhaften Datei zu kopieren. Sind jedoch alle Controlfiles verloren, so ist es erforderlich, diese aus einer Sicherung wiederherzustellen, anschließend die Datenbank zu recovern und mit der Option resetlogs zu öffnen. Um Controlfiles wiederherstellen zu können, muss die Datenbank-Instanz im „nomount“Modus gestartet sein: RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP NOMOUNT;
Sofern Sie Auto-Backups für Controlfiles aktiviert haben, ist die Wiederherstellung recht einfach. Stellen Sie das Controlfile aus einem Auto-Backup oder aus einer ControlfileKopie wieder her: RMAN> RMAN> RMAN> RMAN>
RESTORE CONTROLFILE FROM AUTOBACKUP; ALTER DATABASE MOUNT; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS;
Bei Verwendung einer RMAN-Katalogdatenbank, kann der Befehl restore controlfile verwendet werden. Dazu ist im Anschluss an die Anmeldung an der Katalogdatenbank die DB-ID zu setzen: RMAN> RMAN> RMAN> RMAN> RMAN>
SET DBID=30228820 RESTORE CONTROLFILE; ALTER DATABASE MOUNT; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS;
Praxistipp Sie sollten die DB-IDs Ihrer Datenbanken unbedingt dokumentieren. Die View v$database gibt hierüber Auskunft: SQL> SELECT dbid FROM v$database; DBID ---------30228820 Diese Abfrage funktioniert nur bei einer Datenbank mit vorhandenen validen Controlfiles. Im Fehlerfall – wenn die Controlfiles verloren sind – funktioniert diese Abfrage nicht. Die DB-ID lässt sich über ein Backup Piece oder eine Image Copy eines Undo-Tablespaces, des System- oder des Sysaux-Tablespaces der Datenbank ermitteln. Im System- und im Undo-Tablespace wird die DBID im Header unter MAXVALUE gespeichert, im Tablespace Sysaux ebenfalls im Header hinter „DBID=“. Einige Beispiele:
Undo-Tablespace: strings file_name |grep MAXVALUE System-Tablespace: strings file_name |grep MAXVALUE Sysaux-Tablespace: strings file_name |grep DBID= Präventiv nehmen Sie am besten die Platzhalter %d für den Datenbanknamen und %I für die DBID in das Namensformat für Backup-Pieces auf. Im Falle einer Wiederherstellung der Controlfiles haben Sie so die DB-ID bereits im Namen der Backup-Pieces dokumentiert.
601
13 Backup und Recovery
13.3.42 Data Recovery Advisor (DRA) Die Wiederherstellung einer Datenbank ist – wie viele von Ihnen sicher wissen – eine Wissenschaft für sich. Immer wieder erlebt man die eine oder andere Herausforderung, die mal mehr, mal weniger komplex ist und Spaß beim Tüfteln bringen kann. Doch leider werden Systeme ja nicht betrieben, um uns als Administratoren neue Herausforderungen zu bieten; vielmehr zählt die Verfügbarkeit der Daten, und das heißt: So schnell wie möglich wieder online sein. Im Fehlerfall benötigt ein Administrator meist einige Zeit für die Fehleranalyse. Erst danach kann mit der Korrektur gestartet werden. Oracle Database 11g setzt hier an. RMAN verfügt nun über einen Data Recovery Advisor (DRA). Dieser soll dabei helfen, die richtige Diagnose zu stellen und den schnellstmöglichen Weg zur Wiederherstellung des Datenbanksystems zu finden. Er erkennt Fehler anhand von Symptomen. So deuten beispielsweise Zugriffsfehler auf ein Problem mit einem Datafile hin. DRA erkennt Block-Korruptionen und Fehler im Undo-Bereich, Probleme des Data Dictionary, fehlende Datenbankdateien und vieles mehr. Die Fehler werden kategorisiert: critical, high und low. Incidents werden als offen (open) oder erledigt (closed) angezeigt. Alle Informationen des DRA sind im Automatic Diagnostic Repository (ADR) gespeichert. DRA kann sowohl mit Kommandozeilen im RMAN CLI als auch über die grafische Oberfläche der Enterprise Manager bedient werden. RMAN bietet im Command Line Interface neue Befehle wie: list failure, advise failure und repair failure. Die Ergebnisse sind meist, jedoch nicht immer brauchbar. Bei komplexen Konstellationen ist dann gelegentlich doch wieder „echtes“ Administratoren-Know-how gefragt. Der Befehl list failure gibt Informationen zu Fehlern mit einer der Prioritäten cal oder high aus:
criti-
RMAN> LIST FAILURE;
Sie können den Befehl advise failure aufrufen, um Informationen darüber zu erhalten, wie aktuelle Fehler behoben werden können: RMAN> ADVISE FAILURE;
Eine Reparatur leiten Sie mit repair
failure
ein:
RMAN> REPAIR FAILURE;
Die Klausel preview zeigt eine Voransicht der Reparatur-Befehle, führt diese aber nicht aus. Ein Spool übernimmt Befehle zur Reparatur in eine Datei: RMAN> SPOOL LOG TO '/tmp/repair_test.lst'; RMAN> REPAIR FAILURE PREVIEW; RMAN> SPOOL LOG OFF;
Praxistipp Der Data Recovery Advisor arbeitet ausschließlich in Single-Instance-Umgebungen. Beim Arbeiten mit einer RAC-Datenbank ist es erforderlich, diese im Single-Instance-Modus zu starten. PhysicalStandby-Datenbanken werden nicht unterstützt.
602
13.3 Recovery Manager (RMAN) Die vorgeschlagenen Reparaturoptionen sind meist korrekt. Dennoch sollte man immer noch einen Blick auf die Reparaturvorschläge werfen und sie genau prüfen. Relevante Informationen zu Fehlern findet man in den Views failure_set, v$ir_manual_checklist und v$ir_repair.
v$ir_failure, v$ir_
13.3.43 Übersicht der RMAN-Befehle Tabelle 13.3 RMAN-Befehlsübersicht Befehl
Beschreibung
@
Ausführung eines Befehlsskriptes
@@
Ausführen eines Befehlsskriptes im selben Verzeichnis wie das übergeordnete Befehlsskript
advise failure
Empfehlungen zur Fehlerbehebung anzeigen
backup
Sichern von Datenbanken, Tablespaces, Datafiles, Conrolfiles
catalog
Katalogisieren von Sicherungen in einer Katalogdatenbank
change
Ändern des Status eines Backup Piece, einer Image Copy oder eines archivierten Redologs auf available oder unavailable
configure
Persistente RMAN-Settings konfigurieren
create catalog
Erstellen eines RMAN-Katalogs
crosscheck
Prüfen, welche Dateien noch auf Disk oder Tape vorhanden sind
delete
Löschen von Sicherungen
duplicate
Duplizieren einer Datenbank
flashback database
Zurücksetzen einer Datenbank
list
Anzeige von Informationen zu Sicherungen
list failure
Anzeige aktueller Fehler in der Datenbank
recover
Anwenden von archivierten Redologs, Nachfahren von Transaktionen
register database
Registrieren einer Datenbank im RMAN-Katalog
repair failure
Fehler beheben
report
Anzeige von Sicherungen, die obsolet sind
restore
Wiederherstellen aus einer Sicherung
run
Zusammenfassung von Befehlen in einem Run-Block
set
Setzen von Attributen für die Dauer einer Session oder den Ablauf eines RunBlocks
show
Anzeige persistenter RMAN-Settings
shutdown
Herunterfahren der Datenbank
sql
Ausführen von SQL-Befehlen
startup
Starten der Datenbank
validate
Validieren von Sicherungen
603
13 Backup und Recovery
13.3.44 Monitoring und Troubleshooting Folgende Abfrage zeigt die aktuellen RMAN-Sessions : SQL> SELECT s.sid, p.spid, s.client_info FROM v$process p, v$session s WHERE p.addr = s.paddr AND CLIENT_INFO LIKE 'rman%';
Mit v$session_longops prüfen Sie den Fortschritt einer Sicherung oder Wiederherstellung: SQL> SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK, ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE" FROM V$SESSION_LONGOPS WHERE OPNAME LIKE 'RMAN%' AND OPNAME NOT LIKE '%aggregate%' AND TOTALWORK != 0 AND SOFAR TOTALWORK;
RMAN schreibt Trace Files, sofern ein ORA-600 oder ein ORA-3113 auftritt, ein Channel nicht allokiert wurde oder die Media Management Library nicht geladen werden kann. Die Datei sbtio.log enthält Log-Informationen zur herstellerspezifischen Media Management Library. Sowohl Trace Files als auch sbtio.log stehen im Verzeichnis user_dump_dest. Sofern Sie ermitteln möchten, welchen PL/SQL-Code RMAN generiert bzw. bei welchem Befehl RMAN exakt hängen bleibt oder fehlschlägt, können Sie den debug-Befehl nutzen. Er wird in einen Run-Block eingeschlossen: RMAN> run { debug on; allocate channel c1 type disk; backup datafile 11; debug off; backup datafile 12; }
Der Output ist allerdings enorm. Lassen Sie ihn am besten in ein Tracefile schreiben: $ rman target / catalog rman_user/password debug trace /tmp/debug.log
13.4
Data Pump Mithilfe logischer Sicherungen ist es möglich, logische Strukturen sowie Inhalte zu exportieren und gegebenenfalls später wiederherzustellen. Als Werkzeug ist Data Pump geeignet. Es extrahiert die Definitionen der Datenbank-Objekte wie Indexe, Kommentare oder Constraints und schreibt diese in einen Dump. Anders als bei physischen Backups werden bei logischen Sicherungen nicht die DatenDateien bzw. physischen Blöcke und Strukturen gesichert, sondern die Inhalte der Datenbank-Objekte und die dazugehörige logische Struktur.
604
13.4 Data Pump
13.4.1 Übersicht Die Betriebssystembefehle expdp und impdp starten Data Pump für den Export bzw. Import von Daten. Zentrale Komponente von Data Pump ist die Master-Tabelle. In ihr werden sämtliche Informationen über Data-Pump-Jobs protokolliert. Dazu zählen:
Status der Worker-Prozesse Konfigurationsparameter Restart-Informationen der aktuelle Status jedes Objekts, das ex- oder importiert wird die Stelle im Dumpfile-Set, an der das Objekt gespeichert ist Die Master-Tabelle wird bei der Definition eines Jobs automatisch im Schema des Benutzers erstellt, der den Data-Pump-Job aufruft. Ihr Name entspricht dem des Jobs, der die Master-Tabelle erzeugt hat. Nach erfolgreicher Beendigung eines Jobs wird die zugehörige Master-Tabelle automatisch gelöscht. Stoppt ein Job aufgrund eines Fehlers, bleibt die Master-Tabelle bestehen und die Informationen in der Master Table werden für den Restart des Jobs verwendet. Ein explizites Beenden mit dem Kommando KILL_JOB löscht die Master Table, ein Restart dieses Jobs ist dann nicht mehr möglich. Die Worker-Prozesse werden über den Befehl start_job vom Master-Control-Prozess gestartet. Die Anzahl der Worker-Prozesse entspricht dabei dem Parameter parallel. Sie führen die Ex- und Import-Aufgaben durch und protokollieren, welche Art von Objekten (zum Beispiel Tabellen, Indizes, Views) momentan verarbeitet werden sowie deren jeweiligen Status (zum Beispiel completed, failed, pending, running). Diese Informationen sind für einen Restart des Jobs erforderlich. Data Pump benötigt ein Directory-Objekt in der Datenbank: SQL> CREATE DIRECTORY dp_export AS '/opt/oracle/export';
Der ausführende Datenbank-Benutzer muss Lese- und Schreib-Rechte auf das oben definierte Verzeichnis besitzen: SQL> GRANT READ, WRITE ON DIRECTORY dp_export TO amueller;
Wird kein Verzeichnis definiert, kommt das Standard-Verzeichnis DATA_PUMP_DIR zum Einsatz. Den Pfad können Sie mit folgendem Statement ermitteln: SQL> SELECT DIRECTORY_NAME, DIRECTORY_PATH FROM DBA_DIRECTORIES WHERE DIRECTORY_NAME='DATA_PUMP_DIR';
Data Pump kann entweder interaktiv, per Kommandozeile oder mit einer Parameterdatei aufgerufen werden. Zusätzlich ist es möglich, Data Pump über den Enterprise Manager zu nutzen: expdp <username>/<password> JOB_NAME=<jobname>
Wurde bereits ein expdp-Job gestartet, ist es anders als bei einem konventionellen Export hier über einen interaktiven Aufruf möglich, sich mit einem laufenden Job (in diesem Beispiel expjob) zu verbinden und diesen zu administrieren. Dazu wird der Parameter ATTACH angegeben, gefolgt vom Namen des Jobs, zu dem verbunden werden soll:
605
13 Backup und Recovery expdp <username>/<password> ATTACH=<jobname>
Ruft man expdp ohne weitere Parameter auf, wird anders als beim konventionellen Export sofort ein Export der Tabellen des angemeldeten Benutzers gestartet.
13.4.2 Befehle Das folgende Beispiel exportiert die Tabellen kunden, rechnungen und rechnungspositionen: $ expdp amueller/einPw TABLES=(kunden, rechnungen, rechnungspositionen) $ expdp amueller/einPw PARFILE=tablelist.txt
Die Parameterdatei partables kann dann folgendermaßen aussehen: DIRECTORY=dp_export TABLES=( kunden, rechnungen, rechnungspositionen)
Mit einem Tabellen-Export kann man Tabellen, Partitionen, Subpartitionen und die zugehörigen Objekte exportieren. Die Benutzung von Wildcards ist beim Export von Tabellen möglich: expdp <username>/<password> DIRECTORY= TABLES = , …,
Ein Schema-Export exportiert alle Objekte, die zu einem bestimmten Schema gehören. Dabei sind mehrere Schemata durch Kommata getrennt anzugeben: expdp <username>/<password> DIRECTORY= SCHEMAS=<schema_name>
Ein Tablespace-Export exportiert alle Objekte und Daten inklusive der abhängigen Objekte, die zu einem Tablespace gehören: expdp <username>/<password> DIRECTORY= TABLESPACES=
Mit einem Full-Export werden Objekte der kompletten Datenbank gedumpt. Voraussetzung dafür ist die Rolle EXP_FULL_DATABASE. Beachten Sie, dass bei einem Full-Export System-Schemata wie SYS, MDSYS oder ORDSYS nicht exportiert werden: expdp <username>/<password> DIRECTORY= FULL=Y
Verlassen der Client-Sitzung, der serverbasierte Export-Job läuft jedoch im Hintergrund weiter. Der Status des Jobs kann über die Log-Datei sowie die Views DBA_DATAPUMP_JOBS und V$SESSION_LONGOPS überwacht werden. Über das ATTACH-Kommando von expdp wird der Job erneut administriert und überwacht
FILESIZE
Änderung der Maximal-Größe von nachfolgend erzeugten Dump-Dateien
HELP
Zeigt eine Liste der Kommandos an, die im interaktiven Modus möglich sind
KILL_JOB
Beendet den laufenden Job und dessen Client-Prozesse. Ein Restart dieses Jobs ist nicht mehr möglich
PARALLEL
Ändert die Anzahl der Worker-Prozesse des aktiven Jobs
START_JOB
Startet den Job neu. Der Neustart eines Jobs ist möglich, solange die Master-Tabelle und das Dumpfile Set unbeschädigt sind
STATUS
Zeigt den aktuellen Status des Jobs an. Mit status=n wird das Wiederholungsintervall der Statusanzeige in Sekunden angegeben
STOP_JOB
Stoppt den Job. Ein späterer Restart mit start_job ist möglich
13.4.3 Parameter Tabelle 13.5 Übersicht Data Pump-Parameter Parameter
Beschreibung
ATTACH
Verbindet eine Client-Sitzung mit einem aktuell laufenden DataPump-Export-Job. Der Job wird so interaktiv administriert
COMPRESSION
Aktivierung der Komprimierung ALL: alle Daten, die exportiert werden DATA_ONLY: Nur Dateninhalte METADATA_ONLY: Nur Metadaten bzw. die Objektdefinitionen NONE: keine Komprimierung
CONTENT
Filter, welche Objekte exportiert werden sollen ALL: Dateninhalte und Objektdefinitionen DATA_ONLY: Nur Dateninhalte METADATA_ONLY: Nur Objektdefinitionen
DIRECTORY
Directory-Objekt für das Verzeichnis der Dump-, Log- und SQLDateien.
607
13 Backup und Recovery Parameter
Beschreibung
DUMPFILE
Definiert den Namen und optional das Directory-Objekt für die Dump-Datei. Dieser Parameter übersteuert den Parameter DIRECTORY:
DUMPFILE=dp_export:expdp_myDB.dat Sie können mehrere Dump-Dateien angeben. Über die Nutzung der Variable %U innerhalb eines Dump-Datei-Namens werden bei Ausführung des Jobs dynamisch so viele Dump-Dateien erzeugt, wie man benötigt:
DUMPFILE=dumpdir:expdp%U.dat ESTIMATE_ONLY
Abschätzung des benötigten Platzes für den Export-Job. Es wird jedoch kein Export durchgeführt.
EXCLUDE
Schließt Objekte und deren abhängige Objekte vom Export aus. Welche Objekte ausgeschlossen werden können, zeigen die Views DATABASE_EXPORT_OBJECTS, SCHEMA_EXPORT_ OBJECTS und TABLE_EXPORT_OBJECTS. Es sind auch Jokerzeichen möglich: EXCLUDE=INDEX:"LIKE '%KUNDEN%'"
FILESIZE
Maximale Dateigröße der Dump-Datei(en)
FULL
Alle Daten und Meta-Daten werden exportiert. Schemata wie sys, mdsys oder ordsys werden dabei nicht exportiert
HELP
Anzeige der Hilfe.
INCLUDE
Definiert Objekte, die zu exportieren sind. Die Syntax entspricht der des Parameters EXCLUDE
JOB_NAME
Definiert für den Job einen Namen, der bei weiteren Aktionen wie ATTACH und bei der Überwachung des Jobs verwendet wird
LOGFILE
Definiert den Namen und optional das Directory-Objekt für die Log-Datei: DUMPFILE=mylogdirect:expdp.log
NETWORK_LINK
Wurde beim Aufruf von expdp der Parameter NETWORK_LINK übergeben, so verbindet sich die aktuelle Datenbank mit jener Datenbank, für die der Export über einen Datenbank-Link durchgeführt werden soll. Voraussetzung für die Nutzung des Parameters ist die Definition eines gültigen Datenbank-Links über CREATE DATABASE LINK sowie ausreichende Rechte des Benutzers, der den Export ausführt
PARALLEL
Ändert die Anzahl der Worker-Prozesse bzw. I/O-Server-Prozesse des aktiven Jobs. Der Wert sollte kleiner oder gleich der Anzahl der Dump-Dateien sein. Der Parameter kann während der Ausführung eines Jobs verändert werden
PARFILE
Name der Parameterdatei
QUERY
Filter für den Export einer Teilmenge der Tabellen-Daten Beispiel (Export der Daten der Tabelle gehalt für die Mitarbeiter mit Personalnummer pnr kleiner 50):
QUERY=gehalt:"WHERE kd_nr < 50" Außer den WHERE-Klauseln sind auch andere SQL-Klauseln möglich
608
13.5 Restore Points Parameter
Beschreibung
REUSE_DUMPFILE
Überschreiben von bereits existierenden Dump-Dateien
SCHEMAS
Liste der zu exportierenden Benutzer
TABLES
Liste der zu exportierenden Tabellen, Partitions und Subpartitionen
TABLESPACES
Liste der zu exportierenden Tablespaces
TRANSPORT_TABLESPACES
Export der Metadaten bei transportablen Tablespaces
TRANSPORT_FULL_CHECK
Prüfung der Abhängigkeiten bei einem Tablespace-Transport
TRANSPORTABLE
Wird in Verbindung mit einem Export von Tabellen verwendet und exportiert Metadaten von Tabellen, Partitionen oder Subpartitionen, falls TRANSPORTABLE=ALWAYS gesetzt ist. Die Funktionsweise ist ähnlich TRANSPORT_TABLESPACES, jedoch auf Tabellen, Partitionen und Subpartitionen beschränkt
VERSION
Erzeugt eine Menge an Dump-Dateien, die zu einer älteren Oracle-Version kompatibel sind
13.4.4 Monitoring der Data-Pump-Jobs Im interaktiven Modus ist die Überwachung der Data-Pump-Jobs mit dem Befehl status möglich. Über den Parameter logfile können Sie diese Statusmeldungen in eine LogDatei schreiben lassen. Zusätzlich gibt es noch die Möglichkeit, die Jobs über die View überwachen. Sie zeigt den Fortschritt einer Session an:
v$session_longops
zu
SELECT opname, target_desc, sofar, totalwork FROM v$session_longops WHERE sofar < totalwork;
Darüber hinaus zeigt die View dba_datapump_jobs alle aktiven Data-Pump-Jobs in der Datenbank – unabhängig von ihrem derzeitigen Status. SELECT job_name, operation, job_mode, state, degree FROM dba_datapump_jobs;
13.5
Restore Points Seit Oracle Database 10g gibt es Restore Points. Diese sind mit der System Change Number (SCN) assoziiert. Ein Restore Point setzt damit einen Sicherungszeitpunkt auf, auf den bei Bedarf zurückgerollt werden kann. Gerade im Zusammenhang mit Flashback Database sind Restore Points äußerst hilfreich. So ist es möglich, beispielsweise vor einem Upgrade der Datenbank mit dem Befehl create restore point einen Wiederherstellungspunkt zu erzeugen. Bei Fehlschlagen des Upgrades kann man jederzeit mit dem Befehl flashback database to restore point auf diesen Zeitpunkt zurückgehen. SQL> CREATE RESTORE POINT pre_update GUARANTEE FLASHBACK DATABASE; SQL> SELECT * FROM v$restore_point; RMAN> LIST RESTORE POINT ALL;
609
13 Backup und Recovery Damit ein Restore Point nicht überschrieben wird, kann die Klausel preserve angewandt werden. Sie legt fest, dass bei Überschreitung der maximalen Anzahl speicherbarer Restore Points keine Löschung dieses Wiederaufsatzpunkts erfolgt: SQL> CREATE RESTORE POINT restore_test3 PRESERVE;
Die View v$restore_point zeigt, ob ein Restore Point geschützt ist: SQL> SELECT name, preserved FROM v$restore_point; NAME -----------------------RESTORE_TEST1 RESTORE_TEST2 RESTORE_TEST3
PRESERVED --------NO NO YES
Garantierte Restore Points sind übrigens stets mit dem preserve-Flag versehen. Restore Points können etwa bei einem Flashback als Zielpunkt verwendet werden: RMAN> FLASHBACK DATABASE TO RESTORE POINT before_update; RMAN> ALTER DATABASE OPEN RESETLOGS;
13.6
Flashback „Human Error Correction“ ist das Thema, auf das Oracle mit seinen Flashback-Erweiterungen zielt. Menschliche Fehler sind tatsächlich eine der häufigsten Ursachen für Systemausfälle. Einer Studie von Gartner zufolge fallen 32 Prozent der Downtimes in diese Fehlerkategorie. Oracle will hier Abhilfe schaffen und hat mit der Version 10g eine RestoreMöglichkeit geschaffen, die keine andere Datenbank derzeit in diesem Umfang beherrscht. Flashback heißt die Technologie, die Administratoren das Leben erleichtern soll. Die Recovery Time im Falle von Benutzer- und logischen Applikationsfehlern kann durch Einsatz von Flashback auf wenige Minuten reduziert werden. Hat ein Benutzer versehentlich Daten gelöscht oder in unbeabsichtigter Weise verändert, so gab es – mit Ausnahme von Standby-Konfigurationen mit Delay – bis einschließlich Oracle 9i nur eine Möglichkeit: Die Datenbank musste in solchen Fällen mit einem Backup wiederhergestellt werden, um anschließend alle Transaktionen bis zum Zeitpunkt unmittelbar vor dem Benutzerfehler mittels archivierter Redologs nachzufahren. Insbesondere bei einer großen Datenbank ist dieses Vorgehen ausgesprochen zeitaufwendig. Zudem sind alle Datenänderungen verloren, die Transaktionen nach dem Benutzerfehler betreffen. Flashback bietet für diese Problemstellung einen ganz erheblich vereinfachten Workaround an. Mit wenigen Befehlen lassen sich auf diesem Wege fehlerhaft geänderte oder gelöschte Daten wiederherstellen. Dabei können vier im Hinblick auf Funktionalität, Architektur und Implementierung recht unterschiedliche Flashback-Typen zum Einsatz kommen:
13.6.1 Flashback Database / Zurücksetzen der Datenbank Der Befehl flashback database setzt die Datenbank auf einen Zeitpunkt oder eine SCN zurück. Er bietet eine schnelle Alternative zu einem unvollständigen Datenbank-Recovery. Voraussetzungen sind der Betrieb der Datenbank im Archivelog-Modus sowie die Aktivierung von Flashback Logs: SQL> SQL> SQL> SQL> SQL>
SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABAE ARCHIVELOG; ALTER DATABASE FLASHBACK ON; ALTER DATABASE OPEN;
Flashback Logs werden in die Fast Recovery Area10 geschrieben. Overhead für das Schreiben der Logs entsteht ausschließlich bei Änderungen, nicht bei Abfragen. Er ist abhängig von der Art und Menge der Transaktionen und liegt in der Regel unter 2 Prozent. Die View v$flashback_database_stat gibt hierüber Auskunft. Ein Flashback kann auf einen Zeitstempel, eine System Change Number oder einen Restore Point erfolgen. Der Datenbankparameter db_flashback_retention_target legt die Anzahl an Minuten fest, die durch die Flashback Logs abgedeckt werden. Welches Zeitfenster abgedeckt ist, können Sie mit der View v$flashback_database_log ermitteln. Zum Ausführen des Befehls forderlich. SQL> SQL> SQL> SQL>
flashback database
ist die Systemberechtigung
sysdba
er-
SHUTDOWN IMMEDIATE; STARTUP MOUNT; FLASHBACK DATABASE TO TIMESTAMP SYSDATE-1; ALTER DATABASE OPEN RESETLOGS;
Alternativ zu einem Zeitstempel kann man auch eine System Change Number oder einen Restore Point angeben: SQL> FLASHBACK DATABASE TO SCN 2910439; SQL> FLASHBACK DATABASE TO RESTORE POINT 'PRE_UPDATE';
13.6.2 Flashback Table / Zurücksetzen einer Tabelle Der Befehl flashback table setzt den Datenbestand einer Tabelle zurück auf den eines vergangenen Zeitpunkts. Dazu muss zunächst Row Movement aktiviert sein: SQL> ALTER TABLE t_kundendaten ENABLE ROW MOVEMENT;
Für das Zurücksetzen kann ein Zeitstempel, eine System Change Number oder ein Restore Point genannt werden: SQL> FLASHBACK TABLE t_kundendaten TO TIMESTAMP TO_TIMESTAMP('2010-10-17 07:30:00', 'YYYY-MM-DD HH:MI:SS'); SQL> FLASHBACK TABLE t_kundendaten TO SCN 102934; SQL> FLASHBACK TABLE t_kundendaten TO RESTORE POINT pre_update;
10
Bis Oracle 11g R1: Flash Recovery Area
611
13 Backup und Recovery
13.6.3 Flashback Drop / Wiederherstellen einer gelöschten Tabelle Seit Version 10g stellt Oracle den Recycle Bin zur Verfügung, eine Art Papierkorb. Er bietet die Möglichkeit der schnellen Wiederherstellung nach einem drop table. Den Inhalt des Recycle Bin können Sie sich wie folgt anzeigen lassen: SQL> SELECT * FROM RECYCLEBIN; SQL> SELECT * FROM USER_RECYCLEBIN;
Die Wiederherstellung einer Tabelle ist recht einfach: SQL> FLASHBACK TABLE t_kundendaten TO BEFORE DROP;
Um einen neuen Tabellennamen für die wiederherzustellende Tabelle zu vergeben, verwenden Sie ein rename. Dies ist insbesondere dann erforderlich, wenn inzwischen eine neue Tabelle gleichen Namens erstellt wurde: SQL> FLASHBACK TABLE t_kundendaten TO BEFORE DROP RENAME TO t_kundendaten_old;
13.6.4 Flashback Transaction / Transaktionen zurücksetzen Die View flashback_transaction_query zeigt Informationen über Undo-SQL Statements: SQL> SELECT FROM WHERE
Das Ergebnis der Abfrage gibt Auskunft über den Benutzer, der eine Änderung ausgeführt hat, die betreffende Tabelle und deren Besitzer sowie das Undo SQL Statement zum Rückgängig-Machen der Änderung. Das eigenhändige Herausfinden, welche Abhängigkeiten zwischen eigenständigen und aufeinanderfolgenden Transaktionen bestehen, ist nicht nur mühselig, sondern auch fehleranfällig. Mit Flashback Transaction Backout lassen sich solche Transaktionen einfach identifizieren und mit einem Rollback zurücksetzen, was optional auch für alle abhängigen Transaktionen möglich ist. Um Flashback Transaction Backout zu aktivieren, muss die Datenbank im Archivelog-Modus11 laufen. Danach ergänzen Sie Redologs mit zusätzlichen Transaktionsinformationen: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
Das Ergänzen von Logdaten kann sich bei stark durch DML beanspruchten Umgebungen negativ auf die Performance auswirken. Deshalb sollten Sie vor und nach dem Aktivieren des zusätzlichen Loggings die Systemressourcen im Auge behalten. Um Transaktionen kaskadierend zurückzusetzen, kann man entweder den Enterprise Manager unter der Rubrik „Verfügbarkeit“ oder die Prozedur dms_flashback.transaction_ backout nutzen. 11
Die Transaktions-ID (XID) der zurückzurollenden Transaktion ermitteln Sie am besten über den Logminer: SQL> ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS'; SQL> BEGIN dbms_logmnr.start_logmnr ( starttime => '05-NOV-2010 12:21:10', endtime => '05-NOV-2010 12:21:35', options => dbms_logmnr.dict_from_online_catalog + dbms_logmnr.continuous_mine + dbms_logmnr.no_sql_delimiter + dbms_logmnr.print_pretty_sql ); END; /
Die View v$logmnr_contents zeigt die zur Operation gehörende Transaktionsnummer: column username format a8 column operation format a10 column sql_redo format a35 set lines 10000 set pages 500 SELECT FROM WHERE AND
Die XID (Transaktionsnummer) setzen Sie in den Aufruf der Prozedur back.transaction_backout ein.
dbms_flash-
Praxistipp Vorsicht bei kaskadierendem Flashback Transaction! Prüfen Sie vorab genau die möglichen Auswirkungen.
13.7
Resümee Oracle bietet eine Vielzahl an Sicherungsmöglichkeiten. Planen und testen Sie Ihre Backup- und Recovery-Strategie genau! Es sollten alle Fehlerfälle abgedeckt sein. Neben dem Fehlertyp ist das Zeitfenster für die Wiederherstellung maßgeblich. Stellen Sie nur die fehlerhaften Teile der Datenbank wieder her und erwägen Sie alternative Verfahren wie einen Data-Pump-Import oder ein Flashback. Last but not least: Übung macht den Meister. Das heißt: Testen, testen, testen!
613
13 Backup und Recovery
614
14 14 Verfügbarkeit In diesem Kapitel zeigen wir Ihnen:
die Grid Infrastruktur; Oracle Restart; Real Application Cluster (RAC); RAC One Node; die Einbindung von Third-Party-Applikationen in die Grid Infrastruktur; Data Guard; den Failover von Datenbank-Sessions. In den vergangenen Jahren sind die Anforderungen an die Verfügbarkeit von Anwendungen gestiegen. Oracle bietet schon seit Jahren mit jedem Release neue Funktionen, die diese zunehmend abdecken. So wurde ein Aktiv/Aktiv-Cluster bereits mit Release 6.2 eingeführt. Ab Oracle Database 7.3 konnten Standby-Datenbanken manuell erstellt und ab Oracle 8 i im Managed Recovery Mode betrieben werden. Oracle Database 10 g ergänzte den Funktionsumfang um Flashback, eine Option zur Behebung logischer Fehler. Mit der Version 11 g R2 gibt es zusätzlich Oracle Restart, das lokale Ressourcen überwacht und bei Fehlern neu startet, sowie Erweiterungen rund um den Grid-Infrastruktur-Stack.
14.1
Übersicht Grid Infrastruktur Die Grid Infrastruktur ist ab Oracle 11g R2 ein eigenständiges Softwarepaket, das sowohl für Oracle Real Application Clusters (RAC) als auch für Standalone-Systeme genutzt werden kann. In beiden Umgebungen – Cluster oder Standalone – stellt es Automatic Storage Management (ASM)1 bereit. Für Standalone-Systeme bietet die Grid Infrastruktur das Produkt Oracle Restart, das einen Neustart von Datenbank-Komponenten inklusive aller Ab1
Siehe Kapitel 5 „Automatic Storage Management“.
615
14 Verfügbarkeit hängigkeiten managen kann. In RAC-Umgebungen enthält die Grid Infrastruktur die Oracle Clusterware. Sie ist die Basis für den Betrieb von Rechnern und Software-Komponenten in einem Verbund. Für die Installation der Grid Infrastruktur ist ein separates Home-Verzeichnis erforderlich. Optional kann auch ein separater Benutzer mit einem eigenen Basisverzeichnis verwendet werden. Weitere Informationen zur Installation und Administration der Grid Infrastruktur finden Sie in den Abschnitten 14.2 „Oracle Restart“, 14.3 „Grid Infrastruktur und Oracle Real Application Clusters (RAC)“ und 14.4 „Grid Infrastruktur für Third-Party-Applikationen“.
14.2
Oracle Restart Oracle Restart wurde mit Oracle 11 g R2 eingeführt. Es ist Teil des Grid-InfrastrukturStacks und ermöglicht, Komponenten eines Oracle-Datenbanksystems automatisch neu starten zu lassen, nachdem ein Hardware- oder Software-Fehler aufgetreten ist. Die Funktionsweise ähnelt der eines Clusters, ist jedoch auf Standalone-Systeme mit nur einem Rechner angepasst. Oracle Restart bietet damit zwar keine Redundanz: Fällt ein Rechner aus, so gibt es keinen automatischen oder manuellen Failover. Doch können mittels Restart Dienste eines Rechners überwacht und automatisch inklusive aller Abhängigkeiten neu gestartet werden. Neben Oracle Restart gibt es ab Release 11 g R2 auch Oracle RAC One Node, eine Option, mit der ein echter Aktiv/Passiv-Cluster mit redundanter Hardware konfiguriert werden kann. Weitere Informationen dazu finden Sie in Abschnitt 14.5 „RAC One Node“. Oracle Restart führt regelmäßige Prüfungen auf die Funktionsweise von Komponenten aus. Schlägt eine dieser Prüfungen fehl, wird die Komponente zunächst heruntergefahren und danach neu gestartet. Folgende Komponenten können eingebunden werden:
Eine oder mehrere Datenbank-Instanzen Datenbankservices2 Oracle Listener Eine Instanz des Oracle Automatic Storage Management (ASM) Oracle ASM Diskgroups Oracle Notification Services (ONS/eONS)3 Ein automatischer Neustart erfolgt ausschließlich im Fehlerfall. Wird eine Komponente dagegen gezielt mit Werkzeugen wie Server Control, SQL*Plus oder Listener Control heruntergefahren, so startet Oracle Restart diese nicht automatisch neu. 2 3
616
Mit Ausnahme des Default Service einer Datenbank. In einer Standalone-Serverumgebung kann ONS/eONS für den automatischen Failover einer Data Guard-Konfiguration über Fast Application Notification (FAN) genutzt werden. ONS/eONS sendet dazu FAN Events an Clients.
14.2 Oracle Restart Die Erstellung einer Datenbank mit dem Database Configuration Assistant (DBCA) auf einem System mit Oracle Restart implementiert auch gleich entsprechende Abhängigkeiten zwischen den Komponenten. So wird eine Datenbankinstanz, die ASM nutzt, erst nach der ASM-Instanz und dem Mount der zugehörigen ASM-Diskgruppen gestartet. Ein manueller Stopp oder Start mit Server Control (srvctl) berücksichtigt etwaige Abhängigkeiten. Die Konfiguration von Abhängigkeiten ist auch manuell möglich. Verwenden Sie dazu ebenfalls das Werkzeug „Server Control“. Siehe auch Abschnitt 14.2.3 „Administration“.
14.2.1 Architektur Oracle Restart steht ausschließlich für Standalone-Systeme zur Verfügung und setzt die Installation des Grid-Infrastruktur-Stacks für Standalone-Server voraus. Jedoch lehnt sich die Architektur stark an die der Oracle Clusterware an. Anstelle einer Cluster Registry (OCR) nutzt Restart eine lokale Registry (OLR). Sie enthält Informationen über eingebundene Komponenten und deren Abhängigkeiten. Sie finden diese in $GRID_HOME/cdata/ localhost/$host_name.olr4. Beim Start des Systems wird der Init Daemon des Betriebssystems genutzt. Er ruft das Restart-Wrapper-Skript init.ohasd auf, das wiederum die Daemons und Prozesse ohasd.bin, oraagent.bin, orarootagent.bin, diskmon.bin, cssdagent und ocssd.bin startet. Die inittab wird dementsprechend während der Installation von Oracle Restart modifiziert: # cat /etc/inittab h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 .log CRS Log: /log//crsd/. Das CRS Log wird nach jeweils 10 MB automatisch archiviert. Die Dateinamen lauten bspw. crsd.l01, crsd.l02 usf.
CSSD Log:
/log//cssd/. Das CSSD Log wird nach jeweils 20 MB archiviert und erhält dann einen Dateinamen wie cssd.l01, cssd.l02, usw.
EVM Log: /log//evmd. SRVM Log (srvctl): /log//client OCR Log (ocrdump, ocrfonfig, ocrscheck): $ORACLE_HOME/log//client/ 14.3.6 Grid Plug and Play (GPnP) Grid Plug and Play (GPnP) vereinfacht es ab 11 g R2, Cluster-Knoten hinzuzufügen, zu verschieben und zu löschen. Cluster sind somit einfacher dynamisch verwaltbar und konfigurierbar. In älteren Releases war dies mit aufwendigen manuellen Tätigkeiten verbunden.
14.3.7 Grid Naming Service (GNS) Der Grid Naming Service (GNS) ist Teil der GPnP-Features ab Oracle RAC 11g R2. Er stellt die Namensauflösung für das Cluster zur Verfügung. Um GNS zu aktivieren, benötigen Sie ein Set von IP-Adressen einer Subdomain. Eine manuelle Konfiguration des Oracle Listeners ist dann nicht notwendig. Anfragen an die Cluster Domain werden an eine GNS Virtual IP-Adresse geroutet.
624
14.3 Grid Infrastruktur und Oracle Real Application Clusters (RAC)
14.3.8 Single Client Access Name (SCAN) Ab Oracle Database 11 g R2 können sich Clients mittels Single Client Access Name (SCAN) zu RAC-Datenbanken verbinden. SCAN bezeichnet einen DNS-Namen, hinter dem drei IP-Adressen stehen. Die Grid Infrastruktur nutzt diese als virtuelle IP-Adressen. Jede davon erhält einen eigenen SCAN-Listener, der zusammen mit der SCAN-IP zwischen den Knoten hin und her geschwenkt werden kann. Die Anzahl der SCAN-IPs ist unabhängig von der Knotenanzahl. SCAN lässt sich beispielsweise mit JDBC Thin URLs oder EZConnect verwenden und unterstützt Load Balancing und Client Failover. Damit vereinfacht sich die Adressierung einer RAC-Datenbank beispielsweise in URLs oder tnsnames: Mit SCAN ist nur noch ein ADDRESS-Eintrag erforderlich; der Eintrag unterscheidet sich damit nicht mehr von dem einer Single-Instance-Installation. Deshalb muss man die Verbindungsinformation des Clients nicht mehr ändern, wenn ein Rechner zum Cluster hinzugefügt oder aus ihm entfernt wird. SCAN wird während der Installation der Oracle Grid Infrastruktur konfiguriert. Sie können die SCAN-IPs in den Grid Naming Service (GNS) von Oracle oder aber in einen vorhandenen Domain Name Service (DNS) einbinden. Im letztgenannten Fall benötigen Sie von Ihrem Netzwerk-Administrator einen Namen, der in einem Round-Robin-Verfahren in drei IP-Adressen aufgelöst wird.
14.3.9 Installation Bis Oracle 11 g R1 war die Oracle Clusterware getrennt von ASM- und Datenbanksoftware zu installieren. Ab 11 g R2 bildet die Clusterware gemeinsam mit ASM die Oracle Grid Infrastruktur: ASM und Clusterware sind hier in einem gemeinsamen Verzeichnis hinterlegt. Als Basis für die Installation der Oracle 11 g R2 Grid Infrastruktur gibt es drei Optionen:
Ein von Oracle zertifiziertes Cluster File Systems (CFS) Ein von Oracle zertifiziertes Network File System (NFS) Automatic Storage Management (ASM) Praxistipp Installationen von Oracle 11 g R2 auf Block oder Raw Devices werden nicht mehr unterstützt. Wird eine ältere Clusterversion aktualisiert, so können – beispielsweise während eines Rolling Upgrades – zunächst vorhandene Block- oder Raw Devices genutzt werden. Nach Abschluss der Aktualisierung können auch OCR- und Voting Devices migriert werden.
Für Oracle 11 g R2 sind je 280 MB für ein Voting Device bzw. ein OCR-File erforderlich. Zukünftige Installation werden jedoch sicherlich größere Files benötigen. Oracle Clusterware (bis 11g R1) bzw. die Grid Infrastruktur (ab 11g R2) ist als erstes Oracle-Softwareprodukt zu installieren. Alle nachfolgenden Installationen erkennen die
625
14 Verfügbarkeit Grid Infrastruktur und stellen gegebenenfalls erweiterte Optionen wie beispielsweise die Installation von Oracle RAC bereit. Die Installation der Oracle Clusterware ab 11g R2 wird mit einem Aufruf des Oracle Installers der Grid Infrastruktursoftware von einem der Cluster-Knoten aus gestartet. Wählen Sie anschließend „Grid Infrastruktur für einen Cluster installieren“. Für die Installation sind folgende Schritte erforderlich: 1. Prüfen der System-Voraussetzungen Prüfen des Betriebssystems und des Releases/der Kernel-Version auf Zertifizierung für den Oracle Cluster.10 Prüfen der Installationsvoraussetzungen gemäß des Release- und Plattform-spezifischen Installationsguides.11 2. Prüfen der Netzwerk-Voraussetzungen Jeder Knoten benötigt mindestens zwei Netzwerk-Interfaces. Die Interface-Namen für das Public und das Private Interface müssen knoten-übergreifend identisch sein. Beispiel: eth0 auf allen Knoten für das Private Interface, eth1 für das Public Interface. Die Public IP-Adresse muss über DNS oder /etc/hosts auflösbar sein. Die Private IP-Adresse muss über /etc/hosts auflösbar sein. Die Cluster GNS-Adresse muss über DNS auflösbar sein. 3. Installation erforderlicher Betriebssystem-Packages Welche Betriebssystem-Packages erforderlich sind, finden Sie in der betriebssystemspezifischen Installationsdokumentation. 4. Setzen von Kernel-Parametern und Shell-Limits Setzen von Kernelparametern Bearbeiten bspw. der limits.conf und der pam_limits.so 5. Erstellen von Gruppen, Benutzern und Verzeichnissen Erstellen der Gruppe oinstall und dba Erstellen der Benutzer oracle und grid Erstellen der Verzeichnisse für das Grid-Home und die Oracle-Software 6. Installation der Grid Infrastruktur Die Installationsroutine wird mit dem Befehl ./runInstaller der Grid-Software aufgerufen und führt durch alle weiteren Konfigurationsschritte. Alle übrigen ClusterKnoten werden von der Installationsroutine automatisch über ssh mit der Software bestückt.
10 11
626
Informationen zu Zertifizierungen finden Sie über My Oracle Support. Beispielsweise unter http://www.oracle.com/pls/db112/homepage
14.3 Grid Infrastruktur und Oracle Real Application Clusters (RAC) Praxistipp Die Installation der Grid Infrastruktur wird mit dem Ausführen von Root-Skripten abgeschlossen (siehe Abbildung 14.2). Starten Sie das Root-Skript zunächst nur auf dem ersten Knoten und warten Sie unbedingt, bis dieses erfolgreich abgeschlossen ist! Erst dann, wenn die Clusterware auf dem ersten Knoten erfolgreich gestartet wurde, beginnen Sie mit dem zweiten Knoten. Verfahren Sie ebenso bei weiteren Knoten.
7. Installation der Datenbanksoftware Siehe auch Abschnitt 1.1 „Die Datenbank-Software installieren“. Zusätzlich zu den in Kapitel 1 angegebenen Schritten werden Sie nach einigen Cluster-Spezifika gefragt.
Abbildung 14.2 Die Installation der Datenbanksoftware wird mit der Ausführung von Root-Skripten abgeschlossen
8. Implementation der Cluster-Datenbanken Auch im Cluster werden Datenbanken mit dem Database Configuration Assistant (DBCA) oder manuell mittels SQL-Befehlen erstellt. Bei der manuellen Erstellung ist zu beachten, dass RAC-Datenbanken Besonderheiten bzgl. der Konfiguration aufweisen. So benötigt jeder Cluster-Knoten ein eigenes Set an Redolog-Files (Threads) sowie jeweils einen eigenen Undo Tablespace.
627
14 Verfügbarkeit
14.3.10 Administration Eines der wichtigsten Verwaltungswerkzeuge des Oracle Clusters ist crsctl. Das Kürzel crs steht für Cluster Ready Services, ctl für Control. Der Befehl crsctl wird jeweils um ein Verb und ein Objekt sowie eventuelle Schalter erweitert. Eine allgemeine Hilfe erhalten Sie hiermit: crsctl -help
Möchten Sie die Hilfe zu einer Befehlserweiterung erhalten, beispielsweise zum StartBefehl, so ergänzen Sie das jeweilige Verb um den Schalter -help: crsctl start -help
Die Clusterware kann auf einem einzelnen Cluster-Knoten – oder auf allen – sowohl gestartet als auch gestoppt werden: crsctl start cluster -n server_name crsctl start cluster -all crsctl stop cluster -n server_name crsctl stop cluster -all
Den aktuellen Status prüft der Befehl check: crsctl check cluster -all crsctl check cluster -n server_name
Die Konfiguration zeigt der folgende Befehl. Er gibt unter anderem Auskunft, ob die Clusterware bei einem Startup automatisch gestartet wird: crsctl config crs
Den automatischen Start der Clusterware konfigurieren Sie mit enable bzw. disable
crs:
crsctl enable | disable crs
Voting Devices verwalten Pfad und Namen der Voting Devices Ihres Clusters zeigt der folgende Befehl: crsctl query css votedisk
Sie können Voting Devices der bestehenden Konfiguration hinzufügen: crsctl add css votedisk /dev/dsk/disk1 /dev/dsk/disk2 /dev/dsk/disk3
Der Schalter -purge sorgt dafür, dass vorhandene Voting Devices durch neue ersetzt werden. Mit replace können Sie bestehende Voting Devices ersetzen: crsctl replace votedisk /mnt/nfs/disk1 /mnt/nfs/disk2
Es ist außerdem möglich, ein Voting Device explizit zu entfernen: crsctl delete css votedisk /mnt/nfs/disk1
Oracle Cluster Registry (OCR) verwalten Zur Verwaltung der OCR kommen die Werkzeuge ocrcheck, ocrdump und ocrconfig zum Einsatz. Der folgende Befehl zeigt bestehende Sicherungen:
628
14.3 Grid Infrastruktur und Oracle Real Application Clusters (RAC) ocrconfig -showbackup
Folgender Befehl sichert in den Standard-Backup-Pfad $GRID_HOME/cdata/host_name: ocrconfig -manualbackup
Der Standardpfad der Sicherung kann auch geändert werden: ocrconfig -backuploc new_OCR_backup_path
Alternativ lässt sich der Pfad- und Dateiname während der Sicherung explizit angeben: ocrdump -backupfile OCR_backup_file_name
Die Wiederherstellung der OCR erfordert, dass die CRS zuvor gestoppt werden: # # # # # #
Den Inhalt der OCR dumpt der folgende Befehl auf Standard Out: ocrdump -stdout
Der Befehl ocrdump kennt etliche Optionen. So können Sie beispielsweise die Ausgabe auf einen bestimmten Schlüssel und seinen Wert begrenzen oder die Inhalte der OCR in eine XML-Datei schreiben. Ocrdump erzeugt zudem ein Logfile in grid_home/log/host_ name/client. Um den Log-Level zu ändern, muss die Datei grid_home/srvm/admin/ ocrlog.ini angepasst werden. Der Eintrag comploglvl enthält die Log-Level der einzelnen Komponenten. Der Befehl ocrcheck zeigt unter anderem den genutzten Speicher, die OCR-ID sowie die Lage der OCR. Der Befehl führt außerdem eine blockweise Checksummen-Berechnung aus und gibt für jede OCR-Datei den Status der Integritätsprüfung zurück. # ocrcheck Status of Oracle Cluster Registry is as follows : Version : 3 Total space (kbytes) : 282224 Used space (kbytes) : 812 ID : 2014233231 Device/File Name : +dg_ocr_01 Device/File integrity check succeeded Device/File Name : +dg_ocr_01 Device/File integrity check succeeded Device/File not configured Device/File not configured Device/File not configured Cluster registry integrity check succeeded Logical corruption check succeeded
Inhalte der OCR lassen sich auch exportieren und importieren: ocrconfig -export file_name ocrconfig -import file_name
Verwaltung von Datenbank-Services im Cluster Komponenten eines RAC können – ähnlich wie in Oracle Restart – mit Server Control (srvctl) konfiguriert und gesteuert werden (siehe Abschnitt 14.2.3 „Administration“).
629
14 Verfügbarkeit
14.3.11 Server Pools Ein Server Pool ist eine logische Einheit, die einen Cluster in Pools von Cluster-Knoten unterteilt. Üblicherweise handelt es sich bei einem Pool um ein Subset der Cluster-Knoten. Jeder Server Pool muss einen eindeutigen Namen im Cluster haben. Mit der Oracle Clusterware werden automatisch zwei Server Pools erstellt: „GENERIC“ und „FREE“. Alle neuen Installationen werden automatisch dem FREE-Server-Pool zugeordnet. Server Pool-Attribute können die Eigenschaften eines Pools bestimmen. Das einzig zwingende Attribut ist der Name des Pools. Alle anderen sind optional konfigurierbar. Hierzu zählen:
ACL: Festlegung der Rechte im Format owner:user:rwx,pgrp:group:rwx,other::r ACTIVE_SERVERS: Eine kommaseparierte Liste von Servern, die aktuell zu einem Server Pool zugeordnet sind
IMPORTANCE: Wert zwischen 0 und 1000, der die Gewichtung in Relation zu anderen Server Pools festlegt
MAX_SIZE: Bestimmt die maximale Anzahl an Servern in einem Pool. Der Wert -1 ist Standard. Er steht für den gesamten Cluster.
MIN_SIZE: Legt die minimale Größe eines Pools fest PARENT_POOLS: Erlaubt die Erstellung von Nested Pools SERVER_NAMES: Liste der Cluster-Knoten, die Kandidaten für einen Pool sind und mit diesem assoziiert werden können Server Pools können mit srvctl und crsctl erstellt werden: $ crsctl add serverpool SP1 -attr "MIN_SIZE=2, MAX_SIZE=5, IMPORTANCE=3" $ srvctl add srvpool -g SP1 -l 2 -u 5 -i 3 -n "server1,server2"
14.3.12 Administrator-managed und Policy-managed Cluster Ab Oracle 11 g R2 stehen zwei Konfigurationen für das Ressourcen-Management eines RAC zur Verfügung: Administrator-managed und Policy-managed. Beide nutzen einen Server Pool, eine logische Einheit, die einen Cluster in Pools von Servern unterteilt. In einem Administrator-managed Cluster werden Datenbank-Ressourcen vom Administrator an die Cluster-Knoten zugewiesen. Für Cluster mit einer kleinen Anzahl an Knoten ist dies gut geeignet. In einem Policy-managed Cluster wird die Zuordnung von Ressourcen zu Cluster-Knoten über Server Pools gehandhabt. Die Oracle Clusterware ist dann verantwortlich für die Platzierung von Datenbank-Ressourcen an einen spezifischen Server im Cluster. Die physische Zuordnung einer Ressource zu einem Cluster-Knoten ist damit nicht mehr erforderlich. Dies eignet sich bei einer großen Anzahl an Cluster-Knoten und ist gut mit einem Workload Management kombinierbar. Eine Administrator-Managed Ressource wird beispielsweise wie folgt erstellt:
Eine Policy-Managed Ressource wird beispielsweise so erstellt: # crsctl add resource myApache -type cluster_resource -attr "ACTION_SCRIPT=’ /app/clust/res/myapache.scr’, PLACEMENT=’restricted’, SERVER_POOLS=’myServerPool’, CHECK_INTERVAL=’30’, START_DEPENDENCIES=’hard(appsvip)’, STOP_DEPENDENCIES=’hard(appsvip)’,RESTART_ATTEMPTS=’2’,"
14.4
Grid Infrastruktur für Third-Party-Applikationen Bereits seit Version 10 g R2 ist es möglich, Third-Party-Applikationen in die Verwaltung durch die Clusterware mittels eigens geschriebener Skripte einzubinden. 11 g R2 bietet eine konsequente Weiterentwicklung dieses Features.
14.4.1 Installation Die Installation erfolgt über die Implementierung der Grid Infrastruktur bzw. der Clusterware (siehe Abschnitt 14.3 „Grid Infrastruktur und Oracle Real Application Clusters (RAC)“).
14.4.2 Administration In den Versionen 10 g R2 und 11 g R1 können externe Ressourcen mittels der crs-Befehle in das Cluster eingebunden werden. Dazu ist wie folgt vorzugehen: 1. Erstellung eines Action Scripts, das von der Clusterware aufgerufen werden kann. 2. Erstellung des Applikationsprofils mit dem Befehl crs_profile. 3. Registrieren des Profils mit dem Befehl crs_register. 4. Setzen von Berechtigungen mit dem Befehl crs_setperm. Danach ist die Ressource mittels Oracle Clusterware administrierbar. In 11 g R2 ist dieses Vorgehen prinzipiell möglich. Jedoch sind die bisher verwendeten Kommandozeilenwerkzeuge veraltet. Stattdessen sind nur noch zwei Befehle notwendig:
crsctl: Verwaltet den Clusterstack sowie alle externen Ressourcen srvctl: Steuert interne Oracle-Ressourcen Ressourcen und Ressourcen-Typen Eine Ressource ist eine Komponente, die in das Cluster eingefügt und von ihm verwaltet wird. Ressourcen sind innerhalb eines Clusters zwar einmalig, doch haben manche einige gemeinsame Eigenschaften. Diese können in Ressourcen-Typen zusammengefasst werden. So können Ressourcen über deren Typ verwaltet werden.
631
14 Verfügbarkeit Jede Ressource, die im Cluster registriert wird, muss einem Ressourcen-Typen zugeordnet sein. Oracle bietet innerhalb der Clusterware Standard-Typen an: local_resource und cluster_ressource12. Zusätzlich können Sie benutzerdefinierte Ressourcen-Typen mit dem Clusterware Control (crsctl) erstellen. Action Scripts und Attribute Ein Action Script implementiert die eigentliche Steuerung des Agenten. Sie können es als Shell-Skript oder mit C/C++ implementieren. Es muss mindestens folgende Einstiegspunkte beinhalten:
Start: Starten einer Ressource Stop: Stoppen einer Ressource Check: Prüfen einer Ressource Clean: „Aufräumen“ einer Ressource Abort (optional): Abbruch einer Ressource; wird stets dann aufgerufen, wenn einer der anderen Einstiegspunkte hängt und nicht innerhalb eines angegebenen Timeouts beendet wurde. Die Registrierung der Ressource erfolgt dann mit crsctl: $ crsctl add resource resource_name -type resource_type [-file file_path] | [-attr "attribute_name='attribute_value', attribute_name='attribute_value', ..."]
Folgender Befehl konfiguriert beispielsweise einen Apache als Cluster-Ressource: $ crsctl add resource myApache -type cluster_resource -attr "ACTION_SCRIPT=/opt/cluster/scripts/myapache.scr, PLACEMENT='restricted', SERVER_POOLS=myApache_sp, CHECK_INTERVAL='30', RESTART_ATTEMPTS='2', START_DEPENDENCIES='hard(appsvip)', STOP_DEPENDENCIES='hard(appsvip)'"
Der Name des Ressourcen-Typs wird mit dem Argument -type übergeben. Attribute können entweder mit einer Text-Datei, deren Name mit dem Argument -file übergeben wird, oder mit einer kommaseparierten Liste als Attribute-Werte-Paar gesetzt werden. Eine Attribute-Datei kann beispielsweise so aussehen: PLACEMENT=favored HOSTING_MEMBERS=node1 node2 node5 RESTART_ATTEMPTS@CARDINALITYID(1)=0 RESTART_ATTEMPTS@CARDINALITYID(2)=0 FAILURE_THRESHOLD@CARDINALITYID(1)=2 FAILURE_THRESHOLD@CARDINALITYID(2)=4 FAILURE_INTERVAL@CARDINALITYID(1)=300 FAILURE_INTERVAL@CARDINALITYID(2)=500 CHECK_INTERVAL=2 CARDINALITY=2
Mit Oracle Database 11 g R2 wurden Attribute, die eine Ressource haben können, nochmals erweitert. Die Wichtigsten sind:
12
632
Ressourcen vom Typ local_resource werden auf jedem Cluster-Knoten gestartet. Ressourcen vom Typ cluster_resource sind dagegen „cluster aware“ und können per Switchover und Failover den Cluster-Knoten wechseln.
14.4 Grid Infrastruktur für Third-Party-Applikationen
ACTION_SCRIPT: Name des auszuführenden Skripts AGENT_FILENAME: Agentenprogramm für die Ressource AUTO_START: Ist dieses Attribut auf always gesetzt, wird die Ressource gestartet, gleich, welchen Status sie beim Stoppen hatte. Der Wert restore führt dazu, dass der letzte bekannte Status wiederhergestellt wird. Ein never bewirkt, dass eine Ressource nicht automatisch gestartet wird.
CHECK_INTERVAL: Intervall für Check-Aufrufe in Sekunden FAILOVER_INTERVAL und FAILOVER_THRESHOLD: Diese Attribute legen fest, ab wann eine Ressoure als fehlerhaft erkannt und auf einen anderen Knoten übernommen wird. Bei einem Intervall von 30 und einem Threshold von 4 wird die Ressource alle dreißig Sekunden auf Validität geprüft. Ist diese Prüfung viermal fehlgeschlagen, wird die Ressource auf einen anderen Knoten verschoben und dort gestartet.
PLACEMENT: Legt fest, wie die Oracle Clusterware den Server für den Start einer Ressource auswählt und wohin nach einem Server-Fehler eine Relokation erfolgt. Mit hosund server_pools legen Sie fest, welche Server berechtigt sind, die Ressource zu starten. Wird das Attribut Placement auf den Wert balanced gesetzt, so kann die Ressource auf jedem Server laufen, der online ist. Mit dem Wert favored dagegen können favorisierte Server, mit restricted eine restriktive Serverliste konfiguriert werden. ting_members
SCRIPT_TIMEOUT: Legt fest, wie viele Sekunden ein Script laufen darf, bis es in einen Timeout läuft und ABORT aufgerufen wird.
START_DEPENDENCIES und STOP_DEPENDENCIES: Hier kann man Ressourcen-Abhängigkeiten für das Starten und Stoppen hinterlegen. Eine typische Abhängigkeit ist die einer Datenbank, die auf einer ASM-Diskgroup basiert: Die Datenbank darf nur starten, wenn zuvor die ASM-Diskgroup gemountet ist. Umgekehrt darf die ASMInstanz erst dann heruntergefahren werden, wenn die Datenbank zuvor gestoppt wurde. Solche Abhängigkeiten lassen sich mit diesen Attributen auch für Third-Party-Anwendungen implementieren.
UPTIME_THRESHOLD: Legt fest, nach welchem Zeitraum die Clusterware eine Ressource als stabil einstuft. Nach Ablauf dieses Zeitraums wird der interne Zähler für Startversuche auf 0 zurückgesetzt. Der Zeitraum wird durch einen Integer-Wert, gefolgt von einem Zeitmarker (s für Sekunde, m für Minute, h für Stunde, d für Tage oder w für Wochen), angegeben. Wird eine Ressource basierend auf einem Ressourcen-Typ erstellt, so erbt sie dessen Attribute. Vererbte Attribute lassen sich ihrerseits überschreiben und erweitern. Aktuelle Attribute zeigt der Befehl crsctl status type -p
Eine Clusteranwendung kann auf jedem Server im Cluster gestartet werden, sofern:
dies den Policies entspricht, die konfiguriert wurden, Ressourcen, von denen die Applikation abhängig ist, gestartet wurden, das Action Script auf dem Server verfügbar ist. 633
14 Verfügbarkeit Abhängigkeiten definieren
Auch für Third-Party-Applikationen können Abhängigkeiten definiert werden. Das folgende Beispiel definiert die Ressource myApache als abhängige Komponente der Ressource appsvip: crsctl add resource myApache -type cluster_resource -attr "ACTION_SCRIPT=/opt/cluster/scripts/myapache.scr, PLACEMENT=restricted, SERVER_POOLS=server_pool_list,CHECK_INTERVAL=30,RESTART_ATTEMPTS=2, START_DEPENDENCIES=hard(appsvip),STOP_DEPENDENCIES=hard(appsvip)"
Berechtigungen Ein Benutzer, der eine Ressource dem Cluster hinzugefügt hat, ist deren Owner. Jede Ressource läuft unter ihrem Owner. Manche Ressourcen müssen von root gemanagt werden. Wurde nun eine Ressource, die unter root laufen muss, von einem anderen Owner als root hinzugefügt, so ist es erforderlich, die Berechtigungen dementsprechend zu ändern: # crsctl setperm resource resource_name -o root
Zusätzlich muss der Benutzer, der die Oracle Clusterware installiert hat, Berechtigungen erteilen. Im folgenden Beispiel erhält der Benutzer oracle entsprechende Rechte: $ crsctl setperm resource resource_name -u user:oracle:r-x
Abschließend wird die Cluster-Ressource gestartet: $ crsctl start resource resource_name
14.5
RAC One Node Ab 11 g R2 gibt es die Option, einen Aktiv/Passiv-Cluster mit der Option „RAC One Node“ zu betreiben. Hierzu werden wie bei einem Standard-RAC die Grid Infrastruktur und die Datenbanksoftware installiert. Auch die Verwaltungswerkzeuge sind dieselben wie die des RAC. Einziger Unterschied: Es ist nur eine Instanz aktiv. Auf den ersten Blick scheint RAC One Node im Widerspruch zum bisherigen Konzept des Aktiv/Aktiv-Clusters zu stehen. Tatsächlich schließt diese Option aber eine Lücke. Bisher war für die Implementierung eines Aktiv/Passiv-Clusters stets die Clusterware eines Drittherstellers wie Veritas Cluster, Sun Cluster oder HACMP erforderlich. Künftig genügt die Verwendung der Oracle Clusterware bzw. der Oracle Grid Infrastruktur. So können, wie im Standard-RAC, rollierende Upgrades zum Einsatz kommen. Zudem ist ein Upgrade zu einem vollständigen RAC problemlos möglich. Ein geplantes Schwenken ist mit RAC One Node mit deutlich geringerer Downtime verbunden, als es in anderen Clustersystemen der Fall ist. OMotion nennt sich das Verfahren, das an VMotion aus dem VMWare-Umfeld erinnert. Hierzu nutzt RAC One Node vorübergehend zwei Knoten. Neue Anmeldungen werden nur an die neue Instanz weitergegeben. Nach einem konfigurierbaren Timeout, längstens jedoch nach 30 Minuten, werden alle
634
14.6 Oracle Data Guard Sessions der alten Instanz beendet. Diese können sich unmittelbar neu anmelden, da die neue Instanz für die Verbindungsaufnahme bereitsteht. Für Clients des RAC One Node sollte ein transparenter Failover beispielsweise mit TAF implementiert werden. Siehe auch Abschnitt 14.7 „Failover der Clients“. Praxistipp RAC One Node setzt die Installation der Oracle Grid Infrastruktur sowie der Oracle Database 11 g R2 in der Enterprise Edition mit der Option „Oracle Real Application Clusters“ voraus. Für 11 g R2 muss mindestens Patch 9004119 im Database Home implementiert sein.
Abbildung 14.3 Erstellung einer RAC One Node-Datenbank mit dbca
14.6
Oracle Data Guard Oracle Data Guard dient zur Minimierung der Ausfallzeiten einer Produktivdatenbank, indem regelmäßig anfallende Änderungen des Produktivsystems auf eine oder mehrere Sekundärdatenbanken angewendet werden. Das Sekundärsystem wird als Standby-Datenbank bezeichnet, da es ein Abbild der gesamten oder einer Untermenge der Produktivdatenbank bzw. Primärdatenbank darstellt und kommt bei einem unerwarteten Ausfall als Ersatz des Produktivsystems zum Einsatz. Oracle Data Guard besitzt Werkzeuge, die es
635
14 Verfügbarkeit ermöglichen, bei Ausfall des Produktivsystems ein schnelles Umschalten auf das Sekundärsystem zu gewährleisten und damit die entstehenden Ausfallzeiten so gering wie möglich zu halten. Eine lokale Begrenzung zwischen der Primär- und der Sekundärdatenbank besteht nicht, solange das Netzwerk zwischen diesen beiden Datenbanken eine ausreichende Bandbreite für die Datenübertragung zur Verfügung stellt. Des Weiteren kann man die Standby-Datenbank zur Lastverteilung von Performanceintensiv lesenden SQL-Anweisungen nutzen, die zum Beispiel bei der Erzeugung von Reports anfallen, um die Ressourcen des Produktivsystems zu schonen. Oracle Data Guard ist ein Bestandteil der Oracle Enterprise Edition und nicht in der Standard Edition verfügbar. Dennoch besteht die Möglichkeit, in der Standard Edition ein System aufzusetzen, das die grundlegenden Funktionalitäten einer Standby-Datenbank simuliert, indem die Standby-Datenbank in einen permanenten Wiederherstellungsmodus versetzt wird und die anfallenden Archive der Primärdatenbank manuell auf das Standby-System übertragen und angewendet werden.
14.6.1 Architektur Oracle Data Guard besteht aus zwei Arten von Datenbanken. Hierbei wird zwischen der Primärdatenbank und einer oder mehreren Sekundärdatenbanken unterschieden. Die Primärdatenbank ist das aktuelle Produktivsystem, auf dem die Anwender ihre aktuelle Arbeit verrichten. Die Sekundärdatenbank empfängt die getätigten Änderungen über die Oracle Net-Verbindung und wendet sie an. Aufgrund der Verbindung der Datenbanken mit Oracle Net spielt es keine Rolle, ob sich die Datenbanken geografisch am selben oder an unterschiedlichen Standorten befinden. Je nach Unternehmensanforderungen können unterschiedliche Arten von Standby-Datenbanken erstellt und verwendet werden: Die Physical und die Logical Standby sowie verschiedene Protection Modes können zum Einsatz kommen. Die Physical Standby Database Die Physical Standby Database ist eine auf Blockbasis physikalisch identische Kopie der Produktivdatenbank. Zur Synchronisation der Daten zwischen Primär- und Standby-Datenbank werden bei dieser Art die protokollierten Redo-Informationen der Primärdatenbank auf die Standby-Datenbank angewendet. Dies stellt die effizienteste Art der Datenüberführung dar, weil die Redo-Informationen auf unterster Ebene angewendet werden und somit die SQL-Ebene umgangen wird. Aufgrund der Möglichkeit des Öffnens der Physical Standby Database in den schreibgeschützten Modus können auf ihr Leseoperationen, wie die Erstellung von Reports, ausgeführt werden. Dies ist im Sinne einer Lastverteilung nützlich. Aufgrund der physikalisch identischen Struktur zum Primärsystem kann eine Sicherungsstrategie mithilfe des Recovery Managers auf Basis der Physical Standby Database erarbeitet werden, um das Aufkommen von zusätzlichen E/A-Operationen und CPU-Belastungen der Primärdatenbank zu reduzieren. Diese Sicherungen sind vollwertig für die Wiederherstellung der Primärdatenbank einsetzbar.
636
14.6 Oracle Data Guard Die Logical Standby Database Während die Physical Standby Database Redo-Informationen für die Datensynchronisation verwendet, erfolgt die Synchronisation der Logical Standby Database auf Basis von SQL. Die Redo-Informationen der Primärdatenbank werden in adäquate SQL-Anweisungen transformiert und auf die Standby-Datenbank angewendet. Diese Architektur bietet die Möglichkeit, auch nur einen Ausschnitt von Objekten der Primärdatenbank zur Standby-Datenbank zu replizieren, wobei nur die für den Geschäftsprozess notwendigen Transaktionen herausgefiltert und angewendet werden. Da die Logical Standby Database aus den Redo-Daten SQL-Anweisungen rekonstruiert, ist sie in der Lage, mögliche Defekte auf Blockebene − verursacht durch die Hardware der Primärdatenbank − zu erkennen und die Speicherung dieser Defekte zu vermeiden. Ein weiterer Vorteil der Verwendung einer Logical Standby Database besteht darin, dass die Speicherstrukturen des Schemas nicht mit den Strukturen der Primärdatenbank identisch sein müssen, indem beispielsweise zu Performance-Analysen anstatt normaler HeapTabellen partitionierte Tabellen verwendet werden. Aufgrund dieser Gegebenheiten unterstützt eine Logical Standby Database beispielsweise auch die Durchführung von Applikations-Upgrades oder aber die Installation von Patchsets, wodurch sich Ausfallzeiten verringern lassen. Eine Logical Standby Database wird immer im Schreibmodus geöffnet; nur die zu replizierenden Tabellen befinden sich im schreibgeschützten Modus, welcher wiederum das Verteilen der Last bei performance-intensiven Lesezugriffen zwischen der Primär- und der Standby-Datenbank ermöglicht. Weitere Applikationen können ohne Weiteres zusätzlich innerhalb der Logical Standby Database implementiert werden, die losgelöst von den zu replizierenden Objekten fungieren. Einschränkungen bei der Logical Standby Database Bei der Installation und dem Betrieb einer Logical Standby Database sind einige Einschränkungen bezüglich unterstützter Tabellen, Datentypen, DML- und DDL-Anweisungen zu beachten. Es werden nicht alle Datentypen bei der Überführung der Daten zur Standby-Datenbank unterstützt. Daten folgender Datentypen können nicht repliziert werden:
Bfiles Collections inklusive Varrays und Nested Tables Multimedia Datentype inklusive Oracle Spatial, Image und Oracle Text Rowid, Urowid Benutzerdefinierte Datentypen Objektrelational gespeicherte XMLTypes Binary XML Der neue Datentyp „Secure Files“ und die damit verbundene Kompression und transparente Datenverschlüsselung wird unterstützt, sofern der Initialisierungsparameter COMPATIBLE
637
14 Verfügbarkeit auf 11.2 oder höher gesetzt wurde. Die Möglichkeit der Deduplizierung dieses Datentyps erhält keine Unterstützung. Wird die transparente Datenverschlüsselung auf Spaltenebene verwendet, benötigen beide Datenbanken, das Primär- und Sekundärsystem, Zugriff auf das gleiche geöffnete Wallet, welches den zu verwendenden Schlüssel für die Kodierung enthält. Voraussetzung für die Verwendung der transparenten Datenverschlüsselung auf Tabellenebene ist ein Kompatibilitätsmodus beider Datenbanken ab R11 g.
14.6.2 Data Guard Services Für den Betrieb von Standby-Datenbanken besitzt Data Guard unterschiedliche Dienste, die für die Übertragung der Daten von der Primärdatenbank zur Standby-Datenbank sowie für den Rollenwechsel einer Standby-Datenbank zu einer Primärdatenbank notwendig sind. Folgende Dienste werden durch die Verwendung von Data Guard implementiert: Redo Transport Service Apply Service Role Transitions Diese werden in den folgenden Abschnitten genauer dargestellt. Redo Transport Service Der Redo Transport Service überträgt die Redo-Daten von der Primärdatenbank zu einer oder mehreren Standby-Datenbanken und überwacht den Transfer dieser Daten. Der Transfer der Redo-Daten kann entweder in Echtzeit oder durch Übertragen der archivierten Redo-Log-Dateien zur Standby-Datenbank erfolgen. Zusätzlich versucht der Redo Transport Service, fehlende Informationen aus vorhandenen Archiven auf die Standby-Datenbank anzuwenden, falls durch Netzwerkausfälle Lücken (Gaps) im Redo-Strom entstanden sind. Sollten Archive auf der Standby-Datenbank fehlen oder defekt sein, so versucht der Redo Transport Service, Ersatz von der Primärdatenbank oder von einer anderen vorhandenen Standby-Datenbank zu erhalten. Apply Service Der Apply Service wendet die übertragenen Redo-Daten auf die Standby-Datenbank an und hält die transaktionale Konsistenz zwischen der Primär- und der Standby-Datenbank aufrecht. Allerdings ist zwischen einer Physical Standby Database und einer Logical Standby Database zu unterscheiden. Während bei einer Physical Standby Database die Redo-Daten direkt angewendet werden, erfolgt bei einer Logical Standby Database im Vorfeld eine Konvertierung der Redo-Daten in SQL-Anweisungen, die dann in einem zweiten Schritt in der Standby-Datenbank ausgeführt werden. Role Transitions Mithilfe von Data Guard können zu Wartungszwecken die Rollen zwischen einer StandbyDatenbank und der Primärdatenbank getauscht werden. Durch diese Aktion wird ohne Da-
638
14.6 Oracle Data Guard tenverlust die Primärdatenbank zu einer Standby-Datenbank herab- und eine der StandbyDatenbanken zu einer Primärdatenbank heraufgestuft. Dieser Vorgang wird als Switchover bezeichnet. Bei Ausfall der Primärdatenbank muss diese durch eine der vorhandenen Standby-Datenbanken ersetzt werden. Dieser Vorgang kann bei entsprechender Konfiguration ebenfalls ohne Datenverlust vonstattengehen und wird als Failover bezeichnet.
14.6.3 Data Guard Protection Modes Vor der Version 10g wurden die archivierten Redo-Log-Dateien nach einem Gruppenwechsel zur Standby-Datenbank übertragen, um deren protokollierten Informationen dann dort nachzufahren. Bei einem Ausfall der Primärdatenbank gingen die Daten verloren, die in der aktuellen Redo-Log-Datei protokolliert, aber noch nicht an die Standby-Datenbank gesendet wurden. In den neueren Datenbankversionen werden die Redo-Daten direkt in einem Redo-Stream zur Standby-Datenbank übertragen, welche dann in sogenannte Standby-Redo-Log-Dateien abgespeichert werden und somit bei einem Ausfall der Primärdatenbank für ein Recovery der Standby-Datenbank zur Verfügung stehen. In Verbindung mit dieser neuen Funktionalität können zur Vermeidung von Datenverlust bei einem Failover unterschiedliche Schutzmodi mit Data Guard implementiert werden. Maximum Protection Maximum Protection bietet den höchsten Schutz der Daten bei einem Ausfall der Primärdatenbank. Dies wird gewährleistet durch synchrones Übertragen der Redo-Daten von der Primärdatenbank zur Standby-Datenbank. Diese Daten werden erst in der Primärdatenbank festgeschrieben und bestätigt, bis sie mindestens auch auf einer der vorhandenen StandbyDatenbanken verfügbar sind, die in diesem Modus arbeitet. Ist dies nicht mehr gewährleistet, so hält der Betrieb der Primärdatenbank an und garantiert somit, dass bei einem Ausfall der Primärdatenbank kein Datenverlust auftritt. Maximum Availability Dieser Modus ist ähnlich dem Maximum Protection Modus; allerdings arbeitet die Primärdatenbank weiter, wenn keine Standby-Datenbank mehr erreichbar ist. Ist deren Erreichbarkeit wiederhergestellt, so erfolgt eine automatische Synchronisation der Daten zwischen der Primär- und der Standby-Datenbank. Auch hier ist der Schutz vor Datenverlust gesichert. Maximum Performance Der Modus „Maximum Performance“ bietet die größte Geschwindigkeit bei der Datenverarbeitung in der Primärdatenbank, da die Redo-Daten von der Primärdatenbank asynchron zur Standby-Datenbank gesendet werden. Beim Festschreiben der Daten in die Primärdatenbank wird nicht auf eine Bestätigung der erfolgreichen Übertragung zur StandbyDatenbank gewartet. Aus diesem Grund ist der Schutz der Daten, im Gegensatz zu den
639
14 Verfügbarkeit anderen Modi, nicht gewährleistet. Allerdings profitiert die Primärdatenbank von einer höheren Geschwindigkeit der Transaktionsverarbeitung. Sollte keine Standby-Datenbank mehr verfügbar sein, bleibt die Primärdatenbank weiterhin verfügbar.
14.6.4 Data Guard Broker Der Data Guard Broker ist ein Framework für die Erstellung von Konfigurationen von Data Guard. So können mit diesem Framework beispielsweise die Protection Modes geändert und alle weiteren notwendigen Konfigurationen angepasst werden. Zusätzlich erleichtert der Data Guard Broker die Durchführung eines Switchovers oder Failovers und die Aktivierung des Fast Start Failovers, das automatisch eine Standby-Datenbank zu einer Primärdatenbank heraufstuft, wenn die Primärdatenbank ausgefallen ist.
14.6.5 Verwaltungswerkzeuge Für die Verwaltung, Konfiguration und Überwachung der Primär- und der Standby-Datenbanken stehen unterschiedliche Werkzeuge von Oracle zur Verfügung. Für die Konfiguration und Überwachung ist Data Guard im Oracle Enterprise Manager integriert. Allerdings sind nicht alle Funktionalitäten verfügbar, die Data Guard zur Konfiguration bietet. Der volle Funktionsumfang für Data Guard wird erst in Verbindung mit dem Grid Control von Oracle erreicht. Auf Kommandozeilenebene stellt Oracle für Data Guard das Werkzeug DGMGRL zur Verfügung, mit dem die gesamte Bandbreite der Funktionalitäten von Data Guard gewartet und konfiguriert werden kann.
14.6.6 Hard- und Softwarevoraussetzungen Oracle Data Guard bietet eine hochflexible Struktur für die Implementierung von Primärund Standby-Systemen. So können Primär- und Standby-Datenbanken auf unterschiedlichen Betriebssystemen mit unterschiedlichen Prozessor-Architekturen erstellt werden, deren Datenbank-Binaries sich in 32 Bit und 64 Bit unterscheiden. Für die Implementierung ist der gleiche Versionsstand der Oracle Enterprise Edition auf dem Primär- und dem Standby-System notwendig. Grundvoraussetzung für den Aufbau und Betrieb ist die Aktivierung des Archivelog-Modus der Primärdatenbank. Dessen Aktivierung in der Standby-Datenbank ist ebenfalls sinnvoll, wenn die Funktion des Switchovers benötigt wird. Weil Änderungen bei nicht-protokollierten Befehlen nicht an die Standby-Datenbank weitergegeben werden, sollte die Primärdatenbank in den „FORCE LOGGING“-Modus versetzt werden. Die Aktivierung protokolliert alle Änderungen, unabhängig von der Angabe der Option „NOLOGGING“. Aktivitäten innerhalb des temporären Tablespaces bleiben
640
14.6 Oracle Data Guard weiterhin von der Protokollierung ausgeschlossen. Die Aktivierung des „FORCE LOGGING“-Modus erfolgt über den Befehl: SQL> ALTER DATABASE FORCE LOGGING;
Auf allen Datenbanken im Data Guard-Verbund muss der gleiche Kompatibilitätslevel eingestellt sein. Ausgenommen davon ist die Logical Standby-Database, bei der ein höherer Level zur Primärdatenbank möglich ist, wenn Upgrades zu einer höheren Version erfolgen sollen. Für die Erstellung und Wartung der Datenbanken müssen Administratoren die SYSDBABerechtigungen besitzen. Für die Standardauthentifizierung des Redo Transport Service an Standby-Datenbanken wird in Data Guard die Passwortdatei verwendet, was voraussetzt, dass auf allen Datenbanken die gleiche Passwortdatei vorhanden ist. Als Benutzer für die Authentifizierung wird das vordefinierte Administratorkonto SYS verwendet. Soll eine Authentifizierung durch einen anderen Administrator erfolgen, so kann dieser über den Parameter REDO_TRANSPORT_USER abgeändert werden, sofern dieser Administrator SYSDBABerichtigungen besitzt.
14.6.7 Verzeichnisstrukturen der Standby-Database Werden die Standby- und Primärdatenbank auf unterschiedlichen Systemen installiert, so sollten diese vorzugsweise in eine identische Verzeichnisstruktur gebracht werden, um die zukünftige Wartung, wie Sicherungsstrategien und Switchover, zu vereinfachen. Besteht nicht die Möglichkeit, für die Primär- und Standby-Datenbank eine identische Verzeichnisstruktur aufzubauen, so muss mithilfe von Parametern eine Konvertierung der Pfade der Datenbankdateien durchgeführt werden. Der Parameter DB_FILE_NAME_CONVERT wird für die Umbenennung der Dateinamen zwischen dem Primär- und dem StandbySystem genutzt. Der Parameter LOG_FILE_NAME_CONVERT konvertiert die Namen der RedoLog-Dateien.
14.6.8 Vorbereitung der Primärdatenbank Um eine Physical Standby-Datenbank aufzusetzen, muss im ersten Schritt die Primärdatenbank vorbereitet werden, aus der im zweiten Schritt dann die Standby-Datenbank aufgebaut wird. Aktivieren des Force Logging-Modus Damit auch Änderungen von SQL-Anweisungen mit der Option NOLOGGING in Redo-LogDateien protokolliert werden, sollte die Datenbank in den „FORCE LOGGING“-Modus gebracht werden, um diese Änderungen ebenfalls an die Standby-Datenbank übermitteln zu können. SQL> alter database force logging;
641
14 Verfügbarkeit Konfiguration des Redo-Datentransports Da für den Transport der Redo-Daten zur Standby-Datenbank Oracle Net verwendet wird, muss die Authentifizierungsmethode zwischen diesen beiden Datenbanken definiert werden. Die Authentifizierung kann über SSL oder die Passwortdatei der Datenbank durchgeführt werden. Wird die Authentifizierung über die Passwortdatei verwendet, so muss diese auf der Standby- und der Primärdatenbank identisch sein. Wird das Kennwort des Administrators geändert, über den die Authentifizierung an der Standby-Datenbank erfolgt, so muss erneut die Passwortdatei der Primärdatenbank zur Standby-Datenbank kopiert werden. Konfiguration der Initialisierungsparameter der Primärdatenbank Auf der Primärdatenbank sind Parameter zu setzen, die die Primärdatenbank als solche identifizieren sowie den Transport der Redo-Daten zur Standby-Datenbank definieren. Zusätzlich sind Parameter nötig, die einen Rollenwechsel zwischen Primär- und StandbyDatenbank erlauben. Folgende Parameter sind für den Betrieb der Primärdatenbank notwendig:
642
DB_NAME
Definiert den Datenbanknamen der Primärdatenbank. Der Wert dieses Parameters ist auf der Primär- und der Standby-Datenbank identisch.
DB_UNIQUE_NAME
Mit diesem Parameter wird ein eindeutiger Name der einzelnen Datenbanken bestimmt.
CONTROL_FILES
Speicherorte der Kontrolldateien
REMOTE_LOGIN_PASSWORD_FILE
Dieser Parameter muss auf exclusive oder shared stehen, wenn die Passwortdatei für die Authentifizierung des Redo Transport Service verwendet wird.
LOG_ARCHIVE_DEST_N
Dieser Parameter bestimmt das Archivierungsziel der Redo-Log-Dateien sowie den Redo-Daten-Strom zur Standby-Datenbank, wobei N den Wert 1 bis 30 besitzt. Das optionale Zusatzattribut VALID_FOR bestimmt, wie das Archivierungsziel in Abhängigkeit der Rolle des Servers zu verwenden ist, und macht dadurch eine Parameteranpassung bei einem Rollenwechsel überflüssig. Der erste Wert dieses Parameters bestimmt, für welche Art von Dateien dieses Ziel gültig ist. Mögliche Werte sind ALL_LOGFILES, ONLINE_LOGFILE und STANDBY_ LOGFILE. Der zweite Wert bestimmt, in welcher Rolle des Servers dieses Ziel gültig ist. Steht der Wert auf ALL_ ROLES, gilt dieses Ziel unabhängig von der Rolle des Servers. Bei PRIMARY ROLE gilt das Ziel nur, wenn der Server sich in der Rolle der Primär- und STANDBY ROLE, wenn der Server sich in der Standby-Rolle befindet.
LOG_ARCHIVE_CONFIG
Mithilfe der Parameteroption DG_CONFIG werden mit diesem Parameter alle im Data Guard-Verbund vorhandenen Datenbanken angegeben.
14.6 Oracle Data Guard FAL_SERVER
Dieser Parameter zeigt in der Regel auf den Oracle NetServicenamen der Primärdatenbank, von der Redo-Daten im Fehlerfall nachgefordert werden.
FAL_CLIENT
Dieser Parameter zeigt auf den Oracle Net-Servicenamen der Standby-Datenbank, an die Redo-Daten im Fehlerfall nachgereicht werden. In Oracle 11 g R2 ist dieser Parameter nicht mehr notwendig.
LOG_ARCHIVE_DEST_STATE_N
Mit diesem Parameter wird das Archivierungsziel aktiviert oder deaktiviert.
DB_FILE_NAME_CONVERT
Wenn die Verzeichnisstrukturen zwischen Primär- und Standby-Datenbank nicht identisch sind, werden mit diesem Parameter die Dateinamen umbenannt.
LOG_FILE_NAME_CONVERT
Dieser Parameter konvertiert die Namen der Log-Dateien bei Nichtübereinstimmung der Verzeichnisstrukturen.
STANDBY_FILE_MANAGEMENT
Wurde dieser Parameter auf AUTO gesetzt, so werden physikalische Änderungen, wie das Hinzufügen oder Löschen von Datendateien, in der Primärdatenbank an die Standby-Datenbanken weitergereicht.
Konfiguration von Oracle Net Für die Übertragung der Redo-Daten über Oracle Net muss ein neuer Eintrag der Datei tnsnames.ora hinzugefügt werden, der auf den Service der Standby-Datenbank zeigt: PRIM = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dg1)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = prim) ) ) STDBY = (DESCRIPTION = (ADDRESS_LIST =
Hierbei ist darauf zu achten, dass die Verbindung immer über einen dedizierten Serverprozess erfolgt. Siehe auch Abschnitt 7.2.2.3 „Shared / Dedicated Server“. Zusätzlich sollte ein statischer Eintrag für den Service der Primärdatenbank im Listener registriert werden, damit die spätere Möglichkeit eines Switchovers mit Data Guard gewährleistet ist. SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = prim) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = prim) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = DG1)(PORT = 1521)) ) )
Aktivieren des Archivelog-Modus in der Primärdatenbank Der letzte Schritt auf der Primärdatenbankseite ist die Aktivierung des Archivelog-Modus. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. …… Database mounted. SQL> alter database archivelog; Database altered. SQL> alter database open; Database altered.
14.6.9 Erstellung der Physical Standby Database Es wird vorausgesetzt, dass der Host, auf dem die Standby-Datenbank betrieben werden soll, eine zur Primärdatenbank analoge Oracle Software-Installation enthält und dass eine Namensauflösung zwischen dem Primär- und dem Standby-System durch DNS oder die HOST-Datei erfolgen kann. Des Weiteren wird bei dieser Vorgehensweise davon ausgegangen, dass die Verzeichnisstrukturen der Primär- und der Standby-Datenbank identisch sind.
644
14.6 Oracle Data Guard Kopieren der Primärdatenbank zum Standby-System Die Physical Standby-Datenbank wird aus der Primärdatenbank erzeugt, was durch Kopieren mit Betriebssystemmitteln oder durch das Erzeugen einer Sicherung mit dem Recovery Manager erfolgen kann. Prinzipiell kann ein Online-Backup oder andere schon vorhandene Backups genutzt werden, sofern alle archivierten Redo-Logs ab Beginn der Backup-Erstellung lückenlos vorhanden sind. Im folgenden Beispiel wird die Primärdatenbank heruntergefahren, und deren Datendateien werden mithilfe von Secure Copy SCP zum Standby-System übertragen. SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> exit [oracle@dg1 prim]$ scp * oracle@dg2:/u01/app/oracle/oradata/prim/ oracle@dg2's password: example01.dbf redo01.log redo02.log redo03.log sysaux01.dbf system01.dbf temp01.dbf undotbs01.dbf users01.dbf
Zusätzlich zu den Datendateien muss die Passwortdatei auf das Standby-System kopiert werden, welche zur Authentifizierung zwischen den Datenbanken beim Transport der Redo-Daten dient. Jedes Mal, wenn in der Passwortdatei der Primärdatenbank Änderungen durchgeführt werden, indem Kennwörter geändert oder weitere Administratoren hinzugefügt werden, muss sie erneut auf das Standby-System übertragen und entsprechend umbenannt werden. Konfiguration der Initialisierungsparameter der Physical Standby Database Für die Standby-Datenbank muss eine Parameterdatei erzeugt werden, die analog zur Primärdatenbank die gleichen Parameter für Data Guard verwendet. Diese Parameterdatei kann vorzugsweise aus dem SPFILE der Primärdatenbank mit CREATE PFILE FROM SPFILE erstellt werden. Allerdings sind folgende Unterschiede zwischen der Parameterdatei der Primärdatenbank und der Standby-Datenbank festzustellen:
Der Parameter DB_UNIQUE_NAME wird auf den aktuellen Namen der Standby-Datenbank gesetzt, während beibehält.
DB_NAME
den Namen, unter dem die Primärdatenbank erstellt wurde,
Das Archivierungsziel LOG_ARCHIVE_DEST_2 ist in diesem Beispiel auf den Service der Primärdatenbank gesetzt, da im Falle eines Rollenwechsels bzw. Switchovers die Standby-Datenbank zur Primärdatenbank wird und umgekehrt. Diese neue Primärdatenbank benötigt wiederum ein Archivierungsziel auf ihrer Standby-Datenbank.
Konfiguration von Oracle Net Analog zur Primärdatenbank muss Oracle Net für die gegenseitige Verbindung zwischen Primär- und Standby-Datenbank auf dem Standby-System eingerichtet werden (siehe Abschnitt 14.6.8 „Vorbereitung der Primärdatenbank“). Erzeugung einer Standby-Kontrolldatei Für die Erstellung einer Standby-Datenbank wird eine Standby-Kontrolldatei benötigt, die in der Mount-Phase der Primärdatenbank zu erzeugen ist und auf das Standby-System übertragen werden muss. SQL> startup mount ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers Database mounted.
Nach der Erstellung der Standby-Kontrolldatei wird die Primärdatenbank für die nächsten Schritte wieder geöffnet. Aktivieren der Standby Physical Database Für die Aktivierung der Standby-Datenbank wird sie in die Mount-Phase gebracht und die automatische Anwendung der Archive der Primärdatenbank aktiviert. SQL> startup mount ORACLE instance started. Total System Global Area Fixed Size Variable Size Database Buffers Redo Buffers
646
839282688 2217992 524290040 310378496 2396160
bytes bytes bytes bytes bytes
14.6 Oracle Data Guard Database mounted. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; Database altered.
Bis zu diesem Schritt werden nach einem Log-Gruppenwechsel in der Primärdatenbank die erzeugten Archive automatisch auf die Standby-Datenbank übertragen und angewendet. Eine Echtzeitanwendung von Änderungen der Primärdatenbank auf die Standby-Datenbank ist bis zu diesem Zeitpunkt noch nicht möglich.
14.6.10 Überwachung der Physical Standby Database Um sicherzustellen, dass die Archive auch wirklich an die Standby-Datenbank übertragen und angewendet werden, wird zur Überwachung die View v$archived_log verwendet. Der höchste Wert der Spalte SEQUENCE# liefert das letzte an die Standby-Datenbank übertragene Archiv, die Spalte APPLIED gibt Auskunft darüber, ob dieses Archiv auch angewendet wurde. SQL> ALTER SESSION SET nls_date_format='yyyy-mm-dd hh24:mi:ss'; Session altered. SQL> SELECT FROM ORDER BY
Erzwingen eines Log-Gruppenwechsels in der Primärdatenbank: SQL> ALTER SYSTEM SWITCH LOGFILE; System altered.
Erneute Ausführung von v$archived_log in der Standby-Datenbank: SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#; SEQUENCE# ---------6 7 8 9 10
Auch die View v$managed_standby ist hilfreich. Sie zeigt den Fortschritt der StandbyDatenbank und liefert Informationen zu Aktivitäten des Log Transport Service und des Log Apply Service. SQL> SELECT process, pid, status, client_process, group# FROM v$managed_standby;
647
14 Verfügbarkeit
14.6.11 Real Time Apply und Standby Logfiles Bis zu diesem Zustand der Konfiguration werden nur die Änderungen der Archive auf die Standby-Datenbank angewendet, wenn ein Gruppenwechsel in der Primärdatenbank erfolgt. Um eine Echtzeitanwendung (Real Time Apply) der Redo-Daten zu erhalten, müssen in der Standby-Datenbank sogenannte Standby Logfiles erstellt werden, die den RedoDaten-Strom entgegennehmen, der dann durch den Apply Service angewendet werden kann. Diese Standby Logfiles sind strukturell identisch zu den normalen Redo-Log-Dateien. Bei der Erstellung muss beachtet werden, dass die Standby Logfiles die gleiche Größe besitzen wie die Redo-Log-Dateien der Datenbank, und es muss mindestens eine StandbyLog-Gruppe mehr vorhanden sein, als es Redo-Log-Gruppen in der Datenbank gibt. Um ein Switchover zwischen Primär- und Standby-Datenbank zu ermöglichen und den damit verbundenen administrativen Overhead zu minimieren, sollten ebenfalls in der Primärdatenbank Standby Logfiles vorhanden sein. Die Erstellung von Standby Logfiles wird mit dem Befehl ALTER DATABASE ADD STANDBY LOGFILE durchgeführt. SQL> alter database add standby logfile '/u01/db4/stbyredo01.log' size 50M; Database altered. SQL> alter database add standby logfile '/u01/db4/stbyredo02.log' size 50M; Database altered.
Informationen über die Standby Logfiles werden über die Views v$standby_log und v$logfile ausgelesen: SQL> SELECT GROUP#, BYTES, STATUS FROM V$STANDBY_LOG; GROUP# BYTES STATUS ---------- ---------- ---------4 52428800 ACTIVE 5 52428800 UNASSIGNED 6 52428800 UNASSIGNED 7 52428800 UNASSIGNED SQL> SELECT GROUP#, MEMBER FROM V$LOGFILE WHERE TYPE='STANDBY'; GROUP# ---------4 5 6 7
MEMBER -------------------------------------------------/u01/app/oracle/oradata/prim/stbyredo01.log /u01/app/oracle/oradata/prim/stbyredo02.log /u01/app/oracle/oradata/prim/stbyredo03.log /u01/app/oracle/oradata/prim/stbyredo04.log
14.6.12 Starten und Stoppen des Redo-Apply Für das Anwenden der Redo-Daten auf die Standby-Datenbank wird der Befehl ALTER verwendet. Durch Absetzen dieses Befehls werden die Archive nach jedem Gruppenwechsel der Primärdatenbank auf die Standby-Datenbank angewendet. Die Sitzung, die diesen Befehl abgesetzt hat, verbleibt im Wiederherstellungsmodus und kehrt nicht zur Eingabeaufforderung zurück, bis dieser mit CTRL+X abgebrochen wird.
DATABASE RECOVER MANAGED STANDBY DATABASE
Soll die Sitzung nach der Aktivierung des Wiederherstellungsmodus zur Eingabeaufforderung zurückkehren, so wird die Zusatzoption DISCONNECT FROM SESSION benötigt.
648
14.6 Oracle Data Guard SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; Database altered.
Sind Standby Logfiles in der Standby-Datenbank vorhanden, so kann die Echtzeitanwendung der Redo-Daten gestartet werden. Die Echtzeitübertragung wird durch die weitere Option USING CURRENT LOGFILE aktiviert. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered.
Wurde der Wiederherstellungsmodus mit der Option DISCONNECT FROM SESSION gestartet, so kann er mit dem Befehl ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL beendet werden.
14.6.13 Aktivierung des Data Guard Brokers Die Verwendung des Data Guard Brokers wird empfohlen, da Wartung und Konfiguration sowie die Möglichkeiten eines Switchovers und Failovers enorm vereinfacht werden. Hierfür steht das Kommandozeilenwerkzeug DGMGRL zur Verfügung, welches entsprechende Verbindungen zu den Standby-Datenbanken und zur Primärdatenbank aufbaut. Die Aktivierung des Data Guard Brokers startet den Prozess Gata Guard Monitor DMON, der für die Konfigurations-, Kontroll- und Überwachungsfunktion des Brokers zuständig ist. Konfiguration des Listeners Für die Verwendung von DGMGRL wird ein statischer Eintrag eines Service für jede Instanz im Listener benötigt, damit Aktionen wie ein Switchover oder Failover durchgeführt werden können, die einen Neustart von Instanzen notwendig machen. Zusätzlich gibt es einen sogenannten Observer, der bei Ausfall der Primärdatenbank ein automatisches Failover durchführen kann. Dieser benötigt ebenfalls den entsprechenden statischen Eintrag der Services der Instanzen im Listener. Als Standardeintrag für das Attribut GLOBAL_DBNAME der Datei Listener.ora wird der zusammengesetzte Name db_unique_name_DGMGRL.db_domain verwendet. Eintrag auf der Standby-Datenbank: SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = stdby_DGMGRL) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = stdby) )
Eintrag auf der Primärdatenbank: SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = prim_DGMGRL) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1) (SID_NAME = prim) )
649
14 Verfügbarkeit Konfigurationsdateien und Start des Data Guard Brokers Konfigurationseinstellungen des Data Guard Brokers werden in einer speziellen Konfigurationsdatei gespeichert, deren Name und Speicherort über den Initialisierungsparameter DG_BROKER_CONFIG_FILE1 und, für die Redundanz, über DG_BROKER_CONFIG_FILE2 angegeben werden. Diese Parameter müssen auf der Primär- und auf den Standby-Datenbanken gesetzt werden. SQL> alter system set dg_broker_config_file1= '/u01/app/oracle/oradata/prim/dg_config1/dgcfg1.dat'; System altered. SQL>
alter system set dg_broker_config_file2= '/u01/app/oracle/oradata/prim/dg_config2/dgcfg2.dat'; System altered.
Nach dem Festlegen der Konfigurationsdateien wird der Data Guard Monitor Prozess DMON auf jeder Datenbank gestartet, welches mit dem Parameter DG_BROKER_START realisiert wird. SQL> alter system set dg_broker_start=true; System altered.
Erstellen und Aktivieren von Data Guard Broker-Konfigurationen Data Guard benötigt eine Initialkonfiguration, die innerhalb der Konfigurationsdateien abgespeichert wird. Diese Initialkonfiguration wird vorzugsweise über das Kommandozeilenwerkzeug DGMGRL erzeugt und kann im Nachhinein angepasst werden. Die Anmeldung mit DGMGRL erfolgt an der Primärdatenbank mit einem Administrator, der SYSDBABerechtigungen benötigt. Allgemeine Syntax: dgmgrl /@
Beispiel: [oracle@DG1 ~]$ dgmgrl sys/top_secret@prim DGMGRL for Linux: Version 11.2.0.1.0 - 64bit Production Copyright (c) 2000, 2009, Oracle. All rights reserved. Welcome to DGMGRL, type "help" for information. Connected. DGMGRL>
Aus DGMGRL muss nun die Initialkonfiguration erzeugt werden, für die ein Konfigurationsname, der Name der Primärdatenbank aus dem Initialisierungsparameter DB_UNIQUE_ NAME und der Oracle Net-Verbindungsname bekannt sein muss. Allgemeine Syntax: CREATE CONFIGURATION AS PRIMARY DATABASE IS '' CONNECT IDENTIFIER IS ;
Die Erzeugung der Konfiguration sieht dann mit echten Werten folgendermaßen aus: DGMGRL> CREATE CONFIGURATION prim_cg1 AS PRIMARY DATABASE IS 'prim' CONNECT IDENTIFIER IS prim; Configuration "prim_cg1" created with primary database "prim" DGMGRL>
650
14.6 Oracle Data Guard Eine Überprüfung der Konfiguration erfolgt durch Eingabe von show configuration. Nach der Erstellung ist eine Aktivierung der Konfiguration mit enable configuration notwendig. DGMGRL> enable configuration; Enabled. DGMGRL> show configuration; Configuration - prim_cg1 Protection Mode: MaxPerformance Databases: prim - Primary database Fast-Start Failover: DISABLED Configuration Status: SUCCESS
Der Konfigurationsstatus kann den Wert SUCCESS, WARNING oder FAILED annehmen.
SUCCESS bedeutet, dass alle in der Konfiguration vorhandenen Datenbanken in ordnungsgemäßer Weise arbeiten.
WARNING bedeutet, dass einige Datenbanken in der Konfiguration nicht in der gewünschten Weise arbeiten.
FAILED bedeutet, dass einige Datenbanken in der Konfiguration nicht mehr verfügbar sind oder nicht mehr reagieren.
14.6.14 Hinzufügen und Aktivieren von Standby-Datenbanken Nach der Erstellung der Konfiguration müssen dieser noch die vorhandenen Standby-Datenbanken bekannt gemacht werden. Die Bekanntmachung erfolgt aus DGMGRL mit ADD DATABASE '' AS CONNECT IDENTIFIER IS ; als Datenbankname muss ebenfalls der Name des Initialisierungsparameters DB_UNIQUE_NAME verwendet werden. DGMGRL> ADD DATABASE 'stdby' AS CONNECT IDENTIFIER IS stdby; Database "stdby" added
Nach dem Hinzufügen der Standby-Datenbank zur Konfiguration wird diese mit der Anweisung enable database aktiviert. Eine Deaktivierung zu Wartungszwecken erfolgt dementsprechend mit disable database . Den aktuellen Status einer Datenbank im Data Guard-Verbund liefert show database . DGMGRL> show database stdby Database - stdby Role: Intended State: Transport Lag: Apply Lag: Real Time Query: Instance(s):
PHYSICAL STANDBY OFFLINE (unknown) (unknown) OFF stdby
14 Verfügbarkeit DGMGRL> show database stdby Database - stdby Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds Apply Lag: 0 seconds Real Time Query: ON Instance(s): stdby Database Status: SUCCESS
Der Broker schreibt Informationen im Alert-Log jeder der Datenbanken mit. Für jede Datenbank der Broker-Konfiguration schreibt der DMON-Prozess wichtige Informationen in ein Broker Logfile. Sie liegen in einer Unix-Umgebung beispielsweise unter $ORACLE_HOME/rdbms/log/drc*.log
14.6.15 Ändern von Konfigurationseinstellungen Mit DGMGRL können Konfigurationseinstellungen von Data Guard angepasst werden. Dazu gehört unter anderem die Änderung des Protection Mode, Statusänderungen einer Datenbank, das Aktivieren und Deaktivieren des Transportstatus und des Redo Transport Service. Ändern der Datenbankkonfiguration Alle möglichen Konfigurationseinstellungen einer Datenbank werden über show verbose wiedergegeben.
database
DGMGRL> show database verbose prim Database - prim Role: Intended State: Instance(s): prim
Zu Abänderung von Konfigurationseinstellungen einer Datenbank wird der Befehl verwendet.
database set property <Parameter>=Wert;
DGMGRL> edit database prim set property LogXptMode='SYNC'; Property "logxptmode" updated
652
edit
14.6 Oracle Data Guard LogShipping
Bestimmt, ob Transport Service Redo-Daten zur Standby-Datenbank senden kann. Dieser Wert kann auf ON oder OFF gesetzt werden.
LogXptMode
Bestimmt, ob die Redo-Daten-Übertragung synchron oder asynchron erfolgen soll. Dieser Wert kann auf SYNC oder ASYNC stehen.
DelayMins
Bestimmt ein Zeitintervall in Minuten, nach dem erst die Redo-Daten zur Standby-Datenbank übertragen werden sollen.
CommunicationTimeout
Bestimmt eine Zeit in Sekunden, wie lange der Broker wartet, bis er bei Nichterreichbarkeit einer Datenbank die Kommunikation abbricht.
Ändern des Protection Mode Der Protection Mode wird über die Abänderung der Konfiguration von Data Guard mit edit configuration set protection mode as <Modus> gesetzt, wobei der Modus den Wert MAXAVAILABILITY, MAXPROTECTION oder MAXPERFORMANCE annehmen kann. DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; Succeeded.
Für die Protection Modes MAXAVAILABILITY und MAXPROTECTION muss die Redo-DatenÜbertragung synchron erfolgen, welche durch den Parameter LogXptMode gesetzt wird. Ist LogXptMode auf ASYNC eingestellt, so wird eine Fehlermeldung beim Setzen von einem dieser Modi generiert. DGMGRL> edit database prim set property LogXptMode='ASYNC'; Property "logxptmode" updated DGMGRL> edit database stdby set property LogXptMode='ASYNC'; Property "logxptmode" updated DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION; Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode Failed. DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY; Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode Failed.
Beim Setzen der Data Guard-Konfiguration in den Maximum Protection-Modus wird die Instanz der Primärdatenbank automatisch beendet und neu gestartet. DGMGRL> edit database prim set property LogXptMode='SYNC'; Property "logxptmode" updated DGMGRL> edit database stdby set property LogXptMode='SYNC'; Property "logxptmode" updated DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION; Operation requires shutdown of instance "prim" on database "prim" Shutting down instance "prim"... Database closed. Database dismounted. ORACLE instance shut down. Operation requires startup of instance "prim" on database "prim" Starting instance "prim"... ORACLE instance started. Database mounted. Database opened. DGMGRL>
653
14 Verfügbarkeit Ändern des Datenbankstatus Der Datenbankstatus für die Primärdatenbank bestimmt, ob der automatische Redo Transport Service aktiviert bzw. deaktiviert ist. Für die Standby-Datenbank definiert dieser Status, ob automatisch die transportierten Redo-Daten auf die Standby-Datenbank angewendet werden. Die Verwendung der Anweisung edit database set state=<Status> ermöglicht die Änderung dieses Status. Der automatische Transportservice der Primärdatenbank wird mit dem Wert TRANSPORT-ON aktiviert und mit TRANSPORTOFF deaktiviert. DGMGRL> edit database prim set state='TRANSPORT-ON'; Succeeded.
Die automatische Anwendung der Redo-Daten in der Standby-Datenbank wird über den Status APPLY-ON aktiviert und mit APPLY-OFF deaktiviert. DGMGRL> edit database stdby set state='APPLY-ON'; Succeeded.
14.6.16 Durchführen eines Switchovers Für das Durchführen eines Switchovers müssen die Primär- und die Standby-Datenbank aktiviert sein. Des Weiteren ist es notwendig, dass der automatische Redo-Transport der Primärdatenbank und der Apply Service auf der Standby-Datenbank laufen. Beides kann über den Befehl show database verifiziert werden. Dass der RedoTransport der Primärdatenbank funktionsfähig ist, bestimmt der Status „Intended State“, der auf TRANSPORT-ON zu stehen hat. Bei automatischer Anwendung der Redo-Daten in der Standby-Datenbank liefert dieser Staus den Wert APPLY-ON zurück. Der Status der Primärdatenbank sieht dann wie folgt aus: DGMGRL> show database prim Database - prim Role: Intended State: Instance(s): prim
PRIMARY TRANSPORT-ON
Database Status: SUCCESS
Der Status der Standby-Datenbank liefert folgende Werte zurück: DGMGRL> show database stdby Database - stdby Role: Intended State: Transport Lag: Apply Lag: Real Time Query: Instance(s): stdby Database Status: SUCCESS
654
PHYSICAL STANDBY APPLY-ON 0 seconds 0 seconds ON
14.6 Oracle Data Guard Sind diese Voraussetzungen erfüllt, kann ein Switchover mit switchover name> eingeleitet werden.
to switchover to stdby; Performing switchover NOW, please wait... New primary database "stdby" is opening... Operation requires shutdown of instance "prim" on database "prim" Shutting down instance "prim"... Database dismounted. ORACLE instance shut down. Operation requires startup of instance "prim" on database "prim" Starting instance "prim"... ORACLE instance started. Database mounted. Database opened. Switchover succeeded, new primary is "stdby"
Nach einem erfolgreichen Switchover haben die Primärdatenbank und die Standby-Datenbank ihre Rollen getauscht.
14.6.17 Durchführen eines Failovers Erfolgt ein Ausfall der Primärdatenbank, bei dem eine Wiederherstellung nicht mehr möglich ist, so muss ein Failover durchgeführt werden. Das Failover aktiviert die benannte Standby-Datenbank und stuft sie zu einer neuen Primärdatenbank herauf. Die Durchführung eines Failovers erfolgt mit einer direkten Verbindung mit DGMGRL zur StandbyDatenbank und wird über den Befehl failover to [immediate] eingeleitet. Bei einem vollständigen Failover wird in Abhängigkeit des Protection Modes versucht, die Standby-Datenbank auf den Stand zu bringen, der mit den vorhandenen Redo-Daten möglich ist. Zusätzlich wird versucht, alle anderen Standby-Datenbanken aktiviert zu halten, sofern sie im Verhältnis zur neuen Primärdatenbank entsprechende Redo-Daten erhalten haben. Ein sofortiges Failover wird mit der Zusatzoption immediate gestartet und ist die schnellste Art, ein Failover durchzuführen. Hierbei werden keine weiteren Redo-Daten auf die Zieldatenbank angewendet, wodurch alle anderen Standby-Datenbanken deaktiviert und entweder neu initialisiert oder erstellt werden müssen. Fast-Start Failover Mit der Aktivierung des Fast-Start Failovers besteht die Möglichkeit, automatisch eine Standby-Datenbank zu einer Primärdatenbank hochzustufen, wenn die aktuelle Primärdatenbank ausgefallen ist, Fehler aufweist oder die Verbindung verloren ist. Dafür wird von einem dritten Host ein Observer gestartet, der bei Ausfall der Primärdatenbank eine durch den Parameter FastStartFailoverTarget konfigurierte Standby-Datenbank aktiviert. Des Weiteren besteht die Möglichkeit, ein Zeitintervall über den Parameter FastStartFailoverThreshold anzugeben, indem der Observer wartet, bis eine Aktivierung der kontrollierten Standby-Datenbank erfolgt. Im nächsten Schritt muss das Fast-Start Failover mit ENABLE FAST_START FAILOVER aktiviert werden.
655
14 Verfügbarkeit DGMGRL> DGMGRL> DGMGRL> DGMGRL>
EDIT DATABASE prim SET PROPERTY FastStartFailoverTarget = 'stdby'; EDIT DATABASE stdby SET PROPERTY FastStartFailoverTarget = 'prim'; EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = '180'; FAST_START FAILOVER;
Von einem dritten Host wird nun der Observer gestartet, der die Überwachung der Primärdatenbank übernimmt und im Fehlerfall die Aktivierung durchführt. DGMGRL> START OBSERVER;
14.6.18 Aufbau einer Logical Standby Database Da die Replikation einer Logical Standby Database auf Basis von SQL arbeitet, ist es notwendig, dass die korrespondierenden Tabellenzeilen zwischen Primär- und Standby-Datenbank eindeutig identifiziert werden können. Für diese eindeutige Identifizierung wird entweder ein Primary- oder ein Not Null-Unique-Constraint auf den Tabellen benötigt. Ist weder ein Primär- noch ein Not Null-Unique-Constraint vorhanden, werden alle Spalten mit Datentypen definierter Größe zur Identifizierung der Zeilen herangezogen, das heißt, alle Spalten, bis auf Spalten mit den Datentypen LONG, LONG RAW und LOBS. Die View DBA_LOGSTDBY_NOT_UNIQUE hilft bei der Identifizierung von Tabellen, deren Spalten keine eindeutige Identifizierung besitzen. Für die Erzeugung einer Logical Standby Database wird zuerst eine Physical Standby Database erstellt, welche dann in eine Logical Standby Database konvertiert wird. Dafür wird im Vorfeld mit dem PL/SQL Package DBMS_LOGSTDBY.BUILD ein Dictionary für den LogMiner aufgebaut, der Bestandteil des SQL-Applies ist. Damit im nächsten Schritt die Redo-Daten angewendet werden können, wird die Physical Standby Database mit ALTER DATABASE RECOVER TO LOGICAL STANDBY in eine Logical Standby Database konvertiert. Das Starten des SQL-Applies wird dann mit ALTER DATABASE START LOGICAL STANDBY APPLY, das Beenden mit ALTER DATABASE STOP LOGICAL STANDBY APPLY erreicht. Standardmäßig werden alle unterstützen Tabellen repliziert. Soll dies nicht der Fall sein, so können Tabellen, aber auch einzelne SQL-Anweisungen oder ganze Schemata von der Replikation mit der Prozedur DBMS_LOGSTDBY.SKIP herausgefiltert werden. Ein Unterdrücken der Replikation für DML-Anweisungen auf ein Objekt würde dann mit DBMS_LOGSTDBY.SKIP (stmt => 'DML', schema_name => '<Schema>', object_name => '')
erfolgen. Um die Replikation von DDL-Anweisungen auf ein Objekt zu unterbinden, wird folgende Anweisung verwendet: DBMS_LOGSTDBY.SKIP (stmt => 'SCHEMA_DDL', schema_name => '<Schema>', object_name => '')
656
14.7 Failover der Clients
14.7
Failover der Clients Der Failover im Real Application Cluster erfolgt serverseitig automatisch, in einer DataGuard-Umgebung je nach Konfiguration automatisch oder manuell: Die Datenbankdienste werden also auf ein funktionsfähiges System übertragen. Damit auch Clients die Umschaltung realisieren, kommen Transparent Application Failovers (TAF) oder auch Oracle Notification Services (ONS), Fast Application Notifications (FAN) bzw. Fast Connection Failovers (FCF) zum Einsatz.
14.7.1 Transparent Application Failover (TAF) Transparent Application Failover (TAF) ist Bestandteil des Oracle Call Interface (OCI). Es ermöglicht eine automatische Neu-Verbindung zur Datenbank, wenn die Verbindung zu einer Datenbank-Instanz beispielsweise aufgrund eines Ausfalles unterbrochen wurde. In diesem Fall wird die aktive Transaktion zurückgerollt und anschließend eine neue Verbindung − beispielsweise zu einem anderen Cluster-Knoten in einem RAC, der dieselbe Datenbank bereitstellt, oder zu einer Standby-Datenbank − erstellt. Der Ausfall eines Cluster-Knotens bewirkt zunächst noch nichts. Erst wenn die Datenbanksitzung mit dem Server kommunizieren möchte, registriert TAF, dass der Knoten nicht erreichbar ist. Der hierbei auftretende Netzwerkfehler wird aufgefangen und TAF verbindet sich transparent zu einem verbleibenden Cluster-Knoten oder zur Data GuardUmgebung, um dort weiterzuarbeiten. Dabei ist die von TAF transparent aufgebaute Datenbank-Verbindung eine völlig neue, sodass der Zustand der alten Verbindung nicht mehr zur Verfügung steht. Falls der Session-Status für die Anwendung von Bedeutung ist, muss die Anwendung dafür Sorge tragen: Der Entwickler muss im Exception Handler auf den Failover reagieren und den Session-Status wieder korrekt setzen. Dazu stellt TAF spezielle Callback-Mechanismen bereit, die vom Entwickler implementiert werden und mit denen die Anwendung auf das Failover reagieren kann. Speziell für offene Cursor (failover_ type=select) bietet TAF ein Feature: Wird während des Failovers gerade ein Cursor abgearbeitet, kann TAF die SQL-Abfrage sofort nach Verbindungsaufbau nochmals absetzen, die Cursorposition erfassen, an der der Failover auftrat und dort die Bearbeitung fortsetzen. Da TAF auf Erkennung eines Netzwerkfehlers im Client basiert, stellt es keine Funktionalität zur Verfügung, um neue Knoten zu erkennen oder bei einem Wiederanlauf des ausgefallenen Knotens die Verbindung auf diesen wieder zurückzuschalten: Sollen alle Knoten wieder gleichmäßig ausgelastet werden, so kann TAF das nicht realisieren. Stattdessen sind die Datenbankverbindungen explizit zu schließen und neu zu öffnen. Für Client/ Server-Architekturen ist das oft akzeptabel, da durch das Schließen und ein erneutes Öffnen der Anwendung neu zur Datenbank verbunden wird und die Auslastung sich so mit der Zeit wieder verteilt. Für eine Drei-Schichten-Architektur wie J2EE ist dies jedoch ungeeignet: Der Application-Server hält die Verbindungen zur Datenbank im Connection-Pool dauerhaft. Daher wird ein Verfahren benötigt, das den wieder verfügbaren Cluster-Knoten
657
14 Verfügbarkeit automatisch und möglichst zeitnah nutzt. Hier greifen Technologien wie ONS, FAN und FCF.13 Bis 11 g R1 nutzt TAF im Verbindungsdescriptor mehrere Host-Namen sowie einen Service-Namen der Datenbank. Achten Sie auf den Eintrag ADDRESS: Hier finden Sie für jeden Cluster-Knoten einen eigenen Eintrag. dwh.ds-apps.de= (DESCRIPTION= (LOAD_BALANCE=on) (FAILOVER=on) (ADDRESS=(PROTOCOL=tcp)(HOST=dw1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=dw2-server)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=dwh) (FAILOVER_MODE=(TYPE=select) (METHOD=basic))))
Ab 11 g R2 kann ein Single Client Access Name (SCAN) verwendet werden, der als virtueller Hostname des Clusters fungiert. Daher muss ab 11 g R2 nur noch der SCAN des Clusters im Verbindungsdeskriptor angegeben werden. Der Parameter method kann die Werte basic oder preconnect annehmen. Während basic erst im Fehlerfall eine neue Verbindung zu einer funktionsfähigen Datenbankinstanz erstellt, sorgt preconnect dafür, dass bereits bei der ersten Verbindungsaufnahme eine „Schatten“-Session zu einer zweiten Instanz geöffnet wird. Die Failover-Zeit wird so nochmals verkürzt, weil die Zeit für die erneute Verbindungsaufnahme im Fehlerfall entfällt. Doch dafür werden mehr Ressourcen verbraucht, da jeder Client stets direkt zwei Sessions im Cluster öffnet. Der Parameter type kann einen der Werte session, select oder none annehmen. Wird session angegeben, so wird bei einem Verbindungsverlust automatisch eine neue Session (Verbindung) zu einer funktionsfähigen Datenbankinstanz erstellt. Bei select wird zusätzlich der aktuelle Select-Cursor übernommen. Dieser Modus erfordert zusätzlichen Overhead auf Client-Seite. Mit none wird festgelegt, dass kein Failover erfolgen soll. Ist ein Failover erfolgt, so können Sie dies in den Views gv$session (clusterweit) sehen:
v$session
(lokal) bzw.
SELECT username, program, machine, failover_type, failover_method, failed_over FROM v$session;
14.7.2 Failover mit ONS, FAN und FCF Fast Application Notification (FAN) gestattet der Datenbank, an Clients Nachrichten über den Status von Datenbankinstanzen zu versenden. Fast Connection Failover (FCF) setzt auf FAN auf. Zwingende Voraussetzung für FAN und FCF ist die Verwendung der Oracle Notification Services (ONS). ONS kann serverseitig mit dem Server Control (srvctl) implementiert werden:
13
658
Siehe Abschnitt 14.7.2 „Failover mit ONS, FAN und FCF“.
14.7 Failover der Clients srvctl add ons srvctl enable ons srvctl start ons
Die Datei /opmn/conf/ons.config wird automatisch bei der Installation erstellt und enthält die Konfiguration. Drei Parameter sind wichtig:
localport: Der Port, über den ONS mit den Clients kommuniziert remoteport: Der Port, über den ONS mit anderen ONS Daemons kommuniziert nodes: Gibt die Liste weiterer ONS Daemons an, mit denen kommuniziert wird. Sie sollte alle RAC ONS Daemons sowie alle Mid Tier ONS Daemons enthalten. Für jeden Rechner können entweder Hostnamen oder IP-Adressen angegeben werden, die um ihren Remoteport ergänzt werden. FCF wurde mit Oracle10 g R1 eingeführt und ist für 3-Schicht-Architekturen wie J2EE oder ASP.NET ausgelegt. Eine J2EE-Komponente, gleich ob Servlet, JSP oder EJB, verbindet sich in der Regel nicht direkt mit einer Datenbankinstanz. Stattdessen stellt ein Application Server einen Connection Pool bereit, aus dem die Komponente eine Datenbankverbindung entnimmt und an den diese nach Beendigung der Aufgaben die Verbindung wieder zurückgibt. Sofern FCF im Connection Pool aktiviert wurde, registriert sich dieser beim ONS und wird fortan beim Auftreten von Ereignissen wie server down oder server up benachrichtigt. Auf den Ausfall eines Knotens kann nun durch Invalidierung der entsprechenden Datenbankverbindungen reagiert werden: Der Connection Pool gibt keine Verbindungen zum ausgefallenen Knoten mehr aus. Ebenso kann auf das Ereignis server up reagiert werden: Es werden automatisch Verbindungen zur Datenbankinstanz aufgebaut und bei Bedarf an die Anwendungskomponenten ausgeliefert. Im Gegensatz zu TAF ist FCF nicht transparent. Der Entwickler ist in der Pflicht, den Fehler abzufangen, anhand der ORA-Fehlernummer festzustellen, ob ein Failover vorliegt, eine neue Datenbankverbindung aus dem Pool zu holen und den letzten Session-Status wiederherzustellen. Dies erfolgt meist im Exception Handler, der ohnehin genutzt wird. Für das Failover-Handling muss vor allem auf den ORA-Fehler 17008 (Closed Connection) reagiert werden. FCF kann unter anderem für Thick und Thin JDBC-Clients genutzt werden. Um FCF zu aktivieren, setzen Sie die Eigenschaft FastConnectionFailoverEnabled der Data Source auf true. PoolDataSource pds = PoolDataSourceFactory.getPoolDataSource(); pds.setONSConfiguration("nodes=primaryhost:6200,standbyhost:6200"); pds.setFastConnectionFailoverEnabled(true); pds.setURL("jdbc:oracle:thin:@(DESCRIPTION= (LOAD_BALANCE=on) (ADDRESS=(PROTOCOL=TCP)(HOST=primaryhost)(PORT=1521)) (ADDRESS=(PROTOCOL=TCP)(HOST=standbyhost)(PORT=1521)) (CONNECT_DATA=(service_name=service_name)))"); .
Beim Start der Applikation muss die Datei ons.jar im classpath liegen. Die ons.jar ist Teil der Oracle Client-Installation.
659
14 Verfügbarkeit
14.8
Resümee Der Vielfalt der Anforderungen an die Verfügbarkeit von Datenbanksystemen begegnet Oracle mit zahlreichen Optionen wie Oracle Restart, Oracle RAC, Oracle RAC One Node, Standby-Datenbanken mit Data Guard oder Flashback Database. Nahezu jede Anforderung kann so mit Oracle-Bordmitteln bedarfsgerecht abgedeckt werden. Beachten Sie jedoch die Lizenzkosten. Einige Optionen erfordern die teurere Enterprise Edition, andere kosten einen zusätzlichen Aufpreis. Informationen zur Lizenzierung gibt die Oracle-Dokumentation.14 Prüfen Sie die Anforderungen Ihrer Anwendung genau. Errechnen Sie Kosten, die je Stunde Ausfallzeit entstehen, und stellen Sie diese den Kosten für Lizenzierung, Implementierung und laufende Verwaltung gegenüber. Sie erhalten so einen guten Anhaltspunkt, welche Optionen sich für Ihre Umgebung tatsächlich bezahlt machen.
14
660
Wählen Sie unter http://tahiti.oracle.com das passende Oracle Release. Hier finden Sie Lizenzinformationen unter der Rubrik „Licencing Information“.
15 15 Große Datenbanken In diesem Kapitel finden Sie folgende Themengebiete:
Parallelverarbeitung Partitionierung Materialized Views Komprimierung Besonderheiten bei Data Warehouse Datenbanken Dieses Kapitel beschäftigt sich mit den Oracle-Technologien die typischerweise in großen Datenbanken zum Einsatz kommen. Generell denkt man heutzutage bei dem Begriff „große Datenbanken“ zuallererst an Data-Warehouse-Lösungen. Jedoch tauchen in der Praxis auch vermehrt große OLTP-Datenbanken auf (OLTP = Online Transaction Processing), bedingt durch die stetig wachsende Fülle von Unternehmensdaten und den damit einhergehenden Anforderungen, immer größere Datenmengen effizient zu verarbeiten, zu speichern und letztlich als Basis für weitere operative Applikationen bereitzustellen. Ab wann spricht man von großen Datenbanken? Intuitiv legen wir vor allem die Datenmenge als entscheidendes Kriterium an. Heutzutage gelten Datenbanken ab circa 1 TB als groß. Zwischen 300 GB und 1 TB würden wir alles in der Schublade „mittelgroß“ ablegen. Alles unter 300 GB fällt in die Rubrik „kleine Datenbanken“. Sicherlich variieren die hier aufgezeigten Grenzen je nach persönlichem Empfinden. Tabelle 15.1 stellt eine ungefähre Verteilung von Datenbanken in großen Betriebsumgebungen dar. Sicherlich ist die hier durchgeführte Gruppierung als sehr flexibel anzusehen. Ausreißer wird es immer geben, aber die generelle Verteilung basiert auf Erfahrungswerten aus zahlreichen Projekten.
661
15 Große Datenbanken Tabelle 15.1 Prozentuale Verteilung von Datenbankgrößen in Großen Betriebsumgebungen Datenbankgröße (Datenmenge)
Kategorie
Prozentuale Häufigkeit in großen Betriebsumgebungen
Komplexität
Administrationsaufwand
0 GB – 300 GB
Kleine Datenbanken
80 − 90 %
Meist niedrige Komplexität der Verarbeitungslogik
Niedriger Administrationsaufwand, hohe Abdeckung über standardisierte, automatisierte Betriebslösungen
300 GB – 1 TB
Mittlere Datenbanken
10 − 15 %
Oft komplexere Verarbeitungslogik
Mittlerer Administrationsaufwand, teilweise gesonderte Betriebskonzepte
> 1 TB
Große Datenbanken
CREATE MATERIALIZED VIEW FWEEK_PSCAT_SALES_MV TABLESPACE EXAMPLE BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND ENABLE QUERY REWRITE AS SELECT t.week_ending_day, p.prod_subcategory, sum(s.amount_sold) AS dollars, s.channel_id, s.promo_id FROM sales s, times t, products p WHERE s.time_id = t.time_id AND s.prod_id = p.prod_id GROUP BY t.week_ending_day, p.prod_subcategory, s.channel_id, s.promo_id;
Folgende Parameter sind spezifisch:
Wann werden die Zeilen eingefügt? BUILD IMMEDIATE (Default) BUILD DEFERRED Existierende Tabellen werden verwendet: ON PREBUILD TABLE Query Rewrite DISABLE QUERY REWRITE (Default) ENABLE QUERY REWRITE Refresh-Methode USING NO INDEX: verhindert das Erstellen des Default Index Über die Dictionary Views [ALL_], [DBA_] oder entsprechend im Dictionary abgefragt werden.
USER_OBJECTS
SQL> SELECT object_name, object_type FROM user_objects WHERE object_name LIKE '%FWEEK_PSCAT%'; OBJECT_NAME OBJECT_TYPE ------------------------------ -----------------FWEEK_PSCAT_SALES_MV TABLE FWEEK_PSCAT_SALES_MV MATERIALIZED VIEW I_SNAP$_FWEEK_PSCAT_SALES_ INDEX
678
können Materialized Views
15.3 Materialisieren
15.3.3 Notwendige Rechte Für eine erfolgreiche Erstellung und Nutzung von Materialized Views sind folgende Privilegien nötig:
Erstellen einer Materialized View im eigenen Schema und Query Rewrite aktivieren: CREATE MATERIALIZED VIEW QUERY REWRITE CREATE TABLE Erstellen einer Materialized View in einem anderen Schema und Query Rewrite aktivieren: CREATE ANY MATERIALIZED VIEW GLOBAL QUERY REWRITE CREATE TABLE für den Owner Befinden sich die Master-Tabelle(n) und die MView nicht im selben Schema, sind folgende Privilegien zwingend notwendig:
Eigenes Schema: CREATE MATERIALIZED VIEW GLOBAL QUERY REWRITE CREATE TABLE SELECT auf den Master Tabellen (direkt Grant) Erstellen einer MView in einem anderen Schema und Query Rewrite aktivieren: CREATE ANY MATERIALIZED VIEW GLOBAL QUERY REWRITE für den Owner (direkt Grant) SELECT auf den Master Tabellen für den Owner (direkt) Für die Materialized-View-Logs sind folgende Privilegien zwingend: Materialized-View-Log im eigenen Schema erstellen: CREATE TABLE Materialized-View-Log in einem anderen Schema erstellen: CREATE ANY TABLE, MENT ANY TABLE, SELECT
COM-
auf der Master Tabelle
Je nach Situation ist einiges zu beachten, damit erstens die Materialized View erfolgreich erstellt wird und zweitens auch der Query Rewrite stattfinden kann.
15.3.4 Materialized Views modifizieren Das Query Rewrite kann aktiviert und deaktiviert werden: SQL> ALTER MATERIALIZED VIEW fweek_pscat_sales_mv ENABLE QUERY REWRITE;
Nach Modifikationen abhängiger Objekte ist die Materialized View in der Regel zu kompilieren: SQL> ALTER MATERIALIZED VIEW fweek_pscat_sales_mv COMPILE;
679
15 Große Datenbanken Schließlich kann man eine Materialized View löschen: SQL> DROP MATERIALIZED VIEW fweek_pscat_sales_mv;
15.3.5 Materialized Views und Query Rewrite Der größte Vorteil von Materialized Views ist, dass der CBO automatisch Query Rewrites durchführt, ohne den Applikationscode zu verändern. Der CBO berechnet die Kosten verschiedener Exection-Pläne – mit und ohne Query Rewrite –, um den besten Ausführungsplan zu ermitteln. Query Rewrite ist in den folgenden Situationen möglich:
SELECT CREATE INSERT
TABLE ... AS SELECT INTO ... SELECT
Der Cost Based Optimizer kann die Query-Rewrite-Funktionalität nutzen, wenn folgenden Bedingungen erfüllt sind:
Die Materialized View wurde mit der Option ENABLE QUERY REWRITE erstellt. Der Init.ora-Parameter COMPATIBLE ist mindestens auf 8.1.0 oder höher gesetzt. Auf Befehlsebene sind folgende Hints möglich: REWRITE, NOREWRITE (ab Oracle 10g NO_REWRITE) Die Verwendung von Materialized Views für Query Rewrite ist vom Init.ora-Parameter QUERY_REWRITE_INTEGRITY abhängig:
ENFORCED: Nur up-to-date-Materialized Views (nicht STALE) und Relationen, basierend auf erzwungenen Constraints, werden in Betracht gezogen. TRUSTED: Nur up-to-date-Materialized Views (nicht STALE). Dimensionen werden verwendet und Constraints müssen aktiviert sein. STALE_TOLERATED: Alle Materialized Views, Dimensionen und Constraints werden unabhängig von ihrer Aktualität verwendet. Generell nutzt der Optimizer drei Methoden für das Umschreiben eines Select-Statements:
Full Text Match Query Rewrite: Es werden ausschließlich Leerzeichen ignoriert. Partitial Text Match Query Rewrite: Unterschiede in der SELECT-Klausel sind unterstützt. Es können weniger Spalten als in der Materialized Views vorhanden sein. Die Attribute können durch Funktionen (SUBSTR, TO_CHAR etc.) modifiziert sein. Es können Aggregationen stattfinden. Leerzeichen werden ignoriert. Bei der Vorgehensweise für das General Query Rewrite nutzt der Optimizer folgende Methoden:
Semantische Prüfungen Starke Verwendung von Constraints Query Rewrite möglich, auch wenn nicht alle Daten in der MView vorhanden sind (Join Back).
680
15.3 Materialisieren
15.3.6 Materialized Views und Refresh Modes Beim Ändern eine Master Tabelle erhalten die abhängigen Materialized Views den Status STALE, das heißt, sie sollten aktualisiert werden. Es gibt folgende Refresh Modes:
COMPLETE: Die Materialized View wird vollständig neu erstellt FAST: Alle Modifikationen seit dem letzten Refresh applizieren FORCE: Wenn möglich FAST, ansonsten COMPLETE (Default) NEVER: Es wird kein Refresh durchgeführt Zeitpunkt des Refreshs:
ON ON
DEMAND
(Default)
COMMIT
Beispiel eines manuellen Refreshs: dbms_mview.refresh('FWEEK_PSCAT_SALES_MV')
Es kommt die Technologie von DBMS_SNAPSHOT zum Einsatz. Weitere Hilfsprozeduren finden sich im Package DBMS_MVIEW (REFRESH_ALL_MVIEWS, REFRESH_DEPENDENT etc.). 15.3.6.1
Fast Refresh
Damit ein Fast Refresh überhaupt erst möglich ist, muss ein Log aller Modifikationen seit dem letzten Refresh vorhanden sein. Es gibt zwei Arten von Logs:
DML-Befehle verwenden ein Materialized-View-Log (MVIEW-Log), das explizit auf jeder Master-Tabelle zu erstellen ist.
Direct Path Loads verwenden automatisch ein internes Log (ALL_SUMDELTA). Mehrere Materialized Views können dasselbe MVIEW-Log verwenden. Im Folgenden ein einfaches Beispiel für dessen Erstellung: CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID;
Folgende MVIEW-Log-Parameter können spezifiziert werden:
Identifikation der modifizierten Zeilen: WITH PRIMARY KEY (Default) WITH ROWID WITH SEQUENCE Welche Spalten der Log enthalten soll: Spaltenliste (Default keine) Alte bzw. neue Werte im Log: EXCLUDING NEW VALUES (Default) INCLUDING NEW VALUES Für einen Fast Refresh muss die RowId enthalten sein. 681
15 Große Datenbanken
Das Schlüsselwort SEQUENCE muss spezifiziert sein, wenn gemischte DMLs (Kombination von Inserts, Updates und Deletes) auf den Master-Tabellen erfolgen.
Wenn die Materialized View Aggregate enthält, muss der Log folgende Aggregate enthalten:
Alle Spalten sind in der/den MView(s) spezifiziert Die Klausel ICLUDING NEW VALUES Wenn die Materialized View Aggregate enthält, sind folgende Attribute erforderlich: COUNT(*) ist obligatorisch Die SELECT-Liste muss alle Columns der Klausel GROUP BY enthalten Gegebenenfalls weitere Aggregate Wenn die Materialized Views nur Joins enthalten (ohne Aggregationen): Die RowId aller Master-Tabellen muss in der SELECT-Liste der MView-Query enthalten sein
Bei Outer-Joins muss ein Unique-Constraint auf den Join Columns der inneren Tabelle existieren
Für die Beschleunigung des Refresh-Prozesses ist es empfehlenswert, auf der Mview-Tabelle einen Index auf den RowId-Spalten der großen Master-Tabelle zu erstellen Je nach Situation sind einige Dinge zu beachten und auszuführen, damit das Ganze überhaupt funktioniert. Es gibt natürlich auch diverse Einschränkungen, die erfüllt sein müssen, damit ein FastRefresh möglich ist:
Keine nicht-deterministischen Ausdrücke in der MView Definition (SYSDATE, etc.). Eine Materialized View mit Aggregationen unterstützt nicht MIN und MAX mit DELETE und UPDATE auf die Master-Tabellen.
Es sind keine Spalten LONG und LONG 15.3.6.2
RAW
erlaubt.
Refresh Fast on Commit
Diese Technologie ermöglicht die Nachführung redundanter Daten in den Materialized Views in derselben Transaktion wie die ändernde Transaktion auf der Master-Tabelle. Für eine ON-COMMIT Aggregations-MView12 oder Join-MView13 ist immer ein RowId14-
12
Materialized View, die nach jedem Commit neu aggregiert wird. Materialized View, die ihre Quelldaten aus mehreren Basistabellen über eine entsprechende FromKlausel spezifiziert. 14 Ein MView-Log ist ein interner Trigger, der alle Änderungen auf den involvierten Basistabellen protokolliert. Ein MView-Log wird bei der Fast-Refresh Methode verwendet. Somit kann gezielt eine Delta Aktualisierung aller geänderten Daten innerhalb einer Zeitperiode durchgeführt werden. Ein RowId MView-Log referenziert immer auf die RowIds der involvierten Quelltabellen. 13
682
15.3 Materialisieren MView-Log notwendig. Zudem müssen alte Attribute (alte und neue Werte), die in der Materialized View enthalten sind, auch im MView-Log vorhanden sein.
15.3.7 Materialized Views und Analysemöglichkeiten Nicht alle Materialized Views unterstützen dieselben Query-Rewrite- bzw. Refresh-Möglichkeiten. In früheren Oracle-Versionen war es zum Teil schwierig, die unterstützten Features einer MView zu identifizieren. Seit der Version 9i sind im Package DBMS_MVIEW Prozeduren (EXPLAIN_MVIEW und EXPLAIN_REWRITE) enthalten, um genau dies zu vereinfachen:
Die Prozedur EXPLAIN_MVIEW identifiziert die unterstützten Funktionalitäten einer Materialized View.
Die generierten Ausgaben können in die Tabelle MV_CAPABILITIES_TABLE geschrieben werden. Diese ist über das Skript $ORACLE_HOME/rdbms/admin/utlxmv.sql zu erzeugen. Die Ausgabe erfolgt über einen Parameter vom Typ VARRAY. Prüfung nach der Rewritefähigkeit einer Materialized View: exec dbms_mview.explain_mview('FWEEK_PSCAT_SALES_MV', '1') SQL> SELECT capability_name, possible,msgtxt FROM mv_capabilities_table WHERE mvname = 'FWEEK_PSCAT_SALES_MV' AND mvowner = user AND statement_id = '1' AND capability_name LIKE 'REWRITE%'; CAPABILITY_NAME ----------------------------REWRITE REWRITE_FULL_TEXT_MATCH REWRITE_PARTIAL_TEXT_MATCH REWRITE_GENERAL REWRITE_PCT
P MSGTXT - ----------------------Y Y Y Y N general rewrite is not possible and PCT is not possible on any of the detail tables
Prüfung nach der Refreshfähigkeit einer Materialized View: SQL> SELECT capability_name, possible, msgtxt FROM mv_capabilities_table WHERE mvname = 'FWEEK_PSCAT_SALES_MV' AND mvowner = user AND statement_id = '1' AND capability_name LIKE 'REFRESH%'; CAPABILITY_NAME ----------------------------REFRESH_COMPLETE REFRESH_FAST REFRESH_FAST_AFTER_INSERT
P MSGTXT - ----------------------------Y N N the detail table does not have a materialized view log ... REFRESH_FAST_AFTER_ONETAB_DML N SUM(expr) without COUNT(expr) REFRESH_FAST_AFTER_ANY_DML N see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled ...
683
15 Große Datenbanken
Die Prozedur
EXPLAIN_REWRITE identifiziert, weshalb ein Rewrite unmöglich ist bzw. welche Materialized View für ein Rewrite verwendet wird. Der generierte Output kann entweder in die Tabelle REWRITE_TABLE geschrieben werden (erstellt mit $ORACLE_HOME/ rdbms/admin/utlxrw.sql) oder auch über den Ausgabeparameter VARRAY zurückgegeben werden. Das nachfolgende Beispiel zeigt einen Test, ob eine bestimmte Abfrage die Materialized ViewFWEEK_PSCAT_SALES_MV verwenden kann. Das Select-Statement wird dabei analysiert und nicht ausgeführt. SQL> var query VARCHAR2(1000) SQL> exec :query := 'SELECT p.prod_subcategory, '|| ' sum(s.amount_sold) dollars '|| 'FROM sales s, products p '|| 'WHERE s.prod_id = p.prod_id '|| 'GROUP BY p.prod_subcategory' SQL> exec dbms_mview.explain_rewrite( :query, 'FWEEK_PSCAT_SALES_MV', '1')
Wird der zweite Übergabeparameter nicht angegeben, werden alle Materialized Views des aktuellen Schemas analysiert. Der dritte Übergabeparameter dient zur Identifikation der Statements in der Resultats-Tabelle (Daten werden nicht automatisch gelöscht). SQL> SELECT FROM WHERE AND AND
MESSAGE ------------------------------------------------------QSM-01071: a lossy join in materialized view, FWEEK_PSCAT_SALES_MV, from table,SALES, not found in query QSM-01052: referential integrity constraint on table, SALES, not VALID in ENFORCED integrity mode QSM-01086: dimension(s) not present or not used in ENFORCED integrity mode
Die Beschreibungen der Fehlermeldungen (QSM-Messages) stehen in der Oracle-Dokumentation „Error Message Guide“. Optional sind sie damit online abfragbar: oerr qsm
15.3.8 Materialized Views und Partitionen In einem Data Warehouse sind üblicherweise viele Tabellen partitioniert und es kommen sogenannte „Rolling Windows“ zum Einsatz. Im Rahmen des Rolling-Windows-Vorgehens möchten wir natürlich auch Materialized Views verwenden. Die übliche Vorgehensweise für das Hinzufügen von Daten für eine neue Partition und das Aktualisieren der abhängigen Materialized Views läuft wie folgt ab:
684
15.4 Komprimieren
Eine neue Partition hinzufügen. Die neuen Daten direkt in diese neue Partition unter der Verwendung der Klausel EXCHANGE PARTITION
laden. Die älteste Partition löschen.
Alle abhängigen Materialized Views aktualisieren. Noch unter Oracle 8i wurde die ganze Materialized View entweder als FRESH oder als STALE betrachtet, unter Oracle 9i geschieht dies mit einer feineren Granularität. Die Identifizierung der Zeilen einer Materialized View, die von einer bestimmten Partition (der Basis-Tabelle) abhängig sind, ist möglich. Wenn nun also eine Partition einer ElternTabelle modifiziert wird, sind nur die entsprechenden Zeilen dieser Materialized View betroffen. Diese Funktionalität nennt man Partition Change Tracking (PCT). Sie bedeutet Folgendes:
Unterstützung von Fast Refresh Unterstützung von Query Rewrite auf einer teilweise STALE Materialized View, auch bei Gebrauch des ENFORCED und TRUSTED Integritäts-Modus Für die Verwendung von PCT existieren einige Voraussetzungen bzw. Einschränkungen:
Mindestens eine Basistabelle muss RANGE oder COMPOSITE partitioniert sein. Nur einfache Partitionsschlüssel sind erlaubt (ein Attribut). Die Materialized View muss einen Partitionierungsschlüssel (oder Partition Marker) beinhalten.
Für Partition-Change-Tracking-Query-Rewrite muss der Partitionsschlüssel benutzt werden.
Bei der Verwendung eines GROUP ker im GROUP
BY
BY
ist der Partitionsschlüssel oder der Partition-Mar-
zu verwenden.
Datenmodifikationen werden nur auf partitionierte Basis-Tabellen durchgeführt. Praxistipp Häufig will man den Partitionsschlüssel nicht in der Materialized View verwenden, da dies die Anzahl der Zeilen erheblich vergrößern würde. Um dies zu verhindern, kann ein sogenannter „Partition Marker“ abgespeichert werden. Dies ist ein Identifizierungskennzeichen, das die Funktion DBMS_MVIEW.PMARKER erzeugt. Die ROWID wird als Eingabeparameter mitgegeben. Leider wird hier ein relativ großer Zeitaufwand für die Erstellung der Materialized View benötigt.
15.4
Komprimieren Gerade in sehr großen Datenbanken und insbesondere bei Data-Warehouse-Datenbanken spielt die Komprimierung von Daten und Indizes eine große Rolle. Ein Hauptgrund dafür ist die erhoffte Platzersparnis. Der mögliche Performance-Gewinn hinsichtlich des Zugriffs (mehr Daten innerhalb eines Datenblocks) und eine daraus resultierende Reduzierung der I/O-Last wird oft vergessen. Diese beiden Punkte stellen aber nach Meinung der Autoren die Hauptvorteile bei der Anwendung von Daten- und Indexkomprimierung dar.
685
15 Große Datenbanken Oracle komprimiert Daten auf Blockebene. Dies bedeutet, dass Mehrfacheinträge im Datenteil eines Blocks nur einmal gespeichert sind. Ein Verweis im Datenteil des Blockes zeigt auf eine Symboltabelle, die im Header des Blockes verwaltet wird. Diese Symboltabelle übernimmt hier die Verwaltung der Duplikate innerhalb eines Blocks. Die Indexkomprimierung funktioniert ebenfalls auf Blockebene und verhindert über das gleiche Prinzip wie bei der Datenkomprimierung die Speicherung von Dubletten. Eine Symboltabelle im Blockheader verweist auf sich wiederholende Einträge in den Leaf-Blöcken des Index. Generell gilt für jede Daten- und Indexkomprimierungsart: Die Komprimierungsrate ist stark von der Art und der Verteilung der Daten abhängig und sollte immer sorgfältig getestet werden. Mit Oracle 11g kam die Advanced-Compression-Option auf den Markt. Damit sind weitere Komprimierungsfunktionalitäten auf unterschiedlichsten Ebenen verfügbar:
OLTP Compression: Table Compression für alle Operationen Securefile Compression: Komprimierung für unstrukturierte Daten des neuen Datentyps „Securefile“
RMAN Backup Compression: Zusätzlicher Komprimierungsalgorithmus für RMANBackups
Data Pump Compression: Komprimierung von Exports Data Guard Network Compression: ab 11g R2 generell komprimierte Übertragung von Redo auf die Standby-Seite In den folgenden Abschnitten konzentrieren wir uns auf die reinen Daten- und Indexkomprimierungsmöglichkeiten von Indizes und gesamten Heap-Tabellen innerhalb der Datenbank. Oracle Funktionalität
Verfügbar seit Version
Index Compression
Oracle 8i
IOT Compression
Oracle 8i
Table Compression for Direct Load
Oracle 9i R2
Table Compression for All Operations
Oracle 11g R1
Securefile Compression
Oracle 11g R1
Abbildung 15.9 Übersicht über aktuell verfügbare Oracle Komprimierungsfunktionalitäten
15.4.1 „Index und Index Organized Table“-Komprimierung Die seit Oracle 8i implementierte „Index und Index Organized Table“-Komprimierung ist bei B*Tree Indizes und IOTs möglich. Index-Komprimierung ist bei „Nonunique Indizes“ am effektivsten. Aber auch für zusammengesetzte „Unique Indizes“ mit mindestens zwei Spalten ist Indexkomprimierung möglich.
Abbildung 15.10: Prinzip der „Index Leaf Block“-Komprimierung
Die Indexkomprimierung wird über das Schlüsselwort „COMPRESS“ vorgenommen: SQL> CREATE INDEX cust_last_name ON customers(cust_last_name) TABLESPACE USERS COMPRESS;
Eine Indexkomprimierung kann ebenfalls im Rahmen eines Index-Rebuilds aktiviert oder deaktiviert werden: SQL> ALTER INDEX cust_last_name REBUILD ONLINE NOCOMPRESS;
Die Indexkomprimierung unterstützt keine Bitmap-Indizes, Indizes auf Composite-partitionierte Tabellen und Domain-Indizes. Die Indexkomprimierung kann unter den zuvor genannten Vorrausetzungen auch für partitionierte Indices verwendet werden. Die Verwendung der Indexkomprimierung kann zu einem höheren CPU-Bedarf führen. Auch ist die zu erwartende Indexkomprimierungsrate stark von den Inhalten der betreffenden Oracle-Blöcke abhängig. Je mehr Dubletten darin enthalten sind, desto stärker kann man komprimieren.
15.4.2 DIRECT-LOAD-Datenkomprimierung Diese unter Oracle 9i R2 eingeführte Datenkomprimierung, auch als Batch-Komprimierung bekannt, hat ebenfalls das primäre Ziel, weniger Speicherplatz für Heap-Tabellen (normale Tabellen, Materialized Views) zu verwenden. Auch hier erfolgt die Komprimierung durch die Eliminierung von Wiederholungen auf Spaltenebene. Ziel dieser Komprimierungsart ist es, sich nicht mehr ändernde Daten effizient zu speichern. SQL> CREATE TABLE cust_comp COMPRESS FOR DIRECT_LOAD OPERATIONS AS SELECT * FROM sh.customers ORDER BY cust_first_name, cust_last_name;
Die DIRECT_LOAD-Komprimierung wird mit der Syntax COMPRESS FOR DIRECT_LOAD aktiviert. Die folgende Abfrage auf die Dictionary Tabelle USER_TABLES zeigt den Status der angelegten Tabelle CUST_COMP an. Hier steht der Wert BASIC für die DIRECT-LOADKomprimierung. Wichtig ist, dass die Datenkomprimierung nur bei sogenannten „DirectPath-Operationen“ wie Create Table as Select (CTAS), INSERT /* +APPEND */ …,
687
15 Große Datenbanken INSERT SELECT … FROM …, Import über Data Pump oder bei einer explizit durchgeführten Reorganisation ausgeführt wird: SQL> SELECT FROM WHERE
table_name, compression, compress_for user_tables table_name like 'CUST%';
Ein Vergleich der Platzbelegung über die Dictionary Tabelle USER_SEGMENTS zeigt in diesem Fall eine Reduzierung des Speicherplatzbedarfs nach der Komprimierung um 50 Prozent an: SQL> SELECT FROM WHERE
segment_name, bytes/1024/1024 user_segments segment_name like 'CUST%';
Wie bereits erwähnt, führen „Nicht-Direct-Path-Operationen“ wie herkömmliche Inserts und Updates zur Speicherung von nicht-komprimierten Daten. Dies führt wiederum nach einiger Zeit zu gravierenden Performance-Einbußen durch die entstehenden Migrated Rows (siehe auch Kapitel 8 „Optimierung“) und zusätzlich noch zu einem erhöhten Speicherplatzbedarf. Die folgende Abfrage zeigt den Effekt der Migrated Rows, in diesem Fall entstanden durch Massen-Updates auf komprimierte Datensätze: SQL> ANALYZE TABLE cust COMPUTE STATISTICS; Table analyzed. SQL> ANALYZE TABLE cust_comp COMPUTE STATISTICS; Table analyzed. SQL> SELECT FROM WHERE
table_name, compression, compress_for, chain_cnt user_tables table_name like 'CUST%';
In diesem Fall hilft nur noch eine Daten-Reorganisation für die Behebung des Problems. Praxistipp Eine vorherige Sortierung der betroffenen Spalten für eine geplante DIRECT-LOAD-Datenkomprimierung anhand von nicht selektiven Kriterien führt zu einer erhöhten Komprimierungsrate. Im Falle einer geplanten DIRECT-LOAD-Komprimierung kann dies sicherlich gut über eine Datenreorganisation durchgeführt werden. Absolute Vorsicht ist bei nachträglichen Änderungen der Daten über Insert- und/oder UpdateBefehle geboten. Es entstehen Migrated Rows, die die Performance nachteilig beeinflussen, sodass nach einiger Zeit eine Reorganisation unumgänglich ist.
688
15.4 Komprimieren
15.4.3 OLTP-Tabellenkomprimierung Die mit 11g R1 eingeführte Advanced-Compression-Option enthält auch eine neue Datenkomprimierungsart, die sogenannte „OLTP-Tabellenkomprimierung“. Diese Komprimierung basiert ebenfalls auf dem bereits beschriebenen Blockkomprimierungsprinzip, allerdings mit einem kleinen Unterschied: Die Daten werden nicht nur bei Direct-Path-Operationen komprimiert abgespeichert, sondern auch bei Verwendung von herkömmlichen Insert- und Update-Befehlen asynchron nachträglich komprimiert. Die eingefügten Daten werden zunächst nicht komprimiert im Oracle-Block abgespeichert. Die eigentliche Komprimierung erfolgt nach Erreichen der PCTFREE-Grenze im Hintergrund. Neue Daten werden ebenfalls unkomprimiert abgespeichert und bei der Erreichung der PCTFREE-Grenze wieder blockweise komprimiert. Diese Technik ist daher optimal für den OLTP-Betrieb geeignet. Nachfolgend der Ablauf einer OLTP-komprimierten Tabelle vom Anlegen bis zu den Update-Änderungen: Es beginnt mit dem Befehl und dem Schlüsselbegriff das Anlegen einer OLTP-komprimierten Tabelle:
COMPRESS FOR ALL OPERATIONS
für
SQL> CREATE TABLE cust_oltp_comp COMPRESS FOR ALL OPERATIONS AS SELECT * FROM sh.customers ORDER BY cust_first_name, cust_last_name;
Ein Vergleich der Platzbelegung über die Dictionary-Tabelle USER_SEGMENTS zeigt eine Reduzierung des Speicherplatzbedarfs nach erfolgter OLTP-Komprimierung um 50 Prozent an: SQL> SELECT FROM WHERE
segment_name, bytes/1024/1024 user_segments segment_name like 'CUST%';
Nachfolgend die Situation nach den gleichen durchgeführten Massen-Updates auf die OLTP-komprimierte Tabelle CUST_OLTP_COMP: SQL> ANALYZE TABLE cust_comp COMPUTE STATISTICS; Table analyzed. SQL> ANALYZE TABLE cust_oltp_comp COMPUTE STATISTICS; Table analyzed. SQL> SELECT FROM WHERE
table_name, compression, compress_for, chain_cnt user_tables table_name like 'CUST%';
Wir erkennen hier im Vergleich zur DIRECT-LOAD-komprimierten Tabelle sogar noch mehr Migrated Rows, was zu einer noch dramatischeren Performance-Verschlechterung
689
15 Große Datenbanken der Tabelle CUST_OLTP_COMP im Vergleich zur zuvor gemessenen Tabelle CUST_COMP führt. Wir stellen hier genauso die negativen Auswirkungen fest wie zuvor, diesmal allerdings nur bei den Update-Aktivitäten. Praxistipp Eine vorherige Sortierung der betroffenen Spalten für eine geplante OLTP-Datenkomprimierung anhand von nicht selektiven Kriterien führt zu einer erhöhten Komprimierungsrate. Im Falle einer geplanten OLTP-Komprimierung kann dies über eine vorherige Datenreorganisation erfolgen. Absolute Vorsicht ist auch hier bei nachträglichen Änderungen der Daten über Update-Befehle geboten. Es entstehen ebenfalls wie bei der DIRECT-LOAD-Komprimierung Migrated Rows, die die Performance so nachteilig beeinflussen, dass nach einiger Zeit eine Reorganisation erforderlich ist. Es gibt große Performance-Einbußen bei der Ausführung von ADD COLUMN-, DROP COLUMN- und CREATE TABLE AS SELECT-Befehlen auf OLTP-komprimierte Tabellen. Hier müssen Sie individuell testen, ob eine OLTP-Komprimierung überhaupt gewinnbringend einsetzbar ist.
15.5
Data Warehouses Neben den üblichen transaktionsorientierten Anwendungen, den sogenannten „OLTP-Applikationen“, mit ihrem Schwerpunkt auf zahlreiche kleine und wenige Daten-verändernde Transaktionen, gibt es auch analyseorientierte Applikationen für Reporting, interaktive Analysen oder Data Mining. Diese sind deutlich stärker auf umfangreiche, lang laufende und vorwiegend lesende Prozesse angepasst. Die Daten dieser Anwendungen stammen oft von mehreren unterschiedlichen Quellsystemen und werden ständig aktualisiert. Diese nicht selten unternehmensweit genutzten Datenbestände werden in vielen Fällen historisch geführt und fast immer über die Quellsysteme hinweg integriert. Geschrieben und verändert werden sie nicht direkt durch Benutzer, sondern nur über dedizierte Prozesse, sogenannte „ETL-Prozesse“. Diese extrahieren meist in bestimmten Zeitabständen große Datenmengen von den Quellsystemen und fügen sie zentral zusammen – oft parallelisiert und innerhalb weniger Transaktionen. Solche Anwendungen, die in den meisten Fällen auf Datenbanksystemen basieren, nennt man Data Warehouses. Das Oracle Datenbanksystem wird häufig für den Betrieb solcher Data Warehouses genutzt und so stehen bereits seit Ende der neunziger Jahre erste Mechanismen und Tools speziell dafür zur Verfügung. Inzwischen ist die Liste der Data-Warehouse-Features – manche als Option zusätzlich zu lizenzieren – in der Datenbank stark angewachsen. Neben zahlreichen Erweiterungen des Query Optimizers geht es um folgende wichtige Funktionen:
Parallelisierung Star Transformation & Bitmap/Bitmap Join Indizes Analytische SQL-Funktionen SQL-DML-Erweiterungen (Merge, Multi Table Insert, DML Error Logging etc.) Table- und Index-Kompression Dimensionen Einige dieser Möglichkeiten sind für OLTP-Systeme ebenso interessant und sind daher bereits in anderen Kapiteln dieses Buches behandelt. Im Folgenden beschränken wir uns deshalb auf die rein DWH-spezifischen Features und Best Practices mit Oracle-Datenbanken im Data-Warehouse-Umfeld.
15.5.1 Daten cachen oder In-Memory Operationen: PGA versus SGA Wie verteile ich für Data Warehouses den verfügbaren Hauptspeicher zwischen SGA15 und PGA16 am geschicktesten? In der SGA verwaltet Oracle zahlreiche Speicher-Pools: den Shared-Pool für SQL-Statements und PL/SQL-Code, die Buffer-Caches für Daten, die (SGA-interne) UGA17 für Kommunikationsbuffer, den Java-Pool für Javaklassen etc. In der PGA hingegen werden die sessionspezifischen Daten abgelegt, also Stacks und Heaps für PL/SQL- und Java-Programme, aber auch Sortier-, Hash- und Bitmap-Puffer für SQL-Operationen. Dabei ist bei älteren Oracle-Versionen einiges zu beachten. 15.5.1.1 Oracle 9i und Oracle 10g Die Größe der PGA ist seit Version 9i durch den Parameter PGA_AGGREGATE_TARGET datenbankweit einstellbar, sofern der Parameterwert von WORKAREA_SIZE_POLICY auf AUTO steht. Es handelt sich dabei allerdings nicht um einen festen, reservierten Speicherbereich im RAM, sondern um einen Richtwert, der die Summe der Größen aller einzelnen PGA-Arbeitsbereiche (= Workareas18) vorgibt. Je nach aktueller Nutzung kann der tatsächlich genutzte Hauptspeicher deutlich kleiner, aber manchmal auch durchaus größer als der Richtwert sein.19 15 16
17 18 19
Bei der SGA handelt es sich um eine Gruppe von Shared Memory-Strukturen im Hauptspeicher, die Daten sowie Steuerinformationen einer Oracle-Instanz enthalten. 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. Wir betrachten hier nur den Fall dedizierter Connections, nicht die Shared-Server-Konfiguration, da diese im DWH-Umfeld eher ungewöhnlich ist. Achtung: Eine Workarea entspricht nicht einer Session. Eine Session kann durchaus auch mehrere Workareas beispielsweise für unterschiedliche Operationen innerhalb einer Abfrage gleichzeitig nutzen. Vor 10g R2 gelten dabei allerdings feste Maximalgrößen für einzelne Workareas. So kann eine Sortoder Hash-Operation maximal 5 Prozent der PGA bzw. 100 MB nutzen – bei Parallel Queries maximal 30 Prozent. Ab 10g R2 sind diese Grenzen flexibler geworden.
691
15 Große Datenbanken Praxistipp Für DWH-Systeme kann eine explizite PGA_AGGREGATE-Basiseinstellung von 50 Prozent des für Oracle-Caches verfügbaren Hauptspeichers als gute erste Ausgangsbasis angesehen werden, sofern es keine konkreten Anhaltspunkte für eine andere Verteilung gibt. Wenn also beispielsweise 64 GB zur Verfügung stehen, sollte man initial 32 GB für die SGA und 32 GB für die PGA vergeben. Im Test und Betrieb kann dies durch eine Feineinstellung verändert werden. Dabei ist zu beachten, dass diese Werte auch Einfluss auf die Entscheidungen des Query-Optimizers haben können, also die Ausführungspläne beeinflussen. Aus Erfahrungen mit manchen DWHs kann der Anteil der PGA auch durchaus mal in Richtung 80 Prozent tendieren – oder aber auch in Richtung 20 Prozent.
Auch wenn WORKAREA_SIZE_POLICY = AUTO als systemweite Einstellung die richtige Wahl ist: Manchmal muss man sichergehen, dass für den eigenen ETL- oder Abfrageprozess eine bestimmte Menge an Sort- oder Hashspace zur Verfügung steht. Dann kann gezielt für eine bestimmte Session auch die ältere Variante der expliziten Sort- und HashVerwaltung genutzt werden. Dafür stellt man für die betroffene Session WORKAREA_SIZE_ POLICY auf MANUAL und justiert dann SORT_AREA_SIZE und HASH_AREA_SIZE nach Bedarf (der Wert wird aus Tests ermittelt, V$SQL_WORKAREA bietet hier einen guten Überblick, solange WORKAREA_SIZE_POLICY noch auf AUTO steht). Allerdings gilt in diesem Fall, dass der maximale Wert 231-1 Bytes (also knapp 2 GB) nicht überschritten werden darf. Beispiel: Sicherstellen einer 1-GB-Hash-Area-Size für eine bestimmte Query: ALTER SESSION SET WORKAREA_SIZE_POLICY = MANUAL; ALTER SESSION SET HASH_AREA_SIZE = 1073741824; … Query ALTER SESSION SET WORKAREA_SIZE_POLICY = AUTO;
Beachten Sie, dass solche manuellen Einstellungen die Ausnahme bleiben, da sonst das Prinzip des Speicherpools wieder ausgehebelt wird. Wenn diese Art der Nutzung überhand nimmt, könnte das DWH-System wieder beginnen, Teile des RAMs auf die Disks auszulagern (Swapping) – und genau das will man ja verhindern. 15.5.1.2 Oracle 11g Wie in Kapitel 2 „Architektur und Administration“ bereits ausführlich erläutert, kann ab Oracle 11g mit dem Datenbankparameter MEMORY_TARGET eine automatische Umverteilung des Hauptspeichers zwischen PGA und SGA eingestellt werden. Erste Projekterfahrungen mit diesem Parameter zeigen keine besonderen Probleme. Allerdings können im Zusammenhang mit manchen Betriebssystemen (wie Linux 32Bit) und bestimmten Einstellungen (Large Pages) Probleme auftauchen. 15.5.1.3 Wenn die PGA zu klein ist Passen nun bei einer Abfrage Sortierbereiche oder Hashes trotz allem nicht mehr in den vorgesehenen PGA-Bereich – was gerade im Betrieb großer DWHs sehr oft vorkommt –, werden diese in den TEMP-Tablespace geschrieben und in Häppchen verarbeitet. Dies
692
15.5 Data Warehouses belastet einerseits den Disk-IO zusätzlich, andererseits werden die Operationen oft um Faktoren langsamer. Eine Abfrage-Operation profitiert also immer nur dann zuverlässig von einer großen PGA, wenn folgende Bedingungen erfüllt sind:
Sortier- und Hash Operationen müssen komplett in eine Workarea der PGA passen oder diese muss zumindest so partitionierbar sein, dass jede Bereichsoperation komplett in eine Workarea passt (beispielsweise bei Partition-Wise-Joins).
Die Summe aller zu einem Zeitpunkt genutzten PGA Workareas dürfen den Wert von PGA_AGGREGATE_TARGET nicht (deutlich) überschreitet.
Genügend physisches RAM muss zur Verfügung stehen. Weitere Maßnahmen zur TEMP-Optimierung finden Sie in Kapitel 3 „Speicherplatzverwaltung“.
15.5.2
Backup & Recovery von großen Data-WarehouseDatenbanken
Wie Sie mit Oracle-Datenbanken Backup & Recovery durchführen, haben wir in Kapitel 14 „Backup und Recovery“ bereits ausführlich beschrieben. Auf den folgenden Seiten geht es aber um die Besonderheiten beim Backup & Recovery von sehr großen Data-Warehouse-Datenbanken, für die meist besondere Regeln gelten. Wenn wir monate- oder jahrelang Daten von Kunden, Bestellungen, Lieferungen, Telefonaten oder gar Messdaten aus RFID-Lesern sowie Sensordaten aus automatisierten Produktionsanlagen speichern, integrieren und analysieren wollen, kommen nicht selten Datenmengen im zwei- und dreistelligen TB-Bereich zusammen. Bei Datenbanken dieser Größenordnung reichen wöchentliche Inc0-/Inc1-Backups nicht mehr aus. Lösungen außerhalb der Oracle-Datenbank sind beispielsweise Split-Mirror-Verfahren oder Image-Copies auf SAN-Ebene. Es geht aber grundsätzlich auch mit RMAN. Hier kommt uns zu Hilfe, dass typische Data Warehouses sehr oft einen riesigen Anteil an sich (fast) nie wieder ändernden Daten haben, also in gewissen Bereichen Nur-Lese-Datenbanken sind und demnach recht umfangreiche Read-Only-Bestandteile haben.
Unveränderliche Daten (Read Only)
Veränderliche Daten Flüchtige/Temporäre Daten Abbildung 15.11: Data Warehouse: Anteil sich ändernder Daten 10 Prozent, Anteil Read-Only-Daten 80 Prozent, Anteil flüchtiger „intermediate“ Daten 10 Prozent
693
15 Große Datenbanken 15.5.2.1 Maßnahme 1: Block Change Tracking & Backup Retention Zunächst muss verhindert werden, dass jedes Backup immer alle Blöcke aller Tablespaces liest, nur um die geänderten zu identifizieren. Angenommen, zwischen zwei Backups ändern sich lediglich zwei Prozent der Blöcke im gesamten Data Warehouse bzw. sind neu hinzugekommen. Das wäre dann bei 50 TB lediglich 1 TB, das gesichert werden müsste. Natürlich ist es bei solch großen Datenbanken erst einmal sehr wichtig, ein Backup in möglichst kurzer Zeit wieder einspielen zu können. Wir sollten dabei aber nicht unterschätzen, dass ein IncX-Backup, das alle Blöcke prüfen muss, auch selbst eine unangenehm lange Laufzeit haben kann, was wiederum negativen Einfluss auf die verfügbaren Hardware-Ressourcen für den Regelbetrieb hat. Bei einer angenommenen Bandbreite von 1GB/sek. für Backup-Lesevorgänge in unserem betrachteten Beispiel ist das ein hypothetischer Unterschied von mehr als 14 Stunden für einen kompletten Check aller Blöcke gegenüber gerade mal 17 Minuten bei gezieltem Lesen der nur geänderten Blöcke. Es macht in der Realität zwar einen noch beträchtlicheren Unterschied, ob man alles am Stück liest oder ganz gezielt einzelne Blöcke von 32 kB herauspicken muss, aber da in (gut gemachten) Data Warehouses ein Großteil der Datenmanipulation durch Massen-Inserts im Append Mode entsteht, und so neue Daten sehr oft in großen Tranchen am Stück in die Datendateien geschrieben werden, kann der reale Zeitgewinn dennoch beträchtlich und durchaus in der Nähe des hypothetischen Maximums sein. Kurzum, es geht – wie eigentlich meistens – um eine Minimierung des Aufwands zur Identifikation der zu sichernden Daten sowie um eine Minimierung des Volumens der Daten; Letzteres aber weniger aus Platz- denn aus Zeitgründen. Zu den ohnehin gerne genutzten Möglichkeiten zur Backup-Beschleunigung wie MultiSection-Backups für sehr große Datendateien greift man zunächst am besten auf Features wie das „Block Change Tracking“ (BCT) zurück, das alle geänderten Blöcke in einer Datei protokolliert und beim eigentlichen Backup nur noch diese Blöcke sichert. So wird ein regelmäßigesn aber möglichst seltenes, langsames Inc0-Backup um zahlreiche tägliche, schnelle, durch BCT gestützte Inc1-Backups unterstützt. Leider müssen bei einem FullRestore alle Inhalte aller Backups seit dem letzten Inc0-Backup wieder eingespielt werden, sodass sich die Restore-Performance mit der Anzahl und Größe der Inc1-Restores verschlechtert. So ist es nach einigen Inc1-Backups irgendwann wieder an der Zeit, ein Inc0Backup durchzuführen. Hier müssen wir von Datenbank zu Datenbank immer auch einen individuellen Breakeven zwischen Backup- und Restore-Performance finden. 15.5.2.2 Maßnahme 2: NOLOGGING für flüchtige Daten Um noch mehr Optimierungspotenzial zu finden, betrachten wir zunächst ein hypothetisches, aber durchaus repräsentatives Data Warehouse aus Backup & Recovery-Sicht (siehe Abbildung 15.11). Es hat folgenden Aufbau:
10 Prozent Daten, die sich immer wieder ändern, z.B. Kundenstammdaten 10 Prozent Daten, die nur temporär innerhalb eines bestimmten Prozesses benötigt werden, z.B. Staging- oder Cleansing-Daten, die während eines ETL-Prozesses erzeugt und wieder gelöscht werden
694
15.5 Data Warehouses
80 Prozent Daten, die sich per Definition nie wieder ändern, z.B. abgeschlossene Bestellungen oder Messdaten Am einfachsten (und unpraktischsten) sind die Erstgenannten. Sie werden einfach regulär gesichert. Aber glücklicherweise sind diese Datenmengen meist überschaubar. Ebenfalls kein großes Problem stellt die zweite Gruppe dar, auch wenn sie vielleicht etwas schwieriger zu identifizieren ist. Tabellen, deren Inhalte nur während einer ETL-Verarbeitung relevant sind – sogenannte „transiente Daten“ – dürfen im Regelfall in NOLOGGING-Tabellen liegen und per Direct-Insert befüllt werden. Sie müssen zudem in kein reguläres RMAN-Backup einfließen. Letzteres stellt man sicher, indem man seine ETLProzesse nach ihrer Arbeit aufräumt, also nicht mehr benötigte Datensätze in den transienten Tabellen mit TRUNCATE löscht. 15.5.2.3 Maßnahme 3: Richtig Partitionieren Am interessantesten sind aber die 80 Prozent „Read-Only“-Daten. Wenn es möglich wäre, sie aus dem Backup komplett herauszuhalten, hätten wir es nicht mit einer 50-TB-, sondern lediglich mit einer 10-TB-Datenbank zu tun; und das auch bei einem Inc0, also einem Full Backup. Um einen Tablespace aus einem Full Backup auszuschließen, muss man lediglich dafür sorgen, dass er auf „Read Only“ gesetzt ist.20 Dann wird er innerhalb der eingestellten Backup-Retention auch nur ein einziges Mal gesichert. Ziel ist es, erstens dafür zu sorgen, dass Read-Only-Daten auch wirklich auf Read-Only-Tablespaces liegen, und zweitens, die Backup-Retention möglichst hoch zu setzen. Um Read-Only-Daten von veränderlichen Daten zu unterscheiden, gilt es, diese auf Segmentebene zu separieren. In einem Data Warehouse muss man daher zwischen Tabellenpartitionen für alte und für neue Daten unterscheiden. Mit Range-Partitionierung ist das kein Problem, sofern man ein Feld als Partitionierungskriterium nutzt, das das Alter der Daten und damit deren angenommene Änderungsrate beschreibt. Dafür lässt sich beispielsweise ein Datumsfeld mit dem Transaktionsdatum einer Buchung verwenden. Aus Erfahrung wissen wir, dass zwanzig Tage nach Monatsabschluss 100 Prozent der Werte des Vormonats fix sind und es demnach keine Transaktionen für den alten Monat mehr geben wird. Wenn man also die Transaktionsdaten monatsweise partitioniert hat und zudem alle Partitionen auf entsprechend monatsgebundene Tablespaces legt, muss man am 20. eines Monats nur noch den Tablespace des Vormonats auf „Read Only“ setzen, ein weiteres Mal sichern, und dann wird er anschließend für viele Monate – eben bis zum Ablauf der Retention – in kein weiteres Backup mehr einfließen müssen. Wir haben es damit geschafft, dass in der Folge nur noch rund 20 Prozent der Datenbank im Regelbetrieb zu sichern sind.
20
Ab Oracle 11g R2 werden Read-Only-Tablespaces ebenfalls regulär im Rahmen eines Backups mit gesichert.
695
15 Große Datenbanken Veränderliche Tablespaces
CO_FACT_SALES
CO_FACT_SALES
August 2009
September 2009
Juli 2009 Juni 2009
Monatsabschluss August
Mai 2009
August 2009 Juli 2009 Juni 2009
April 2009
Mai 2009
März 2009
April 2009 März 2009 Read-Only Tablespaces
Abbildung 15.12: Der Monatsabschluss-Prozess setzt die Tablespaces mit den Fact-Partitionen vom Juli 2009 auf „Read-Only“
Unglücklicherweise ist die Wirklichkeit nicht ganz so elegant, wie es jeder DBA unseres beispielhaften Data Warehouses gerne hätte. Ein gutes Beispiel dafür sind die sogenannten „Late-Arriving-Facts“ (LAF), also die zu-spät-kommenden Bewegungsdaten. Dazu gehören beispielsweise nach zwei Wochen aufgefundene Bestellungen – durchaus möglich, wenn die Extraktion aus den Vorsystemen nicht immer alles findet – oder auch reguläre Messdaten, die ein gepufferter Sensor einen Monat nicht verschicken konnte, weil seine Netzwerkkarte ausgefallen war und erst bei der nächsten regulären Wartung wieder ersetzt wurde. Eine praktikable Möglichkeit, LAFs von regulären Bewegungsdaten zu trennen, ist die Partitionierung nach einem zweiten Kriterium, welches das Zuspätkommen anzeigt. Das kann ein spezielles Flag oder auch einfach nur der Data-Warehouse-Zeitstempel sein, also das Datum, zu dem der Transaktionsdatensatz im Data Warehouse verarbeitet wurde. Veränderliche Tablespaces
CO_FACT_SALES
CO_FACT_SALES
September 2009
LAF89
August 2009
LAF89
Juli 2009
LAF78
Juni 2009
LAF69
LAF89
August 2009
LAF78
Juli 2009
LAF69
Juni 2009
LAF59
Mai 2009
LAF49
April 2009
Mai 2009
LAF59
LAF39
März 2009
April 2009
LAF49
März 2009
LAF39
Monatsabschluss August
Read-Only Tablespaces
Abbildung 15.13: Separate „Late Arriving Facts“-Partitionen zum Aufsammeln (kleiner) Datenmengen, die zu spät geliefert werden. Wichtig: Das Verfahren benötigt keine nachträgliche Reorganisation
696
15.5 Data Warehouses 15.5.2.4 Restore nicht gesicherter Objekte Natürlich dürfen wir den Aufwand zur Wiederherstellung von Datenbank-Strukturen, die beim Backup außen vor bleiben, nicht unterschätzen. Auch diese Objekte müssen beim Restore im Regelfall wiederhergestellt werden – was sowohl Zeit als auch Aufwand bedeutet. Eine Möglichkeit sind logische Backups mittels Datapump, wobei nur die Strukturen, nicht aber Daten ins Backup einfließen. Diese Backups erstellt und aktualisiert sinnvollerweise das Data-Warehouse-Release-Management. Am deutlichsten wird das bei den Indizes – wenn wir uns entscheiden, diese nicht zu sichern, haben wir beim Restore neben dem zusätzlichen Aufwand, die richtigen Indizes wieder zu erzeugen, zudem einen klaren Performance-Nachteil –, denn das Aufbauen von Indizes dauert üblicherweise beträchtlich länger als ein einfacher Restore derselben.
15.5.3 OLAP, ETL und Co. Online Analytical Processing (OLAP) ist ein Begriff aus der Business-Intelligence-Welt. OLAP-Anwendungen – beispielsweise Management Informationssysteme (MIS) – setzen ganz im Gegensatz zu OLTP (Online Transactional Processing)-Anwendungen – wie beispielsweise einem ERP – speziell abfrageorientiert organisierte Daten voraus. Was bedeutet dieser Unterschied im Detail? Betrachten wir das zunächst einmal ganz strikt:
Redundanzen werden gezielt in Kauf genommen. Aggregierte Ergebnisse werden vorausberechnet und separat gespeichert. Daten werden regelmäßig und nur durch dedizierte Prozesse hinzugefügt. Daten werden nie – oder nur in großen, meist zeitbezogenen Tranchen – gelöscht. Daten werden nie oder nur selten und nur innerhalb eines definierten Zeitraumes aktualisiert.
Das einfache, performante Lesen der Daten hat oberste Priorität, und nicht etwa die Manipulierbarkeit, wie in OLTP-Systemen.
nd e
In realen BI-Projekten sind einige dieser Vorgaben nicht ganz so strikt einzuhalten. So können manche Daten – beispielsweise bei Budget-Planungen – durchaus auch mal manuell geändert werden, oder die Vorausberechnung von Ergebnissen wird nur durchgeführt, wenn diese sehr oft gelesen werden und der Performance-Gewinn dadurch erheblich ist.
Ku
Produkt
nz Ko
er n
Umsatz Sales Umsatz YTD Sales YTD ...
Zeit
Abbildung 15.14: Würfel (Cube) mit vier Dimensionen. Die Kanten entsprechen den Dimensionen
697
15 Große Datenbanken Je nach Anforderungen und technischer Umsetzung gibt es unterschiedliche OLAPSpielarten:
Relationales OLAP (ROLAP) Multidimensionales OLAP (MOLAP) Hybrid OLAP (HOLAP) ROLAP beschreibt einfach die Nutzung einer relationalen Datenbank zu OLAP-Zwecken. MOLAP setzt hingegen den Einsatz eines multidimensionalen Datenbanksystems voraus. Hier werden Daten nicht in zweidimensionalen Tabellen in Spalten und Zeilen gespeichert, sondern in mehrdimensionalen „Würfeln“ oder „Cubes“. Dabei werden Kennzahlen wie beispielsweise Umsätze oder Zähler nicht nur auf unterster Ebene, also beispielsweise pro Bestellung, gespeichert, sondern auf jeder Verdichtungsebene (pro Kunde, pro Jahr etc.) wiederholt als Summe oder gemäß einer anderen Aggregatfunktion. So aufbereitet sind oft interaktive Analysen von großen Datenmengen im Mikrosekundenbereich möglich, denn es werden, wo immer möglich, die verdichteten Werte gelesen. Manche Fragestellungen, wie beispielsweise ein COUNT(DISTINCT DIMENSIONS_ID), gruppiert nach vielen anderen Dimensionen, erlauben allerdings keine effiziente Nutzung von Summen-Informationen. Dabei stoßen multidimensionale Datenbanken bei großen Datenmengen auch an ihre Leistungsgrenzen. Hier kommt HOLAP ins Spiel. HOLAP beschreibt das Zusammenspiel zwischen multidimensionalem und relationalem OLAP. So könnte eine MOLAP-Datenbank für spezielle, detailorientierte Abfragen die relational gespeicherten Daten auf einem verbundenen Datenbanksystem nutzen oder umgekehrt eine relationale Datenbank eine SQLAbfrage automatisch auf eine MOLAP-Datenbank mit aufbereiteten Daten umlenken. ETL steht für „Extraktion, Transformation & Load“, also für die zuvor beschriebenen Extraktions- und Befüllprozesse von Data Warehouses. Hier haben sich in den vergangenen fünfzehn Jahren ganz bestimmte Vorgehensweisen etabliert, die sich inzwischen in den zahlreichen grafischen Werkzeugen zur Datenintegration, wie ETL auch gerne genannt wird, niederschlagen. Eines dieser Tools ist bereits Bestandteil der Oracle-Datenbank: der Oracle Warehouse Builder (OWB). Bei der Standard-Installation einer 11g-Datenbank sind sein Repository und einige Prozesse sogar bereits in der per DBCA erzeugten Datenbank installiert. 15.5.3.1 OLAP & Oracle Aus Oracle-Sicht ist OLAP zunächst einmal eine kostenpflichtige Option zur Enterprise Edition. Sie bietet die Möglichkeit, echte multidimensionale Strukturen (Dimensionen mit „Hierarchien“ und „Cubes“) zu definieren und im Datenbanksystem zu speichern. Diese Speicherung erfolgt zwar innerhalb relationaler Tabellen, allerdings in Form von BLOBs in einem proprietären Format – praktisch in einem eigenen multidimensionalen Datenbanksystem innerhalb der Oracle Datenbank. Tabellen mit solchen BLOBs heißen dann Analytic Workspaces (AW). Verwaltet werden die dort abgelegten MOLAP-Daten, -Strukturen und deren Ladeprozesse wahlweise durch den Oracle Warehouse Builder (OWB) oder den Analytic Workspace Manager (AWM) (siehe Abbildung 15.15).
698
15.5 Data Warehouses
Abbildung 15.15: Beispielansicht des Analytical Workspace Managers, Model View
Abbildung 15.16: Erstellen eines Analytical Workspaces mit dem Oracle Warehouse Builder 10g R2
699
15 Große Datenbanken Der Zugriff auf Daten innerhalb eines Analytic Workspace erfolgt durch relationale Views, wodurch jedes SQL-fähige Werkzeug die Möglichkeit hat, von der Oracle OLAP-QueryPerformance zu profitieren. Dazu ein Beispiel mit Analytic Workspace Table: SQL> DESCRIBE aw$myaw; Name Null? ------------------ -------PS# GEN# EXTNUM AWLOB OBJNAME PARTNAME
Typ -----------NUMBER(10) NUMBER(10) NUMBER(8) BLOB VARCHAR2(60) VARCHAR2(60)
15.5.3.2 Hybrid-OLAP & Oracle Seit Oracle 11g besteht zudem die Möglichkeit, Oracle-OLAP-Strukturen als Ersatz oder Ergänzung der altbekannten Materialized Views zu verwenden. Dabei formuliert man SQLs auf ganz normale relationale Tabellen, während der Oracle Optimizer über den Query-Rewrite-Mechanismus die Daten nicht mehr nur aus relationalen, vorverdichteten Ergebnistabellen liest (Materialized Views), sondern aus dem oft deutlich performanteren Analytic Workspace. Diese ganz speziellen Materialized Views werden als Cube-Organized Materialized Views bezeichnet. Die Vorteile gegenüber normalen Materialized Views sind:
Meist reicht ein Analytic-Workspace-Cube anstatt vieler Materialized Views aus, wodurch sich die Administrationsarbeit verringert.
Die Query-Performance bei Nutzung des der Cube-Organized Materialized Views ist konstant gut, während diese bei normalen Materialized Views schwankt. Der Grund dafür ist, dass die Daten im Analytic Workspace automatisch für alle möglichen Verdichtungsebenen erzeugt werden.
Das Laden bzw. der Refresh kann wie bei den normalen Materialized Views automatisiert oder über DBMS_MVIEW.REFRESH erfolgen.
15.5.4 Dimensionen Die von DBAs wie Entwicklern gerne unterschätzten DIMENSIONS sind spezielle, datenlose Strukturen in einer Oracle-Datenbank. Man kann sie in etwa als Definitionen für fachliche Zusammenhänge von Attributen und Hierarchien über mehrere Tabellen hinweg betrachten. Direkt nutzen kann man sie nicht, aber beim Rewrite von Materialized Views unterstützen sie den Query Optimizer und erweitern so die Möglichkeiten für Rewrites. Betrachten wir dazu das Datenmodell in Abbildung 15.17. Die Tabelle SALES beinhaltet die Kennzahlen (= Measures wie Umsatz), die Tabellen CUSTOMERS und PRODUCTS werden gerne als Dimensionen oder Dimensions-Tabellen bezeichnet. Man sollte sie aber keinesfalls mit den Oracle Diemensions verwechseln. COUNTRIES ist eine einfache Tabelle mit Informationen über Staaten. Sie dient als Lookup
700
15.5 Data Warehouses
Times Countries
Sales Customers
Products
Abbildung 15.17: Snowflake-Modell auf Basis des SHDemo-Schemas
für Kunden.21 TIMES schließlich beinhaltet einen Datensatz pro Tag mit zahlreichen Spalten zur Angabe des Monats, des Jahres etc. Wir möchten nun eine Abfrage erstellen, die die Gesamtumsätze für das Jahr 2001 nach Ländern sortiert darstellt. Betrachten Sie dazu die Tabellen SALES, CUSTOMERS und COUNTRIES genauer. Wir reduzieren dabei auf die für unser Beispiel relevanten Spalten: SQL> DESC sales Name Null? ---------------------------------PROD_ID NOT NULL CUST_ID NOT NULL TIME_ID NOT NULL AMOUNT_SOLD NOT NULL
Type -----------NUMBER NUMBER DATE NUMBER(10,2)
SQL> DESC times Name ------------------------TIME_ID CALENDAR_YEAR
Null? -------NOT NULL NOT NULL
Type ------------DATE NUMBER(4)
SQL> DESC customers Name ------------------------CUST_ID CUST_CITY CUST_STATE_PROVINCE COUNTRY_ID
Null? -------NOT NULL NOT NULL NOT NULL NOT NULL
Type ------------NUMBER VARCHAR2(30) VARCHAR2(40) NUMBER
SQL> DESC countries Name ------------------------COUNTRY_ID COUNTRY_NAME COUNTRY_SUBREGION COUNTRY_REGION COUNTRY_TOTAL
Null? -------NOT NULL NOT NULL NOT NULL NOT NULL NOT NULL
Type ------------NUMBER VARCHAR2(40) VARCHAR2(30) VARCHAR2(20) VARCHAR2(11)
Die Abfrage für unsere Aufgabenstellung würde beispielsweise so lauten: SELECT t.calendar_year, co.country_name, sum(amount_sold) FROM sales s, times t, customers cu, countries co WHERE s.time_id = t.time_id AND s.cust_id = cu.cust_id AND
21
Da hier eine normalisierte Kundentabelle verwendet wird – die LOCATIONS-Informationen könnten ja auch redundant als Attribute in der Tabelle CUSTOMERS stehen –, spricht man im Übrigen von einem Snowflake-Schema. Wären die Dimensionstabellen nicht normalisiert, handelte es sich um ein StarSchema.
701
15 Große Datenbanken cu.country_id = co.country_id AND t.calendar_year = 2001 GROUP BY t.calendar_year, co.country_name ORDER BY co.country_name;
Für diese und ähnliche Fragestellung erzeugen wir nun eine Materialized View: CREATE MATERIALIZED VIEW mv_sales_regions ENABLE QUERY REWRITE AS SELECT t.calendar_year, co.country_name, co.country_id, sum(amount_sold) as amount_sold FROM sales s, times t, customers cu, countries co WHERE s.time_id = t.time_id AND s.cust_id = cu.cust_id AND cu.country_id = co.country_id GROUP BY t.calendar_year, co.country_name, co.country_id;
wird übrigens benötigt, damit wir später auch effizient andere Spalten aus der Tabelle COUNTRIES nutzen können. Wenn wir also nun die Abfrage ausführen, erhalten wir folgendes Ergebnis:
COUNTRY_NAME SUM(AMOUNT_SOLD) ---------------------------------------- ---------------Argentina 702.69 Australia 1164870.57 Brazil 5197.89 Canada 859218.21 China 628.89 Denmark 598323.01 France 1025156.84 Germany 2604893.08 Italy 1414260.79 Japan 2157287.05 Saudi Arabia 628.89 Singapore 909996.22 Spain 659288.38 United Kingdom 1674751.85 United States of America 15061257.6
--------------------------------------------------------| Id | Operation | Name | --------------------------------------------------------| 0 | SELECT STATEMENT | | | 1 | SORT ORDER BY | | | 2 | MAT_VIEW REWRITE ACCESS FULL| MV_SALES_REGIONS | ---------------------------------------------------------
Das automatische Umschreiben hat also funktioniert. Was aber, wenn wir nun auf einer anderen Ebene einschränken, also beispielsweise nur noch die Umsätze auf der Regionsebene sehen möchten? SELECT t.calendar_year, co.country_region, sum(amount_sold) FROM sales s, times t, customers cu, countries co WHERE s.time_id = t.time_id AND s.cust_id = cu.cust_id AND cu.country_id = co.country_id AND t.calendar_year = 2001 GROUP BY t.calendar_year, co.country_region ORDER BY co.country_region;
702
15.5 Data Warehouses CALENDAR_YEAR ------------2001 2001 2001 2001 2001
COUNTRY_REGION SUM(AMOUNT_SOLD) -------------------- ---------------Americas 15926376.4 Asia 3067912.16 Europe 7976673.95 Middle East 628.89 Oceania 1164870.57
-------------------------------------------| Id | Operation | Name | -------------------------------------------| 0 | SELECT STATEMENT | | | 1 | SORT GROUP BY | | | 2 | HASH JOIN | | | 3 | TABLE ACCESS FULL | COUNTRIES | | 4 | HASH JOIN | | | 5 | VIEW | VW_GBC_13 | | 6 | HASH GROUP BY | | | 7 | HASH JOIN | | | 8 | TABLE ACCESS FULL| TIMES | | 9 | TABLE ACCESS FULL| SALES2 | | 10 | TABLE ACCESS FULL | CUSTOMERS | ---------------------------------------------
Offensichtlich ist ein Query-Rewrite hier nicht möglich, obwohl die Daten in COUNTRIES das ermöglichen würden, denn hier sind immer ein oder mehrere Länder an eine Region gebunden. Um das aber auch dem Query-Optimizer verständlich zu machen, muss man die Zusammenhänge zwischen der Sales-Tabelle einerseits und der Customers/Countries-Tabellenkombination andererseits bekannt machen. Dafür baut man eine Dimension: CREATE DIMENSION SH.CUSTCOUNTRIES_DIM LEVEL CUSTOMER IS SH.CUSTOMERS.CUST_ID LEVEL COUNTRY IS SH.COUNTRIES.COUNTRY_ID LEVEL REGION IS SH.COUNTRIES.COUNTRY_REGION_ID HIERARCHY REG_ROLLUP ( CUSTOMER CHILD OF COUNTRY CHILD OF REGION JOIN KEY SH.CUSTOMERS.COUNTRY_ID REFERENCES COUNTRY ) ATTRIBUTE COUNTRY LEVEL COUNTRY DETERMINES SH.COUNTRIES.COUNTRY_NAME ATTRIBUTE REGION LEVEL REGION DETERMINES SH.COUNTRIES.COUNTRY_REGION;
Die verschiedenen LEVEL definieren dabei zunächst die Stufen der darzustellenden Hierarchie, die dann in der Klausel HIERARCHY definiert ist. Damit lassen sich auch mehrere Hierarchien erzeugen und so die Level mehrfach verwenden. ATTRIBUTE schließlich ordnet synonyme Spalten den in LEVEL definierten Angaben zu – sodass beispielweise auch eine ID auf einen Namen abgebildet werden kann. Zu beachten ist aber, dass ein Level bzw. ein Attribut nur in einer einzigen Dimension referenziert werden darf. Starten wir die Query nochmals, erhalten wir diesmal folgenden Ausführungsplan: -----------------------------------------------------------| Id | Operation | Name | -----------------------------------------------------------| 0 | SELECT STATEMENT | | | 1 | SORT GROUP BY | | | 2 | MERGE JOIN | | | 3 | TABLE ACCESS BY INDEX ROWID | COUNTRIES | | 4 | INDEX FULL SCAN | COUNTRIES_PK | |* 5 | SORT JOIN | | |* 6 | MAT_VIEW REWRITE ACCESS FULL| MV_SALES_REGIONS | ------------------------------------------------------------
703
15 Große Datenbanken Der Zugriff erfolgt jetzt auch über die Materialized View mit einem Backjoin zu COUNTum die Region darzustellen. Durch den Einsatz komplexerer Dimensionen können somit ganze Familien von Abfragen auf diese Materialized View profitieren.
RIES,
Praxistipp QUERY_REWRITE_INTEGRITY = TRUSTED. Bitte beachten Sie, dass zur Benutzung von Dimensions für Query-Rewrite der Parameter QUERY_REWRITE_INTEGRITY explizit mindestens auf TRUSTED gesetzt sein muss. Dies ermöglicht Oracle, die Integrität der Dimension zu akzeptieren, obwohl sie nicht automatisch geprüft wird. Mit dieser Einstellung wird aber auch anderen Definitionen vertraut, wie beispielsweise eingeschalteten, aber nicht validierten Constraints. Der DBA muss also selbst sicherstellen, dass die Integrität der Daten gewahrt bleibt – sonst sind falsche Ergebnisse nicht auszuschließen.
15.5.4.1 Indexierung im Data Warehouse Die Indexierung kleinerer Tabellen in einem normalisierten Core Data Warehouse folgt im Wesentlichen den Methoden der Indexierung von OLTP-Systemen und soll hier nicht weiter betrachtet werden. Für die Indexierung von sehr großen Tabellen oder generell denormalisierten Strukturen (denormalisiertes Core oder relationale Data Marts) sind jedoch besondere Vorgehensweisen erforderlich. Dazu einige Praxistipps:
Grundsätzlich sollte die Tabelle nach geeigneten Kriterien (beispielsweise Datumsbereiche) partitioniert sein.
Die Indizes sollten, wo immer möglich, lokal partitioniert sein. Somit wird je Partition oder Subpartition einer Tabelle genau ein Indexbaum erstellt. Nach zahlreichen Partition Maintenance Operationen (PMOPs) könnte ein Rebuilt der betroffenen Indizes nötig werden. Viel effizienter und somit schneller ist der Rebuilt eines kompletten Index.
Bitmap Indizes eignen sich prinzipiell besser als normale Indizes zur Indizierung von wenig selektiven Feldern wie beispielsweise den ID-Spalten der Dimensionen in den Faktentabellen. Ein BitmapIndex kann auf ein Feld angelegt und dennoch effizient in Kombination mit anderen Feldern genutzt werden.
Mithilfe der Star-Transformation22 kann der Oracle-Query-Optimizer mehrere BitmapIndizes besonders bei AND-kombinierten Filtern auf Abfragen mit gejointen Fact- und Dimensionstabellen sehr effizient nutzen.
Vor 10g R2 sollten möglichst keine Update- oder Delete-Operationen auf BitmapIndizes angewandt werden. Diese führen zu einem erheblichen Größenzuwachs der Indizes. Ab 10g R2 ist dieses Problem behoben.
Dennoch sollten Bitmap-Indizes – mehr noch als die normalen B-Tree-Indizes – vor Manipulationen an größeren Datenmengen deaktiviert und nach der Operation neu aufgebaut (Rebuild) werden. 22
704
Zur Aktivierung der Star-Transformation muss der Parameter STAR_TRANSFORMATION_ENABLED auf TRUE oder TEMP_DISABLED gesetzt werden. Per Default steht der Wert systemweit auf FALSE.
15.6 Resümee
Bitmap-Join-Indizes erlauben die Indexierung von Dimensionsattributen innerhalb eines Fact-Table-Indizes. Das erlaubt Oracle, bei bestimmten Star-Queries nur den FactTable-Index zu lesen, auch wenn die Abfrage Elemente der Dimensionstabellen beinhaltet. Somit wird die Abfrage deutlich schneller. Generell gilt: Die Komprimierungsrate ist stark von der Art und der Verteilung der Daten abhängig.
Bitmap-Join-Indizes haben den Nachteil, dass sie sehr langsam im Aufbau und bei der Aktualisierung sind (ETL wird langsamer!) und darüber hinaus bei der Aktualisierung zu Table-Locks der beteiligten Dimensionstabellen führen können – daher sollten sie vor einem Einsatz ausführlich getestet werden.
15.6
Resümee Obwohl auf den ersten Blick OLTP- und Data-Warehouse-Datenbanken wenig gemein haben, gibt es doch einige Techniken, die gezielt eingesetzt enorme Vorteile für beide Datenbanktypen bringen können. Jedoch geht dies teilweise einher mit der Implementierung eines optimierten Datenmodells, wie zum Beispiel Partitionierung, Materialized Views oder auch Datenkomprimierung. Hierbei sind immer besondere Administrationstätigkeiten durch den Datenbankadministrator erforderlich. Durch die Möglichkeiten der Parallelverarbeitung kann die Verarbeitung großer Datenmengen maßgeblich beschleunigt werden. Aber auch hier steigt die Komplexität für den DBA durch zahlreiche verfügbare Stellschrauben. Große Datenbanken erfordern daher für einen optimalen Betrieb ein sehr breites und fundiertes technisches Wissen. Ohne dieses Wissen kann man sich schnell in den Tiefen der Oracle Technologien und Features verlaufen.
705
15 Große Datenbanken
706
16 16 Datenbank-Upgrades In diesem Kapitel zeigen wir Ihnen:
die Vorgehensweise für die technische Planung eines Datenbankupgrades; einen Überblick über die wichtigsten Upgrade-Methoden; Best Practices bei einem Datenbankupgrade; einen Überblick über Alternative und komplexere Upgrade-Methoden. Jeder Datenbank-Administrator ist früher oder später mit dem Thema „Upgrade“ konfrontiert. In großen Datenbankbetriebsumgebungen gehören Upgrades sogar zum täglichen Geschäft. Doch wann ist ein Upgrade sinnvoll bzw. wann muss man seine Oracle Software auf den neuesten Stand bringen? Folgende zentrale Gründe können hier zum Tragen kommen:
De-Support der eingesetzten Datenbankversion: Der Premier-Support-Zeitraum ist ausgelaufen. Üblicherweise erstreckt sich dieser über fünf oder sechs Kalenderjahre. Der Extended Support ist nur für Terminal Patch Sets verfügbar (zum Beispiel 9.2.0.8, 10.2.0.5). Critical Patch Updates (CPU) und Patch Set Updates (PSU) sind maximal für die letzten zwei Patch Sets eines Release verfügbar (siehe Abbildung 16.1). Es gibt derzeit drei unterschiedliche Support-Level:
Premier Support: 5 Jahre ab Releasedatum Extended Support: 6. – 8. Jahr ab Releasedatum Sustaining Support: im Anschluss an Premier Support oder Extended Support Der Support beinhaltet folgende Leistungen:
Zugang zu My Oracle Support Technischer Support Software-Update-Service und Bug-Fixes Security Alerts Zertifikation mit Produkten von Drittanbietern Zertifikation mit neuen Oracle-Produkten
707
16 Datenbank-Upgrades
Abbildung 16.1 Oracle Support Lifetime Policy
Kostenersparnis: Neue Funktionalitäten eliminieren/reduzieren die Softwarekosten von Drittanbietern (z.B. Oracle Clusterware, ASM, Oracle Secure Backup, Enterprise Manager Grid Control oder Database Control).
Lizenzoptimierung und Konsolidierung: Neue Funktionalitäten sind in günstigeren Editionen enthalten (zum Beispiel RAC in der Standard Edition), Optimierung der Lizenzkosten durch Datenbankkonsolidierung oder Harmonisierung bzw. Minimierung der Versionsvielfalt.
Sicherheits-Aspekte: Neue Security-Funktionalitäten sind verfügbar (zum Beispiel Groß-/Kleinschreibung von Passwörtern, Database Vault, Verschlüsselung von Tabellenspalten und Tablespaces) oder schlichtweg das Beseitigen von bekannten Security Bugs über Patch Set Updates (PSU) oder Critical Patch Updates (CPU).
Administration: Mehr dynamische oder automatisierte Konfigurationsmöglichkeiten wie Automatisches Memory Management, Automatisches Undo Management oder Rolling Upgrades erleichtern die Administration und den Betrieb der Datenbanken. Aber auch verbesserte Online-Maintenance-Funktionalitäten oder Verbesserungen im Bereich Tuning wie Automatic Database Diagnostic Monitor (ADDM) oder das Automatic Workload Repository können ebenfalls entscheidende Gründe für einen Upgrade liefern.
Alte/neue Bugs und Fixes: Durch einen gezielten Upgrade auf ein aktuelles Release kann man das aufwendige Einspielen zahlreicher Patches umgehen. Auf diese Weise lassen sich auch bisher nicht aufgetretene aber potenzielle Bugs vermeiden.
Funktionalitäts- und Performanceverbesserungen: Einführung neuer Funktionalitäten, die gleichzeitig auch performantere Konzepte mit sich bringen, wie zum Beispiel neue Partitioning-Methoden, SecureFiles, Result Cache, dynamisches SQL oder Virtual Columns. Hier ist oft die Applikation der treibende Faktor.
Zertifizierungsvorgaben durch Hardware, Betriebssystem oder Applikation: Hardware wird normalerweise nicht durch Oracle zertifiziert, nur die unterschiedlichen Betriebssysteme. Die Betriebssystemhersteller zertifizieren die einzelnen Hardware-
708
16.1 Generelle Rahmenbedingen Plattformen. Ausnahmen gibt es im Bereich Interconnect-Protokolle und Hardware in Verbindung mit RAC oder NFS Devices (z.B. NetApp Filer). Oracle zertifiziert Datenbankversionen gegen die unterschiedlichen Betriebssystem-Releases wie zum Beispiel HP-UX Itanium, Sun Solaris SPARC oder Windows 2008 (x86)1.
16.1
Generelle Rahmenbedingen Unabhängig davon, welche der oben aufgeführten Gründe letztendlich ausschlaggebend sind, gilt es immer ein bevorstehendes Datenbankupgrade sorgfältig zu planen und entsprechend technisch vorzubereiten. Hierbei sind immer gewisse Rahmenbedingungen vorab zu klären.
Festlegen der Oracle Zielversion: Bestimmung des Terminal-Patch-Sets2 oder des letzten aktuellen Patch Sets einer potenziellen Zielversion.
Zertifizierung der Applikationen: Prüfung der notwendigen Applikationsversionen und eventuell davon abhängige Versionen der Middleware.
Wartungsfenster festlegen: Evaluierung der Dauer der möglichen Ausfallzeiten. Diese beeinflusst entscheidend die zu wählende Upgrade-Strategie. Ebenso elementar ist das Festlegen der Fallback-Szenarien und damit einhergehend die maximal mögliche Fallback-Dauer.
Abstimmung der Hardware-Voraussetzungen: Hierzu gehört die Prüfung der Vorgaben für die neue Oracle-Zielversion bezüglich des Hauptspeicherbedarfs (RAM), der CPU-Kapazität, des Plattenplatzes (Datenbanken und Software) auf Basis der relevanten „My Oracle Support“-Notes. Ebenso wichtig ist die Festlegung der Eigenschaften des Zielrechners, ob beispielsweise ein Plattformwechsel durchgeführt oder die Datenbank auf einen neuen, stärkeren Rechner umgezogen werden soll.
Abstimmung der Software-Voraussetzungen: Hierzu gehören Prüfungen der Betriebssystemvoraussetzungen bezüglich vorgeschriebener Versionen und Patches, die korrekte Konfiguration der Kernelparameter (Semaphoren, Shared-Memory, openfiles, maxuserproc etc.), optional die Nutzung neuer Filesysteme oder Clusterpackages und ein eventuell erforderlicher Wechsel von 32-Bit- auf 64-Bit-Betriebssystemversionen. In solchen Fällen empfiehlt sich eine genaue Recherche über My Oracle Support und ein sorgfältiges Studieren der zugehörigen Upgrade-Dokumentation. Haben wir uns intensiv mit den oben aufgeführten Fragestellungen beschäftigt, die nötigen Rahmenbedingungen abgesteckt und entsprechend unseren individuellen Anforderungen gewichtet, können wir beruhigt in die nächste Phase, die Technische Planung und Vorbereitung des/der bevorstehenden Upgrades, übergehen.
1
Eine detaillierte Aufstellung der Zertifizierungsmatrix für Oracle-Produkte ist in Oracle My Oracle Support Reiter „Certifications“ einsehbar. 2 Finales Patch-Set für ein Release.
709
16 Datenbank-Upgrades
16.2
Technische Planung Generell gilt, je penibler man die Planung durchführt und testet, desto verlässlicher und sicherer ist der Upgrade-Erfolg. Ein fehlgeschlagener Upgrade kann ein Vielfaches an Zeit beanspruchen, als in der Planungsphase für ein sorgfältiges Vorgehen investiert wurde − ganz zu schweigen von potenziell zusätzlichen Ausfallzeiten, die bei kritischen Applikationen umso mehr schmerzen. Daher ist aus DBA-Sicht hier besondere Aufmerksamkeit und Sorgfalt angebracht. Oracle hat im Verlauf der einzelnen Datenbankreleases viel Zeit und Mühe in die Optimierung der technischen Unterstützung bei Datenbanksoftware-Upgrades investiert. Mittlerweile gibt es zahlreiche, sehr gute „My Oracle Support“-Notes zu diesem Thema wie Upgrade-Checklisten („Manual Upgrade Checklisten“ für 10g und 11g) sowie UpgradeCompanions für 10g und 11g. Ebenso steht über Oracle Tech Net (OTN) eine OracleUpgrade-Seite inklusive Diskussionsforum zur Verfügung. Die verschiedenen versionsabhängigen Upgrade-Guides sind als vorbereitende Lektüre ebenfalls zwingend notwendig. Oracle und andere Anbieter veranstalten zum Thema Upgrade spezielle Roadshows und vermitteln hier ihre Praxiserfahrung. Sie können auch einen Consultant Ihres Vertrauens für die gewünschte Unterstützung auswählen. Nutzen Sie ausgiebig die Vielzahl der verfügbaren Informationsquellen für Ihre Vorbereitung!
Abbildung 16.2 „Oracle Tech Net“-Homepage für das 11g-Datenbank-Upgrade
710
16.2 Technische Planung Praxistipp Typische Upgrade-Problematiken sind beispielsweise Schnittstellenprobleme wie nicht funktionierende Datenbank-Links, Clients, die sich aufgrund von Inkompatibilitäten der Client-Software und der Datenbank nicht mehr an die Datenbank verbinden können, sowie Performance-Probleme. Aber auch hier gibt es inzwischen ab 11g R1 neue Funktionalitäten wie Real Application Testing (Database Replay und SQL Performance Analyzer), die Sie bei gezielten Workload-Tests Ihrer Datenbank und der gesamten Applikation effizient unterstützen.
Folgende generelle Schritte sollten im Rahmen eines geplanten Upgrades und der Risikominimierung stets durchlaufen werden: Migrationsplanung 1. Vorbereitung Mit den neuen Features der Zielversion durch Oracle Dokumentation, My Oracle Support, OTN, Veranstaltungen und Schulungen vertraut machen. Die Rahmenbedingungen bestimmen. Eine passende Upgrade-Methode auswählen. Die gewählten Vorgehensweise inklusive detailliertem Testplan mit Testszenarien für die Datenbank, sowie aller relevanten Applikationen und Schnittstellen dokumentieren. Risiken sorgfältig erfassen und bewerten. Eine geeignete Backup- und Fallback-Strategie auswählen. Performance-kritische Applikationsteile identifizieren und Basis-Messungen durchführen. 2. Upgrade Tests Das neue Software-Release in einem eigenen Oracle-Home-Verzeichnis installieren. Ein Testupgrade auf einer adäquaten Testumgebung durchführen. Das spätere Produktionsupgrade verifizieren. Alle Komponenten der neuen Datenbank inklusive aller Applikationsteile und Schnittstellen unter Miteinbeziehung der Applikationsuser sorgfältig testen. Das Fallback-Szenario ebenfalls testen und dokumentieren. Messungen von kritischen Applikationsteilen vor und nach dem Upgrade vergleichen. Geeignete Korrekturen der festgestellten Problemfelder durchführen und dokumentieren. Tests wiederholen, bis ein zufriedenstellendes Ergebnis für den Produktionsupgrade erreicht ist. 3. Vorbereiten des Produktionsupgrade Die Produktionsdatenbank auf Basis der Erkenntnisse aus den Upgrade-Tests vorbereiten. Die nötige Downtime für Backup und den eigentlichen Upgrade-Vorgang festlegen.
711
16 Datenbank-Upgrades
Ein geeignetes Backup der Produktionsdatenbank durchführen. Datenverlust im Ernstfall vermeiden. 4. Upgrade der Produktionsdatenbank Das eigentliche Upgrade gemäß der erstellten Planung durchführen. Nach erfolgreichem Upgrade erneut ein Backup und nötige Abschlussarbeiten durchführen. Die korrekte Arbeitsweise der Datenbank und Applikation durch erneute Usertests verifizieren. 5. Tuning und Korrekturen Vor allem während der ersten Betriebszeit mit der neuen Datenbankversion auf unerwartete Störungen achten. Hier ist es wichtig, schnell und effizient bei Performance-Problemen eingreifen zu können. Ein Spezialisten-Team für hochkritische Applikationen einige Zeit zur Nachbetreuung in erhöhter Bereitschaft stellen, das gegebenenfalls schnell handeln kann. In den normalen Betrieb übergehen. Praxistipp Wichtige Informationen zum Thema Datenbank STARTUP UPGRADE
11. Start des Upgrade-Skripts. Prüfen Sie das erstellte Spool-File nach Fehlermeldungen. SQL> SPOOL $ORACLE_BASE/admin/DB1020A/log/upgrade_DB1020A.log SQL> @?/rdbms/admin/catupgrd.sql SQL> SPOOL OFF
12. Der wichtigste Teil des Datenbank-Upgrades ist nun beendet. Starten Sie nun die Datenbank und führen Sie das Skript utlu112s.sql zur Prüfung des Upgrade Status aus. Es gibt den jeweilige Status und die zugehörige Upgrade-Zeit aus: SQL> @utlu112s.sql . Oracle Database 11.2 Post-Upgrade Status Tool . Component Status . Oracle Server . VALID JServer JAVA Virtual Machine . VALID Oracle Workspace Manager . VALID OLAP Analytic Workspace . VALID OLAP Catalog . VALID Oracle OLAP API . VALID Oracle Label Security . OPTION OFF Oracle Enterprise Manager . VALID Oracle XDK . VALID Oracle Text . VALID Oracle XML Database . VALID Oracle Database Java Packages . VALID Oracle Multimedia . VALID Spatial . VALID Oracle Expression Filter . VALID Oracle Rules Manager . VALID . VALID Gathering Statistics . Total Upgrade Time: 00:40:43
726
04-23-2011 05:07:00 Version
HH:MM:SS
11.2.0.2.0
00:13:45
11.2.0.2.0
00:03:47
11.2.0.2.0
00:00:48
11.2.0.2.0
00:00:40
11.2.0.2.0
00:01:29
11.2.0.2.0
00:00:37
11.2.0.1.0
00:00:00
11.2.0.2.0
00:03:44
11.2.0.2.0
00:00:41
11.2.0.2.0
00:00:41
11.2.0.2.0
00:02:40
11.2.0.2.0
00:00:24
11.2.0.2.0
00:04:33
11.2.0.2.0
00:01:16
11.2.0.2.0
00:00:12
11.2.0.2.0 3.2.1.00.10
00:00:13 00:05:02
16.7 Downgrade 13. Nun folgt die Durchführung weiterer Data-Dictionary-Upgrades, die jedoch die Datenbank nicht im Upgrade-Mode erfordern. SQL> @?/rdbms/admin/catuppst.sql
14. Wahlweise können Sie danach in einer separaten oder in einer parallelen Session die Rekompilierung der PL/SQL- und Java-Objekte anstoßen. SQL> @?/rdbms/admin/utlrp.sql
15. Zum Abschluss fallen noch Upgrade-Nacharbeiten an: Passen Sie den Oracle-HomeParameter der Listener.ora-Datei für die aktualisierte Datenbank an. Starten Sie den Datenbank-Listener erneut. Konfigurieren Sie gegebenenfalls Fine Grained Access für externe Netzwerk-Services, schalten Sie die Passwörter „case sensitive“, migrieren Sie gegebenenfalls Daten des Typs TIMESTAMP with TIMEZONE mithilfe des Packages DBMS_DST oder führen Sie die Enterprise-Manager-Konfiguration durch. Jetzt steht die Datenbank in der Version 11.2.0.2 für den Betrieb bereit.
16.7
Downgrade Selbst bei der sorgfältigsten Vorbereitung eines Upgrades kann es vorkommen, dass aus irgendwelchen Gründen ein sauberer Datenbankbetrieb unter der neuen Version nicht möglich ist. Spätestens jetzt stellt sich die Frage: Wie komme ich am schnellsten wieder zurück auf meine ursprüngliche Datenbankversion? Eine Möglichkeit besteht darin, die Datenbank wieder unter der alten Version aufzubauen (Separate Installation des vorigen Releases) und die Daten über das Export/Import-Utility wieder zurückzuimportieren. Je nach Datenbankgröße kann dies unter Umständen sehr lange (einige Tage) dauern. Während dieser Zeit steht die Datenbank produktiv nicht zur Verfügung. Selbstverständlich gibt es bei Oracle auch die Möglichkeit, ähnlich wie bei einem manuellen Upgrade die Datenbank wieder auf das frühere Release zurückbringen. Hierfür sind allerdings einige Voraussetzungen zu beachten: Die Funktionalitäten des neuen Releases wurden noch nicht benutzt. Das heißt, der Konfigurationsparameter COMPATIBLE steht noch auf dem Wert der Ursprungsversion. Downgrades sind prinzipiell auf die Basis.Releases 11.1.0.6, 10.2.0.2 oder 10.1.0.5 möglich. Patchset-Downgrades sind auf den vorherigen Patchstand des zuletzt eingespielten Patchsets möglich. Enterprise Manager-Database-Control-Downgrades sind nicht möglich. Für einen Downgrade sind folgende Schritte erforderlich:
Prüfen Sie den Parameter COMPATIBLE. Dieser darf keinesfalls auf dem Wert des aktuell neuen Releases stehen. Ein Downgrade auf die Version 9.2 ist generell nicht mehr möglich. Erstellen Sie vor dem Downgrade ein Full-Backup der Datenbank. Stoppen Sie, falls vorhanden, das Enterprise-Manager-Database-Control-GUI: ORACLE_HOME/bin/emctl stop dbconsole
727
16 Datenbank-Upgrades
Stoppen Sie die Datenbank und starten Sie diese wieder im Downgrade-Modus: SQL> SHUTDOWN IMMEDIATE SQL> STARTUP DOWNGRADE
Jetzt erfolgt der eigentliche Downgrade des Data Dictionaries. Hierzu wird unter dem User SYS das Downgrade-Skript catdwngrd.sql ausgeführt. Da ein Enterprise Manager Downgrade nicht möglich ist, müssen Sie zuvor den Datenbankuser SYSMAN löschen. Benutzen Sie immer das catdowngrd.sql-Skript aus Ihrer aktuellen Installation, in diesem Fall das entsprechende Skript der Datenbankversion 11.2.0.2: SQL> SQL> SQL> SQL>
DROP USER sysman CASCADE; SPOOL $ORACLE_BASE/admin/DB1120A/scripts/downgrade_DB1120A.log @?/rdbms/admin/catdowngrd.sql SPOOL OFF
Sollten während des Downgrades Fehler auftreten, beheben Sie diese und starten Sie das catdowngrd.sql-Skript erneut. Es ist beliebig oft ausführbar.
Nach erfolgreicher Ausführung fahren Sie die Datenbank herunter: SQL> SHUTDOWN IMMEDIATE
Für Microsoft-Windows-Systeme ist der Service-Eintrag der Datenbank zu löschen und unter der Angabe des alten Oracle-Home-Verzeichnisses wieder zu erstellen.
Für Unix und Linux-Systeme wird nun wieder das alte Oracle-Home Verzeichnis in die oratab-Datei
eingetragen. Das oraenv-Utility setzt nun die korrekten Umgebungsvari-
ablen.
Falls sich die zugehörige Spfile- und Passwortdatei nicht mehr im ursprünglichen Oracle-Home Verzeichnis befinden, sind diese wieder aus Ihrer Sicherung zurückzuspielen. Optional können Sie diese Dateien auch wieder neu anlegen. Bei einer geclusterten Datenbank muss der Initialisierungsparameter cluster_database=FALSE gesetzt sein.
Nun wird die Datenbank unter dem alten Oracle-Home-Verzeichnis im Upgrade-Modus hochgefahren und das catreload.sql-Skript ausgeführt. SQL> SQL> SQL> SQL>
STARTUP UPGRADE SPOOL $ORACLE_BASE/admin/DB1120A/scripts/reload_DB1120A.log @?/rdbms/admin/catreload.sql SPOOL OFF
Anschließend erfolgt ein Stoppen und erneutes Starten der Instanz. Im nächsten Schritt werden alle ungültigen Objekte neu kompiliert. Bei einer RAC-Datenbank sollten Sie nun den Initialisierungsparameter cluster_database=TRUE setzen. SQL> SHUTDOWN IMMEDIATE SQL> STARTUP SQL> @?/rdbms/admin/utlrp.sql
Nun ist der Downgrade Ihrer Datenbank erfolgreich vollzogen und Ihre Datenbank arbeitet wieder mit der früheren Softwareversion.
728
16.8 Patchset 11.2.0.2 Out-Of-Place-Upgrade
16.8
Patchset 11.2.0.2 Out-Of-Place-Upgrade Ab der Version 11.2.0.2 sind die ausgelieferten Datenbank-Patchsets sogenannte „Vollinstallationen“ der Datenbanksoftware. Dies bedeutet, dass nicht wie früher z.B. zuerst das Oracle Basis-Release 10.2.0.1 und anschließend das Patchset 10.2.0.4 zu installieren ist, sondern direkt die Version 11.2.0.2 als Vollversion in ein neues Oracle Home. Nach erfolgreicher Software-Installation werden die Daten der Datenbank aus dem alten OracleHome-Verzeichnis über den Upgrade-Prozess in die Datenbank des neuen Oracle-HomeVerzeichnisses migriert. Diese Vorgehensweise nennt man einen Out-Of-Place-Upgrade. Oracle empfiehlt diese ausdrücklich. Der eigentliche Upgrade-Prozess gestaltet sich wie in Abschnitt 16.5 „Database Upgrade Assistant“ mithilfe des DBUA oder wie in Abschnitt 16.6.1 „Manueller Upgrade im Detail“ beschrieben ist. Prinzipiell ist aber auch jede andere Upgrade-Methode anwendbar. Die Vorteile eines Out-Of-Place-Upgrades sind:
Neue Software-Installationen sind auf dem neuesten Patchstand. Es sind direkte Upgrades von einem vorigen Release auf den aktuellsten Patchstand möglich. Dadurch entsteht weniger Ausfallzeit während der Patchset-Installation.
Es gibt mehr Sicherheit bei einem etwaigen Abbruch während eines Installationsvorgangs. Vor allem in großen Datenbankumgebungen kann sich nachteilig auswirken, dass zeitweise mehr Plattenplatz notwendig ist, denn es sind temporär zwei Vollinstallationen der Oracle 11.2 Software (Oracle 11.2.0.1 und Oracle 11.2.0.2) vorzuhalten.
16.9
Patchset 11.2.0.2 In-Place-Upgrade Obwohl Oracle das In-Place-Upgrade ab dem Patchset 11.2.0.2 nicht mehr ausdrücklich empfiehlt, kann es in manchen Fällen trotzdem sinnvoll sein. Beim In-Place-Upgrade wird die neue Datenbanksoftware in dasselbe Oracle-Home des bisherigen Softwareverzeichnisses installiert. Die neue Softwareversion ersetzt die bisherige, was eine etwas andere Vorgehensweise bei der Softwareinstallation erfordert. Es sind einige manuelle Zusatzschritte nötig. Die Vorteile eines In-Place-Upgrades sind:
Es ist weniger Plattenplatz notwendig. Bei Windows Plattformen müssen die bisherigen Service-Einträge nicht gelöscht und neu angelegt werden.
Bei Unix/Linux-Plattformen ist keine die Anpassung der Environment-Variablen erforderlich. Nachteilig wirkt sich aus, dass wir vor der eigentlichen Software-Installation des neuen Releases den kompletten oder zumindest bestimmte Verzeichnisse aus dem Softwarebaum des vorigen Releases in ein separates Verzeichnis sichern müssen. Dies macht den gerade
729
16 Datenbank-Upgrades erwähnten Vorteil der Einsparung des Plattenplatzes wieder hinfällig. Auch die übrigen erwähnten Vorteile sind nicht gerade bahnbrechend.
16.9.1 Vorgehensweise In-Place-Upgrade 1. Sichern der folgenden Dateien aus den Verzeichnissen des bisherigen Releases:
ORACLE_HOME/dbs (Windows: ORACLE_HOME/database). In diesem Verzeichnis sind die Konfigurationsdateien init.ora, Spfile und die Passwortdatei abgelegt.
ORACLE_HOME/network/admin. Dieses Verzeichnis beinhaltet die Konfigurationsdateien Listener.ora, Sqlnet.ora und Tnsnames.ora. ORACLE_HOME/hostname_dbname. Dieses Verzeichnis enthält die Konfigurationsdateien des Enterprise Managers. ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname. In diesem Verzeichnis liegen die OC4J/J2EE-Konfigurationen des Enterprise Managers. 2. Löschen der bisherigen Softwareversion (11.2.0.1) aus dem Oracle Inventory: ORACLE_HOME/oui/bin/runInstaller -detachHome ORACLE_HOME=11.2.0.1.0 software
3. Sichern des bisherigen Oracle Softwareverzeichnisses: mv ORACLE_HOME ORACLE_HOME_save
4. Herunterladen der neuesten Datenbank-Softwareversion über das „My Oracle Support“Tool. 5. Deinstallieren der bisherigen Softwareversion (11.2.0.1) über den Oracle Universal Installer und Bereinigen des Oracle Inventories 6. Installieren der neuen Softwareversion 11.2.0.2 in dasselbe Verzeichnis über den OUI und der Option „software only“. Achtung: Hier können eventuell später Verwirrungen entstehen, wenn Sie Ihre OFA-Struktur vier- oder fünfstellig aufgebaut haben. Möglich wäre, dass Sie z.B. in einem 11.2.0.1-Home-Verzeichnis nun die 11.2.0.2-Software installieren und betreiben. Dieses Konzept hebelt Ihre standardisierten Namenskonventionen aus. 7. Zurückkopieren der zuvor gesicherten Dateien in das nun aktualisierte Oracle-HomeVerzeichnis (jetzt Version 11.2.0.2):
ORACLE_HOME/dbs (Windows: ORACLE_HOME/database). ORACLE_HOME/network/admin ORACLE_HOME/hostname_dbname ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname 8. Auswählen der zu aktualisierenden Datenbank über den DBUA. Es erfolgt nun der eigentliche Upgrade-Prozess. 9. Prüfen der Log-Files und Inbetriebnahme der Datenbank.
730
16.10 Best Practices Datenbank-Upgrade Diese Vorgehensweise beinhaltet ein paar zusätzliche Schritte im Vergleich zu einem OutOf-Place-Upgrade. Da es sich hierbei um manuelle Eingriffe handelt, ist auch das grundsätzliche Fehlerpotenzial etwas höher.
16.10 Best Practices Datenbank-Upgrade Bevor wir uns den alternativen Upgrade-Techniken widmen, folgen noch einige, vielleicht banale Tipps für einen erfolgreichen Datenbank-Upgrade:
Nochmal ausdrücklich der Hinweis: Lesen Sie ausgiebig die vorhandene Dokumentation (Database Upgrade Guide, plattformspezifischer Oracle Installation Guide, „My Oracle Support“-Notes, OTN Datenbank-Webseiten).
Abbildung 16.9 Upgrade Companion Oracle 11g R2
Bringen Sie Ihr neues Oracle-Home-Verzeichnis vor dem Upgrade auf den neuesten Patchstand. Für die Patchset Installation 11.2.0.2 ist ein Out-of-Place-Upgrade empfohlen.
Installieren Sie die aktuellen Patch Set Updates (PSU). Datenbank PSU’s beinhalten Fixes für kritische Fehler, die eine große Anzahl Kunden betreffen können und die vor allem schon ausgiebig im Feld getestet wurden. Der Patch Set Update ist kumulativ. Typischerweise werden diese PSUs viermal pro Jahr bereitgestellt.
731
16 Datenbank-Upgrades
Abbildung 16.10 Oracle Recommended Patches
Prüfen Sie über das „My Oracle Support“-Tool die relevanten Notes (Konkret für Oracle Database 11gR2 und das Patch Set 11.2.0.2: “Support Status and Alerts for Oracle 11gR2”, “Known Issues specific to the 11.2.0.2 Patch Set” und “OS Installation and Configuration”).
Sammeln Sie proaktiv Performance-Statistiken. Damit sind Performance-Vergleiche der kritischen Applikationsteile (SQL-Statements, Batchprozesse etc.) vor und nach dem Upgrade möglich. Ebenso können Performance-Tests mithilfe der Real-Application-Testing-Option (SQL Performance Analyzer, Database Replay) anhand von echten Produktionsworkloads durchgeführt werden. Ein ausreichendes Zeitfenster für Performance-Daten bedeutet mindenstens vier Wochen vor dem eigentlichen Upgrade. Datenbank-Performancedaten können entweder über STATSPACK (Oracle 8i/Oracle 9i, Oracle Database Standard Edition 10g/11g) oder natürlich über die AWR-Funktionalität (Automatic Workload Repository) gesammelt werden.
Führen Sie folgende Sicherheitsprüfungen vor dem eigentlichen Upgrade durch: Prüfen Sie die Datenbank nach ungültigen Objekten. Keinesfalls sollten im Schema SYS oder SYSTEM invalide Objekte vorhanden sein; gegebenenfalls mit dem Skript utlrp.sql alle Datenbankobjekte nochmals kompilieren. Löschen Sie vor dem Upgrade die Inhalte des Recyclebins (Oracle 10g oder Oracle 11g) mit folgendem Befehl: SQL> purge DBA_RECYCLEBIN
Benutzen Sie immer das passende Pre-Upgrade-Skript. Für einen geplanten Upgrade auf Oracle Database 11g R2 führen Sie das Skript utlu112i.sql aus und analysieren Sie das Ergebnis. Führen Sie die notwendigen Anpassungen vor dem eigentlichen Datenbankupgrade aus. Verwenden Sie immer das passende Script utlu1nni.sql in Abhängigkeit der Software-Zielversion. Prüfen Sie hierzu die “My Oracle Support”Note „How to Download and Run Oracle's Database Pre-Upgrade Utility”.
Entfernen Sie nicht mehr unterstützte Konfigurations-Parameter, Underscore-Parameter sowie Events aus Ihren Init.ora- und Spfile.ora-Dateien.
732
16.10 Best Practices Datenbank-Upgrade
Belassen Sie den COMPATIBLE6-Parameter, wenn möglich, für eine Zeit auf dem alten Wert, bevor Sie ihn auf 11g R2. anpassen. Sobald Sie den COMPATIBLE-Parameter hochgesetzt haben, gibt es kein Zurück mehr. Ein direkter Downgrade mittels catdwgrd.sql ist dann nicht mehr möglich. Andere Fallbackstrategien wie z.B. Export/ Import sind dann erforderlich.
Testen Sie Ihre Fallback-Strategie. Führen Sie in jedem Fall ein Datenbank-Backup durch. Stellen Sie sicher, dass Ihre gewählte Fallback-Strategie folgende Problemfelder abdeckt: Schwerwiegende Probleme während des Upgrade-Prozesses sowie schwerwiegende Probleme, die nach ein paar Tagen oder Wochen auftreten können. Ebenfalls ist vorab zu klären, ob Sie bei schwerwiegenden Problemen notfalls einen Datenverlust in Kauf nehmen können. Dies alles bestimmt letztlich die möglichen Fallbackstrategien (Restore Backup, Flashback oder Export/Import, Downgrade per Script etc.)
Post-Upgrade-Aktivitäten: Sammeln Sie System-Statistiken während einer typischen Workload-Periode. Somit entstehen zusätzliche I/O-relevante Statistiken für den Cost Based Optimizer: exec DBMS_STATS.GATHER_SYSTEM_STATS('start'); -- Systemstatistiken sammeln während eines typischen Datenbanworkloads exec DBMS_STATS.GATHER_SYSTEM_STATS('stop'); SQL> select pname, pval1, pval2 from sys.aux_stats$; PNAME PVAL1 PVAL2 ------------------------------ ---------- ---------------STATUS COMPLETED DSTART 04-21-2011 14:06 DSTOP 04-21-2011 14:36 FLAGS 0 CPUSPEEDNW 909.137 IOSEEKTIM 9.021 IOTFRSPEED 4096 SREADTIM 83556.196 MREADTIM 90194.871 CPUSPEED 853 MBRC 10 MAXTHR 5512192 SLAVETHR
Post-Upgrade-Aktivitäten: Sammeln Sie Statistiken für die Oracle Fixed Tables.7 Bei der manuellen Upgrade-Methode generieren Sie diese Statistiken direkt nach dem catDadurch wird das Rekompilieren mit Hilfe des utlrp.sql-Skripts deutlich beschleunigt: upgrd.sql-Skript.
SQL> exec DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
6
Der COMPATIBLE-Parameter steuert die Feature-Aktivierung des neuesten Releases, Anpassung der Datenfileheader und die Anpassung der Redologfiles während des ersten Zugriffs. Dieser Parameter ist statisch, d.h. die Datenbank muss für eine Aktivierung durchgestartet werden. 7 Fixed Tables sind keine echten Tabellen, sondern interne Oracle Tabellen. Fixed Tables sind direkt im Oracle Source-Code definiert und basieren auf den C-Strukturen des Oracle Kernels. Sie können nicht verändert werden.
733
16 Datenbank-Upgrades Sammeln Sie nach einer bestimmten Zeitperiode eines typischen Datenbank-WorkloadZyklus (z.B. nach einer Woche) wieder Fixed-Table-Statistiken. Wiederholen Sie dies von Zeit zu Zeit.
16.11 Alternative Upgrade-Methoden Oracle bietet zusätzlich alternative Upgrade-Methoden an. Diese eignen sich für eine Characterset-Konvertierung8 oder auch für einen Betriebssystem-Plattformwechsel. Auf den folgenden Seiten werden wir diese verfügbaren Methoden kurz beleuchten und bewerten.
16.11.1 Original Export-und-Import-Utilities (exp/imp) Die Nutzung des Original Export-Utilities ist offiziell nur bis Oracle Database 10g R2 unterstützt. Allerdings werden die Original Export/Import-Utilities aus Gründen der Abwärtskompatibilität immer noch mit Oracle 11g R2 ausgeliefert und lassen sich somit auch nutzen. Dies ermöglicht Upgrades via Nutzung des Import-Utilities ab Version 5. Benutzen Sie für den Export immer die Utility-Version der Quelldatenbank und für den Import der Daten die Import-Utility-Version der Zieldatenbank. Die Vorteile des Original Export/Import-Utilities in aller Kürze:
Nicht gerade schnell, aber robust und zuverlässig Nutzbar für Zeichensatz-Konvertierungen, Plattformwechsel, Schema-Konsolidierung und Unterstützung von nicht direkten Upgrade-Pfaden (wie Upgrade von Version 8.1.5 nach Version 11.2.0.2)
Unabhängig von Quelldatenbank-Patchständen oder Time-Zone-Patches Praxistipp Übertragen Sie die Dumpfiles immer im Binary Mode. Full-Database-Exports immer als User SYSTEM durchführen. Grants auf Sysobjekte sind separat zu exportieren. Der Import dauert in der Regel immer dreimal länger als der Export der Daten. Erhöhung der Export Performance über den Parameter DIRECT=Y. Dies umgeht das SQL-Layer, aber nicht die Konvertierungen. Steigerung der Import-Performance Den Parameter BUFFER (Default 4096) erhöhen Den Parameter INDEXES=N setzen. Erstellen Sie die Indizes später parallel anhand eines zuvor erstellten Indexfiles.
8
734
Datenbankweite Zeichensatz-Konvertierung beispielsweise von WE8ISO8859P1 in WE8ISO8859P15 zur Darstellung des Euro-Zeichens.
16.11 Alternative Upgrade-Methoden
Abbildung 16.11 Übersicht Befehlssyntax der Original Export-Utility 11.2.0.2
16.11.2 Export und Import mittels Data Pump Data Pump ist der Nachfolger der Original Export/Import-Utilities und ab 10g R1 in der Datenbank-Distribution enthalten. Data Pump bietet maximale Performance für Entladeund Ladevorgänge von Daten. Es arbeitet serverbasiert, das bedeutet, dass Dump-Dateien über ein Datenbank-Directory auf dem Server abgelegt werden. Data Pump unterstützt folgende Export Modi:
Full Export Schema Table Transportable Tablespace Die neue Architektur und interne Prozesstruktur ermöglichen eine Reihe von zusätzlichen Funktionalitäten im Vergleich zum bisherigen Original Export/Import-Utility. Dazu einige erweiterte Funktionalitätsbeispiele:
Performance: Parallelisierung beim Entlade- und Ladevorgang (Parameter
PARALLEL,
nutzbar für Oracle Enterprise Edition)
Restart-Fähigkeit: Ein Entlade- oder Ladevorgang kann unterbrochen und wieder gestartet werden, ohne dass man die gesamten Daten erneut entladen oder laden muss.
SQL-WHERE-Klausel: Eine WHERE-Klausel schränkt die Daten eines Entlade- oder Ladevorgangs ein.
735
16 Datenbank-Upgrades
Abbildung 16.12 Überblick DataPump-Komponenten
Export/Import über Network-Link: Über einen Datenbank-Link lassen sich Daten direkt aus einer Quelldatenbank in eine Zieldatenbank importieren. Bei einem Export wird auf dem Server, auf dem der Export über Network-Link gestartet wurde, das Dumpfile erstellt. Achtung: Es gelten Einschränkungen bzgl. Datentypen für Datenbank-Links: LONG, LONG RAW oder Objektypen werden nicht übertragen.
Komprimierung der Dumpfiles: Während des Exports gibt es verschiedene Komprimierungslevel (METADATA_ONLY, DATA_ONLY, ALL). Dies erfordert allerdings die AdvancedCompression-Option der Oracle Enterprise Edition.
Parameter REMAP_DATA: Selbsterstellte PL/SQL-Funktion können Daten während eines Entlade- oder Ladevorgangs verändern, z.B. für eine Anonymisierung der Daten.
Data-Pump-Legacy-Mode: Über die Rückwärtskompatibilität für Original Export/Import-Skripte ab Oracle Database 11g R2 kann Data Pump auch die alte Original Export/ Import-Syntax verstehen, intern übersetzen und so Data-Pump-Dumpfiles zur weiteren Nutzung erstellen.
GUI-Integration über Enterprise Manager Die wesentlichen Vorteile von Data Pump:
Schnell und performant für sehr große Datenmengen Nutzbar für Zeichensatz-Konvertierungen, Plattformwechsel und Schema-Konsolidierungen
Zahlreiche Zusatzfunktionalitäten eröffnen ganz neue Einsatzszenarien (siehe Oracle Dokumentation Utilities)
Das zentrale PL/SQL-API DBMS_DATAPUMP ermöglicht das Integrieren von selbst programmierten Datenexports oder Datenimports. Somit ist auch eine Steuerung von Export/Import-Aktivitäten über Applikationen mithilfe des PL/SQL-Packages DBMS_ DATAPUMP möglich.
Unabhängig von Quelldatenbank-Patchständen oder Time-Zone-Patches
736
16.11 Alternative Upgrade-Methoden
16.11.3 Transportable Tablespaces Das Konzept der Transportable Tablespaces besteht im Wesentlichen aus dem physischen Kopieren der Datenfiles in eine neue Zielumgebung. Die zugehörigen Metadaten werden entweder mithilfe der Original Export/Import-Utilities oder mit Data Pump transferiert. In der neuen Zielumgebung sind die Datenfiles und Metadaten dann in eine neue, bereits im Vorfeld erstellte Datenbank eingeklinkt. Diese Datenbank besteht aus den Tablespaces SYSTEM, SYSAUX, TEMP und UNDO. Die Anwender-Tablespaces sind anschließend auf die Zielumgebung verschoben.
Generelle Vorgehensweise bei der Transportable-Tablespace-Methode 1. Prüfen Sie, ob das ausgewählte Tablespace keine Referenzen und Abhängigkeiten auf andere Tablespaces beinhaltet („Self Contained“). Wäre diese der Fall, müssten Sie alle abhängigen Tablespaces transportieren. In unserem Beispiel ist das Tablespace EXAMPLE „Self Contained“. Die SQL-Abfrage gibt keine Abhängigkeiten aus. SQL> EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('EXAMPLE', TRUE)9; PL/SQL procedure successfully completed. SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS; no rows selected
2. Setzen Sie nun das/die ausgewählte(n) Tablespace(s) in den „Read-Only“-Modus: SQL> ALTER TABLESPACE example READ ONLY;
Jetzt ist der Zugriff auf die Daten in diesem Tablespace nur lesend möglich. Ab diesem Zeitpunkt besteht nur noch eine eingeschränkte Nutzung der Daten für darauf zugreifende Applikationen. 3. Exportieren Sie jetzt die Metadaten des Tablespaces und die darin enthaltenen Objekte wie Tabellen, Indizes, Partitionen, Materialized Views usw.) aus der Quelldatenbank. Dies kann entweder über das Original Export-Utility oder über Data Pump erfolgen: $ expdp system DUMPFILE=tts_expdat.dmp DIRECTORY=data_pump_dir TRANSPORT_TABLESPACES=example LOGFILE=tts_export.log 9
Diese Prüfung kann auch optional direkt beim Export der Metadaten über den Parameter TRANSPORT_FULL_CHECK=y erfolgen.
737
16 Datenbank-Upgrades 4. Übertragen Sie die Datendateien. Normalerweise geschieht dies über Betriebssystembefehle wie ftp oder scp. 5. Wenn Sie zusätzlich noch einen Plattformwechsel durchführen möchten, sind die Datenfiles zuerst in ein Zwischenverzeichnis zu kopieren. Konvertierbare Plattformen lassen sich über die View v$transportable_platform abfragen: SQL> SELECT PLATFORM_ID ----------1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 18 19 20 21
* FROM v$transportable_platform ORDER BY 1; PLATFORM_NAME -------------------------------------------Solaris[tm] OE (32-bit) Solaris[tm] OE (64-bit) HP-UX (64-bit) HP-UX IA (64-bit) HP Tru64 UNIX AIX-Based Systems (64-bit) Microsoft Windows IA (32-bit) Microsoft Windows IA (64-bit) IBM zSeries Based Linux Linux IA (32-bit) Linux IA (64-bit) Microsoft Windows x86 64-bit Linux x86 64-bit HP Open VMS Apple Mac OS Solaris Operating System (x86) IBM Power Based Linux HP IA Open VMS Solaris Operating System (x86-64) Apple Mac OS (x86-64)
6. Das eigentliche Konvertieren erledigt das RMAN-Utility. Diese Konvertierung kann entweder auf der Quelle oder auf dem Ziel erfolgen. In der Praxis findet die DatenfileKonvertierung meist auf dem Zielserver statt: RMAN> CONVERT DATAFILE '/u01/tmp/TT1DB112/EXAMPLE01.DBF','/u01/tmp/TT1DB112/EXAMPLE02.DBF' TO PLATFORM="Linux x86 64-bit" FROM PLATFORM="Microsoft Windows IA (32-bit)" DB_FILE_NAME_CONVERT=('/u01/tmp/TT1DB112','/U01/ORADATA/TT1DB112') PARALLELISM=4;
7. Importieren Sie jezt die Metadaten, dadurch werden die Tablespaces in die neue Datenbank eingehängt. Dieser Schritt kann entweder über das Original Import-Utility oder über Data Pump erfolgen: $ impdp system DUMPFILE=tts_expdat.dmp DIRECTORY=data_pump_dir TRANSPORT_DATAFILES='/u01/tmp/TT1DB112' ,'/U01/ORADATA/TT1DB112' LOGFILE=tts_import.log
8. Nach erfolgreichem Import der Metadaten können Sie nun das/die Tablespace(s) in der Zieldatenbank in den Read/Write-Modus setzen: SQL> ALTER TABLESPACE example READ WRITE;
9. Kopieren Sie zusätzliche Objekte wie Sequenzen, Synonyme etc. ebenfalls in die Zieldatenbank. Dies kann beispielsweise mittels eines Data-Pump-Exports über NetworkLink oder über ein zuvor erstelltes Spool-Skript erfolgen. Die Vorteile der Transportable-Tablespace-Methode:
738
16.12 Komplexe Upgrade-Methoden
Schnell und einfach durchführbar Teilmigrationen möglich Sofern die Transportable Tablespaces im Read-Only-Modus bleiben, können diese auch gleichzeitig auf mehreren Datenbanken eingehängt werden. Falls Sie sich für die alternative Upgrade-Methode der Transportable Tablespaces entscheiden, sollten Sie im Vorfeld folgende Punkte dringend beachten:
Der Zeichensatz von Quell- und Zieldatenbank muss identisch sein. Bei verschlüsselten Tablespaces ist zwingend auch das zugehörige Wallet auf die Zielseite zu kopieren. Praxistipp Passen Sie so früh wie möglich Ihr Tablespace-Layout an eine Transportable-Tablespace-UpgradeStrategie an. Je einfacher Sie Ihr Design gestalten, desto leichter haben Sie es bei der Durchführung. Informieren Sie rechtzeitig Ihre Applikationsentwickler über die geplante Upgrade-Strategie.
16.12 Komplexe Upgrade-Methoden Komplexe Upgrade-Methoden kommen meist in Situationen zum Einsatz, in denen keine oder nur minimale Auszeiten möglich sind. Oracle bietet hier ebenfalls eine Reihe von Technologien und Vorgehensweisen an, deren Funktionalitätsumfang (Ausnahme: Copy Table Methode) von Version zu Version kontinuierlich erweitert wird. Zu den komplexeren Upgrade-Methoden zählen:
Copy Table (Create Table as Select, CTAS) Upgrade über Replikationsmechanismen Oracle Streams Oracle Golden Gate Logische Standby-Datenbanken über Data Guard Die genannten Vorgehensweisen haben eines gemeinsam: In allen Fällen ist ein Upgrade mit minimalster Downtime möglich. Die Konzeptions-, Test- und Umsetzungsphase ist sehr penibel zu planen und zu testen. Diese Methoden kommen meist in sehr komplexen hochintegrativen Systemen zum Einsatz und erfordern daher auch ein hohes Maß an Flexibilität. Ein solches Upgrade-Projekt stellt am Ende immer eine kundenspezifische Lösung dar. Unterstützt wird dies durch ein technisches Instrumentarium seitens der Oracle Datenbank in Form von Funktionalitäten (z.B. Logische Standby-Datenbanken), selbst erstellten oder am Markt verfügbaren Skriptgeneratoren oder zusätzlichen Tools. Nachfolgend einige Fakten zu jedem dieser Vorgehensweisen.
739
16 Datenbank-Upgrades
16.12.1 Copy Table (Create Table as select) Diese Upgrade-Methode kommt in der Praxis eher seltener vor, da vor allem die Vorbereitung einen enormen Aufwand erfordert. Bei komplexeren Schemas ist ein generischer Skriptansatz zu wählen, der einen hohen Programmieraufwand verursacht. Tools gibt es hier leider nur spärlich am Markt. Im SAP-Datenbank-Umfeld wird man am ehesten fündig. Für einfache Schema-Migrationen ist diese Methode jedoch bestens geeignet und wird von Datenbank-Administratoren und Anwendungsentwicklern von Zeit zu Zeit für den Aufbau von Testsystemen eingesetzt. Konzept CTAS Generell werden die Daten über Database-Links und Statements wie CREATE TABLE AS SELECT oder INSERT INTO in eine zuvor neu erstellte Datenbank transferiert. Eine hochgradige Parallelisierung kann einfach über den Zugriff auf die Quelldatenbank mithilfe von vielen gleichzeitig genutzten Database Links realisiert werden. Maximale Netzwerktransferraten setzen hier das Limit ebenso wie die verfügbaren Memory- und CPU-Ressourcen auf den Datenbankservern. Bevor man die Daten jedoch in die neue Zieldatenbank bzw. das neue Zielschema transferieren kann, sind alle nötigen Datenbank-Objektedefinitionen über Export/Import-Utilities oder Data Pump (Stichwort Import über Network-Link) zu importieren. Auch das korrekte Aktivieren von Constraints und die Erstellung von Sequenzen sind wichtig. Die Vorteile dieser Upgrade-Methode sind in manchen Fällen sehr willkommen:
Einfache Strukturänderungen in der Datenbank Einfache Datenreorganisation Selektiver Upgrade (einzelne Schemas oder Objekte) Möglicher Plattform- und Zeichensatzwechsel Nachteilig wirkt sich hier der Skripting-Aufwand aus, der von der Komplexität des Datenmodells abhängt. Bei großen Datenmengen kann das verfügbare Zeitfenster ein entscheidender und vor allem limitierender Faktor sein. Die verwendeten Skripte müssen immer zu dem aktuellen Datenmodell passen. Ein generischer Ansatz ist hier am besten geeignet.
16.12.2 Oracle Streams / Oracle Golden Gate Oracle Streams, mit der Version 9i R2 eingeführt, stellt Replikationsmechanismen zwischen Datenbanken bereit, die sogar bidirektional möglich sind. Oracle Streams ist nur noch bis einschließlich Version 11g R2 unterstützt. Golden Gate ist ein von Oracle im Jahr 2009 zugekauftes Produkt, das die Nachfolge von Oracle Streams antreten soll. Golden Gate ist ebenfalls ein Replikationsprodukt, das Datentransfers und das Einspielen der Datenänderungen entweder in eine Richtung oder bidirektional unterstützt. Die beiden Technologien ähneln sich von der prinzipiellen Vorgehensweise. Es werden die Transaktionsdaten aus den Redo-Logs mithilfe eines Capture-Prozesses ausgelesen, anschließend transformiert und auf die Zieldatenbank(en) übertragen. Dort werden die angelieferten Trans-
740
16.12 Komplexe Upgrade-Methoden aktionsdaten eingelesen, gegebenenfalls erfolgen noch Konfliktauflösungen. Über Schnittstellen kann selbst programmierte Logik in den Capture- als auch in den Apply- und den Konfliktlösungsprozess eingefügt werden. Oracle Golden Gate verfügt im Vergleich zu Oracle Streams noch über weitere zusätzliche Eigenschaften:
Zertifizierung für Reporting-Lösungen von Oracle Applications (E-Busines Suite, PeopleSoft, JD Edwards)
Unterstützung für mehr Datentypen als Streams, für Exadata zertifiziert Unterstützung von heterogenen Umgebungen: Log-basierter Capture-Prozess von und zu MS SQL Server 2008, IBM DB2 v9.7 und MySQL
Nativer Datentransfer zu Oracle Times-Ten-Datenbanken Capture-Prozess von JMS-basierten Messaging-Systemen Datenverteilung nach IBM DB2 for i Höhere Transaktionsflexibilität und Möglichkeiten zum Performance-Tuning Unterstützung von OLE-DB-Verbindungen auf Microsoft SQL-Server-Datenbanken Upgrade-Konzept für den Replikationsmechanismus
Erstellen Sie eine Kopie der Quelldatenbank auf dem gewünschten Zielsystem mittels der Transportable-Tablespace-Methode oder über Export/Import-Utilities.
Starten Sie den Capture-Prozesses auf der Quelldatenbank. Upgraden Sie die Zieldatenbank (manuelles Skript-Upgrade oder DBUA). Aktualisieren Sie die Daten der Zieldatenbank. Schalten Sie die Anwendung auf die aktualisierte Zieldatenbank um. Diese fungiert nun als die neue Produktionsdatenbank.
Bei Bedarf können Sie die ehemalige Quelldatenbank ebenfalls auf die neueste Version aktualisieren und anschließend für Reporting- oder Sicherungszwecke benutzen. Die Datenaktualisierung erfolgt dabei in die andere Richtung. Die Vorteile einer Upgrade-Methode mithilfe von Replikationsmechanismen liegen vor allem in der Möglichkeit, mit nahezu keiner oder nur sehr geringer Downtime Datenbanken auf die neueste Version zu bringen. Zusätzlich können hier elegant in einem Rutsch Plattformwechsel und Datenreorganisationen durchgeführt werden. Nachteilig wirkt sich die zweifellos hohe Komplexität in verteilen Systemen aus, was zu einem hohen manuellen und personellen Aufwand führt und entsprechendes Know-how erfordert.
16.12.3 Upgrade mit logischer Standby-Datenbank Ab der Version 10.1.0.3 kann ein Datenbank-Upgrade auch über eine logische StandbyDatenbank erfolgen. Diese Methode heißt auch „Rolling Upgrade“. Bei einer logischen Standby-Datenbank werden die Transaktionen der Quelldatenbank (Primary) automatisiert
741
16 Datenbank-Upgrades im Hintergrund über das LogMiner-Utility (extrahierte SQL-Statements) in die StandbyDatenbank appliziert. Leider gibt es je nach Datenbankversion einige Datentyp-Einschränkungen des LogMiners, die es zu beachten gilt. Mit der Oracle Version 11.2.0.2 gelten folgende Einschränkungen:
BFILE-Datentypen Einfache und verschachtelte abstrakte Datentypen (ADTs) Collections (Nested Tables und VARRAYs) Objekt-Referenzen Securefiles (erlaubt, wenn der COMPATIBLE-Parameter >=11.2. gesetzt ist) Eine genaue Übersicht über nicht unterstützte Objekte in Ihrer Datenbank erhalten Sie über eine Abfrage der View dba_logstdby_unsupported. In der Standby-Datenbank sind diese Objekte zwar enthalten, werden aber bei Änderungen nicht aktualisiert. Eine Aktualisierung dieser Datentypen muss getrennt entweder über Original Export/Import oder Data Pump erfolgen. Optional kann auch über entsprechende Datenbank-Konfigurationen die Aktualisierung ganz deaktiviert werden. Upgrade-Konzept der logischen Standby-Datenbank
Installieren Sie die aktuellste Softwareversion in ein neues Oracle-Home-Verzeichnis auf Ihrem Quell- als auch auf Ihrem Zieldatenbankserver. Denken Sie auch an eventuell verfügbare Patch Set Updates (PSUs).
Erstellen Sie eine physische Standby-Datenbank als 1:1-Kopie Ihrer Primärdatenbank. In der Regel geschieht dies über das RMAN-Utility und den DUPLICATE DATABASEBefehl. Anschließend konvertieren Sie die physische Standby-Datenbank in eine logische Standby-Datenbank.
Upgraden Sie die logische Standby-Datenbank über die manuelle Upgrade-Methode oder den DBUA.
Führen Sie nach erfolgreichem Upgrade der Standby-Datenbank einen Switchover (Rollentausch) auf diese durch. Jetzt ist die aktualisierte Standby-Datenbank die neue Primärdatenbank. Die ehemalige Produktionsdatenbank wird nun zur logischen Standby-Datenbank.
Führen Sie jetzt den Upgrade-Prozess (Manueller Upgrade oder DBUA) für die ehemalige Primärdatenbank (jetzt logische Standby-Datenbank) durch.
Wenn gewünscht, können Sie nach dem erfolgreichen Upgrade wieder einen Switchover (Rollentausch) durchführen. Jetzt befindet sich Ihre Primär- und Standby- Rollenverteilung wieder im Ursprungszustand. Während dieser Abläufe können die Anwender normal weiterarbeiten – einzig die Umschaltaktivitäten unterbrechen die Verbindung der Applikationen zur Datenbank kurz.
742
16.13 Datenbank-Konvertierung auf 64-Bit Upgrade-Konzept der Transient logischen Standby-Datenbank Das Prinzip eines Upgrades mit einer Transient logischen Standby-Datenbank entspricht fast dem vorangehend beschriebenen Ablauf. Es gibt nur wenige Unterschiede:
Nach dem Einrichten der physischen Standby-Datenbank als 1:1-Kopie der Primärdatenbankerstellen Sie einen garantierten Restore Point auf Ihrer Primärdatenbank.
Nach dem erfolgreichen Upgrade der Standby-Datenbank und dem Switchover wandeln Sie die ehemalige Primär-Datenbank über den Befehl ALTER DATABASE CONVERT TO PHYSICAL STANDBY in eine physikalische Standby-Datenbank um. Der Upgrade der ursprünglichen Primärdatenbank erfolgt nun automatisch über den Log-Apply-Prozess. Die Vorteile dieser Upgrade-Methoden liegen eindeutig in der nur sehr minimalen Ausfallzeit. Ab 11g R1 ist sogar eine heterogene Plattformunterstützung zwischen Linux- und Windows-Plattformen implementiert. Das bedeutet, Sie können Ihre Primär- und StandbyDatenbank auf unterschiedlichen Plattformen betreiben. Ab Oracle 11.2.0.2 wurde diese Plattformunterstützung nochmals erweitert. Eine genaue Aufstellung der möglichen Betriebssystemkombinationen finden Sie unter der „My Oracle Support“-Note „Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration“. Nachteilig ist die generell erhöhte Komplexität einer solchen Vorgehensweise und das damit erforderliche tiefe technische Know-how. Ein Upgrade über logische Standby-Datenbanken ist nur für die Enterprise Edition anwendbar. Die LogMiner-Einschränkungen können diese Upgrade-Methode noch zusätzlich komplizierter gestalten.
16.13 Datenbank-Konvertierung auf 64-Bit Ab Version 10g R2 können Sie Ihre Datenbanksoftware von einer 32-Bit-Installation automatisch in eine 64-Bit Datenbank konvertieren.10 Dafür müssen Sie neben den üblichen Schritten eines manuellen Upgrades bzw. über den DBUA noch folgende Schritte durchführen:
Deutliches Erhöhen der Memory-Initialisierungsparameter wie SGA_TARGET oder MEMORY_TARGET
Nach dem Anpassen der oben genannten Initialisierungsparameter erfolgt ein erneutes Verbinden mit der Datenbank und eine neue Datenbanksession mit den angepassten 64Bit-Memory-Parametern wird eröffnet. Eine genaue Aufstellung der einzelnen Upgrade-Schritte finden Sie in der My Oracle Support-Note “ How to convert a 32-bit database to 64-bit database on Linux?”.
10
64-Bit Betriebssysteme erfordern eine Installation der 64-Bit Oracle Softwareversion. Im Rahmen des Upgrade Prozesses ist lediglich die Installation der 64-Bit Software erforderlich. Innerhalb der ehemaligen 32-Bit Datenbank muss nichts weiter konfiguriert oder angepasst werden.
743
16 Datenbank-Upgrades
16.14 Wechsel von einer Standard Edition auf die Enterprise Edition Die Vorgehensweise beim Wechsel von einer Standard Edition auf eine Enterprise Edition ist wie ein In-Place-Upgrade (siehe Abschnitt 16.9 „Patchset 11.2.0.2 In-Place-Upgrade“). Sie können allerdings wechseln, wenn die Versionsnummern exakt übereinstimmen. Wenn beispielsweise die Standard Edition die Version 11.1.0.6 ist, dann muss die neue Enterprise Edition ebenfalls die Version 11.1.0.6 haben. So wechseln Sie von der Standard Edition auf die Enterprise Edition:
Stellen Sie sicher, dass die Release-Nummern exakt übereinstimmen. Stoppen Sie die Datenbank. Läuft Ihre Datenbank auf einer Windows-Plattform, stoppen Sie alle Oracle-Services inklusive des OracleServiceSID-Service.
Sichern Sie das Oracle-Home-Verzeichnis Ihrer Standard-Edition-Datenbank. Deinstallieren Sie Ihre Standard Edition über das Oracle-Tool Deinstall aus dem Oracle-Home-Verzeichnis.
Installieren Sie die Enterprise Edition Software über den Oracle Universal Installer (OUI) in das gleiche Home-Verzeichnis, in dem zuvor die Standard Edition war. Wählen Sie über den OUI die Enterprise Edition mit der Installationsart „Software Only“ aus. Führen Sie die Installation bis zum Ende korrekt durch.
Kopieren Sie folgende zuvor gesicherten Dateien in das nun aktualisierte Oracle-HomeVerzeichnis zurück:
ORACLE_HOME/dbs (Windows: ORACLE_HOME/database). ORACLE_HOME/network/admin ORACLE_HOME/hostname_dbname ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_hostname_dbname Starten Sie Ihre Datenbank wieder. Ihre ehemalige Standard Edition ist nun in eine Enterprise Edition umgewandelt.
16.15 Wechsel von einer Enterprise Edition auf eine Standard Edition Eine Enterprise Edition verfügt über Data-Dictionary-Objekte, die in einer Standard Edition nicht enthalten sind. Wenn Sie nur die Standard Edition installieren und Ihre Datenbank wieder in Betrieb nehmen, werden einige Data-Dictionary-Objekte ungültig und Sie werden zwangsläufig Probleme beim späteren Datenbankbetrieb bekommen.
744
16.16 Resümee Praxistipp Der einzige Weg, von einer Enterprise Edition in eine Standard Edition zu wechseln, ist nur über die Verwendung der Export/Import-Utilities möglich. Oracle empfiehlt den Export über das ExportUtility der Standard Edition durchzuführen. Der Import-Vorgang dieses Dumpfiles importiert keine Enterprise-Edition-spezifischen Data-Dictionary-Objekte, da SYS-Schema-Objekte nicht exportiert werden. Nach dem erfolgreichen Import in die neue Standard Edition sind lediglich noch die Enterprise-Edition-bezogenen User wie MDSYS zu löschen. Testen Sie diese Methode sehr gut.
16.16 Resümee Oracle bietet mittlerweile eine Vielzahl von möglichen Upgrade-Pfaden und nutzbaren Technologien. Es gilt also: Wer die Wahl hat, hat die Qual! Die ersten Abschnitte dieses Kapitels haben gezeigt, dass eine sorgfältige Vorbereitung und Planung sowie ausgiebige Tests elementar für einen erfolgreichen Upgrade sind. Darüber hinaus haben wir die gängigsten Upgrade-Methoden ausführlich vorgestellt. Der nächste Upgrade müsste Ihnen damit wesentlich leichter fallen.
745
16 Datenbank-Upgrades
746
Die Autoren Andrea Held Andrea Held ist Geschäftsführerin der Held Informatik – Gesellschaft für datenbankgestützte Informationssysteme mbH. Sie und ihre Mitarbeiter sind vorrangig in Projekten für Großunternehmen tätig. Seit 14 Jahren beschäftigt sie sich intensiv mit Oracle-Datenbanken. Sie ist Oracle Certified Professional und Autorin zahlreicher Fachartikel und erfolgreicher Bücher rund um die Oracle-Datenbank. Andrea Held hat die Kapitel 2 „Architektur und Administration“, 3 „Verwaltung von Datenbankobjekten“, 13 „Backup und Recovery“ und 14 „Verfügbarkeit“ verfasst. Mirko Hotzy Mirko Hotzy arbeitet als Principal Consultant und Disziplinmanger für Datenbanken bei der Trivadis GmbH in Stuttgart, wo er als Hauptreferent für die Inhalte und Durchführung der Oracle New Features und Oracle Storage Kurse verantwortlich ist. Darüber hinaus ist er Partner der Firma Trivadis. Seit 1994 beschäftigt er sich intensiv mit Oracle Datenbanken und konnte sein umfangreiches Know-how in zahlreichen Großprojekten kontinuierlich verfeinern. Seine Interessen liegen im Bereich Datenbankarchitekturen, Performance-Optimierung sowie Betrieb und Organisation von komplexen und hochkritischen IT-Umgebungen. Mirko Hotzy hat die Kapitel 9 „Troubleshooting“ und 16 „Datenbank-Upgrades“ sowie zusammen mit Peter Welker das Kapitel 15 „Große Datenbanken“ verfasst. Lutz Fröhlich Lutz Fröhlich ist Diplom-Mathematiker und Oracle Certified Master sowie erfolgreicher Autor von Fachbüchern und Veröffentlichungen. Fröhlich arbeitet seit 1993 mit Oracle-Datenbanken und ist spezialisiert auf die Themen Performance, Hochverfügbarkeit und Exadata. Er hält regelmäßig Seminare und Vorträge zu diesen und anderen Themen ab. Seine praktischen Erfahrungen basieren auf ConsultingTätigkeiten für über 40 internationale Unternehmen in den USA und Europa. Lutz Fröhlich hat die Kapitel 1 „Schnelleinstieg“ und 5 „Automatic Storage Management“ sowie den Abschnitt 2.13 „Verwaltungswerkzeuge“ verfasst.
747
Die Autoren Marek Adar Marek Adar ist Diplom Physik Ingenieur sowie Oracle Certified Professional. Er arbeitet seit mehreren Jahren als freiberuflicher Oracle Referent, Trainer und Consultant. Seine Kernbereiche im Oracle-Umfeld liegen in der SQL- und PL/SQL-Programmierung, der Datenbankadministration, Performance Tuning, Backup und Recovery sowie Data Guard. Er ist Autor erfolgreicher Bücher zur Datenbankadministration und für den Einstieg in den Recovery Manager. Marek Adar hat in Kapitel 14 „Verfügbarkeit“ den Abschnitt „Data Guard“ verfasst. Christian Antognini Seit 1995 konzentriert sich Christian Antognini auf das Erforschen der Oracle Datenbank Engine. Seine Interessen liegen schwerpunktmäßig im logischen und physischen Datenbank Design, in der Integration von Datenbanken und Java Applikationen und dem Query Optimizer. Derzeit arbeitet Chris Antognini als Principal Consultant und Trainer bei der Trivadis AG in Zürich. Er hält Vorträge, ist erfolgreicher Autor und Mitglied des Trivadis Performance Teams und des OakTable Networks. Darüber hinaus ist er Partner der Firma Trivadis. Chris Antognini hat die Kapitel 4 „Speicherplatzverwaltung“ und 8 „Optimierung“ verfasst. Konrad Häfeli Konrad Häfeli beschäftigt sich seit 19 Jahren mit Oracle-Datenbanken. Ab 1998 betreute er als Principal Consultant bei der Trivadis AG in Bern im Bereich Infrastructure Managed Services Kunden von der Konzeptionierung über Betriebsunterstützung bis Tunings und Reviews. Zusätzlich war er Hauptreferent für Architektur- und Backup/Recovery-Themen. Seit Mitte 2008 ist Konrad Häfeli als Senior Technology Manager verantwortlich für die Erarbeitung und den Transfer von Wissen über sämtliche Infrastrukturthemen, welche in den Dienstleistungen der Trivadis angeboten werden. Darüber hinaus ist er Partner der Firma Trivadis. Konrad Häfeli hat das Kapitel 7 „Oracle Net“ verfasst. Daniel Steiger Daniel Steiger ist als Principal Consultant und Disziplinmanager für die Trivadis AG in der Schweiz im Bereich Infrastructure Managed Services tätig. Seine Haupttätigkeiten sind Architekturberatung und technisches Consulting im Oracle-Umfeld. Er ist Hauptreferent für den Oracle Architektur- und Interna-Kurs der Trivadis. Daniel Steiger ist seit über 20 Jahren mit Oracle in Kontakt. Er war einige Jahre als Programmierer tätig und sammelte als Oracle-DBA Erfahrung in zahlreichen Einsätzen und Kundenprojekten. Sein hauptsächliches Interesse gilt betrieblichen und konzeptionellen Fragestellungen im Oracle-Datenbankbereich. Daniel Steiger hat die Kapitel 11 „Monitoring“ und 12 „Aufbau und Betrieb eines Datenbankservers“ verfasst.
748
Die Autoren Sven Vetter Sven Vetter ist Oracle Certified Professional für die Versionen 8.0 bis 11g und trägt seit 2010 die Auszeichnung als „Leading SME Professional“ durch die Zertifizierung nach dem „Leading Subject Matter Experts Rating“. Er arbeitet seit 1999 bei der Firma Trivadis und unterstützte zunächst als Senior Consultant, später als Principal Consultant diverse Kunden in großen DatenbankProjekten. Als Senior Technology Manager ist er seit 2008 innerhalb der Trivadis verantwortlich für Security. Darüber hinaus ist er Partner der Firma Trivadis. Sein Wissen gibt er in zahlreichen Kursen (Advanced Administration, New Features, Oracle Security), Vorträgen und Artikeln weiter. Sven Vetter hat die Kapitel 6 „Security“ und 10 „Jobsteuerung“ verfasst. Peter Welker Peter Welker arbeitet seit 1992 mit diversen Datenbank Management Systemen, seit 1996 mit Fokus auf Oracle und seit 2005 auch mit MySQL. Seit 1998 beschäftigt er sich vorwiegend mit Data Warehouses, und dort vor allem mit den Themengebieten ETL und Performanceoptimierung. Peter Welker ist heute als Technology Manager bei der Trivadis für die Bereiche „Business Intelligence“ und „Application Performance Management“ verantwortlich. Peter Welker hat zusammen mit Mirko Hotzy das Kapitel 15 „Große Datenbanken“ verfasst.
749
Die Autoren
750
Register $ $tablespace 90
/ /u00 554
3 3-Tier-Architektur 363
A Abfrageoptimierung 411 ACFS 290, 316 verwalten 321 ACFS Background Process 321 ACFS Mount Registry 318 ACFS Snapshot 320 ACFS-Volume 321 ACL 333 im Cluster 630 ACTION_SCRIPT 633 Active Incidents 475 ACTIVE_SERVERS 630 Active Session History 430 active_sessions.sql 437 Activity-Grafik 431 Adaptive Thresholds 514 Administrator-managed Cluster 630 ADR 58, 507, 525, 558 ADR-BASE 400, 468 ADR-Home 468, 558 ADRCI 401, 470, 507 ADRCI-Skript 520 ADRCI-Utility 466
Advanced Queuing 498 Advanced Security Option, RMAN 583 Advanced-Features 409 advise failure 602 AGENT_FILENAME 633 Aktiv/Passiv-Cluster 616, 621 Alert-Datei 41 Alert.log 465, 519 im Dateisystem finden 57 mit external Table auslesen 192 Alert.Log-File 510 Alias eines OMF-Dateinamen 313 ALL 736 all_def_audit_opts 344 all_rows 415 Allocation Unit 290, 302 ALTER INDEX 223, 233 ALTER SYSTEM 28, 126 AMM 67 Analytic Workspace Manager 698 ANY-Privilegien 330, 342 Apply Service 638 Arbeitsspeicher 67, 411 einer Oracle Datenbank 60 ARC 72 Architektur einer Oracle-Datenbank 38, 39 Archive Log Modus 51 (de-)aktivieren 120 manuell archivieren 121 Status ermitteln 120 stoppen und starten 121 Archiver 72
D DAS 244 DATA 736 Data Block Integrity 471 Data Dictionary Cache 65 Eigentümer des 45 Speicherung im System-Tablespace 45 Data Dictionary Cache 64 Data Guard 635, 739 13.6.5 Verwaltungswerkzeuge 640 Apply Service 638 Architektur 636 Broker 640 Broker aktivieren 649 DB_FILE_NAME_CONVERT 641 Failover 639, 655, 657 Fast Start Failover 655 FORCE LOGGING 640 Hardware 640 Konfigurationsdateien 650 Listener 644
755
Register Listener.ora 649 LOG_FILE_NAME_CONVERT 641 Maximum Availability 639 Maximum Performance 639 Maximum Protection 639 NOLOGGING 640 Oracle Net-Konfiguration 643 Protection Modes 639 Protection Mode ändern 653 Role Transitions 638 Services 638 Switchover 639, 654, 655 Voraussetzungen 640 Redo Transport Service 638 Data Guard Network Compression 686 Data Masking Pack 506 DATA_ONLY 736 Data Recovery Advisor 472, 475, 602 Data Warehouses 662, 690 Database Buffer Cache 61 Keep-Cache 62 Recycle-Cache 62 Database Configuration Assistant 3, 6, 12, 326 Database Replay 732 Database Resident Connection Pooling 396 Database Upgrade Assistant 716 Database Vault 339, 351 Database Writer 71 Database Writer-Prozesse 61, 70 Datenblöcke ändern 45 Datafiles 41, 44 Begriffsklärung 39 dba_data_files 91 Informationen im Data Dictionary 90 löschen 100 Mindestanzahl 40 Namen und Attribute ermitteln 91 umbenennen 98 und Tablespaces 44 verschieben 98 v$datafile 91 Datafile needs Recovery 575 Datapump 565, 604, 697, 735
R RAC 368, 376, 378, 384, 392, 393, 493, 615, 621 Architektur 622 Failover 657 Failover Connection Pool 659 Grid Infrastruktur 616, 621, 631 Private Network 622 Public Network 622 Redologs konfigurieren 120 Ressourcen-Management 630 Server Pools 630 Services verwalten 629 Shared Storage 622 Single Client Access Name (SCAN) 658 VIP 622 Voraussetzungen 622 Voting Device 623 Workload Management 630 RAC One Node 616, 634
Register RAID 1+0 247 RAID 10 247 RAID 5 246 RAID 6 246 RAW 186 Raw Devices 250 RAC 625 RC_RMAN_STATUS 536 Read Commited 77 Read Only 77 Read Write / Read Only 86 Real Application Clusters 30, 615 Grid Infrastruktur 616, 621, 631 Voraussetzungen 621 Real Time Apply 648 Real-Time SQL Monitor 544 Real-Time SQL Monitoring 530 Rebalancing 253 Intensität 311 Rebalancing-Operationen 254 REBUILD ONLINE 223 receive queue 394 Rechnerverbund 621 Rechte, Tabellen 210 RECO 70, 73 Recoverer 73 Recoverer Prozess 70 Recovery 565, 567, 576 einer Betriebssystemkopie 576 mit Controlfile 576 unvollständiges 567, 576 using backup controlfile 576 vollständiges 576 Recovery-Katalog 594 Recovery Manager 565, 577 Recycle-Cache 62, 414 Redo-Apply, Starten und stoppen 648 Redo Integrity 472 Redo Transport Service 638 Redologs 41, 51 aktive und inaktive 53 Anzahl 51 Anzahl der Member einer Gruppe 52
Archive Log Mode 53 Archive Log Modus aktivieren 120 archivierte ermitteln 115 Aufteilung der Member einer Gruppe auf Devices 52 Begriffsklärung 39 bereinigen / clear 119 Empfehlungen zur Konfiguration 115 Größe 52 Größe ermitteln 114 Group Member ermitteln 114 Gruppen 52 Gruppe anlegen 117 Gruppe löschen 118 History 114 Informationen im Data Dictionary 51, 114 manuell archivieren 121 Member einer Gruppe hinzufügen 117 Member einer Gruppe löschen 117 Log Sequence Number 51, 53 Member 52 Namen ermitteln 114 Pfade ermitteln 114 RAC (Real Application Clusters) 120 Spiegelung 52 Switch erzwingen 118 v$archived_log 53 v$log 51 v$log.members 52 v$logfile 51 verschieben und umbenennen 119 verwalten 113 Redolog-Buffer 63, 414 Redotransport 393 Redundanz 254 Referenz-Note 483 Refresh Fast on Commit 682 relationale Data Marts 704 Relationales OLAP 698 REMAP_DATA 736 REMOTE_LISTENER 129 REMOTE_LOGIN_PASSWORD_FILE 642 remote_login_passwordfile 132
769
Register REMOTE_LOGIN_PASSWORDFILE 129 Reorganisation 280 Index 228 Reorganisationsmethoden 280 repair failure 602 RESIZE-Befehl 258 Resource consumer group 493 Ressourcen im Cluster 631 Ressourcen-Management im Cluster 630 Ressourcen-Typen im Cluster 631 Restart 615, 616 Restore 567 Restore und Recovery Unterschiede 567 Restore Point 609 erstellen 609 Preserve 610 Restricted Session bei Startup 85 Result Caching 461 Retentions-Policies 526 Reverse Key Index 225 REWRITE_TABLE 684 RMAN 565, 577 Anmeldung 578 Archived Logs sichern 589 Auxiliary Database 577 Backup as Copy 587 Backup Backupset 587 Backup-Piece 578 Backup Set 578 Bandsicherung konfigurieren 585 Batch Modus 578 Befehlsübersicht 603 Block Change Tracking 59 Catalog Database 577 Change Tracking aktivieren 588 Channel 577 Channel allokieren 586 Channel konfigurieren 580 cmdfile 578 control_file_record_keep_time 584 Controlfile sichern 579, 589 Controlfile wiederherstellen 601
770
Data Recovery Advisor 602 Datafile wiederherstellen 599 Datenbank sichern 579 Datenblock reparieren 598 DBID ermitteln 601 DBID setzen 601 Defaultwerte zurücksetzen 584 Disk Backup 581 DRA 602 Duplexing 581 Flash Recovery Area 568 Größe der Backup-Pieces begrenzen 580 Image Copy 578 Inkrementell aktualisierte Sicherung 589 Inkrementelle Sicherung 588 Interaktiver Modus 578 Katalog erstellen 595 Katalog planen 595 Katalogdatenbank registrieren 596 Katalog-Upgrade 596 Komponenten 577 Komprimierung 582 Konfiguration anzeigen 579 Kopien von Backups erstellen 581 Korrupte Datenblöcke ermitteln 598 Korruptionen prüfen 592 Langzeitsicherung erstellen 593 Löschen archivierter Redologs 593 Löschen von Sicherungen 592 Monitoren des Job-Fortschrittes 591 Monitoring 604 Multisection Backup 580 Namen konfigurieren 590 Offline-Sicherung 588 Online-Sicherung 587 optimization on / off 579 Paralleles Backup 581 Pfad konfigurieren 590 Point in Time Recovery 600 Recovery-Katalog 594 Report 591 Run-Block 586 Sicherungen anzeigen 591
Z Zeichensatz 18 aktuellen ermitteln 133 ändern 133 Empfehlungen 183 Multi Byte 183 Single Byte 184 Unicode 184 unterstützte 185 Zeilenverzeichnis eines Datenblockes 43 Zertifizierung 550 Zugriffspfad 456
Die DOAG Deutsche ORACLEAnwendergruppe e.V. repräsentiert die deutsche Oracle-Community Die DOAG ist in Deutschland die Interessensvertretung der Anwender aller Oracle-Produkte und informiert seine Mitglieder kompetent über alle Oracle-Themen. DOAG-Mitglied zu sein bedeutet, ständigen Zugang zu aktuellem Praxis-Know-how durch die DOAG-Veranstaltungen, die Publikationen und den Online-
Dienst zu haben sowie in das Netzwerk der größten und einflussreichsten deutschsprachigen Oracle-Community einbezogen zu sein. Die DOAG setzt sich engagiert für die Interessen seiner Mitglieder ein und führt einen konstruktiv-kritischen Dialog mit Oracle.
DOAG-Mitglieder sind erfolgreicher! Erfahrungsaustausch und Informationsvermittlung sorgen für den entscheidenden Wissensvorsprung und mehr Erfolg im Job.
Das bietet die DOAG-Mitgliedschaft: • Kostenfreie Teilnahme an Treffen der Regionalgruppen
• Rabatte auf zahlreiche DOAGVeranstaltungen
• Bezug der DOAG News, Business News und Java aktuell
• Bezug des 14-tägigen elektronisch DOAG/ Computerwoche Newsletters
• Verbindung zu und Kommunikation mit anderen internationalen Benutzergruppen
• Interessenvertretung bei Oracle • Mitbestimmungsrecht im Rahmen der Vereinsaktivitäten
• Bevorzugte Buchung für ausgewählte Veranstaltungen und Schulungen
2011_Handbuch_DBA.indd 1
04.08.2011 9:04:27 Uhr
Vier Communities, um Kräfte zu bündeln Die DOAG räumt der ständig erweiterten Produktpalette von Oracle Bedeutung ein und spricht die Anwender entsprechend ihrer Zielgruppen an. Als größte Usergroup im deutschsprachigen Raum bietet die DOAG seit Jahren erstklassigen Wissens- und Erfahrungsaustausch; dafür sorgt unser Netzwerk von inzwischen rund 5.000 Mitgliedern. Um ein optimales Angebot zu entwickeln und die Interessen der jeweiligen Zielgruppen gleichwertig in die Vereinsarbeit einzubinden, fasst die DOAG ihre thematischen Schwerpunkte in vier Communities zusammen: Datenbank Community, Infrastruktur & Middleware Community, Development & BI/DWH und Business Solutions Community. Im Dialog mit den Mitgliedern ankern sie die Themenschwerpunkte fest und bieten somit eine maßgeschneiderte Veranstaltungsgestaltung.
Datenbank Community Die traditionell stark vertretene Datenbank Community greift alle Facetten rund um die Datenbank auf und beleuchtet sie aus den unterschiedlichsten Blickwinkeln. Neben Oracle Database sind Oracle & SAP und MySQL weitere Themen.
2011_Handbuch_DBA.indd 2
Business Solutions Community Die DOAG unterstützt alle Anwender der Oracle Business-Lösungen und bietet Entscheidungsträgern fundierte Informationen zum strategischen Einsatz der Oracle-Produkte an.
Infrastruktur & Middleware Community Durch die Übernahme von Sun Microsystems erweitert sich das Port-folio von Oracle um Technologien im Bereich Infrastruktur. Des Weiteren befasst sich die Community mit allen Bereichen von Oracle Fusion Middleware.
Development & BI/DWH Im Focus der Community ist die Software-Entwicklung mithilfe von OracleWerkzeugen. Dabei steht die Developer/ Designer-Perspektive im Vordergrund. Java-Developer sind in der Community ebenfalls vertreten. Darüber hinaus kommen auch die Themen SOA/BPM sowie BI/DWH zur Sprache.
04.08.2011 9:04:27 Uhr
Die DOAG im Dialog mit den Anwendern Die Competence Center der DOAG informieren zu wichtigen Support-, Lizenz-, Securityund Lokalisierungsfragen. Themenspezifische Anfragen der Mitglieder werden beantwortet. Die DOAG schafft Transparenz, vermittelt und unterstützt im technischen Dialog mit dem Hersteller.
Face-to-face: Profitieren vom gebündelten Know-how Erleben Sie mit der größten und einflussreichsten deutschsprachigen Oracle-Community hochwertige Fachvorträge, praxisnahe Erfahrungsberichte, nachhaltige Seminare und moderne Networking-Elemente. Ein weltweites Netzwerk an Referenten, Experten und Fachspezialisten bietet Aktualität sowie erstklassige Qualität und eröffnet somit den Zugang zu Erfahrungen und Informationen aus erster Hand. Während die Regionalgruppen themenübergreifend Kontakte und Austausch auf regionaler Ebene bieten, überzeugen die Communities in ihren SIG-Events mit Themenvielfalt zu aktuellen Trends sowie Tipps und Tricks. Nachhaltiges Wissen bieten die Berliner Expertenseminare, die in kleinen Gruppen von Experten geführt werden.
Die mehrtägigen Konferenzen bieten das Rundumpaket aus Fachvorträgen, Erfahrungsberichten, Workshops, Networking-Elementen sowie begleitende Ausstellungen. Lebendig, praxisbezogen und in einem Ambiente, das den professionellen Austausch besonders fördert. Vorteile für Sie:
• Es zählen persönlicher Wissenstransfer und hohe Effizienz
• Netzwerken à la carte: Multipliziertes Wissen bringt Sie zum Erfolg
• Der Rundum-Service schafft optimale Bedingungen in den Veranstaltungen
DOAG Konferenz + Ausstellung Technische Themenvielfalt der Oracle-Produkte. Drei Tage Wissen pur. Größte Oracle-Konferenz in Europa. Jährlich Mitte November.
DOAG Applications Führende Konferenz für Anwender der Oracle Business Applikationen. Jährlich im Frühjahr.
2011_Handbuch_DBA.indd 3
04.08.2011 9:04:27 Uhr
DOAG Computerwoche/Newsletter Fundierte Beiträge der Computerwoche-Redaktion sowie exklusive Inhalte der DOAG finden Sie in unserem Newsletter. Der DOAG/Computerwoche Newsletter erscheint 14-tägig in Kooperation mit der Zeitschrift Computerwoche und enthält Anrisse und Verweise auf Interviews und Meinungsartikel zu aktuellen Themen sowie Berichte über DOAG-Veranstaltungen. Der Newsletter wird allen Mitgliedern der DOAG sowie Interessenten kostenlos online im HTML-Format zugestellt.
DOAG News – die Fachzeitschrift für DOAG-Mitglieder Die DOAG News informiert in erster Linie über Grundlagen-Themen, Anwendungen und Neuigkeiten rund um die Produkte von Oracle. Hinzu kommen Interviews und Meinungsartikel zu aktuellen Themen sowie Berichte über DOAG-Veranstaltungen. Insbesondere die fachlich fundierten, praxisorientierten Beiträge der Oracle-Community bilden das Highlight der Publikation. Die Zeitschrift DOAG News erscheint sechs Mal im Jahr und wird allen Mitgliedern der DOAG kostenlos zugestellt. Darüber hinaus kommt zweimal jährlich die DOAG Business News mit Themen für die Anwender der Oracle Business Applications heraus.
Die Medien der DOAG: Immer aktuell Die Mitglieder erwartet eine Vielzahl aktueller Inhalte rund um Oracle und seine Produktpalette. Um die Kommunikation zwischen den Mitgliedern auch im Internet zu fördern, stellt die DOAG ein Internetforum zur Verfügung, in dem Experten und Anfänger sich austauschen können. In puncto Neue Medien ist die DOAG auch bei Xing, Facebook und Twitter vertreten. Wer immer auf dem neuesten Stand sein möchte, kann auch den RSS-Feed oder den Newsletter abonnieren.
Java aktuell – die Welt der Java-Entwickler Die DOAG ist Gründungsmitglied im Interessenverbund der Java Usergroups (iJUG) e.V., der die Java aktuell herausbringt. Die Themen der vierteljährlich erscheinenden Zeitschrift umfassen sowohl die Oracle-Produkte für Java wie WebLogic, JDeveloper und ADF 11g, als auch entsprechende Open-SourceProjekte wie Spring oder Eclipse. Hinzu kommen wichtige Bereiche wie JavaFX, Rapid Application Development, Java Virtual Machines und die SunServer. Java aktuell ist an ausgewählten Kiosken sowie im Abonnement erhältlich. DOAG-Mitglieder erhalten die Zeitschrift kostenlos zugeschickt.
Kontakt:
Weitere Informationen: www.doag.org
2011_Handbuch_DBA.indd 4
DOAG e.V. Tempelhofer Weg 64 12347 Berlin 0700 11 36 24 38 [email protected]
04.08.2011 9:04:27 Uhr
Auf gute Performance.
Fröhlich Oracle 11g Performance Forecast 219 Seiten ISBN 978-3-446-41494-5
Viele Unternehmen, die Oracle-Datenbanken einsetzen, kämpfen mit dem Thema Performance. Kein Wunder, denn mit dem Wachstum von Datenbanken und Applikationen verschlechtert sich die Performance. Lutz Fröhlich stellt in diesem Praxisbuch sowohl mathematische Modelle für Performance Forecasts als auch pragmatische und erprobte Vorgehensweisen für das Performance- und Kapazitätsmanagement vor. Er liefert praktische Lösungen für den Datenbank-Administrator, der im täglichen Support-Geschäft für die Überwachung und Einhaltung der PerformanceVorgaben oder Service Level Agreements sorgen muss. Dem IT-Manager bietet er Entscheidungsgrundlagen für die Hardware- und Budgetplanung. Der Datenbank-Entwickler erhält die Möglichkeit, die Performance seiner Applikationen vorab zu berechnen – ohne teure Tests.
Mehr Informationen zu diesem Buch und zu unserem Programm unter www.hanser.de/computer
Alles drin, alles 11g
Loney Oracle Database 11g Die umfassende Referenz 992 Seiten. Mit CD ISBN 978-3-446-41864-6
In diesem umfassenden Standardwerk zur Oracle Database 11g lernen Sie die grundlegenden Konzepte der Oracle-Datenbank kennen und erhalten detaillierte Informationen über die mächtigen Features von 11g. Sie erfahren, wie Sie die neuen Features und Tools effektiv einsetzen und erhalten praktische Tipps zu Themen wie Security-Maßnahmen und Performance Tuning, die für jeden DBA wichtig sind. Die alphabetische Referenz liegt erstmals auf CD bei. So finden Sie in diesem praktischen Nachschlagewerk schnell, was Sie suchen: die Konzepte, Befehle, Funktionen und Features von Oracle. Zahlreiche Querverweise helfen Ihnen bei der Orientierung innerhalb der Referenz und im Grundlagenteil des Buches. Mehr Informationen zu diesem Buch und zu unserem Programm unter www.hanser.de/computer
■ Ein unentbehrliches Hilfsmittel für die täglichen DBA-Aufgaben! ■ Nutzen Sie die Erfahrung von langjährigen OracleSpezialisten! ■ Mit einer Fülle von praxiserprobten Lösungen. ■ Deckt die Oracle Versionen bis 11g R2 ab. ■ Im Internet: Die Skripte des Buches sowie Listen mit nützlichen Kommandos zum Nachschlagen.
Als Administrator der Oracle Database finden Sie in diesem Handbuch die ideale Unterstützung für die Herausforderungen Ihres Alltags. Hier hat sich eine Gruppe namhafter und praxiserfahrener Autoren zusammengetan, die gemeinsam 134 Jahre Erfahrung mit dieser Datenbank aufweisen und in den jeweiligen Kapiteln ihre Spezialgebiete darstellen. Die Autoren vermitteln Ihnen fundiertes Know How sowie praktische Lösungen zu Themen wie Aufbau und Betrieb eines Datenbankservers, Administration und Monitoring, High Availability, Backup und Recovery, Security, Upgrade einer Datenbank und Optimierung. Zusätzlich finden Sie in diesem Handbuch neben einer Darstellung der Produkte und Features der Oracle Database 11g R2, viele Beispiele, Praxistipps und Tricks, die Sie direkt in Ihre tägliche Arbeit integrieren können und die über Versionsgrenzen hinweg anwendbar sind. Im Internet finden Sie 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.
Sven VETTER und Peter WELKER sind zertifizierte Oracle Experten der Trivadis in Deutschland und in der Schweiz (trivadis.de, trivadis.ch), sie bringen hier ihr Know-how zu den verschiedenen Aspekten der Datenbankadministration ein.
AUS DEM INHALT // ■ Schnelleinstieg ■ Architektur und Administration ■ Verwaltung von Datenbankobjekten ■ Speicherplatzverwaltung ■ Automatic Storage Management ■ Security ■ Oracle Net ■ Optimierung ■ Troubleshooting ■ Jobsteuerung ■ Monitoring ■ Aufbau und Betrieb eines Datenbankservers ■ Backup und Recovery ■ Verfügbarkeit ■ Große Datenbanken ■ Datenbank-Upgrades
€ 69,00 [D] | € 71,00 [A] ISBN 978-3-446-42081-6
9 www.hanser.de/computer
783446 420816
Systemvoraussetzungen für eBook-inside: Internet-Verbindung und eBookreader Adobe Digital Editions.
DER ORACLE DBA //
Andrea HELD, Lutz FRÖHLICH und Marek ADAR bringen hier als selbständige und zertifizierte Oracle-Spezialisten ihre langjährige Erfahrung in der Administration von Oracle Datenbanken ein. Sie sind Mitglieder des Oranerds-Netzwerks (oranerds.de), einem Netzwerk unabhängiger Oracle-Experten. Mirko HOTZY, Chris ANTOGNINI, Konrad HÄFELI, Daniel STEIGER,
