Utility dbaascli in Exadata Cloud Infrastructure verwenden

Hier erfahren Sie, wie Sie das Utility dbaascli in Exadata Cloud Infrastructure verwenden.

Utility dbaascli in Exadata Cloud Infrastructure verwenden

Mit dem Utility dbaascli können Sie verschiedene Datenbanklebenszyklus- und Administrationsvorgänge in Exadata Cloud Infrastructure ausführen: Sie können das Kennwort eines Datenbankbenutzers ändern, eine Datenbank starten, integrierbare Datenbanken (PDBs) verwalten und vieles mehr.

Zum Skalieren von Ressourcen müssen Sie die Oracle Cloud Infrastructure-Konsole oder die Befehlszeilenschnittstelle verwenden. Die Funktionen des Utilitys dbaascli stehen zusätzlich zur und separat von der Konsole, API oder Befehlszeilenschnittstelle (CLI) zur Verfügung. Sofern nicht anders angegeben, benötigen Sie root-Zugriff auf dbaascli, um alle Administrationsbefehle auszuführen.

Um das Utility verwenden zu können, müssen Sie mit einer virtuellen Maschine von Exadata Cloud Infrastructure verbunden sein. Weitere Informationen finden Sie unter Verbindungen mit einer Exadata Cloud Infrastructure-Instanz herstellen.

Um die mit dbaascli verfügbaren Befehle abzurufen, führen Sie dbaascli --help aus.

Um die befehlsspezifische Hilfe abzurufen, führen Sie den dbaascli-Befehl --help aus. Beispiel: dbaascli database create --help.

Die Befehle und befehlsspezifische Informationen finden Sie in der Dokumentation unter dbaascli-Befehlsreferenz.

Datenbanken mit dbaascli erstellen

Mit dbaascli können Sie eine Oracle-Datenbank erstellen, indem Sie zunächst ein Oracle Database Home mit der gewünschten Version und anschließend eine Datenbank in diesem Oracle Database Home erstellen

Verfügbare Softwareimages und Versionen für Database und Grid Infrastructure auflisten

Um eine Liste der verfügbaren unterstützten Versionen für das Patching zu erstellen, verwenden Sie den Befehl dbaascli cswlib showImages.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli cswlib showImages --product database

    In der Befehlsausgabe werden die verfügbaren Datenbanksoftwareimages aufgeführt.

    dbaascli cswlib showImages --product grid

    Die Befehlsausgabe listet die verfügbaren Grid-Softwareimages auf.

  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli cswlib showImages.

Beispiel 6-1: dbaascli cswlib showImages

[root@dg11lrg1 dbhome_1]# dbaascli cswlib showImages
DBAAS CLI version <version>
Executing command cswlib
      showImagesJob id: 00e89b1a-1607-422c-a920-22f44bec1953Log file location:
      /var/opt/oracle/log/cswLib/showImages/dbaastools_2022-05-11_08-49-12-AM_46941.log

############
List of Available Database Images
#############

17.IMAGE_TAG=18.17.0.0.0  
   VERSION=18.17.0.0.0  
   DESCRIPTION=18c JAN 2022 DB Image

18.IMAGE_TAG=19.10.0.0.0  
   VERSION=19.10.0.0.0  
   DESCRIPTION=19c JAN 2021 DB Image

19.IMAGE_TAG=19.11.0.0.0  
   VERSION=19.11.0.0.0  
   DESCRIPTION=19c APR 2021 DB Image

20.IMAGE_TAG=19.12.0.0.0
  VERSION=19.12.0.0.0
  DESCRIPTION=19c JUL 2021 DB Image

21.IMAGE_TAG=19.13.0.0.0  
  VERSION=19.13.0.0.0  
  DESCRIPTION=19c OCT 2021 DB Image

Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.
dbaascli execution completed

Oracle Database Home erstellen

Um ein Oracle Database Home mit der gewünschten Version zu erstellen, verwenden Sie den Befehl dbaascli dbhome create.

Hinweis

Sie können ein Oracle Database Home mit einem angegebenen Oracle Home-Namen erstellen. Wenn Sie nichts angeben, wird dieser automatisch festgelegt (empfohlen).
  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli dbhome create --version Oracle Home Version --imageTag image Tag Value
    Dabei gilt:
    • --version gibt die Oracle Database-Version an.
    • --imageTag gibt das Imagetag des zu verwendenden Images an.
    Beispiel:
    dbaascli dbhome create --version 19.9.0.0.0
    Hinweis

    Die Angabe von imageTag ist optional. Informationen zum Anzeigen der Imagetags finden Sie unter dbaascli cswlib showImages. Imagetags entsprechen in der Regel der Version der Datenbank. Das Imagetag wird jedoch für Fälle beibehalten, in denen mehrere Images für dieselbe Version freigegeben werden müssen, die jeweils spezifische Kundenanforderungen erfüllen.
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli dbhome create.

Oracle-Datenbank im angegebenen Oracle Database Home erstellen

Um eine Oracle-Datenbank im angegebenen Oracle Database Home mit der gewünschten Version zu erstellen, verwenden Sie den Befehl dbaascli database create.

Mit dem Befehl dbaascli database create können Sie:
  • Eine Containerdatenbank (CDB) oder Nicht-Containerdatenbank erstellen
  • Eine CDB mit integrierbaren Datenbanken (PDBs) erstellen
  • Eine Oracle-Datenbank mit dem angegebenen Zeichensatz erstellen
  • Oracle-Datenbanken auf einer Teilmenge von Clusterknoten erstellen
    Hinweis

    Datenbanken, die auf einer Teilmenge von Knoten erstellt wurden, werden nicht in der OCI-Konsole angezeigt.
  • Oracle-Datenbanken der Version 12.1.0.2 oder höher mit dem Releaseupdate JAN 2021 oder höher erstellen. Für Datenbanken mit niedrigeren Versionen wird die auf der OCI-Konsole-basierende API empfohlen.
  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli database create --dbName database name --oracleHome Oracle Home Path
    Dabei gilt:
    • --dbName gibt den Namen der Datenbank an.
    • --oracleHome gibt das Oracle Home-Verzeichnis an.
    Verwenden Sie den folgenden Befehl, um eine CDB zu erstellen:
    dbaascli database create --dbName database name --oracleHome Oracle Home Path
    Verwenden Sie den folgenden Befehl, um eine Nicht-CDB zu erstellen:
    dbaascli database create --dbName database name --oracleHome Oracle Home Path --createAsCDB false

    Geben Sie bei entsprechender Aufforderung die sys- und tde-Kennwörter ein.

  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli database create.

Vor dem Erstellen einer Oracle-Datenbank erforderliche Prüfungen ausführen

Um Voraussetzungsprüfungen auszuführen, verwenden Sie die Befehlsoption --executePrereqs. Damit werden nur die Voraussetzungsprüfungen ausgeführt, ohne dass die Oracle-Datenbank erstellt wird.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli database create --dbName database name --oracleHome Oracle Home Path --executePrereqs
    Dabei gilt:
    • --dbName gibt den Namen der Datenbank an.
    • --oracleHome gibt das Oracle Home-Verzeichnis an.
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli database create.

Oracle-Datenbankerstellungsvorgang fortsetzen oder rückgängig machen

Um einen nicht erfolgreichen Datenbankerstellungsvorgang fortzusetzen oder rückgängig zu machen, verwenden Sie die Befehlsoption --resume bzw. --revert.

Beispiel:
dbaascli database create --dbName database name --oracleHome Oracle Home Path --resume
Hinweis

  • Stellen Sie bei Verwendung der Befehlsoptionen --resume oder --revert sicher, dass Sie denselben Befehl aus demselben Knoten verwenden, der auch für den Erstellungsvorgang verwendet wurde.
  • Sie können die Datenbankerstellung nur dann mit "resume" fortsetzen, wenn der Schritt nach der Datenbankerstellung nicht erfolgreich ist.

Datenbankkennwörter ändern

Führen Sie diese Schritte aus, um das SYS-Kennwort oder das TDE-Wallet-Kennwort zu ändern.

Das Kennwort, das Sie beim Erstellen einer neuen Exadata Cloud Infrastructure-Instanz oder -Datenbank im Feld Datenbank-Admin-Kennwort angeben, wird als Kennwort für die SYS-, SYSTEM-, TDE-Wallet- und PDB-Administratoranmeldedaten festgelegt. Führen Sie die folgenden Schritte aus, um die Kennwörter für eine vorhandene Datenbank zu ändern.

Hinweis

Wenn Sie Data Guard für eine Datenbank aktivieren, müssen das SYS-Kennwort und das TDE-Wallet-Kennwort der Primär- und der Standbydatenbank identisch sein.
Hinweis

Wenn Sie das SYS-Kennwort mit dbaascli ändern, wird sichergestellt, dass die Backup-/Restore-Automatisierung die Kanäle über alle Knoten im Cluster hinweg parallelisieren kann.

So ändern Sie das SYS-Kennwort einer Exadata Cloud Infrastructure-Datenbank

  1. Melden Sie sich bei der virtuellen Maschine von Exadata Cloud Infrastructure als opc an.
  2. Führen Sie den folgenden Befehl aus:
    sudo dbaascli database changepassword --dbname database_name --user SYS

So ändern Sie Datenbankkennwörter in einer Data Guard-Umgebung

  1. Führen Sieden folgenden Befehl auf der Primärdatenbank aus:
    dbaascli database changePassword —dbName <dbname> --user SYS --prepareStandbyBlob true --blobLocation <location to create the blob file>
  2. Kopieren Sie die erstellte BLOB-Datei in alle Standbydatenbanken, und aktualisieren Sie den Dateieigentümer auf den Benutzer oracle.
  3. Führen Sieden folgenden Befehl auf allen Standbydatenbank aus:
    dbaascli database changePassword —dbName <dbname> --user SYS --standbyBlobFromPrimary <location of copies the blob file>

So ändern Sie das TDE-Wallet-Kennwort einer Exadata Cloud Infrastructure-Datenbank

  1. Melden Sie sich bei der virtuellen Maschine von Exadata Cloud Infrastructure als opc an.
  2. Führen Sie den folgenden Befehl aus:
    sudo dbaascli tde changepassword --dbname database_name

Exadata Cloud Infrastructure-Softwareimages mit dem Utility dbaascli verwalten

Sie können die Oracle-Datenbanksoftwareimages in einer Exadata Cloud Infrastructure-Instanz auflisten und herunterladen, die dann für das Provisioning eines Datenbank-Homes verwendet werden können.

Hinweis

Sie können benutzerdefinierte Datenbanksoftwareimages für Ihre Exadata Cloud Infrastructure-Instanzen mit der Konsole oder API erstellen. Diese Images werden in Object Storage gespeichert und können zum Provisioning eines Datenbank-Homes in der Exadata-Instanz verwendet werden. Weitere Informationen finden Sie unter Oracle-Datenbanksoftwareimages.

Sie können die Version der Oracle-Binärdateien steuern, die beim Provisioning einer neuen Datenbank in einer Exadata Cloud Infrastructure-Instanz installiert werden, indem Sie die Softwareimages im System verwalten. Oracle stellt eine Bibliothek mit Cloud-Softwareimages bereit, die Sie mit dem Utility dbaascli anzeigen und in die Instanz herunterladen können.

Verfügbare Softwareimages und Versionen für Database und Grid Infrastructure auflisten

Um eine Liste der verfügbaren unterstützten Versionen für das Patching zu erstellen, verwenden Sie den Befehl dbaascli cswlib showImages.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli cswlib showImages --product database

    In der Befehlsausgabe werden die verfügbaren Datenbanksoftwareimages aufgeführt.

    dbaascli cswlib showImages --product grid

    Die Befehlsausgabe listet die verfügbaren Grid-Softwareimages auf.

  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli cswlib showImages.

Beispiel 6-2: dbaascli cswlib showImages

[root@dg11lrg1 dbhome_1]# dbaascli cswlib showImages
DBAAS CLI version <version>
Executing command cswlib
      showImagesJob id: 00e89b1a-1607-422c-a920-22f44bec1953Log file location:
      /var/opt/oracle/log/cswLib/showImages/dbaastools_2022-05-11_08-49-12-AM_46941.log

############
List of Available Database Images
#############

17.IMAGE_TAG=18.17.0.0.0  
   VERSION=18.17.0.0.0  
   DESCRIPTION=18c JAN 2022 DB Image

18.IMAGE_TAG=19.10.0.0.0  
   VERSION=19.10.0.0.0  
   DESCRIPTION=19c JAN 2021 DB Image

19.IMAGE_TAG=19.11.0.0.0  
   VERSION=19.11.0.0.0  
   DESCRIPTION=19c APR 2021 DB Image

20.IMAGE_TAG=19.12.0.0.0
  VERSION=19.12.0.0.0
  DESCRIPTION=19c JUL 2021 DB Image

21.IMAGE_TAG=19.13.0.0.0  
  VERSION=19.13.0.0.0  
  DESCRIPTION=19c OCT 2021 DB Image

Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.
dbaascli execution completed

So laden Sie ein Softwareimage herunter

Sie können verfügbare Softwareimages in die Exadata Cloud Infrastructure-Instanz herunterladen, indem Sie den Unterbefehl cswlib download des Utilitys dbaascli ausführen.

  1. Stellen Sie als Benutzer opc eine Verbindung zu einem Compute Node her. Detaillierte Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.
  2. Starten Sie die Befehlsshell des Root-Benutzers:
    $ sudo -s
    #
  3. Führen Sie den Befehl dbaascli mit dem Unterbefehl cswlib download aus:
    # dbaascli cswlib download [--version <software_version>] [--imageTag <image tag
        value>]
    Der Befehl zeigt den Speicherort der Softwareimages an, die in die Exadata Cloud Infrastructure-Umgebung heruntergeladen werden.

    Optionale Parameter:

    • version gibt die Version der Oracle Database-Software an. Beispiel: 19.14.0.0.0.
    • imageTag gibt das Imagetag des Images an.
  4. Beenden Sie die Befehlshell des Benutzers "root":
    # exit
    $

Oracle Grid Infrastructure und Oracle-Datenbanken mit dbaascli patchen

Hier erfahren Sie, wie Sie mit dem Utility dbaascli Patching-Vorgänge für Oracle Grid Infrastructure und Oracle Database auf einem Exadata Cloud Infrastructure-System ausführen.

Datenbanken mit dbaascli patchen

Mit dbaascli können Sie Datenbanken patchen, indem Sie das Oracle Home patchen oder die Datenbank in ein Oracle Home mit der gewünschten Patchebene verschieben.

  • Oracle Home patchen (In-Place-Patching) Dadurch werden alle Datenbanken aktualisiert, die sich in dem Oracle Home befinden.
  • Datenbank in ein anderes Oracle Home mit der gewünschten Oracle Database-Softwareversion verschieben (Out-of-Place-Patching).
Datenbank-Home patchen (In-Place-Datenbank-Patching)

Um ein Oracle Home zu patchen, verwenden Sie den Befehl dbaascli dbHome patch.

Dadurch werden alle Datenbanken gepatcht, die im angegebenen Home ausgeführt werden, und die Datenbanken verbleiben nach Abschluss des Patchings in dem Home. Für die Verwendung des Befehls dbHome patch für In-Place-Patching-Vorgänge gilt Folgendes:
  • Sie können alle Datenbankknoten oder eine Teilmenge von Knoten patchen.
  • Das Patching von mehreren Knoten erfolgt im Rolling-Modus.
  • Optional können Sie einen Nur-Software-Patchvorgang ausführen. Sie können dann später datapatch starten, um die SQL-Aktionen nach dem Patchen auszuführen.
  • Sie können ein Oracle Home patchen, das eine oder mehrere Datenbanken enthält.

So patchen Sie ein Oracle Home (dbhome):

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli dbhome patch --oracleHome dbhome_path --targetVersion Oracle_Database_version
    Dabei gilt:
    • --oracleHome gibt den Pfad des zu patchenden Oracle Homes an.
    • --targetVersion gibt die zu patchende Oracle Database-Zielversion als fünf durch Punkte getrennte numerische Segmente an (Beispiel: 19.12.0.0.0).
    Beispiel:
    dbaascli dbhome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2 --targetVersion 19.9.0.0.0
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli dbHome patch.

Datenbank in ein anderes Oracle Home verschieben (Out-of-Place-Patching)

Um eine Oracle-Datenbank zu patchen, indem Sie sie in ein Oracle Home mit der gewünschten Patchebene verschieben, verwenden Sie den Befehl dbaascli database move.

Nachdem der Datenbankverschiebevorgang abgeschlossen ist, wird die Datenbank mit der Oracle Database-Softwareversion des Ziel-Oracle Homes ausgeführt.

So patchen Sie eine Datenbank durch Verschieben in ein anderes Oracle Home:

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli database move --oracleHome path_to_target_oracle_home --dbname database_name
    Dabei gilt:
    • --oracleHome gibt den Pfad des Ziel-Oracle Homes an, das die gewünschte Oracle Database-Softwareversion verwendet. Beachten Sie, dass das Ziel-Oracle Home in Ihrem System vorhanden sein muss, bevor Sie den Befehl database move verwenden.
    • --dbname gibt den Namen der zu verschiebenden Datenbank an.
    Beispiel:
    dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2 --dbname xyz
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli database move.

Oracle Grid Infrastructure patchen

Um einen Patch in Oracle Grid Infrastructure einzuspielen, verwenden Sie den Befehl grid patch.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli grid patch --targetVersion target_software_version_number

    Dabei gibt --targetVersion die Zielsoftwareversion an, auf die Oracle Grid Infrastructure gepatcht wird.

    Beispiel:
    dbaascli grid patch --targetVersion 19.11.0.0.0
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli grid patch.

Oracle Grid Infrastructure (GI) mit GI-Softwareimage patchen

Führen Sie das dieses Verfahren aus, um Oracle Grid Infrastructure (GI) mit dem GI-Softwareimage zu patchen.

Sie können Oracle Grid Infrastructure auch patchen, indem Sie zunächst ein gepatchtes Softwareimage erstellen und dann dieses Image für den Patching-Vorgang verwenden. Dies bietet den Vorteil, dass ein Image im Voraus außerhalb des Patching-Fensters erstellt werden kann. Diese Vorgehensweise hilft auch bei der Konfliktauflösung, da Konflikte zwischen den Patches während des Imageerstellungsprozesses hervorgehoben werden, ohne dass dies Auswirkungen auf das Patching-Fenster hat.

  1. Erstellen Sie ein gepatchtes Softwareimage.
    dbaascli grid patch --targetVersion <target_software_version_number> --createImage
    Nachdem Sie das gepatchte Softwareimage erstellt haben, kann es für den Patching-Vorgang verwendet werden.
  2. Führen Sie den Patching-Vorgang aus.
    dbaascli grid patch --targetVersion <target_software_version_number> --imageLocation <location_of_patched_software_image>

Verfügbare Softwareimages und Versionen für Database und Grid Infrastructure auflisten

Um eine Liste der verfügbaren unterstützten Versionen für das Patching zu erstellen, verwenden Sie den Befehl dbaascli cswlib showImages.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli cswlib showImages --product database

    In der Befehlsausgabe werden die verfügbaren Datenbanksoftwareimages aufgeführt.

    dbaascli cswlib showImages --product grid

    Die Befehlsausgabe listet die verfügbaren Grid-Softwareimages auf.

  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

    Weitere Einzelheiten zu erweiterten unterstützten Optionen finden Sie unter dbaascli cswlib showImages.

Beispiel 6-3: dbaascli cswlib showImages

[root@dg11lrg1 dbhome_1]# dbaascli cswlib showImages
DBAAS CLI version <version>
Executing command cswlib
      showImagesJob id: 00e89b1a-1607-422c-a920-22f44bec1953Log file location:
      /var/opt/oracle/log/cswLib/showImages/dbaastools_2022-05-11_08-49-12-AM_46941.log

############
List of Available Database Images
#############

17.IMAGE_TAG=18.17.0.0.0  
   VERSION=18.17.0.0.0  
   DESCRIPTION=18c JAN 2022 DB Image

18.IMAGE_TAG=19.10.0.0.0  
   VERSION=19.10.0.0.0  
   DESCRIPTION=19c JAN 2021 DB Image

19.IMAGE_TAG=19.11.0.0.0  
   VERSION=19.11.0.0.0  
   DESCRIPTION=19c APR 2021 DB Image

20.IMAGE_TAG=19.12.0.0.0
  VERSION=19.12.0.0.0
  DESCRIPTION=19c JUL 2021 DB Image

21.IMAGE_TAG=19.13.0.0.0  
  VERSION=19.13.0.0.0  
  DESCRIPTION=19c OCT 2021 DB Image

Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.
dbaascli execution completed

Vorabprüfung vor dem Patching von Datenbanken und Grid Infrastructure ausführen

Mit dem entsprechenden Vorabprüfungs-Flag können Sie eine Voraussetzungsprüfung (auch als "Vorabprüfung" bezeichnet) für die Befehle in diesem Thema durchführen.

Sie können die Vorabprüfungen für das Patching ausführen, ohne das eigentliche Patching vorzunehmen. Oracle empfiehlt, Vorabprüfungen auszuführen, um Softwareprobleme zu ermitteln, die ein erfolgreiches Patching verhindern könnten.

Um Patching-Vorabprüfungen auszuführen, stellen Sie zunächst eine Verbindung zu einer virtuellen Maschine in der Exadata Cloud Infrastructure-Instanz als Benutzer root her.

Vorabprüfung für Oracle Home-Patching (In-Place-Patching)

Verwenden Sie das Flag --executePrereqs mit dem Befehl dbaascli dbhome patch.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli dbhome patch --oracleHome dbhome_path --targetVersion Oracle_Database_version --executePrereqs
    Dabei gilt:
    • --oracleHome gibt den Pfad des vorab zu prüfenden Oracle Homes an.
    • --targetVersion gibt die zu patchende Oracle Database-Zielversion als fünf durch Punkte getrennte numerische Segmente an (Beispiel: 19.12.0.0.0).
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit
Vorabprüfung für Patching durch Datenbankverschiebung (Out-of-Place-Patching)

Verwenden Sie das Flag --executePrereqs mit dem Befehl dbaascli database move.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli database move --oracleHome path_to_target_oracle_home --dbname database_name --executePrereqs
    Dabei gilt:
    • --oracleHome gibt den Pfad des Ziel-Oracle Homes an, das die gewünschte Oracle Database-Softwareversion verwendet. Beachten Sie, dass das Ziel-Oracle Home in Ihrem System vorhanden sein muss, bevor Sie den Befehl database move verwenden.
    • --dbname gibt den Namen der zu verschiebenden Datenbank an.
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit
Vorabprüfung für Oracle Grid Infrastructure-Patching

Verwenden Sie das Flag --executePrereqs mit dem Befehl dbaascli grid patch.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den folgenden Befehl aus:
    dbaascli grid patch --targetVersion target_software_version_number --executePrereqs

    Dabei gibt --targetVersion die Zielversion der Software, auf die Oracle Grid Infrastructure gepatcht wird, als fünf durch Punkte getrennte numerische Segmente an. Beispiel: 19.12.0.0.0

  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

Patching-Vorgänge fortsetzen oder zurücksetzen

Sie können einen nicht erfolgreichen Patching-Vorgang fortsetzen oder zurücksetzen. Das Zurücksetzen eines Patches wird als Rollback bezeichnet.

Patchvorgang fortsetzen

Um einen Patchvorgang fortzusetzen, verwenden Sie das Flag --resume mit dem ursprünglichen Patching-Befehl.

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den ursprünglichen Patching-Befehl aus, um einen Patching-Vorgang fortzusetzen:
    Beispiel:
    dbaascli dbhome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2 --targetVersion 19.9.0.0.0 --resume
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit
Patchvorgang zurücksetzen

Verwenden Sie das Flag --rollback mit dem ursprünglichen Patching-Befehl, um einen Patchvorgang zurückzusetzen (Rollback).

  1. Stellen Sie als Benutzer opc eine Verbindung zur virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Führen Sie den ursprünglichen Patching-Befehl aus, um einen Patching-Vorgang zurückzusetzen (Rollback):
    Beispiel:
    dbaascli grid patch --targetVersion 19.11.0.0.0 --rollback
    Hinweis

    • Resume- und Rollback-Vorgänge werden für Oracle Home-Patching, Oracle Grid Infrastructure-Patching und Datenbankverschiebevorgänge unterstützt.
    • Wenn Sie einen Patching-Vorgang fortsetzen oder zurücksetzen, müssen Sie den entsprechenden Befehl auf demselben Knoten ausführen, auf dem der ursprüngliche Patching-Befehl ausgeführt wurde. Außerdem müssen Sie den ursprünglichen Befehl mit dem Flag --resume oder --rollback ausführen.
  4. Beenden Sie die Befehlsshell des Benutzers root:
    exit

Mit dbaascli Cloud-Tooling-Logs erfassen und Cloud-Tooling-Health Check durchführen

Mit dem dbaascli-Befehl diag können Sie dbaas-Tooling-Logs der Gast-VM für Exadata Database Service on Dedicated Infrastructure- und Exadata Database Service on Cloud@Customer-Systeme erfassen. Mit diesen Logs können Sie Probleme im Zusammenhang mit dbaas-Tooling beheben.

Mit dem Befehl diag können Sie dbaastools-Logs erfassen und auf allen Knoten in einem Exadata-Cluster einen Health Check ausführen. Beachten Sie, dass die Option --waitForCompletion ab Version 22.4.1 unterstützt wird.
Hinweis

  • Der dbaascli-Befehl diag muss als Benutzer root ausgeführt werden.
  • Wenn Sie den Befehl dbaascli diag collect auf einem einzelnen Knoten ausführen, werden Logdaten für alle Knoten erfasst.
  • Es wird empfohlen, die in diesem Thema dokumentierten Befehle für Befehle mit langer Ausführungszeit mit der Option --waitForCompletion auszuführen. Weitere Informationen zur Verwendung finden Sie in den Beispielen.

Informationen zum Aktualisieren von Exadata-Cloud-Tooling finden Sie unter dbaascli admin updateStack.

Beispiele für das Erfassen von Tooling-Logdaten

Der dbaascli-Befehl "dbaascli diag collect" verwendet die unten gezeigte Syntax zum Erfassen von Tooling-Logdaten:

Syntaxdetails finden Sie in der dbaascli-Befehlsreferenz unter dbaascli diag collect.

# dbaascli diag collect
DBAAS CLI version 24.1.1.0.0
Executing command diag collect
Job id: 92f33125-aa70-4ce2-94fb-64d8f1cbdc93
Session log: /var/opt/oracle/log/diag/collect/dbaastools_2023-12-14_07-20-44-PM_83383.log
Loading PILOT...
Session ID of the current execution is: 10
Log file location: /var/opt/oracle/log/diag/collect/pilot_2023-12-14_07-20-48-PM_83856
-----------------
..
---------- DIAG COLLECT PLUGIN RESULT ----------
{
  "collectedArchive with SHA256 CheckSum" : "{/var/opt/oracle/dbaas_acfs/diag_collect/artifacts_diag_cloudlogs_20231214-1920/diag_cloudlogs_20231214-1920_node1.zip=a0d049b87ab9e9cec2ab7d95ded4903bac818c81c8b6a46d295e1e75f4630e19}"
}
dbaascli execution completed
# dbaascli diag collect --waitForCompletion false
DBAAS CLI version 24.1.1.0.0
Executing command diag collect --waitForCompletion false
Job id: 5b556976-dba1-4be9-a4fe-4b58e69c1d96
Session log: /var/opt/oracle/log/diag/collect/dbaastools_2023-12-14_07-23-26-PM_98107.log
Job accepted. Use "dbaascli job getStatus --jobID 5b556976-dba1-4be9-a4fe-4b58e69c1d96" to check the job status.
Hinweis

Mit dem Jobstatusbefehl können Sie den Fortschritt überwachen.
# dbaascli diag collect --dbnames myOracleDatabase19cName
DBAAS CLI version 24.1.1.0.0
Executing command diag collect --dbnames myOracleDatabase19cName
Job id: 8e1d2667-4649-4384-8610-b6348d6548ac
Session log: /var/opt/oracle/log/diag/collect/dbaastools_2023-12-14_08-41-41-PM_88831.log
Loading PILOT...
Session ID of the current execution is: 12
Log file location: /var/opt/oracle/log/diag/collect/pilot_2023-12-14_08-41-45-PM_89361
-----------------
..
---------- DIAG COLLECT PLUGIN RESULT ----------
{
  "collectedArchive with SHA256 CheckSum" : "{/var/opt/oracle/dbaas_acfs/diag_collect/artifacts_diag_cloudlogs_20231214-2041/diag_cloudlogs_20231214-2041_node1.zip=9e50500089a74ca7cd8ae08550c06868e26e1cd9c52e808194256594f63397e4}"
}
dbaascli execution completed
# dbaascli diag collect --destLocation /tmp/test/
DBAAS CLI version 24.1.1.0.0
Executing command diag collect --destLocation /tmp/test/
Job id: f992afdf-415e-4b58-ab5b-9e38f8c2079d
Session log: /var/opt/oracle/log/diag/collect/dbaastools_2023-12-14_09-42-54-PM_16270.log
Loading PILOT...
Session ID of the current execution is: 14
Log file location: /var/opt/oracle/log/diag/collect/pilot_2023-12-14_09-42-58-PM_16777
-----------------
..
---------- DIAG COLLECT PLUGIN RESULT ----------
{
  "collectedArchive with SHA256 CheckSum" : "{/tmp/test/diag_collect/artifacts_diag_cloudlogs_20231214-2143/diag_cloudlogs_20231214-2143_node1.zip=8a26cffcfdd72c261660d4f736c615981856e357749d90751b94f3eda19a9a70}"
}
dbaascli execution completed
# dbaascli diag collect --startTime 2023-12-05T10:00:00 --endTime 2023-12-05T11:00:00
DBAAS CLI version 24.1.1.0.0
Executing command diag collect --startTime 2023-12-05T10:00:00 --endTime 2023-12-05T11:00:00
Job id: 70b03e50-98cc-4c2b-9684-1f82070bac88
Session log: /var/opt/oracle/log/diag/collect/dbaastools_2023-12-14_09-45-17-PM_42856.log
Loading PILOT...
Session ID of the current execution is: 15
Log file location: /var/opt/oracle/log/diag/collect/pilot_2023-12-14_09-45-21-PM_43526
-----------------
..
---------- DIAG COLLECT PLUGIN RESULT ----------
{
  "collectedArchive with SHA256 CheckSum" : "{/var/opt/oracle/dbaas_acfs/diag_collect/artifacts_diag_cloudlogs_20231214-2145/diag_cloudlogs_20231214-2145_node1.zip=b44cf3bfca1ab7a1629dd83098a7772790ab949e50dbb3950f0017e427d7bd05}"
}
dbaascli execution completed
# dbaascli diag collect --nodes node1,node2
DBAAS CLI version 24.1.1.0.0
Executing command diag collect --nodes node1,node2
Job id: fa70da09-3de6-4cc8-854c-a739b4fc2ceb
Session log: /var/opt/oracle/log/diag/collect/dbaastools_2023-12-14_09-46-58-PM_55884.log
Loading PILOT...
Session ID of the current execution is: 16
Log file location: /var/opt/oracle/log/diag/collect/pilot_2023-12-14_09-47-02-PM_56418
-----------------
..
---------- DIAG COLLECT PLUGIN RESULT ----------
{
  "collectedArchive with SHA256 CheckSum" : "{/var/opt/oracle/dbaas_acfs/diag_collect/artifacts_diag_cloudlogs_20231214-2147/diag_cloudlogs_20231214-2147_node1.zip=de2805c9c6c2af2d602395a84d37747935327b73a6c73052282665a8410eb41f}"
}
# dbaascli diag collect --components dbaastools
DBAAS CLI version 24.1.1.0.0
Executing command diag collect --components dbaastools
Job id: da941d3c-5191-4ced-b1bb-9b083fa75865
Session log: /var/opt/oracle/log/diag/collect/dbaastools_2023-12-14_09-47-23-PM_68256.log
Loading PILOT...
Session ID of the current execution is: 17
Log file location: /var/opt/oracle/log/diag/collect/pilot_2023-12-14_09-47-27-PM_68729
-----------------
..
---------- DIAG COLLECT PLUGIN RESULT ----------
{
  "collectedArchive with SHA256 CheckSum" : "{/var/opt/oracle/dbaas_acfs/diag_collect/artifacts_diag_cloudlogs_20231214-2147/diag_cloudlogs_20231214-2147_node1.zip=d1f290fb42c981935e1142ec059c2dbba8be2e0a9ffebc9eea83a6336abe2eed}"
}
dbaascli execution completed
# dbaascli diag collect --objectStoreBucketUri https://objectstorage.us-phoenix-1.oraclecloud.com/p/aL-IbIKQ1j6lWNftJc2rLoLh6o9bJgbZm8z0S--BeVuXaipSEEMISrSCfFrVEolG/n/intexadatateam/b/diag_collect_test/o/
DBAAS CLI version 24.1.1.0.0
Executing command diag collect --objectStoreBucketUri https://objectstorage.us-phoenix-1.oraclecloud.com/p/aL-IbIKQ1j6lWNftJc2rLoLh6o9bJgbZm8z0S--BeVuXaipSEEMISrSCfFrVEolG/n/intexadatateam/b/diag_collect_test/o/
Job id: 028151b7-cbc4-409a-9ec6-69affe10f3bb
Session log: /var/opt/oracle/log/diag/collect/dbaastools_2023-12-14_09-51-36-PM_2963.log
Loading PILOT...
Session ID of the current execution is: 20
Log file location: /var/opt/oracle/log/diag/collect/pilot_2023-12-14_09-51-40-PM_3555
-----------------
..
---------- DIAG COLLECT PLUGIN RESULT ----------
{
  "collectedArchive with SHA256 CheckSum" : "{/var/opt/oracle/dbaas_acfs/diag_collect/artifacts_diag_cloudlogs_20231214-2151/diag_cloudlogs_20231214-2151_node1.zip=71633e13ccd06de15cb26850bb0266cf0d869e259550515c5b1fb734c487b470}"
}
dbaascli execution completed

Beispiele für das Ausführen eines Health Checks

Mit dem dbaascli-Befehl dbaascli diag healthcheck können Sie einen Health Check auf allen Systemknoten ausführen.

Syntaxdetails finden Sie in der dbaascli-Befehlsreferenz unter dbaascli diag healthcheck.

# dbaascli diag healthcheck                
DBAAS CLI version MAIN
Executing command diag healthcheck
INFO: Starting diag healthcheck
INFO: Collected diag logs at: /var/opt/oracle/dbaas_acfs/diag_cloudlogs_20210322-2246.tar.gz
# dbaascli diag healthcheck --destLocation /tmp/test
DBAAS CLI version MAIN
Executing command diag healthcheck --destLocation /tmp/test
INFO: Starting diag healthcheck
INFO: Collected diag logs at: /tmp/test/diag_cloudlogs_20210322-2250.tar.gz
# dbaascli diag healthcheck --nodes rbcl1,rbcl2                   
DBAAS CLI version MAIN
Executing command diag healthcheck --nodes rbcl1,rbcl2
INFO: Starting diag healthcheck
INFO: Collected diag logs at: /var/opt/oracle/dbaas_acfs/diag_cloudlogs_20210421-1915.tar.gz
# dbaascli diag healthcheck --objectStoreBucketUri https://objectstorage.us-phoenix-1.oraclecloud.com/p/t0Z-kRV5pSmFzqnf-y5XhaAbM4LS82epeBnulKnCr31IeHVjxI9tOkntLF2kq7fP/n/MyNamespace/b/MyParBucket/o/
DBAAS CLI version MAIN
Executing command diag healthcheck --objectStoreBucketUri https://objectstorage.us-phoenix-1.oraclecloud.com/p/t0Z-kRV5pSmFzqnf-y5XhaAbM4LS82epeBnulKnCr31IeHVjxI9tOkntLF2kq7fP/n/MyNamespace/b/MyParBucket/o/
INFO: Collected diag logs at: https://objectstorage.us-phoenix-1.oraclecloud.com/p/t0Z-kRV5pSmFzqnf-y5XhaAbM4LS82epeBnulKnCr31IeHVjxI9tOkntLF2kq7fP/n/MyNamespace/b/MyParBucket/o/diag_cloudlogs_20210421-1839.tar.gz

Cloud-Tooling mit dbaascli aktualisieren

Führen Sie diese Schritte aus, um das Cloud-Tooling-Release für Oracle Exadata Database Service on Dedicated Infrastructure zu aktualisieren.

Cloudspezifisches Tooling wird auf den Exadata Cloud Infrastructure-Gast-VMs für lokale Vorgänge verwendet, darunter dbaascli-Befehle.

Das Cloud-Tooling wird automatisch von Oracle aktualisiert, wenn neue Releases verfügbar gemacht werden. Bei Bedarf können Sie die folgenden Schritte ausführen, um sicherzustellen, dass Sie die neueste Version der Cloud-spezifischen Tools auf allen virtuellen Maschinen im VM-Cluster verwenden.
Hinweis

Sie können das Cloud-spezifische Tooling aktualisieren, indem Sie ein Softwarepaket mit den aktualisierten Tools herunterladen und einspielen.
  1. Stellen Sie als Benutzer opc eine Verbindung zu einer virtuellen Maschine her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell mit dem Benutzer root:
    sudo -s
  3. Um ein Update auf das neueste verfügbare Cloud-Tooling-Release auszuführen, führen Sie den folgenden Befehl aus:
    dbaascli admin updateStack

    Mit diesem Befehl wird das Cloud-Tooling-Release auf allen Knoten des Clusters aktualisiert.

    Weitere Einzelheiten und andere verfügbare Optionen finden Sie unter dbaascli admin updateStack --help.

Doppelte Datenbank erstellen

Cloud-Datenbank mit dbaascli duplizieren

Sie können eine duplizierte Datenbank mit dbaascli erstellen. Diese neue Datenbank kann sich in derselben Cloud-Region wie die Quellregion oder in allen Regionen befinden. In den folgenden Schritten wird beschrieben, wie Sie eine doppelte Datenbank in der Cloud erstellen.

Hinweis

Wenn eine Datenbank mit OCI Vault für die TDE-Verschlüsselung konfiguriert ist und Sie eine Datenbank duplizieren möchten, lesen Sie die folgenden Abschnitte.

Duplizierung vorbereiten

Folgende Voraussetzungen müssen erfüllt sein:

  • Stellen Sie sicher, dass ein Netzwerkpfad eingerichtet ist, um über die Zeichenfolge EZConnect auf die Quelldatenbank zuzugreifen.
  • Kopieren Sie die TDE-Wallet-Datei (ewallet.p12 ) in den Zieldatenbankknoten. Der Knoten, auf dem Sie den Befehl dbaascli ausführen möchten.
  • Erstellen Sie bei Bedarf ein Oracle Home auf dem Zielknoten. Oracle Home-Version muss dieselbe Version wie die Quelle oder eine höhere RU-Version sein.

Voraussetzungsprüfungen ausführen

Um Voraussetzungsprüfungen auszuführen, verwenden Sie die Befehlsoption --executePrereqs. Dadurch werden nur die Voraussetzungsprüfungen ausgeführt, ohne dass die eigentliche Oracle Database-Duplizierung ausgeführt wird.

dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --sourceDBTdeConfigMethod FILE --tdeConfigMethod FILE --executePrereqs

Datenbank duplizieren

dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --sourceDBTdeConfigMethod FILE --tdeConfigMethod FILE

Überlegungen bei der Verwendung von OCI Vault für die Schlüsselverwaltung

Dieser Abschnitt ist nur anwendbar, wenn die Datenbank mit OCI Vault für die TDE-Verschlüsselung konfiguriert ist und Sie eine Datenbank duplizieren möchten.

Datenbank in derselben Region duplizieren

  • Weitere vorbereitende Schritte

    Richten Sie OCI Vault-Zugriffs-Policys für Zieldatenbankknoten ein. Zieldatenbankknoten sollten zusammen mit dem neuen Key Vault auf den OCI Key Vault der Quelldatenbank zugreifen können (wenn sie sich für einen separaten Key Vault entscheiden).

  • Voraussetzungsprüfungen ausführen
    dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --sourceDBTdeConfigMethod KMS --sourceDBKMSKeyOCID <Source Database OCI Vault key OCID> --tdeConfigMethod KMS --kmsKeyOCID <OCI Vault key OCID> --executePrereqs
  • Datenbank duplizieren
    dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --sourceDBTdeConfigMethod KMS --sourceDBKMSKeyOCID <Source Database OCI Vault key OCID> --tdeConfigMethod KMS --kmsKeyOCID <OCI Vault key OCID>

    Nach erfolgreichem Abschluss dieses Befehls wird die Datenbank dupliziert.

Datenbanken regionsübergreifend duplizieren

  • Weitere vorbereitende Schritte
    • Richten Sie einen neuen OCI Vault für die Zieldatenbank in der entsprechenden Region ein, indem Sie die unter Vom Kunden verwaltete Schlüssel im Vault-Service vorbereiten beschriebenen Schritte ausführen. Schließen Sie die Aufgaben 1 bis 3 ab.
    • Richten Sie die OCI Vault-Replikation von der Quellregion zur Zielregion ein. Weitere Informationen finden Sie unter Vaults und Schlüssel replizieren.
    • Aktualisieren Sie die Policy der dynamischen Gruppe, die in Schritt 2 erstellt wird, um den Zugriff auf den replizierten OCI Vault-Schlüssel zu ermöglichen.
  • Voraussetzungsprüfungen ausführen
    dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --sourceDBTdeConfigMethod KMS --sourceDBKMSKeyOCID <Source Database OCI Vault key OCID> --tdeConfigMethod KMS --kmsKeyOCID <OCI Vault key OCID> --executePrereqs
  • Datenbank duplizieren
    dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --sourceDBTdeConfigMethod KMS --sourceDBKMSKeyOCID <Source Database OCI Vault key OCID> --tdeConfigMethod KMS --kmsKeyOCID <OCI Vault key OCID>

    Nach erfolgreichem Abschluss dieses Befehls wird die Datenbank dupliziert.

On-Premise-Datenbank duplizieren

Mit dbaascli können Sie eine On-Premise-Datenbank in der Cloud duplizieren. Dies kann mit dem Befehl dbaascli database duplicate erfolgen. Mit diesem Befehl wird eine neue Datenbank in der Cloud erstellt. Dabei handelt es sich um ein Duplikat einer On-Premise-Datenbank zusammen mit den zugehörigen Daten. Während dieses Prozesses bleibt die On-Premise-Datenbank weiterhin betriebsbereit. Sie können Ihre Anwendungen nach der erforderlichen Überprüfung in die duplizierte Datenbank in der Cloud migrieren.

Duplizierung vorbereiten

Der Migrationsprozess enthält die folgenden Voraussetzungen, die erfüllt sein müssen.
  • Stellen Sie sicher, dass ein Netzwerkpfad eingerichtet ist, um über die Zeichenfolge EZConnect vom OCI-Knoten auf eine On-Premise-Datenbank zuzugreifen.
  • Wenn eine On-Premise-Datenbank mit TDE konfiguriert ist, kopieren Sie die TDE-Wallet-Datei (ewallet.p12 ) auf den OCI-Knoten, auf dem Sie den Befehl dbaascli ausführen möchten.
  • Erstellen Sie bei Bedarf ein Oracle Home auf dem OCI-Knoten. Die Oracle Home-Version muss mit der Quelle oder einer höheren RU-Version identisch sein.

Prüfen Sie die erforderlichen RPMs

Für diesen Prozess ist eine dbaastools-RPM-Mindestversion von 23.3.2.0.0 erforderlich. Eine Aktualisierung auf die neueste dbaastools-U/min wird jedoch immer empfohlen.

  • Um die aktuell installierte Version zu prüfen, führen Sie Folgendes aus:
    dbaascli --version
    DBAAS CLI version 23.3.2.0.0
  • Um das neueste Tools-RPM als Benutzer root anzuwenden, führen Sie Folgendes aus:
    # dbaascli admin updateStack

Voraussetzungsprüfungen ausführen

Um die Voraussetzungsprüfungen auszuführen, verwenden Sie die Befehlsoption --executePrereqs. Dadurch werden nur die Voraussetzungsprüfungen ausgeführt, ohne dass die eigentliche Oracle Database-Duplizierung ausgeführt wird.

dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --executePrereqs

Datenbank duplizieren

Kopieren Sie die Datenbank mit dem folgenden Befehl:

dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet>

Beispiel:

dbaascli database duplicate --sourceDBConnectionString xyzhost.oracle.com:1521/dbuniquename.oracle.com --dbName orcl --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_1 --sourceDBTDEWalletLocation /tmp/wallet_copy/tde --waitForCompletion false

Nach erfolgreichem Abschluss dieses Befehls wird die Datenbank in der Cloud dupliziert und ist für Integritätsprüfungen für die Anwendungsnutzung bereit. Nachdem die Verifizierung abgeschlossen ist, können Anwendungsverbindungen in die Cloud-Datenbank migriert werden.

Weitere Konfigurationsoptionen finden Sie unter dbaascli database duplicate –help.

Nur wenige Aspekte zur Migration

  • Wenn Sie mehrere Channels für RMAN-Duplikate zuweisen möchten, können Sie dies tun, indem Sie das Argument --rmanParallelism angeben.
  • Exadata Cloud Service konfiguriert den Datenbankspeicher als Automatic Shared Memory Management (ASMM). Wenn die On-Premise-Datenbank mit einer anderen Speicherverwaltung konfiguriert ist, müssen Sie die Speicherparameterwerte entsprechend auf OCI-Seite anpassen, indem Sie Werte für --sgaSizeInMB und --pgaSizeInMB angeben.
  • Stellen Sie sicher, dass die On-Premise-Datenbank keine veralteten oder ungültigen Initialisierungsparameter enthält.
  • Datenbankinitialisierungsparameter für den Datenbankspeicher (Speicherort der Datendatei, Redo-Speicherort, Ziel des Recovery-Bereichs, Multiplexing der Kontrolldatei) können mit dem Argument --initParams geändert werden.

    Beispiel: So überschreiben Sie den Wert db_create_online_log_dest für die duplizierte Datenbank: --initParams db_create_online_log_dest_1=+DATAC1,db_create_online_log_dest_2=+RECOC1

Datenbankduplizierung beheben

  • Die Logdatei für den Vorgang dbaascli finden Sie unter /var/opt/oracle/log/<dbname>/database/duplicate
  • Einer der Jobs des Duplikats ist die Ausführung von dbca. Die Logdatei ist unter /u02/app/oracle/cfgtoollogs/dbca und /u02/app/oracle/cfgtoollogs/dbca/<dbuniquename> zu finden.

Wenn der Vorgang nicht erfolgreich verläuft, können Sie den Vorgang fortsetzen, indem Sie das Argument --resume für denselben Befehl angeben. Alternativ können Sie die Datenbank mit dbaascli database delete –dbname <dbname> –force bereinigen und dann den Datenbankduplikatbefehl erneut ausführen.

Versionshinweise

Hier sind die Änderungen in verschiedenen Releases von dbaascli aufgeführt.

Version 25.3.1.0.0 (250813)

  • Der dbaascli dbhome patch-Befehl enthält jetzt die Option skipDBForDatapatch.

    Zweck: Mit dieser Option können Sie eine Liste der Datenbanken angeben, in denen der Datapatch-Schritt beim In-Place-DB-Home-Patching übersprungen wird.

  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Version 25.2.1.0.0 (250522)

  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Version 25.1.2.0.0 (250325)

  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Version 25.1.1.0.0 (250107)

  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 24.4.1.0.0 (241104)

  • Erweitertes dbaascli database getDetails um tde encryption-Details. Der Befehl dbaascli tde status ist jetzt veraltet.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 24.3.2.0.0 (240828)

  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 24.3.1.0.0 (240711)

  • TDE-Migration von sqlnet.ora nach wallet_root bei Datenbankupgrade auf Release 19c
  • Grid Patch an Ort und Stelle zur Verwendung des abbildbasierten Patchings als Standardmodus
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 24.2.1.0.0 (20530)

  • Unterstützung für Oracle Database 23ai hinzugefügt.
  • Verbesserungen im Backup- und Recovery-Bereich mit Zero Data Loss Autonomous Recovery Service (ZRCV) als Backupziel.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen.

Release 24.1.2.0.0 (20306)

  • Einführung eines neuen optimierten Workflows für Data Guard-Vorgänge
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 24.1.1.1.1.0.0 (231219)

  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 23.4.1.0.0 (231102)

  • Backup und Recovery: Das minimale Backup-Recovery-Fenster wurde in 7 Tage geändert. Während die Automatisierung von Backup-Pieces das Wiederherstellungsfenster als 7 Tage betrachtet, wenn es einen Wert kleiner als 7 aus dem System erkennt.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 23.3.2.0.0 (230921)

  • Vorgänge für integrierbare Datenbanken
    • Unterstützung zum Festlegen der OCID der benutzerdefinierten Schlüsselversion (Bring Your Own Key - BYOK) von OCI Vault bei Erstellungs- und Klonvorgängen wurde hinzugefügt. Einzelheiten finden Sie in der Hilfe zu den jeweiligen PDB-Befehlen.
  • Grid Infrastructure-(GI-)Patching
    • Verbesserter Patching-Workflow zur Verbesserung der Patching-Zeit, insbesondere in Umgebungen mit einer hohen Anzahl von Datenbanken.
    • Die neue Option --patchInParallel wird eingeführt, mit der Remoteknoten parallel gepatcht werden können.
  • Datenbankpatching
    • Bereitgestellte Option zum Ausführen von Datapatch auf einem bestimmten Clusterknoten.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 23.3.1.0.0 (230712)

  • Neue dbaascli-Befehle
    • dbaascli gridHome create: Mit diesem Befehl können Sie ein Grid Infrastructure Home einer unterstützten Version erstellen. Einzelheiten finden Sie unter dbaascli gridHome create --help.
    • dbaascli system getGridHomes: Dieser Befehl gibt Details zu den verfügbaren Grid Infrastructure Homes im System an. Einzelheiten finden Sie unter dbaascli system getGridHomes --help.
    • dbaascli admin updateAHF: Mit diesem Befehl können Sie die AHF auf eine angegebene Cloud-zertifizierte Version der AHF-Version aktualisieren. Es wird jedoch empfohlen, AHF-Updates implizit von der Cloud-Automatisierung zu verarbeiten. Einzelheiten finden Sie unter dbaascli admin updateAHF --help.
  • Vorgänge für integrierbare Datenbanken
    • Verbesserungen im Bereich des aktualisierbaren integrierbaren Datenbanklebenszyklus.
  • Backup und Recovery von Datenbanken
    • Unterstützung für die Konfiguration von Backups auf Standby Sites bei Data Guard-Konfigurationen wurde hinzugefügt. Die Backupkonfiguration ist Data Guard-Site-spezifisch, d.h. die Rollenänderung (z.B. bei einem Data Guard-Switchover-Vorgang) wirkt sich nicht auf die Backupvorgänge der Datenbank auf Primär- oder Standbysites aus. Backups, die auf dem primären Standort oder Stand-by-Standort konfiguriert sind, werden unabhängig von der Rollenänderung fortgesetzt.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 23.2.1.0.0 (230503)

  • Verbesserungen bezüglich des Datenbanklebenszyklus
    • dbaascli grid removeTCPSCert wurde eingeführt, um abgelaufene TCPS-Zertifikate zu entfernen. Einzelheiten finden Sie unter dbaascli grid removeTCPSCert --help.
    • Option zum Ausschließen bestimmter PDBs beim Duplizieren der Datenbank hinzugefügt. Einzelheiten finden Sie im Argument skipPDBs in dbaascli database duplicate --help.
  • Backup und Recovery von Datenbanken
    • Der Standardwert für FILES_PER_SET für OSS-Backups wurde in 64 geändert. Dies kann mit dbaascli database backup --configure geändert werden. Einzelheiten finden Sie unter dbaascli database backup --help.
    • Archive Log-Backups werden von der Standbysite nach dem Rollen-Switchover in Data Guard-Umgebungen fortgesetzt.
    • Bei Backups, die nicht von Oracle verwaltet werden, werden die Pläne für L0- und L1-Backups nicht standardmäßig erstellt. Sie müssen explizit mit dem Befehl dbaascli database backup --configure erstellt werden.
  • sysLens

    Ein Framework, das Systemressourcendaten für ExaDB-D-Flotten sammelt, analysiert und meldet, ist in 23.2.1.0.0 (235503) enthalten. Weitere Informationen finden Sie unter sysLens verwalten.

  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 23.1.2.0.0 (230305)

  • Verbesserungen bezüglich des Datenbanklebenszyklus
    • Option zum Erstellen von Datenbankvorlagen (DBCA-Vorlagen) zum Objektspeicher hinzugefügt. DBCA-Vorlagen können anschließend zum Erstellen von Datenbanken verwendet werden. Einzelheiten finden Sie unter dbaascli database createTemplate --help.
  • Vorgänge für integrierbare Datenbanken
    • dbaascli pdb refresh zum Aktualisieren einer integrierbaren Datenbank, die mit der Option zum manuellen Aktualisieren erstellt wurde, eingeführt. Einzelheiten finden Sie unter dbaascli pdb refresh --help.
    • Option zum Konvertieren einer aktualisierbaren integrierbaren Datenbank in eine reguläre integrierbare Datenbank hinzugefügt. Einzelheiten finden Sie unter dbaascli pdb open --help.
    • Für die Erstellung einer aktualisierbaren integrierbaren Datenbank ist jetzt ein vorhandener Quelldatenbankbenutzer erforderlich, um einen Datenbanklink zur integrierbaren Quelldatenbank zu erstellen. Einzelheiten finden Sie im Argument dblinkUserName in dbaascli pdb remoteClone --help.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 23.1.1.0.1 (230113)

  • Verbesserungen bezüglich des Datenbanklebenszyklus
    • Unterstützung zum Erstellen einer Duplikatdatenbank aus einer Quelldatenbank, die OCI Vault-Services für die Verwaltung von Verschlüsselungsschlüsseln verwendet, wurde hinzugefügt.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.4.1.0.1 (221122)

  • Vorgänge für integrierbare Datenbanken
    • Option, um die PDB am Ende der Umspeicherung nicht zu öffnen, wurde hinzugefügt. Einzelheiten finden Sie im Argument skipOpenPDB in dbaascli pdb relocate --help. Nach Verwendung dieser Option kann die PDB-Umspeicherung abgeschlossen werden, indem der Befehl mit dem Argument completePDBRelocate ausgeführt wird.
    • Option zum Bereinigen der umgespeicherten PDB-Metadaten/-Services am Quellspeicherort wurde hinzugefügt. Einzelheiten finden Sie im Argument cleanupRelocatedPDB in dbaascli pdb delete --help.
  • Neue dbaascli-Befehle
    • Mit dem Befehl dbaascli database createTemplate können Sie Datenbankvorlagen (DBCA-Vorlagen) erstellen, mit denen anschließend Datenbanken erstellt werden können. DBCA-Templates werden häufig zum Erstellen einer Klondatenbank mit DBCA verwendet. Hierbei handelt es sich um ein Tool, das im Lieferumfang der Oracle Database-Serversoftware enthalten ist. Einzelheiten finden Sie unter dbaascli database createTemplate --help.
    • dbaascli tde rotateMasterKey wurde eingeführt, um den Masterschlüssel für die Datenbankverschlüsselung zu rotieren. Einzelheiten finden Sie unter dbaascli tde rotateMasterKey --help. Der Befehl dbaascli tde rotate masterkey ist jetzt veraltet.
  • Verbesserungen bezüglich des Datenbanklebenszyklus
    • Unterstützung für die Verwendung von DBCA-Vorlagen in Workflows zur Datenbankerstellung wurde hinzugefügt. Einzelheiten finden Sie im Argument dbcaTemplateFilePath in dbaascli database create --help.
    • Performance bei der Erstellung von Duplikatdatenbanken wurde verbessert. Einzelheiten zum Erstellen einer Duplikatdatenbank finden Sie unter dbaascli database duplicate --help.
    • Unterstützung zum Erstellen einer Duplikatdatenbank aus einer Quelldatenbank, die nicht TDE-verschlüsselt ist, wurde hinzugefügt.
  • TDE-Management
    • dbaascli tde rotateMasterKey wurde eingeführt, um den Masterschlüssel für die Datenbankverschlüsselung zu rotieren. Einzelheiten finden Sie unter dbaascli tde rotateMasterKey --help. Der Befehl dbaascli tde rotate masterkey ist jetzt veraltet.
    • Workflow für alle TDE-Vorgänge wurde überarbeitet. Einzelheiten finden Sie unter dbaascli tde --help.
  • Grid Infrastructure-(GI-)Patching
    • Unterstützung für die parallele Ausführung des Patching-Vorgangs auf Knoten wurde hinzugefügt. Diese Option muss mit Bedacht eingesetzt werden, da sie zu einer geringeren Datenbankverfügbarkeit führt.
  • Backup und Recovery von Datenbanken
    • Workflow zum Erstellen von Datenbanken aus Standalone-Backups wurde überarbeitet.
  • Beinhaltet AHF-Version 22.2.4
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.3.1.1.0 (221003)

  • Neue dbaascli-Befehle
    • Mit dem Befehl dbaascli database getDetails können Sie ausführliche Informationen zu einer bestimmten Datenbank anzeigen, beispielsweise Name der Datenbank, Knoteninformationen, Informationen zu integrierbaren Datenbanken usw. Einzelheiten finden Sie unter dbaascli database getDetails --help.
  • Vorgänge für integrierbare Datenbanken
    • Unterstützung für das Erstellen integrierbarer Datenbanken als aktualisierbarer Klon mit dem Argument refreshablePDB hinzugefügt. Einzelheiten finden Sie unter dbaascli pdb remoteClone --help.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.3.1.0.1 (220721)

  • Neue Befehle zum Datenbanklebenszyklus
    • dbaascli database addInstance: Mit diesem Befehl können Sie eine Datenbankinstanz zu einem der Knoten des Clusters hinzufügen, auf dem die Datenbank noch nicht konfiguriert ist. Einzelheiten finden Sie unter dbaascli database addInstance --help.
    • dbaascli database deleteInstance: Mit diesem Befehl können Sie eine Datenbankinstanz aus einem der Knoten des Clusters löschen, auf dem die Datenbank konfiguriert ist. Einzelheiten finden Sie unter dbaascli database deleteInstance --help.
    • dbaascli database duplicate: Mit diesem Befehl können Sie eine neue Datenbank aus einer bereits vorhandenen Datenbank in einem Cluster bzw. clusterübergreifend erstellen, sofern eine Netzwerkverbindung zwischen den Clustern besteht. Einzelheiten finden Sie unter dbaascli database duplicate --help.
  • Cloud-Software-Library
    • Der Befehl dbaascli cswlib listLocal wurde eingeführt, um Images aufzulisten, die lokal aus der Software-Library im System heruntergeladen werden. Einzelheiten finden Sie unter dbaascli cswlib listLocal --help. Der Befehl dbaascli dbimage list ist jetzt veraltet.
    • Der Befehl dbaascli cswlib deleteLocal wurde eingeführt, um Images zu löschen, die aus der Cloud-Software-Library heruntergeladen wurden. Einzelheiten finden Sie unter dbaascli cswlib deleteLocal --help. Der Befehl dbaascli dbImage purge ist jetzt veraltet.
  • Der Logspeicherort für den Befehl dbaascli admin updateStack wurde geändert, um die Konvention anderer dbaascli-Befehle einzuhalten. Sie finden die Logs im Verzeichnis /var/opt/oracle/log/admin/updateStack. Der frühere Speicherort war /var/opt/oracle/log/tooling/Update.
  • Die Hilfe zu dbaascli ist nun cloudplattformfähig, da sie die Hilfeausgabe für Befehle auflistet, die für die jeweilige Cloud-Umgebung anwendbar sind.
  • Unterstützung für das Ändern des TDE-Kennworts in Data Guard-Umgebungen hinzugefügt. Einzelheiten finden Sie unter "dbaascli tde changePassword --help". Diese Unterstützung steht für das Release 11.2.0.4 derzeit nicht zur Verfügung.
  • AHF-Version 22.1.5 aufgenommen.
  • Überarbeiteter Workflow für Upgradevorgang von Datenbanken.
  • Überarbeiteter Workflow für Erstellungsvorgang von Datenbank-Homes.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.2.1.1.0 (220623)

  • AHF-Version 22.1.1 aufgenommen
  • Ein Problem wurde behoben, bei dem das Update von dbaastools-RPM im System zu einem Datenbankausfall mit dem Fehler ORA-600 geführt hat.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.2.1.1.0 (220609)

  • Neue dbaascli-Befehle:
    • dbaascli dbHome getDatabases: Dieser Befehl listet alle Datenbanken auf, die aus einem bestimmten Oracle Home-Verzeichnis der Datenbank ausgeführt werden. Die Ausgabe wird im JSON-Format zurückgegeben, um die Automatisierung zu erleichtern. Einzelheiten finden Sie unter dbaascli dbHome getDatabases --help.
    • dbaascli database getPDBs: Dieser Befehl listet alle integrierbaren Datenbanken einer bestimmten Containerdatenbank auf. Die Ausgabe wird im JSON-Format zurückgegeben, um die Automatisierung zu erleichtern. Einzelheiten finden Sie unter dbaascli database getPDBs --help.
    • dbaascli dbHome delete: Dieser Befehl löscht ein bestimmtes OracleHome der Datenbank. Einzelheiten finden Sie unter dbaascli dbHome delete --help.
    • dbaascli dataguard prepareStandbyBlob: Dieser Befehl generiert eine BLOB-Datei mit verschiedenen Dateien, die auf der Standbysite für eine Data Guard-Umgebung erforderlich sind. Einzelheiten finden Sie unter dbaascli dataguard prepareStandbyBlob --help.
  • Grid Infrastructure-(GI-)Patching:
    • Neuer optimierter Workflow
    • Es wurde die Möglichkeit eingeführt, das Grid Infrastructure-(GI-)Softwareimage vor dem Patching zu erstellen. Dieses GI-Image kann anschließend für den GI-Patching-Vorgang verwendet werden. Der Vorteil dieses Ansatzes ist, dass es zu einem reduzierten Patching-Fenster führt, da das Image bereits erstellt ist. Zum Erstellen des Images wird der GI-Stack auf dem Knoten nicht heruntergefahren. Einzelheiten finden Sie unter der Option createImage in dbaascli grid patch --help.
    • Es wurde die Möglichkeit eingeführt, das Grid Infrastructure-Patching mit dem benutzerdefinierten GI-Softwareimage auszuführen, das mit der Option createImage des Befehls dbaascli grid patch erstellt wurde. Einzelheiten finden Sie unter der Option imageLocation in dbaascli grid patch --help.
  • Unterstützung der Kennwortänderung in Data Guard-Umgebungen:
    • Unterstützung der Kennwortänderung in Data Guard-Umgebungen hinzugefügt. Einzelheiten finden Sie unter dbaascli database changePassword --help und dbaascli dataguard prepareStandbyBlob --help.
  • Data Guard-Konfiguration:
    • Unterstützung der Aktualisierung von Data Guard-Automatisierungsattributen (in der Datei /var/opt/oracle/dg/dg.conf) hinzugefügt. Einzelheiten finden Sie unter dbaascli dataguard --help.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.2.1.0.1 (220423)

  • Neue dbaascli-Befehle
    • dbaascli admin showLatestStackVersion wurde eingeführt, um die neueste dbaastools-Version anzuzeigen, die Kunden zum Herunterladen und Installieren zur Verfügung stehen. Die Installation von dbaastools RPM kann mit dem Befehl dbaascli admin updateStack ausgeführt werden. Einzelheiten finden Sie im Abschnitt "dbaascli-Befehlsreferenz".
  • Cloud-Software-Library
    • Eine BP-Aktivierung (dbaascli cswlib activateBP) wird nicht mehr unterstützt, da BPs (Bundle-Patches) jetzt durch RUs ("Releaseupdates") ersetzt werden. Beim Cloud-Deployment werden RUs in Form von Softwareimages konsumiert, die durch "Imagetags" identifiziert werden. Es wird daher empfohlen, Imagetags während der Arbeit mit Befehlen der Cloud-Software-Library (cswlib) zu verwenden. Einzelheiten finden Sie unter dbaascli cswlib download –help.
    • Es müssen keine Nicht-CDB-Images mehr heruntergeladen werden, um Nicht-CDB-Datenbanken zu erstellen. Jetzt können Benutzer die Nicht-CDB-Datenbank mit regulären Images erstellen. Einzelheiten finden Sie unter der Option createAsCDB in dbaascli database create –help.
  • Nicht-CDB-Datenbank erstellen
    • Verbesserter Workflow zum Erstellen einer Nicht-CDB-Datenbank mit dem Standard-Softwareimage der Datenbank. Einzelheiten finden Sie unter der Option createAsCDB in dbaascli database create –help.
  • Datenbank-Home-Patching
    • Neuer optimierter Workflow
  • Grid Infrastructure-Upgrade
    • Neuer optimierter Workflow
  • Vorgänge für integrierte Datenbanken (PDBs)
    • Das Löschen einer PDB in Data Guard-Umgebungen erfordert eine explizite Bestätigung, dass die auf der Standbysite erforderlichen Vorgänge abgeschlossen sind. Dazu wird das zusätzliche Argument "–allStandByPrepared" übergeben. Einzelheiten finden Sie unter dbaascli pdb delete --help.
  • Rollierende Funktion für "database bounce"-Vorgang bereitgestellt. Einzelheiten finden Sie unter dbaascli database bounce –help.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.1.1.2.0 (220405)

  • Unterstützung für ExaDB-D X9M hinzugefügt
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.1.1.1.0 (220317)

  • Neue dbaascli-Befehle:
    • dbaascli system getDBHomes wurde eingeführt, um alle Oracle Database Homes im Cluster abzurufen. Die Ausgabe wird im JSON-Format zurückgegeben, um die Automatisierung zu erleichtern.
    • dbaascli dbhome getDetails wurde eingeführt, damit detaillierte Informationen zu einem bestimmten Oracle Home abgerufen werden können. Die Ausgabe wird im JSON-Format zurückgegeben, um die Automatisierung zu erleichtern.
  • Cloud-Software-Library (cswlib):
    • Der Befehl dbaascli cswlib list für Auflistungsvorgänge in der Cloud-Software-Library wird nicht mehr unterstützt. Der neue Befehl ist dbaascli cswlib showImages. Damit werden die Images zusammen mit ihrem ImageTag aufgelistet. Es wird empfohlen, die Images mit Image tags aus der Cloud-Software-Library herunterzuladen. Einzelheiten zu Downloads mit Imagetags finden Sie unter dbaascli cswlib download –help.
    • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 22.1.1.0.1 (220223)

  • Grid Infrastructure-Upgrade
    • Neuer optimierter Workflow
  • Backup und Recovery von Datenbanken
    • Interne Aktualisierung des Metadaten-Repositorys für Backupmetadaten
    • Es wurden Meldungen eingeführt, dass bkup_api-Befehle veraltet sind, da diese jetzt durch dbaascli-Befehle ersetzt werden. Einzelheiten finden Sie unter "dbaascli database backup --help" und "dbaascli database recover –help".
  • Vorgänge für integrierte Datenbanken (PDBs)
    • PDB-Umspeicherung wird jetzt unterstützt. Einzelheiten finden Sie unter "dbaascli pdb relocate –help".
    • Workflow für Konvertierung von Nicht-CDB in PDB wurde überarbeitet. Einzelheiten finden Sie unter "dbaascli database convertToPDB –help".
  • Verwaltung von Verschlüsselungsschlüsseln
    • Heartbeat-spezifische Initialisierungsparameter für Transparent Data Encryption (TDE) wurden auf die für die Cloud empfohlenen Werte für Datenbanken mit vom Kunden verwalteten Schlüsseln gesetzt.
  • Verwaltung der Cloud-Software-Library
    • Download von Artefakten aus der Software-Library über imageTags wurde überarbeitet. Es wird empfohlen, die Database- und Grid-Softwareimages mit imageTags herunterzuladen. Einzelheiten finden Sie unter "dbaascli cswlib showimages" und "dbaascli cswlib download –help".
  • AHF-Version 21.4.2 aufgenommen
  • Verschiedene Bugfixes und Stabilitätsverbesserungen

Release 21.4.1.1.0 (220209)

  • AHF-Version 21.4.1 aufgenommen
  • Bugfixes und Stabilitätsverbesserungen

Release 21.4.1.1.0

  • Verschlüsselung der Tablespaces auf Systemebene (SYSTEM, SYSAUX, UNDO und TEMP) für Datenbanken, die mit dieser oder einer künftigen Version von dbaastools erstellt werden, wurde aktiviert. Dieses Feature ist für Oracle Database Version 19.6.0.0.0 und höher aktiviert.
  • Grid-Patching:
    • Erforderliche Bedingung hinzugefügt, um zu prüfen, ob der Eigentümer der folgenden Datei der Benutzer grid ist.
      • <gi_home>/suptools/tfa/release/tfa_home/jlib/jdev-rt.jar
      • <gi_home>/suptools/tfa/release/tfa_home/jlib/jewt4.jar
  • Datenbank-Patching:
    • Gleichzeitige database move-Vorgänge sind standardmäßig nicht zulässig. Eine neue Option –allowParallelDBMove wird eingeführt, mit der das Standardverhalten für Oracle Database-Releases 12.2 und höher außer Kraft gesetzt werden kann.
    • Probleme im Zusammenhang mit dem Verschieben von Standbydatenbanken im MOUNT-Modus wurden behoben.
  • Backup und Recovery von Datenbanken:
    • Neue Befehlszeilenoptionen für Datenbankbackup wurden hinzugefügt. Weitere Einzelheiten finden Sie in der dbaascli database backup-Befehlsreferenz.
    • Neue Befehlszeilenoptionen für das Datenbank-Recovery wurden hinzugefügt. Weitere Einzelheiten finden Sie in der dbaascli database recover-Befehlsreferenz.
    • Die Verwendung von bkup_api für Backup- und Recovery-Vorgänge wird in Zukunft nicht mehr unterstützt.
    • Um der von Oracle empfohlenen Vorgehensweise zur Verwendung der administrativen Berechtigung SYSBACKUP für Backup- und Recovery-Vorgänge zu entsprechen, erstellt die Cloud-Automatisierung einen allgemeinen Benutzer C##DBLCMUSER mit der Rolle SYSBACKUP auf der CDB$ROOT-Containerebene. Backup- und Recovery-Vorgänge werden daher mit einem Benutzer ausgeführt, der über die geringsten erforderlichen Berechtigungen verfügt. Zugangsdaten für diesen Benutzer werden zufällig generiert und sicher von der Cloud-Automatisierung verwaltet. Wenn der Benutzer nicht gefunden wird oder LOCKED und EXPIRED ist, erstellt oder entsperrt die Cloud-Automatisierung diesen Benutzer während des Backup- oder Recovery-Vorgangs. Diese Änderung an der Cloud-Automatisierung tritt ab Version 21.4.1.1.0 von dbaastools in Kraft.
  • Erweiterte dbaascli resume-Funktionalität zum Fortsetzen einer vorherigen Session durch Angabe des Arguments –sessionID <value> für den Fortsetzungsbefehl. Die Session-ID wird in der dbaascli-Ausgabe und in den Logs gemeinsam verwendet.
  • Die dbaascli help-Ausgabe wurde verbessert und zeigt die Befehlsverwendung.
  • Die Verwendung der dbaascli-Shell (interaktive Session) wird nicht mehr unterstützt. Diese wird nach März 2022 nicht mehr unterstützt. Es wird empfohlen, vollständige dbaascli-Befehle an der Eingabeaufforderung auszuführen, wie in allen Dokumentbeispielen vorgeschlagen.
  • Autonomous Health Framework (AHF) Version 21.2.8 wurde aufgenommen.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen.

Release 21.3.1.2.0

  • Das Timing von dbaascli-Vorgängen wurde durch verbesserte Synchronisierungslogik für Control-Plane-Metadaten verbessert.
  • Die dbaascli-Logs wurden um Informationen auf Millisekundenebene zusammen mit dem zugehörigen Thread erweitert.
  • Beim Patching von Datenbank-Homes und bei der Datenbankverschiebung wurden weitere Voraussetzungsprüfungen eingeführt, um potenziellen Fehlerszenarios mit Korrekturvorschlägen zu begegnen.
  • Bei Datenbank-Patching-Vorgängen wird jetzt der Zustand der Datenbanken vor dem Patching beibehalten. Bei integrierbaren Datenbanken wird der gespeicherte PDB-Zustand berücksichtigt.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen.

Release 21.3.1.1.0

  • Unterstützung der Entsperrung des PDB-Admin-Benutzeraccounts im Rahmen der PDB-Erstellung oder des Vorgangs localClone oder remoteClone wurde hinzugefügt. Einzelheiten finden Sie unter der Option --lockPDBAdminAccount in dbaascli pdb create --help.
  • Ein Problem wurde behoben, sodass die bei Oracle Grid Infrastructure registrierte Datenbankressource in vorhandenen Umgebungen mit dem richtigen Wert für den Datenbanknamen aktualisiert wird.
  • PDB-Lebenszyklusvorgänge wurden verbessert.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen.

Release 21.3.1.0.1

  • Unterstützung für die Ausführung der folgenden dbaascli-Befehle als Benutzer oracle.
    • dbaascli pdb bounce
    • dbaascli pdb close
    • dbaascli pdb connectString
    • dbaascli pdb create
    • dbaascli pdb delete
    • dbaascli pdb getDetails
    • dbaascli pdb list
    • dbaascli pdb localClone
    • dbaascli pdb open
    • dbaascli pdb remoteClone
  • Das Out-of-Place-Patching von Datenbanken wurde überarbeitet. Einzelheiten finden Sie unter dbaascli database move –help.
  • Timingbezogene Verbesserungen im Patching-Workflow von Oracle Grid Infrastructure. Einzelheiten finden Sie unter dbaascli grid patch –help.
  • Die Unterstützung für exadbcpatchmulti/dbaascli patch für Patching-Vorgänge wurde eingestellt. Die Befehle dbaascli dbhome patch und dbaascli grid patch werden für den Patching-Vorgang für Datenbank-Homes und Oracle Grid Infrastructure bereitgestellt. Einzelheiten finden Sie im Abschnitt Oracle Grid Infrastructure und Oracle-Datenbanken mit dbaascli patchen. Siehe auch den Abschnitt dbaascli-Befehlsreferenz.
  • Der dbaascli-Befehl "tools patch" wird nicht mehr unterstützt, um Konsistenz in den dbaascli-Befehlskonventionen zu erzielen. Der neue Befehl lautet dbaascli admin updateStack. Einzelheiten finden Sie im Abschnitt Cloud-Tooling mit dbaascli aktualisieren.
  • Möglichkeit, dbaascli für Vorgänge mit langer Ausführungszeit im Offlinemodus auszuführen. Wenn Sie den Befehl dbaascli mit --waitForCompletion false ausführen, erhalten Sie eine Job-ID, die später abgefragt werden kann, um den Status des Vorgangs mit dbaascli job getStatus –jobid job_id abzurufen. Dies ist nützlich für Vorgänge mit langer Ausführungszeit, bei denen Benutzer die Kontrolle unmittelbar nach der Befehlsausführung wieder übernehmen möchten. In diesem Release ist diese Option nur für den Befehl dbaascli database create verfügbar. Weitere Befehle werden in nachfolgenden Releases hinzugefügt, damit dies unterstützt wird. Die Hilfeausgabe für diese Befehle gibt die Unterstützung der Option --waitForCompletion wieder.
  • Die dbaascli-Shell wird nicht mehr unterstützt. Es wird empfohlen, dass Benutzer die vollständigen dbaascli-Befehle an der Eingabeaufforderung ausführen, wie in allen Dokumentbeispielen vorgeschlagen. Wird nur dbaascli ausgeführt, wird die Verwendungshilfe angezeigt und nicht die dbaascli-Shell aufgerufen.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen.

Release 21.2.1.x.x

  • Der Patching-Vorgang für Oracle Grid Infrastructure wurde neu gestaltet und bietet nun zusätzlich die Möglichkeit zum Fortsetzen ab dem Fehlerzeitpunkt, zum Patchen von Teilmengen von Knoten, zum Draining von Instanzen sowie weitere Verbesserungen. Einzelheiten finden Sie unter dbaascli grid patch --help. Weitere Informationen finden Sie im Abschnitt Oracle Grid Infrastructure und Oracle-Datenbanken mit dbaascli patchen.
  • Für Patching-Vorgänge wird exadbcpatchmulti/dbaascli patch nicht mehr unterstützt. Die Befehle dbaascli dbhome patch und dbaascli grid patch werden für Patching-Vorgänge für Datenbank-Homes und Oracle Grid Infrastructure bereitgestellt. Einzelheiten finden Sie im Abschnitt Oracle Grid Infrastructure und Oracle-Datenbanken mit dbaascli patchen. Siehe auch den Abschnitt dbaascli-Befehlsreferenz.
  • Der Befehl dbaascli tools patch wird nicht mehr unterstützt, um Konsistenz in den Befehlskonventionen zu erzielen. Der neue Befehl lautet dbaascli admin updateStack.
  • Die PDB-Management-APIs für Erstellungs-, lokale Klon- und Remoteklonvorgänge wurden neu gestaltet. Einzelheiten finden Sie unter dbaascli pdb --help.
  • Die API zum Löschen von Datenbanken wurde neu gestaltet. Einzelheiten finden Sie unter dbaascli database delete --help.
  • Die Erstellung von Datenbank-Homes wurde neu gestaltet (Unterstützung für benutzerdefiniertes Softwareimage, horizontales Skalieren). Einzelheiten finden Sie unter dbaascli dbhome create --help.
  • Unterstützung für die Datenbankerstellung auf Teilmengen von Clusterknoten. Einzelheiten finden Sie unter dbaascli database create --help.
  • Möglichkeit, dbaascli für Vorgänge mit langer Ausführungszeit im Offlinemodus auszuführen. Wenn Sie den Befehl dbaascli mit --waitForCompletion false ausführen, erhalten Sie eine Job-ID, die später abgefragt werden kann, um den Status des Vorgangs mit dbaascli job getStatus –jobid job_id abzurufen. Dies ist nützlich für Vorgänge mit langer Ausführungszeit, bei denen Benutzer die Kontrolle unmittelbar nach der Befehlsausführung wieder übernehmen möchten. In diesem Release ist diese Option nur für den Befehl dbaascli database create verfügbar. Weitere Befehle werden in nachfolgenden Releases hinzugefügt, damit dies unterstützt wird. Die Hilfeausgabe für diese Befehle gibt die Unterstützung der Option --waitForCompletion wieder.
  • Verbesserte Benutzererfahrung beim dbhome-Patching durch Einführung mehrerer Optionen wie skipPDBs, continueWithDowntime usw. Einzelheiten finden Sie unter dbaascli dbhome patch --help.
  • Unterstützung für eine bessere Diagnoseerfassung. Einzelheiten finden Sie unter dbaascli diag collect --help.
  • Geringfügige Verbesserungen bei der Automatisierung von Datenbankupgrades.
  • Verschiedene Bugfixes und Stabilitätsverbesserungen.

dbaascli-Befehlsreferenz

Sie müssen dbaascli verwenden, um Datenbanken zu erstellen und in das Cloud-Automatisierungs-Framework zu integrieren.

dbaascli ist eine cloudnative Schnittstelle, die DBCA-Vorlagen als Eingaben verwenden kann, die DBCA-Funktionalität zum Erstellen von Datenbanken aufruft und anschließend OCI-APIs zur Integration der Datenbank in das Cloud-Automatisierungs-Framework aufruft. Kunden, die aktuell DBCA in Skripten verwenden, können ihre vorhandenen Skripte aktualisieren, so dass dbaascli anstelle von DBCA aufgerufen wird. Falls dbaascli nicht verwendet werden kann, weil ein bestimmtes DBCA-Feature in dbaascl nicht verfügbar ist, können Kunden eine My Oracle Support-(MOS-)Anfrage stellen, um diese Funktionalität zu dbaascli hinzufügen zu lassen.

Um das Utility dbaascli verwenden zu können, müssen Sie mit einem Exadata Cloud Infrastructure-Compute Node verbunden sein. Weitere Informationen finden Sie unter Verbindung mit einer Exadata Cloud Infrastructure-Instanz herstellen.

Einige dbaascli-Befehle können als oracle- oder opc-Benutzer ausgeführt werden, viele Befehle erfordern jedoch root-Administratorberechtigungen. Die spezifischen Anforderungen finden Sie bei den einzelnen Befehlen.

dbaascli-Admin updateAHF

Um Autonomous Health Framework (AHF) zu installieren oder zu aktualisieren, verwenden Sie den Befehl dbaascli admin updateAHF.

Voraussetzungen

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli admin updateAHF
 {
   --targetVersion value | --imageTag value
}
[--resume [--sessionID value]] [--executePrereqs]
Dabei gilt:
  • --targetVersion gibt die Zielversion an, auf die AHF aktualisiert werden soll.
  • --imageTag gibt das Imagetag des zu installierenden AHF-Artefakts an.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --executePrereqs führt Voraussetzungsprüfungen aus und meldet die Ergebnisse.

dbaascli admin updateStack

Um ein dbaastools-RPM zu installieren oder zu aktualisieren, verwenden Sie den Befehl dbaascli admin updateStack.

Voraussetzungen

Führen Sie den Befehl als Benutzer root aus.

Um das Utility verwenden zu können, müssen Sie eine Verbindung zu einer virtuellen Maschine von Exadata Cloud Infrastructure herstellen.

Siehe Verbindung zu einer virtuellen Maschine mit SSH herstellen.

Syntax

dbaascli admin updateStack 
[--resume]
[--prechecksOnly]
[--nodes]
Dabei gilt:
  • --resume setzt die vorherige Ausführung fort.
  • --prechecksOnly führt nur die Vorabprüfungen für diesen Vorgang aus.
  • --nodes gibt eine kommagetrennte Liste von Knoten an, auf denen das RPM installiert werden soll. Wenn Sie dieses Argument nicht übergeben, wird das RPM auf allen Clusterknoten installiert.

dbaascli cswlib deleteLocal

Um das lokale Image zu löschen, verwenden Sie den Befehl dbaascli cswlib deleteLocal.

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli cswLib deleteLocal --imageTag <value>

Dabei gilt:

  • --imageTag gibt das Imagetag des Oracle Homes an.

Beispiel 6-4: dbaascli cswlib deletelocal

dbaascli cswlib deletelocal --imagetag 19.15.0.0.0
DBAAS CLI version MAIN
Executing command cswlib deletelocal --imagetag 19.15.0.0.0
Job id: 8b3e71de-4b81-4832-b49c-7f892179bb4f
Log file location: /var/opt/oracle/log/cswLib/deleteLocal/dbaastools_2022-07-18_10-00-02-AM_73658.log
dbaascli execution completed

dbaascli cswlib download

Um verfügbare Softwareimages herunterzuladen und in der Exadata Cloud Infrastructure-Umgebung verfügbar zu machen, verwenden Sie den Befehl dbaascli cswlib download.

Voraussetzungen

Führen Sie den Befehl als Benutzer root aus.

Um das Utility verwenden zu können, müssen Sie eine Verbindung zu einer virtuellen Maschine von Exadata Cloud Infrastructure herstellen.

Siehe Verbindung zu einer virtuellen Maschine mit SSH herstellen.

Syntax

dbaascli cswlib download --version | --imageTag
[--product]
Dabei gilt:
  • --version gibt eine Oracle Home-Imageversion an.
  • --imageTag gibt das Imagetag des Images an.
  • --product gibt den Imagetyp an. Gültige Werte: database oder grid.

Beispiel 6-5: dbaascli cswlib download --product --imageTag

dbaascli cswlib download --product database --imageTag 19.14.0.0.0

Beispiel 6-6: dbaascli cswlib download --version 19.9.0.0.0

dbaascli cswlib download --product database --imageTag 19.14.0.0.0

dbaascli cswlib listLocal

Um die Liste der lokal verfügbaren Datenbank- und Grid Infrastructure-Images anzuzeigen, verwenden Sie den Befehl dbaascli cswlib listLocal.

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli cswLib listLocal [--product <value>]

Dabei gilt:

  • --product gibt den Oracle Home-Produkttyp an. Gültige Werte: database oder grid.

Beispiel 6-7: dbaascli cswlib listlocal

dbaascli cswlib listlocal
DBAAS CLI version MAIN
Executing command cswlib listlocal
Job id: bc4f047c-0a34-4d4d-a1ea-21ddc2a9c627
Log file location: /var/opt/oracle/log/cswLib/listLocal/dbaastools_2022-07-18_10-29-53-AM_16077.log
############ List of Available Database Images  #############
1.IMAGE_TAG=12.2.0.1.220419
  IMAGE_SIZE=5GB
  VERSION=12.2.0.1.220419
  DESCRIPTION=12.2 APR 2022 DB Image
2.IMAGE_TAG=18.16.0.0.0
  IMAGE_SIZE=6GB
  VERSION=18.16.0.0.0
  DESCRIPTION=18c OCT 2021 DB Image
3.IMAGE_TAG=19.14.0.0.0
  IMAGE_SIZE=5GB
  VERSION=19.14.0.0.0
  DESCRIPTION=19c JAN 2022 DB Image
dbaascli execution completed

dbaascli cswlib showImages

Um die Liste der verfügbaren Datenbank- und Grid Infrastructure-Images anzuzeigen, verwenden Sie den Befehl dbaascli cswlib showImages.

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli cswlib showImages 
[--product]

Dabei gilt:

  • --product gibt den Oracle Home-Produkttyp an. Gültige Werte: database oder grid.

Beispiel 6-8: dbaascli cswlib showImages

dbaascli cswlib showImages

dbaascli database addInstance

Um die Datenbankinstanz auf dem angegebenen Knoten hinzuzufügen, verwenden Sie den Befehl dbaascli database addInstance.

Voraussetzung

  • Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database addInstance --dbname <value> --node <value> [--newNodeSID <value>]
Dabei gilt:
  • --dbname gibt den Namen der Oracle-Datenbank an.
  • --node gibt den Knotennamen für die Datenbankinstanz an.
    • --newNodeSID gibt die SID für die Instanz an, die dem neuen Knoten hinzugefügt werden soll.

dbaascli database backup

Um Oracle Database mit einem Backupspeicherziel zu konfigurieren, Datenbankbackups zu erstellen, Backups abzufragen und Backups zu löschen, verwenden Sie den Befehl dbaascli database backup.

Voraussetzung

  • Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database backup --dbname <value>
        {
            --list
                {
                    [--backupType <value>]
                    | [--json <value>]
                }
            | --start [--level0] [--level1]
                {
                    [--archival --tag <value>]
                    | [--archivelog]
                }
            | --delete --backupTag <value>
            | --status --uuid <value> [--json <value>]
            | --getBackupReport
                {
                    --tag <value>
                    | --latest
                }
                --json <value>
            | --configure
                {
                    --configFile <value>
                    | --enableRTRT
                    | --disableRTRT
                    | --disableCatalog
                    | --deleteImmutableConfiguration
                }
            | --getConfig
                {
                    [--configFile <value>]
                    | [--showOldParams]
                }
            | --validate [--untilTime <value>]
            | --showHistory [--all]
            | --getSchedules
        }

Dabei gilt:

  • --dbname gibt den Namen der Oracle-Datenbank an.
  • --list gibt Datenbank-Backupinformationen zurück

    [--backupType | --json]

    [--backupType gibt backupType an (REGULAR-L0 | REGULAR-L1 | ARCHIVELOG | LONGTERM) ]

    [--json gibt den Dateinamen für die JSON-Ausgabe an ]

  • --start beginnt mit dem Datenbankbackup.

    [--level0 erstellt ein Backup der Ebene 0 (vollständig)]

    [--level1 erstellt ein Backup der Ebene 1 (inkrementell) ]

    [--archival | --archivelog]

    [--archival erstellt ein vollständiges Archivierungsbackup]

    --tag gibt das Backuptag an.

    [--archivelog ]

  • --delete löscht das Archivierungsbackup

    --backupTag gibt das zu löschende Backuptag an

  • --status zeigt die Details zu einem Backupjobprozess an

    Eindeutige ID --uuid des Backupvorgangs. Eingabeformat: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

    [--json gibt den Dateinamen für die JSON-Ausgabe an]

  • --getBackupReport gibt BackupReport zurück

    --tag | --latest

    --tag gibt das Backuptag an.

    --latest gibt den letzten Backupbericht zurück (alle Typen von Datenbankbackup)

    --json gibt den Dateinamen für die JSON-Ausgabe an

  • --configure konfiguriert die Datenbank für das Backup

    --configFile | --enableRTRT | --disableRTRT | --disableCatalog | --deleteImmutableConfiguration

    --configFile gibt die Datenbank-Backupkonfigurationsdatei an.

    --enableRTRT aktiviert Echtzeit-Redo-Transport

    --disableRTRT deaktiviert den Echtzeit-Redo-Transport

    --disableCatalog deaktiviert Recovery-Katalog

    --deleteImmutableConfiguration löscht die unveränderliche Konfiguration

  • --getConfig gibt die Datenbank-Backupkonfiguration zurück

    [--configFile | --showOldParams]

    [--configFile gibt die Datenbank-Backupkonfigurationsdatei an]

    [--showOldParams gibt alte Parameternamen der Backupkonfiguration zurück.]

  • --validate validiert, ob Backups vollständig und fehlerfrei sind

    [--untilTime validiert das nächste (vollständige) Backup der Ebene 0 bis zur angegebenen Zeit. Eingabeformat: DD-MON-YYYY HH24:MI:SS]

  • --showHistory zeigt die Historie der Backupvorgänge an

    [--all zeigt alle Backupvorgänge an]

  • --getSchedules gibt alle Backupzeitpläne für eine angegebene Datenbank zurück
Hinweis

Die Parameter enableRTRT und disableRTRT gelten nur für ZDLRA-Backupziele in Exadata Database Service on Cloud@Customer.

dbaascli database bounce

Um eine angegebene Exadata Cloud Infrastructure-Datenbank herunterzufahren und neu zu starten, verwenden Sie den Befehl dbaascli database bounce.

Voraussetzungen

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli database bounce
[--dbname][--rolling <value>]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --rolling gibt durch true oder false an, ob die Datenbank im Rolling-Modus herunter- und wieder hochgefahren werden soll. Der Standardwert ist false.

Der Befehl fährt eine Datenbank im Immediate-Modus herunter. Die Datenbank wird dann neu gestartet und geöffnet. In Oracle Database 12c oder höher werden auch alle PDBs geöffnet.

Beispiel 6-9: dbaascli database bounce

dbaascli database bounce --dbname dbname

dbaascli database changepassword

Um das Kennwort eines angegebenen Oracle-Datenbankbenutzers zu ändern, verwenden Sie den Befehl dbaascli database changePassword. Wenn Sie dazu aufgefordert werden, geben Sie den Benutzernamen, für den Sie das Kennwort ändern möchten, und dann das Kennwort ein.

Voraussetzungen

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli database changePassword [--dbname <value>] [--user <value>]
{
  [--prepareStandbyBlob <value> [--blobLocation <value>]] | [--standbyBlobFromPrimary <value>]
}
[--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Namen der Oracle-Datenbank an, die Sie bearbeiten möchten.
  • --user gibt den Benutzernamen an, dessen Kennwort geändert werden muss.
  • --prepareStandbyBlob gibt true an, um eine BLOB-Datei mit den Artefakten zu generieren, die zum Ändern des Kennworts in einer Data Guard-Umgebung erforderlich sind. Gültige Werte: true|false
  • --blobLocation gibt den benutzerdefinierten Pfad an, in dem die BLOB-Datei generiert wird.
  • --standbyBlobFromPrimary gibt die Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird.
  • --resume gibt an, dass die vorherige Ausführung fortgesetzt werden soll.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.

Beispiel 6-10: dbaascli database changePassword

dbaascli database changepassword --dbname db19

dbaascli database convertToPDB

Um die angegebene Nicht-CDB-Datenbank in eine PDB zu konvertieren, verwenden Sie den Befehl dbaascli database convertToPDB.

Syntax

dbaascli database convertToPDB --dbname <value> [--cdbName <value>] [--executePrereqs]
        {
            [--copyDatafiles [--keepSourceDB]]|[backupPrepared]
        }
        [--targetPDBName <value>] [--waitForCompletion <value>] [--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Namen der Oracle-Datenbank an.
  • --cdbName gibt den Namen der Ziel-CDB an, in der die PDB erstellt wird. Wenn die CDB nicht vorhanden ist, wird sie im selben Oracle Home wie die Quell-Nicht-CDB erstellt.
  • --executePrereqs gibt an, dass nur die Prüfungen vor der Konvertierung ausgeführt werden sollen.
  • --copyDatafiles gibt an, dass eine neue Kopie der Datendateien erstellt werden soll, statt die Dateien aus der Quelldatenbank zu verwenden.

    --keepSourceDB dient zum Beibehalten der Quelldatenbank nach Abschluss des Vorgangs.

  • --backupPrepared: Flag zur Bestätigung, dass ein ordnungsgemäßes Datenbankbackup für die Nicht-CDB vorhanden ist, bevor die Konvertierung in die PDB ausgeführt wird.
  • --backupPrepared: Flag zur Bestätigung, dass ein ordnungsgemäßes Datenbankbackup für die Nicht-CDB vorhanden ist, bevor die Konvertierung in die PDB ausgeführt wird.
  • --targetPDBName gibt den Namen der PDB an, die im Rahmen des Vorgangs erstellt wird.
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true|false
  • --resume gibt an, dass die vorherige Ausführung fortgesetzt werden soll.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.

Beispiel 6-11: dbaascli database convertToPDB

So führen Sie die Vorabprüfungen vor der Konvertierung aus:
dbaascli database convertToPDB --dbname ndb19 --cdbname cdb19 --backupPrepared --executePrereqs
So führen Sie eine vollständige Konvertierung mit einer Kopie der Datendateien aus der Nicht-CDB aus:
dbaascli database convertToPDB --dbname tst19 --cdbname cdb19 --copyDatafiles

dbaascli database create

Um eine Oracle-Datenbank zu erstellen, verwenden Sie den Befehl dbaascli database create. Geben Sie bei entsprechender Aufforderung die Kennwörter für sys und tde ein.

Mit diesem Befehl können Sie eine Datenbank der Oracle-Database-Version 12.1.0.2 oder höher mit dem Releaseupdate JAN 2021 oder höher erstellen. Für Datenbanken mit niedrigeren Versionen wird die auf der OCI-Konsole-basierende API empfohlen.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database create --dbName {--oracleHome | --oracleHomeName}
[--dbUniqueName <value>]
[--dbSID <value>]
[--createAsCDB <value>]
[--pdbName <value>]
[--pdbAdminUserName <value>]
[--dbCharset <value>]
[--dbNCharset <value>]
[--dbLanguage <value>]
[--dbTerritory <value>]
[--sgaSizeInMB <value>]
[--pgaSizeInMB <value>]
[--datafileDestination <value>]
[--fraDestination <value>]
[--fraSizeInMB <value>]
[--nodeList <value>]
[--tdeConfigMethod <value>]
[--kmsKeyOCID <value>]
{
            [--resume [--sessionID <value>]]
            | [--revert [--sessionID <value>]]
        }
[--executePrereqs]
[--honorNodeNumberForInstance <value>]
[--lockPDBAdminAccount <value>]
[--dbcaTemplateFilePath <value>]
[--waitForCompletion]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --oracleHome gibt das Verzeichnis des Oracle Homes an.
  • --oracleHomeName gibt den Namen des Oracle Homes an.
  • --dbUniqueName gibt einen eindeutigen Datenbanknamen an.
  • --dbSID gibt die SID der Datenbank an.
  • --createAsCDB: Geben Sie true oder false an, um die Datenbank als CDB oder Nicht-CDB zu erstellen.
  • --pdbName: Geben Sie den PDB-Namen an.
  • --pdbAdminUserName: Geben Sie den PDB-Admin-Benutzernamen an.
  • --dbCharset gibt den Datenbankzeichensatz an.
  • --dbNCharset gibt den länderspezifischen Zeichensatz der Datenbank an.
  • --dbLanguage gibt die Datenbanksprache an.
  • --dbTerritory gibt das Datenbankgebiet an.
  • --sgaSizeInMB gibt den sga_target-Wert in Megabyte an.
  • --pgaSizeInMB gibt den pga_aggregate_target-Wert in Megabyte an.
  • --datafileDestination gibt den Namen der ASM-Datenträgergruppe an, die für Datenbankdatendateien verwendet werden soll.
  • --fraDestination gibt den ASM-Datenträgergruppennamen an, der für den Fast Recovery-Bereich der Datenbank verwendet werden soll.
  • --fraSizeInMB gibt den Wert für die Größe des Fast Recovery-Bereichs in Megabyte an.
  • --nodeList gibt eine kommagetrennte Liste von Knoten für die Datenbank an.
  • --tdeConfigMethod gibt die TDE-Konfigurationsmethode an. Gültige Werte: FILE, KMS
  • --kmsKeyOCID gibt die für TDE zu verwendende KMS-Schlüssel-OCID an. Gilt nur, wenn KMS für TDE ausgewählt ist.
  • --resume setzt die vorherige Ausführung fort.
  • --revert setzt die letzte Ausführung zurück.
  • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt oder zurückgesetzt werden soll.
  • --executePrereqs ist auf yes gesetzt, wenn nur die Voraussetzungen für diesen Vorgang geprüft werden sollen. Gültige Werte: yes oder no
  • --honorNodeNumberForInstance gibt durch true oder false an, ob an den Instanznamen Clusterknotennummern als Suffix angehängt werden sollen. Standardwert: true
  • --lockPDBAdminAccount: Geben Sie true oder false an, um den PDB-Admin-Benutzeraccount zu sperren. Standardwert ist True
  • --dbcaTemplateFilePath: Geben Sie den absoluten Pfad des DBCA-Vorlagennamens an, um die Datenbank zu erstellen.
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true oder false

Beispiel 6-12: dbaascli database create

dbaascli database create --dbName db19 --oracleHomeName myhome19 --dbSid db19sid --nodeList node1,node2 --createAsCDB true

dbaascli database delete

Um eine Oracle-Datenbank zu löschen, verwenden Sie den Befehl dbaascli database delete.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database delete --dbname <value>
[--deleteArchiveLogs <value>]
[--deleteBackups <value>]
[--precheckOnly <value>]
[--waitForCompletion <value>]
[--force]
[--dbSID <value>]
[--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --deleteArchiveLogs gibt durch true oder false an, ob die Datenbank-Archive-Logs gelöscht werden oder nicht.
  • --deleteBackups gibt durch true oder false an, ob die Datenbankbackups gelöscht werden oder nicht.
  • --precheckOnly gibt durch yes an, dass nur die Vorabprüfungen für diesen Vorgang ausgeführt werden. Gültige Werte: yes oder no.
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true oder false.
  • –-force: Flag, mit dem das Löschen der Datenbank erzwungen wird.
  • --dbSID: Geben Sie die Datenbank-SID an.
  • --resume setzt die vorherige Ausführung fort.
  • --sessionID setzt eine bestimmte Session-ID fort.

Beispiel 6-13: dbaascli database delete

dbaascli database delete --dbname db19

dbaascli database deleteInstance

Um die Datenbankinstanz auf dem angegebenen Knoten zu löschen, verwenden Sie den Befehl dbaascli database deleteInstance.

Voraussetzung

  • Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database deleteInstance --dbname <value> --node <value> [--continueOnUnreachableNode]
Dabei gilt:
  • --dbname gibt den Namen der Oracle-Datenbank an.
  • --node gibt den Knotennamen für die Datenbankinstanz an.
  • --continueOnUnreachableNode gibt an, dass der Vorgang auch ausgeführt werden soll, wenn der Knoten nicht erreichbar ist.

Beispiel 6-14: database deleteinstance

database deleteinstance --node test-node

dbaascli database duplicate

Um eine Datenbank aus einer aktiven Datenbank zu erstellen, verwenden Sie den Befehl dbaascli database duplicate.

Voraussetzung

  • Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database duplicate --dbName <value> --sourceDBConnectionString <value>
        {
            --oracleHome <value>
            | --oracleHomeName <value>
        }
[--dbSID <value>] 
[--dbUniqueName <value>] 
[--sgaSizeInMB <value>] 
[--pgaSizeInMB <value>] 
[--datafileDestination <value>] 
[--fraDestination <value>] 
[--fraSizeInMB <value>] 
[--sourceDBWalletLocation <value>] 
[--nodeList <value>]
        {
            [--resume [--sessionID <value>]]
            | [--revert [--sessionID <value>]]
        }
[--rmanParallelism <value>]
[--rmanSectionSizeInGB <value>]
[--tdeConfigMethod <value>]
[--kmsKeyOCID <value>]
[--sourceDBTdeConfigMethod <value>]
[--sourceDBKmsKeyOCID <value>]
[--executePrereqs <value>] 
[--waitForCompletion <value>]
[--skipPDBs <value>]
Dabei gilt:
  • --dbName gibt den Namen der Oracle-Datenbank an.
  • --sourceDBConnectionString gibt die Verbindungszeichenfolge der Quelldatenbank im Format <scan_name>:<scan_port>/<database_service_name> an.
  • --oracleHome gibt das Oracle Home-Verzeichnis an.
  • --oracleHomeName gibt den Namen des Oracle Homes an.
  • --dbSID gibt die Datenbank-SID an.
  • --dbUniqueName gibt einen eindeutigen Datenbanknamen an.
  • --sgaSizeInMB gibt den sga_target-Wert in Megabyte an.
  • --pgaSizeInMB gibt den pga_aggregate_target-Wert in Megabyte an.
  • --datafileDestination gibt den Namen der ASM-Datenträgergruppe an, die für Datenbankdatendateien verwendet werden soll.
  • --fraDestination gibt den ASM-Datenträgergruppennamen an, der für den Fast Recovery-Bereich der Datenbank verwendet werden soll.
  • --fraSizeInMB gibt die Größe des Fast Recovery-Bereichs in Megabyte an.
  • --sourceDBWalletLocation gibt den Speicherort der TDE-Wallet-Datei der Quelldatenbank an. Diese Angabe ist erforderlich, um die Datenbank aus der aktiven Datenbank zu duplizieren.
  • --nodeList gibt eine kommagetrennte Liste von Knoten für die Datenbank an.
  • --resume gibt an, dass die vorherige Ausführung fortgesetzt werden soll.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --revert gibt an, dass ein Rollback der vorherigen Ausführung durchgeführt werden soll.
    • --sessionID gibt an, dass ein Rollback einer bestimmten Session-ID durchgeführt werden soll.
  • --rmanParallelism gibt den Parallelitätswert an.
  • --rmanSectionSizeInGB gibt die RMAN-Abschnittsgröße in GB an.
  • --tdeConfigMethod gibt die TDE-Konfigurationsmethode an. Zulässige Werte sind FILE und KMS.
  • --kmsKeyOCID gibt die für TDE zu verwendende KMS-Schlüssel-OCID an. Gilt nur, wenn KMS für TDE ausgewählt ist.
  • --sourceDBTdeConfigMethod gibt die TDE-Konfigurationsmethode der Quelldatenbank an. Zulässige Werte sind FILE und KMS.
  • --sourceDBKmsKeyOCID gibt die für TDE zu verwendende KMS-Schlüssel-OCID der Quelldatenbank an. Gilt nur, wenn KMS für TDE ausgewählt ist.
  • --executePrereqs ist auf yes gesetzt, wenn nur die Voraussetzungen für diesen Vorgang geprüft werden sollen. Gültige Werte: yes|no
  • --waitForCompletion gibt false an, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false
  • --skipPDBs gibt eine durch Komma getrennte Liste der PDB-Namen der Quelldatenbank an, die bei der Datenbankduplizierung ausgeschlossen werden muss. Beispiel: pdb1,pdb2...

Beispiel 6-15: dbaascli database duplicate

dbaascli database duplicate --sourceDBConnectionString test-user-scan.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com:1521/mynew.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2 --dbName newdup --sourceDBWalletLocation /var/opt/oracle/dbaas_acfs/tmp/prim_wallet

dbaascli database getDetails

Dieser Befehl zeigt detaillierte Informationen zu einer bestimmten Datenbank an, beispielsweise Name der Datenbank, Knoteninformationen, Informationen zu integrierbaren Datenbanken usw.

Voraussetzungen

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli database getDetails --dbname <value>
Dabei gilt:
  • --dbname: Name der Oracle-Datenbank.

dbaascli database getPDBs

Um die Liste aller integrierbaren Datenbanken in einer Containerdatenbank anzuzeigen, verwenden Sie den Befehl dbaascli database getPDBs.

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli database getPDBs --dbname <value>
Dabei gilt:
  • --dbname gibt den Namen der Containerdatenbank an.

Beispiel 6-16: dbaascli database getPDBs --dbname

dbaascli database getPDBs --dbname apr_db1

dbaascli database modifyParameters

Um Initialisierungsparameter für eine Oracle-Datenbank zu ändern oder zurückzusetzen, verwenden Sie den Befehl dbaascli database modifyParameters.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database modifyParameters --dbname <value> --setParameters <values>| --resetParameters <values> | --responseFile
[--backupPrepared]
[--instance]
[--allowBounce]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --setParameters gibt eine kommagetrennte Liste von Parametern an, die neue Werte erhalten sollen. Beispiel: parameter1=valueA,parameter2=valueB usw. Verwenden Sie für leere Werte parameter1=valueA,parameter2=" usw.
  • --resetParameters gibt eine kommagetrennte Liste von Parametern an, die auf ihre jeweiligen Standardwerte zurückgesetzt werden sollen. Beispiel: parameter1,parameter2 usw.
  • --responseFile gibt den absoluten Speicherort der JSON-Antwortdatei für die Änderung der Datenbankparameter an.
  • --backupPrepared bestätigt, dass ein ordnungsgemäßes Datenbankbackup vorhanden ist, bevor kritische oder sensible Parameter geändert werden.
  • --instance gibt den Namen der Instanz an, auf der die Parameter verarbeitet werden. Wenn keine Angabe gemacht wird, wird der Vorgang auf Datenbankebene ausgeführt.
  • --allowBounce erteilt die Berechtigung zum Herunter- und Hochfahren der Datenbank, damit die Änderungen an den anwendbaren statischen Parametern wiedergegeben werden.

Beispiel 6-17: dbaascli database modifyParameters

dbaascli database modifyParameters --dbname dbname --setParameters "log_archive_dest_state_17=ENABLE"

dbaascli database move

Verwenden Sie den dbaascli database move-Befehl, um die Datenbank von einem Home in ein anderes zu verschieben.

Voraussetzungen

  • Stellen Sie vor dem Ausführen eines Verschiebevorgangs sicher, dass alle mit der Datenbank verknüpften Datenbankinstanzen gestartet und hochgefahren sind.
  • Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database move
        {
            --oracleHome <value>
            | --oracleHomeName <value>
        }
        --dbname <value>
        {
            [--resume [--sessionID <value>]]
            | [--rollback [--sessionID <value>]]
        }
[--executePrereqs]
[--nonRolling]
[--skipDatapatch]
[--skipPDBs <value>]
[--skipClosedPDBs]
[--continueWithDbDowntime]
[--drainTimeoutInSeconds <value>]
[--allowParallelDBMove]
[--waitForCompletion <value>]
[--nodeList <value>]

Dabei gilt:

  • --oracleHome gibt den Pfad des Oracle Homes an.
  • --oracleHomeName gibt den Namen des Oracle Homes an.
  • --dbname gibt den Namen der Datenbank an.
  • --executePrereqs führt die Voraussetzungsprüfungen aus und meldet die Ergebnisse.
  • --nonRolling verschiebt die Datenbank parallel auf allen Knoten.

    Beachten Sie, dass dies zu Ausfallzeiten der Datenbank führen würde.

  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --rollback rollt die Datenbank zurück zum vorherigen Home
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --skipDatapatch überspringt die Ausführung von Datapatch in den Datenbanken.
  • --skipPdbs überspringt die Ausführung von datapatch in einer angegebenen kommagetrennten Liste von PDBs.

    Beispiel: pdb1,pdb2...

  • --skipClosedPDBs überspringt das Patching geschlossener PDBs.
  • --continueWithDbDowntime setzt das Patching mit Datenbankausfallzeit fort.

    Diese Option kann in Umgebungen verwendet werden, in denen nur eine aktive Instanz hochgefahren ist und der Patching-Vorgang auch mit einer Ausfallzeit fortgesetzt werden kann.

  • --drainTimeoutInSeconds gibt die Zeit (in Sekunden) für den Abschluss des Ressourcen-Drains an, während die Datenbank gestoppt wird.
  • Mit --allowParallelDBMove lässt sich die Datenbank parallel verschieben.
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll.

    Gültige Werte: true|false

  • --nodeList gibt eine kommagetrennte Liste von Knoten an, wenn der Vorgang für eine Teilmenge von Knoten ausgeführt werden muss.

Beispiel 6-18: dbaascli database move

dbaascli database move --dbname testdb1 --oracleHome /u02/app/oracle/product/12.1.0/dbhome_2

dbaascli database recover

Um eine Datenbank wiederherzustellen, verwenden Sie den Befehl dbaascli database recover.

Voraussetzung

  • Führen Sie den Befehl als Benutzer root aus.
  • Die Datenbank muss mit den Details des Backupspeicherziels konfiguriert sein, in dem Backups gespeichert werden.

Syntax

dbaascli database recover --dbname <value>
        {
            --start
                {
                    --untilTime <value>
                    | --untilSCN <value>
                    | --latest
                    | --tag <value>
                }
            | --status --uuid <value>
        }
Dabei gilt:
--dbname: Oracle Database name.
      --start | --status
--start: Begins database recovery.
      --untilTime | --untilSCN | --latest | --tag
      --untilTime: Recovers database until time. Input format: DD-MON-YYYY HH24:MI:SS.
      --untilSCN: Recovers database until SCN.
      --latest: Recovers database to last known state.
      --tag: Recovers database to archival tag.
--status
      --uuid <value>

Beispiel 6-19: Beispiele

  • So stellen Sie die Datenbank myTestDb auf den neuesten Stand wieder her:
    dbaascli database recover --dbname myTestDb --start --latest
  • So fragen Sie den Status der mit uuid 2508ea18be2911eb82d0020017075151 übermittelten Recovery-Anforderung ab:
    dbaascli database recover --dbname myTestDb --status --uuid 2508ea18be2911eb82d0020017075151

dbaascli database runDatapatch

Um eine Oracle-Datenbank zu patchen, verwenden Sie den Befehl dbaascli database runDatapatch.

Voraussetzungen

  • Stellen Sie vor dem Ausführen eines runDatapatch-Vorgangs sicher, dass alle mit der Datenbank verknüpften Datenbankinstanzen gestartet und hochgefahren sind.

  • Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database runDatapatch --dbname
[--resume]
    [--sessionID]
[--skipPdbs | --pdbs]
[--executePrereqs]
[--patchList]
[--skipClosedPdbs]
[--rollback]

Dabei gilt:

  • --dbname gibt den Namen der Datenbank an.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --skipPdbs überspringt die Ausführung von datapatch in einer angegebenen kommagetrennten Liste von PDBs. Beispiel: pdb1,pdb2...
  • --pdbs führt datapatch nur in einer angegebenen kommagetrennten Liste von PDBs aus. Beispiel: pdb1,pdb2...
  • --executePrereqs führt Voraussetzungsprüfungen aus.
  • --patchList wendet die angegebene kommagetrennte Patchliste an oder setzt sie zurück. Beispiel: patch1,patch2...
  • --skipClosedPdbs überspringt die Ausführung von datapatch in geschlossenen PDBs.
  • --rollback führt ein Rollback der eingespielten Patches aus.
dbaascli database runDatapatch --dbname db19

dbaascli database createTemplate

Mit diesem Befehl können Sie Datenbankvorlagen (DBCA-Vorlagen) erstellen, mit denen anschließend Datenbanken erstellt werden können.

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

Erstellen Sie eine neue DBCA-Vorlage aus der angegebenen Datenbank.

dbaascli database createTemplate --dbname <value>
 {
   --templateLocation <value> | --uploadToObjectStorage --objectStorageLoginUser <value> --objectStorageBucketName <value> [--objectStorageUrl <value>]
 }
 [--templateName <value>] [--rmanParallelism <value>]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --templateLocation gibt den Vorlagennamen an
  • --uploadToObjectStorage: Gibt an, dass die Vorlage in Object Storage hochgeladen werden soll
    • --objectStorageLoginUser: Gibt den Benutzer für die Object Storage-Anmeldung an
    • --objectStorageBucketName: Gibt den Namen des Object Storage-Buckets an
    • --objectStorageUrl: Gibt die Object Storage-URL an
  • --templateName: Gibt den Namen der Vorlage an
  • --rmanParallelism: Gibt den Parallelitätswert an

dbaascli database start

Um eine Oracle-Datenbank zu starten, verwenden Sie den Befehl dbaascli database start.

Voraussetzungen

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database start
[--dbname]
[--mode]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --mode gibt durch "mount" oder "nomount" an, in welchem Modus die Datenbank gestartet wird.

Der Befehl startet und öffnet die Datenbank. In Oracle Database 12c oder höher werden auch alle PDBs geöffnet.

Beispiel 6-20: dbaascli database start

dbaascli database start --dbname dbname --mode mount

dbaascli database status

Um den Status einer Oracle--Datenbank zu prüfen, verwenden Sie den Befehl dbaascli database status.

Voraussetzungen

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database status
[--service][--dbname] 
[--user]
[--password]
Dabei gilt:
  • --service gibt den Namen des Service an.
  • --dbname gibt den Namen der Datenbank an.
  • --user gibt den Benutzernamen des Service an.
  • --password gibt das Kennwort des Benutzers an.

Die Ausgabe des Befehls enthält den Open-Modus der Datenbank, das Softwarerelease und die Edition der Datenbank sowie die Releaseversion anderer Softwarekomponenten.

Beispiel 6-21: dbaascli database status

dbaascli database status --dbname db19

dbaascli database stop

Um eine Oracle-Datenbank zu stoppen, verwenden Sie den Befehl dbaascli database stop.

Voraussetzungen

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database stop
[-–dbname <value>]
[--mode <value>]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an, die Sie stoppen möchten.
  • --mode gibt den Modus der Datenbank an. Gültige Werte: abort, immediate, normal, transactional

Der Befehl fährt eine Datenbank im Immediate-Modus herunter. Es sind keine neuen Verbindungen oder Transaktionen zulässig. Für aktive Transaktionen wird ein Rollback durchgeführt, und die Verbindungen aller Benutzer werden getrennt.

Beispiel 6-22: dbaascli database stop

dbaascli database stop --dbname db19

dbaascli database upgrade

Um ein Upgrade einer Oracle-Datenbank auszuführen, verwenden Sie den Befehl dbaascli database upgrade.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli database upgrade --dbname <value> 
{--targetHome <value> | --targetHomeName <value>}
{ [--executePrereqs | --postUpgrade | --rollback]}
{[--standBy | --allStandbyPrepared]}
{[--upgradeOptions <value>]  | [--standBy]}
[--removeGRP]
[--increaseCompatibleParameter]
[--resume [--sessionID <value>]]
[--waitForCompletion <value>]
Dabei gilt:
  • --dbname (obligatorisch) gibt den Namen der Datenbank an.
  • --targetHome gibt das Zielverzeichnis des Oracle Homes an.
  • --targetHomeName gibt den Namen des Ziel-Homes der Oracle-Datenbank an.
  • --standBy wird für Upgrades von Standbydatenbanken in Data Guard-Konfigurationen verwendet.
  • --allStandbyPrepared ist für mit Data Guard konfigurierte Primärdatenbanken erforderlich. Flags, die bestätigen, dass alle erforderlichen Vorgänge in den Standbydatenbanken vor dem Upgrade der Primärdatenbank ausgeführt wurden.
  • --removeGRP entfernt das garantierte Restore-Point-(GRP-)Backup nur dann automatisch, wenn das Datenbankupgrade erfolgreich war.
  • --increaseCompatibleParameter erhöht den Kompatibilitätsparameter im Rahmen des Datenbankupgrades automatisch. Der Parameter wird nur erhöht, wenn das Datenbankupgrade erfolgreich war.
  • --executePrereqs führt nur die Prüfungen vor dem Upgrade aus.
  • --postUpgrade wird verwendet, wenn die Schritte nach dem Upgrade nicht erfolgreich waren und erneut ausgeführt werden müssen.
  • --rollback setzt eine Oracle-Datenbank auf das ursprüngliche Oracle Home zurück.
  • --upgradeOptions wird verwendet, um DBUA-spezifische Argumente zur Ausführung des Oracle Database-Upgrades zu übergeben. Die unterstützten Argumente und Optionen finden Sie in der entsprechenden Oracle-Dokumentation.

    --standby

  • --resume setzt die vorherige Ausführung fort.
  • --sessionID setzt eine bestimmte Session-ID fort.
  • --waitForCompletion: Geben Sie "false" an, um den Vorgang im Hintergrund auszuführen. Gültige Werte : true|false.

Beispiel 6-23: dbaascli database upgrade - Voraussetzungsprüfungen vor dem Upgrade

dbaascli database upgrade --dbbname dbname --targetHome Target Oracle home location --executePrereqs

dbaascli dataguard prepareStandbyBlob

Um eine BLOB-Datei zu generieren, die verschiedene Dateien enthält, die auf der Standbysite im Fall einer Data Guard-Umgebung erforderlich sind, verwenden Sie den Befehl dbaascli dataguard prepareStandbyBlob.

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli dataguard prepareStandbyBlob --dbname <value> --blobLocation <value>
Dabei gilt:
  • --dbname gibt den Namen der Oracle-Datenbank an.
  • --blobLocation gibt den Speicherort des benutzerdefinierten Verzeichnisses an, in dem die Standby-BLOB-Datei in einer Data Guard-Umgebung generiert wird.

dbaascli dataguard updateDGConfigAttributes

Um Data Guard-Automatisierungsattribute über alle Clusterknoten hinweg zu aktualisieren, verwenden Sie den Befehl dbaascli dataguard updateDGConfigAttributes.

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli dataguard updateDGConfigAttributes --attributes <value>
Dabei gilt:
  • --attributes enthält die zu ändernden Data Guard-Automatisierungsattribute. Akzeptiert kommagetrennte Werte im Format <attribute=value>. Attribute müssen in der Data Guard-Konfigurationsdatei vordefiniert sein.

dbaascli dataguard-Failover

Um einen manuellen Failover zur Standbydatenbank auszuführen, verwenden Sie den Befehl dataguard failover.

Führen Sie diesen Befehl als Benutzer oracle in der Standby-Zieldatenbank aus.

Syntax

dbaascli dataguard failover --dbname <value> [--useImmediateFailover] [--executePrereqs] [--waitForCompletion <value>] [--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --useImmediateFailover verwenden dieses Flag, wenn die Oracle Data Guard-Konfiguration einen Warnungs- oder Fehlerstatus aufweist.
  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --waitForCompletion gibt an, ob der Abschluss des Vorgangs gewartet werden soll. Setzen Sie diesen Wert auf false, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.
Manuellen Failover-Vorgang mit dem Utility dbaascli ausführen

Um einen manuellen Failover zur Standbydatenbank auszuführen, verwenden Sie den Befehl dataguard failover.

  1. Stellen Sie eine Verbindung zur virtuellen Maschine in der Oracle Data Guard-Konfiguration her, in der die neue Primärdatenbank als Benutzer opc gehostet wird.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell des Root-Benutzers, und wechseln Sie zum Benutzer oracle:
    $ sudo -s
    # su - oracle
    $
  3. Starten Sie den Failover zur Standbydatenbank.
    $ dbaascli dataguard failover --dbname <db-name>
  4. Kehren Sie als Benutzer root zurück.
    $ exit
    #
  5. Beenden Sie die Befehlsshell des Root-Benutzers, und trennen Sie die Anmeldung bei der virtuellen Maschine.
    # exit
    $ exit

dbaascli dataguard neu instanziieren

Um eine ausgefallene Datenbank nach einem Failover als Standbydatenbank neu zu instanziieren, verwenden Sie den Befehl dataguard reinstate.

Führen Sie diesen Befehl als Benutzer oracle aus, auf dem eine Neuinstanziierung erforderlich ist (d.h. nicht erfolgreiche Standbydatenbank).

Syntax

dbaascli dataguard reinstate --dbname <value> [--primaryDBUniqueName <value>] [--executePrereqs] [--waitForCompletion <value>] [--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --primaryDBUniqueName gibt den eindeutigen Datenbanknamen der aktuellen Primärdatenbank im Oracle Data Guard-Setup an.
  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --waitForCompletion gibt an, ob der Abschluss des Vorgangs gewartet werden soll. Setzen Sie diese Option auf false, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.

So legen Sie fest, wann ein Member in einer Data Guard-(DG-)Konfiguration neu instanziiert werden soll:

Überwachen Sie die Ausgabe dgmgrl show database auf die folgenden ORA-Fehler:

  • Auf dem neuen primären Cluster:

    ORA-16661: Die Standbydatenbank muss neu instanziiert werden

  • Auf dem alten primären Cluster:

    ORA-16623: Mitglied hat Rollenwechsel ermittelt

Diese Meldungen zeigen an, dass ein Failover stattgefunden hat. Um die vollständige Synchronisierung innerhalb der Data Guard-Konfiguration wiederherzustellen, muss die frühere Primärdatenbank neu instanziiert werden.

Nicht erfolgreiche Primärdatenbank mit dem dbaascli-Utility neu instanziieren

Um eine nicht erfolgreiche Primärdatenbank nach einem Failover neu zu instanziieren, verwenden Sie den Befehl dataguard reinstate.

  1. Stellen Sie als Benutzer oracle eine Verbindung zu einer der virtuellen Maschinen in der Oracle Data Guard-Konfiguration her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie die Neuinstanziierung der nicht erfolgreichen Primärdatenbank.
    $ dbaascli dataguard reinstate --dbname <db-name>

    In einem Setup mit mehreren Standby-Datenbanken (Data Guard-Gruppe) wird empfohlen, das Argument --primaryDBUniqueName anzugeben.

    dbaascli dataguard reinstate --dbname <db-name> --primaryDBUniqueName <primary-DB-unique-name>
  3. Trennen Sie die Verbindung zur virtuellen Maschine.
    $ exit

dbaascli dataguard-Switchover

Um einen Switchover zur Standbydatenbank auszuführen, verwenden Sie den Befehl dataguard switchover.

Führen Sie diesen Befehl als Benutzer oracle aus.

Syntax

dbaascli dataguard switchover --dbname <value> [--targetStandbyDBUniqueName <value>] [--executePrereqs] [--enableDGDebug] [--waitForCompletion <value>] [--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --targetStandbyDBUniqueName gibt den eindeutigen Namen der Standbydatenbank an, um die Rolle von Standby- zu Primärdatenbank zu ändern.
  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --enableDGDebug aktiviert die Traces während der Ausführung des Vorgangs.
  • --waitForCompletion gibt an, ob der Abschluss des Vorgangs gewartet werden soll. Setzen Sie diese Option auf false, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.
Switchover-Vorgang mit dem Utility dbaascli ausführen

Um einen Switchover zur Standbydatenbank auszuführen, verwenden Sie den Befehl dataguard switchover.

  1. Stellen Sie eine Verbindung zur virtuellen Maschine in der Oracle Data Guard-Konfiguration her, in der die neue Primärdatenbank als Benutzer opc gehostet wird.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie eine Befehlsshell des Root-Benutzers, und wechseln Sie dann zum Benutzer oracle.
    $ sudo -s
    # su - oracle
    $
  3. Starten Sie den Switchover zur Standbydatenbank.
    $ dbaascli dataguard switchover --dbname <db-name>

    In einem Setup mit mehreren Standby-Datenbanken (Data Guard-Gruppe) wird empfohlen, das Argument --targetStandbyDBUniqueName anzugeben.

    dbaascli dataguard switchover --dbname <db-name> --targetStandbyDBUniqueName <target-standby-DB-unique-name>
  4. Kehren Sie als Benutzer root zurück.
    $ exit
    #
  5. Beenden Sie die Befehlsshell des Root-Benutzers, und trennen Sie die Anmeldung bei der virtuellen Maschine.
    # exit
    $ exit

dbaascli dataguard prepareForStandby

Um eine Oracle Standbydatenbank zu erstellen, verwenden Sie den Befehl dbaascli dataguard prepareForStandby als ersten Schritt.

Führen Sie diesen Befehl als Benutzer root in der Primärdatenbank aus. Am Ende der Befehlsausführung wird eine Standby-BLOB-Datei erstellt. Sie müssen diese Datei in das Standbydatenbanksystem kopieren, um mit dem Schritt configureStandby fortzufahren.

Hinweis

Bei Disaster-Recovery-(DR-)Konfigurationen auf Exadata Cloud@Customer (ExaDB-C@C) müssen Sie Data Guard mit der Oracle Cloud Infrastructure-(OCI-)Konsole oder dem OCI-SDK einrichten. Das Utility dbaascli wird für diesen Anwendungsfall nicht unterstützt und darf nicht verwendet werden.

Syntax

dbaascli dataguard prepareForStandby --dbname <value> --standbyDBUniqueName <value>  --standbyDBDomain | --noDBDomain  --standbyScanIPAddresses <Standby SCAN IP Addresses> [ --standbyScanPort ] [ --standbyServiceName ] [  -- primaryScanIPAddresses ] [ --primaryScanPort ] [--executePrereqs] [--resume [--sessionID <value>]] [--revert [--sessionID <value>]] [--waitForCompletion] [--skipDRConfiguration]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --standbyDBUniqueName gibt den eindeutigen Namen der Standbydatenbank, für die die Primärdatenbank konfiguriert wird.
  • --standbyDBDomain gibt die Standbydatenbankdomäne an, für die die Primärdatenbank konfiguriert wird.
  • --noDBDomain gibt an, dass nicht der Datenbankdomainname für eine Standbydatenbank verwendet werden darf.
  • --standbyScanIPAddresses gibt eine kommagetrennte Liste von IP-Adressen an, die dem SCAN-Listener für die Standbydatenbank oder dem SCAN-Namen der Standbydatenbank entsprechen.
  • --standbyScanPort gibt die zugehörige SCAN-Portnummer der Standbydatenbank an.
  • --standbyServiceName gibt den Namen des Standby-Datenbankservice an, für den die Primärdatenbank konfiguriert wird.
  • --primaryScanIPAddresses gibt eine kommagetrennte Liste von IP-Adressen an, die dem SCAN-Listener für die Primärdatenbank oder dem SCAN-Namen der Primärdatenbank entsprechen.
  • --primaryScanPort gibt die zugehörige SCAN-Portnummer der Primärdatenbank an.
  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.
  • --revert setzt den vorherigen Vorgang zurück.
  • --waitForCompletion gibt an, ob der Abschluss des Vorgangs gewartet werden soll. Setzen Sie diese Option auf false, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false.
  • --skipDRConfiguration gibt an, ob die Disaster-Recovery-(DR-)Konfiguration im Rahmen des Standbydatenbanksetups übersprungen werden soll. Gültige Werte: true (DR-Konfiguration überspringen) oder false (DR konfigurieren).
Vorgang PrepareForStandby mit dem Utility dbaascli ausführen

Um die Primärdatenbank auf das Erstellen einer neuen Standbydatenbank vorzubereiten, verwenden Sie den Befehl dbaascli dataguard prepareForStandby.

  1. Stellen Sie eine Verbindung zur virtuellen Maschine her, auf der die Primärdatenbank als Benutzer opc gehostet werden soll.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie die Befehlsshell des Root-Benutzers.
    $ sudo -s
  3. Führen Sie den Befehl prepareForStandby aus. Geben Sie das SYS-Kennwort ein, wenn Sie dazu aufgefordert werden.
    dbaascli dataguard prepareForStandby --dbName <db name> --standbyDBUniqueName <standby db unique name> --standbyDBDomain <standby db domain> --standbyScanIPAddresses  <comma-delimieted list of standby SCAN IP addresses> --primaryScanIPAddresses <comma-delimited list of primary SCAN IP addresses> --standbyScanPort <standby SCAN listener port>

    Nach Abschluss zeigt der Befehl den Speicherort an, in dem die Standby-BLOB-Datei erstellt wird.

  4. Beenden Sie die Befehlsshell des Root-Benutzers, und trennen Sie die Anmeldung bei der virtuellen Maschine.
    #  exit

dbaascli dataguard configureStandby

Um eine neue Standbydatenbank zu erstellen, verwenden Sie den Befehl dbaascli dataguard configureStandby als zweiten Schritt nach dem Schritt prepareForStandby.

Führen Sie diesen Vorgang als Benutzer root im Standbycluster aus.

Syntax

dbaascli dataguard configureStandby --dbname <value>  --oracleHome <value> | --oracleHomeName <value> --standbyDBUniqueName <value> [--standbyDBDomain <value>] | [--noDBDomain] --primaryScanIPAddresses <value> --primaryScanPort <value> --primaryServiceName <value> --protectionMode <value> --transportType <value> --activeDG <value> [--standbyBlobFromPrimary <value>] | [--standbyDBInfoJsonLocation <value>] [--standbyScanIPAddresses <value>] [--standbyScanPort <value>] [--standbySID <value>] [--nodeList <value>] [--skipAWRConfiguration] [--primaryDBOCID <value>] [--sgaSizeInMB <value>] [--pgaSizeInMB <value>] [--datafileDestination <value>] [--fraDestination <value>] [--redoLogDestination <value>] [--fraSizeInMB <value>] [--tdeKeyStoreType <value> [--tdeKeyOCID <value>]] [--tdeKeyOCID <value>] [--executePrereqs]  [--resume [--sessionID <value>]] | [--revert [--sessionID <value>]] --waitForCompletion <value>] [--enableFIPS <value>] [--skipDRConfiguration] [--okvServer <value> --okvAdminUserName <value> [--okvServerRestPort <value>]] [--okvWalletName <value>]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --oracleHome gibt den Oracle Home-Pfad an.
  • --oracleHomeName gibt den Oracle Home-Namen an.
  • --standbyDBUniqueName gibt den eindeutigen Datenbanknamen für die Standby-Datenbank an.
  • --standbyDBDomain gibt die Standbydatenbankdomäne an, für die die Primärdatenbank konfiguriert wird.
  • --noDBDomain gibt an, dass nicht der Datenbankdomainname für eine Standbydatenbank verwendet werden darf.
  • --primaryScanIPAddresses gibt eine kommagetrennte Liste von IP-Adressen an, die dem SCAN-Listener für die Primärdatenbank oder dem SCAN-Namen der Primärdatenbank entsprechen.
  • --primaryScanPort gibt die entsprechende SCANNEN-Portnummer des Primärdatenbank-Service an.
  • --primaryServiceName gibt den Namen des Primärdatenbankdienstes an, für den die Standbydatenbank konfiguriert wird.
  • --protectionMode gibt den Data Guard-Schutzmodus an, der beim Konfigurieren der Standbydatenbank festgelegt werden soll. Gültige Werte: MAX_PERFORMANCE|MAX_AVAILABILITY.
  • --transportType gibt den Data Guard-Transporttyp an, der beim Konfigurieren der Standbydatenbank festgelegt werden soll. Gültige Werte: ASYNC|SYNC.
  • --activeDG gibt an, ob die Data Guard-Konfiguration aktiv ist oder nicht. Gültige Werte: true|false.
  • --standbyBlobFromPrimary gibt den Speicherort der Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird. Dies ist nur für Standbyvorgänge erforderlich.
  • --standbyDBInfoJsonLocation gibt den Speicherort der Informationsdatei an, die aus der Primärdatenbank zum Exportieren zusätzlicher Metadaten generiert wird. Diese Option ist nur für Standbyvorgänge erforderlich.
  • --standbyScanIPAddresses gibt eine kommagetrennte Liste von IP-Adressen an, die dem SCAN-Listener für die Standbydatenbank oder dem SCAN-Namen der Standbydatenbank entsprechen.
  • --standbyScanPort gibt die zugehörige SCAN-Portnummer der Standbydatenbank an.
  • --standbySID gibt die Standbydatenbank-SID für eine Standby-Konfiguration an.
  • --nodeList gibt eine Liste der Knoten an, auf denen die Standbydatenbank ausgeführt werden soll, einschließlich Knoten, die bereits ausgeführt oder konfiguriert sind.
  • --skipAWRConfiguration gibt an, ob die Oracle AWR-Konfiguration im Rahmen des Standbydatenbanksetups übersprungen werden soll. Gültige Werte: true (AWR-Konfiguration überspringen) oder false (AWR konfigurieren).
  • --primaryDBOCID gibt den Ressourcen-OCID-Wert für die Primärdatenbank an.
  • --sgaSizeInMB gibt den Wert sga_target in MB an.
  • --pgaSizeInMB gibt den pga_aggregate_target-Wert in MB an.
  • --datafileDestination gibt den Speicherort an, der für Datenbankdatendateien verwendet werden soll.
  • --fraDestination gibt den Speicherort an, der für den Fast Recovery-Bereich der Datenbank verwendet werden soll.
  • --redoLogDestination gibt den Speicherort an, der für die Redo-Logdateien verwendet werden soll.
  • --fraSizeInMB gibt die Größe des Fast-Recovery-Bereichs in MB an.
  • --tdeKeyStoreType gibt den TDE-Keystore-Typ an. Gültige Werte: FILE|KMS|AZURE|GOOGLE|AWS|OKV
  • --tdeKeyOCID gibt die Schlüssel-OCID KMS/AZURE/GOOGLE/AWS an, die für TDE verwendet werden soll. Gilt nur, wenn KMS/AZURE/GOOGLE/AWS für den TDE-Keystore-Typ ausgewählt ist.
  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.
  • --revert setzt den vorherigen Vorgang zurück.
  • --waitForCompletion gibt an, ob der Abschluss des Vorgangs gewartet werden soll. Setzen Sie diese Option auf false, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false.
  • --enableFIPS gibt an, ob FIPS aktiviert werden soll. Setzen Sie diese Eigenschaft auf false, um sie zu deaktivieren. Gültige Werte: true|false.
  • --skipDRConfiguration gibt an, ob die Disaster-Recovery-(DR-)Konfiguration im Rahmen des Standbydatenbanksetups übersprungen werden soll. Gültige Werte: true (DR-Konfiguration überspringen) oder false (DR konfigurieren).
  • In --okvServer wird der Oracle Key Vault-Server angegeben. Durch Komma getrennte Liste mit mehreren IP-Adressen.
  • --okvAdminUserName gibt den Oracle Key Vault-Admin-Benutzernamen an.
  • --okvServerRestPort gibt die REST-Portnummer für Oracle Key Vault an.
  • --okvWalletName gibt den Oracle Key Vault-Walletnamen an.
Vorgang configureStandby mit dem Utility dbaascli ausführen

Zum Erstellen einer Standbydatenbank verwenden Sie den Befehl dbaascli dataguard configureStandby.

  1. Stellen Sie eine Verbindung zur virtuellen Maschine her, auf der die Standbydatenbank als Benutzer opc gehostet werden soll.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie die Befehlsshell des Root-Benutzers.
    $ sudo -s
  3. Führen Sie den Befehl configureStandby aus.
    dbaascli dataguard configureStandby --standbySID <standby SID> --activeDG <true|false> --dbName <db name> --standbyDBUniqueName <standby db unique name> --standbyScanName <comma-delimited list of standby SCAN IP addresses> --protectionMode <MAX_PERFORMANCE|MAX_AVAILABILITY> --standbyScanPort <standby SCAN port> --oracleHome <oracle home path> --standbyDBDomain <standby db domain name>. --primaryServiceName <primary db service name> --transportType <ASYNC|SYNC> --primaryScanPort <primary db SCAN port> --primaryScanIPAddresses <comma-delimited list primary db SCAN IP addresses> --standbyBlobFromPrimary <standby BLOB from primary>
  4. Geben Sie die Kennwörter SYS, TDE und AWR der Primärdatenbank ein, wenn Sie dazu aufgefordert werden.

    Nach erfolgreichem Abschluss des Befehls wird die Standbydatenbank gestartet und betriebsbereit.

dbaascli dataguard registerStandby

Um eine neu erstellte Standbydatenbank bei allen vorhandenen Standbydatenbanken und bei der Primärdatenbank zu registrieren, verwenden Sie den Befehl dbaascli dataguard registerStandby als dritten Schritt nach dem Schritt configureStandby.

Führen Sie diesen Befehl als Benutzer root im primären Cluster aus. Führen Sie außerdem in einem Setup mit mehreren Standbydatenbanken den Befehl auf allen Standbyclustern mit Ausnahme des neu erstellten Standbydatenbankclusters aus.

Syntax

dbaascli dataguard registerStandby --dbname <value> --standbyDBUniqueName <value>  --standbyDBDomain <value> | --noDBDomain --standbyScanIPAddresses <value> [--standbyScanPort <value>] [--standbyServiceName <value>] [--executePrereqs] [--resume [--sessionID <value>]] | [--revert [--sessionID <value>]] [--waitForCompletion <value>]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --standbyDBUniqueName gibt den eindeutigen Datenbanknamen der Standbydatenbank an, die bei der Oracle Data Guard Broker-Konfiguration registriert werden soll.
  • --standbyDBDomain gibt die Standbydatenbankdomäne an, für die die Primärdatenbank konfiguriert wird.
  • --noDBDomain gibt an, dass nicht der Datenbankdomainname für eine Standbydatenbank verwendet werden darf.
  • --standbyScanIPAddresses gibt eine kommagetrennte Liste von IP-Adressen an, die dem SCAN-Listener für die Standbydatenbank oder dem SCAN-Namen der Standbydatenbank entsprechen.
  • --standbyScanPort gibt die zugehörige SCAN-Portnummer der Standbydatenbank an.
  • --standbyServiceName gibt den Namen des Standby-Datenbankservice an, für den die Primärdatenbank konfiguriert wird.
  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.
  • --revert setzt den vorherigen Vorgang zurück.
  • --waitForCompletion gibt an, ob der Abschluss des Vorgangs gewartet werden soll. Setzen Sie diese Option auf false, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false.
Vorgang registerStandby mit dem Utility dbaascli ausführen

Um die angegebene Standbydatenbank bei der Oracle Data Guard Broker-Konfiguration zu registrieren, verwenden Sie den Befehl dbaascli dataguard registerStandby.

Bei einzelnen Standby-Anwendungsfällen darf der Befehl registerStandby nur auf dem primären Cluster ausgeführt werden, da eine Eins-zu-Eins-Verknüpfung zwischen der Primär- und der Standbydatenbank besteht.

In Konfigurationen mit mehreren Standbydatenbanken müssen Sie jedoch den Befehl registerStandby sowohl auf dem primären Cluster als auch auf allen vorhandenen Standbyclustern ausführen, ohne dass die neue Standbydatenbank hinzugefügt wird.

Beispiel: Ein Setup mit zwei Standbydatenbanken: stdby1 und stdby2, wobei stdby2 die neue zu registrierende Standbydatenbank ist. Führen Sie in diesem Fall den Befehl registerStandby im primären Cluster und auf stdby1 aus, nicht jedoch auf stdby2.

Wenn Sie eine neue Standbydatenbank zu einer vorhandenen Oracle Data Guard-Konfiguration hinzufügen, führen Sie zusammenfassend den Befehl registerStandby auf der Primärdatenbank und auf allen anderen zuvor registrierten Standbyclustern aus, mit Ausnahme der neuen Standbydatenbank, die hinzugefügt wird.

  1. Stellen Sie als Benutzer opc eine Verbindung zum primären Cluster der Data Guard-Konfiguration her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie die Befehlsshell des Root-Benutzers.
    $ sudo -s
  3. Führen Sie den Befehl registerStandby aus.
    dbaascli dataguard registerStandby --dbname <db-name> --standbyDBUniqueName <standby-DB-unique-name> --standbyDBDomain <standby-DB-domain>

    Nach erfolgreichem Abschluss des Befehls wird die angegebene Standbydatenbank bei der Oracle Data Guard Broker-Konfiguration registriert.

  4. Wiederholen Sie die Schritte 1 bis 3, wie im primären Cluster ausgeführt, auf allen vorhandenen Standbyclustern in der Oracle Data Guard Broker-Konfiguration, mit Ausnahme des zu registrierenden Clusters.

dbaascli dataguard deregisterStandby

Führen Sie beim Löschen der Standbydatenbank den Befehl dbaascli dataguard deregisterStandby aus, bevor Sie die Datenbank im Standbycluster löschen, um die Registrierung der Standbydatenbank bei der Oracle Data Guard Broker-Konfiguration aufzuheben.

Führen Sie diesen Befehl als Benutzer root im primären Cluster aus. Im Kontext mehrerer Standbydatenbanken muss dieser Befehl jedoch auf allen Standbyclustern mit Ausnahme der Ziel-Standbydatenbank ausgeführt werden.

Syntax

dbaascli dataguard deregisterStandby --dbname <value> --standbyDBUniqueName <value> [--executePrereqs] [--resume [--sessionID <value>]] [--waitForCompletion <value>]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --standbyDBUniqueName gibt den eindeutigen Datenbanknamen der Standbydatenbank an, deren Registrierung in der Oracle Data Guard Broker-Konfiguration aufgehoben werden soll.
  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.
  • --waitForCompletion gibt an, ob der Abschluss des Vorgangs gewartet werden soll. Setzen Sie diese Option auf false, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false.
Vorgang deregisterStandby mit dem Utility dbaascli ausführen

Führen Sie beim Löschen der Standbydatenbank den Befehl dbaascli dataguard deregisterStandby aus, bevor Sie die Datenbank im Standbycluster löschen, um die Registrierung der Standbydatenbank bei der Oracle Data Guard Broker-Konfiguration aufzuheben.

Bei einzelnen Standby-Anwendungsfällen darf der Befehl deregisterStandby nur auf dem primären Cluster ausgeführt werden, da eine Eins-zu-Eins-Verknüpfung zwischen der Primär- und der Standbydatenbank besteht.

In Konfigurationen mit mehreren Standbydatenbanken müssen Sie jedoch den Befehl deregisterStandby sowohl auf dem primären Cluster als auch auf allen vorhandenen Standbyclustern ausführen, ohne die Standbydatenbank, die derzeit abgemeldet wird.

Beispiel: Ein Setup mit zwei Standbydatenbanken: stdby1 und stdby2, wobei die Registrierung von stdby2 aufgehoben werden soll. Führen Sie in diesem Fall den Befehl deregisterStandby im primären Cluster und auf stdby1 aus, nicht jedoch auf stdby2.

Wenn Sie eine Standbydatenbank aus einer vorhandenen Oracle Data Guard-Konfiguration löschen, führen Sie zusammenfassend den Befehl deregisterStandby auf der Primärdatenbank und auf allen anderen vorhandenen Standbyclustern aus, bevor Sie den Datenbankvorgang auf dem gewünschten Standbycluster löschen.

  1. Stellen Sie als Benutzer opc eine Verbindung zum primären Cluster der Oracle Data Guard-Konfiguration her.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie die Befehlsshell des Root-Benutzers.
    $ sudo -s
  3. Führen Sie den Befehl deregisterStandby aus.
    dbaascli dataguard deregisterStandby --dbname <db-name> --standbyDBUniqueName <standby-DB-unique-name>

    Nach erfolgreichem Abschluss des Befehls wird die Registrierung der angegebenen Standbydatenbank von der Oracle Data Guard Broker-Konfiguration aufgehoben (entfernt).

  4. Wiederholen Sie die Schritte 1 bis 3, wie auf dem primären Cluster ausgeführt, auf allen vorhandenen Standbyclustern in der Oracle Data Guard Broker-Konfiguration, mit Ausnahme des Clusters, das abgemeldet wird.

dbaascli dataguard configureAWR

Um die Automatic Workload Repository-(AWR-)Konfiguration in der Active Data Guard-Standbydatenbank zu aktivieren oder zu deaktivieren, verwenden Sie den Befehl dbaascli dataguard configureAWR.

Führen Sie diesen Befehl als Benutzer root im Active Data Guard-Standbycluster aus, in dem Sie die AWR-Konfiguration aktivieren oder deaktivieren möchten. Verwenden Sie diesen Befehl, wenn AWR während des Standbyadditionsprozesses nicht konfiguriert wurde.

Syntax

dbaascli dataguard configureAWR --dbname <value> { --action <value> | --enable | --disable } [--executePrereqs] [--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --action gibt an, ob AWR aktiviert oder deaktiviert werden soll. Verwenden Sie --action enable, um AWR zu aktivieren, und --action disable, um es zu deaktivieren.

    Das Argument --action wird aus Gründen der Abwärtskompatibilität beibehalten. Es wird jedoch empfohlen, --enable oder --disable zu verwenden, da sie die gleiche Funktionalität bieten, jedoch expliziter sind.

  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.
Vorgang configureAWR mit dem Utility dbaascli ausführen

Um AWR in einer ADG-Standbydatenbank zu konfigurieren, verwenden Sie den Befehl dbaascli dataguard configureAWR.

  1. Stellen Sie eine Verbindung zur virtuellen Maschine her, auf der Ihre ADG-Standbydatenbank als Benutzer opc gehostet wird.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie die Befehlsshell des Root-Benutzers.
    $ sudo -s
  3. Führen Sie den Befehl configureAWR aus.

    Um AWR zu aktivieren, führen Sie folgenden Befehl aus:

    $ dbaascli dataguard configureAWR --dbname <db-name> --enable

    Um AWR zu deaktivieren, führen Sie folgenden Befehl aus:

    $ dbaascli dataguard configureAWR --dbname <db-name> --disable
  4. Geben Sie die Kennwörter SYS und AWR ein, wenn Sie dazu aufgefordert werden.

    Nach erfolgreichem Abschluss des Befehls wäre die ADG-Standbydatenbank mit AWR konfiguriert worden

dbaascli dataguard updateConfiguration

Um den Transportmodus oder den Schutzmodus oder beide Parameter einer Data Guard-Umgebung zu aktualisieren, verwenden Sie den Befehl dbaascli dataguard updateConfiguration.

Führen Sie diesen Vorgang als Benutzer root aus.

Wenn der Befehl "Transportmodus aktualisieren" auf der Primärdatenbank ausgeführt wird, wird nur der Transportmodus der Primärdatenbank aktualisiert. Um den Transportmodus einer Standbydatenbank zu aktualisieren, muss der Befehl separat in dieser Standbydatenbank ausgeführt werden.

Wenn der Befehl für den Aktualisierungsschutzmodus hingegen auf der Primärdatenbank ausgeführt wird, wird der Schutzmodus sowohl für die Primär- als auch für die Standbydatenbank aktualisiert. Der Schutzmodus kann auch von der Standby-Seite aus aktualisiert werden. In diesem Fall werden sowohl die Primär- als auch die Standby-Datenbank aktualisiert.

Beim Aktualisieren des Transport- oder Schutzmodus von der Primärdatenbank prüft das System die aktuellen Modi sowohl in der Primär- als auch in der Standbydatenbank und fährt nur dann mit der Aktualisierung fort, wenn alle erforderlichen Bedingungen erfüllt sind.

Syntax

dbaascli dataguard updateConfiguration --dbname <value> [--protectionMode <value>] [--transportType <value>] [--standbyDGType <value>] [--executePrereqs] [--resume [--sessionID <value>]] [--waitForCompletion <value>]
Dabei gilt:
  • --dbname gibt den Oracle Database-Namen an.
  • --protectionMode gibt den Data Guard-Schutzmodus an, der beim Konfigurieren der Standbydatenbank festgelegt werden soll. Gültige Werte: MAX_PERFORMANCE|MAX_AVAILABILITY.
  • --transportType gibt den Data Guard-Transporttyp an, der beim Konfigurieren der Standbydatenbank festgelegt werden soll. Gültige Werte: ASYNC|SYNC.
  • --standbyDGType gibt den Data Guard-Typ der Standbydatenbank an, der festgelegt werden soll. Gültige Werte: ADG|DG.
  • --executePrereqs führt die Voraussetzungsprüfungen durch und meldet die Ergebnisse.
  • --resume setzt den vorherigen Vorgang fort.
  • --sessionID setzt eine bestimmte Session anhand ihrer ID fort.
  • --waitForCompletion gibt an, ob der Abschluss des Vorgangs gewartet werden soll. Setzen Sie diese Option auf false, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false.
Vorgang updateConfiguration mit dem Utility dbaascli ausführen

Um Transportmodus und Schutzmodus oder beide Parameter zu aktualisieren, verwenden Sie den Befehl dbaascli dataguard updateConfiguration.

  1. Stellen Sie eine Verbindung zur virtuellen Maschine her, auf der Ihre ADG-Standbydatenbank als Benutzer opc gehostet wird.

    Ausführliche Anweisungen finden Sie unter Verbindung zu einer virtuellen Maschine mit SSH herstellen.

  2. Starten Sie die Befehlsshell des Root-Benutzers.
    $ sudo -s
  3. Führen Sie den Befehl updateConfiguration aus.
    $ dbaascli dataguard updateConfiguration --dbname <db-name> --protectionMode MAX_PERFORMANCE|MAX_AVAILABILITY --transportType ASYNC|SYNC --standbyDGType ADG|DG.

    Nach erfolgreichem Abschluss des Befehls wird der angegebene Data Guard mit dem angegebenen Transportmodus oder Schutzmodus konfiguriert.

dbaascli dbhome create

Um ein Oracle Database Home mit der gewünschten Version zu erstellen, verwenden Sie den Befehl dbaascli dbhome create.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli dbhome create --version <value>
[--oracleHome <value>]
[--oracleHomeName <value>]
[--enableUnifiedAuditing <value>] 
[--imageTag <value>]
[--ImageLocation <value>
Dabei gilt:
  • --version gibt die Version des Oracle Homes als fünf durch Punkte getrennte numerische Segmente an. Beispiel: 19.12.0.0.0
  • --oracleHome gibt das Verzeichnis des Oracle Homes an.
  • --oracleHomeName gibt den benutzerdefinierten Oracle Home-Namen an. Falls nicht angegeben, wird der Standardname verwendet.
  • --enableUnifiedAuditing gibt durch true oder false an, ob die Linkoption für einheitliches Auditing im Oracle Home aktiviert oder deaktiviert ist.
  • --imageTag gibt das Imagetag des Oracle Homes an.
  • --imageLocation: Pfad des zu verwendenden Images.
  • --waitForCompletion gibt false an, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true oder false.

Beispiel 6-24: dbaascli dbhome create

dbaascli dbhome create --version 19.11.0.0.0

Alternativ können Sie dbaascli dbhome create --version 19.8.0.0.0.0 --imageTag 19.8.0.0.0 für Fälle verwenden, in denen sich die Imagetags von der Version unterscheiden.

dbaascli dbHome delete

Um ein bestimmtes Oracle Database Home zu löschen, verwenden Sie den Befehl dbaascli dbHome delete.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli dbHome delete 
{ --oracleHome <value> 
| --oracleHomeName <value> } [--resume [--sessionID <value>]] 
Dabei gilt:
  • --oracleHome gibt das Verzeichnis des Oracle Homes an.
  • --oracleHomeName gibt den Namen des Oracle Homes an.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.

dbaascli dbhome getDatabases

Um Informationen zu allen Oracle-Datenbanken anzuzeigen, die aus einem bestimmten Oracle Home-Verzeichnis der Datenbank ausgeführt werden, verwenden Sie den Befehl dbaascli dbHome getDatabases. Geben Sie entweder das Oracle Home-Verzeichnis oder den Oracle Home-Namen an.

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli dbHome getDatabases
{ --oracleHomeName value | --oracleHome value }
Dabei gilt:
  • --oracleHomeName gibt den benutzerdefinierten Namen des Oracle Homes an.
  • --oracleHome gibt das Verzeichnis (Pfad) des Oracle Homes an.

Beispiel 6-25: dbaascli dbHome getDatabases --oracleHome

dbaascli dbHome getDatabases --oracleHome /u02/app/mar_home/

dbaascli dbHome getDetails

Um Informationen zu einem bestimmten Oracle Home anzuzeigen, verwenden Sie den Befehl dbaascli dbHome getDetails. Geben Sie entweder das Oracle Home-Verzeichnis oder den Oracle Home-Namen an.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli dbHome getDetails
{ --oracleHomeName value | --oracleHome value }
Dabei gilt:
  • --oracleHomeName gibt den benutzerdefinierten Namen des Oracle Homes an.
  • --oracleHome gibt das Verzeichnis des Oracle Homes an.

Beispiel 6-26: dbaascli dbHome getDetails - mit Oracle Home-Verzeichnis

dbaascli dbHome getDetails --oracleHome /u02/app/home_db19c/

Beispiel 6-27: dbaascli dbHome getDetails - mit Oracle Home-Namen

dbaascli dbHome getDetails --oracleHomeName home_db19c

dbaascli dbHome patch

Um das Oracle Home von einer Patchebene auf eine andere zu patchen, verwenden Sie den Befehl dbaascli dbHome patch.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli dbHome patch

{
    --oracleHome <value>
    | --oracleHomeName <value>
 }
        [--imageFilePath <value>] [--executePrereqs] [--nodes <value>]
        {
            [--resume [--sessionID <value>]]
            | [--rollback [--sessionID <value>]]
        }
[--skipDatapatch] 
[--skipClosedPDBs] 
[--skipPDBs <value>] 
[--continueWithDbDowntime] 
[--skipUnreachableNodes] 
[--drainTimeoutInSeconds <value>] 
[--waitForCompletion <value>]
[--nonRolling] 
[--skipDatapatchForDB <value>]
Dabei gilt:
  • --oracleHome gibt den Pfad des Oracle Homes an.
  • --oracleHomeName gibt den Namen des Oracle Homes an.
  • --targetVersion gibt die Zielversion des Oracle Home als fünf durch Punkte getrennte numerische Segmente an. Beispiel: 19.12.0.0.0.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --continueWithDbDowntime setzt das Patching mit Datenbankausfallzeit fort. Diese Option kann in Umgebungen verwendet werden, in denen nur eine aktive Instanz hochgefahren ist und der Patching-Vorgang auch mit einer Ausfallzeit fortgesetzt werden kann.
  • --skipUnreachableNodes überspringt den Vorgang auf nicht erreichbaren Knoten.
  • --nodes gibt eine kommagetrennte Liste von Knoten an, wenn das Patching für eine Teilmenge von Knoten ausgeführt werden muss.
  • --executePrereqs führt Voraussetzungsprüfungen aus.
  • --skipDatapatch überspringt die Ausführung von datapatch in den Datenbanken.
  • --imageFilePath gibt den absoluten Pfad der zu verwendenden Imagedatei an.
  • --skipPDBs überspringt die Ausführung von datapatch in einer angegebenen kommagetrennten Liste von PDBs. Beispiel: cdb1:pdb1,cdb2:pdb2 usw.
  • --skipClosedPdbs überspringt die Ausführung von datapatch in geschlossenen PDBs.
  • --rollback setzt das gepatchte Oracle Home zurück.
  • --waitForCompletion gibt "false" an, um den Vorgang im Hintergrund auszuführen. Gültige Werte : true|false
  • --drainTimeoutInSeconds gibt die Zeit (in Sekunden) für den Abschluss des Ressourcen-Drains an, während die Datenbank gestoppt wird
  • --skipUnreachableNodes überspringt den Vorgang auf nicht erreichbaren Knoten.
  • [--nonRolling] patcht das DB-Home auf allen Knoten parallel. Beachten Sie, dass dies zu einer Ausfallzeit in der Datenbank führt.
  • [--skipDatapatchForDB <value>] überspringt die Ausführung von datapatch in der angegebenen kommagetrennten Datenbankliste. Beispiel: db1,db2,db3...

Beispiel 6-28: dbaascli dbhome patch

dbaascli dbhome patch --targetVersion 19.10.0.0.0 --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2

dbaascli dbimage purge

Der Befehl dbimage purge entfernt das angegebene Softwareimage aus der Exadata Cloud Infrastructure-Umgebung.

Melden Sie sich als Benutzer opc beim Compute Node an, und führen Sie diesen Befehl als Benutzer root aus.

# dbaascli dbimage purge --version software_version --bp software_bp [--cdb ( yes | no )]

Im vorherigen Befehl:

  • software_version: Gibt die Oracle Database-Softwareversion an. Beispiel: 11204, 12102, 12201, 18000, 19000.

  • software_bp: Gibt das Release des Bundle-Patches an. Beispiel: APR2018, JAN2019, OCT2019 usw.

  • --cdb: Gibt optional an, ob das Softwareimage entfernt werden soll, das die mehrmandantenfähige Oracle-Architektur unterstützt. Der Standardwert ist yes. Wenn Sie --cdb no angeben, wird das Softwareimage, das Binärdateien zur Unterstützung von Nicht-Containerdatenbanken (Nicht-CDBs) enthält, entfernt.

Wenn der Befehl ein Softwareimage entfernt, das derzeit in der Softwareimagebibliothek nicht verfügbar ist und daher nicht erneut heruntergeladen werden kann, wird zur Bestätigung aufgefordert.

Das aktuelle Standardsoftwareimage können Sie für keine Softwareversion entfernen. Zur Vermeidung dieser Einschränkung müssen Sie ein anderes Softwareimage als aktuelles Standardimage festlegen.

dbaascli diag collect

Um Diagnosedaten zu erfassen, verwenden Sie den Befehl dbaascli diag collect.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli diag collect [--components <value>] [--startTime <value>] [--endTime <value>] [--nodes <value>] [--dbNames <value>]
        {
            [--objectStoreBucketUri <value>]
            | [--destLocation <value>]
        }
        [--waitForCompletion <value>]
Dabei gilt:
  • --components gibt eine Liste der Komponenten für die Logerfassung an.

    Gültige Werte:

    • db
    • gi
    • os
    • dbaastools
    • all
  • --startTime gibt die Startzeit für die Logerfassung an. Gültiges Datums- und Uhrzeitformat: YYYY-MM-DDTHH24:MM:SS
  • --endTime gibt die Endzeit für die Logerfassung an. Gültiges Datums- und Uhrzeitformat: YYYY-MM-DDTHH24:MM:SS
  • --nodes gibt eine kommagetrennte Liste der Knoten an, die Logs erfassen sollen.
  • --dbNames gibt den Namen der Datenbank an, für die Logs erfasst werden sollen. Sie können nur einen Datenbanknamen angeben.
  • --objectStoreBucketURI gibt eine vorab authentifizierte Anforderungs-(PAR-)URL für den Object Storage-Service an, mit der erfasste Logs hochgeladen werden. Logs werden von der Gast-VM erfasst. Weitere Informationen finden Sie unter Vorab authentifizierte Anforderungen verwenden.
  • --destLocation gibt den Speicherort auf der Gast-VM an, in dem Logs erfasst werden. Standardwert: /var/opt/oracle/dbaas_acfs
  • Werte für --waitForCompletion: true|false. Standardwert: true. Geben Sie false an, damit der Vorgang im Hintergrund ausgeführt wird.

dbaascli diag healthCheck

Um Health Checks für die Diagnose auszuführen, verwenden Sie den Befehl dbaascli diag healthCheck.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli diag healthCheck
[--destLocation]
[--nodes]
[--objectStoreBucketURI]
Dabei gilt:
  • --destLocation gibt den Speicherort auf der Gast-VM an, in dem Logs erfasst werden. Standardwert: /var/opt/oracle/dbaas_acfs
  • --nodes gibt eine kommagetrennte Liste der Knoten an, die Logs erfassen sollen.
  • --objectStoreBucketURI gibt eine vorab authentifizierte Anforderungs-(PAR-)URL für den Object Storage-Service an, mit der erfasste Logs hochgeladen werden. Logs werden von der Gast-VM erfasst. Weitere Informationen finden Sie unter Vorab authentifizierte Anforderungen verwenden.

dbaascli gridHome erstellen

Um das Grid Infrastructure Home zu konfigurieren, verwenden Sie den Befehl dbaascli gridHome create.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli gridHome create --version value [--resume [--sessionID value]] [--waitForCompletion value]
Dabei gilt:
  • --version gibt die Grid Home-Version an.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true|false

dbaascli grid configureTCPS

Um TCPS für das vorhandene Cluster zu konfigurieren, verwenden Sie den Befehl dbaascli grid configureTCPS.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

Hinweis

Standardmäßig ist TCPS für Datenbanken in Oracle Exadata Database Service on Dedicated Infrastructure-Systemen aktiviert.
Hinweis

TCPS ist nicht für Datenbanken in Exadata Database Service on Cloud@Customer-Systemen aktiviert. Um TCPS für eine bestimmte Datenbank zu aktivieren, aktualisieren Sie die datenbankspezifische Datei sqlnet.ora auf allen Datenbankknoten mit WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets))), und starten Sie die Datenbank dann neu. Dadurch wird TCPS für die Datenbank aktiviert. Die Aktivierung von TCPS führt jedoch dazu, dass keine ZDLRA-Verbindung möglich ist. In Exadata Database Service on Cloud@Customer-Systemen können Sie die ZDLRA- oder die TCPS-Konfiguration aktivieren. Die gleichzeitige Aktivierung von ZDLRA und TCPS ist nicht möglich.
dbaascli grid configureTCPS
[--pkcs12WalletPath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]
Dabei gilt:
  • --pkcs12WalletPath gibt den Pfad des Zertifikats an, welches das Wallet-Format pkcs12 hat.
  • --caCertChain: Zusammengesetzte Liste von Zertifikaten mit Zwischen-CA- und Root-CA-Zertifikaten
  • --precheckOnly gibt durch yes an, dass nur die Vorabprüfungen für diesen Vorgang ausgeführt werden. Gültige Werte: yes oder no.
  • --serverCert gibt den Pfad des PEM-Zertifikats an, das für die TCPS-Konfiguration verwendet oder rotiert werden soll.
  • --privateKey gibt den Pfad der Private-Key-Datei des Zertifikats an.
  • --certType gibt den Typ des Zertifikats an, das dem Grid Infrastructure-Wallet hinzugefügt werden soll. Akzeptierte Werte sind: SELF_SIGNED_CERT, CA_SIGNED_CERT oder PKCS12_CERT. Standardwert: SELF_SIGNED_CERT
  • --privateKeyPasswordProtected gibt an, ob der Private Key kennwortgeschützt ist. Gültige Werte: true oder false. Standardwert: true.

Beispiel 6-29: dbaascli grid configureTCPS

So konfigurieren Sie Grid mit selbstsigniertem Zertifikat:
dbaascli grid configureTCPS
So konfigurieren Sie Grid mit CA-signiertem Zertifikat:
dbaascli grid configureTCPS --cert_type CA_SIGNED_CERT --server_cert /tmp/certs/server_cert.pem --ca_cert_chain /tmp/certs/ca.pem --private_key /tmp/certs/encrypted_private.key --private_key_password_protected false

dbaascli grid patch

Um Oracle Grid Infrastructure auf die angegebene Nebenversion zu patchen, verwenden Sie den Befehl dbaascli grid patch.

Voraussetzungen

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli grid patch
 {
            --targetVersion <value>
            | --targetHome <value>
        }
        [--executePrereqs] [--nodeList <value>] [--continueWithDbDowntime] [--drainTimeoutInSeconds <value>] [--containerURL <value>] [--imageFile <value>] [--patchInParallel]
        {
            [--resume [--sessionID <value>]]
            | [--rollback [--sessionID <value>]]
        }
        [--waitForCompletion <value>]

Dabei gilt:

  • --targetVersion gibt die Zielversion des Oracle Homes als fünf durch Punkte getrennte numerische Segmente an (Beispiel: 19.12.0.0.0).
  • --targetHome gibt den vollqualifizierten Pfad des Ziel-Grid Infrastructure Home für das Out-of-Place-Patching an.
  • --containerURL gibt die benutzerdefinierte URL zum Abrufen des Grid Infrastructure-Images an.
  • --executePrereqs ist eine Option zum Ausführen von Voraussetzungsprüfungen.
  • --nodeList gibt eine kommagetrennte Liste von Knoten an, wenn das Patching für eine Teilmenge von Knoten ausgeführt werden muss.
  • --patchInParallel gibt an, dass das Patching von Remoteknoten parallel ausgeführt wird.
  • --rollback gibt an, das gepatchte Oracle Home zurückzusetzen.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --continueWithDbDowntime setzt das Patching mit Datenbankausfallzeit fort. Diese Option kann in Umgebungen verwendet werden, in denen nur eine aktive Instanz hochgefahren ist und der Patching-Vorgang auch mit einer Ausfallzeit fortgesetzt werden kann.
  • --drainTimeoutInSeconds gibt die Zeit (in Sekunden) für den Abschluss des Ressourcen-Drains an, während die Datenbank gestoppt wird.
  • --createImage erstellt ein Image aus einer Kopie des aktiven Grid Homes, das auf die angegebene Zielversion gepatcht wird.
    • --createImageDir gibt den vollqualifizierten Pfad des Verzeichnisses an, in dem das Image erstellt werden soll.
  • --imageFile gibt den vollqualifizierten Pfad des zu verwendenden Images an.
  • --patchInParallel führt das Patching der Remoteknoten parallel aus
  • --waitForCompletion gibt false an, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false

Beispiel 6-30: dbaascli grid patch

dbaascli grid patch --targetVersion 19.12.0.0.0

dbaascli grid removeTCPSCert

Um vorhandene TCPS-Zertifikate aus dem Grid Infrastructure-Wallet zu entfernen, verwenden Sie den Befehl dbaascli grid removeTCPSCert.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli grid removeTCPSCert --subject <value>
 {
   --userCert | --trustedCert | --requestedCert
 }
 [--serialNumber <value>] [--executePrereqs] [--resume [--sessionID <value>]] [--bounceListeners]
Dabei gilt:
  • --subject gibt den Betreff des Zertifikats an
  • Kennzeichen --userCert zur Angabe eines Benutzerzertifikats
  • Kennzeichen --trustedCert zur Angabe eines vertrauenswürdigen Zertifikats
  • Kennzeichen --requestedCert zur Angabe eines angeforderten Zertifikats
  • --serialNumber gibt die Seriennummer des Zertifikats an.
  • --executePrereqs führt die Voraussetzungsprüfungen aus und meldet die Ergebnisse.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • Kennzeichen --bounceListeners zum Neustart des Grid Infrastructure Listeners und Scan Listeners

dbaascli grid rotateTCPSCert

Um TCPS-Zertifikate zu rotieren, verwenden Sie den Befehl "dbaascli grid rotateTCPSCert".

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli grid rotateTCPSCert
[--pkcs12WalletPath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]
Dabei gilt:
  • --pkcs12WalletPath gibt den Pfad des Zertifikats an, welches das Wallet-Format pkcs12 hat.
  • --caCertChain: Zusammengesetzte Liste von Zertifikaten mit Zwischen-CA- und Root-CA-Zertifikaten
  • --precheckOnly gibt durch yes an, dass nur die Vorabprüfungen für diesen Vorgang ausgeführt werden. Gültige Werte: yes oder no.
  • --serverCert gibt den Pfad des PEM-Zertifikats an, das für die TCPS-Konfiguration verwendet oder rotiert werden soll.
  • --privateKey gibt den Pfad der Private-Key-Datei des Zertifikats an.
  • --certType gibt den Typ des Zertifikats an, das dem Grid Infrastructure-Wallet hinzugefügt werden soll. Akzeptierte Werte sind: SELF_SIGNED_CERT, CA_SIGNED_CERT oder PKCS12_CERT. Standardwert: SELF_SIGNED_CERT
  • --privateKeyPasswordProtected gibt an, ob der Private Key kennwortgeschützt ist. Gültige Werte: true oder false. Standardwert: true.

Beispiel 6-31: dbaascli grid rotateTCPSCert

So rotieren Sie Zertifikate bei selbstsigniertem Zertifikat (Standardoption):
dbaascli grid rotateTCPSCert
So rotieren Sie Zertifikate bei CA-signiertem Zertifikat:
dbaascli grid rotateTCPSCert --cert_type CA_SIGNED_CERT --server_cert /tmp/certs/server_cert.pem --ca_cert_chain /tmp/certs/ca.pem --private_key /tmp/certs/encrypted_private.key --privateKeyPasswordProtected true

dbaascli grid upgrade

Um Oracle Grid Infrastructure von einer Hauptversion auf eine andere zu aktualisieren, verwenden Sie den Befehl dbaascli grid upgrade.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli grid upgrade --version
[--resume]
[--executePrereqs]
[--containerURL]
[--softwareOnly]
[--targetHome]
[--revert]
Dabei gilt:
  • --version gibt die Zielversion an.
  • --resume setzt die vorherige Ausführung fort.
  • --executePrereqs führt Voraussetzungsprüfungen für das Upgrade von Grid Infrastructure aus.
  • --containerUrl gibt die benutzerdefinierte URL zum Abrufen des Grid Infrastructure-Images an.
  • --softwareOnly installiert nur die Grid Infrastructure-Software.
  • --targetHome gibt den Pfad eines vorhandenen Ziel-Grid-Homes an.
  • --revert setzt eine nicht erfolgreiche Ausführung zurück.

Beispiel 6-32: dbaascli grid upgrade

daascli grid upgrade --version 19.11.0.0.0 --executePrereqs
DBAAS CLI version MAIN
Executing command grid upgrade --version 19.11.0.0.0 --executePrereqs

dbaascli job getStatus

Um den Status eines angegebenen Jobs anzuzeigen, verwenden Sie den Befehl dbaascli job getStatus.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli job getStatus --jobID
Dabei gilt:
  • --jobID gibt die Job-ID an.

Beispiel 6-33: dbaascli job getStatus

dbaascli job getStatus --jobID 13c82031-f202-41b7-9aef-f4a71df0f551
DBAAS CLI version MAIN
Executing command job getStatus --jobID 13c82031-f202-41b7-9aef-f4a71df0f551
{
  "jobId" : "13c82031-f202-41b7-9aef-f4a71df0f551",
  "status" : "Success",
  "message" : "database create job: Success",
  "createTimestamp" : 1628095442431,
  "updatedTime" : 1628095633660,
  "description" : "Service job report for operation database create",
  "appMessages" : {
    "schema" : [ ],
    "errorAction" : "SUCCEED_AND_SHOW"
  },
  "resourceList" : [ ],
  "pct_complete" : "100"
}

dbaascli patch db apply

Hinweis

Die Befehle dbaascli patch db prereq und dbaascli patch db apply sind seit dem dbaascli-Release 21.2.1.2.0 veraltet und wurden durch die Befehle dbaascli grid patch, dbaascli dbhome patch und dbaascli database move ersetzt.
Weitere Informationen finden Sie unter:
  • dbaascli grid patch
  • dbaascli dbhome patch
  • dbaascli database move
  • Oracle Grid Infrastructure und Oracle-Datenbanken mit dbaascli patchen

dbaascli patch db preq

Hinweis

Die Befehle dbaascli patch db prereq und dbaascli patch db apply sind seit dem dbaascli-Release 21.2.1.2.0 veraltet und wurden durch die Befehle dbaascli grid patch, dbaascli dbhome patch und dbaascli database move ersetzt.
Weitere Informationen finden Sie unter:
  • dbaascli grid patch
  • dbaascli dbhome patch
  • dbaascli database move
  • Oracle Grid Infrastructure und Oracle-Datenbanken mit dbaascli patchen

dbaascli pdb backup

Um eine integrierbare Datenbank (PDB) zu sichern, PDB-Backups abzufragen und ein PDB-Backup zu löschen, verwenden Sie den Befehl dbaascli pdb backup.

Voraussetzung

  • Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli pdb backup --pdbName <value> --dbname <value>
        {
            --start
                {
                    [--level1]
                    | [--archival --tag <value>]
                }
            | --delete --backupTag <value>
            | --status --uuid <value>
            | --getBackupReport --json <value> --tag <value>
            | --list [--json <value>]
        }
Dabei gilt:
--pdbName: PDB name.
--dbname: Oracle Database name.
--start | --delete | --status | --getBackupReport | --list
--start: Begins PDB backup.
      [--level1 | --archival]
      [--level1: Creates a Level-1 (incremental) backup.]
      [--archival: Creates an archival full backup.]
          --tag: Specify backup tag.
--delete: Deletes archival backup.
          --backupTag: Specify backup tag to delete.
--status
          --uuid <value>
--getBackupReport: Returns backup report.
         --json: Specify the file name for JSON output.
         --tag: Specify backup tag.
--list: Returns PDB backup information.
         [--json: Specify the file name for JSON output.]

Beispiel 6-34: Beispiele: Beispiele

  • So erstellen Sie ein Backup der Ebene 1 für eine PDB pdb1 in einer CDB myTestDb:
    dbaascli pdb backup --dbname myTestDb --pdbName pdb1 --start --level1
  • So fragen Sie den Status der mit uuid eef16b26361411ecb13800163e8e4fac übermittelten PDB-Backupanforderung ab:
    dbaascli pdb backup --dbname myTestDb --pdbName pdb1 --status --uuid eef16b26361411ecb13800163e8e4fac

dbaascli pdb bounce

Um eine integrierbare Datenbank (PDB) herunter- und wieder hochzufahren, verwenden Sie den Befehl dbaascli pdb bounce.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli pdb bounce --dbname --pdbName | --pdbUID
[–openMode]
Dabei gilt:
  • --dbname gibt den Namen der Containerdatenbank an, welche die PDB hostet.
  • --pdbName gibt den Namen der PDB an.
  • --pdbUID gibt die ID der PDB an.
  • --openMode gibt den Ziel-OPEN MODE für die PDB an.

Beispiel 6-35: dbaascli pdb bounce

dbaascli pdb bounce --dbname cdb_name --pdbName pdb name associated with the CDB
dbaascli pdb bounce --dbname cdb_name --pdbUID con_uid of that pdb
Optional:
  • --openMode READ_WRITE
  • --openMode READ_ONLY

dbaascli pdb close

Um eine integrierbare Datenbank (PDB) zu schließen, verwenden Sie den Befehl dbaascli pdb close.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli pdb close --dbname --pdbName | --pdbUID
Dabei gilt:
  • --dbname gibt den Namen der Containerdatenbank an, welche die PDB hostet.
  • --pdbname gibt den Namen der PDB an, die Sie schließen möchten.
  • --pdbUID gibt die ID der PDB an.

Nach erfolgreicher Ausführung dieses Befehls wird die PDB in allen Instanzen der Containerdatenbank geschlossen.

Beispiel 6-36: dbaascli pdb close

dbaascli pdb close --dbname cdb name --pdbName pdb name associated with the CDB
dbaascli pdb close --dbname cdb name --pdbUID con_uid of that pdb

dbaascli pdb getConnectString

Um Informationen zur Oracle Net-Verbindungszeichenfolge für eine integrierbare Datenbank (PDB) anzuzeigen, führen Sie den Befehl dbaascli pdb getConnectString aus.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli pdb getConnectString --dbname --pdbName | --pdbUID
Dabei gilt:
  • --dbname gibt den Namen der Containerdatenbank an, welche die PDB hostet.
  • --pdbname gibt den Namen der PDB an, für die Sie Informationen zur Verbindungszeichenfolge anzeigen möchten.
  • --pdbUID gibt die ID der PDB an.

Beispiel 6-37: dbaascli pdb getConnectString

dbaascli pdb getConnectString --dbname dbname --pdbName pdbName

dbaascli pdb create

Um eine neue integrierbare Datenbank (PDB) zu erstellen, verwenden Sie den Befehl dbaascli pdb create.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli pdb create --pdbName <value> --dbName <value> 
[--maxCPU <value>] 
[--maxSize <value>] 
[--pdbAdminUserName <value>] 
[--lockPDBAdminAccount <value>] 
[--resume [--sessionID <value>]] 
[--executePrereqs <value>] 
[--waitForCompletion <value>] 
[--blobLocation |--standbyBlobFromPrimary <value>]
Dabei gilt:
  • --pdbName gibt den Namen der neuen PDB an, die Sie erstellen möchten.
  • --dbName gibt den Namen der Containerdatenbank an, welche die neue PDB hostet.
  • --maxCPU gibt optional die maximale Anzahl von CPUs an, die für die PDB verfügbar sind. Die Wirkung dieser Option entspricht der Wirkung des Parameters CPU_COUNT in der PDB
  • --maxSize gibt optional die maximale Gesamtgröße der Daten- und temporären Dateien für Tablespaces an, die zu der PDB gehören. Die Wirkung dieser Option entspricht der Wirkung der Speicherklausel MAXSIZE PDB im SQL-Befehl CREATE PLUGGABLE DATABASE. Sie können einen Grenzwert festlegen, indem Sie eine Ganzzahl gefolgt von einer Größeneinheit (K, M, G oder T) angeben. Alternativ können Sie UNLIMITED angeben, um explizit keinen Grenzwert festzulegen.
  • --pdbAdminUserName gibt den neuen PDB-Admin-Benutzernamen an.
  • --lockPDBAdminAccount gibt durch true oder false an, ob der PDB-Admin-Benutzeraccount gesperrt werden soll. Standardwert ist True.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --executePrereqs ist auf yes gesetzt, wenn nur die Voraussetzungen für diesen Vorgang geprüft werden sollen. Gültige Werte: yes oder no
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true oder false
  • --blobLocation gibt einen benutzerdefinierten Verzeichnisspeicherort an, in dem die Standby-BLOB-Datei in einer DG-Umgebung generiert wird.
  • --standbyBlobFromPrimary gibt den Speicherort der Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird. Dies ist nur für PDB-Vorgänge bei Standbydatenbanken erforderlich.
    Hinweis

    Die Parameter blobLocation und standbyBlobFromPrimary schließen sich gegenseitig aus.

Beim Erstellen der PDB werden Sie aufgefordert, das Administrationskennwort für die neue PDB anzugeben.

Beispiel 6-38: dbaascli pdb create

So erstellen Sie eine PDB aus Seed in einer Standarddatenbank in einer Umgebung ohne Data Guard:
dbaascli pdb create --dbName db721 --pdbName new_pdb1 --maxsize 5G --maxcpu 2
So erstellen Sie eine PDB in einer Data Guard-Umgebung:
dbaascli pdb create --dbName db721 --pdbName new_pdb1
dbaascli pdb create --dbName db721 --pdbName new_pdb1 --standbyBlobFromPrimary /tmp/send_db721.tar

dbaascli pdb delete

Um eine integrierbare Datenbank (PDB) zu löschen, führen Sie den Befehl dbaascli pdb delete aus.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli pdb delete --dbName value 
{ --pdbName value | --pdbUID value }
[--executePrereqs value]
[--waitForCompletion value]
[--resume [--sessionID value]]
[--allStandbyPrepared]
[--cleanupRelocatedPDB]
Dabei gilt:
  • --dbName gibt den Namen der Containerdatenbank an, welche die PDB hostet.
  • --pdbName gibt den Namen der zu löschenden PDB an.
  • --pdbUID gibt die UID der zu löschenden PDB an.
  • --executePrereqs ist auf yes gesetzt, wenn nur die Voraussetzungen für diesen Vorgang geprüft werden sollen. Gültige Werte: yes oder no
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true oder false
  • --resume gibt an, dass die vorherige Ausführung fortgesetzt werden soll.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --allStandbyPrepared fordert eine Bestätigung an, dass der Vorgang in allen Standbydatenbanken erfolgreich ausgeführt wurde.
  • --cleanupRelocatedPDB ist eine Option zum Bereinigen der Quelldatenbank, nachdem eine PDB umgespeichert wurde.
Beispiel: dbaascli pdb delete

So löschen Sie eine PDB aus einer Standarddatenbank in einer Nicht-Data Guard-Umgebung oder aus einer Standbydatenbank in einer Data Guard-Umgebung

dbaascli pdb delete --dbName db721 --pdbName pdb1

So erstellen Sie eine PDB aus einer Primärdatenbank in einer Data Guard-Umgebung

dbaascli pdb create --dbName db721 --pdbName pdb1 --allStandbyPrepared

dbaascli pdb getDetails

Um Details einer integrierbaren Datenbank (PDB) anzuzeigen, verwenden Sie den Befehl dbaascli pdb getDetails.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli pdb getDetails --dbname --pdbName | --pdbUID
Dabei gilt:
  • --dbname gibt den Namen der Containerdatenbank an, welche die PDB hostet.
  • --pdbname gibt den Namen der zu löschenden PDB an.
  • --pdbUID gibt die ID der PDB an.

Beispiel 6-39: dbaascli pdb getDetails

dbaascli pdb getDetails--dbname cdb name --pdbName pdb name associated with the CDB
dbaascli pdb getDetails--dbname cdb name --pdbUID con_uid of that pdb

dbaascli pdb list

Um die Liste der integrierbaren Datenbanken (PDB) in einer Containerdatenbank anzuzeigen, verwenden Sie den Befehl dbaascli pdb list.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli pdb list --dbname
Dabei gilt:
  • --dbname gibt den Namen der Containerdatenbank an, welche die PDB hostet.

Beispiel 6-40: dbaascli pdb list

dbaascli pdb list --dbname cdb name

dbaascli pdb localClone

Um eine neue integrierbare Datenbank (PDB) als Klon einer vorhandenen PDB in derselben Containerdatenbank (CDB) zu erstellen, verwenden Sie den Befehl dbaascli pdb localClone.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli pdb localClone --pdbName <value> --dbName <value> [--targetPDBName <value>] [--powerLimit <value>] [--maxCPU <value>] [--maxSize <value>] [--resume [--sessionID <value>]] [--executePrereqs] [--waitForCompletion <value>]
    {
      [--blobLocation <value>]
      | [--standbyBlobFromPrimary <value>]
    }
    [--excludeUserTablespaces <value>] [--excludePDBData <value>] [--pdbAdminUserName <value>] [--lockPDBAdminAccount <value>] [--sourcePDBServiceConvertList <value>]
    {
      [--createFromSnapshot
        {
          --snapshotName <value>
          | --snapshotUID <value>
        }
        [--copyDataFiles]]
      | [--snapshot]
    }
Dabei gilt:
  • --pdbName gibt den Namen der neuen PDB an, die Sie klonen möchten.
  • --dbName gibt den Namen der Datenbank an.
  • --targetPDBName gibt den Namen für die Ziel-PDB (neue geklonte PDB) an.
  • --powerLimit gibt den Parallelitätsgrad an, der für den Klonvorgang verwendet werden soll. Gültige Werte: 1 bis 128
  • --maxCPU gibt die maximale Anzahl von CPUs an, die für die PDB zugewiesen werden sollen.
  • --maxSize gibt die maximale Speichergröße in GB für die neue PDB an.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --executePrereqs ist auf yes gesetzt, wenn nur die Voraussetzungen für diesen Vorgang geprüft werden sollen. Gültige Werte: yes oder no
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true oder false
  • --blobLocation gibt einen benutzerdefinierten Verzeichnisspeicherort an, in dem die Standby-BLOB-Datei in einer DG-Umgebung generiert wird.
  • --standbyBlobFromPrimary gibt den Speicherort der Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird. Dies ist nur für PDB-Vorgänge bei Standbydatenbanken erforderlich.
    Hinweis

    Die Parameter blobLocation und standbyBlobFromPrimary schließen sich gegenseitig aus.
  • --excludeUserTablespaces: Option zum Überspringen von Benutzer-Tablespaces, Beispiel: t1,t2,t3.
  • --excludePDBData : Geben Sie "true/yes" an, um Benutzerdaten aus der Quell-PDB zu überspringen.
  • --pdbAdminUserName: Geben Sie den neuen PDB-Admin-Benutzernamen an.
  • --lockPDBAdminAccount: Geben Sie true oder false an, um den PDB-Admin-Benutzeraccount zu sperren. Standardwert ist True.
  • --sourcePDBServiceConvertList: Geben Sie eine kommagetrennte Liste der Quellservicenamen an, die konvertiert werden müssen. Die Syntax lautet source_srv1:new_srv1,source_srv2:new_srv2.
  • --createFromSnapshot | --snapshot
    • --createFromSnapshot: Geben Sie an, dass PDB aus PDB-Snapshot erstellt werden soll.

      --snapshotName | --snapshotUID

      • --snapshotName: Geben Sie den Snapshot-Namen ein, um eine PDB aus der PDB zu erstellen.
      • --snapshotUID: Geben Sie die Snapshot-UID zum Erstellen einer PDB aus der PDB an.

      --copyDataFiles: Geben Sie diese Option zum Überspringen der Snapshot-Kopie an.

    • --snapshot: Geben Sie an, ob eine PDB mit Snapshot-Kopie erstellt werden soll.

Die neu geklonte PDB erbt Administrationskennwörter von der Quell-PDB.

Beispiel 6-41: dbaascli pdb localClone

dbaascli pdb localClone --dbName db35 --pdbName PDB35 --targetPDBName local_clone1 --maxCPU 2 --maxSize 15

dbaascli pdb open

Um eine integrierbare Datenbank (PDB) zu öffnen, verwenden Sie den Befehl dbaascli pdb open.

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli pdb open
 {
   --pdbName <value> | --pdbUID <value>
 }
--dbname <value> [--openMode <value>] [--startServices <value>] [--waitForCompletion <value>] [--setPDBRefreshModeNone [--skipPDBRefresh] [--pdbAdminUserName <value>]]
Dabei gilt:
  • --pdbName gibt den Namen der PDB an, die geöffnet werden soll.
  • --pdbUID gibt die ID der PDB an.
  • --dbname gibt den Namen der Containerdatenbank an, welche die PDB hostet.
  • --openMode gibt den Ziel-OPEN MODE für die PDB an.
  • --startServices: Gibt an, dass alle Services einer PDB gestartet oder aufgelistet werden sollen. Akzeptierte Werte sind all oder eine durch Komma getrennte Liste mit PDB-Services.
  • --waitForCompletion: Mit false belegen, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true|false
  • --setPDBRefreshModeNone: Gibt an, dass eine aktualisierbare PDB in eine nicht aktualisierbare PDB konvertiert werden soll
    • --skipPDBRefresh: Gibt an, dass die Aktualisierung einer aktualisierbaren PDB übersprungen werden soll
    • --pdbAdminUserName: gibt den neuen PDB-Admin-Benutzernamen an.

Nach erfolgreicher Ausführung wird die PDB in allen Instanzen der Containerdatenbank geöffnet.

Beispiel 6-42: dbaascli pdb open

dbaascli pdb open --dbname cdb name --pdbName pdb name associated with the CDB
dbaascli pdb open --dbname cdb name --pdbUID con_uid of that pdb

Optional: --openMode READ_WRITE/READ_ONLY

dbaascli pdb recover

Um eine integrierbare Datenbank (PDB) wiederherzustellen, verwenden Sie den Befehl dbaascli pdb recover.

Voraussetzung

  • Führen Sie den Befehl als Benutzer root aus.
  • Die Datenbank muss mit den Details des Backupspeicherziels konfiguriert sein, in dem Backups gespeichert werden.

Syntax

dbaascli pdb recover --pdbName <value> --dbname <value>
        {
            --start
                {
                    --untilTime <value>
                    | --untilSCN <value>
                    | --latest
                    | --tag <value>
                }
            | --status --uuid <value>
        }
Dabei gilt:
--pdbName: PDB name.
--dbname: Oracle Database name.
--start | --status
--start
       --untilTime | --untilSCN | --latest | --tag
       --untilTime: Recovers PDB until time. Input format: DD-MON-YYYY HH24:MI:SS.
       --untilSCN: Recovers PDB until SCN.
       --latest: Recovers PDB to last known state.
       --tag: Recovers PDB to archival tag.
--status
       --uuid <value>

Beispiel 6-43: Beispiele: Beispiele

  • So stellen Sie eine PDB pdb1 in einer CDB myTestDb auf den neuesten Stand wieder her:
    dbaascli pdb recover --dbname myTestDb --pdbName pdb1 --start --latest
  • So fragen Sie den Status der mit uuid 81a17352362011ecbc3000163e8e4fac übermittelten PDB-Recovery-Anforderung ab:
    dbaascli pdb recover --dbname myTestDb --pdbName pdb1 --status --uuid 81a17352362011ecbc3000163e8e4fac

dbaascli pdb refresh

Um eine angegebene integrierbare Datenbank (PDB) zu aktualisieren, verwenden Sie den Befehl dbaascli pdb refresh.

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli pdb refresh --dbname <value>
   {
      --pdbName <value> | --pdbUID <value>
    }
    [--waitForCompletion <value>]

Dabei gilt:

  • --dbname: gibt den Namen der Oracle-Datenbank an
  • --pdbName: Gibt den Namen der integrierbaren Datenbank an
  • --pdbUID: Gibt die ID der integrierbaren Datenbank an
  • --waitForCompletion: Mit false belegen, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true|false

dbaascli pdb relocate

Um die angegebene PDB aus der Remotedatenbank in die lokale Datenbank zu verschieben, verwenden Sie den Befehl dbaascli pdb relocate.

Voraussetzung

Führen Sie den Befehl als Benutzer oracle aus. Wenn Sie dazu aufgefordert werden, müssen Sie das SYS-Benutzerkennwort für die Quelldatenbank angeben.

Syntax

dbaascli pdb relocate --pdbName <value> --dbName <value> --sourceDBConnectionString <value> 
[--targetPDBName <value>]
[--powerLimit <value>]
[--maxCpu <value>]
[--maxSize <value>]
[--resume [--sessionID <value>]]
[--executePrereqs <value>]
[--sourcePDBServices <value>]
[--sourcePDBReadOnlyServices <value>]
[--waitForCompletion <value>]
{
    [--blobLocation <value>] | [--standbyBlobFromPrimary <value>]
}
[--upgradePDB <value>]
[--updateDBBlockCacheSize]
{
    [skipOpenPDB] | [--completePDBRelocate]
}
Dabei gilt:
  • --pdbName gibt den Namen der Quell-PDB an, die umgespeichert werden soll.
  • --dbName gibt den Namen der Zieldatenbank an.
  • --sourceDBConnectionString gibt die Verbindungszeichenfolge der Quelldatenbank im Format <scan_name>:<scan_port>/<database_service_name> an.
  • --targetPDBName gibt einen Namen für die Ziel-PDB (neue umgespeicherte PDB) an.
  • --powerLimit gibt den Parallelitätsgrad an, der für den Umspeicherungsvorgang verwendet werden soll.
  • --maxCpu gibt die maximale Anzahl von CPUs an, die für die PDB zugewiesen werden sollen.
  • --maxSize gibt die maximale Speichergröße in GB für die neue PDB an.
  • --resume gibt an, dass die vorherige Ausführung fortgesetzt werden soll.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --executePrereqs ist auf yes gesetzt, wenn nur die Voraussetzungen für diesen Vorgang geprüft werden sollen. Gültige Werte: yes|no
  • --sourcePDBServices gibt eine kommagetrennte Liste mit Quell-PDB-Services an.
  • --sourcePDBReadOnlyServices gibt eine kommagetrennte Liste der schreibgeschützten Quell-PDB-Services an.
  • --waitForCompletion gibt "false" an, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false
  • --blobLocation gibt einen benutzerdefinierten Verzeichnisspeicherort an, in dem die Standby-BLOB-Datei in einer DG-Umgebung generiert wird.
  • --standbyBlobFromPrimary gibt den Speicherort der Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird. Dies ist nur für Standbyvorgänge erforderlich.
    Hinweis

    Die Parameter --blobLocation und schließen sich gegenseitig aus.
  • --upgradePDB: Geben Sie true an, um die PDB im Rahmen dieses Vorgangs upzugraden. Gültige Werte : true | false.
  • --updateDBBlockCachesize: Option, mit der die Anwendung Initialisierungsparameter für die DB-Blockcachegröße festlegen kann, um eine Datenkopie mit einer anderen Blockgröße zu unterstützen.
  • --skipOpenPDB: Gibt an, dass die PDB am Ende des aktuellen Vorgangs nicht geöffnet werden soll.
  • --completePDBRelocate: Schließt die PDB-Umspeicherung ab, wenn nachdem der Vorgang in zwei Schritten ausgeführt wurde.

Beispiel 6-44: dbaascli pdb relocate

dbaascli pdb relocate --sourceDBConnectionString test-scan.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com:1521/source_cdb_service_name --pdbName source_pdb --dbName target_db

dbaascli pdb remoteClone

Um eine neue integrierbare Datenbank (PDB) als Klon einer vorhandenen PDB in einer anderen Containerdatenbank (CDB) zu erstellen, verwenden Sie den Befehl dbaascli pdb remoteClone.

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli pdb remoteClone --pdbName <value> --dbName <value> --sourceDBConnectionString <value> [--targetPDBName <value>] [--powerLimit <value>] [--maxCPU <value>] [--maxSize <value>] [--resume [--sessionID <value>]] [--executePrereqs] [--waitForCompletion <value>] [--sourcePDBExportedTDEKeyFile <value>]
        {
            [--blobLocation <value>]
            | [--standbyBlobFromPrimary <value>]
        }
[--excludeUserTablespaces <value>] 
[--excludePDBData <value>] 
[--pdbAdminUserName <value>] 
[--lockPDBAdminAccount <value>] 
[--sourcePDBServiceConvertList <value>] 
[--refreshablePDB --refreshMode <value> [--refreshIntervalInMinutes <value>] --dblinkUsername <value> [--honorCaseSensitiveUserName]] 
[--updateDBBlockCacheSize]
Dabei gilt:
  • --pdbName gibt den Namen der Quell-PDB an, die Sie klonen möchten.
  • --dbname gibt den Namen (DB_NAME) der CDB an, welche die neu geklonte PDB hostet.
  • --sourceDBConnectionString gibt die Verbindungszeichenfolge der Quelldatenbank im Format scan_name:scan_port/database_service_name an.
  • --targetPDBName gibt den Namen für die Ziel-PDB (neue geklonte PDB) an.
  • --powerLimit gibt den Parallelitätsgrad an, der für den Klonvorgang verwendet werden soll. Gültige Werte: 1 bis 128
  • --maxCPU gibt die maximale Anzahl von CPUs an, die für die PDB zugewiesen werden sollen.
  • --maxSize gibt die maximale Speichergröße in GB für die neue PDB an.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --executePrereqs ist auf yes gesetzt, wenn nur die Voraussetzungen für diesen Vorgang geprüft werden sollen. Gültige Werte: yes oder no
  • --waitForCompletion ist auf false gesetzt, wenn der Vorgang im Hintergrund ausgeführt werden soll. Gültige Werte: true oder false
  • --sourcePDBExportedTDEKeyFile gibt die exportierte Schlüsseldatei der Quell-PDB an. Diese Variable gilt nur für 12.1-Datenbanken.
  • --blobLocation gibt den benutzerdefinierten Pfad an, in dem die Standby-BLOB-Datei in einer Data Guard-Umgebung generiert wird.
  • --standbyBlobFromPrimary: Geben Sie den Speicherort der Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird. Dies ist nur für PDB-Vorgänge bei Standbydatenbanken erforderlich.
    Hinweis

    Die Parameter blobLocation und standbyBlobFromPrimary schließen sich gegenseitig aus.
  • --excludeUserTablespaces: Option zum Überspringen von Benutzer-Tablespaces. Beispiel: t1,t2,t3.
  • --excludePDBData: Geben Sie true/yes an, um Benutzerdaten aus der Quell-PDB zu überspringen.
  • --pdbAdminUserName gibt den neuen PDB-Admin-Benutzernamen an.
  • --lockPDBAdminAccount: Geben Sie true oder false an, um den PDB-Admin-Benutzeraccount zu sperren. Standardwert ist True.
  • --sourcePDBServiceConvertList: Geben Sie eine kommagetrennte Liste der Quellservicenamen an, die in Zielservicenamen konvertiert werden müssen. Die Syntax lautet source_srv1:new_srv1, source_srv2:new_srv2.
  • --refreshablePDB gibt an, dass eine aktualisierbare PDB erstellt werden soll.
    • --refreshMode gibt den Aktualisierungsmodus für die aktualisierbare PDB an. Gültige Werte: AUTO|MANUAL
      • --refreshIntervalInMinutes gibt das Aktualisierungsintervall für refreshablePDB in Minuten an
    • --dblinkUsername gibt den allgemeinen Benutzer einer Remotedatenbank an, der für den Datenbanklink zur Verbindung mit der Remotedatenbank verwendet werden soll.
      • --honorCaseSensitiveUserName gibt an, dass beim angegebenen Benutzernamen die Groß-/Kleinschreibung beachtet werden muss.
  • --updateDBBlockCacheSize: Gibt an, dass die Anwendung db block cache size-Initialisierungsparameter setzen kann, um eine Datenkopie mit einer anderen Blockgröße zu unterstützen

Auf Aufforderung müssen Sie das SYS-Benutzerkennwort für die Quell-PDB angeben. Die neu geklonte PDB erbt Administrationskennwörter von der Quell-PDB. Der Name der geklonten PDB hat folgendes Format: dbname_sourcepdbname. Dieser Befehl wird nur für Datenbanken unterstützt, die sich nicht in einer Data Guard-Konfiguration befinden und Oracle Database Version 12.2.0.1 oder höher verwenden.

Beispiel 6-45: dbaascli pdb remoteClone

dbaascli pdb remoteClone --sourceDBConnectionString test-can.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com:1521 --pdbName source_pdb1 --dbName db9944 --targetPDBName new_pdb1 --maxsize 5 --maxcpu 2
dbaascli pdb remoteClone --sourceDBConnectionString orcla.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com --pdbName source_pdb1 --dbName db9944 --targetPDBName new_pdb1 --maxsize 5 --maxcpu 2

dbaascli system getDBHomes

Um Informationen zu allen Oracle Homes anzuzeigen, verwenden Sie den Befehl dbaascli system getDBHomes.

Voraussetzung

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli system getDBHomes

Beispiel 6-46: dbaascli system getDBHomes

dbaascli system getDBHomes

dbaascli-System getGridHomes

Um die Details aller Grid Homes aufzulisten, verwenden Sie den Befehl dbaascli system getGridHomes.

Voraussetzung

Führen Sie den Befehl als Benutzer root oder oracle aus.

Syntax

dbaascli system getGridHomes

dbaascli tde changePassword

Um das TDE-Keystore-Kennwort und das DB-Wallet-Kennwort für den Alias tde_ks_passwd zu ändern, verwenden Sie den Befehl dbaascli tde changePassword.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde changePassword [--dbname <value>]
  {            [--prepareStandbyBlob <value> [--blobLocation <value>]]
               | [--standbyBlobFromPrimary <value>]
  }
  [--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --prepareStandbyBlob: Geben Sie "true" an, um eine BLOB-Datei mit den Artefakten zu generieren, die zum Ausführen des Vorgangs in einer DG-Umgebung erforderlich sind.
  • --blobLocation gibt einen benutzerdefinierten Pfad an, in dem die Standby-BLOB-Datei in einer DG-Umgebung generiert wird.
  • --standbyBlobFromPrimary: Geben Sie den Speicherort der Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird. Dies ist nur für Standbyvorgänge erforderlich.
  • --resume setzt die vorherige Ausführung fort.
  • --sessionID setzt eine bestimmte Session-ID fort.
So ändern Sie das TDE-Kennwort in einer Nicht-Data-Guard-Umgebung
dbaascli tde changepassword --dbname
      <dbname>
So ändern Sie das TDE-Kennwort in einer Data Guard-Umgebung
  1. Ändern Sie das TDE-Kennwort in der Primärdatenbank.
    dbaascli tde changepassword --dbname
          <dbname> --prepareStandbyBlob true --blobLocation
          <Location where blob file has to be generated>
  2. Kopieren Sie die erstellte Standby-BLOB-Datei in die Standby-Datenbankumgebung.
  3. Ändern Sie das TDE-Kennwort in Standby-Datenbank.
    dbaascli tde changepassword --dbname
         <dbname> --standbyBlobFromPrimary <Location of blob generated from
        primary>

dbaascli tde addSecondaryHsmKey

Um der vorhandenen HSM-(KMS-)Konfiguration einen sekundären HSM-(KMS-)Schlüssel hinzuzufügen, verwenden Sie den Befehl dbaascli tde addSecondaryHsmKey.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde addSecondaryHsmKey --dbname <value> --secondaryKmsKeyOCID <value>
[--executePrereqs]
Dabei gilt:
  • --secondaryKmsKeyOCID gibt den sekundären KMS-Schlüssel an, der der vorhandenen HSM-(KMS-)Konfiguration hinzugefügt werden soll.
  • --dbname gibt den Namen der Datenbank an.
  • --executePrereqs führt die Voraussetzungsprüfungen aus und meldet die Ergebnisse.

Beispiel 6-47: dbaascli tde addSecondaryHsmKey

dbaascli tde addSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde addSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --precheckOnly yes

dbaascli tde enableWalletRoot

Um den spfile-Parameter wallet_root für die vorhandene Datenbank zu aktivieren, verwenden Sie den Befehl dbaascli tde enableWalletRoot.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde enableWalletRoot --dbname <value>
[--dbRestart <value>]
[--executePrereqs]
[--resume [--sessionID <value>]]
Dabei gilt:
  • --dbname gibt den Namen der Oracle-Datenbank an.
  • --dbrestart gibt die Option für den Datenbankneustart an. Gültige Werte: rolling oder full. Standardwert: rolling

    Wenn Sie das Argument dbrestart nicht übergeben, wird die Datenbank im rolling-Modus neu gestartet.

  • --precheckOnly führt nur die Vorabprüfung für diesen Vorgang aus. Gültige Werte: yes oder no
  • --resume setzt die vorherige Ausführung fort.
  • --sessionID setzt eine bestimmte Session-ID fort.

Beispiel 6-48: dbaascli tde enableWalletRoot

dbaascli tde enableWalletRoot --dbname db name --dbrestart rolling|full
dbaascli tde enableWalletRoot --dbname orcl
dbaascli tde enableWalletRoot --dbname orcl--dbrestart full

dbaascli tde encryptTablespacesInPDB

Um alle Tablespaces in der angegebenen PDB zu verschlüsseln, verwenden Sie den Befehl dbaascli tde encryptTablespacesInPDB.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde encryptTablespacesInPDB --pdbName
[--dbname]
[--precheckOnly]
[--useSysdbaCredential]
Dabei gilt:
  • --pdbName gibt den Namen der PDB an, in der alle Tablespaces verschlüsselt werden sollen.
  • --dbname gibt den Namen der Oracle-Datenbank an.
  • --precheckOnly führt nur die Vorabprüfung für diesen Vorgang aus. Gültige Werte: yes oder no
  • --useSysdbaCredential verwendet SYSDBA-Zugangsdaten für diesen Vorgang, wenn der Wert true übergeben wird. Gültige Werte: true oder false

Beispiel 6-49: dbaascli tde encryptTablespacesInPDB

dbaascli tde encryptTablespacesInPDB --dbname dbname --pdbName pdb
dbaascli tde encryptTablespacesInPDB --dbname dbname --pdbName pdb --precheckOnly yes
dbaascli tde encryptTablespacesInPDB --dbname dbname --pdbName pdb --useSysdbaCredential true

dbaascli tde fileToHsm

Um FILE-basierte TDE in HSM-(KMS/OKV-)basierte TDE zu konvertieren, verwenden Sie den Befehl dbaascli TDE fileToHsm.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde fileToHsm --kmsKeyOCID <value> --dbname <value> 
[--skipPatchCheck <value>] 
[--executePrereqs ] 
[--primarySuc <value>]
{
    [--resume [--sessionID <value>]] | [--revert [--sessionID <value>]]
}
[--waitForCompletion <value>]
Dabei gilt:
  • --kmsKeyOCID gibt die für TDE zu verwendende KMS-Schlüssel-OCID an. Gilt nur, wenn KMS für TDE ausgewählt ist.
  • --dbname gibt den Namen der Datenbank an.
  • --skipPatchCheck überspringt die Validierungsprüfung für erforderliche Patches, wenn als Wert dieses Arguments true übergeben wird. Gültige Werte: true oder false
  • --executePrereqs führt die Voraussetzungsprüfungen aus und meldet die Ergebnisse.
  • --primarySuc: Geben Sie diese Eigenschaft in der Standbydatenbank der Data Guard-Umgebung an, nachdem der Befehl erfolgreich in der Primärdatenbank ausgeführt wurde.
  • --resume gibt an, dass die vorherige Ausführung fortgesetzt werden soll.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --revert gibt an, dass ein Rollback der vorherigen Ausführung durchgeführt werden soll.
    • --sessionID gibt an, dass ein Rollback einer bestimmten Session-ID durchgeführt werden soll.
  • --waitForCompletion: Geben Sie "false" an, um den Vorgang im Hintergrund auszuführen. Gültige Werte : true|false.

Beispiel 6-50: dbaascli tde fileToHsm --kmsKeyOCID

dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs 
dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --resume

dbaascli tde getHsmKeys

Um Details zum aktiven TDE-Schlüssel abzurufen, verwenden Sie den Befehl dbaascli TDE getHsmKeys.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde getHsmKeys
[--dbname]
[--infoFile]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --infoFile gibt den Dateipfad an, in dem die Liste der OCIDs gespeichert wird. Die Ausgabe hat das JSON-Format.

Beispiel 6-51: dbaascli tde getHsmKeys

dbaascli tde getHsmkeys --dbname dbname
dbaascli tde getHsmkeys --dbname dbname --infoFile infoFilePath

dbaascli tde getMkidForKeyVersionOCID

Um die Masterschlüssel-ID abzurufen, die mit der KMS-Schlüsselversions-OCID verknüpft ist, verwenden Sie den Befehl dbaascli tde getMkidForKeyVersionOCID.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde getMkidForKeyVersionOCID --kmsKeyVersionOCID <value>
[--dbname <value>]
[--waitForCompletion <value>]
Dabei gilt:
  • --kmsKeyVersionOCID gibt die OCID der KMS-Schlüsselversion an, die festgelegt werden soll.
  • --dbname gibt den Namen der Datenbank an.
  • --waitForCompletion: Geben Sie false an, um den Vorgang im Hintergrund auszuführen. Gültige Werte : true|false.

Beispiel 6-52: dbaascli tde getMkidForKeyVersionOCID

dbaascli tde getMkidForKeyVersionOCID --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha

dbaascli tde getPrimaryHsmKey

Um den primären HSM-(KMS-)Schlüssel aus der vorhandenen HSM-(KMS-)Konfiguration abzurufen, verwenden Sie den Befehl dbaascli tde getPrimaryHsmKey.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde getPrimaryHsmKey
[--dbname]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.

Beispiel 6-53: dbaascli tde getPrimaryHsmKey

dbaascli tde getPrimaryHsmKey --dbname dbname

dbaascli tde hsmToFile

Um HSM-(KMS/OKV-)basierte TDE- in FILE-basierte TDE zu konvertieren, verwenden Sie den Befehl dbaascli tde hsmToFile.

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde hsmToFile 
[--dbname <value>] 
{
    [--prepareStandbyBlob <value> [--blobLocation <value>]
   | [--standbyBlobFromPrimary <value>]
}
] 
[--skipPatchCheck <value>] 
[--executePrereqs ] 
[--primarySuc <value>] 
{
     [--resume [--sessionID <value>]] |
     [--revert [--sessionID <value>]]
} 
[--waitForCompletion <value>]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --prepareStandbyBlob: Geben Sie true an, um eine BLOB-Datei mit den Artefakten zu generieren, die zum Ausführen des Vorgangs in einer DG-Umgebung erforderlich sind.
  • --blobLocation gibt einen benutzerdefinierten Verzeichnisspeicherort an, in dem die Standby-BLOB-Datei in einer DG-Umgebung generiert wird.
  • --standbyBlobFromPrimary gibt den Speicherort der Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird. Dies ist nur für Standbyvorgänge erforderlich.
  • --skipPatchCheck überspringt die Validierungsprüfung für erforderliche Patches, wenn als Wert dieses Arguments true übergeben wird. Gültige Werte: true oder false
  • --executePrereqs führt die Voraussetzungsprüfungen aus und meldet die Ergebnisse.
  • --primarySuc: Geben Sie diese Eigenschaft in der Standbydatenbank der Data Guard-Umgebung an, nachdem der Befehl erfolgreich in der Primärdatenbank ausgeführt wurde.
  • --resume setzt die vorherige Ausführung fort.
    • --sessionID gibt an, dass eine bestimmte Session-ID fortgesetzt werden soll.
  • --revert gibt an, dass die vorherige Ausführung zurückgesetzt werden soll.
    • --sessionID gibt an, dass ein Rollback einer bestimmten Session-ID durchgeführt werden soll.
  • --waitForCompletion gibt false an, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false

Beispiel 6-54: dbaascli tde hsmToFile

dbaascli tde hsmToFile --dbname dbname
dbaascli tde hsmToFile --dbname dbname --executePrereqs
dbaascli tde hsmToFile --dbname dbname --resume

dbaascli tde listKeys

Um TDE-Masterschlüssel aufzulisten, verwenden Sie den Befehl dbaascli TDE listKeys.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde listKeys
[--dbname <value>]
[--infoFilePath <value>]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --infoFilePath: Geben Sie den absoluten Pfad der Datei an, in der die Ergebnisse gespeichert werden.

Beispiel 6-55: dbaascli tde listKeys

dbaascli tde listKeys --dbname dbname
dbaascli tde listKeys --dbname dbname --infoFilePath infoFilePath

dbaascli tde removeSecondaryHsmKey

Um den sekundären HSM-(KMS-)Schlüssel aus der vorhandenen HSM-(KMS-)Konfiguration zu entfernen, verwenden Sie den Befehl dbaascli tde removeSecondaryHsmKey.

Voraussetzung

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde removeSecondaryHsmKey --dbname <value>
[--confirmDeletion]
[--secondaryKmsKeyOCID]
[--executePrereqs]
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an.
  • --confirmDeletion: Ist diese Option nicht angegeben, werden dem Benutzer beim Löschen aller vorhandenen HSM-(KMS-)Schlüssel Prompts angezeigt.
  • --secondaryKmsKeyOCID gibt den sekundären KMS-Schlüssel an, der aus einer vorhandenen HSM-(KMS-)Konfiguration entfernt werden soll. Wenn Sie diese Option nicht angeben, werden alle sekundären KMS-Schlüssel entfernt.
  • --executePrereqs führt die Voraussetzungsprüfungen aus und meldet die Ergebnisse.

Häufig gestellte Fragen

F: Wozu dient der Befehl dbaascli tde removeSecondaryHsmKey?

A: Mit dem Befehl dbaascli tde removeSecondaryHsmKey wird ein sekundärer Hardware Security Module-(HSM-)Schlüssel aus der vorhandenen HSM-(KMS-)Konfiguration in einer Oracle Database-Umgebung entfernt.

F: Welche Voraussetzungen müssen für die Ausführung des Befehls dbaascli tde removeSecondaryHsmKey erfüllt sein?

A: Sie müssen:
  • Führen Sie den Befehl als Benutzer root aus.
  • Stellen Sie mit SSH eine Verbindung zu einer virtuellen Exadata Cloud Infrastructure-Maschine her.

F: Was bewirkt der Parameter --force im Befehl dbaascli tde removeSecondaryHsmKey?

A: Mit dem Parameter --force kann der sekundäre HSM-Schlüssel entfernt werden, ohne dass der Benutzer zur Bestätigung aufgefordert wird. Wenn keine Angabe gemacht wird, fordert der Befehl den Benutzer auf, bevor er Schlüssel löscht.

F: Was gibt der Parameter --secondaryKmsKeyOCID an?

A: Der Parameter --secondaryKmsKeyOCID gibt die OCID (Oracle Cloud-ID) des sekundären KMS-Schlüssels an, den Sie aus der vorhandenen HSM-Konfiguration entfernen möchten.

F: Was bewirkt der Parameter --dbname?

A: Der Parameter --dbname gibt den Namen der Datenbank an, für die der sekundäre HSM-Schlüssel entfernt wird.

F: Was ist der Zweck des Parameters --precheckOnly?

A: Wenn der Parameter --precheckOnly auf yes gesetzt ist, werden nur die Vorabprüfungen ausgeführt, um die Bereitschaft für den Entfernungsvorgang zu validieren, ohne den sekundären HSM-Schlüssel tatsächlich zu entfernen. Wenn dieser Wert auf no gesetzt ist, wird der vollständige Entfernungsvorgang ausgeführt.

F: Ist der Parameter --force erforderlich?

A: Nein, der Parameter --force ist optional. Ist dies nicht angegeben, fordert das System den Benutzer zur Bestätigung auf, bevor das Entfernen des Schlüssels fortgesetzt wird.

F: Ist der Parameter --secondaryKmsKeyOCID obligatorisch?

A: Ja, Sie müssen --secondaryKmsKeyOCID angeben, um den spezifischen sekundären HSM-Schlüssel zu identifizieren, den Sie aus der Konfiguration entfernen möchten.

F: Ist der Parameter --dbname obligatorisch?

A: Nein, der Parameter --dbname ist optional. Wenn keine Angabe gemacht wird, versucht der Befehl, den sekundären HSM-Schlüssel aus der Standarddatenbank im System zu entfernen.

F: Was soll ich tun, wenn ich den sekundären HSM-Schlüssel ohne Benutzereingaben entfernen möchte?

A: Verwenden Sie den Parameter --force, um den Bestätigungs-Prompt zu umgehen und den sekundären HSM-Schlüssel direkt zu entfernen:

dbaascli tde removeSecondaryHsmKey --force --secondaryKmsKeyOCID <value>

F: Wie kann ich testen, ob das System bereit ist, den sekundären HSM-Schlüssel zu entfernen, ohne ihn tatsächlich zu entfernen?

A: Sie können den Parameter --precheckOnly, der auf "Ja" gesetzt ist, verwenden, um eine Vorabprüfung auszuführen:

dbaascli tde removeSecondaryHsmKey --precheckOnly yes --secondaryKmsKeyOCID <value>

F: Was geschieht, wenn ich keinen Datenbanknamen mit --dbname gebe?

A: Wenn der Parameter --dbname nicht angegeben ist, versucht der Befehl, den sekundären HSM-Schlüssel aus der auf dem System konfigurierten Standarddatenbank zu entfernen.

F: Was sollte ich überprüfen, ob der Befehl den sekundären HSM-Schlüssel nicht entfernt?

A: Stellen Sie sicher, dass:
  • Sie führen den Befehl als Benutzer root aus.
  • Sie sind mit der virtuellen Maschine von Exadata Cloud Infrastructure verbunden.
  • Die korrekten --secondaryKmsKeyOCID- und --dbname-Werte werden angegeben. Weitere Einzelheiten zum Fehler finden Sie in den Fehlermeldungen und Logs.

F: Was muss ich tun, wenn der Entfernungsvorgang nicht erfolgreich verläuft?

A: Wenn der Vorgang nicht erfolgreich verläuft, prüfen Sie die Fehlerlogs, und führen Sie den Befehl mit --precheckOnly aus, um sicherzustellen, dass das System für den Vorgang bereit ist. Beheben Sie bei Bedarf alle Probleme, bevor Sie den Vorgang wiederholen.

F: Kann ich den Befehl dbaascli tde removeSecondaryHsmKey ausführen, während die Datenbank ausgeführt wird?

A: Ja, der Befehl kann während der Ausführung der Datenbank ausgeführt werden, da die Datenbank nicht gestoppt werden muss.

F: Was ist der Zweck, einen sekundären HSM-Schlüssel zu entfernen?

A: Das Entfernen eines sekundären HSM-Schlüssels erfolgt in der Regel, wenn der Schlüssel nicht mehr benötigt wird oder wenn Sie die in der TDE-Konfiguration (Transparente Datenverschlüsselung) verwendeten Verschlüsselungsschlüssel verwalten möchten.

F: Wie stelle ich eine Verbindung zur virtuellen Maschine von Exadata Cloud Infrastructure her, um den Befehl auszuführen?

A: Sie können mit SSH eine Verbindung zur virtuellen Maschine herstellen. Anweisungen zum Herstellen einer sicheren Verbindung finden Sie in der Exadata Cloud Infrastructure-Dokumentation.

Beispiel 6-56: dbaascli tde removeSecondaryHsmKey

dbaascli tde removeSecondaryHsmKey --dbname dbname
dbaascli tde removeSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde removeSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs 

dbaascli tde rotateMasterKey

Rotieren Sie den Masterschlüssel für die Datenbankverschlüsselung.

Voraussetzungen:

Führen Sie den Befehl als Benutzer root aus.

Syntax

(Optional) <Geben Sie hier Syntaxinformationen ein.>

dbaascli tde rotateMasterKey --dbname <value> 
[--rotateMasterKeyOnAllPDBs] 
[--pdbName <value>] 
[--executePrereqs] 
[--resume [--sessionID <value>]]
{
     [--prepareStandbyBlob <value> [--blobLocation <value>]]
     | [--standbyBlobFromPrimary <value>]
 }
Dabei gilt:
  • --dbname: Name der Oracle-Datenbank.
  • --rotateMasterKeyOnAllPDBs: Geben Sie "true" an, um den Masterschlüssel aller PDBs in der CDB zu rotieren. Gültige Werte: true|false
  • --pdbName: Geben Sie den PDB-Namen an.
  • --executePrereqs: Führen Sie die Voraussetzungsprüfungen aus, und melden Sie die Ergebnisse.
  • --resume setzt die vorherige Ausführung fort.
  • --sessionID setzt eine bestimmte Session-ID fort.
  • --prepareStandbyBlob | --standbyBlobFromPrimary]
  • --prepareStandbyBlob: Geben Sie "true" an, um eine BLOB-Datei mit den Artefakten zu generieren, die zum Ausführen des Vorgangs in einer DG-Umgebung erforderlich sind.
  • --blobLocation: benutzerdefinierter Verzeichnisspeicherort, in dem die Standby-BLOB-Datei in einer DG-Umgebung generiert wird.
  • --standbyBlobFromPrimary: Geben Sie den Speicherort der Standby-BLOB-Datei an, die von der Primärdatenbank aus vorbereitet wird. Dies ist nur für Standbyvorgänge erforderlich

dbaascli tde setKeyVersion

Um die Version des Primärschlüssels festzulegen, der in einer DB/CDB oder PDB verwendet werden soll, verwenden Sie den Befehl dbaascli tde setKeyVersion.

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --dbname <value>
[--pdbName <value>]
[--masterKeyID <value>]
[--standbySuc]
[--executePrereqs]
[--waitForCompletion <value>]
Dabei gilt:
  • --kmsKeyVersionOCID gibt die KMS-Schlüsselversions-OCID an, die festgelegt werden soll.
  • --dbname gibt den Namen der Datenbank an.
  • --pdbName gibt den Namen der PDB an, die die Schlüsselversions-OCID verwendet.
  • --masterKeyID gibt die Masterschlüssel-ID der angegebenen Schlüsselversions-OCID an. Dies gilt für die Data Guard-Umgebung.
  • --standbySuc: Geben Sie diese Eigenschaft in der Primärdatenbank der Data Guard-Umgebung an, nachdem der Befehl erfolgreich in der Standbydatenbank ausgeführt wurde.
  • --executePrereqs führt die Voraussetzungsprüfungen aus und meldet die Ergebnisse.
  • --waitForCompletion: Geben Sie false an, um den Vorgang im Hintergrund auszuführen. Gültige Werte: true|false

Beispiel 6-57: dbaascli tde setKeyVersion

dbaascli tde setKeyVersion --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha
dbaascli tde setKeyVersion --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha --executePrereqs
dbaascli tde setKeyVersion --dbname dbname --pdbName pdb --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha

dbaascli tde setPrimaryHsmKey

Um den primären HSM-(KMS-)Schlüssel für die vorhandene HSM-(KMS-)Konfiguration zu ändern, verwenden Sie den Befehl dbaascli tde setPrimaryHsmKey.

Führen Sie den Befehl als Benutzer root aus.

Syntax

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <value> --dbname <value>
[--allStandbyPrepared]
[--bounceDatabase]
[--executePrereqs]
[--resume [--sessionID <value>]]
Dabei gilt:
  • --primaryKmsKeyOCID gibt den primären KMS-Schlüssel an, der festgelegt werden soll.
  • --dbname gibt den Namen der Datenbank an.
  • --allStandbyPrepared: Geben Sie diese Option an, um zu bestätigen, dass der Vorgang in allen Standbydatenbanken erfolgreich ausgeführt wurde.
  • --bounceDatabase: Setzen Sie dieses Flag, um einen Rolling-Datenbank-Bounce für diesen Vorgang auszuführen.
  • --executePrereqs führt die Voraussetzungsprüfungen aus und meldet die Ergebnisse.
  • --resume setzt die vorherige Ausführung fort.
  • --sessionID setzt eine bestimmte Session-ID fort.

Beispiel 6-58: dbaascli tde setPrimaryHsmKey

dbaascli tde setPrimaryHsmKey --dbname dbname --primaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde setPrimaryHsmKey --dbname dbname --primaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs

dbaascli tde status

Um Informationen zum Keystore für die angegebene Datenbank anzuzeigen, verwenden Sie den Befehl dbaascli tde status.

Voraussetzung

Hinweis

Der Befehl dbaascli tde status ist in dbaascli Release 24.4.1.0.0 veraltet. Oracle empfiehlt stattdessen die Verwendung des Befehls dbaascli database getDetails.

Führen Sie den Befehl als Benutzer oracle aus.

Syntax

dbaascli tde status --dbname dbname
Dabei gilt:
  • --dbname gibt den Namen der Datenbank an, die Sie prüfen möchten.

Die Ausgabe des Befehls enthält den Keystore-Typ und den Status des Keystores.

Beispiel 6-59: dbaascli tde status

dbaascli tde status --dbname dbname

Verwandte Themen