Konzepte für Datenbankadministratoren

Der Skriptcontent auf dieser Seite ist ausschließlich für Navigationszwecke vorgesehen und bewirkt keinerlei Änderung des Contents.

In diesem Teil werden die Aufgaben, Tools und grundlegenden Kenntnisse für Datenbankadministratoren beschrieben.

Aufgaben von Datenbankadministratoren

Die Hauptverantwortung eines Datenbankadministrators (DBA) besteht darin, den Benutzern Unternehmensdaten zur Verfügung zu stellen.

DBAs müssen eng mit Entwicklern zusammenarbeiten, um sicherzustellen, dass ihre Anwendungen die Datenbank effizient nutzen. Außerdem müssen sie mit Systemadministratoren zusammenarbeiten, um sicherzustellen, dass physische Ressourcen angemessen und effizient genutzt werden.

Oracle DBAs sind dafür verantwortlich, die Oracle AI Database-Architektur und die Funktionsweise der Datenbank zu verstehen. DBAs können die folgenden Aufgaben ausführen:

Die Benutzertypen sowie ihre Rollen und Verantwortlichkeiten hängen von der Datenbankumgebung ab. Eine kleine Datenbank kann über einen DBA verfügen. Eine sehr große Datenbank kann die DBA-Aufgaben auf mehrere Spezialisten aufteilen, z. B. Sicherheitsbeauftragte, Backup-Operatoren und Anwendungsadministratoren.

Siehe:

Tools für Datenbankadministratoren

Oracle stellt mehrere Tools für die Verwaltung einer Datenbank bereit.

In diesem Abschnitt werden einige häufig verwendete Tools beschrieben.

Oracle Enterprise Manager

Oracle Enterprise Manager (Enterprise Manager) ist ein webbasiertes Systemverwaltungstool, das die Verwaltung von Oracle-Datenbanken, Exadata-Datenbankmaschinen, Fusion Middleware, Oracle-Anwendungen, Servern, Speicher und nicht von Oracle stammender Hardware und Software bereitstellt.

Oracle Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control (Cloud Control) ist eine webbasierte Schnittstelle, die dem Administrator eine vollständige Überwachung über den gesamten Oracle-Technologie-Stack und Nicht-Oracle-Komponenten bietet.

Manchmal ist eine Komponente der Fast Application Notification (FAN) nicht mehr verfügbar, oder es treten Leistungsprobleme auf. In diesem Fall zeigt Cloud Control den automatisch generierten Alert an, damit der Administrator die entsprechende Wiederherstellungsaktion ausführen kann.

Zu den Komponenten von Cloud Control gehören:

Siehe:

Oracle Enterprise Manager Database Express 12c

Oracle Enterprise Manager Database Express (EM Express) ist ein Web-Management-Produkt, das in die Oracle-Datenbank integriert ist. Es erfordert keine spezielle Installation oder Verwaltung.

EM Express enthält die wichtigsten Seiten für das Performance-Management und die grundlegende Administration in Cloud Control. Diese Seiten umfassen:

Sie können online über die EM Express-Konsole und offline über die Active Reports-Technologie auf diese Features zugreifen. Aus architektonischer Sicht verfügt EM Express über keine Mid-Tier- oder Middleware-Komponenten, wodurch der Overhead auf dem Datenbankserver vernachlässigbar ist.

Mit EM Express können Sie administrative Aufgaben wie die Verwaltung der Benutzersicherheit und die Verwaltung von Datenbankspeicher und -speicher ausführen. Sie können auch Performance- und Statusinformationen zur Datenbank prüfen.

Siehe auch: Unter Oracle AI Database – Erste Schritte mit Performance Tuning erfahren Sie, wie Sie die Datenbank mit EM Express verwalten.

SQL*Plus

SQL*Plus ist ein interaktives Tool für Batchabfragen, das in jeder Oracle AI Database-Installation enthalten ist.

Es verfügt über eine Befehlszeilen-Benutzeroberfläche, die bei der Anmeldung bei der Datenbank als Client agiert. SQL*Plus verfügt über eigene Befehle und eine eigene Umgebung. Sie können SQL-, PL/SQL-, SQL*Plus- und Betriebssystembefehle eingeben und ausführen, um Aufgaben wie die folgenden auszuführen:

Sie können SQL*Plus verwenden, um Berichte interaktiv und als Batchprozesse zu generieren. Sie können die Ergebnisse in eine Textdatei, auf dem Bildschirm oder zum Durchsuchen im Internet in eine HTML-Datei ausgeben. Mit der HTML-Ausgabefunktion können Sie Berichte dynamisch generieren.

Siehe auch: SQL*Plus-Benutzerdokumentation und -Referenz, um mehr über SQL*Plus zu erfahren

Tools für Datenbankinstallation und -konfiguration

Oracle stellt mehrere Tools bereit, um die Installation und Konfiguration von Oracle AI Database-Software zu vereinfachen.

In der folgenden Tabelle werden unterstützte Tools beschrieben.

Tabelle 1: Tools für die Datenbankinstallation und -konfiguration

Tool Beschreibung Weitere Infos
Oracle Universal Installer (OUI) OUI ist ein GUI-Utility, mit dem Sie Oracle AI Database-Software anzeigen, installieren und deinstallieren können. Die Onlinehilfe führt Sie durch die Installation. Onlinehilfe, die Sie durch die Installation führt
Assistent für Datenbank-Upgrade (DBUA) DBUA führt Sie interaktiv durch ein Datenbankupgrade und konfiguriert die Datenbank für das neue Release. DBUA automatisiert das Upgrade, indem alle Aufgaben ausgeführt werden, die normalerweise manuell ausgeführt werden. DBUA gibt Empfehlungen für Konfigurationsoptionen wie Tablespaces und das Online-Redo-Log aus. Oracle AI Database 2 Day DBA, um zu erfahren, wie Sie eine Datenbank mit DBUA upgraden
Datenbank-Konfigurationsassistent (DBCA) DBCA stellt eine grafische Oberfläche und den geführten Workflow zum Erstellen und Konfigurieren einer Datenbank dar. Mit diesem Tool können Sie eine Datenbank aus von Oracle bereitgestellten Templates erstellen oder eine eigene Datenbank und eigene Templates erstellen. Oracle AI Database - Administratordokumentation, in der Sie erfahren, wie Sie eine Datenbank mit DBCA erstellen

Tools für Oracle Net-Konfiguration und -Administration

Oracle Net Services stellt unternehmensweite Connectivity-Lösungen in verteilten, heterogenen Computing-Umgebungen dar. Mit Oracle Net, einer Komponente von Oracle Net Services, wird eine Netzwerksession von der Clientanwendung zu einer Datenbank ermöglicht.

Mit den folgenden Tools können Sie Oracle Net Services konfigurieren und verwalten:

Siehe:

Tools für Datenverschiebung und -analyse

Oracle AI Database umfasst mehrere Dienstprogramme zur Unterstützung bei der Datenverschiebung und -analyse.

Beispiel: Mit Datenbankutilitys können Sie:

Tabelle 2: Aufgaben zum Verschieben und Analysieren von Daten

Aufgabe Weitere Infos
Daten aus Betriebssystemdateien in Oracle AI Database-Tabellen laden "SQL*Loader"
Daten und Metadaten von einer Datenbank in eine andere verschieben "Oracle Data Pump - Export und Import"
Redo Log-Dateien über eine SQL-Schnittstelle abfragen "Oracle LogMiner"
Oracle AI Database-Daten verwalten "ADR-Befehlsdolmetscher (ADRCI)"

Weitere Aufgaben umfassen die Durchführung von Integritätsprüfungen der physischen Datenstruktur in einer Offlinedatenbank oder Datendatei mit DBVERIFY oder die Änderung der Datenbank-ID (DBID) oder des Datenbanknamens für eine operative Datenbank mit dem DBNEWID-Utility.

Hinweis:

Siehe:

SQL*Loader

SQL*Loader lädt Daten aus externen Dateien, die als Datendateien bezeichnet werden (nicht zu verwechseln mit den internen Datendateien der Datenbank), in Datenbanktabellen. Es verfügt über eine leistungsstarke Datenanalyse-Engine, die kaum Einschränkungen des Formats der Daten in der Datendateien vorgibt.

Mit SQL*Loader können Sie:

Eine typische SQL*Loader-Session übernimmt als Eingabe eine SQL*Loader-Kontrolldatei und eine oder mehrere Datendateien. Die Ausgabe ist eine Oracle-Datenbank, eine Log-Datei, eine fehlerhafte Datei und möglicherweise eine Discard-Datei. Die folgende Abbildung veranschaulicht den Ablauf einer typischen SQL*Loader-Session.

Abbildung 1: SQL*Loader-Session

Beschreibung der Abbildung cncpt271.gif

Sie können auch den SQL*Loader-Expressmodus verwenden, der aktiviert wird, wenn Sie den Parameter table im SQL*Loader-Befehl angeben, wie im folgenden Beispiel dargestellt:

% sqlldr hr table=employees

Es ist keine Kontrolldatei zulässig, was die Verwendung von SQL*Loader vereinfacht. Anstatt eine Kontrolldatei zu parsen, verwendet SQL*Loader die Tabellenspaltendefinitionen, um die Eingabedatentypen zu bestimmen. SQL*Loader nimmt mehrere Default-Annahmen vor, einschließlich Zeichensatz, Feldbegrenzungszeichen und Namen von Daten, Log-Dateien und fehlerhaften Dateien. Sie können viele der Standardwerte mit Befehlszeilenparametern überschreiben.

Siehe:

Oracle Data Pump exportieren und importieren

Mit Oracle Data Pump können Daten und Metadaten schnell von einer Datenbank in eine andere verschoben werden.

Diese Technologie ist die Grundlage für die folgenden Oracle AI Database-Dienstprogramme zur Datenverschiebung:

Oracle Data Pump besteht aus den folgenden eindeutigen Teilen:

In der folgenden Abbildung wird dargestellt, wie Oracle Data Pump mit SQL*Loader und externen Tabellen integriert wird. Wie gezeigt, ist SQL*Loader in die API für externe Tabellen und die Data Pump-API integriert, um Daten in externe Tabellen zu laden. Clients wie Oracle Enterprise Manager Cloud Control (Cloud Control) und Transportable Tablespaces können die Oracle Data Pump-Infrastruktur verwenden.

Abbildung 2: Oracle Data Pump-Architektur

Beschreibung der Abbildung cncpt261.png

Siehe:

Oracle LogMiner

Mit Oracle LogMiner können Sie Redo Log-Dateien über eine SQL-Schnittstelle abfragen.

Mögliche Anwendungen für Daten in Redo Log-Dateien umfassen:

Der Zugriff auf LogMiner erfolgt über eine Befehlszeilenschnittstelle oder über die Oracle LogMiner Viewer-GUI, die Bestandteil von Enterprise Manager ist.

Siehe auch: Oracle AI Database Utilities, um mehr über LogMiner zu erfahren

ADR Command Interpreter (ADRCI)

ADRCI ist ein Befehlszeilenutility, mit dem Sie Probleme untersuchen, Health-Check-Berichte anzeigen sowie First-Failure-Daten in ein Package integrieren und in Oracle Support hochladen können.

Sie können das Utility auch verwenden, um die Namen der Tracedateien im Automatic Diagnostic Repository (ADR) anzuzeigen und das Alertlog anzuzeigen. ADRCI verfügt über einen umfangreichen Befehlssatz, den Sie interaktiv oder in Skripten verwenden können.

Siehe:

Themen für Datenbankadministratoren

In diesem Abschnitt werden Themen behandelt, die für DBAs am wichtigsten sind und an anderer Stelle im Handbuch nicht behandelt wurden.

Backup und Wiederherstellung

Backup und Recovery sind Konzepte, Prozeduren und Strategien zum Schutz der Datenbank vor Datenverlust, die durch Mediafehler oder Benutzerfehler verursacht werden.

Ein Backup ist eine Kopie von Daten. Ein Backup kann wichtige Teile der Datenbank enthalten, wie Datendateien, die Serverparameterdatei und die Kontrolldatei. Ein Beispielszenario für Backup und Recovery ist ein ausgefallenes Festplattenlaufwerk, das den Verlust einer Datendatei verursacht. Wenn ein Backup der verlorenen Datei vorhanden ist, können Sie sie wiederherstellen und wiederherstellen. Die Vorgänge, die an der Wiederherstellung von Daten in den Zustand vor dem Verlust beteiligt sind, werden als Medien-Recovery bezeichnet.

Der vorliegende Abschnitt umfasst die folgenden Themen:

Siehe:

Backup- und Recovery-Techniken

Mit Recovery Manager oder benutzerverwalteten Techniken können Sie eine Oracle-Datenbank sichern, wiederherstellen und wiederherstellen.

Die Hauptunterschiede zwischen den beiden Ansätzen sind wie folgt:

Siehe:

Recovery Manager-Architektur

Auf RMAN und Oracle Secure Backup kann sowohl über die Befehlszeile als auch über Enterprise Manager Cloud Control (Cloud Control) zugegriffen werden.

Cloud Control bietet eine grafische Frontend- und Planungsfunktion für RMAN. Sie geben Jobparameter ein und geben dann einen Jobplan an. Cloud Control führt RMAN zum angegebenen Zeitpunkt oder zu dem angegebenen Wiederholungsintervall aus, um die Backup- und Recovery-Vorgänge auszuführen. Cloud Control ermöglicht den Zugriff auf RMAN über eine Reihe von Assistenten. Diese Assistenten führen Sie durch eine Vielzahl von Recovery-Prozeduren, die auf einer Analyse Ihrer Datenbank, Ihrer verfügbaren Backups und Ihrer Daten-Recovery-Ziele basieren.

Mit Cloud Control können Sie die in dieser Dokumentation beschriebenen einfacheren Wiederherstellungs- und Recovery-Szenarios ausführen. Sie können auch anspruchsvollere Wiederherstellungs- und Recovery-Techniken wie Point-in-Time Recovery und Oracle Flashback-Vorgänge verwenden, die eine effiziente Reparatur von Medienfehlern und Benutzerfehlern ermöglichen. Die Verwendung von Cloud Control ist oft einfacher als der RMAN-Befehlszeilenclient.

Die folgende Grafik zeigt eine RMAN-Beispielarchitektur. Der über Cloud Control zugängliche RMAN-Client verwendet Serversessions in einer Zieldatenbank, um Daten auf Datenträger oder Band zu sichern. RMAN kann einen externen Recovery-Katalog mit Backupmetadaten aktualisieren.

Abbildung 3: RMAN-Architektur

Beschreibung der Abbildung cncpt318.gif

Unabhängig davon, welche Backup- und Recovery-Technik Sie verwenden, empfiehlt Oracle, einen Fast Recovery-Bereich zu konfigurieren. Dieses datenbankverwaltete Verzeichnis, Dateisystem oder Oracle ASM-Datenträgergruppe zentralisiert Backup- und Recovery-Dateien, einschließlich aktiver Kontrolldateien, Online- und archivierter Redo-Logdateien und Backups. Recovery-Komponenten von Oracle AI Database interagieren mit dem Fast Recovery-Bereich, um die Wiederherstellbarkeit der Datenbank sicherzustellen.

Siehe:

Datenbankbackups

Datenbankbackups können physisch oder logisch sein.

Physische Backups, die in einer Backup- und Recovery-Strategie das Hauptanliegen sind, sind Kopien physischer Datenbankdateien. Sie können physische Backups mit RMAN- oder Betriebssystem-Utilitys erstellen.

Im Gegensatz dazu enthalten logische Backups Tabellen, Stored Procedures und andere logische Daten. Sie können logische Daten mit einem Oracle AI Database-Utility wie Data Pump Export extrahieren und in einer Binärdatei speichern. Logische Backups können physische Backups ergänzen.

Physische Backups haben eine große Granularität und eine begrenzte Transportfähigkeit, sind jedoch sehr schnell. Logische Backups haben eine feine Granularität und vollständige Transportierbarkeit, sind jedoch langsamer als physische Backups.

Vollständige und teilweise Datenbankbackups

Ein gesamtes Datenbankbackup ist ein Backup jeder Datendatei in der Datenbank sowie der Kontrolldatei. Ganze Datenbankbackups sind der häufigste Backup-Typ.

Ein partielles Datenbankbackup enthält eine Teilmenge der Datenbank: einzelne Tablespaces oder Datendateien. Ein Tablespace Backup ist ein Backup aller Datendateien in einem Tablespace oder in mehreren Tablespaces. Tablespace-Backups, unabhängig davon, ob sie konsistent oder inkonsistent sind, sind nur gültig, wenn die Datenbank im ARCHIVELOG-Modus ausgeführt wird, da Redo erforderlich ist, um den wiederhergestellten Tablespace mit dem Rest der Datenbank konsistent zu machen.

Konsistente und inkonsistente Backups

Ein Backup der gesamten Datenbank ist konsistent oder inkonsistent.

In einem konsistenten Backup haben alle Lese-/Schreibdatendateien und Kontrolldateien dieselbe Checkpoint-SCN, sodass sichergestellt ist, dass diese Dateien alle Änderungen bis zu dieser SCN enthalten. Diese Art von Backup erfordert kein Recovery, nachdem es wiederhergestellt wurde.

Ein konsistentes Backup der Datenbank ist nur nach einem konsistenten Herunterfahren möglich und ist die einzige gültige Backupoption für eine Datenbank, die im NOARCHIVELOG-Modus ausgeführt wird. Für andere Backupoptionen ist ein Media Recovery aus Gründen der Konsistenz erforderlich. Dies ist ohne Anwendung archivierter Redo Log-Dateien nicht möglich. Hinweis: Wenn Sie ein konsistentes Backup der gesamten Datenbank wiederherstellen, ohne Redo anzuwenden, gehen alle Transaktionen verloren, die nach dem Backup vorgenommen wurden.

In einem inkonsistenten Backup verfügen Lese-/Schreibdatendateien und Kontrolldateien nicht garantiert über dieselbe Checkpoint-SCN, sodass Änderungen fehlen können. Alle Online-Backups sind notwendigerweise inkonsistent, da Datendateien während der Backups geändert werden können.

Inkonsistente Backups bieten eine überragende Verfügbarkeit, da Sie die Datenbank nicht herunterfahren müssen, um Backups zu erstellen, die die Datenbank vollständig schützen. Wenn die Datenbank im ARCHIVELOG-Modus ausgeführt wird und Sie die archivierten Redo-Logs und Datendateien sichern, können inkonsistente Backups die Grundlage für eine solide Backup- und Recovery-Strategie sein.

Siehe:

Backupsets und Imagekopien

Der RMAN-Befehl BACKUP generiert Imagekopien oder Backupsets.

Die Backup-Typen unterscheiden sich wie folgt:

Siehe auch: Oracle AI Database Backup and Recovery - Benutzerdokumentation, um mehr über Backupsets und Imagekopien zu erfahren

Datenreparatur

Während mehrere Probleme den normalen Betrieb einer Datenbank stoppen oder I/O-Vorgänge beeinträchtigen können, erfordern nur einige Probleme einen Eingriff des DBA und eine Datenreparatur.

Datenreparatur ist in der Regel in den folgenden Fällen erforderlich:

In der Regel haben Sie mehrere Möglichkeiten, die vorhergehenden Probleme zu lösen. In diesem Abschnitt werden einige dieser Lösungen zusammengefasst.

Siehe:

Oracle Flashback-Technologie

Oracle AI Database bietet eine Gruppe von Funktionen, die als Oracle Flashback-Technologie bekannt sind und die das Anzeigen früherer Datenstatus und das zeitnahe Aufwickeln von Daten unterstützen, ohne dass Backups wiederhergestellt werden müssen.

Abhängig von den Datenbankänderungen können Flashback-Features unerwünschte Änderungen oft schneller rückgängig machen und weniger Auswirkungen auf die Verfügbarkeit haben als das Media Recovery. Die folgenden Flashback-Features sind am wichtigsten für Backup und Recovery:

Siehe:

Block Media-Recovery

Block Media Recovery ist eine Methode zum Wiederherstellen und Wiederherstellen beschädigter Datenblöcke, während Datendateien online sind.

Eine Blockbeschädigung ist ein Datenblock, der sich nicht in einem erkannten Oracle-Format befindet oder dessen Inhalt intern nicht konsistent ist. Wenn Sie Blockbeschädigungen erkennen und nur wenige Blöcke beschädigt sind, ist das Block-Recovery möglicherweise dem Recovery von Datendateien vorzuziehen.

Siehe:

Wiederherstellung von Datendateien

Die Wiederherstellung von Datendateien repariert eine verlorene oder beschädigte aktuelle Datendatei oder Kontrolldatei. Es kann auch Änderungen wiederherstellen, die verloren gehen, wenn ein Tablespace ohne die Option OFFLINE NORMAL offline ging.

Ein Media Recovery ist erforderlich, wenn Sie ein Backup einer Datendatei oder Kontrolldatei wiederherstellen oder eine Datendatei ohne die Option OFFLINE NORMAL offline gesetzt wird. Die Datenbank kann nicht geöffnet werden, wenn Online-Datendateien ein Media Recovery benötigen. Eine Datendatei, die ein Media Recovery erfordert, kann auch nicht online gesetzt werden, bis das Media Recovery abgeschlossen ist.

Um ein physisches Backup einer Datendatei oder Kontrolldatei wiederherzustellen, müssen Sie sie rekonstruieren und für Oracle AI Database verfügbar machen. Um ein Backup wiederherzustellen, wenden Sie archivierte Redo Log-Dateien an, um verlorene Änderungen wiederherzustellen. RMAN kann Datendateien auch mit inkrementellen Backups wiederherstellen, die nur Datenblöcke enthalten, die nach einem vorherigen Backup geändert wurden.

Im Gegensatz zum Instance Recovery, bei dem Änderungen automatisch auf Onlinedateien angewendet werden, muss das Media Recovery von einem Benutzer aufgerufen werden und archivierte Redo Log-Dateien auf zurückgeschriebene Backups anwenden. Media Recovery von Datendateien kann nur für Offlinedatendateien oder Datendateien in einer Datenbank ausgeführt werden, die nicht von einer Datenbankinstanz geöffnet wird.

Das Recovery von Datendateien unterscheidet sich je nachdem, ob alle Änderungen angewendet werden:

Siehe:

Zero Data Loss Recovery Appliance

Die Cloud-basierte Zero Data Loss Recovery Appliance, allgemein als Recovery Appliance bekannt, ist ein Engineered System, das Datenverluste und Backup-Overhead für alle Oracle Databases im Unternehmen drastisch reduziert.

Die Recovery Appliance ist in RMAN integriert und stellt eine zentralisierte Backup- und Recovery-Strategie für eine große Anzahl von Datenbanken bereit. Dabei werden Hardware und Speicher in der Cloud verwendet, die fehlertolerant sind. Die Recovery Appliance validiert Backups kontinuierlich auf Wiederherstellbarkeit.

Vorteile von Recovery Appliance

Eine zentralisierte Recovery Appliance führt die meisten Datenbankbackups und -wiederherstellungen durch, wodurch die Speicherauslastung, Performance und Verwaltbarkeit von Backups effizienter wird.

Die Hauptvorteile sind:

Recovery Appliance-Umgebung

Eine geschützte Datenbank ist eine Clientdatenbank, die Daten in einer Recovery Appliance sichert.

Die folgende Abbildung zeigt eine Beispielumgebung, die sechs geschützte Datenbanken und zwei Recovery Appliances umfasst. Jede Datenbank verwendet das Zero Data Loss Recovery Appliance-Backupmodul (Recovery Appliance-Backupmodul) für ihre Backups. Dieses Modul ist eine von Oracle bereitgestellte SBT-Library, mit der RMAN Backups über das Netzwerk an die Recovery Appliance überträgt.

Abbildung 4: Recovery Appliance-Umgebung

Beschreibung der Abbildung amagd_vm_025.png

Die Recovery Appliance-Metadatendatenbank, die sich auf jeder Recovery Appliance befindet, verwaltet Metadaten, die im Recovery-Katalog gespeichert sind. Alle geschützten Datenbanken, die Backups an Recovery Appliance senden, müssen diesen Recovery-Katalog verwenden. Die Backups befinden sich im Recovery Appliance-Speicherort, einem Set von Oracle ASM-Datenträgergruppen. Hinweis: Datenbanken können Recovery Appliance als Recovery-Katalog verwenden, ohne sie auch als Backup-Repository zu verwenden.

Administratoren verwalten und überwachen die Umgebung mit Cloud Control. Cloud Control bietet eine zentrale Ansicht des gesamten Backup-Lebenszyklus für jede Datenbank, unabhängig davon, ob Backups auf Datenträger, Band oder einer anderen Recovery Appliance gespeichert sind.

Speicherverwaltung

Zur Speicherverwaltung gehört die Verwaltung optimaler Größen für die Speicherstrukturen für die Oracle-Instanzen, während sich der Bedarf an der Datenbank ändert. Initialisierungsparametereinstellungen bestimmen, wie der SGA- und Instanz-PGA-Speicher verwaltet wird. Abbildung 22-5 zeigt einen Entscheidungsbaum für Speicherverwaltungsoptionen. In den folgenden Abschnitten werden die Optionen ausführlich erläutert.

Abbildung 5: Speicherverwaltungsmethoden

Beschreibung der Abbildung cncpt242.gif

Automatic Memory Management

Bei der automatischen Speicherverwaltung verwaltet Oracle AI Database den SGA- und Instanz-PGA-Speicher vollständig automatisch. Diese Methode ist die einfachste und wird von Oracle dringend empfohlen.

Die einzigen benutzerdefinierten Steuerelemente sind der Initialisierungsparameter für die Zielspeichergröße (MEMORY_TARGET) und der optionale Initialisierungsparameter für die maximale Speichergröße (MEMORY_MAX_TARGET). Oracle AI Database optimiert die Größe des Zielspeichers und verteilt den Speicher nach Bedarf zwischen der SGA und der Instanz-PGA.

Die SGA kann den In-Memory Column Store (IM-Spaltenspeicher) oder den memoptimize pool enthalten, die beide optional sind. Größe des IM-Spaltenspeichers mit dem Initialisierungsparameter INMEMORY_SIZE und des Memoptimize-Pools mit dem Initialisierungsparameter MEMOPTIMIZE_POOL_SIZE unabhängig von der verwendeten Speicherverwaltungsmethode. Die Größe des IM-Spaltenspeichers ist Memoptimize-Pool, der IM Speicherziel enthalten ist, aber nicht vom automatischen Skalierungsalgorithmus verwaltet wird. Beispiel: Wenn Sie MEMORY_TARGET auf 5 GB und INMEMORY_SIZE auf 1 GB setzen, beträgt das Gesamtspeicherziel 5 GB (nicht 6 GB), und INMEMORY_SIZE ist immer 1 GB.

Die folgende Grafik zeigt eine Datenbank, die manchmal Jobs verarbeitet, die von Onlinebenutzern und manchmal von Batchjobs weitergeleitet wurden. Mit der automatischen Speicherverwaltung passt die Datenbank die Größe des Großen Pools und des Datenbankpuffercaches automatisch an, je nachdem, welcher Jobtyp ausgeführt wird. Beachten Sie, dass die Grafik den IM-Spaltenspeicher oder den Memoptimierungsbereich nicht darstellt.

Abbildung 6: Automatic Memory Management

Beschreibung der Abbildung cncpt256.gif

Wenn Sie eine Datenbank mit DBCA erstellen und die grundlegende Installationsoption auswählen, aktiviert Oracle AI Database standardmäßig die automatische Speicherverwaltung.

Siehe:

Shared Memory-Verwaltung der SGA

Sie können die Größe der SGA manuell steuern, indem Sie die SGA-Größe mit automatischer Shared Memory-Verwaltung festlegen oder die SGA-Komponenten manuell optimieren.

Wenn die automatische Speicherverwaltung nicht aktiviert ist, muss das System die Shared Memory-Verwaltung der SGA verwenden. Shared Memory Management ist in einer der folgenden Formen möglich:

Siehe:

Speicherverwaltung der Instanz-PGA

Wenn die automatische Speicherverwaltung nicht aktiviert ist, verwendet Oracle AI Database entweder automatische oder manuelle PGA-Speicherverwaltung.

Die folgenden Modi sind für die Verwaltung des PGA-Speichers möglich:

Siehe auch: Oracle AI Database Performance Tuning Guide enthält Informationen zur PGA-Speicherverwaltung

Zusammenfassung der Speicherverwaltungsmethoden

Die Speicherverwaltung erfolgt entweder automatisch oder manuell.

Wenn Sie die automatische Speicherverwaltung nicht aktivieren, müssen Sie separat eine Speicherverwaltungsmethode für die SGA und eine für die PGA konfigurieren. Hinweis: Wenn die automatische Speicherverwaltung für die Datenbankinstanz als Ganzes deaktiviert ist, aktiviert Oracle Database standardmäßig die automatische PGA-Speicherverwaltung.

Die folgende Tabelle enthält den Initialisierungsparameter INMEMORY_SIZE und den Initialisierungsparameter MEMOPTIMIZE_POOL_SIZE. Beide steuern Speicherbereiche, die optional sind.

Tabelle 3: Speicherverwaltungsmethoden

Instanz SGA PGA Beschreibung Initialisierungsparameter
Automatisch n/v n/v Die Datenbank optimiert die Größe der Instanz basierend auf einer einzelnen Instanzzielgröße.

Sie legen Folgendes fest:

  • Gesamte Speicherzielgröße für die Datenbankinstanz (MEMORY_TARGET)

  • Optionale maximale Speichergröße für die Datenbankinstanz (MEMORY_MAX_TARGET)

  • Optionale Größe für den IM-Spaltenspeicher (INMEMORY_SIZE) in der SGA

n/v Automatisch Automatisch

Die Datenbank optimiert die SGA automatisch basierend auf einem SGA-Ziel.

Die Datenbank optimiert die PGA automatisch basierend auf einem PGA-Ziel.

Sie legen Folgendes fest:

  • SGA-Zielgröße (SGA_TARGET)

  • Optionale maximale SGA-Größe (SGA_MAX_SIZE)

  • Optionale Größe für den IM-Spaltenspeicher (INMEMORY_SIZE) in der SGA

  • Optionale Größe für den memoptimize-Pool in der SGA (MEMOPTIMIZE_POOL_SIZE)

  • PGA-Aggregatzielgröße (PGA_AGGREGATE_TARGET)Fußzeile 1

Die Datenbank konfiguriert den Initialisierungsparameter PGA_AGGREGATE_LIMIT automatisch. Sie können diesen Parameter manuell festlegen.

n/v Automatisch Manuell

Die Datenbank optimiert die SGA automatisch basierend auf einem SGA-Ziel.

Sie steuern die PGA manuell und legen die maximale Größe des Arbeitsbereichs für jeden SQL-Operatortyp fest.

Sie legen Folgendes fest:

  • SGA-Zielgröße (SGA_TARGET)

  • Optionale maximale SGA-Größe (SGA_MAX_SIZE)

  • Optionale Größe für den IM-Spaltenspeicher in der SGA (INMEMORY_SIZE)

  • Optionale Größe für den memoptimize-Pool in der SGA (MEMOPTIMIZE_POOL_SIZE)

  • PGA-Arbeitsbereichsparameter, wie SORT_AREA_SIZE, HASH_AREA_SIZE und BITMAP_MERGE_AREA_SIZE
n/v Manuell Automatisch

Sie steuern die SGA manuell, indem Sie einzelne Komponentengrößen festlegen.

Die Datenbank optimiert die PGA automatisch basierend auf einem PGA-Ziel.

Sie legen Folgendes fest:

  • Shared Pool-Größe (SHARED_POOL_SIZE)

  • Puffercachegröße (DB_CACHE_SIZE)

  • Große Pool-Größe (LARGE_POOL_SIZE)

  • Java-Pool-Größe (JAVA_POOL_SIZE)

  • Optionale Größe für den IM-Spaltenspeicher (INMEMORY_SIZE) in der SGA

  • Optionale Größe für den memoptimize-Pool in der SGA (MEMOPTIMIZE_POOL_SIZE)

  • PGA-Aggregatzielgröße (PGA_AGGREGATE_TARGET)Fußzeile 2

Die Datenbank konfiguriert den Initialisierungsparameter PGA_AGGREGATE_LIMIT automatisch. Sie können diesen Parameter manuell festlegen.

n/v Manuell Manuell

Sie müssen die SGA-Komponentengrößen manuell konfigurieren.

Sie steuern die PGA manuell und legen die maximale Größe des Arbeitsbereichs für jeden SQL-Operatortyp fest.

Sie müssen die SGA-Komponentengrößen manuell konfigurieren. Sie legen Folgendes fest:

  • Shared-Pool-Größe (SHARED_POOL_SIZE)

  • Puffercachegröße (DB_CACHE_SIZE)

  • Große Pool-Größe (LARGE_POOL_SIZE)

  • Java-Poolgröße (JAVA_POOL_SIZE)

  • Optionale Größe für den IM-Spaltenspeicher (INMEMORY_SIZE) in der SGA

  • Optionale Größe für den memoptimize-Pool in der SGA (MEMOPTIMIZE_POOL_SIZE)

  • PGA-Arbeitsbereichsparameter, wie SORT_AREA_SIZE, HASH_AREA_SIZE und BITMAP_MERGE_AREA_SIZE

Fußnote 1

Die Datenbank konfiguriert den Initialisierungsparameter PGA_AGGREGATE_LIMIT automatisch. Sie können diesen Parameter auch manuell festlegen.

Fußnote 2

Die Datenbank konfiguriert den Initialisierungsparameter PGA_AGGREGATE_LIMIT automatisch. Sie können diesen Parameter auch manuell festlegen.

Siehe auch: Oracle AI Database Administrator's Guide, da die automatische Speicherverwaltung nicht auf allen Plattformen verfügbar ist

Resource Management und Aufgabenplanung

Oracle AI Database bietet Tools, die Sie bei der Verwaltung von Ressourcen und bei der Planung von Aufgaben unterstützen, um die Auswirkungen auf Benutzer zu reduzieren.

In einer Datenbank mit vielen aktiven Benutzern ist die RessourcenAdministration ein wichtiger Bestandteil der Datenbankverwaltung. Sessions, die übermäßige Ressourcen verbrauchen, können andere Sessions daran hindern, ihre Arbeit auszuführen. Ein verwandtes Problem ist, wie Aufgaben so geplant werden, dass sie zur besten Zeit ausgeführt werden. Oracle AI Database bietet Tools zur Lösung dieser Probleme.

Database Resource Manager

Oracle AI Database Resource Manager (der Resource Manager) bietet eine granulare Kontrolle über Datenbankressourcen, die Benutzeraccounts, Anwendungen und Services zugewiesen sind. Der Resource Manager fungiert in erster Linie als Gatekeeper, wodurch einige Jobs langsam ausgeführt werden, sodass andere schnell ausgeführt werden können.

Das PL/SQL-Package DBMS_RESOURCE_MANAGER löst viele Probleme bei der Ressourcenzuweisung, die ein Betriebssystem nicht gut verwaltet, einschließlich:

Der Resource Manager hilft dabei, die vorhergehenden Probleme zu überwinden, indem er der Datenbank mehr Kontrolle über die Zuweisung von Hardwareressourcen und die Priorisierung der Arbeit in der Datenbank gibt. Sie können Sessions basierend auf Sessionattributen in Gruppen klassifizieren und diesen Gruppen dann Ressourcen zuweisen, um die Hardwareauslastung zu optimieren. Mit Resource Manager können Sie Grenzwerte für den PDB-Speicherverbrauch festlegen.

Die Zuteilung von Ressourcen zu Benutzern geschieht nach einem Ressourcenplan, der vom Datenbankadministrator festgelegt wurde. Der Plan gibt an, wie die Ressourcen auf Ressourcen-Nutzungsgruppen verteilt werden sollen. Hierbei handelt es sich um Benutzersessions, die nach Ressourcenanforderungen gruppiert sind. Eine Ressourcenplananweisung verknüpft eine Ressourcen-Nutzungsgruppe mit einem Plan und gibt an, wie Ressourcen der Gruppe zugewiesen werden sollen. Abbildung 22-7 zeigt einen einfachen Ressourcenplan für ein Unternehmen, das OLTP-Anwendungen und Reportinganwendungen tagsüber gleichzeitig ausführt. Der derzeit aktive Plan DAYTIME weist CPU-Ressourcen drei Ressourcennutzungsgruppen zu. Insbesondere wird OLTP 75% der CPU-Zeit zugewiesen, REPORTS 15% und OTHER_GROUPS 10% erhalten.

Abbildung 7: Einfacher Ressourcenplan

Beschreibung der Abbildung admin078.gif

Ein Problem, das Resource Manager lösen kann, sind unkontrollierte Abfragen, die mit SQL Monitor überwacht werden können. Mit Resource Manager können Sie Schwellenwerte zur Identifizierung und Reaktion auf fehlgeleitete SQL-Anweisungen angeben. Beispiel: Sie können Schwellenwerte für CPU-Zeit, verstrichene Zeit, physische oder logische I/Os und PGA-Auslastung durch jeden Vordergrundprozess in einer Nutzungsgruppe angeben. Als Antwort kann Resource Manager zu einer Consumer-Gruppe mit niedrigerer Priorität wechseln, die SQL-Anweisung beenden oder die Schwellenwertverletzung protokollieren.

Siehe:

CPU-Management

Ab Oracle AI Database 26ai bietet Oracle eine alternative Methode für die CPU-Ressourcenverwaltung, die auf allen Datenbankinstanzen auf dem Server ausgeführt wird.

In früheren Releases bot Oracle eine Methode der CPU-Ressourcenverwaltung an, die innerhalb einer Datenbankinstanz ausgeführt wurde. Ab Oracle AI Database 26ai können Sie RESOURCE_MANAGER_CPU_SCOPE festlegen, um den Geltungsbereich der CPU-Ressourcenverwaltung zu steuern. Mit diesem Parameter können Sie zwischen den beiden Steuermethoden wählen.

Wenn Sie RESOURCE_MANAGER_CPU_SCOPE auf SERVER_WIDE setzen, wird die instanzübergreifende CPU-Ressourcenverwaltung auf Serverebene aktiviert. Diese Methode wurde in Oracle AI Database 26ai eingeführt und kann verwendet werden, wenn mehrere Datenbankinstanzen einen Linux-Server gemeinsam verwenden. Es ermöglicht die CPU-Ressourcenverwaltung für alle Datenbankinstanzen auf dem Server. Mit dieser Methode konfiguriert Oracle automatisch Linux-Kontrollgruppen (Cgroups) mit den gewünschten CPU-Sharing- und CPU-Auslastungslimits und platziert Datenbanksessions dann in die entsprechenden Cgroups.

RESOURCE_MANAGER_CPU_SCOPE ist standardmäßig auf INSTANCE_ONLY gesetzt.

Siehe:

Oracle Scheduler

Mit Oracle Scheduler (dem Scheduler) können Datenbankadministratoren und Anwendungsentwickler kontrollieren, wann und wo verschiedene Aufgaben in der Datenbankumgebung ausgeführt werden.

Der Scheduler bietet komplexe Funktionen für die Unternehmensplanung, mit denen Sie:

Programmobjekte (Programme) enthalten Metadaten zu dem Befehl, den der Scheduler ausführt, einschließlich der Standardwerte für alle Argumente. Ausführungsplanobjekte (Zeitpläne) enthalten Informationen über Ausführungsdatum und -zeit sowie Wiederholungsmuster. Jobobjekte (Jobs) verknüpfen ein Programm mit einem Zeitplan. Um zu definieren, was wann ausgeführt wird, ordnen Sie Beziehungen zwischen Programmen, Zeitplänen und Jobs zu.

Der Scheduler wird als eine Gruppe von Funktionen und Prozeduren im PL/SQL-Package DBMS_SCHEDULER implementiert. Scheduler-Objekte erstellen und bearbeiten Sie mit diesem Package oder mit Enterprise Manager. Da Scheduler-Objekte Standard-Datenbankobjekte sind, können Sie den Zugriff auf diese Objekte mit System- und Objektberechtigungen steuern. In Abbildung 22-8 wird die grundlegende Architektur des Schedulers dargestellt. Die Job-Tabelle ist ein Container für alle Jobs mit einer Tabelle pro Datenbank. Der Hintergrundprozess des Jobkoordinators wird bei Bedarf automatisch gestartet und gestoppt. Untergeordnete Jobprozesse werden vom Koordinator erweckt, wenn ein Job ausgeführt werden muss. Die untergeordneten Prozesse sammeln Metadaten aus der Jobtabelle und führen den Job aus.

Abbildung 8: Scheduler-Komponenten

Beschreibung der Abbildung admin062.gif

Siehe:

Performance und Optimierung

Als DBA sind Sie verantwortlich für die Performance der Oracle-Datenbank. In der Regel resultieren Performanceprobleme aus inakzeptablen Antwortzeiten, d.h. der Zeit bis zum Abschluss einer bestimmten Workload, oder dem Durchsatz, d.h. dem Umfang der Arbeit, die in einer bestimmten Zeit abgeschlossen werden kann.

Typische Probleme sind:

Das allgemeine Ziel der Optimierung besteht in der Regel darin, die Reaktionszeit zu verbessern, den Durchsatz zu erhöhen oder beides. Ein spezifisches und messbares Ziel könnte "die Antwortzeit der angegebenen SELECT-Anweisung auf weniger als 5 Sekunden reduzieren" lauten. Ob dieses Ziel erreicht werden kann, hängt von Faktoren ab, die möglicherweise vom DBA kontrolliert werden. Im Allgemeinen ist das Tuning der Aufwand, spezifische, messbare und erreichbare Optimierungsziele zu erreichen, indem Datenbankressourcen so effizient wie möglich verwendet werden.

Die Performance-Methode von Oracle basiert auf der Identifizierung und Beseitigung von Engpässen in der Datenbank und der Entwicklung effizienter SQL-Anweisungen. Die Anwendung der Oracle-Performancemethode umfasst folgende Aufgaben:

In diesem Abschnitt werden wesentliche Aspekte der Leistungsoptimierung von Oracle AI Database beschrieben, einschließlich der Verwendung von Advisorn. Oracle AI Database Advisor geben spezifische Empfehlungen zu wichtigen Fragen des Datenbankmanagements, u.a. zu Speicherplatz, Performance und Undo-Management.

Datenbank-Selbstüberwachung

Die Selbstüberwachung erfolgt, wenn die Datenbank ihren regulären Betrieb ausführt und sicherstellt, dass die Datenbank über auftretende Probleme informiert ist. Oracle AI Database kann einen vom Server generierten Alert senden, um Sie über ein bevorstehendes Problem zu informieren.

Alerts werden automatisch generiert, wenn ein Problem auftritt oder wenn Daten nicht mit erwarteten Werten für Metriken übereinstimmen, wie physische Lesevorgänge pro Sekunde oder SQL-Antwortzeit. Eine Metrik ist die Änderungsrate in einer kumulativen Statistik. Servergenerierte Alerts können auf benutzerdefinierten Schwellenwerten basieren oder weil ein Ereignis aufgetreten ist.

Servergenerierte Alerts identifizieren nicht nur das Problem, sondern empfehlen manchmal, wie das gemeldete Problem gelöst werden kann. Ein Beispiel ist ein Alert, dass der Speicherplatz im Fast Recovery-Bereich knapp wird. Dabei wird empfohlen, veraltete Backups zu löschen oder zusätzlichen Plattenspeicherplatz hinzuzufügen.

Siehe auch: Oracle AI Database Administrator's Guide

Automatic Workload Repository (AWR)

Automatic Workload Repository (AWR) ist ein Repository historischer Performancedaten, das kumulative Statistiken für das System, Sessions, einzelne SQL-Anweisungen, Segmente und Services enthält.

AWR-Statistiken bilden die Grundlage für das Performance Tuning. Durch die Automatisierung der Erfassung von Datenbankstatistiken zur Problemerkennung und -optimierung dient AWR als Grundlage für die Selbstverwaltung der Datenbank.

Wie in der folgenden Grafik dargestellt, speichert die Datenbank die aktuellen AWR-Statistiken in der SGA. Standardmäßig sammelt der MMON-Prozess Statistiken jede Stunde und erstellt einen AWR-Snapshot. Ein AWR-Snapshot ist ein Set von Performancestatistiken, die zu einem bestimmten Zeitpunkt erfasst werden. Die Datenbank schreibt Snapshots in den Tablespace SYSAUX. AWR verwaltet Snapshot-Speicherplatz und löscht ältere Snapshots gemäß einer konfigurierbaren Snapshot-Aufbewahrungs-Policy.

Abbildung 9: Automatic Workload Repository (AWR)

Beschreibung der Abbildung cncpt279.gif

Eine AWR-Baseline ist eine Sammlung von Statistikraten, die in der Regel über einen Zeitraum hinweg verwendet werden, in dem das System bei Spitzenlast gut abschneidet. Sie können ein Paar oder einen Bereich von AWR-Snapshots als Baseline angeben. Wenn Sie mithilfe eines AWR-Berichts Statistiken vergleichen, die während einer Periode schlechter Performance mit einer Baseline erfasst wurden, können Sie Probleme diagnostizieren.

Eine automatisierte Wartungsinfrastruktur namens AutoTask veranschaulicht, wie Oracle Database AWR für die Selbstverwaltung verwendet. Durch die Analyse von AWR-Daten kann AutoTask den Bedarf an Wartungsaufgaben ermitteln und deren Ausführung in Oracle Scheduler-Wartungsfenstern planen. Beispiele für Aufgaben sind das Sammeln von Statistiken für den Optimizer und das Ausführen von Automatic Segment Advisor.

Siehe:

Automatic Database Monitor (ADDM)

Mit in AWR (Automatic Workload Repository) erfassten Statistiken diagnostiziert ADDM automatisch und proaktiv die Datenbankperformance und bestimmt, wie identifizierte Probleme gelöst werden können. Sie können ADDM auch manuell ausführen. Automatic Database Diagnostic Monitor (ADDM) ist ein Selbstdiagnose-Advisor, der in Oracle Database integriert wurde.

ADDM verfolgt einen ganzheitlichen Ansatz für die Systemperformance und verwendet die Zeit als gemeinsame Währung zwischen den Komponenten. ADDM identifiziert Bereiche von Oracle Database, die am meisten Zeit beanspruchen. Beispiel: Die Datenbank verbringt möglicherweise übermäßig viel Zeit mit dem Warten auf freie Datenbankpuffer. ADDM führt einen Drilldown durch, um die Ursache von Problemen und nicht nur die Symptome zu ermitteln, und meldet die Auswirkungen des Problems auf Oracle Database insgesamt. Minimaler Overhead tritt während des Prozesses auf.

In vielen Fällen empfiehlt ADDM Lösungen und quantifiziert die erwarteten Performancevorteile. ADDM kann beispielsweise Änderungen an Hardware, Datenbankkonfiguration, Datenbankschema oder Anwendungen empfehlen. Wenn eine Empfehlung abgegeben wird, meldet ADDM den Zeitvorteil. Die Verwendung von Zeit als Maßnahme ermöglicht Vergleiche von Problemen oder Empfehlungen.

Neben der Meldung potenzieller Performanceprobleme dokumentiert ADDM Bereiche der Datenbank, die keine Probleme darstellen. Unterkomponenten wie I/O und Speicher, die sich nicht wesentlich auf die Datenbankperformance auswirken, werden frühzeitig aus dem Klassifizierungsbaum entfernt. ADDM listet diese Unterkomponenten auf, sodass Sie schnell erkennen können, dass die Ausführung von Aktionen in diesen Bereichen wenig Vorteile bietet.

Siehe auch: Oracle AI Database – Erste Schritte mit Performance Tuning und Oracle AI Database Performance Tuning Guide

Active Session History (ASH)

Active Session History (ASH) erfasst jede Sekunde aktive Datenbanksessions und schreibt die Daten in den Speicher und den persistenten Speicher. ASH ist ein integraler Bestandteil des Datenbank-Selbstverwaltungs-Frameworks und eignet sich besonders zur Diagnose von Performanceproblemen.

Im Gegensatz zu Statistiken auf Instance-Ebene, die von Automatic Workload Repository (AWR) erfasst werden, sammelt die Datenbank ASH-Statistiken auf Session-Ebene. Eine aktive Session ist eine Session, die CPU verwendet und nicht auf ein Ereignis in der Wait-Klasse "inaktiv" wartet.

Mit Enterprise Manager oder SQL-Skripten können Sie ASH-Berichte generieren, die Sessionstatistiken sammeln, die über einen bestimmten Zeitraum gesammelt wurden. Sie können ASH-Berichte für folgende Zwecke verwenden:

Beispiel: Ein Benutzer benachrichtigt Sie, dass die Datenbank zwischen 10:00 und 10:02 Uhr langsam war. Die 2-minütige Performancebeeinträchtigung stellt jedoch einen kleinen Teil des AWR-Snapshot-Intervalls von 10:00 Uhr und 11:00 Uhr dar und wird in ADDM-Ergebnissen nicht angezeigt. ASH-Berichte können helfen, die Quelle des vorübergehenden Problems zu identifizieren.

Siehe auch: Oracle AI Database – Erste Schritte mit Performance Tuning und Oracle AI Database Performance Tuning Guide

Anwendungs- und SQL-Tuning

Oracle Database automatisiert den SQL-Tuning-Prozess vollständig.

ADDM identifiziert SQL-Anweisungen, die ungewöhnlich hohe Systemressourcen belegen und daher Performanceprobleme verursachen. Darüber hinaus erfasst AWR automatisch die wichtigsten SQL-Anweisungen in Bezug auf CPU- und Shared Memory-Auslastung. Die Identifizierung von High-Load-SQL-Anweisungen erfolgt automatisch und erfordert keinen Eingriff.

EXPLAIN PLAN-Anweisung

Mit Tools wie der Anweisung EXPLAIN PLAN können Sie Ausführungspläne anzeigen, die vom Optimizer ausgewählt wurden.

EXPLAIN PLAN zeigt den Abfrageplan für die angegebene SQL-Abfrage an, wenn sie jetzt in der aktuellen Session ausgeführt wurde. Weitere Tools sind Oracle Enterprise Manager und der SQL*Plus-Befehl AUTOTRACE.

Siehe auch: Oracle AI Database SQL Language Reference, um mehr über EXPLAIN PLAN zu erfahren

Optimizer Statistics Advisor

Optimizer Statistics Advisor ist eine Diagnosesoftware, die analysiert, wie Sie derzeit Statistiken sammeln, die Effektivität vorhandener Statistiksammeljobs und die Qualität der gesammelten Statistiken. Optimizer Statistics Advisor verwendet dasselbe Advisor Framework wie Automatic Database Diagnostic Monitor (ADDM), SQL Performance Analyzer und andere Advisor.

Optimizer Statistics Advisor bietet die folgenden Vorteile gegenüber dem herkömmlichen Ansatz, der auf Best Practices basiert:

Optimizer Statistics Advisor verwaltet Regeln, die von Oracle bereitgestellte Standards sind, mit denen der Advisor seine Prüfungen ausführt. Die Regeln enthalten Best Practices von Oracle basierend auf dem aktuellen Featureset. Wenn sich die Best Practices von Release zu Release ändern, ändern sich auch die Optimizer Statistics Advisor-Regeln. Auf diese Weise liefert der Berater immer die aktuellsten Empfehlungen.

Optimizer Statistics Advisor prüft den Prozess zur Erfassung von Statistiken und generiert dann einen Bericht über Ergebnisse, die Verstöße gegen die Regeln darstellen. Wenn der Advisor Empfehlungen ausgibt und Aktionen auf der Grundlage dieser Empfehlungen vorschlägt, können Sie die Aktionen entweder automatisch implementieren oder ein editierbares, ausführbares PL/SQL-Skript generieren.

Die Advisor Task wird automatisch im Wartungsfenster ausgeführt. Sie können sie aber auch bei Bedarf ausführen.

Siehe:

SQL Tuning Advisor

Die Schnittstelle für das automatische SQL-Tuning ist SQL Tuning Advisor, der automatisch während der Systemwartungsfenster als Wartungsaufgabe ausgeführt wird.

Während jeder automatischen Ausführung wählt der Advisor High-Load-SQL-Abfragen in der Datenbank und generiert Empfehlungen für das Tuning dieser Abfragen.

SQL Tuning Advisor-Empfehlungen fallen in die folgenden Kategorien:

Ein SQL-Profil enthält zusätzliche Statistiken, die für eine SQL-Anweisung spezifisch sind, und ermöglicht dem Optimizer, einen besseren Ausführungsplan zu generieren. Im Wesentlichen ist ein SQL-Profil eine Methode zur Analyse einer Abfrage. Sowohl die Zugriffspfad- als auch die SQL-Strukturanalyse sind nützlich, um eine Anwendung zu optimieren, die sich in der Entwicklung befindet, oder eine selbst entwickelte Produktionsanwendung.

Ein Hauptvorteil von SQL Tuning Advisor besteht darin, dass Lösungen vom Optimizer und nicht von externen Tools stammen. Daher wird das Tuning von der Datenbankkomponente durchgeführt, die für die Ausführungspläne und die SQL-Performance verantwortlich ist. Der Tuning-Prozess kann vergangene Ausführungsstatistiken einer SQL-Anweisung berücksichtigen und die Optimizer-Einstellungen für diese Anweisung anpassen.

Siehe:

SQL Access Advisor

Mit SQL Access Advisor können Sie SQL-Abfragen analysieren und Möglichkeiten zur Optimierung von Schemaobjekten oder zur Optimierung von Abfragen festlegen.

SQL Access Advisor bietet Ratschläge zur Optimierung von Datenzugriffspfaden. Insbesondere wird empfohlen, wie die Datenbankperformance durch Partitionierung, Materialized Views, Indizes und Materialized View Logs verbessert werden kann.

Schemaobjekte wie Partitionen und Indizes sind für die Optimierung komplexer, datenintensiver Abfragen unerlässlich. Die Erstellung und Verwaltung dieser Objekte kann jedoch zeitaufwendig sein, und der Speicherplatzbedarf kann erheblich sein. Mit SQL Access Advisor können Sie Leistungsziele erreichen, indem Sie Datenstrukturen für eine angegebene Workload empfehlen.

Sie können SQL Access Advisor in Enterprise Manager mit einem Assistenten oder mit dem Package DBMS_ADVISOR ausführen. DBMS_ADVISOR besteht aus einer Sammlung von Analyse- und Advisory-Funktionen und -Prozeduren, die aus einem beliebigen PL/SQL-Programm aufgerufen werden können.

Siehe auch: Oracle AI Database – Erste Schritte mit Performance Tuning und Oracle AI Database SQL Tuning Guide

SQL-Planmanagement

Verwalten Sie SQL-Ausführungspläne, indem Sie mit SQL Plan Management nur getestete und geprüfte Pläne ausführen.

Standardmäßig wird SQL Plan Management (SPM) Evolve Advisor täglich im geplanten Wartungsfenster ausgeführt, sortiert alle nicht akzeptierten Pläne und führt Testausführungen so vieler Pläne wie möglich durch. SPM Evolve Advisor wählt den kostengünstigsten akzeptierten Plan in der SQL-Planbaseline aus, um ihn mit jedem nicht akzeptierten Plan zu vergleichen. Wenn der nicht akzeptierte Plan ausreichend besser funktioniert als der vorhandene akzeptierte Plan, akzeptiert der Advisor ihn.

Wenn Hochfrequenz-SPM aktiviert ist, wird der SPM Evolve Advisor in einer periodischen Hintergrundaufgabe außerhalb des Wartungsfensters ausgeführt, um zeitnahere Leistungsverbesserungen zu ermöglichen. Die Hochfrequenzaufgabe identifiziert SQL-Anweisungen, die wichtige Systemressourcen verwenden, und prüft, ob ein zuvor verwendeter SQL-Ausführungsplan besser funktioniert. In diesem Fall wird eine neue SQL-Plan-Baseline erstellt, um den früheren SQL-Ausführungsplan durchzusetzen und die SQL-Performance-Regression zu reparieren.

Wenn Oracle Database 26ai aktiviert ist, startet Echtzeit-SPM die Performanceanalyse sofort, wenn eine SQL-Anweisung einen neuen SQL-Ausführungsplan verwendet. Wenn ein vorher erstellter SQL-Ausführungsplan besser funktioniert, wird sofort eine neue SQL-Planbaseline erstellt, ohne dass hierfür eine Hintergrundaufgabe erforderlich ist.

Siehe: