Bekannte Probleme

Details: Im synthetischen Monitoring können die Browser- und Skriptbrowsermonitore möglicherweise nicht für Anwendungen ausgeführt werden, die Frames verwenden.

Workaround: Das Problem ist uns bekannt, und wir arbeiten an einer Lösung. Bei Skriptbrowsermonitoren können Sie dieses Problem umgehen, indem Sie index=<frame-index> durch id=<id-of-frame> oder name=<name-of-frame> im Skript .side ersetzen.

Beispiel: Ursprüngliche Version des Skripts:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "index=0",
      "targets": [
        ["index=0"]
      ],
      "value": ""
    }

Geänderte Version des Skripts:

{
      "id": "23956f51-8812-40e6-ac91-1d608871ee4c",
      "comment": "",
      "command": "selectFrame",
      "target": "id=frame1",
      "targets": [
        ["id=frame1"]
      ],
      "value": ""
    }

Direkter Link zu diesem Problem: Browser- und Skriptbrowsermonitore führen möglicherweise keine Anwendungen aus, die Frames verwenden

Details: Autorisierungs-Policys, die auf den apm-domains-Ressourcentags basieren, können für den Trace Explorer und die APIs für synthetisches Monitoring nicht verwendet werden. Sie führen zu Autorisierungsfehlern.

Workaround: Das Problem ist uns bekannt, und wir arbeiten an einer Lösung.

Direkter Link zu diesem Problem: Probleme mit den Autorisierungs-Policys, die auf den Ressourcentags der apm-Domains basieren

Details: Wenn Sie die regionsübergreifende Replikation für ein Volume aktivieren, das für die Verwendung eines Vault-Verschlüsselungsschlüssels konfiguriert ist, wird die folgende Fehlermeldung ausgegeben: Fehler bei Volume-Bearbeitung: Sie können die regionsübergreifende Replikation nicht für Volume <volume_ID> aktivieren, da es einen Vault-Verschlüsselungsschlüssel verwendet.

Workaround: Wir arbeiten an einer Lösung. Die regionsübergreifende Replikation wird für Volumes, die mit vom Kunden verwalteten Schlüsseln verschlüsselt sind, nicht unterstützt. Um die Replikation zu aktivieren, heben Sie die Zuweisung des Vault-Verschlüsselungsschlüssels zum Volume auf. In diesem Szenario wird das Volume mit einem von Oracle verwalteten Schlüssel verschlüsselt.

Direkter Link zu diesem Problem: Die regionsübergreifende Replikation wird für Volumes, die mit vom Kunden verwalteten Schlüsseln verschlüsselt sind, nicht unterstützt

Details: Um die optimale Performance für Volumes zu erzielen, die für extrem hohe Performance konfiguriert wurden, muss der Volume-Anhang Multipath-fähig sein. Multipath-fähige Anhänge von VM-Instanzen werden nur für Instanzen unterstützt, die auf Ausprägungen mit mindestens 16 OCPUs basieren.

Sie können Instanzen mit weniger als 16 OCPUs so vergrößern, dass sie über 16 oder mehr OCPUs verfügt, um Multipath-fähige Anhänge zu unterstützen. Dieser Schritt funktioniert nicht bei Instanzen, bei denen die ursprüngliche OCPU-Anzahl kleiner als 8 war und der Volume-Anhang paravirtualisiert ist. In diesem Szenario ist der Volume-Anhang auch nach dem Trennen und erneuten Anhängen des Volumes nicht Multipath-fähig, obwohl die Instanz jetzt Multipath-fähige Anhänge unterstützt.

Workaround: Als Workaround wird empfohlen, dass Sie eine neue Instanz erstellen, die auf einer Ausprägung mit mindestens 16 OCPUs basiert, und das Volume an die neue Instanz anhängen.

Direkter Link zu diesem Problem: Paravirtualisierter Volume-Anhang ist nach Änderung der Instanzgröße nicht mehr Multipath-fähig

Details: Wenn Sie versuchen, die maximale Anzahl an Block-Volumes an eine kleinere VM.Standard.A1.Flex-Instanz anzuhängen, kann es vorkommen, dass die Volumes nicht angehängt werden können. Dies geschieht aufgrund von Einschränkungen bei der zugrunde liegenden physischen Hostkonfiguration.

Workaround: Wir arbeiten an einer Lösung. Als Workaround wird empfohlen, die Größe der VM durch Ändern der VM-Größe zu erhöhen. Versuchen Sie dann erneut, die Volumes anzuhängen.

Direkter Link zu diesem Problem: Das Anhängen der maximalen Anzahl von Block-Volumes an kleinere VM.Standard.A1.Flex-Instanzen schlägt möglicherweise fehl

Details: Wenn Sie Volume- und Volume-Gruppenbackups mit einer Backup-Policy planen, die für regionsübergreifende Kopien von Volumes aktiviert ist, die mit Vault-Verschlüsselungsschlüsseln gesichert werden, werden die Verschlüsselungsschlüssel nicht mit dem Volume-Backup in die Zielregion kopiert. Die Volume-Backupkopien in der Zielregion werden stattdessen mit von Oracle bereitgestellten Schlüsseln verschlüsselt.

Workaround: Wir arbeiten an einer Lösung. Als Workaround können Sie Volume-Backups und Volume-Gruppenbackups regionsübergreifend entweder manuell oder mit einem Skript kopieren und die Schlüssel-ID für die zentrale Verwaltung in der Zielregion für den Kopiervorgang angeben. Weitere Informationen zum manuellen regionsübergreifenden Kopieren finden Sie unter Volume-Backups zwischen Regionen kopieren.

Direkter Link zu diesem Problem: Vault-Verschlüsselungsschlüssel werden für geplante regionsübergreifende Backupkopien nicht in die Zielregion kopiert

Details: Wenn Sie ein Windows-Boot-Volume mit einer anderen Instanz verknüpfen und versuchen, mit dem Volume eine Verbindung herzustellen, indem Sie die Schritte unter Bei Block-Volumes anmelden ausführen, kann das Volume nicht zugeordnet werden, und möglicherweise tritt der folgende Fehler auf:

Connect-IscsiTarget : The target has already been logged in via an iSCSI session.

Workaround: Sie müssen Folgendes an den aus der Konsole kopierten Connect-IscsiTarget-Befehl anhängen:

-IsMultipathEnabled $True

Direkter Link zu diesem Problem: Ein Windows-Boot-Volume kann nicht als Daten-Volume an eine andere Instanz angehängt werden

Details: Wird GetInstance aufgerufen, ist das Attribut bootVolumeSizeInGBs eines InstanceSourceViaImageDetails Null.

Workaround: Wir arbeiten an einer Lösung. Um dieses Problem zu umgehen, rufen Sie GetBootVolume auf, und verwenden Sie das Attribut sizeInGBs von BootVolume.

Direkter Link zu diesem Problem: Attribut "bootVolumeSizeInGBs" ist Null

Details: Wenn Sie versuchen, mit Firefox auf die Konsole zuzugreifen, wird die Konsolenseite nie im Browser geladen. Dieses Problem wird wahrscheinlich durch ein beschädigtes Firefox-Benutzerprofil verursacht.

Workaround: Erstellen Sie wie folgt ein neues Firefox-Benutzerprofil:

1. Stellen Sie sicher, dass Sie die neueste Version von Firefox verwenden. Führen Sie andernfalls ein Update auf die neueste Version aus.
2. Erstellen Sie ein neues Benutzerprofil, und entfernen Sie Ihr altes Benutzerprofil. Anweisungen zum Erstellen und Entfernen von Benutzerprofilen finden Sie in der Mozilla-Hilfe unter: https://support.mozilla.org/de/kb/profile-manager-create-and-remove-firefox-profiles.
3. Öffnen Sie Firefox mit dem neuen Profil.

Alternativ können Sie einen der anderen unterstützten Browser verwenden.

Direkter Link zu diesem Problem: Ein Bug im Firefox-Browser kann dazu führen, dass die Konsole nicht geladen wird

Details: Vorhandene PDBs werden in einer neu erstellten Datenbank nicht angezeigt. Es kann ein paar Stunden dauern, bis sie in der Konsole angezeigt werden. Dazu gehören die Standard-PDB für eine neue Datenbank und vorhandene PDBs für geklonte oder wiederhergestellte Datenbanken. Bei einer In-Place-Wiederherstellung einer älteren Version wird die PDB-Liste ähnlich aktualisiert, und es können Verzögerungen auftreten.

Workaround: Keine

Direkter Link zu diesem Problem: Vorhandene PDBs in einer neuen Datenbank

Details: Das Erstellen und Klonen einer PDB in der primären Datenbank ist nicht über die Konsole oder das API zulässig.

Workaround: Mit sqlplus können Sie PDBs in der Primärdatenbank erstellen oder klonen. Sie werden später in der OCI-Konsole synchronisiert.

Direkter Link zu diesem Problem: PDB in vorhandener Data Guard-Konfiguration

Details: Die Migration eines dateibasierten TDE-Wallets mit der Database-Service-API in ein vom Kunden verwaltetes, schlüsselbasiertes TDE-Wallet auf Oracle Database 12c Release 1 (12.1.0.2) schlägt fehl. Es kommt zu folgender Fehlermeldung:

[FATAL] [DBAAS-11014] – Erforderliche Patches (30128047) sind im Oracle-Standardverzeichnis nicht vorhanden <ORACLE_HOME>
AKTION: Spielen Sie die erforderlichen Patches (30128047) ein und wiederholen Sie den Vorgang.

nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

Im vorherigen Befehl bezieht sich <kms_key_ocid> auf die OCID des vom Kunden verwalteten Schlüssels, den Sie verwenden.

Details: Die Migration eines vom Kunden verwalteten schlüsselbasierten TDE-Wallets mit der Database-Service-API in ein dateibasiertes TDE-Wallet auf Oracle Database 12c Release 1 (12.1.0.2) schlägt fehl. Es kommt zu folgender Fehlermeldung:

[FATAL] [DBAAS-11014] – Erforderliche Patches (30128047) sind im Oracle-Standardverzeichnis nicht vorhanden <ORACLE_HOME>
AKTION: Spielen Sie die erforderlichen Patches (30128047) ein und wiederholen Sie den Vorgang.

nohup /var/opt/oracle/dbaascli/dbaascli tde hsm_to_file --dbname <database_name> --skip_patch_check true &

Details: Die Migration eines dateibasierten TDE-Wallets mit der Database-Service-API in ein vom Kunden verwaltetes schlüsselbasiertes TDE-Wallet auf Oracle Database 12c Release 2 (12.2.0.1) schlägt fehl. Es kommt zu folgender Fehlermeldung:

[FATAL] [DBAAS-11014] – Erforderliche Patches (30128047) sind im Oracle-Standardverzeichnis nicht vorhanden <ORACLE_HOME>
AKTION: Spielen Sie die erforderlichen Patches (30128047) ein und wiederholen Sie den Vorgang.

Workaround: Migrieren Sie ein dateibasiertes TDE-Wallet wie folgt in ein vom Kunden verwaltetes schlüsselbasiertes TDE-Wallet:

1. Bestimmen Sie, ob die Datenbank verschlüsselte UNDO- oder TEMP-Tablespaces in einer der autonomen Datenbanken oder in CDB$ROOT besitzt, wie folgt:
   Führen Sie die folgende Abfrage aus CDB$ROOT aus, um alle verschlüsselten Tablespaces aufzulisten, die in allen autonomen Datenbanken enthalten sind:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   Suchen Sie in der Spalte NAME des Ergebnisses der Abfrage nach den Namen der UNDO- und TEMP-Tablespaces. Wenn UNDO- oder TEMP-Tablespaces verschlüsselt sind, fahren Sie mit dem nächsten Schritt fort.

2. Heben Sie die Verschlüsselung von UNDO- oder TEMP-Tablespaces wie folgt auf:

   Wenn ein UNDO-Tablespace verschlüsselt ist

   Heben Sie wie folgt die Verschlüsselung vorhandener UNDO-Tablespaces auf:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Wiederholen Sie diese Schritte für alle verschlüsselten UNDO-Tablespaces.

   Wenn ein TEMP-Tablespace verschlüsselt ist

   1. Prüfen Sie den Standard-TEMP-Tablespace wie folgt:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Wenn der Standard-TEMP-Tablespace nicht verschlüsselt ist, andere TEMP-Tablespaces jedoch verschlüsselt sind, löschen Sie die anderen TEMP-Tablespaces wie folgt:

      SQL> drop tablespace <temp_tablespace_name>;

      Überspringen Sie die restlichen Schritte in diesem Verfahren.

      Wenn der Standard-TEMP-Tablespace verschlüsselt ist, fahren Sie mit den restlichen Schritten fort, um einen unverschlüsselten Standard-TEMP-Tablespace zu erstellen und festzulegen.

   2. Legen Sie den Parameter encrypt_new_tablespaces wie folgt auf DDL fest:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Erstellen Sie wie folgt einen TEMP-Tablespace mit den Spezifikationen des aktuellen TEMP-Tablespace:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Legen Sie den neuen TEMP-Tablespace wie folgt als Standard-TEMP-Tablespace für die Datenbank fest:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Löschen Sie vorhandene TEMP-Tablespaces wie folgt:

      SQL> drop tablespace <temp_tablespace_name>;

   Wiederholen Sie diese Schritte für alle verschlüsselten TEMP-Tablespaces.

   Die Datenbank wird jetzt mit unverschlüsselten UNDO- und TEMP-Standard-Tablespaces ausgeführt. Die Verschlüsselung älterer TEMP- und UNDO-Tablespaces wird ebenfalls aufgehoben.

   Setzen Sie encrypt_new_tablespaces wie folgt auf den ursprünglichen Wert:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Fahren Sie mit der Keystore-Migration auf vom Kunden verwaltete Schlüssel fort.

3. Nachdem Sie überprüft haben, ob keine UNDO- oder TEMP-Tablespaces in einer der integrierbaren Datenbanken oder in CDB$ROOT verschlüsselt sind, überspringen Sie die Validierung des Patches für Bug 30128047 mit dem DBAASCLI-Utility mit dem Kennzeichen --skip_patch_check true. Stellen Sie sicher, dass Sie den Patch für Bug 31527103 im Oracle Home eingespielt haben, und führen Sie dann den folgenden Befehl dbaascli aus:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   Im vorherigen Befehl bezieht sich <kms_key_ocid> auf die OCID des vom Kunden verwalteten Schlüssels, den Sie verwenden.

Details: Die Migration eines vom Kunden verwalteten schlüsselbasierten TDE-Wallets mit der Database-Service-API in ein dateibasiertes TDE-Wallet auf Oracle Database 12c Release 2 (12.2.0.1) schlägt fehl. Es kommt zu folgender Fehlermeldung:

[FATAL] [DBAAS-11014] – Erforderliche Patches (30128047) sind im Oracle-Standardverzeichnis nicht vorhanden <ORACLE_HOME>
AKTION: Spielen Sie die erforderlichen Patches (30128047) ein und wiederholen Sie den Vorgang.

Workaround: Migrieren Sie ein vom Kunden verwaltetes schlüsselbasiertes TDE-Wallet wie folgt in ein dateibasiertes TDE-Wallet:

1. Bestimmen Sie wie folgt, ob die Datenbank verschlüsselte UNDO- oder TEMP-Tablespaces in einer der autonomen Datenbanken oder in CDB$ROOT besitzt:
   Führen Sie die folgende Abfrage aus CDB$ROOT aus, um alle verschlüsselten Tablespaces aufzulisten, die in allen autonomen Datenbanken enthalten sind:

   SQL> select tstab.con_id, tstab.name from v$tablespace tstab, v$encrypted_tablespaces enctstab where tstab.ts# = enctstab.ts# and encryptedts = 'YES';

   Suchen Sie in der Spalte NAME des Ergebnisses der Abfrage nach den Namen der UNDO- und TEMP-Tablespaces. Wenn UNDO- oder TEMP-Tablespaces verschlüsselt sind, fahren Sie mit dem nächsten Schritt fort.

2. Heben Sie die Verschlüsselung von UNDO- oder TEMP-Tablespaces wie folgt auf:

   Wenn ein UNDO-Tablespace verschlüsselt ist

   Heben Sie wie folgt die Verschlüsselung vorhandener UNDO-Tablespaces auf:

   SQL> alter tablespace <undo_tablespace_name> encryption online decrypt;

   Wiederholen Sie diese Schritte für alle verschlüsselten UNDO-Tablespaces.

   Wenn ein TEMP-Tablespace verschlüsselt ist

   1. Prüfen Sie den Standard-TEMP-Tablespace wie folgt:

      SQL> select property_value from database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

      Wenn der Standard-TEMP-Tablespace nicht verschlüsselt ist, andere TEMP-Tablespaces jedoch verschlüsselt sind, löschen Sie die anderen TEMP-Tablespaces wie folgt:

      SQL> drop tablespace <temp_tablespace_name>;

      Überspringen Sie die restlichen Schritte in diesem Verfahren.

      Wenn der Standard-TEMP-Tablespace verschlüsselt ist, fahren Sie mit den restlichen Schritten fort, um einen unverschlüsselten Standard-TEMP-Tablespace zu erstellen und festzulegen.

   2. Legen Sie den Parameter encrypt_new_tablespaces wie folgt auf DDL fest:

      SQL> alter system set "encrypt_new_tablespaces" = DDL scope = memory;

   3. Erstellen Sie wie folgt einen TEMP-Tablespace mit den Spezifikationen des aktuellen TEMP-Tablespace:

      SQL> create temporary tablespace <temp_tablespace_name> TEMPFILE size 5000M;

   4. Legen Sie den neuen TEMP-Tablespace wie folgt als Standard-TEMP-Tablespace für die Datenbank fest:

      SQL> alter database default temporary tablespace <temp_tablespace_name>;

   5. Löschen Sie vorhandene TEMP-Tablespaces wie folgt:

      SQL> drop tablespace <temp_tablespace_name>;

   Wiederholen Sie diese Schritte für alle verschlüsselten TEMP-Tablespaces.

   Die Datenbank wird jetzt mit unverschlüsselten UNDO- und TEMP-Standard-Tablespaces ausgeführt. Die Verschlüsselung älterer TEMP- und UNDO-Tablespaces wird ebenfalls aufgehoben.

   Setzen Sie encrypt_new_tablespaces wie folgt auf den ursprünglichen Wert:

   SQL> alter system set "encrypt_new_tablespaces" = cloud_only;

   Fahren Sie mit der Keystore-Migration auf vom Kunden verwaltete Schlüssel fort.

3. Nachdem Sie überprüft haben, ob keine UNDO- oder TEMP-Tablespaces in einer der integrierbaren Datenbanken oder in CDB$ROOT verschlüsselt sind, überspringen Sie die Validierung des Patches für Bug 30128047 mit dem DBAASCLI-Utility mit dem Kennzeichen --skip_patch_check true. Stellen Sie sicher, dass Sie den Patch für Bug 29667994 im Oracle Home eingespielt haben, und führen Sie dann den folgenden dbaascli-Befehl aus:

   nohup /var/opt/oracle/dbaascli/dbaascli tde file_to_hsm --dbname <database_name> --kms_key_ocid <kms_key_ocid> --skip_patch_check true &

   Im vorherigen Befehl bezieht sich <kms_key_ocid> auf die OCID des vom Kunden verwalteten Schlüssels, den Sie verwenden.

Details: Wenn Sie den Lizenztyp Ihrer Datenbank oder Ihres DB-Systems von "BYOL" in "Lizenz inklusive" oder umgekehrt ändern, werden beide Lizenztypen für die erste Stunde in Rechnung gestellt. Danach wird entsprechend Ihrem aktualisierten Lizenztyp abgerechnet.

Workaround: Wir arbeiten an einer Lösung.

Direkter Link zu diesem Problem: Abrechnungsproblem bei Änderung des Lizenztyps

Details: Wenn Sie Ihr VCN mit einem Servicegateway konfigurieren, blockiert das private Subnetz den Zugriff auf die YUM-Repositorys, die zum Aktualisieren des Betriebssystems erforderlich sind. Dieses Problem betrifft alle DB-Systemtypen.

Workaround: Dieses Problem ist jetzt gelöst. Folgender Workaround wurde vor der Lösung des Problems empfohlen:

Das Servicegateway ermöglicht den Zugriff auf die Oracle YUM-Repositorys, wenn Sie unter Verfügbare Service-CIDR-Labels Alle <Region>-Services in Oracle Services Network verwenden. Allerdings können beim Zugriff auf die YUM-Services über das Servicegateway trotzdem noch Probleme auftreten. Es liegt eine Lösung für das Problem vor. Weitere Informationen finden Sie unter Probleme für Instanzen beim Zugriff auf Oracle Yum-Services über das Servicegateway.

Direkter Link zu diesem Problem: Servicegateway unterstützt derzeit keine BS-Updates

Details: Nicht verwaltete Backups in Object Storage über die Datenbank-CLI (dbcli) oder RMAN verlaufen mit den folgenden Fehlern nicht erfolgreich:

-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Aufgrund von Policys, die von zwei gängigen Webbrowsern in Bezug auf Symantec-Zertifikate implementiert wurden, hat Oracle vor Kurzem die Certificate Authority für Oracle Cloud Infrastructure geändert. Die daraus resultierende Änderung in SSL-Zertifikaten kann dazu führen, dass Backups in Object Storage nicht erfolgreich verlaufen, wenn das Oracle Database Cloud-Backupmodul weiterhin auf das alte Zertifikat verweist.

Workaround für dbcli: Prüfen Sie die Logdateien auf die aufgeführten Fehler, und aktualisieren Sie gegebenenfalls das Backupmodul.

Prüfen Sie die RMAN-Backuplogdateien auf die oben aufgeführten Fehler:

1. Bestimmen Sie die ID des nicht erfolgreichen Backupjobs.

   dbcli list-jobs

   In dieser Beispielausgabe lautet die ID des nicht erfolgreichen Backupjobs "f59d8470-6c37-49e4-a372-4788c984ea59".

   root@<node name> ~]# dbcli list-jobs
    
   ID                                       Description                                                                 Created                             Status
   ---------------------------------------- --------------------------------------------------------------------------- ----------------------------------- ----------
   cbe852de-c0f3-4807-85e8-7523647ec78c     Authentication key update for DCS_ADMIN                                     March 30, 2018 4:10:21 AM UTC       Success
   db83fdc4-5245-4307-88a7-178f8a0efa48     Provisioning service creation                                               March 30, 2018 4:12:01 AM UTC       Success
   c1511a7a-3c2e-4e42-9520-f156b1b4cf0e     SSH keys update                                                             March 30, 2018 4:48:24 AM UTC       Success
   22adf146-9779-4a2c-8682-7fd04d7520b2     SSH key delete                                                              March 30, 2018 4:50:02 AM UTC       Success
   6f2be750-9823-4ed5-b5ff-8e49f136dd22     create object store:bV0wqIaoLA4xLT4dGjOu                                    March 30, 2018 5:33:38 AM UTC       Success
   0716f464-1a10-40df-a303-cadee0302b1b     create backup config:bV0wqIaoLA4xLT4dGjOu_BC                                March 30, 2018 5:33:49 AM UTC       Success
   e08b21c3-cd09-4e3a-944c-d1da96cb21d8     update database : hfdb1                                                     March 30, 2018 5:34:04 AM UTC       Success
   1c3d7c58-79c3-4039-8f48-787057ce7c6e     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:37:11 AM UTC       Success
   f59d8470-6c37-49e4-a372-4788c984ea59     Create Longterm Backup with TAG-DBTLongterm<identity number> for Db:<dbname>    March 30, 2018 5:43:45 AM UTC       Failure

2. Ermitteln Sie anhand der ID des nicht erfolgreichen Jobs den Speicherort der zu prüfenden Logdatei.

   
   dbcli describe-job -i <failed_job_ID>

   Eine relevante Ausgabe des Befehls describe-job sollte wie folgt aussehen:

   Message: DCS-10001:Internal error encountered: Failed to run Rman statement.
   Refer log in Node <node_name>: /opt/oracle/dcs/log/<node_name>/rman/bkup/<db_unique_name>/rman_backup/<date>/rman_backup_<date>.log.

Aktualisieren Sie das Oracle Database Cloud-Backupmodul:

1. Ermitteln Sie die Swift-Objektspeicher-ID und den Benutzer, den die Datenbank für Backups verwendet.

   1. Führen Sie den Befehl dbcli list-databases aus, um die ID der Datenbank zu bestimmen.

   2. Verwenden Sie die Datenbank-ID, um die Backupkonfigurations-ID (backupConfigId) zu bestimmen.

      dbcli list-databases
      dbcli describe-database -i <database_ID> -j

   3. Ermitteln Sie anhand der Backupkonfigurations-ID, die Sie im vorherigen Schritt notiert haben, die Objektspeicher-ID (objectStoreId).

      dbcli list-backupconfigs
      dbcli describe-backupconfig –i <backupconfig_ID> -j

   4. Ermitteln Sie anhand der Objektspeicher-ID, die Sie im vorherigen Schritt notiert haben, den Objektspeicherbenutzer (userName).

      dbcli list-objectstoreswifts
      dbcli describe-objectstoreswift –i <objectstore_ID> -j

2. Aktualisieren Sie das Backupmodul mithilfe der Zugangsdaten des Objektspeichers, die Sie in Schritt 1 erhalten haben.

   dbcli update-objectstoreswift –i <objectstore_ID> -p –u <user_name>

Workaround für RMAN: Prüfen Sie die RMAN-Logdateien auf die aufgeführten Fehlermeldungen. Wenn Sie sie gefunden haben, melden Sie sich beim Host als Oracle-Benutzer ("oracle") an, und verwenden Sie Ihre Swift-Zugangsdaten, um das Backupmodul neu zu installieren.

java -jar <opc_install.jar_path> -opcId '<swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

Bei einem DB-System mit mehreren Knoten können Sie den Workaround für alle Knoten im Cluster anwenden.

Weitere Informationen zur Verwendung dieses Befehls finden Sie in der Dokumentation zum Oracle Database Cloud-Backupmodul.

Direkter Link zu diesem Problem: Backup in Object Storage mit dbcli oder RMAN verläuft wegen Zertifikatsänderung nicht erfolgreich

Details: In den SDKs, die am 18. Oktober 2018 veröffentlicht wurden, werden bedeutende Änderungen an der Datenbankgröße und den Datenbankeditionsattributen in den Datenbankbackup-APIs eingeführt.

Workaround: In der folgenden sprachspezifischen Dokumentation finden Sie weitere Informationen zu den wichtigen Änderungen. Aktualisieren Sie gegebenenfalls Ihren vorhandenen Code:

Direkter Link zu diesem Problem: Wichtige Änderungen bei Datenbankservice-SDKs

Details: Backup- und Restore-Vorgänge können möglicherweise nicht in Ihrem DB-System ausgeführt werden, wenn Sie die Konsole oder die API verwenden.

Workaround: Installieren Sie das Oracle Database Cloud-Backupmodul, und wenden Sie sich für weitere Anweisungen an Oracle Support Services.

So installieren Sie das Oracle Database Cloud-Backupmodul:

1. Stellen Sie mit SSH eine Verbindung zum DB-System her, und melden sich als "opc" an.

   
   ssh -i <SSH_key> opc@<DB_system_IP address>
   login as: opc

   Alternativ können Sie opc@<DB_system_hostname> zur Anmeldung verwenden.

2. Laden Sie das Oracle Database Cloud-Backupmodul von http://www.oracle.com/technetwork/database/availability/oracle-cloud-backup-2162729.html herunter.
3. Extrahieren Sie den Inhalt von opc_installer.zip in ein Zielverzeichnis, z.B. /home/opc.
4. Erstellen Sie in Ihrem Mandanten einen temporären Benutzer, und erteilen Sie ihm Berechtigungen für den Zugriff auf den Objektspeicher des Mandanten.
5. Erstellen Sie für diesen temporären Benutzer ein Authentifizierungstoken, und notieren Sie sich das Kennwort.

6. Verifizieren Sie die Zugangsdaten, indem Sie den folgenden curl-Befehl ausführen:

   Hinweis
   
   Swift-Kennwörter werden jetzt als "Authentifizierungstoken" bezeichnet. Weitere Informationen finden Sie unter Authentifizierungstoken mit Swift verwenden.

   curl -v -X HEAD -u  <user_id>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

   Informationen zur richtigen Region finden Sie unter https://cloud.oracle.com/infrastructure/storage/object-storage/faq.

   Der Befehl sollte entweder den Antwortcode für Erfolgsstatus HTTP 200 oder HTTP 204 No Content zurückgeben. Jeder andere Statuscode gibt ein Problem beim Herstellen der Verbindung mit Object Storage an.

7. Führen Sie den folgenden Befehl aus:

   java -jar opc_install.jar -opcid <user_id> -opcPass '<auth_token>' -libDir <target_dir> -walletDir <target_dir> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -configFile config.txt

   Hinweis: <target_dir> ist das Verzeichnis, in das Sie opc_installer.zip in Schritt 3 extrahiert haben.

   Die Ausführung dieses Befehls kann einige Minuten dauern, da er libopc.so und weitere Dateien herunterlädt. Nach Abschluss des Befehls sollten mehrere Dateien (einschließlich libopc.so) in Ihrem Zielverzeichnis angezeigt werden.

8. Wechseln Sie in das Zielverzeichnis, und kopieren Sie die Dateien lipopc.so und opc_install.jar in das Verzeichnis /opt/oracle/oak/pkgrepos/oss/odbcs.

   cp libopc.so /opt/oracle/oak/pkgrepos/oss/odbcs

   
   
   cp opc_install.jar /opt/oracle/oak/pkgrepos/oss/odbcs

   (Möglicherweise müssen Sie "sudo" mit den Kopierbefehlen verwenden, um sie als Root auszuführen.)

9. Führen Sie den folgenden Befehl aus, um zu prüfen, ob das angegebene Verzeichnis vorhanden ist:

   
   
   ls /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

   Wenn dieses Verzeichnis vorhanden ist, führen Sie die folgenden Schritte aus:

   1. Sichern Sie die Dateien im Verzeichnis /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs.

   2. Führen Sie diese beiden Befehle aus, um die vorhandenen Dateien libopc.so und opc_install.jar in diesem Verzeichnis zu ersetzen:

      
      cp libopc.so /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs
      cp opc_install.jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs

10. Prüfen Sie die Version von opc_install.jar.

    
    java -jar /opt/oracle/oak/pkgrepos/oss/odbcs/opc_install.jar |grep -i build
    

    Wenn /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs vorhanden ist, führen Sie auch den folgenden Befehl aus:

    
    java -jar /opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/opc_install.jar |grep -i build

    Beide Befehle sollten die folgende Ausgabe zurückgeben:

    Oracle Database Cloud Backup Module Install Tool, build MAIN_2017-08-16.

11. (Optional) Löschen Sie den temporären Benutzer und das Zielverzeichnis, die Sie zum Installieren des Backupmoduls verwendet haben.

Nachdem Sie die Prozedur abgeschlossen haben, wenden Sie sich an Oracle Support oder den Mandantenadministrator, um weitere Anweisungen zu erhalten. Sie müssen die OCID des DB-Systems angeben, für das Sie Backups aktivieren möchten.

Direkter Link zu diesem Problem: In Ihrem DB-System können keine verwalteten Backups verwendet werden

Details: Die Speicherbeschränkungen von Hostrechnern, auf denen die VM.Standard1.1-Ausprägung ausgeführt wird, können zu Fehlern bei automatischen Datenbankbackupjobs führen, die von Oracle Cloud Infrastructure verwaltet werden (Jobs, die mit der Konsole oder der API verwaltet werden). Sie können die Arbeitsspeicherparameter des Systems ändern, um dieses Problem zu lösen.

Workaround: Ändern Sie die Arbeitsspeicherparameter des Systems wie folgt:

1. Wechseln Sie im Betriebssystem zum Oracle-Benutzer ("oracle").

   [opc@hostname ~]$ sudo su - oracle

2. Legen Sie die Umgebungsvariable für die Anmeldung bei der Datenbankinstanz fest. Beispiel:

   
   [oracle@hostname ~]$ . oraenv
    ORACLE_SID = [oracle] ? orcl
   				

3. Starten Sie SQL*Plus.

   [oracle@hostname ~]$ sqlplus / as sysdba

4. Ändern Sie die anfänglichen Arbeitsspeicherparameter wie folgt:

   
   SQL> ALTER SYSTEM SET SGA_TARGET = 1228M scope=spfile;
   SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 1228M;
   SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 2457M;
   SQL> exit
   							

5. Starten Sie die Datenbankinstanz neu.

   
   [oracle@hostname ~]$ srvctl stop database -d db_unique_name -o immediate
   [oracle@hostname ~]$ srvctl start database -d db_unique_name -o open								

Direkter Link zu diesem Problem: Verwaltete automatische Backups sind für die VM.Standard1.1-Ausprägung wegen eines Prozessabsturzes nicht erfolgreich

Details: Bei High Performance- und Extreme Performance-DB-Systemen verlaufen die Vorgänge des Data Pump-Utilitys, die Komprimierung und/oder Parallelität verwenden, möglicherweise nicht erfolgreich und geben den Fehler ORA-00439: Feature nicht aktiviert zurück. Dieses Problem betrifft die Datenbankversionen 12.1.0.2.161018 und 12.1.0.2.170117.

Workaround: Spielen Sie den Patch 25579568 oder 25891266 in die Oracle Database Homes für die Datenbankversion 12.1.0.2.161018 bzw. 12.1.0.2.170117 ein. Alternativ können Sie die Konsole verwenden, um den Patch von April 2017 in das DB-System und das Datenbank-Home einzuspielen.

Direkter Link zu diesem Problem: Oracle Data Pump-Vorgänge geben "ORA-00439: Feature nicht aktiviert" zurück

Details: Sie erhalten möglicherweise eine Fehlermeldung wie "Sichere Verbindung konnte nicht hergestellt werden", wenn Sie versuchen, eine Verbindung von Ihrem DB-System mit 1 Knoten zur EM Express-Konsole herzustellen, da die richtigen Berechtigungen nicht automatisch angewendet wurden.

Workaround: Fügen Sie Leseberechtigungen für die asmadmin-Gruppe im Wallet-Verzeichnis des DB-Systems hinzu, und wiederholen Sie den Verbindungsvorgang:

1. Stellen Sie mit SSH eine Verbindung zum DB-Systemhost her, melden Sie sich als "opc" an, und wechseln Sie mit "sudo" zum Grid-Benutzer.

   [opc@dbsysHost ~]$ sudo su - grid
   [grid@dbsysHost ~]$ . oraenv
   ORACLE_SID = [+ASM1] ?
   The Oracle base has been set to /u01/app/grid
   

2. Rufen Sie den Speicherort des Wallet-Verzeichnisses ab, der unten in der Befehlsausgabe rot dargestellt ist.

   [grid@dbsysHost ~]$ lsnrctl status | grep xdb_wallet
   
   (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=dbsysHost.sub04061528182.dbsysapril6.oraclevcn.com)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet))(Presentation=HTTP)(Session=RAW))

3. Kehren Sie zum Benutzer "opc" zurück, wechseln Sie zum Benutzer "oracle", und wechseln Sie dann zum Wallet-Verzeichnis.

   [opc@dbsysHost ~]$ sudo su - oracle
   [oracle@dbsysHost ~]$ cd /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet

4. Listen Sie den Verzeichnisinhalt auf, und notieren Sie die Berechtigungen.

   
   [oracle@dbsysHost xdb_wallet]$ ls -ltr
   total 8
   -rw------- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
   -rw------- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
   

5. Ändern Sie die Berechtigungen:

   
   [oracle@dbsysHost xdb_wallet]$ chmod 640 /u01/app/oracle/admin/dbsys12_phx3wm/xdb_wallet/*

6. Prüfen Sie, ob Leseberechtigungen hinzugefügt wurden.

   [oracle@dbsysHost xdb_wallet]$ ls -ltr
   total 8
   -rw-r----- 1 oracle asmadmin 3881 Apr  6 16:32 ewallet.p12
   -rw-r----- 1 oracle asmadmin 3926 Apr  6 16:32 cwallet.sso
   

Direkter Link zu diesem Problem: Verbindung vom DB-System mit 1 Knoten zur EM Express-Konsole kann nicht hergestellt werden

Details: Backupvorgänge in Object Storage mit dem Exadata-Backuputility (bkup_api) oder RMAN sind mit den folgenden Fehlern nicht erfolgreich:

* DBaaS Error trace:
-> API::ERROR -> KBHS-00715: HTTP error occurred 'oracle-error'
-> API::ERROR -> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> API::ERROR -> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> API::ERROR -> ORA-27023: skgfqsbi: media manager protocol error
-> API::ERROR Unable to verify the backup pieces
-> Oracle Error Codes found:
-> ORA-19554: error allocating device, device type: SBT_TAPE, device name:
-> ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
-> KBHS-00712: ORA-29024 received from local HTTP service
-> ORA-27023: skgfqsbi: media manager protocol error

Aufgrund von Policys, die von zwei gängigen Webbrowsern in Bezug auf Symantec-Zertifikate implementiert wurden, hat Oracle vor Kurzem die Certificate Authority für Oracle Cloud Infrastructure geändert. Die daraus resultierende Änderung in SSL-Zertifikaten kann dazu führen, dass Backups in Object Storage nicht erfolgreich verlaufen, wenn das Oracle Database Cloud-Backupmodul weiterhin auf das alte Zertifikat verweist.

Workaround für bkup_api: Prüfen Sie die Logdateien auf die oben aufgeführten Fehler, und installieren Sie gegebenenfalls das Backupmodul neu.

Verwenden Sie den folgenden Befehl, um den Status des nicht erfolgreichen Backups zu prüfen:

/var/opt/oracle/bkup_api/bkup_api bkup_status --dbname=<database_name>

Führen Sie den folgenden Befehl aus, um das Backupmodul neu zu installieren:

/var/opt/oracle/ocde/assistants/bkup/bkup -dbname=<database_name>

Workaround für RMAN: Prüfen Sie die RMAN-Logdateien auf die aufgeführten Fehlermeldungen. Wenn Sie sie gefunden haben, melden Sie sich beim Host als Oracle-Benutzer ("oracle") an, und installieren Sie das Backupmodul mit den Swift-Zugangsdaten neu.

java -jar <opc_install.jar_path> -opcId '<Swift_user_ID>' -opcPass '<auth_token>' -container <objectstore_container> -walletDir <wallet_directory> -configfile <config_file> -host https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace> -import-all-trustcerts

Führen Sie diesen Workaround auf allen Knoten im Cluster aus.

Weitere Informationen zur Verwendung dieses Befehls finden Sie in der Dokumentation zum Oracle Database Cloud-Backupmodul.

Direkter Link zu diesem Problem: Backup in Object Storage mit bkup_api oder RMAN verläuft wegen Zertifikatänderung nicht erfolgreich

Details: Mit der Einführung gemeinsam verwendeter Datenbank-Homes für Exadata-DB-Systeme werden in der Konsole jetzt auch Informationen zu Datenbanken synchronisiert und angezeigt, die mit den Utilitys dbaasapi und dbaascli erstellt und verwaltet werden. Bei Datenbanken, für die Data Guard konfiguriert ist, werden unter folgenden Bedingungen jedoch nicht die korrekten Informationen in der Konsole angezeigt:

• Wenn Data Guard mit der Konsole aktiviert wurde und mit dbaascli eine Änderung an der Primär- oder Standbydatenbank vorgenommen wird (z.B. Verschieben der Datenbank in ein anderes Home), wird das Ergebnis in der Konsole nicht berücksichtigt.
• Wenn Data Guard manuell konfiguriert wurde, wird in der Konsole keine Data Guard-Verknüpfung zwischen den beiden Datenbanken angezeigt.

Workaround: Das Problem ist uns bekannt, und wir arbeiten an einer Lösung. Bis auf Weiteres empfiehlt Oracle, Datenbanken mit aktiviertem Data Guard entweder nur mit der Konsole oder nur mit Befehlszeilenutilitys zu verwalten.

Direkter Link zu diesem Problem: Konsoleninformationen für Datenbanken mit aktiviertem Data Guard werden bei Verwendung von dbaascli nicht synchronisiert

Details: Dies ist ein Clusterware-Problem, das nur auftritt, wenn die Oracle GI-Version 12.2.0.1 ohne Bundle-Patch ist. Das Problem wird durch die Beschädigung einer Voting Disk verursacht, nachdem Sie den Datenträger offline und wieder online gesetzt haben.

Workaround: Bestimmen Sie die GI-Version, und ermitteln Sie, ob die Voting Disk beschädigt ist. Reparieren Sie den Datenträger gegebenenfalls, und spielen Sie dann das neueste GI-Bundle ein.

1. Prüfen Sie, ob die GI-Version 12.2.0.1 ist und ob ein Bundle-Patch eingespielt wurde:

   
   [root@rmstest-udaau1 ~]# su - grid
   [grid@rmstest-udaau1 ~]$ . oraenv
   ORACLE_SID = [+ASM1] ? +ASM1
   The Oracle base has been set to /u01/app/grid
   [grid@rmstest-udaau1 ~]$ $ORACLE_HOME/OPatch/opatch lsinventory
   Oracle Interim Patch Installer version 12.2.0.1.6
   Copyright (c) 2018, Oracle Corporation.  All rights reserved.
   
   
   Oracle Home       : /u01/app/12.2.0.1/grid
   Central Inventory : /u01/app/oraInventory
      from           : /u01/app/12.2.0.1/grid/oraInst.loc
   OPatch version    : 12.2.0.1.6
   OUI version       : 12.2.0.1.4
   Log file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/opatch2018-01-15_22-11-10PM_1.log
   
   Lsinventory Output file location : /u01/app/12.2.0.1/grid/cfgtoollogs/opatch/lsinv/lsinventory2018-01-15_22-11-10PM.txt
   
   --------------------------------------------------------------------------------
   Local Machine Information::
   Hostname: rmstest-udaau1.exaagclient.sretest.oraclevcn.com
   ARU platform id: 226
   ARU platform description:: Linux x86-64
   
   Installed Top-level Products (1):
   
   Oracle Grid Infrastructure 12c                                       12.2.0.1.0
   There are 1 products installed in this Oracle Home.
   
   
   There are no Interim patches installed in this Oracle Home.
   
   
   --------------------------------------------------------------------------------
   
   OPatch succeeded.

2. Prüfen Sie die Datei /u01/app/grid/diag/crs/<Hostname>/crs/trace/ocssd.trc auf Hinweise, dass GI aufgrund einer Beschädigung der Voting Disk nicht gestartet werden konnte:

   ocssd.trc
    
   2017-01-17 23:45:11.955 :    CSSD:3807860480: clssnmvDiskCheck:: configured 
   Sites = 1, Incative sites = 1, Mininum Sites required = 1 
   2017-01-17 23:45:11.955 :    CSSD:3807860480: (:CSSNM00018:)clssnmvDiskCheck: 
   Aborting, 2 of 5 configured voting disks available, need 3 
   ...... 
   . 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmCheckForNetworkFailure: 
   skipping 31 defined 0 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssnmRemoveNodeInTerm: node 4, 
   slcc05db08 terminated. Removing from its own member and connected bitmaps 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: 
   ################################### 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: clssscExit: CSSD aborting from 
   thread clssnmvDiskPingMonitorThread 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: 
   ################################### 
   2017-01-17 23:45:11.956 :    CSSD:3807860480: (:CSSSC00012:)clssscExit: A 
   fatal error occurred and the CSS daemon is terminating abnormally 
    
   ------------
    
   2017-01-19 19:00:32.689 :    CSSD:3469420288: clssnmFindVF: Duplicate voting disk found in the queue of previously configured disks 
   queued(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009 
   cbd]), 
   found(o/192.168.10.18/PCW_CD_02_slcc05cel10|[66223efc-29254fbb-bf901601-21009c 
   bd]), is not corrupted 
   2017-01-19 19:01:06.467 :    CSSD:3452057344: clssnmvVoteDiskValidation: 
   Voting disk(o/192.168.10.19/PCW_CD_02_slcc05cel11) is corrupted

3. Sie können auch mit SQL*Plus prüfen, ob die Voting Disks beschädigt sind:

   1. Melden Sie sich als Grid-Benutzer ("grid") an, und setzen Sie die Umgebung auf ASM.

      [root@rmstest-udaau1 ~]# su - grid
      [grid@rmstest-udaau1 ~]$ . oraenv
      ORACLE_SID = [+ASM1] ? +ASM1
      The Oracle base has been set to /u01/app/grid

   2. Melden Sie sich bei SQL*Plus als SYSASM an.

      $ORACLE_HOME/bin/sqlplus / as sysasm

   3. Führen Sie folgenden beiden Abfragen aus:

      SQL> select name, voting_file from v$asm_disk where VOTING_FILE='Y' and group_number !=0;
      SQL> select  CC.name, count(*) from x$kfdat AA JOIN (select disk_number, name from v$asm_disk where VOTING_FILE='Y' and group_number !=0) CC ON CC.disk_number = AA.NUMBER_KFDAT where AA.FNUM_KFDAT= 1048572 group by CC.name;

      Wenn das System fehlerfrei ist, sollten die Ergebnisse wie im folgenden Beispiel aussehen.

      Ergebnisse Abfrage 1

      NAME                           VOTING_FILE
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        Y
      DBFSC3_CD_09_SLCLCX0787        Y
      DBFSC3_CD_04_SLCLCX0786        Y

      Ergebnisse Abfrage 2

      NAME                           COUNT(*)
      ------------------------------ ---------------
      DBFSC3_CD_02_SLCLCX0788        8
      DBFSC3_CD_09_SLCLCX0787        8
      DBFSC3_CD_04_SLCLCX0786        8

      In einem fehlerfreien System muss jede Voting Disk, die in der ersten Abfrage zurückgegeben wird, auch in der zweiten Abfrage zurückgegeben werden. Die Anzahl für alle Datenträger muss ungleich Null sein. Andernfalls ist mindestens eine Ihrer Voting Disks beschädigt.

4. Wenn eine Voting Disk beschädigt ist, setzen Sie die Grid Disk mit der Voting Disk offline. Die Cells verschieben die fehlerhafte Voting Disk automatisch auf die andere Grid Disk und setzen diese Voting Disk online.

   1. Der folgende Befehl setzt eine Grid Disk mit dem Namen DATAC01_CD_05_SCAQAE08CELADM13 offline.

      SQL> alter diskgroup DATAC01 offline disk DATAC01_CD_05_SCAQAE08CELADM13;
           Diskgroup altered.

   2. Warten Sie 30 Sekunden, und führen Sie dann die beiden Abfragen in Schritt 3c erneut aus, um zu prüfen, ob die Voting Disk auf die neue Grid Disk migriert wurde und ob sie fehlerfrei ist.

   3. Stellen Sie sicher, dass die Grid Disk, die Sie offline gesetzt haben, jetzt online ist:

      SQL> select name, mode_status, voting_file from v$asm_disk where name='DATAC01_CD_05_SCAQAE08CELADM13';

      mode_status muss ONLINE sein, und voting_file darf NICHT Y sein.

   Wiederholen Sie die Schritte 4a bis 4c für jede verbleibende Grid Disk, die eine beschädigte Voting Disk enthält.

   Hinweis
   
   

   Wenn das CRS wegen einer Beschädigung der Voting Disk nicht gestartet wird, starten Sie es im Exclusive-Modus, bevor Sie den Befehl in Schritt 4 ausführen.

   crsctl start crs -excl

    

5. Wenn Sie die Oracle GI-Version 12.2.0.1 ohne Bundle-Patch verwenden, müssen Sie die GI-Version auf das aktuelle GI-Bundle upgraden, unabhängig davon, ob eine Voting Disk beschädigt wurde.

   Anweisungen zur Verwendung des dbaascli-Utilitys zum Patchen von Oracle Grid Infrastructure und Oracle Database auf Oracle Exadata Database Service on Dedicated Infrastructure finden Sie unter Oracle Grid Infrastructure und Oracle-Datenbanken mit dbaascli patchen.

Direkter Link zu diesem Problem: Grid Infrastructure wird nicht gestartet, nachdem ein Datenträger offline und online gesetzt wurde

Details: Exadata-DB-Systeme, die am 15. Juni 2018 oder später gestartet wurden, umfassen automatisch die Möglichkeit, Datenbanken mit der Konsole, der API oder der Oracle Cloud Infrastructure-CLI zu erstellen, aufzulisten und zu löschen. Für Systeme, die vor diesem Datum bereitgestellt wurden, sind zusätzliche Schritte erforderlich, um diese Funktionalität zu aktivieren.

Versuche, diese Funktionalität ohne die zusätzlichen Schritte zu verwenden, führen zu folgenden Fehlermeldungen:

• Beim Erstellen einer Datenbank: "Datenbank erstellen wird auf diesem Exadata-DB-System nicht unterstützt. Um dieses Feature zu aktivieren, wenden Sie sich an Oracle Support."
• Beim Beenden einer Datenbank: "DeleteDbHome wird auf diesem Exadata-DB-System nicht unterstützt. Um dieses Feature zu aktivieren, wenden Sie sich an Oracle Support."

Workaround: Sie müssen den Exadata-Agent auf jedem Knoten des Exadata-DB-Systems installieren.

Erstellen Sie zunächst eine Serviceanforderung für Unterstützung durch Oracle Support Services. In der Antwort von Oracle Support erhalten Sie eine vorab authentifizierte URL für einen Oracle Cloud Infrastructure Object Storage-Speicherort, in dem Sie den Agent abrufen können.

Bevor Sie den Exadata-Agent installieren, führen Sie folgende Schritte aus:

• Führen Sie auf allen Knoten des Exadata DB-Systems ein Upgrade des Toolings (dbaastools rpm) auf die neueste Version aus. SieheTooling auf einer Exadata Cloud Service-Instanz aktualisieren.
• Stellen Sie sicher, dass das System für den Zugriff auf Oracle Cloud Infrastructure Object Storage mit den erforderlichen Sicherheitslisten für die Region konfiguriert ist, in der das DB-System erstellt wurde. Weitere Informationen zur Konnektivität mit Oracle Cloud Infrastructure Object Storage finden Sie unter Voraussetzungen für Backups auf Exadata Cloud Service.

So installieren Sie den Exadata-Agent:

1. Melden Sie sich beim Knoten als "root" an.

2. Führen Sie die folgenden Befehle aus, um den Agent zu installieren:

   [root@<node_n>~]# cd /tmp
   [root@<node_n>~]# wget https://objectstorage.<region_name>.oraclecloud.com/p/1q523eOkAOYBJVP9RYji3V5APlMFHIv1_6bAMmxsS4E/n/dbaaspatchstore/b/dbaasexadatacustomersea1/o/backfill_agent_package_iwwva.tar
   [root@<node_n>~]# tar -xvf /tmp/backfill_agent_package_*.tar -C /tmp
   [root@<node_n>~]# rpm -ivh /tmp/dbcs-agent-2.5-3.x86_64.rpm

   Beispielausgabe:

   [root@<node_n>~]# rpm -ivh dbcs-agent-2.5-3.x86_64.rpm
   Preparing...                ########################################### [100%]
   Checking for dbaastools_exa rpm on the system
   Current dbaastools_exa version = dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64
   dbaastools_exa version dbaastools_exa-1.0-1+18.1.4.1.0_180725.0000.x86_64 is good. Continuing with dbcs-agent installation
      1:dbcs-agent             ########################################### [100%]
   initctl: Unknown instance:
   initctl: Unknown instance:
   initzookeeper start/running, process 85821
   initdbcsagent stop/waiting
   initdbcsadmin stop/waiting
   initdbcsagent start/running, process 85833
   initdbcsadmin start/running, process 85836
   

3. Stellen Sie sicher, dass der Agent installiert wurde und ausgeführt wird.

   [root@<node_n>~]# rpm -qa | grep dbcs-agent
   dbcs-agent-2.5-0.x86_64
   [root@<node_n>~]# initctl status initdbcsagent
   initdbcsagent start/running, process 97832

4. Wiederholen Sie die Schritte 1 bis 3 für die restlichen Knoten.

Nachdem der Agent auf allen Knoten installiert wurde, kann Oracle bis zu 30 Minuten lang weitere Workflowaufgaben ausführen, z.B. ein Upgrade des Agent auf die neueste Version, das Rotieren der Agent-Zugangsdaten usw. Wenn der Prozess abgeschlossen ist, sollten Sie die von Exadata verwalteten Features in der Konsole, der API oder der Oracle Cloud Infrastructure-CLI verwenden können.

Direkter Link zu diesem Problem: Verwaltete Features für Systeme, die vor dem 15. Juni 2018 bereitgestellt wurden, sind nicht aktiviert

Details: Die Patching-Konfigurationsdatei (/var/opt/oracle/exapatch/exadbcpatch.cfg) verweist auf den Objektspeicher der Region us-phoenix-1, selbst wenn das Exadata-DB-System in einer anderen Region bereitgestellt wurde.

Dieses Problem tritt auf, wenn die Releaseversion des Datenbank-Tooling-Packages (dbaastools_exa) 17430 oder niedriger ist.

Workaround: Befolgen Sie die Anweisungen unter Tooling auf einer Exadata Cloud Service-Instanz aktualisieren, um sicherzustellen, dass die Releaseversion des Tooling-Packages 17430 oder niedriger ist. Aktualisieren Sie sie anschließend auf die neueste Version.

Direkter Link zu diesem Problem: Patching-Konfigurationsdatei verweist auf die falsche Region

Details: Eine Änderung dahingehend, wie Oracle Linux 7 temporäre Dateien verarbeitet, kann dazu führen, dass erforderliche Socket-Dateien aus dem Verzeichnis /var/tmp/.oracle entfernt werden. Dieses Problem betrifft nur Exadata-DB-Systeme, auf denen das Betriebssystemimage der Version 19.1.2 ausgeführt wird.

Workaround: Führen Sie sudo /usr/local/bin/imageinfo als OPC-Benutzer ("opc") aus, um die Imageversion Ihres Betriebssystems zu bestimmen. Wenn Ihre Imageversion 19.1.2.0.0.190306 lautet, befolgen Sie die Anweisungen unter Dok-ID 2498572.1, um das Problem zu beheben.

Direkter Link zu diesem Problem: Verschiedene Datenbankworkflowfehler aufgrund der Entfernung von erforderlichen temporären Dateien unter Oracle Linux 7

Details: Wenn Sie DR-Vorgänge für Berechnung und Speicherung innerhalb derselben Region über verschiedene ADs hinweg ausführen und dabei Volume-Gruppenbackups verwenden, führen vor- und zurückgehende DR-Übergänge dazu, dass der Rechenspeicher und der zugehörige Blockspeicher (der Volume-Gruppenbackups verwendet) jedes Mal in einer anderen AD platziert werden.

Workaround: Dieses Problem wirkt sich nicht auf den Blockspeicher aus, der mit der Volume-Gruppenreplikation repliziert wird.

Details: Die Einstellungen der automatischen Performanceoptimierung für Blockspeicher-Volumes werden während DR-Vorgängen nicht übernommen.

Workaround: Bei Blockspeicher-Volumes mit aktivierter automatischer Performanceoptimierung müssen Sie diese Einstellungen erneut aktivieren, nachdem Full Stack DR diese Blockspeicher-Volumes in eine andere Region überführt hat.

Details: Wenn Sie einen Failover-Vorgang unmittelbar nach Änderung einer mit Full Stack-DR geschützten Ressource ausführen, verläuft das Ressourcen-Recovery möglicherweise nicht erfolgreich, oder die Ressource wird möglicherweise nicht ordnungsgemäß wiederhergestellt. Beispiel: Wenn Sie das Replikationsziel oder andere Eigenschaften für eine Volumegruppe ändern, die Sie einer DR-Schutzgruppe hinzugefügt haben, und die primäre Region danach sofort ausfällt, erkennt Full Stack DR möglicherweise nicht die Änderungen, die Sie an den Replikationseinstellungen der Volumegruppe vorgenommen haben. Dies wirkt sich auf das Recovery dieser Volumegruppe aus.

Workaround: Führen Sie eine Switchover-Vorabprüfung aus, nachdem Sie Änderungen an Ressourcen unter DR-Schutz vorgenommen haben.

Details: Full Stack DR verwendet das Utility Befehl ausführen von Oracle Cloud Agent (OCA), um lokale Skripte auf Instanzen auszuführen. Wenn Sie einen benutzerdefinierten Schritt konfigurieren, um ein lokales Skript auf einer Microsoft Windows-Instanz auszuführen, können Sie das Feature "Full Stack-DR als Benutzer ausführen" nicht verwenden, mit der Sie eine andere Benutzer-ID angeben können, um auf Instanzen gespeicherte lokale Skripte auszuführen.

Workaround: Bei Microsoft Windows-Instanzen kann das Skript nur als Standard-Benutzer-ID ocarun ausgeführt werden, die vom Oracle Cloud Agent-Utility-Ausführungsbefehl verwendet wird. Diese Einschränkung wirkt sich nicht auf Oracle Linux-Instanzen aus.

Details: Full Stack DR verwendet das Utility Befehl ausführen von Oracle Cloud Agent (OCA), um lokale Skripte auf Instanzen auszuführen. Standardmäßig werden alle Schritte als Benutzer ocarun ausgeführt.

Workaround: Auf einer Microsoft Windows-Instanz müssen alle lokalen Skripte, die Sie für die Ausführung als benutzerdefinierten Schritt in einem DR-Plan konfigurieren, für diese Benutzer-ID ocarun zugänglich und ausführbar sein.

Details: Wenn Sie ein lokales Skript mit einem benutzerdefinierten Schritt in einem DR-Plan ausführen, wenn Sie keine vollständigen Pfade zu Skript-Dolmetschern oder Skripts angeben, löst Full Stack DR Fehler aus.

Workaround: Wenn Sie einen benutzerdefinierten Schritt in einem DR-Plan konfigurieren, um ein lokales Skript auszuführen, das sich auf einer Instanz befindet, stellen Sie sicher, dass Sie den vollständigen Pfad zu jedem Interpreter angeben, der dem Skriptnamen vorangestellt werden kann, sowie den vollständigen Pfad zum Skript.

Details: Während DR-Operationen versucht Full Stack DR, die ursprüngliche private IP einer Instanz neu zuzuweisen, wenn der CIDR-Block des Zielsubnetzes mit dem CIDR-Block des Quellsubnetzes übereinstimmt und die ursprüngliche private IP der Instanz noch nicht zugewiesen ist.

Wenn Sie Full Stack DR verwenden, um alle Knoten in einem OCFS2-Cluster zu verschieben, und die private IP für einen der Cluster-Knoten kann nicht neu zugewiesen werden, werden diese Cluster-Knoten vom OCFS2-Cluster getrennt, nachdem die Knoten in der Standbyregion gestartet wurden.

Workaround: Stellen Sie sicher, dass der CIDR-Block des Zielsubnetzes mit dem CIDR-Block des Quellsubnetzes übereinstimmt und alle für Clusterknoten erforderlichen privaten IP-Adressen im Zielsubnetz verfügbar sind.

Details: Nachdem der Full Stack-DR eine Instanz in einer anderen Region gespeichert hat, kann die Ressourcenseite der Instanz die folgende Meldung für den Instanzzugriff anzeigen:

Wir sind nicht sicher, wie wir eine Verbindung zu einer Instanz herstellen können, die dieses Image verwendet

Workaround: Ignorieren Sie diese Meldung. SSH-Verbindungen zur Instanz funktionieren normal, wenn Sie die ursprüngliche SSH-Schlüsseldatei zur Verbindung und Authentifizierung der Instanz verwenden.

Details: Nachdem die Full Stack-DR-Instanz in eine andere Region verschoben wurde, werden auf der Ressourcenseite der Instanz möglicherweise falsche Informationen für den Imageteil des Boot-Volumes angezeigt.

Beispiel: In der Spalte "Imageinformationen" kann die folgende Meldung angezeigt werden: Fehler beim Laden von Daten

Workaround: Diese Fehlermeldung betrifft die Anzeige des Imagenamens, hat jedoch keine Auswirkungen auf den Vorgang der Instanz oder des zugehörigen Boot-Volumes.

Details: Wenn keine Ruhezeit für den Befehl nohup vorhanden ist, kann der Befehl run nicht ausgeführt werden und kann den Status nicht erfolgreich melden.

nohup sh enabler.sh  &> enabler.log &
sleep 10
exit 0

Details: Wenn die Block-Volumes während eines DR-Übergangs in eine andere Region verschoben werden, werden die Performanceeinstellungen (IOPS und Durchsatz) nicht automatisch repliziert und wiederhergestellt. Möglicherweise müssen Sie diese Performanceeinstellungen neu konfigurieren.

Problemumgehung: Nachdem Sie einen DR-Plan ausgeführt haben, konfigurieren Sie die Performanceeinstellung manuell.

Details: Der On-Demand-Upload einer ZIP-Datei, die auf einem Windows-Rechner erstellt wird, kann den Loginhalt manchmal nicht hochladen. Der Grund für den Fehler ist, dass die Zeit der letzten Änderung der in Windows erstellten ZIP-Datei und die Erstellungszeit der Datei dieselbe sind. Wenn die Datei dekomprimiert wird, wird die Zeit der letzten Änderung der Datei als Erstellungszeit festgelegt. Möglicherweise liegt diese vor dem Zeitstempel der Logeinträge in der Logdatei. In diesem Fall werden Logeinträge, deren Zeitstempel eine Zeit nach der letzten Änderungszeit angibt, nicht hochgeladen.

Beispiel für das Problem:

Zeitstempel im Logeintrag: 2020-10-12 21:12:06

Zeit der letzten Änderung der Datei: 2020-10-10 08:00:00

Workaround: Kopieren Sie die Logdateien in einen neuen Ordner, und erstellen Sie eine ZIP-Datei. Durch diese Aktion erhalten Sie eine Änderungszeit, die später ist als der Zeitstempel der Logeinträge. Verwenden Sie diese neue ZIP-Datei für On-Demand-Uploads.

Anwendung des vorherigen Beispiels, nachdem der Workaround implementiert wurde:

Zeitstempel im Logeintrag: 2020-10-12 21:12:06

Zeit der letzten Änderung der Logdatei: 2021-03-31 08:00:00

Direkter Link zu diesem Problem: On-Demand-Upload von einem Windows-Rechner mit einer ZIP-Datei

Details: Ordner mit mehr als 10.000 Dateien können eine hohe Ressourcennutzung (Speicher/Speicher/CPU) durch den Management Agent verursachen. Dies kann zu einer langsamen Logerfassung führen, sich auf andere Funktionen des Management Agent auswirken und den Hostrechner verlangsamen.

Wenn vom Management Agent-Logging Analytics-Plug-in große Ordner gefunden werden, wird der Management Agent-Datei mgmt_agent_logan.log eine Meldung wie die folgende Beispielmeldung hinzugefügt:

2020-07-30 14:46:51,653 [LOG.Executor.2388 (LA_TASK_os_file)-61850] INFO - ignore large dir /u01/service/database/logs. set property loganalytics.enable_large_dir to enable. 

Lösung: Es wird empfohlen, große Ordner zu vermeiden. Verwenden Sie einen Bereinigungsmechanismus, um Dateien kurz nach der Erfassung zu entfernen, damit der Management Agent genügend Zeit hat, sie erneut zu erfassen.

Wenn Sie jedoch weiterhin Logs in großen Ordnern überwachen möchten, können Sie die Unterstützung aktivieren, indem Sie die folgende Aktion ausführen:

sudo -u mgmt_agent echo "loganalytics.enable_large_dir=true" >> INSTALL_DIRECTORY/agent_inst/config/emd.properties

Ersetzen Sie INSTALL_DIRECTORY durch den Pfad zum Ordner agent_inst, und starten Sie den Agent neu.

Direkter Link zu diesem Problem: Besondere Behandlung beim Monitoring von Logs in großen Ordnern